On Fri, 19 Mar 2021 14:34:00 GMT, Rafael Winterhalter <winterhal...@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
