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.

▲

pjmlp 4 hours ago | parent | next [-]

Because developers don't like to pay for tools.

https://en.wikipedia.org/wiki/Excelsior_JET

https://www.ptc.com/en/products/developer-tools/perc

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.

▲

rjsw 33 minutes ago | parent | next [-]

You could do AOT Java using gcj, it didn't need commercial tools.

▲

nikanj 4 hours ago | parent | prev | next [-]

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 4 hours ago \| parent \| next [-]
		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.
	▲	fithisux 21 minutes ago \| parent \| prev [-]
		I think what they do is correct. We also need to get paid this way.

▲

pjc50 3 hours ago | parent | prev [-]

You don't have to pay for dotnet AOT.

▲

gunnarmorling 4 hours ago | parent | prev | next [-]

> 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/). 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.

▲

gf000 5 hours ago | parent | prev | next [-]

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 4 hours ago \| parent [-]
		Except when they support dynamic linking they pay the indirect call cost that JITs can remove.

▲

xxs 4 hours ago | parent | prev [-]

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.