The Violin Strings Library

Frequently Asked Questions

1. Why is the library called "Violin Strings Library"?

   Well, since the word "string" in English means both the character strings used in programing languages and the strings of music instruments I thought it nice to name my library in this ambigous way. Of course this is entirely a matter of taste and you may find it just plain nonsense. As long as the library is of any use to you I don't care.

2. Is the Violin Strings Library compatible with JDK 1.0.2?

   No. It uses some functions from java.lang.String which were not available in JDK 1.0.2. I have tested it under JDK 1.1.8 and JDK 1.3.

3. Why did you use static methods of a Strings class instead of subclassing the original String class provided by Sun or writing your own new  MyString class?

   Firstly, the original String class cannot be subclassed because it's declared final. Writing a new MyString class would allow using the string methods in a more natural and more object-oriented way; that's true. However, Strings are used almost everywhere in a program, and each time you wanted to use one of the Violin Strings functions you would have to construct an object of the new MyString class, just to call one of its member functions and then throwing it away. Or you would have to use the new MyString class everywhere in your program, still having the necessity to convert between the new class and the original one. I think this would be too cumbersome for most users. With the static functions you can use them easily whereever you need them, without bothering about conversions or constructing new Objects. Of course this comes at the price of using the class name on each invocation of a function and having an additional argument to each of the functions. If you know a clean, easy way to solve this problem, please tell me.

4. There a some functions which have an exact equivalent in the java.lang.String class. Why did you replicate them?

   I wanted to have all string manipulation functions in the same place, without the user having to bother about how a certain function has to be called.

5. Why did you code that strange function for testing character equality? Why isn't it sufficient to test just the lowercase equivalents of the characters?

   The Java API documentation for java.langString#equalsIgnoreCase(String) says:

   Two characters are considered the same, ignoring case, if at least one of the following is true:

   • The two characters are the same (as compared by the == operator).
   • Applying the method Character.toUppercase to each character produces the same result.
   • Applying the method Character.toLowercase to each character produces the same result.

   And the source code for function java.langString#regionMatches(boolean, int, String, int, int) contains a comment about strange rules for case conversion in the Georgian alphabet, which is the ultimate reason for this cumbersome equality test.

Java and all Java-based marks are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries. Michael Schmeling is independent of Sun Microsystems, Inc.