6 ms·

I never understood why AOT never took off for Java. The write once run anywhere quickly faded as an argument, the number of platforms that a software package ne

by ck45 10mo ago

I never understood why AOT never took off for Java. The write once run anywhere quickly faded as an argument, the number of platforms that a software package needs to support is rather small.

gf000 10mo ago
Well, one aspect is how dynamic the platform is. It simply defaults to an open world where you could just load a class from any source at any time to subclass something, or straight up apply some transformation to classes as they load via instrumentation. And defaults matter, so AOT compilation is not completely trivial (though it's not too bad either with GraalVM's native image, given that the framework you use (if any) supports it). Meanwhile most "AOT-first" languages assume a closed-world where everything "that could ever exist" is already known fully.
- pjmlp 10mo ago
  Except when they support dynamic linking they pay the indirect call cost that JITs can remove.
pjmlp 10mo ago
Because developers don't like to pay for tools. https://en.wikipedia.org/wiki/Excelsior_JET https://en.wikipedia.org/wiki/Excelsior_JET https://www.ptc.com/en/products/developer-tools/perc https://www.ptc.com/en/products/developer-tools/perc https://www.aicas.com/products-services/jamaicavm/ https://www.aicas.com/products-services/jamaicavm/ It is now getting adopted because GraalVM and OpenJ9 are available for free. Also while not being proper Java, Android does AOT since version 5, mixed JIT/AOT since version 7. EDIT: Fixed the sentence regarding Android versions.
- nikanj 10mo ago
  Developers pay for tools gladly when the pricing model isn’t based on how much money you’re making. I’m happy to drop a fixed 200e/mo on Claude but I’d never sign paperwork that required us to track user installs and deliver $0.02 per install to someone
  - jacquesm 10mo ago
    Especially not if those kind of contracts don't survive an acquisition because then your acquisition is most likely dead in the water. The acquirer would have to re-negotiate the license and with a little luck they'd be screwed over because they have nowhere else to go.
    - Joel_Mckay 10mo ago
      I have seen worse, where people updated the EULA 6 months after being paid $14k/seat. Now it is FOSS all the way... lesson learned... =3 https://www.youtube.com/watch?v=WpE_xMRiCLE https://www.youtube.com/watch?v=WpE_xMRiCLE
      - jacquesm 10mo ago
        That is something that I never understood, that that's even legal. You enter into an agreement (let's call it a contract, because that's how the other side treats it) and then, retroactively they get to pull the rug right out from under you. I made the 'FOSS all the way' decision somewhere in '96 or so but unfortunately our bookkeeping system and our own software package only worked on Windows (this was an end-user thing) so we had to keep one windows machine around. I was pretty happy when we finally switched it off. The funny thing is that I wouldn't even know where to start to develop on/for mac or windows, Linux just feels so much more powerful in that sense. Yes, it has some sharp edges but for the most part it is the best thing that could have happened to the world of software development.
        Joel_Mckay 10mo ago
        I have done native cross-platform projects in https://wxwidgets.org/ https://wxwidgets.org/ and https://quasar.dev/ https://quasar.dev/ . Fine for basic interfaces, but static linking on Win64 gets dicey with lgpl libraries etc. YMMV For iOS targets, one must use a MacOS environment with a non-free Apple developer account. Personally, I like Apache 2.0, and standard quality of life *nix build tools. Everything Windows runs off a frozen VM backing image KVM COW file now, as even Microsoft can no longer resist the urge to break things. =3
- pjc50 10mo ago
  You don't have to pay for dotnet AOT.
  - pjmlp 10mo ago
    Actually you do indirectly, via Windows licenses, Office, Azure, Visual Studio Professional and Ultimate licenses, C# DevKit. Also you are forgetting AOT first came with NGEN, .NET Native, commercial, and on Mono side, Xamarin had some price points for AOT optimiztions, if I recall correctly. However this is a moot point, you also don't pay for GraalVM, OpenJ9, or Android.
  - vips7L 10mo ago
    You don’t have to pay for Java AOT either. Graal is free.
