jmx-dev [PATCH] JDK-8005472: com/sun/jmx/remote/NotificationMarshalVersions/TestSerializationMismatch.sh failed on windows (original) (raw)

Chris Hegarty chris.hegarty at oracle.com
Sat Feb 9 00:43:05 PST 2013

On 02/08/2013 07:50 PM, Stuart Marks wrote:

On 2/8/13 8:37 AM, Chris Hegarty wrote:

Jon Gibbons suggested invoking the compiler API directly from java instead of writing a shell script. Doing this seems fairly simple, and I think it would be advantageous to keep things entirely in Java. I may attempt to rewrite the defaultSVID test using the compiler API.

Here's a test that does just that. http://hg.openjdk.java.net/jdk8/tl/jdk/file/2de8c6c2d652/test/sun/misc/JarIndex/metaInfFilenames/Basic.java Oh cool, interesting. This test invokes com.sun.tools.javac.Main.compile() and passes an array of String arguments, just like a command line. It seems pretty effective, at least for this case.

This com.sun API is a supported interface into the compiler. I find it works really well when writing tests, mainly because of it simplicity. I have avoided a number of shell scripts by using it.

It should be a reasonable candidate if considering removing a number of shell scripts, that do something trivial, then compile and run.

-Chris.

But that's not what Jon was talking about. :-) I believe Jon was referring to the offical Java Compiler API (JSR 199) which lives in javax.tools. This API is more fiddly than just passing an array of strings to javac's main, but it's also considerably more flexible. For example, it's possible to use it to call the compiler directly on a String! (I haven't coerced it to compile a String directly to class bytes, but it should be possible to do so in principle.) Anyway, this is good, we should investigate these approaches for a variety of use cases and develop a repertoire of techniques. Eventually we may be able to avoid writing shell script tests entirely. s'marks

More information about the serviceability-dev mailing list