Why have an external launcher?

There are two main reasons:

  1. Remove self-dependency injection of JavaFX in the Recaf app itself.
    • In the older iterations of Recaf we would do everything this launcher does in the background. Managing the JavaFX dependency externally ensures that we don't have to do anything nasty or hacky.
  2. Remove auto-updater behavior from the Recaf app itself.
    • Recaf can still tell you that there is an update available, but it won't attempt to automate the process by itself.
    • This is more friendly towards environments like Brew/AUR which manage the app (vs the app managing itself).

How was this handled in the past?

If you ran Recaf 2.X with JavaFX on the classpath, nothing special happens. However, if you did not have JavaFX on the classpath...

  1. Recaf would check for the latest version of JavaFX and then download the artifacts deemed to be the closest fit for your operating system.
  2. Recaf would then hijack the module system and disable reflection access restrictions
  3. Recaf can now use unrestricted reflection to grab an instance of the internal application classloader and inject JavaFX into it
    • Because the internals moved around a bit between versions, there's some conditional logic to tweak how this is done before and after certain releases
    • This loader has a private field ucp which is a wrapper holding q List<URL> pointing to all classpath entries
    • Normally this list will only hold the standard path + anything given via -cp but we want to add JavaFX
    • Doing List.add by itself does not notify the runtime of any changes, but thankfully they expose an addUrl(URL) method
      • We call that for each of the JavaFX artifacts we downloaded earlier
    • If nothing has thrown an exception so far, JavaFX should now magically load when we first reference it later on during execution

But now with a launcher I have an extra layer between me and Recaf

Both the GUI and CLI launchers allow you to immediately run Recaf, making the launcher effectively invisible.

The GUI asks you how it should behave when you first use it. The first option, which is also selected by default, will show the launcher every time you run it. The second option though will attempt to update Recaf and then run it without ever showing the launcher. The third option immediately runs Recaf without ever updating. These last two options result in the launcher immediately opening Recaf, unless there is an update available if you selected the second option.

The CLI launcher offers set-default-action as a command. You can configure the launcher to do auto if you want to always update then run Recaf, or run if you want to run Recaf without ever updating. Once the value is set any use of java -jar launcher.jar will immediately run the specified action (and in turn, open Recaf).

But I really don't want to use a launcher...

Totally understandable, please refer to the prior page "manual installation" on how to grab Recaf for strictly offline usage. Additionally, Recaf is a regular Java project so its relatively easy to clone and build the project from source too.

The launcher exists as a middle ground between the average "end user" and what I will refer to as "power users". Average end users generally don't care how something opens unless it is annoying. The launcher may be a level of indirection, but it provides single click updates without them having to remember to open a web browser, download a new version of Recaf and update their local copy. That sounds simple but most of the time they don't bother to do that, so making it easy to update is ideal (Users can report a bug, and then click it once their ticket / message is addressed). Most of the users of Recaf from my observation fall into this category.

Then there are the "power users". These are generally highly technical users that have use an OS like Arch Linux and desire a very specific setup for their installed software. If your software doesn't align with their desired setup, they either wont use your software or will post a wall of text explaining how it doesn't align with Unix/FOSS princples. Different power users also have different desired setups which. For these users its best to hand them the tools they need and tell them to figure it out themselves, because if you try and figure it out for them, you will do it wrong. Something all power users universally hate though is auto-updating software. That used to be a feature of Recaf where if you would run it, it was capable of updating itself. That is no longer the case and now updating is a task relegated to the launcher.