Support for Java 11 #3965

nirupamarachuri · 2018-10-09T21:20:51Z

Is there any release planned for jersey-common and jersey-guava that supports Java 11? If yes, when is it planned to release?

jansupol · 2018-10-16T13:36:16Z

Relates to Guava#3272? Currently, we plan to continue supporting jdk 8 for some time. As I understand it, JAX-RS 3.0 will use Java API that is not in Java SE 8. Since then, Jersey (Possibly 3.x) would be able to get rid of Java SE 8/Unsafe dependency completely. This mostly depends on the community demand. I feel Java 11 is still not the mainstream, but with the Java 8 end-of-life the requirement of Java 8 compatibility will end. Vendors (IBM, RedHat) still plan to support their Java SE 8 for couple of years.

Technically, we are able to use unsafe on JDK 8 and something else in JDK 11. This is a legal issue a bit, though. This would mean to alter repackaged classes that use Unsafe. That would mean to ask legal staff to validate the license whether it allows a change in the repackaged class source code. Likely, it would be ok. We may try to ask legal for their opinion once Jakarta EE is released and all the legal stuff related to the transition of Java EE to Jakarta EE is taken care of.

Did you have any other concern regarding Java 11 in mind?

mszabo-wikia · 2018-10-30T23:14:52Z

@jansupol It seems that currently it's not possible to start a project build on Java 11 because the currently used maven-enforcer-plugin version 1.4.1 cannot parse the Java 11 version thing, resulting in an exception:

    at org.apache.maven.plugins.enforcer.RequireJavaVersion.execute (RequireJavaVersion.java:52)
    at org.apache.maven.plugins.enforcer.EnforceMojo.execute (EnforceMojo.java:193)
    at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo (DefaultBuildPluginManager.java:137)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:208)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:154)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:146)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:117)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:81)
    at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:56)
    at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:128)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
    at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
    at org.apache.maven.cli.MavenCli.execute (MavenCli.java:954)
    at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:288)
    at org.apache.maven.cli.MavenCli.main (MavenCli.java:192)
    at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
    at jdk.internal.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:62)
    at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke (Method.java:566)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:289)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:229)
    at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:415)
    at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:356)
Caused by: java.lang.StringIndexOutOfBoundsException: begin 0, end 3, length 2
    at java.lang.String.checkBoundsBeginEnd (String.java:3319)
    at java.lang.String.substring (String.java:1874)
    at org.apache.commons.lang.SystemUtils.getJavaVersionAsFloat (SystemUtils.java:1122)
    at org.apache.commons.lang.SystemUtils.<clinit> (SystemUtils.java:818)
    at org.apache.maven.plugins.enforcer.RequireJavaVersion.execute (RequireJavaVersion.java:52)
    at org.apache.maven.plugins.enforcer.EnforceMojo.execute (EnforceMojo.java:193)
    at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo (DefaultBuildPluginManager.java:137)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:208)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:154)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:146)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:117)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:81)
    at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:56)
    at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:128)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
    at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
    at org.apache.maven.cli.MavenCli.execute (MavenCli.java:954)
    at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:288)
    at org.apache.maven.cli.MavenCli.main (MavenCli.java:192)
    at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
    at jdk.internal.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:62)
    at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke (Method.java:566)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:289)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:229)
    at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:415)
    at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:356)

