Pavel,

 

this complete Jigsaw topic is a mess for the end user and I wonder what the OpenJDK guys wanted to reach with making JAXB optional… In reality no end user knows anything about Jigsaw (end users are not Java licencees, not even programmers, they are simply people who try to startup an application they did not have a source code for and they do not have any interest in the difference from Java 8 to Java 9 but just think "the newer the better"). What will happen in reality is that lots of end users will download JRE 9 and run JAX-RS-containing applications ontop of it and then fail. If we want to let them stand in the rain, we can go on like this. But we should be prepared about the effect… : Angry people hating us for not telling them the truth. Anyways, seems I am the only one who has a problem with the fact that our hotline soon will melt down. I hope that everybody in this EG is clear about the effects of not telling people how to run a JAX-RS 2.1 application on Java 9.

 

Hands up please: Who in this EG thinks it is a good idea to NOT tell anybody in the specification that JAXB *is not* conditional but actually it is technically as soon as an end user replaces JRE 8 by JRE 9?

 

I know that at least my own 10.000+ end users will kill me for this backwards-incompatibility. They don't care who broke it. It's just broken by me or Oracle in their view.

 

-Markus

 

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

 

Well.. the spec says nothing about running on Java 9, since Java 9 won't be final when JAX-RS 2.1 is released.

When a user want's to run on Java 9, it is expected that he knows what he's doing (i.e. running on unsupported environment). There is plenty of tools provided by jdk to get this kind of information, for example jdeps:

$ jdeps ~/.m2/repository/javax/ws/rs/javax.ws.rs-api/2.1-m09/javax.ws.rs-api-2.1-m09.jar
javax.ws.rs-api-2.1-m09.jar -> java.base
javax.ws.rs-api-2.1-m09.jar -> java.logging
javax.ws.rs-api-2.1-m09.jar -> java.xml
javax.ws.rs-api-2.1-m09.jar -> java.xml.bind
   javax.ws.rs                                        -> java.lang                                          java.base
   javax.ws.rs                                        -> java.lang.annotation                               java.base
   javax.ws.rs                                        -> java.net                                           java.base
   javax.ws.rs                                        -> java.util                                          java.base
   javax.ws.rs                                        -> javax.ws.rs.core                                   javax.ws.rs-api-2.1-m09.jar
   javax.ws.rs                                        -> javax.ws.rs.ext                                    javax.ws.rs-api-2.1-m09.jar
   javax.ws.rs.client                                 -> java.io                                            java.base
   javax.ws.rs.client                                 -> java.lang                                          java.base
   javax.ws.rs.client                                 -> java.lang.annotation                               java.base
   javax.ws.rs.client                                 -> java.lang.invoke                                   java.base
   javax.ws.rs.client                                 -> java.lang.reflect                                  java.base
   javax.ws.rs.client                                 -> java.net                                           java.base
   javax.ws.rs.client                                 -> java.security                                      java.base
   javax.ws.rs.client                                 -> java.util                                          java.base
   javax.ws.rs.client                                 -> java.util.concurrent                               java.base
   javax.ws.rs.client                                 -> java.util.logging                                  java.logging
   javax.ws.rs.client                                 -> javax.net.ssl                                      java.base
   javax.ws.rs.client                                 -> javax.ws.rs                                        javax.ws.rs-api-2.1-m09.jar
   javax.ws.rs.client                                 -> javax.ws.rs.core                                   javax.ws.rs-api-2.1-m09.jar
   javax.ws.rs.container                              -> java.io                                            java.base
   javax.ws.rs.container                              -> java.lang                                          java.base
   javax.ws.rs.container                              -> java.lang.annotation                               java.base
   javax.ws.rs.container                              -> java.lang.reflect                                  java.base
   javax.ws.rs.container                              -> java.net                                           java.base
   javax.ws.rs.container                              -> java.util                                          java.base
   javax.ws.rs.container                              -> java.util.concurrent                               java.base
   javax.ws.rs.container                              -> javax.ws.rs.core                                   javax.ws.rs-api-2.1-m09.jar
   javax.ws.rs.core                                   -> java.io                                            java.base
   javax.ws.rs.core                                   -> java.lang                                          java.base
   javax.ws.rs.core                                   -> java.lang.annotation                               java.base
   javax.ws.rs.core                                   -> java.lang.reflect                                  java.base
   javax.ws.rs.core                                   -> java.net                                           java.base
   javax.ws.rs.core                                   -> java.security                                      java.base
   javax.ws.rs.core                                   -> java.util                                          java.base
   javax.ws.rs.core                                   -> javax.ws.rs                                        javax.ws.rs-api-2.1-m09.jar
   javax.ws.rs.core                                   -> javax.ws.rs.ext                                    javax.ws.rs-api-2.1-m09.jar
   javax.ws.rs.core                                   -> javax.xml.bind.annotation                          java.xml.bind
   javax.ws.rs.core                                   -> javax.xml.bind.annotation.adapters                 java.xml.bind
   javax.ws.rs.core                                   -> javax.xml.namespace                                java.xml
   javax.ws.rs.ext                                    -> java.io                                            java.base
   javax.ws.rs.ext                                    -> java.lang                                          java.base
   javax.ws.rs.ext                                    -> java.lang.annotation                               java.base
   javax.ws.rs.ext                                    -> java.lang.invoke                                   java.base
   javax.ws.rs.ext                                    -> java.lang.reflect                                  java.base
   javax.ws.rs.ext                                    -> java.net                                           java.base
   javax.ws.rs.ext                                    -> java.security                                      java.base
   javax.ws.rs.ext                                    -> java.util                                          java.base
   javax.ws.rs.ext                                    -> java.util.logging                                  java.logging
   javax.ws.rs.ext                                    -> javax.ws.rs                                        javax.ws.rs-api-2.1-m09.jar
   javax.ws.rs.ext                                    -> javax.ws.rs.core                                   javax.ws.rs-api-2.1-m09.jar
   javax.ws.rs.sse                                    -> java.io                                            java.base
   javax.ws.rs.sse                                    -> java.lang                                          java.base
   javax.ws.rs.sse                                    -> java.lang.invoke                                   java.base
   javax.ws.rs.sse                                    -> java.lang.reflect                                  java.base
   javax.ws.rs.sse                                    -> java.net                                           java.base
   javax.ws.rs.sse                                    -> java.security                                      java.base
   javax.ws.rs.sse                                    -> java.util                                          java.base
   javax.ws.rs.sse                                    -> java.util.concurrent                               java.base
   javax.ws.rs.sse                                    -> java.util.function                                 java.base
   javax.ws.rs.sse                                    -> java.util.logging                                  java.logging
   javax.ws.rs.sse                                    -> javax.ws.rs.client                                 javax.ws.rs-api-2.1-m09.jar
   javax.ws.rs.sse                                    -> javax.ws.rs.core                                   javax.ws.rs-api-2.1-m09.jar

