Глава 13. Бинарная совместимость

Если класс, который не был объявлен abstract, изменяется на объявление abstract, то существующие двоичные файлы, которые пытаются создать новые экземпляры этого класса, будут выбрасывать либо InstantiationError во время линковки, либо (если используется рефлексивный метод) InstantiationException во время выполнения; поэтому такое изменение не рекомендуется для широко распространённых классов.

Изменение класса, объявленного abstract, на необъявление abstract не нарушает совместимость с существующими двоичными файлами.

Добавление или удаление параметра типа класса не оказывает влияния на бинарную совместимость.

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

Переименование параметра типа класса не влияет на существующие бинарные файлы.

Изменение первого ограничения параметра типа класса может изменить стирание (§4.6) любого члена, который использует этот параметр типа в собственном типе, и это может повлиять на бинарную совместимость. Изменение такого ограничения аналогично изменению первого ограничения параметра типа метода или конструктора (§13.4.13).

Изменение любого другого ограничения не влияет на бинарную совместимость.

Добавление члена-инстанса (соответственно static), имеющего то же имя и доступность (для полей), или то же имя, доступность и сигнатуру и возвращаемый тип (для методов), что и член-инстанс (соответственно static) суперкласса или подкласса, не приводит к несовместимости с существующими бинарными файлами. Ошибка не возникает, даже если набор связываемых классов вызовет ошибку компиляции.

Удаление члена класса или конструктора, который не объявлен private, может вызвать ошибку линковки, если член или конструктор используется существующим бинарным файлом.

class Hyper {
    void hello() { System.out.println("hello from Hyper"); }
}
class Super extends Hyper {
    void hello() { System.out.println("hello from Super"); }
}
class Test {
    public static void main(String[] args) {
        new Super().hello();
    }
}

hello from Super

class Super extends Hyper {}

hello from Hyper

Ключевое слово super может использоваться для доступа к методу, объявленному в суперклассе, минуя любые методы, объявленные в текущем классе. Выражение super.Идентификатор разрешается во время компиляции к методу m в суперклассе S. Если метод m является методом-инстансом, то метод, который вызывается во время выполнения, — это метод с той же сигнатурой, что и m, который является членом непосредственного суперкласса класса, содержащего выражение, включающее super.

class Hyper {
    void hello() { System.out.println("hello from Hyper"); }
}
class Super extends Hyper { }
class Test extends Super {
    public static void main(String[] args) {
        new Test().hello();
    }
    void hello() {
        super.hello();
    }
}

hello from Hyper

class Super extends Hyper {
    void hello() { System.out.println("hello from Super"); }
}

hello from Super

Изменение объявленного доступа к члену или конструктору для ограничения доступа может нарушить совместимость с существующими бинарными файлами, вызвав ошибку линковки при их разрешении. Доступ ограничен, если модификатор доступа изменён с пакета на private доступ; от protected доступа до пакета или private доступа; или от public доступа до protected, пакета или private доступа. Поэтому не рекомендуется изменять доступ к членам или конструкторам широко используемых классов.

Возможно, неожиданно, что формат бинарных файлов определён так, что изменение члена или конструктора для расширения доступа не вызывает ошибку линковки, когда подкласс (уже) определяет метод с ограниченным доступом.

package points;
public class Point {
    public int x, y;
    protected void print() {
        System.out.println("(" + x + "," + y + ")");
    }
}

class Test extends points.Point {
    public static void main(String[] args) {
        Test t = new Test();
        t.print();
    }
    protected void print() { 
        System.out.println("Test"); 
    }
}

Test

Разрешение суперклассам изменять методы protected на public без нарушения бинарных файлов существующих подклассов помогает сделать бинарные файлы менее хрупкими. Альтернатива, где такое изменение вызывало бы ошибку линковки, создавала бы дополнительные несовместимости бинарных файлов.

Широко используемые программы не должны предоставлять доступ к полям своим клиентам. Помимо проблем с бинарной совместимостью, обсуждаемых ниже, это хорошая практика разработки программного обеспечения. Добавление поля в класс может нарушить совместимость с существующими бинарными файлами, которые не перекомпилированы.

