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 Why String Constructor exists in the API Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Java in General
Bookmark "Why String Constructor exists in the API" Watch "Why String Constructor exists in the API" New topic
Author

Why String Constructor exists in the API

sandeeprajsingh tandon
Ranch Hand

Joined: Mar 06, 2009
Posts: 71
It seems from all the discussion on the topic, that String s = new String("mystring") is not wanted. Then why dont they remove the constructor from the API?
Jesper de Jong
Java Cowboy
Saloon Keeper

Joined: Aug 16, 2005
Posts: 14338
    
  22

They don't remove it from the API because that might break existing programs in which this constructor is used. Sun is always very careful with backward compatibility when a new version of Java comes out. Sometimes methods or classes are deprecated, but they are never actually removed from the API.

But indeed, the constructor of class String that takes a String is quite useless and unnecessary, because class String is immutable. You (almost?) never need to copy a String object. (Can anybody think of a use case where you'd really need this?).


Java Beginners FAQ - JavaRanch SCJP FAQ - The Java Tutorial - Java SE 8 API documentation
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 39784
    
  28
I believe it is because String is a sort of "library" class. Unlike the sort of classes we write, where we only add methods they are needed, library classes have lots of public methods (and constructors) just in case anybody ever uses them. If anybody ever thought, "Having a copy constructor in String might be useful," that is all it takes to make them write a copy constructor. Even though it is not useful, as Jesper said, it would potentially cause problems to remove that constructor.
pankaj vijay
Ranch Hand

Joined: Apr 01, 2008
Posts: 75
String constructor have its own purpose. when you declare

now both reference s1& s2 are denoting same object Because String pool does not create duplicate object unless declare.
But if you declare like this

In this case s1 & s2 both are denoting different objects. because new create a brand new object in String pool.if you want to create a bracnd new object in String pool you have to use String constructor. For E.g
s1==s2 will return true While
s3==s4 will return false.
the reason is s1 & s2 both are denoting same object while s3 & s4 are denoting different objects.


Pankaj Vijay (SCJP, SCBCD)
Learn Core Java,Learn Servlet Jsp, SCJP Questions,Struts Tutorial
Brij Garg
Ranch Hand

Joined: Apr 29, 2008
Posts: 234

But if you declare like this

String s3= "JAVA";
String s4= new String("JAVA");

In this case s1 & s2 both are denoting different objects. because new create a brand new object in String pool.if you want to create a bracnd new object in String pool you have to use String constructor. For E.g
s1==s2 will return true While
s3==s4 will return false.
the reason is s1 & s2 both are denoting same object while s3 & s4 are denoting different objects


String str = new String("Test");
this will create two objects.

and

will create one object.

Agree with you whatever you have written but my point is why to use new when we have other option.
Mike Simmons
Ranch Hand

Joined: Mar 05, 2008
Posts: 3018
    
  10
pankaj vijay: that's an effect of the constructor, yes. But is it really a purpose? Why would anyone need this? It only seems to create confusion. What's the use of having two identical instances rather than one? I would argue that if that was the purpose intended by Sun for this constructor, it was a bad idea.

Jesper Young wrote:They don't remove it from the API because that might break existing programs in which this constructor is used. Sun is always very careful with backward compatibility when a new version of Java comes out. Sometimes methods or classes are deprecated, but they are never actually removed from the API.

Mmmm, but they can and do deprecate things that are a bad idea. Sometimes, at least. They deprecated several other String constructors. But not this one.

It turns out, there is a more useful function that this constructor can have. It's rare that it's actually useful, but sometimes, it is.

Imagine you have a very large file with many records, one per line. Each line begins with a 10-character id code, followed by many other things you don't care about. You just want to get a List of all the IDs. How to do this?

Now assume that the file is very long, and each line is pretty long as well. The code above ends up using a lot more memory than it needs to.

It looks like each time we read a line, we only save the first 10 characters as id, which is put in the list - and then the line should become eligible for GC, right? Except that it turns out that when we create a String using substring(), the new String uses the same array of char[], internally, that was used by the original String. It only pays attention to the first 10 elements of that array, in this case (because we asked for a substring() of 10 characters). But it still keeps a reference to the entire array. Thus, because we save a reference to a String of 10 characters, we also prevent the garbage collection of a char[] array with many more than 10 characters. And we do this each time we read a line from the file. If the file is long, we could be using a lot more memory than we can afford to.

Why does substring() behave this way? Well, in many cases this is much faster and more efficient than creating a new String with a correctly-sized char[] array, with contents copied from the original. Instead, substring() doesn't copy any data - it just creates a small String object with a view into the larger, already-existing array. Most of the time, this is fine, and even a good thing. But occasionally, as in the code above, it can be a problem.

So, how do we fix it? That's where the String(String) constructor comes in:

The new String() constructor explicitly creates a new String with the same content - but with a correctly-sized char[] array, 10 characters in this case. And after this iteration completes, the original long String with its long char[] array is available for GC, since we haven't saved a reference to it.

This, then, is the only useful purpose I'm aware of for the String(String) constructor. The copy can have a more memory-efficient internal representation than the original did. I suspect many programmers can go their whole careers without having a real need for this. But it's there in the String API, nonetheless.
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 39784
    
  28
Yes, that is a real use for the copy constructor. Somebody else said you could use new String("lock") for objects, and use those identical Strings as locks.
Paul Clapham
Bartender

Joined: Oct 14, 2005
Posts: 18882
    
    8

Campbell Ritchie wrote:Somebody else said you could use new String("lock") for objects, and use those identical Strings as locks.

Although you could equally well use new Object() for those same locks, avoiding confusion about what the constructor is for.
sandeeprajsingh tandon
Ranch Hand

Joined: Mar 06, 2009
Posts: 71
Thanks Mike especially for this answer. It could not have been more enlightening

Thanks others for insight too.

What String(locks) are you talking about Campbell. Can you point me somewhere?
Jesper de Jong
Java Cowboy
Saloon Keeper

Joined: Aug 16, 2005
Posts: 14338
    
  22

Interesting use case, Mike. But you really have to know about the inner workings of class String to understand this!
Pat Farrell
Rancher

Joined: Aug 11, 2007
Posts: 4659
    
    5

Jesper Young wrote:Interesting use case


Interesting and it does come up occasionally.

Jesper Young wrote: Sometimes methods or classes are deprecated, but they are never actually removed from the API.

While Mike's example shows a valuable use for the copy constructor, I think in general, The Java Fathers should deprecate more and remove more. Java is showing its age.
Jesper de Jong
Java Cowboy
Saloon Keeper

Joined: Aug 16, 2005
Posts: 14338
    
  22

Pat Farrell wrote:I think in general, The Java Fathers should deprecate more and remove more. Java is showing its age.

One of the most important things that people are working on for Java 7 is the modularization of Java - this would make it possible to move less used parts of the JDK, such as MIDI support and CORBA support, into a separate, optional module. I don't think they will really remove deprecated methods, classes and interfaces anytime soon, because backward compatibility is still treated as something holy. Java is showing its age, and that's one of the reasons why alternative languages on the JVM (Scala, Groovy, JRuby, Clojure, ...) are so popular.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Why String Constructor exists in the API