Соображения о том, какую версию Java запустить в Production

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

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

Какие соображения мне нужно сделать, чтобы определить, целесообразно ли обновить производственную среду до более поздней версии Java?

Первый вопрос, который нужно задать: «Поддерживается ли на компьютере версия Java?» Хотя обновление JRE - это одна вещь, возможно, базовая ОС не поддерживается в новой версии Java (поддерживаемые сертификаты и контракты на поддержку и т. П., Которые любят иметь многие корпоративные среды).

Многие производственные среды Java на самом деле работают поверх сервера приложений . Это будет следующим соображением. Сравнение серверов приложений Java EE из Википедии показывает, какая версия Java EE поддерживается. Это можно увидеть в обзоре совместимости Oracle с JavaEE . Протестированная конфигурация для JBoss Enterprise Application Platform 6 не соответствует Java SE 6.0 update 6u30. Java SE 6.0 update 6u30 также является протестированной конфигурацией для JBoss Application Server 7.1.0 Final . Они могут работать в Java 7, но они не являются проверенными конфигурациями.

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

Следующим по линии является структура . Одним из примеров этого является JAXB, который поставляется с Java и Spring, который использует его. Переход на Java 7 обновил JAXB, который генерировал код, который был несовместим с некоторыми фреймворками (что требует их обновления и обновления их зависимостей ...).

Инструменты сборки являются следующими в списке. Нужно убедиться, что среда сборки использует правильную версию Java. Написание кода для Java 7, но не обновление версии, используемой Maven или Ant, может вызвать проблемы. Есть моменты, когда сами инструменты сборки сильно привязаны к одной версии с определенными плагинами.

Инструменты тестирования . Такие вещи, как PMD, findbugs и checkstyle, могут не распознавать новые структуры в новой версии Java - они могут очень запутаться с инструкциями переключения строк или сложными перехватами. Инструменты, которые входят в инструментарий, такие как покрытие кода, могут не работать в новой JVM. В контексте Java 7 Cobertura и Emma не были обновлены до нового JRE (опять же, эти приложения изменяют байт-код, чтобы увидеть, какой код выполняется, а какой нет) (см. Библиотеки с открытым исходным кодом для jdk7 ). Это может потребовать изменения сценариев сборки для переключения с одного на другой.

Тогда есть IDE . Нужно обновить IDE до версии, которая знает о новых структурах в языке. Объявление Eclipse о поддержке Java 7 показывает эти проблемы.

Последний и, конечно, не в последнюю очередь это разработчик . Разработчик должен написать новый код и знать, как его можно реструктурировать. Начиная с Java 1.4 до 1.5, были представлены шаблоны и аннотации, и разработчикам потребовалось время, чтобы осознать наличие новых доступных структур. Точно так же коллекции переработаны в 1.2 и отвлекают разработчиков от использования HashTable и Vector. Обновление версии должно сопровождаться определенным обучением новым языковым структурам.