[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [jakartaee-tck-dev] A quick thought about signature tests
|
I was merely hit by the consequences of a possibility of removing the
signature tests, which I did not realize when the discussion about it
took place on mailing list couple of months ago.
* On one hand, the product 9.x is an EE 9 compatible and has a
customer support for a long period for which the implementation
cannot be upgraded and the customers want to have access to the
newer version of Y. The process blocks that possibility and customer
is unhappy with it.
* On the other hand, the product 9.x is an EE 9 compatible for a long
period the customer knows that the API won't change in a way the
customer needs to update his code and the customer is happy about
it. However, without signature tests, 9.x can still claim to be
compatible with EE 9 and yet the customer may experience a situation
where he needs to modify his code (for instance to implement an
additional method from the API interface)
I am not sure that a compatibility level between Jakarta EE releases
would be a right thing. I merely tried to point at the possibilities of
what could happen without the signature tests, without being prejudiced
about whether it is good or not.
Thanks,
Jan
On 27.05.2020 17:16, Scott Marlow wrote:
Thanks for raising this discussion Jan!
In summary, it sounds to me like you are proposing a new Platform
level compatibility contract between any two Jakarta EE releases (and
how their SPEC API jars may change between EE releases), is that correct?
More inline below...
On Wed, May 27, 2020 at 9:32 AM Jan Supol <jan.supol@xxxxxxxxxx
<mailto:jan.supol@xxxxxxxxxx>> wrote:
Hi,
I just hit a side-effect I have not thought about earlier, which I
want
to bring to a discussion about the idea of removing/replacing
signature
tests. I am not sure whether it is supports the idea of having the
signature tests removed or contrary...
The idea I heard quite some time ago, and it may not be valid any
longer, is that the signature tests are no longer needed, since
the API
is brought over from maven central and noone is modifying the API any
longer.
A part of this is that the specification also publishes the exact
maven coordinates for each Jakarta EE Platform release, for example
for EE 9 https://jakarta.ee/specifications/jsonb/2.0/ identifies the
maven coordinates:
jakarta.jsonb:jakarta.jsonb-api:jar:2.0.0
However, there is no requirement that EE 9 implementations actually
use the jakarta.jsonb:jakarta.jsonb-api:jar:2.0.0 coordinates, as the
implementation may need to modify the
jakarta.jsonb:jakarta.jsonb-api:jar:2.0.0 artifact in a way, that is
not useful for others. So the signature tests also help verify that
the implementation is using SPEC API jars that have the expected
signatures (with no super/sub setting), at least this has been the
(Platform level) requirement up to now.
The side-effect of the signature tests is as follows:
Suppose a product of version say 9.X compatible with a specification
(CDI, JSON-B, any particular spec, not Jakarta EE spec) of version Y,
part of say Jakarta EE 9 (I chose 9 for simplicity, but it could
be 10
or any further version).
Suppose a product of version 9.X+1, that is still supposed to be
compatible with Jakarta EE 9. Suppose a specification of version Y+1
(part of say Jakarta EE 10), backward compatible with version Y. When
the product 9.X+1 replaces specification Y with Y+1, the TCK
signature
tests for the Jakarta EE 9 will fail.
I don't think that a product that is implementing Y + 1, would run the
Y signature tests, as they would instead run the Y + 1 signature tests.
Just for an example, assume that Y + 1 (EE 10) adds some new methods
and removes some, the Y + 1 signature tests should add/remove those
same methods, but the Y (EE 9) signature tests will not have these
modifications, so yes, I agree the Y signature tests cannot be run
against a Y + 1 product. But, somehow, I feel like I must be missing
the problem that you are raising here.
Without the signature tests,
however, when the specification Y is replaced with Y+1, the
Jakarta EE
9 TCK pass, because of the backward compatibility of Y+1, even
though
there is Y+1 API in the 9.X+1 and the whole product 9.X+1 is still
Jakarta EE 9 compatible, despite it is using Y+1 API (And it may be
compatible with the Y+1 spec at the same time).
At the Platform level, are you thinking of a new way to define
compatibility between EE 9 + EE 10? As well as any future Y being
replaced with Y + 1?
Thanks,
Scott
Thanks,
Jan
_______________________________________________
jakartaee-tck-dev mailing list
jakartaee-tck-dev@xxxxxxxxxxx <mailto: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