Почему класс String объявлен окончательным в Java?

Очень полезно иметь строки, реализованные как неизменяемые объекты. Вы должны прочитать о неизменяемости, чтобы понять больше об этом.

Одним из преимуществ неизменяемых объектов является то, что

Вы можете поделиться дубликатами, указав их на один экземпляр.

(из здесь).

Если бы String не был окончательным, вы могли бы создать подкласс и иметь две строки, которые выглядят одинаково, когда «видятся как строки», но на самом деле разные.

Абсолютно самая важная причина того, что String является неизменной или окончательной, заключается в том, что она используется механизмом загрузки классов и, таким образом, имеет глубокие и фундаментальные аспекты безопасности.

Если бы строка была изменяемой или не окончательной, запрос на загрузку «java.io.Writer» мог бы быть изменен на загрузку «mil.vogoon.DiskErasingWriter».

ссылка: Почему String неизменяем в Java

String — это очень важный класс в Java, многие вещи зависят от его работы определенным образом, например, от неизменности.

Создание класса final предотвращает появление подклассов, которые могут нарушить эти предположения.

Обратите внимание, что даже сейчас, если вы используете отражение, вы можете сломать строки (изменить их значение или хэш-код). Отражение можно остановить с помощью менеджера безопасности. Если бы String не было final, это мог бы сделать каждый.

Другие классы, которые не объявлены final, позволяют вам определять несколько сломанные подклассы (например, у вас может быть List, который добавляет к неправильной позиции), но, по крайней мере, JVM не зависит от них для своих основных операций.

Как сказал Бруно, речь идет о неизменности. Речь идет не только о строках, но и о любых обертках, например. Double, Integer, Character и т. д. На это есть множество причин:

• Безопасность потока
• Безопасность
• Куча, которой управляет сама Java (в отличие от обычной кучи, которая собирается мусором другим способом)
• Управление памятью

В основном это делается для того, чтобы вы, как программист, могли быть уверены, что ваша строка никогда не будет изменена. Это также, если вы знаете, как это работает, может улучшить управление памятью. Попробуйте создать две одинаковые строки друг за другом, например "hello". Вы заметите, если вы отлаживаете, что у них идентичные идентификаторы, это означает, что это ОДИНАКОВЫЕ объекты. Это связано с тем, что Java позволяет вам это делать. Это было бы невозможно, если бы строки были изменяемыми. Они могут иметь то же, что и я, и т. д., потому что они никогда не изменятся. Итак, если вы когда-нибудь решите создать 1 000 000 строк «hello», то на самом деле вы создадите 1 000 000 указателей на «hello». Кроме того, использование любой функции в строке или любых оболочек по этой причине приведет к созданию другого объекта (снова посмотрите на идентификатор объекта - он изменится).

Кроме того, final в Java не обязательно означает, что объект не может изменяться (это отличается, например, от C++). Это означает, что адрес, на который он указывает, не может измениться, но вы можете изменить его свойства и/или атрибуты. Поэтому понимание разницы между неизменяемостью и окончательным в некоторых случаях может быть действительно важным.

HTH

Использованная литература:

• http://chaoticjava.com/posts/how-does-garbage-collection-work/
• http://chaoticjava.com/posts/gc-tips-and-memory-leaks/
• http://java.sun.com/j2se/1.5/pdf/jdk50_ts_guide.pdf

Возможно, это было сделано для упрощения реализации. Если вы разрабатываете класс, который будет наследоваться пользователями этого класса, то у вас будет совершенно новый набор вариантов использования, которые нужно учитывать при разработке. Что произойдет, если они сделают то или иное с защитным полем X? Делая это окончательно, они могут сосредоточиться на правильной работе общедоступного интерфейса и убедиться, что он надежный.

С уже упомянутым множеством хороших моментов я хотел бы добавить еще один: одна из причин того, почему String неизменяема в Java, заключается в том, чтобы позволить String кэшировать свой хэш-код , будучи неизменяемой String в Java кэширует свой хэш-код и не вычислять каждый раз, когда мы вызываем метод хэш-кода строки, что делает его очень быстрым в качестве ключа хэш-карты для использования в хэш-карте в Java.

Короче говоря, поскольку String является неизменной, никто не может изменить ее содержимое после создания, что гарантирует, что hashCode String будет одинаковым при многократном вызове.

Если вы видите, что класс String объявлен как

/** Cache the hash code for the string */
private int hash; // Default to 0

и функция hashcode() выглядит следующим образом:

public int hashCode() {
    int h = hash;
    if (h == 0 && value.length > 0) {
        char val[] = value;

        for (int i = 0; i < value.length; i++) {
            h = 31 * h + val[i];
        }
        hash = h;
    }
    return h;
}

Если это уже компьютер, просто верните значение.

Чтобы убедиться, что мы не получим лучшую реализацию. Конечно, это должен был быть интерфейс.

