Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakartaee-platform-dev] Re: JPMS Module Info classes
Why would the module info make anything less stable?

If your app does not declare one you don't need to bother, but it makes usage of the official Jakarta EE APIs as opposed to internal or vendor specific packages much better to control.

Had a proper JPMS be available sooner, the whole "sun.misc.unsafe" and other problems could have been avoided much sooner.

--
Diese Nachricht wurde von meinem Android Mobiltelefon mit GMX Mail gesendet.
Am 30.08.23, 04:55 schrieb Romain Manni-Bucau via jakartaee-platform-dev <jakartaee-platform-dev@xxxxxxxxxxx>:
Hi,

Technically if JPMS is a vendor responsability it would be neat to say JPMS must not be in jars cause it impacts the way apps are developped if used and if unstable it will impact end users negatively - it is not like maven coordinates which are transparent to code.

Romain Manni-Bucau
@rmannibucau |  Blog | Old Blog | Github | LinkedIn | Book


Le mer. 30 août 2023 à 02:19, David Blevins via jakartaee-platform-dev <jakartaee-platform-dev@xxxxxxxxxxx> a écrit :
As long as we're all on the same page about that, great.  Note on that front, we need to avoid saying in specifications that these are features of the spec:


Any spec that refers to the Maven coordinates, module-infos, etc as a feature of the spec should be removed.  Spec jars are the responsibility of the implementation and we should avoid referring to one set of them as the one-true version and we should avoid referring to their non-portable features as features of the spec.

We should remove that section of the CDI spec and replace it with language like we added to the EE 10 spec.

-- 
David Blevins


On Aug 29, 2023, at 2:27 PM, Scott Stark <starksm64@xxxxxxxxx> wrote:

The requirements are the same as EE 10 in that one should be provided with the indicated naming pattern. The content is unspecified and there are no TCK tests for modules is the status quo for EE 11.

On Mon, Aug 28, 2023 at 9:58 PM David Blevins via jakartaee-platform-dev <jakartaee-platform-dev@xxxxxxxxxxx> wrote:
"It is desired to firm up these suggestions into requirements. Several discussions via Issues, Mailing Lists, and the Platform call have resulted in these requirements for Jakarta EE 11."

 - https://jakartaee.github.io/jakartaee-platform/jakartaee11/JakartaEE11ReleasePlan

The last agreement I recall is that the module-infos are there for convenience and are not standard or requirements of the specification:

 - https://github.com/jakartaee/jakartaee-platform/issues/425
 - https://www.eclipse.org/lists/jakartaee-platform-dev/msg02906.html

We have this in section 13.3 of the EE 10 specification:

    "The contents of module-info.class files are not standard,
    portable, may change without notice and there is no requirement
    around testing of JPMS in API jar signature tests or TCKs. Vendors
    are free to create their own API jars that pass the signature
    tests, but include no JPMS module-info.class files or JPMS
    module-info.class files with different or conflicting contents."


--
David Blevins
http://twitter.com/dblevins
http://www.tomitribe.com

_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev

_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
_______________________________________________ jakartaee-platform-dev mailing list jakartaee-platform-dev@xxxxxxxxxxx To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev

Back to the top