Earlier quoted context omitted.
Jpackage or jlink should be extended to support creating AppImages.
It already supports that, try running "jpackage --help".
[deleted]
JEP 544: Ahead-of-Time Code Compilation
71–76 of 76 posts
Re: JEP 544: Ahead-of-Time Code Compilation
#72Earlier quoted context omitted.
Are you describing jpackage? I'm not sure how you would make it less bespoke, given you are essentially creating a Java runtime for your program. Maybe the Java folks could tree-shake the runtime for you so you wouldn't have to care about their weird module system, but it's not the worst thing to learn.
jpackage is heavily oriented around installable artifacts, it creates a .deb or .rpm for Linux for example. So if I wanted to throw someone a cli utility I can literally just send them the binary if I’m working in Go, whereas Java they need to use dpkg to install the deb. This somewhat complicates building a docker image as well. It’s the same story for windows and Mac as well. If I’m creating a Swing app or somethin…
[deleted]
Re: JEP 544: Ahead-of-Time Code Compilation
#73Earlier quoted context omitted.
Jpackage or jlink should be extended to support creating AppImages.
It already supports that, try running "jpackage --help".
Not really; `-type app-image` merely runs jlink and is intended to let you edit the bundle before calling jpackage again and create the installer. You need the tools from appimage.org for the final step.
Re: JEP 544: Ahead-of-Time Code Compilation
#74Earlier quoted context omitted.
It already supports that, try running "jpackage --help".
Not really; `-type app-image` merely runs jlink and is intended to let you edit the bundle before calling jpackage again and create the installer. You need the tools from appimage.org for the final step.
Ugh, that's a pretty bad name collision.
Re: JEP 544: Ahead-of-Time Code Compilation
#75Earlier quoted context omitted.
It works well enough for systems software written in C and C++, where Java still remains a niche option, even when it could deliver.
Java has many dynamic features where runtime optimization is required to remove the overhead. Virtual method calls are opt-out instead of opt-in, and there is an open world assumption. The possibility of doing stack allocation of objects depends on the call hierarchy (in the future it will get a bit easier with value objects). Also, C/C++ are not managed languages, therefore the effects of bad optimization don't hurt…
Depends on how many dynamic libraries or OOP features get used, or the C++ frameworks inspired by Smalltalk that predated Java by a decade.
Re: JEP 544: Ahead-of-Time Code Compilation
#76Earlier quoted context omitted.
There is no install time in Java. If you want something to happen at install time you'd have to ship a shell script with the installer that does a brief training run when the application is first started.
There is with jpackage. The packages it builds could include install scripts (or custom actions in the case of MSI) to run at install time. The script wouldn't have to do the training run at install time, as I understand it, just the AOT compilation. See the section on "AOTMode=record" vs "AOTMode=create" in the JEP.
That's basically what I said...