NTS (TeX reimplementation in Java from 2001) still compiles under Java 16 | Hacker News Reader

NTS (TeX reimplementation in Java from 2001) still compiles under Java 16

github.com

68 pointswolfi163 comments

I've been maintaining a "port" of an older enterprise KVM tool that was written for something along the lines of Java 6-8 and required a very minimal rewrite patch to keep working. The most annoying parts of older Java binaries are ones that used the "sun.*" packages that were disabled at some point.

https://github.com/mmastrac/raritan-multi-platform-client-mo...

Say what you will about Java, but the app actually functions -- including all the wild features like remote virtual media, audio tunnelling, etc. It doesn't look very pretty, however.

I've not used Java for many years now, but earlier when I did, the "sun.*" packages were clearly mentioned as subject to change and not to be relied on, IIRC.

And with so many people falling into the same trap, there are usually drop-in replacement packages.

Same goes for javax -> jakarta since the handover of enterprise Java from Oracle to Eclipse.

'find . -name "*.java" -exec sed -i "s/search/replace/g" \;' on a per package basis will likely sort things out.

The same as is true for most 1990s Win32 apps. Java and the Windows API seem to be the only stable pillars in this industry.

Totally agree.

What is amazing to me is just how fast those apps run even on W11. I have an older copy of Adobe Acrobat, and double-clicking a .pdf to full app launch and render is literally an eye blink. Compare to Reader DC, which is about 5 seconds of who knows what.

They are fast precisely because you are running them on win11 hardware. Try running them on the old pentiums or Core 2s and they would be just as slow.

I think you are actually reinforcing the point: Software has gotten very slow and does a whole bunch of who knows what.

Try using any of that 25-year-old software with accessibility devices, or at any DPI scaling other than 96x96, or split between two monitors with different refresh rates (or worse yet, two monitors connected to two different GPUs), or with sound or 3D accel that works over RDP, or with an RTL UI language. Those are some of the many "whats" that you get batteries-included in modern OS UI frameworks in exchange for the added overhead.

> or worse yet, two monitors connected to two different GPUs

This was a great feature of the Macintosh II in 1987. Sad that it's not ubiquitous yet. (Even modern Macs snap apps to one monitor or the other, so no video walls.)

> Even modern Macs snap apps to one monitor or the other, so no video walls

Linux, and I believe Windows as well, can display windows across different monitors just fine. But sometimes the monitors are too different, and part of the window gets ugly. Probably a blocker in Appleverse.

Those will maybe account for 2x slowdown if we are being generous.

The vast majority is just bloat. Unimaginable bloat, hundreds of levels deep.

I'm sure you're right in what you say, but this is not the reason modern acrobat is slow. I'm sure you could build a modern and accessible app that starts and loads the requested PDF snappily to show it, but acrobat will also (iirc) have some cloud integration now for storage and a bunch of the features they offer are gated behind some sort of subscription, the status of which I would guess is loaded on startup, probably along with a bunch of other stuff.

The hardware is not a bit faster. It is many order of magnitude faster.

I can play video games at 4k 10bit HDR 120Hz with a 1kHz mouse polling rate. I can copy data at 10Gbps across computers via 30m of copper. I can transfer at 1.3Gbps through wifi.

But it takes 250ms for the f'n calculator to start up on a good day?

This is a general issue to all modern software.

Although it's true that maintained UI frameworks have features less-maintained UI frameworks don't, this isn't really the cause of the slowdowns. Those features are all edge cases that aren't in use most of the time, by most users, and so shouldn't be incurring any significant performance hit on the regular paths.

And you can certainly have such features in modern / fast frameworks. Take a Java Swing or JavaFX app and compile it with GraalVM Native Image. The framework dates from the 90s but is maintained because JetBrains relies on it. It supports hi-dpi displays, accessibility apps, multi-monitor rendering and so on. And when natively compiled, it will start in the blink of an eye.

