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 prod
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
yes :)
Remi
On March 8, 2017 9:41:13 PM GMT+01:00, John Rose wrote:
>On Mar 8, 2017, at 10:47 AM, Remi Forax wrote:
>>
>> The exception if the lookup is PRIVATE should be
>IllegalStateException and not UnuspportedOperationException.
>> then, given that the loaded class will have the same prot
On 14/03/2017 17:37, Russell Gold wrote:
Hi Alan,
I am trying this in SimpleStub, and it seems to work for my current
test cases if I do this:
MethodHandles.Lookup in = MethodHandles.privateLookupIn(baseClass,
MethodHandles.lookup() ).dropLookupMode( MethodHandles.Lookup.PRIVATE );
return in
time package
> as the Lookup's lookup class.
>
> An initial implementation of Lookup.defineClass is in the current Jigsaw EA
> builds [1], the javadoc is also online [2]. We are currently looking for help
> in trying out this method to see how it might be used to replace existi
On 11/03/2017 16:48, Rafael Winterhalter wrote:
:
For testing libraries like Mockito, I would however prefer to use a
mechanism similar to Unsafe::defineClass. My prefered way would be to add a
test-specific module to any JDK installation that needs to be enabled by
some flag. It would be too b
On Mar 11, 2017, at 9:55 AM, Michael Rasmussen
wrote:
>
> What should the Lookup be based on though, since you don't have a Class yet?
Lookups are designed to represent computations in the context of a pre-existing
class.
I guess a Lookup for this use case would have to be based on a pre-exist
You are right, that is a problem. However, I do not think that the lookup
would need to be based on the class as long as it has the same priviledges.
In this case, the lookupClass method could return null or throw an
unsupported operation exception if the class is yet unloaded. I do not
think that
> For this to work, I do however think it is crucial to add a parameter to
> the ClassFileTransformer::transform method where a lookup object should be
> provided as an additional argument in order to allow defining additional
> classes in the instrumented class's loader and module.
What should th
I have implemented support for Lookup::defineClass in my library Byte Buddy
and my first impression is quite positive, I think this can offer a great
alternative for at least some use cases.
For this to work, I do however think it is crucial to add a parameter to
the ClassFileTransformer::transfor
On Mar 8, 2017, at 10:47 AM, Remi Forax wrote:
>
> The exception if the lookup is PRIVATE should be IllegalStateException and
> not UnuspportedOperationException.
> then, given that the loaded class will have the same protection domain as the
> lookup class, i do not fully understand why having
Hi Alan,
i've already updated the only code i had that was using ClassLoader.defineClass
after a Method.setAccessible() to use Unsafe.defineClass
(no way to remove it, i need to be able to inject code a la Mockito)
so Lookup.defineClass is a safe replacement of Unsafe.defineClass , i su
ime. To
that end, a promising proposal is to add a defineClass method to
MethodHandles.Lookup so that a class can be defined to the same class
loader and in the same runtime package as the Lookup's lookup class.
An initial implementation of Lookup.defineClass is in the current Jigsaw
EA builds
13 matches
Mail list logo
