Hi Uwe, it's a different issue, but still: https://bugs.openjdk.java.net/browse/JDK-8157225
Best, Michael > Am 13.05.2016 um 12:14 schrieb Uwe Schindler <uschind...@apache.org>: > > Hi, > > One addition, maybe add to issue: > > If this was added, jdk.dynalink module could use it, too - this was mentioned > by Attila already: > http://hg.openjdk.java.net/jdk9/dev/nashorn/file/4b118e012ac4/src/jdk.dynalink/share/classes/jdk/dynalink/beans/BeanLinker.java > > Uwe > > ----- > Uwe Schindler > uschind...@apache.org > ASF Member, Apache Lucene PMC / Committer > Bremen, Germany > http://lucene.apache.org/ > >> -----Original Message----- >> From: Uwe Schindler [mailto:uschind...@apache.org] >> Sent: Friday, May 13, 2016 11:55 AM >> To: 'Remi Forax' <fo...@univ-mlv.fr> >> Cc: 'Michael Haupt' <michael.ha...@oracle.com>; 'Core-Libs-Dev' <core-libs- >> d...@openjdk.java.net> >> Subject: RE: MethodHandle for array length >> >> Hi, >> >> OK, thanks for creating an issue! >> >> Uwe >> >> ----- >> Uwe Schindler >> uschind...@apache.org >> ASF Member, Apache Lucene PMC / Committer >> Bremen, Germany >> http://lucene.apache.org/ >> >>> -----Original Message----- >>> From: Remi Forax [mailto:fo...@univ-mlv.fr] >>> Sent: Friday, May 13, 2016 10:37 AM >>> To: Uwe Schindler <uschind...@apache.org> >>> Cc: Michael Haupt <michael.ha...@oracle.com>; Core-Libs-Dev <core-libs- >>> d...@openjdk.java.net> >>> Subject: Re: MethodHandle for array length >>> >>> Hi Uwe, >>> I was planning to add a bug for this feature but it seems that Michael was >>> faster than me, >>> https://bugs.openjdk.java.net/browse/JDK-8156915 >>> >>> regards, >>> Rémi >>> >>> ----- Mail original ----- >>>> De: "Uwe Schindler" <uschind...@apache.org> >>>> À: "Michael Haupt" <michael.ha...@oracle.com>, "Core-Libs-Dev" >> <core- >>> libs-...@openjdk.java.net> >>>> Envoyé: Jeudi 12 Mai 2016 14:34:34 >>>> Objet: RE: MethodHandle for array length >>>> >>>> Hi Michael, >>>> >>>>>> Am 11.05.2016 um 21:35 schrieb Uwe Schindler >>> <uschind...@apache.org>: >>>>>> With Java 9 this gets a bit worse: There is no "easy way" with the >>>>> MethodHanldes class to generate a MethodHandles.countedLoop() on >> all >>>>> elements of an array: >>>>>> >>>>>> public static MethodHandle countedLoop(MethodHandle iterations, >>>>> MethodHandle init, MethodHandle body) [new in Java 9] >>>>> >>>>> this isn't a remedy when you need the index in each iteration, but you >>> can >>>>> generate a loop over all elements of an array using iteratedLoop(), as >>>>> illustrated by this test from LoopCombinatorTest: >>>>> >>>>> @Test >>>>> public static void testIterateSum() throws Throwable { >>>>> // Integer[] a = new Integer[]{1,2,3,4,5,6}; int sum = 0; for (int e : >>>>> a) { sum >>>>> += e; } return sum; => 21 >>>>> MethodHandle loop = >>>>> MethodHandles.iteratedLoop(Iterate.MH_sumIterator, >>> Iterate.MH_sumInit, >>>>> Iterate.MH_sumStep); >>>>> assertEquals(Iterate.MT_sum, loop.type()); >>>>> assertEquals(21, loop.invoke(new Integer[]{1, 2, 3, 4, 5, 6})); >>>>> } >>>>> >>>>> ... where MH_sumIterator is a handle to this method: >>>>> >>>>> static Iterator<Integer> sumIterator(Integer[] a) { >>>>> return Arrays.asList(a).iterator(); >>>>> } >>>> >>>> Of course this works, too. >>>> >>>> My proposal or question here was more about the API inconsistency in >>> general. >>>> You can do a lot here and there, you can implement effective or >>>> non-effective loops with MethodHandles, but still the following holds >> true: >>>> java.lang.invoke.MethodHandles is missing an accessor for >> "array.length", >>>> which is not understandable. The "countedLoop" here was just an >> example >>> use >>>> case (if that one is great or not does not matter), it was just posted to >>>> actually show the API and how it *could* be used. >>>> >>>> The real example from our script engine was not related to loops, it was >> an >>>> actual invokedynamic callsite implementation where it was not possible >> to >>>> figure out how to get a method handle to the very special arraylength >> byte >>>> code, aka "array.length javac sugar". Everything else to handle arrays is >>>> there at one single place, but the array length is missing and you get very >>>> annoyed. If you are not so familiar to bytecode and the mechanics >> behind, >>>> you have a very hard time to find out how to do this: the intuitive >>>> solutions does not work: "array.length" -> aha it’s a field, so let's try >>>> Lookup.findGetter(long[].class, "length", int.class) -> does not work! >>>> >>>> What is so hard to accept the proposal to have >>>> MethodHandles.arrayLengthGetter, implemented in the most effective >>> way (as a >>>> methodhandle that solely calls the special bytecode "arraylength")? In >> fact >>>> thais is like a 10 liner to implement + Javadocs. No need to delay a >>>> release, there are still changes in JDK 9 going on that are far more risky >>>> than this. >>>> >>>> Best, >>>> Uwe -- <http://www.oracle.com/> Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | LangTools Team | Nashorn Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 München Registergericht: Amtsgericht München, HRA 95603 Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher <http://www.oracle.com/commitment> Oracle is committed to developing practices and products that help protect the environment
