Develop Reference

Wildfly org.jboss.nio -> FileNotFoundException: Invalid file path with Windows Java JDK 11.0.15+10

Since the update to Eclipse Tamurin JDK 11.0.15+10 we notice a problem as soon a HTTP request reaches Wildfly 20.0.1.Final. The same behaviour exsists in Wildfly 26.1.0.Final This only happens with the JDK Windows version, the Linux JDK works fine.
As it is an "Invalid file path" error, an OS dependent BUG seems possible.
Until now SAP Machine is the only JDK that does not encounter this failure.
I'm still not sure if this is a JDK or a Wildfly problem...
You can check that when opening the Wildfly Management Interface.
ERROR [io.undertow.request] (External Management Request Threads -- 1) UT005071: Undertow request failed HttpServerExchange{ GET /management}: java.io.IOError: java.io.FileNotFoundException: Invalid file path
at org.jboss.xnio#3.8.1.Final//org.xnio.channels.Channels$4.run(Channels.java:1103)
at org.jboss.xnio#3.8.1.Final//org.xnio.channels.Channels$4.run(Channels.java:1093)
at java.base/java.security.AccessController.doPrivileged(Native Method)
at org.jboss.xnio#3.8.1.Final//org.xnio.channels.Channels.<clinit>(Channels.java:1093)
at io.undertow.core#2.1.3.Final//io.undertow.io.UndertowOutputStream.write(UndertowOutputStream.java:231)
at io.undertow.core#2.1.3.Final//io.undertow.io.BlockingSenderImpl.writeBuffer(BlockingSenderImpl.java:245)
at io.undertow.core#2.1.3.Final//io.undertow.io.BlockingSenderImpl.writeBuffer(BlockingSenderImpl.java:238)
at io.undertow.core#2.1.3.Final//io.undertow.io.BlockingSenderImpl.send(BlockingSenderImpl.java:75)
at io.undertow.core#2.1.3.Final//io.undertow.io.BlockingSenderImpl.send(BlockingSenderImpl.java:107)
at org.jboss.as.domain-http-interface#12.0.3.Final//org.jboss.as.domain.http.server.DomainUtil.writeResponse(DomainUtil.java:89)
at org.jboss.as.domain-http-interface#12.0.3.Final//org.jboss.as.domain.http.server.DomainApiHandler$1.doSendResponse(DomainApiHandler.java:177)
at org.jboss.as.domain-http-interface#12.0.3.Final//org.jboss.as.domain.http.server.ResponseCallback.sendResponse(ResponseCallback.java:32)
at org.jboss.as.domain-http-interface#12.0.3.Final//org.jboss.as.domain.http.server.DomainApiHandler.handleRequest(DomainApiHandler.java:232)
at io.undertow.core#2.1.3.Final//io.undertow.server.handlers.encoding.EncodingHandler.handleRequest(EncodingHandler.java:72)
at org.jboss.as.domain-http-interface#12.0.3.Final//org.jboss.as.domain.http.server.DomainApiCheckHandler.handleRequest(DomainApiCheckHandler.java:91)
at org.jboss.as.domain-http-interface#12.0.3.Final//org.jboss.as.domain.http.server.security.ElytronIdentityHandler.lambda$handleRequest$0(ElytronIdentityHandler.java:62)
at org.wildfly.security.elytron-private#1.12.1.Final//org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:328)
at org.wildfly.security.elytron-private#1.12.1.Final//org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:285)
at org.jboss.as.controller#12.0.3.Final//org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:254)
at org.jboss.as.controller#12.0.3.Final//org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:225)
at org.jboss.as.domain-http-interface#12.0.3.Final//org.jboss.as.domain.http.server.security.ElytronIdentityHandler.handleRequest(ElytronIdentityHandler.java:61)
at io.undertow.core#2.1.3.Final//io.undertow.server.handlers.BlockingHandler.handleRequest(BlockingHandler.java:56)
at io.undertow.core#2.1.3.Final//io.undertow.server.Connectors.executeRootHandler(Connectors.java:370)
at io.undertow.core#2.1.3.Final//io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:830)
at org.jboss.threads#2.3.3.Final//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
at org.jboss.threads#2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
at org.jboss.threads#2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
at org.jboss.threads#2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1348)
at java.base/java.lang.Thread.run(Thread.java:829)
at org.jboss.threads#2.3.3.Final//org.jboss.threads.JBossThread.run(JBossThread.java:485)
Caused by: java.io.FileNotFoundException: Invalid file path
at java.base/java.io.FileOutputStream.<init>(FileOutputStream.java:231)
at java.base/java.io.FileOutputStream.<init>(FileOutputStream.java:126)
at org.jboss.xnio#3.8.1.Final//org.xnio.channels.Channels$4.run(Channels.java:1098)
... 29 more
JDK
Works with Wildfly
Eclipse Tamurin
no
Amazon Coretto
no
Azul Zulu
no
Bellsoft
no
Oracle OpenJDK
no
Oracle JDK
no
SAP Machine
yes