Can you actually compile Swing or JavaFX with GraalVM? I have only ever heard anecdotal evidence of that, even though I have known people from the Graal team itself.

Like, there shouldn’t be anything fundamental that prevents it from working (it just has platform specific native dyn libs which works fine with graal), but never seen an example, so I would appreciate a pointer.

Haven't tried it, but looks like you can: https://www.praj.in/posts/2021/compiling-swing-apps-ahead-of...

Sure. For JavaFX see here:

https://github.com/gluonhq/substrate

Sibling gave a link for Swing. I've also seen it done for Jetpack Compose but that's definitely more experimental.

None of this stuff is very smoothed over though. There aren't many people doing it. But, the results are pretty magical.

What makes old apps lean launch ultrafast and modern superbloated apps launch at barely tolerable speed are SSDs, not CPUs.

(FYI: Older versions of the PDF reader might have critical parsing vulnerabilities that affect system security. You're probably fine if you only download trusted PDFs, but it's best to take caution.)

amusingly the older versions are still available on Adobe FTP

ftp://ftp.adobe.com/pub/adobe/reader/

And .NET Framework. You can still run 3.5 applications, and 4.5 will also exist as long as Windows will exist.

And yet, as with so many other systems Microsoft can't or won't keep this up for newer versions. I spent part of Thursday wrestling with Graph code that it turns out has an older version of one Nuget package, and if you "just" upgrade it now all the authentication layer is completely broken and needs to be redesigned because it's apparently "better" with the "streamlined" modern version, but if you don't upgrade it nobody's documentation for the problems we're solving matches because they also moved a bunch of the extension methods to different places or renamed things, again you know for streamlining.

Somebody else on HN said they don't rely on anything which has Semver and yet the major version is 4 or greater, because that means they were so wrong they had to change their API already at least three times so they've clearly got no idea what they're doing. I think I'm beginning to agree.

> You can still run 3.5 applications

Given the discussion in a sibling (nephew?) thread (https://news.ycombinator.com/item?id=40755845), I thought at first that this was a description of how many modern, bloated apps you could run on a modern computer before the OS slowed to a crawl.

and Go.

Go 1.0 code mostly compiles and runs just fine.

Not really the same, .NET Framework is a dead end, current .NET (former Core) is quite different, you can't port .NET Framework 4.8 apps to .NET 8

You can.

C# 1.0 is still valid syntax, and library authors can target both legacy and current day versions of .NET with netstandard2.0 target. Most libraries do just that.

Moreover, there are still some applications that get to use modern runtime-independent language features and SDK-style projects (terse Cargo.toml-like project manifests, still XML but they are very readable) while targeting both .NET Framework 4.8 and .NET 8 at the same time (and everything in-between them). Hell, I've seen projects[0] which look relatively modern but for some reason still target .NET Framework 3.5, I do not condone that, but it is doable and sometimes there are reasons for it.

[0]: https://github.com/Kevin-Robertson/Inveigh/blob/master/Invei...

You can do (almost) everything with enough time and resources, but it can be tough. WCF, without CoreWCF couldn't migrate until 2022 release and .Net Core 1.0 was released in 2019. EF Core is different. WPF, ASP .Net WebForms... Microsoft Message Queues usage is a no go. So yes, you can, not always, not easy, often not worth.

(2016) https://devblogs.microsoft.com/dotnet/announcing-net-core-1-...

I wonder why enterprises use Windows and Java rather than convert to the latest new language.

The enterprise want to keep running. IT is a cost so not needing to upgrade is a massive win.

And Perl 5.

> Running the tests is really easy. Because there are no tests, to run the tests you just do nothing.

Maybe I should adopt this mentality.

To paraphrase Wayne Gretzky, you pass 100% of the tests you don't write.

All you have to do is not care about the next person doing your job and it's easy —the poor shmuck.

"Nobody goes there anymore. It's too crowded." - Yogi Berra.

Too bad the next person doing your job will probably be you.

But does it still compile under Java 17 and Java 21? :)

