Hi Steve,
Thanks. I can also workaround it (with very limited changes) in another way
by overriding javafx.runtime.version with something specific to my app, and
its version (which will ultimately dictate the cache directory name) -- as
the chances of having a clash then, are astronomically low.
> A batch of typo and grammar fixes that were found by the spellchecker.
>
> Integration can wait until RDP 1/2.
Nir Lisker has updated the pull request with a new target base due to a merge
or a rebase. The pull request now contains seven commits:
- Fixed javadoc for internal Node methods
-
This also doesn't seem to affect apps running with the zulufx distributions
(the JRE with JavaFX bundled).
E.g. this build of JavaFX ensemble
https://www.jdeploy.com/~jdeploy-demo-javafx-ensemble
It uses Java 19, and OpenJFX 20, and it doesn't seem to create an .openjfx
directory anywhere that I c
Hi,
Thanks for the reply. Yes -- my project uses JFX JARs rather than jmods (as
many do). And the clashing application in question, must be the same. But
this is a real problem that occurred with a real user, and I only have a
handful of users.
Oracle signing the JFX DLLs, while an improvement, w
I think that went a bit under the radar as this only occurs when using
the maven dependencies. The SDK and jmod downloads do not have that
issue as they don't copy DLLs into any temp directory. Only the maven
jars have to do this.
About signing any JavaFX DLLs, that would indeed be a good addi
Hi,
I am surprised nobody else sees this bug as a higher-priority conversation
point.
It's troubling to see how running one self-contained application can break
another self-contained application (because of a cache that most JFX devs
wouldn't even know exist).
If one well-behaved JFX applicatio
