Topics

module-info or not module-info..


Pavel Bucek
 

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

-----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


Andy McCright
 

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@...
 
 

----- 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

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,
 
Andy

J. Andrew McCright
IBM WebSphere Development
+1 507 253 7448
TL 553-7448
andymc@...
 
 
----- 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

2017-06-03 8:11 GMT+02:00 Ivar Grimstad <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

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,
 
Andy

J. Andrew McCright
IBM WebSphere Development
+1 507 253 7448
TL 553-7448
andymc@...
 
 
----- 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.


Pavel Bucek
 

We do have the module name and the content already, see

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


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,
 
Andy

J. Andrew McCright
IBM WebSphere Development
+1 507 253 7448
TL 553-7448
andymc@...
 
 
----- 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



Pavel Bucek
 

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.


Pavel Bucek
 

Please see https://github.com/jax-rs/api/commit/f84db6dbb13801411560368deaac7d0d5004db65

Manifest entry "Automatic-Module-Name" was added (based on http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2017-May/000687.html).

Module name for JAX-RS API is "java.ws.rs". Corresponding module-info is already part of the API sources, but it is ignored when compiling on Java SE 8, which is what we use.

Please let me know if you see any issues. (sooner is better).

Regards,
Pavel



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.