Community
Participate
Working Groups
I think it's time to raise the minimum Java version for JGit to Java SE 11. Java 11 is available since Sep 2018 and the next LTS release 17 is planned for Sep 2021. WDYT ?
RedHat at least supports OpenJDK Java 8 until May 2026.[1] Is there anything specific from Java 11 that we want to use and that would require bumping the minimum version? Clients can use already a Java 11 (or even higher) JVM and can thus benefit from fixes and improvements made since Java 8. OTOH there might be users who cannot move to Java 11 (yet). Do z/OS or HPE NonStop have Java 11? Bumping JGit to Java 11 would also require bumping EGit to Java 11. Which means we should also consider bumping the EGit baseline to the first Eclipse version that required Java 11 (I think that was 2020-09). EGit-Github might actually be the one project that might see a real benefit from moving to Java 11, see [2] (support for HTTP PATCH requests). But also in that case we might leave library users who cannot move to Java 11 for whatever reason out in the cold. [1] https://access.redhat.com/articles/1299013 [2] https://git.eclipse.org/r/c/egit/egit-github/+/161168
I'm indifferent here. We've (Advantest) moved from 8 to 11 in R&D, and that was a pain (and still is a pain), not to compare to anything else we had before (may be similar to 3.x -> 4.x move, but now it affects every Java application, not just Eclipse). Most of our customers are still on Java 8, it is impossible to convince people to move, if there is not much you can offer and they have fear to change a single line of code, even if the change is trivial. The fun is, Java 8 will be longer supported as Java 11, so even this is not an argument for Java 11. Unfortunately 9+ changes were so disruptive... Some people can't move just because they use 3rd party libraries that have no support anymore and do not run on recent Java. I don't know if our end users are listening to our mailing lists, but we should ask on jgit & cross-project lists about it, just in case someone would have a good use case to stay on Java 8 or to move to 11.
New Gerrit change created: https://git.eclipse.org/r/c/jgit/jgit/+/174128
Java 11 would allow us to use the new http client [1] instead of java.net.HttpURLConnection [2] which is currently used to implement org.eclipse.jgit.transport.http.HttpConnection. [1] https://openjdk.java.net/groups/net/httpclient/intro.html [2] https://docs.oracle.com/javase/8/docs/api/java/net/HttpURLConnection.html
(In reply to Matthias Sohn from comment #4) > Java 11 would allow us to use the new http client [1] instead of > java.net.HttpURLConnection [2] which is currently used to implement > org.eclipse.jgit.transport.http.HttpConnection. What would be the benefit for JGit? Is the new API faster/easier to use/whatever else?
Supporting modular and non-modular Java in the same codebase is such a pain that I fully understand every team that decides they don't have the manpower or the will to keep doing it.
I would prefer that the minimum Java version for JGit remain at Java 8 so that the Jenkins git client plugin continues to receive the benefit of new JGit releases. If the minimum Java version is increased to Java 11, it will lock the Jenkins git client plugin to the last JGit version that supports Java 8. The Jenkins git client plugin spent several years locked to an older 4.x release until it made the "jump" to track JGit 5.x releases. It has been using JGit 5.x releases for the last 12 months (beginning with JGit 5.6.0, currently delivering JGit 5.10.0 inside the Jenkins git client plugin). The Jenkins git client plugin bundles JGit as an alternative to command line git. A Google Summer of Code 2020 project (Git plugin performance improvement) added a feature that will use JGit automatically for small repositories because we found it to be consistently faster than starting a new process and running command line git in the new process. See https://www.jenkins.io/blog/authors/rishabhbudhouliya/ for the blog posts that describe the git plugin performance improvement project and how it decided to use JGit for small repositories even when the user had selected command line git. We don't have any timeline to require Java 11 as the minimum version for Jenkins users. The Jenkins project uses Java 11 to run ci.jenkins.io and regularly tests with Java 11, but the majority of Jenkins users are still running Java 8. We expect that will continue for several years at least.
Google has been running googlesource.com under Java SE 11 since 2019-09. The main problem we had was tuning the G1 garbage collector. Running under the same memory as CMS caused lots of crashes. G1 requires 10%-15% more container memory than CMS to maintain its data structures. Getting G1 working did make our tasks more stable by eliminating our environments "zombie reaping" that was happening when CMS caused >5s of seconds long full GC pauses where the binaries didn't respond to health checks. tl;dr: To use Java SE 11's default G1GC garbage collector, be prepared to add another ~10% to container memory
Some supported exotic platforms (NonStop J-series, zOS R2.3) do not have an implementation of Java 11 available. This will cut off JGit from use where Java 11 is required. Unless there is a specific reason to move to Java 11, I would request not doing so until those platform versions are officially deprecated (around 2023 at least).
Java 11 was the first java version that included Tls-1.3 support what is a requirement for some projects. Eg. https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-52r2.pdf Or https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Mindeststandards/Mindeststandard_BSI_TLS_Version_2_0.pdf?__blob=publicationFile&v=2 However since tls-1.3 is backported to java8 in 261 that is no longer a blocking point. https://www.oracle.com/java/technologies/javase/8u261-relnotes.html Looking at the difficulty maintaining compatibility regarding different java versions within a multimodule project I strongly vote for alignment to eclipse minimum requirement Java 11 or - if really needed - introduce another branch for java 8 support.
(In reply to Carsten Hammer from comment #10) > Looking at the difficulty maintaining compatibility regarding different java > versions within a multimodule project I strongly vote for alignment to > eclipse minimum requirement Java 11 ... Currently this is not a problem for JGit (or EGit). The Eclipse bundles build just fine with Java 8, and can be used in any Eclipse from Eclipse Neon on. Gerrit builds JGit from source and has no problems doing so in a Java 11 build.
(In reply to Carsten Hammer from comment #10) > ... or - if really needed - introduce another branch for java 8 support. JGit already has a "next" branch, which is supposed to be working towards a JGit 6.0. Maybe bumping the BREE is something for that branch, especially in view of Terry's comment 8: if changing the JGit BREE might require users to re-evaluate memory requirements and GC tuning for their applications it should perhaps not come in a minor version bump. On a slightly tangential note: while we have that "next" branch for quite a while now, I have not seen significant development happening there. Nor have I seen any clear roadmap for a JGit 6.0 that would summarize what was to be done for 6.0. I can imagine a few things (some interface clean-ups, maybe re-design the exception hierarchy, drop JSch (not possible without API breaks), now perhaps a BREE bump), but what else? @Matthias: there is a highly outdated wiki page at [1]. Shall we re-activate that page and use it to collect ideas and formulate goals for a JGit 6.0? [1] https://wiki.eclipse.org/EGit/Planning
My fleet of projects are stuck on Java 8, and I am starting to feel pain as upstream projects (eclipse and others) shift to Java 11. From my standpoint, the pain is already here, so whether JGit bumps or not doesn't make things any worse. As a developer of end-user applications where we can use any JVM version we want, we didn't see much advantage to Java 11. But with all the accumulated sugar in Java 15 (records, sealed classes, pattern matching, text blocks, etc), we now can see clear immediate benefit in doing the upgrade. And like everyone else, we're excited about Valhalla and Loom, but we can't even begin experimenting with them until we make the Java 11 bump. I'm excited to see what performance JGit can achieve when Valhalla becomes available (ObjectId!!!).
(In reply to Thomas Wolf from comment #12) > (In reply to Carsten Hammer from comment #10) > > ... or - if really needed - introduce another branch for java 8 support. > > JGit already has a "next" branch, which is supposed to be working towards a > JGit 6.0. Maybe bumping the BREE is something for that branch, especially in > view of Terry's comment 8: if changing the JGit BREE might require users to > re-evaluate memory requirements and GC tuning for their applications it > should perhaps not come in a minor version bump. good idea > On a slightly tangential note: while we have that "next" branch for quite a > while now, I have not seen significant development happening there. Nor have > I seen any clear roadmap for a JGit 6.0 that would summarize what was to be > done for 6.0. I can imagine a few things (some interface clean-ups, maybe > re-design the exception hierarchy, drop JSch (not possible without API > breaks), now perhaps a BREE bump), but what else? > > @Matthias: there is a highly outdated wiki page at [1]. Shall we re-activate > that page and use it to collect ideas and formulate goals for a JGit 6.0? > > [1] https://wiki.eclipse.org/EGit/Planning yeah, I agree we should write down such breaking changes and start implementing them on the next branch. Then we can decide later when we want to release 6.0 as soon as there is enough content to justify shipping a new major release. I hope this adds less maintenance burden compared to what we did in the past where we had a mix of Java 5 and 6 or later Java 6 and 7 with optional features using Java 7 while the bulk of jgit still required Java 6. Not sure if EGit/Planning is the right wiki page for JGit plans, maybe we should add a similar page for jgit at https://wiki.eclipse.org/JGit/Planning ?
Bumping minimum java version to 11 would allow us to upgrade to jetty 10 or 11 which both require Java 11 [1][2]. Gerrit started working on upgrading to jetty 10 [3]. According to the jetty release notes jetty 10 uses javax.servlet 4.0.1 [1] jetty 11 uses jakarta.servlet 5.0.0 [2] Additional constraints for jgit are: Both of these major jetty releases require Java 11. As long as the minimum Java version supported by jgit is Java 8 we cannot upgrade to jetty 10 in jgit. It may be possible to update to javax.servlet 4.0.1 in jgit while staying on jetty 9.4.x, didn't try this yet. Changing from javax.servlet to jakarta.servlet namespace looks like a breaking change for the bundles - org.eclipse.jgit.http.server - org.eclipse.jgit.junit.http - org.eclipse.jgit.lfs.server I think this means we should - try to update to javax.servlet 4.0.1 in 5.11 - postpone the update to jakarta.servlet to 6.0 which can be prepared on jgit's "next" branch. [1] https://github.com/eclipse/jetty.project/releases/tag/jetty-10.0.0 [2] https://github.com/eclipse/jetty.project/releases/tag/jetty-11.0.0 [3] https://gerrit-review.googlesource.com/c/gerrit/+/238383
(In reply to Matthias Sohn from comment #14) > > [1] https://wiki.eclipse.org/EGit/Planning > Not sure if EGit/Planning is the right wiki page for JGit plans, maybe we > should > add a similar page for jgit at https://wiki.eclipse.org/JGit/Planning ? :-) Of course. Completely missed that the existing page is for EGit.
(In reply to Matthias Sohn from comment #14) > add a similar page for jgit at https://wiki.eclipse.org/JGit/Planning ? OK; I've put some initial content at https://wiki.eclipse.org/JGit/Planning . Additional input most welcome! Free free to add/improve/delete or drop the whole page again.
I just realized: if we require Java 11 in JGit, it will no longer be possible to use it via EGit on older Eclipse installations that run on a JDK 1.8. Eclipse requires Java 11 only as of 2020-09, but EGit can be used in any Eclipse back to Neon.3. True, users of older Eclipses could install Java 11 and run their old Eclipse on that. Doing so might force them to edit eclipse.ini to set the VM explicitly, which is already beyond the abilities of a surprisingly large number of users. If possible I'd like to avoid that complication. I'm not opposed to moving that EGit baseline a bit, but jumping straight to 2020-09 is going to alienate a lot of users and is a no-go IMO.
+1 for Java 11
+1 for Java 11. Jetty offers already version 10.x, that requires Java 11.
+1 for Java 11 Trivial bugs like these one below originate in lack of availability of utilities. The result is C-style code which is error-prone. https://bugs.eclipse.org/bugs/show_bug.cgi?id=575629
announced the plan to switch to Java 11 in 6.0 for 2021-12 on the cross list https://www.eclipse.org/lists/cross-project-issues-dev/msg18654.html
Gerrit change https://git.eclipse.org/r/c/jgit/jgit/+/174128 was merged to [master]. Commit: http://git.eclipse.org/c/jgit/jgit.git/commit/?id=f81a3fc91a51776e6b44a4fc0d9ba5ac488f2c9e
