Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakartaee-platform-dev] Transitioning Jakarta EE to the jakarta namespace

I think as a Community we should focus on to push Jakarta EE forward with the Speed needed to stay update with new market expect and needs.

I know that backward compatibility is desirable and is an important thing and I think we should keep that in mind for future releases but, the situation we are facing now was not created by us or by Eclipse Foundation.

So, I think we should invest effort and time to do the necessary changes to move from javax.* to jakarta.* (going for the big bang approach) and make clear to all that, to run Applications keeping the compatibility, the user would continue to use Jakarta EE 8 and, of course, to keep update with this new project momentum and receive new features, everybody should make an effort to migrate their Applications to run on Jakarta EE 9.

Maybe we should had a strong commitment to offering help (for those who needs it), writing blog posts, books, making videos, doing online code review sessions and help anybody that face problems with that migration process.

If we detect that there are old dependencies that, for example, doesn't have code available anymore or not have the original maintainers, maybe it's the right time to face that problem and fix it (if possible). Otherwise, we'll keep facing problems related to this package limitation thing on the future.

To help others with the same migration issues that will come, we could create an GitHub repository with common problems facing by the community during the migration and with the solutions taken (or simple put the link to Stackoverflow question).

Silvio Silva

Em qui, 23 de mai de 2019 às 10:28, Peter P. Lupo <pplupo@xxxxxxxxx> escreveu:
"Backward compatibilily is present if we change only package name. But if 
specification evolve, we have same issue that upgrading Java EE 7 and 
Java EE 8 : Not tools and human intervention."

Unless I didn't understand correctly (forgive me if that's the case), it doesn't sound true. JEE7 is backward compatible with JEE6 and it is an evolution.

People will want the 1:1 because they will want to leave the javax/oracle space.
Also, it may get very complicated to evolve some specs that may depend on code on javax if we can't modify javax code and we don't have jakarta parity to rely on.
Load time mapping from javax to jakarta will be much more complicated. It may cause delays to deliver JEE9.

Peter P. Lupo
Software Engineer, M.Sc.
Certified ScrumMaster / Sun Certified Associate for Java Platform
MPS.BR Authorized Appraiser and Implementation Practitioner
+1 647-676-3699
http://www.pplupo.com


On Thu, May 23, 2019 at 7:48 AM Lilian BENOIT <lilian.benoit@xxxxxxxxxx> wrote:
Hi,

We don't 1:1 mapping. Tools must use list of packages. (cf.
https://github.com/eclipse-ee4j/jakartaee-platform/blob/master/namespace/unaffected-packages.adoc)
Why couldn't we add javax.ejb in list if this specification haven't
evolved ? or javax.servlet for jetty ?

Backward compatibilily is present if we change only package name. But if
specification evolve, we have same issue that upgrading Java EE 7 and
Java EE 8 : Not tools and human intervention.

---
Regards,
Lilian BENOIT.

Le 23/05/2019 12:17, Greg Wilkins a écrit :
> On Thu, 23 May 2019 at 10:53, Ian Robinson <ian_robinson@xxxxxxxxxx>
> wrote:
>
>> Renaming stuff and _then _pruning it ... your P.S. made me laugh.
>>
>> Where there's stuff to prune, surely the worst reason to put that
>> off is to rename it first.
>
> If that was all that was going on, then I would agree
> wholeheartedly.... but the need to support backwards and binary
> compatibility means there is a benefit to having a 1:1 mapping from
> javax to jakarta APIs.     If porting tools have to cope with renaming
> and pruning deprecated methods or even updating to newer APIs then
> they won't be fully automatic and humans will need to get involved.
>
>  A 1:1 mapping gives the prospect that a tool can do a rename on the
> code or binary and it will just work as expected without any human
> intervention.
>
> cheers
>
>  --
>
> Greg Wilkins <gregw@xxxxxxxxxxx> CTO http://webtide.com
> _______________________________________________
> 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

Back to the top