RFR: JDK-8315248: AssertionError in Name.compareTo
Archie Cobbs
acobbs at openjdk.org
Wed Aug 30 13:35:10 UTC 2023
On Wed, 30 Aug 2023 00:25:52 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:
> Please review a small fix to avoid an `AssertionError` coming out of `CharSequence.compare` for two `CharSequence` objects obtained from different instances of the `javax.lang.model` API.
>
> Full details in the JBS issue and comments.
>
> There are some minor cleanup edits as well, and some improvements to the code to throw AssertionError in a few places.
This definitely works. However, if a class `X` implements `Comparable`, by definition instances must be able to `compareTo()` themselves with any other instance of type `X` (even if `X` is an interface - so this is a pretty major imposition that any class or interface implementing `Comparable` imposes on all subtypes, present, past, and future).
In this case, it is `Name` that implements `Comparable`, and `Utf8NameTable.NameImpl`'s version of `compareTo()` is just as an overriding optimization of `Name.compareTo()`, which does in fact work in all cases.
So it seems like the "truly correct" thing to do here would be something like this:
// Utf8NameTable.NameImpl.compareTo()
@Override
public int compareTo(Name name0) {
NameImpl name;
try {
name = (NameImpl)name0;
} catch (ClassCastException e) {
return super.compareTo(name0);
}
byte[] buf1 = getByteData();
...etc...
This probably doesn't matter in practice, but just wanted to point out the theoretical argument.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/15478#issuecomment-1699184276
More information about the compiler-dev
mailing list