GeezerVison

I'd like to second this. This change would also make it much easier to use JavaFX with py5.

Hi @vsquared and thanks for your suggestion. It looks like the current commit just adds a file to the root of the repository with instructions for modifying JavaBuild.java, instead of directly making the change in the file. Could you update the PR to modify JavaBuild.java directly instead so we can properly review the proposed changes?

After modifying two different Processing editors with the above change my observation is that adding the seven javafx jar files to the sketch folder is no longer necessary. I have no experience using javafx in IntelliJ or testing on a platform other than macos. My impression is that adding all the jar files to the sketch folder sometimes fails when trying to run javafx code in an editor that has not been modified. I cannot be 100% certain about this and it needs further study. Nevertheless, I don't think the average user wants to go to all the bother to find the seven jar files and copy them to the sketch folder just to run a javafx demo. It would be easier for everyone if a simple one line change was made to the editor. I know this works for macos, but have not tried it on Windows or Linux.
Addendum:
Processing 4.3 failed to run a javafx app with all seven jar files in sketch folder, either lying free or inside a 'code' folder. Another copy of a Processing 4.3 editor modified with the changes above will run the javafx demo without the addition of jar files.
Processing 4.3.1 on macos also failed to run a javafx app with all seven jar files in the sketch folder, both lying free and inside a 'code' folder.

@SableRaf - I did another fork of the main app and edited the JavaBuild.java file and submitted a second pull request.

Tested on windows, does indeed fix the issue you're describing, so happy to merge after the requested changes.
If you can find a user friendly way, e.g. not just adding the JavaFX jars to the code folder, please let me know. I would like to make that possible.

Cool thanks @vsquared!

I'll let you hit the merge button @SableRaf

@Stefterv - If you can find a user friendly way, e.g. not just adding the JavaFX jars to the code folder, please let me know. I would like to make that possible.
On macos if you make the changes I suggested the user should not need to add the jar files to the sketch folder.

@Stefterv Pull Request Followup: Thank you for adding the pull request changes. After the last release of the Processing IDE (v. 4.3.2) I have been able to run JavaFX demos on MacOS without adding a 'code' folder to the sketch or modifying/recompiling the editor as I was doing in the past. Because of this success I have started posting new JavaFX demos in the Forum with the anticipation that other users would be able to run them too. Unfortunatey this has not been the case for Windows or Linux users, as discussed here: https://discourse.processing.org/t/processing-and-javafx/45692/6 . They are able to run JavaFX demos, but only after creating a 'code' folder either by drag 'n dropping all seven of the JavaFX jar files onto an open sketch window or manually copy/pasting the jar files which are not easy to find in the 'libraries' folder. It appears that the Processing IDE correctly installs the JavaFX jar files but does not know that they are there and therefore unable to use them. It also appears that this is a known problem and is on the TODO list to fix. I'm willing to help track this down if I know where to start, but I am not a skilled Windows or Linux programmer. I do have Windows 11 and Linux PopOS systems which are rarely used but could be used for testing. Do you have any advice on where to start looking to solve this problem? I appreciate your time and efforts.

Hi @vsquared. Thanks for your follow-up and for testing on different platforms.

For the JavaFX compatibility issue specifically, I recommend opening a new issue, clarifying the current and intended behavior, as well as any proposed solution(s).

Note: Right now, our main focus is the Gradle migration, which is a major effort with very limited capacity (mostly just @Stefterv working on it). Long term, we are looking at moving away from JOGL and abstracting the renderer—this is part of the roadmap (see issue #881). If you have any thoughts on that and how JavaFX may support that goal, feel free to contribute to the discussion over there.

Appreciate your patience and contributions!