Re: [ee4j-pmc] Just changing javax to jakarta in package names

["Kevin Sutter" <sutter@xxxxxxxxxx>]

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