Dear experts,
we originally intended to include compiled module-info to JAX-RS API jar. Original plan was to prepare a release on final or "almost" final Java SE 9 compliant JDK.
As you might know, Java SE 9 was postponed and the JAX-RS release will most likely happen before that date.
Should we include compiled module-info, even when the compilation was done by early access build of JDK 9? I would believe that there won't be any change in the bytecode format, but it could happen..
From my point of view, it might be better to NOT include compiled module-info now and (if demanded), release JAX-RS 2.1.1 (or something like that) with updated API jar.
Any thoughts/comments?
Thanks, Pavel
|
|
Looking at all the trouble I had with diverse Java 9 pre-releases in the past months, I really think it would be wise to completely ignore Java 9 for now. At the time of releasing JAX-RS 2.1 current Java SE still will be 8. Target platforms for JAX-RS 2.1 are Java SE 8 and Java EE 8. So I do neither see a need nor any real benefit for prematurely supporting Java SE 9. It would imply a risk, even if a small one, so we should abstain from that.
It think it would be wise also, not to include Java SE 9 support in JAX-RS 2.1.1. Instead, we should plan to provide Java 9 support in JAX-RS 3, but right now start to work on that once JAX-RS 2.1 is released.
-Markus
toggle quoted messageShow quoted text
-----Original Message----- From: jaxrs-spec@javaee.groups.io [mailto:jaxrs-spec@javaee.groups.io] On Behalf Of Pavel Bucek Sent: Freitag, 2. Juni 2017 16:38 To: jaxrs-spec@javaee.groups.io Subject: [jaxrs] module-info or not module-info..
Dear experts,
we originally intended to include compiled module-info to JAX-RS API jar. Original plan was to prepare a release on final or "almost" final Java SE 9 compliant JDK.
As you might know, Java SE 9 was postponed and the JAX-RS release will most likely happen before that date.
Should we include compiled module-info, even when the compilation was done by early access build of JDK 9? I would believe that there won't be any change in the bytecode format, but it could happen..
From my point of view, it might be better to NOT include compiled module-info now and (if demanded), release JAX-RS 2.1.1 (or something like that) with updated API jar.
Any thoughts/comments?
Thanks, Pavel
|
|
I agree that we should not ship the module-info in 2.1.
I do think it is important that JAX-RS 2.1 should function in Java 9 out-of-the-box though. So, I would advise a wait-and-see approach for whether to include a module-info for a 2.1.1 maintenance release. If JPMS is on by default when Java 9 ships, I would be in favor of including it in the maintenance release.
Thanks,
Andy
J. Andrew McCright IBM WebSphere Development +1 507 253 7448 TL 553-7448 andymc@...
toggle quoted messageShow quoted text
----- Original message ----- From: "Markus KARG" <markus@...> Sent by: jaxrs-spec@javaee.groups.io To: jaxrs-spec@javaee.groups.io Cc: Subject: Re: [jaxrs] module-info or not module-info.. Date: Fri, Jun 2, 2017 11:26 AM
Looking at all the trouble I had with diverse Java 9 pre-releases in the past months, I really think it would be wise to completely ignore Java 9 for now. At the time of releasing JAX-RS 2.1 current Java SE still will be 8. Target platforms for JAX-RS 2.1 are Java SE 8 and Java EE 8. So I do neither see a need nor any real benefit for prematurely supporting Java SE 9. It would imply a risk, even if a small one, so we should abstain from that.
It think it would be wise also, not to include Java SE 9 support in JAX-RS 2.1.1. Instead, we should plan to provide Java 9 support in JAX-RS 3, but right now start to work on that once JAX-RS 2.1 is released.
-Markus
-----Original Message----- From: jaxrs-spec@javaee.groups.io [mailto:jaxrs-spec@javaee.groups.io] On Behalf Of Pavel Bucek Sent: Freitag, 2. Juni 2017 16:38 To: jaxrs-spec@javaee.groups.io Subject: [jaxrs] module-info or not module-info..
Dear experts,
we originally intended to include compiled module-info to JAX-RS API jar. Original plan was to prepare a release on final or "almost" final Java SE 9 compliant JDK.
As you might know, Java SE 9 was postponed and the JAX-RS release will most likely happen before that date.
Should we include compiled module-info, even when the compilation was done by early access build of JDK 9? I would believe that there won't be any change in the bytecode format, but it could happen..
From my point of view, it might be better to NOT include compiled module-info now and (if demanded), release JAX-RS 2.1.1 (or something like that) with updated API jar.
Any thoughts/comments?
Thanks, Pavel
|
|

