Change of the toString implementation for annotations
Hello, I recognized a failing test on Java 9 caused by a changed return value returned by toString on an annotation with a class-property. When calling toString on an annotation: @interface Foo { Class<?> value(); } instantiated as @Foo(Bar.class) with Java 8 it would be printed as: @Foo(class Bar) while in Java 9 it is printed as: @Foo(Bar.class) Is this change intended? I do not see a big benefit of this implementation change and it could break code. In my case, the problem is not that big, it is an easy fix but still, I found it a bit surprising. Thank you. Best regards, Rafael
Hello Rafael, On 7/18/2016 5:43 PM, Rafael Winterhalter wrote:
Hello, I recognized a failing test on Java 9 caused by a changed return value returned by toString on an annotation with a class-property.
When calling toString on an annotation: @interface Foo { Class<?> value(); } instantiated as @Foo(Bar.class) with Java 8 it would be printed as:
@Foo(class Bar)
while in Java 9 it is printed as:
@Foo(Bar.class)
Is this change intended? I do not see a big benefit of this implementation change and it could break code. In my case, the problem is not that big, it is an easy fix but still, I found it a bit surprising.
I pushed the change your test noticed; it was done as part of JDK-5040830: (ann) please improve toString() for annotations containing exception proxies https://bugs.openjdk.java.net/browse/JDK-5040830 The basic rationale for the change is that "Foo.class" is the syntax that appears when annotations are in source code so the toString() form should generally reflect that. Thanks for running your project against JDK 9 builds; HTH, -Joe
Hi Joe, thank you for your answer. Can I ask for the rationale of using {} instead of [] only for classes? If the goal was to come closer to the source code representation, would this not imply to use curly braces for all array of an annotation? Thank you for your time! Best regards, Rafael 2016-07-19 4:13 GMT+02:00 joe darcy <joe.darcy@oracle.com>:
Hello Rafael,
On 7/18/2016 5:43 PM, Rafael Winterhalter wrote:
Hello, I recognized a failing test on Java 9 caused by a changed return value returned by toString on an annotation with a class-property.
When calling toString on an annotation: @interface Foo { Class<?> value(); } instantiated as @Foo(Bar.class) with Java 8 it would be printed as:
@Foo(class Bar)
while in Java 9 it is printed as:
@Foo(Bar.class)
Is this change intended? I do not see a big benefit of this implementation change and it could break code. In my case, the problem is not that big, it is an easy fix but still, I found it a bit surprising.
I pushed the change your test noticed; it was done as part of
JDK-5040830: (ann) please improve toString() for annotations containing exception proxies https://bugs.openjdk.java.net/browse/JDK-5040830
The basic rationale for the change is that "Foo.class" is the syntax that appears when annotations are in source code so the toString() form should generally reflect that.
Thanks for running your project against JDK 9 builds; HTH,
-Joe
Another remark about "printability". Array types are printed in their internal form, i.e. "java.lang.Void[].class" becomes "Ljava.lang.Void;.class" in the string form. While I very much agree over the improvements of the toString implementation of the unresolved values, I still wonder if this special treatment is really necessary and justify the compatibility break. Are the curly braces meant to avoid confusion from parsing annotation values where the braces could also be part of a type literal? Any parser would need to process the annotation string sensitively anyways as string values could contain any value, if this is the case. Best regards, Rafael 2016-07-28 15:38 GMT+02:00 Rafael Winterhalter <rafael.wth@gmail.com>:
Hi Joe, thank you for your answer. Can I ask for the rationale of using {} instead of [] only for classes? If the goal was to come closer to the source code representation, would this not imply to use curly braces for all array of an annotation? Thank you for your time! Best regards, Rafael
2016-07-19 4:13 GMT+02:00 joe darcy <joe.darcy@oracle.com>:
Hello Rafael,
On 7/18/2016 5:43 PM, Rafael Winterhalter wrote:
Hello, I recognized a failing test on Java 9 caused by a changed return value returned by toString on an annotation with a class-property.
When calling toString on an annotation: @interface Foo { Class<?> value(); } instantiated as @Foo(Bar.class) with Java 8 it would be printed as:
@Foo(class Bar)
while in Java 9 it is printed as:
@Foo(Bar.class)
Is this change intended? I do not see a big benefit of this implementation change and it could break code. In my case, the problem is not that big, it is an easy fix but still, I found it a bit surprising.
I pushed the change your test noticed; it was done as part of
JDK-5040830: (ann) please improve toString() for annotations containing exception proxies https://bugs.openjdk.java.net/browse/JDK-5040830
The basic rationale for the change is that "Foo.class" is the syntax that appears when annotations are in source code so the toString() form should generally reflect that.
Thanks for running your project against JDK 9 builds; HTH,
-Joe
It appears the plain overloads of Arrays.toString cannot be used to provide an annotation source compatible form since they use "[]" rather than "{}" to surround to contents. I'll see if I can handle that. On 7/28/2016 8:33 AM, Rafael Winterhalter wrote:
Another remark about "printability". Array types are printed in their internal form, i.e. "java.lang.Void[].class" becomes "Ljava.lang.Void;.class" in the string form.
Ah yes, good catch -- some more checking is required there.
While I very much agree over the improvements of the toString implementation of the unresolved values, I still wonder if this special treatment is really necessary and justify the compatibility break. Are the curly braces meant to avoid confusion from parsing annotation values where the braces could also be part of a type literal? Any parser would need to process the annotation string sensitively anyways as string values could contain any value, if this is the case.
As a general comment, the exact toString output of an annotation is deliberately not specified; from java.lang.annotation.Annotation.toString(): * Returns a string representation of this annotation. The details * of the representation are implementation-dependent [...] Therefore, the details of the toString output of annotations are not a formally exported interface of the platform. (For more details discussions of such matters see [1].) Early in the life of the platform, there was a preference to exactly specify toString output and hash values, etc., but this policy was found to be overly constraining so we moved away from that. HTH, -Joe [1] http://cr.openjdk.java.net/~darcy/OpenJdkDevGuide/OpenJdkDevelopersGuide.v0....
Best regards, Rafael
2016-07-28 15:38 GMT+02:00 Rafael Winterhalter <rafael.wth@gmail.com <mailto:rafael.wth@gmail.com>>:
Hi Joe, thank you for your answer. Can I ask for the rationale of using {} instead of [] only for classes? If the goal was to come closer to the source code representation, would this not imply to use curly braces for all array of an annotation? Thank you for your time! Best regards, Rafael
2016-07-19 4:13 GMT+02:00 joe darcy <joe.darcy@oracle.com <mailto:joe.darcy@oracle.com>>:
Hello Rafael,
On 7/18/2016 5:43 PM, Rafael Winterhalter wrote:
Hello, I recognized a failing test on Java 9 caused by a changed return value returned by toString on an annotation with a class-property.
When calling toString on an annotation: @interface Foo { Class<?> value(); } instantiated as @Foo(Bar.class) with Java 8 it would be printed as:
@Foo(class Bar)
while in Java 9 it is printed as:
@Foo(Bar.class)
Is this change intended? I do not see a big benefit of this implementation change and it could break code. In my case, the problem is not that big, it is an easy fix but still, I found it a bit surprising.
I pushed the change your test noticed; it was done as part of
JDK-5040830: (ann) please improve toString() for annotations containing exception proxies https://bugs.openjdk.java.net/browse/JDK-5040830
The basic rationale for the change is that "Foo.class" is the syntax that appears when annotations are in source code so the toString() form should generally reflect that.
Thanks for running your project against JDK 9 builds; HTH,
-Joe
participants (2)
-
joe darcy
-
Rafael Winterhalter