While we're starting to get off topic, the choice of StringBuffer or StringBuilder would be decided by their usage. I tend to keep String building local to a method and not share the builder, so I tend to use StringBuilder over StringBuffer, but it would be wrong to use one or the other without considering why.
David O'Meara wrote: I tend to keep String building local to a method and not share the builder, so I tend to use StringBuilder over StringBuffer, but it would be wrong to use one or the other without considering why.
As of release JDK 5, this class has been supplemented with an equivalent class designed for use by a single thread, StringBuilder. The StringBuilder class should generally be used in preference to this one, as it supports all of the same operations but it is faster, as it performs no synchronization.
In practice, you almost never use the same StringBuffer object from multiple threads at the same time. Synchronization adds overhead, and most of the time it's not necessary. So you'd better use StringBuilder, unless you have a very specific reason to use StringBuffer.
pete stein wrote:
I believe that it is possible through reflection, but not good practice for you break String's contract and risk a whole host of bugs.
It's actually an interesting solution, but it may not work with all JVMs (or if certain products are used). Some third party JVMs have there own implementation of String -- and it's implemented differently. And the private fields that is being changed, may be different, or may not even exist.
I ran into this issue a few years ago, when mixing two products, with a non-Sun JVM. Ran into a whole bunch of errors related to the String class.
Are the private fields of String part of this documentation? I think not. And that's why Sun is allowed to change them completely, as long as the public and protected members do not change. Anything not documented (i.e. not in the API) should be considered as a black box and no assumptions should be made about them. That includes Sun's classes for internal use, in packages starting with sun, com.sun etc.
But I wouldn't do it that way. I'd either simply return the explanation, with null indicating no problem; or if I wasn't feeling like using one thing (the return value) for two purposes (good/bad result + message), I might return void, and throw an exception if it failed (a common pattern in validating required conditions); or I'd do this:
Regardless, I am of the opinion that Mutable object is generally icky and leaves me wanting a shower.
Ankit Sanghavi wrote:thank you for welcoming me, I have read all post... but not got the answer...!!!
The correct answer is there if you look for it. Fred Rosenberger said it the best. I could say it a different way but you wouldn't want that. (<-- closest thing to "The Hulk" that we have around here)
Who the heck comes up with interview questions like this anyway? IMO, questions like this and this are very poor ways of finding good people to hire. It's like interviewing drivers who will eventually drive your kids around and you asking them "Are you able to get a car to go up to 115 mph, then do a 360-degree spinout?" Do you really want to hire the guy who says "Yes" to this? I think they should fire the interviewer.
I think your interviewer had not worked on java since a long time and did not have real questions to ask.
My personal opinion after a considerable interview experience( on both ends of the table ) - This is a typical question "Not so good developers" ask others in interviews.
Anrd
"One of the best things you could do is to simplify a larger application into a smaller one by reducing its process and complexity - Fowler"
0
I guess with reflection and bytecode manipulation, it's possible to do pretty much everything :p
(<-- closest thing to "The Hulk" that we have around here)
