RFR: 8263763: Synthetic constructor parameters of enum are not considered for annotation indices

Tagir F.Valeev tvaleev at openjdk.java.net
Mon Mar 22 07:55:39 UTC 2021


On Fri, 19 Mar 2021 14:34:00 GMT, Rafael Winterhalter <winterhalter at openjdk.org> wrote:

>> A general comment, the enum constructor situation is a bit tricky as
>> 
>> 1) There is no 100% reliable way to determine which of a enum constructor's args are synthetic.
>> 
>> 2) How a Java compiler generates enum constructors is a compiler-internal contract since all the enum constructors must be private.
>> 
>> It is true that javac has consistently added two extra parameters as an implementation detail. Offhand, I don't know if ecj in particular has made the same choice. javac is not obliged to continue implementing enum constructors in this manner, so for better robustness, I think a fix in this space needs to be able to accommodate situations other than exactly N+2 parameters.
>
> *ejc* issues the same constructor that prefixes a `String` and an `int` parameter. I agree that the solution is not perfect, but I would prefer it over the reflection API throwing an `IndexOutOfBoundsException` upon calling `getAnnotations()`, which nobody really expects upon a getter invocation.
> 
> I added a check to see if the enum constructor in question starts with a `String` and `int` parameter after checking if there are two excess parameters. I believe that that's at least an improvement over today's state where it's very unlikely that an enum constructor  yields an incorrect result in the reflection API whereas the result it is always incorrect today, given the implementation of both *ejc* and *javac*.
> 
> Ideally, this would of course also be fixed by javac (and ejc) such that the annotations are placed on the correct indices, but I still argue that the fix is an improvement for being able to properly process enum constructors for older class files also.

@raphw a duplicate? https://bugs.openjdk.java.net/browse/JDK-8246586

-------------

PR: https://git.openjdk.java.net/jdk/pull/3082


More information about the core-libs-dev mailing list