如何在Java 11中使用JDK而不需要JRE

70
我们计划将Java 8项目迁移至使用Java 11,但我注意到Java 11没有JRE文件夹。
在Java 9和Java 10中,文件夹结构发生了变化,即 java\jdk1.xjava\jre1.x,其中 x 是Java 9或10。
但是在Java 11中,我只得到一个文件夹,即 java\jdk-11。我的客户如何在没有 jre 的情况下使用我的应用程序?
我的理解是,Java 11正在强制模块化我们的应用程序,并且需要使用jlink创建我们自己的jre以在客户端运行应用程序。
我的理解正确吗?

5
Java 9+的目录结构与以前不同,但具备完整的JRE功能。例如,您可以看到JDK包含一个bin/java可执行文件(或bin/java.exe)。 - VGR
7
请参阅文档:Oracle JDK 迁移指南 - 部署。您不必使用模块系统。 - Jesper
4
JEP 220和JDK 9发布说明(特别是https://www.oracle.com/technetwork/java/javase/9-relnote-issues-3704069.html#JDK-8049367)详细介绍了运行时镜像结构的变化。 - Alan Bateman
6
为什么它被关闭为不相关主题?它似乎并没有要求离线资源,只是询问如何在没有JRE的情况下使用JDK。 - Didier L
3
类似问题:如何让Java 11运行环境工作,因为已经没有可下载的JRE 11了? - Basil Bourque
显示剩余3条评论
3个回答

98

在过去的20年里,JDK都会附带一个JRE,它只是其功能的一个子集,安装在系统中不同的目录下。

事实上,它附带了两个完全相同的JRE,一个安装在JDK安装目录内部,另一个则在外部。

这一直让我感到困惑,因为维护者这样做完全是在浪费精力,而且在安装在计算机上时,这个JRE只是复制了JDK已经能够完成的一些功能,也就是对硬盘空间的完全浪费。

终于,随着Java 11的到来,Oracle和OpenJDK团队决定结束这种愚蠢行为,仅分发单个东西:JDK。当安装此JDK时,它实际上比旧版JRE的大小还要小,甚至没有了需求将JRE用作具有有限磁盘空间设备的独立运行环境的论据。而这个论据本身并不能解释为什么单个JDK需要安装两个JRE,只是为了证明JRE作为JDK的简化运行环境的必要性。

因此,不再需要独立的JRE,并且很长一段时间以来都没有需要,更不用说将其作为JDK安装的一部分强制安装了。

而且,您不需要创建自己的JRE。只需在客户机上安装OpenJDK,并确保将$JAVA_HOME/bin添加到系统路径中,就像旧版JRE一样。

此外,有些旧版JRE安装程序将java*.exe文件放置在Windows目录树中,因此需要删除它们,还要删除一些JRE安装程序添加的奇怪条目的系统路径。


10
在早期版本中,jdk可以安装在任何地方,而“公共jre”必须安装在引导分区上。这纯粹是Sun发明的限制,因为实际上,浏览器插件或控制面板的注册并不需要这样做。较新版本取消了此限制,但仍将“public jre”作为单独的jre安装(我总是关闭此选项)。现在,这些功能已经消失了,所以这个不必要的东西变得更加不必要了。据我所知,您仍然可以通过使用jlink从JDK创建JRE,这归结为删除开发模块。 - Holger
2
@Holger 很好的观点。更奇怪的是,Sun在Windows下默认将JRE安装在“c:\program files”目录下,而如果安装在名称中带有空格的目录中,则无法正常工作 :) - jwenting
2
那么...不再需要JRE_HOME环境变量了吗? - David Ferreira
9
我认为 JRE 不再可用的实际原因是因为从 Java 9 开始(模块系统),应用程序需要作为一个自包含的单元发布,而不是依赖于外部可用的 JRE。 - Codebender
2
AdoptOpenJDK项目为Java 11提供JRE和JDK下载:https://adoptopenjdk.net/releases.html?variant=openjdk11#x64_win(参见@matsonkepson的回答)。这更加“愚蠢”吗? - mzjn
显示剩余6条评论

