|
+1 to this proposal.
Some more thoughts:
Jakarta EE 9 is a big-bang namespace change (ideally only javax
to jakarta). It will also introduce a binary converter making
possible running old apps on the new platform.
Jakarta EE 10 may introduce more changes in package names and new
functionality. The binary converter (stable at that time) is
updated reflecting package/class names changes.
We are targeting to a fast release cadence. I believe that
Jakarta EE 10 may be released relatively quick after Jakarta EE 9.
It makes sense to start working on Jakarta EE 10 before Jakarta EE
9 completion.
-- Dmitry
On 30.05.2019 23:41, arjan tijms wrote:
Hi,
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
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
+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.
+1 - let's minimise the
confusion for the day to day developer
here.
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@xxxxxxxxxxx
wrote
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@xxxxxxxxxxx
wrote 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
> > https://urldefense.proofpoint.com/v2/url?
> >
>
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
> https://urldefense.proofpoint.com/v2/url?
>
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
|
