Move to Java 11 or Java 17 for next major iteration of gitlab4j-api

[jabby]

As maintainer, I don't want to support Java 8 anymore.

I want to upgrade to a newer LTS version of Java. I'm not sure if I will jump to latest LTS (Java 17) or if I migrate to Java 11 first.

If you use gitlab4j-api, feel free to comment this issue.

[ludakhris]

So would this mean that you aren’t guaranteeing that it’ll work in Java 8? Or that it won’t run on Java 8 at all? Maybe as a first step go to Java 11, that’s what other libraries are doing.

[jabby]

Some updates about updating to next major Java LTS. I tried to summarized what I learned about Java end of life and adoption of Java 17 in the industry.

Spring 6 baseline will be Java 17+ and Jakarta EE 9. Spring Boot 3 based applications will require a minimum of JDK 17 at runtime. Quarkus already support Java 17 in JVM mode. Not in native mode. See https://github.com/quarkusio/quarkus/issues/21481 and https://github.com/quarkusio/quarkus/issues/20891 for more informations.

According to JRebel Java Developer Productivity report 2022, 62% of those with knowledge of their upgrade plans reported their intention to move to JDK 17 within the next 12 months..

According to https://endoflife.date/java

• Java 11 active support will ends at 2023-09-30
• Java 11 security support will ends at 2026-09-30
• Java 17 active support will ends at 2026-09-30
• Java 17 active support will ends at 2031-09-30

As I don't plan to release a new major release of gitlab4j-api before 2023, I think the next major release will require a minimum of JDK 17.

In the meantime, I will continue to support Java 8 and release new version of gitlab4j-api 5.x

If you have any concern about the future of gitlab4j-api and especially about a JDK 17 requirement, feel free to add a comment here.

References:

• https://spring.io/blog/2022/03/28/an-update-on-java-17-adoption
• https://quarkus.io/blog/quarkus-2-6-0-final-released/#java-17-in-generated-projects
• https://github.com/quarkusio/quarkus/issues/21481
• https://spring.io/blog/2021/09/02/a-java-17-and-jakarta-ee-9-baseline-for-spring-framework-6
• https://www.jrebel.com/resources/java-developer-productivity-report-2022

[akphi]

@jabby Thanks for your great work in maintaining the library! Could you do us a favor to mention these kinds of changes briefly in the changelog when we do a release? Thank you so much!!!

[berezovskyi]

Thank you for your work! It would be great if you could go for JDK 11 first, but obviously up to you to decide.

[jorsol]

For a library it make sense to go for JDK 11 first, frameworks like Quarkus supports both Java 11 and Java 17 (using JDK 11 as baseline) and even Spring 6 (with JDK 17 as baseline) will be available on Q4 2022, and even then don't expect that the migration to Spring 6 will be massive for at least one year or two.

IMHO, if you want to aggressively set the baseline of newer JDK versions my proposal is to follow the latest LTS minus 1 (counting LTS only).

To illustrate this:

Version (LTS)	Date	Baseline
Java 11	Sep 2018	JDK 8
Java 17	Sep 2021	JDK 11
Java 21	Sep 2023	JDK 17

So what this means is that current baseline could be JDK 11, and when JDK 21 is released (on Sep 2023) then migrate to JDK 17 as baseline, the baseline doesn't mean that a version will not work with newer JDKs (you could potentially use a Java 7 lib in a Java 18 app without issues), it just mean that it will not work on older JDKs.

Anyway, this is just my personal opinion and you could choose any baseline you want.

[krusche]

I would appreciate support for Spring Boot 3. We wanto to support it in our application soon and temporarily use a custom built jar from a fork: https://github.com/b-fein/gitlab4j-api in which we changed the namespace from javax to jakarta. However, this has several disadvantages, in particular that we now need to specify the gitlab4j-api dependencies in our application's build.gradle file.

[MiguelAngelLV]

Support for Jakarta is crucial. Spring Boot 3 need it.

[dousp]

This means JDK17 is not supported yet？？

[cjchand]

Any updates/ETA on Spring Boot 3.x support, @jabby?

[jmini]

This means JDK17 is not supported yet？？

@dousp: This lib works perfectly with Java 17.

I am using it with Java 17 in standalone scripts like print-groups-and-projects-tree executed with JBang.

Or in Quarkus based app like ucascade also using Java 17.

[jmini]

