On 06/26/2012 02:24 PM, Jochen Theodorou wrote:
> Am 26.06.2012 13:37, schrieb Julien Ponge:
>> You may bypass the invokespecial (…)V as a first method
>> invocation within a constructor requirement by launching the JVM with
>> -noverify. As long as you don't do anything stupid in the bytecode it
>
Am 26.06.2012 13:37, schrieb Julien Ponge:
> You may bypass the invokespecial (…)V as a first method
> invocation within a constructor requirement by launching the JVM with
> -noverify. As long as you don't do anything stupid in the bytecode it
> will be just ok and you can call a constructor using
Am 26.06.2012 13:06, schrieb Rémi Forax:
[...]
(2) calling super()
afaik I cannot generate a call site that replaces the invokeSpecial call
to a super class constructor.
>>> You can call super.foo()
>> ah true... this is not reflection.. even if I get the handle from the
>> super cla
You may bypass the invokespecial (…)V as a first method invocation within
a constructor requirement by launching the JVM with -noverify. As long as you
don't do anything stupid in the bytecode it will be just ok and you can call a
constructor using indy.
Anyway I confess that disabling verifica
On 06/26/2012 12:37 PM, Jochen Theodorou wrote:
> Am 26.06.2012 11:59, schrieb Rémi Forax:
>> On 06/26/2012 11:40 AM, Jochen Theodorou wrote:
>>> Hi all,
>>>
>>> just to be sure I understand correctly... afaik there are two things
>>> invokedynamic cannot do.
>>>
>>> (1) calling private methods
>>>
Am 26.06.2012 11:59, schrieb Rémi Forax:
> On 06/26/2012 11:40 AM, Jochen Theodorou wrote:
>> Hi all,
>>
>> just to be sure I understand correctly... afaik there are two things
>> invokedynamic cannot do.
>>
>> (1) calling private methods
>> actually I am not sure this is really true. There is a Lo
Changeset: 7f23289ab8a8
Author:jrose
Date: 2012-06-26 02:52 -0700
URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/7f23289ab8a8
meth: fix broken cache
! meth-lazy-7023639.patch
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://
Hi blackdrag,
Private methods can be called - providing you have a lookup object
that was constructed (via MethodHandles.lookup() ) in a context which
can see the private method.
The point of the lookup mechanism is to provide the capability to
selectively give access to private methods, without
On 06/26/2012 11:40 AM, Jochen Theodorou wrote:
> Hi all,
>
> just to be sure I understand correctly... afaik there are two things
> invokedynamic cannot do.
>
> (1) calling private methods
> actually I am not sure this is really true. There is a Lookup instance I
> can use to get handles to privat
Changeset: 7897d571c685
Author:jrose
Date: 2012-06-26 02:54 -0700
URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/7897d571c685
rebase
! meth-lazy-7023639.xbmh.patch
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjd
Changeset: 2a77b30743df
Author:jrose
Date: 2012-06-26 02:40 -0700
URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/2a77b30743df
meth: compiled MH paths work in C1 (unit tests except PermuteArgsTest)
! meth-lazy-7023639.jit.patch
! meth-lazy-7023639.patch
_
Hi all,
just to be sure I understand correctly... afaik there are two things
invokedynamic cannot do.
(1) calling private methods
actually I am not sure this is really true. There is a Lookup instance I
can use to get handles to private methods (afaik), therefore it should
be possible. Or is t
12 matches
Mail list logo
