My opinion remains that if we believe Java 11 support is solid enough to be the default, then we may as well keep things simple and drop Java 8 support: start building core and important plugins with `java.level=11`, and take advantage of its features. Building and testing primarily against 8 while pushing users to run 11, and forcing developers to consider both platforms in every situation, seems like the worst decision.
--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr2hjuPWgK7XqzwezcT8eP1i1_ZZd_iMNreg%3D7K7FTzH8Q%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAH-3BifVe04fx-7vx6Dp-jkLmTvepCDGHXqRDLEWdHyNN8TG%3Dw%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/74c9f96d-1acc-4315-9fd5-e59bb6fdeff8n%40googlegroups.com.
I am in favor of making JDK11 the default in all our distributions, including controller and agent Docker images.At the same time I am afraid that removal of Java 1.8 support is premature. The vast majority of Jenkins users still uses this version, and the migration to Java 11 won't be seamless in al l cases. For example, Maven Plugin will effectively switch project builds to Java 11 once the agent images are updated. It will cause unexpected issues in user builds here and there. Nothing should be critical, but we should not force users to migrate immediately.IMHO there should be a grace period between Java 8 support deprecation and the actual removal. Maybe 6 months or so.
--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAMo7PtLW05CwT6JyDHHpq52V%2BZwcRy3hQxPW7O9U-D%3DR1adL7Q%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAH-3BicOSJ%2B%3DMhXxO2HRz4QL7O8tm5P56MJhJPsU13z3tTe0og%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/440cfea5-a0d3-4a95-9cd3-1dcaf9be57efn%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAG%3D_Dut95AqgjACv6chnnw7UeWRqm2niqAoe%3DVePrU_QOq4oUw%40mail.gmail.com.
You received this message because you are subscribed to a topic in the Google Groups "Jenkins Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkinsci-dev/VfRq09Yfloo/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAH-3Bicv94K9tFdRwa6hwBCzF4P_esiQ%2BGvjQADtjU_O3ApMog%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAPfivLDMLqksecXjU8PWnyPirJdY-kXvc6aQ8GGCjnriLj_yDQ%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAH-3Bicc-wdqpD4Yw4H2aLHcX9kJiq0-%2Btw3Ly%2B6DPGheVeQZA%40mail.gmail.com.
encourage existing users to migrate
--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr0w-YsTD3odTAJouMGG2QZLRpq85Q6ynp8pzFEk0vJgzg%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/b61e8db2-0c93-4e7f-9147-6ce662c1acfcn%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAPiUgVdB-s4DyRbyBK_BoGN8TK4YTibmJLY5Lfn6Z6Xzbw2UwA%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/a33b6e0b-59eb-4c83-ba13-b3b66c639354n%40googlegroups.com.
I understand that, but when deploying Jenkins into production environments in the community (HPE NonStop), using the Oracle JRE is a requirement not an option. As long as the minimum support level is still 1.8, there is no problem, but I cannot deploy Adoptium anything in production. The Docker image, built with Adoptium, may be fine for the Controller, but when remoting.jar is launched, it must use the Oracle builds. Perhaps I have not clarified my question.
Sent from Mail for Windows 10
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAPiUgVeNVFFyJgyco2ZvE6gMMmk6PvEi6vtKmWv5M8UmKGjRNA%40mail.gmail.com.
when deploying Jenkins into production environments […] using the Oracle JRE is a requirement not an option
That's assuming that Docker runs on NonStop, which it doesn't. The key issue is remoting.jar and whether that can be maintained at 1.8 compatibility. Most groups are using a Controller/Agent architecture using Docker for the Controller and running the platform JVM for remoting.jar. There are a few using the jenkins.war, so as long as that is also 1.8 compatible, building using 11 is fine.
On Wednesday, August 4, 2021 at 2:55:02 p.m. UTC-4 Jesse Glick wrote:On Wed, Aug 4, 2021 at 2:13 PM Randall Becker <the.n...@gmail.com> wrote:when deploying Jenkins into production environments […] using the Oracle JRE is a requirement not an option
If your environment has specialized needs, including legal ones, you can of course build your own Docker images accordingly starting with a WAR file. The question is about the default images supported by the Jenkins project and deemed suitable for typical purposes.
--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/72b102da-b169-4363-9f74-ac34e07ca102n%40googlegroups.com.
Similar to Randall (the.n...), I have customers that use NonStop, but they also use various distros of Enterprise Linux. Their corporate strategy for software development is to remain on Java 8 for the foreseeable future, primarily due to the JDK 11 licensing mentioned above. They have a corporate support contract with Oracle to continue to get Java 8 updates, so support is not an issue for them. Shipping a version of Jenkins that won't do 'remoting' on those target platforms should require much longer than 5 months of advance notice, as those customers are on much longer strategic cycles.
Even though the newer platforms and releases for NonStop include both Java 8 and Java 11, customers on NonStop and Linux that are Enterprise-focused (and there are MANY) haven't installed Java 11 and have no plan to do so this year or probably even next. What was the penetration number above for Java 11, only 4%? Expecting a large percentage of your customer base to make this move is short-sighted.
If Jenkins is to retain its preferred position in Enterprise environments, this decision should be very carefully reconsidered. Most of your customers don't spend time reviewing this group. And many Enterprise decisionmakers don't participate in Twitter, which leaves the results of surveys in that platform somewhat questionable. This is not just a question of what is easier for the developers of Jenkins, it's also a matter of where Jenkins (and its remotes) run.
This is just my .02$US,
On Aug 11, 2021, at 09:18, jn...@cloudbees.com <jn...@cloudbees.com> wrote:
Hi Bill (et al) for those that are running nonstop or the like and have an update / test cycle in the order of 6 months :
--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/46cbc074-c917-4dd3-b94e-953c1f08441en%40googlegroups.com.
Matt,
Oracle releases Java to the larger OS platforms (Windows, Linux, MacOS, IOS, Android) directly. However for other platforms (speaking specifically for NonStop), the vendor has to do the deep port themselves and go through their QA process, etc. They do this with the support of Oracle (under paid license and support), but it’s never going to be fast. Java 11 has only been released on NonStop for a few years now (not 10). And there are actually 2 different underlying instruction sets. The currently-sold versions NonStop (‘X’ and ‘V’) run on Xeon processors or in VMs, and Java 11 exists for those. However, ‘E’ is an Itanium-based platform that is no longer sold but is still supported for Enterprise customers. It still has 3 years of support remaining.
I wouldn’t expect Java 17 to be available for NonStop for another 5-10 years.
Building Java apps with Java 11 that run on an Java 8 RTE is not difficult at all. Where you may run into issues is with 3rd party packages. But in the Open Source world it’s at least theoretical that you have the source and can rebuild the class files with the ability to run on Java 8, if the functionality of the package you need is critical.
Many of the Enterprise customers using NonStop, while not averse to change (otherwise they wouldn’t be in the devops realm), but they are very skeptical about changing things. Their business critical apps run for years without an outage. (They use replication and managed failover to avoid planned outages, for example). How to reach them and ask? Those of us that work with the platform do so with various publications and events.
But the developers that use tools like git and Jenkins actually WILL be the ones that are impacted if Jenkins won’t run (correctly) because the JRE is at Java 8.
I’ve heard of other platforms where the story is similar but am not an expert on them.
From: jenkin...@googlegroups.com <jenkin...@googlegroups.com> On Behalf Of Matt Sicker
Sent: Wednesday, August 11, 2021 10:03 AM
To: jenkin...@googlegroups.com
Subject: Re: Using JDK 11 instead of JDK 8 in default docker images
Plus Java 17 comes out really soon. I can imagine that will inspire more projects to set Java 11 as a baseline. Definitely start planning since most people will probably be affected by some other dependencies well before they hit Jenkins.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/01D0068C-167C-406A-89FE-850B1474E584%40gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/01D0068C-167C-406A-89FE-850B1474E584%40gmail.com.
The question to ask is, was that minimum version due to the ‘default’ action of javac (that is, -target 11), or because they required something that doesn’t exist in Java 8?
It won’t solve all problems but ‘projects’ that are intended to be dependencies for other projects would be better if the above question were asked in the design phase. That’s just my $.02US, for what it’s worth.
Bill
From: jenkin...@googlegroups.com <jenkin...@googlegroups.com> On Behalf Of Tim Jacomb
Sent: Wednesday, August 11, 2021 2:46 PM
To: jenkin...@googlegroups.com
Subject: Re: Using JDK 11 instead of JDK 8 in default docker images
Jetty, Hikari, and opensaml are all projects I’ve come across recently where new development has a minimum Java 11 version… there’s probably many others
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAH-3Bidps_mDO3pFUv2xP_FXAyANCOSwhURAT8MxYhkqZsVsbQ%40mail.gmail.com.