Thank you for your work! It would be great if you could go for JDK 11 first, but obviously up to you to decide.

I tend to agree with @berezovskyi here.

One usage I know of this library is in the https://github.com/jenkinsci/gitlab-branch-source-plugin project (cc: @jetersen, @mifitous)

Jenkins has set its minimal Java version policy to Java 11, so doing Java 11 for a while might be less disruptive for them.

Currently the ideas for the next versions do not really require Java 17. The only thing I could think of is to use records, but no decisions has been made so far.

[dousp]

@jmini

Which version do you use? Have you confirmed that the API you use involves those changed packages? Those packages are no longer in jdk17, or the namespace has been changed. Are you sure you can call those unreplaced imports and deleted classes?

This means JDK17 is not supported yet？？

@dousp: This lib works perfectly with Java 17.

I am using it with Java 17 in standalone scripts like print-groups-and-projects-tree executed with JBang.

Or in Quarkus based app like ucascade also using Java 17.

[MiguelAngelLV]

For me, the problem is the WebHookManager. It need a HttpServletRequest, but use javax instead of jakarta.

[dousp]

My project temporarily uses this repo: derkoe/gitlab4j-api

see from here : pr 841

[berezovskyi]

It need a HttpServletRequest, but use javax instead of jakarta.

But that's not related to the JDK version?

[Polyackov]

@jabby are you planning to migrate the library to Java 17? If so, could you give an approximate time frame?

[gedeffe]

Hello,

As we are moving our projects to new version of Spring Boot (3.x), it implies also a move to version 17 of jdk. To be compatible with more use cases, I tried to keep compatibility with version 11.

Feel free to comment related PR (https://github.com/gitlab4j/gitlab4j-api/pull/943) which has been successfully tested locally (with both jdk 11 and 17) with our use of gitlab api ^^

Have a nice day Gedeffe

[jetersen]

I would love to see at least one version target JDK 11 so if we need to, we can backport and patch it.

But yes JDK 17 should not be an issue for Jenkins plugins to adapt and will give users a reason to adopt Java 17.

FYI it was only recent that Jenkins switched to requiring Java 11 https://www.jenkins.io/blog/2022/12/14/require-java-11/

If you have a look at march numbers: Jenkins Version Stats 2023 March Jenkins have had an increasing number of people getting to update their older servers.

The actual usage of https://github.com/jenkinsci/gitlab-branch-source-plugin is coming from the wrapped plugin dependency of this library which is located here: https://plugins.jenkins.io/gitlab-api/

Jenkins has had a tendency to wrap dependency into plugins to avoid class loading issues.

You can see the GitLab API plugin adoption here: https://stats.jenkins.io/pluginversions/gitlab-api.html

[jmini]

So as discussed in https://github.com/gitlab4j/gitlab4j-api/issues/926 we are now working on a 6.x.x version of the client on the 6.x branch.

On this branch we have decided to require Java 11 as minimal version (using Java 17 will be possible as well) and we will use Jakarta EE components that are using the jakarta.* packages instead of javax.* (making this version compatible with Spring Boot 3 application).

As I wrote earlier, you can use Java 17 already today with the current version (like 5.1.0) and you will be able to do it with the 6.x.x version as well.

[jmini]

Please check if the release 6.0.0-rc.1 works for you and give feedback. This version is using:

• minimal version: Java 11
• Jakarta EE components with the jakarta.* packages instead of javax.*

So that we know if we are on the good path to prepare the 6.0.0 release.

[gedeffe]

With 6.0.0-rc.1, looks good to me with our use cases. Thank you guys !

[jetersen]

I do not actively use GitLab so if any kind soul wants to contribute to plugin consumers in Jenkins that would be appreciated. But I would assume the changes would be fine. This is the gitlab-api plugin dependants (found via http://stats.jenkins.io/jenkins-stats/jenkinsgraph.html by searching gitlab-api and then click on it)

[Telamon-m]

@jmini I tested release 6.0.0-rc.1 and it works for me. Thank you.

[weinbergalfredo]

Hi. I'm trying to set the merge_commit_template using ProjectApi. I've noticed that it was introduced in 6.X I'm using the 6.0.0-rc.4 maven dependency downloaded from maven central and I don't see those changes in the source code.

Is 6.0.0-rc.4 uploaded to maven central repo? Thank you very much in advance

Best regards