users@javaee-spec.java.net

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

From: Kevin Sutter <sutter_at_us.ibm.com>
Date: Wed, 3 May 2017 20:02:32 -0500

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") 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> 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 Twitter: @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)
LinkedIn: https://www.linkedin.com/in/kevinwsutter



From: Lukas Jungmann <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



[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/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?

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.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
[2]: https://java.net/jira/browse/JPA_SPEC-146