8015470: (ann) IncompleteAnnotationException does not need to call toString
David Holmes
david.holmes at oracle.com
Mon Jun 3 11:55:50 UTC 2013
Hi Otavio,
I've put these into a webrev here:
http://cr.openjdk.java.net/~dholmes/8015470/webrev/
The changes touch a number of areas but hopefully are trivial enough
that we can keep the review on core-libs. As I've put this together I'll
be looking for a second reviewer to make sure I didn't mess it up :)
On 29/05/2013 9:03 PM, Otávio Gonçalves de Santana wrote:
> Thank you everyone.
> I searched classes with this situation and I find these classes:
>
> * sun.tools.java.MemberDefinition
Fixed
> * sun.rmi.rmic.Main
Fixed
> * sun.tools.jconsole.inspector.Utils
One of these could be needed for a null check (params[i].toString()).
> * com.sun.jndi.toolkit.dir.SearchFilter
Fixed
> * javax.swing.text.html.FormView
Needed for a null check.
Plus the IncompleteAnnotationExample case that doesn't perform the null
check.
Thanks,
David
>
>
> The diffs is in attachment
>
>
> On Tue, May 28, 2013 at 10:31 PM, David Holmes <david.holmes at oracle.com
> <mailto:david.holmes at oracle.com>> wrote:
>
> On 28/05/2013 11:08 PM, Remi Forax wrote:
>
> On 05/28/2013 02:48 PM, David Holmes wrote:
>
> Sorry it didn't register that getName() already returns a
> String -
> hence the toString() is redundant - but minimally so.
>
> David
>
>
> The second call to toString() also performs an implicit nullcheck
> (elementName can not be null).
> So if we have to fix something, it's only to remove the call to
> toString() after the call to getName().
>
>
> Good catch Remi!
>
> Otavio: I don't want to dissuade you from getting involved but as
> Remi indicates your suggested change becomes simply
>
>
> - super(annotationType.getName()__.toString() +
> + super(annotationType.getName() +
>
> and this is such a minor change to interpreted performance (the JIT
> will remove the toString call) that I don't think it is worth the
> process overhead (testing etc) to actually make this change. As I
> said in other email sometimes there are non-obvious reasons (like
> null checks :) ) that code has to be kept in its current form.
>
> David
> -----
>
>
> cheers,
> Rémi
>
>
> On 28/05/2013 9:15 PM, David Holmes wrote:
>
> Please see my reply under your original subject line.
>
> This is not a bug.
>
> David
>
> On 28/05/2013 7:37 PM, Otávio Gonçalves de Santana wrote:
>
> diff --git
> a/src/share/classes/java/lang/__annotation/__IncompleteAnnotationException.__java
>
>
> b/src/share/classes/java/lang/__annotation/__IncompleteAnnotationException.__java
>
>
> ---
> a/src/share/classes/java/lang/__annotation/__IncompleteAnnotationException.__java
>
>
> +++
> b/src/share/classes/java/lang/__annotation/__IncompleteAnnotationException.__java
>
>
> @@ -55,9 +55,9 @@
> public IncompleteAnnotationException(
> Class<? extends Annotation>
> annotationType,
> String elementName) {
> - super(annotationType.getName()__.toString() +
> + super(annotationType.getName() +
> " missing element " +
> - elementName.toString());
> + elementName);
>
> this.annotationType = annotationType;
> this.elementName = elementName;
>
>
>
>
>
>
> --
> Atenciosamente.
>
> Otávio Gonçalves de Santana
>
> blog: http://otaviosantana.blogspot.com.br/
> twitter: http://twitter.com/otaviojava
> site: http://www.otaviojava.com.br <http://www.otaviojava.com.br/>
> (11) 98255-3513
>
More information about the core-libs-dev
mailing list