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