45

简述

没有jre,我的客户如何使用我的应用程序?

➥ 在你的基于Java的应用程序中捆绑一个Java实现。

了解:

详细内容

我的理解是Java 11强制我们将应用程序模块化

严格来说,不需要模块化。大多数现有的应用程序可以在Java 11中按原样运行。您可以继续在Java 11中开发而无需模块化代码。但是对于GUI桌面或移动应用程序,您需要在应用程序中打包一个JVM。模块化并使用jlink工具可能是最好的方法。相比之下,服务器端基于Servlet的应用程序或微服务服务器尚不需要模块化,但最好最终这样做。

我注意到Java 11没有JRE文件夹。

欧拉不再打算让最终用户安装JRE或JDK。浏览器中的Java Applets和应用程序交付中的Java Web Start都正在逐步淘汰,使最终用户不再需要JRE。基于Java的应用程序将预计捆绑自己的Java实现。唯一有意识安装JDK的人将是开发人员和服务器端系统管理员。

一些人对“Java Everywhere”的梦想的消失感到失望。他们可能会因为必须为每个主机操作系统(macOS、Linux、Windows等)制作应用程序版本而感到烦恼。另一方面,一些开发人员很高兴能够与他们的应用程序捆绑Java实现(现在比以往任何时候都小),因为这样可以省去最终用户下载-安装-更新系统范围的Java实现的麻烦。也消除了与公司IT部门争论在用户PC上安装Java的问题。并且将Java与应用程序捆绑简化了测试和支持,因为您可以确切地知道和控制涉及的Java版本和分发。顺便说一句,这种应用程序捆绑Java并不是很新:多年来,苹果在macOS和iOS应用商店中一直支持它。

重要:

下面是一个流程图,可以帮助您在各种提供Java 11实现的供应商中进行选择和决策。

Flowchart guiding you in choosing a vendor for a Java 11 implementation


Motivations in choosing a vendor for Java


1
将您所写的和jwenting所写的联系起来,我对Oracle的愿景的理解是:最终用户需要安装一个Java运行时作为他们想要执行的每个Java应用程序的一部分。开发人员需要为每个非服务器平台提供单独的应用程序安装程序,以便他们的应用程序能够运行;安装包括他们的应用程序和Java运行时。WORA(编写一次,随处运行)的RA部分现在比以前更加困难。 - Pixelstix
3
没错,除了最后一句话。一些开发人员很高兴将一个Java实现与他们的应用程序捆绑在一起(现在比以前小得多),因为这样可以消除最终用户下载-安装-更新系统范围内Java实现的麻烦。还可以避免让公司IT部门安装Java。而且将Java与应用程序捆绑在一起可以简化测试和支持,因为您知道并控制涉及的Java版本和分发版本。顺便说一句,在macOS和iOS应用商店中,苹果公司支持将Java与应用程序捆绑在一起已经有很多年了。 - Basil Bourque
1
考虑到企业的角度,事情确实更容易,特别是如果您采用应用商店模式进行更新。开发人员在道德上有义务发布新版本的应用程序,以确保它们配备最新的JRE而不会出现已知的安全漏洞。从更广泛的意义上讲,这对我来说就像是从Java作为平台转变为Java作为运行时,做出了一些权衡,其中一些权衡对某些人来说更好。 - Pixelstix
2
您只有在新的安全漏洞可能因为您的特定功能而影响到您的特定客户时,才需要更新应用程序以获取最新版本。如果您的应用程序不使用TLS,则无需更新TLS漏洞。同样适用于您可能作为应用程序依赖项包含的任何库。 JVM现在是您的应用程序中的一个(大型)依赖项。您的应用程序中的JVM仅由您的应用程序使用。 - Basil Bourque
2
@Pixelstix 我们确实同意。这无疑是从Java作为平台转向Java作为运行时的转变。是的,这其中存在一些权衡,有一些好处和一些不利因素。 - Basil Bourque

12

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接