Spec-Zone .ru спецификации, руководства, описания, API

ГЛАВА 13

Совместимость на уровне двоичных кодов

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

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

Бумага, заключенная в кавычки выше, кажется в Продолжениях OOPSLA '95, опубликованной как ACM SIGPLAN Уведомления, Объем 30, Номер 10, октябрь 1995, страницы 426-438. В пределах платформы той бумаги двоичные файлы языка программирования Java двоичные совместимый при всех соответствующих преобразованиях, которые авторы идентифицируют (с некоторыми протестами относительно добавления переменных экземпляра). Используя их схему, вот список некоторых важных двоичных совместимых изменений, которые поддерживает язык программирования Java:

• Повторно реализовывая существующие методы, конструкторов, и инициализаторы, чтобы улучшить производительность.
• Изменение методов или конструкторов к возвращаемым значениям на вводах, для которых они ранее или выдавали исключения, которые обычно не должны происходить или отказавший, входя в бесконечный цикл или вызывая мертвую блокировку.
• Добавляя новые поля, методы, или конструкторов к существующему классу или интерфейсу.
• Удаление private поля, методы, или конструкторы класса.
• Когда весь пакет обновляется, удаляя поля доступа (только для пакета) по умолчанию, методы, или конструкторов классов и интерфейсов в пакете.
• Переупорядочивая поля, методы, или конструкторов в существующем описании типа.
• Перемещение метода вверх в иерархии классов.
• Переупорядочение списка прямых суперинтерфейсов класса или интерфейса.
• Вставка нового класса или интерфейса вводит иерархию типа.

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

Эта глава сначала определяет некоторые свойства, которые любой двоичный формат для языка программирования Java должен иметь (§13.1). Это затем определяет совместимость на уровне двоичных кодов, объясняя, что это и что это не (§13.2). Это наконец перечисляет большой набор возможных изменений к пакетам (§13.3), классы (§13.4) и интерфейсы (§13.5), определяя, какие из этих изменений, как гарантируют, сохранят совместимость на уровне двоичных кодов и которые не являются.

13.1 Форма Двоичного файла

Необходимые свойства:

• Класс или интерфейс должно назвать его двоичное имя, которое должно встретить следующие ограничения:
  • Двоичное имя высокоуровневого типа является своим каноническим именем (§6.7).
  • Двоичное имя типа элемента состоит из двоичного имени его сразу типа включения, сопровождаемого $, сопровождаемым простым именем элемента.
  • Двоичное имя любого вложенного типа должно иметь, как префикс, двоичное имя его высокоуровневого класса включения.
• Ссылка на другой класс или интерфейсный тип должна быть символьной, используя двоичное имя типа.
• Учитывая юридическое выражение, обозначающее доступ к полю в классе C, ссылаясь на поле, названное f, объявленным в (возможно отличный) класс или интерфейс D, мы определяем тип квалификации полевой ссылки следующим образом:
  • Если выражение имеет форму Primary.f тогда, тип времени компиляции Основных является типом квалификации ссылки.
  • Если выражение имеет форму super.f тогда суперкласс C является типом квалификации ссылки.
  • Если выражение имеет форму X.super.f тогда, суперкласс X является типом квалификации ссылки.
  • Если ссылка имеет форму X.f, где X обозначает класс или интерфейс, то класс или интерфейс, обозначенный X, являются типом квалификации ссылки
  • Если на выражение ссылается простое имя, то, если f является элементом текущего класса или интерфейса, C, то T, которым позволяют, являются C. Иначе, позвольте T быть самым внутренним, лексически классом включения которого f является элементом. T является типом квалификации ссылки.

Ссылка на f должна быть скомпилирована в символьную ссылку на тип квалификации ссылки, плюс простое имя поля, f. Ссылка должна также включать символьную ссылку на объявленный тип поля так, чтобы верификатор мог проверить, что тип как ожидалось. Ссылки на поля, которые являются final и инициализированный с константными выражениями времени компиляции разрешаются во время компиляции к постоянной величине, которая обозначается. Никакая ссылка на такое постоянное поле не должна присутствовать в коде в двоичном файле (кроме в классе или интерфейсе, содержащем постоянное поле, у которого будет код, чтобы инициализировать это), и такие постоянные поля, должно всегда казаться, были инициализированы; начальное значение по умолчанию для типа такого поля никогда не должно наблюдаться. См. §13.4.8 для обсуждения.

• Учитывая выражение вызова метода в классе или интерфейсе C ссылка на метод, названный м., объявил в (возможно отличный) класс или интерфейс D, мы определяем тип квалификации вызова метода следующим образом:

