I mean there's a very real chance that regardless of how long Jenkins
attempts to keep Java 8 compatibility, eventually some dependency it
or a key plugin uses will stop supporting Java 8 and subsequently
publish CVEs that are only fixed in the Java 11 version. I don't
expect that to happen very soon, but it's definitely something to
consider in the longer term. The Java 17 release, being an LTS one,
will encourage some communities to move their base level of Java
support from Java 8 to 11 (which has already been slowly happening
with some projects).

On Wed, Aug 11, 2021 at 11:32 AM Bill Honaker <[email protected]> wrote:
>
> 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: [email protected] <[email protected]> On 
> Behalf Of Matt Sicker
> Sent: Wednesday, August 11, 2021 10:03 AM
> To: [email protected]
> 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.
>
> Matt Sicker
>
>
>
> On Aug 11, 2021, at 09:18, [email protected] <[email protected]> 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 :
>
>
> I would recommend that your customers probably want to start the planning / 
> validation to update to Java11 now even if this LTS version still runs on 
> Java8.  Java11 is going to happen at some point and I am not sure the project 
> will be able to give you all the advance notice you need.
>
>
>
> Jenkins has supported Java11 for a while now, and if there are any specifics 
> from you that cause it not to run we would like to be aware as early as 
> possible (it won;t help you if we find out after the switch has been made and 
> 7 days before a go live)
>
> >  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.
>
> On that note - where should we announce surveys / things like this - if users 
> are not in the user email / discored or the like how can we reach people to 
> inform them and have them participate?
>
> I also work for a company (CloudBees) that has Jenkins at its core for 
> Enterprise customers, so we have the statistics from these installations as 
> well - so this project is not blind of enterprises (and if a customer wants a 
> version of Jenkins that is supported for 9 months rather than the normal 3 we 
> can probably help you out, and there may be others)
>
>
>
> Regards
>
>
>
> /James
>
> On Wednesday, August 4, 2021 at 11:00:06 PM UTC+1 [email protected] wrote:
>
> Mark,
>
>
>
> Randall had pointed me to this thread.  I admit to only reading the last 
> couple of dozen posts and, based only on that, share my concerns.  I should 
> have spent more time reading the thread, but I was scheduled to do a code 
> walkthrough with my customer and took the 'short' path, for which I apologize.
>
>
>
> Your clarification does seem 100% the right thing to do, and I thank you for 
> sharing it.  That's worth much  more than .02$US!
>
>
>
> And my customers all never need know I ever had this concern, you had it  
> covered. :-)
>
>
>
> Bill
>
> On Wednesday, August 4, 2021 at 3:49:40 PM UTC-5 Mark Waite wrote:
>
> Thanks for sharing your insights.  Great to have participation in the thread. 
>  Comments are inline
>
>
>
> On Wednesday, August 4, 2021 at 2:39:05 PM UTC-6 bhon wrote:
>
> 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.
>
>
>
>
>
> I'm not sure where you're getting the idea that we would be shipping a 
> version of Jenkins that won't do 'remoting' on those target platforms.  The 
> proposal does not remove Java 8 support.  The proposal does not prevent users 
> from running agents or controllers or both with Java 8.  The proposal does 
> not change how 'remoting' operates.
>
>
>
>
>
> 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.
>
>
>
>
>
> We're not expecting them to make a move.  We're changing the default in the 
> Jenkins Docker images so that users who choose to use the default Jenkins 
> Docker images will use Java 11 instead of Java 8.  Users that can't use 
> Docker images (arm32, ppc64, s390x, ia64, riscv) can continue to use either 
> Java 8 or Java 11 on their platform.  After the change, users that are 
> running Docker images can change the name of the image they are using and 
> that will allow them to continue running with Java 8.  Today, if they run 
> with `docker run --rm -i -t jenkins/jenkins:lts` and they have a hard 
> requirement for Java 8, they will need to run with `docker run --rm -i -t 
> jenkins/jenkins:lts-jdk8`.
>
>
>
> 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.
>
>
>
>
>
> We're not changing where Jenkins can run with this proposal.
>
>
>
> This is just my .02$US,
>
>
>
>
>
> Thanks for sharing!
>
> Mark Waite
>
>
>
> --
> 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 [email protected].
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-dev/46cbc074-c917-4dd3-b94e-953c1f08441en%40googlegroups.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 [email protected].
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-dev/01D0068C-167C-406A-89FE-850B1474E584%40gmail.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 [email protected].
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-dev/017a01d78ece%2467663e40%243632bac0%24%40xid.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 [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CACmp6kq-49sC3ro0GQfE9hSu0iprVzzxEtdUXb41o1kN2chRdw%40mail.gmail.com.

Reply via email to