This is an issue in the JDK. You can wait for JDK 11.0.16 or downgrade to a lower version like JDK 11.0.14.

This is caused by a known JDK bug. You can work around the issue by setting Djdk.io.File.enableADS system property. In Intellij go to Run -> Edit configurations and paste -Djdk.io.File.enableADS=true in VM Options field.

Tess4J 4.0.0 java.lang.UnsatisfiedLinkError: The specified module could not be found

Downloading and using tessData-best for tesseract-ocr github repository improved my accuracy for english on Tess4j 3.8.4 significantly. But to use that trainedData for other languages i had to upgrade to Tess4J 4.0.0. But When I did that its giving me following error on this line
TessBaseAPI api = TessAPI1.TessBaseAPICreate();
Exception in thread "main" java.lang.UnsatisfiedLinkError: The specified module could not be found.
at com.sun.jna.Native.open(Native Method)
at com.sun.jna.Native.open(Native.java:1759)
at com.sun.jna.NativeLibrary.loadLibrary(NativeLibrary.java:260)
at com.sun.jna.NativeLibrary.getInstance(NativeLibrary.java:398)
at com.sun.jna.Native.register(Native.java:1396)
at com.sun.jna.Native.register(Native.java:1156)
at net.sourceforge.tess4j.TessAPI1.<clinit>(TessAPI1.java:41)
at OCR.confidenceWord(OCR.java:106)
at OCR.processImg(OCR.java:381)
at test.main(test.java:10)
I have 64-bit windows 8.1 running on my machine with 64-bit JVM. I have VC++ 2015 redistributable installed. I checked in dependency walker and no dll seems to be missing.By setting system property "jna.debug.load" to "true", I can see it properly looks for and gets "libtesseract400" at temp folder. Has anyone been able to solve this error?

OpenGL Error with Executable .JAR (Architecture Word Mismatch?)

I've created an OpenGL-based application using Java, JOGL and Maven. I'm using Arch Linux for ARM on a 32-bit machine. When I build the project from within my development environment, the application loads and executes successfully.
When I use maven-assembly-plugin to generate a JAR which houses both my compiled application code and all of it's dependencies, the executable JAR terminates before it's able to establish an OpenGL context, with an error I've never seen before:
Java HotSpot(TM) Server VM warning: You have loaded library /tmp/jogamp_0000/file_cache/jln5003285820939498405/jln7050454496148437271/libgluegen-rt.so which might have disabled stack guard. The VM will try to fix the stack guard now.
It's highly recommended that you fix the library with 'execstack -c <libfile>', or link it with '-z noexecstack'.
Exception in thread "main" java.lang.UnsatisfiedLinkError: /tmp/jogamp_0000/file_cache/jln5003285820939498405/jln7050454496148437271/libgluegen-rt.so: /tmp/jogamp_0000/file_cache/jln5003285820939498405/jln7050454496148437271/libgluegen-rt.so: wrong ELF class: ELFCLASS64 (Possible cause: architecture word width mismatch)
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1941)
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1824)
at java.lang.Runtime.load0(Runtime.java:809)
at java.lang.System.load(System.java:1086)
at com.jogamp.common.jvm.JNILibLoaderBase.loadLibraryInternal(JNILibLoaderBase.java:575)
at com.jogamp.common.jvm.JNILibLoaderBase.access$000(JNILibLoaderBase.java:63)
at com.jogamp.common.jvm.JNILibLoaderBase$DefaultAction.loadLibrary(JNILibLoaderBase.java:95)
at com.jogamp.common.jvm.JNILibLoaderBase.loadLibrary(JNILibLoaderBase.java:459)
at com.jogamp.common.os.DynamicLibraryBundle$GlueJNILibLoader.loadLibrary(DynamicLibraryBundle.java:421)
at com.jogamp.common.os.Platform$1.run(Platform.java:317)
at java.security.AccessController.doPrivileged(Native Method)
at com.jogamp.common.os.Platform.<clinit>(Platform.java:287)
at com.jogamp.opengl.GLProfile.<clinit>(GLProfile.java:146)
at com.jogamp.opengl.util.AnimatorBase.<clinit>(AnimatorBase.java:112)
at com.app.main(Main.java:123)
Do you have any idea what could be the issue? One thing that might be worth mentioning is that I use emulated graphics on this machine, so I depend upon software rasterization.