Предположим ссылку на поле f с квалифицирующим классом C. Далее предположим, что f — это фактически поле-инстанс (соответственно static), объявленное в суперклассе C, S, и что тип f — X.

Если новое поле типа X с тем же именем, что и f, добавлено в подкласс S, который является суперклассом C или C самим по себе, может возникнуть ошибка линковки. Такая ошибка линковки произойдёт только в том случае, если, помимо вышеперечисленного, выполняется одно из следующих условий:

В частности, ошибка линковки не возникнет в случае, когда класс больше не может быть перекомпилирован, потому что доступ к полю ранее ссылался на поле суперкласса с несовместимым типом. Ранее скомпилированный класс с такой ссылкой будет продолжать ссылаться на поле, объявленное в суперклассе.

class Hyper { String h = "hyper"; }
class Super extends Hyper { String s = "super"; }
class Test {
    public static void main(String[] args) {
        System.out.println(new Super().h);
    }
}

hyper

class Super extends Hyper {
    String s = "super";
    int h = 0;
}

hyper

class Hyper { String h = "Hyper"; }
class Super extends Hyper { }
class Test extends Super {
    public static void main(String[] args) {
        String s = new Test().h;
        System.out.println(s);
    }
}

Hyper

class Super extends Hyper { char h = 'h'; }

Hyper

class Hyper { String h = "Hyper"; }
class Super extends Hyper { char h = 'h'; }
class Test extends Super {
    public static void main(String[] args) {
        String s = new Test().h;
        System.out.println(s);
    }
}

Удаление поля из класса нарушит совместимость с любыми существующими бинарными файлами, которые ссылаются на это поле, и будет выброшена ошибка NoSuchFieldError при линковке такой ссылки из существующего бинарного файла. Только поля private могут быть безопасно удалены из широко распространённого класса.

Для целей бинарной совместимости добавление или удаление поля f, тип которого включает переменные типов (§4.4) или параметризованные типы (§4.5), эквивалентно добавлению (соответственно удалению) поля с тем же именем, тип которого является стиранием (§4.6) типа f.

Если поле, которое не было объявлено final, изменяется на объявление final, это может нарушить совместимость с существующими двоичными файлами, которые пытаются присвоить новые значения полю.

class Super { char s; }
class Test extends Super {
    public static void main(String[] args) {
        Super x = new Super();
        x.s = 'a';
        System.out.println(x.s);
    }
}

a

class Super { final char s = 'b'; }

Удаление ключевого слова final или изменение значения, к которому инициализировано поле, не нарушает совместимость с существующими двоичными файлами.

Если поле является константой (§4.12.4), и, более того, является static, то удаление ключевого слова final или изменение его значения не нарушит совместимость с существующими двоичными файлами, вызывая их неработоспособность, но они не увидят новых значений для использования поля, если не перекомпилированы. Этот результат является побочным эффектом решения по поддержке условной компиляции (§14.22). (Можно предположить, что новое значение не видно, если используется в константном выражении (§15.29), но видно в противном случае. Это не так; существующие двоичные файлы вообще не видят нового значения.)

Лучший способ избежать проблем с «непостоянными константами» в широко распространенном коде — использовать static константные переменные только для значений, которые, по всей вероятности, никогда не изменятся. Помимо истинных математических констант, мы рекомендуем, чтобы исходный код очень экономно использовал static константные переменные.

private static int N;
public static int getN() { return N; }

public static final int N = ...;

public static int N = ...;

Если поле, которое не объявлено private, не было объявлено static и изменено на объявление static, или наоборот, то произойдет ошибка связи, конкретно ошибка IncompatibleClassChangeError, если поле используется существующим двоичным файлом, который ожидал поле другого типа. Такие изменения не рекомендуются в коде, который широко распространен.

Добавление или удаление модификатора transient поля не нарушает совместимость с существующими двоичными файлами.

