[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [jakartaee-platform-dev] Oracle's position on Jakarta EE 9
|
Thomas,I think the javax->jakarta
namespace change will be significant enough for users to handle in Jakarta
EE 9. If we open the flood gates with new features and enhancements
at the same time, I'm afraid we will scare off existing users (a very large
base that we don't want to lose). In addition, adding new features
and enhancements will extend the timeline for a Jakarta EE 9 release. We
have to start thinking on a smaller scale so that we can produce Jakarta
EE releases in a more timely manner.
---------------------------------------------------
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:
Thomas
Andraschko <andraschko.thomas@xxxxxxxxx>To:
jakartaee-platform
developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>Date:
10/02/2019
03:05 AMSubject:
[EXTERNAL]
Re: [jakartaee-platform-dev] Oracle's position on Jakarta EE 9Sent
by: jakartaee-platform-dev-bounces@xxxxxxxxxxx
I generell the easiest way for EE9 would
be just a renaming of the packages, without any new specs or existing API
enhancements.If we rename all packages, we will completely
destroy backward compatibility.
I would say this bigbang approach isn't bad and we should see as restart
and as big change and allow API changes/enhancements in EE9.Let me explain further.I already talked with Arjan - especially
about JSF and PrimeFaces:
I'm "community lead" of PrimeFaces
- working on JSF related projects since 2013 (PrimeFaces + Extensions,
DeltaSpike, JSF specs, MyFaces Core, CDI/OpenWebBeans, Mojarra).If we change the namespaces, we probably
need to create a second JAR for JakartaEE (primefaces.jar <> primefaces-jakarta.jar).
Same may be happen to all third-party libs, which are based on Jakarta
EE.In this new jakarta-jar, we can completely
start from new ground! We can remove old hacks for JSF2.0-2.3 and also
remove for example old hacks for very old JavaEE6 containers/old versions
of JSF impls!
If we can remove old hacks, why not introduce
new features or enhancements in the same version, which would make the
life easier for JSF users?We don't have backward compatibility
problems at exactly this point as everything will be broken because of
the big bang.What would happen if we don't add them
in EE9 but later in EE10?On PrimeFaces we can't use the new features
as having 3 JARs would be unmaintainable (primefaces.jar, primefaces-jakarta9.jar,
primefaces-jakarta10.jar).Woudln't we miss A BIG CHANCE, to enhance/change
the API in EE9?
Am Mi., 2. Okt. 2019 um 04:38 Uhr
schrieb Josh Juneau <juneau001@xxxxxxxxx>:+1 for all of the points raised in the
Oracle position document...fully agree. I also am on-board with a
faster release of Jakarta EE 9. As mentioned, it should incorporate
the namespace changes along with only any minor updates and enhancements
that will not delay the release.
Josh Juneau
juneau001@xxxxxxxxx
http://jj-blogger.blogspot.com
https://www.apress.com/us/search?query=JuneauOn Oct 1, 2019, at 4:51 PM, Reza Rahman
<reza_rahman@xxxxxxxxx>
wrote:
I believe aiming for a faster release
is better at this time. It will help reassure many people this is a committed
effort.Reza Rahman
Principal Program Manager
Java on Azure
Please note that views here are my own as an individual community member
and do not represent the views of my employer.On 10/1/2019 5:22 PM, Bill Shannon wrote:The key change for Jakarta EE 9 is the
namespace change.
Pruning reduces the amount of work to be done there.
I don't expect to add any completely new specifications, but if it can
be done with minimal impact on the other work it's worth considering.
Jakarta EE 9 may not be the right time to add new profiles, mostly because
of the TCK work required to support new profiles.
I would hope that API enhancements would be modest.
I won't be surprised if the community decides not to specify backwards
compatibility.
Whether you name the releases 9, 10, 11, 12 or 8.1, 8.2, 8.3, 8.4 doesn't
really matter. The issue is how you decide the content of the releases.
Are the releases date driven or content driven, or some combination?
We haven't really decided a general approach, and it might be different
for each release. It's quite clear that the community prefers releases
more frequently than what was done for Java EE, so I'm assuming a 6 - 12
month time frame, which likely constrains the amount of content that can
be included.
It took a lot of effort to get out a release that had no API changes at
all, so I don't think we yet know enough to predict how long it will take
to produce a Jakarta EE 9 release even with just some minimal set of changes.
I guess we need more community input on the date vs. content tradeoffs.
Do we decide what we want and then it takes as long as it takes?
Or do we drive to a particular date and scale the content accordingly?
Edwin Derks wrote on 10/1/19 1:58 PM:Thanks Bill, it's a pleasure to see a
detailed document containing Oracle's position on Jakarta EE 9. What I feel though, and I would certainly
like to hear your opinions on this, is that we are gearing up a lot of
desired changes to the platform for release 9:- possible big bang namechange of javax- possible pruning of specifications- possible new specifications- possible new profiles- possible API enhancements- possible backwards compatibility featuresThis is awesome of course, but do we
really want to put all of these topics (to some extend) in one "big
bang" release that will result in Jakarta EE 9? Alternatively, can
we spread ithese out over smaller releases like Jakarta EE 8.1, 8.2, 8.3
or Jakarta EE 9, 10, 11, 12 in order to shorten the time of delivering
any platform updates? Since we are now starting to plan these changes,
can we in any way start to define a (high level) roadmap on these? To my
current knowledge, a release cycle for Jakarta EE hasn't been determined
yet, but maybe this will shape itself when we start planning/estimating/roadmapping?
I'm not only curious about this myself, but the desire for some kind of
roadmap was also mentioned in feedback that I got from a few community
members I spoke to at Oracle CodeOne.Hope this helps.Kind regards,EdwinOn Tue, 1 Oct 2019 at 22:15, Kevin Sutter
<sutter@xxxxxxxxxx>
wrote:Excellent strawman,
Bill. Thanks!
What about Entity Beans? You mention "client view", but
did you also mean to include Entity BMP and CMP Beans? I'd vote +1
for that pruning as well.
I noticed that you didn't include Jakarta Management in the Pruning list.
The other Stable APIs were included to be pruned (Registries, RPC, and
Deployment). Did you just just forget Management, or is there a reason
why you wouldn't include that in your list to be pruned?
Any justification on which Java SE 8 APIs should be moved to Jakarta EE
9 and which ones shouldn't? Or, was it just gut reaction to usage
scenarios?
Agree with postponing the MicroProfile decision until after Jakarta EE
9.
The TCK work could be initiated and completed at any time, right?
Does it have to line up with Jakarta EE releases?
Other than that, I think this is a great start!
---------------------------------------------------
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: Bill
Shannon <bill.shannon@xxxxxxxxxx>
To: jakartaee-platform
developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Date: 10/01/2019
11:33 AM
Subject: [EXTERNAL]
[jakartaee-platform-dev] Oracle's position on Jakarta EE 9
Sent by: jakartaee-platform-dev-bounces@xxxxxxxxxxx
See attached for Oracle's proposal for Jakarta EE 9. We look forward
to
continuing this discussion.
[attachment "jakartaee9.md" deleted by Kevin Sutter/Rochester/IBM]
_______________________________________________
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
_______________________________________________
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
--
Reza Rahman
Principal Program Manager
Java on Azure
Please note that views here are my own as an individual community member
and do not represent the views of my employer._______________________________________________
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