Я хорошо знаком с .NET и знаю, что исправления и обновления являются взаимоисключающими для версий фреймворка (1.x), (2.x / 3.x) и (4.x). Такое разделение позволяет легко понять зависимости.
Какая логика или разделение применяется к применению обновлений Java? Когда мне это делать, а когда нет?
Многие известные версии приложений, которым требуется определенная версия java, обычно включают эту версию двоичных файлов java в свое приложение, и запуск ее является разновидностью <-lots -of -switches>.
В приведенном выше случае обновление общего / общесистемного / стандартного java обычно не влияет на приложение с его собственными двоичными файлами java. С другой стороны, вы также можете не знать, что версия java для конкретного приложения (с известной уязвимостью) существует, когда вы обновляете системную Java по умолчанию, если только вы не измеряете ее и не составляете отчет с помощью приложения для инвентаризации программного обеспечения.
Как всегда, ответ - «зависит от обстоятельств».
Если вы потребитель и исправление связано с безопасностью, сделайте это сейчас.
Если вы являетесь предприятием и используете сервер приложений, и в деталях патча не упоминается уязвимость безопасности, с которой вы, вероятно, столкнетесь (пользователь, запускающий вредоносное приложение JNLP), вы можете воздержаться. Если «патч» добавляет новые функции, такие как Java 1.6.0 с обновлением 10 (обновление N), возможно, вы можете подождать.
В целом обновления определенной версии Java (1.4.2, 5, 6, 7) должны быть стабильными по API и нормально обновляться, но в зависимости от того, что ваше приложение делает с java, вам может потребоваться протестировать или отложить.
Например, недавно Oracle изменила некоторые метаданные о виртуальной машине HotSpot в патче, что привело к сбою Eclipse IDE.
В 99 случаях из 100 патчи Java должны быть стабильными по API и иметь неразрывные изменения.
Незначительные обновления обычно представляют собой исправления ошибок и обновления безопасности, поэтому их следует применять всегда. Это особенно важно для любых виртуальных машин Java, которые взаимодействуют с внешним миром (веб-сервисами и клиентами). Основные обновления (от 1.5 до 1.6, от 1.6 до 1.7) обычно обратно совместимы с более ранними версиями. Это то, в чем Java была действительно надежна с момента ее создания.
Прямая совместимость обычно является основной проблемой, и приложения или платформы (например, Eclipse, Tomcat), которые зависят от новых функций Java (например, универсальные шаблоны Java 5, аннотации Java 6, лямбда-выражения Java 8), как правило, будут определять решение для основных обновления платформы в нашем магазине. В качестве одного из примеров вы можете обнаружить, что клиенты Java 6 внезапно не могут получить доступ к некоторым веб-сайтам HTTPS за последние несколько месяцев из-за ответа на logjam уязвимость SSL, что побудило многих веб-администраторов обновить свои сертификаты SSL до 2048-битных ключей, размер ключа Java 6 не поддерживает, но поддерживает Java 7 и 8.
В прошлом, как правило, было от трех до пяти лет, когда обычно использовались две или три различные основные версии Java, пока какая-то критическая функция, такая как перечисленные выше, не побудила перейти к более новой версии.
Наша среда разработки по-прежнему ориентирована на Java 6 там, где это необходимо (для старых клиентов OS X), Java 7 для новой разработки и Java 8 для нашей серверной среды. По сути, нам нужна стабильная производственная среда, основанная на Java 8, прежде чем мы начнем полагаться на возможности Java 8 в нашей среде разработки. Обратная совместимость Java дает нам много времени, чтобы совершить этот переход.
Я считаю, что для Java 6 отсутствие поддержки 1024DH - это гвоздь в гроб.