4 ms·

Java already solved this problem, for the most part. This whole ABI nonsense really grinds my gears. It's essentially just a result of the silly decision to com

Java already solved this problem, for the most part. This whole ABI nonsense really grinds my gears. It's essentially just a result of the silly decision to compile software into dubious blobs and ship those to users. You could get rid of an awful lot of malware and massively simplify software distribution if you were to distribute a platform agnostic intermediary representation of source code that preserves enough semantic meaning to eliminate ABI issues, then leaves the last step of compilation to the operating system. Shipping binary files is just plain bad in every way.

6483974564 2y ago
[flagged]
robocat 2y ago
> dubious blobs 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).
- James_K 2y ago
  I'm trying to replace platform dependant and easily breakable binary files with platform independent and change resistant files. Yes, those files are still in binary, but this is true of all files on a computer. What's useful about these new formats is that they retain a greater degree of information about the source code.
wyldfire 2y ago
> Shipping binary files is just plain bad in every way. 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.
- xxs 2y ago
  >Aren't .class and .jar files "binaries"? 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.
  - 3036e4 2y ago
    Java can be optimized beyond all recognition, into bytecode that can no longer be represented by the Java language. At least that used to be the case in the past. It is not different from other binaries, except the target system is a virtual CPU rather than a real one. 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.
nice_byte 2y ago
java classes have "abi". any binary representation of executable code that is supposed to be interacted with by other code necessarily defines an application BINARY interface.
- xxs 2y ago
  The point was that the "abi" is platform independent (and has very late bindings)
mqus 2y ago
You mean ABI issues like not being able to run a java 11 jar on a java 8 runtime?
- James_K 2y ago
  No, I mean ABI issues like not being able to change the order of fields in a struct.
DeathArrow 2y ago
Why Libre Office takes much more time to start than MS Office? Why does it feel sluggish? At least you didn't propose to write everything in Javascript.
- James_K 2y ago
  While the Java implementation is suboptimal, there is really no need for it to be that way. I think the ideal way to go about it would be to run the compiler optimisations and whatnot then generate something semantically similar to C89 as output. Then you invoke a simple compiler with few optimisations on the target machine the first time the program is run, and cache the results somewhere. On all subsequent runs, you've got something which can actually run faster than pre-compiled C code because the compiler doesn't need to preserve the ABI so can do stuff like inlining dynamic library calls.
  - DeathArrow 2y ago
    Do you know any software that does that?
    - James_K 2y ago
      Sadly not. Wasm is attempting something similar, but it lacks certain things that would be important for this (the to specify in one module a type of unknown size and then query its size in another module at link time).

6483974564 2y ago

[flagged]

robocat 2y ago

> dubious blobs 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).

James_K 2y ago
I'm trying to replace platform dependant and easily breakable binary files with platform independent and change resistant files. Yes, those files are still in binary, but this is true of all files on a computer. What's useful about these new formats is that they retain a greater degree of information about the source code.

wyldfire 2y ago

> Shipping binary files is just plain bad in every way. 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.

xxs 2y ago
>Aren't .class and .jar files "binaries"? 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.
- 3036e4 2y ago
  Java can be optimized beyond all recognition, into bytecode that can no longer be represented by the Java language. At least that used to be the case in the past. It is not different from other binaries, except the target system is a virtual CPU rather than a real one. 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.

nice_byte 2y ago

java classes have "abi". any binary representation of executable code that is supposed to be interacted with by other code necessarily defines an application BINARY interface.

xxs 2y ago
The point was that the "abi" is platform independent (and has very late bindings)

mqus 2y ago

You mean ABI issues like not being able to run a java 11 jar on a java 8 runtime?

James_K 2y ago
No, I mean ABI issues like not being able to change the order of fields in a struct.

DeathArrow 2y ago

Why Libre Office takes much more time to start than MS Office? Why does it feel sluggish? At least you didn't propose to write everything in Javascript.

James_K 2y ago
While the Java implementation is suboptimal, there is really no need for it to be that way. I think the ideal way to go about it would be to run the compiler optimisations and whatnot then generate something semantically similar to C89 as output. Then you invoke a simple compiler with few optimisations on the target machine the first time the program is run, and cache the results somewhere. On all subsequent runs, you've got something which can actually run faster than pre-compiled C code because the compiler doesn't need to preserve the ABI so can do stuff like inlining dynamic library calls.
- DeathArrow 2y ago
  Do you know any software that does that?
  - James_K 2y ago
    Sadly not. Wasm is attempting something similar, but it lacks certain things that would be important for this (the to specify in one module a type of unknown size and then query its size in another module at link time).