Добавление метода или конструктора в класс не нарушит совместимость с любыми существующими двоичными файлами, даже в том случае, когда класс больше не может быть перекомпилирован, потому что вызов ранее ссылался на метод или конструктор суперкласса с несовместимым типом. Предыдущий скомпилированный класс с такой ссылкой будет по-прежнему ссылаться на метод или конструктор, объявленный в суперклассе.

Предположим ссылку на метод m с квалифицирующим классом C. Предположим также, что m является фактически методом экземпляра (соответственно static) метода, объявленного в суперклассе C, S.

Если к подклассу S, который является суперклассом C или самим C, добавлен новый метод типа X с той же сигнатурой и возвращаемым типом, что и m, может произойти ошибка связи. Такая ошибка связи произойдет только в том случае, если, помимо вышесказанного, верно одно из следующих утверждений:

Удаление метода или конструктора из класса может нарушить совместимость с любым существующим двоичным файлом, который ссылался на этот метод или конструктор; может быть выброшена ошибка NoSuchMethodError при связывании такой ссылки из существующего двоичного файла. Такая ошибка произойдёт только если в суперклассе нет метода с совпадающей сигнатурой и возвращаемым типом.

Если исходный код для класса, не являющегося внутренним классом, не содержит объявленных конструкторов, то неявно объявляется конструктор по умолчанию без параметров (§8.8.9). Добавление одного или нескольких объявлений конструкторов в исходный код такого класса предотвратит неявное объявление этого конструктора по умолчанию, эффективно удалив конструктор, за исключением случая, когда один из новых конструкторов также не имеет параметров, тем самым заменяя конструктор по умолчанию. Конструктор по умолчанию без параметров получает тот же модификатор доступа, что и класс объявления, поэтому любая замена должна иметь не меньший или больший доступ, чтобы сохранить совместимость с существующими двоичными файлами.

Добавление или удаление параметра типа метода или конструктора само по себе не имеет никакого влияния на двоичную совместимость.

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

Переименование параметра типа метода или конструктора не влияет на существующие двоичные файлы.

Изменение первой границы параметра типа метода или конструктора может изменить стирание (§4.6) любого члена, который использует этот параметр типа в своем типе, и это может повлиять на двоичную совместимость. В частности:

Изменение любой другой границы не влияет на двоичную совместимость.

Изменение имени формального параметра метода или конструктора не влияет на существующие двоичные файлы.

Изменение имени метода или типа формального параметра метода или конструктора, или добавление параметра к объявлению метода или конструктора, или удаление параметра из объявления метода или конструктора создает метод или конструктор с новой сигнатурой и имеет совокупный эффект удаления метода или конструктора со старой сигнатурой и добавления метода или конструктора с новой сигнатурой (§13.4.12).

Изменение типа последнего формального параметра метода с T[] на параметр с переменным числом аргументов типа T, то есть на T... (§8.4.1), и наоборот, не влияет на существующие двоичные файлы.

Для целей двоичной совместимости добавление или удаление метода или конструктора m, чья сигнатура включает переменные типа (§4.4) или параметризованные типы (§4.5), эквивалентно добавлению (соответственно, удалению) иначе эквивалентного метода, чья сигнатура является стиранием (§4.6) сигнатуры m.

Изменение типа результата метода или замена типа результата на void, или замена void на тип результата, приводит к удалению старого метода и добавлению нового метода с новым типом результата или вновь добавленным void результатом (см. §13.4.12).

В целях бинарной совместимости добавление или удаление метода или конструктора m, тип возвращаемого значения которого включает переменные типов (§4.4) или параметризованные типы (§4.5), эквивалентно добавлению (соответственно, удалению) иначе эквивалентного метода, тип возвращаемого значения которого представляет собой стирание (§4.6) типа возвращаемого значения m.

Изменение метода, объявленного abstract, на метод, который больше не объявлен abstract, не нарушает совместимость с существующими бинарными файлами.

