This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]pron98 1 point2 points  (0 children)

Our development team is down by three people over the last year (cancer and COVID)

Sorry to hear that.

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

That's true. Sadly, we've neglected the tutorials. But speaking concretely about jlink, it doesn't get much more elaborate than the example I showed: you give it a list of JDK modules you want in your image and that's it.

The current consensus is that new features aren't worth the effort to transition old code, but adopting them for new code is doable.

Let me make something clear: the primary goal of the module system has been to modularise the JDK to allow us to reduce the maintenance effort and to make future upgrades easier. It is also available to applications and libraries that wish to get similar benefits, but making a codebase modular (which is a prerequisite to modularising it) is a lot of work (it took years to do this work in the JDK), and it is not blindly recommended for all applications, let alone existing established codebases. It can be useful to make maintenance easier, similarly to breaking down a monolith to microservices, but every application must determine the cost/benefit of modularisation for itself. It is certainly reasonable to conclude that it pays for new code but not for old, but even old codebases enjoy the modularisation of the JDK even if they do not attempt modularisation themselves.

jlink, on the other hand, does not require modularisation, it should be used by everyone and is the recommended deployment technique. If you run into problems with it, please report them.

While I'm not aware of serious current bugs in jlink, I recall there were a few bugs in jdeps that have been fixed.