Re: RFR: implementation for JEP 334: JVM Constants API

2018-06-03 Thread Vicente Romero
Hi all, There is a new iteration of the implementation at: [1] http://cr.openjdk.java.net/~vromero/constant.api/webrev.10 [2] http://cr.openjdk.java.net/~vromero/constant.api/javadoc.10 main changes in this iteration: we have added additional tests to improve code coverage. Thanks, Vicente

Re: RFR: implementation for JEP 334: JVM Constants API

2018-05-31 Thread Vicente Romero
Hi all, I have uploaded another iteration of the implementation of the constants API + the javadoc. Thanks for the comments so far, Vicente [1] http://cr.openjdk.java.net/~vromero/constant.api/webrev.09 [2] http://cr.openjdk.java.net/~vromero/constant.api/javadoc.09 On 05/24/2018 09:09 PM,

Re: RFR: implementation for JEP 334: JVM Constants API

2018-05-24 Thread Vicente Romero
Thanks for the comments so far, I have uploaded another iteration of the implementation + javadoc Vicente [1] http://cr.openjdk.java.net/~vromero/constant.api/webrev.08 [2] http://cr.openjdk.java.net/~vromero/constant.api/javadoc.08 On 05/23/2018 02:41 PM, Vicente Romero wrote: Hi all,

Re: RFR: implementation for JEP 334: JVM Constants API

2018-05-24 Thread Brian Goetz
EnumDesc and VarHandleDesc, those should be static inner classes of respectively Enum and VarHandle, they are not part of the main API but nice addons. After some thought, I am inclined to agree.  Here's the rationale. There are some built in constant types; they have Desc counterparts in

Re: RFR: implementation for JEP 334: JVM Constants API

2018-05-24 Thread Brian Goetz
Thanks for the review and the great comments! This version is far better than the previous one, ... or the previous seven :) MethodHandleDesc.Kind: The JVMS defines names for these constants, why using different names here ? Mostly for readability of client code.  Happy to consider

Re: RFR: implementation for JEP 334: JVM Constants API

2018-05-24 Thread Brian Goetz
This is the terminology used by the JVMS (JVMS 4.3.2).  Since these things model classfile entities, we adopted the JVMS terminology. On 5/24/2018 1:32 AM, Ali Ebrahimi wrote: I think using FieldTypeDescriptor is misleading. since that is used for param types and return types. I propose

Re: RFR: implementation for JEP 334: JVM Constants API

2018-05-24 Thread Andrej Golovnin
Hi Vincente, the following files do not have the copyright header: src/java.base/share/classes/java/lang/invoke/FieldTypeDescriptor.java src/java.base/share/classes/java/lang/invoke/MethodTypeDescriptor.java src/java.base/share/classes/java/lang/invoke/TypeDescriptor.java In the following files

Re: RFR: implementation for JEP 334: JVM Constants API

2018-05-24 Thread Remi Forax
by the JEP 334. regards, Rémi - Mail original - > De: "Vicente Romero" <vicente.rom...@oracle.com> > À: "amber-dev" <amber-...@openjdk.java.net>, "core-libs-dev" > <core-libs-dev@openjdk.java.net> > Envoyé: Mercredi 23 Mai 201

Re: RFR: implementation for JEP 334: JVM Constants API

2018-05-23 Thread Ali Ebrahimi
I think using FieldTypeDescriptor is misleading. since that is used for param types and return types. I propose SimpleTypeDescriptor or VariableTypeDescriptor. On Wed, May 23, 2018 at 11:11 PM, Vicente Romero wrote: > Hi all, > > Please review the proposed