| Re: [jakartaee-platform-dev] Java EE Guardians Statement on Oracle/Eclipse Agreement |
|
Hello,
I have been following the developments here and was asked to add my two pennies worth...
On the subject of transitioning to the jakarta.* namespace
I don't see much value in going through an incremental transition because a start will be delayed by the inevitable discussions about where to start and how to go forward.
As a consumer of Java EE I can safely say going the Big Bang route will make a transition to Jakarta far easier. Constantly having to revisit and refactor in incremental releases would get tiring fast. Choosing Big Bang removes any delay on deciding where to start: do it all, start as soon as possible.
As Steve Millidge said, this is by no means an irreversible decision so if Big Bang becomes too cumbersome then an incremental approach is still possible. Indeed while Big Bang is being implemented planning for an incremental approach can and should be made in parallel in case a fall back is needed.
Now that my opinion on how to transition is known, what else?
MicroProfile
Because there is overlap in the APIs used in both Java EE and MicroProfile it makes sense to align MicroProfile and jakarta.* . It may even make sense to incorporate APIs in MicroProfile into jakarta.*, at least for Jakarta 10.
Deprecating "old" API's
We have an opportunity to begin the process of unburdening Jakarta 9 of previous enterprise API's. I can think of a number of them, JMS would make an excellent candidate as would the JSF Bean Annotations, which should never be used anyway. Marking out of date or even unused API's @Deprecated and ensuring that they will be removed in Jakarta 10 (or 11 if more lead time is necessary) ensures that developers like myself know how to proceed.
Tooling
A Big Bang approach will make it easier to build tools both to aid in refactoring and for run time binary compatibility. IDE's will also be able to tool up faster and also not have to track incremental Jakarta release. There are a whole host of other tools that would benefit from Big Bang, APM tools being one of a class of tool I use both in testing and in production environments.
How providers of API Implementations would benefit is less clear.
They will be able to anticipate a move to the jakarta.* namespace and have things ready when needed. Having said that having the jakarta.* namespace fully populated removes any worries about those API's they might need to wait for in the case of an incremental transition.
Thanks for reading/listening.
Andy Bailey Lead Developer Faktor Zehn GmbH Im Zollhafen 15/17 50678 Köln Phone +49 221 88826-332 Fax +49 221 88826-8332 Mobile +49 151 580 63831 Andy.Bailey@xxxxxxxxxxxxx http://www.ConVista.com Von: jakartaee-platform-dev-bounces@xxxxxxxxxxx <jakartaee-platform-dev-bounces@xxxxxxxxxxx> im Auftrag von Ryan Cuprak <rcuprak@xxxxxxxxx>
Gesendet: Montag, 3. Juni 2019 23:13 An: jakartaee-platform developer discussions Betreff: [jakartaee-platform-dev] Java EE Guardians Statement on Oracle/Eclipse Agreement Hello,
A heads-up to those on this list, the Java EE Guardians have published a statement on the agreement between Oracle and Eclipse:
Regards,
-Ryan
Faktor Zehn GmbH Sitz der Gesellschaft: München Registernummer: HRB 242535 Registergericht: Amtsgericht München Geschaeftsfuehrung: Dr. Florian Schwandt, Joerg Renger |