[jdk16] RFR: 8256693: getAnnotatedReceiverType parameterizes types too eagerly
The fix for JDK-8256693 too often produces a ParameterizedType as the result of getAnnotatedReceiverType().getType() . A ParameterizedType is necessary only when this type or any of its transitive owner types has type parameters, but should be avoided if this isn't the case. This implementation recursively creates a chain of ParameterizedTypes starting from the outermost type that has type parameters. See here for the now closed JDK 17 pr: https://github.com/openjdk/jdk/pull/1414 - Commit messages: - Add javadoc note explaining empty type arguments array - 8256693: getAnnotatedReceiverType parameterizes types too eagerly Changes: https://git.openjdk.java.net/jdk16/pull/33/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk16&pr=33&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8256693 Stats: 133 lines in 4 files changed: 106 ins; 22 del; 5 mod Patch: https://git.openjdk.java.net/jdk16/pull/33.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/33/head:pull/33 PR: https://git.openjdk.java.net/jdk16/pull/33
Re: [jdk16] RFR: 8256693: getAnnotatedReceiverType parameterizes types too eagerly
On Wed, 16 Dec 2020 09:41:47 GMT, Joel Borggrén-Franck wrote: > The fix for JDK-8256693 too often produces a ParameterizedType as the result > of getAnnotatedReceiverType().getType() . A ParameterizedType is necessary > only when this type or any of its transitive owner types has type parameters, > but should be avoided if this isn't the case. > > This implementation recursively creates a chain of ParameterizedTypes > starting from the outermost type that has type parameters. > > See here for the now closed JDK 17 pr: > https://github.com/openjdk/jdk/pull/1414 Changes requested by vromero (Reviewer). test/jdk/java/lang/annotation/typeAnnotations/GetAnnotatedReceiverType.java line 181: > 179: if (failures != 0) > 180: throw new RuntimeException("Test failed, see log for > details"); > 181: else if (tests != 25) this looks a bit brittle, isn't it better to count the number of tests failing and issue an error if that number is > 0? - PR: https://git.openjdk.java.net/jdk16/pull/33
Re: [jdk16] RFR: 8256693: getAnnotatedReceiverType parameterizes types too eagerly
On Wed, 16 Dec 2020 16:26:37 GMT, Vicente Romero wrote: >> The fix for JDK-8256693 too often produces a ParameterizedType as the result >> of getAnnotatedReceiverType().getType() . A ParameterizedType is necessary >> only when this type or any of its transitive owner types has type >> parameters, but should be avoided if this isn't the case. >> >> This implementation recursively creates a chain of ParameterizedTypes >> starting from the outermost type that has type parameters. >> >> See here for the now closed JDK 17 pr: >> https://github.com/openjdk/jdk/pull/1414 > > test/jdk/java/lang/annotation/typeAnnotations/GetAnnotatedReceiverType.java > line 181: > >> 179: if (failures != 0) >> 180: throw new RuntimeException("Test failed, see log for >> details"); >> 181: else if (tests != 25) > > this looks a bit brittle, isn't it better to count the number of tests > failing and issue an error if that number is > 0? Yes, not great, but at least it isn't brittle when running the test, only when changing it. I'd like to take a separate pass over the tests for 17 if possible. - PR: https://git.openjdk.java.net/jdk16/pull/33
Re: [jdk16] RFR: 8256693: getAnnotatedReceiverType parameterizes types too eagerly
On Wed, 16 Dec 2020 19:57:32 GMT, Joel Borggrén-Franck wrote: > Yes, not great, but at least it isn't brittle when running the test, only > when changing it. I'd like to take a separate pass over the tests for 17 if > possible. what about declaring a static final field for that value instead of using a literal? - PR: https://git.openjdk.java.net/jdk16/pull/33
Re: [jdk16] RFR: 8256693: getAnnotatedReceiverType parameterizes types too eagerly [v2]
On Wed, 16 Dec 2020 21:21:19 GMT, Vicente Romero wrote: >> Yes, not great, but at least it isn't brittle when running the test, only >> when changing it. I'd like to take a separate pass over the tests for 17 if >> possible. > >> Yes, not great, but at least it isn't brittle when running the test, only >> when changing it. I'd like to take a separate pass over the tests for 17 if >> possible. > > what about declaring a static final field for that value instead of using a > literal? Done - PR: https://git.openjdk.java.net/jdk16/pull/33
Re: [jdk16] RFR: 8256693: getAnnotatedReceiverType parameterizes types too eagerly [v2]
> The fix for JDK-8256693 too often produces a ParameterizedType as the result > of getAnnotatedReceiverType().getType() . A ParameterizedType is necessary > only when this type or any of its transitive owner types has type parameters, > but should be avoided if this isn't the case. > > This implementation recursively creates a chain of ParameterizedTypes > starting from the outermost type that has type parameters. > > See here for the now closed JDK 17 pr: > https://github.com/openjdk/jdk/pull/1414 Joel Borggrén-Franck has updated the pull request incrementally with one additional commit since the last revision: Use constant for expected cases - Changes: - all: https://git.openjdk.java.net/jdk16/pull/33/files - new: https://git.openjdk.java.net/jdk16/pull/33/files/c04169d8..99e03115 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk16&pr=33&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk16&pr=33&range=00-01 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk16/pull/33.diff Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/33/head:pull/33 PR: https://git.openjdk.java.net/jdk16/pull/33
Re: [jdk16] RFR: 8256693: getAnnotatedReceiverType parameterizes types too eagerly [v2]
On Thu, 17 Dec 2020 10:07:13 GMT, Joel Borggrén-Franck wrote: >> The fix for JDK-8256693 too often produces a ParameterizedType as the result >> of getAnnotatedReceiverType().getType() . A ParameterizedType is necessary >> only when this type or any of its transitive owner types has type >> parameters, but should be avoided if this isn't the case. >> >> This implementation recursively creates a chain of ParameterizedTypes >> starting from the outermost type that has type parameters. >> >> See here for the now closed JDK 17 pr: >> https://github.com/openjdk/jdk/pull/1414 > > Joel Borggrén-Franck has updated the pull request incrementally with one > additional commit since the last revision: > > Use constant for expected cases Marked as reviewed by vromero (Reviewer). - PR: https://git.openjdk.java.net/jdk16/pull/33