Если класс, который не был объявлен 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);
    }
}

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

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

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

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

a

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

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

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

Этот результат является побочным эффектом решения поддерживать условную компиляцию, как обсуждалось в конце §14.21.

class Flags { static final boolean debug = true; }
class Test {
    public static void main(String[] args) {
        if (Flags.debug)
            System.out.println("debug is true");
    }
}

debug is true

class Flags { static final boolean debug = false; }

debug is true

interface Flags { boolean debug = true; }
class Test {
    public static void main(String[] args) {
        if (Flags.debug)
            System.out.println("debug is true");
    }
}

Лучший способ избежать проблем с «изменяемыми константами» в широко используемом коде — объявлять в качестве констант времени компиляции только те значения, которые действительно вряд ли изменятся. Помимо истинно математических констант, мы рекомендуем, чтобы исходный код делал очень умеренное использование переменных класса, которые объявлены static и final. Если требуется только для чтения природа final, лучший выбор — объявить private static переменную и подходящий метод доступа для получения её значения.

Таким образом, мы рекомендуем:

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

вместо:

public static final int N = ...;

Нет проблем с:

public static int N = ...;

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

Мы отмечаем, но не рекомендуем, что если поле примитивного типа интерфейса может измениться, его значение может быть выражено следующим образом:

interface Flags {
    boolean debug = new Boolean(true).booleanValue();
}

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

Еще одно примечание: поля static final, имеющие константные значения (будь то примитивного или String типа), никогда не должны иметь значение по умолчанию для своего типа (§4.12.5). Это означает, что все такие поля, по-видимому, инициализируются в первую очередь во время инициализации класса (§8.3.2.1, §9.3.1, §12.4.2).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Для целей бинарной совместимости, добавление или удаление метода или конструктора 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-компилятор не может расширять метод inline во время компиляции. В общем случае мы рекомендуем реализациям использовать генерацию и оптимизацию кода с поздней связью (во время выполнения).

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

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

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