On Wed, 9 Sep 2026 10:41:33 GMT, Jorn Vernee <[email protected]> wrote:
> Consider this set of classes:
>
>
> interface I1 { void m(); }
> interface I2 { void m(); }
>
>
> class Widget implements I1 { // version 1
> @Override
> public void m() {}
> }
>
>
> class Widget implements I2 { // version 2
> @Override
> public void m() {}
> }
>
>
> The current jar tool validator, which checks if different versions of a class
> in a multi-release jar file have the same API, will accept the above two
> versions of `Widget` as valid, given that they both have a method called `m`
> with the same signature.
>
> However, when version 2 of the Widget class is loaded by code that was
> compiled against version 1, we can run into problems:
>
>
> I1 x = new Widget(); // 1
> System.out.println(x instanceof I1); // 2
> x.m(); // 3
>
>
> Depending on the implementation of the verifier, the assignment on line (1)
> will succeed and cause heap pollution. The print statement on line (2) will
> print `false`, even though the type of `x` is `I1`, and the method call on
> line (3) will fail with an `IncompatibleClassChangeError`.
>
> Clearly, version 1 and 2 of the `Widget` class are incompatible, but the
> current jar file validator doesn't catch this because it ignores super
> interfaces.
>
> This patch adds a check for the super interfaces of a type to the validator
> as well, to catch cases like these.
>
> ---------
> - [x] I confirm that I make this contribution in accordance with the [OpenJDK
> Interim AI Policy](https://openjdk.org/legal/ai).
After discussing with colleagues, and double checking the [JAR
spec](https://docs.oracle.com/en/java/javase/25/docs/specs/jar/jar.html),
having additional super interface is something that is explicitly disallowed by
the spec, which mandates an exact API match:
> The public API exported by the classes in a multi-release JAR file must be
> _exactly_ the same across **versions**
Consider also that additional super interfaces can bring in additional
inherited default methods, thereby changing the set of public methods of a type.
Therefore, versioned classes in an MR-JAR should _not_ implement additional
interfaces from newer JDKs such as `SequencedCollection`. For such use cases,
the [tip & tail model](https://openjdk.org/jeps/14) is much more suitable,
where different versions of the API are published as part of a separate release
trains.
Thanks for the reviews. I forgot to undraft this again. Some changes might
still come as a result of CSR-related discussion
-------------
PR Comment: https://git.openjdk.org/jdk/pull/32787#issuecomment-5669100473
PR Comment: https://git.openjdk.org/jdk/pull/32787#issuecomment-5731359062