Upgrading the plugin to the latest 3.0.0-M2 version allows the build to proceed as normal (it'll fail eventually for jersey-commons due to Unsafe usages). Would a CQ be required to update the plugin?

cogman · 2018-11-19T23:05:23Z

@jansupol Main concerns I have are the uses of sun.misc.unsafe in the jersey internal libraries (looks like most come from guava).

   org.glassfish.jersey.internal.jsr166.SubmissionPublisher$BufferedSubscription -> sun.misc.Contended                                 JDK internal API (JDK removed internal API)
   org.glassfish.jersey.internal.jsr166.SubmissionPublisher$BufferedSubscription -> sun.misc.Unsafe                                    JDK internal API (jdk.unsupported)
   org.glassfish.jersey.internal.jsr166.UnsafeAccessor -> sun.misc.Unsafe                                    JDK internal API (jdk.unsupported)
   org.glassfish.jersey.internal.util.collection.ConcurrentHashMapV8 -> sun.misc.Unsafe                                    JDK internal API (jdk.unsupported)
   org.glassfish.jersey.internal.util.collection.ConcurrentHashMapV8$1 -> sun.misc.Unsafe                                    JDK internal API (jdk.unsupported)
   org.glassfish.jersey.internal.util.collection.ConcurrentHashMapV8$TreeBin -> sun.misc.Unsafe                                    JDK internal API (jdk.unsupported)
   org.glassfish.jersey.internal.util.collection.LinkedTransferQueue -> sun.misc.Unsafe                                    JDK internal API (jdk.unsupported)
   org.glassfish.jersey.internal.util.collection.LinkedTransferQueue$1 -> sun.misc.Unsafe                                    JDK internal API (jdk.unsupported)
   org.glassfish.jersey.internal.util.collection.LinkedTransferQueue$Node -> sun.misc.Unsafe                                    JDK internal API (jdk.unsupported)

Jersey still works under 11, however, I'm not sure how long that will continue to be the case.

Would it be possible to maintain two branches for the duration of 8 support? A 3.X and 2.X? Future versions could take advantage of java 9's multi release jars ( https://www.javaworld.com/article/3184029/java-language/java-9s-other-new-enhancements-part-4-multi-release-jar-files.html ). Hopefully that will make this not such a problem with java 28.

mszabo-wikia · 2018-11-19T23:53:58Z

@cogman I actually opened #3979 some time ago to remove much of those old collection classes. It seems they only existed to provide BC with older Java versions, which are now unsupported because Jersey 2.26 and above require Java 8 to be compiled and run—so they could be simply replaced with the corresponding JDK classes instead. That leaves only the SubmissionPublisher which is a Java 9 backport and would probably have to be kept. I'm no Jersey expert though, so these are just my observations :)

cogman · 2018-11-20T01:00:03Z

@mszabo-wikia I'll have to do a search, but I wonder if SubmissionPublisher is actually being used.

Either way, it wouldn't be hard to implement it without the internal libraries (I've done this for my company), it just wouldn't be as fast (probably not an issue since we are talking about http communication anyways).

I might propose a pull request. You could even, probably, do a class existence check where submission publisher is used to see if it exists, otherwise use the internal version.

mszabo-wikia · 2018-11-20T01:28:38Z