Regards,
Pavel

 

 

On 16/06/2017 17:39, Markus KARG wrote:

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

 

 

 

 

 

Well.. the spec says nothing about running on Java 9, since Java 9 won't be final when JAX-RS 2.1 is released.

When a user want's to run on Java 9, it is expected that he knows what he's doing (i.e. running on unsupported environment). There is plenty of tools provided by jdk to get this kind of information, for example jdeps:

$ jdeps ~/.m2/repository/javax/ws/rs/javax.ws.rs-api/2.1-m09/javax.ws.rs-api-2.1-m09.jar
javax.ws.rs-api-2.1-m09.jar -> java.base
javax.ws.rs-api-2.1-m09.jar -> java.logging
javax.ws.rs-api-2.1-m09.jar -> java.xml
javax.ws.rs-api-2.1-m09.jar -> java.xml.bind
   javax.ws.rs                                        -> java.lang                                          java.base
   javax.ws.rs                                        -> java.lang.annotation                               java.base
   javax.ws.rs                                        -> java.net                                           java.base
   javax.ws.rs                                        -> java.util                                          java.base
   javax.ws.rs                                        -> javax.ws.rs.core                                   javax.ws.rs-api-2.1-m09.jar
   javax.ws.rs                                        -> javax.ws.rs.ext                                    javax.ws.rs-api-2.1-m09.jar
   javax.ws.rs.client                                 -> java.io                                            java.base
   javax.ws.rs.client                                 -> java.lang                                          java.base
   javax.ws.rs.client                                 -> java.lang.annotation                               java.base
   javax.ws.rs.client                                 -> java.lang.invoke                                   java.base
   javax.ws.rs.client                                 -> java.lang.reflect                                  java.base
   javax.ws.rs.client                                 -> java.net                                           java.base
   javax.ws.rs.client                                 -> java.security                                      java.base
   javax.ws.rs.client                                 -> java.util                                          java.base
   javax.ws.rs.client                                 -> java.util.concurrent                               java.base
   javax.ws.rs.client                                 -> java.util.logging                                  java.logging
   javax.ws.rs.client                                 -> javax.net.ssl                                      java.base
   javax.ws.rs.client                                 -> javax.ws.rs                                        javax.ws.rs-api-2.1-m09.jar
   javax.ws.rs.client                                 -> javax.ws.rs.core                                   javax.ws.rs-api-2.1-m09.jar
   javax.ws.rs.container                              -> java.io                                            java.base
   javax.ws.rs.container                              -> java.lang                                          java.base
   javax.ws.rs.container                              -> java.lang.annotation                               java.base
   javax.ws.rs.container                              -> java.lang.reflect                                  java.base
   javax.ws.rs.container                              -> java.net                                           java.base
   javax.ws.rs.container                              -> java.util                                          java.base
   javax.ws.rs.container                              -> java.util.concurrent                               java.base
   javax.ws.rs.container                              -> javax.ws.rs.core                                   javax.ws.rs-api-2.1-m09.jar
   javax.ws.rs.core                                   -> java.io                                            java.base
   javax.ws.rs.core                                   -> java.lang                                          java.base
   javax.ws.rs.core                                   -> java.lang.annotation                               java.base
   javax.ws.rs.core                                   -> java.lang.reflect                                  java.base
   javax.ws.rs.core                                   -> java.net                                           java.base
   javax.ws.rs.core                                   -> java.security                                      java.base
   javax.ws.rs.core                                   -> java.util                                          java.base
   javax.ws.rs.core                                   -> javax.ws.rs                                        javax.ws.rs-api-2.1-m09.jar
   javax.ws.rs.core                                   -> javax.ws.rs.ext                                    javax.ws.rs-api-2.1-m09.jar
   javax.ws.rs.core                                   -> javax.xml.bind.annotation                          java.xml.bind
   javax.ws.rs.core                                   -> javax.xml.bind.annotation.adapters                 java.xml.bind
   javax.ws.rs.core                                   -> javax.xml.namespace                                java.xml
   javax.ws.rs.ext                                    -> java.io                                            java.base
   javax.ws.rs.ext                                    -> java.lang                                          java.base
   javax.ws.rs.ext                                    -> java.lang.annotation                               java.base
   javax.ws.rs.ext                                    -> java.lang.invoke                                   java.base
   javax.ws.rs.ext                                    -> java.lang.reflect                                  java.base
   javax.ws.rs.ext                                    -> java.net                                           java.base
   javax.ws.rs.ext                                    -> java.security                                      java.base
   javax.ws.rs.ext                                    -> java.util                                          java.base
   javax.ws.rs.ext                                    -> java.util.logging                                  java.logging
   javax.ws.rs.ext                                    -> javax.ws.rs                                        javax.ws.rs-api-2.1-m09.jar
   javax.ws.rs.ext                                    -> javax.ws.rs.core                                   javax.ws.rs-api-2.1-m09.jar
   javax.ws.rs.sse                                    -> java.io                                            java.base
   javax.ws.rs.sse                                    -> java.lang                                          java.base
   javax.ws.rs.sse                                    -> java.lang.invoke                                   java.base
   javax.ws.rs.sse                                    -> java.lang.reflect                                  java.base
   javax.ws.rs.sse                                    -> java.net                                           java.base
   javax.ws.rs.sse                                    -> java.security                                      java.base
   javax.ws.rs.sse                                    -> java.util                                          java.base
   javax.ws.rs.sse                                    -> java.util.concurrent                               java.base
   javax.ws.rs.sse                                    -> java.util.function                                 java.base
   javax.ws.rs.sse                                    -> java.util.logging                                  java.logging
   javax.ws.rs.sse                                    -> javax.ws.rs.client                                 javax.ws.rs-api-2.1-m09.jar
   javax.ws.rs.sse                                    -> javax.ws.rs.core                                   javax.ws.rs-api-2.1-m09.jar

