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
+1

On Tue, May 7, 2019 at 5:35 AM Greg Wilkins <gregw@xxxxxxxxxxx> wrote:

All,

tl;dr;  1 month is insufficient time to address the valid FUD about how to deal with this name change.

<FUD>
I think it is very easy to underestimate the effort that will be required to rename the APIs.   It is not as simple as just s/javax/jakarta/ in our code base.  Vendors will need to come up with migration strategies that will assist their users through a transition that will likely take years, so that legacy code can be deployed alongside new code.  We will face difficult decisions about cut-and-paste code duplication vs maintaining 2 slowly diverging implementations, neither is a clear winner.   I predict that many vendors development resources will be consumed by such a rename for years, stalling all other significant developments.    There are many small and large users that will not move for many years - if at all - and they will need to be supported.   Some vendors will face difficult decision about how much of their business is in supporting these suddenly legacy users and how much is chasing new customers on the new APIs.   Any automatic approaches used (eg automatic rewriting of byte code to the new name space), might work OK on day 1, but will be an ongoing resource suck as the jakarta APIs and behaviours diverge from javax.
</FUD>

So the FUD above may be able to be addressed/mitigated etc.  but I think June 9th deadline for making such a decision is way too aggressive, as before making any such decision we need to:
  • educate ourselves as to what exactly are the ramifications of a renaming APIs.
  • educate our users as to what the ramification of a rename could be
  • Give our users some time to evaluation these ramifications, cost and estimate the efforts and make some kind of decision of if/when they would be likely to switch.
  • Gather the feedback and estimates from those users.
  • Come up with some alternatives scenarios to evaluate against.
  • Discuss the feedback and alternatives within the individual projects/specifications expert groups.
  • Combine the results of those discussions in an architectural level discussion (here).
  • Probably iterate this process two or 3 times.
I simply do not see how this process can be done in a month.  As much as we'd like to rip this particular band-aid off, I think we need to take some time to consider, educate and bring our communities with us.   In a months time there are still going to be significant sections of our user base having WTF moments as they just discover this is an issue.

Putting my servlet hat on,  I see very little demand for any incremental changes to the API (we are a year late with our 4.0 release and not a single user has asked about it!).  On the other hand,  there is interest in more revolutionary change that could get rid of the cruft of decades and embrace current best practises and going to a new name space is a perfect opportunity to introduce such revolutionary change.... except if we start by polluting  that name space with all the legacy cruft of the current APIs, we will have lost that opportunity for a clean break and will have to try to evolve the spec within the context of decades old APIs.

regards


On Tue, 7 May 2019 at 09:12, Jorge Alejandro Cajas <jac.mota@xxxxxxxxx> wrote:
Hello everyone.

Keeping in mind what Jorge Vargas said, JavaEE7/JavaEE8 can be the "legacy" way to do things, and we should support them for some years from now as the industry has many applications made with JavaEE

But for the good of JakartaEE the feared big change is needed, Jakarta EE should be the new standard and evolve as needed starting with the big bang javax to jakartaee change.
One of the things about JavaEE we aways compalined about was the slow adoption of new standards and API, this is the moment to change that for good.

My 5 cents to this is for the Proposal No.1, a clean and quick cut to the javax namespace.
also I think this would be great  for new developers, as they can start learning from the jakartaEE specification and not for a wreid mix of javax / jakarta always changing API's if we took the Proposal 2.


Jorge Cajas |  @cajasmota
+502 54754892


On Mon, May 6, 2019 at 11:53 PM Jorge Vargas Garcia - Edivargas <edivargas@xxxxxxxxx> wrote:
Actually,

Thinking about transition from Java 8 to Java 11 and so, we have to be very worried to lost compatibility? We can stand working for JavaEE7 and JavaEE8 like still now? and we begin to work with JakartaEE8 like a big and new bird flying in the new sky?

My 5 cents.

BR

@edivargas - CTO weex
Oracle/SUN Java Champion
JUG's: www.javaup.org.mx
Mobile (+52) 55 3334 9115
       (+52) 55 7070 9866
Twitter/Google/Yahoo: edivargas
Facebook: https://www.facebook.com/EdivargasJVG


On Tue, May 7, 2019 at 12:46 AM Rudy De Busscher <rdebusscher@xxxxxxxxx> wrote:
Hi All,

The package name change needs to happen already in Jakarta EE 8.

If we wait until Jakarta EE 9 or later, hardly anyone will still use or consider Jakarta. When is Jakarta EE 9 scheduled? Maybe end of 2020 or later? That means that in a period of 3 years or more we didn't release anything new. One of the rules is that you should only consider an open-source library which is 'active'. I do not think that we fall in that category if we do not release something useful in a 3 year period!

The fastest, but with a breaking change, is proposal 1 - Big Bang (but now and not within a year or so). Replacing the import statements in the application code or a java agent within the runtime are easy to do!.

Regards
Rudy

On Tue, 7 May 2019 at 06:16, Edwin Derks <ederks85@xxxxxxxxx> wrote:
Hi all,

and big thanks David for starting this thread! I also would like to share my thoughts and have done so at my blog. Whatever the path we are going to take with this transition, I will try to assist wherever I can.

Thanks,

Edwin

On Tue, 7 May 2019 at 04:33, David Blevins <dblevins@xxxxxxxxxxxxx> wrote:
Great to hear from you!

> On May 6, 2019, at 7:22 PM, Hildeberto Mendonça <me@xxxxxxxxxxxxxx> wrote:
>
> A way to add value is not increasing the maintenance cost and preserving backwards compatibility. I'm afraid Proposal 1 would break these two values.
> I would prefer Proposal 2 if jakarta worked as a wrapper around javax, preserving the same interfaces, reusing what is already there and innovating on the wrapper side.

Both proposals involve what you would call "a wrapper" and have the same basic backwards compatibility challenge of having to figure out how to make old apps run.

The primary place they differ is:

 - do we break compatibility bit by bit over time in an as-needed basis
 - do we break compatibility in one shot and get it over with

The primary question here is as a user how do you want to deal with migrating and potential compatibility issues:

 - bit by bit over time
 - in one shot

Knowing neither path frees you from having to absorb a backwards incompatible change and the solutions would be the same, which timeline is your preferred?


-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
_______________________________________________
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