blog/java-to-a-native-linux-app/

[giscus[bot]]

blog/java-to-a-native-linux-app/

The new native Linux port compiles your Java to a single self-contained ELF through ParparVM and GTK3, with no JVM on the target machine. It runs on an ancient universal glibc, supports musl for Alpine, and ships for both x64 and arm64.

https://www.codenameone.com/blog/java-to-a-native-linux-app/

[jsfan3]

Hi Shai, thank you for the detailed write-up. Small note: it looks like the Mermaid flowchart was included as raw code in the article instead of being rendered as the actual diagram.

I also had a couple of related questions/observations. Are the desktop targets, Linux, Windows, and macOS, currently the only Codename One targets that do not use native interfaces? If native desktop integrations were ever added in the future, would they likely need to be implemented in C/C++, or would another approach make more sense?

I’m asking because in the Linux desktop world it is quite common for applications to call CLI tools behind the scenes for certain integrations. I’m not sure whether something like that would be possible, or even desirable, in the context of CN1.

One more practical note: I just created a new project with the Initializr, but I don’t see a Linux desktop target among the Maven goals shown in IntelliJ.

Separately, there may also be something to adjust in the CSS generated by the Initializr. The generated app seems to render correctly only in dark mode. In light mode, some colors look wrong, for example the toolbar appears black.

[shai-almog]

Thanks, there was a race condition between mermaid and the on-load stuff. Fixed that now.

The update to the initializr seems to have failed, we're looking into that. We'll add the Linux directory. The theme issue is probably due to the use of the modern theme, this is something we're working on improving right now in this PR: #5274 essentially what we're trying to do is grab screenshots from native widgets then compare them to Codename One widgets and if they look similar the test passes. That way we have a deterministic test that indicates if we drift too far from native OS look and feel which will make it easier to keep up with changing device native widgets.

All the desktop targets should support native interfaces. Windows uses the win directory, Linux should use a linux directory and both should create C based native interfaces (developer guide is updated and so is generate native interfaces).

The Mac target uses the same target as iOS, that means the iOS native interfaces are shared with the Mac target. If you need Mac specific code you can use an ifdef to qualify that. I think that's probably the best approach and will make the process easier.

[jsfan3]

Thanks, Shai. I downloaded a new Initializr project. Here are my observations:

1. The only non-hidden folders present are android, common, ios, javascript, javase, and linux; the win folder is missing.

2. The theme issue is in the CSS related to “Initializr Theme Overrides” (rows 73–97). Removing these lines resolves the issue in light mode. Incidentally, Initializr no longer has any theme options, so it’s unclear where these overrides are coming from. In my opinion, it would be helpful for new Codename One developers to provide a default CSS that works well out-of-the-box in both light and dark modes.

3. The “Linux desktop build” target still does not appear in IntelliJ.

[shai-almog]

Thanks. I'm working on a fix. Windows was a pain. We had a special case that deleted the old UWP win directory for the Java 17 support because it wasn't supported there. Then we decided to reuse the "win" name for the win32 target but didn't remove the code that deletes the directory. Ugh. Should probably be fixed later today at some point.