Both Java and C# support the use of assignment operators to create new instances of string objects from literals and other string instances, as illustrated in this fragment of C# code:

String someString = "This is a string.";
String someOtherString = someString;

Notice that the .NET String class doesn’t provide constructor equivalents of these assignment statements.

The only other difference of note is the support .NET provides for creating a string given a pointer to a char or byte array. Because they use pointers, these constructors are unsafe. See the Unsafe Code section in Chapter 6, for details on unsafe code.

Table 7-1 summarizes the Java and .NET string constructors.

Java does not provide support for comparing strings using operators. The == or != operator in Java will compare object references and not the contents of the string. In C# support for operator overloading, the == and != operators have been implemented to support the comparison of string content. Both operators are backed by the String.Equals method. The following C# statements demonstrate the use of the overloaded == operator to compare a string variable with a string literal:

if (someString == "This is a string.") {
    // some statements
}

Java and .NET both provide methods for comparing whole or partial strings. These are summarized in Table 7-2.

Java and C# both provide operator support for copying strings. The = operator is used to assign a string literal or variable to another string variable; .NET also provides the static String.Copy method, which can be used to copy strings. For example, the following two C# statements have the same effect:

string SomeString = "Some string value.";
string SomeOtherString = string.Copy("Some string value.");

The length of a Java String is obtained by calling the String.length method; .NET provides the read-only property String.Length.

Like Java, C# provides both operator and method support for concatenating strings. The support in C# is the same as in Java and allows the use of both the + and += operators. Method-based concatenation support in .NET is more extensive than that provided in Java. Java provides the String.concat method, which is equivalent to the operator syntax described earlier. .NET provides a set of static, overloaded String.Concat methods that concatenate a variable number of strings and string representations of objects into a single string.

The static String.Join methods provide a mechanism to concatenate an array of strings into a single string separating each component with a configurable string token. This is useful for creating strings that represent hierarchical information such as IP addresses, URLs, or file names. For example:

string[] names = {"www", "microsoft", "com"};
string nameString = System.String.Join(".", names);

The value of nameString will be www.microsoft.com.

Both Java and .NET provide capabilities to convert the case of a string. The equivalent methods are shown in Table 7-3.

Both Java and .NET provide mechanisms to retrieve, remove, and replace the individual characters contained within a string. .NET provides a superset of the Java functionality and provides two particularly useful features:

Because strings are immutable, these methods do not modify the string instance, instead returning a new string containing any modifications. If performing many edit operations, it’s more efficient to use the StringBuilder class, discussed later in this chapter. When performing complex or repeated matching operations, regular expressions (discussed later in this chapter) provide a more flexible solution. The methods for character access are summarized in Table 7-4.

Java and .NET both provide mechanisms for locating and modifying substrings within an existing string. As with the character access just discussed, the use of StringBuilder or regular expressions can provide a more efficient alternative. The substring manipulation methods are summarized in Table 7-5.

Both the Java and .NET String classes provide methods to split a string based on the occurrence of tokens within a string. The Java String.split method exposes regular expression functionality, discussed later in this chapter. Java also provides the java.util.StringTokenizer as a flexible mechanism to split strings without using regular expressions; .NET has no direct equivalent.

The .NET String.Split method splits a string into component parts based on the location of a definable set of characters, returning an array of components from the source string.

It’s common to use strings as keys in collections such as dictionaries. The GetHashCode and Equals methods inherited from System.Object are the basis for key comparison. The String class has overridden these two methods to provide appropriate behavior for key comparison. The GetHashCode method returns a hash code based on the entire contents of the string, not the object reference. The Equals method is discussed earlier in this chapter.

Parsing is the process used to create date and numeric data types from strings, for example, creating an int from the string 600. The .NET Framework provides a parsing mechanism that is similar to the Java static parseXXX methods in the primitive wrapper classes. Because all .NET value types are objects, there is no need for wrapper classes. In .NET, all of the simple data types (Byte, Int32, Double, and so forth) have static methods named Parse that take a String and return an instance of the appropriate value type. An exception will be thrown if

