Почему компилируемая java не пересылается вперёд

Если я не понимаю, как работает JVM, это не байт-код Java, такой же, как и скомпилированный C, за исключением того, что он работает на JVM в отличие от ОС (JVM, действующий как ОС)?Почему компилируемая java не пересылается вперёд

Если это так, не означает ли это, что новые банки должны иметь возможность запускать любую версию JVM, которую я хочу?

Или существует какая-то разница в действительных инструкциях байт-кода между версиями Java, которые не существуют в таких вещах, как C?

источник

2015-07-30 Epicblood

«новые банки должны иметь возможность запускать любую версию JVM, которую я хочу». Не было бы это совместимо с передовым? –

@PaulBellora, если я ошибаюсь, передовая совместимость означает, что старые банки все еще могут работать на новом jvm, нет? – Epicblood

Если я кодирую и компилирую программу с использованием C++ 14, вы бы сказали, что она обратно совместима, поскольку она будет работать в любой системе, независимо от версии (я думаю) – Epicblood

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

Когда новая версия java представила новый байт-код, естественно, более старые версии VM не смогут интерпретировать этот байт-код.

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

Это отличается от C/C++. Компилятор для такого языка генерирует байт-код для точного процессора, на который вы нацеливаетесь. Набор команд для процессора не изменится, он статичен. Таким образом, при компиляции C для конкретного CPU каждая версия стандарта C/C++ будет компилироваться и запускаться, если есть инструкция, соответствующая требуемой операции.

Редактировать: Эта проблема также проявляется в C/C++, когда вы смотрите внимательно. Например, заголовок <cstdint> вводит факультативно типов, например. int64_t. Это по причине прямой совместимости. Старые чипы, возможно, не смогут обрабатывать 64-битные целочисленные типы, поэтому для обеспечения совместимости с ними для них стандарт делает их необязательными для объявления.

источник

2015-07-30 01:29:09 WorldSEnder

Итак, JVM больше относится к процессору, а не к ОС? – Epicblood

@Epicblood, да. Он выполняет байт-код, то же самое, что делает процессор. Но большинство процессоров используют общий набор инструкций (например, x86), поэтому JVM не должен настраивать таргетинг на каждый процессор. Было бы быстрее и эффективнее делать это, хотя – WorldSEnder

ОК, то есть были ли я смущены, спасибо. – Epicblood

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

Кроме того, из вашего вопроса, (как надуманный например) код скомпилирован с gcc для предназначаться для Intel Pentium с -march=586 (вероятно) не будет работать на 486 или 386 (в отличие от -mtune).

источник

2015-07-30 01:24:49

В вашем примере несовместимость возникает из языкового уровня? или потому, что архитектура пентий отличается? Потому что из моего понимания (может быть неправильно), но позволяет сказать, что я что-то кодирую и компилирую с помощью C++ 14, он будет работать на любой версии C++, поскольку фактические инструкции одинаковы. – Epicblood

@TimBiegeleisen В виде байтового кода? Я думаю, что это (в основном) работает.Я могу придумать несколько изменений, которые не были обратно совместимы (но использование файла jar с разумным интерфейсом, который не выполняет манипуляции с байт-кодом, обычно работает). –

@Epicblood Архитектура JVM * может * (и ** иногда ** * делает *) меняться между релизами. –

Почему компилируемая java не пересылается вперёд

ответ

Смежные вопросы