+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
