Jansi is a small java library that allows you to use ANSI escape sequences to format your console output which works even on windows.

Related tags

CLI jansi
Overview

Jansi

Description

Jansi is a small java library that allows you to use ANSI escape codes to format your console output which works even on Windows.

It also provides the required JNI libraries:

Maven Central

Features

  • Implements ANSI escape colorization/handling that is missing on the Windows platform, using integrated JNI library.
  • Strips ANSI escape codes if process output is is being redirected and not attached to a terminal.
  • Easy to use Ansi escape sequence builder API.
  • JNI access to low-level console features.

Synopsis

Most unix terminals support rendering ANSI escape codes when Java sends them via System.out, but when this is done on Windows, they don't get interpreted and you get garbage on the console.

Furthermore, even when on Unix, when process output is being redirected to a file, you typically don't want to output escape codes to the file since most file viewers and editors will not properly display the escape codes.

Jansi detects and abstracts the ANSI support provided by the attached terminal. When your Java application uses Jansi, it can always assume that standard out and error streams support ANSI sequences. Depending on the platform and if the application output is attached to a real terminal, Jansi will do one of the following with the ANSI escape codes that it receives:

  • Pass them through untouched
  • Filter them out
  • Use platform specific APIs to implement the terminal commands represented by the escape sequence

Example Usage

Enabling the Jansi ANSI support into your application is as simple as doing a simple static method call:

import org.fusesource.jansi.AnsiConsole;
...
AnsiConsole.systemInstall();

Disabling it is also done via a static method:

AnsiConsole.systemUninstall();

It is safe to call those methods multiple times, they keep track of how many times systemInstall() has been called and only uninstalls when the systemUninstall() method is called a corresponding number of times.

Using the Ansi escape sequence builder:

import static org.fusesource.jansi.Ansi.*;
import static org.fusesource.jansi.Ansi.Color.*;
...
System.out.println( ansi().eraseScreen().fg(RED).a("Hello").fg(GREEN).a(" World").reset() );

The above will clear the screen, write Hello in red and World in green, then reset the color attributes so that subsequent data printed to the stream uses the default colors.

But there is an even simpler way to accomplish the above using the render method:

System.out.println( ansi().eraseScreen().render("@|red Hello|@ @|green World|@") );

Windows XP Users

The JNI library that JANSI uses depends on the "Microsoft Visual C++ 2008 SP1 Redistributable" You can get a free copy from MS at:

http://www.microsoft.com/en-us/download/details.aspx?displaylang=en&id=5582

Project Links

