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?
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"?
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.
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
|
