On Tue, Jun 8, 2021 at 11:05 AM Mark Thomas <
markt@xxxxxxxxxx> wrote:
>
> On 08/06/2021 16:24, Jason Greene wrote:
> >
> >
> > On Jun 8, 2021 at 2:46:27 AM, Mark Thomas <
markt@xxxxxxxxxx> > <mailto:
markt@xxxxxxxxxx>> wrote:
> >
> > On 08/06/2021 04:11, Scott Stark wrote:
> >> The "We need to define the JPMS strategy for EE10 and beyond" issue:
> >>
https://github.com/eclipse-ee4j/jakartaee-platform/issues/329> >> <
https://github.com/eclipse-ee4j/jakartaee-platform/issues/329>
> >> <
https://github.com/eclipse-ee4j/jakartaee-platform/issues/329> >> <
https://github.com/eclipse-ee4j/jakartaee-platform/issues/329>>
> >>
> >> Has a number of comments. My takeaway from the thread is that we
> >> need to
> >> focus on:
> >>
> >> 1. Do we required that specification API jars provide a
> >> module-info.class description?
> >
> > If we want the JARs to be usable in a JPMS environment, which I assume
> > we do, then the answer has to be yes.
> >
> >
> > 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.
