[
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?
|
Let's see how this
discussion plays out before making or reverting any generics-related updates...
---------------------------------------------------
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/kevinwsutterFrom:
arjan
tijms <arjan.tijms@xxxxxxxxx>To:
Jakarta
EE community discussions <jakarta.ee-community@xxxxxxxxxxx>Date:
02/12/2020
08:59Subject:
[EXTERNAL]
Re: [jakarta.ee-community] Jakarta EE 9 APIs - what's required? what's
allowed?Sent
by: jakarta.ee-community-bounces@xxxxxxxxxxx
Hi,Absolutely fine with me, though notice
that in _expression_ Language we already made that change (the, I think,
non-controversial unbounded one);https://github.com/eclipse-ee4j/el-ri/commit/1e9f39fa6e584fdcece4f02d3d7278136c684cf2Kind regards,ArjanOn Wed, Feb 12, 2020 at 3: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_______________________________________________
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