+1 on all points. I absolutely agree this next revision should just focus on the namespace move and avoid scope creep, further complexity and further delays.
I agree with you, Werner and others. The Jakarta namespace change justifies a Jakarta EE 9 (vs 8.1). We also decided that the naming of the Jakarta EE releases would be independent from the Java SE releases.
In Java EE 8, some of the individual APIs attempted to create module-info.class files, but since we wanted consistency, this was removed as a requirement from Java EE 8 platform. Attempting to define appropriate templates for the module-info.class files for every API in time for the Jakarta EE 9 release is probably pushing it. Since we're trying to eliminate or limit the new features going into Jakarta EE 9, my vote would be to leave this module-info.class idea off the list.
Individual Jakarta Components are welcome to follow the Specification Process to release new interim releases of their functionality -- independent of the Jakarta Platform. But, these Components also have to realize that the requirements of the Platform spec may require certain capabilities that would still need to be released. So, the development and coordination of these new features should be done in branches to avoid possible contamination of master.
---------------------------------------------------
Kevin Sutter
STSM, MicroProfile and Jakarta EE architect
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>
Date: 11/18/2019 15:55
Subject: [EXTERNAL] Re: [jakartaee-platform-dev] Rename Jakarta EE 9 to 8.1, introduce the Java Modularity in Jakarta EE 9 and fastfeaturereleases
Sent by: jakartaee-platform-dev-bounces@xxxxxxxxxxx
Tibor,
Thanks for your Reply. As the package rename is clearly a Major and Breaking Change I’m not so sure if a 8.1 release would do that justice.
As Long as a Jakarta EE application does not define its own module-info, there is no side-effect I know even if you use JDK 11 or 13. I just helped a major Open Source Project for security get Jigsaw-enabled and we tested using it Prior to that, so I know t rather well.
Especially with some of the older specs and their implementations it is not known for sure, whether they properly separated package names for each module, that is the biggest no-go for using the Java Module System.
So changing the package Name seems easier with a big-bang, I cannot say for sure, if module-info for every spec was possible at the same time.
"unplug" the impl, with OSGi that even works at runtime, but as Jigsaw never got there, it is mostly restricted to build time and redeploment of some apps. However, with many systems built on container technologies now anyway the tear-down and redeploy of such app is often seamless anyway.
Cheers,
Werner
Sent from Mailfor Windows 10
From: Tibor Digana
Sent: Monday, November 18, 2019 21:24
To: jakartaee-platform developer discussions
Subject: Re: [jakartaee-platform-dev] Rename Jakarta EE 9 to 8.1,introduce the Java Modularity in Jakarta EE 9 and fastfeaturereleases
Hey Werner,
I did not say that "only Jigsaw". I mentioned Jigsaw because I have never seen it as a plan in Jakarta. Other features are expected of course in every major release.
Question: Can we add "module-info.class" to every API/JAR in JakartaEE 9.0?
This would be an additional feature I would say.
I hope it would not break the EE apps on JDK 1.8.0.
If the impl follows the API dependencies, then it should be no problem to "unplug" the impl modules while the some APIs are not used by the EE application.
Then I can imaging Cloud EE Container which enables/disables these APIs and their implementations upon the deployment of modular WAR.
Is the API a service in Cloud then? It can be maybe seen just like that!
Cheers
Tibor17
On Mon, Nov 18, 2019 at 8:58 PM Werner Keil <werner.keil@xxxxxxx> wrote:
Tibor,
This sounds interesting, but if it was just to be „Jigsaw enabled“ without actual Features I would not really see why the refactoring (Breaking API Change) should only be done as 8.1 and the only Thing that 9 would add is module-info?
I Kind of like the idea of big Breaking changes in 9 and even some new featues being added subsequently by 9.1 but happy to har the Preference by others. A small number of Jakarta EE specs especially JSON-P and JSON-B already define a module-info now. Whether the "java.*" has to be replaced by a universal "jakarta.* " also in the module-info, I can only guess but I would guess so.
Cheers,
Werner
From: Tibor Digana
Sent: Monday, November 18, 2019 10:43
To: jakartaee-platform developer discussions
Subject: [jakartaee-platform-dev] Rename Jakarta EE 9 to 8.1,introduce the Java Modularity in Jakarta EE 9 and fast featurereleases
The current activities in Jakarta EE are mainly related to the new transfer release.
Please rename the version from 9 to 8.1.
I remember the Vote of users in Java EE Guardians several years ago when we voted for alignment between EE and SE and the release time alignment as well.
IMO the Java Modules would be something very natural in Jakarta EE 9 because not only Maven POM but also the binary file of the API would declare that it is dependent on another API.
It would be clear for the build tool to build the EE application with tailor made container and no list of api-layers would have to be specified by the user in the build tool.
I think this would be a big jump in EE 9 but with SE 9 in the area of Microservices and such profile.
Pls reserve the version number 9 for what i have described, rename this "transfer" release to 8.1 and try to be consistent with the original idea of alignment with SE releases; otherwise the number would be really meaningless.
Accepting the version 8.1 would also mean that we have started with very fast feature releases, e.g. 9.1, 9.2, etc. Additionally, some new APIs may have later release time, for instance 9.1 and the other or unrelated APIs would not have to wait for the whole umbrella of major version.
Cheers
Tibor17
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev