• Post Reply Bookmark Topic Watch Topic
  • New Topic

Why still we are using "String" ?  RSS feed

 
Sanket Akre
Greenhorn
Posts: 15
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi All,
Now we have advance version of String i.e. StringBuffer and StringBuilder,
Why still we are using "String" ?
Can anyone tell me why?
 
Bear Bibeault
Author and ninkuma
Marshal
Posts: 66306
152
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
StringBuilder and StringBuffer are not "advanced" versions of String. They are utility classes used to build strings dynamically. They should not be used in place of String when the string value does not need to be built or changed internally at run-time.
 
Bear Bibeault
Author and ninkuma
Marshal
Posts: 66306
152
IntelliJ IDE Java jQuery Mac Mac OS X
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Exercise: write code that builds a StringBuffer containing your name without using instances of String or string literals.
 
Greg Charles
Sheriff
Posts: 3015
12
Firefox Browser IntelliJ IDE Java Mac Ruby
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
On a similar note, why are we still using StringBuffer when we have StringBuilder? StringBuilder is faster because it's not synchronized, and I've never seen a use of StringBuffer that actually needed the synchronization it provides. I've lived a pretty sheltered life though.
 
Jesper de Jong
Java Cowboy
Sheriff
Posts: 16060
88
Android IntelliJ IDE Java Scala Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Greg: StringBuffer has been superseded by StringBuilder since Java 5, exactly because of the reason you mentioned: StringBuffer had unnecessary synchronization.

Since Oracle (and before them, Sun) always has to be very careful about backward compatibility, they couldn't just take the synchronization out of StringBuffer - that would break programs that depend on it (even though almost nobody needs and uses it). They even didn't deprecate StringBuffer, probably because they were afraid to annoy too many people who were using StringBuffer.

In new code, always use StringBuilder instead of StringBuffer.
 
Jelle Klap
Bartender
Posts: 1952
7
Eclipse IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I most frequently just use String concatenation instead of StringBuilder. The code is more readable in my opinion and the compiler optimizes to use StringBuilder under the hood anyway, in most cases, not all. On recent (>=6U23) server JVM implementations escape analysis should be supported and performed by default, so lock elision should eliminate StringBuffer's synchronization overhead where applicable. Might be useful to know if you're stuck with legacy code that uses StringBuffer all over the place, no need to go maniacally replacing it with StringBuilder.
 
Tony Docherty
Bartender
Posts: 3271
82
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I most frequently just use String concatenation instead of StringBuilder.

It really depends on the size of the String and number of concatenations you are performing but if you are doing many concatenations on very large strings explicitly using a StringBuilder can dramatically improve performance. I've tested many compilers new and old and all the ones I've tested, for string concatenation in a loop, create a new StringBuilder and String Object for each iteration of the loop.
 
Jelle Klap
Bartender
Posts: 1952
7
Eclipse IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes it does indeed depend on the situation, which may not always be appearant. So then it might be preferable to just always use StringBuilder, especially when working in a team, for the sake of consistency. I woudn't though, as in a lot of cases that would mean sacrificing readability. Also, who knows, maybe String concatenation will be subject to further optimization in the future like with the StringBuilder replacement by the current compiler. I guess the ever annoying "it depends" applies here as well.
 
Winston Gutkowski
Bartender
Posts: 10575
66
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Sanket Akre wrote:Why still we are using "String" ?

Quite apart from everything that Bear said: Strings are Thread-safe. Therefore, you can happily share them around any multi-tasking app you've written and KNOW that you'll never have any problems. Try that with StringBuilder or (in some situations) StringBuffer.

Winston
 
Tony Docherty
Bartender
Posts: 3271
82
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Jelle Klap wrote:Yes it does indeed depend on the situation, which may not always be appearant...

I would imagine most String concatenations in loops aren't long enough strings or a high enough number of iterations to have any noticeable effect on performance and the remaining few cases would be easily picked up by a profiler.

Jelle Klap wrote: I woudn't though, as in a lot of cases that would mean sacrificing readability

Personally I don't find using StringBuilder less readable than String concatenation so I always use StringBuilder when concatenating in a loop but if you do find it less readable then I agree in most cases it's not worth doing. And like you said when working in a team it's important to take a consistent approach.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!