Re: A pure Java example with reflective access behaving differently with invokeWithArguments() compared to core reflection's invoke() (Re: Strange observation: MethodHandle.invokeWithArguments() would

, the Java supplied implementation would be able to adopt changes in the inner workings accordingly thereby insulating bridges from such details and problems. On 08.06.2018 18:23, Peter Levart wrote: I think what you found is a discrepancy between handling of varargs methods using reflection

Re: A pure Java example with reflective access behaving differently with invokeWithArguments() compared to core reflection's invoke() (Re: Strange observation: MethodHandle.invokeWithArguments() would

Hi Rony, I think what you found is a discrepancy between handling of varargs methods using reflection vs. method handle's .invokeWithArguments(). Reflection basically ignores the fact that some methods are varargs methods. It treats them exactly the same as if they had an array parameter (no

Re: ClassValue rooting objects after it goes away?

Hi Charles, On 03/02/2018 09:22 PM, Charles Oliver Nutter wrote: Put it another way: does a static reference from a class to itself prevent that class from being garbage collected? Of course not. ClassValue is intended to be a way to inject pseudo-static data into either a class or a Class. In

Re: Isolated Methods JEP

Hi Michael, John, On 08/13/2016 12:46 AM, John Rose wrote: So there will be no class hosting this method? Not even the "caller" class of the Lookup instance that loadCode was invoked upon? What will be reported by Reflection.getCallerClass() invoked in a @CallerSensitive method invoked from t

Re: Isolated Methods JEP

Hi Michael, On 08/09/2016 02:05 PM, Peter Levart wrote: In which case would lookup privileges be insufficient to define an isolated method? I would expect the privileges of the code in the isolated method to be checked when such method is executed and not when defining such method - lazily

Re: Isolated Methods JEP

Hi Michael, In the JEP's description you write: /"The loadCode method creates a method from the passed bytecode instructions and constants and returns a MethodHandle that can be used to call the method. The implementation of loadCode will take care of verification of the code to load

Re: RFR: JDK-8031043 ClassValue's backing map should have a smaller initial size

e benefits of locality of reference inherent to open-addressing tables with minimal average number of false probes which is a property of linked-nodes tables. It seems that in practice, it beats other strategies tried here when lookup performance is in question. Regards, Peter On 06/13/2016 07:18 P

RFR: JDK-8031043 ClassValue's backing map should have a smaller initial size

Hi, The patch for this issue is a result of the following discussion on mlvm-dev list: http://mail.openjdk.java.net/pipermail/mlvm-dev/2016-May/006602.html I propose the following improvement to the implementation of ClassValue API: http://cr.openjdk.java.net/~plevart/misc/ClassValue.Alterna

Re: proxy an interface and call a default method

