Кастинг Java представляет наверху? Почему?

Например, предположим, что у нас есть массив объекта [], где каждый элемент может иметь другой тип. Но мы всегда знаем, что, скажем, элемент 0 - двойной, элемент 1 - это строка. (Я знаю, что это неверный дизайн, но давайте просто предполагаем, что я должен был сделать это.)

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

Является ли информация типа Java, все еще сохранена во время выполнения? Или все забыто после компиляции, и если мы сделаем (дважды) элементы [0], мы просто будем следовать указатель и интерпретировать эти 8 байтов в виде двойного, что бы то ни было?

Некоторая информация содержится во время выполнения , но не статические типы отдельных элементов. Вы можете сказать это от поиска формата файла класса.

Теоретически возможно, что компилятор JIT может использовать «анализ Escape», чтобы устранить ненужные проверки типа в некоторых заданиях. Тем не менее, делать это со степенью, которую вы предлагаете, будут за пределами реалистической оптимизации. Выплата анализа типов отдельных элементов будет слишком маленьким.

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

Я не могу использовать конструктор «int length» для StringBuilder , так как длина CLOB превышает int и ему необходимо значение long .

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

Если фактическая длина CLOB меньше Integer.MAX _ VALUE , просто переместите long в int , поставив перед ним (int) .

Вместо выполнения файла .reg необходимо внести изменения в реестр с помощью функциональных возможностей, предусмотренных в пространстве имен Microsoft.Win32 .

Довольно просто создать раздел реестра с помощью этого API:

RegistryKey key = Registry.CurrentUser.CreateSubKey("Names");
key.SetValue("Name", "Isabella");
key.Close();

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

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

Для разумной реализации Java:

Каждый объект имеет заголовок, содержащий, среди прочего, указатель на тип среды выполнения (например, Double или Последовательностей , но никогда не может быть CharSequence или AbstractList ). Предполагая, что компилятор среды выполнения (как правило, HotSpot в случае Sun) не может определить тип статически, некоторая проверка должна быть выполнена сгенерированным машинным кодом.

Сначала необходимо прочитать указатель на тип среды выполнения. Это в любом случае необходимо для вызова виртуального метода в подобной ситуации.

Для приведения к типу класса точно известно, сколько суперклассов существует, пока вы не нажмете java.lang.Object , так что тип может быть считан с постоянным смещением от указателя типа (фактически первые восемь в HotSpot). Опять же, это аналогично считыванию указателя метода для виртуального метода.

Тогда считанное значение просто требует сравнения с ожидаемым статическим типом приведения. В зависимости от архитектуры набора команд другая команда должна перейти (или выйти из строя) на неправильную ветвь. ISA, такие как 32-разрядные ARM, имеют условную инструкцию и могут иметь возможность прохождения печального пути через счастливый путь.

Интерфейсы являются более сложными из-за множественного наследования интерфейса. Как правило, последние две операции с интерфейсами кэшируются во время выполнения. В САМЫЕ ранние дни (более десяти лет назад),интерфейсы были немного медленными, но это уже не актуально.

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

Инструкция по байтому коду для выполнения кастинга во время выполнения называется Checkcast . Вы можете разобрать код Java с использованием Javap , чтобы увидеть, какие инструкции генерируются.

Для массивов Java хранит информацию во время выполнения. Большую часть времени компилятор будет для вас ошибок типа, но есть случаи, когда вы столкнетесь с ArrayStoreexception при попытке хранить объект в массиве, но тип не совпадает (и Компилятор не поймал его). SPEC Java Language Spec дает следующий пример:

class Point { int x, y; }
class ColoredPoint extends Point { int color; }
class Test {
    public static void main(String[] args) {
        ColoredPoint[] cpa = new ColoredPoint[10];
        Point[] pa = cpa;
        System.out.println(pa[1] == null);
        try {
            pa[0] = new Point();
        } catch (ArrayStoreException e) {
            System.out.println(e);
        }
    }
}

точка [] PA = CPA действительна с окрашенной точки - это подкласс точки, но PA [0 ] = Новая точка () недействительна.

Это противостоит универсальным типам, где нет информации о типах, хранящихся во время выполнения. Компилятор вставки Checkcast Инструкции, где это необходимо.

Эта разница в печати для общих типов и массивов делает его часто неподходящими для смешивания массивов и универсальных типов.