- rjsw 10mo ago
  You could do AOT Java using gcj, it didn't need commercial tools.
  - pjmlp 10mo ago
    If we ignore gcj was never production ready, and basically the only good case that Red-Hat sponsored was to compile Eclipse, which was usually slower than using the JIT anyway. And that around 2009, most of the team left the project, some went to OpenJDK, others elsewhere, while GCC kept it around because gcj unit tests stressed parts of the GCC that weren't tested by other frontends, until the decision came to remove it completly. As side note, I expect a similar outcome to gccgo, abandoned since Go added generics support.
gunnarmorling 10mo ago
> I never understood why AOT never took off for Java. GraalVM native images certainly are being adopted, the creation of native binaries via GraalVM is seamlessly integrated into stacks like Quarkus or Spring Boot. One small example would be kcctl, a CLI client for Kafka Connect (https://github.com/kcctl/kcctl/ https://github.com/kcctl/kcctl/). I guess it boils down to the question of what constitutes "taking off" for you? But it's also not that native images are unambiguously superior to running on the JVM. Build times definitely leave to be desired, not all 3rd party libraries can easily be used, not all GCs are supported, the closed world assumption is not always practical, peak performance may also be better with JIT. So the way I see it, AOT compiled apps are seen as a tactical tool by the Java community currently, utilized when their advantages (e.g. fast start-up) matter. That said, interesting work is happening in OpenJDK's Project Leyden, which aims to move more work to AOT while being less disruptive to the development experience than GraalVM native binaries. Arguably, if you're using CDS, you are using AOT.
xxs 10mo ago
dynamic class loading is a major issue, and it's an integral feature. Realistically, there are very few cases that AOT and Java make sense.
dehrmann 10mo ago
I'm not sure how much Hotspot can do this, but JIT means you can target different CPUs, taking advantage of specific extensions or CPU quirks. It can also mean better cache performance because you don't need branches to handle different chips, so the branch is gone and the code is smaller.

by ck45 10mo ago

I never understood why AOT never took off for Java. The write once run anywhere quickly faded as an argument, the number of platforms that a software package needs to support is rather small.

gf000 10mo ago

Well, one aspect is how dynamic the platform is. It simply defaults to an open world where you could just load a class from any source at any time to subclass something, or straight up apply some transformation to classes as they load via instrumentation. And defaults matter, so AOT compilation is not completely trivial (though it's not too bad either with GraalVM's native image, given that the framework you use (if any) supports it). Meanwhile most "AOT-first" languages assume a closed-world where everything "that could ever exist" is already known fully.

pjmlp 10mo ago
Except when they support dynamic linking they pay the indirect call cost that JITs can remove.

pjmlp 10mo ago

Because developers don't like to pay for tools. https://en.wikipedia.org/wiki/Excelsior_JET https://en.wikipedia.org/wiki/Excelsior_JET https://www.ptc.com/en/products/developer-tools/perc https://www.ptc.com/en/products/developer-tools/perc https://www.aicas.com/products-services/jamaicavm/ https://www.aicas.com/products-services/jamaicavm/ It is now getting adopted because GraalVM and OpenJ9 are available for free. Also while not being proper Java, Android does AOT since version 5, mixed JIT/AOT since version 7. EDIT: Fixed the sentence regarding Android versions.

nikanj 10mo ago
Developers pay for tools gladly when the pricing model isn’t based on how much money you’re making. I’m happy to drop a fixed 200e/mo on Claude but I’d never sign paperwork that required us to track user installs and deliver $0.02 per install to someone
- jacquesm 10mo ago
  Especially not if those kind of contracts don't survive an acquisition because then your acquisition is most likely dead in the water. The acquirer would have to re-negotiate the license and with a little luck they'd be screwed over because they have nowhere else to go.
  - Joel_Mckay 10mo ago
    I have seen worse, where people updated the EULA 6 months after being paid $14k/seat. Now it is FOSS all the way... lesson learned... =3 https://www.youtube.com/watch?v=WpE_xMRiCLE https://www.youtube.com/watch?v=WpE_xMRiCLE
    - jacquesm 10mo ago
      That is something that I never understood, that that's even legal. You enter into an agreement (let's call it a contract, because that's how the other side treats it) and then, retroactively they get to pull the rug right out from under you. I made the 'FOSS all the way' decision somewhere in '96 or so but unfortunately our bookkeeping system and our own software package only worked on Windows (this was an end-user thing) so we had to keep one windows machine around. I was pretty happy when we finally switched it off. The funny thing is that I wouldn't even know where to start to develop on/for mac or windows, Linux just feels so much more powerful in that sense. Yes, it has some sharp edges but for the most part it is the best thing that could have happened to the world of software development.
      - Joel_Mckay 10mo ago
        I have done native cross-platform projects in https://wxwidgets.org/ https://wxwidgets.org/ and https://quasar.dev/ https://quasar.dev/ . Fine for basic interfaces, but static linking on Win64 gets dicey with lgpl libraries etc. YMMV For iOS targets, one must use a MacOS environment with a non-free Apple developer account. Personally, I like Apache 2.0, and standard quality of life *nix build tools. Everything Windows runs off a frozen VM backing image KVM COW file now, as even Microsoft can no longer resist the urge to break things. =3
pjc50 10mo ago
You don't have to pay for dotnet AOT.
- pjmlp 10mo ago
  Actually you do indirectly, via Windows licenses, Office, Azure, Visual Studio Professional and Ultimate licenses, C# DevKit. Also you are forgetting AOT first came with NGEN, .NET Native, commercial, and on Mono side, Xamarin had some price points for AOT optimiztions, if I recall correctly. However this is a moot point, you also don't pay for GraalVM, OpenJ9, or Android.
- vips7L 10mo ago
  You don’t have to pay for Java AOT either. Graal is free.
rjsw 10mo ago
You could do AOT Java using gcj, it didn't need commercial tools.
- pjmlp 10mo ago
  If we ignore gcj was never production ready, and basically the only good case that Red-Hat sponsored was to compile Eclipse, which was usually slower than using the JIT anyway. And that around 2009, most of the team left the project, some went to OpenJDK, others elsewhere, while GCC kept it around because gcj unit tests stressed parts of the GCC that weren't tested by other frontends, until the decision came to remove it completly. As side note, I expect a similar outcome to gccgo, abandoned since Go added generics support.

gunnarmorling 10mo ago

> I never understood why AOT never took off for Java. GraalVM native images certainly are being adopted, the creation of native binaries via GraalVM is seamlessly integrated into stacks like Quarkus or Spring Boot. One small example would be kcctl, a CLI client for Kafka Connect (https://github.com/kcctl/kcctl/ https://github.com/kcctl/kcctl/). I guess it boils down to the question of what constitutes "taking off" for you? But it's also not that native images are unambiguously superior to running on the JVM. Build times definitely leave to be desired, not all 3rd party libraries can easily be used, not all GCs are supported, the closed world assumption is not always practical, peak performance may also be better with JIT. So the way I see it, AOT compiled apps are seen as a tactical tool by the Java community currently, utilized when their advantages (e.g. fast start-up) matter. That said, interesting work is happening in OpenJDK's Project Leyden, which aims to move more work to AOT while being less disruptive to the development experience than GraalVM native binaries. Arguably, if you're using CDS, you are using AOT.

xxs 10mo ago

dynamic class loading is a major issue, and it's an integral feature. Realistically, there are very few cases that AOT and Java make sense.

dehrmann 10mo ago

I'm not sure how much Hotspot can do this, but JIT means you can target different CPUs, taking advantage of specific extensions or CPU quirks. It can also mean better cache performance because you don't need branches to handle different chips, so the branch is gone and the code is smaller.