Regards,
Pavel

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

 

 

 

 

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

 

 

 

 

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

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

 

 

 

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

 

 

 

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

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

Hi Sergey,

I believe that javadoc is the right place for documentation like this. Not to mention that writing the documentation to the annotation string literal is not very convenient, especially when the text would span multiple lines.

I think I get what usecase addressed here, but seems like the proposed solution would not provide solution of related issues. It would reduce "documentation" annotations, but various doc tools would still require additional annotations.

Thanks and regards,
Pavel


On 13/06/2017 14:17, Sergey Beryozkin wrote:

Hi

I created an issue awhile back to get something like

@Path(value="/", doc="the path")

supported for all of the JAX-RS annotations.

The idea is to come up with a single well known property that the future code or service api info generation tools can use.

For example, some use JavaDocs - which overloads it a bit because what is documented at the Java level and what is visible to the HTTP service consumer may not always make sense to keep in sync.
Then we have Swagger2 annotations related to the docs, in CXF we also have @Description annotations that can be used by the WADL filter.

Having a 'doc' would be a simple improvement which can help to minimize the 'noise' related to everyone using their own annotations/approaches to documenting JAX-RS API...

Sergey

Hi Sergey,

that's true, but does that contradict what we did?

(I do see that as a shortcut, which makes sense to have, nothing more).

