users@javaee-spec.java.net

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

From: Lukas Jungmann <lukas.jungmann_at_oracle.com>
Date: Wed, 3 May 2017 22:27:44 +0200

[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
>> <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
>> <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
>> <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
> <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
>> <https://java.net/jira/browse/JPA_SPEC-145>
>> [2]: https://java.net/jira/browse/JPA_SPEC-146
>> <https://java.net/jira/browse/JPA_SPEC-146>
>>
>>
>
>