Based on the feedback given so far and the concern raised about
loosening the current "no super setting" verification that
prevents inserting of additional annotations into SPEC API
implementation, Jakarta EE 9.1 will continue to verify that no
annotations have been added to each SPEC API.
On 3/18/21 3:53 PM, Lance Andersen
wrote:
So let's take a step back for a moment.
One of the things that led to the success of Java
EE was its strict conformance rules which included no super
setting. Once you lower the bar and allow “random/selective”
annotations, there is no going back.
The JDK team already added fields to the Deprecated annotation
in a binary compatible way but they did super set the original
Deprecated interface. I think that we need to figure out which
super setting changes are allowable and aren't.
IMO this is relevant for solving the jakartaee-tck/issues/156
issue (action is to remove or ignore JDK signatures in signature
testing for which I am working on change for).
Some possible options:
1. Ignore only JDK signatures in signature testing.
2. Ignore only JDK annotation signatures in signature testing.
3. Ignore all annotation signatures in signature testing.
IMO the benefit of solving jakartaee-tck/issues/156 is so that
TCKs can be run on newer JDK versions than the base JDK version
originally targeted by an EE release. Of course, if a
particular JDK release breaks compatibility, there is no
benefit.
When making such an important
architectural/platform strategy decision, you need to think
carefully of what it could mean 1, 5, 10 years down the road.
If you do not take a simple and clear stand on adding vendor
specific annotations, where will it end? How will you
decide that Vendor A’s annotation is OK, but Vendor B’s
annotation is not? What guarantees are there for an API
class when vendors are adding their own annotations that there
will be no surprises today, tomorrow, or next year?
We need to listen to the community on this IMO. Feedback is
welcome!
Whether an annotation is visible via reflection
should not have a bearing on the architectural/platform
strategy discussion of adding vendor specific annotations.
I would strongly suggest you spend some time
thinking through the overall ramifications of an action such
as this. If an annotation is “so compelling” then it should
be added to the Jakarta EE Platform vs. allowing vendors to
add their favorite annotations to their versions of a Jakarta
API JARs.
One of the proposals was to only allow Jakarta EE Platform
annotations to be added.
Once you go down this path, it can be difficult to
find your way back so I would not make a hasty decision.
+1 on not making hasty decisions but also we should be open to
adjustments as well (like we are doing for jakartaee-tck/issues/156).
Best,
Scott
Best
Lance
>
Another
alternative could be for us to maintain a static list
of annotations to ignore. The `annotation ignore
list` would only be updated during the development of
a Jakarta EE release (e.g. likely via a code change).
That's the
alternative that has the slippery slope of when to say
when....
---------------------------------------------------
Kevin Sutter
STSM, Jakarta EE and MicroProfile architect @ IBM
e-mail: sutter@xxxxxxxxxx Twitter:
@kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)
LinkedIn: https://www.linkedin.com/in/kevinwsutter
Part-time schedule: Tue, Wed, Thu (off on Mon and Fri)
From: Scott Marlow <smarlow@xxxxxxxxxx>
To: jakartaee-tck-dev@xxxxxxxxxxx
Date: 03/18/2021 08:47
Subject: [EXTERNAL] Re:
[jakartaee-tck-dev] Relaxing signature testing
Sent by: "jakartaee-tck-dev"
<jakartaee-tck-dev-bounces@xxxxxxxxxxx>
On 3/17/21
8:51 PM, Scott Stark wrote: The problem with that is
the tooling in this case will never look at that,
unless it is also going to be brought under Jakarta.
On 3/17/21 8:51 PM, Scott
Stark wrote:
The problem with that is
the tooling in this case will never look at that,
unless it is also going to be brought under Jakarta.
Since the BND annotations
use a RetentionPolicy.CLASS they are not visible via
reflection. I don't know if the bytecode for the
annotation retains the retention policy setting. It
must, else how could the reflection system make the
distinction? Is that a sufficient distinction to allow
CLASS or SOURCE RetentionPolicy annotations in API
jars?
Here is a list of some of
the RUNTIME annotations that we would still be
verifying { SafeVarargs, Retention, Repeatable,
Inherited, Documented, Target, Deprecated } if we were
to ignore all CLASS/SOURCE annotations.
Another alternative could
be for us to maintain a static list of annotations to
ignore. The `annotation ignore list` would only be
updated during the development of a Jakarta EE release
(e.g. likely via a code change).
On Wed, Mar 17, 2021 at
3:38 PM David Blevins <david.blevins@xxxxxxxxx> wrote:
> On Mar 17,
2021, at 12:21 PM, Scott Marlow <smarlow@xxxxxxxxxx> wrote:
>
> On 3/17/21 2:48 PM, David Blevins wrote:
>> The flip side is if this is actually adds
capabilities desirable in well-known platforms like
OSGi, maybe should create a standard annotation and
officially add it to the API so everyone has it.
> This is the fundamental question, whether to
ignore certain annotations that have no impact on
compatibility. This is also somewhat of a slippery
slope as the annotation class could be enhanced in a
way that does cause compatibility concerns, even if
the annotation is a standard annotation.
I intended to say something very different than I
think was understood. When I say potentially making
it a standard annotation what I mean is a new
"jakarta.*" annotation defined in a spec and with
signature tests.
-David
_______________________________________________
jakartaee-tck-dev mailing list
jakartaee-tck-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-tck-dev
_______________________________________________
jakartaee-tck-dev mailing list
jakartaee-tck-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-tck-dev
_______________________________________________
jakartaee-tck-dev mailing list
jakartaee-tck-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-tck-dev
_______________________________________________
jakartaee-tck-dev mailing
list
jakartaee-tck-dev@xxxxxxxxxxx
To unsubscribe from this
list, visit https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/jakartaee-tck-dev__;!!GqivPVa7Brio!Kdy9ToD2PDerClo9Z8-Mp4c0E0Yt2Tdi31sGq3uSwuW_oIlG6BpOBWQpLXgVrlaHGw$
Lance Andersen| Principal Member of Technical Staff |
+1.781.442.2037
Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
Lance.Andersen@xxxxxxxxxx
_______________________________________________
jakartaee-tck-dev mailing list
jakartaee-tck-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-tck-dev