Skip to main content

[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

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



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

Back to the top