Міркування щодо версії Java для запуску у виробництві

Деякі люди користуються надзвичайними кромками технологій - оновлюючи день того, що щось оновлюється. У виробництві це не так доречно.

Дослідження того, чи готова до виробництва поточна (Java 7) версія, створює значну кількість старого матеріалу, який більше не може бути правильним (на момент написання цього Java 7 вже півтора року, що здається досить довгим) .

Які міркування потрібно зробити, щоб визначити, чи доцільно оновити виробниче середовище до більш пізньої версії Java?

Перше запитання - "Чи підтримується версія Java на машині?" Під час оновлення JRE - це одне, можливо, основна ОС не підтримується, запускаючи нову версію Java (підтримувані сертифікати та контракти на підтримку тощо), що люблять мати багато корпоративних середовищ).

Багато виробничих середовищ Java фактично працюють над сервером додатків . Це був би наступний розгляд. Порівняння у Вікіпедії серверів додатків Java EE показує, яка версія Java EE підтримується. Це можна побачити в огляді сумісності JavaEE Oracle . Тестована конфігурація для JBoss Enterprise Application Platform 6 відповідає Java SE 6.0 оновлення 6u30. Оновлення Java 6.0 оновлення 6u30 Java SE також є тестованою конфігурацією для сервера додатків JBoss 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. Оновлення версії повинно супроводжуватися певним навчанням у нових мовних структурах.