Make JDK 11 as Default and Deprecate JDK 8

[ywei2017]

We have been trying to promote JDK 11, instead of the default JDK 8. But most dev teams don't do anything, so they use JDK 8 as default.

I was wondering of the possibility of moving the default to JDK 11, since time has progressed. Would that be a good idea, or there are many reasons against it?

We really would like to retire JDK 8 all together. What is the time horizon for that?

Thanks
Yansheng

[dmikusa]

It's not something that has been discussed yet, however, I do appreciate feedback from you and other users on the subject. If you are interested in this change, please 👍 this issue.

In the meantime, if you would like to make it the default you can. You would just need to edit this line in the config file then follow the instructions to package the buildpack. The "online" version would be the same as what you get through the Releases page. You can build an "offline" version if your users are building in environments without Internet access, or if you want to speed up builds by not requiring downloads at the cost of having a larger buildpack, you can also use the "offline" variant.

[mayrstefan]

Changing the default raises two questions:

1. When will Bellsoft EOL the different Java versions?
2. What would be the buildpack policy to change the default between LTS versions? Next would be Java 17

Looking at Adoptium we will get

• Java 8 at least until 2026
• Java 11 at least until 2024
• Java 17 no statement yet

So in 2025 we have at least two choices: back to Java 8 because it is still supported or move forward to Java 17. Or Java 23 or whatever will be the next LTS release.

[dmikusa]

When will Bellsoft EOL the different Java versions?

https://bell-sw.com/pages/roadmap/ (far right column).

Java 8 is in a weird spot. It's technically supported longer than both Java 11 and 17. It looks like Adoptium is similar. That is definitely a concern with changing the default. That would necessitate another default change to 17 at some point, whereas if we stick with 8 then no changes for even longer.

What would be the buildpack policy to change the default between LTS versions? Next would be Java 17

I think this is an open question because in the history of the buildpack we haven't had to do that yet. Regardless of the default value, we'll continue supporting Java 8, 11, and 17 through their lifecycle, so even if the default changes to Java 11 you'll still be able to use Java 8.

I didn't look to see if there's something we could use already, but having an env variable that is unique like JBP_CONFIG_DEFAULT_JVM might make sense too. That way folks could set a running environment variable group to apply defaults across their foundations. The JBP could keep 8 as the default-default, but operators could set their own foundation or company-wide default. Does this seem useful/interesting to folks?

[mayrstefan]

If we would have a policy to change the default version one year after LTS GA we would have default version

• 11 immediately (or maybe with the next Java release in January)
• 17 starting September 22
• 21 starting September 24
  an this should already be the 5th release of that LTS version when it becomes the default version. So the first known issues should already be mitigated. Also this is in the middle of the time span between two LTS versions.

If we assume a life span of at least 8 years we could also change defaults in the middle of its life span: after 4 years

• 11 as default starting September 22
• 17 starting September 25
• 21 starting September 27
  This looks somewhat extreme. I think I would be more comfortable with my first proposal.

While I like the idea to configure a default version on a foundation level I'm skeptic if this is currently possible. As a VMware Tanzu user I fear this could be a feature that requires some platform changes that we would not get backported into Tanzu LTS releases. And not having that available in Tanzu LTS releases would miss the target audience - conservative enterprise customers.

[ywei2017]

@mayrstefan I also like the first proposal better. It is a given reality that, regardless the decision, we will not make everybody happy. So we just need to think through, and figure out which way we want to nudge our dev community.

In our situation, dev teams have a strong tendency to stay with old stuff, really old stuff. In the mean time, some teams want/need the features of later versions. We have come to the unplesant conclusion to support multiple versions of the Java buildpacks. That is a necessary evil, since there is no way we can anticipate the whole company to dance on the same beat.

For teams staying on "old versions", I have 2 concerns. Frist , they miss out the better tuned JRE capabilities in continerized workloads (such as GC). More importantly, security fixes. If we can be more aggressive in setting the default JRE version to later one (like 11 now), that will be yet another way to nudge teams to "stay up-to-date". I assume JRE 8 is duely patched, but other libraries may not be. So by adopting later JRE as the default, teams will be better situated to keep newer version of the whole system, and get us better protected.

@dmikusa-pivotal , I didn't know the platform wide staging/running environmental variables until recently. So it could be a last resort. The downside of that approach is "local customization". So far, we have always told dev teams to "read the buildpack documentation". The moment we make these "custom settings", the communication is muddied, and people will say "can you reset it to the default, blah, blah."

As far as "what happens once JRE 11 comes EOSL"? My recommendation is to go to JRE 17, or whichever the later LTS version. This is assuming that there is a new, relatively stable LTS JRE version.

[dmikusa]

Thanks for the continued feedback @mayrstefan and @ywei2017

