On Thu, 17 Oct 2019 15:28:31 GMT, Kevin Rushforth wrote:
> On Thu, 17 Oct 2019 15:28:30 GMT, mruzicka
> wrote:
>
>> On Thu, 17 Oct 2019 15:28:28 GMT, mruzicka
>> wrote:
>>
>>> Secondary event loop introduced as a means of synchronization with the
>>> JavaFX Application thread in [1] never
> JDK-8193502
Johan can comment on whether he wants to backport it. As noted below,
someone reported a regression associated with it when using gtk2, but we
don't have a bug filed or a test case.
> It might have been solved in the fix for JDK-8179073.
Not sure what you mean since
Could JavaFX 11 also get backported the fix related for JDK-8193502? It
might have been solved in the fix for JDK-8179073.
I noticed this regression right after JDK 9 build 161. Recently also JavaFX
8 got this regression after update 181.
It seems this was fixed in JavaFX 13.
I asked on GitHub
On Fri, 11 Oct 2019 05:52:33 GMT, Arunprasad Rajkumar
wrote:
> 8232158: [macOS] Fallback to command line tools if xcode is missing
>
>
>
> Commits:
> - 063d2f38: JDK-8232158: [macOS] Fallback to command line tools if xcode is
> missing
>
> Changes:
On Mon, 21 Oct 2019 11:10:32 GMT, Johan Vos wrote:
> The pull request has been updated with additional changes.
>
>
>
> Added commits:
> - f34a99a3: In order to leverage this on Mac, we need to add -DSTATIC_BUILD
> to the cc flags
>
> Changes:
> - all:
On Mon, 21 Oct 2019 10:03:24 GMT, Johan Vos wrote:
> This PR adds a JNI_OnLoad_prism_sw call to the static lib libprism_sw.a.
> This approach is similar to the addition of e.g. JNI_OnLoad_prism_es2 that
> has been done as part of https://bugs.openjdk.java.net/browse/JDK-8223760
>
> Unless
Changeset: a09a0fa5
Author:Kevin Rushforth
Date: 2019-10-21 16:45:26 +
URL: https://git.openjdk.java.net/jfx/commit/a09a0fa5
8232522: FX: Update copyright year in docs, readme files to 2020
Reviewed-by: arapte
! build.properties
!
On Sat, 19 Oct 2019 15:04:27 GMT, Kevin Rushforth wrote:
> As indicated in the JBS bug, this makes the needed change for releasing in
> 2020.
>
>
>
> Commits:
> - 85c03ad9: 8232522: FX: Update copyright year in docs, readme files to 2020
>
> Changes:
Actually, I did a quick check and there is more than just Pisces in the
native prism_sw library, so removing Pisces isn't sufficient to remove
prism_sw.
-- Kevin
On 10/21/2019 5:54 AM, Kevin Rushforth wrote:
This approach seems fine to me. Worth noting is that prism-sw will be
removed as
On Mon, 21 Oct 2019 10:19:06 GMT, Robert Lichtenberger
wrote:
> On Mon, 21 Oct 2019 10:19:05 GMT, Kevin Rushforth wrote:
>
>> On Mon, 21 Oct 2019 10:19:04 GMT, Robert Lichtenberger
>> wrote:
>>
>>> By using the collection itself as synchronization lock we achieve behaviour
>>> that
This approach seems fine to me. Worth noting is that prism-sw will be
removed as part of the Pisces removal by JDK-8196079 [1], which is
targeted for 14. If your proposed change helps in the mean time, then I
see no problem with getting it in.
-- Kevin
[1]
+1
-- Kevin
On 10/21/2019 3:16 AM, Johan Vos wrote:
Hi Kevin,
I request permission to backport the following issues to the jfx-11
repository. All patches apply clean or with minor changes (e.g.
build.properties must keep jfx.release.major.version to 11)
Thanks,
- Johan
Hi,
When creating static libraries for the native parts of JavaFX, I ran into
an issue with symbols exposed in more than 1 library:
checkAndClearException() is declared and used in both libjavafx_font.a and
in libprism_sw.a
I have a simple fix for this that adds a prefix to the symbol in the
The pull request has been updated with additional changes.
Added commits:
- f34a99a3: In order to leverage this on Mac, we need to add -DSTATIC_BUILD to
the cc flags
Changes:
- all: https://git.openjdk.java.net/jfx/pull/19/files
- new:
On Mon, 21 Oct 2019 10:19:05 GMT, Kevin Rushforth wrote:
> On Mon, 21 Oct 2019 10:19:04 GMT, Robert Lichtenberger
> wrote:
>
>> By using the collection itself as synchronization lock we achieve behaviour
>> that matches java.util.Collections classes.
>>
>> I've create test cases that fail
On Mon, 21 Oct 2019 10:19:04 GMT, Robert Lichtenberger
wrote:
> By using the collection itself as synchronization lock we achieve behaviour
> that matches java.util.Collections classes.
>
> I've create test cases that fail with the current way of synchronizing on a
> separate object.
>
>
By using the collection itself as synchronization lock we achieve behaviour
that matches java.util.Collections classes.
I've create test cases that fail with the current way of synchronizing on a
separate object.
I've removed unused constructors.
Commits:
- 7e80839f:
Hi Kevin,
I request permission to backport the following issues to the jfx-11
repository. All patches apply clean or with minor changes (e.g.
build.properties must keep jfx.release.major.version to 11)
Thanks,
- Johan
https://bugs.openjdk.java.net/browse/JDK-8221302 : Upgrade to gcc 8.2 on
This PR adds a JNI_OnLoad_prism_sw call to the static lib libprism_sw.a.
This approach is similar to the addition of e.g. JNI_OnLoad_prism_es2 that has
been done as part of https://bugs.openjdk.java.net/browse/JDK-8223760
Unless -PSTATIC_BUILD is provided when building, this patch has no
19 matches
Mail list logo
