I don't know:

1. having nullable references by default strikes me as a bigger issue

2. I don't see any reason I'd want to subclass String, actually (though I could see wanting to create an alternate implementation e.g. ropes-based). So String being a final class makes perfect sense as far as I'm concerned (unless it were an interface or some sort of "proxy" class as is often done in Cocoa). On the other hand, I'd give a phalange to easily create an unrelated type (typesystem-wise) with the same implementation. What `newtype` provides in Haskell.

I must agree with the nullable one. Let's say the biggest failure that I haven't heard anyone else talk about.

As per your #2, that's what I was hinting at except that the implementation effort of final vs. non-final is negligible, thus making it harder to excuse as far as I'm concerned.

how would a nominally different string type be better than wrapping the string ?

I mean I understand why having a Name, ZipCode or UUID stringish class helps ensure program correctness, I do not understand (out of ignorance) how it would improve your code vs a wrapper.

> how would a nominally different string type be better than wrapping the string ?

* It is significantly less verbose, therefore simpler and more likely to be used at all. And less error-prone

* It can provide string APIs working on itself (either by default or through the aliasing declaration) precluding the need to manually re-implement things like comparisons or printing

It's amusing that in a thread about the advantages of Haskell, immutability is being identified as the largest failure a language has made.

I don't think immutable Strings are a bad idea but I do think it's unfortunate that Java:

- Made Strings immutable, used them everywhere, and only later worked out that perhaps CharSequence would have been better in a lot of places.

- Didn't provide a sensible way to handle Object extensions

A class being final means that you can't derive from it in Java, not that instances of the class are immutable.

To ensure immutability of a type in Java, you typically need to prevent it from being extended.

Biggest failure? try Integer(100) == Integer(100) and Integer(200) == Integer(200)

Why a failure?

String is final in most languages OO languages.

I would consider having any final classes in a standard library to be a failure. One of the pillars of OOP is extensibility.

Then you should learn about the fragile base class problem,

http://www.cas.mcmaster.ca/~emil/Publications_files/Mikhajlo...

API design is a very complex issue. Any change in a base class can have unintended consequences.

Specially in components sold as libraries to development companies, where you as a customer don't have access to the source code.

You're right, one of the OOP pillars is extensibility, but inheritance is just one way of doing it.

Replied to the wrong comment?