Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jersey-dev] Jersey build vs. JDK version


I do not like too much the idea of removing tests. I understand that the tests do not work with OpenJDK, but every removed test possibly allows a merge request that breaks something that could have been caught with the test. There are better ways to handle the tests: rework them not to depend on javafx, or have a way (profile sounds good) to skip the tests. I do not think we need to rely on Oracle JDK, but it is most common, most people would not have issues with running the tests with javafx, which is another reason for keeping the tests.

I understand that people can have an environment where certain tests fail. There is bunch of tests in Jersey that got already @Ignored for being unstable. I think fixing the tests should be priority before we start adding new features.

Regarding the new versions, situation is, if I understand it correctly, as follows:

1) dependency on technology being donated (perhaps in the latest batch) - We should depend on the new version which has/will have the EPL licence. We are not allowed to have a dependency on technology with GPL and the same I assume is with CDDL.

2) dependency on 3rd party libs - for each lib, there needs to be a CQ filed for some specific version. The CQs were not filed yet, as the Eclipse process does not prefer filing all CQs at once. The great thing is that Jersey was approved for being located in the git repository even without the 3rd party approved. But, any new version needs an additional CQ. I think we should get the CQs for the Initial Contribution of Jersey approved first. Unfortunately, Jersey is rather large project with lot of dependencies.



On 05.05.2018 13:07, Markus KARG wrote:

I'm also willing to help fixing that, but we need a clear statement of the project lead and the committers what the solution shall look like. For example, I'm +1 for getting rid of any dependency on JavaFX and OracleJDK, as JAX-RS has nothing to do with neither Oracle nor GUIs. But according to the EF rules, it is up to the committers to decide about that. So I kindly like to ask the committers to allow us to simply remove such dependencies.


*From:*jersey-dev-bounces@xxxxxxxxxxx [mailto:jersey-dev-bounces@xxxxxxxxxxx] *On Behalf Of *Christian Kaltepoth
*Sent:* Samstag, 5. Mai 2018 10:32
*To:* jersey-dev@xxxxxxxxxxx
*Subject:* [jersey-dev] Jersey build vs. JDK version

Hi all,

it looks like there are many people (including me) who run into problems building Jersey.

The problems I'm aware of are:

  * Jersey uses JMockit 1.18 which has a known bug
    <> that causes build
    failures with OpenJDK. I already created a pull request
    <> that updates
    JMockit to 1.19 which fixes this problem.
  * The "e2e-entity" module uses JavaFX classes. As OpenJDK doesn't
    include JavaFX, the build fails on this module. Perhaps this
    module could only be included when running with an Oracle JDK?
    This should be easy using a Maven profile which gets activated
    depending on the JDK version.
  * The LinkingTest
    from the "declarative-linking" module fails when running the build
    with the latest OpenJDK 8 version. It looks like the order of the
    links returned from the resource is different and the test is
    (too?) strict about checking the response. Disabling JSONAssert's
    strict mode fixes this problem. I'll create a pull request for
    this later today.
  * Markus reported
    <> that
    ClientDestroyTest fails for him when running the build with Oracle
    JDK 1.8.0_144
  * On the mailing list Jan told us
    <> that
    there are known problems with JDK 8b161+

So you see that running the Jersey build is not very straight forward. :-)

So I wonder if this could be improved. I think that the issues regarding newer Oracle JDK versions are definitely something that should be fixed. What about OpenJDK support? Is there any specific reason for relying on Oracle JDK at the moment?

I would love to help the Jersey team to improve the situation! So please let me know how to help.



Christian Kaltepoth




jersey-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

Back to the top