> 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…
> 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 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
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 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 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:
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.
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:
> 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 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
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
>>
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
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
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
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 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
>
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.
>
> 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
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 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:
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 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:
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
> 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: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
-
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:
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
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 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
>>
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
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
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
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 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
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
>
> 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
> 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
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
39 matches
Mail list logo