Why am I only able to successfully load dynamic linking libraries using "-Djava.library.path=" in Linux but not Windows

I am using a library that requires that I load load dynamic linking libraries. My source code that uses these libraries is identical, the only difference is the operating system that I am using and which version of the library (Windows-64 version or Linux-64 version) that I am using. The library I am using provides 1 set for Windows ".dll" files and 1 set for Linux ".so" files, each in its own folder. To load the Linux ".so" libraries, I do
"-Djava.library.path=/home/johnmichaelreed/Desktop/Dropbox/Moved_Netbeans_Projects/Crazy_Client/Libjitsi_linux_64/lib/native/linux-64"
in the VM options and everything works.
Then, when I copy and paste the directory where the Windows ".dll" native libraries are into the VM options, I get rid of the Linux libraries path and insert:
-Djava.library.path=C:\Users\JohnReedLOL\Desktop\Dropbox\Moved_Netbeans_Projects\Crazy_Client\Libjitsi_windows_64\lib\windows_native\windows-64
I then change the library JAR files to the ones that came with the Windows version of the Library and I run the program and I get this error:
SEVERE: Failed to register custom Renderer org.jitsi.impl.neomedia.jmfext.media.renderer.video.JAWTRenderer with JMF.
java.lang.UnsatisfiedLinkError: C:\Users\JohnReedLOL\Desktop\Crazy_Client\Libjitsi_windows_64\lib\windows_native\windows-64\jnawtrenderer.dll: Can't find dependent libraries
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1937)
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1855)
at java.lang.Runtime.loadLibrary0(Runtime.java:870)
at java.lang.System.loadLibrary(System.java:1119)
at org.jitsi.impl.neomedia.jmfext.media.renderer.video.JAWTRenderer.<clinit>(JAWTRenderer.java:90)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:260)
at org.jitsi.impl.neomedia.device.DeviceConfiguration.registerCustomRenderers(DeviceConfiguration.java:1034)
at org.jitsi.impl.neomedia.device.DeviceConfiguration.<init>(DeviceConfiguration.java:355)
at org.jitsi.impl.neomedia.MediaServiceImpl.<init>(MediaServiceImpl.java:150)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:408)
at java.lang.Class.newInstance(Class.java:438)
at org.jitsi.impl.libjitsi.LibJitsiImpl.getService(LibJitsiImpl.java:142)
at org.jitsi.service.libjitsi.LibJitsi.invokeGetServiceOnImpl(LibJitsi.java:163)
at org.jitsi.service.libjitsi.LibJitsi.getMediaService(LibJitsi.java:115)
at outermost_crazy.Libjitsi_Main.<init>(Libjitsi_Main.java:124)
at outermost_crazy.Libjitsi_Main.main(Libjitsi_Main.java:827)
The weird thing is I am 100% sure that the native library path is the right place because when I print it using System.getProperty("java.library.path"), I get the folder:
C:\Users\JohnReedLOL\Desktop\Dropbox\Moved_Netbeans_Projects\Crazy_Client\Libjitsi_windows_64\lib\windows_native\windows-64
^ This folder definitely has all 12 .dll files ^. The library JAR files that I am using are the ones the ones that came with these 12 ".dll" files, not the ones that came with the Linux ".so" files, so I am pretty sure that I am using the right JAR files. Why this is error only happening on Windows with the .dll files, but not on Linux with the .so files?
Dependency Walker opening of jnawtrenderer.dll:

Unity-Android _ CommandInvokationFailure: Unable to convert classes into dex format

