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
