Extending String would play havoc with equals and intern. JavaDoc says equals

"Compares this string to the specified object. The result is true if and only if the argument is not null and is a String object that represents the same sequence of characters as this object."

Assuming java.lang.String wasn't final, a SafeString could equal a String, and vice versa; because they'd represent the same sequence of characters.

What would happen if you applied intern to a SafeString -- would the SafeString go into the JVM's string pool? The ClassLoader and all objects the SafeString held references to would then get locked in place for the lifetime of the JVM. You'd get a race condition about who could be the first to intern a sequence of characters -- maybe your SafeString would win, maybe a String, or maybe a SafeString loaded by a different classloader (thus a different class).

If you won the race into the pool, this would be a true singleton and people could access your whole environment (sandbox) through reflection and secretKey.intern().getClass().getClassLoader().

Or the JVM could block this hole by making sure that only concrete String objects (and no subclasses) were added to the pool.

If equals was implemented such that SafeString != String then SafeString.intern != String.intern, and SafeString would have to be added to the pool. The pool would then become a pool of <Class, String> instead of <String> and all you'd need to enter the pool would be a fresh classloader.

The only benefit you get from making checkString part of String is that you can call it using "blah".checkString(), rather than checkString("blah"). Scala provides 'views' of objects, so you can say that all Strings in a certain file, or package, have the checkString method, so you can do "blah".checkString().

This is a compile-time-only view; the runtime is not affected.

It's a form of mixin, and it's what you're really after, except that you're used to using inheritance for code reuse, rather than other forms.

A problem with inheritance for code reuse (there are many, here's just one) is that it's inflexible. If you want UnsafeString, a subclass of String that adds 'SafeString checkString()', and then you also want Filename, a subclass of String that adds 'boolean exists()', but then you want something that has both checkString and exists, you're a bit stuck, because you're really just trying to add a method to a class, not to make a new class.

Try Scala's views, or Ruby's open classes. Or, better, CLOS, where polymorphic methods aren't actually part of classes.

The Managing Gigabytes for Java project (http://mg4j.dsi.unimi.it/) has a matured mutable extendable string implementation. http://mg4j.dsi.unimi.it/docs/it/unimi/dsi/mg4j/util/MutableString.html

I think it's a shame that java.util.Date is mutable, but final String class is OK. Use Charsequence or StringBuilder. I can agree on MutableString implementing Charsequence but the java.lang.String should always be final.

It's a culture issue. Anything that should be simple is made hard in Java land. Maybe the authors of String class have a strong reason.

In the first case of adding strings together, since MyString is-a String, there should be no issue, however since this is done by the compiler - there could be work to support it in javac.

In the second case - I would expect that you define constructors for MyString as for any other class.

I really don't understand what you are trying to do. Why can't you simply wrap a string in another object for example? That would give you any flexibility you need - no need to change the String class!

I think the principle argument against extending strings for the reasons you've outlined, is that the "state" (internationalized, normalized against unsafe characters, etc) could be better expressed via apps_hungarian notation, e.g, "String safeLoginStr = normalize(loginStr);". That way, just LOOKING at the code, you know which parts are using the unsafe string, and which are using the safe string. To be tremendously cliche, here's a link to an article Joel Spolsky wrote on the subject. I'm not trying to give you the Slashdot answer (Q:"How do I do this in PHP?" ,A:"Switch to Ruby!") but rather, just point out that there's an alternative solution to the problem, and given that there IS a solution, the Java implementors at Sun might be of the impression that the risks of letting you extend String (whatever their extent may be) might outweigh the benefits.

I didn't get yoir point. Concatenation still wouldn't work:

public void process(SafeString s) {
  String a = "abc" + s; // compilation error
  String b = "abc" + (String) s; // that would work
}

You would need a cast, as SafeString isn't a String. The power of inheritance comes with polimorfism (which can also be accomplished with interfaces), but if all String methods are final and polimorfism isn't possible, why inherit it?

Just use composition (and delegation if needed), as pointed before. Best to leave String final and avoid inheritance.

your SafeString wasn't only a marker interface?

Great idea! A few observations:

• The issue you raise is (for me) mainly about tools: I would want the strings to be statically checked. One way of doing this is to have a checker with plugins for certain constructor invocations and static method invocations.

  new MySQLStatement("sql code");
  Tools.createSQLStatement("sql code");
  

  With plugins for MySQLStatement and createSQLStatement, one can use the checker to make statically sure the the syntax of the strings is well-formed. Ideally, the syntax-highlighting would also be adjusted.
• Note that in functional languages, people are a lot less shy about wrapping a constructor around data (like MySQLStatement above). And this is often a good solution in Java, as well.
• In RDF, strings can be typed (they are called "typed literals" there) via "string"^^XMLDatatypeURI. That is, RDF does not even have integers and booleans, they use "123"^^xsd:integer and "true"^^xsd:boolean This idea looks similar. If annotations are ever allowed to strings, one could closely emulate RDF in this regard.

Are you talking about static (development-time) checking of SQL statements in a Java IDE? Maybe this could be done (better?) with annotations. Instead of "marking" a string as containing SQL, annotate it as such.

For run time, a problem with marking strings is that by their immutable nature, one string is as good as another. E.g. "A" equals "A" equals "A"... and they can be used interchangably. If they are computed strings, they won't have referential equality. But they will be equal.

Marking one string "A" in a special manner breaks this. An inequality is introduced. One string "A" is now different than another string "A". One string "SELECT * FROM FOO" is different than another "SELECT * FROM FOO". But should it be? Wouldn't it be better to mark all "SELECT * FROM FOO" as valid SQL instead of one individual string reference? Following this route leads you away from marker interfaces into caches and sets of vetted strings (like strings known to be valid SQL or not contains funny characters...). This is old school Java and doesn't need a special language extension.

Making String mutables would break Maps.

hash() has a certain contract that is guaranteed to be kept immutable for the entire life of the object - that is why StringBuilder does not have implemented hash(). Maps also rely heavily in the equals() implementation.

Your proposal would yield a different hash() and equals() return value depending on the instant were they are called, which would break the Map implementation we all rely on. My .02 euro :)