3

I keep reading in all sorts of Java libraries, which are using the Jersey HTTP client package, that I should be careful because they use Jersey 2.x and if I have Jersey 1.x in my classpath already, it may cause some conflicts.

But, Jersey project changed group id and package names when it was incorporated into Glassfish project, starting with version 2.x.

Since package names are different, what conflicts could there be? If I have Jersey 1.x in my deployable, those classes will be used, because of Jersey 2.x, provided by the Glassfish Runtime, are entirely different classes, with different names.

Likewise, if I have Jersey 1.x in my deployable, and some dependency comes and adds Jersey 2.x, the only problem that I may have is the following: without a deployment descriptor, Glassfish will use its version of the library, not the provided one. But in any case, no problem should occur because I have both Jersey 1.x and 2.x in my classpath, right?

Please advise, am I missing something? What's all the fuss about?

amihaiemil
  • 623
  • 8
  • 19
  • 1
    let's say class x in version 2 has an improved version of the same method in version 1 ... how on earth is the compiler to know which one you want to use? their paths are the same, so are their classnames and signatures – Stultuske Nov 17 '17 at 09:21
  • Well, no, it is clear that Jersey changed package names entirely in 2.x, right? That's what I found after my research, at least. So, what conflicts, they are different classes. – amihaiemil Nov 17 '17 at 09:22
  • always if you load different versions of the same package, you risk clashes – Stultuske Nov 17 '17 at 09:24
  • They are practically whole different packages, didn't you read what I wrote? Different maven groupIds, different packages: Jersey 1.x com.sun.jersey, with base package com\sun\jersey; Jersey 2.x org.glassfish, with base package org\glassfish. You are either trying to play smart and not saying what you actually mean, or have no idea how the Java classloader works. – amihaiemil Nov 17 '17 at 09:56
  • The conflict is not so much with the Jersey _implementation_, as it is with the JAX-RS API. Jersey 2.x will use JAX-RS 2 while Jersey 1.x will use JAX-RS 1. Some of the APIs have changed from JAX-RS 1 to JAX-RS 2, and most of the problems you will face are NoSuchMethodErrors and AbstractMethodErrors due to class discrepancies (e.g. javax.ws.rs.core.Application) and JAX-RS 2 class trying to use methods that are not on the JAX-RS 1 version of the class. These are the kind of problems you will face. For example https://stackoverflow.com/q/28509370/2587435 – Paul Samsotha Nov 17 '17 at 15:00
  • Not sure (only guessing), but I suspect some problem related to the [Service loader](https://docs.oracle.com/javase/8/docs/api/java/util/ServiceLoader.html) mechanism. Both Jersey versions could provide a service implementer for the same service, hence the conflict. – Olivier Cailloux Nov 18 '17 at 17:44

1 Answers1

2

Yes you should !

Always think twise when your project is attached with dependency which is out of your control.

One is as you,ve mentioned from 1.x to 2.x they have moved from sun namespace to glassfish namespace.

And also in 1.x they use JEE6 version of JAX-RS and in 2.x they use JEE7 version of JAX-RS. This is a big deal. For example javax.ws.rs.core.Application used in jersey in differen versions are different and cannot used in the same manner.

Jesey 2.x uses JEE 7. In JEE 7 version of javax.ws.rs.core.Application has

Jesey 1.x uses JEE 6. In JEE 6 version of javax.ws.rs.core.Application only has

  • getClasses()
  • getClass()

But getProperties() is not defined. https://jersey.github.io/apidocs/1.19.1/jersey/javax/ws/rs/core/Application.html Which can lead to erros like NoSuchMethodError https://docs.oracle.com/javase/7/docs/api/java/lang/NoSuchMethodError.html This is just one incompetency. Im sure if you,ve dig deeper you can find more.

Its not only the namespaces, the underlying implementations has changed a log. Yes glassfish runtime is loaded with jersey. But you may be in trouble because although have specified provided scope different artifact names can lead to inconsistencies.

JoshDM
  • 4,939
  • 7
  • 43
  • 72
Kalpa Gunarathna
  • 1,047
  • 11
  • 17