users@javaee-spec.java.net

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

From: Werner Keil <werner.keil_at_gmail.com>
Date: Thu, 4 May 2017 09:48:44 +0200

Indeed, the Umbrella (where necessary with help of the PMO) should try to
ensure all the individual modules are available and should any of them do
something "weird" (e.g. call a module totally different) request they
change it.
There are a number of "No" votes, I know, and being a significant change to
the Java language, it must pass with a 2/3 "Supermajority", kind of like
some votes in US parlament or elsewhere ;-)

Seems we won't run out of topics next week in Texas...

Werner


On Thu, May 4, 2017 at 9:32 AM, Ondrej Mihályi <ondrej.mihalyi_at_gmail.com>
wrote:

> I suggest that the umbrella specification should address Java SE 9
> modules, although I'm not sure whether there's enough time to do it and
> even whether modules will be part of Java 9 because of the No votes in the
> JCP. This is the first time when a new Java EE version is going to be
> released just couple of months or even weeks before the next major Java
> version, therefore for many Java EE 8 users Java 9 will be already
> available. Even Java EE 8 was released almost whole year before Java 8, and
> Java 8 was not so disruptive as Java 9 with modules is going to be,
> therefore we should also look into the future.
>
> I think it's important that the Java EE umbrella specification is leading
> in cross-cutting concerns like support for modules, classloading, common
> naming patterns, otherwise, the platform is too fragmented and more like a
> collection of individual specifications than an integrated platform. Java
> EE platform is already fragmented and this doesn't help in keeping it
> relevant. Maybe we shouldn't forbid individual JSRs to define support for
> modules, but the umbrella Java EE should be leading and define common
> guidelines ASAP.
>
> Ondrej
>
> 2017-05-04 3:02 GMT+02:00 Kevin Sutter <sutter_at_us.ibm.com>:
>
>> Thanks, Werner. I'm not necessarily advocating that we have to wait for
>> Java EE 9 to support Java SE 9 modules. But, we do need the Java EE
>> Platform spec to declare support due to it's rippling effect. Maybe it's
>> an MR for Java EE 8 sometime down the road, since I doubt we have time to
>> incorporate this into all of Java EE 8 at this point in time. I just don't
>> think we should allow individual specs to define Java SE 9 module support
>> without the complete platform.
>>
>> ---------------------------------------------------
>> 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: Werner Keil <werner.keil_at_gmail.com>
>> To: jsr374-experts_at_json-processing-spec.java.net
>> Cc: users_at_jpa-spec.java.net, "pmo_at_jcp.org" <pmo_at_jcp.org>,
>> users_at_javaee-spec.java.net, Linda DeMichiel <linda.demichiel_at_oracle.com>
>> Date: 05/03/2017 05:29 PM
>> Subject: [jpa-spec users] Re: [jsr374-experts] Re: Re: Re:
>> JPA_SPEC-145, JPA_SPEC-146: Provide support for JDK9 module system
>> ------------------------------
>>
>>
>>
>> Kevin,
>>
>> You are right, that Java EE 8 as such will have Java SE 8 as a minimum
>> requirement, but we see a growing number of Java EE 7 containers and
>> projects also switch to Java SE 8 now despite EE 7 was originally based on
>> JDK 7.
>>
>> It is safe to assume, something similar happens over time with Java EE 8
>> used on SE 9. So although Java EE 8 won't support "custom profiles" or some
>> kind of "Micro Profile" (as the Eclipse project with the same name) it
>> seems beneficial to offer the module-info before Java EE 9. From what we
>> know about Jigsaw its Auto-Module feature would kick in and result in
>> modules like "javax.servlet-api" for Servlet etc. Different from the
>> intended module names. There are several "javax" packages in JDK 9 itself
>> that were renamed on purpose, e.g. "javax.swing" to "java.swing" or
>> similar.
>>
>> The statement
>> >Standard modules, whose specifications are governed by the JCP, must
>> have names starting with the >string "java.".
>> Is quit clear and refers to all JSRs governed by the JCP, not just the
>> JDK.
>>
>> The Umbrella Java EE JSR and its Spec Leads probably have to make up
>> their minds, because a combined artifact like
>> "javaee-api-7.0.jar" for Java EE 8 in a modular form would rather be a
>> module (by a name like say "*java.ee* <http://java.ee/>") that contains
>> all individual modules like "java.json" assuming they all expose
>> module-info.
>>
>> So it won't work without a coordinated effort, but I am not sure, waiting
>> till EE 9 is a good idea. Unless the final version of Jigsaw offers a
>> different solution than the proposed auto-module.
>>
>> Regards,
>>
>> Werner Keil
>>
>>
>>
>> On Wed, May 3, 2017 at 11:24 PM, Kevin Sutter <*sutter_at_us.ibm.com*
>> <sutter_at_us.ibm.com>> wrote:
>> 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* <sutter_at_us.ibm.com> Twitter: @kwsutter
>> phone: tl-553-3620 (office), 507-253-3620 (office)
>> LinkedIn: *https://www.linkedin.com/in/kevinwsutter*
>> <https://www.linkedin.com/in/kevinwsutter>
>>
>>
>>
>> From: Lukas Jungmann <*lukas.jungmann_at_oracle.com*
>> <lukas.jungmann_at_oracle.com>>
>> To: *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>, *users_at_javaee-spec.java.net* <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* <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* <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 Persistencebootstrap 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.persis
>> tence.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>
>>
>>
>>
>>
>>
>>
>>
>>
>