File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Java in General and the fly likes Never never never use a String in Java Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Java in General
Bookmark "Never never never use a String in Java" Watch "Never never never use a String in Java" New topic
Author

Never never never use a String in Java

Paul Mrozik
Ranch Hand

Joined: Feb 10, 2013
Posts: 117

This goes out to all the experienced developers out there with a good grasp of OOP. I found the following article http://codemonkeyism.com/never-never-never-use-string-in-java-or-at-least-less-often/ and I must say the author has a very valid point.

I'm currently working on a personal project and I have Strings and ArrayList<String(s)> galore. Now it made me completely rethink my design, but what does it all look like in the real world?





Junilu Lacar
Bartender

Joined: Feb 26, 2001
Posts: 4999
    
    8

Interesting article, thanks for the link.

I don't know about the practicality of the approach though. Seems like it could get tedious to define types for potentially hundreds of different attributes. I immediately start thinking of base classes for StringWrapper, IntegerWrapper (redundant?), etc. Then you'll get into having to decide on overriding equals() and hashCode(), delegating built-in String methods like substr, split, contains, etc. and other things you tend to take for granted when you deal with native/standard types. I don't know if it's going to be more trouble than it's worth. The other thing too is that it's not a very common approach and you'd have to explain it to the rest of your team and leave documentation for others coming in after you to explain the design choices. Without that documentation, "WTF?!" can certainly be an understandable reaction from anyone who sees the code for the first time.

Give it a try and let us know how it works out for you.


Junilu - [How to Ask Questions] [How to Answer Questions]
Paul Clapham
Bartender

Joined: Oct 14, 2005
Posts: 18887
    
    8

It seemed like an interesting idea to me, but then it occurred to me that if you were using an ORM like Hibernate to persist your data, it would complicate your setup quite a bit.
Ivan Jozsef Balazs
Rancher

Joined: May 22, 2012
Posts: 875
    
    5
It reminds me the issue with Hungarian notation. Given two data types which are technically equivalent, might be different in their usage. A String if identifies a person is of different use from a String identifying, say, a flight and it is not good to intermix them. Whether this issue should be addressed by using different types, a naming convention or meticulous care to the parameter names, depends on the very situation.

Never say "never ever" ;-)
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 39799
    
  28
I thought it was “never say never again”. This sounds similar to what we have inone of our FAQ, which quotes Joshua Bloch’s Effective Java™ page 224.
Paul Mrozik
Ranch Hand

Joined: Feb 10, 2013
Posts: 117

Junilu Lacar wrote:Without that documentation, "WTF?!" can certainly be an understandable reaction from anyone who sees the code for the first time.

Give it a try and let us know how it works out for you.


And the WTF is what I was afraid of. I suppose a logical balance would make sense, but then there will always be people who will question my logic. :-)
Paul Mrozik
Ranch Hand

Joined: Feb 10, 2013
Posts: 117

Campbell Ritchie wrote:I thought it was “never say never again”. This sounds similar to what we have inone of our FAQ, which quotes Joshua Bloch’s Effective Java™ page 224.


Similar indeed. Stephan Schmidt seems to be religious about it though, saying "Never, never, never use (unwrapped) String or long or int. Why? Those primitive types have no semantic meaning."



Junilu Lacar
Bartender

Joined: Feb 26, 2001
Posts: 4999
    
    8

Paul Mrozik wrote:Those primitive types have no semantic meaning."

I think I'll stick with using well-chosen names and well-placed responsibilities to provide the necessary semantics. Life is too short to be fighting the language on the level of primitive types.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Never never never use a String in Java