in my opinion they don't have to buy such an upgrade. at least they can make a new branch of their software and start migrating and testing on their local machines and so they can be prepare everything for the next feature release without stress.
and about the backwards compatibility i think it would also be easier in the Big-Bang scenario.
So the vendors have to implement this tool just once and have one release for testing with no other changes which could maybe have side-effects.
but i have no doubt that the vendors can keep their promises in fact if it's just a custom classloader they can easily test everything
i totally agree with you ryan about the upheavel in the java ecosystem
but in the incremental approach its just like david said with every jakarta release you have to learn the new transitions or make new technical depts
and aslong the vendors would support this namespace compatibility tool with the big-bang its up to the developers if they also make this transition at once OR incremental when they decide to use one of the new features ;)
Dominic
Another angle, with Big Bang, what happens to companies that have purchased an application container? Are they going to pay for an upgrade that includes just a namespace change?
Where I’ve had trouble upgrading application servers in the past has centered around the JSF UI stuff. For some old applications, EE upgrades have generally required an upgrade to the third party JSF component libraries. UI code tends to be a bit more fragile and the UI frameworks may not upgrade nicely (been my experience). Server-side code I haven’t run into too many issues.
I’d like to see the reference implementation (GlassFish) tackle the name spacing first. How hard will it be for GlassFish to support both EE 8 and EE 9 (assuming 9 has a different namespace)? To me this debate has been somewhat abstract. The impact of the refactoring is going to depend upon application complexity. Some organizations are deploying multiple applications to containers (which by different groups on different schedules) which communicate via RMI etc.
Separately, I think the Java ecosystem is going through a bit of upheaval at the moment with getting code running on post Java 8. With Java 9, the technical debt bill came due. Do we want to throw a namespace challenge into the mix at the moment when companies are grappling with transitioning to Java 11?
Just curious, why aren’t the individual specs making the decision on when they jump to the new namespace?
-Ryan
> On May 10, 2019, at 3:38 PM, domi <dbuechner93@xxxxxxxxx> wrote:
>
> I totaly agree with you guys.
>
> another point why i prefer the BIG-BANG transition is that after that step you can say IT'S DONE and build jakarta ee on a "carefree base".
>
> Dominic
>
> Am 10.05.19 um 18:54 schrieb Mark Struberg:
>> And even worse: we would break backward compat with every Jakarta EE release :(
>>
>> LieGrue,
>> strub
>>
>>> Am 10.05.2019 um 14:33 schrieb David Blevins <dblevins@xxxxxxxxxxxxx>:
>>>
>>>> On May 10, 2019, at 8:55 PM, Richard Monson-Haefel <rmonson@xxxxxxxxxxxxx> wrote:
>>>>
>>>> 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?
>>> Here's where they're the same:
>>>
>>> Jakarta EE 9 comes out and it is some mix of javax and jakarta. You must learn the mix.
>>>
>>> Here's where they're different:
>>>
>>> Big Bang: Jakarta EE 10 comes out. You already learned the mix, you're good.
>>>
>>> Incremental: Jakarta EE 10 comes out. Forget the old mix, learn the new one. Also update your source code again.
>>>
>>>
>>> And worse case...
>>>
>>> Big Bang: Jakarta EE 11 comes out. You already learned the mix, you're good.
>>>
>>> Incremental: Jakarta EE 11 comes out. Forget the old mix, learn the new one. Hope you have any chance of keeping it straight. Hope your boss doesn't get mad when you tell her you have to migrate source again to use a new feature.
>>>
>>>
>>> -David
>>>
>>> _______________________________________________
>>> 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
> _______________________________________________
> 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
