RFR 8143628: Fork sun.misc.Unsafe and jdk.internal.misc.Unsafe native method tables

Paul Sandoz paul.sandoz at oracle.com
Wed Dec 2 23:00:22 UTC 2015


Hi Stefan,

> On 2 Dec 2015, at 17:20, Stefan Särne <stefan.sarne at oracle.com> wrote:
> 
> 
> Hi Paul,
> 
> The reason we stick on standard jtreg tests is because it is simpler.
> For us, a java test is not a unit test, it is an application.  :)
> 

I tend to think of that as an artificial distinction since such java test classes often contain a logical grouping of tests (and perhaps data over which to test) and make test assertions. Let’s call it duck unit testing, it looks and quacks like a unit test :-)


> I agree with you that when writing and debugging java code, I would choose testng over jtreg and run and debug it inside my java IDE.

In the case of the JDK it's not jtreg over testng it is jtreg + testng.


> But debugging the VM is instead done with a native debugger and what the framework gives you for java development, becomes a level of indirection in VM land. Just adding the test class as argument to the java launcher where a main method exists is preferred.
> 

How do HotSpot engineers debug the VM with a jtreg test that uses @library (or @module once Jigsaw gets integrated), or uses WhiteBox, or uses ProcessTools?

Paul.



More information about the core-libs-dev mailing list