| Re: [jakarta.ee-spec.committee] Potential Agenda item for tomorrow |
|
The problem I see with leaving some specs in javax is what if you find you do need to update them some time in the future? Now you need to move it to the jakarta. namespace and you break people’s
apps again! I prefer one big break than lots of little breaks. Lots of little breaks will drain away what loyalty we have. If you move EVERY api to jakarta.* for Jakarta EE 9 it means you break things once only. Also vendors could easily support both apps using old javax and new apps on jakarta as the api jars and namespaces
are not mixed and therefore both could be packaged if a vendor wanted to support Jakarta EE 8 and Jakarta EE 9. Mixing jakarta and javax namespaces in Jakarta EE 9 could make that more difficult. Given appservers like Payara 5, which we hope to certify on Jakarta EE 8, are supported for many years we have plenty time to assist customers in migrating to new apis.
Personally I think moving everything to jakarta.* and modernising at least provides a vision of the future that people could get behind. I for one will not want to explain to new committers which
class they can touch and which they can’t without renaming and moving it to a new package. Life’s too short to carry that level of technical debt.
Steve From: jakarta.ee-spec.committee-bounces@xxxxxxxxxxx <jakarta.ee-spec.committee-bounces@xxxxxxxxxxx>
On Behalf Of Werner Keil If there were enough People and contributors to do all that, sure, why not. With often the same one or two „Usual Suspects“ working on 6 different MicroProfile Features and 3 or more Jakarta EE specs this could be a bit challenging, so we’ll see, which can be migrated.
Leaving those that are not yet (or never) improved sounds like a good idea, so people don’t have to migrate for Nothing. Werner Sent from
Mail for Windows 10 From:
Steve Millidge (Payara) I’m not saying kill any specific specs, even EJB (we just added HTTP invokers so I’m a fan) or JCA (we have Kafka and MQTT connectors) but move them to jakarta.* and rip out their technical debt. Embrace the whirlwind
and build new runtimes on the new leaner apis and specs. Steve From:
jakarta.ee-spec.committee-bounces@xxxxxxxxxxx <jakarta.ee-spec.committee-bounces@xxxxxxxxxxx>
On Behalf Of Werner Keil Some like Java Connector are probably among the most rarely used and hardly maintained specs in recent years. IMO that could probably even be pruned or deprecated, at least declared an optional
Addition (like Microprofile ;-) but others especially EJB have much greater potential and as I demonstrated in a recent tutorial also a few Advantages even over the much praised CDI in certain situations where EJB allows greater Control by the container, e.g.
for concurrency or observers. So EJB is far from dead, but I’d be perfectly open to one or the other „Micro profile“ or a „Mix and Match“ one like the „A’la Carte“ Bill mentioned. Werner From:
Steve Millidge (Payara) 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
> 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 _______________________________________________ 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 |