Should the Java 9 module system be adopted in Java EE 9, would we assign
standard module names?
I assume the answer is "yes", but feel better asking explicitly.
It wouldn't be fun but would seem fundamentally necessary.
-David
On Thu, May 4, 2017 at 2:02 PM, Werner Keil <werner.keil_at_gmail.com> wrote:
> So is the purpose of https://github.com/javaee/jsonp/tree/master/api/src/
> main/jdk9 and the related build profiles that it allows vendors and users
> of JSR 374 to build a Java 9 compliant version of the API for themselves
> while the official JSR 374 JARs won't contain it until a later point?
>
> We offer similar profiles for small parts of JSR 363 but so far we also
> did not publish the smaller JARs to MavenCentral. Their main purpose is for
> very small devices, e.g. Java ME Embedded. So vendors can build a smaller
> JAR that's compliant with certain profiles.
>
> Do the JDK 9 profiles in at least the JSON JSRs have a similar goal?
>
>
> On Thu, May 4, 2017 at 10:47 PM, Bill Shannon <bill.shannon_at_oracle.com>
> wrote:
>
>> The spec, *including** javadocs*, for these Java EE 8 APIs should not
>> mention SE 9 modules.
>>
>> A vendor's implementation might support SE 9 modules, and might include
>> that information in the vendor-specific documentation.
>>
>>
>> Werner Keil wrote on 05/04/2017 01:25 PM:
>>
>> Dmitry,
>>
>> Nobody proposes to refer to modules in the spec (the written document
>> where a JSR comes with it)
>> A module definition like https://github.com/javaee
>> /jsonb-spec/blob/master/api/src/main/java/module-info.java exposes the
>> API, not RI, or are you saying you'd rather remove that on the API level
>> for now?
>>
>> This file even shows the inter-dependency between JSON-B and JSON-P,
>> there are certainly other cases like JSP or JSF using Servlet, etc. If an
>> application also uses either of these modules and the module changes with
>> EE 9 or a MR to the EE 8 content, it forces a change to that application.
>>
>> On the other hand, what we see around Java 9 including a hard time to
>> even approve Jigsaw without some improvement and fixes, it still is going
>> to be a great challenge to existing applications running Java 6, 7 or 8, so
>> a changed module name is probably not the biggest barrier to use Java SE or
>> EE 9 here ;-)
>>
>> Regards,
>> Werner
>>
>>
>> On Thu, May 4, 2017 at 9:57 PM, Dmitry Kornilov <
>> dmitry.kornilov_at_oracle.com> wrote:
>>
>>> Werner, I don’t understand what are you proposing. Bill made a clear
>>> statement that modules must not be a part of specs. I agree with it. If
>>> module is defined in an RI it doesn’t affect Java EE 8 at all because it’s
>>> Java 8 based. On the other hand, some implementation, like JSON-P or Yasson
>>> are designed to work in Java SE environment as well. It makes sense making
>>> them JDK9 compatible. We follow naming convention proposed by Java team
>>> (see email from Lukas below). If future versions of Java EE define
>>> different module name convention, we will rename the modules.
>>>
>>>
>>>
>>> Thanks,
>>>
>>> Dmitry
>>>
>>>
>>>
>>> *From: *<werner.keil_at_gmail.com>
>>> *Reply-To: *<jsr374-experts_at_json-processing-spec.java.net>
>>> *Date: *Thursday, 4 May 2017 at 20:34
>>> *To: *Bill Shannon <bill.shannon_at_oracle.com>, "
>>> users_at_javaee-spec.java.net" <users_at_javaee-spec.java.net>, "
>>> 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>, Linda DeMichiel <linda.demichiel_at_oracle.com>
>>>
>>> *Subject: *[jsr374-experts] Re: JPA_SPEC-145, JPA_SPEC-146: Provide
>>> supportforJDK9 module system
>>>
>>>
>>>
>>> Just an example, so far all JSRs are supposed to use „java“, while some
>>> internal parts of the JDK have a „jdk“ module prefix, so just something it
>>> might change to. It does not matter what it changes to, the Change as such
>>> will certainly make it harder to upgrade from Java EE 8 to 9 ;-/
>>>
>>>
>>>
>>> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for
>>> Windows 10
>>>
>>>
>>>
>>> *From: *Bill Shannon <bill.shannon_at_oracle.com>
>>> *Sent: *Thursday, May 4, 2017 20:30
>>> *To: *werner.keil_at_gmail.com; users_at_javaee-spec.java.net;
>>> users_at_jpa-spec.java.net
>>> *Cc: *jsr374-experts_at_json-processing-spec.java.net; pmo_at_jcp.org; Linda
>>> DeMichiel <linda.demichiel_at_oracle.com>
>>> *Subject: *Re: [jsr374-experts] Re: JPA_SPEC-145, JPA_SPEC-146: Provide
>>> supportforJDK9 module system
>>>
>>>
>>>
>>> What's this JEE you're talking about?
>>> <https://javaee.github.io/javaee-spec/JEE>
>>>
>>> Yes, all module names.
>>>
>>> werner.keil_at_gmail.com wrote on 05/04/2017 11:15 AM:
>>>
>>> All module names even those by individual modules like the ones Dmitry
>>> or Lukas defined for JSR 374?!!
>>>
>>>
>>>
>>> That would be rather inconsistent and annoying. Some artifactIds of JSRs
>>> like Servlet etc. also changed to contain the „javax.servlet“ string or
>>> similar, but if 374 or any other Java EE JSR called their module
>>> „java.json“ right now, and was forced to rename it to say „jee.json“ later,
>>> it would make it difficult for modules consuming it.
>>>
>>>
>>>
>>> If only the Umbrella JEE module had any given Name and respected
>>> individual modules following the current JCP Guideline, that’s something
>>> else, I would not see much of a Problem with that.
>>>
>>>
>>>
>>> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for
>>> Windows 10
>>>
>>>
>>>
>>> *From: *Bill Shannon <bill.shannon_at_oracle.com>
>>> *Sent: *Thursday, May 4, 2017 20:04
>>> *To: *users_at_javaee-spec.java.net; users_at_jpa-spec.java.net
>>> *Cc: *jsr374-experts_at_json-processing-spec.java.net; pmo_at_jcp.org; Linda
>>> DeMichiel <linda.demichiel_at_oracle.com>
>>> *Subject: *[jsr374-experts] Re: JPA_SPEC-145, JPA_SPEC-146: Provide
>>> support forJDK9 module system
>>>
>>>
>>>
>>> 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 <(507)%20253-3620> (office)
>>>
>>> LinkedIn: 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
>>> 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
>>>
>>> [image: id:image001.png_at_01D2C513.38F97A10]
>>>
>>>
>>>
>>>
>>> [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> 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/m
>>> ain/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?
>>>
>>> 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.xmlfor 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/200which 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> 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.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
>>> [2]: https://java.net/jira/browse/JPA_SPEC-146
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>