The fix for https://bugs.openjdk.java.net/browse/JDK-8237069 expressly encoded the new super top interface types IdentityObject and InlineObject in class files. This approach was taken because at that time it seemed to be in conformance with what we do for other implicit super types (jlO, enums, annotations ...)

However, this approach has been an irritant insofar as it has caused several tests to be massaged to avoid "failures" in expected output.

It is very much the case that both the static environment (javac) and dynamic environment (jvm) must be prepared to handle classes compiled with legacy versions of javac (pre-inline-class-support-enabled versions) as being IdentityObject without the class file expressly encoding the top type.

Given that, do we want the inline-classes-support-enabled-javac to expressly encode the new top types in class files ? Or do we want the static and dynamic environments to simply "maintain the notion" of a new top type in new and old class files without it being actually encoded anywhere ??

John Rose weighed in on this with the following:

"I’d say don’t add it explicitly. Having an optional add-in just adds noise to the system. We should consider a structural rule that would allow us to forbid IdentityObject in the interfaces list, except exactly in cases (if any) where it would be a useful addition. We have a nearby structural rule which forbids a null super class field except for jl.Object; a similar rule would “know about” IdentityObject.

General principle: New constructs (new bytecodes, new magic supers, new abstract ctors, etc.) have to pay their way. Having two ways to say the same thing is the very definitions of noise, since the distinction carries exactly 0 bits of information yet it occupies bits in the channel (tools, classfiles). Noise is expensive."

So, this ticket is to reverse the explicit encoding which will have to be a co-ordinated move.