JEP 358 (Helpful NPEs) and single source file mode
Hi, I've been exploring the new helpful NPE feature a bit. It's a very welcomed improvement, but I noticed one potential usability issue in conjunction with the single source file mode (JEP 330): as debug info is missing in that case, e.g. local variables are rendered as "" in the exception message. Single source file mode also doesn't let me specify the "-g:vars" option I could use with javac for adding the debugging info. Perhaps single source file mode should add debug information by default to prevent this issue? Thanks, --Gunnar
Re: Compact Number Formatting and Fraction Digits
Aaah, ok, so I *only* must call setMaximumFractionDigits(). That's the part I had missed so far; thanks! --Gunnar Am Fr., 18. Jan. 2019 um 00:35 Uhr schrieb Scott Palmer : > > > On Jan 17, 2019, at 2:22 PM, Gunnar Morling wrote: > > >> since you don’t actually want a minimum. > > > > I'd like to have 1 fractional digit unless it's 0: > > > > 1,000 -> 1K (*not* 1.0K) > > 1,500 -> 1.5K > > > > --Gunnar > > That’s exactly what setting the maximum fraction digits to 1 does. > > Scott > > > > > >> Am Do., 17. Jan. 2019 um 19:15 Uhr schrieb Scott Palmer > >> : > >> > >> > >> On Jan 17, 2019, at 12:42 PM, Gunnar Morling wrote: > >> > >>>> this could be a good value add to introduce an API [...] > >>> > >>> Should I file a JDK issue then (not sure I can even)? > >>> > >>>> Wouldn’t this be accomplished with setMaximumFractionDigits(1) ? > >>> > >>> That wouldn't achieve that there's no fraction digit(s) in case of > >>> trailing 0s. > >> > >> Yes it does. I just tried. Don’t set a minimum fraction digits, since you > >> don’t actually want a minimum. > >> > >> Scott > >> > >>> > >>>> Am Do., 17. Jan. 2019 um 15:50 Uhr schrieb Scott Palmer > >>>> : > >>>> > >>>> Wouldn’t this be accomplished with setMaximumFractionDigits(1) ? > >>>> > >>>>> On Jan 17, 2019, at 5:13 AM, Nishit Jain wrote: > >>>>> > >>>>> Hi Gunnar, > >>>>> > >>>>> Currently there is no way to obtain the below expected behavior (to get > >>>>> 1K) when min fraction digit is set to non-zero value. I think that is > >>>>> not even expected when min fraction digits is set, but considering the > >>>>> objective of compact number formatting this could be a good value add > >>>>> to introduce an API which if set, truncates trailing fractional zeros > >>>>> while formatting output. This may need some thought process on its > >>>>> feasibility. > >>>>> > >>>>> Regards, > >>>>> Nishit Jain > >>>>>> On 17-01-2019 14:37, Gunnar Morling wrote: > >>>>>> Hi, > >>>>>> > >>>>>> I took a look at the compact number formatting recently added in JDK > >>>>>> 12. > >>>>>> > >>>>>> There's setMinimumFractionDigits() to control the number of fractional > >>>>>> digits, so that e.g. 1,500 can be formatted as 1.5K. That's great, but > >>>>>> it also will format 1,000 as 1.0K. Is there a way to have fractional > >>>>>> digits but remove trailing zeros, so that 1,500 and 1,000 would be > >>>>>> formatted as 1.5K and 1K, respectively?
Re: Compact Number Formatting and Fraction Digits
> since you don’t actually want a minimum. I'd like to have 1 fractional digit unless it's 0: 1,000 -> 1K (*not* 1.0K) 1,500 -> 1.5K --Gunnar Am Do., 17. Jan. 2019 um 19:15 Uhr schrieb Scott Palmer : > > > On Jan 17, 2019, at 12:42 PM, Gunnar Morling wrote: > > >> this could be a good value add to introduce an API [...] > > > > Should I file a JDK issue then (not sure I can even)? > > > >> Wouldn’t this be accomplished with setMaximumFractionDigits(1) ? > > > > That wouldn't achieve that there's no fraction digit(s) in case of > > trailing 0s. > > Yes it does. I just tried. Don’t set a minimum fraction digits, since you > don’t actually want a minimum. > > Scott > > > > >> Am Do., 17. Jan. 2019 um 15:50 Uhr schrieb Scott Palmer > >> : > >> > >> Wouldn’t this be accomplished with setMaximumFractionDigits(1) ? > >> > >>> On Jan 17, 2019, at 5:13 AM, Nishit Jain wrote: > >>> > >>> Hi Gunnar, > >>> > >>> Currently there is no way to obtain the below expected behavior (to get > >>> 1K) when min fraction digit is set to non-zero value. I think that is not > >>> even expected when min fraction digits is set, but considering the > >>> objective of compact number formatting this could be a good value add to > >>> introduce an API which if set, truncates trailing fractional zeros while > >>> formatting output. This may need some thought process on its feasibility. > >>> > >>> Regards, > >>> Nishit Jain > >>>> On 17-01-2019 14:37, Gunnar Morling wrote: > >>>> Hi, > >>>> > >>>> I took a look at the compact number formatting recently added in JDK 12. > >>>> > >>>> There's setMinimumFractionDigits() to control the number of fractional > >>>> digits, so that e.g. 1,500 can be formatted as 1.5K. That's great, but > >>>> it also will format 1,000 as 1.0K. Is there a way to have fractional > >>>> digits but remove trailing zeros, so that 1,500 and 1,000 would be > >>>> formatted as 1.5K and 1K, respectively?
Re: Compact Number Formatting and Fraction Digits
> this could be a good value add to introduce an API [...] Should I file a JDK issue then (not sure I can even)? > Wouldn’t this be accomplished with setMaximumFractionDigits(1) ? That wouldn't achieve that there's no fraction digit(s) in case of trailing 0s. With min and max fraction digits set to 1, there'll always be exactly one fraction digit. So having an API that'd allow to remove trailing 0s would be very welcomed. Btw. another suggestion I'd have is to document guarantees in terms of thread-safety of CompactNumberFormat. It's a common mistake to use SimpleDateFormat concurrently from multiple threads (although its docs even state that this is incorrect). So CNF should at least document its behaviour (or even allow for concurrent access, if feasible). Am Do., 17. Jan. 2019 um 15:50 Uhr schrieb Scott Palmer : > > Wouldn’t this be accomplished with setMaximumFractionDigits(1) ? > > > On Jan 17, 2019, at 5:13 AM, Nishit Jain wrote: > > > > Hi Gunnar, > > > > Currently there is no way to obtain the below expected behavior (to get 1K) > > when min fraction digit is set to non-zero value. I think that is not even > > expected when min fraction digits is set, but considering the objective of > > compact number formatting this could be a good value add to introduce an > > API which if set, truncates trailing fractional zeros while formatting > > output. This may need some thought process on its feasibility. > > > > Regards, > > Nishit Jain > > On 17-01-2019 14:37, Gunnar Morling wrote: > >> Hi, > >> > >> I took a look at the compact number formatting recently added in JDK 12. > >> > >> There's setMinimumFractionDigits() to control the number of fractional > >> digits, so that e.g. 1,500 can be formatted as 1.5K. That's great, but > >> it also will format 1,000 as 1.0K. Is there a way to have fractional > >> digits but remove trailing zeros, so that 1,500 and 1,000 would be > >> formatted as 1.5K and 1K, respectively?
Compact Number Formatting and Fraction Digits
Hi, I took a look at the compact number formatting recently added in JDK 12. There's setMinimumFractionDigits() to control the number of fractional digits, so that e.g. 1,500 can be formatted as 1.5K. That's great, but it also will format 1,000 as 1.0K. Is there a way to have fractional digits but remove trailing zeros, so that 1,500 and 1,000 would be formatted as 1.5K and 1K, respectively? Thanks, --Gunnar
Re: Guaranteed order of annotations?
Hi Joe,
Thanks for your confirmation. Bean Validation may benefit from it, but
I understand that just a single request hardly justifies the change.
--Gunnar
2017-01-23 23:05 GMT+01:00 joe darcy <joe.da...@oracle.com>:
> Hi Gunnar,
>
> Annotations went into the platform way back in Java SE 5.0, with a GA during
> 2004. When working on repeating annotations, I was surprised to find there
> weren't stronger ordering guarantees for annotations from core reflection.
> However, requests to tighten this aspect of the platform haven't come up
> very often in the interim and I don't like it is likely to happen at this
> point.
>
> HTH,
>
> -Joe
>
>
>
> On 1/17/2017 11:26 PM, Gunnar Morling wrote:
>>
>> Joseph, all,
>>
>> Thanks for the clarification.
>>
>> Are there chances to establish such guaranteed ordering in a future
>> Java version? As pointed out, it'd be very helpful to Bean Validation
>> and I reckon other cases, too.
>>
>> Thanks,
>>
>> --Gunnar
>>
>>
>>
>> 2017-01-18 3:13 GMT+01:00 Joseph D. Darcy <joe.da...@oracle.com>:
>>>
>>> Hello,
>>>
>>> Following up on Joel's message, IIRC this ordering issue did come up
>>> during
>>> the design and testing of repeating annotations.
>>>
>>> As noted previously in the thread, while the ordering of the annotations
>>> in
>>> a container annotation is guaranteed, there is *not* a general ordering
>>> constraint on the annotations returned by the methods of the
>>> AnnotatedElement interface.
>>>
>>> HTH,
>>>
>>> -Joe
>>>
>>>
>>> On 1/13/2017 1:16 PM, Gunnar Morling wrote:
>>>>
>>>> Hi Yuri,
>>>>
>>>> Thanks for the pointer.
>>>>
>>>> But do you see any clear description of an order mandated for
>>>> getDeclaredAnnotations()? The only references to an order I can find
>>>> there are for repeatable annotations (where source code order is
>>>> maintained when retrieving them via the container annotation type).
>>>> But I cannot find any guaranteed order when obtaining all declared
>>>> annotations from an element.
>>>>
>>>> The reason why I'm asking is Bean Validation, where we've seen
>>>> requests of people that wish to validate the constraints of an element
>>>> in a fixed order, aborting after the first failed constraint:
>>>>
>>>> @NotNull
>>>> @Email
>>>> String email;
>>>>
>>>> Here one may want to first validate @NotNull and don't proceed with
>>>> validating @Email if the field is null.
>>>>
>>>> Relying on source order would be a very natural way to express the
>>>> order of constraints. Without a guaranteed ordering of annotations
>>>> we'd have to add some other means of ordering, e.g. an attribute with
>>>> the index (@NotNull(order=0) @Email(order=1)) which is more verbose of
>>>> course.
>>>>
>>>> --Gunnar
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> 2017-01-13 21:15 GMT+01:00 Yuri Gaevsky <ygaev...@azulsystems.com>:
>>>>>
>>>>> Hi Gunnar,
>>>>>
>>>>> Please take a look at JDK-8010679 'Clarify "present" and annotation
>>>>> ordering in Core Reflection for Annotations' [*].
>>>>>
>>>>> Best regards,
>>>>> -Yuri
>>>>>
>>>>> [*] https://bugs.openjdk.java.net/browse/JDK-8010679
>>>>>
>>>>>
>>>>> -Original Message-
>>>>> From: core-libs-dev [mailto:core-libs-dev-boun...@openjdk.java.net] On
>>>>> Behalf Of Gunnar Morling
>>>>> Sent: Friday, January 13, 2017 08:14 PM
>>>>> To: core-libs-dev@openjdk.java.net
>>>>> Subject: Guaranteed order of annotations?
>>>>>
>>>>> Hi,
>>>>>
>>>>> Is there any order guaranteed in which an element's annotations are
>>>>> returned by AnnotatedElement#getDeclaredAnnotations()? Specifically,
>>>>> is this the order in which the annotations are given in the source
>>>>> code?
>>>>>
>>>>> Section 9.7.5. of the JLS ("Multiple Annotations of the Same Type")
>>>>> makes a statement of the source order being considered by the array of
>>>>> the implicit container annotation created for a repeatable annotation
>>>>> ("[...] all the base annotations in the left-to-right order in which
>>>>> they appeared in the context").
>>>>>
>>>>> But I couldn't find any authoritative description on the ordering
>>>>> behaviour of getDeclaredAnnotations(). Should we assume that we cannot
>>>>> rely on the order in the source?
>>>>>
>>>>> Thanks for any pointers,
>>>>>
>>>>> --Gunnar
>>>
>>>
>
Re: Guaranteed order of annotations?
Joseph, all,
Thanks for the clarification.
Are there chances to establish such guaranteed ordering in a future
Java version? As pointed out, it'd be very helpful to Bean Validation
and I reckon other cases, too.
Thanks,
--Gunnar
2017-01-18 3:13 GMT+01:00 Joseph D. Darcy <joe.da...@oracle.com>:
> Hello,
>
> Following up on Joel's message, IIRC this ordering issue did come up during
> the design and testing of repeating annotations.
>
> As noted previously in the thread, while the ordering of the annotations in
> a container annotation is guaranteed, there is *not* a general ordering
> constraint on the annotations returned by the methods of the
> AnnotatedElement interface.
>
> HTH,
>
> -Joe
>
>
> On 1/13/2017 1:16 PM, Gunnar Morling wrote:
>>
>> Hi Yuri,
>>
>> Thanks for the pointer.
>>
>> But do you see any clear description of an order mandated for
>> getDeclaredAnnotations()? The only references to an order I can find
>> there are for repeatable annotations (where source code order is
>> maintained when retrieving them via the container annotation type).
>> But I cannot find any guaranteed order when obtaining all declared
>> annotations from an element.
>>
>> The reason why I'm asking is Bean Validation, where we've seen
>> requests of people that wish to validate the constraints of an element
>> in a fixed order, aborting after the first failed constraint:
>>
>> @NotNull
>> @Email
>> String email;
>>
>> Here one may want to first validate @NotNull and don't proceed with
>> validating @Email if the field is null.
>>
>> Relying on source order would be a very natural way to express the
>> order of constraints. Without a guaranteed ordering of annotations
>> we'd have to add some other means of ordering, e.g. an attribute with
>> the index (@NotNull(order=0) @Email(order=1)) which is more verbose of
>> course.
>>
>> --Gunnar
>>
>>
>>
>>
>>
>> 2017-01-13 21:15 GMT+01:00 Yuri Gaevsky <ygaev...@azulsystems.com>:
>>>
>>> Hi Gunnar,
>>>
>>> Please take a look at JDK-8010679 'Clarify "present" and annotation
>>> ordering in Core Reflection for Annotations' [*].
>>>
>>> Best regards,
>>> -Yuri
>>>
>>> [*] https://bugs.openjdk.java.net/browse/JDK-8010679
>>>
>>>
>>> -Original Message-
>>> From: core-libs-dev [mailto:core-libs-dev-boun...@openjdk.java.net] On
>>> Behalf Of Gunnar Morling
>>> Sent: Friday, January 13, 2017 08:14 PM
>>> To: core-libs-dev@openjdk.java.net
>>> Subject: Guaranteed order of annotations?
>>>
>>> Hi,
>>>
>>> Is there any order guaranteed in which an element's annotations are
>>> returned by AnnotatedElement#getDeclaredAnnotations()? Specifically,
>>> is this the order in which the annotations are given in the source
>>> code?
>>>
>>> Section 9.7.5. of the JLS ("Multiple Annotations of the Same Type")
>>> makes a statement of the source order being considered by the array of
>>> the implicit container annotation created for a repeatable annotation
>>> ("[...] all the base annotations in the left-to-right order in which
>>> they appeared in the context").
>>>
>>> But I couldn't find any authoritative description on the ordering
>>> behaviour of getDeclaredAnnotations(). Should we assume that we cannot
>>> rely on the order in the source?
>>>
>>> Thanks for any pointers,
>>>
>>> --Gunnar
>
>
Re: Guaranteed order of annotations?
Hi Yuri,
Thanks for the pointer.
But do you see any clear description of an order mandated for
getDeclaredAnnotations()? The only references to an order I can find
there are for repeatable annotations (where source code order is
maintained when retrieving them via the container annotation type).
But I cannot find any guaranteed order when obtaining all declared
annotations from an element.
The reason why I'm asking is Bean Validation, where we've seen
requests of people that wish to validate the constraints of an element
in a fixed order, aborting after the first failed constraint:
@NotNull
@Email
String email;
Here one may want to first validate @NotNull and don't proceed with
validating @Email if the field is null.
Relying on source order would be a very natural way to express the
order of constraints. Without a guaranteed ordering of annotations
we'd have to add some other means of ordering, e.g. an attribute with
the index (@NotNull(order=0) @Email(order=1)) which is more verbose of
course.
--Gunnar
2017-01-13 21:15 GMT+01:00 Yuri Gaevsky <ygaev...@azulsystems.com>:
> Hi Gunnar,
>
> Please take a look at JDK-8010679 'Clarify "present" and annotation ordering
> in Core Reflection for Annotations' [*].
>
> Best regards,
> -Yuri
>
> [*] https://bugs.openjdk.java.net/browse/JDK-8010679
>
>
> -Original Message-
> From: core-libs-dev [mailto:core-libs-dev-boun...@openjdk.java.net] On Behalf
> Of Gunnar Morling
> Sent: Friday, January 13, 2017 08:14 PM
> To: core-libs-dev@openjdk.java.net
> Subject: Guaranteed order of annotations?
>
> Hi,
>
> Is there any order guaranteed in which an element's annotations are
> returned by AnnotatedElement#getDeclaredAnnotations()? Specifically,
> is this the order in which the annotations are given in the source
> code?
>
> Section 9.7.5. of the JLS ("Multiple Annotations of the Same Type")
> makes a statement of the source order being considered by the array of
> the implicit container annotation created for a repeatable annotation
> ("[...] all the base annotations in the left-to-right order in which
> they appeared in the context").
>
> But I couldn't find any authoritative description on the ordering
> behaviour of getDeclaredAnnotations(). Should we assume that we cannot
> rely on the order in the source?
>
> Thanks for any pointers,
>
> --Gunnar
Guaranteed order of annotations?
Hi,
Is there any order guaranteed in which an element's annotations are
returned by AnnotatedElement#getDeclaredAnnotations()? Specifically,
is this the order in which the annotations are given in the source
code?
Section 9.7.5. of the JLS ("Multiple Annotations of the Same Type")
makes a statement of the source order being considered by the array of
the implicit container annotation created for a repeatable annotation
("[...] all the base annotations in the left-to-right order in which
they appeared in the context").
But I couldn't find any authoritative description on the ordering
behaviour of getDeclaredAnnotations(). Should we assume that we cannot
rely on the order in the source?
Thanks for any pointers,
--Gunnar
Proposal: Add a type token class for representing generic types
Hi, I'd like to suggest the addition of a type token class to the Java class library, to be used for representing generic types such as List. Actual class literals can only represent raw types. But often libraries have the need to apply some sort of configuration to specific generic types, link specific behaviour to them or expose (meta) data related to them. The suggested type token class would allow to implement such cases in a type-safe fashion. # Example use cases * The "type-safe heterogenous container" pattern from Joshua Bloch's book "Effective Java" introduces a container which allows to safely store and retrieve objects of different types. They are keyed by Class, which means that one cannot have a value for a List and another value for a List in such container. Also one cannot obtain a List without casting from such container. Type literals would allow this: void put(TypeLiteral type, T value); T get(TypeLiteral type); TypeLiteralstringListType = ...; List stringList = container.get( stringListType ); * JAX-RS allows to read response message entities into parameterized types using its GenericType class: List customers = response.readEntity( new GenericType
() {} ); * CDI allows to dynamically obtain beans of specific parameterized types using its TypeLiteral class: @Inject @Any Instance anyPaymentProcessor; public PaymentProcessor getChequePaymentProcessor() { PaymentProcessor pp = anyPaymentProcessor .select( new TypeLiteral
() {} ).get(); } # Proposed solution Type literals would be represented by a new type java.lang.reflect.TypeLiteral. Instances would be created via sub-classing, capturing the parameter and baking it into the sub-class: TypeLiteral stringListType = new TypeLiteral
(){}; That'd allow to provide type-safe APIs around generic types as shown in the examples above. The following methods should be defined on TypeLiteral in order to make it useful for implementers of such APIs: Type getType(); Class getRawType(); boolean equals(Object obj); int hashCode(); String toString(); # Prior art The idea of type tokens based on capturing a generic type in a sub-class has been around for a long time. The first reference I've found is Neal Gafter's blog post on "Super Type Tokens" from 2006 [1]. Examples in real-world APIs and libraries are TypeLiteral in CDI [2], GenericType in JAX-RS [3], TypeLiteral in commons-lang [4] and TypeToken in Guava [5]. # Alternatives and shortcomings The obvious alternative would be reified generics, but I think it's commonly agreed upon that these will not come to the Java language any time soon. Without native support in the language itself the proposed type literal class is the best way to support the mentioned use cases as far as I can say. Shortcomings are the creation of a sub-class per literal instantiation (probably more an aesthetic problem, though) and failure of the pattern when type variables are included anywhere in the represented type [6]. Unfortunately, this can only be detected at runtime when instantiating a literal but not by the compiler (although, I reckon it technically could, by handling this case specifically). # Conclusion Lacking reified generics, the Java platform would benefit from the addition of new type token class java.lang.reflect.TypeLiteral. The pattern's presence in common APIs and libraries shows that there is a wide-spread need for such mechanism and the community would benefit very much from a standardized solution in the JDK itself. This will allow for more unified API designs as well as foster integration of different libraries. I'm eager to learn about your feedback and the OpenJDK team's assessment of this proposal. --Gunnar [1] http://gafter.blogspot.de/2006/12/super-type-tokens.html [2] https://docs.oracle.com/javaee/7/api/index.html?javax/enterprise/util/TypeLiteral.html [3] https://docs.oracle.com/javaee/7/api/index.html?javax/ws/rs/core/GenericType.html [4] https://commons.apache.org/proper/commons-lang/apidocs/org/apache/commons/lang3/reflect/TypeLiteral.html [5] https://google.github.io/guava/releases/20.0/api/docs/index.html?com/google/common/reflect/TypeToken.html [6] http://gafter.blogspot.de/2007/05/limitation-of-super-type-tokens.html
Accessing type annotations at runtime
Hi, Is it possible to retrieve type annotations (as defined by JSR 308) using reflection at runtime? E.g. I would like to retrieve the @NotNull annotation from a member declared like this: private List@NotNull String names; I assumed that this would be possible using reflection, but I couldn't find a way to do it. Is there an example for this somewhere? Or are type annotations only meant to be accessed by compile-time tools such as the Checker framework? I noticed that the byte code of my class contains information about the annotation, so I guess one could access it by examining the class file if it's really not possible via the reflection API. Many thanks, --Gunnar
Re: Accessing type annotations at runtime
Hi Joe, Thanks for the reply and hinting me the right direction! I had seen these methods but was missing the down-cast to AnnotatedParameterizedType which gives access to getAnnotatedActualTypeArguments(). In case it's helpful to others, that's what I ended up with: Field myField = ...; // ListString AnnotatedParameterizedType type = (AnnotatedParameterizedType) declaredField.getAnnotatedType(); // String AnnotatedType typeArg = type.getAnnotatedActualTypeArguments()[0]; // @NotNull Annotation annotation = typeArg.getAnnotations()[0]; Thanks again, --Gunnar 2014-03-13 15:39 GMT+01:00 Joe Darcy joe.da...@oracle.com: Hello, See the methods in java.lang.reflect named getAnnotedFoo which return java.lang.reflect.AnnotedType or a subinterface. -Joe On 3/13/2014 6:24 AM, Gunnar Morling wrote: Hi, Is it possible to retrieve type annotations (as defined by JSR 308) using reflection at runtime? E.g. I would like to retrieve the @NotNull annotation from a member declared like this: private List@NotNull String names; I assumed that this would be possible using reflection, but I couldn't find a way to do it. Is there an example for this somewhere? Or are type annotations only meant to be accessed by compile-time tools such as the Checker framework? I noticed that the byte code of my class contains information about the annotation, so I guess one could access it by examining the class file if it's really not possible via the reflection API. Many thanks, --Gunnar
Re: (reflect) Accessing members of inner annotations types
Hi, Many thanks for the investigation and suggested workarounds. Bean Validation recommends to declare an inner @List annotation to specify several constraints of the same type on a given element, but its ok to deviate from that pattern in the rare cases of package-private constraint types. I can file a bug/rfe for this. I think that would be great; Taking the referenced types into account when determining the package for generated proxy classes sounds reasonable to me. Thanks again, --Gunnar 2014/1/8 Joel Borggren-Franck joel.fra...@oracle.com On 2014-01-08, Peter Levart wrote: On 01/08/2014 01:00 PM, Joel Borggren-Franck wrote: Perhaps an alternative would be to check if the interface a proxy is proxying is nested. In that case use the outermost interface's access level for the package calculation. This would probably lead to a few more proxies being generated into the real package compared to your proposal. I don't know if that is ok or not. The nested public interface need not be referencing the outer class/interface. In this case, proxy class can be generated in com.sun.proxy. Yes, this is the reason for my remark about more proxies being generated into the real package. I'm not sure this is a problem, however it is moot considering you second point. More importantly, even if the outer interface/class was public, the nested interface could be referencing some other package-private type. For example: Ugh. Acknowledged. (This feels like a really bad practice but that doesn't matter here.) cheers /Joel
(reflect) Accessing members of inner annotations types
Hi,
In the course of running the Bean Validation TCK on JDK 8, I'm
investigating an issue around reflectively accessing members of annotations
which are declared as inner type of another, package-private annotation
type.
The following shows an example:
@Retention( RetentionPolicy.RUNTIME )
/*package-private */ @interface Named {
@Retention( RetentionPolicy.RUNTIME )
/*package-private */ @interface List {
Named[] value();
}
}
The @List annotation is used as this on a type in the same package:
public class Foo {
@Named.List( @Named )
public void getBar() {}
}
I'm then trying to access the @Named annotation using reflection like this:
Annotation listAnnotation = Foo.class.getMethod( getBar
).getAnnotations()[0];
Method method = listAnnotation.getClass().getMethod( value );
method.setAccessible( true );
//fails
Annotation namedAnnotation = ( (Annotation[]) method.invoke(
listAnnotation ) )[0];
This is the exception I get:
IllegalAccessError: tried to access class com.example.Named from class
com.sun.proxy.$Proxy3
at com.sun.proxy.$Proxy3.value(Unknown Source)
Interestingly, this only occurs when the List annotation is declared as an
inner type within the Named type; it works when the List annotation is a
top-level package-private type (the Named annotation still being
package-private) as well as when it is declared as an inner type within
another package-private class.
I first thought that this might be related to 8004260 (dynamic proxy class
should have the same Java language access as the proxy interfaces), but
the issue occurs on on JDK 7 as well.
Is this a potential issue with the access check implementation or is
something wrong here with the way I'm accessing the annotation member?
Thanks for any help,
--Gunnar