Если D Object тогда тип квалификации выражения Object. Иначе:
• Если выражение имеет форму Primary.m тогда, тип времени компиляции Основных является типом квалификации вызова метода.
• Если выражение имеет форму super.m тогда суперкласс C является типом квалификации вызова метода.
• Если выражение имеет форму X.super.m тогда, суперкласс X является типом квалификации вызова метода.
• Если ссылка имеет форму X.m, где X обозначает класс или интерфейс, то класс или интерфейс, обозначенный X, являются типом квалификации вызова метода
• Если на метод ссылается простое имя, то, если м. является элементом текущего класса или интерфейса, C, позволяют T быть C. Иначе, позвольте T быть самым внутренним, лексически классом включения которого м. является элементом. T является типом квалификации вызова метода.
Ссылка на метод должна быть разрешена во время компиляции к символьной ссылке на тип квалификации вызова плюс подпись метода (§8.4.2). Ссылка на метод должна также включать или символьную ссылку на тип возврата обозначенного метода или индикацию, которой объявляется обозначенный метод void и не возвращает значение. Подпись метода должна включать все следующее:
• Простое имя метода
• Число параметров к методу
• Символьная ссылка на тип каждого параметра

• Учитывая выражение создания экземпляра класса (§15.9) или оператор вызова конструктора (§8.8.5.1) в классе или интерфейсе C ссылка на конструктора м. объявил в (возможно отличный) класс или интерфейс D, мы определяем тип квалификации вызова конструктора следующим образом:
  • Если выражение имеет форму new D (...) или X.new D (...), тогда тип квалификации вызова является D.
  • Если выражение имеет форму новый D (..) {...} или X.new D (...) {...}, тогда тип квалификации выражения является типом времени компиляции выражения.
  • Если выражение имеет форму супер (...) или Primary.super (...) тогда, тип квалификации выражения является прямым суперклассом C.
  • Если выражение имеет форму this(...), тогда тип квалификации выражения является C.

Ссылка на конструктора должна быть разрешена во время компиляции к символьной ссылке на тип квалификации вызова плюс подпись конструктора (§8.8.2). Подпись конструктора должна включать обоих:
• Число параметров конструктору
• Символьная ссылка на тип каждого параметра
Кроме того, конструктор нечастного внутреннего задействованного класса должен быть скомпилирован так, что, он имеет как его первый параметр, дополнительный неявный параметр, представляющий сразу экземпляр включения (§8.1.2).

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

• Если это - класс и не является классом Object, тогда символьная ссылка на прямой суперкласс этого класса
• Символьная ссылка на каждый прямой суперинтерфейс, если любой
• Спецификация каждого поля, объявленного в классе или интерфейсе, данном как простое имя поля и символьной ссылки на тип поля
• Если это - класс, то подпись каждого конструктора, как описано выше
• Для каждого метода, объявленного в классе или интерфейсе, его подписи и типе возврата, как описано выше
• Код должен был реализовать класс или интерфейс:
  • Для интерфейса кодируйте для полевых инициализаторов
  • Для класса кодируйте для полевых инициализаторов, экземпляра и статических инициализаторов, и реализации каждого метода или конструктора
• Каждый тип должен содержать достаточную информацию, чтобы восстановить ее каноническое имя (§6.7).
• У каждого типа элемента должна быть достаточная информация, чтобы восстановить ее исходный модификатор доступа уровня.
• У каждого вложенного класса должна быть символьная ссылка на ее сразу класс включения.
• Каждый класс, который содержит вложенный класс, должен содержать символьные ссылки на все его задействованные классы, и на все локальные и анонимные классы, которые появляются в его методах, конструкторах и статичный или инициализаторы экземпляра.

13.2 Что Совместимость на уровне двоичных кодов и Не

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

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

• Добавление большего количества методов, перегружающих определенное имя метода, не повреждает совместимость с существующими ранее двоичными файлами. Сигнатура метода, которую существующий ранее двоичный файл будет использовать для поиска метода, выбирается алгоритмом разрешения перегрузки метода во время компиляции (§15.12.2). (Если язык был разработан так, чтобы определенный метод, который будет выполнен, был выбран во время выполнения, тогда такая неоднозначность могла бы быть обнаружена во время выполнения. Такое правило подразумевало бы, что добавление дополнительного перегруженного метода, чтобы сделать неоднозначность возможной на сайте вызова, могло повредить совместимость с неизвестным числом существующих ранее двоичных файлов. См. §13.4.21 для большего количества обсуждения.)

13.3 Развитие Пакетов

Изменения в высокоуровневом классе и интерфейсных типах, которые не являются public и это не суперкласс или суперинтерфейс, соответственно, a public введите, влияйте только на типы в пределах пакета, в котором они объявляются. Такие типы могут быть удалены или иначе изменены, даже если несовместимости иначе описываются здесь, при условии, что двоичные файлы, на которые влияют, того пакета обновляются вместе.

13.4 Развитие Классов

13.4.1 abstract Классы

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

13.4.2 final Классы

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

13.4.3 public Классы

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

13.4.4 Суперклассы и Суперинтерфейсы

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

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

Например, предположите что следующая тестовая программа:

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

h

class Super { char s = 's'; }

Это поучительно, чтобы рассмотреть то, что могло бы произойти без шага проверки: программа могла бы работать и печать:

s

Урок - то, что реализация, которая испытывает недостаток в верификаторе или сбоях, чтобы использовать это, не будет поддерживать безопасность типов и, поэтому, не допустимая реализация.

13.4.5 Тело класса и Задействованные Объявления

Удаление элемента класса или конструктора, который не объявляется 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.Identifier

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

hello from Hyper

13.4.6 Доступ к Элементам и Конструкторам

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

Так, например, если пакет points определяет класс Point:

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

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

Test

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

13.4.7 Полевые Объявления

Примите ссылку на поле f с квалификацией типа T. Предположите далее, что f является фактически экземпляром (соответственно static) поле, объявленное в суперклассе T, S, и что тип f X. Если новое поле типа X с тем же самым именем как f добавляется к подклассу S, который является суперклассом T или T непосредственно, то ошибка редактирования может произойти. Такая ошибка редактирования произойдет, только если, в дополнение к вышеупомянутому, любому из следующих условий содержите:

• Новое поле менее доступно чем старое.
• Новое поле является a static (соответственно экземпляр) поле.

Таким образом компилируя и выполняя код:

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);
	}
}

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

13.4.8 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 { final static char s = 'b'; }

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

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

Если пример:

class Flags { final static 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 { final static boolean debug = false; }

debug is true

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

Это поведение не изменилось бы если Flags были изменены, чтобы быть интерфейсом, как в измененном примере:

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 требуется, лучший выбор состоит в том, чтобы объявить a private 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 final поля, у которых есть постоянные величины (ли из примитивных или String введите), никогда должно казаться, не имеет начальное значение по умолчанию для их типа (§4.5.5). Это означает, что все такие поля, кажется, инициализируются сначала во время инициализации класса (§8.3.2.1, §9.3.1, §12.4.2).

13.4.9 static Поля

13.4.10 transient Поля

13.4.11 Метод и Объявления Конструктора

Примите ссылку на метод м. с квалификацией типа T. Предположите далее, что м. является фактически экземпляром (соответственно static) метод, объявленный в суперклассе T, S. Если новый метод типа X с той же самой подписью и типа возврата как м. добавляется к подклассу S, который является суперклассом T или T непосредственно, то ошибка редактирования может произойти. Такая ошибка редактирования произойдет, только если, в дополнение к вышеупомянутому, любому из следующих условий содержите:

• Новый метод менее доступен чем старый.
• Новый метод является a static (соответственно экземпляр) метод.

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

13.4.12 Метод и Параметры Конструктора

13.4.13 Тип Результата метода

13.4.14 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();
}

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

Удаление final модификатор от метода не повреждает совместимость с существующими ранее двоичными файлами.

13.4.16 native Методы

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

13.4.17 static Методы

13.4.18 synchronized Методы

13.4.19 Метод и Броски Конструктора

13.4.20 Метод и Тело Конструктора

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

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

Вообще мы предлагаем, чтобы реализации использовали последний ограниченный (время выполнения) генерация кода и оптимизация.

13.4.21 Метод и Конструктор, Перегружающийся

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

Если пример программы:

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

13.4.22 Переопределение метода

13.4.23 Статические Инициализаторы

13.5 Развитие Интерфейсов

13.5.1 public Интерфейсы

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

13.5.2 Суперинтерфейсы

13.5.3 Интерфейсные Элементы

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

Если пример программы:

interface I { void hello(); }
class Test implements I {
	public static void main(String[] args) {
		I anI = new Test();
		anI.hello();
	}
	public void hello() { System.out.println("hello"); }
}

hello

interface I { }

13.5.4 Полевые Объявления

13.5.5 Абстрактные Объявления метода