Werner, I don’t understand what are you proposing. Bill made a clear statement that modules must not be a part of specs. I agree with it. If module is defined in an RI it doesn’t affect Java EE 8 at all because it’s Java 8 based. On the other hand, some implementation, like JSON-P or Yasson are designed to work in Java SE environment as well. It makes sense making them JDK9 compatible. We follow naming convention proposed by Java team (see email from Lukas below). If future versions of Java EE define different module name convention, we will rename the modules.
Thanks,
Dmitry
From: <werner.keil_at_gmail.com>
Reply-To: <jsr374-experts_at_json-processing-spec.java.net>
Date: Thursday, 4 May 2017 at 20:34
To: Bill Shannon <bill.shannon_at_oracle.com>, "users_at_javaee-spec.java.net" <users_at_javaee-spec.java.net>, "users_at_jpa-spec.java.net" <users_at_jpa-spec.java.net>
Cc: "jsr374-experts_at_json-processing-spec.java.net" <jsr374-experts_at_json-processing-spec.java.net>, "pmo_at_jcp.org" <pmo_at_jcp.org>, Linda DeMichiel <linda.demichiel_at_oracle.com>
Subject: [jsr374-experts] Re: JPA_SPEC-145, JPA_SPEC-146: Provide supportforJDK9 module system
Just an example, so far all JSRs are supposed to use „java“, while some internal parts of the JDK have a „jdk“ module prefix, so just something it might change to. It does not matter what it changes to, the Change as such will certainly make it harder to upgrade from Java EE 8 to 9 ;-/
Sent from Mail for Windows 10
From: Bill Shannon
Sent: Thursday, May 4, 2017 20:30
To: werner.keil_at_gmail.com; users_at_javaee-spec.java.net; users_at_jpa-spec.java.net
Cc: jsr374-experts_at_json-processing-spec.java.net; pmo_at_jcp.org; Linda DeMichiel
Subject: Re: [jsr374-experts] Re: JPA_SPEC-145, JPA_SPEC-146: Provide supportforJDK9 module system
What's this JEE you're talking about?
Yes, all module names.
werner.keil_at_gmail.com wrote on 05/04/2017 11:15 AM:
All module names even those by individual modules like the ones Dmitry or Lukas defined for JSR 374?!!
That would be rather inconsistent and annoying. Some artifactIds of JSRs like Servlet etc. also changed to contain the „javax.servlet“ string or similar, but if 374 or any other Java EE JSR called their module „java.json“ right now, and was forced to rename it to say „jee.json“ later, it would make it difficult for modules consuming it.
If only the Umbrella JEE module had any given Name and respected individual modules following the current JCP Guideline, that’s something else, I would not see much of a Problem with that.
Sent from Mail for Windows 10
From: Bill Shannon
Sent: Thursday, May 4, 2017 20:04
To: users_at_javaee-spec.java.net; users_at_jpa-spec.java.net
Cc: jsr374-experts_at_json-processing-spec.java.net; pmo_at_jcp.org; Linda DeMichiel
Subject: [jsr374-experts] Re: JPA_SPEC-145, JPA_SPEC-146: Provide support forJDK9 module system
I agree, and that's what I've told our team.
None of our Java EE 8 specs should reference SE 9 modules.
On the other hand, if the reference implementations accommodate SE 9 modules, I'm fine with that. But the module names won't be a JCP standard and thus would be subject to change when defined by a future standard.
Kevin Sutter wrote on 05/03/2017 02:24 PM:
We should not be incorporating Java SE 9 module definitions into individual Java EE specifications without the proper guidance from the Java EE Platform. We have to be consistent with this effort. I know some of the older Java EE specs that have been incorporated into Java SE have been defining MRs with the required Java SE 9 updates. But, since Java EE 8 only requires Java SE 8, we should not be defining Java SE 9 module info in these "child" specifications. This should be a platform requirement that filters down to the child specs.
---------------------------------------------------
Kevin Sutter
STSM, Java EE and Java Persistence API (JPA) architect
e-mail: sutter_at_us.ibm.com Twitter: @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)
LinkedIn:
https://www.linkedin.com/in/kevinwsutter
From: Lukas Jungmann <lukas.jungmann_at_oracle.com>
To: users_at_jpa-spec.java.net
Cc: jsr374-experts_at_json-processing-spec.java.net, pmo_at_jcp.org, users_at_javaee-spec.java.net
Date: 05/03/2017 03:28 PM
Subject: [jpa-spec users] Re: [jsr374-experts] Re: JPA_SPEC-145, JPA_SPEC-146: Provide support for JDK9 module system
[forgot to cc others in my original reply]
--lukas
On 5/3/17 9:24 PM, Werner Keil wrote:
Lukas,
Thanks a lot for the pointer especially the JEP and its mention of a standard namespace for all JCP defined artifacts. That'll help.
Regards,
Werner
On Wed, May 3, 2017 at 7:09 PM, Lukas Jungmann <lukas.jungmann_at_oracle.com> wrote:
Hi Werner,
On 5/3/17 6:24 PM, Werner Keil wrote:
Lukas,
Thanks for bringing that up.
I was wondering, if there is a common pattern all (Java EE) JSRs are supposed to follow for making the JSRs Java 9/Jigsaw compatible?
JSON-B
https://github.com/javaee/jsonb-spec/blob/master/api/src/main/java/module-info.java
and JSON-P
https://github.com/javaee/jsonp/blob/master/api/src/main/jdk9/module-info.java
already got a module-info (at least for JSR 374 it was also you who created or last changed it;-)
right, I was the one who created it for JSON-P and suggested JSON-B to use it as well. The idea behind it was that JSON-B is fresh new, simple API targeted to Java SE 8+ and with JDK 9 release coming it made sense to me to try to align JSON-B with it (...so MR won't be needed later just because of JDK9). JSON-P was kind of consequence of this since JSON-B depends on JSON-P...
Unfortunately I don't think there's common pattern to make JSRs Java 9 compatible except of those being part of JDK 9 (eg. JSR-67 (SAAJ), JSR-222 (JAXB) and JSR-224 (JAX-WS) on which I've been working on as well)
As for this spec/JPA 2.2 MR - I'm not strictly against not defining module name (and I'd actually prefer to define it as soon as provider-agnostic JPA API artifact becomes available) but since there is currently no provider-agnostic JPA API artifact, it does not make much sense to me at this point.
Based on module naming by the JDK itself, should we take
"java.<something>" as a module name to be the preferred name for both the JDK and all JSRs under jcp.org?
Or are there other preferences e.g. "javax.<something>" to match the Maven GroupId of most Java EE JSRs especially those by Oracle?
see
https://github.com/javaee/jsonp/blob/master/api/pom.xmlfor JSR 374.
A former EG Member of JSR 363 also asked this in our list and we discussed what would be a good module name there, but wanted to wait for official JCP guidance if possible.
the only official naming convention I'm aware of is defined by
http://openjdk.java.net/jeps/200which states that:
1. Standard modules, whose specifications are governed by the JCP, must have names starting with the string "java.".
...that should answer your question ;-)
Thanks,
--lukas
Thanks and Regards,
Werner
On Wed, May 3, 2017 at 6:13 PM, Lukas Jungmann <lukas.jungmann_at_oracle.com> wrote:
Hi,
Since the release of JDK 9 is behind the corner, it would be good to update the spec to be ready for it.
I can see 2 things which can be done:
1) JPA_SPEC-145: define module name
I'm not 100% sure this needs to be done but for the sake of completeness - it is clear that the module name should be 'java.persistence'. While it would be nice to have the name defined and available, do we really need this or should we stick with API being resolved on JDK9 as an automatic module?
I'm proposing to NOT touch this area in the spec now and keep this up to the provider. Any opinions?
2) JPA_SPEC-146: Use ServiceLoader facility
with the introduction of the module system there are currently 2 ways, how persistence provider implementation can be defined - META-INF/services and module-info with 'provides ... with...'. Former way is already covered but the latter is not, so I'd like to propose following change to Section 9.2 of the spec (additions are in italics, removals are striked-through italics)
Section 9.2 Bootstrapping in Java SE Environments
In Java SE environments, the Persistence.createEntityManagerFactory method is used
by the application to create an entity manager factory.
A persistence provider implementation running in a Java SE environment should also act as a service
provider by supplying a service provider configuration file as described in the JAR File Specification. The Persistence
bootstrap class should use ServiceLoader facility to locate all available provider implementations.
The provider configuration file serves to export the provider implementation class to the Persistence
bootstrap class, positioning the provider as a candidate for backing named persistence units.
The provider may supply the provider configuration file by creating a text file named javax.persistence.spi.PersistenceProvider
and placing it in the META-INF/services directory of
one of its JAR files. The contents of the file should be the name of the provider implementation class of
the javax.persistence.spi.PersistenceProvider interface.
Example 1:
A persistence vendor called ACME persistence products ships a JAR called acme.jar that contains
its persistence provider implementation. The JAR includes the provider configuration file.
acme.jar
META-INF/services/javax.persistence.spi.PersistenceProvider
com.acme.PersistenceProvider
…
The contents of the META-INF/services/javax.persistence.spi.PersistenceProvider
file is nothing more than the name of the implementation class: com.acme.PersistenceProvider.
Example 2:
A persistence vendor called ACME persistence products ships a module called acme.jar that provides persistence provider implementation. The JAR contains module definition which contains the name of the implementation class.
acme.jar
module-info.class
…
module acme {
provides javax.persistence.spi.PersistenceProvider with com.acme.PersistenceProvider;
…
}
The source code of the provider's module definition must contain the name of the provider’s implementation class.
Persistence provider jars may be installed or made available in the same ways as other service providers,
e.g. as extensions, or added to the application classpath according to the guidelines in the JAR File
Specification or added to the application module path according to the guidelines in the Java Platform Module System specification.
Do you think this is fine, something should be corrected or is there a reason why this second part should not be added to JPA 2.2 MR?
Thank you,
--lukas
[1]:
https://java.net/jira/browse/JPA_SPEC-145
[2]:
https://java.net/jira/browse/JPA_SPEC-146