Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Why is String class final? [duplicate]

Possible Duplicate:
Why is String final in Java?

There are various moments in my programming life that I wished the the String class had not been final/sealed/NotInheritable.

What are the language architects trying to prevent me from doing that would throw a monkey wrench into the works.

Rather, what are the monkey wrenches the language architects would want to prevent me from throwing into the works by restricting me from extending String class?

Could you list a list of pros-cons of extendable string class?

like image 952
Blessed Geek Avatar asked Aug 02 '10 01:08

Blessed Geek


People also ask

Why is String class made final?

String class is made final in Java in order to make the String objects immutable. Making an object immutable helps in two ways: Security: the system can hand out sensitive bits of read-only information without worrying that they will be altered. Performance: immutable data is very useful in making things thread-safe.

Why String class is final or immutable?

The String is immutable in Java because of the security, synchronization and concurrency, caching, and class loading. The reason of making string final is to destroy the immutability and to not allow others to extend it. The String objects are cached in the String pool, and it makes the String immutable.

Why String is immutable or final in Java?

In the String constant pool, a String object is likely to have one or many references. If several references point to the same String without even knowing it, it would be bad if one of the references modified that String value. That's why String objects are immutable.

Why do we use final String in Java?

The string is immutable means that we cannot change the object itself, but we can change the reference to the object. The string is made final to not allow others to extend it and destroy its immutability.


1 Answers

String is an immutable class which means if you cannot modify its state after you create it. If you could modify a string after it has entered another library, or a Map for instance the result would be unpredictable.

One mistake of the Java API is that BigInteger and BigDecimal are not final which means you need to perform a defensive copy of these objects when receiving them from non trusted code. Conversely, you can always trust that a String will remain consistent.

Untrustworthy BigInteger:

public class DestructiveBigInteger extends BigInteger {

    public DestructiveBigInteger(String value) {
        super(value);
    }

    public BigInteger add(BigInteger val) {
        return BigInteger.ONE; // add() method does not behave correctly
    }

    public BigInteger subtract(BigInteger val) {
        throw new UnsupportedOperationException("subtract is broken");
    }
}

The same thing is not possible with String. As stated in Effective Java, you need to make defensive copies of these types of objects:

public void setValue(BigInteger value) {
    this.value = new BigInteger(value.toByteArray());
}
like image 129
krock Avatar answered Oct 11 '22 03:10

krock