System.DateTime, System.TimeSpace, and System.Enumeration classes also implement Parse methods for parsing strings.

.NET also defines the System.Convert class, which provides an impressive selection of static methods for converting between data types; however, all the methods that convert strings simply call the Parse method of the target type.

.NET provides functionality for creating strings that contain formatted representations of other data types. This includes the use of formatting conventions for different regions, cultures, and languages. Java provides similar capabilities through the java.text.MessageFormat class, among others; however, the implementations are sufficiently different that it is easier, and more instructive, just to discuss the .NET implementation on its own.

Formatting functionality is exposed through overloaded methods in a number of classes in which string output is generated. The most commonly used methods are

Most of these classes provide overloaded methods that take different numbers of parameters. For our discussion, we’ll consider the most general case of the System.Console.WriteLine method, which takes a variable number of arguments through the use of a params parameter. The signature is as follows:

public static void WriteLine(string format, params object[] args);

The format parameter is a string that contains both the standard text to output and embedded format specifiers at locations where formatted data will be inserted.

The args array contains the objects to be formatted and inserted into the resulting string. The method will accept a variable number of arguments through the use of the params keyword. The order of these arguments determines the index they occupy in the object array. The array index of each object is used in the format string to identify where each formatted object should be inserted. The best way to convey how this works is by example. This code

double a = 345678.5678;
uint b = 12000;
byte c = 254;
Console.WriteLine("a = {0}, b = {1}, and c = {2}", a, b, c);
Console.WriteLine("a = {0:c0}, b = {1:n4}, and c = {2,10:x5}",
    a, b, c);

will result in the following output:

a = 345678.5678, b = 12000, and c = 254
a = £345,679, b = 12,000.0000, and c =      000fe

The codes in the braces, highlighted in the example, are called format specifications. Changing the contents of the format specification changes the format of the output. The current cultural and regional settings can affect the formatted output. As in the example, the currency symbol, thousands separator, and decimal separator are all affected by localization settings.

Format specifications have the general form

{N,[M][:F]}

where:

Any object can be passed as a parameter for formatting, although only types that implement the IFormattable interface support format strings. Any type that doesn’t implement IFormattable will always be rendered to a string using the inherited Object.ToString method, irrespective of any format strings provided. Attempts to use invalid format strings on IFormattable objects will cause a FormatException exception to be thrown.

All of the simple types, as well as System.DateTime, System.TimeSpan, and System.Enum, implement IFormattable. We’ll discuss some of the more common format strings in Chapter 8, but the .NET documentation provides complete coverage.

string ToString(string format, IFormatProvider formatProvider);

using System;
using System.Text;

public class MyNumber : IFormattable {
    private int val;

    public MyNumber(int v) { val = v; }

    public string ToString(string format, IFormatProvider provider) {
        if (format != null && format.ToLower() == "w") {
            switch (val) {
                case 1 : return "one";
                case 2 : return "two";
                case 3 : return "three";
                default: return "unknown";
            }
        } else {
            return val.ToString();
        }
    }

    public static void Main() {

        MyNumber numberOne = new MyNumber(3);
        MyNumber numberTwo = new MyNumber(1);

        Console.WriteLine("The first number is {0} and the second is {1}",
            numberOne,  numberTwo);
        Console.WriteLine("The first number is {0:w} and the second is " +
            "{1:w}", numberOne,  numberTwo);
    }
}

The first number is 3 and the second is 1
The first number is three and the second is one

Java and .NET both support Unicode and encode characters internally using the UTF-16 scheme. However, Unicode is not the only character-encoding scheme, nor is UTF-16 the only scheme for encoding Unicode. Support for different character encodings is essential for providing cross-platform support and integration with legacy systems.

