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
@Joakim it is really about consumer, in the project itself it always works - and yes it is not a spec only thing, any module adding JPMS creates troubles at some point cause JPMS is NOT transparent to the build and run and it is kind of rejected - at least not embraced - by the ecosystem and graal made it worse.
Putting the modules in the classpath works well but a ton of modules try to guess cause when you have a JPMS stack you don't want to configure your module-path and clsas-path (yes both since everything is not JPMS in general) manually, it is hard to maintain. So automotion is needed and easy to break with module-info presence.

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


Le jeu. 31 août 2023 à 07:34, Joakim Erdfelt <joakim.erdfelt@xxxxxxxxx> a écrit :
Eclipse Jetty has shipped JPMS compliant jars (with module-info) since Jetty 10.0.0 (Dec 2020)
Jetty 11 and Jetty 12 (all shipped environments) are also JPMS compliant.

We've had 1 issue with surefire (in a beta version of surefire), it works in both module-path and class-path mode reliably both during build/compile/test and also runtime.

- Joakim

On Wed, Aug 30, 2023 at 10:30 PM Romain Manni-Bucau via jakartaee-platform-dev <jakartaee-platform-dev@xxxxxxxxxxx> wrote:
Just to point out an example - and indeed I assume a lot of projects use Maven and surefire for tests: https://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html#useModulePath. This will break if you switch from a module info to a plain classpath jar as idea will break your compilation too. Indeed all have configuration but the portability goal is totally broken even when you don't intend to use JPMS at all, when you just want to consome the specs.
So it is an all in or all out choice.

Hope it is clearer.

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


Le jeu. 31 août 2023 à 07:24, David Blevins via jakartaee-platform-dev <jakartaee-platform-dev@xxxxxxxxxxx> a écrit :
You're completely correct that they aren't portable or guaranteed, and if we aren't extremely clear with that, it definitely does create significant downsides to users who were given the impression they were a guarantee of the spec.

The Platform spec language is clear, but the CDI spec seems misleading to me.

Lenny, were you given the impression by the CDI spec text that the module-info was standard and portable?

On Aug 30, 2023, at 8:16 PM, Romain Manni-Bucau <rmannibucau@xxxxxxxxx> wrote:

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

_______________________________________________
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