3

I'm trying to solve a problem with my Java project and one of the possible solutions is to change jdk.io.File.enableADS to TRUE in system properties. But, i don't know how to change it.

I'm also working in a project that uses jhipster and undertow. My project builds with no error, generating the connection link, but when I try to connect the page it doesn't load and the application shows the error:

java.lang.NoClassDefFoundError: Could not initialize class org.xnio.conduits.Conduit

I've looked at the code, found the line that throws the error and I saw in many blogs people telling to change the config above the text.

I'm using the JDK 11.0.15

This is the code that throws the error:

 try {
    if (osName.contains("windows")) {
         return new FileOutputStream("NUL:").getChannel();
    } else {
         return new FileOutputStream("/dev/null").getChannel();
    }
} catch (FileNotFoundException e) {
    throw new IOError(e);
}
Michail Alexakis
  • 1,405
  • 15
  • 14
Paulo Henrique Neves
  • 43
  • 1
  • 5
  • 2
    "I'm working on a problem. I found a solution but it doesn't work". This is not a question we can answer in any form, without knowing what either the problem or the proposed solution is. – Silvio Mayolo May 16 '22 at 15:40
  • 1
    What about [How to set system property?](https://stackoverflow.com/questions/5189914/how-to-set-system-property) and similar questions? Do these help? – andrewJames May 16 '22 at 16:00
  • Sorry about the lack of details, I changed the problem explanation. – Paulo Henrique Neves May 16 '22 at 16:34

2 Answers2

7

It seems you're running into this problem: Java: FileOutputStream("NUL:") not working after Java upgrade

The code you're referencing that is causing the problem is from https://code.yawk.at/org.jboss.xnio/xnio-api/3.8.4.Final/org/xnio/conduits/Conduits.java

    static {
        NULL_FILE_CHANNEL = AccessController.doPrivileged(new PrivilegedAction<FileChannel>() {
            public FileChannel run() {
                final String osName = System.getProperty("os.name", "unknown").toLowerCase(Locale.US);
                try {
                    if (osName.contains("windows")) {
                        return new FileOutputStream("NUL:").getChannel();
                    } else {
                        return new FileOutputStream("/dev/null").getChannel();
                    }
                } catch (FileNotFoundException e) {
                    throw new IOError(e);
                }
            }
        });
    }

I've looked at the sources for this release (3.8.4) and the most recent release on maven central (3.8.7): https://mvnrepository.com/artifact/org.jboss.xnio/xnio-api/3.8.7.Final

And there is some good news, it has been fixed in the latest release of xnio-api. The current code in version 3.8.7 is now as follows: (NUL: was replaced by NUL)

                    if (osName.contains("windows")) {
                        return new FileOutputStream("NUL").getChannel();
                    } else {
                        return new FileOutputStream("/dev/null").getChannel();
                    }

So if it's possible i would suggest you try to upgrade your dependency so that xnio-api-3.8.7.Final.jar is used.

Update 09-2022 Thanks to the comment of @NicolasRiousset, who found the following issue logged on jhipster's github, i have further traced this problematic dependency.

It starts with the optional dependency to spring-boot-starter-undertow, which in turn depends on undertow-core, and that depends on xnio-api from Jboss.

The earliest version that includes the fix (xnio-api-3.8.7) can be found in undertow-core 2.2.18.Final. The earliest version that uses this is spring-boot-starter-undertow 2.7.1.

And JHipster starts including spring-boot version >= 2.7.1 from jhipster-framework 7.9.0.

So upgrading to JHipster >= 7.9.0 should fix this problematic xnio-api dependency.

In case you don't strictly need undertow as your embedded web server, you can also switch (back) to spring-boot-starter-tomcat, since tomcat doesn't use the xnio-api.

Otherwise the mentioned system property should indeed also be a valid workaround for now. Since the code is statically loaded, i think you'll have to use VM arguments to include it in your program instead of using System.setProperty.

So add -Djdk.io.File.enableADS=true to your programs startup/command line. See for reference the following question that was mentioned in the comments: How to set system property?

It does also seem to be fixed in newer version of the Java runtime, so upgrading your JDK/JRE is also an option. According to the linked question at the top it's fixed in Java 8u333, and on my test system with Java 17.0.2 both versions of NUL also work.

slindenau
  • 1,091
  • 2
  • 11
  • 18
0

I ran into this same issue. I closed and reopened IntelliJ. Now it works. Worth trying before getting too deep down the rabbit hole.

Cody McCarty
  • 51
  • 6