Regards,
Pavel

On 13/06/2017 13:33, Sergey Beryozkin wrote:

Hi Pavel

As far as I understand that is what the idea behind ResourceContext.getResource(Class<T>) was ?

Thanks, Sergey

On 07/06/17 16:29, Pavel Bucek wrote:

Dear experts,

we are in a stage when we are re-reading spec document and javadoc (you're welcomed to help us - if you have some favorite typo anywhere in JAX-RS and you wan't to get rid of it, now is the time to report it) and one particular thing was noticed:

specification supports only returning an instance as a subresource, thus:

@Path("sub1")
public SubResource getSubResourceLocator1() {
    return new SubResource();
}

is supported and

@Path("sub2")
public Class<SubResource> getSubResourceLocator2() {
    return SubResource.class;
}

is not.

RI currently supports both cases and I'm wondering whether we should add that into the specification.

There is obvious advantage of the latter approach, since the instance will be managed (in a correct scope) by the JAX-RS runtime and more importantly, it will be injected, so application developer don't have to inject evertyhing required in a root resource and pass injected values in a constructor of returned instance.

What do you think?

Thanks and regards,
Pavel

Hi

I created an issue awhile back to get something like

@Path(value="/", doc="the path")

supported for all of the JAX-RS annotations.

The idea is to come up with a single well known property that the future code or service api info generation tools can use.

For example, some use JavaDocs - which overloads it a bit because what is documented at the Java level and what is visible to the HTTP service consumer may not always make sense to keep in sync.
Then we have Swagger2 annotations related to the docs, in CXF we also have @Description annotations that can be used by the WADL filter.

Having a 'doc' would be a simple improvement which can help to minimize the 'noise' related to everyone using their own annotations/approaches to documenting JAX-RS API...

Sergey

Hi Pavel

As far as I understand that is what the idea behind ResourceContext.getResource(Class<T>) was ?

Thanks, Sergey

On 07/06/17 16:29, Pavel Bucek wrote:

Dear experts,

we are in a stage when we are re-reading spec document and javadoc (you're welcomed to help us - if you have some favorite typo anywhere in JAX-RS and you wan't to get rid of it, now is the time to report it) and one particular thing was noticed:

specification supports only returning an instance as a subresource, thus:

@Path("sub1")
public SubResource getSubResourceLocator1() {
    return new SubResource();
}

is supported and

@Path("sub2")
public Class<SubResource> getSubResourceLocator2() {
    return SubResource.class;
}

is not.

RI currently supports both cases and I'm wondering whether we should add that into the specification.

There is obvious advantage of the latter approach, since the instance will be managed (in a correct scope) by the JAX-RS runtime and more importantly, it will be injected, so application developer don't have to inject evertyhing required in a root resource and pass injected values in a constructor of returned instance.

What do you think?

Thanks and regards,
Pavel

Dear experts,

we are in a stage when we are re-reading spec document and javadoc (you're welcomed to help us - if you have some favorite typo anywhere in JAX-RS and you wan't to get rid of it, now is the time to report it) and one particular thing was noticed:

specification supports only returning an instance as a subresource, thus:

@Path("sub1")
public SubResource getSubResourceLocator1() {
    return new SubResource();
}

is supported and

@Path("sub2")
public Class<SubResource> getSubResourceLocator2() {
    return SubResource.class;
}

is not.

RI currently supports both cases and I'm wondering whether we should add that into the specification.

There is obvious advantage of the latter approach, since the instance will be managed (in a correct scope) by the JAX-RS runtime and more importantly, it will be injected, so application developer don't have to inject evertyhing required in a root resource and pass injected values in a constructor of returned instance.

What do you think?

Thanks and regards,
Pavel

