Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakartaee-platform-dev] [External] : Re: JPMS requirements discussion 
Hi,

On 6/29/21 9:23 PM, Werner Keil 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“ (see https://dzone.com/articles/explicitly-naming-automatic-java-modules <https://urldefense.com/v3/__https://dzone.com/articles/explicitly-naming-automatic-java-modules__;!!ACWV5N9M2RV99hQ!ayoMeBCedwTGFY9tVG_r9Ry5jwMQshBuRRVthdHGGICgEpxY2dpVZrGf6-RPg9BTbfc$>) ?
It should probably be shortened to "reliance on automatic modules is not allowed", so the definition of the term "automatic module" as is defined by JDK can be reused[1]:
"A JAR file with a module-info.class in its top-level directory, or in a versioned entry in a multi-release JAR file, is a modular JAR file and thus defines an explicit module. A JAR file that does not have a module-info.class in its top-level directory defines an automatic module..." 

thanks,
--lukas
[1]: https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/module/ModuleFinder.html#of(java.nio.file.Path...)
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“ 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 like https://search.maven.org/artifact/jakarta.platform/jakarta.jakartaee-api <https://urldefense.com/v3/__https://search.maven.org/artifact/jakarta.platform/jakarta.jakartaee-api__;!!ACWV5N9M2RV99hQ!ayoMeBCedwTGFY9tVG_r9Ry5jwMQshBuRRVthdHGGICgEpxY2dpVZrGf6-RPK9-Wiqo$> or https://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!ayoMeBCedwTGFY9tVG_r9Ry5jwMQshBuRRVthdHGGICgEpxY2dpVZrGf6-RPaFD7ucE$>.
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, see https://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!ayoMeBCedwTGFY9tVG_r9Ry5jwMQshBuRRVthdHGGICgEpxY2dpVZrGf6-RPjsS_u4I$>, 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, visit
        https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
        <https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev__;!!ACWV5N9M2RV99hQ!ayoMeBCedwTGFY9tVG_r9Ry5jwMQshBuRRVthdHGGICgEpxY2dpVZrGf6-RPsxNTWHM$>

    _______________________________________________
    jakartaee-platform-dev mailing list
    jakartaee-platform-dev@xxxxxxxxxxx
    <mailto:jakartaee-platform-dev@xxxxxxxxxxx>
    To unsubscribe from this list, visit
    https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
    <https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev__;!!ACWV5N9M2RV99hQ!ayoMeBCedwTGFY9tVG_r9Ry5jwMQshBuRRVthdHGGICgEpxY2dpVZrGf6-RPsxNTWHM$>


--

*Ivar Grimstad*
*Jakarta EE Developer Advocate | **Eclipse Foundation */Eclipse Foundation/ <https://urldefense.com/v3/__https://www.eclipse.org/__;!!ACWV5N9M2RV99hQ!ayoMeBCedwTGFY9tVG_r9Ry5jwMQshBuRRVthdHGGICgEpxY2dpVZrGf6-RPQFRNh1E$>/- Community. Code. Collaboration. / 


_______________________________________________
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!ayoMeBCedwTGFY9tVG_r9Ry5jwMQshBuRRVthdHGGICgEpxY2dpVZrGf6-RPsxNTWHM$

Back to the top