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`.
Verified that builds and tests on all three platforms ran successfully.
Hi,
Looking at JMemoryBuddy, there are unused fields and methods. It's not
clear if they were left in by mistake or are part of future work.
* line 89: AssertCollectable assertCollectable = new
AssertCollectable(weakReference);
* line 237: the method setMxBeanProxyName
* line 309:
On Mon, 10 Jan 2022 21:09:15 GMT, John Hendrikx wrote:
>> This is an implementation of the proposal in
>> https://bugs.openjdk.java.net/browse/JDK-8274771 that me and Nir Lisker
>> (@nlisker) have been working on. It's a complete implementation including
>> good test coverage.
>>
>> This
On Thu, 13 Jan 2022 19:18:33 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
> flag
>
> I’m not sure jpackage handles the notarization. I had done it for a
> jpackage application and posted something on how to do it on my site. My
> builds are currently throwing some sort of error on that I haven’t looked
> at yet. The code signing and packaging I think all invoke native OS/X
>
> On Jan 20, 2022, at 9:23 AM, Steve Hannah wrote:
>
> My reason for a launcher is that I'm building an alternative to jpackage that
> uses npm for deployment/versioning/updates and allows you to build native
> bundles for all platforms (Mac/Linux/Windows) on any platform. I.e. You
>
My reason for a launcher is that I'm building an alternative to jpackage
that uses npm for deployment/versioning/updates and allows you to build
native bundles for all platforms (Mac/Linux/Windows) on any platform. I.e.
You don't need to be building on a Windows box to create a native windows
> On Jan 20, 2022, at 9:08 AM, Steve Hannah wrote:
>
> I just wanted to post an update on this in case it helps some future dev
> who gets stuck on the same issue.
>
You probably have good reasons for having your own launcher but you might want
to consider if jpackage could be an
I just wanted to post an update on this in case it helps some future dev
who gets stuck on the same issue.
It seems that on Mac OS you can't use JNI_CreateJavaVM() to launch the JVM
if you hope to use any GUI stuff.This issue is described in this issue:
No worries.
-- Kevin
On 1/20/2022 5:30 AM, Jeanette Winzenburg wrote:
Thanks for the cleanup, Kevin - and sry for having created the mess ;)
-- Jeanette
Zitat von Kevin Rushforth :
Yes, this happened because the bug was still targeted to openjfx18. I
had meant to go through all of the
Thanks for the cleanup, Kevin - and sry for having created the mess ;)
-- Jeanette
Zitat von Kevin Rushforth :
Yes, this happened because the bug was still targeted to openjfx18.
I had meant to go through all of the issues still targeted to
openjfx18 earlier this week, but then got busy
Thanks for all the help on this.
I have done some further digging and I think the current problem (with the
minimal test case) may not be JavaFX specific, but rather something related
to GUI in general on Mac OS. I changed the test to just use Swing but it
also hangs as soon as it tries to
Yes, this happened because the bug was still targeted to openjfx18. I
had meant to go through all of the issues still targeted to openjfx18
earlier this week, but then got busy with (too many) other things.
I'll fix up the JBS records.
Thanks.
-- Kevin
On 1/20/2022 4:13 AM, Jeanette
On Wed, 19 Jan 2022 19:43:38 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 17:26:44 GMT, Jose Pereda wrote:
>> Martin Fox has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Renamed test to match existing conventions along with minor cleanup.
>
> Looks good
@jperedadnr can you re-review this?
On Wed, 19 Jan 2022 19:43:38 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
>>
wondering what happened in https://github.com/openjdk/jfx/pull/684
(fix for https://bugs.openjdk.java.net/browse/JDK-8187307)
- requested integration (into master) after review approval
- the bots did the usual thingies (commit, comment/close the issue in jbs)
- the bots did some unusual
On Tue, 30 Nov 2021 12:32:37 GMT, Jeanette Winzenburg
wrote:
> The misbehaviour was that an edit handler received both a commit and cancel
> event when cell commitEdit is called. That happened whenever a collaborator
> reset the controls editing state (either directly or indirectly) while
>
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 Tue, 30 Nov 2021 12:32:37 GMT, Jeanette Winzenburg
wrote:
> The misbehaviour was that an edit handler received both a commit and cancel
> event when cell commitEdit is called. That happened whenever a collaborator
> reset the controls editing state (either directly or indirectly) while
>
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`.
Marked as reviewed by arapte (Reviewer).
-
PR:
That sounds correct indeed. I filed
https://bugs.openjdk.java.net/browse/JDK-8280369 for this.
Thanks for reporting!
- Johan
On Thu, Jan 20, 2022 at 6:14 AM Glavo wrote:
> I noticed that openjfx packaged in jar caches native libraries in
> ~/.openjfx/cache/${version}, it is not related to the
23 matches
Mail list logo
