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

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

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

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

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

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

Исключение 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 {
    throwAorB();
} catch(ExceptionA | ExceptionB 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 с квалифицируемым типом T. Предположим далее, что f фактически является полем экземпляра (соответственно static) объявленным в суперклассе T, S, и что тип f равен X.

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

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

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.21). (Можно предположить, что новое значение не отображается, если используется в выражении константы (§15.28), но отображается в противном случае. Это не так; существующие двоичные файлы вообще не видят нового значения.)

Лучший способ избежать проблем с "непостоянными константами" в широко распространённом коде — использовать 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 с квалифицирующим типом T. Предположим далее, что m фактически является методом экземпляра (соответственно static) объявленным в суперклассе T, S.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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