Hi Pavel,

Totally understandable.

However, let me raise an issue that is related to the CDI topic -- I think the whole CDI integration contains several, different concerns at once:

For developers it would be very helpful to @Inject JAX-RS managed objects -- mainly UriInfo -- into other (CDI) managed beans. We stumbled across this several times and I think it is an easy thing to require in the spec, something like: If the container supports JAX-RS and CDI/JSR 330, then UriInfo (maybe among others) must be injectable with an appropriate scope (here request scoped I guess). Wouldn't involve any other changes in the API.

WDYT?

Cheers,
Sebastian
   

On 06/08/2017 12:21 AM, Pavel Bucek wrote:

Hi Guillermo,

I really appreciate your activity around this area, but at this point, I don't think we should consider pursuing any change. We are days from Proposed Final Draft and we still don't have ready everything we HAVE TO deliver. Adding any other (non-trivial) changes like this is like sawing off the branch we’re sitting on..

Thanks and regards,
Pavel

On 06/06/2017 18:38, Guillermo González de Agüero wrote:

Hi,

I invited Antoine Sabot Durand (CDI Spec lead) to join the conversation and he replied me today that he and the Weld team will have a look at the issue as they have already been helping other spec integrate with CDI.

CDI 2.0 is already final but maybe they have some ideas that could help here going some step foward. I ask you and Santiago and the rest of the EG please to wait a little for them to comment here before taking a definitive decission.

Regards,

Guillermo González de Agüero

On Tue, Jun 6, 2017 at 5:47 PM, Pavel Bucek <pavel.bucek@...> wrote:

Dear experts,

Thank you for a productive discussion about CDI integration. We now have a good understanding of what can be achieved when using the new CDI 2.0 API.

Our recent analysis has concluded that providing a better CDI integration would require more experimentation than what we can do in this minor release. We also don't want to introduce "hard" dependency on CDI API to the JAX-RS API as many JAX-RS developers rely on running JAX-RS outside of CDI context.

We agree that CDI can be used as the "glue" of the whole Java EE platform and JAX-RS can do more in terms of the CDI integration when running in a Java EE container. Currently, such enhancements are NOT forbidden at the spec level and JAX-RS providers are free to introduce support that goes beyond what JAX-RS spec mandates. Further experiment in this area can help to gather more feedback for any future re-evaluation of improved CDI/JAX-RS integration story. Also, this feedback may help CDI owners to provide public API enhancements to enable full JAX-RS /CDI integration in a portable way.

Thanks again for the discussion on the mailing list.

Best regards,
Pavel & Santiago

Hi Guillermo,

I really appreciate your activity around this area, but at this point, I don't think we should consider pursuing any change. We are days from Proposed Final Draft and we still don't have ready everything we HAVE TO deliver. Adding any other (non-trivial) changes like this is like sawing off the branch we’re sitting on..

Thanks and regards,
Pavel

On 06/06/2017 18:38, Guillermo González de Agüero wrote:

Hi,

I invited Antoine Sabot Durand (CDI Spec lead) to join the conversation and he replied me today that he and the Weld team will have a look at the issue as they have already been helping other spec integrate with CDI.

CDI 2.0 is already final but maybe they have some ideas that could help here going some step foward. I ask you and Santiago and the rest of the EG please to wait a little for them to comment here before taking a definitive decission.

Regards,

Guillermo González de Agüero

On Tue, Jun 6, 2017 at 5:47 PM, Pavel Bucek <pavel.bucek@...> wrote:

Dear experts,

Thank you for a productive discussion about CDI integration. We now have a good understanding of what can be achieved when using the new CDI 2.0 API.

Our recent analysis has concluded that providing a better CDI integration would require more experimentation than what we can do in this minor release. We also don't want to introduce "hard" dependency on CDI API to the JAX-RS API as many JAX-RS developers rely on running JAX-RS outside of CDI context.

We agree that CDI can be used as the "glue" of the whole Java EE platform and JAX-RS can do more in terms of the CDI integration when running in a Java EE container. Currently, such enhancements are NOT forbidden at the spec level and JAX-RS providers are free to introduce support that goes beyond what JAX-RS spec mandates. Further experiment in this area can help to gather more feedback for any future re-evaluation of improved CDI/JAX-RS integration story. Also, this feedback may help CDI owners to provide public API enhancements to enable full JAX-RS /CDI integration in a portable way.

Thanks again for the discussion on the mailing list.

Best regards,
Pavel & Santiago