Изменение метода, который не объявлен abstract, на метод, объявленный abstract, нарушит совместимость с существующими бинарными файлами, которые ранее вызывали этот метод, что приведёт к AbstractMethodError.

class Super { void out() { System.out.println("Out"); } }
class Test extends Super {
    public static void main(String[] args) {
        Test t = new Test();
        System.out.println("Way ");
        t.out();
    }
}

Way
Out

abstract class Super {
    abstract void out();
}

Изменение метода, объявленного final, на метод, который больше не объявлен final, не нарушает совместимость с существующими бинарными файлами.

Изменение инстансного метода, который не объявлен final, на метод, объявленный final, может нарушить совместимость с существующими бинарными файлами, которые зависят от возможности переопределения метода.

class Super { void out() { System.out.println("out"); } }
class Test extends Super {
    public static void main(String[] args) {
        Test t = new Test();
        t.out();
    }
    void out() { super.out(); }
}

out

class Super { final void out() { System.out.println("!"); } }

Изменение метода класса (static), который не объявлен final, на объявленный final, не нарушает совместимость с существующими бинарными файлами, так как метод не мог быть переопределён.

Добавление или удаление модификатора native метода не нарушает совместимость с существующими бинарными файлами.

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

Если метод, который не объявлен private, также объявлен как static (то есть, метод класса) и изменяется на не объявленный static (то есть, инстансный метод), или наоборот, то совместимость с существующими бинарными файлами может быть нарушена, что приведёт к ошибке времени компоновки, а именно IncompatibleClassChangeError, если эти методы используются существующими бинарными файлами. Такие изменения не рекомендуются в коде, который широко распространён.

Добавление или удаление модификатора synchronized метода не нарушает совместимость с существующими бинарными файлами.

Изменения в части throws методов или конструкторов не нарушают совместимость с существующими бинарными файлами; эти части проверяются только на этапе компиляции.

Изменения в теле метода или конструктора не нарушают совместимость с существующими бинарными файлами.

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

Поэтому отметим, что Java-компилятор не может встроить метод в режиме компиляции. В общем, мы рекомендуем реализациям использовать генерацию и оптимизацию кода на поздних этапах (во время выполнения).

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

Хотя добавление нового перегруженного метода или конструктора может вызвать ошибку времени компиляции в следующий раз, когда класс или интерфейс компилируется, потому что нет метода или конструктора, который является наиболее специфичным (§15.12.2.5), во время выполнения такой ошибки не возникает, поскольку разрешение перегрузки не выполняется во время выполнения.

class Super {
    static void out(float f) {
        System.out.println("float");
    }
}
class Test {
    public static void main(String[] args) {
        Super.out(2);
    }
}

float

class Super {
    static void out(float f) { System.out.println("float"); }
    static void out(int i)   { System.out.println("int");   }
}

float

int

Если инстансный метод добавлен в подкласс и переопределяет метод в суперклассе, то метод подкласса будет найден вызовами методов в существующих бинарных файлах, и эти бинарные файлы не изменятся.

Если метод класса добавляется в класс, то этот метод не будет найден, если класс, к которому относится вызов метода, не является подклассом.

Добавление, удаление или изменение статического инициализатора (§8.7) класса не повлияет на существующие бинарные файлы.

Добавление или изменение порядка констант перечисления в классе перечисления не нарушит совместимость с существующими бинарными файлами.

Удаление константы перечисления из класса перечисления удалит поле public, соответствующее константе перечисления (§8.9.3). Последствия описаны в §13.4.8. Такое изменение не рекомендуется для широко распространённых классов перечислений.

Во всех остальных отношениях правила бинарной совместимости для классов перечислений идентичны правилам для обычных классов.

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

Более точно, добавление, удаление, изменение или переупорядочивание компонентов записи может изменить соответствующие неявные объявления полей компонентов и методов-доступов, а также изменить сигнатуру и реализацию канонического конструктора и других поддерживающих методов, со следствиями, указанными в §13.4.8 и §13.4.12.

Во всех других отношениях правила двоичной совместимости для классов записей идентичны правилам для обычных классов.