Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Using jlink to cross-compile minimal JREs

jakewharton.com

Post reply on HN
Print view View original

51–60 of 66 posts

Re: Using jlink to cross-compile minimal JREs

#51

Post by toyg »

luxoramonrising wrote: post #47
toyg wrote: post #22

Earlier quoted context omitted.

We already have that, it's called a package manager. The concept has a number of problems (multiple runtime versions for multiple programs, who pays for and controls the repository, etc etc).

> multiple runtime versions for multiple programs For Java, the latest one. Current latest java still runs 20 year old jars. > who pays for and controls the repository The OS distributor.

> Current latest java still runs 20 year old jars.

Dude, I've been using Java since 1.2. Sure, all versions will try to "run" anything, but they'll do that with all sorts of slight differences and incompatibilities in behaviour - which make it effectively impractical for any serious program to run on anything but a small subset of tried and tested versions.

> The OS distributor

Careful what you wish for. Do you really want to hand Microsoft the power to decide which runtimes are allowed to run on Windows...?

Re: Using jlink to cross-compile minimal JREs

#52

Post by tyingq »

oblio wrote: post #24
pron wrote: post #10

These days, all Java runtimes are created with jlink, including the one that's bundled in the JDK, so it's worth it to take a few minutes to learn how to do it yourself for a custom image. The result is not only drastically smaller, but more secure, as the potential attack surface area is much smaller. If your application is modularised, it can become a part of the image, but, as the article shows, creating a custom…

How is modularization progressing in practice? Stuff like Hibernate, Spring, the big libraries. How easy is it for the average greenfield enterprise to start as a modular app? How easy is it for the average brownfield enterprise app started 10 years ago to convert to a modular app?

Even without being modular, switches like --strip-debug --no-man-pages --no-header-files net you a fair amount of space saving.

Re: Using jlink to cross-compile minimal JREs

#53

Post by erik_seaberg »

kaba0 wrote: post #18
erik_seaberg wrote: post #16

Earlier quoted context omitted.

Yeah, I have trouble believing a private runtime image per app isn't going to add up to more than one complete runtime image provided by the system package manager or shared Docker layer.

But unfortunately the state would be having `n` complete runtime images for different versions. This is not a Java problem, Java just followed suit, and seemingly the preferred way of delivering executables is bundling everything.

Yeah, that’s not my preference, and I haven’t seen a team do it.

Re: Using jlink to cross-compile minimal JREs

#55

Post by clhodapp »

whartung wrote: post #48
oblio wrote: post #24

Earlier quoted context omitted.

How is modularization progressing in practice? Stuff like Hibernate, Spring, the big libraries. How easy is it for the average greenfield enterprise to start as a modular app? How easy is it for the average brownfield enterprise app started 10 years ago to convert to a modular app?

It's getting better to be sure. It's definitely taken time for the libraries to catch up, but when 17 came out and put a kibosh on the work arounds folks relied upon when using libraries that were not properly modularized. From a JakartaEE perspective, that's a different world. The containers were modular runtimes of their own sort anyway, many are built upon OSGI, etc. I don't think mainstream EE projects are using…

It's a real shame that modularization focused almost entirely on solving the JDK vendor's problems rather than solving the application author's problems.

Specifically, modularization can and should have been taken as a chance to allow multiple versions of the same dependency to exist within a single scope within an application. At present, this is sort of achievable by taking control of classloading and invoking defineModulesWithManyLoaders, but not many people will do this and key features are missing (it still does not allow a single module to directly reference two versions of the same dependency).

Re: Using jlink to cross-compile minimal JREs

#56

Post by synergy20 »

brabel wrote: post #49
synergy20 wrote: post #40

This is awesome to know, I'm using Dart these days(java like language) that has a much smaller runtime(helloworld is 6MB), any one tried it with swing for GUI and see how large the final size is about.

