Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakartaee-platform-dev] [jakarta.ee-spec.committee][jakarta.ee-spec][jakartaee-spec-project-leads]AutomaticModuleNamesinJakartaEE9
Hi Werner,

>> Do you really think all those Vendors will still ship their products with Java 8 now? ;-)

No, I only said that:
1. The automatic module in MANIFEST does not provide full features of JPMS as it can be seen in "module-info.java". Therefore the project should switch to j9.
2. or skip the automatic modules and speed up the release of the version 9 and be faster in version 10 with full JPMS using "module-info.java" .

If this community really wants to "provide more features" than the Spring, then please think about how the "module-info.java" can be utilized in the Cloud, and here is one business idea:
Imaging that you would deploy only WAR. The Cloud would "read" all module descriptors in the WAR and it would decide on what application server vendor to use. All this would happen only upon the entries in the module descriptors.
This means the developer does not hato think about the server and does not have to embed the server in the JAR (like in the current Quarkus) because the Cloud service already contains the server instance.
So this is one example how the entries (opens, requires) in the module descriptors can be utilized in Cloud.

Cheers
T



On Sat, Jul 25, 2020 at 4:09 PM Werner Keil <werner.keil@xxxxxxx> wrote:

Do you really think all those Vendors will still ship their products with Java 8 now? ;-)

 

The whole Java SE 8 compatible topic is about the TCK and the minimal JDK version that Jakarta EE 9 should perform well with, but in reality you will see it anywhere from Java SE 8 to 16 or beyond.

 

Werner

 

From: Tibor Digana
Sent: Saturday, July 25, 2020 02:33
To: jakartaee-platform developer discussions
Subject: Re: [jakartaee-platform-dev][jakarta.ee-spec.committee][jakarta.ee-spec][jakartaee-spec-project-leads]AutomaticModuleNamesinJakartaEE9

 

Don't worry about the names of JAR because the Java 9+ is able to determine the module name upon the file name if it satisfies this pattern:

<modulename>-<version>.jar

 

The customers respect changes in major versions, but they do not like changing the same thing in version 9 and then 10, 11, etc.

So if we did not specify the Manifest entry in every JAR for the version 8 and then we do it for all Jars in version 9, and then we change continue with module-info.java, then it is the worst scenario.

 

Everybody would ignore it even if you do nothing with the modularity, simply because the compiler version 8 in project - nobody would expect cool JPMS modularity.

But if you compiled the libraries with Java 9 then nobody would expect changing the module descriptor over and over again.

 

T

 

On Fri, Jul 24, 2020 at 10:41 PM Werner Keil <werner.keil@xxxxxxx> wrote:

Just see how Spring explains why they use the automatic module names, they define a stable and reliable module that doesn’t Change if the JAR should somehow be renamed.

 

Anyway, half of all module definitions in Jakarta EE 9 are already true module-info and those are perfectly in order, the 8 that must change are among the other half that does automatic-module-name, so changing that is done in a minute ;-)

 

Werner

 

From: Tibor Digana
Sent: Friday, July 24, 2020 22:27
To: jakartaee-platform developer discussions
Subject: Re: [jakartaee-platform-dev][jakarta.ee-spec.committee][jakarta.ee-spec][jakartaee-spec-project-leads]AutomaticModuleNamesinJakartaEE9

 

Anyway, the automatic-modules are not the real benefits of modules. All benefit you have from it is just the name and nothing more since you would not have the exported/imported packages just like it is in the "module-info.java" descriptor.

 

So this means removing the manifest header "Automatic-Module-Name", makes you ready to go further and you can better prepare for Java Compiler 9+ compatibility and the real "module-info.java".

 

There would be much more time spent on the discussions like this one.

 

Enjoy!

T

 

 

On Fri, Jul 24, 2020 at 2:28 PM Werner Keil <werner.keil@xxxxxxx> wrote:

Hi Anthony,

 

Removing one that was there should be avoided at all Costs, and those that accidentially say " Java" either may remove them if they were not in Jakarta EE 8 or have to Change the " Java" to "Jakarta".

 

In fact it should be enough to point to " Package Names and Module Names " of the Java SE spec:  https://docs.oracle.com/javase/specs/jls/se9/html/jls-6.html#jls-6.1

 

This pretty much goes along what you (or was it someone else?) mentioned about the package name and except for CDI (but it had no module so it could wait till a later version) where it is more complicated because the spec has a minimum of two top level package names, it should work everywhere.

 

If say a spec like Authentication which defined it in Jakarta EE 8 already as "java.security.auth.message" and therefore must change the "java" to "jakarta" now but not remove the stable module name it established, some future version decided to refactor to another package structure, then it could change the module name to say "jakarta.authentication" along with it, but there shouldn’t be any mess like "Oh we change from Java package names to artifactId and everyone suddenly must add .api", that would be vicious and unnecessary.

 

