Описание: Как шутят программисты, не бывает приложений без багов – бывают недостаточно протестированные. Любые Java-фреймворки, любая JDK от любого вендора, любые ОС и железо могут содержать различные баги, от чего ваше, пусть даже идеально написанное, Java-приложение может страдать различными спецэффектами. Компания Oracle, а точнее, её Java-подразделение пытается свести риски от этих спецэффектов к минимуму: регулярно выпускать апдейты, при этом тщательно следя за мультиплатформенностью, безопасностью, совместимостью, производительностью и т.д., а также, в особо тяжёлых случаях, втыкая в JDK специальные костыли, обходящие баги в ваших OC и железе. Поэтому апдейты платформы необходимы.

Процесс обновления Java пользователем выглядит обычно довольно просто: новая версия Java качается с сайта Oracle или OpenJDK и просто ставится вместо предыдущей. Более того, экосистема платформы устроена так, что позволяет с относительной лёгкостью сменить вендора Java! Но что за этим стоит?

Что мы, Java Platform Group, для этого делаем и сколько усилий тратим? Как вообще устроен процесс изменений платформы Java? Какие изменения допускаются в апдейтах (7u17 -> 7u21), а какие – в новой версии платформы (Java7 -> Java 8)? По какому принципу нумеруются апдейты внутри одной версии? Зачем пользователям нужно обновлять старые версии платформы (Java 5, Java 6)? Какие процессы и инструменты помогают инженерам Oracle управлять изменениями в платформе? Какие гарантии даёт Oracle, если вы используете Java от других вендоров (OpenJDK, IcedTea, Azul, Excelsior, IBM, SAP и др.)? Обо всё этом вы узнаете из моего доклада.

Тип выступления: Доклад (50 минут)