On 2/13/22 1:05 PM, Dan Smith wrote:
On Feb 12, 2022, at 10:16 PM, Srikanth Adayapalam <srikanth.adayapa...@oracle.com> wrote: I understand Frederic is asking about whether the spec​ inadvertently allows something it should not - Here anyway is javac behavior: Given: abstract class A implements ValueObject { int x; } on compile: X.java:1: error: The type A attempts to implement the mutually incompatible interfaces ValueObject and IdentityObject abstract class A implements ValueObject { ^ 1 errorYep, this is expected and consistent: javac sees the field and infers the superinterface IdentityObject (per the language rules), then detects the conflict between interfaces. A slightly more interesting variation: declare a simple interface Foo; change to 'A implements Foo'. This compiles fine, inferring A implements IdentityObject. Then separately compile Foo so that it extends ValueObject. No compilation error, but the JVM should detect the IdentityObject/ValueObject conflict when A is loaded. To generate the kind of class files Fred asked about, you'd need to use something other than javac.
That's not really the point. The JVM cannot rely on what javac generates or not, because it has to deal with other class files generators. We have to agree on the behavior of the VM based on what is possible in the class file, because, at the end, this is what must be implemented. The fact that such a class file is useless to the user is almost secondary. We just need to know if the VM should accept such class file. As long as it doesn't break VM invariants, we are fine accepting it. Fred
