Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakartaee-platform-dev] JPMS Module Info classes
Was there any real world testing on the "no downside" part? This is not true since any tool using jpms - even some surefire version - will make your code broken. Likely the same in idea for ex.
And as soon as people use it - guess it is there for that, you broke the api portability EE always guaranteed.
So there are downsides (to summarize: it breaks EE portability design) and IMHO there are serious enough to force spzc to standardize or forbid module-info but nothing in the middle.

Le mer. 30 août 2023 à 23:46, David Blevins via jakartaee-platform-dev <jakartaee-platform-dev@xxxxxxxxxxx> a écrit :
Agree they are useful to people and there is no downside to allowing people to add them to their spec jars -- this is what we all agreed on.  No argument there.

We just need to be careful to understand that they are not standard, portable or spec defined.  You are able to implement the spec and be considered compliant without including module-infos in your spec jars or implementation.  You're even allowed to supply a module-info that is completely different and/or conflicting with the module-info of another implementation.

If a spec implies that they are requirements, it is actively misleading people.  That spec text should be updated to be more honest about the actual situation and lack of guarantees around them.

Does that make more sense?

On Aug 30, 2023, at 4:21 AM, lenny--- via jakartaee-platform-dev <jakartaee-platform-dev@xxxxxxxxxxx> wrote:

The issue is that if JPMS is not included, you get nasty warnings such as:
[WARN] *****************************************************************************************************************************************************************************************************
[WARN] * Required filename-based automodules detected: [microprofile-config-api-3.0.2.jar]. Please don't publish this project to a public artifact repository! *
[WARN] *****************************************************************************************************************************************************************************************************
Since Java 9+, all of JDK is JPMS-modularizied, there is no downside to included module-info in Jakarta EE spec JARs, thus the requirement in the SPEC,
which is great and should definitely be there.

On Aug 30, 2023, at 4:08 AM, Romain Manni-Bucau via jakartaee-platform-dev <jakartaee-platform-dev@xxxxxxxxxxx> wrote:



Le mer. 30 août 2023 à 12:52, Werner Keil <werner.keil@xxxxxxx> a écrit :
Why would the module info make anything less stable?

Itd presence impacts your deliverables and app linking in most tools.
If not specified and in the spec then it makes your app unstable compared to not delivering it and staying in unamed module.

If specified EE should support jpms.

Side note: same applies to osgi meta.


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
_______________________________________________
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