Skip to content

Fix REG_APP_DIR to support jpackage application launchers - #1528

Open
tutimura-kg wants to merge 3 commits into
processing:mainfrom
tutimura-kg:fix-associate-issue
Open

Fix REG_APP_DIR to support jpackage application launchers#1528
tutimura-kg wants to merge 3 commits into
processing:mainfrom
tutimura-kg:fix-associate-issue

Conversation

@tutimura-kg

@tutimura-kg tutimura-kg commented Jun 19, 2026

Copy link
Copy Markdown

Description

This PR fixes an issue where the file association fails when Processing is packaged and launched using jpackage.

Currently, REG_APP_DIR relies directly on System.getProperty("user.dir"). However, when launched via a jpackage generated launcher, user.dir points to the directory from which the application was invoked (e.g., the current terminal directory or shortcut location), rather than the actual installation directory of processing.exe. This causes incorrect registry paths to be registered in checkAssociations().

Thus, launching via file association breaks the next launch via file association. And launching via shortcut fixes the file association. This has not surfaced as a major issue on Windows 11 because the File Manager can override registry-defined associations. However, it remains a hidden bug that this PR aims to fix.

Changes

  • Updated REG_APP_DIR to dynamically resolve the installation directory based on the location of the JAR file (via WindowsPlatform.class).
  • Added a fallback to the original user.dir behavior in case processing.exe cannot be found relative to the JAR location.
  • Kept the changes minimal to avoid any unexpected impact on the existing codebase.

This ensures that file associations (.pde, etc.) always register the correct absolute path of processing.exe, regardless of the working directory at launch.

@tutimura-kg tutimura-kg mentioned this pull request Jun 19, 2026
Open
@tutimura-kg

tutimura-kg commented Jun 22, 2026

Copy link
Copy Markdown
Author

The launcher executable created with jpackage continues to run as a process, so we can easily obtain the executable using ProcessHandle.current().info().command().orElse(null). We can make use of it. In this case, during debugging (launched by gradlew run), it will be ...\java.exe, so we will still need to substitute it with the current directory.

@catilac

catilac commented Jun 22, 2026

Copy link
Copy Markdown
Collaborator

Thanks @tutimura-kg. I am currently doing some fixes to the build system so we can commence releases again. Will review your work after that.

@catilac
catilac self-requested a review June 22, 2026 14:35
@catilac catilac assigned tutimura-kg and unassigned catilac Jun 22, 2026
@catilac

catilac commented Jun 23, 2026

Copy link
Copy Markdown
Collaborator

@tutimura-kg okie! the build system is fixed. i will review soon :)

@ntsuchimura

ntsuchimura commented Jun 24, 2026

Copy link
Copy Markdown

Ok, I'll be waiting.
For reference, I used regedit.exe to check the path of the associated executable file. I needed to type [F5] to update.
processing-assoc

@tutimura-kg

tutimura-kg commented Oct 29, 2026

Copy link
Copy Markdown
Author

Since this PR fixes a bug in Processing 4, I noticed that the repository guidelines recommend targeting 4.x for Processing 4 bug fixes. Would it make sense to retarget this PR to 4.x? I can update the base branch if that would be preferable.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@catilac catilac Awaiting requested review from catilac

Assignees

@tutimura-kg tutimura-kg

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

3 participants

@tutimura-kg @catilac @ntsuchimura