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