From: ee4j-pmc-bounces@xxxxxxxxxxx [mailto:ee4j-pmc-bounces@xxxxxxxxxxx]
On Behalf Of Kevin Sutter
Sent: Friday, May 31, 2019 10:07 PM
To: EE4J PMC Discussions <ee4j-pmc@xxxxxxxxxxx>
Subject: Re: [ee4j-pmc] Just changing javax to jakarta in package names
Just to be clear, the exact content and roadmap for Jakarta EE 9 is not cast yet... Arjan has communicated some of the ideas floating around, but nothing is concrete
yet. We do know that we have to change the package name from javax to jakarta. That's a definite part of Jakarta EE 9. (The incremental approach or big bang approach also has to come to a conclusion, but let's not muddy this thread with that topic.)
In my mind, changing anything more in the package name other than the required javax -> jakarta just injects more confusion into the upgrade. Even if we provide wonderful binary
compatibility, it's still going to be a pain to the customers when they have to change their source code. Again, even with proper tooling, it's going to be painful. We really need to make this migration to the new jakarta namespace as painless as possible.
A simple javax.* to jakarta.* package name change accomplishes that goal.
Also, even if we have some "not perfect" package names in Java EE today, familiarity wins out in my mind. We need to focus on bringing our existing Java EE customers forward
to Jakarta EE. Minimal impact will be key to that success.
---------------------------------------------------
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: "Guillermo González de Agüero" <z06.guillermo@xxxxxxxxx>
To: EE4J PMC Discussions <ee4j-pmc@xxxxxxxxxxx>
Date: 05/31/2019 12:40 AM
Subject: [EXTERNAL] Re: [ee4j-pmc] Just changing javax to jakarta in package
names
Sent by: ee4j-pmc-bounces@xxxxxxxxxxx
Probably no end-user application will use Jakarta EE 9 but library authors will probably do, in order to test their products. Changing packages in two steps imposes new work for all of them.
As for breaking compatibility by removing old stuff, I don't think that's comparable to renaming packages. Java EE lacked a proper process for permanently removing pretty old or failed stuff, which made some specs unnecessary big over time. Removing JSP support
from JSF is actually great news and won't probably break anyone who is upgrading. Renaming packages affect everyone.
Note that we have already sold the idea that Jakarta EE 9 will be the last one from the transition and that we are only making a simple string replace. If we decide it's better to make some more changes (which I actually don't oppose), we have to do it as part
of the current transition release, which is what users expect.
El jue., 30 may. 2019 23:42, arjan tijms <arjan.tijms@xxxxxxxxx> escribió:
Hi,
On Thu, May 30, 2019 at 10:44 PM Guillermo González de Agüero <z06.guillermo@xxxxxxxxx> wrote:
IMO all of these changes should be done in one shot. If Jakarta EE 9 is the one that might break compatibility, but we claim the right to change package names again on the next release, users can't take compatibility for granted anymore.
Though I definitely would not be strongly against one shot, we may have to keep in mind that Jakarta EE 8 and Jakarta EE 9 are in a way "paper releases". With this I mean that they, at least as proposed now, are only procedural releases without any enhancements
or features of any kind.
* Jakarta EE 8 is virtually identical to Java EE 8, just "produced" by the Eclipse Specification Project and the API jars being available using the jakarta Maven group id.
* Jakarta EE 9 is (proposed!) virtually identical to Jakarta EE 9, with only all package names being converted from javax to jakarta.
Yes, Jakarta EE 9 is breaking, but is it practically a release people will actually adopt? It's more of a necessary step in the transfer process. It's perhaps a little like Java SE 9, which was released, but I don't think anyone ever used that, despite Java
SE 9 actually containing new features.
Jakarta EE 10 would be the *real* new version. Breaking compatibility, like Java SE 11 does as well, and would be intended to be actually used having new features, new APIs, and what have you. Indeed, compatibility can not be taken for granted anymore, but
that would not have been the case anyway. JSF for instance will remove JSP support and remote deprecated (Java) APIs, so won't be compatible anyway, package change or not.
In my view, Jakarta EE 9 is a somewhat unfortunate, but necessary process step to go through, one that we want to get done quickly. Although I'm as indicated above really a fan of improving packages like javax.resources and javax,jms, I got somewhat convinced
that Jakarta EE 9 isn't that one chance, but Jakarta EE 10 is.
All in all it remains a difficult decision, and both arguments (change now, or change in EE 10) have merit.
Kind regards.
Arjan
El jue., 30 may. 2019 20:06, arjan tijms <arjan.tijms@xxxxxxxxx> escribió:
Hi,
There's indeed a strong point for the utter simple mapping of just javax to jakarta. Although I remain of the opinion that it's also a unique chance to finally rectify some weirdness (like javax.resource for JCA, aka Connectors), there's definitely something
to say for a trivial mapping.
After some consideration, maybe for this release just javax to jakarta is best, and then per project consider additional changes for a later release.
Kind regards,
Arjan
On Thu, May 30, 2019 at 6:53 PM Alasdair Nottingham <alasdair.nottingham@xxxxxxxxx> wrote:
+1 with my developer hat on changing import statements is one thing, having to change type names which are sprinkled through my code, or method names would be horrific. Changing package name from javax.jakarta is always going to be simpler to automate because
I have to match on the right package name and then change javax to jakarta and I’m done. Automating where every package has a unique transform is more work because I need a mapping from one to the other so I’m very much in favour of just changing javax to
jakarta.
On May 30, 2019, at 11:45 AM, Martijn Verburg <martijnverburg@xxxxxxxxx> wrote:
+1 - let's minimise the confusion for the day to day developer here.
Cheers,
Martijn
On Thu, 30 May 2019 at 16:01, Kevin Sutter <sutter@xxxxxxxxxx> wrote:
Sorry, I should have include the link to Mike's post: https://www.eclipse.org/lists/jakartaee-platform-dev/msg00331.html
---------------------------------------------------
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
ee4j-pmc-bounces@xxxxxxxxxxxwrote on 05/30/2019 08:53:36 AM:
> From: "Kevin Sutter" <sutter@xxxxxxxxxx>
> To: EE4J PMC Discussions <ee4j-pmc@xxxxxxxxxxx>
> Date: 05/30/2019 08:53 AM
> Subject: [EXTERNAL] Re: [ee4j-pmc] Just changing javax to jakarta in
> package names
> Sent by: ee4j-pmc-bounces@xxxxxxxxxxx
>
> There is absolutely no requirement to change anything in the Package
> names other than "javax" to "jakarta". Thus, jms, jsp, jstl, jpa,
> ejb, etc can all by continued to use. This was clearly stated by
> Mike Milinkovich on one of the Platform-Dev threads...
>
> ---------------------------------------------------
> 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
>
> ee4j-pmc-bounces@xxxxxxxxxxxwrote on 05/30/2019 08:35:29
AM:
>
> > From: "Gergely Molnár" <gergelymolnarpro@xxxxxxxxx>
> > To: EE4J PMC Discussions <ee4j-pmc@xxxxxxxxxxx>
> > Date: 05/30/2019 08:35 AM
> > Subject: [EXTERNAL] Re: [ee4j-pmc] Just changing javax to jakarta in
> > package names
> > Sent by: ee4j-pmc-bounces@xxxxxxxxxxx
> >
> > Is JSP and JSLT affected too or Persistence (JPA)?
>
> > Best regards/Üdvözlettel,
> > Gergely Molnár
> >
> > arjan tijms <arjan.tijms@xxxxxxxxx> ezt írta (időpont: 2019.
máj.
> > 30., Cs 15:30):
> > > The spec names should change but not the package other than
> > replacing javax with jakarta. We already have a lot of work to do
> > with the transition without adding more overhead and honestly, I see
> > no benefit in changing the package names at all.
> >
> > I think there is a benefit, as mentioned that we only really get
> > this chance once. I do appreciate Kevin's concern for the ripple
> > effect, as indeed, every other change is just a small change on top
> > of the previous one. But all together it becomes bigger and bigger.
> >
> > That said, suppose we do indeed only change javax to jakarta, what
> > about packages that contain names that are not to be used anymore,
> > such as javax.jms? In that case I guess we *have* to change "jms" as
> > well, right?
> >
> > Kind regards,
> > Arjan
> >
> > On Thu, May 30, 2019 at 2:49 PM Martijn Verburg <martijnverburg@xxxxxxxxx
> > > wrote:
> > +1 to this - perhaps package names can be changed for Jakarta EE 9/10
> >
> > On Thu, 30 May 2019 at 13:27, Richard Monson-Haefel <rmonson@xxxxxxxxxxxxx
> > > wrote:
> > Just chiming in, I hope that is Ok.
> >
> > The spec names should change but not the package other than
> > replacing javax with jakarta. We already have a lot of work to do
> > with the transition without adding more overhead and honestly, I see
> > no benefit in changing the package names at all. People are used to
> > them, regardless of how strange they might be, and changing them
> > just adds to the confusion. I hope we don't do this on top of
> > everything else. Seems like a waste of resources and a great way to
> > create more issues.
> >
> > On Wed, May 29, 2019 at 4:03 PM Kevin Sutter <sutter@xxxxxxxxxx>
wrote:
> > Hi,
> > On a separate discussion thread, Bill Shannon and I were discussing
> > the proposed package renaming...
> >
> > > I trust this was just used as an example since there is no
> > requirement to change
> > > anything in the package name other than javax. If a component
> > wishes to change
> > > the package name (ie. javax.ws.rs.* to jakarta.rest.*), then they
> > are allowed
> > > to. But, I wouldn't recommend it. Keep the changes to a minimum.
> >
> > This is indeed a completely separate issue, but the direction from the PMC
> > so far has been to use package names that are more aligned with the new spec
> > names.
> >
> > I don't remember that we, as the PMC, were recommending to modify
> > the package names to be more aligned with the new spec names. And,
> > personally, I wouldn't recommend it. The more we change, the more
> > angst it produces for our customers. Just change javax to jakarta
> > and be done with it. (IMHO)
> >
> > ---------------------------------------------------
> > 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
> > _______________________________________________
> > ee4j-pmc mailing list
> > ee4j-pmc@xxxxxxxxxxx
> > To change your delivery options, retrieve your password, or
> > unsubscribe from this list, visit
> > https://www.eclipse.org/mailman/listinfo/ee4j-pmc
> >
> > --
> > Richard Monson-Haefel
> > https://twitter.com/rmonson
> > https://www.tomitribe.com/
> > _______________________________________________
> > ee4j-pmc mailing list
> > ee4j-pmc@xxxxxxxxxxx
> > To change your delivery options, retrieve your password, or
> > unsubscribe from this list, visit
> > https://www.eclipse.org/mailman/listinfo/ee4j-pmc
> > --
> > Cheers, Martijn (Sent from Gmail Mobile)
> > _______________________________________________
> > ee4j-pmc mailing list
> > ee4j-pmc@xxxxxxxxxxx
> > To change your delivery options, retrieve your password, or
> > unsubscribe from this list, visit
> > https://www.eclipse.org/mailman/listinfo/ee4j-pmc
> > _______________________________________________
> > ee4j-pmc mailing list
> > ee4j-pmc@xxxxxxxxxxx
> > To change your delivery options, retrieve your password, or
> > unsubscribe from this list, visit
> > https://www.eclipse.org/mailman/listinfo/ee4j-pmc
> > _______________________________________________
> > ee4j-pmc mailing list
> > ee4j-pmc@xxxxxxxxxxx
> > To change your delivery options, retrieve your password, or
> > unsubscribe from this list, visit
> > INVALID URI REMOVED
> >
> u=https-3A__www.eclipse.org_mailman_listinfo_ee4j-2Dpmc&d=DwICAg&c=jf_iaSHvJObTbx-
> > siA1ZOg&r=R9dtOS3afYnRUmu_zogmh0VnVYl2tse_V7QBUA9yr_4&m=gjPxrwWKDRlQeKy3uV7-
> > ogw1y1DVcEsEEeHrQSbAiF0&s=Zk1s1veBxkei3mflSpHu9SmRiUMTsWplsbKMsE16g2M&e=
> _______________________________________________
> ee4j-pmc mailing list
> ee4j-pmc@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or
> unsubscribe from this list, visit
> INVALID URI REMOVED
> u=https-3A__www.eclipse.org_mailman_listinfo_ee4j-2Dpmc&d=DwICAg&c=jf_iaSHvJObTbx-
> siA1ZOg&r=R9dtOS3afYnRUmu_zogmh0VnVYl2tse_V7QBUA9yr_4&m=qkXrixk609KgjQOn_WueHtz17ueFSb0rVz8qIw3zBV8&s=xgI6RUJQ5vZarwKD2Ei_wRifRkBIIYBpq_dLSLTxwGE&e=
_______________________________________________
ee4j-pmc mailing list
ee4j-pmc@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/ee4j-pmc
_______________________________________________
ee4j-pmc mailing list
ee4j-pmc@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/ee4j-pmc
_______________________________________________
ee4j-pmc mailing list
ee4j-pmc@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/ee4j-pmc
_______________________________________________
ee4j-pmc mailing list
ee4j-pmc@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/ee4j-pmc
_______________________________________________
ee4j-pmc mailing list
ee4j-pmc@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/ee4j-pmc
_______________________________________________
ee4j-pmc mailing list
ee4j-pmc@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/ee4j-pmc_______________________________________________
ee4j-pmc mailing list
ee4j-pmc@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/ee4j-pmc
