I would also think that that's the biggest advantage of the Big
Bang approach is to not have to distinguish between the old and
the new namespace, since everything would wholesale move to the
jakartaee. That would very much simplify tooling, too.
A caveat might be javax.* classes that live in Java SE, but even
those could be copied over.
Regards
/Dimitris
On 10/05/2019 13:55, Richard Monson-Haefel wrote:
I'm having trouble understanding the difference
between Big Bang and Incremental proposals with regard to what
I think is a key issue: The mixing of javax and jakarta
namespaces in a single application. In the github proposal
for Incremental, it says over and over again that the result
would be mixed namespaces. But the Big Bang never says that
yet it does say "Any packages not moved from javax to jakarta
could be included in Jakarta EE, but would be forever frozen
and never move to the jakarta namespace." which is exactly
the same thing, right? So if Big Bang allows for mixing of
namespaces why doesn't the proposal for that say so? What am
I missing?
The cons for Incremental go a long way to arguing that this
mixing is an issue, yet the Big Bang, if that proposal as
written in github is followed, does not. I think we need to
decide if Big Bang allows mixing or not. It's been my
understanding that Big Bang moves EVERYTHING over not just
what we think matters. That is also a key difference that
seems to get lost with that one statement I quoted above.
I could have captured this in a JIRA ticket, I suppose, but
I think it would simply be lost and never discussed.
My intention was to motivate you to help fill
out that doc to cover the issues you're concerned
about.
Are you up for helping develop the backwards
compatibility concept?
Yes - but it's taking me a while to come up with my
own mental topology of options. We are working on some
internal stuff at the moment and I'll try to generalise
that and send a PR in the next few days.
I agree with you 100%. Five more emails of awesome
points in, and I'll still probably agree with you :)
Nah! Actually it is going to other way! I started
off pretty much opposed to the big bang rename, but now
I'm tending to think we will never be able to avoid the
consequences so ripping the bandaid off may well be
best. It is a pity we will lose resources/time to
innovate, but on the other hand a clean slate name space
doesn't make great new APIs pop into existence either,
nor exempt us from an obligation to deal with
backwards/binary compatibility. As Bill says in his
reply, changing the name space doesn't really change how
we support version-to-version and if we really wish to
break compatibility for some new ideas, there is plenty
(infinite) of space under the jakarta.* top level for
new APIs and we can apply @deprecated to "legacy" ones
if we choose to (hmmm perhaps "classic" might be better
than "legacy":)
A doc of options with pros/cons is great.
Doesn't have to be complete, just needs to be enough
to get the ball rolling.
Yep - I think defining transition strategies and
technologies is key - for big bang and incremental.
I'll try to roll the ball a little in the next few days
and I promise you it wont be complete.
cheers
--
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
--
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
|