public static String valueOf(char[] data) Returns the string representation of the char array argument. The contents of the character array are copied; subsequent modification of the character array does not affect the newly created string. Parameters: data - a char array. Returns: a newly allocated string representing the same sequence of characters contained in the character array argument
public static String copyValueOf(char[] data) Returns a String that is equivalent to the specified character array. It creates a new array and copies the characters into it. Parameters: data - the character array. Returns: a String that contains the characters of the character array.
Looking at the API and source code there doesn't seem to be any difference in functionality. Is someone saying there is a noticable difference? How about adding a comment to the copied API or source code you post here, it's hard to tell what your trying to say or point out.
Ernest Friedman-Hill
,
author and iconoclast
staff
Marilyn got me thinking. I rooted around for the oldest JDK source code I have -- JDK 1.0 beta for sparc -- and in String.java, you find this (emphasis mine
But the comments lie, actually. The array ends up being copied in both cases, although copyValueOf() does it explicitly and then calls "new String()", and valueOf calls "new String()" directly. The String constructor also copies the array, so this old version of copyValueOf results in the char[] being copied twice, for no reason.
The very strong implication is that, sometime in the history of Java Strings, before the 1.0 release, Strings weren't immutable, and they had constructors and a factory method which let you create instances that used a specific char[] to hold their contents! By the 1.0 release, that capability had been removed, but these two methods both remained -- even though copyValueOf() was redundant and could easily have been removed.
Chalk it up to... a mistake. [ June 07, 2005: Message edited by: Ernest Friedman-Hill ]
Ernest Friedman-Hill wrote:Marilyn got me thinking. I rooted around for the oldest JDK source code I have -- JDK 1.0 beta for sparc -- and in String.java, you find this (emphasis mine
But the comments lie, actually. The array ends up being copied in both cases, although copyValueOf() does it explicitly and then calls "new String()", and valueOf calls "new String()" directly. The String constructor also copies the array, so this old version of copyValueOf results in the char[] being copied twice, for no reason.
The very strong implication is that, sometime in the history of Java Strings, before the 1.0 release, Strings weren't immutable, and they had constructors and a factory method which let you create instances that used a specific char[] to hold their contents! By the 1.0 release, that capability had been removed, but these two methods both remained -- even though copyValueOf() was redundant and could easily have been removed.
Chalk it up to... a mistake.
[ June 07, 2005: Message edited by: Ernest Friedman-Hill ]
I think the coffee guys might want to differenciate them and wanted to implement these two methods in different ways, but then they forget about it and instead, they invented another methods named
From its Javadoc we read:
String java.lang.String.valueOf(char[] data, int offset, int count)
Returns the string representation of a specific subarray of the char array argument.
The offset argument is the index of the first character of the subarray. The count argument specifies the length of the subarray. The contents of the subarray are copied; subsequent modification of the character array does not affect the newly created string.
Parameters:
data the character array.
offset the initial offset into the value of the String.
count the length of the value of the String.
Returns:
a string representing the sequence of characters contained in the subarray of the character array argument.
Throws:
IndexOutOfBoundsException - if offset is negative, or count is negative, or offset+count is larger than data.length.
So that's the method you guessed. Now one of these two methods is obsolete. It's not for the backward compability, as I had guessed.
Let's look and see what the latest version of Java® uses, remembering that the previous posts are eleven years old. Because of backwards compatibility, the two methods are still in the String class: valueOf() and copyValueOf(). If you look through those two links, you will find that the distinction has been abolished. Both do the same thing. Obviously Ernest's β link shows code which created a potentially mutable form of a String instance with valueOf(), and that has since been changed. I don't know when it was changed.
Post by:autobot
You learn how to close your eyes and tell yourself "this just isn't really happening to me." Tiny ad:
a bit of art, as a gift, that will fit in a stocking