| Re: [jakartaee-platform-dev] Transitioning Jakarta EE to the jakarta namespace |
_______________________________________________Ultimately I believe which way to go depends on the number of current javax specifications we believe will be evolved in the short to medium term. If the number is high then big bang is the best approach as will minimise future pain. If the number is low then incremental will inflict the lowest pain.
Defining the threshold and evolving apis will determine the best outcome.
For example, purely as a strawman, if 80% of current javax apis are likely to evolve in JakartaEE.next then Big Bang is a better approach as we may as well identify the forever frozen and move the rest. Aternatively if 10% of current javax apis are likely to evolve in JakartaEE.next then incremental is probably the easier and simpler approach.
Perhaps next step is to list the apis and the appetite for evolution and also indicate whether they could be frozen forever.
Steve
From: jakartaee-platform-dev-bounces@xxxxxxxxxxx <jakartaee-platform-dev-bounces@xxxxxxxxxxx> On Behalf Of Ian Robinson
Sent: 21 May 2019 20:22
To: jakartaee-platform developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Subject: Re: [jakartaee-platform-dev] Transitioning Jakarta EE to the jakarta namespace
As Peter says, future API evolution in the example below, with compatibility, has the same burden either way. "Done in minutes", even if that were the case, would be an implementers perspective. The large number of consumers of Java EE (who pay my bills) will likely not be so accepting of unnecessary breaking of backward compatibility for all the stuff that isn't changing - we might find that Big Bang is neither quickly forgotten nor forgiven by the people who just use Java EE even if we manage to get over it ourselves "in minutes". Surely we should take this broader "community cost" into consideration as well and not just relegate it to providing blanket migration mitigation. Much of this has been said before and laid our more fully in posts like https://blog.hargrave.io/2019/05/jakarta-ee-and-package-renaming.html and https://markclittle.blogspot.com/2019/05/to-enterprise-java-and-beyond-personal.html
Regards,
Ian
From: "Markus KARG" <markus@xxxxxxxxxxxxxxx>
To: "'jakartaee-platform developer discussions'" <jakartaee-platform-dev@xxxxxxxxxxx>
Date: 21/05/2019 17:08
Subject: Re: [jakartaee-platform-dev] Transitioning Jakarta EE to the jakarta namespace
Sent by: jakartaee-platform-dev-bounces@xxxxxxxxxxx
With the big bang the migration path is at most simple: Search all files for "import javax." and replace by "import jakarta.". Done in minutes. Exactly once. Finished for all times! And after that we evolve the API frictionless as we did in the past. Not "once per release of Jakarta per some of the packages but not for others". So the problem I describe does *not* exist with the BB.
-Markus
From: jakartaee-platform-dev-bounces@xxxxxxxxxxx [mailto:jakartaee-platform-dev-bounces@xxxxxxxxxxx] On Behalf Of Peter P. Lupo
Sent: Dienstag, 21. Mai 2019 13:37
To: jakartaee-platform developer discussions
Subject: Re: [jakartaee-platform-dev] Transitioning Jakarta EE to the jakarta namespace
Markus, the problem you are citing exists whether we go with big bang or not. It's inherit to API evolution and backward compatibility.
We should, nevertheless, provide migration. Even if it is to promote a platform free from Oracle's claws - or people won't see it as free.
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 Tue, May 21, 2019 at 4:38 AM Emmanuel Bernard <ebernard@xxxxxxxxxx> wrote:
+1
Your new API for say JPA would create a jakarta.ee.EntityManager which
would point to javax.persistence.Query as a return type. Then a few
versions later you need to enhance Query hence create jakarta.ee.Query
and boom, you need to change jakarta.ee.EntityManager in a possibly non
backward compatible way. Better stick to the binary model.
If you generalize this problem as MArk or MArkus said, it is likely
better to big bang and avoid these cross spec out of sync updates.
On 21 May 2019, at 9:44, Mark Struberg wrote:
> Agree with Markus. And it will simply not work technically as it would
> create incompatible versions of interfaces. They would cross-reference
> each other, and the result would be tons of wrapper classes all
> around. That's just very ugly and will not work out imo.
> It's not practicable. See the OptionA in my blog post where I pointed
> out that even extending interfaces and abstract classes will often
> just not work.
>
> LieGrue,
> strub
>
>
>> Am 21.05.2019 um 07:16 schrieb Markus KARG <markus@xxxxxxxxxxxxxxx>:
>>
>> For the end user it makes no difference as he still has to change the
>> package name once a new parameter is added to an existing method, or
>> once a new class is introduced, whether you use a new API project or
>> change the old API project. It makes extending the existing spec
>> really complicated, as you have to cross package boundaries now, what
>> might not be possible, as some of the existing "internal" classes are
>> not public (API-internal utilities etc.), so you effectively have to
>> copy them. As this happens more often than not, you still have
>> ongoing changes to the existing applications and a lot of trouble.
>> -Markus
>>
>> From: jakartaee-platform-dev-bounces@xxxxxxxxxxx
>> [mailto:jakartaee-platform-dev-bounces@xxxxxxxxxxx] On Behalf Of
>> Emily Jiang
>> Sent: Dienstag, 21. Mai 2019 00:23
>> To: jakartaee-platform developer discussions
>> Subject: Re: [jakartaee-platform-dev] Transitioning Jakarta EE to the
>> jakarta namespace
>>
>> Mark,
>> I am not sure I understand your point completely. Let me try to
>> explain what I think your comments are. In my approach (MicroProfile
>> approach), we have this dependency demonstrated already. For example,
>> MP Rest Client depends on JAX-RS, CDI etc. If Rest Client requires
>> CDI to be updated, we will create jakarta CDI 1.0. Rest Client will
>> depends on jakarta CDI 1.0, which then depends on CDI.
>>
>> Another advantage with my suggestion (MP approach) is that:
>>
>> No more time spending on packaging renaming, rerunning tcks, etc.
>> Either big bang or incremental approach will need to rename packages
>> first. For Big Bang, it will need at least some months to get all
>> APIs renamed including the dormant ones. This will further delay spec
>> updates. We have spent good effort for the massive move already. It
>> is time to develop the specs not spending more time to do the
>> renaming.
>>
>> For MP approach, we can start new spec update now. We can propose new
>> CDI updates to EFSP (Eclipse Foundation Spec Process) and create a
>> new repo for the new changes. No op for renaming, no op for existing
>> apps, no op for runtime. Time to move on...
>>
>> Thanks
>> Emily
>>
>> On Mon, May 20, 2019 at 1:02 PM Mark Struberg <struberg@xxxxxxxxxx>
>> wrote:
>>> The problem why this doesn't work is that there are quite a few
>>> cross-references between specs.
>>>
>>> E.g. if you want to do anything in javax.el you would also need to
>>> touch CDI.
>>> That's because the BeanManager has a reference to
>>> javax.el.ExpressionFactory.
>>> Just one simple example, but there are quite a few such.
>>>
>>> LieGrue,
>>> strub
>>>
>>>> Am 20.05.2019 um 10:48 schrieb Emily Jiang
>>>> <emijiang6@xxxxxxxxxxxxxx>:
>>>>
>>>> Don't forget in big band approach, you will need to update the
>>>> namespace straightaway no matter whether you will need to use the
>>>> potential update or not. In my approach, you will need to import
>>>> the new package when you need to use it. Otherwise, it is noop.
>>>>
>>>> Thanks
>>>> Emily
>>>>
>>>> On Sun, May 19, 2019 at 3:51 PM Markus KARG
>>>> <markus@xxxxxxxxxxxxxxx> wrote:
>>>> This is not true. The big bang allows to extend the existing
>>>> packages once they are renamed. This means, once an application is
>>>> migrated, now *new* packages are needed to be imported at a later
>>>> time.
>>>>
>>>> -Markus
>>>>
>>>>
>>>>
>>>> From: jakartaee-platform-dev-bounces@xxxxxxxxxxx
>>>> [mailto:jakartaee-platform-dev-bounces@xxxxxxxxxxx] On Behalf Of
>>>> Emily Jiang
>>>> Sent: Sonntag, 19. Mai 2019 16:39
>>>> To: jakartaee-platform developer discussions
>>>> Subject: Re: [jakartaee-platform-dev] Transitioning Jakarta EE to
>>>> the jakarta namespace
>>>>
>>>>
>>>>
>>>> Not really. My point is no different from Big Bang or incremental
>>>> approach when it comes to consume new updates. All of the
>>>> approaches require importing new packages.
>>>>
>>>> Emily
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On May 18, 2019 at 5:27 pm, <Markus KARG> wrote:
>>>>
>>>> Your idea would cut off all existing apps from easily adopting
>>>> minor enhancements of existing APIs and would enforce to migrate to
>>>> completely new APIs, which is more work and higher risk than simply
>>>> once change the imported package names. Typically existing apps are
>>>> not maintained just to get free of bugs but also to adopt these
>>>> small enhancements, and nobody wants to rewrite his app from
>>>> Jakarta API to Microprofile API just to have one new parameter in a
>>>> method.
>>>>
>>>> -Markus
>>>>
>>>>
>>>>
>>>> From: jakartaee-platform-dev-bounces@xxxxxxxxxxx
>>>> [mailto:jakartaee-platform-dev-bounces@xxxxxxxxxxx] On Behalf Of
>>>> Emily Jiang
>>>> Sent: Samstag, 18. Mai 2019 18:05
>>>> To: jakartaee-platform developer discussions
>>>> Subject: Re: [jakartaee-platform-dev] Transitioning Jakarta EE to
>>>> the jakarta namespace
>>>>
>>>>
>>>>
>>>> We discussed Big Bang and incremental approach so far. Both of them
>>>> have pros and cons. How about we do something in between:
>>>>
>>>> Directly lock javax JSRs. For any new update related to a
>>>> particular JSR, just start the new changes under Jakarta EE
>>>> namespace without changing the existing APIs. For an example,
>>>> MicroProfile Rest Client is an update to Rest client. MicroProfile
>>>> context propagation is an update on Concurrence JSR. In
>>>> MicroProfile, we create new APIs without changing any Java EE
>>>> specs. We can use this approach for Jakarta EE spec updates. The
>>>> only difference is to use jakata.ee namespace. In this way, we can
>>>> directly create any APIs.
>>>>
>>>> I think changing the current javax either Big Bang or incrementally
>>>> will impact existing users. As you may know, some old libs may not
>>>> have the source available any more. I think what I recommend does
>>>> not impact any existing apps.
>>>>
>>>> My 2cents
>>>>
>>>> Thanks
>>>>
>>>> Emily
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On May 18, 2019 at 3:10 pm, <Peter P. Lupo> wrote:
>>>>
>>>> All the points made in favor of the big bang so far are pretty
>>>> relevant and good points. I also agree with the big bang. I like
>>>> the idea of providing an alternative to the existing API so we can
>>>> provide a tool to migrate the existing applications but I would
>>>> only go this far in terms of keeping existing functionality.
>>>>
>>>> Truth being told, Java EE needs pruning. The more features we add,
>>>> greater is the effort to keep backward compatibility, making
>>>> enhancements costly.
>>>>
>>>> We could provide a Jakarta.legacy package for equivalence and start
>>>> fresh under Jakarta.*, keeping what is useful, adding new stuff and
>>>> removing stuff like ejb older than 3.1, etc...
>>>>
>>>>
>>>>
>>>> On Sat, May 18, 2019, 09:49 Josh Juneau <juneau001@xxxxxxxxx>
>>>> wrote:
>>>>
>>>> An area that I don't think has been mentioned yet is documentation.
>>>> Sorry if it has and I've missed it. If we take a step back and
>>>> look through the eyes of the everyday user, I believe it would be
>>>> very cumbersome and confusing to have books, tutorials, and
>>>> articles that contained different namespaces due to an incremental
>>>> approach. The users would really have to be on top of the versions
>>>> they are using while reading and trying to learn.
>>>>
>>>>
>>>>
>>>> The big bang approach, in my opinion, would make learning a bit
>>>> easier from a users perspective. If they were to pick up a book
>>>> written on Jakarta EE 9, then all package renames would be
>>>> documented...and the book would still be relevant down the road
>>>> when Jakarta EE 10 or 11 are released. It would be almost as if
>>>> Jakarta EE 9+ is a completely new platform...a fresh start, as
>>>> others have said.
>>>>
>>>>
>>>>
>>>> If we were to choose an incremental approach, it seems that books
>>>> and tutorials would almost be obsolete each time a new release
>>>> comes out.
>>>>
>>>>
>>>>
>>>> Thanks for reading.
>>>>
>>>>
>>>>
>>>> Josh Juneau
>>>> juneau001@xxxxxxxxx
>>>> http://jj-blogger.blogspot.com
>>>> https://www.apress.com/us/search?query=Juneau
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Fri, May 17, 2019 at 10:58 AM Rieon Ke <rieon@xxxxxxxx> wrote:
>>>>
>>>>
>>>> Hello,
>>>>
>>>> I have opened a PR to add transitive dependencies list,
>>>>
>>>> https://github.com/eclipse-ee4j/jakartaee-platform/pull/16/files?short_path=0c5b152#diff-0c5b1524ade3c5428f44f31bdf1d9815
>>>>
>>>> Am I heading in the right direction? is this what we want?
>>>>
>>>>
>>>>
>>>> Rieon
>>>>
>>>> _______________________________________________
>>>> 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
>>>>
>>>>
>>>> --
>>>> Thanks
>>>> Emily
>>>> =================
>>>> Emily Jiang
>>>> ejiang@xxxxxxxxxx
>>>> _______________________________________________
>>>> 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
>>
>>
>> --
>> Thanks
>> Emily
>> =================
>> Emily Jiang
>> ejiang@xxxxxxxxxx
>> _______________________________________________
>> 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
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
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