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