Re: [jakarta.ee-spec.committee] Potential Agenda item for tomorrow

["Steve Millidge (Payara)" <steve.millidge@xxxxxxxxxxx>]

I'm also in the camp of big bang move for Jakarta EE 9. Strip it right down, remove all legacy, move everything left to jakarta.*. All jar artifacts compiled JDK 11+. Drop all javax namespace apis in one go.

That way we can take the inevitable chaos in one go and move on. 

Vendors can mitigate this in runtimes as they see fit. 

Otherwise we will drip break things whenever a change to an api is required and a class needs to be copied to the Jakarta package namespace. 

Steve

-----Original Message-----
From: jakarta.ee-spec.committee-bounces@xxxxxxxxxxx <jakarta.ee-spec.committee-bounces@xxxxxxxxxxx> On Behalf Of Scott Stark
Sent: 16 April 2019 18:09
To: Jakarta specification committee <jakarta.ee-spec.committee@xxxxxxxxxxx>
Subject: Re: [jakarta.ee-spec.committee] Potential Agenda item for tomorrow

I'm of the opinion that that Jakarta EE gets stripped to the bone, everything left moved into the jakarta.* namespace and migration strategies for existing Java EE 8 and earlier applications proposed.
Profiles of interest can then be defined as deemed necessary.

On Tue, Apr 16, 2019 at 6:51 AM Kevin Sutter <sutter@xxxxxxxxxx> wrote:
>
> Good questions, Bill.  Thanks.  I agree that we need to look at the big picture first.  But, we also need to have some direction for the masses when the neutering of the javax namespace is announced.
>
> Werner, I agree with you that the Config JSR should just move to the JESP.  In my mind, there is no reason to continue down the JSR path and be limited by the javax namespace thing.  We might as well move that to JESP and use the jakarta.* namespace from the get-go.  MVC is probably too far down the JSR path to switch at this point, but I still think they should consider the long-term consequences now that the javax namespace is frozen.
>
> ---------------------------------------------------
> Kevin Sutter
> STSM, MicroProfile and Java EE architect
> e-mail: sutter@xxxxxxxxxx Twitter: @kwsutter
> phone: tl-553-3620 (office), 507-253-3620 (office)
> LinkedIn: https://www.linkedin.com/in/kevinwsutter
>
>
>
> ----- Original message -----
> From: Bill Shannon <bill.shannon@xxxxxxxxxx> Sent by: 
> jakarta.ee-spec.committee-bounces@xxxxxxxxxxx
> To: Jakarta specification committee 
> <jakarta.ee-spec.committee@xxxxxxxxxxx>, Werner Keil 
> <werner.keil@xxxxxxx>
> Cc:
> Subject: Re: [jakarta.ee-spec.committee] Potential Agenda item for 
> tomorrow
> Date: Mon, Apr 15, 2019 9:31 PM
>
> Specs that don't change don't need to move out of javax.*.
>
> I'd like to see a bigger vision for Jakarta EE 9.  Is there still a platform?  Is there still an application server?  Does it include everything that was in Jakarta EE 8, plus more?  Is it pruned to the bone?  Is it microservices only?  Is it all a la carte?
>
> With some guiding principles, maybe some of the detailed answers will fall out?
>
>
> Werner Keil wrote on 4/15/19 5:39 PM:
>
> Kevin,
>
>
>
> Good Point, thanks for elaborating.
>
> Especially
>
> >     - If so, when and would anything not be moved?
>
> Is a key question probably mainly towards Oracle.
>
>
>
> Would an existing spec like JCA (Java Connector Architecture) have to change to a new “jakarta” namespace, even if hypothetically it may never be touched or upgraded again?
>
>
>
> While e.g. Ivar’s and Christian’s MVC standard is close enough to a Final release, JSR 382 (led by “Eclipse Foundation” although at least Emily is a permanent employee of IBM, not sure, how the whole IP situation works in that case?) https://jcp.org/en/jsr/detail?id=382 is quite inactive by JCP standards. And even after upgrading to JCP 2.11, the 18 months before a failure to submit a Public Review trigger a Renewal Ballot seem only a few weeks away.
>
>
>
> For MVC or the specs that went Final with Java EE 8 already it is a good question, if an update towards Jakarta EE 9 or above means, only the new elements should be declared under “jakarta” or everything refactored from “javax.*” to “jakarta.*” starting with a new version.
>
>
>
> We had similar cases before, remember http://medialab.di.unipi.it/web/doc/tutorial/uiswing/start/_packagename.html with package names literally swinging from “com.sun.java.swing” to “java.awt.swing” and “javax.swing”?
>
> Who knows, if it followed the fate of JavaFX it may end up with a 4th package name some day.
>
>
>
> If JSR 382 which has not even produced an EDR yet wanted to become a part of the Jakarta EE platform, then for the sake of consistency and to avoid confusing possible users (or other projects and specs hoping to use it) it really should make up its mind, if a start with “javax.config” still makes any sense if it had to rename new or all parts to “jakarta.config” anyway.
>
>
>
> Werner
>
>
>
> From: Kevin Sutter
> Sent: Tuesday, April 16, 2019 02:14
> To: jakarta.ee-spec.committee@xxxxxxxxxxx
> Subject: Re: [jakarta.ee-spec.committee] Potential Agenda item for 
> tomorrow
>
>
>
> I couldn't make last week's call so I don't know how much of this was discussed already...  But, I think David's first question has to be asked (and answered) before we dive into the details of what tooling is available to accomplish some task...
>
>
>
> >  - Should all code be transitioned from javax.* to jakarta.*
> >     - If so, when and would anything not be moved?
>
>
> My take is that we should not do a "big bang" move from javax.* to jakarta.* in Jakarta EE 9.  I think we should do this on an "as needed" basis.  So, instead of doing a full-scale move of everything from javax.* to jakarta.*, we should do it as the Java EE components require it.  As an example, let's assume that JAX-RS and JMS are chomping at the bit to add new functionality in Jakarta EE 9.  These components should figure out what the impact is to move to jakarta.*.  And, there may be ripple effect.  But, we shouldn't move EJB to jakarta.*, if there are no proposed updates in the space.
>
>
>
> Some may argue that we should just bite this and make the move all at once.  But, why affect every Java EE application with Jakarta EE 9 if we could limit it to maybe 20% (or whatever)?  And, allow a more gradual move to the new namespace.  Maybe at some point down the road, we determine that we have critical mass and we can move the rest of the dormant components.  Or, maybe we determine that these dormant components should just be left with javax.* and never "promoted" to Jakarta EE...  Decisions that we can move out a bit.
>
>
>
> Once we determine the scope of the change in Jakarta EE 9, then we can determine how best to roll it out for each component and also look at providing tooling to help with any required migrations.
>
>
>
_______________________________________________
jakarta.ee-spec.committee mailing list
jakarta.ee-spec.committee@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee