I noticed that openjfx packaged in jar caches native libraries in
~/.openjfx/cache/${version}, it is not related to the system and
architecture.
It should be noted that in fact, we can start programs with different
architectures on the same system. A typical example is that Windows x86
software
Point #1 is one of the known limitations of using javafx modules on the
classpath (and is one of the reasons we recommend against it), so that's
not surprising. And I see you found the workaround.
I wonder if it might have something to do with a shared library that is
being loaded in one case
>
> 1. If your main class extends Application, and you try to run it like:
> java -jar MyApplication.jar
> It will fail immediately with:
> Error: JavaFX runtime components are missing, and are required to run this
> application
> 2. If you "trick" it, by making your Application class a
I've reduced the problem down to something minimal and have found that:
1. If your main class extends Application, and you try to run it like:
java -jar MyApplication.jar
It will fail immediately with:
Error: JavaFX runtime components are missing, and are required to run this
application
2. If
On 1/19/22 2:12 PM, Steve Hannah wrote:
I have been resisting using modules for a long time because it just makes
things more complicated, ...
It also makes some things easier, though, and certainly smaller. It's
easier to use an old-school Makefile with modules, and using 'jlink' can
get a
Thanks for all the replies on this. I'm working on getting a minimal
example. Sadly I'm reduced to a hello-world JavaFX application that I
can't get running using Maven dependencies, even just doing it the plain
old way with "java -jar target/hello-world-1.0-SNAPSHOT.jar".
I get: "Error: JavaFX
On 1/19/2022 1:46 PM, Michael Hall wrote:
On Jan 19, 2022, at 2:13 PM, Matthias Bläsing wrote:
Unsupported != does not work!
But it might mean less tested. So you might have to worry about things like it
works here but does it work on Linux? It works with version x but does it work
> On Jan 19, 2022, at 2:13 PM, Matthias Bläsing
> wrote:
>
> Unsupported != does not work!
But it might mean less tested. So you might have to worry about things like it
works here but does it work on Linux? It works with version x but does it work
with y?
> At this point in time Apache
FWIW, in a draft of my earlier reply, I had written a comment pointing
out that JavaFX is only supported with modules. I didn't include it,
because I think it very unlikely that that's related to the problem.
I think a simple reproducer will be most helpful in tracking this down.
-- Kevin
Hi,
Am Mittwoch, dem 19.01.2022 um 13:49 -0600 schrieb Michael Hall:
>
> > They are included in the classpath. I'm not using modules.
>
> This one
> https://stackoverflow.com/questions/67854139/javafx-warning-unsupported-javafx-configuration-classes-were-loaded-from-unna
>
>
> On Jan 19, 2022, at 11:40 AM, Steve Hannah wrote:
>
> com.sun.javafx.application.PlatformImpl startup
> Exception in thread "Thread-5" java.lang.IllegalStateException: This
> operation is permitted on the event thread only; currentThread =
> Thread-5
Searching on…
> When a window is closed while handling performKeyEquivalent the same NSEvent
> might be passed to the new key window causing it to being processed twice.
> Long ago a fix was put in for this case; when the GlassWindow was closed a
> flag was set to ensure that we would return YES from
On Wed, 19 Jan 2022 16:25:17 GMT, Martin Fox wrote:
>> When a window is closed while handling performKeyEquivalent the same NSEvent
>> might be passed to the new key window causing it to being processed twice.
>> Long ago a fix was put in for this case; when the GlassWindow was closed a
>>
JDK 17.0.2 shipped yesterday as part of the January CPU release. We should
update the JavaFX 18 build to use that version, so this is targeted for `jfx18`.
-
Commit messages:
- 8280280: Update boot JDK to 17.0.2
Changes: https://git.openjdk.java.net/jfx/pull/721/files
Webrev:
On Wed, 19 Jan 2022 18:43:31 GMT, Kevin Rushforth wrote:
> JDK 17.0.2 shipped yesterday as part of the January CPU release. We should
> update the JavaFX 18 build to use that version, so this is targeted for
> `jfx18`.
I'd like two reviewers given that we are in ramp-down for JavaFX 18.
Very odd. If you can create a simple, standalone test case, ideally a
single, self-contained JavaFX application and a C main program as a
launcher, then you might want to file a bug at https://bugreport.java.com/
-- Kevin
On 1/19/2022 10:42 AM, Steve Hannah wrote:
Thanks for the reply.
>
On Wed, 19 Jan 2022 10:58:54 GMT, Abhinay Agarwal wrote:
> Release Notes for 17.0.2
This pull request has now been integrated.
Changeset: 3aa459eb
Author:Abhinay Agarwal
Committer: Kevin Rushforth
URL:
Thanks for the reply.
> What are the JVM args you use for launching?
vm_args.version = JNI_VERSION_1_6;
vm_args.options = options;
vm_args.nOptions = numOptions;
vm_args.ignoreUnrecognized = 1;
For options, I'm just using -Djava.class.path, though I have experimented
using
Hard to say what's going on without more information. What are the JVM
args you use for launching? Are the JavaFX modules jlink'ed into the JDK
or loaded via --module-path? As a debugging aid, you might try setting
the system property "javafx.verbose" to "true" before loading your
The following issue only seems to occur on Linux (Ubuntu 20.04.1), and only
when I try to launch the JVM from a custom C launcher using JNI. It does
not occur when launching the JVM as a separate process using the "java"
binary. It also does not occur on MacOS when using the same C launcher
On Wed, 19 Jan 2022 16:25:17 GMT, Martin Fox wrote:
>> When a window is closed while handling performKeyEquivalent the same NSEvent
>> might be passed to the new key window causing it to being processed twice.
>> Long ago a fix was put in for this case; when the GlassWindow was closed a
>>
On Wed, 19 Jan 2022 15:18:48 GMT, Kevin Rushforth wrote:
> Fixed a test dependency issue in `build.gradle` that causes a compilation
> failure when running `gradle test` if the `Assumptions` API from JUnit5 is
> used. I added a test that fails to compile without the build fix and passes
>
On Wed, 19 Jan 2022 16:38:58 GMT, Martin Fox wrote:
>> tests/system/src/test/java/test/robot/javafx/scene/DoubleShortcutProcessing.java
>> line 53:
>>
>>> 51: // When a key equivalent closes a window it can be passed
>>> 52: // to the new key window and processed twice.
>>> 53: public class
On Tue, 18 Jan 2022 23:35:43 GMT, Jose Pereda wrote:
>> Martin Fox has refreshed the contents of this pull request, and previous
>> commits have been removed. The incremental views will show differences
>> compared to the previous content of the PR. The pull request contains one
>> new commit
> When a window is closed while handling performKeyEquivalent the same NSEvent
> might be passed to the new key window causing it to being processed twice.
> Long ago a fix was put in for this case; when the GlassWindow was closed a
> flag was set to ensure that we would return YES from
Fixed a test dependency issue in `build.gradle` that causes a compilation
failure when running `gradle test` if the `Assumptions` API from JUnit5 is
used. I added a test that fails to compile without the build fix and passes
with the fix.
This was first discovered when testing the patch for PR
On Tue, 18 Jan 2022 17:26:15 GMT, Martin Fox wrote:
>> When a window is closed while handling performKeyEquivalent the same NSEvent
>> might be passed to the new key window causing it to being processed twice.
>> Long ago a fix was put in for this case; when the GlassWindow was closed a
>>
On Wed, 19 Jan 2022 14:16:14 GMT, Abhinay Agarwal wrote:
>> Release Notes for 17.0.2
>
> Abhinay Agarwal has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Remove build and test changes
Marked as reviewed by kcr (Lead).
-
PR:
On Tue, 18 Jan 2022 17:26:15 GMT, Martin Fox wrote:
>> When a window is closed while handling performKeyEquivalent the same NSEvent
>> might be passed to the new key window causing it to being processed twice.
>> Long ago a fix was put in for this case; when the GlassWindow was closed a
>>
> Release Notes for 17.0.2
Abhinay Agarwal has updated the pull request incrementally with one additional
commit since the last revision:
Remove build and test changes
-
Changes:
- all: https://git.openjdk.java.net/jfx17u/pull/28/files
- new:
On Wed, 19 Jan 2022 13:06:14 GMT, Abhinay Agarwal wrote:
>> Release Notes for 17.0.2
>
> Abhinay Agarwal has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Add security fix
The latest addition looks good. Per the above discussion, you should
On Wed, 19 Jan 2022 12:48:32 GMT, Abhinay Agarwal wrote:
>> doc-files/release-notes-17.0.2.md line 17:
>>
>>> 15: [JDK-8272638](https://bugs.openjdk.java.net/browse/JDK-8272638)|Update
>>> copyright header for files modified in 2021|other
>>> 16:
> Release Notes for 17.0.2
Abhinay Agarwal has updated the pull request incrementally with one additional
commit since the last revision:
Add security fix
-
Changes:
- all: https://git.openjdk.java.net/jfx17u/pull/28/files
- new:
On Wed, 19 Jan 2022 12:18:40 GMT, Kevin Rushforth wrote:
>> Abhinay Agarwal has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Fix formatting
>
> doc-files/release-notes-17.0.2.md line 17:
>
>> 15:
Zitat von Marius Hanl :
I think I had the same issues some days ago. What helped was to delete all
the 'build' or 'target' or 'out' folders - so basically all the folders
with the compiled files.
thanks for the suggestion - didn't help, unfortunately
wondering what is
On Wed, 19 Jan 2022 11:30:10 GMT, Abhinay Agarwal wrote:
>> Release Notes for 17.0.2
>
> Abhinay Agarwal has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Fix formatting
The list of bugs fixed looks correct, with the addition of the
> Release Notes for 17.0.2
Abhinay Agarwal has updated the pull request incrementally with one additional
commit since the last revision:
Fix formatting
-
Changes:
- all: https://git.openjdk.java.net/jfx17u/pull/28/files
- new:
On Wed, 19 Jan 2022 10:58:54 GMT, Abhinay Agarwal wrote:
> Release Notes for 17.0.2
doc-files/release-notes-17.0.2.md line 18:
> 16: | [JDK-8272638](https://bugs.openjdk.java.net/browse/JDK-8272638) |
> Update copyright header for files modified in 2021 | other|
> 17: |
Release Notes for 17.0.2
-
Commit messages:
- 8280172: Create release notes for JavaFX 17.0.2
Changes: https://git.openjdk.java.net/jfx17u/pull/28/files
Webrev: https://webrevs.openjdk.java.net/?repo=jfx17u=28=00
Issue: https://bugs.openjdk.java.net/browse/JDK-8280172
Stats:
39 matches
Mail list logo
