2

Along the lines of an existing thread, The “Why” behind PMD's rules, I'm trying to figure out the meaning of one particular PMD rule : String and StringBuffer Rules.StringInstantiation.

This rule states that you shouldn't explicitly instantiate String objects. As per their manual page :

Avoid instantiating String objects; this is usually unnecessary since they are immutable and can be safely shared.

This rule is defined by the following Java class:net.sourceforge.pmd.lang.java.rule.strings.StringInstantiationRule

Example(s):

private String bar = new String("bar"); // just do a String bar = "bar";

http://pmd.sourceforge.net/pmd-5.0.1/rules/java/strings.html

I don't see how this syntax is a problem, other than it being pointless. Does it affect overwhole performance ?

Thanks for any thought.

Community
  • 1
  • 1
O_o
  • 23
  • 3
  • Thanks all for your answers. So basically 1) it is slower and 2) it makes the code harder to read (except a few instances where it is done on purpose) – O_o Jan 02 '13 at 15:55

6 Answers6

3

With String foo = "foo" there will be on instance of "foo" in PermGen space (This is referred to as string interning). If you were to later type String bar = "foo" there would still only be one "foo" in the PermGen space.

Writing String foo = new String( "foo" ) will also create a String object to count against the heap.

Thus, the rule is there to prevent wasting memory.

Cheers,

Anders R. Bystrup
  • 15,729
  • 10
  • 59
  • 55
3

It shouldn't usually affect performance in any measurable way, but:

private String bar = new String("bar"); // just do a String bar = "bar";

If you execute this line a million times you will have created a million objects

private String bar = "bar"; // just do a String bar = "bar";

If you execute this line a million times you will have created one Object.

There are scenarios where that actually makes a difference.

Sean Patrick Floyd
  • 292,901
  • 67
  • 465
  • 588
3

Does it affect overwhole performance ?

Well, performance and maintenance. Doing something which is pointless makes the reader wonder why the code is there in the first place. When that pointless operation also involves creating new objects (two in this case - a new char[] and a new String) that's another reason to avoid it...

In the past, there has been a reason to call new String(existingString) if the existing string was originally obtained as a small substring of a longer string - or other ways of obtaining a string backed by a large character array. I believe that this is not the case with more recent implementations of Java, but obviously you can still be using an old one. This shouldn't be a problem for constant strings anyway, mind you.

(You could argue that creating a new object allows you to synchronize on it. I would avoiding synchronizing on strings to start with though.)

Jon Skeet
  • 1,421,763
  • 867
  • 9,128
  • 9,194
  • No, in my case, the purpose of this syntax is not due to the soft running against an older implementation of Java. Thanks for the details. – O_o Jan 02 '13 at 15:59
2

One difference is the memory footprint:

String a = "abc"; //one object
String b = "abc"; //same object (i.e. a == b) => still one object in memory
String c = new String("abc"); // This is a new object - now 2 objects in memory

To be honest, the only reason I can think of, why one would use the String constructor is in combination with substring, which is a view on the original string. Using the String constructor in that case helps getting rid of the original string if it is not needed any longer.

However, since java 7u6, this is not the case any more so I don't see any reasons to use it any more.

assylias
  • 321,522
  • 82
  • 660
  • 783
2

It can be useful, because it creates a new identity, and sometimes object identities are important/crucial to an application. For example, it can be used as an internal sentinel value. There are other valid use cases too, e.g. to avoid constant expression.

If a beginner writes such code, it's very likely a mistake. But that is a very short learning period. It is highly unlikely that any moderately experienced Java programmer would write that by mistake; it must be for a specific purpose. File it under "it looks like a stupid mistake, but it takes efforts to make, so it's probably intended".

irreputable
  • 44,725
  • 9
  • 65
  • 93
1

It is

  • pointless
  • confusing
  • slightly slower

You should try to write the simplest, clearest code you can. Adding pointless code is bad all round.

Peter Lawrey
  • 525,659
  • 79
  • 751
  • 1,130