Commercial JDKs always offered AOT compilation, the problem is that people nowadays apparently don't buy compilers anymore unless forced to do so (e.g. embedded, consoles...).
Those are priced for people who already made a big investment in writing their application in Java and now realise they need features not present in javac. If you're just starting out, it can very well make more sense to use Microsoft Visual C++, which costs less than a commercial Java compiler and comes with an IDE that's light years ahead of anything available to Java developers.
Desktop Java also had many other problems, which can be summarised as "the JVM is its own OS". You can't write an application in Java that has a native look and feel. Or at least you couldn't for the first several significant years of its life and even now I don't think there's a good story for writing a simple native application. Meanwhile you could grab wxWidgets or Qt (and there goes your budget for a java compiler) and have a native-looking cross-platform application. Which very few did, because back then Mac OSX didn't exist, Apple were on their death bed and "Linux Desktop Environment" was even more of a joke than it is today.
So yeah, it didn't make any bit of sense to develop Java desktop apps given that you already had a large pool of proficient C++ developers, the only platform you cared about was Windows and Java GUI libraries insisted on reinventing their own look and feel. Oh and you could always just buy Delphi if you didn't want to suffer C++ (again, for a fraction of the price of a commercial Java compiler).
Nowadays people wrap a bunch of javascript in an electron instance, but this only happened after the web took off and nobody really looks at native desktop apps much. If this AOT work can give us fully contained native executables that we can distribute without having the user install Java and with significantly better performance than nodejs, maybe Java on the desktop can still happen.
That's not correct. The first UI toolkit Java had was AWT and it mapped through to native widgets. AWT was not very successful because it tried to be cross platform rather than a direct mapping of the Windows UI toolkit, which was significantly more advanced in that era than its competitors MacOS Classic and - most problematically - UNIX workstations, which had truly miserable UI toolkits. So AWT was limited to the lowest common denominator and trying to abstract UI libraries didn't work very well, the abstraction was leaky.
So for the first few years of Java's existence developers were given native UI, and said no, actually, we don't care if we have a native look and feel or not - for the kinds of line-of-business apps they were writing a powerful and consistent toolkit was more important than one that looked the right shade of grey. Hence, Swing.
Nowadays if you want to write a small, pure native Java app with native widgets you can do it with SWT and Avian. There's an example here:
https://readytalk.github.io/avian/
It demos all the features available in SWT with a 1mb download that's fully self contained. You still have the problem of leaky abstractions and SWT apps don't look entirely normal, as some more complex widgets still need to be custom, but it's another attempt at AWT that works significantly better as MacOS and Linux closed the gap with what Windows could do, so you can have a richer abstraction.
> If you're just starting out, it can very well make more sense to use Microsoft Visual C++, which costs less than a commercial Java compiler and comes with an IDE that's light years ahead of anything available to Java developers.
Sorry but you are way wrong.
I do consulting in Java, .NET and C++ eco-systems, and started using C++ back in 1993, when C++ARM was the only reference for a possible future standard.
The only C++ IDE that for many years could match the Java ones is C++ Builder.
Visual C++ only started to match C++ Builder now with the C++/CX + XAML, for the WinRT applications.
And while Visual C++ debugger and code navigation are quite good, they still don't rival Java IDEs or even their own .NET experience, without installing something like Visual Assist or ReSharper C++.
> You can't write an application in Java that has a native look and feel. Or at least you couldn't for the first several significant years of its life and even now I don't think there's a good story for writing a simple native application.
Sure you can, but developers seem not to like to read books, so they just write crappy Java desktop applications without learning how to use Swing.
> Meanwhile you could grab wxWidgets or Qt (and there goes your budget for a java compiler) and have a native-looking cross-platform application. Which very few did, because back then Mac OSX didn't exist, Apple were on their death bed and "Linux Desktop Environment" was even more of a joke than it is today.
We were targeting UNIX with Motif++ back in those days.
Regarding Windows, OWL and later VCL were way better than anything that Microsoft produced for C++. Even XAML was initially targeted to .NET.
As for Apple, we were mainly using Metrowerks with PowerPlant.
> If this AOT work can give us fully contained native executables that we can distribute without having the user install Java and with significantly better performance than nodejs, maybe Java on the desktop can still happen.
There are many applications that people aren't aware that are actually compiled with ExcelsiorJET.
As I said, this generation doesn't pay for compilers.
I seem to recall that GCJ had a lot of limitations back in the day - you couldn't use the same standard library, it didn't support newer language features, etc. Wouldn't surprise me if even now GCJ had poor integrations with IDEs and other essential tools to make Java livable.
Desktop Java also had many other problems, which can be summarised as "the JVM is its own OS". You can't write an application in Java that has a native look and feel. Or at least you couldn't for the first several significant years of its life and even now I don't think there's a good story for writing a simple native application. Meanwhile you could grab wxWidgets or Qt (and there goes your budget for a java compiler) and have a native-looking cross-platform application. Which very few did, because back then Mac OSX didn't exist, Apple were on their death bed and "Linux Desktop Environment" was even more of a joke than it is today.
So yeah, it didn't make any bit of sense to develop Java desktop apps given that you already had a large pool of proficient C++ developers, the only platform you cared about was Windows and Java GUI libraries insisted on reinventing their own look and feel. Oh and you could always just buy Delphi if you didn't want to suffer C++ (again, for a fraction of the price of a commercial Java compiler).
Nowadays people wrap a bunch of javascript in an electron instance, but this only happened after the web took off and nobody really looks at native desktop apps much. If this AOT work can give us fully contained native executables that we can distribute without having the user install Java and with significantly better performance than nodejs, maybe Java on the desktop can still happen.