User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
Jakarta EE 8 is definitely NOT an Oracle brand. I'm not sure what
legal issue there would be for a Jakarta EE 9 product to support
applications written for Jakarta EE 8.
carlos andres de la rosa wrote on
10/2/19 1:05 AM:
Hello bill
Regarding your comment "I won't be surprised if the
community decides not to specify backward compatibility."
For me make sense, and just support backward compatibility
only from Jakarta EE 9 and beyond, due Jakarta EE 8 still been
oracle brand and can be tricky from the legal side handle the
support.
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 features
This 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,
Edwin
On 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
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