I just tested it with OpenJDK 22, and it actually still works.

That is pretty incredible, thanks!

Being used to current industry-standard Java practices, this source code looks like C to me. No streams, no generics, no patterns, but lots of mutable variables and for/while loops. And no tests of course! No build tool! Java was a _very_ different language (and ecosystem) back then, kind of like the wild west.

This does not read like C at all.

It's not structured like C code would be, but some parts of the code itself read like older C++ with labeled break/continue, e.g. this function: https://github.com/jamespfennell/new-typesetting-system/blob...

generics were introduced in 2004, this code is from 2001. As for the build system, I find it refreshing that you only need javac and nothing else

Love the print statements still in the code:

https://github.com/jamespfennell/new-typesetting-system/blob...

Alot of this doesnt look much different than Java code bases i see

Someone should try to compile it to a Javascript web application with TeaVM.

The license on that is so bizarre! What was the original intent of that license? It’s just really bizarre requirements, like you have to rename a file if you modify it, except maybe some files that specifically prevent any modifications… just weird stuff.

> NTS has a custom open source license with extremely strange clauses around modification.

My word, that is indeed an odd licence! Those "strange clauses" make up most of the body of the licence. I've never read a licence like that before.

xneko, an X11/UNIX port of a somewhat famous cute cat chasing a mouse pointer last updated in 1993, still compiles and runs under macOS. You need Xquartz because xneko is an X11 program, but that’s it.

The only problem we see with our old legacy Java code is third-party libraries. Some of them do not exist in newer versions.

What do you mean? Unless they use sun.*, those old libraries should be fine.

Since Java 9 deprecated APIs are actually removed, and since Java 16 naughty reflection tricks are forbidden.

Both are rare to encounter. I think migration of JavaEE to JakartaEE had bigger impact than anything else, but even in that case working with javax packages is still possible.

What about the old binaries do they still run on windows and linux?

Do you mean the jars, or the JRE itself?

I mean the jars.

I haven’t tried in this particular case, but they are very backwards compatible and I have had success running some CS professor’s 20 years old random, obscure jar about some datastructure visualization, downloaded from these old, ugly html-only university website.

Not this one but there is a logic gate simulator I used in Uni called Logisim whose JARs (compiled ~10 years ago) continue to work in JRE 21 on my PC.

why are you so amazed? software is not apples, doesn't rot by itself.

People have gotten used to the world moving under their feet. I got used to common lisp in the 90s, and it bothers me that some code I wrote in other languages doesn't run after 10 years. I even had things stop working during the same major version of python.

It differs from language to language. Java was designed for "write once, run anywhere" - which includes in the future. They have been very careful -- too careful, some would argue -- to keep backwards compatibility. Other languages don't care about that so much, preferring evolving rapidly. Unfortunately, it's not something you can predict. Also, compilers change, sometimes introducing bugs of their own, sometimes fixing bugs that the software relied on. A program doesn't exist in a vacuum.

I find old Linux executables, and Python programs, are two particular cases where it's very hard to run old versions.

I keep a set of old Debian VMs around, to find a machine from the time a program was created, so I can run older stuff.

(If you wonder why I'm running so much old, unsupported stuff, that's academic research software for you)

That what you would think.

I started using again an old ~12 year old Asus Android tablet. Impossible to browse the web, as it doesn't support newer TLS versions, newer CA. Impossible to install more recent software on that old Android version. Play store don't even work anymore (probably for the TLS reason). Then I wanted to install a recent Linux, and even after working around all the above and have the Asus bootloader unlock app installed, with mitm proxy to simulate old TLS, I realized that the Asus service to unlock bootloader doesn't exist anymore...

Software rot so much faster than hardware sadly :( (the good news is that old software is also full of vuln, so I was able to install my Linux - postmarketos - anyway without unlocking the bootloader, and to my surprise, everything works perfectly out of the box)

> service to unlock bootloader

WTF. Did that service check something while it worked?

Reply on news.ycombinator.com