Pavel,

 

my point is that the application *user* simply does not know that he must use --add-module when running any binary application on Java 9, as the *user* has no knowledge that JAXB is used *inside* of that (at least we as an ISV do not tell our users what APIs we use inside). So as the JAX-RS specification talks about how JAXB is handled, the user could assume that the JAX-RS implementation handles this issue "somehow magically" (like having a module-info). So *because* we decided against a "magic solution" (= module-info), it would be fair if the spec would in turn say that since there is no module-info enforced by JAX-RS, the *user* has to be informed by the application vendor when an application is making use of JAXB. How should the user know otherwise (other than trial-and-error)?

 

-Markus

 

From: jaxrs-spec@javaee.groups.io [mailto:jaxrs-spec@javaee.groups.io] On Behalf Of Pavel Bucek
Sent: Freitag, 16. Juni 2017 16:16
To: jaxrs-spec@javaee.groups.io
Subject: Re: [jaxrs] Status of JAXB in JAX-RS 2.1

 

that depends on how the application is ran (on Java 9).

If the app is on classpath, the *user* has to --add-module java.xml.bind. Nobody can do that for him.

If the app is on module path, there is another set of dependencies:

       requires transitive java.activation;
       requires transitive java.desktop;
       requires transitive java.logging;
       requires transitive java.management;

and maybe others. (some of those are required by Jersey (logger), some of them by JAX-RS (spec mandates that implementation has to support returning java.awt.image.RenderedImage, which is in java.desktop).

Dependency on java.xml.bind could be solved in the API jar, as suggested in the module-info:

https://github.com/jax-rs/api/blob/master/jaxrs-api/src/main/java/module-info.java

but since we agreed on not including it, it's up to the user or the implementation. (both parties can fix the issue by adding runtime switches - your statement about implementation being required to do something is not correct).

So, Markus, I'm not sure whether you are asking for something or .. ?

Regards,
Pavel

On 16/06/2017 15:37, Markus KARG wrote:

I do not say we should remove JAXB, I just wanted to ask because it was in the JSR 370 charter. I also do not see a big benefit of removing JAXB. The only problem I see is running JAX-RS 2.1 on Java SE 9: Due to project Jigsaw, a JRE will not allow access to JAXB unless the JVM is *explicitly* asked to grant access to JAXB. So we all should be aware what this means for the (reference) implementations: If we do *not* say JAXB is "conditional", and until an implementation *forbids* running Java 9, that implies that JAXB is still a MUST even on Java SE 9 -- so all implementations must take care to grant JAXB access. I assume that all existing implementors already fixed this…? :-)

-Markus

 

 

From: jaxrs-spec@javaee.groups.io [mailto:jaxrs-spec@javaee.groups.io] On Behalf Of Santiago Pericas-Geertsen
Sent: Donnerstag, 15. Juni 2017 17:48
To: jaxrs-spec@javaee.groups.io
Subject: Re: [jaxrs] Status of JAXB in JAX-RS 2.1

 

 

On Jun 15, 2017, at 11:30 AM, Sergey Beryozkin <sberyozkin@...> wrote:

 

I see no practical point in doing it anyway. It's unlikely that any of the existing JAX-RS implementations will choose to annoy some of its users and just do not ship JAXB-aware providers - they will be needed for the next 10 years at least anyway even though the new services are more likely to use JSON/etc

 

 +1

 

— Santiago

Sergey 
On 15/06/17 16:31, Pavel Bucek wrote:

Hi Markus,

we learned that it is not possible to do that in this release.

The main issue is that we cannot just deprecate something, there is a strict policy related to making backwards incompatible changes - we'd need to create separate specification, which would replace deprecated/removed functionality.

What we could do is to add a note to the JaxbLink javadoc saying "This class will be removed at some point, replaced by FOOBAR"; the problem is that we don't have FOOBAR at the moment..

Regards,
Pavel

 

On 15/06/2017 16:31, Markus KARG wrote:

Dear Spec Leads,

 

the JSR 370 charter says that with JAX-RS 2.1 the JAXB technology should become conditional.

 

Looking at the last spec draft I cannot find anything about that. Quite contrary is still is rather clear about the fact what an implementation has to do with JAXBElement etc.

 

So I'd like to ask what to do with this issue. Will JAXB stay as it is? Or do you have plans to make it obsolete in JAX-RS 2.1 final draft?

 

Thanks

-Markus