Aren't .class and .jar files "binaries"?
> Java already solved this problem, for the most part
Maybe, just maybe, there are some drawbacks that mean that in fact it's not solved. Otherwise perhaps Java would've completely obsoleted C, C++. Some of us design applications which can't tolerate the worst case GC pauses, for example. Some of us design applications which we can't afford to spend extra time heap-allocating nearly everything.
Not at all. jar is just a zip with a different extension +some metadata in META-INF (including dependencies). class are compiled java files but they do contain all kinds of metadata, including variable names and debug info (if you choose to retain it). they contain all methods and fields with their original names (along with annotations), so the reflection APIs work. Decompiling a class file is trivial to a point the original line numbers can be restored.
>Otherwise perhaps Java would've completely obsoleted C
Java does require a managed runtime written mostly in C/C++.
>Some of us design applications which can't tolerate the worst case GC pauses
The current breed or low latency GCs w/o a stop-the-world phase should suffices for a large set of applications.
>we can't afford to spend extra time heap-allocating nearly everything.
That has not been an issue for quite some time, heap allocation can be elided, and under normal condition is just a pointer bump. Per thread private allocation is by far the most common case - the garbage collection of non old-gen referenced objects is totally trivial too (i.e. memset). Even shared (cross thread/area) allocation is a CAS'd bump in most cases. Note: copy/generational garbage collectors copy objects that are referenced by non-young-gen ones to another area, then zero the original area.
With that being said - Java (and managed languages) are no panacea.
Java also deprecated all sorts of things over the years. Not to mention applets being completely killed off. I have Java binaries from 25 years ago that could no longer run at all with a contemporary run-time already 10-15 years ago.
Not to mention much of real-world Java is platform-specific. Not often native code perhaps, but more subtle things like hardcoded paths or forgetting to properly use the correct path-separator. Installers used to often be platform-specific as well. Maybe that has been solved, but you would still run into trouble trying to install an old Java application that has an installer only supporting contemporary Windows and Mac systems.
I am not sure how that works, Java is all about JIT. Bytecode almost doesn't matter. Personally I can read assembly (and years [decades] back could just read hex). So even obfuscated (not optimizied) Java is quite readable. Still, the class files do retain all method declarations, all constant pool entries and all bytecode (again trivial to decompile). There have been few changes in the class format of course.
> Java binaries from 25 years ago that could no longer run at all with a contemporary run-time already 10-15 years ago.
Need a shorter frame, Java 8 (10y back) could run pretty much anything from java 1.0 (or even 0.9). It's quite more recent - Java 9 (2017) that introduced project jigsaw. Prior that Java was by far the most backward compatible platform. Still is, for most applications. Do note deprecation mean(t) - do not use in new projects, not it has been removed; again those are more recent changes.
>Not to mention much of real-world Java is platform-specific.
Again, that's super rare nowadays. Stuff like zstd might load a library but even then the native code interfaces are the same across pretty much all platforms. If you talk about native UIs you might have some point, of course.
>to properly use the correct path-separator.
Windows with its backslash is notorious, yet - there is no reason to use backslash any longer, for like 25years now. All Windows paths do work with forward slash (aside that the separator is readily available in java.io.File)
First of all, I should like to point out that such people are overwhelmingly deluded and come to this belief without ever actually having tested the hypothesis. But at any rate, the idea of a JAR file doesn't require garbage collection. We can already see this with things such as Wasm, though it doesn't quite achieve what I would want.
I think you are just suggesting to replace binary blobs with other binary blobs e.g. CLR/.NET assemblies/executables or WebAssembly files.
Or do it the JavaScript way: distribute compressed minified (kinda compiled) source code and the runtime JIT compiles it at runtime (e.g. V8 engine Turbofan compiler).
At least you didn't propose to write everything in Javascript.
Can't we freeze the functionality of libc? Why does it need to be updated so frequently?
And even if we make changes to its implementation, why do we need to bump the version number if the underlying API is still the same?
Sure, but for how much longer will Microsoft allow this unsigned ancient binary?
Using Linux for runing Windows programs is going to be desperately needed as Microsoft enshittifies Windows going forward.
Windows S Mode was already a test.
The nagging, warning and outright "blocking" (while hiding the "run anyway" button under "more info") is the first step. This already is a warning to software vendors that something will come.
The next step will be blocking unsigned exes on Home Editions (not on Pro or Enterprise), so that software vendors and most of places depending on unsigned old software can move on to signed software.
Then Home and Pro Editions of windows wont be able to run unsigned software anymore and if you need unsigned software to run you'll have to use an Enterprise Edition.
The last step would be no windows can run unsigned software anymore and if you need unsigned software running, you'll need to run that one on an Azure instance of Windows which can still run unsigned software or (if you can't / don't want to run your software in the cloud) you will have to contact Microsoft for a special Windows version, costing lots of money. But if your business depends on that one single unsigned exe file, you might be ready to pay for that one.
Someone should develop an analog for Linux itself. I.e. support for older / historic ABIs that would be translated into whatever modern Linux has.
Some isolated example of that is SDL 1.x translated to SDL 2.
Wine itself already exists, you don't need to develop any new distro for running Windows programs on Linux. Just improve Wine if anything is missing.
We'll probably get a bit of irony in a few years when somebody at MS realizes that they can just use wine on top of their Linux emulation layer to run any old MS legacy software from the past three decades+ and then cleans up the rest of windows to not have any support for legacy APIs. Because having that is redundant. Emulators are great. There's no need to run ancient software natively.
Or, in other words, "We can solve any problem by introducing an extra level of indirection."
On Linux, you are supposed to share the source code, not the binaries. FOSS source is easier to fix than a binary blob. This is why the FSF exists.
But the trade-off is that the software you have in your repos will be really old. At the end your RHEL support cycle libs will be a decade out of date.
Point still stands: fixing the situation with these libraries seems like less fuss than turning Linux into windows.
Still I'd rather this than deal with daily driving Windows! I'm amazed at how good Gaming on Linux has gotten over the past few years.
Anything online with anti-cheat is usually broken.
The working number is usually around 40-50% see areweanticheatyet.com