problem with private classes and invokedynamic

104 views
Skip to first unread message

Jochen Theodorou

unread,
Jan 7, 2012, 5:08:40 PM1/7/12
to jvm-la...@googlegroups.com
hi all,


I have a small problem and I wonder how others solve this. Assuming I have

foo.bar()

with the static type of foo being Object. Let us assume there is a
public class Base which provides a public method bar and there is a
class Foo$Foo extending Base, overriding bar, but this class is private.
foo be an instance of Foo$Foo.

If I now follow the usual pattern of Groovy method selection, then this
will give me of course Foo#bar. But if I want to use that I get a
"symbolic reference class is not public"

I may have no control over this class, so I don't see how I could get a
LOOKUP object... how am I supposed to call this method? Should I really
fall back to reflection for this?

bye blackdrag

--
Jochen "blackdrag" Theodorou - Groovy Project Tech Lead
blog: http://blackdragsview.blogspot.com/
german groovy discussion newsgroup: de.comp.lang.misc
For Groovy programming sources visit http://groovy-lang.org

Rémi Forax

unread,
Jan 7, 2012, 5:15:20 PM1/7/12
to jvm-la...@googlegroups.com
On 01/07/2012 11:08 PM, Jochen Theodorou wrote:
> hi all,
>
>
> I have a small problem and I wonder how others solve this. Assuming I
> have
>
> foo.bar()
>
> with the static type of foo being Object. Let us assume there is a
> public class Base which provides a public method bar and there is a
> class Foo$Foo extending Base, overriding bar, but this class is
> private. foo be an instance of Foo$Foo.
>
> If I now follow the usual pattern of Groovy method selection, then
> this will give me of course Foo#bar. But if I want to use that I get a
> "symbolic reference class is not public"
>
> I may have no control over this class, so I don't see how I could get
> a LOOKUP object... how am I supposed to call this method? Should I
> really fall back to reflection for this?
>
> bye blackdrag
>

You can always bypass the security by creating a j.l.r.Method,
call setAccessible() on it and then use lookup.unreflect().

cheers,
R�mi

Jochen Theodorou

unread,
Jan 7, 2012, 5:21:37 PM1/7/12
to jvm-la...@googlegroups.com
Am 07.01.2012 23:15, schrieb R�mi Forax:
[...]

> You can always bypass the security by creating a j.l.r.Method,
> call setAccessible() on it and then use lookup.unreflect().

ah! ok... thanks.

Jochen Theodorou

unread,
Jan 7, 2012, 5:43:27 PM1/7/12
to jvm-la...@googlegroups.com
Am 07.01.2012 23:21, schrieb Jochen Theodorou:
> Am 07.01.2012 23:15, schrieb R�mi Forax:
> [...]
>> You can always bypass the security by creating a j.l.r.Method,
>> call setAccessible() on it and then use lookup.unreflect().
>
> ah! ok... thanks.

hmm... I seemed to be happy too early... it does not work

Rémi Forax

unread,
Jan 7, 2012, 5:56:32 PM1/7/12
to jvm-la...@googlegroups.com
On 01/07/2012 11:43 PM, Jochen Theodorou wrote:
> Am 07.01.2012 23:21, schrieb Jochen Theodorou:
>> Am 07.01.2012 23:15, schrieb R�mi Forax:
>> [...]
>>> You can always bypass the security by creating a j.l.r.Method,
>>> call setAccessible() on it and then use lookup.unreflect().
>>
>> ah! ok... thanks.
>
> hmm... I seemed to be happy too early... it does not work

it works !

import java.lang.invoke.MethodHandle;
import java.lang.invoke.MethodHandles;
import java.lang.invoke.MethodType;
import java.lang.reflect.Method;

public class SecBypass {
public static class Base {
public void foo() {
System.out.println("Base::foo");
}
}

static class Sub extends Base {
public void foo() {
System.out.println("Sub::foo");
}
}

public static void main(String[] args) throws Throwable {
Base base = new Sub();

//MethodHandle mh =
MethodHandles.publicLookup().findVirtual(Sub.class, "foo",
MethodType.methodType(void.class));
// don't work

Method method = Sub.class.getDeclaredMethod("foo");
method.setAccessible(true);
MethodHandle mh = MethodHandles.publicLookup().unreflect(method);
// ok

mh.invoke(base);
}
}


>
> bye blackdrag
>

cheers,
R�mi

Jochen Theodorou

unread,
Jan 8, 2012, 4:17:57 AM1/8/12
to jvm-la...@googlegroups.com
Am 07.01.2012 23:56, schrieb R�mi Forax:
> On 01/07/2012 11:43 PM, Jochen Theodorou wrote:
>> Am 07.01.2012 23:21, schrieb Jochen Theodorou:
>>> Am 07.01.2012 23:15, schrieb R�mi Forax:
>>> [...]
>>>> You can always bypass the security by creating a j.l.r.Method,
>>>> call setAccessible() on it and then use lookup.unreflect().
>>>
>>> ah! ok... thanks.
>>
>> hmm... I seemed to be happy too early... it does not work
>
> it works !

sorry, I take it back. It was too late already and I didn't see that the
error and the taken path in the code are totally unrelated.

Julien Ponge

unread,
Jan 9, 2012, 3:28:38 AM1/9/12
to jvm-la...@googlegroups.com
Hi,

Is there a performance penalty in using a method handle obtained using unreflect() vs findVirtual()?

This is not clear from the docs.

Cheers

On Saturday, January 7, 2012 at 11:56 PM, Rémi Forax wrote:

On 01/07/2012 11:43 PM, Jochen Theodorou wrote:
Am 07.01.2012 23:21, schrieb Jochen Theodorou:
Rémi

--
You received this message because you are subscribed to the Google Groups "JVM Languages" group.
To post to this group, send email to jvm-la...@googlegroups.com.
To unsubscribe from this group, send email to jvm-language...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/jvm-languages?hl=en.

Rémi Forax

unread,
Jan 9, 2012, 4:21:34 AM1/9/12
to jvm-la...@googlegroups.com
On 01/09/2012 09:28 AM, Julien Ponge wrote:
Hi,

Is there a performance penalty in using a method handle obtained using unreflect() vs findVirtual()?

This is not clear from the docs.

In practice, there is no perf difference when you call the resulting method handle.

The only difference is that findVirtual() may be faster than getMethod/getDeclaredMethod+unreflect
because you send the return type of the method to findVirtual() which avoid to crawle
all methods of the vtable (or of a side map) to find the one requested.
The reflection API also requires to return the method with the most specific return type
when you have several methods with the same parameter types.



Cheers

-- 
Julien Ponge

cheers,
Rémi

Julien Ponge

unread,
Jan 9, 2012, 4:22:11 AM1/9/12
to jvm-la...@googlegroups.com
Thanks Rémi!
Reply all
Reply to author
Forward
0 new messages