Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakartaee-platform-dev] JPMS requirements discussion


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.

  • Suggestion 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


On Wed, Jun 9, 2021 at 12:48 AM Jason Greene <jason.greene@xxxxxxxxxx> wrote:

On Jun 8, 2021, at 1:49 PM, Scott Stark <starksm64@xxxxxxxxx> wrote:

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. 

On Jun 8, 2021 at 1:19:36 PM, Jason Greene <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
To unsubscribe from this list, visit
jakartaee-platform-dev mailing list
To unsubscribe from this list, visit


Ivar Grimstad

Jakarta EE Developer Advocate | Eclipse Foundation Eclipse Foundation - Community. Code. Collaboration. 

Back to the top