i'm using Windows 7, jdk 1.8.0 (64bit), jre 8 (64bit), Unity Pro 4.3.4f1 and Android SDK 22.6.1
All are updated softwares.
All works fine but when i use StartApp sdk, this error comes. No extra plugin is used, only the SDK provided by the StartApp ad.
Error building Player: CommandInvokationFailure: Unable to convert classes into dex format. See the Console for details.
C:\Program Files\Java\jdk1.8.0\bin\java.exe -Xmx1024M -Dcom.android.sdkmanager.toolsdir="D:/android-sdks\tools" -Dfile.encoding=UTF8 -jar "C:/Program Files (x86)/Unity/Editor/Data/BuildTargetTools/AndroidPlayer\sdktools.jar" -
stderr[
UNEXPECTED TOP-LEVEL EXCEPTION:
java.lang.IllegalArgumentException: already added: Lcom/unity3d/player/a$1;
at com.android.dx.dex.file.ClassDefsSection.add(ClassDefsSection.java:122)
at com.android.dx.dex.file.DexFile.add(DexFile.java:161)
at com.android.dx.command.dexer.Main.processClass(Main.java:685)
at com.android.dx.command.dexer.Main.processFileBytes(Main.java:634)
at com.android.dx.command.dexer.Main.access$600(Main.java:78)
at com.android.dx.command.dexer.Main$1.processFileBytes(Main.java:572)
at com.android.dx.cf.direct.ClassPathOpener.processArchive(ClassPathOpener.java:284)
at com.android.dx.cf.direct.ClassPathOpener.processOne(ClassPathOpener.java:166)
at com.android.dx.cf.direct.ClassPathOpener.processDirectory(ClassPathOpener.java:229)
at com.android.dx.cf.direct.ClassPathOpener.processOne(ClassPathOpener.java:158)
at com.android.dx.cf.direct.ClassPathOpener.process(ClassPathOpener.java:144)
at com.android.dx.command.dexer.Main.processOne(Main.java:596)
at com.android.dx.command.dexer.Main.processAllFiles(Main.java:498)
at com.android.dx.command.dexer.Main.runMonoDex(Main.java:264)
at com.android.dx.command.dexer.Main.run(Main.java:230)
at com.android.dx.command.dexer.Main.main(Main.java:199)
at com.android.dx.command.Main.main(Main.java:103)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at SDKMain.main(SDKMain.java:129)
1 error; aborting
]
I already tried JAVA_OPT and JAVA_HOME solutions. But still couldn't solved

I ran into this using IntelliJ 13.1.4, JDK 1.6 but I would guess that this is caused by the same thing on any other IDE -> classes.jar is referenced/included more than once.
Check and make sure that the classes.jar you added to the project (from Unity\Editor\Data\PlaybackEngines\androidplayer\bin\classes.jar) isn't referenced/included more than once. If you go into File->Project Structure:
There should only be one "classes" under libraries.
There should be NO reference to classes under Artifacts (Artifacts is used to create the plugin .jar file.)
Check out this related answer ->
https://stackoverflow.com/a/8437996/3464367

My issue was actually related to having duplicate files. Well not really duplicates, but I had 2 adMob sdk packages (different versions), that were getting into conflict. After deleting the older one, everything was fixed. Are you using any 3rd party SDK's or something similar, if so, try removing them if possible and see if the issue persists. Try to find out which part of the code is causing this to happen. You could ultimately try to compile an empty project just for testing.

Today I solved similar problem of Error building Player: CommandInvokationFailure: Unable to convert classes into dex format. See the Console for details. with adding .jar file into Plugins\Android\
I got different kind of errors:
Caused by: com.android.dx.cf.iface.ParseException: bad class file magic (cafebabe) or version (0034.0000 ...
Caused by: com.android.dx.cf.iface.ParseException: class name (ht/stringing/test) does not match path (src/ht/stringing/test.class)
My result working solution was similar to this:
Code lives here:
verysimple\src\ht\stringing\test.java
I do:
> javac -classpath "c:\Android\sdk\platforms\android-15" ht\stringing\test.java
> jar cvf ..\dist\verysimple.jar ht\stringing\test.class
> copy ..\dist\verysimple.jar c:\ExUnityApp\Assets\Plugins\Android
Don't forget to compare your 'Minimum Api Level' in Player Setting. For me it was Android 4.0.3 ... (15)