DefaultTerminalFactory Graal native-image support

[reibitto]

Resolves #440

I was able to workaround this without needing to do any module splitting. The issue is that the runtime checks in TerminalFactory.createTerminal isn't enough to tell Graal that AWT/Swing isn't going to be needed. I created a createHeadlessTerminal method which can be verified AOT that the emulators aren't going to be used. Using createHeadlessTerminal I'm able to use lanterna + native-image without any issues.

I'm not sure how you feel about this solution. It's simple, but maybe adding a new method to TerminalFactory isn't ideal? But I don't see many other alternatives.

[jrb0001]

Splitting the module and then using SPI to load the implementations sounds like the more flexible option. But I have no idea how Graal would behave with such a setup and I don't trust it too much after reading about this AWT/Swing issue (the fact that java.desktop isn't needed at runtime is already known at compile time and thus Graal should know that as well).

How well does createHeadlessTerminal(...) work on Windows? I would expect "not at all" for all three modes: regular classpath (maybe native bindings as a workaround), JPMS and Graal.

[reibitto]

Hmm, I'm not sure about Windows. I'll look into it tomorrow. But yeah, you might be right about that.

[reibitto]

After a lot of setup work for Windows and Graal native-image and fixing 4 or 5 different issues I came across, I finally ran into this blocker: oracle/graal#1870. So it looks like that particular experiment will have to wait until next year.

Besides Graal though, I ran into the known issues with lanterna and Windows. WindowsTerminal isn't complete and not in a working state currently, which I can understand given this #422. But even the cygwin support is currently not working which I wasn't expecting to be the case. I missed this issue: #421. I ran into the exact same thing with "/bin/stty" not being found.

So looks like I'm all out of options when it comes to Windows. I guess I can only provide a native executable for Mac and Linux, and continue to rely on the plain JVM + Swing for Windows.

[mabe02]

Cygwin support proved to be next to impossible unfortunately, I'll remove it from master branch

[mabe02]

So what's the status on this PR, is it ready to be merged? If it only works on Mac+Linux, that's better than nothing.

[reibitto]

It's confirmed to be working on macOS at least. I imagine Linux too since it's the same code path.

The goal is to have some sort of solution for Windows too, but I can see that's going to take a lot of time and effort on both fronts. Firstly, there's not much point pursuing it for now since Graal native-image support on Windows is still experimental. I imagine it could take over a year for it to be in a usable state.

Then there's the lanterna Windows support issue. If cygwin support is being dropped, maybe I'll have to look into the native implementation and get that fully tested and stable. Not sure how much work that will be, but it's definitely something I'm interested in supporting. Depending on how successful my upcoming open source project becomes, I might be able to get some help with that. We'll see. This is still months down the line.

[buko]

Cygwin support proved to be next to impossible unfortunately, I'll remove it from master branch

I wonder why Cygwin support is being removed? We actually just got it working finally here a few months ago.

[mabe02]

I decided to leave Cygwin in after all, since it is possible to get it somewhat working.