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 knew something was wrong in what I had understood. Thank you for the clarification. :-)

I didn't mean that we should treat Oracle as the ultimate evil, but if you want Java to be seen as a free platform, we need to act like it.

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 Fri, May 24, 2019 at 5:15 PM Lilian BENOIT <lilian.benoit@xxxxxxxxxx> wrote:
Hi,

Sorry, I misspoke on backward compatibility.
It's clearly a advantage of Java EE (and Jakarta EE on the future, i
hope)

I want say when we want upgrade an application to Java EE N to Java EE
N+1, It's not magic. It's a human action.
But It's a cost. That is why some applications servers supports multiple
versions of Java EE.

Currently, we have 2 two proposals : Big Bang or Incremental approach.

But we have no roadmap, no perspectives of evolution. To disengage from
Oracle as "ultimate evil" is not a goal of all community.
(disclaimer : I don't say that Oracle is "ultimate evil")

If we have one direction, if we known how many specifications evolve in
future, It would be easier to choose a scenario.

Perhaps, we have another proposal. We can add new specification as
Configuration, NoSQL and other without modification javaee
specification.

We will have a Java EE 9 with new features for developers and no problem
of backward compatibility.
In parallel, we could construct a new perspectives for Jakarta EE.

Regards,
Lilian.

Le 23/05/2019 15:27, Peter P. Lupo a écrit :
> "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 [1] Authorized Appraiser and Implementation Practitioner
> +1 647-676-3699
> http://www.pplupo.com [2]
>
> 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
>
>
> Links:
> ------
> [1] http://MPS.BR
> [2] http://www.pplupo.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

Back to the top