[
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
|
Renaming stuff and
then pruning it ... your P.S. made me laugh.
Where there's
stuff to prune, surely the worst reason to put that off is to rename it
first.
Regards,
Ian
From:
"Peter
P. Lupo" <pplupo@xxxxxxxxx>
To:
jakartaee-platform
developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Date:
23/05/2019
02:45
Subject:
Re:
[jakartaee-platform-dev] Transitioning Jakarta EE to the
jakarta namespace
Sent
by: jakartaee-platform-dev-bounces@xxxxxxxxxxx
I also think it should
be pruned. However:
1- I don't think
that now is the time to do it. We already have a big challenge (the whole
namespace issue, regardless of big bang or incremental approach).
2- The already long
delay is going to push developers away - going on a discussion about pruning
will certainly delay things substantially.
3- We are already
facing rejection because of the delay, the namespace issue will also be
a factor working against us and pruning will make things worse.
Pruning MUST come
with an upside, which is delivering more updates and/or faster. If we do
it now, no upside will be perceived. Also, we will be putting a big deal
breaker for anyone that wants to try the new stuff.
I mentioned pruning
before and I think that we should allow automatic migration to the new
namespace as much as possible BEFORE start pruning. This way we can allow
a smooth transition and only then we can start pruning. And honestly, I
think the version after the next one would be the best candidate for pruning
so we can shorten the period and deliver features that are likely to be
out on this one because it's already taking so long.
And I don't think
we should prune without a "frozen" period first, while stuff
still works but no enhancements are being made. This will allow some time
for applications to be adapted. Migrating with the big bang approach will
allow us to do just that. We keep everything working, deliver some enhancements,
tag some specs for pruning as a reason for not getting enhancements and
we will have between the upcoming version and the following one to adapt
applications before pruning.
Cheers.
P.S.: What do you
say to the breaking backward compatibility? Not today. (GOT reference -
sorry, I couldn't help myself).
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 Wed, May 22, 2019 at 4:52 PM Lilian
BENOIT <lilian.benoit@xxxxxxxxxx>
wrote:
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_______________________________________________
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