Bug 301589 - Should warn if creating a new Boolean instance
Summary: Should warn if creating a new Boolean instance
Status: VERIFIED WONTFIX
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.6   Edit
Hardware: All All
: P3 enhancement (vote)
Target Milestone: 3.6 M7   Edit
Assignee: Olivier Thomann CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-02-02 15:00 EST by Mattias CLA
Modified: 2010-04-27 06:56 EDT (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Mattias CLA 2010-02-02 15:00:39 EST
Build Identifier: 20090920-1017

Constructing a new instance of Boolean using 'new Boolean(boolean)' should generate a warning and 'Boolean.valueOf(boolean)' should be suggested. The warning should be disabled with a comment such as //$NEW-BOOLEAN$ or with an annotation such as @SuppressWarnings{"new-boolean"}.

Constructing new Booleans are almost always a bad idea; their values
can only be compared with .equals(Object) and not with ==.
Furthermore it takes more (not really that much) memory while they
can not be changed (all boxing classes are immutable).

Reproducible: Always
Comment 1 Olivier Thomann CLA 2010-02-02 15:11:25 EST
(In reply to comment #0)
> warning should be disabled with a comment such as //$NEW-BOOLEAN$ or with an
> annotation such as @SuppressWarnings{"new-boolean"}.
Using SuppressWarnings is possible, not the other one. I don't think this would deserve such a special comment.
 
> Constructing new Booleans are almost always a bad idea; their values
When this would be a good idea?

I don't believe this very special case deserves a specific warning.
Markus, what do you think ?
Comment 2 Markus Keller CLA 2010-02-03 09:25:00 EST
I also wouldn't add a warning for that special case.

new Boolean(..) is just one instance of the general "use the factory instead of calling the constructor" family of problems. These problems are not general problems that often occur in the Java language, but problems that depend on specific libraries. These kinds of problems don't fit well into our current "Potential programming problems" category.

They'd better be implemented in a third=party plug-in for now.
Comment 3 Olivier Thomann CLA 2010-03-18 13:23:08 EDT
Closing as WONTFIX.
It is easy using a search request to find all usage of this constructor. It doesn't deserve a specific treatment from the compiler.
Comment 4 Jay Arthanareeswaran CLA 2010-04-27 06:56:22 EDT
Verified for 3.6M7.