@cogman Looks like it's only being used in Jersey's SSE implementation (plus potentially in the projects of Jersey users who disregarded the fact it's in an internal package 😉 ).

Yeah, the class existence check would work for running the project, however it'd still cause an issue when building the project on Java 11. Currently (if one patches the maven plugin issue), compilation fails on SubmissionPublisher.java because of @Contended usage (@Unsafe, for now at least, seems ok).

ehiggs · 2018-11-23T09:57:33Z

Technically, we are able to use unsafe on JDK 8 and something else in JDK 11. This is a legal issue a bit, though. This would mean to alter repackaged classes that use Unsafe. That would mean to ask legal staff to validate the license whether it allows a change in the repackaged class source code. Likely, it would be ok.

If I understood correctly you want to take some code out of openjdk and package it into jersey. This is likely not ok as openjdk is GPL and jersey is EPL: https://www.eclipse.org/legal/eplfaq.php#GPLCOMPATIBLE

Are the Eclipse Public License (EPL) 1.0 and the General Public License (GPL) compatible?
The EPL 1.0 and the GPL are not compatible in any combination where the result would be considered either: (a) a "derivative work" (which The Eclipse Foundation interprets consistent with the definition of that term in the U.S. Copyright Act ) or (b) a work "based on" the GPL code, as that phrase is used in the GPLv2, GPLv3 or the GPL FAQ as applicable. Further, you may not combine EPL 1.0 and GPL code in any scenario where source code under those licenses are both the same source code module.

Based upon the position of the Free Software Foundation, you may not combine EPL 1.0 and GPL code in any scenario where linking exists between code made available under those licenses. The above applies to both GPL version 2 and GPL version 3.

Jdk8 is EoL January 2019, so the time to sort this out is asap, imo. Or make a classifier for java8 vs. java11. This way android and slow moving orgs can remain on the oldy mouldy java while the world moves on.

jansupol · 2018-11-23T13:24:30Z

We have JDK 11 on top of our priority list, for 2.29 release.

You are correct, Oracle JDK 8 EoL was announced to be January. Unless I am too much mistaken OpenJDK has EoL in a couple of years. You are also correct that GPL is an issue with EPL. The situation is more complicated with GPLwCPE that JDK 8 is using, but that's possibly not our concern, The classes we might need to update if any were part JEP 266 and originally available under CC0 license before putting to JDK.

skofgar · 2019-01-25T15:24:31Z

@jansupol that's great news – is there a planned release date for 2.29? Also I tried to see if there are any "help wanted" issues for 2.29. But I cannot find anything, not even a milestone.

jansupol · 2019-01-25T15:39:45Z

Right, we are focusing on releasing 2.28 right now, which is in progress currently. Once done, we start working on 2.29. As soon as all the legal matters between the Eclipse Foundation and Oracle are settled, we can perform new releases. I'd love to see 2.29 in April.

Regarding "help wanted", we certainly welcome any help with the open issues Jersey has. Regarding JDK 11, we would welcome any PR that fixes build of Jersey there, even partially, per modules.

mszabo-wikia · 2019-01-30T17:27:04Z

@jansupol For JDK 11 there's already PR #3979, which fixes an issue with JdkVersion utility class. This class was used in the internal DataStructures helper to decide (based on Java version) whether to use backported Jersey collections or their standard equivalents, but it would crash on JDK 11 as it couldn't handle the new version format.

tandr · 2020-08-06T22:18:55Z

Fellas, I am curious what is the status of Java 11 as of right now? Fully supported, or still considered "experimental" of sorts?

jansupol · 2020-08-10T08:32:38Z

Hi, right now Jersey 2.31 should be working flawlessly on JDK 8, 11, 12, 13, 14, and 15. If you have a reason to believe otherwise, please file a bug. Please see our wiki for releases and JDK compatibility.

I think this can be closed.

The current settings were a deliberate decision in DCS-239, due to upstream issues with TLSv1.3. We did not explicitly disable any of the older versions so far, since they are enabled in Java by default. Since new Jersey versions work fine with JDK 11, we can enable 1.3 again, and disable deprecated/old versions, see eclipse-ee4j/jersey#3965 for more info. Tested with Chrome, Firefox and cURL. Request: DCS-1291 Change-Id: I8a5518b87dd2cebf6a33ea6789255a95c0361038

uzoltan mentioned this issue Oct 30, 2018

Oracle Java 11, OpenJDK, and MySQL 8 Support - and a couple of other things arrowhead-f/core-java#19

Merged

mszabo-wikia mentioned this issue Jan 30, 2019

Update maven-enforcer-plugin to 3.0.0-M2 #4041

Merged

wborn mentioned this issue May 5, 2019

Add support for running openHAB with Java 11 openhab/openhab-distro#768

Closed

zbynek mentioned this issue May 31, 2019

Add missing module jaxb-api jenkins-infra/plugin-site-api#55

Merged

jansupol closed this as completed Aug 10, 2020

joakime mentioned this issue Feb 7, 2023

Can we make rest call to jetty 10 server using jersey 1.19? jetty/jetty.project#9323

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Support for Java 11 #3965

Support for Java 11 #3965

nirupamarachuri commented Oct 9, 2018

jansupol commented Oct 16, 2018 •

edited

Loading

mszabo-wikia commented Oct 30, 2018 •

edited

Loading

cogman commented Nov 19, 2018

mszabo-wikia commented Nov 19, 2018

cogman commented Nov 20, 2018

mszabo-wikia commented Nov 20, 2018

ehiggs commented Nov 23, 2018

jansupol commented Nov 23, 2018

skofgar commented Jan 25, 2019

jansupol commented Jan 25, 2019

mszabo-wikia commented Jan 30, 2019

tandr commented Aug 6, 2020

jansupol commented Aug 10, 2020

Support for Java 11 #3965

Support for Java 11 #3965

Comments

nirupamarachuri commented Oct 9, 2018

jansupol commented Oct 16, 2018 • edited Loading

mszabo-wikia commented Oct 30, 2018 • edited Loading

cogman commented Nov 19, 2018

mszabo-wikia commented Nov 19, 2018

cogman commented Nov 20, 2018

mszabo-wikia commented Nov 20, 2018

ehiggs commented Nov 23, 2018

jansupol commented Nov 23, 2018

skofgar commented Jan 25, 2019

jansupol commented Jan 25, 2019

mszabo-wikia commented Jan 30, 2019

tandr commented Aug 6, 2020

jansupol commented Aug 10, 2020

jansupol commented Oct 16, 2018 •

edited

Loading

mszabo-wikia commented Oct 30, 2018 •

edited

Loading