P2
sigtest does comparison of two version of API. First is represented as a sigfile,
and a second is taken either from classpath or via reflection. It is sufficient for
TCKs. Sigtest however is also used internally to track changes between product builds.
It would be useful to be able to compare just two jar files. Something like:
sigtest -cp1 build24.jar -cp2 build25.jar
In other cases it is useful to compare two sigfiles from two releases:
sigtest -sig1 tck13.sig -sig2 tck14.sig
Generalizing this approach each API source could be represented as one of the following:
- sigfile
- classpath
- reflection
etc.
Note that si,ilar feature was implemented in APICheck tool so some ideas
of command line options can be reused from there.
From time to time JDK developers are asking about a tool that would allow then to track changes in API. Sigtest can be used for this purpose. However it checks only public API.
JDK team tracks changes in non-public API. For example, changes in com.sun.*
classes or in package-private members could be a subject for an approval too.
What could help is a mode in sigtool that would enable checking non-public API.
This feature could be also very useful in testing JSR-269 (annotation processing).
JCK team needs this feature for implementing CR 6494271 "checking signature of generated classes" in the JCK 6a and the standalone Compiler TCK:
Existing compiler tests pay much attention to language construct in input source and poorly check produced class files. Basically generated classes are partially
checked using runtime execution but this verifies only that particular examined members are present in class files and didn't check that all required membres including not-public are present and that no extra members are generated.
Without having this RFE implemented we would have a lack of coverage of generation of non-public API members.
and a second is taken either from classpath or via reflection. It is sufficient for
TCKs. Sigtest however is also used internally to track changes between product builds.
It would be useful to be able to compare just two jar files. Something like:
sigtest -cp1 build24.jar -cp2 build25.jar
In other cases it is useful to compare two sigfiles from two releases:
sigtest -sig1 tck13.sig -sig2 tck14.sig
Generalizing this approach each API source could be represented as one of the following:
- sigfile
- classpath
- reflection
etc.
Note that si,ilar feature was implemented in APICheck tool so some ideas
of command line options can be reused from there.
From time to time JDK developers are asking about a tool that would allow then to track changes in API. Sigtest can be used for this purpose. However it checks only public API.
JDK team tracks changes in non-public API. For example, changes in com.sun.*
classes or in package-private members could be a subject for an approval too.
What could help is a mode in sigtool that would enable checking non-public API.
This feature could be also very useful in testing JSR-269 (annotation processing).
JCK team needs this feature for implementing CR 6494271 "checking signature of generated classes" in the JCK 6a and the standalone Compiler TCK:
Existing compiler tests pay much attention to language construct in input source and poorly check produced class files. Basically generated classes are partially
checked using runtime execution but this verifies only that particular examined members are present in class files and didn't check that all required membres including not-public are present and that no extra members are generated.
Without having this RFE implemented we would have a lack of coverage of generation of non-public API members.