On Sun, 18 Oct 2020 22:21:37 GMT, Rafael Winterhalter
wrote:
> If an annotation member type is changed in an incompatible manner, the
> `AnnotationParser` currently throws a `NullPointerException` if:
>
> - An enumeration-typed member is changed to be an annotation type or a
> `Class` type.
Hi Robert,
I have to agree with Mandy and Alan here. What you propose, in terms of
getting more visibility into which class the classloader is trying to
load, is quite reasonable. But the mechanism is quite problematic for a
number of reasons as Mandy mentioned. In particular platform code
> A method's or constructor's owner type might carry annotations on its
> potential type parameters but is never represented as parameterized type what
> makes these parameters inaccessible at runtime, despite the presence of
> parameter type annotations.
Rafael Winterhalter has refreshed the
On Sun, 15 Nov 2020 19:49:57 GMT, Joel Borggrén-Franck
wrote:
>> Rafael Winterhalter has refreshed the contents of this pull request, and
>> previous commits have been removed. The incremental views will show
>> differences compared to the previous content of the PR. The pull request
>>
> A method's or constructor's owner type might carry annotations on its
> potential type parameters but is never represented as parameterized type what
> makes these parameters inaccessible at runtime, despite the presence of
> parameter type annotations.
Rafael Winterhalter has refreshed the
On Sat, 31 Oct 2020 21:11:15 GMT, Rafael Winterhalter
wrote:
>> A method's or constructor's owner type might carry annotations on its
>> potential type parameters but is never represented as parameterized type
>> what makes these parameters inaccessible at runtime, despite the presence of
>>
> JDK-8189198: Add "forRemoval = true" to Applet APIs
Andy Herrick has updated the pull request incrementally with one additional
commit since the last revision:
JDK-8189198: Add "forRemoval = true" to Applet APIs
-
Changes:
- all:
