| Re: [jakartaee-platform-dev] Transitioning Jakarta EE to the jakarta namespace |
Hi all,
I am application developer in java ee platform and i hope to be on the
future jakarta ee platform.
After reading initial proposal of David Blevins, i have preferred Big
Bang approach. My first idea was "we have one task, do it without
talking about if for ten years"
But i have readed several messages and blog posts. Thanks for all
contributions. It have permitted to show different view.
We know that java ee is too fat and certain specs must have pruned.
For example, if we have a new version of CDI. We must change all
dependencies specification.
I find this link for transitive dependencies :
https://github.com/eclipse-ee4j/jakartaee-platform/blob/master/namespace/transitive-dependencies.adoc
But this page that written manually. Do we have any dependency graph on
specification ? I think same dependency graph on JDK 9 (without modules)
For other example, Management API (JSR 88) should be pruned if we have a
consensus.
With Big Bang, we must change package for that? Why ?
Finally, i have concluded same idea that Steeve :
"Perhaps next step is to list the apis and the appetite for evolution
also indicate whether they could be frozen forever."
With this list, we have 20%, 50% 80% of new specifications and we could
take a decision more facility.
---
Best Regards,
Lilian BENOIT
Le 22/05/2019 13:14, Steve Millidge (Payara) a écrit :
> 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
> [1] and
> https://markclittle.blogspot.com/2019/05/to-enterprise-java-and-beyond-personal.html
> [2]
>
> 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 [3] Authorized Appraiser and Implementation Practitioner
> +1 647-676-3699
> http://www.pplupo.com [4]
>
> 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 [5] 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 [6]
>>>>> https://www.apress.com/us/search?query=Juneau [7]
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> 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
> [8]
>>>>>
>>>>> 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
> [9]
>>>>>
>>>>> _______________________________________________
>>>>> 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
> [9]
>>>>>
>>>>> _______________________________________________
>>>>> 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
> [9]
>>>>>
>>>>> _______________________________________________
>>>>> 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
> [9]
>>>>>
>>>>> _______________________________________________
>>>>> 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
> [9]
>>>>>
>>>>>
>>>>> --
>>>>> 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
> [9]
>>>>
>>>> _______________________________________________
>>>> 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
> [9]
>>>
>>>
>>> --
>>> 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 [9]
>>
>> _______________________________________________
>> 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 [9]
> _______________________________________________
> 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
> [9]_______________________________________________
> 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 [9]
>
> 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
>
> Links:
> ------
> [1]
> https://blog.hargrave.io/2019/05/jakarta-ee-and-package-renaming.html
> [2]
> https://markclittle.blogspot.com/2019/05/to-enterprise-java-and-beyond-personal.html
> [3] http://MPS.BR
> [4] http://www.pplupo.com/
> [5] http://jakata.ee
> [6] http://jj-blogger.blogspot.com
> [7] https://www.apress.com/us/search?query=Juneau
> [8]
> https://github.com/eclipse-ee4j/jakartaee-platform/pull/16/files?short_path=0c5b152#diff-0c5b1524ade3c5428f44f31bdf1d9815
> [9] 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