<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Christopher Schnick on foojay.io - Friends of OpenJDK</title><link>https://foojayio.github.io/website/today/author/christopher-schnick/</link><description>Articles written by Christopher Schnick on foojay.io - Friends of OpenJDK</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Tue, 12 Mar 2024 16:11:56 +0000</lastBuildDate><atom:link href="https://foojayio.github.io/website/today/author/christopher-schnick/index.xml" rel="self" type="application/rss+xml"/><item><title>Run JavaFX on the Windows Subsystem for Linux and More!</title><link>https://foojayio.github.io/website/today/javafx-on-wsl/</link><pubDate>Tue, 12 Mar 2024 16:11:56 +0000</pubDate><guid>https://foojayio.github.io/website/today/javafx-on-wsl/</guid><description>&lt;p&gt;&lt;strong&gt;What does it take to run standalone JavaFX applications on exotic Linux systems like the Windows Subsystem for Linux or some embedded systems? As you will see, not a lot! Familiarizing yourself with the native libraries required by JavaFX and the font loading process is all that is needed. Then, JavaFX applications can run on them out of the box if you set everything up correctly.&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;Most graphical Linux systems will automatically come with all the native libraries that are required by Java(FX) as these are pretty standard. Running a standalone Java(FX) application, which has been created with jlink or jpackage for example, on these systems works without having to put in any thought about possible dependencies. However, there are systems where this is not the case.&lt;/p&gt;</description></item><item><title>Java for desktop applications: Tips and Tricks (Part 1)</title><link>https://foojayio.github.io/website/today/java-for-desktop-applications-part-1/</link><pubDate>Fri, 24 Nov 2023 09:18:15 +0000</pubDate><guid>https://foojayio.github.io/website/today/java-for-desktop-applications-part-1/</guid><description>&lt;p&gt;&lt;strong&gt;As desktop applications have kind of become a niche topic, it&amp;rsquo;s getting harder to find information about up-to-date best practices for desktop development.&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;Since I have been doing this for many years now, I hope that I can share some of the lessons learned with other fellow desktop developers. Most items that are discussed here are taken straight from &lt;a href="https://github.com/xpipe-io/xpipe" target="_blank" rel="noopener noreferrer"&gt;XPipe&lt;/a&gt;
, the application I am working on right now. So if you&amp;rsquo;re skeptical or are interested in more details, you can take a look at the actual source code or try them in action yourself in the actual application.&lt;/p&gt;</description></item><item><title>Unconventional Remote Process Control in Java</title><link>https://foojayio.github.io/website/today/presenting-xpipe/</link><pubDate>Mon, 08 May 2023 14:03:08 +0000</pubDate><guid>https://foojayio.github.io/website/today/presenting-xpipe/</guid><description>&lt;p&gt;Have you ever wanted to control a remote process from a Java application? Essentially something like a &lt;code&gt;ProcessBuilder&lt;/code&gt; for remote systems that allows you to run and configure a process on almost any system and also supports all regular features that you would expect from it.&lt;/p&gt;
&lt;p&gt;Now obviously, this isn&amp;rsquo;t a revolutionary idea. You can easily take an SSH library like the &lt;a href="https://github.com/mwiede/jsch" target="_blank" rel="noopener noreferrer"&gt;newer jsch fork&lt;/a&gt;
 and use the &lt;code&gt;exec&lt;/code&gt; or &lt;code&gt;shell&lt;/code&gt; channel to control remote processes or remote shells by just copying and pasting some tutorial code. So what is this about then?&lt;/p&gt;</description></item></channel></rss>