"Option F" is what sounds least intrusive and time-consuming and we should have that "disclaimer" saying not all specs are obliged to use modules now, pointing to the Java SE spec for anything that matters about the JPMS including the naming convention they already got there in the JDK and that should be all we need to do.

 

Werner

 

From: Anthony Vanelverdinghe
Sent: Friday, July 24, 2020 13:39
To: Werner Keil; jakartaee-platform developer discussions
Cc: Kevin Sutter
Subject: Re:[jakartaee-platform-dev][jakarta.ee-spec.committee][jakarta.ee-spec][jakartaee-spec-project-leads]AutomaticModuleNamesinJakartaEE9

 

Hi Werner

The purpose of `Automatic-Module-Name` is to allow top-down migration to modules, i.e. fix the module name ahead of proper modularization such that other projects can reliably refer to it. So yes, I agree that changing it afterwards defeats the purpose.

However, I believe the disclaimer is justified in this case, since I read it as: "Some component specs have already defined module names. However, those names were never endorsed by the platform and are inconsistent with one another. In a future version of the platform, a naming convention will be established, and any existing module names will be updated to comply with it."

So as I see it, some specs made a promise about their module name, even though they weren't entitled to do so (though I understand they did so out of necessity). So it's the platform's right to update the module name if needed.

Kind regards,
Anthony

On 23/07/2020 23:56, Werner Keil wrote:

Anthony,

 

Spring is Pretty clear on "stable language-level modules”

https://docs.spring.io/spring/docs/current/spring-framework-reference/overview.html

and it isn’t even an official standard, just popular, so for an actual standard we should regard that kind of stability even higher.

 

What I would envision for the spec is not much more than the few sentences in the Spring docu.

 

I see no problem with the top-most package, in fact it would even work for Websocket where the groupId is used by https://github.com/eclipse-ee4j/websocket-api/tree/master/api/server/src/main/java/jakarta/websocket/server and client.

 

Some like Authorization only changed the "javax.* " to "jakarta.security.jacc", if they wold do the same for the automatic-module-name, then why not.

 

If a future version went to change that, sure why shouldn’t a module change but in general the modules should aim to be stable until they get broken down into smaller modules, e.g. CDI or it was discussed with JPA whether or not a "Light" module could be used by NoSQL.

 

Then it could be justified to change that, but not just for the sake of changing so soon after the "Big Bang".

 

Werner

 

From: Anthony Vanelverdinghe
Sent: Thursday, July 23, 2020 23:42
To: jakartaee-platform developer discussions; Werner Keil; Kevin Sutter
Cc: Jakarta specification committee
Subject: Re: [jakartaee-platform-dev][jakarta.ee-spec.committee][jakarta.ee-spec][jakartaee-spec-project-leads]AutomaticModuleNamesinJakartaEE 9

 

The listed specs all define the module name I'd expect them to have (assuming that `java.servlet` will be changed to `jakarta.servlet` for Jakarta EE 9), so I don't foresee further changes for them.

W.r.t. dependent projects, I doubt that many of them actually depend on the module name (e.g. in my experience, Spring Boot apps run with everything on the classpath). Either way, changing the module name would be much less disruptive than the current package name changes.

For Java modules, the typical naming convention is to use the root package (also see [1]).

[1] https://github.com/eclipse-ee4j/jakartaee-platform/issues/174

Kind regards,
Anthony

On 23/07/2020 22:27, Werner Keil wrote:

IMO

 

The "existence" of modules may change, but frankly speaking especially for the Top 5 Jakarta EE 8 specs with modules

changing the name of either of them would be extremely bad for the image and adoption of Jakarta EE.

 

We spent a lot of time on "namespaces" or naming conventions, therefore those that already have modules better not drop them or suddenly change them if up to 1000 projects including heavyweights like Spring Boot include them, and that way Ten if not Hundreds of Thousands of apps and services may depend on those names.

 

Writing a few sentences like the module name where present shall reflect the Maven groupId (except for EL or JSP all others do, Websocket is the only special case because it has a Client and Server module) or if everyone thought that would be better the artifactId (in such case every module shall NOW end with ".api” and not change between Jakarta EE 9 and 9.1 or 10) is really no effort compared to the hours we already spent on XML schema that many specs have absolutely no use for.

 

Werner

 

From: Anthony Vanelverdinghe
Sent: Thursday, July 23, 2020 21:48
To: jakartaee-platform developer discussions; Kevin Sutter
Cc: Jakarta specification committee
Subject: Re: [jakartaee-platform-dev][jakarta.ee-spec.committee][jakarta.ee-spec][jakartaee-spec-project-leads]AutomaticModuleNamesinJakarta EE 9

 

To me, this is essential:

(We will still need some type of disclaimer in the Platform Spec that indicates not to count on the Module Names for Jakarta EE 9 -- they will be changing in the future when we properly support JPMS Modules.)


And with such a disclaimer in place, it doesn't really matter which option is chosen, even "do as you wish" would work (of the defined ones, I'd go with F though).

