This week's book giveaway is in the OO, Patterns, UML and Refactoring forum.
We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line!
See this thread for details.
The moose likes Programmer Certification (SCJP/OCPJP) and the fly likes Which is better? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login

JavaRanch » Java Forums » Certification » Programmer Certification (SCJP/OCPJP)
Bookmark "Which is better?" Watch "Which is better?" New topic

Which is better?

Sunny Jain
Ranch Hand

Joined: Jul 23, 2007
Posts: 433

I have two option to create a String which looks somethig like this, Can any one help me to know which is better ;

I know in the first case,
Number of immutable Object : 7
Number of mutable Object : 0

In second Case :
Number of Immutable Object : 5
Number of mutable Object : 1

So Over all i saved 2 immutable Object. If I have to create similar String 20 times in a program, I will save 20 Objects.
My query is that which one i should prefer to use while coding?

first one is easy to understand and use. Second one is more spacious and not easy to understand ?
Which one is generally prefer and why ?

Thanks and Regards,
SCJP 1.5 (90%), SCWCD 1.5 (85%), The Jovial Java, java.util.concurrent tutorial
Jesper de Jong
Java Cowboy
Saloon Keeper

Joined: Aug 16, 2005
Posts: 14950

If we take a look at your specific example, then the first is better, because the compiler is smart enough to concatenate the strings "javaRanch" + " is" + " good" + " site" at compile time. So, writing:

String str = "javaRanch" + " is" + " good" + " site";

is, at runtime, exactly the same as writing:

String str = "javaRanch is good site";

Note however, that if you use the + operator to concatenate strings that are not compile-time constants, the compiler will convert this automatically to code that uses StringBuffer (or StringBuilder). That can be less efficient than using StringBuilder yourself. Have a look at the following example:

The compiler will automatically convert this to something like this:

This is quite inefficient code: in every iteration of the loop, a new StringBuilder object is created, the contents of 'result' is copied into it, then a value is concatenated to it, and then the content of the StringBuilder is copied into a new String object again which is assigned to 'result'. So, there are a lot of temporary objects and a lot of copying of data going on.

Suppose you wrote it yourself like this:

That is a lot more efficient - there is only one StringBuilder object, and no unnecessary copying.
[ May 15, 2008: Message edited by: Jesper Young ]

Java Beginners FAQ - JavaRanch SCJP FAQ - The Java Tutorial - Java SE 8 API documentation
Sunny Jain
Ranch Hand

Joined: Jul 23, 2007
Posts: 433

Jasper, I have one more query :
what if i have following :

String str = "javaRanch" + " is" + " a" + status + " site";

where status is a variable whose value can change at run time ?
At this situation what is the best way ?
Bhavik patel
Ranch Hand

Joined: Feb 20, 2007
Posts: 49
Hi sunny...

well..This will help you...

Appending strings

Bhavik Patel
Glassfish Consultancy service At
Jesper de Jong
Java Cowboy
Saloon Keeper

Joined: Aug 16, 2005
Posts: 14950

Originally posted by Sunny Jain:
Jasper, I have one more query :

Try thinking about it yourself.

Note the following: If you have compile-time constants (values of which the value is fixed at compile time), the compiler will do the work beforehand. If not, then the compiler will convert the code to something with StringBuilder.

Look at your code, and think about what the compiler would do with it.

Note that problems with inefficiency especially happen when you use + on strings inside a loop - it's not such a problem when it's not in a loop.
I’ve looked at a lot of different solutions, and in my humble opinion Aspose is the way to go. Here’s the link:
subject: Which is better?
It's not a secret anymore!