[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [jakarta.ee-community] Jakarta EE 9 APIs - what's required? what's allowed?
|
If an annotation doesn't make sense to be repeated, then @Repeatable
should
never be added to it.
Emily Jiang wrote on 2/12/20 3:35 PM:
I would also leave @Repeatable to Jakarta EE10 as some
annotations don't make sense to be repeatable. This will
require discussion before this addition should be performed,
as it causes behaviour change. As for @Deprecated, since
javadoc marks so, it is easier to manage and does not affect
functionality.
Thanks
Emily
Based on all
of the
discussion related to the semi-defined usage of generics,
maybe we should
wait to introduce the use of generics into the APIs until
Jakarta EE 10?
It just seems like there are too many questions to be
answered before
we make this decision. We can still do the @Deprecated and
@Repeatable
in Jakarta EE 9, but wait for the introduction of generics
until Jakarta
EE 10. Thoughts?
---------------------------------------------------
Kevin Sutter
STSM, MicroProfile and Jakarta EE architect @ IBM
e-mail: sutter@xxxxxxxxxx Twitter:
@kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)
LinkedIn: https://www.linkedin.com/in/kevinwsutter
From:
arjan
tijms <arjan.tijms@xxxxxxxxx>
To:
Jakarta
EE community discussions <jakarta.ee-community@xxxxxxxxxxx>
Date:
02/12/2020
08:47
Subject:
[EXTERNAL]
Re: [jakarta.ee-community] Jakarta EE 9 APIs - what's
required? what's
allowed?
Sent
by: jakarta.ee-community-bounces@xxxxxxxxxxx
Hi,
On Wed, Feb 12, 2020 at 3:04 PM
Steve
Millidge (Payara) <steve.millidge@xxxxxxxxxxx> wrote:
I’m still a little nervous about
Map
to Map<String,String> for example
Rather than Map to Map<?,?>
mainly
due to the impact on code of those using those methods.
When we are discussing generics
are we
discussing narrowing the types or using unbounded generics?
The <String, String> was
just as
example, practically many instances are actually
Map<String, ?>,
for example here:
https://github.com/eclipse-ee4j/authentication/blob/master/api/src/main/java/jakarta/security/auth/message/MessageInfo.java#L72
It's now Map getMap(); but it
should
have been Map<String, ?> getMap();
I do agree that there could have
been,
theoretically, code that misused the implied String key type
and for proprietary
purposes used another type as key.
I still think we should
eventually narrow
the type correctly, but let's not do it for Jakarta EE 9, at
least not
for Jakarta Authentication. I'll start a proper discussion
about this on
the authentication list first.
Thanks!
Kind regards,
Arjan
From: jakarta.ee-community-bounces@xxxxxxxxxxx<jakarta.ee-community-bounces@xxxxxxxxxxx>
On Behalf Of Werner Keil
Sent: 12 February 2020 11:51
To: Jakarta EE community discussions <jakarta.ee-community@xxxxxxxxxxx>
Subject: Re: [jakarta.ee-community] Jakarta EE 9 APIs
- what's required?
what's allowed?
What about the extra layer of
"security.enterprise"
that must be done in Jakarta EE 9?
Do you still see a value in the
new Jakarta
EE namespaces or is it more of a "hack" we had to introduce
in
Java EE 8 but no longer need after being separated from
"javax"?
Regards,
Werner
arjan tijms <arjan.tijms@xxxxxxxxx>
schrieb am Mi., 12. Feb. 2020, 12:31:
Hi,
I asked for this for Jakarta
Authentication.
As mentioned in the original post about this, it's not a big
deal for me.
If it's allowed or even expected, I can add the missing
generics (e.g.
Map to Map<String, String> in method arguments),
otherwise Jakarta
EE 10 is fine too.
Kind regards,
Arjan
On Wed, Feb 12, 2020 at 9:51 AM
Mark
Thomas <markt@xxxxxxxxxx>
wrote:
On 11/02/2020 20:07, Markus KARG
wrote:
> I think that generics should be allowed as long as they
are unbounded.
> -Markus
+1. That should be sufficient to fix most if not all of the
"missing
generics" issues in the projects I'm involved in.
Mark
>
> -----Ursprüngliche Nachricht-----
> Von: jakarta.ee-community-bounces@xxxxxxxxxxx
> [mailto:jakarta.ee-community-bounces@xxxxxxxxxxx]
Im Auftrag von Bill
> Shannon
> Gesendet: Dienstag, 11. Februar 2020 21:00
> An: Jakarta EE community discussions
> Betreff: [jakarta.ee-community] Jakarta EE 9 APIs -
what's required?
what's
> allowed?
>
> At the Jakarta EE Platform project team meeting this
morning, we discussed
> several items related to what sorts of changes are
required and allowed
in
> Jakarta EE 9 APIs.
>
> The question was what changes, if any, should be
allowed by the base
> Jakarta EE 9 release plan, without requiring a separate
release plan?
>
>
> - package names
>
> It should be obvious to everyone that a required change
is the change
from
> javax.* packages to jakarta.* packages. That was
easy.
And in fact that
> was the original goal, that the package name change
would be the *only*
> change allowed to the APIs. In addition, only the
"javax"
part of the name
> may be changed; no other part of the class name may be
changed.
>
>
> - @Deprecated
>
> Is it allowed to add @Deprecated to APIs? We decided
that yes,
if the API
> was already marked with the javadoc @deprecated, the
@Deprecated annotation
> may be added.
>
>
> - generics
>
> May APIs be "genericized", i.e., may the APIs be
updated
to use generics
> where appropriate? This one was not clear to us and
we'd like
more feedback
> from the community.
>
> On the one hand, the change of package name is already
a source incompatible
> change so adding another source incompatible change is
not a big deal.
Any
> binary compatibility tools would not need to deal with
it. We
think that
> the major IDEs will be able to help with the source
incompatibility.
>
> On the other hand, not everyone is using an IDE, and
this will be
another
> annoying change that's harder to apply in some
automated way.
Perhaps this
> should be deferred to Jakarta EE 10?
>
> A complicating factor is that we haven't yet decided
what sorts of
API
> changes
> we will allow in future Jakarta EE releases. Perhaps
changes
of this sort
> will be limited to "LTS" releases? We just don't know
yet.
>
> So, given all the uncertainty and variables, do you
think we should
allow
> generics to be applied to APIs for the Jakarta EE 9
release?
>
>
> - @Repeatable
>
> Should we allow the addition of @Repeatable to APIs,
where appropriate?
> We decided that yes, this is allowed. Most of the
cases where
@Repeatable
> was appropriate were dealt with in Java EE 8, but if
some cases were
missed
> now is a good time to fix them.
>
>
> - property names
>
> Finally, while not strictly an API change, we decided
that any properties
> defined by a spec that are named "javax.*" *MUST* be
changed
to "jakarta.*".
> Obviously this is another issue that any binary
compatibility solution
> will need to deal with, so in some cases it may be best
for the runtime
> to support both jakarta.* and javax.* property names,
with the former
taking
> precedence.
>
>
>
> If there are additional items of this sort that you
think the platform
team
> should consider, please let me know.
>
> Remember that even changes that are disallowed above
*may* be allowed
for
> a specific API based on the requirements and
justification included
in a
> separate release plan for that API. This has already
been done
in at least
> two cases - Jakarta Activation and Jakarta Enterprise
Beans.
> _______________________________________________
> jakarta.ee-community mailing list
> jakarta.ee-community@xxxxxxxxxxx
> To change your delivery options, retrieve your
password, or unsubscribe
from
> this list, visit
> https://www.eclipse.org/mailman/listinfo/jakarta.ee-community
>
> _______________________________________________
> jakarta.ee-community mailing list
> jakarta.ee-community@xxxxxxxxxxx
> To change your delivery options, retrieve your
password, or unsubscribe
from this list, visit
> https://www.eclipse.org/mailman/listinfo/jakarta.ee-community
>
_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe
from this list, visit
https://www.eclipse.org/mailman/listinfo/jakarta.ee-community
_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe
from this list, visit
https://www.eclipse.org/mailman/listinfo/jakarta.ee-community
_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To change your delivery options, retrieve your password,
or unsubscribe
from this list, visit
https://www.eclipse.org/mailman/listinfo/jakarta.ee-community_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To change your delivery options, retrieve your password,
or unsubscribe
from this list, visit
https://www.eclipse.org/mailman/listinfo/jakarta.ee-community
_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jakarta.ee-community
--
_______________________________________________
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/jakarta.ee-community__;!!GqivPVa7Brio!Pwh7KqmUujumirG9uayuOdJ8iTj-my3GsfHQ06-LEuVVLP9DV4IkRGPlHNVZPA2tbw$