users@jpa-spec.java.net

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

From: Lukas Jungmann <lukas.jungmann_at_oracle.com>
Date: Thu, 4 May 2017 16:47:19 +0200

Hi,


On 5/4/17 1:21 AM, Linda DeMichiel wrote:
> Hi,
>
> Since Java EE 8 only requires Java SE 8, JPA 2.2 shouldn't explicitly
> define anything related to Java SE 9 modules. (I.e., the
> italicized text should not be included in the spec.)

I agree; it's inline with my proposal to 1) (...don't do it now, target
milestone for JPA_SPEC-145 has been changed from 2.2 to TBD)

>
> Also, with regard to the second item below (Section 9.2), it isn't
> clear how the ServiceLoader facility is intended to be used.
> Is this intended as a replacement for the requirements in section 9.3
> (Determining the Available Persistence Providers)?
> Or is it only intended as a replacement for the behavior of the
> default PersistenceProviderResolver in determining the persistence
> providers?
My intention is to replace direct reference to service provider
configuration file and in turn to JAR File specification (and following
paragraph which looks like a slightly modified copy of ServiceLoader
javadoc) in 9.2 with a direct reference to ServiceLoader itself, which,
I think, would make the 'should' statement in " /A persistence provider
implementation running in a Java SE environment should also act as a
service provider/..." a bit more general - not constrained by
availability of
META-INF/services/javax.persistence.spi.PersistenceProvider but
constrained directly with what ServiceLoader defines and expects. So
given SE 8 is a base, it's only wording what I propose to change,
behaviour of what is in 9.2/9.3 should remain the same (... unless I
overlooked something, what can easily happen...).

Does it make more sense now?

Thanks,
--lukas
>
> thanks,
>
> -Linda
>
>
> On 5/3/17, 9:13 AM, Lukas Jungmann 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
>>
>