Ivar Grimstad
As I recall there were some discussion on the javaee-spec mailinglist ( java.net) in May regarding standardzing the module names for the Java EE specs in Java EE 9. So it may be a bit premature to include it now as it may change then depending on how that goes.
Ivar
toggle quoted messageShow quoted text
On Fri, Jun 2, 2017 at 6:55 PM Andy McCright < andymc@...> wrote: I agree that we should not ship the module-info in 2.1.
I do think it is important that JAX-RS 2.1 should function in Java 9 out-of-the-box though. So, I would advise a wait-and-see approach for whether to include a module-info for a 2.1.1 maintenance release. If JPMS is on by default when Java 9 ships, I would be in favor of including it in the maintenance release.
Thanks,
----- Original message ----- From: "Markus KARG" <markus@...> Sent by: jaxrs-spec@javaee.groups.io To: jaxrs-spec@javaee.groups.io Cc: Subject: Re: [jaxrs] module-info or not module-info.. Date: Fri, Jun 2, 2017 11:26 AM
Looking at all the trouble I had with diverse Java 9 pre-releases in the past months, I really think it would be wise to completely ignore Java 9 for now. At the time of releasing JAX-RS 2.1 current Java SE still will be 8. Target platforms for JAX-RS 2.1 are Java SE 8 and Java EE 8. So I do neither see a need nor any real benefit for prematurely supporting Java SE 9. It would imply a risk, even if a small one, so we should abstain from that.
It think it would be wise also, not to include Java SE 9 support in JAX-RS 2.1.1. Instead, we should plan to provide Java 9 support in JAX-RS 3, but right now start to work on that once JAX-RS 2.1 is released.
-Markus
-----Original Message----- From: jaxrs-spec@javaee.groups.io [mailto:jaxrs-spec@javaee.groups.io] On Behalf Of Pavel Bucek Sent: Freitag, 2. Juni 2017 16:38 To: jaxrs-spec@javaee.groups.io Subject: [jaxrs] module-info or not module-info..
Dear experts,
we originally intended to include compiled module-info to JAX-RS API jar. Original plan was to prepare a release on final or "almost" final Java SE 9 compliant JDK.
As you might know, Java SE 9 was postponed and the JAX-RS release will most likely happen before that date.
Should we include compiled module-info, even when the compilation was done by early access build of JDK 9? I would believe that there won't be any change in the bytecode format, but it could happen..
From my point of view, it might be better to NOT include compiled module-info now and (if demanded), release JAX-RS 2.1.1 (or something like that) with updated API jar.
Any thoughts/comments?
Thanks, Pavel
--
Java Champion, JCP EC/EG Member, JUG Leader
|
|
I fully agree to the comments already posted. Including a compiled module-info now seems to be too risky. JAX-RS should wait for some recommendation from the umbrella spec before integrating module-info.
Christian
toggle quoted messageShow quoted text
As I recall there were some discussion on the javaee-spec mailinglist ( java.net) in May regarding standardzing the module names for the Java EE specs in Java EE 9. So it may be a bit premature to include it now as it may change then depending on how that goes.
Ivar On Fri, Jun 2, 2017 at 6:55 PM Andy McCright < andymc@...> wrote: I agree that we should not ship the module-info in 2.1.
I do think it is important that JAX-RS 2.1 should function in Java 9 out-of-the-box though. So, I would advise a wait-and-see approach for whether to include a module-info for a 2.1.1 maintenance release. If JPMS is on by default when Java 9 ships, I would be in favor of including it in the maintenance release.
Thanks,
----- Original message ----- From: "Markus KARG" <markus@...> Sent by: jaxrs-spec@javaee.groups.io To: jaxrs-spec@javaee.groups.io Cc: Subject: Re: [jaxrs] module-info or not module-info.. Date: Fri, Jun 2, 2017 11:26 AM
Looking at all the trouble I had with diverse Java 9 pre-releases in the past months, I really think it would be wise to completely ignore Java 9 for now. At the time of releasing JAX-RS 2.1 current Java SE still will be 8. Target platforms for JAX-RS 2.1 are Java SE 8 and Java EE 8. So I do neither see a need nor any real benefit for prematurely supporting Java SE 9. It would imply a risk, even if a small one, so we should abstain from that.
It think it would be wise also, not to include Java SE 9 support in JAX-RS 2.1.1. Instead, we should plan to provide Java 9 support in JAX-RS 3, but right now start to work on that once JAX-RS 2.1 is released.
-Markus
-----Original Message----- From: jaxrs-spec@javaee.groups.io [mailto:jaxrs-spec@javaee.groups.io] On Behalf Of Pavel Bucek Sent: Freitag, 2. Juni 2017 16:38 To: jaxrs-spec@javaee.groups.io Subject: [jaxrs] module-info or not module-info..
Dear experts,
we originally intended to include compiled module-info to JAX-RS API jar. Original plan was to prepare a release on final or "almost" final Java SE 9 compliant JDK.
As you might know, Java SE 9 was postponed and the JAX-RS release will most likely happen before that date.
Should we include compiled module-info, even when the compilation was done by early access build of JDK 9? I would believe that there won't be any change in the bytecode format, but it could happen..
From my point of view, it might be better to NOT include compiled module-info now and (if demanded), release JAX-RS 2.1.1 (or something like that) with updated API jar.
Any thoughts/comments?
Thanks, Pavel
--
Java Champion, JCP EC/EG Member, JUG Leader
|
|

