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

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


Back to the top