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