Comments
  • eraseLine() malfunction!

    eraseLine() malfunction!

    Note: This took me several hours to figure out, so please bear 1-2 minutes to read this, thanks! Context: Trying to update/replace multiple lines with new data. Bug: When then console is already filled with stuff, eraseLine()/restoreCursorPostion() wont work! Confirmed broken on versions: Jansi 2.2.0 (Windows and Linux) and Jansi 1.18 (Linux) Confirmed working on versions: Jansi 1.18 (Windows) Java version: 1.8 Code:

    try{
                    // Print out TEST 15 times. This shouldn't fill out the console window and the erase function works just fine.
                    // BUT if we change this to 30 or 50, so that the console window is filled out, and then use the erase function it breaks and does not erase any lines! Instead of replacing it writes new lines.
                    for (int i = 0; i < 30; i++) {
                        System.out.println("TEST");
                    }
                    AnsiConsole.systemInstall(); 
                    // Step 1: save the cursor.
                    System.out.print(Ansi.ansi().saveCursorPosition());
                    for (int i = 0; i < 5; i++) {
                        // Step 2: print the data
                        System.out.println(Ansi.ansi().a("Line 1 with data "+i));
                        System.out.println(Ansi.ansi().a("Line 2 with data "+i));
                        // Step 3: define interval for next update
                        Thread.sleep(1000);
                        // Step 4: jump back to start, erase the data and jump back to start again
                        System.out.print(Ansi.ansi().restoreCursorPosition());
                        System.out.print(Ansi.ansi().eraseLine(Ansi.Erase.FORWARD));
                        System.out.print(Ansi.ansi().restoreCursorPosition());
                    }
                } catch (Exception e) {
                    e.printStackTrace();
                }
    
    opened by Osiris-Team 29
  • [Jansi 1.16 / Maven 3.5.1 regression] ANSI escape codes for colors are not interpreted correctly in Cygwin and MINGW (GitBash and Intellij IDEA terminals)

    [Jansi 1.16 / Maven 3.5.1 regression] ANSI escape codes for colors are not interpreted correctly in Cygwin and MINGW (GitBash and Intellij IDEA terminals)

    Prologue: Maven jira ticket -->> MNG-6282

    Details / history:

    • maven 3.5.0 (with jansi 1.13): everything works fine
    • maven 3.5.1 (with jansi 1.16): console output fails to show colors (red, blue, green, yellow) Jansi revert / downgrade (to, say, version 1.15) solves colors issues in maven 3.5.1, but, according to @hboutemy, this action is a no-go a due to related changes / tickets (see this JIRA comment)

    Git-bisect shows this commit (that introduced regression): https://github.com/fusesource/jansi/commit/bb3d538315c44f799d34fd3426f6c91c8e8dfc55 ANSI output stripping does not work if TERM is xterm, fixes #83

    Maven 3.5.0 and 3.5.1 outputs in GitBash and Cygwin terminals:

    • https://issues.apache.org/jira/secure/attachment/12886398/screenshot-1.png
    • https://issues.apache.org/jira/secure/attachment/12886657/screenshot-5-Cygwin.png

    Note: @hboutemy branch / PR #88 was used in order to confirm issues on both terminals (see comments below).

    opened by dejan2609 13
  • Jansi drowns the entire VM if platform is not supported

    Jansi drowns the entire VM if platform is not supported

    We, the Apache Maven team, are currently preparing Maven 3.4 with color logging support. Running a snapshot from Maven master on a platform which is not supported (no so available), drowns the entire VM. See example for FreeBSD:

    $ ./apache-maven-3.4.0-SNAPSHOT/bin/mvn -v
    
    ---------------------------------------------------
    constituent[0]: file:/net/home/osipovmi/apache-maven-3.4.0-SNAPSHOT/conf/logging/
    constituent[1]: file:/net/home/osipovmi/apache-maven-3.4.0-SNAPSHOT/lib/maven-embedder-3.4.0-SNAPSHOT.jar
    constituent[2]: file:/net/home/osipovmi/apache-maven-3.4.0-SNAPSHOT/lib/maven-settings-3.4.0-SNAPSHOT.jar
    constituent[3]: file:/net/home/osipovmi/apache-maven-3.4.0-SNAPSHOT/lib/plexus-utils-3.0.24.jar
    constituent[4]: file:/net/home/osipovmi/apache-maven-3.4.0-SNAPSHOT/lib/maven-core-3.4.0-SNAPSHOT.jar
    constituent[5]: file:/net/home/osipovmi/apache-maven-3.4.0-SNAPSHOT/lib/maven-model-3.4.0-SNAPSHOT.jar
    constituent[6]: file:/net/home/osipovmi/apache-maven-3.4.0-SNAPSHOT/lib/commons-lang3-3.4.jar
    constituent[7]: file:/net/home/osipovmi/apache-maven-3.4.0-SNAPSHOT/lib/maven-settings-builder-3.4.0-SNAPSHOT.jar
    constituent[8]: file:/net/home/osipovmi/apache-maven-3.4.0-SNAPSHOT/lib/maven-builder-support-3.4.0-SNAPSHOT.jar
    constituent[9]: file:/net/home/osipovmi/apache-maven-3.4.0-SNAPSHOT/lib/plexus-interpolation-1.22.jar
    constituent[10]: file:/net/home/osipovmi/apache-maven-3.4.0-SNAPSHOT/lib/plexus-component-annotations-1.6.jar
    constituent[11]: file:/net/home/osipovmi/apache-maven-3.4.0-SNAPSHOT/lib/plexus-sec-dispatcher-1.4.jar
    constituent[12]: file:/net/home/osipovmi/apache-maven-3.4.0-SNAPSHOT/lib/plexus-cipher-1.7.jar
    constituent[13]: file:/net/home/osipovmi/apache-maven-3.4.0-SNAPSHOT/lib/maven-repository-metadata-3.4.0-SNAPSHOT.jar
    constituent[14]: file:/net/home/osipovmi/apache-maven-3.4.0-SNAPSHOT/lib/maven-artifact-3.4.0-SNAPSHOT.jar
    constituent[15]: file:/net/home/osipovmi/apache-maven-3.4.0-SNAPSHOT/lib/maven-plugin-api-3.4.0-SNAPSHOT.jar
    constituent[16]: file:/net/home/osipovmi/apache-maven-3.4.0-SNAPSHOT/lib/org.eclipse.sisu.plexus-0.3.3.jar
    constituent[17]: file:/net/home/osipovmi/apache-maven-3.4.0-SNAPSHOT/lib/cdi-api-1.0.jar
    constituent[18]: file:/net/home/osipovmi/apache-maven-3.4.0-SNAPSHOT/lib/jsr250-api-1.0.jar
    constituent[19]: file:/net/home/osipovmi/apache-maven-3.4.0-SNAPSHOT/lib/javax.inject-1.jar
    constituent[20]: file:/net/home/osipovmi/apache-maven-3.4.0-SNAPSHOT/lib/org.eclipse.sisu.inject-0.3.3.jar
    constituent[21]: file:/net/home/osipovmi/apache-maven-3.4.0-SNAPSHOT/lib/maven-model-builder-3.4.0-SNAPSHOT.jar
    constituent[22]: file:/net/home/osipovmi/apache-maven-3.4.0-SNAPSHOT/lib/guava-19.0.jar
    constituent[23]: file:/net/home/osipovmi/apache-maven-3.4.0-SNAPSHOT/lib/aether-api-1.0.2.v20150114.jar
    constituent[24]: file:/net/home/osipovmi/apache-maven-3.4.0-SNAPSHOT/lib/maven-aether-provider-3.4.0-SNAPSHOT.jar
    constituent[25]: file:/net/home/osipovmi/apache-maven-3.4.0-SNAPSHOT/lib/aether-spi-1.0.2.v20150114.jar
    constituent[26]: file:/net/home/osipovmi/apache-maven-3.4.0-SNAPSHOT/lib/aether-util-1.0.2.v20150114.jar
    constituent[27]: file:/net/home/osipovmi/apache-maven-3.4.0-SNAPSHOT/lib/aether-impl-1.0.2.v20150114.jar
    constituent[28]: file:/net/home/osipovmi/apache-maven-3.4.0-SNAPSHOT/lib/jansi-1.12.jar
    constituent[29]: file:/net/home/osipovmi/apache-maven-3.4.0-SNAPSHOT/lib/guice-4.0-no_aop.jar
    constituent[30]: file:/net/home/osipovmi/apache-maven-3.4.0-SNAPSHOT/lib/aopalliance-1.0.jar
    constituent[31]: file:/net/home/osipovmi/apache-maven-3.4.0-SNAPSHOT/lib/maven-compat-3.4.0-SNAPSHOT.jar
    constituent[32]: file:/net/home/osipovmi/apache-maven-3.4.0-SNAPSHOT/lib/wagon-provider-api-2.10.jar
    constituent[33]: file:/net/home/osipovmi/apache-maven-3.4.0-SNAPSHOT/lib/slf4j-api-1.7.16.jar
    constituent[34]: file:/net/home/osipovmi/apache-maven-3.4.0-SNAPSHOT/lib/commons-cli-1.3.1.jar
    constituent[35]: file:/net/home/osipovmi/apache-maven-3.4.0-SNAPSHOT/lib/wagon-http-2.10-shaded.jar
    constituent[36]: file:/net/home/osipovmi/apache-maven-3.4.0-SNAPSHOT/lib/wagon-http-shared-2.10.jar
    constituent[37]: file:/net/home/osipovmi/apache-maven-3.4.0-SNAPSHOT/lib/jsoup-1.7.2.jar
    constituent[38]: file:/net/home/osipovmi/apache-maven-3.4.0-SNAPSHOT/lib/commons-lang-2.6.jar
    constituent[39]: file:/net/home/osipovmi/apache-maven-3.4.0-SNAPSHOT/lib/commons-io-2.2.jar
    constituent[40]: file:/net/home/osipovmi/apache-maven-3.4.0-SNAPSHOT/lib/wagon-file-2.10.jar
    constituent[41]: file:/net/home/osipovmi/apache-maven-3.4.0-SNAPSHOT/lib/aether-connector-basic-1.0.2.v20150114.jar
    constituent[42]: file:/net/home/osipovmi/apache-maven-3.4.0-SNAPSHOT/lib/aether-transport-wagon-1.0.2.v20150114.jar
    constituent[43]: file:/net/home/osipovmi/apache-maven-3.4.0-SNAPSHOT/lib/gossip-slf4j-2.0.0.jar
    constituent[44]: file:/net/home/osipovmi/apache-maven-3.4.0-SNAPSHOT/lib/gossip-core-2.0.0.jar
    constituent[45]: file:/net/home/osipovmi/apache-maven-3.4.0-SNAPSHOT/lib/gossip-bootstrap-2.0.0.jar
    ---------------------------------------------------
    Exception in thread "main" java.lang.UnsatisfiedLinkError: Could not load library. Reasons: [no jansi32-1.12 in java.library.path, no jansi-1.12 in java.library.path, no jansi in java.library.path]
            at org.fusesource.hawtjni.runtime.Library.doLoad(Library.java:182)
            at org.fusesource.hawtjni.runtime.Library.load(Library.java:140)
            at org.fusesource.jansi.internal.CLibrary.<clinit>(CLibrary.java:42)
            at org.fusesource.jansi.AnsiConsole.wrapOutputStream(AnsiConsole.java:48)
            at org.fusesource.jansi.AnsiConsole.<clinit>(AnsiConsole.java:38)
            at org.apache.maven.cli.MavenCli.main(MavenCli.java:215)
            at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
            at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
            at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
            at java.lang.reflect.Method.invoke(Method.java:606)
            at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
            at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
            at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
            at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
    

    This doesn't really help because we do not know our users up front and can't have it fail. Jansi shall fall back in no-color mode and emit an error on stderr. With this, it is guaranteed that Maven continues to work without color support. See reference thread. Issues MNG-3507 and MNG-6038.

    I already have a fork of fusesource/hawtjni which makes it perfectly compile on FreeBSD 9 and 10 (tests) pending and local snapshots of all components with colored logging on FreeBSD.

    FreeBSD is just an example, this will also happen on Solaris, AIX, etc. I assume that isatty() does not fail gracefully?

    @hboutemy @jdillon

    opened by michael-o 12
  • Support for os.name=Linux, os.arch=armv6

    Support for os.name=Linux, os.arch=armv6

    I get this error on Raspberry Pi Zero (armv6):

    Exception in thread "main" java.lang.ExceptionInInitializerError
    	at org.fusesource.jansi.AnsiConsole.ansiStream(AnsiConsole.java:239)
    	at org.fusesource.jansi.AnsiConsole.initStreams(AnsiConsole.java:542)
    	at org.fusesource.jansi.AnsiConsole.systemInstall(AnsiConsole.java:496)
    	at com.diozero.sampleapps.SystemInformation.main(SystemInformation.java:52)
    Caused by: java.lang.RuntimeException: Unable to load jansi native library
    	at org.fusesource.jansi.internal.JansiLoader.initialize(JansiLoader.java:62)
    	at org.fusesource.jansi.internal.CLibrary.<clinit>(CLibrary.java:30)
    	... 4 more
    Caused by: java.lang.Exception: No native library found for os.name=Linux, os.arch=armv6, paths=[/usr/java/packages/lib/arm:/usr/lib/arm-linux-gnueabihf/jni:/lib/arm-linux-gnueabihf:/usr/lib/arm-linux-gnueabihf:/usr/lib/jni:/lib:/usr/lib]
    	at org.fusesource.jansi.internal.JansiLoader.loadJansiNativeLibrary(JansiLoader.java:333)
    	at org.fusesource.jansi.internal.JansiLoader.initialize(JansiLoader.java:60)
    	... 5 more
    

    Would it be possible to compile the native library for armv6?

    opened by mattjlewis 11
  • Trouble using Jansi with GraalVM native-image on MacOS

    Trouble using Jansi with GraalVM native-image on MacOS

    Looks like there was already some work done to address issue #162, but that doesn't seem to quite do everything that was required in my case to get things working with Jansi in a GraalVM native image.

    The problem was that native-image build was running the code that finds and links the necessary native library image at build time, so the library was not linked at run time, resulting in an UnsatisfiedLinkError error at runtime:

    Exception in thread "main" java.lang.UnsatisfiedLinkError: org.fusesource.jansi.internal.CLibrary.isatty(I)I [symbol: Java_org_fusesource_jansi_internal_CLibrary_isatty or Java_org_fusesource_jansi_internal_CLibrary_isatty__I]
    	at com.oracle.svm.jni.access.JNINativeLinkage.getOrFindEntryPoint(JNINativeLinkage.java:153)
    	at com.oracle.svm.jni.JNIGeneratedMethodSupport.nativeCallAddress(JNIGeneratedMethodSupport.java:57)
    	at org.fusesource.jansi.internal.CLibrary.isatty(CLibrary.java)
            ...
    

    I was able to overcome this by telling the native image that the relevant classes must be initialised at runtime rather than at build time. I achieved this by adding the following class to my codebase:

    @AutomaticFeature
    public class JansiFeature implements Feature {
    
        JansiFeature() { /* empty constructor required for Feature operation */ }
    
        @Override
        public void afterRegistration(AfterRegistrationAccess access) {
            RuntimeClassInitialization.initializeAtRunTime("org.fusesource.jansi.internal");
        }
    
        @Override
        public void beforeAnalysis(BeforeAnalysisAccess access) {
            JNIRuntimeAccess.register(CLibrary.class);
            JNIRuntimeAccess.register(CLibrary.class.getDeclaredFields());
        }
    }
    

    It may be possible to add the necessary configuration (either this file, or appropriate .json config files) to the Jansi library itself so that it will work correctly "out of the box" with native-image builds on GraalVM. If not, perhaps this will at least be useful to someone else who encounters the same problem.

    opened by greenatatlassian 11
  • Jansi in GraalVM native images

    Jansi in GraalVM native images

    TL;DR - for Jansi Users

    Jansi by itself is insufficient to show colors in Java applications compiled to GraalVM native images for Windows. This is partly because GraalVM requires configuration and partly because Jansi internally depends on non-standard system properties, without a graceful fallback if these properties are absent (as is the case in GraalVM).

    Users may be interested in combining Jansi with picocli-jansi-graalvm until this issue is fixed.

    For the Jansi Maintainers

    Background

    I'm working on picocli support for Graal native images. Building native images for Windows is still experimental, and it's not perfect but it works.

    I would like to provide support for colored output on Windows console when executing a native image. Using Jansi for this is the obvious choice. (We don't need to worry about other OS-es.)

    Would you be interested in helping to provide Jansi support for GraalVM native images on Windows?

    Objective

    Easily create a single Windows executable that shows colors on the console.

    Problem Description

    We need two configuration files to make Jansi work in a native image. If we can include these in the Jansi JAR file, it becomes very easy for developers to create native images.

    • JNI - Jansi uses JNI, and all classes, methods, and fields that should be accessible via JNI must be specified during native image generation in a configuration file
    • resources - to get a single executable we need to bundle the jansi.dll in the native image. We need some configuration to ensure the jansi.dll is included as a resource.

    Also, there is a problem extracting the jansi.dll from the native image. This should work similarly to extracting it from the jansi JAR, but there is some difference and org.fusesource.hawtjni.runtime.Library (in jansi 1.18) is unable to extract jansi.dll from the native image.

    What I've done so far

    Created the below GraalVM configuration files:

    • jni-config.json
    • resource-config.json

    I've created a jni-config.json file for all classes, methods and fields in org.fusesource.jansi.internal.CLibrary and org.fusesource.jansi.internal.Kernel32. (See attached jni-config.json.txt file.)

    (The jni-config.json config file can be re-generated with the below command if necessary: )

    java -cp picocli-4.0.4.jar;jansi-1.18.jar;picocli-codegen-4.0.5-SNAPSHOT.jar ^
      picocli.codegen.aot.graalvm.JniConfigGenerator ^
      org.fusesource.jansi.internal.CLibrary ^
      org.fusesource.jansi.internal.Kernel32 ^
      -o=.\jni-config.json
    

    Secondly, we need to ensure that the jansi.dll is included in the native image, just like it is included in the Jansi JAR. To do this, we register it as a resource with GraalVM using configuration. The Jansi JAR file includes native libraries for many platforms, but we only need the jansi.dll for 64-bit Windows. We can ensure this DLL is included in the native image by supplying this resource-config.json file:

    {
      "resources": [
        {"pattern": "META-INF/native/windows64/jansi.dll"}
      ]
    }
    

    What I need from you

    Summary:

    • Make things easy for developers by including GraalVM config in Jansi in future releases
    • There is a problem in the hawtjni Library logic that extracts the jansi.dll, when running as a native image. There is a workaround, but it would be great if the Library logic itself could be fixed so that the workaround is not necessary.

    Please include GraalVM configuration in Jansi distribution going forward

    Developers can specify the above two configuration files on the command line when creating a native image, but this is cumbersome.

    If Jansi can include these two configuration files in the jansi-x.x.jar in the following location, then the GraalVM native-image generator tool will pick up the configuration automatically:

    /META-INF/native-image/jansi/jni-config.json
    /META-INF/native-image/jansi/resource-config.json
    

    Extraction Issue in hawtjni Library

    The configuration alone is not sufficient to get colored output from a native image. When I create a native image for a sample program that runs AnsiMain after AnsiConsole.systemInstall(), I get the following error:

    Jansi null (Jansi native null, HawtJNI runtime null)
    
    library.jansi.path=
    library.jansi.version=
    Exception in thread "main" java.lang.UnsatisfiedLinkError: Could not load library. Reasons: [java.lang.LinkageError: Unable to load library jansi]
            at org.fusesource.hawtjni.runtime.Library.doLoad(Library.java:233)
            at org.fusesource.hawtjni.runtime.Library.load(Library.java:185)
            at org.fusesource.jansi.AnsiMain.main(AnsiMain.java:63)
            at App.main(App.java:8)
    

    Setting the library.jansi.path system property to a writable directory did not help, resulting in a similar but longer error message:

    ...
    Exception in thread "main" java.lang.UnsatisfiedLinkError: Could not load library. Reasons: [java.lang.LinkageError: Unable to load library from C:\Users\remko\IdeaProjects\native-java-cli-demo\build\graal\windows-1\amd64\jansi.dll, java.lang.LinkageError: Unable to load library from C:\Users\remko\IdeaProjects\native-java-cli-demo\build\graal\windows-1\jansi.dll, java.lang.LinkageError: Unable to load library from C:\Users\remko\IdeaProjects\native-java-cli-demo\build\graal\windows\jansi.dll, java.lang.LinkageError: Unable to load library from C:\Users\remko\IdeaProjects\native-java-cli-demo\build\graal\.\jansi.dll, java.lang.LinkageError: Unable to load library jansi]
            at org.fusesource.hawtjni.runtime.Library.doLoad(Library.java:233)
    

    Cause: problem in extraction logic when running in native image

    The problem does not manifest when the application extracts jansi.dll before calling AnsiConsole.systemInstall(): there is no UnsatisfiedLinkError, and the console shows colors! See the workaround below for details.

    So there is some problem in the hawtjni Library extraction logic that makes it fail when run in a GraalVM native image. I have not been able to determine what that problem is exactly.

    Would you be interested in helping me figure out where the problem is, and fixing the hawtjni Library extraction logic?

    Steps to reproduce:

    choco install windows-sdk-7.1 kb2519277
    

    Then (from the cmd prompt), activate the sdk-7.1 environment:

    call "C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\SetEnv.cmd"
    

    This starts a new Command Prompt, with the sdk-7.1 environment enabled. Run all subsequent commands in this Command Prompt window.

    Example app:

    import org.fusesource.jansi.AnsiConsole;
    import org.fusesource.jansi.AnsiMain;
    import java.io.IOException;
    
    class App {
        public static void main(String[] args) throws IOException {
            AnsiConsole.systemInstall();
            AnsiMain.main(args);
            AnsiConsole.systemUninstall();
        }
    }
    

    Here is the command to create the native image:

    javac -cp jansi-1.18.jar App.java
    
    C:\apps\graalvm-ce-19.2.1\bin\native-image -H:JNIConfigurationFiles=jni-config.json ^
      -H:ResourceConfigurationFiles=resource-config.json ^
      -cp .;jansi-1.18.jar ^
      App myapp
    

    This will create a native image myapp.exe in the current directory. Executing this native image will show the UnsatisfiedLinkError.

    Workaround: Extract jansi.dll in the application

    To fix the UnsatisfiedLinkError and show colors, replace the main method in App with the below.

    Here is the code to “manually” extract the jansi.dll from the native image resource and add it to the java.library.path in the application (instead of relying on Library:

        public static void main(String[] args) {
            URL url = org.fusesource.jansi.internal.CLibrary.class
                    .getResource("/META-INF/native/windows64/jansi.dll");
            File lib = new File(System.getProperty("java.io.tmpdir"), "jansi.dll");
            if (!lib.getParentFile().exists() && !lib.getParentFile().mkdirs()) {
                throw new IOException(lib.getParentFile() +
                        " does not exist and could not be created");
            }
            try (InputStream in = url.openStream()) {
                Files.copy(in, lib.toPath(), StandardCopyOption.REPLACE_EXISTING);
            }
            String libPath = System.getProperty("java.library.path");
            if (libPath != null && libPath.length() > 0) {
                libPath += File.pathSeparator;
            }
            libPath += lib.getParentFile().getAbsolutePath();
            System.setProperty("java.library.path", libPath);
    
            AnsiConsole.systemInstall();
            AnsiMain.main(args);
            AnsiConsole.systemUninstall();
        }
    

    With this workaround, colors are shown on the console when running as a native image. It would be great if the Library logic itself could be fixed so that this workaround is not necessary.

    Sorry for the very long issue.

    opened by remkop 11
  • No colors if stdout is redirected

    No colors if stdout is redirected

    I've write a program that uses both stdout (for "graphical" view) and stderr (for logging), they both have colorized texts. I'm using Win10. Without any redirect, or if I redirect only stderr, JAnsi works fine. But if I redirect stdout, the log won't be printed with colors. This is strange... I think JAnsi uses only stdout for detecting the redirection, but what about stderr?

    opened by klenium 9
  • Does not work with Git CMD on Windows

    Does not work with Git CMD on Windows

    When I run Maven using Git CMD on Windows I'm seeing the escape characters printed on the console:

    Apache Maven 3.5.3 (3383c37e1f9e9b3bc3df5050c29c8aff9f295297; 2018-02-24T21:49:05+02:00)
    Maven home: C:\Programs\maven\bin\..
    Java version: 10, vendor: Oracle Corporation
    Java home: C:\Program Files\Java\jdk
    Default locale: en_US, platform encoding: Cp1252
    OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
    

    I suspect the reason is because MSYSTEM is set to MINGW64. If I unset it the output is fine. I wonder if there is a way to detect that the terminal used is CMD and it does not support ANSI escape character?

    opened by plamentotev 9
  • Fix license name

    Fix license name

    The license name in the POM is wrong. It must read: Apache License, Version 2.0

    See: https://github.com/apache/maven-apache-parent/blob/e3a75f29af4e8ab443ee4f2ee702c766a2f017f2/pom.xml#L45-L49

    opened by michael-o 8
  • Support for 256 color terminals

    Support for 256 color terminals

    The terminal on OSX supports 256 colors. It would be awesome if Jansi could know when to strip them out and when to leave them.

    Try this on an OSX terminal

    #!/bin/bash
    
    cat > /tmp/termcolors.java <<EOF
    public class termcolors {
        public static void main(String[] args) {
            for (int i = 0; i < 256; i++) {
                System.out.printf("\033[38;5;%sm#@%03d", i, i);
                System.out.print("  ");
    
                if (i % 12 == 0) System.out.println();
            }
            System.out.println();
        }
    }
    EOF
    javac /tmp/termcolors.java &&
    java -cp /tmp termcolors
    
    cat <<EOF
    
    #!/bin/bash
    N=202
    echo -e "\033[38;5;\${N}mTry Me\033[0m"
    EOF
    
    
    
    opened by dblevins 8
  • Why jansi-*.dll is extracted in %TMP% ? How can I avoid that ?

    Why jansi-*.dll is extracted in %TMP% ? How can I avoid that ?

    I am using jansi-1.16 in a small project which is an application that I invoke every now and then. At a result, here is what jansi does: it extract a lot of dll into my %TMP% folder as shown below.

    => I understand that it is required, but could it not use some more stable path, such as ${user.home}/.jansi/jansi-<version>.dll ?

    image

    opened by glhez 8
  • Add support for statically linking Jansi JNI library

    Add support for statically linking Jansi JNI library

    We have a picocli-based application for which we build native images for Windows, Linux & MacOS using GraalVM. For various reasons, we build a statically linked executable for Linux, and dynamically linked executables for Windows/MacOS.

    We would like to add Jansi (and JLine) to our application. Jansi 2.4.0 works just fine for our dynamically linked executables, however it fails to load the native jansi library in the statically linked executable because musl apparently doesn't support dynamic library loading (see https://github.com/oracle/graal/issues/4028#issue-1055983935):

    open("/tmp", O_RDONLY|O_LARGEFILE|O_CLOEXEC|O_DIRECTORY) = 4
    open("/tmp/jansi-2.4.0-83026643492bd4eb-libjansi.so.lck", O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = 4
    open("/tmp/jansi-2.4.0-83026643492bd4eb-libjansi.so", O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = 4
    open("/tmp/jansi-2.4.0-83026643492bd4eb-libjansi.so", O_RDONLY|O_LARGEFILE) = 4
    Failed to load native library:jansi-2.4.0-83026643492bd4eb-libjansi.so. osinfo: Linux/x86_64
    java.lang.UnsatisfiedLinkError: Can't load library: /tmp/jansi-2.4.0-83026643492bd4eb-libjansi.so
    

    Apart from this issue, it's also just more logical to statically link the Jansi library when building native images, to avoid dynamic extraction of the library to a temporary directory and then loading it.

    Based on what I've read so far, I think the following would be needed:

    • jansi.c: Export either JNI_OnLoad (for dynamic linking) or JNI_OnLoad_jansi (for static linking)
    • Update Makefile to add support for building libJansi.a/jansi.lib files
    • Optional: publish pre-built .a/.lib files, to avoid users having to build these themselves
    • Update JansiLoader to (also) try System.loadLibrary("jansi") (either always try, or use a system property to decide between this and the original System.load(path)-based approach)
    • Document how to statically link Jansi:
      • Add org.graalvm.nativeimage:svm dependency
      • Add the required GraalVM @AutomaticFeature (alternatively, publish a new jansi-<version>-static-feature.jar artifact that readily includes this feature, such that users can simply add this as a dependency)
      • Add -H:CLibraryPath=/path/to/dir/containing/libJansi.a option to native-image invocation
      • Add a resource exclude to prevent dynamic Jansi libraries being added to the native image, basically making GraalVM ignore: https://github.com/fusesource/jansi/blob/00e15cb1fab9117790580a412f7d54f2c08d2f11/src/main/resources/META-INF/native-image/jansi/resource-config.json#L5

    For reference, some links related to statically linking JNI libraries:

    • https://www.blog.akhil.cc/static-jni
    • https://github.com/oracle/graal/issues/3359#issuecomment-822070278
    • https://github.com/oracle/graal/issues/3359#issuecomment-1031482202
    opened by rsenden 1
  • - Not able to load Jansi

    - Not able to load Jansi

    Hello,

    My user ha changed and now I can't lunch jansi.

    But with another user no problem, is for path with LuísCENTEIO ? Whow can I overcome this issue?

    Below the two output from two users in same computer : ( hotline and LuísCENTEIO ) hotline the good

    C:\Users\LuísCENTEIO>java -jar C:\Apps\sqlcl\lib\jansi.jar Jansi 2.4.0

    library.jansi.path= library.jansi.version= Failed to load native library:jansi-2.4.0-a29997176d7b74cc-jansi.dll. osinfo: Windows/x86_64 java.lang.UnsatisfiedLinkError: C:\Users\LuísCENTEIO\AppData\Local\Temp\jansi-2.4.0-a29997176d7b74cc-jansi.dll: Can't find dependent libraries Failed to load native library:jansi-2.4.0-da01663cb1674f6b-jansi.dll. osinfo: Windows/x86_64 java.lang.UnsatisfiedLinkError: C:\Users\LuísCENTEIO\AppData\Local\Temp\jansi-2.4.0-da01663cb1674f6b-jansi.dll: Can't find dependent libraries java.lang.RuntimeException: Unable to load jansi native library. You may want set the jansi.graceful system property to true to be able to use Jansi on your platform at org.fusesource.jansi.internal.JansiLoader.initialize(JansiLoader.java:65) at org.fusesource.jansi.AnsiMain.main(AnsiMain.java:70) Caused by: java.lang.Exception: No native library found for os.name=Windows, os.arch=x86_64, paths=[/org/fusesource/jansi/internal/native/Windows/x86_64;C:\Program Files\Java\jdk-17.0.5\bin;C:\WINDOWS\Sun\Java\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\Program Files\Common Files\Oracle\Java\javapath;C:\app\oracle\product\21.0.0\product\21.0.0\client_1\bin;C:\Program Files (x86)\Common Files\Oracle\Java\javapath;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0;C:\Windows\System32\OpenSSH;C:\Program Files\Microsoft VS Code\bin;C:\Program Files (x86)\Microsoft SQL Server\150\DTS\Binn;C:\Program Files\Microsoft SQL Server\Client SDK\ODBC\170\Tools\Binn;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0;C:\WINDOWS\System32\OpenSSH;C:\ProgramData\chocolatey\bin;C:\tools\lxrunoffline;C:\Program Files\dotnet;c:\utils;C:\Program Files\Citrix\Citrix Files;C:\Program Files\Java\jdk1.8.0_211\bin;C:\Users\LuísCENTEIO\AppData\Local\Microsoft\WindowsApps;.] at org.fusesource.jansi.internal.JansiLoader.loadJansiNativeLibrary(JansiLoader.java:334) at org.fusesource.jansi.internal.JansiLoader.initialize(JansiLoader.java:62) ... 1 more

    os.name= Windows 10, os.version= 10.0, os.arch= amd64 file.encoding= Cp1252 java.version= 17.0.5, java.vendor= Oracle Corporation, java.home= C:\Program Files\Java\jdk-17.0.5

    jansi.graceful= jansi.mode= jansi.out.mode= jansi.err.mode= jansi.colors= jansi.out.colors= jansi.err.colors= jansi.passthrough= false jansi.strip= false jansi.force= false jansi.noreset= false org.fusesource.jansi.Ansi.disable= false

    IS_WINDOWS: true IS_CONEMU: false IS_CYGWIN: false IS_MSYSTEM: false

    Failed to load native library:jansi-2.4.0-d8d3e45b9f756f14-jansi.dll. osinfo: Windows/x86_64 java.lang.UnsatisfiedLinkError: C:\Users\LuísCENTEIO\AppData\Local\Temp\jansi-2.4.0-d8d3e45b9f756f14-jansi.dll: Can't find dependent libraries isatty(STDOUT_FILENO): 0, System.out is NOT a terminal isatty(STDERR_FILENO): 0, System.err is NOT a terminal

    Resulting Jansi modes for stout/stderr streams:

    • System.out: AnsiPrintStream{type=Unsupported, colors=Colors16, mode=Strip, resetAtUninstall=false}
    • System.err: AnsiPrintStream{type=Unsupported, colors=Colors16, mode=Strip, resetAtUninstall=false} Processor types description:
    • Native: Supports ansi sequences natively
    • Unsupported: Ansi sequences are stripped out
    • VirtualTerminal: Supported through windows virtual terminal
    • Emulation: Emulated through using windows API console commands
    • Redirected: The stream is redirected to a file or a pipe Colors support description:
    • Colors16: 16 colors
    • Colors256: 256 colors
    • TrueColor: 24-bit colors Modes description:
    • Strip: Strip all ansi sequences
    • Default: Print ansi sequences if the stream is a terminal
    • Force: Always print ansi sequences, even if the stream is redirected

    test on System.out: BLACK RED GREEN YELLOW BLUE MAGENTA CYAN WHITE DEFAULT bright: BLACK RED GREEN YELLOW BLUE MAGENTA CYAN WHITE DEFAULT bold: BLACK RED GREEN YELLOW BLUE MAGENTA CYAN WHITE DEFAULT faint: BLACK RED GREEN YELLOW BLUE MAGENTA CYAN WHITE DEFAULT bold+faint: BLACK RED GREEN YELLOW BLUE MAGENTA CYAN WHITE DEFAULT 256 colors:

         truecolor: /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
                    /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
                    /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
                    /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
                    /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
                    /\/\/\/\/\/\/\/\
    

    test on System.err: BLACK RED GREEN YELLOW BLUE MAGENTA CYAN WHITE DEFAULT bright: BLACK RED GREEN YELLOW BLUE MAGENTA CYAN WHITE DEFAULT bold: BLACK RED GREEN YELLOW BLUE MAGENTA CYAN WHITE DEFAULT faint: BLACK RED GREEN YELLOW BLUE MAGENTA CYAN WHITE DEFAULT bold+faint: BLACK RED GREEN YELLOW BLUE MAGENTA CYAN WHITE DEFAULT 256 colors:

         truecolor: /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
                    /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
                    /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
                    /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
                    /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
                    /\/\/\/\/\/\/\/\
    
                      ┌──┐┌─────┐ ┌─────┐ ┌──────┬──┐
                      │██├┘█████└┬┘█████└┬┘██████│▐▌│
                 ┌──┐ │██│██▄▄▄██│██┌─┐██│██▄▄▄▄ │▄▄│
                 │▒▒└─┘▒█│▒█┌─┐▒█│▒█│ │▒█│ ▀▀▀▀▒█│▒█│
                 └┐▓▓▓▓▓┌┤▓▓│ │▓▓│▓▓│ │▓▓│▀▓▓▓▓▓▀│▓▓│
                  └─────┘└──┘ └──┴──┘ └──┴───────┴──┘
    

    c:>java -jar C:\Apps\sqlcl\lib\jansi.jar Jansi 2.4.0

    library.jansi.path= library.jansi.version= Jansi native library loaded from C:\Users\hotline\AppData\Local\Temp\jansi-2.4.0-57cb32c49e8d6081-jansi.dll which was auto-extracted from jar:file:/C:/Apps/sqlcl/lib/jansi.jar!/org/fusesource/jansi/internal/native/Windows/x86_64/jansi.dll

    os.name= Windows 10, os.version= 10.0, os.arch= amd64 file.encoding= Cp1252 java.version= 17.0.5, java.vendor= Oracle Corporation, java.home= C:\Program Files\Java\jdk-17.0.5

    jansi.graceful= jansi.mode= jansi.out.mode= jansi.err.mode= jansi.colors= jansi.out.colors= jansi.err.colors= jansi.passthrough= false jansi.strip= false jansi.force= false jansi.noreset= false org.fusesource.jansi.Ansi.disable= false

    IS_WINDOWS: true IS_CONEMU: false IS_CYGWIN: false IS_MSYSTEM: false

    isatty(STDOUT_FILENO): 1, System.out is a terminal isatty(STDERR_FILENO): 1, System.err is a terminal

    Resulting Jansi modes for stout/stderr streams:

    • System.out: AnsiPrintStream{type=VirtualTerminal, colors=Colors16, mode=Default, resetAtUninstall=true}
    • System.err: AnsiPrintStream{type=VirtualTerminal, colors=Colors16, mode=Default, resetAtUninstall=true} Processor types description:
    • Native: Supports ansi sequences natively
    • Unsupported: Ansi sequences are stripped out
    • VirtualTerminal: Supported through windows virtual terminal
    • Emulation: Emulated through using windows API console commands
    • Redirected: The stream is redirected to a file or a pipe Colors support description:
    • Colors16: 16 colors
    • Colors256: 256 colors
    • TrueColor: 24-bit colors Modes description:
    • Strip: Strip all ansi sequences
    • Default: Print ansi sequences if the stream is a terminal
    • Force: Always print ansi sequences, even if the stream is redirected

    test on System.out: BLACK RED GREEN YELLOW BLUE MAGENTA CYAN WHITE DEFAULT bright: BLACK RED GREEN YELLOW BLUE MAGENTA CYAN WHITE DEFAULT bold: BLACK RED GREEN YELLOW BLUE MAGENTA CYAN WHITE DEFAULT faint: BLACK RED GREEN YELLOW BLUE MAGENTA CYAN WHITE DEFAULT bold+faint: BLACK RED GREEN YELLOW BLUE MAGENTA CYAN WHITE DEFAULT 256 colors:

         truecolor: /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
                    /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
                    /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
                    /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
                    /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
                    /\/\/\/\/\/\/\/\
    

    test on System.err: BLACK RED GREEN YELLOW BLUE MAGENTA CYAN WHITE DEFAULT bright: BLACK RED GREEN YELLOW BLUE MAGENTA CYAN WHITE DEFAULT bold: BLACK RED GREEN YELLOW BLUE MAGENTA CYAN WHITE DEFAULT faint: BLACK RED GREEN YELLOW BLUE MAGENTA CYAN WHITE DEFAULT bold+faint: BLACK RED GREEN YELLOW BLUE MAGENTA CYAN WHITE DEFAULT 256 colors:

         truecolor: /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
                    /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
                    /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
                    /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
                    /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
                    /\/\/\/\/\/\/\/\
    
                      ┌──┐┌─────┐ ┌─────┐ ┌──────┬──┐
                      │██├┘█████└┬┘█████└┬┘██████│▐▌│
                 ┌──┐ │██│██▄▄▄██│██┌─┐██│██▄▄▄▄ │▄▄│
                 │▒▒└─┘▒█│▒█┌─┐▒█│▒█│ │▒█│ ▀▀▀▀▒█│▒█│
                 └┐▓▓▓▓▓┌┤▓▓│ │▓▓│▓▓│ │▓▓│▀▓▓▓▓▓▀│▓▓│
                  └─────┘└──┘ └──┴──┘ └──┴───────┴──┘
    
    opened by centeiol 1
  • jansi dll constantly extracted to temp

    jansi dll constantly extracted to temp

    The code here: https://github.com/fusesource/jansi/blob/00e15cb1fab9117790580a412f7d54f2c08d2f11/src/main/java/org/fusesource/jansi/internal/JansiLoader.java#L168-L169

    Appends a randomUUID to the dll extracted from the jar.

    This has two potential issues:

    1. dll is extracted/deleted on every launch/exit.
    2. If the application does not exit cleanly (ie: crash) the dll is not deleted.

    The dll is already versioned, so my suggested change would be:

    1. Remove the uuid
    2. Add an arch identifier (ie: x86, aarch64, etc)
    3. Don't delete on exit, and don't re-extract if the dll already exists.

    This would improve startup/shutdown times, and stop cluttering temp when the application does not shutdown cleanly.


    Obviously the is more a design choice than a bug, but I just thought I'd log an issue to see what people thought. image

    opened by VirtualTim 0
  • AnsiConsole.systemInstall() should only increment

    AnsiConsole.systemInstall() should only increment "installed" if it succeeds without exception

    The counter is incremented first in https://github.com/fusesource/jansi/blob/00e15cb1fab9117790580a412f7d54f2c08d2f11/src/main/java/org/fusesource/jansi/AnsiConsole.java#L511, although exceptions like the following might be experienced:

    java.lang.ExceptionInInitializerError
    	at org.fusesource.jansi.AnsiConsole.ansiStream(AnsiConsole.java:239)
    	at org.fusesource.jansi.AnsiConsole.initStreams(AnsiConsole.java:542)
    	at org.fusesource.jansi.AnsiConsole.systemInstall(AnsiConsole.java:496)
    	at org.apache.maven.shared.utils.logging.MessageUtilsTest.testTerminalWidth(MessageUtilsTest.java:72)
    	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
    	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    	at java.base/java.lang.reflect.Method.invoke(Method.java:568)
    	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
    	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
    	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
    	at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
    	at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
    	at org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
    	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
    	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
    	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
    	at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
    	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
    	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
    	at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
    	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
    	at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
    	at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
    	at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:93)
    	at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:40)
    	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:529)
    	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:756)
    	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:452)
    	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:210)
    Caused by: java.lang.RuntimeException: Unable to load jansi native library
    	at org.fusesource.jansi.internal.JansiLoader.initialize(JansiLoader.java:62)
    	at org.fusesource.jansi.internal.CLibrary.<clinit>(CLibrary.java:30)
    	... 30 more
    Caused by: java.lang.Exception: No native library found for os.name=Mac, os.arch=aarch64, paths=[/Users/konradwindszus/Library/Java/Extensions:/Library/Java/Extensions:/Network/Library/Java/Extensions:/System/Library/Java/Extensions:/usr/lib/java:.]
    	at org.fusesource.jansi.internal.JansiLoader.loadJansiNativeLibrary(JansiLoader.java:333)
    	at org.fusesource.jansi.internal.JansiLoader.initialize(JansiLoader.java:60)
    	... 31 more
    

    That leads to the fact that a subsequent call of AnsiConsole.systemInstall() succeeds. Also it is not possible to call AnsiConsole.systemUninstall in case the exception from above has been experienced as that fails with

    java.lang.NullPointerException: Cannot invoke "org.fusesource.jansi.AnsiPrintStream.uninstall()" because "org.fusesource.jansi.AnsiConsole.out" is null
    	at org.fusesource.jansi.AnsiConsole.systemUninstall(AnsiConsole.java:524)
    	at org.apache.maven.shared.utils.logging.MessageUtils.doSystemUninstall(MessageUtils.java:101)
    	at org.apache.maven.shared.utils.logging.MessageUtils.systemUninstall(MessageUtils.java:80)
    	at org.apache.maven.shared.utils.logging.MessageUtilsTest.testSystem(MessageUtilsTest.java:59)
    	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
    	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    	at java.base/java.lang.reflect.Method.invoke(Method.java:568)
    	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
    	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
    	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
    	at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
    	at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
    	at org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
    	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
    	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
    	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
    	at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
    	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
    	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
    	at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
    	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
    	at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
    	at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
    	at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:93)
    	at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:40)
    	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:529)
    	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:756)
    	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:452)
    	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:210)
    
    opened by kwin 1
  • JANSI Not Executable In '/tmp' on CENTOS

    JANSI Not Executable In '/tmp' on CENTOS

    Hi All

    Wondering if anyone else has experienced a similar issue. I have recently upgraded to JDK 8 and Maven 3.8.5 and when i try mvn --version i get an error as such:

    Failed to load native library:jansi-2.4.0-bbb285ac9ffab828-libjansi.so. The native library file at /tmp/jansi-2.4.0-bbb285ac9ffab828-libjansi.so is not executable, make sure that the directory is mounted on a partition without the noexec flag, or set the jansi.tmpdir system property to point to a proper location. osinfo: Linux/x86_64 java.lang.UnsatisfiedLinkError: /tmp/jansi-2.4.0-bbb285ac9ffab828-libjansi.so: /tmp/jansi-2.4.0-bbb285ac9ffab828-libjansi.so: failed to map segment from shared object: Operation not permitted Apache Maven 3.8.5 (3599d3414f046de2324203b78ddcf9b5e4388aa0) Maven home: /opt/apache-maven-3.8.5 Java version: 1.8.0_251, vendor: Oracle Corporation, runtime: /opt/jdk1.8.0_251/jre Default locale: en_US, platform encoding: UTF-8 OS name: "linux", version: "3.10.0-1160.49.1.el7.x86_64", arch: "amd64", family: "unix"

    java version "1.8.0_251" Java(TM) SE Runtime Environment (build 1.8.0_251-b08) Java HotSpot(TM) 64-Bit Server VM (build 25.251-b08, mixed mode)

    I have also tried installing JANSI through yum and that does not seem to resolve it. sudo yum -y install jansi-native

    Any help or guidance on how to resolve this would be greatly appreciated.

    CentOS Linux release 7.9.2009 (Core)

    apache-maven-3.8.5

    jdk1.8.0_251

    opened by clementmark 12
