search

mabe02 / lanterna

Java library for creating text-based GUIs
GNU Lesser General Public License v3.0
2.24k stars 243 forks source link

Be possible to compile natively with graalvm (not yet possible) #481

Closed alexandrenavarro closed 4 years ago

alexandrenavarro commented 4 years ago

Be possible to compile natively with graalvm (not yet possible)

With graalvm, it is possible to compile to native a java application. The 2 main advantages is to use less memory and start quicker which is really useful when you develop a client application like commandline or terminal tool or ui to be competive on this 2 aspects compared to C/C++ or go application notably.

I tried to do a basic example with lanterna https://github.com/alexandrenavarro/java-terminal-sample, unfortunetally it does not work because of use sun.awt.dnd.SunDropTargetContextPeer$EventDispatcher . The static initialisation does not work (at build time or at runtime in graalvm) and I searched a little bit, I didn't find a quick solution. It is not linked to lanterna but the classes used by lanterna notably all AWT stuffs. It should be great to have this possibility in lanterna. I think you should contact graalvm if it is a bug in graalvm or a feature not yet implemented or there is a way to fix it by configuration.

Thanks for your awesome project.

pawelgalecki commented 4 years ago

Tried to reproduce it. Unfortunately, I was successful,so I did a little research and I found following information: Lanterna is Swing dependent and this issue is very common for Swing applications. What's more fixing this doesn't seem to be priority as Swing is slowly being replaced by javaFx. There are some successful attempts of running javaFx on GraalVM ( check https://github.com/gluonhq/substrate ) So I'd presume the only option is to remove Swing dependencies from laterna and make it work in headless mode only. I have also checked https://gitlab.com/klamonte/jexer/-/wikis/home - same problem. @alexandrenavarro do you need Swing support?

jrb0001 commented 4 years ago

AWT/Swing is already optional, see https://github.com/mabe02/lanterna/pull/429.

alexandrenavarro commented 4 years ago

Effectively, GraalVM does not support Swing/AWT, I thought it was the case and don't think they will support it. After your answer, I check the code why Swing/AWT is really mandatory and I discover defaultTerminalFactory.createHeadlessTerminal() in the new version and it works perfectly for my usecase and discover also the answer after on the issue link. I updated my repo with a basic terminal with lanterna and graalvm. So thank you again for answer and don't hesitate to add in your doc to use defaultTerminalFactory.createHeadlessTerminal() if you want to use graalvm.

rednoah commented 4 years ago

If you add -Djava.awt.headless=true to the native-image call, then that might just do the trick, and run all the initializers as if we're running on a headless machine.

Futurile commented 4 years ago

I've been able to compile native images for terminal, screen and GUI. I'm using GraalVM 20.1.0, with Java 11 (OpenJDK 11) on Linux.

The only problem is the AWT or Swing dependencies as these are not compatible with GraalVM as others mentioned.

Primarily this means that you have to avoid DefaultTerminalFactory, and create the terminal directly. I'm directly using UnixTerminal.

GraalVM has a 'tracing agent' that can help to determine class dependencies. I've been using that as part of my compile process which help a lot.

I'm using Clojure 1.10.1, shouldn't make any difference and I did one test program in Java that was fine.

mabe02 commented 4 years ago

@Futurile could you try again with the latest lanterna code (either one of the 3.0/3.1/master branches), I've pushed a change that removes the awt imports from DefaultTerminalFactory and I'm curious if that fixes it.