[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [jakartaee-platform-dev] Rename Jakarta EE 9 to 8.1, introduce the Java Modularity in Jakarta EE 9 and fastfeaturereleases
|
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/kevinwsutterFrom:
Werner
Keil <werner.keil@xxxxxxx>To:
jakartaee-platform
developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>Date:
11/18/2019
15:55Subject:
[EXTERNAL]
Re: [jakartaee-platform-dev] Rename Jakarta EE 9 to 8.1, introduce the
Java Modularity in Jakarta EE 9 and fastfeaturereleasesSent
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