我有一个使用Java 5编译的旧Web应用程序，由于各种原因，它不容易升级到更新版本的Java，并且目前在Java 5下运行。
我的问题是，使用较新版本的Java运行旧的Web应用程序（不使用较新的Java版本重新编译应用程序并假设这不会导致运行时错误）是否会以任何显着的方式缓解旧Java运行时的安全风险环境？
（我特别谈到与旧Java运行时环境相关的安全风险，我知道传递给较新的Java版本不会降低与XSS等相关的安全风险）。
通常，最好使Java运行时保持最新。当然，升级缓解的安全风险取决于应用程序。一个“Hello World！”应用程序可能不会受到影响，因为它没有安全要求，没有攻击向量，并且无论如何都不使用太多的运行时组件（攻击面）。
但是，Web应用程序通常在应用程序服务器上运行，该应用程序服务器可能会使用Java来实现其TLS。这意味着您的TLS实施很可能多年未收到升级。尽管与C阻止某些攻击相比，Java具有一些优势，但其他漏洞肯定会存在。例如，Heartbleed极不可能是一个问题，因为它依赖于缓冲区溢出，而Java有内部保护。 PKCS＃1 v1.5填充神谕可能适用，因为它取决于实际的实施。
由于Java可执行文件本身并没有特别容易被漏洞利用，它主要取决于服务器，库和应用程序的运行时类中使用的功能（按此顺序，服务器更有可能占用大量空间） ）。升级Java版本和服务器+库。某些实用程序库可能具有较低的优先级，具体取决于其功能，但请保持警惕。您不希望遇到漏洞，例如： Apache Commons Codec出现了一个问题。
更重要的是：为您的系统创建更新和升级策略并遵守它。测试量取决于您是否必须更新或升级系统;如果实施得当，您可以自动进行更新测试，并进行全面的升级测试。希望库使用语义版本控制，以便可以将更新与更新区分开来。
如果在较新版本上运行它不会导致运行时错误取决于应用程序;如果它的构建充分考虑了Java的可移植性，那么它很可能不会。但是，有可能滥用Java语言到它将失败的程度。例如，我看到一个应用程序从一个运行时崩溃到另一个运行时错误地实现了equals，而该元素保存在列表中。
对于这样一个旧的应用程序，我认为现在是时候进行全面测试，并可能进行代码审查，以评估兼容性问题是否属于主题。我已经顺利运行了Java 1.2应用程序，但如上所述，这取决于应用程序的编程方式。我肯定会将类（尽可能）重新编译为最新版本，兼容性和性能问题。
在转到Java 11之前，您可能首先想要迁移到Java 8（两者都是长期支持版本）。 Java 8已经过时了，但你可能想要做一个双重步骤因为你已经落后了。可能Java 8版本只是用于短期功能测试。
您可能已经需要获得Java安装许可，但我确保您也可以使用商业用途。对于Java 8和11，应该有一些值得细读的选项。
请注意，Java 10以后只有64位。我从其他供应商那里看过32位版本的Java 10，但是我不会升级到那些版本，因为你会把自己置于另一个角落里。