Ability to silence fallback message

[md-5]

[ERROR] Terminal initialization failed; falling back to unsupported java.lang.NoClassDefFoundError: Could not initialize class org.fusesource.jansi.internal.Kernel32 at org.fusesource.jansi.internal.WindowsSupport.getConsoleMode(WindowsSupport.java:50) at jline.WindowsTerminal.getConsoleMode(WindowsTerminal.java:177) at jline.WindowsTerminal.init(WindowsTerminal.java:80) at jline.TerminalFactory.create(TerminalFactory.java:101) at jline.TerminalFactory.get(TerminalFactory.java:159) at jline.console.ConsoleReader.(ConsoleReader.java:227) at jline.console.ConsoleReader.(ConsoleReader.java:219) at jline.console.ConsoleReader.(ConsoleReader.java:207) at net.md_5.bungee.BungeeCord.(BungeeCord.java:157) at net.md_5.bungee.BungeeCord.main(BungeeCord.java:189)
Older JLine versions didn't display it, and I really don't want to either - users think something is wrong.

[jdillon]

NoClassDefFoundError sounds like a classpath issue, as this class should exist. W/o this class (and its friends) then the terminal will lack most features that make jline interesting for users.

[md-5]

Its failing to initialize on platforms without the correct Visual C++ Runtimes (as far as I can tell - the classes are there).
I know this error wasn't printed in older JLine releases, and I'm happy to fallback to a standard terminal anyway. I just don't want users to complain.

[jdillon]

what version are you using? and what version were you using before which you said did not produce the ERROR logging?

[md-5]

2.6 does not produce logging, 2.11 does :p

[md-5]

Hmmm must be mistaken, that message has been there for a long time :|

[jdillon]

There is no easy way to omit this single error from being displayed. The creation of the Terminal instances is failing in non-expected manner, and the log providing that failure detail.

You can change the log stream used by jline2 by calling jline.internal.Log.setOutput(PrintStream). Note this is internal api and could be changed at any time (though probably won't be any time soon).

There are 2 other alternatives, one would be to add support to disable all logging (I do not recommend this) or change to a more robust logging system which includes details like logger names which would allow specific loggers to be shunted... though I'm no fan of JUL and thus such a change would add another dependency (like to slf4j and then require a slf4j provider) and for these reasons the logging has been left in the simple form that it is in now.

Perhaps Hiram has some insight on if jansi can produce a windows binary w/o additional dependencies and generally avoid this problem all together.

[md-5]

Log.setOutput( new PrintStream( ByteStreams.nullOutputStream() ) );
Works for now, getting JLine to not require Visual C++ runtime would be nice

[jdillon]

@md-5 what version of windows did the failure to locate visual c++ dll occur on? BTW I'm no windows developer, but for clarity can you confirm that it was msvcrt.dll that was having problem being resolved?

[omajid]

You can change the log stream used by jline2 by calling jline.internal.Log.setOutput(PrintStream).

Sorry for jumping in an unrelated issue, but I was trying to disable logging myself for a different bug. This call to Log.setOutput doesn't work when using OSGi because the jline.internal package is not exported. Is there any other way to silence the warnings?

For more information, my use case is to disable the stack trace shown (not the error message itself, just the stack trace) when user enters a bad expansion, like what!?! at the jline input.