users@javaee-spec.java.net

[javaee-spec users] Re: [jsr374-experts] Re: JPA_SPEC-145, JPA_SPEC-146: Provide support for JDK9 module system

From: Bill Shannon <bill.shannon_at_oracle.com>
Date: Thu, 4 May 2017 11:04:22 -0700

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_
> <mailto: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_ <http://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.xml_for 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/200_which 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_
> <mailto: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_
>
>
>
>
>
>
>