The AOT cache compatibility issues come when your boot module path differs between training and actual run. As long as that is not the case, you can use it without problem and load additional modules at runtime after it has started up.

With GraalVM, that is not possible. It still has the closed-world assumption.

Relating to the times JavaFX is mentioned in HN discussions, you can also see this as a showcase about what is possible with modern Java + JavaFX if used correctly. While JavaFX might not be the most trendy desktop framework out there, it is very much alive and still a very solid solution for creating stable desktop applications in Java.

It comes with the following features that you won't find in other templates:

- A fully up-to-date build using the latest features of JDK25, Gradle 9, JavaFX 25, WiX 6, and much more

- Native executable and installer generation for all operating systems using native tools

- A fully modularized build, including fully modularized dependencies and the usage of jmods

- JDK 25 Leyden AOT cache generation logic and customizable training run implementations

- A ready-to-deploy GitHub actions pipeline to automatically build and release your application on all platforms

- Close-to-native theming capabilities with AtlantaFX themes as the basis combined with many manual improvements

- Automated tracking of the system appearance settings with light/dark mode and accent colors

- Advanced error handling and issue tracking with built-in support for Sentry

- Markdown rendering capabilities out-of-the-box with flexmark and the JavaFX WebView

- Integrated ability to automatically codesign the application on Windows and macOS

- Robust state management for caches, persistent data, and more

- Many customization options available to users in a comprehensible settings menu

- Update check capabilities and notifications for new GitHub releases

- Built-in troubleshooting tools for developers and users, including debug mode, heap dump, and more

- Hot-reload capabilities for all resources, including reapplying stylesheets

- Plenty of checks to warn users about problems with their system configuration, environment, and compatibility

- Desktop and registry access support classes

- Robust dependency Linux package management and font handling, your application will even run in WSL

- Application instance management and coordination via inter-process communication

- System tray icon support and proper handling of AWT/Swing alongside JavaFX

- Built-in support for Jackson and Lombok

- Integrated translation support with user interface language changes applying instantly

- Application logo templates that look native on every operating system, including a macOS 26 liquid glass icon

- Included third-party open source licenses of all dependencies, plus the required license display in the application

So as you can see, this is not a basic template but instead a full application, just missing your custom application content to be plugged in. You can of course also customize any of the codebase, the idea is to fork the repository, not depend on it using a library. There is also documentation available at https://kickstartfx.xpipe.io

The licensing model is designed to allow open source projects to use it under an Apache 2.0 license and other proprietary forks to contact me for licensing. Essentially, the base license for everyone is GPL3, but you can contact me to get the permission to license it under the Apache 2.0 license. If you developing a personal project, the only thing you need to show for that is that you are developing your application in an open source repository. If you are a company, developing a closed-source application, and want to license it under something else than GPL3, you can also contact me for an offer. All dependencies are compatible with a permissive license like Apache as well.

Comments URL: https://news.ycombinator.com/item?id=45624942

Points: 2

# Comments: 0

You can run XPipe on a local LTSC installation, you just can't connect to one remotely because it thinks that you are connecting to a Windows Enterprise server. I will think about how to solve this the best way, because that wasn't on my radar

But there is very good support for nested shell connections and tunneling RDP over SSH. If your target system isn't reachable directly and require something like a bastion host connection first, you can still connect via RDP if you use SSH tunnels over multiple hops in XPipe.

- XPipe acts as an askpass program for SSH, meaning that it can listen to any password requests made from the ssh client, forward that your password manager, and reply with the password that the password manager returned. If you password manager supports the SSH-agent, XPipe can also use it to supply keys for ssh as well.

If your hypervisor is supported by libvirt, you should already be able to use it in XPipe.

If it does not support libvirt, then I guess this would need a separate integration. But I would have to look into that first as I have never used these tools you listed.

The only service it relies upon is the licensing server, but if you also don't want to use that to be fully independent, you can request an offline license. You can find the details about that on the pricing page.

Right now, there's no direct import from WinSCP, next best thing where it can import from is Putty

To preface that, the CLI is only very basic. The only real thing you can do with it is launch shell connections. For more advanced usage without the GUI, there is for example the Python API: https://docs.xpipe.io/guide/python-api

If you used XPipe a year ago, it's night and day compared to today in terms of features, stability, and performance.

The community version is pretty extensive in what you can do with it, so I think you can accurately judge whether the homelab plan is worth it for you by using it for a bit.