Gunnar Morling
One option to consider is to add the "Automatic-Module-Name" header to the spec JAR's MANIFEST.MF. This header entry is foreseen by JPMS ( some background) to specify a module name, should a non-modularized JAR be used as an automatic module (instead of deriving a module name from the JAR file name). The change for this hasn't landed int the latest JDK 9 preview release yet (b172 at the time of writing), but once it will, we'd make use of this for Bean Validation. I don't think there's any risk of adding this header, esp. it can be done while building with Java 8.
|
|
toggle quoted messageShow quoted text
On 03/06/2017 08:11, Ivar Grimstad
wrote:
As I recall there were some discussion on the
javaee-spec mailinglist ( java.net) in May
regarding standardzing the module names for the Java EE specs in
Java EE 9.
So it may be a bit premature to include it now as it may
change then depending on how that goes.
Ivar
On Fri, Jun 2, 2017 at 6:55 PM Andy McCright
< andymc@...>
wrote:
I agree that we should not ship the
module-info in 2.1.
I do think it is important that JAX-RS
2.1 should function in Java 9 out-of-the-box though.
So, I would advise a wait-and-see approach for whether
to include a module-info for a 2.1.1 maintenance
release. If JPMS is on by default when Java 9 ships,
I would be in favor of including it in the maintenance
release.
Thanks,
-----
Original message -----
From: "Markus KARG" <markus@...>
Sent by: jaxrs-spec@javaee.groups.io
To: jaxrs-spec@javaee.groups.io
Cc:
Subject: Re: [jaxrs] module-info or not module-info..
Date: Fri, Jun 2, 2017 11:26 AM
Looking at all the
trouble I had with diverse Java 9 pre-releases in
the past months, I really think it would be wise
to completely ignore Java 9 for now. At the time
of releasing JAX-RS 2.1 current Java SE still will
be 8. Target platforms for JAX-RS 2.1 are Java SE
8 and Java EE 8. So I do neither see a need nor
any real benefit for prematurely supporting Java
SE 9. It would imply a risk, even if a small one,
so we should abstain from that.
It think it would be wise also, not to include
Java SE 9 support in JAX-RS 2.1.1. Instead, we
should plan to provide Java 9 support in JAX-RS 3,
but right now start to work on that once JAX-RS
2.1 is released.
-Markus
-----Original Message-----
From: jaxrs-spec@javaee.groups.io
[mailto:jaxrs-spec@javaee.groups.io]
On Behalf Of Pavel Bucek
Sent: Freitag, 2. Juni 2017 16:38
To: jaxrs-spec@javaee.groups.io
Subject: [jaxrs] module-info or not module-info..
Dear experts,
we originally intended to include compiled
module-info to JAX-RS API jar. Original plan was
to prepare a release on final or "almost" final
Java SE 9 compliant JDK.
As you might know, Java SE 9 was postponed and the
JAX-RS release will most likely happen before that
date.
Should we include compiled module-info, even when
the compilation was done by early access build of
JDK 9? I would believe that there won't be any
change in the bytecode format, but it could
happen..
From my point of view, it might be better to NOT
include compiled module-info now and (if
demanded), release JAX-RS 2.1.1 (or something like
that) with updated API jar.
Any thoughts/comments?
Thanks,
Pavel
--
Java Champion, JCP EC/EG Member, JUG Leader
|
|
I'm waiting for the implementation (since I'd like to test it before
the actual commit), but the problem is that I do have some
experience with "breaking" changes between jdk 9 builds, so I'm not
sure whether the header name is final or not :)
I guess we can ask around about this - as you say, introducing
manifest entry is not a problem.
Thanks,
Pavel
toggle quoted messageShow quoted text
On 03/06/2017 12:39, Gunnar Morling via
Groups.Io wrote:
One option to consider is to add the
"Automatic-Module-Name" header to the spec JAR's MANIFEST.MF.
This header entry is foreseen by JPMS (some background)
to specify a module name, should a non-modularized JAR be used as
an automatic module (instead of deriving a module name from the
JAR file name). The change for this hasn't landed int the latest
JDK 9 preview release yet (b172 at the time of writing), but once
it will, we'd make use of this for Bean Validation. I don't think
there's any risk of adding this header, esp. it can be done while
building with Java 8.
|
|
toggle quoted messageShow quoted text
On 04/06/2017 23:11, Pavel Bucek wrote:
I'm waiting for the implementation (since I'd like to test it
before the actual commit), but the problem is that I do have some
experience with "breaking" changes between jdk 9 builds, so I'm
not sure whether the header name is final or not :)
I guess we can ask around about this - as you say, introducing
manifest entry is not a problem.
Thanks,
Pavel
On 03/06/2017 12:39, Gunnar Morling
via Groups.Io wrote:
One option to consider is to add the
"Automatic-Module-Name" header to the spec JAR's MANIFEST.MF.
This header entry is foreseen by JPMS
(some background)
to specify a module name, should a non-modularized JAR be used
as an automatic module (instead of deriving a module name from
the JAR file name). The change for this hasn't landed int the
latest JDK 9 preview release yet (b172 at the time of writing),
but once it will, we'd make use of this for Bean Validation. I
don't think there's any risk of adding this header, esp. it can
be done while building with Java 8.
|
|