[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [jakartaee-platform-dev] [External] : Re: JPMS requirements discussion
|
On 6/30/21 1:28 AM, Tomas Langer wrote:
+1 on Werner’s message.
In general Jakarta APIs do not depend on third party modules, so there
is no need to “modularise” transitive dependencies.
You're right that Jakarta APIs do not depend on 3rd party modules. OTOH
some Jakarta APIs, such as XML Binding or Expression Language (and
everything depending on them), currently depend on java.desktop and I
think dependency on this is not wanted by the Platform - at least that
is something I really prefer not to see. There might be other "hidden"
dependencies the Platform does not need or want, like ie
java.instrument. It is fine for CIs to depend on these modules if they
need to but for the APIs, it seems to me to be wrong. (for example Mail
till version 2 used forked Activation with dropped dependency on
java.desktop to allow its own usage on Android)
And lack of module
info is complicated for runtimes (such as Helidon) where we need to do
some hard magic to generate a JLink image based on “guessed” module
names (or automatic module names from manifests).
For EE 10:
At the individual spec included by the platform level, module info is
suggested to be required.
At the platform/profile level, module info is suggested to NOT be added
to avoid expectations that Platform CIs (aka application servers) do
fully support JPMS - CIs do depend on 3rd party libraries which may need
to be modularized first
this does not prohibit runtimes to define their own, implementation
specific, "aggregating" modules for particular profiles, say
"helidon.jakarta.core", "helidon.jakarta.full", etc. It's more about
getting time to gather feedback from these runtimes in order to make
things right at the platform/profile level.
Note that adding a requirement also means adding corresponding TCK tests
and that can easily become the most time-consuming part of the work.
Regarding service providers - the “uses” keyword is easy, as that works
both in JPMS and on classpath. Problem is with “provides” keyword - if
there is any spec that actually provides service implementations, it
must be defined twice - once in module-info for JPMS and once in
META-INF/services for classpath (this is an unfortunate feature that is
missing from Java - would be great if it would use module-info.java if
present…).
Another problem can be that some spec API jars may have not been updated
to use ServiceLoader to look up the implementation, so in some cases
simple addition of "uses" may not be enough. Ie Persistence was updated
to use ServiceLoader in Java EE 8, till then, custom reader of entries
in META-INF/services was used; XML Binding supports ServiceLoader for
longer time but still allows "customized" lookup through
META-INF/services which is not compliant with ServiceLoader. That is
what I've seen in specs I work on. There are also specs which are out of
my radar, so I don't know if or how much is the customized reading of
META-INF/services spread across other specs included by the platform.
If there is a need, I think we can provide a lot of experience with JPMS
from Helidon where we have to merge together modularised libraries,
automatic module libraries and libraries that just ignore JPMS.
And I would really like if any new library would provide
module-info.java. One important note on this - it is really important
the module-info.java is correct, as there is no workaround for a wrong
module-info (such as if a library is declared as requires instead of
requires static, you enforce it on any user using your library…)
The goal for EE 10 is suggested to be to prepare bricks for 3rd party
libraries, runtimes and the platform and let EE 10.Next(.Next?) just use
them. This should give everyone enough time to make things right.
thanks,
--lukas
Tomas
On 29 Jun 2021, at 21:23, Werner Keil <werner.keil@xxxxxxx
<mailto:werner.keil@xxxxxxx>> wrote:
Hi,
About the exact phrase of „reliance on automatic module name is not
allowed“ I guess that means every module even those that have defined
at least an „automatic-module-name“ in the MANIFEST must convert to a
„module-info“ or should it say something like „spec provides explixit
JPMS module Definition“
(seehttps://dzone.com/articles/explicitly-naming-automatic-java-modules <https://urldefense.com/v3/__https://dzone.com/articles/explicitly-naming-automatic-java-modules__;!!ACWV5N9M2RV99hQ!emzQVniyEBp1wLIu0qbAcdyMGEejwOgiP3Q2G4YA5mqXwzBoW5PtVOCYhtk46N7DVg$>)
?
If EE 10 is not willing to declare a platform Level module yet I guess
that is acceptable for some time, but sooner instead of later we
should also offer something like „java.se
<https://urldefense.com/v3/__http://java.se/__;!!ACWV5N9M2RV99hQ!flXC2f3etxdjmeBVC82smq70_CDkbnnTEp0WAfDL_K4gJt6nTVi4M2qxT9AEhdT1sWI$>“
in the JDK
(https://docs.oracle.com/en/java/javase/16/docs/api/java.se/module-summary.html
<https://docs.oracle.com/en/java/javase/16/docs/api/java.se/module-summary.html>)
preferably in JARs
likehttps://search.maven.org/artifact/jakarta.platform/jakarta.jakartaee-api
<https://urldefense.com/v3/__https://search.maven.org/artifact/jakarta.platform/jakarta.jakartaee-api__;!!ACWV5N9M2RV99hQ!emzQVniyEBp1wLIu0qbAcdyMGEejwOgiP3Q2G4YA5mqXwzBoW5PtVOCYhtkRCGbfIQ$>orhttps://search.maven.org/artifact/jakarta.platform/jakarta.jakartaee-web-api
<https://urldefense.com/v3/__https://search.maven.org/artifact/jakarta.platform/jakarta.jakartaee-web-api__;!!ACWV5N9M2RV99hQ!emzQVniyEBp1wLIu0qbAcdyMGEejwOgiP3Q2G4YA5mqXwzBoW5PtVOCYhtmShsZ1QQ$>.
Adding these in 10.1 or beyond sounds doable, if the pressure on
implementors to use JPMS really should be lowered that way, but IMO if
you don’t adopt JPMS in your application by not putting a module-info
there, it would not create harm or pressure on those apps, and it
would create sanity and consistency if done in the official JARs.
We see what happens otherwise with MicroProfile which has ignored and
refused JPMS anywhere in ist API.
So some projects like Helidon do this on their own,
seehttps://github.com/oracle/helidon/blob/master/config/config-mp/src/main/java/module-info.java
<https://urldefense.com/v3/__https://github.com/oracle/helidon/blob/master/config/config-mp/src/main/java/module-info.java__;!!ACWV5N9M2RV99hQ!emzQVniyEBp1wLIu0qbAcdyMGEejwOgiP3Q2G4YA5mqXwzBoW5PtVOCYhtk-4kkS2Q$>,
with an „assumed“ module Name for MP-Config of
"microprofile.config.api",but nobody can predict or prevent MP from
using a different namespace like
"org.eclipse.microprofile.config" which would match the artifactId and
package like Helidon itself does.
So it creates a Proliferation and Fragmentation and even adds a bit of
Vendor-dependency with those modules Jakarta EE tries to avoid, hence
it would be better to define those in the Jakarta Platform API JARs as
soon as everyone was happy to do so.
Especially for the Core Profile why introduce that and not start with
a module definition right from the beginning?
Werner
*Von:*Ivar Grimstad <mailto:ivar.grimstad@xxxxxxxxxxxxxxxxxxxxxx>
*Gesendet:*Dienstag, 29. Juni 2021 18:59
*An:*jakartaee-platform developer discussions
<mailto:jakartaee-platform-dev@xxxxxxxxxxx>
*Betreff:*Re: [jakartaee-platform-dev] JPMS requirements discussion
Hi,
This topic was discussed on the Platform Call today. The following
suggestion was the result of this discussion. Please comment here on
the thread, and maybe we can reach a decision on the call next week.
oSuggestion for EE 10
*§**Each individual spec provides a module info following a specified
set of conventions:*
·spec module name is jakarta.<specName>
·spec provides JPMS module definition (reliance on automatic module
name is not allowed)
·spec updates provider lookup algorithm to include search on
module-path (if applicable)
*§**We will not provide a platform/profile level module for EE 10*
·Don’t want to set the expectation that implementations must support
JPMS at this point
·Implementations can still experiment with their own aggregator modules
Ivar
On Wed, Jun 9, 2021 at 12:48 AM Jason Greene <jason.greene@xxxxxxxxxx
<mailto:jason.greene@xxxxxxxxxx>> wrote:
On Jun 8, 2021, at 1:49 PM, Scott Stark <starksm64@xxxxxxxxx
<mailto:starksm64@xxxxxxxxx>> wrote:
So, as far as I know, there still is this jlink issue with
automatic modules:
https://bugs.openjdk.java.net/browse/JDK-8130047
<https://bugs.openjdk.java.net/browse/JDK-8130047>
So the reality of a spec api jar is that it is pretty much an
open module with its dependencies explicit. Is this jlink
issue the only limitation of providing module support via the
automatic-module manifest entry? If it is, the requirement for
module support still could be an implementation detail of the
spec project.
Yeah this is a good point. You would basically be forced to
generate descriptors for everything to make this work including
thirdparty libs which aren’t modular. Not sure how important out
of the box jlink support is to implementors.
On Jun 8, 2021 at 1:19:36 PM, Jason Greene
<jason.greene@xxxxxxxxxx <mailto:jason.greene@xxxxxxxxxx>> wrote:
...
> >
> > This is not technically true. A jar that is a named
auto-module
> > (manifest) is certainly usable in a JPMS environment.
I would argue the
> > more sensible permission mappings make it
significantly more usable.
>
> Is the Manifest entry sufficient if the JAR provides a
service via the
> ServiceLoader or depends on such a service? My
understanding was that
> the manifest approach is not sufficient in that instance
and a
> module-info.class is required.
Yes, an automatic module can publish and consume services.
(E.g:)
jar -d --file blah.jar
No module descriptor found. Derived automatic module.
blah automatic
requires java.base mandated
provides blah.MyService with blah.FooService
contains blah
unzip -l blah.jar
Archive: blah.jar
Length Date Time Name
--------- ---------- ----- ----
0 06-08-2021 12:19 META-INF/
28 06-08-2021 12:19 META-INF/MANIFEST.MF
0 06-08-2021 11:50 META-INF/services/
16 06-08-2021 11:50 META-INF/services/blah.MyService
0 06-08-2021 11:53 blah/
143 06-08-2021 11:56 blah/MyService.class
310 06-08-2021 11:56 blah/FooService.class
>
> There may be other JPMS required metadata that can only
be provided via
> module-info.class - the ServiceLoader case is just the
one I have come
> across in the specs I work with.
>
> My expectation is that most API JARs will need to
provide more metadata
> than just an automatic module name in the manifest. If
that is not the
> case then the argument for all API JARs being required
to provide a
> module-info.class may not be as strong as I thought it
was. That said,
> my preference would still be to provide
module-info.class files.
The biggest difference would be the ability to affect
exports. Although, in exchange for significantly reduced
visibility and added dependency management complexity. The
export restrictions are insufficient to be an access
control mechanism, so really more of a warning. If you
have an API/impl split as is the case of spec +
multi-vender then its applicability is pretty limited.
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
<mailto:jakartaee-platform-dev@xxxxxxxxxxx>
To unsubscribe from this list,
visithttps://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
<https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev__;!!ACWV5N9M2RV99hQ!emzQVniyEBp1wLIu0qbAcdyMGEejwOgiP3Q2G4YA5mqXwzBoW5PtVOCYhtkWbYAm-g$>
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
<mailto:jakartaee-platform-dev@xxxxxxxxxxx>
To unsubscribe from this list,
visithttps://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
<https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev__;!!ACWV5N9M2RV99hQ!emzQVniyEBp1wLIu0qbAcdyMGEejwOgiP3Q2G4YA5mqXwzBoW5PtVOCYhtkWbYAm-g$>
--
*Ivar Grimstad*
*Jakarta EE Developer Advocate |**Eclipse Foundation*/Eclipse
Foundation/
<https://urldefense.com/v3/__https://www.eclipse.org/__;!!ACWV5N9M2RV99hQ!emzQVniyEBp1wLIu0qbAcdyMGEejwOgiP3Q2G4YA5mqXwzBoW5PtVOCYhtl-0oOJ1A$>/-
Community. Code. Collaboration. /
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
<mailto:jakartaee-platform-dev@xxxxxxxxxxx>
To unsubscribe from this list,
visithttps://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev__;!!ACWV5N9M2RV99hQ!emzQVniyEBp1wLIu0qbAcdyMGEejwOgiP3Q2G4YA5mqXwzBoW5PtVOCYhtkWbYAm-g$
<https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev__;!!ACWV5N9M2RV99hQ!emzQVniyEBp1wLIu0qbAcdyMGEejwOgiP3Q2G4YA5mqXwzBoW5PtVOCYhtkWbYAm-g$>
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev__;!!ACWV5N9M2RV99hQ!flXC2f3etxdjmeBVC82smq70_CDkbnnTEp0WAfDL_K4gJt6nTVi4M2qxT9AEvtpm5CE$