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