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).
-------------
Commit messages:
- Use parameterized test
- Treat interfaces and classes alike.
- Make order unimportant by use a `Set<String>` for names
- 8382938: jar tool will create multi-release jars where different versions
are incompatible
Changes: https://git.openjdk.org/jdk/pull/32787/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=32787&range=00
Issue: https://bugs.openjdk.org/browse/JDK-8382938
Stats: 65 lines in 2 files changed: 61 ins; 0 del; 4 mod
Patch: https://git.openjdk.org/jdk/pull/32787.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/32787/head:pull/32787
PR: https://git.openjdk.org/jdk/pull/32787