I didn't know the platform wide staging/running environmental variables until recently. So it could be a last resort. The downside of that approach is "local customization".

Yes, that's a good point. If the operator sets it at this level, a user could technically override it. At the same time, a user can technically override the Java version at their app level regardless of what the buildpack does by using the JBP_CONFIG_* env variables. So even if the default is fixed in the buildpack, it's still overridable by the user.

I think my primary concern with making a default version change is breaking apps. You have a whole swath of apps that just assume the default Java version. When the default changes, those apps are going to automatically change and that may break the app.

[ywei2017]

@dmikusa-pivotal Looking for your advice whether we keep this thread open. I am ok if you think we should close it.

[dmikusa]

Let's keep it open for now. I think there are a couple of actionable items here:

1. I would like to add support for an env variable that ops teams can use to set the default version across their platforms.
2. I would like to add support for changing the default version at packaging time. That way users can repackage with a different default easily.

In addition, we need to figure out a strategy for moving forward. The world is slowly moving on, as you can see from projects like Spring declaring that Spring 6 and Boot 3 will be Java 17+. There's good feedback on the thread already, but if others want to join the discussion, please drop in your comments.

[RealCLanger]

Hi,
I was just pointed to this discussion by @dmikusa-pivotal. Thanks.

I understand that it's a tough decision to change the default in the Java buildpack, given that
a) it potentially breaks customer apps, especially for people which have been agnostic to the Java version so far
b) It has never been done before and
c) Java 8 has a strange EOL date compared to 11 and 17 - the latter two will, as of current vendor communications, go out of support earlier than Java 8.

Nevertheless, the concept of a release train is kind of new to the Java world but now I guess it's time to adopt it. I would compare this a little bit to node.js where the buildpack also updates the default node version from time to time.

As for the timing model, I'm in favor of updating the default some time after availability of an LTS. So, one year sounds like a good choice. It would mean that we should be on JDK 11 already and JDK 17 should be made the default in about September 23.

I also welcome the action items from Dan above, that is, provide an env variable for a default version in a platform installation and support configuring the default version at packaging time, e.g. as prerequisite.

Looking forward for the day when we set a new default 😄

[dmarmugi]

Is it possible/worth considering removing a "default" altogether? If the decision is pushed down to ops teams ("set the default version across their platforms") and app developers (JBP_CONFIG_*), then there's only 1 "breaking change event" from the main. Whereas if the buildpack takes on a release train approach, then every EOL cycle will potentially break a whole swath of apps.

Either way, ops teams and app devs will end up responsible for specifying and updating their runtimes, but by removing a default, the requirement is made explicit.

[mayrstefan]

@dmarmugi this would break the popular cloud foundry haiku "here is my source code. run it on the cloud for me. i do not care how"

[dmarmugi]

@dmarmugi this would break the popular cloud foundry haiku "here is my source code. run it on the cloud for me. i do not care how"

@mayrstefan that's fair enough, but #951 shows that this isn't unprecedented. ("this" being a one-time, breaking change that pivots to a more sustainable design)

[ywei2017]

Wow #902 is huge, I hope the message is widely dispersed to the community to prepare for it. It will be definitely breaking stuff.

Does that break the 12factor/cloud-native promise? Only if you take that as a promise. I have learned to use it as a guide to minimize impacts. I also understand any breaks are costly to the large enterprise. So we will be communicating aggressively so teams have 6-9 months to be ready.

We also started to support multiple versions of the buildpack in a foundation last year. That seems to be an unavoidable coping mechanism.

With all that being said, I still favor having a default version, so it works for the lazy people out of the box.

[dmikusa]

I see some recent activity, so just reiterating on my comment here. The current plan is to keep Java 8 as the buildpack default but to expose other ways for others to control the default.

Right now you have (lowest to highest):

1. Java Buildpack Default (Java 8)
2. User specified Java version

The plan, which we'll hopefully get out in the next release, is this (lowest to highest):

1. Java Buildpack Default (Java 8)
2. Java Buildpack Package Default (user can set this when packaging the buildpack)
3. Environment Default (operator can set this with staging env variable group, doesn't conflict with 4)
4. User specified Java version

Where higher takes precedent over lower.

The idea is to essentially de-emphasize the "buildpack default", as we are pretty confident that CF Operators know more about their users' and companies' needs and can better select the default values. By doing this, we also feel that it takes some of the pressure off the project and when we are ready to change the buildpack default it'll be less problematic, essentially because users that need to enforce specific versions can do that on their own.

[dmikusa]

There is an implementation of -> #886 (comment) in PR #957. If you are interested in this, please take a look and add comments to the PR. We'll likely merge the PR in about a week unless there are objections/active discussions.

[dmikusa]

PR #957 merged.