On Tue, 18 Apr 2023 02:22:11 GMT, Joe Darcy wrote:
> I think the code should reject it
The `AnnotationData` constructor already has a check for unknown annotation
element types so I think this concern is covered.
> leaving some bread crumb comments to future maintainers of core reflection
>
On Tue, 18 Apr 2023 01:06:31 GMT, Joe Darcy wrote:
>> Just above (line 228) you can see a call to this method where the argument
>> comes from `Map.values()` whose type is `Collection` so I'd prefer to leave
>> it as is rather than have to convert the argument to a `List`.
>
> In that case, I
On Mon, 17 Apr 2023 20:46:36 GMT, Doug Simon wrote:
> > From the long-term perspective, it is likely that the set of kinds of
> > elements that can occur in an annotation will be expanded, for example,
> > method references are a repeated request. Easing future maintenance to
> > gives more
On Mon, 17 Apr 2023 20:33:30 GMT, Doug Simon wrote:
>> src/java.base/share/classes/jdk/internal/vm/VMSupport.java line 234:
>>
>>> 232: * Encodes a list of annotations to a byte array. The byte array
>>> can be decoded with {@link #decodeAnnotations(byte[], AnnotationDecoder)}.
>>> 233:
On Mon, 17 Apr 2023 16:50:47 GMT, Joe Darcy wrote:
> the methods should phrase their operations in terms of these concepts...
I think this is what you're suggesting:
https://github.com/openjdk/jdk/pull/12810/commits/362738a61410cc8d60d8c4c4fc9e3e8ed0393aed
-
PR Comment:
On Mon, 17 Apr 2023 16:50:47 GMT, Joe Darcy wrote:
> From the long-term perspective, it is likely that the set of kinds of
> elements that can occur in an annotation will be expanded, for example,
> method references are a repeated request. Easing future maintenance to gives
> more
On Mon, 17 Apr 2023 20:33:26 GMT, Doug Simon wrote:
>> src/java.base/share/classes/jdk/internal/vm/VMSupport.java line 234:
>>
>>> 232: * Encodes a list of annotations to a byte array. The byte array
>>> can be decoded with {@link #decodeAnnotations(byte[], AnnotationDecoder)}.
>>> 233:
On Mon, 17 Apr 2023 15:32:56 GMT, Joe Darcy wrote:
>> Doug Simon has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> [skip ci] formatting fixes
>
> src/java.base/share/classes/jdk/internal/vm/VMSupport.java line 234:
>
>> 232: *
On Mon, 17 Apr 2023 15:48:53 GMT, Joe Darcy wrote:
>> Doug Simon has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> [skip ci] formatting fixes
>
> src/java.base/share/classes/jdk/internal/vm/VMSupport.java line 419:
>
>> 417: *
On Fri, 17 Mar 2023 15:38:49 GMT, Doug Simon wrote:
>> This PR extends JVMCI with new API (`jdk.vm.ci.meta.Annotated`) for
>> accessing annotations. The main differences from
>> `java.lang.reflect.AnnotatedElement` are:
>> * All methods in the `Annotated` interface explicitly specify requested
On Fri, 17 Mar 2023 15:38:49 GMT, Doug Simon wrote:
>> This PR extends JVMCI with new API (`jdk.vm.ci.meta.Annotated`) for
>> accessing annotations. The main differences from
>> `java.lang.reflect.AnnotatedElement` are:
>> * All methods in the `Annotated` interface explicitly specify requested
On Fri, 17 Mar 2023 15:38:49 GMT, Doug Simon wrote:
>> This PR extends JVMCI with new API (`jdk.vm.ci.meta.Annotated`) for
>> accessing annotations. The main differences from
>> `java.lang.reflect.AnnotatedElement` are:
>> * All methods in the `Annotated` interface explicitly specify requested
On Fri, 17 Mar 2023 15:38:49 GMT, Doug Simon wrote:
>> This PR extends JVMCI with new API (`jdk.vm.ci.meta.Annotated`) for
>> accessing annotations. The main differences from
>> `java.lang.reflect.AnnotatedElement` are:
>> * All methods in the `Annotated` interface explicitly specify requested
> This PR extends JVMCI with new API (`jdk.vm.ci.meta.Annotated`) for accessing
> annotations. The main differences from `java.lang.reflect.AnnotatedElement`
> are:
> * All methods in the `Annotated` interface explicitly specify requested
> annotation type(s). That is, there is no equivalent of
14 matches
Mail list logo