Also, Jakarta EE 9.1 should solely be about Jakarta EE on Java SE 11 *on the classpath* (i.e. the modulepath only contains the Java SE modules; anything else is on the classpath), so module names would still not matter.
As I see it, bringing Java modules into the platform is a vast topic, and is thus unrealistic to do in Jakarta EE 9.1.

PS: since JPMS still seems pretty popular in conversations about Java modules: https://twitter.com/mreinhold/status/994669659029999616

Kind regards,
Anthony

On 23/07/2020 19:56, Kevin Sutter wrote:

I can still appreciate Tibor's statements though -- we need to quit adding work, no matter how small of an effort, if we want to meet our goals of delivering Jakarta EE 9 this fall.  Thanks, Tibor.


---------------------------------------------------
Kevin Sutter
STSM, MicroProfile and Jakarta EE architect @ IBM
e-mail:  sutter@xxxxxxxxxx     Twitter:  @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)    
LinkedIn: https://www.linkedin.com/in/kevinwsutter



From:        Werner Keil <werner.keil@xxxxxxx>
To:        jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Cc:        Jakarta specification committee <jakarta.ee-spec.committee@xxxxxxxxxxx>
Date:        07/23/2020 11:47
Subject:        [EXTERNAL] Re: [jakartaee-platform-dev] [jakarta.ee-spec.committee][jakarta.ee-spec][jakartaee-spec-project-leads]AutomaticModuleNamesinJakarta EE 9
Sent by:        jakartaee-platform-dev-bounces@xxxxxxxxxxx

 

That’s not correct, because whereever the definitions of modules like " java.servlet", "java.json", etc. existed in Jakarta EE 8 this must also be changed just like the packages.

 

See

https://docs.google.com/spreadsheets/d/1g8jYG0JixO3wzZkpeyU1LMIQRhbnZ76kGtdMFE8mieE/edit?usp=sharing

 

Maybe Scott was a bit ahead of himself sending it to ALL project leads, but especially those that already had a module declaration in Jakarta EE 8 and have not changed that to "jakarta.*" must also do that.

Those with a wrong automatic module name could also be "lazy" and simply remove that, I don’t think any full module-info wasn’t changed or newly introduced correctly, and especially those must not be destroyed because many of them like Activation are used in other specs like Mail, so IMO we could throw those options at them if that is what Scott suggested, but not sure, if the project leads may vote or if they should simply apply them, Option F is the preferred one by the Spec Committee and also what I mentioned here.

 

Only 8 specs would have to do anything, of these at least 4 already had modules defined in Jakarta EE 8, so they should leave them under the new namespace, the others could also just remove the automatic declaration.

 

Werner

 

From: Tibor Digana
Sent: Thursday, July 23, 2020 18:00
To: jakartaee-platform developer discussions
Cc: Jakarta specification committee
Subject: Re: [jakartaee-platform-dev] [jakarta.ee-spec.committee][jakarta.ee-spec][jakartaee-spec-project-leads]AutomaticModuleNamesinJakarta EE 9

 

Our goal was to change the license and rename the Java packages. Please do not prolong the work with more ambitions.

 

Dňa št 23. 7. 2020, 16:48 Scott Stark <starksm64@xxxxxxxxx> napísal(a):

I sent an email to the project leads list asking for feedback in the comments section of the doc that I just added.

 

On Thu, Jul 23, 2020 at 4:32 AM Werner Keil <werner.keil@xxxxxxx> wrote:

Thanks a lot, that might make it easier to decide.

 

Werner

 

Sent from Mailfor Windows 10

 

From: Scott Stark
Sent: Thursday, July 23, 2020 03:00
To: Jakarta specification committee
Cc: jakartaee-platform developer discussions
Subject: Re: [jakarta.ee-spec.committee] [jakartaee-platform-dev][jakarta.ee-spec][jakartaee-spec-project-leads]AutomaticModule NamesinJakarta EE 9

 

Now there are 6 options in the "Proposals for Handling of Automatic-Module-Name header in Jakarta EE 9" document after merging changes suggested by Kevin and Werner.

 

_______________________________________________
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