[править] Ах, получая больше невежественных голосов против. Ответ совершенно серьезный. Мне пришлось несколько раз программировать глупую реализацию String, что приводило к серьезной потере производительности и производительности.

Помимо очевидных причин, предложенных в других ответах, одна мысль о том, чтобы сделать класс String final, также может быть связана с накладными расходами на производительность виртуальных методов. Помните, что String — это тяжелый класс, что делает его окончательным, что означает отсутствие подреализации наверняка, означает отсутствие накладных расходов на косвенные вызовы. Конечно, теперь у нас есть такие вещи, как виртуальный вызов и другие, которые всегда делают такую ​​оптимизацию за вас.

В дополнение к причинам, упомянутым в других ответах (безопасность, неизменность, производительность), следует отметить, что String имеет специальную языковую поддержку. Вы можете писать литералы String и есть поддержка оператора +. Разрешение программистам создавать подклассы String поощряло бы такие взломы, как:

class MyComplex extends String { ... }

MyComplex a = new MyComplex("5+3i");
MyComplex b = new MyComplex("7+4i");
MyComplex c = new MyComplex(a + b);   // would work since a and b are strings,
                                      // and a string + a string is a string.

Ну, у меня другая мысль, я не уверен, прав я или нет, но в Java String - это единственный объект, который также можно рассматривать как примитивный тип данных, я имею в виду, что мы можем создать объект String как имя строки ="java". Теперь, как и другие примитивные типы данных, которые копируются по значению, а не копируются по ссылке, ожидается, что String будет иметь такое же поведение, поэтому String является окончательным. Вот что я подумал. Пожалуйста, игнорируйте, если это совершенно нелогично.

Завершенность строк также защищает их как стандарт. В C++ вы можете создавать подклассы строки, поэтому каждый магазин программирования может иметь свою собственную версию строки. Это приведет к отсутствию сильного стандарта.

Допустим, у вас есть класс Employee с методом greet. Когда вызывается метод greet, он просто печатает Hello everyone!. Таково ожидаемое поведение метода greet.

public class Employee {

    void greet() {
        System.out.println("Hello everyone!");
    }
}

Теперь пусть GrumpyEmployee подкласс Employee и переопределит метод greet, как показано ниже.

public class GrumpyEmployee extends Employee {

    @Override
    void greet() {
        System.out.println("Get lost!");
    }
}

Теперь в приведенном ниже коде взгляните на метод sayHello. Он принимает экземпляр Employee в качестве параметра и вызывает метод приветствия, надеясь, что он скажет Hello everyone!. Но мы получаем Get lost!. Это изменение в поведении связано с Employee grumpyEmployee = new GrumpyEmployee();

public class TestFinal {
    static Employee grumpyEmployee = new GrumpyEmployee();

    public static void main(String[] args) {
        TestFinal testFinal = new TestFinal();
        testFinal.sayHello(grumpyEmployee);
    }

    private void sayHello(Employee employee) {
        employee.greet(); //Here you would expect a warm greeting, but what you get is "Get lost!"
    }
}

Этой ситуации можно избежать, если класс Employee сделать final. Теперь дело за вашим воображением, сколько хаоса может вызвать дерзкий программист, если класс String не будет объявлен как final.

Знает ли JVM, что является неизменным? Ответ: нет. Постоянный пул содержит все неизменяемые поля, но все неизменяемые поля/объекты хранятся не только в постоянном пуле. Только мы реализуем его так, чтобы он добился неизменности и своих свойств. CustomString можно реализовать, не делая его окончательным, используя MarkerInterface, который обеспечит специальное поведение Java для его объединения, функция все еще ожидается!

Большинство ответов связаны с неизменностью - почему объект типа String не может быть обновлен на месте. Здесь много хороших дискуссий, и сообществу Java не мешало бы принять неизменность в качестве принципа. (Не задерживая дыхания.)

Однако вопрос ОП о том, почему он окончательный - почему его нельзя продлить. Некоторые здесь взялись за это, но я согласен с ОП, что здесь есть реальный пробел. Другой язык позволяет разработчикам создавать новые номинальные типы для типа. Например, в Haskell я могу создать следующие новые типы, которые во время выполнения идентичны тексту, но обеспечивают безопасность связывания во время компиляции.

newtype AccountCode = AccountCode Text
newtype FundCode = FundCode Text

Поэтому я бы выдвинул следующее предложение в качестве улучшения языка Java:

newtype AccountCode of String;
newtype FundCode of String;

AccountCode acctCode = "099876";
FundCode fundCode = "099876";

acctCode.equals(fundCode);  // evaluates to false;
acctCode.toString().equals(fundCode.toString());  // evaluates to true;

acctCode=fundCode;  // compile error
getAccount(fundCode);  // compile error

(Или, возможно, мы могли бы начать отвыкать от Java)

Если вы создадите строку один раз, она будет считать, что это объект, если вы хотите изменить это, это невозможно, он создаст новый объект.