Hi Paul, How about making the used (currently internal) annotation @PolymorphicSignature public in MethodHandle? Then the spec would be much easier to define (and future-proof). Of course, a separate ACC_POLYMORPHIC method access flag would have been better from the beginning! I assume, you had no free bits anymore?
In forbiddenapis I took the route to allow any class below java.lang.invoke to define polymorphic signatures. The new version is already out: 2.2 (https://github.com/policeman-tools/forbidden-apis/wiki/Changes) Uwe ----- Uwe Schindler uschind...@apache.org ASF Member, Apache Lucene PMC / Committer Bremen, Germany http://lucene.apache.org/ > -----Original Message----- > From: core-libs-dev [mailto:core-libs-dev-boun...@openjdk.java.net] On > Behalf Of Paul Sandoz > Sent: Thursday, June 23, 2016 9:18 AM > Cc: Java Core Libs <core-libs-dev@openjdk.java.net> > Subject: Re: Question about signature polymorphic, the VM spec of Java 7+, > and VarHandles > > Hi Uwe, > > The JL and JVM specifications have yet to be updated to take into account > the new sig-poly methods on VarHandle, they will be in due course by Alex. > > It’s not clear yet if we can specify this generally or we will have to > enumerate > on a per-class/method basis. Ideally it should be future proof. The tricky > bit is > the specification for invokevirtual. > > Paul. > > > On 16 Jun 2016, at 09:19, Uwe Schindler <uschind...@apache.org> wrote: > > > > Hi, > > > > the Java VM spec tells you the following how to "detect" signature > polymorphic methods in bytecode: > > > > === > > A method is signature polymorphic if and only if all of the following > conditions hold : > > - It is declared in the java.lang.invoke.MethodHandle class. > > - It has a single formal parameter of type Object[]. > > - It has a return type of Object. > > - It has the ACC_VARARGS and ACC_NATIVE flags set. > > > > In Java SE 7, the only signature polymorphic methods are the invoke and > invokeExact methods of the class java.lang.invoke.MethodHandle. > > > > The Java Virtual Machine gives special treatment to signature polymorphic > methods in the invokevirtual instruction (§invokevirtual), in order to effect > invocation of a method handle. A method handle is a typed, directly > executable reference to an underlying method, constructor, field, or similar > low-level operation (§5.4.3.5), with optional transformations of arguments or > return values. These transformations are quite general, and include such > patterns as conversion, insertion, deletion, and substitution. See the > java.lang.invoke package in the Java SE platform API for more information. > > === > > > > Now the question is: In java 9 the MethodHandle class is not the only one, > it also added VerHandle to the list of classes that use signature polymorphic! > > > > Now the problem I have: In the Javadocs it says: "Bytecode generators, > including the compiler back end, are required to emit untransformed > symbolic type descriptors for these methods. Tools which determine > symbolic linkage are required to accept such untransformed descriptors, > without reporting linkage errors." > > > > I am writing a bytecode analysis tool that needs to detect signature > polymorphic methods to have a special treatment with them when invoked > in bytecode. In my opinion, the above spec is fine for Java 7 and Java 8, but > breaks for Java 9, because also VarHandle was added. I think the spec should > be a bit more clear how to detect those methods: > > - Add a reflective getter on Method to check if its signature polymorphic > > - Make the annotation in MethodHandle public and document it. Also > change the spec to say: All native varargs methods with the *public* > annotation on it are signature polymorphic. > > - Change the spec to say: The above described flags and method desriptor > are used to detect (no change), but anything below java.lang.invoke is also > required. I don't really like that spec, because it may break again in future. > > > > I don't like the first part of the spec that says: this signature + > ACC_VARARGS + ACC_NATIVE. A 3rd party tool could create a method with > exactly that signature outside the JDK code, so I have to limit the package > name. Or use the annotations! That’s my problem with the spec! > > > > Whats the plan for the VM spec and "what's" the best way to detect if a > method is signature polymorphic - that is also future proof? > > > > In my code of forbiddenapis, see https://github.com/policeman- > tools/forbidden-apis/pull/106, I implemented purely the Java VM 8 spec, just > extending the class name matcher to "everything below java.lang.invoke", so > it also works for VarHandles. But as said, this does not look like "future- > proof". > > > > Uwe > > > > ----- > > Uwe Schindler > > uschind...@apache.org > > ASF Member, Apache Lucene PMC / Committer > > Bremen, Germany > > http://lucene.apache.org/ > > > >
