Sunday, March 29, 2009

Java's bedevilled take on Strings

"A world without String is Chaos"
(remember this from Mouse Hunt?)


My turn: "A language with befuddling support for String is annoying" :)

Java is not a pure object-oriented language, mostly the impurity comes from the primitive type support. Although primitive types provide fast access and readability, however mixing them with their OOP counterparts is always frustrating. Same goes with C#.

The most annoying bit is the support for String. String is not a primitive type in Java nor was it supported in C++, you would have to create your own char array or use the STL's std::string. Yet there is special support in the language to give it the primitive feel. You can write:

String str = "String object";
String str2 = "this is not a String object but converted to one by the language" + str;
String str3 = "most annoying of all, you could use String's methods on this".toUpperCase();

As the last statement demonstrates, you could even call methods upon this non-standard object while you cannot do the same with other primitive types. Same thing could have been done with an integer literal (int) by providing Integer's methods upon it.

These dual standards are evil and confusing creating doubts about the authenticity of the language.
I'm loving Scala these days, it's stance on these dissimilarities created by Java and C# by providing us the all new and improved data types in the scala package.
Uptill now I have only but one grudge with Scala and that is the Scala's Strings refer to the one in java.lang.String package rather than providing us an improved version of it in the scala package.
Martin Odersky, please do something about it!

6 comments:

  1. I haven't worked with Java 6 that much, but I believe that it does provide auto boxing/unboxing which should take care of the issue you have with ints, right?

    C# has had support for auto boxing/unboxing since its earliest days.

    Also, not sure what is wrong with Java's String class?

    ReplyDelete
  2. @Immad Auto boxing/unboxing is a different concept providing conversion between corresponding reference and value types.
    And that problem with integer cannot be dealt with auto boxing. Consider this:
    int i=999;
    short s = i.shortValue();//Not possible
    s = 999.shortValue();//Not possible
    s = ((Integer)i).shortValue()//works, not on the primitive i but on the object of type Integer.

    While I cannot do 999.someMethod on a primitive int, I can perform operations on a primitive String: "999".someMethod. If you say this string conversion into object is implicit then why isn't the int one? The blame is either on the superior support for String as compared to other primitive types or the not-so-uniformly written BCLs.

    ReplyDelete
  3. I realized the use cases you mentioned after submitting my comment.

    It would be nice to have support for those use cases in Java, but I personally don't think they are a major annoyance.

    But yes, making the language more uniform and hiding these optimizations behind the scenes should be the preferred option.

    ReplyDelete
  4. I don't think having String literal support in the compiler makes Strings feel primitive. Its just that nearly everyone agrees that since Strings are used so much, writing: "Hey You Guys", is much easier than: new String("Hey You Guys") which the former just compiles into. The String literal is still an object.

    In programming you deal with Strings a lot. I think few people today would want to use a language that didn't have natural string literal support.

    What would you propose as an alternative?

    And again, what is wrong with Java's String? I actually think its severely lacking in the things that the compiler does let you do with it, as opposed to the other way around. Ruby lets you do much more, and its far easier.

    ReplyDelete
  5. Ruby follows a uniform approach for primitive types by having them all as OO DS. However Java, supporting primitives explicitly and as an alternative having OO classes for them, remains in between the two approaches.

    I would certainly vote for going the object oriented route like Ruby or Scala.

    ReplyDelete
  6. You really don't a case why there is a problem with String in Java. Using emotional charged language "impure" "evil", "bedeviled", "confusing" don't make a point.

    So, String is class for which can call methods on but you can't do the same for primitives? If you are trying to make some point about primitives not being object-oriented (a valid point), then the topic shouldn't be something (String) that is a real class.

    ReplyDelete