docker-maven-plugin
docker-maven-plugin copied to clipboard
fabric8io
Move to Java 8 as minimal Java version
Description
I want to move to Java 8 to leverage lambdas and Optionals for the internal configuration handling. Up to now the minimal version is Java 7.
Are there any objections to move on to Java 8 (for version 0.30 then) ?
I see none. Java 7 reaches end of life. I think that, as d-m-p is only run on dev and CI/CD, JVM should be more updated than production servers.
We're now at Java 8 EOL. Java 17 is the current LTS. I recommend moving to Java 11.
We're now at Java 8 EOL. Java 17 is the current LTS. I recommend moving to Java 11.
True, but there are still surprisingly many people using Java 8 (https://www.infoworld.com/article/3652408/java-8-still-dominates-but-java-17-wave-is-coming-survey.html). As long as we don't have a hard reason to upgrade, I'm not sure if we should do as long as we also work with 11 or 17 and don't require any new features.
dmp is mostly in maintenance mode these days, so as long as we don't have any issues with Java 8, I don't see a reason to close that door for people using dmp in older environments which they can't easily update.
@chonton do you have any particular use case why you want to kill Java 8 support ?
Not really, certain additional Jre methods allow removal of maven commons and guava dependencies. If this plugin truly is in maintenance phase, then no urgency to upgrade.
Chas
On Jul 29, 2022, at 3:05 AM, Roland Huß @.***> wrote:
We're now at Java 8 EOL. Java 17 is the current LTS. I recommend moving to Java 11.
True, but there are still surprisingly many people using Java 8 (https://www.infoworld.com/article/3652408/java-8-still-dominates-but-java-17-wave-is-coming-survey.html). As long as we don't have a hard reason to upgrade, I'm not sure if we should do as long as we also work with 11 or 17 and don't require any new features.
dmp is mostly in maintenance mode these days, so as long as we don't have any issues with Java 8, I don't see a reason to close that door for people using dmp in older environments which they can't easily update.
@chonton do you have any particular use case why you want to kill Java 8 support ?
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.
Regarding the java 8 vs java 11 usage; How many of the java 8 developers are using containers? I suspect very few. Java 9 introduced experimental flags for managing jvm heap using the cgroup info. In Java 10 these flags became default behavior. See java-inside-docker for details. Do you know of a source of statistics that has the cross product of jvm version with container usage?
Java 8 already has container support since u191 (https://blog.softwaremill.com/docker-support-in-new-java-8-finally-fd595df0ca54). For even older versions, there a startup scripts like https://github.com/fabric8io-images/run-java-sh that help set the proper memory boundaries.
I agree (and also hope) that Java 8 usage is going down, but from my experience in general with the 'stickiness' of older Java versions, especially in an enterprise environment, is that even when a version is EOL, still a lot of people still using (i had the same experience with https://github.com/rhuss/jolokia and Java 6)
According to https://newrelic.com/resources/report/2022-state-of-java-ecosystem#toc-java-11-is-the-new-standard, in 2022 still 46% of all production workloads are running on Java 8, so it's not something we can ignore
Note, while the arguments above are about the Java 8 usage in production workload, here we are discussing about the build tooling (and you can of course, create Java 8 container image with dmp running under Java 11). But I would argue, that when you run your applications with Java 8 that your toolchain is also very likely based on Java 8 and not on something newer. . So with these numbers in mind, I'm afraid it would still make sense to support Java 8 in dmp.
What do you think about collecting usage metrics? Four dimensions seem important: Maven version, Java version, Docker version, and Plugin version.
That would be interesting but requires quite some effort: A service that needs to be highly available for receiving the data. The user to opt-in for sending the data (i would not do it automatically, as many developers are operating in a restricted environment that would not allow such connections, and of course, we should ask the user alone for privacy issues).
Considering the very limited resources that we have even to maintain this plugin, I would not put any high priority on telemetry. Maybe just supporting Java 8 a little bit longer is easier? :)
We (jkube/kubernetes-maven-plugin folks) had discussed having telemetry in the plugin but we had to discard this idea https://github.com/eclipse/jkube/issues/1182 . Most companies are quite protective of their build systems.
