NoSuchFieldError: org.jline.nativ.Kernel32.INVALID_HANDLE_VALUE

[hohwille]

If I run jline on Windows on ARM powered CPU (Snapdragon X1P-42-100), I get flooded with this exception for every progress bar powered by jline:

Exception in thread "WindowsStreamPump" java.lang.NoSuchFieldError: org.jline.nativ.Kernel32.INVALID_HANDLE_VALUE
        at org.jline.terminal.impl.jni.win.NativeWinSysTerminal.processConsoleInput(NativeWinSysTerminal.java:210)
        at org.jline.terminal.impl.AbstractWindowsTerminal.pump(AbstractWindowsTerminal.java:464)
        at [email protected]/java.lang.Thread.runWith(Thread.java:1588)
        at [email protected]/java.lang.Thread.run(Thread.java:1575)
        at org.graalvm.nativeimage.builder/com.oracle.svm.core.thread.PlatformThreads.threadStartRoutine(PlatformThreads.java:832)
        at org.graalvm.nativeimage.builder/com.oracle.svm.core.thread.PlatformThreads.threadStartRoutine(PlatformThreads.java:808)

I used GraalVM native image but will also continue giving feedback about this error in JVM mode, etc.
To me it seems the problem is not related to the GraalVM native image but to the JNI invocation driven by jline.

[hohwille]

Kind of good news. This "bug" has nothing to do with ARM CPU.
It just was introduced to all platforms with the update of jline from 3.24.1 to 3.28.0
See: devonfw/IDEasy@2dcf8e3

[hohwille]

Just to clarify: The issue also happens when we run our application with regular JVM on the console. So it is not related to the fact that we ship our software with GraalVM that has limited reflection capabilities. The "error" also occurs without GraalVM being involved at all.
We use this library to render a progress bar based on jline and that is causing the exception being logged:

<dependency>
  <groupId>me.tongfei</groupId>
  <artifactId>progressbar</artifactId>
  <version>0.10.1</version>
</dependency>

[gnodet]

This is probably caused by 0de32ab.
However, this maybe means that progressbar needs to be rebuilt on top of a recent JLine ?

[hohwille]

This is probably caused by 0de32ab. However, this maybe means that progressbar needs to be rebuilt on top of a recent JLine ?

Thanks for the response. Makes sense. So I will try to create an issue in the progressbar lib and users need to know that they need to update both libs if they use it in combination.