Java 11

36 views
Skip to first unread message

Andrus Adamchik

unread,
May 21, 2021, 2:38:06 AM5/21/21
to Bootique User Group
Now that 2.0 went beta, and the active line of development is 3.0, it may be the time to start making some changes. This one is about Java 11.

There is a suggestion that we upgrade "bootique-jetty" from 9 to 10/11 [1]. Both of those require Java 11 (the latter also requires a switch to JakartaEE packages, but let's focus on Java version at the moment).

For everyone's sanity we would like to keep the same minimal JDK requirement for all Bootique modules (there's an implicit assumption that you can mix and match any Bootique module with any other Bootique module, and we'd like to preserve it).

So should Bootique 3.0 should switch to Java 11 across the board? Java 8is 7 years old [2], and I'd say "yes". But 8 is still the prevailing version across the industry [3]. So will we be shutting down a bunch of users from upgrading to 3.0? I am hoping that Java 17 release this September (which is an LTS) will finally change this equilibrium, and people will start upgrading. So my vote would be to go with the switch.

But I wanted to hear what's the situation for other people on this list. Anyone will still hold onto Java 8 for new development?

Andrus


[1] https://github.com/bootique/bootique-jetty/issues/108
[2] https://en.wikipedia.org/wiki/Java_version_history
[3] https://snyk.io/blog/developers-dont-want-to-leave-java-8-as-64-hold-firm-on-their-preferred-release/

Ari Maniatis

unread,
May 21, 2021, 3:04:56 AM5/21/21
to Bootique User Group
Waiting for bootique 3 might impede our move to Jetty 10 for several years. I tend to prefer to upgrade things one at a time where possible.

As bootique has become a sort of transitive dependency management tool, do modules need some sort of annotation to denote compatibility with each other and the JVM platform? Would that solve anything in this case?

Andrus Adamchik

unread,
May 26, 2021, 12:17:38 AM5/26/21
to Bootique User Group
bootique has become a sort of transitive dependency management tool

Yeah, we are kinda like a Linux distro now :) How do you balance the need to keep dependencies working with each other, and yet allow upgrades of Java and upstream frameworks at the user's preferred pace?

 do modules need some sort of annotation to denote compatibility with each other and the JVM platform? Would that solve anything in this case?

Technically we can have modules with different JVM dependencies within a subproject like Jetty. The question becomes how do we communicate it to the users. Could you elaborate on the annotations idea? How would it look to an average user trying to decide which modules to add to their project?

I suspect there's already a problem to figure out picking out of a collection of similar modules (e.g. in https://github.com/bootique/bootique-cayenne ), and we may have to build something similar to https://start.spring.io/ to guide dependency selection process (though I don't think SpringBoot goes as deep there. They simply provide fixed dependencies, allowing you to change to a non-standard one via a POM property, and deal with consequences on your own.

Waiting for bootique 3 might impede our move to Jetty 10 for several years

Actually I think in this particular case we may simply release 3.0.M1 early with the new Jetty and minimal core changes.

Andrus


--
You received this message because you are subscribed to the Google Groups "Bootique User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bootique-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bootique-user/6f87ebc9-4e3b-4ed7-b43d-c47504dcefd8n%40googlegroups.com.

Andrus Adamchik

unread,
Oct 24, 2021, 2:12:54 PM10/24/21
to Bootique User Group
With Java 17 release out, we just did a switch of Bootique 3.0.x to Java 11. Now we'll be able to do Jetty upgrades and wonder deeper into Jakarta EE namespace :)

Of course Bootique 2.x will stay compatible with either 8 or 11.

Andrus
Reply all
Reply to author
Forward
0 new messages