NoSuchMethodError：< init>在com.sun.glass.ui.win.WinApplication.staticScreen_getScreens中 [英] NoSuchMethodError: <init> in com.sun.glass.ui.win.WinApplication.staticScreen_getScreens

问题描述

自升级到install4j 7.0.5和Java 10以来，在Windows上运行我们的应用程序的用户越来越频繁地报告应用程序抛出

Since upgrading to install4j 7.0.5 and Java 10, users that run our application on Windows more and more often report that the application throws

java.lang.NoSuchMethodError: <init>
    at javafx.graphics/com.sun.glass.ui.win.WinApplication.staticScreen_getScreens(Native Method)
    at javafx.graphics/com.sun.glass.ui.Screen.initScreens(Unknown Source)
    at javafx.graphics/com.sun.glass.ui.Application.lambda$run$1(Unknown Source)
    at javafx.graphics/com.sun.glass.ui.win.WinApplication._runLoop(Native Method)
    at javafx.graphics/com.sun.glass.ui.win.WinApplication.lambda$runLoop$3(Unknown Source)
    at java.base/java.lang.Thread.run(Unknown Source)


UiLauncher (WAITING)
    at java.base@10.0.1/jdk.internal.misc.Unsafe.park(Native Method)
    at java.base@10.0.1/java.util.concurrent.locks.LockSupport.park(Unknown Source)
    at java.base@10.0.1/java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(Unknown Source)
    at java.base@10.0.1/java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(Unknown Source)
    at java.base@10.0.1/java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(Unknown Source)
    at java.base@10.0.1/java.util.concurrent.CountDownLatch.await(Unknown Source)
    at platform/javafx.graphics@10.0.1/com.sun.javafx.tk.quantum.QuantumToolkit.startup(Unknown Source)
    at platform/javafx.graphics@10.0.1/com.sun.javafx.application.PlatformImpl.startup(Unknown Source)
    at platform/javafx.graphics@10.0.1/com.sun.javafx.application.PlatformImpl.startup(Unknown Source)
    at platform/javafx.swing@10.0.1/javafx.embed.swing.JFXPanel.initFx(Unknown Source)
    at platform/javafx.swing@10.0.1/javafx.embed.swing.JFXPanel.<init>(Unknown Source)
    at java.base@10.0.1/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
    at java.base@10.0.1/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
    at java.base@10.0.1/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
    at java.base@10.0.1/java.lang.reflect.Constructor.newInstance(Unknown Source)
    at java.base@10.0.1/java.lang.Class.newInstance(Unknown Source)
    at app//...

启动应用程序时虽然install4j创建了exe文件。通过反射创建javafx.embed.swing.JFXPanel实例来触发错误：

when starting the application though the install4j created exe file. The error is triggered by creating an instance of javafx.embed.swing.JFXPanel through reflection:

Class.forName("javafx.embed.swing.JFXPanel").newInstance();

我们目前怀疑由于某种原因加载了不兼容的DLL（glass.dll似乎包含原生的stacktrace中提到的方法。

We currently suspect that for some reason an incompatible DLL is loaded (glass.dll seems to contain the native method mentioned in the stacktrace).

有谁知道如何防止此错误？例如。是否有办法将通过install4j生成的exe执行应用程序时使用的java.library.path限制为嵌入在安装程序中并随应用程序本地安装的Java运行时环境？
根据一个用户，如果使用

Does anyone know how to prevent this error? E.g. is there are way to restrict the java.library.path used when executing the application through the install4j-generated exe to the Java runtime environment that was embedded in the installer and installed locally with the application? According to one user, the error does not occur if the application is started "manually" using the

java -jar app.jar

命令。所以似乎问题在于install4j创建的可执行文件。

command. So it seems the problem lies with the install4j created executable.

推荐答案

这个问题的解决方法似乎从您的系统％PATH％中删除所有glass.dll的出现。

The workaround to this problem seems to be to remove all occurences of "glass.dll" from your system %PATH%.

我认为必须在其他地方实施修复但是;无论是在Java运行时还是在Install4j代码中，都无法在实际应用程序的Java代码中实现：

I believe a fix must be implemented somewhere else, though; either in the Java runtime or in the Install4j code, but cannot be implemented in the Java code of the actual app:

由于某种原因，Install4j中的Java运行时版本会检查在查找库时捆绑JRE last 。在这种情况下，有问题的本机库是 glass.dll ，它应该包含所请求的< init> 方法，但是如果有的话在你的％PATH％中有一个较旧的，不兼容的 glass.dll 版本（例如来自之前的Java 8安装） ）该文件将加载更高的优先级，然后应用程序将本机崩溃。

For some reason the Java runtime version in Install4j checks the bundled JRE last when locating the libraries. In this case the problematic native library is glass.dll which should contain the requested <init> method but if anywhere in your %PATH% there is an older, incompatible version of glass.dll (e.g. from a previous Java 8 installation) that file will be loaded with a higher precedence and then the application will crash natively.

这是不应用程序代码中的问题（java代码），也不是捆绑JDK的问题，这是一个install-4j生成的exe文件（或内部Java可能）如何尝试解析本机dll的问题。首先应该检查捆绑的JRE目录，而不是首先检查所有路径元素。

This is not a problem in the code of the application (the java code), nor a problem with the bundled JDK, this is a problem of how the install-4j-generated exe files (or maybe Java internally) tries to resolve native dlls. Instead of checking all path elements first, it should be checking the bundled JRE directory, first.

使用Procmon，您可以看到它在路径中加载任意放置的 glass.dll 文件，首先：我添加了一个从JDK 1.8进入我的一个路径元素并得到了这个（加上崩溃）：

With Procmon you can see that it loads arbitrarily placed glass.dll files in the path, first: I added one from JDK 1.8 into one of my path elements and got this (plus the crash):

这篇关于NoSuchMethodError：< init>在com.sun.glass.ui.win.WinApplication.staticScreen_getScreens中的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！