On 06/02/2016 06:34 PM, fo...@univ-mlv.fr wrote: So perhaps, instead of providing a Proxy::findSuper method that returns a pre-bound MH, there could simply be a method like the following in the Proxy class: public final Object invokeSuper(Class interfaze, String methodName

Re: proxy an interface and call a default method

Hi Remi, Jochen, On 06/02/2016 11:15 AM, fo...@univ-mlv.fr wrote: >The solution could be for Proxy API to provide a MH that was already >bound to the Proxy instance. Such pre-bound MH could not be abused then. independently of any security issue, it may be a good idea but doing a partial eval

Re: proxy an interface and call a default method

The solution could be for Proxy API to provide a MH that was already bound to the Proxy instance. Such pre-bound MH could not be abused then. Regards, Peter - Mail original - De: "Peter Levart" À: "Da Vinci Machine Project" , "jochen Theodorou" En

Re: ClassValue perf?

On 05/30/2016 11:09 PM, Peter Levart wrote: Will revert that to volatile semantics... So, here it is. The latest incarnation - the same as webrev.04.1 but with volatile semantics: http://cr.openjdk.java.net/~plevart/misc/ClassValue.Alternative2/webrev.04.2/ Benchmarks show no change in

Re: ClassValue perf?

On 05/30/2016 07:47 PM, Aleksey Shipilev wrote: On 05/30/2016 06:59 PM, Peter Levart wrote: I also employed get-acquire/put-release memory ordering semantics instead of SC (volatile) in hope that it might improve a bit the performance on platforms such as PowerPC or ARM, but this can be

Re: ClassValue perf?

x27;ll assign the issue over to you. Thanks! Best, Michael Am 26.05.2016 um 14:42 schrieb Michael Haupt mailto:michael.ha...@oracle.com>>: Hi Peter, thank you for this wonderful piece of work. Am 26.05.2016 um 10:59 schrieb Peter Levart <mailto:peter.lev...@gmail.com>>

Re: proxy an interface and call a default method

Hi, I think the main problem here is that by providing the InvocationHandler with a Lookup that could provide "invokespecial" MHs for the proxy interface(s) could be abused. Anyone can create a Proxy for any public interface and supply its own InvocationHandler which could be used to "steal"

Re: LinearProbeHashtable Re: ClassValue perf?

include it in MOAT tests. What do you think? Regards, Peter On 26 May 2016, at 10:59, Peter Levart wrote: Hi Michael, On 05/23/2016 03:56 PM, Michael Haupt wrote: I've ran the unpatched version and Peter's two patches once more. The results are attached (results.txt). Th

Re: ClassValue perf?

Hi Michael, On 05/23/2016 03:56 PM, Michael Haupt wrote: I've ran the unpatched version and Peter's two patches once more. The results are attached (results.txt). They confirm Aleksey's observation. Regarding the 03 patch (plevart3 column in the results), perfasm output (see http://cr.openjd

Re: Question in understanding ClassValue better

On 05/24/2016 01:41 PM, Peter Levart wrote: Hm, It seems that my example will not help much. It also seems that the only problem with plain: static final ClassValue META_CLASS_CV = new ClassValue() { @Override protected MetaClass computeValue(Class type

Re: Question in understanding ClassValue better

21:32, Peter Levart wrote: [...] a ClassValue instance can be thought of as a component of a compound key. Together with a Class, they form a tuple (aClass, aClassValue) that can be associated with an "associated value", AV. And yes, the AVs associated with tuple containing a particular

Re: Question in understanding ClassValue better

A small correction... On 05/19/2016 09:32 PM, Peter Levart wrote: // the public API public MetaClass getInstanceFor(Class type) { This should of course read: // the public API public *static* MetaClass getInstanceFor(Class type) { Regards, Peter

Re: Question in understanding ClassValue better

Hi Jochen, I'll try to answer your questions as profoundly as I can... On 05/19/2016 04:27 PM, Jochen Theodorou wrote: Hi, at the beginning of this year I had an exchange with Peter Lavart about JDK-8136353 (see http://mail.openjdk.java.net/pipermail/mlvm-dev/2016-January/006563.html), and

Re: ClassValue perf?

s too is that original jdk 9 ClassValue has at least 2x overhead with cleanup compared to my designs (note that benchmark includes classloading time too). Regards, Peter Best, Michael Am 05.05.2016 um 17:21 schrieb Peter Levart <mailto:peter.lev...@gmail.com>>: Hi Michael,

Re: ClassValue perf?

a.net/~plevart/misc/ClassValue.Alternative2/webrev.02/ Regards, Peter Best, Michael Am 04.05.2016 um 17:50 schrieb Peter Levart <mailto:peter.lev...@gmail.com>>: Hi, On 04/29/2016 10:28 AM, Michael Haupt wrote: All, see http://cr.openjdk.java.net/~mhaupt/8031043/ <http://cr

Re: ClassValue perf?

Hi, On 04/29/2016 10:28 AM, Michael Haupt wrote: All, see http://cr.openjdk.java.net/~mhaupt/8031043/ for a snapshot of what is currently available. We have three patches: * Christian's, which simply reduces the HashMap size, * Peter's, which

Re: Questions about JDK-8136353 "ClassValue preventing class unloading"

On 01/07/2016 02:18 AM, William ML Leslie wrote: On 7 January 2016 at 07:34, Peter Levart wrote: ClassValue API could use a different strategy and reference the cached instance of type T from ClassValue instance instead, but then you would have a problem with ClassValue instances reachable

Re: Questions about JDK-8136353 "ClassValue preventing class unloading"

Hi Jochen, On 01/07/2016 03:05 PM, Jochen Theodorou wrote: Hi Peter, Am 06.01.2016 um 21:34 schrieb Peter Levart: [...] ClassValue API could use a different strategy and reference the cached instance of type T from ClassValue instance instead, but then you would have a problem with

Re: Questions about JDK-8136353 "ClassValue preventing class unloading"

On 01/07/2016 03:05 PM, Jochen Theodorou wrote: Hi Peter, Am 06.01.2016 um 21:34 schrieb Peter Levart: [...] Currently the cached instance of type T is reachable from Class instance and you are using Integer.TYPE in your example. Which means that the cached instance of T is never going to be

Re: Questions about JDK-8136353 "ClassValue preventing class unloading"

On 01/06/2016 09:34 PM, Peter Levart wrote: Hi Craig, I think that what you are asking for is impossible to achieve in current Java. ClassValue API is basically a cache that maps a pair: (ClassValue, Class) -> cached instance of type T You would like the cached instance of type T to

Re: Questions about JDK-8136353 "ClassValue preventing class unloading"

Hi Craig, I think that what you are asking for is impossible to achieve in current Java. ClassValue API is basically a cache that maps a pair: (ClassValue, Class) -> cached instance of type T You would like the cached instance of type T to not be reachable from either ClassValue instance o

Re: RFR: JDK-8136893: Improve early java.lang.invoke infrastructure initialization

null means bootstrap loader in other public APIs as well (for example: Class.forName(String name, boolean initialize, ClassLoader loader); ) although passing null from user code is rarely needed if at all. This is usually just for internal use. Regards, Peter Am 25.09.2015 um 08:46 schrieb P

Re: RFR: JDK-8136893: Improve early java.lang.invoke infrastructure initialization

entical - it's probably really easy to confuse the two when working at the core libs level. Unfortunately, the only proposal for a name I can make, fromDescriptorStringBootCL(), is clunky. Maybe that's acceptable for a low-level method only visible at package level. Am 25.09.2015 um 0

RFR: JDK-8136893: Improve early java.lang.invoke infrastructure initialization

Hi, I propose a simple fix for two initialization issues described/linked in: https://bugs.openjdk.java.net/browse/JDK-8136893 The patch is here: http://cr.openjdk.java.net/~plevart/jdk9-dev/8136893_MethodType.fromDescriptor/webrev.01/ The 1st issue is the method: MetodType.fromMethodDescript

Re: ClassValue perf?

also experiencing problems accessing links on cr.openjdk.java.net ? I get 404 - Not Found on any URL for 2 days now... SFTP works though, so I'm making these http URLs up from the sftp URLs. Hope this get fixed soon. On 05/03/2015 12:32 AM, Peter Levart wrote: Hi, I have considered

Re: ClassValue perf?

Hi, I have considered using ClassValue in the past because it is quite fast (as fast as a hash table can be) but was afraid of footprint overhead, because I saw with debugger a structure being grown before my eyes that was quite complicated and that I could not understand entirely. Now I took

Re: ClassLoader leak in MethodHandle.asType()

On 04/25/2015 02:12 AM, John Rose wrote: On Apr 24, 2015, at 3:24 PM, Peter Levart <mailto:peter.lev...@gmail.com>> wrote: Anyway. The inexact invoke() always transforms a specific MH to a generic one (Object, Object, ...)Object, right? Yes. So using inexact invoke() on any

Re: ClassLoader leak in MethodHandle.asType()

s intermixed with other asType() invocations. Regards, Peter On Apr 24, 2015, at 9:14 AM, Peter Levart <mailto:peter.lev...@gmail.com>> wrote: I think there is a Class(Loader) leak in MethodHandle.asType() implementation. If for example some MH (say mhX) is long lived (because it

ClassLoader leak in MethodHandle.asType()

Hi, I think there is a Class(Loader) leak in MethodHandle.asType() implementation. If for example some MH (say mhX) is long lived (because it is a system cached MH) and a client "generates" variants from it by invoking mhX.asType(newType) and the newType contains a type (either return type or

Re: Implementing VarHandle

On 04/19/2015 02:06 PM, Brian Goetz wrote: Thanks Remi. I’d like to separate this discussion into two components: implementation and API. Let’s talk about API first. We did give a fair amount of thought to the sigpoly-vs-typesafe API question. VarHandles allow you to abstract data access o

Re: [9] RFR (M): 8057967: CallSite dependency tracking scales devastatingly poorly

Hi Vladimir, Would it be possible for CallSite.context to hold the Cleaner instance itself (without indirection through DependencyContext)? DEFAULT_CONTEXT would then be a Cleaner instance that references some "default" Class object (for example DefaultContext.class that serves no other purp

Re: Lambda in security manager initialization fail

Hi Max, On 03/30/2015 05:24 PM, Wang Weijun wrote: I have a customized security manager: import java.security.AccessController; import java.security.PrivilegedAction; public class A3 extends SecurityManager { public A3() { // 1. Using lambda AccessController.doPrivileged

Re: What can we improve in JSR292 for Java 9?

On 02/26/2015 01:02 AM, Charles Oliver Nutter wrote: After talking with folks at the Jfokus VM Summit, it seems like there's a number of nice-to-have and a few need-to-have features we'd like to see get into java.lang.invoke. Vladimir suggested I start a thread on these features. A few from me:

Re: What can we improve in JSR292 for Java 9?

On 03/08/2015 01:38 PM, Jochen Theodorou wrote: Am 08.03.2015 12:16, schrieb Remi Forax: [...] You need to restrict the set of method handles that are allowed to be installed inside a CallSite corresponding to such kind of invokedynamic. Something like: you can do any transformations you want

Re: What can we improve in JSR292 for Java 9?

On 03/07/2015 02:53 PM, Remi Forax wrote: On 03/07/2015 06:31 AM, John Rose wrote: [...] (I wish we had a similar candidate for invokespecial/super. That is badly twisted around the verifier.) One way to solve the problem is to consider that invokedynamic is a special 'bytecode' for th

Re: What can we improve in JSR292 for Java 9?

On 03/05/2015 04:09 AM, Jochen Theodorou wrote: Am 04.03.2015 23:50, schrieb Charles Oliver Nutter: On Thu, Feb 26, 2015 at 4:27 AM, Jochen Theodorou wrote: my biggest request: allow the call of a super constructor (like super(foo,bar)) using MethodHandles an have it understood by the JVM lik

Re: [9] RFR (M): 8069591: Customize LambdaForms which are invoked using MH.invoke/invokeExact

On 01/23/2015 12:30 AM, John Rose wrote: On Jan 22, 2015, at 9:56 AM, Vladimir Ivanov wrote: Remi, John, thanks for review! Updated webrev: http://cr.openjdk.java.net/~vlivanov/8069591/webrev.01/ This time I did additional testing (COMPILE_THRESHOLD > 0) and spotted a problem with MethodHan

Re: [9] RFR (M): 8067344: Adjust java/lang/invoke/LFCaching/LFGarbageCollectedTest.java for recent changes in java.lang.invoke

Hi Vladimir, I just wanted to ask about the reason you used PhantomReference to detect that a referent is not softly reachable any more. You could use another SoftReference or a WeakReference for the same effect, since it is guaranteed that all SoftReferences for same referent are cleared ato

Re: [9, 8u40] RFR (M): 8057020: LambdaForm caches should support eviction

nger lifetime than they deserve (according to strict LRU policy), but the unreferenced ones should all be released before OOME is thrown anyway. Regards, Peter Best regards, Vladimir Ivanov Regards, Peter On 12/06/2014 01:30 PM, Peter Levart wrote: (Sorry for a re-send, forgot to include cor

Re: [9, 8u40] RFR (M): 8057020: LambdaForm caches should support eviction

at didn't "touch" the access time, would be helpful. Regards, Peter On 12/06/2014 01:30 PM, Peter Levart wrote: (Sorry for a re-send, forgot to include core-libs-dev)... Hi Vladimir, First, just a nit. I think that in LambdaFormEditor: 289 private LambdaForm putInCache(Tr

Re: [9, 8u40] RFR (M): 8057020: LambdaForm caches should support eviction

(Sorry for a re-send, forgot to include core-libs-dev)... Hi Vladimir, First, just a nit. I think that in LambdaFormEditor: 289 private LambdaForm putInCache(Transform key, LambdaForm form) { 290 key = key.withResult(form); 291 for (int pass = 0; ; pass++) { 292

Re: [9, 8u40] RFR (M): 8057020: LambdaForm caches should support eviction

Hi Vladimir, First, just a nit. I think that in LambdaFormEditor: 289 private LambdaForm putInCache(Transform key, LambdaForm form) { 290 key = key.withResult(form); 291 for (int pass = 0; ; pass++) { 292 Object c = lambdaForm.transformCache; 293

Re: [9, 8u40] RFR (M): 8057020: LambdaForm caches should support eviction

On 12/01/2014 05:58 PM, Vladimir Ivanov wrote: http://cr.openjdk.java.net/~vlivanov/8057020/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8057020 There are 2 major LambdaForm caches: LambdaFormEditor-based and MethodTypeForm. The former is per-LambdaForm and the latter is per method type

Re: invoking a interface default method from within an InvocationHandler

list of interfaces... I agree that sun.misc.ProxyGenerator can be much faster at generating new class than ASM. But it's also more difficult to program/change. So it depend on what changes would be necessary... Regards, Peter 2014-10-20 11:19 GMT+02:00 Paul Sandoz : On Oct 18, 2014, a

Re: invoking a interface default method from within an InvocationHandler

On 10/17/2014 11:58 AM, Paul Sandoz wrote: On Oct 16, 2014, at 12:43 PM, Remi Forax wrote: On 10/15/2014 06:54 PM, Paul Sandoz wrote: Hi Remi, I did some brief evaluation of this area. MethodHandleProxies.asInterfaceInstance currently does not support proxying to default methods. An Inter

Re: [9] RFR (S): 8058892: FILL_ARRAYS and ARRAYS are eagely initialized in MethodHandleImpl

. 82395900.795 (+-2794747.540) I don't see a noticeable difference (there's a lot of jitter - didn't turn off tiered compilation). Regards, Peter On Thu, Oct 2, 2014 at 3:12 PM, Peter Levart <mailto:peter.lev...@gmail.com>> wrote: Well, if I add the foll

Re: [9] RFR (S): 8058892: FILL_ARRAYS and ARRAYS are eagely initialized in MethodHandleImpl

82395900.795 2794747.540ops/s ...show that with fillByHand, varargs array is indeed eliminated. But then the "helper" method is not of any help, since it's not reusable for different array lengths... Regards, Peter On 10/02/2014 08:54 PM, Peter Levart wrote: On 10/0

Re: [9] RFR (S): 8058892: FILL_ARRAYS and ARRAYS are eagely initialized in MethodHandleImpl

ter Sent from my phone On Oct 2, 2014 2:34 PM, "Peter Levart" <mailto:peter.lev...@gmail.com>> wrote: On 10/02/2014 06:55 PM, Vladimir Ivanov wrote: Small update: http://cr.openjdk.java.net/~vlivanov/8058892/webrev.01/ <http://cr.openjd

Re: [9] RFR (S): 8058892: FILL_ARRAYS and ARRAYS are eagely initialized in MethodHandleImpl

On 10/02/2014 06:55 PM, Vladimir Ivanov wrote: Small update: http://cr.openjdk.java.net/~vlivanov/8058892/webrev.01/ Need to reorder initialization sequence in MHI.Lazy. Initialized FILL_ARRAYS and ARRAYS are required for later MH lookups. Additional testing: * jck (api/java_lang/invoke)

Re: [9] RFR (L): 8057042: LambdaFormEditor: derive new LFs from a base LF

est regards, Vladimir Ivanov [1] https://bugs.openjdk.java.net/browse/JDK-8057020 On 9/3/14, 3:43 PM, Peter Levart wrote: Hi Vladimir, I'm sure you and John have thought about it through, but I'll ask anyway. Are cached LambdaForms going to stay around forever? What about using a WeakRefere

Re: [9] RFR (L): 8057042: LambdaFormEditor: derive new LFs from a base LF

On 09/03/2014 03:25 PM, Vladimir Ivanov wrote: Peter, Thanks for the feedback. > In LambdaFormEditor, where Transform[] is promoted into ConcurrentHashMap: 339 ConcurrentHashMap m = new ConcurrentHashMap<>(MAX_CACHE_ARRAY_SIZE * 2); 340 for (Transfo

Re: [9] RFR (L): 8057042: LambdaFormEditor: derive new LFs from a base LF

Hi Vladimir, I'm sure you and John have thought about it through, but I'll ask anyway. Are cached LambdaForms going to stay around forever? What about using a WeakReference (LambdaFormEditor.Transform could extend WeakReference). This way unused LambdaForms would get GCed. Regards, Peter On

Re: [9] RFR (L): 8057042: LambdaFormEditor: derive new LFs from a base LF

On 09/02/2014 03:59 PM, Vladimir Ivanov wrote: Webrev: http://cr.openjdk.java.net/~vlivanov/8057042/webrev.00 Best regards, Vladimir Ivanov Hi Vladimir, In LambdaFormEditor, where Transform[] is promoted into ConcurrentHashMap: 339 ConcurrentHashMap m = new Concurrent

Re: RFR: 8000975: (process) Merge UNIXProcess.java.bsd & UNIXProcess.java.linux (& .solaris & .aix)

On 04/25/2014 12:44 PM, Paul Sandoz wrote: On Apr 25, 2014, at 12:04 PM, Peter Levart wrote: This is a ping for any Reviewer and also a question for Vladimir. Hello Vladimir, What do you think about the classloader issue in the resolving of classes in MemberName.getMethodType() described

Re: RFR: 8000975: (process) Merge UNIXProcess.java.bsd & UNIXProcess.java.linux (& .solaris & .aix)

/system class loader when initializing the LambdaForm class, but then i got distracted with other stuff and forgot about it.) Your one-liner fix seems to do the trick, but I think we need Vladimir to confirm this is OK. Paul. On Apr 17, 2014, at 11:49 PM, Peter Levart wrote: Hi, I'm

Re: RFR: 8000975: (process) Merge UNIXProcess.java.bsd & UNIXProcess.java.linux (& .solaris & .aix)

re insufficient for that purpose. But it would be cumbersome to transplant current security tests from Basic into an environment where it's the only invocation of the process api. On Thu, Apr 17, 2014 at 8:33 AM, Peter Levart <mailto:peter.lev...@gmail.com>> wrote: Hi Martin, Si

Re: [9] RFR (S): 8036117: MethodHandles.catchException doesn't handle VarargsCollector right (8034120 failed)

On 03/12/2014 12:44 PM, Peter Levart wrote: On 03/11/2014 05:46 PM, Vladimir Ivanov wrote: So all you're achieving by annotating prepend() method is that any exception stack trace, in case it is thrown inside the prepend() method, will hide where it was thrown from. In case all Lambd

Re: [9] RFR (S): 8036117: MethodHandles.catchException doesn't handle VarargsCollector right (8034120 failed)

gards, Peter Best regards, Vladimir Ivanov Regards, Peter There's not much value in it in this particular case, but I decided to reduce possible noise. Best regards, Vladimir Ivanov On 3/11/14 3:35 PM, Peter Levart wrote: Hi, Excuse my ignorant question: What is the purpose of @LambdaFor

Re: [9] RFR (S): 8036117: MethodHandles.catchException doesn't handle VarargsCollector right (8034120 failed)

eption would appear to be thrown from the invocation of the MH... Regards, Peter Best regards, Vladimir Ivanov Regards, Peter There's not much value in it in this particular case, but I decided to reduce possible noise. Best regards, Vladimir Ivanov On 3/11/14 3:35 PM, Peter Leva

Re: [9] RFR (S): 8036117: MethodHandles.catchException doesn't handle VarargsCollector right (8034120 failed)

Vladimir Ivanov On 3/11/14 3:35 PM, Peter Levart wrote: Hi, Excuse my ignorant question: What is the purpose of @LambdaForm.Hidden annotation? I suspect it has to do with hiding the call frames in stack traces that are part of LambdaForm invocation chain. In this case, method: privat

Re: [9] RFR (S): 8036117: MethodHandles.catchException doesn't handle VarargsCollector right (8034120 failed)

Hi, Excuse my ignorant question: What is the purpose of @LambdaForm.Hidden annotation? I suspect it has to do with hiding the call frames in stack traces that are part of LambdaForm invocation chain. In this case, method: private static Object[] prepend(Object elem, Object[] array)

MethodHandleInfo.getDeclaringClass()

Hi, The following code: public class Test { static class X { public void x() { } } static class Y extends X { } public static void main(String[] args) throws Exception { MethodHandles.Lookup lookup = MethodHandles.lookup(); MethodHandle mh = lookup.

Re: Signature of MethodHandleInfo.reflectAs is not specific enough

On 11/11/2013 08:14 AM, Peter Levart wrote: > The method could simply be: > > public T reflect(Lookup lookup); But if one needs to hint the compiler, explicit type parameters can be used as an escape hatch as always: > > Object o = info.reflect(lookup); > Well, w

Re: Signature of MethodHandleInfo.reflectAs is not specific enough

On 11/11/2013 02:24 AM, Ali Ebrahimi wrote: This is another workaround: public R reflectAs(Classsuper T> expected, Lookup lookup); info.reflectAs(Member.class, lookup);//works info.reflectAs(AnnotatedElement.class, lookup);//works info.reflectAs(Member.class, lookup);//works info.reflectAs(An

Re: Classes on the stack trace

a security feature, needed for implementation of MethodHandles. Regards, Peter Nick On Jul 31, 2013, at 2:36 AM, Peter Levart wrote: Hi Nick, The @CallerSensitive annotation is an annotation that prevents some other infrastructure, namely the MethodHandles, to "spoof&quo

Re: Classes on the stack trace

missing the point here? I just don't see a reason for @CallerSensitive. The code could do the exact same thing it currently is without @CallerSensitive (except for enforcing that frame 1 is @CallerSensitive, which really isn't necessary if you aren't using it in further frames). Though

Re: Classes on the stack trace (was: getElementClass/StackTraceElement, was: @CallerSensitive public API, was: sun.reflect.Reflection.getCallerClass)

On 07/30/2013 06:46 PM, MacGregor, Duncan (GE Energy Management) wrote: I can understand the worry about exposing @CallerSensitive methods, at least for the case of lookup.in() as I'm sure it could be used to open an exciting can of worms, but the current limitation doesn't feel quite right. I w

Re: Classes on the stack trace (was: getElementClass/StackTraceElement, was: @CallerSensitive public API, was: sun.reflect.Reflection.getCallerClass)

On 07/30/2013 03:19 PM, Jochen Theodorou wrote: Am 30.07.2013 14:17, schrieb Peter Levart: [...] So what would give Groovy or other language runtimes headaches when all there was was a parameter-less getCallerClass() API? Aren't the intermediate frames inserted by those runtimes controll

Re: Classes on the stack trace (was: getElementClass/StackTraceElement, was: @CallerSensitive public API, was: sun.reflect.Reflection.getCallerClass)

. In these cases, use of any new public API must use reflection (sudo code: If Java 8, use new public caller-sensitive API), so it needs code that it can pass a number into. Nick On Jul 30, 2013, at 7:17 AM, Peter Levart wrote: On 07/27/2013 09:01 PM, Nick Williams wrote: All, In the last

Re: Classes on the stack trace (was: getElementClass/StackTraceElement, was: @CallerSensitive public API, was: sun.reflect.Reflection.getCallerClass)

On 07/27/2013 09:01 PM, Nick Williams wrote: All, In the last two months, there have been a number of discussions surrounding stack traces, Classes on the stack trace, and caller classes [1], [2], [3]. These are all related discussions and the solution to them is equally related, so I wanted

Re: method handle cracking API

Hi John, I peeked at the implementation of HMI.asMember method: 111 +// Helper for default MethodHandleInfo.asMember. 112 +static Member reflectMember(MethodHandleInfo self) throws ReflectiveOperationException { 113 +int mods = self.getModifiers(); 114

Re: some thoughts on ClassValue

On 04/28/2013 12:31 AM, Peter Levart wrote: On 04/27/2013 11:54 PM, John Rose wrote: On Apr 27, 2013, at 2:34 PM, Jochen Theodorou <mailto:blackd...@gmx.org>> wrote: Am 27.04.2013 23:26, schrieb John Rose: ... Each instance of the Groovy runtime will use a distinct ClassValue

Re: some thoughts on ClassValue

On 04/27/2013 11:54 PM, John Rose wrote: On Apr 27, 2013, at 2:34 PM, Jochen Theodorou > wrote: Am 27.04.2013 23:26, schrieb John Rose: ... Each instance of the Groovy runtime will use a distinct ClassValue instance. If the ClassValue instance goes dead, then all t

Re: some thoughts on ClassValue

On 04/26/2013 09:59 AM, Jochen Theodorou wrote: > Hi all, > > basically ClassValue is there so that my runtime/framework or whatever > can store information and bind it to a class. The information is then > available as long as the class exists. In Groovy3 I am going to use this > for meta classes.

Re: another question about megamorphic call sites in combination with MethodHandles

On 03/22/2013 11:50 AM, Remi Forax wrote: On 03/22/2013 11:12 AM, Jochen Theodorou wrote: Am 22.03.2013 10:35, schrieb Remi Forax: On 03/22/2013 10:24 AM, Jochen Theodorou wrote: Am 22.03.2013 10:11, schrieb Remi Forax: [...] I don't think it's a good idea to expose directly method handles t