+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. 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).
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…).
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…)
unsubscribe from this list, visit https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev__;!!ACWV5N9M2RV99hQ!emzQVniyEBp1wLIu0qbAcdyMGEejwOgiP3Q2G4YA5mqXwzBoW5PtVOCYhtkWbYAm-g$
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“ (see https://dzone.com/articles/explicitly-naming-automatic-java-modules)
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 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?
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.
for EE 10
individual spec provides a module info following a specified set of conventions:
module name is jakarta.<specName>
provides JPMS module definition (reliance on automatic module name is not allowed)
updates provider lookup algorithm to include search on module-path (if applicable)
will not provide a platform/profile level module for EE 10
want to set the expectation that implementations must support JPMS at this point
can still experiment with their own aggregator modules
So, as far as I know, there still is this jlink issue with automatic modules:
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.
> > 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.
requires java.base mandated
provides blah.MyService with blah.FooService
unzip -l 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.
Jakarta EE Developer Advocate | Eclipse
Foundation - Community. Code. Collaboration.