JLine is a Java library for handling console input.

JLine JLine is a Java library for handling console input. It is similar in functionality to BSD editline and GNU readline but with additional features

null 1.2k Jan 5, 2023
A library for creating interactive console applications in Java

Text-IO Text-IO is a library for creating Java console applications. It can be used in applications that need to read interactive input from the user.

Beryx 295 Jan 5, 2023
Wrapper around ping command for Windows and MacOS

Wrapper around ping command for Windows and MacOS. Extended with functionality to intercept results provided by the ping command output (latency, ttl and etc.)

Vladislav Kozlov 1 Jan 6, 2022
Java library for creating text-based GUIs

Lanterna Lanterna is a Java library allowing you to write easy semi-graphical user interfaces in a text-only environment, very similar to the C librar

null 2k Dec 31, 2022
Command-line API for Atlassian JIRA using the Tomitribe CREST library

Atlassian JIRA Command-Line (CLI) Jamira is a command-line API for Atlassian JIRA using the Tomitribe CREST library. Installation Jamira can be downlo

Tomitribe 12 Sep 10, 2022
Java annotation-based framework for parsing Git like command line structures

Airline Airline is a Java annotation-based framework for parsing Git like command line structures. Latest release is 0.8, available from Maven Central

null 847 Nov 26, 2022
ASCII renderer in pure java with no external dependencies

