Enums class files in Java can be identified as abstract. It looks like Sigtest should ignore whether enum abstract or not.
For instance AutoSig reported removing abstract modifier from java.util.concurrent.TimeUnit enum which was abstract before JDKb113. But it becomes not abstract in JCKb113, AutoSig reports it as it follows:
27553c27553
< CLSS public abstract !enum java.util.concurrent.TimeUnit
---
> CLSS public final !enum java.util.concurrent.TimeUnit
java.util.concurrent.TimeUnit since 1.5 to 1.9 b113 was abstract enum because of abstract method int excessNanos(long d, long m):
$J8/bin/javap -classpath $J8/jre/lib/rt.jar java.util.concurrent.TimeUnit
Compiled from "TimeUnit.java"
public abstract class java.util.concurrent.TimeUnit extends java.lang.Enum<java.util.concurrent.TimeUnit> {
...
abstract int excessNanos(long, long);
}
Enums cannot be defined abstract in Java.
And TimeUnit was not defined as abstract.
But enum may have an abstract method which made the enum class abstract implicitly.
Abusing method excessNanos() was package private so it doesn't impact compatibility.
And when the method is removed (in b113-b114,JDK-8152083),
TimeUnit became concrete again after recompilation.
Taking into account that enum instances cannot be created explicitly via constructor(s) this change seems not to be able to impact end user programs. Spec/Javadoc is not changed either.
However, whether RI enum abstract or not can affect JCK licensees, namely:
1. If Oracle JDK enum has abstract method then it's abstract. Consequently JCK signature test contains signature files with abstract enum. Consequently JCK licensees should have abstract enum too. This means that the licensees should add abstract method to their enum too or make it abstract by other means.
2. If Oracle JDK enum doesn't have abstract methods then Oracle licensees should not use abstract methods in their enums too or they should make them not abstract by other means.
So actually it doesn't matter if enum is abstract or not but JCK licensees are required to have their enums with the same "abstractness" as ours.
So it seems that enum "abstractness" should be ignored by Sigtest.
Other options which can be seen are ignoring it by JCK Signature Test or requiring to approve any change of enum "abstractness" by JDK team for instance during CCC process.
For instance AutoSig reported removing abstract modifier from java.util.concurrent.TimeUnit enum which was abstract before JDKb113. But it becomes not abstract in JCKb113, AutoSig reports it as it follows:
27553c27553
< CLSS public abstract !enum java.util.concurrent.TimeUnit
---
> CLSS public final !enum java.util.concurrent.TimeUnit
java.util.concurrent.TimeUnit since 1.5 to 1.9 b113 was abstract enum because of abstract method int excessNanos(long d, long m):
$J8/bin/javap -classpath $J8/jre/lib/rt.jar java.util.concurrent.TimeUnit
Compiled from "TimeUnit.java"
public abstract class java.util.concurrent.TimeUnit extends java.lang.Enum<java.util.concurrent.TimeUnit> {
...
abstract int excessNanos(long, long);
}
Enums cannot be defined abstract in Java.
And TimeUnit was not defined as abstract.
But enum may have an abstract method which made the enum class abstract implicitly.
Abusing method excessNanos() was package private so it doesn't impact compatibility.
And when the method is removed (in b113-b114,
TimeUnit became concrete again after recompilation.
Taking into account that enum instances cannot be created explicitly via constructor(s) this change seems not to be able to impact end user programs. Spec/Javadoc is not changed either.
However, whether RI enum abstract or not can affect JCK licensees, namely:
1. If Oracle JDK enum has abstract method then it's abstract. Consequently JCK signature test contains signature files with abstract enum. Consequently JCK licensees should have abstract enum too. This means that the licensees should add abstract method to their enum too or make it abstract by other means.
2. If Oracle JDK enum doesn't have abstract methods then Oracle licensees should not use abstract methods in their enums too or they should make them not abstract by other means.
So actually it doesn't matter if enum is abstract or not but JCK licensees are required to have their enums with the same "abstractness" as ours.
So it seems that enum "abstractness" should be ignored by Sigtest.
Other options which can be seen are ignoring it by JCK Signature Test or requiring to approve any change of enum "abstractness" by JDK team for instance during CCC process.