toggle quoted messageShow quoted text
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
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
Dependency on java.xml.bind could be solved in the API jar, as
suggested in the module-info:
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 ..
On 16/06/2017 15:37, Markus KARG wrote:
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…?
On Jun 15, 2017, at 11:30 AM, Sergey
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
On 15/06/17 16:31, Pavel Bucek wrote:
learned that it is not possible to do that in this
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
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..
15/06/2017 16:31, Markus KARG wrote:
JSR 370 charter says that with JAX-RS 2.1 the JAXB
technology should become conditional.
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.
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?