Yes I know that the target platform for Java EE 8 is Java SE 8, but what I talked about solely was the section about Java SE deployment of JAX-RS 2.1 spec, which does *not* say Java 8. So maybe we should simply say "Java SE 8" in the spec, that would be a solution? -Markus
From: jaxrs-spec@javaee.groups.io [mailto:jaxrs-spec@javaee.groups.io] On Behalf Of Pavel Bucek
Sent: Freitag, 16. Juni 2017 21:03
To: jaxrs-spec@javaee.groups.io
Subject: Re: [jaxrs] Status of JAXB in JAX-RS 2.1 JAXB dependency cannot be declared optional, that's a fact. Even if everyone from the EG would be for that, it won't be done. Reasons were already stated on this list.
We are not going to say anything about Java 9 either, since it won't be released at the time of writing and we don't want to make any statements, which could turn either way - it may become meaning less very soon, or the message meaning could be changed by some change in the Java 9 SE.
You can check that this is consistent with other specifications, since, as you surely are aware of, the target platform for Java EE 8 is Java SE 8.
Have a nice weekend,
Pavel On 16/06/2017 19:50, Markus KARG wrote: Pavel, it seems you just have a different interpretation of the word "end user". At least I, as a car end user, do neither read the specification of pistons, nor does my car vendor add a note to the car's manual that it is the driver's obligation to look into the motor whether the pistons still work well when driving on streets built after the car had been manufactured. I am pretty sure that even oldtimers work well on latest streets without special care of the driver… ;-) Be assured that our products will come with *separate* instructions for how to run on Java SE 9 vs Java SE 8 - for a very good reason! But that's not the point. I neither want to discuss JDK / Java related issues on the JAX-RS EG list. Waht I want this EG (a group who decided to *neither* declare JAXB optional, *nor* to enable JAXB by default using module-info) is to bear the consequences of the sum of these choices: Clearly add a very short but clear note in JAX-RS 2.1's "Java SE Deployment" chapter about two simple facts: (A) JAX-RS 2.1 needs Java SE 8 or later. (B) On Java 9, the end user MUST explicitly activate all optional modules. At time of writing this at least is java.xml.bind. An implementation MAY enable these modules by default. Then everybody knows how the combination of "JAXB is *still mandatory* in this spec" and "Java SE 9 is *not forbidden* by this spec" is meant to work in field. Votes? -Markus Markus, your description of user definitely doesn't read the spec document, javadocs, etc. So what exactly would be achieved by putting a note into the spec document? My recommendation would be putting this as a warning to release notes of your product and reflect that in your documentation. If you want to discuss JDK/Java related issues, please do it elsewhere, as this is a list for JAX-RS, not Java 9 SE. (I'd recommend jdk9-dev@...). Regards,
Pavel On 16/06/2017 18:34, Markus KARG wrote: 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 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 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 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
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: 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?
|
