Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakartaee-tck-dev] A quick thought about signature tests

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> 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
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-tck-dev

Back to the top