Lookup.defineClass

[Alan Bateman]

On 03/04/2017 15:15, Russell Gold wrote:

> Upon further testing, this turns out to be less capable than the 
> “Unsafe” version - in particular, I cannot create a test stub in a 
> closed package. The problem is that unit tests often need to do a 
> number of things like this that make no sense in a production 
> environment.
>
> The problem has to do with creating test stubs to take the place of 
> JDK objects. In many cases, this requires access to package-protected 
> classes or fields, as the JDK doesn’t provide clean interfaces for a 
> lot of its functionality. In the past, we could do this by defining a 
> subclass in the same package as the JDK class we needed to stub. That 
> no longer works without command-line switches.
If I read this correctly then you are looking to define classes in 
java.lang and other packages of core modules, is that right? If so then 
they are deliberately not open and I assume the issue you are running 
into is that you can't get a Lookup to a target class with PACKAGE access.

When testing the JDK then package private members can be exercised. The 
test runner for the JDK tests is "jtreg" and it arranges for the tests 
to be in the same loader/package by using the --patch-module.

> Related to this, unit tests must often create stub classes 
> specifically in thread context class loaders - but those classes are 
> frequently not in the same package as the test code. This new feature 
> doesn’t support that at all, and I don’t even see a way to use a 
> command line switch to enable it.
>
I'm not sure that I understand the scenario. Do you control the TCCL?

-Alan