Java ASCII Render ASCII renderer in pure java with no external dependencies. Java ASCII Render supports graphical primitives/elements, layers, context

David E. Veliev 140 Dec 12, 2022
Command line parsing framework for Java

JCommander This is an annotation based parameter parsing framework for Java 8. Here is a quick example: public class JCommanderTest { @Parameter

Cedric Beust 1.8k Dec 29, 2022
JCLR (JavaColor) is a library that allows you to write colored text in your terminal. It use the ANSI color system. Go check the README.md file to see how to use it.

JCLR JCLR (JavaColor) is a library that allows you to write colored text in your terminal. It use the ANSI color system. To start using it, go to the

Scythe 3 Aug 21, 2021
Terminal GUI library for simple ANSI console tools and graphical interfaces with Windows/Linux support

TerminalCore Terminal GUI library for Windows/Linux. This library contains all colors as ascii codes, native functions of the respective operating sys

Pascal 3 Oct 19, 2022
JVM Profiler Sending Metrics to Kafka, Console Output or Custom Reporter

Uber JVM Profiler Uber JVM Profiler provides a Java Agent to collect various metrics and stacktraces for Hadoop/Spark JVM processes in a distributed w

Uber Common 1.7k Dec 22, 2022
🎯 ConsoleCaptor captures console output for unit testing purposes

ConsoleCaptor Install library with: Install with maven <dependency> <groupId>io.github.hakky54</groupId> <artifactId>consolecaptor</artifactId

Hakan Altındağ 15 Dec 9, 2022
Turn -XX:+TraceBytecodes output into a FlameGraph compatible stack format

A tool to turn the output of -XX:+TraceBytecodes (a JDK debug-only feature to print every bytecode executed by the interpreter) into a simple stack fo

Claes Redestad 34 Dec 11, 2022
RxJava – Reactive Extensions for the JVM – a library for composing asynchronous and event-based programs using observable sequences for the Java VM.

RxJava: Reactive Extensions for the JVM RxJava is a Java VM implementation of Reactive Extensions: a library for composing asynchronous and event-base

ReactiveX 46.7k Dec 30, 2022
A mitigation for CVE-2021-44228 (log4shell) that works by patching the vulnerability at runtime. (Works with any vulnerable java software, tested with java 6 and newer)

Log4jPatcher A Java Agent based mitigation for Log4j2 JNDI exploits. This agent employs 2 patches: Disabling all Lookup conversions (on supported Log4

null 45 Dec 16, 2022
This minecraft plugin adds @a, @p, and @r to EssentialsX Commands! Works with command block and console aswell!

EssentialsX-Target-Selectors This minecraft plugin adds @a, @p, and @r to EssentialsX Commands! Works with command block and console aswell! Usage: Ju

null 6 Dec 7, 2022
A small library for parsing ItemStacks from a human-readable format

easy-item A small library for parsing ItemStacks from a human-readable format (1.16.5+, Java 11) TODO: Maybe add serialization (item to human-readable

Maximilian Dorn 3 Dec 4, 2021
A sample repo to help you use CDP console in Java-TestNG automation test on LambdaTest. Run Selenium tests with TestNG on LambdaTest platform.

How to use CDP console in Java-TestNG automation test on LambdaTest Environment Setup Global Dependencies Install Maven Or Install Maven with Homebrew

null 11 Jul 13, 2022