| Re: [jakarta.ee-community] Jakarta EE 9 APIs - what's required? what's allowed? |
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.ThanksEmily
On Wed, Feb 12, 2020 at 2:54 PM Kevin Sutter <sutter@xxxxxxxxxx> wrote:
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
--
Thanks
Emily
_______________________________________________ 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$