I also use Dart to create native binaries! Just because it's so easy. I have a real CLI app that does quite a lot of stuff, and it's less than 8MB. And runs really fast! At least around as fast as a Java native app compiled with native-image (GraalVM), but I hate native-image because it takes MINUTES to compile and sometimes does not behave exactly like the JVM-version (Dart doesn't even need to compile, you can run…

in some way, Dart is a better and easier Java, I hope Google will change Dart from a client-optimized language to a general-purpose language working at both client and server. It works for server now, but still it's client-optimized. Anyways, I really like Dart a lot.

Re: Using jlink to cross-compile minimal JREs

#57

Post by pron »

clhodapp wrote: post #55
whartung wrote: post #48

Earlier quoted context omitted.

It's getting better to be sure. It's definitely taken time for the libraries to catch up, but when 17 came out and put a kibosh on the work arounds folks relied upon when using libraries that were not properly modularized. From a JakartaEE perspective, that's a different world. The containers were modular runtimes of their own sort anyway, many are built upon OSGI, etc. I don't think mainstream EE projects are using…

It's a real shame that modularization focused almost entirely on solving the JDK vendor's problems rather than solving the application author's problems. Specifically, modularization can and should have been taken as a chance to allow multiple versions of the same dependency to exist within a single scope within an application. At present, this is sort of achievable by taking control of classloading and invoking defi…

> Specifically, modularization can and should have been taken as a chance to allow multiple versions of the same dependency to exist within a single scope within an application....

Modules do it to the best extent possible, but they don't make it prominent because, quite simply, it's impossible to do in a way that's good enough to be advisable. In order for a library to be properly isolatable, it has to be written in a specific way and be quite limited. Any kind of input or output, including the reliance on configuration outside of the source code can immediately make the library susceptible to horrible problems when multiple copies of it exist in the same process, even if isolated. So modules allow you to use class loader isolation if you really need it, but they don't try to pretend it can actually work in general.

The main (though not only) thing that modules exist to provide is strong encapsulation, which is crucial for security and makes code evolution much easier.

Re: Using jlink to cross-compile minimal JREs

#58

Post by captainmuon »

toyg wrote: post #22
captainmuon wrote: post #15

It's a pity that system wide JREs are not a thing anymore. I understand that it was difficult to get an updated JRE on the system in the early 2000s, but nowadays almost every computer is online - certainly one where you are currently downloading an application on - and automatic updates are commonplace. You used to be able to just double click on a .jar, and that was a Java application. And it would be trivial engin…

We already have that, it's called a package manager. The concept has a number of problems (multiple runtime versions for multiple programs, who pays for and controls the repository, etc etc).

I don't know, my package manager doesn't let me download an application without runtime - say QBittorrent without Qt or Deluge without Gtk and Python - double click on an icon, and then say "It looks like you are trying to write a letter run an app that needs a library" and then proceeds to fetch it... from my package manager.

I mean, 80/20 principle. You would only have to write code for the dozen or so runtimes, and then add metadata for a few hundred or so popular apps. Totally in reach for a volunteer community (like many distros, or stuff like PortableApps) and especially for a companies like Canonical or Microsoft. And then when it is going, people would add metadata to their apps themselves, and we would no longer have to ship the runtimes together with the apps.

Think of the metadata it like a 21st century shebang line. Not `#!/usr/bin/env python`, but `#"§% require python>3.9 and gtk-stack>4.0` or `require java-xxx`.

Re: Using jlink to cross-compile minimal JREs

#59

Post by TacticalCoder »

pron wrote: post #10

These days, all Java runtimes are created with jlink, including the one that's bundled in the JDK, so it's worth it to take a few minutes to learn how to do it yourself for a custom image. The result is not only drastically smaller, but more secure, as the potential attack surface area is much smaller. If your application is modularised, it can become a part of the image, but, as the article shows, creating a custom…

> Some people still use the anachronistic term JRE to refer to a Java runtime

Starting with Oracle which, on its Java download page, offers the choice to download the "JRE for consumers" so there's that.

Re: Using jlink to cross-compile minimal JREs

#60

Post by pron »

TacticalCoder wrote: post #59
pron wrote: post #10

These days, all Java runtimes are created with jlink, including the one that's bundled in the JDK, so it's worth it to take a few minutes to learn how to do it yourself for a custom image. The result is not only drastically smaller, but more secure, as the potential attack surface area is much smaller. If your application is modularised, it can become a part of the image, but, as the article shows, creating a custom…

> Some people still use the anachronistic term JRE to refer to a Java runtime Starting with Oracle which, on its Java download page, offers the choice to download the "JRE for consumers" so there's that.

That actually is the JRE for Java 8, the last JRE.
Post reply on HN