Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Set Java baseline to 11 #6081

Closed
8 tasks done
manusa opened this issue Jun 26, 2024 · 7 comments · Fixed by #6437
Closed
8 tasks done

Set Java baseline to 11 #6081

manusa opened this issue Jun 26, 2024 · 7 comments · Fixed by #6437
Assignees
@manusa
Labels
status/never-stale
Milestone
7.0.0

Comments

@manusa
Copy link
Member

manusa commented Jun 26, 2024 •
edited
Loading

Description

Part of #5778

Starting from version 7.0.0, the Fabric8 Kubernetes Client will require at minimum Java 11 to work.

Tasks
@manusa manusa added this to the 7.0.0 milestone Jun 26, 2024
@manusa manusa mentioned this issue Jun 26, 2024
Open
@andreaTP
Copy link
Member

Now that we are at it:
https://www.oracle.com/java/technologies/java-se-support-roadmap.html

Java 11 is almost out of the support phase, would it make sense to bump directly to Java 17?

@manusa manusa moved this to Planned in Eclipse JKube Jun 26, 2024
@manusa
Copy link
Member Author

manusa commented Jun 26, 2024

Now that we are at it: https://www.oracle.com/java/technologies/java-se-support-roadmap.html

Java 11 is almost out of the support phase, would it make sense to bump directly to Java 17?

Refer to #5778 (comment)

Most companies are going to provide commercial support for Java 11 well passed that date (just check the paid support column in your link).

The only reason I (personally) see to bump now is because it's becoming extremely difficult to maintain the project with such a low baseline, many of our dependencies have moved to Java 11.
Other than that, there are no clear advantages of upgrading the baseline past 11 and on the other hand there many disadvantages to do so.

@jorsol
Copy link
Contributor

jorsol commented Jun 26, 2024

Now that we are at it: https://www.oracle.com/java/technologies/java-se-support-roadmap.html
Java 11 is almost out of the support phase, would it make sense to bump directly to Java 17?

Refer to #5778 (comment)

Most companies are going to provide commercial support for Java 11 well passed that date (just check the paid support column in your link).

This project should not be tied to companies that provide commercial support for Java 11... see my comment for a longer explanation: #5778 (comment)

But most importantly, if you check current ecosystem reports like the New Relic one, new Java versions are being adopted faster, is possible that Java 17 is more used than Java 11 right now... Spring 6 (Boot 3) and Quarkus 3.7 require Java 17 as the baseline, in other words, the ecosystem is starting to move faster.

The only reason I (personally) see to bump now is because it's becoming extremely difficult to maintain the project with such a low baseline, many of our dependencies have moved to Java 11. Other than that, there are no clear advantages of upgrading the baseline past 11 and on the other hand there many disadvantages to do so.

This is just my personal opinion, but I think there are more advantages of upgrading past 11 than disadvantages. There will be always trade-offs, so if you feel comfortable with Java 11 that's a good baseline too.

@manusa
Copy link
Member Author

manusa commented Jun 26, 2024

there are more advantages of upgrading past 11

Such as? (I'm referring specifically for this code-base and those advantages that would be impactful from a user's perspective)

@jorsol
Copy link
Contributor

jorsol commented Jun 26, 2024

there are more advantages of upgrading past 11

Such as? (I'm referring specifically for this code-base and those advantages that would be impactful from a user's perspective)

Impactful from a user's perspective probably no, but advantages for the code-base maintainability could be, with Java 17 you have switch expression, text blocks, records, sealed classes, etc... all that would require some refactoring and the effort could not be worth it, but at least for new code or parts that can be refactored, there is an opportunity for that.

In any case, I don't mind keeping Java 11 as the baseline, I'm not a maintainer or even a casual contributor, and this discussion (that probably already happened) should be done with the team that maintains the project, so again, is just my personal preference, don't take it as advice or recommendation 😉 .

@manusa
Copy link
Member Author

manusa commented Jun 26, 2024

:) no worries

Impactful from a user's perspective probably no

I was just making sure that there wasn't anything else that could actually be interesting for users and that we missed out when weighing the pros/cons.

Personally, I need to keep multiple pet projects just to be able to test Java's new features 😅 Otherwise it's groundhog day in 2014 😭

@rohanKanojia rohanKanojia mentioned this issue Aug 26, 2024
Closed
@stale Stale
Copy link

stale bot commented Sep 28, 2024

This issue has been automatically marked as stale because it has not had any activity since 90 days. It will be closed if no further activity occurs within 7 days. Thank you for your contributions!

@stale stale bot added the status/stale label Sep 28, 2024
@manusa manusa self-assigned this Oct 10, 2024
@manusa manusa mentioned this issue Oct 10, 2024
Merged
11 tasks
@github-project-automation github-project-automation bot moved this from Review to Done in Eclipse JKube Oct 11, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@manusa manusa

Labels
status/never-stale
Projects
None yet
Milestone
7.0.0
Development

Successfully merging a pull request may close this issue.

feat: move Java baseline from 8 (1.8) to 11 manusa/kubernetes-client
3 participants
@manusa @jorsol @andreaTP