Java has provided support for character encoding since version 1.1; however, these capabilities were accessible only through other classes such as java.lang.String and java.io.InputStreamReader. The model introduced in Java version 1.4 offers greater flexibility, providing direct access to the underlying encoding mechanisms. The character encoding functionality in Java version 1.4 and .NET is predominantly the same. The most significant difference is how encoding classes are instantiated.

The java.nio.charset.Charset class represents a mapping between 16-bit Unicode characters and encoded bytes. The static factory method Charset.forName(String charsetName) returns a Charset instance for a specific encoding scheme based on a name. The following example demonstrates instantiation of a Charset for performing UTF-8 encoding:

Charset x = Charset.forName("UTF-8");

The .NET equivalent of the Charset class is the abstract class System.Text.Encoding. The Encoding class provides base functionality and factory methods for a number of encoding-specific classes contained in the System.Text namespace. Concrete implementations are provided for UTF-7, UTF-8, Big-Endian and Little-Endian UTF-16, and ASCII. The .NET Framework relies on the underlying operating system to provide support for other encoding schemes, adopting the Java model of returning an Encoding instance based on a scheme name to expose this functionality.

Table 7-6 maps commonly used Java scheme names against their .NET equivalents. The table also shows how to instantiate an Encoding object using the static methods and properties of Encoding. The concrete Encoding subclasses also offer instantiation via constructors.

ASCIIEncoding, UTF8Encoding, and UnicodeEncoding derive from Encoding but do not introduce any new functionality. Table 7-7 provides a summary of the Encoding functionality.

Both the Charset and Encoding classes provide convenience methods for performing single-call transformations and provide factory methods to create stateful encoding and decoding objects for processing longer char and byte arrays. These methods are contrasted in Table 7-8.

The .NET Encoder and Decoder classes are simpler than their Java counterparts and are summarized in Table 7-9 and Table 7-10.

The following code demonstrates the use of the encoding and decoding functionality we’ve discussed in this section:

 // Instantiating an Encoding that supports UTF-8
Encoding myEncoding = Encoding.UTF8;

//Instantiating a UTF-8 Encoder
Encoder myEncoder = myEncoding.GetEncoder();

//Determine the byte array size required to encode a String
char[] myChars = "Hello world !".ToCharArray();
int size = myEncoder.GetByteCount(myChars, 0, 13, true);

//Convert the character array to a UTF-8 byte array
byte[] myBytes = new byte[size];
myEncoder.GetBytes(myChars, 0, 13, myBytes, 0, true);

// Encode the byte stream as UTF-7 using Encoding.Convert()
myBytes = Encoding.Convert(Encoding.UTF8, Encoding.UTF7, myBytes);

// Convert the bytes back to Unicode from UTF-7
String myString = new String(Encoding.UTF7.GetChars(myBytes));

//Display result string
System.Console.WriteLine(myString);

Like Java, .NET also provides access to encoding mechanisms through other relevant classes. The String class provides a constructor that takes an Encoding to create a Unicode string from an encoded byte array. Also, the StreamReader and StreamWriter classes in the System.IO namespace provide constructors that allow an Encoding to be specified, forcing all strings written and read through the stream to be encoded and decoded using the specified scheme.

The immutability of strings means that manipulation and concatenation result in new string instances being created instead of the contents of existing strings being modified. The overhead of creating many new string instances can dramatically affect the performance of an application. Java and .NET both provide similar solutions to this problem. Java provides the java.lang.StringBuffer class, and .NET provides the System.Text.StringBuilder class. Both classes represent a sequence of Unicode characters that can be modified in situ, extended if necessary, and rendered to a string as required.

The .NET StringBuilder class provides better functionality for formatting and manipulating contents of the character data but lacks some of the StringBuffer capability of inspecting the contents of, and extracting substrings from, the underlying character sequence. Table 7-11 compares the functionality of the StringBuffer and StringBuilder classes.