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>
>>
>>
>>
>>
>>
>>
>>
>>
>