[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
