Yes, my expectation is that we would we define standard module names for the
standard modules in Java EE 9.
David Blevins wrote on 05/05/2017 08:59 PM:
> 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
> <mailto:werner.keil_at_gmail.com>> wrote:
>
> So is the purpose
> of https://github.com/javaee/jsonp/tree/master/api/src/main/jdk9
> <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
> <mailto: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
>> <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 <mailto: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 <mailto:werner.keil_at_gmail.com>>
>> *Reply-To: *<jsr374-experts_at_json-processing-spec.java.net
>> <mailto:jsr374-experts_at_json-processing-spec.java.net>>
>> *Date: *Thursday, 4 May 2017 at 20:34
>> *To: *Bill Shannon <bill.shannon_at_oracle.com
>> <mailto:bill.shannon_at_oracle.com>>, "users_at_javaee-spec.java.net
>> <mailto:users_at_javaee-spec.java.net>" <users_at_javaee-spec.java.net
>> <mailto:users_at_javaee-spec.java.net>>, "users_at_jpa-spec.java.net
>> <mailto:users_at_jpa-spec.java.net>" <users_at_jpa-spec.java.net
>> <mailto:users_at_jpa-spec.java.net>>
>> *Cc: *"jsr374-experts_at_json-processing-spec.java.net
>> <mailto:jsr374-experts_at_json-processing-spec.java.net>"
>> <jsr374-experts_at_json-processing-spec.java.net
>> <mailto:jsr374-experts_at_json-processing-spec.java.net>>,
>> "pmo_at_jcp.org <mailto:pmo_at_jcp.org>" <pmo_at_jcp.org
>> <mailto:pmo_at_jcp.org>>, Linda DeMichiel
>> <linda.demichiel_at_oracle.com <mailto: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 <mailto:bill.shannon_at_oracle.com>
>> *Sent: *Thursday, May 4, 2017 20:30
>> *To: *werner.keil_at_gmail.com <mailto:werner.keil_at_gmail.com>;
>> users_at_javaee-spec.java.net <mailto:users_at_javaee-spec.java.net>;
>> users_at_jpa-spec.java.net <mailto:users_at_jpa-spec.java.net>
>> *Cc: *jsr374-experts_at_json-processing-spec.java.net
>> <mailto:jsr374-experts_at_json-processing-spec.java.net>;
>> pmo_at_jcp.org <mailto:pmo_at_jcp.org>; Linda DeMichiel
>> <mailto: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 <mailto: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 <mailto:bill.shannon_at_oracle.com>
>> *Sent: *Thursday, May 4, 2017 20:04
>> *To: *users_at_javaee-spec.java.net
>> <mailto:users_at_javaee-spec.java.net>; users_at_jpa-spec.java.net
>> <mailto:users_at_jpa-spec.java.net>
>> *Cc: *jsr374-experts_at_json-processing-spec.java.net
>> <mailto:jsr374-experts_at_json-processing-spec.java.net>;
>> pmo_at_jcp.org <mailto:pmo_at_jcp.org>; Linda DeMichiel
>> <mailto: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 <mailto:sutter_at_us.ibm.com>
>> Twitter: @kwsutter
>> phone: tl-553-3620 (office), 507-253-3620
>> <tel:%28507%29%20253-3620> (office)
>> LinkedIn: https://www.linkedin.com/in/kevinwsutter
>> <https://www.linkedin.com/in/kevinwsutter>
>>
>>
>>
>> From: Lukas Jungmann <lukas.jungmann_at_oracle.com>
>> <mailto:lukas.jungmann_at_oracle.com>
>> To: users_at_jpa-spec.java.net
>> <mailto:users_at_jpa-spec.java.net>
>> Cc: jsr374-experts_at_json-processing-spec.java.net
>> <mailto:jsr374-experts_at_json-processing-spec.java.net>,
>> pmo_at_jcp.org <mailto:pmo_at_jcp.org>,
>> users_at_javaee-spec.java.net
>> <mailto: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
>>
>> 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
>> <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>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
>
>