search

fusesource / jansi

Jansi is a small java library that allows you to use ANSI escape sequences to format your console output which works even on windows.
http://fusesource.github.io/jansi/
Apache License 2.0
1.11k stars 140 forks source link

Add support for Android #225

Open ghost opened 2 years ago

ghost commented 2 years ago

Currently, the Termux app provides openjdk-17 as a package which can run on Android devices. So gradle, maven etc packages are also needed to be add as a package for supporting building with Java. We already added the gradle package. But for maven, which uses your Jansi, doesn't support on terminal because of incompatible architecture, as Android doesn't have a library 'libc.so.6', showing error:

Screenshot_2021-10-17-14-22-46-497_com termux

Please add support for Android platform, you can use the Android-NDK for compiling native libraries for various Android architectures, compiling with it will link 'libc.so' instead of 'libc.so.6' which is available in the Android OS framework.

advancedwebdeveloper commented 2 years ago

~/nifi-1.15.0/minifi $ mvn --version Failed to load native library:jansi-2.4.0-5abe82c1e27b751f-libjansi.so. osinfo: Linux/arm64 java.lang.UnsatisfiedLinkError: /data/data/com.termux/files/usr/tmp/jansi-2.4.0-5abe82c1e27b751f-libjansi.so: dlopen failed: library "libc.so.6" not found: needed by /data/data/com.termux/files/usr/tmp/jansi-2.4.0-5abe82c1e27b751f-libjansi.so in namespace (default) Apache Maven 3.8.4 (9b656c72d54e5bacbed989b64718c159fe39b537) Maven home: /data/data/com.termux/files/usr/opt/maven Java version: 17-internal, vendor: N/A, runtime: /data/data/com.termux/files/usr/opt/openjdk Default locale: en, platform encoding: UTF-8 OS name: "linux", version: "4.19.127-g127475f6d88e-dirty", arch: "aarch64", family: "unix" ~/nifi-1.15.0/minifi $ java --version openjdk 17-internal 2021-09-14 OpenJDK Runtime Environment (build 17-internal+0-adhoc..src) OpenJDK 64-Bit Server VM (build 17-internal+0-adhoc..src, mixed mode) ~/nifi-1.15.0/minifi $ javac --version javac 17-internal

MERAJ774 commented 2 years ago

~/nifi-1.15.0/minifi $ mvn --version Failed to load native library:jansi-2.4.0-5abe82c1e27b751f-libjansi.so. osinfo: Linux/arm64 java.lang.UnsatisfiedLinkError: /data/data/com.termux/files/usr/tmp/jansi-2.4.0-5abe82c1e27b751f-libjansi.so: dlopen failed: library "libc.so.6" not found: needed by /data/data/com.termux/files/usr/tmp/jansi-2.4.0-5abe82c1e27b751f-libjansi.so in namespace (default) Apache Maven 3.8.4 (9b656c72d54e5bacbed989b64718c159fe39b537) Maven home: /data/data/com.termux/files/usr/opt/maven Java version: 17-internal, vendor: N/A, runtime: /data/data/com.termux/files/usr/opt/openjdk Default locale: en, platform encoding: UTF-8 OS name: "linux", version: "4.19.127-g127475f6d88e-dirty", arch: "aarch64", family: "unix" ~/nifi-1.15.0/minifi $ java --version openjdk 17-internal 2021-09-14 OpenJDK Runtime Environment (build 17-internal+0-adhoc..src) OpenJDK 64-Bit Server VM (build 17-internal+0-adhoc..src, mixed mode) ~/nifi-1.15.0/minifi $ javac --version javac 17-internal

gnodet commented 11 months ago

Would that be fixed by #246 ?

Glavo commented 10 months ago

I think it is possible to implement a provider based on the tty/stty command and use it for Android support.

Glavo commented 10 months ago

Screenshot_2023-10-05-00-02-39-713_com termux

Glavo commented 10 months ago

After merging #270, I will to do some further refactoring.

I want jansi to use stty if jni is not available. In order to do this, I need to change the usage of jansi.graceful to decouple it from the jni provider.

gnodet commented 10 months ago

After merging #270, I will to do some further refactoring.

I want jansi to use stty if jni is not available. In order to do this, I need to change the usage of jansi.graceful to decouple it from the jni provider.

While I'm very glad you work on all those new features, but I'm really starting to wonder if it would make more sense to somehow merge jansi inside jline at some point, keeping jansi the low level library for jline capabilities. It really looks like a lot of duplication to me with all those providers, are a lot of this code is already present in jline and we're just missing the FFM (PR ready) and the new static-native one.

Glavo commented 10 months ago

While I'm very glad you work on all those new features, but I'm really starting to wonder if it would make more sense to somehow merge jansi inside jline at some point, keeping jansi the low level library for jline capabilities. It really looks like a lot of duplication to me with all those providers, are a lot of this code is already present in jline and we're just missing the FFM (PR ready) and the new static-native one.

If there is no MingwSupport, then this point is debatable. But since we already have MingwSupport, what we need is already included in jansi, and #270 needs it to use it on Linux, so we don't need to add anything new after it, just make some adjustments to what we already have.

Other than that, the adjustments to jansi.graceful I think are leftover work after creating AnsiConsoleSupport. The current logic is a bit strange for AnsiConsoleSupport. If the user does not use the jni provider, this property will not take effect. At the same time, it will also cause the traversal of the provider list to stop on jni when -Djansi.graceful=true, even if jni is not working. So I think refactoring is necessary.

We really don't have much left to do beyond this necessary refactoring. I only had to edit AnsiConsoleSupportHolder slightly and get jansi working on any POSIX platform in less than ten lines of code.