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

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

Для целей двоичной совместимости добавление или удаление поля 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 константных переменных заключается в switch операторах. Они являются единственным типом операторов, который полагается на константные выражения, а именно, что каждый case метка switch оператора должна быть константным выражением, значение которого отличается от каждого другого case метка. case метки часто являются ссылками на static константные переменные, поэтому может не быть очевидно, что все метки имеют разные значения. Если доказано, что при компиляции нет дублирующих меток, то внедрение значений в файл class гарантирует отсутствие дублирующих меток во время выполнения - очень желательное свойство.

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 константные переменные только для значений, которые действительно, вероятно, никогда не изменятся. Помимо истинных математических констант, мы рекомендуем, чтобы исходный код использовал static константные переменные очень экономно.

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

public static final int N = ...;

public static int N = ...;

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

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

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

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

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

Если поле, которое не было объявлено 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[] на параметр с переменным числом параметров (§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 не может встраивать метод во время компиляции. В общем случае рекомендуется, чтобы реализации использовали создание и оптимизацию кода на этапе выполнения (late-bound).

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

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

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