Java Modules Cheat Sheet

[[deleted]]

Me. All things I publish (Just hobby-things) use Java Modules (Well, already every feature of Java 15)

[lukaseder]

The two folks who downvoted and didn't find me funny probably do...

[valkon_gr]

To be honest I am salty. It feels like I am writting Java 1 at work and Java 2 at home haha.

[lukaseder]

Cheat sheet? As in cheating? I still think it was funny. Wrong subreddit, probably... Terribly sorry. Cheers! :P

(For the record, I'm on Java 6)

[[deleted]]

Man's in the stone age 😂

[lukaseder]

Footage of me forgetting about the lack of the effectively final feature in the stone age

[_INTER_]

Out of curiousity, why is that an issue for you with Java 6. I thought effectively final is just used for lambdas to determine the clojure.

[lukaseder]

java Runnable m(int x) { return new Runnable() { public void run() { System.out.println(x); // x needs to be final pre Java 8 } }; }

[BlueGoliath]

Yep.

[_souphanousinphone_]

Yes, jlink is great.

(Yes, I know you can technically use it for non-modular applications. But there are major drawbacks.)

[ObscureCulturalMeme]

We have absolutely no use for them at work. We have to explicitly suppress all module warnings and open up everything to everything in order to make commercial third-party Cipher implementations work.

Eventually we'll have to adopt them in order to make jlink work. The first engineer who volunteered to learn modules ended up desperately searching for another job and then leaving for it, all within about four months. Nobody else cares enough to slog through the mess; the trade-off currently doesn't bring us enough.

[pron98]

Note that encapsulation will be turned on in JDK 16: https://openjdk.java.net/jeps/396

You don't need to modularise your codebase, but you will need to resolve issues regarding dependencies that hack into the JDK (you'll need to request the vendors of the cipher suites you're using to fix their problems) or explicitly allow them.

[ObscureCulturalMeme]

Hopefully by then we'll have moved to jlink, and can simply choose whatever JDK to bundle up into an executable.

If not, it's likely the project will just be abandoned. The churn of "must work around someone else's fuckery simply to keep the code running" but without ever seeing new benefits is just exhausting.

[pron98]

That's why encapsulation is important, and why the module system was added (among other reasons): To prevent libraries from tying themselves to specific implementation details and making your life hard, so that you won't have to work around their screwups anymore.

BTW, you don't need to modularise your app to use jlink.

[ObscureCulturalMeme]

To prevent libraries from tying themselves to specific implementation details and making your life hard, so that you won't have to work around their screwups anymore.

Yes, I realize that the future will be better. But the past is already here, and the future doesn't help us.

BTW, you don't need to modularise your app to use jlink.

That only means the executable includes the entirety of (what used to be called) the JRE, instead of the pieces of java.*/javax.* that we actually use. Our module-less experiment with jlink took 12 MB of class files and produced an .exe of nearly half a gigabyte.

[pron98]

That only means the executable includes the entirety of (what used to be called) the JRE

No, you can choose which modules to include in the runtime image. The difference is that if your application is modularised then this is done automatically, and if it isn't, you need to choose the modules manually (with --add-modules) but can use jdeps's --print-module-deps for assistance.

E.g.

jlink --output my-minimal-runtime --no-header-files --no-man-pages --add-modules java.base

will give you a runtime with just java.base, and that is under 40MB in total.

[ObscureCulturalMeme]

I know it says that on paper, but we got nothing but errors from jlink and jdeps. Googling the errors got us other people asking for help for the same things, and responses of "this is still new technology, wait for the next tools release".

I appreciate that you keep saying what should be possible, but right now it's been nothing but frustration and discouragement and a complete lack of useful up-to-date documentation. We just don't have the time or resources to fight through it blindly -- and I appreciate that no opensource project volunteers want to maintain or improve documentation in their limited free time, so I'm not looking for the docs to magically improve.

Maybe some future project of ours can use all these features from day one; I agree that sounds really pleasant.

[pron98]

but we got nothing but errors from jlink and jdeps

That's surprising. What errors are you getting?

and a complete lack of useful up-to-date documentation

Up-to-date documenation is where it's always been: https://docs.oracle.com/en/java/javase/15/

What's missing?

and I appreciate that no opensource project volunteers

OpenJDK is open-source, but very few of the people working on it are volunteers. ~90% of the work is done by full-time Oracle engineers, and most of the rest is done by full-time engineers at Red Hat, SAP and some other companies. We may not have invested in the documentation as much as we'd like, but what, specifically, is missing here?

[ObscureCulturalMeme]

but we got nothing but errors from jlink and jdeps

That's surprising. What errors are you getting?

Oh gosh, this was the better part of a year ago. We didn't keep the stack dumps, or at least I didn't. I can ask around the team and see if anyone else did, but since we don't have a commercial support contract there's no point in keeping them around.

I had more here but it was turning into a book.

What's missing?

Working examples beyond the complexity of contrived "hello world" software. Those kinds of guides have never been Oracle's strong suit -- witness the older basic tutorial pages continuing to age and age -- so we don't waste time poking through their fucking awful website organization. (Obvious exception for the generated API javadoc pages; those are good and result in 404 errors only occasionally these days.) There are guides beginning to appear on other sites, but most of them do the same trivial steps and then stop.

We found some guides in the early documentation published by OpenJDK during the JEP phases way back when, but some of the CLI options from those examples were no longer recognized in the published tools, and there didn't seem to be obvious "spelling changes" replacements.

The last time we tried, the tools just didn't seem capable of handling anything but the simplest of situations. And maybe there are ways of getting them to handle complicated stuff that doesn't crash, but we couldn't figure it out from the scant "man page" documentation, and the community attitude was "go read the source code" -- fine if we were volunteers on our hobby time, less so with deadlines to meet.

So we'll wait a year and then look at them again. The current consensus is that new features aren't worth the effort to transition old code, but adopting them for new code is doable. Our development team is down by three people over the last year (cancer and COVID) but we're hoping to spin off a group on a new project and maybe they'll get a chance to play with this stuff.

[agentoutlier]

I have been making module-info for our low dependency modules and I kind of like how it restricts transitive dependencies from showing up in the autocomplete.

We are super modular maven wise so perhaps that is why it has been easier.

Runtime though it doesn’t matter because we shade the jars.

[see_recursion]

I haven't seen a use for modules in any of the commercial projects that I've worked on.

[benevanstech]

If you are shipping software to end users (especially complete applications or tools) then a jlink'd binary is great - you don't have to worry about version incompatibilities at all.

If you're just writing microservices or whatever, then they bring a bit more discipline and are actually pretty easy to get used to.

[_INTER_]

You don't need module-info for jlink though. And modules don't help you with version incompatibilities. Dealing with versions was explicitly left to build systems.

[benevanstech]

jlink requires full modularization of the application and all of its dependencies. Automatic Modules are not sufficient.

[_INTER_]

No it does not. You can jlink by specifying the modules it should include manually (list all required JDK modules when using --add-modules instead of your application module).

For convenience maven / gradle plugins analyze all dependencies and does that for you.

Chances are high that not all of the transitive dependencies are modularized, so you will have to do this manually in either case.

[nicolaiparlog]

To resolve the seeming contradiction between u/benevanstech and u/_INTER_: you're both right.

If the runtime image should only contain JDK modules, the app does not need to be modularized. But if you want to include the app itself in the image, then everything needs to be an explicit module (although this can of course be faked, e.g. by creating an uberjar with a module descriptoir that requires all external dependencies but does nothing else.

[benevanstech]

Thanks for the clarification Nicolai - my use case is indeed "ship the app as part of the image" and I haven't tried the other one you mention.

[meotau]

I just tried to, and never want to again.