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

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

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

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

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

Например, замена исходного базового типа класса параметризацией класса или интерфейса, названного исходным типом, является бинарно совместимой операцией.

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

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

h

class Super { char s = 's'; }

s

try {
    failByThrowingAorB();
} catch (A|B e) {
    ...
}

Добавление или удаление параметра типа класса само по себе не имеет никаких последствий для бинарной совместимости.

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

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

Изменение первого ограничения параметра типа класса может изменить стирание (§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);
    }
}

Удаление поля из класса нарушит совместимость с любыми ранее существовавшими двоичными файлами, которые ссылаются на это поле, и при такой ссылке из ранее существовавшего двоичного файла будет сгенерирована ошибка линковки. Только поля 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.

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

Удаление метода или конструктора из класса может нарушить совместимость с любым существующим двоичным файлом, который ссылался на этот метод или конструктор; может быть выброшена ошибка 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) класса не влияет на предварительно созданные двоичные файлы.

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

Как и в случае с sealed классами (§13.4.2.1), хотя добавление константы перечисления к классу перечисления считается бинарно совместимым изменением, это может привести к тому, что выполнение исчерпывающего switch (§14.11.1) завершится ошибкой, если switch столкнется с новой константой перечисления, которая не была известна на этапе компиляции (§14.11.3, §15.28.2).

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

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

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

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

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