java - 为什么 .headless 默认为 True？

Question

问题设置

这个问题有几个变化的部分，所以我会尽力以最简单的形式重现这个问题。

我正在尝试将 TrayIcon 添加到 SystemTray。这通常是操作系统(“平台”)上的一个非常简单的目标 support电话(这将在几分钟后发挥不可或缺的作用)。

我目前正在为 Windows 机器编程并在 Windows 机器上编程(这不是关于互操作性的问题)。

这是我得到的有效代码背后的逻辑:

public class SomeClass {

    public static void main(String[] args) {

        if(SystemTray.isSupported()) {
            // DO SOMETHING TO ADD AN ICON
        }
    }
}

有了它的所有内含物，这个就可以了。然而，我真正追求的是能够注入(inject) SystemTray 实例，其图标已经“准备就绪”。

这段代码看起来有点像这样:

public class SomeClass extends NecessarySpringExtension {
    private @Setter(onMethod=@_@Resource(name="SystemTrayControl"))) SystemTrayControl systemTrayControl;
    // The above uses Lombok, as well.

    public static void main(String[] args) {
        // DO SOME RELATED STUFF like setting the configurations for
        // for the application
    }
}

资源返回 SystemTrayControl 类的一个实例 (@Bean)，它本身调用 SystemTray；但是，现在不再支持 SystemTray(请参阅下面的问题 部分中的一些解释)。

一些变化细节

这是其中一些代码的片段(很明显，我已经被这个问题淹没了。如果上下文需要扩展，请告诉我。我相信以下代码应该足以让您了解结构):

SystemTrayControl 类:

@PostConstruct
    public void showIcon() {

        if (SystemTray.isSupported()) {
            val tray = SystemTray.getSystemTray(); ....

资源类:

@Configuration
public class BeansForNeeds {

    @Bean
    public SystemTrayControl systemTrayControl() {
        return new SystemTrayControl():
    } ....

为了更多上下文:如果我删除在 SystemTrayControl 类中看到的条件，我会得到一个 HeadlessException (我已经做了一些阅读)。

问题

问题源于这样一个事实，即在您的程序中使用 SpringApplicationBuilder 时，.headless 属性默认为 true。 javadoc 指出:

Sets if the application is headless and should not instantiate AWT. Defaults to true to prevent java icons appearing

如果我手动将该属性设置为false，那么应用程序运行良好；然而，我总是有点“不稳定”地覆盖默认行为，特别是如果“阻止”x、y 或 z 的语言混入其中。

所以，问题是:

为什么该属性默认为 true？允许 .headless 禁止的行为有什么副作用？它有什么反对 AWT 的？

Answer 1

曾几何时，在像没有 X 的 Unix 这样真正的 headless 机器上引入 AWT 类(和 native 的东西)会导致运行时异常和其他讨厌的操作系统级故障。而且这些错误只会在加载类后发生，因此它可能具有轻微的不确定性。

我记得那是在 Java 6 左右。从那以后情况可能发生了变化。而且我认为重要的是，这只是 AIX Java 的问题，它是一个不基于 Sun 引用实现的洁净室 Java。不过，严格这不是错误，因为当我查看每个引用实现的代码时，引用实现只是错误地避开了同样的问题。

在我的案例中，我们必须小心处理一些启动代码，以免在接触 AWT 时意外使用方便的实用程序类，因为那样的话所有这些都会被拉入，并在遇到丢失的 native UI 时崩溃。这在 Windows 上永远不会发生，因为 Windows 已经进行了大量开发。但是，一旦部署在真正的 headless AIX 机器上，该应用程序就会严重失败，并出现运行时异常，该异常会直接冒泡给用户。

这是因为我们有“客户端”代码(表面上是 headless 的，不依赖于任何 UI 代码)和“UI”代码(知道如何与命令行或完整的 Swing GUI 交互。 ) 客户端代码已更改，因此它引入了一些方便的实用程序类(我忘了是哪个)，但这导致 VM 引入了一些其他类，这些类引入了 AWT，它命中了一些 native 代码，期望有一个 native UI某种形式。

由于 AIX 机器没有 X，这些本地组件不存在，整个事情因翻译的本地/运行时异常而分崩离析。

因此，我们不仅必须 headless 运行 VM，还必须确保我们的代码不会意外地直接或间接引用任何 AWT 代码。

我想做更多的研究来了解这个场景如何与这里讨论的属性交互，但对我来说关键的收获是跨平台意味着跨平台!而“ headless ”在不同平台上可能意味着非常具体的东西。