Re: JavaFX dialog window size regression
Can we get the fix for JDK-8179073 [1] backported to JavaFX 11? As discussed on the openjfx GitHub issue #222 [2]. It seems to have a fix already in PR #456 [3]. [1] https://bugs.openjdk.java.net/browse/JDK-8179073 [2] https://github.com/javafxports/openjdk-jfx/issues/222 [3] https://github.com/javafxports/openjdk-jfx/pull/456 /Sverre tor. 26. apr. 2018 kl. 21:35 skrev Sverre Moe : > I filed a bug report a while back. Since I didn't have access I could > not comment or update in that issue. > > https://bugs.openjdk.java.net/browse/JDK-8179073 > > With Java 9, a JavaFX dialogs got tiny and did not size up to its content. > This worked fine when I was running JDK 9 build 161, but after JDK 9 > build 165 the dialog window did not size up to show any of its > content. > > The code exampled I provided with that bug report still produces a > tiny dialog window with both jdk-9.0.4 and jdk-10.0.1 > > Setting the Dialog size to fixed width/height does not work, but if > with setResizable(true) the Dialog gets its full size. > > It has been a while since I have used Java 9. Today I got the same > problem while trying to exit SceneBuilder 9 downloaded from Gluon. > > I was wondering if I should re-create this bug report on the GitHub > OpenJFX repository? >
Re: RFR: 8231870: Updated armv6hf crosslibs script with new domains
On 10/8/19 1:41 AM, Johan Vos wrote: Rethinking the concept of cross-compiliation involves much more than just downloading a cross-compiler and libs, and we should not fix that in a rush. It would be nice to use the cross-compile tools that come with my system (Ubuntu 16.04) as I do when building the JDK. I may be able to help with that once I understand Gradle a lot better. For the JDK, I install the package "crossbuild-essential-armhf" and I get the GNU C Compiler for armhf: build/linux-arm-server-release/configure.log A new configuration has been successfully created in /home/ubuntu/src/jdk13/build/linux-arm-server-release using configure arguments '--openjdk-target=arm-linux-gnueabihf --with-native-debug-symbols=none'. ... Tools summary: * Boot JDK: openjdk version "12.0.2" 2019-07-16 OpenJDK Runtime Environment (build 12.0.2+10) OpenJDK 64-Bit Server VM (build 12.0.2+10, mixed mode, sharing) (at /home/ubuntu/opt/jdk-12.0.2) * Toolchain: gcc (GNU Compiler Collection) * C Compiler: Version 5.4.0 (at /usr/bin/arm-linux-gnueabihf-gcc) * C++ Compiler: Version 5.4.0 (at /usr/bin/arm-linux-gnueabihf-g++) Is a package like this not available where we build JavaFX for armhf? John
RFR: 8226754: FX build fails using gradle 5.6+ or 6
JBS issue: [JDK-8226754](https://bugs.openjdk.java.net/browse/JDK-8226754) As noted in the JBS bug, the JavaFX build fails with gradle 6 (as well as not building correctly with 5.6 or later). The existing JavaFX build uses two deprecated features that are removed in gradle 6, so the build fails when building with gradle 6. Additionally, some change that went into gradle 5.6 prevents all of our resource files (e.g., css files, images, shaders) from being included in the built artifacts, which causes JavaFX to be non-functional (our unit tests catch this failure). The purpose of this bug fix is to allow JavaFX to build with gradle 6, which is needed to allow building with JDK 13. We will likely upgrade to gradle 6 in the near future. Additionally, this fixes the resource bug that was exposed (or introduced) in gradle 5.6 and also affects gradle 6. The changes are as follows: 1. Remove unneeded STABLE_PUBLISHING setting, which was transitional to allow gradle 4.x to continue working while we moved to gradle 5.x 2. Use `ivy patternLayout ...` instead of `layout "pattern", ...` 3. Specify no metadata for ivy repositories 4. Set output.resourcesDir of sourceSet to match processResources.destinationDir 5. Bump minimum gradle version to 5.3 (since it will no longer run with gradle 4.x after change 1) I verified that the build artifacts produced by gradle 5.3 before and after this changes are identical (so it is behavior neutral for the supported version of gradle). After the fix, I also verified that the build artifacts produced by gradle 5.6.2 and 6.0 nightly match those produced by 5.3. I have tested this fully on Linux and Windows, and I will do a sanity test on Mac in parallel with the review. Commits: - bc6bd441: 8226754: FX build fails using gradle 5.6+ or 6 Changes: https://git.openjdk.java.net/jfx/pull/9/files Webrev: https://webrevs.openjdk.java.net/jfx/9/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8226754 Stats: 28 lines in 4 files changed: 17 ins; 4 del; 7 mod Patch: https://git.openjdk.java.net/jfx/pull/9.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/9/head:pull/9 PR: https://git.openjdk.java.net/jfx/pull/9
Re: RFR: 8087980: Add property to disable Monocle cursor
On Tue, 8 Oct 2019 12:03:44 GMT, Dell Green <12861109+dellgr...@users.noreply.github.com> wrote: > On Tue, 8 Oct 2019 12:03:42 GMT, Dell Green > <12861109+dellgr...@users.noreply.github.com> wrote: > >> Often on embedded systems a cursor is not a valid input modality. On some of >> these systems, when the javafx toolkit initialises the native hardware >> cursor, it produces artefacts which can be seen on screen (in the >> framebuffer for example). This change adds a system property >> "monocle.cursor.enabled" that can disable the creation of a native cursor in >> each of the Monocle NativePlatform implementations in favour of a NullCursor >> which is a no-op implementation of the NativeCursor abstract class that all >> native cursors have to implement. >> >> NullCursor class already existed and was being returned for some >> implementations like AndroidPlatform and HeadlessPlatform. This change >> builds upon that and conditionally returns NullCursor for all platforms. >> >> A system property "monocle.debugcursor" has also been added to turn on >> logging of which NativeCursor has been selected when the toolkit initialises. >> >> >> >> Commits: >> - cfbbc7dd: JDK-8087980: Add property to disable Monocle cursor >> >> Changes: https://git.openjdk.java.net/jfx/pull/5/files >> Webrev: https://webrevs.openjdk.java.net/jfx/5/webrev.00 >> Issue: https://bugs.openjdk.java.net/browse/JDK-8087980 >> Stats: 49 lines in 8 files changed: 40 ins; 0 del; 9 mod >> Patch: https://git.openjdk.java.net/jfx/pull/5.diff >> Fetch: git fetch https://git.openjdk.java.net/jfx pull/5/head:pull/5 > > JBS issue: https://bugs.openjdk.java.net/browse/JDK-8087980 > > /signed > /covered > > https://www.oracle.com/technetwork/community/oca-486395.html#i > > Ideaworks Ltd. - OpenJDK OpenJFX - dellgreen Hold on a minute. There is clearly some bug in the Skara tooling, since this change has *not* yet been reviewed, and is therefore *not* ready to integrate. am going to temporarily change the title in an attempt to force the jcheck bot to run again. I'll change it back once done. Failing this, I will ask the Skara admins to rerun the check if possible. If this doesn't work, we will need to close this PR and have you open a new one. PR: https://git.openjdk.java.net/jfx/pull/5
Re: RFR: 8231870: Updated armv6hf crosslibs script with new domains
On Tue, 8 Oct 2019 11:59:52 GMT, Kevin Rushforth wrote: > On Tue, 8 Oct 2019 11:58:43 GMT, Kevin Rushforth wrote: > >> On Tue, 8 Oct 2019 08:41:40 GMT, Johan Vos wrote: >> >>> On Mon, 7 Oct 2019 19:58:20 GMT, Dell Green >>> <12861109+dellgr...@users.noreply.github.com> wrote: >>> On Mon, 7 Oct 2019 17:42:21 GMT, Kenzie Togami <2093023+kenziero...@users.noreply.github.com> wrote: > On Mon, 7 Oct 2019 17:30:11 GMT, Kevin Rushforth wrote: > >> On Mon, 7 Oct 2019 13:35:51 GMT, Dell Green >> <12861109+dellgr...@users.noreply.github.com> wrote: >> >>> buildSrc/crosslibs-armv6hf.sh pulls down debian and raspbian packages >>> to be able to cross compile javafx for arm hard float. Up to now the >>> upstream distribution versions have been debian and raspbian wheezy, >>> but these are now end of life and have been archived to servers that >>> have different domain names. >>> >>> Tried to change to use jessie but this generates a whole load of >>> __THROWNL errors, so for now have updated the domain names to point to >>> new servers so that wheezy packages can still be retrieved and cross >>> compilation succeeds. >>> >>> https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8231870 >>> >>> >>> >>> Commits: >>> - bb4bcc9e: 8231870: Updated armv6hf crosslibs script with new >>> resource domain names for wheezy >>> >>> Changes: https://git.openjdk.java.net/jfx/pull/8/files >>> Webrev: https://webrevs.openjdk.java.net/jfx/8/webrev.00 >>> Issue: https://bugs.openjdk.java.net/browse/JDK-8231870 >>> Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod >>> Patch: https://git.openjdk.java.net/jfx/pull/8.diff >>> Fetch: git fetch https://git.openjdk.java.net/jfx pull/8/head:pull/8 >> >> buildSrc/crosslibs/crosslibs-armv6hf.sh line 232: >> >>> 231: http://archive.debian.org/debian/ wheezy main armhf \ >>> 232: libatk1.0-dev \ >>> 233: libatk1.0-0 \ >> >> The use of `http://` URLs to download artifacts is strongly discouraged, >> since it isn't secure. Is there a valid `https://` URL that can be used >> instead? I note that just substituting `http` with `https` in the above >> URL does not work. >> >> buildSrc/crosslibs/crosslibs-armv6hf.sh line 392: >> >>> 391: $DESTINATION \ >>> 392: http://legacy.raspbian.org/raspbian wheezy firmware armhf \ >>> 393: libraspberrypi-dev >> >> Same comment hear about using an `https` URL if possible. >> >> I don't have any particular issue with this change. It does highlight an >> existing problem where we are still using an `http` URL rather than >> `https`. That may or may not be something we can solve here. > > In general a lot of Debian package URLs are not HTTPS by default because > of apt's built-in signature checking, https://whydoesaptnotusehttps.com/. > However, it does seem like it should at least be supported, so it might > be a bug in the `debian.org` server config. > > Additionally, I see that the `getPackages` command doesn't check these > signatures. It probably should, but that's another PR. https for legacy.raspbian.org works >>> >>> I confirm that without the patch, the "cross-build tools" can not be >>> fetched. With this patch, the tools can be fetched and the build can be >>> created using these tools. >>> I think this PR is good as it is, as it fixes something that was broken. >>> >>> However, in general I think the concept of this crosslibs script is broken >>> for a number of reasons: >>> 1. for none of the other targets, we have a script for downloading the >>> toolchain. >>> 2. we have one big blob toolchain for all ARM devices, and do not take >>> advantage of new compilers/libraries/CPU's. Maintaining toolchains requires >>> work, and I think it is better that the OpenJFX repository focuses on the >>> source code, not on the build context. >>> >>> Rethinking the concept of cross-compiliation involves much more than just >>> downloading a cross-compiler and libs, and we should not fix that in a rush. >>> >>> I therefore propose to merge this PR. >> >> I am going to temporarily change the title in an attempt to force the jcheck >> bot to run again. I'll change it back once done. Failing this, I will ask >> the Skara admins to rerun the check if possible. If this doesn't work, we >> will need to close this PR and have you open a new one. > > Looks like that worked and reran jcheck. Please ignore the above comments. I added them to the wrong PR. This PR was and still is ready for review. PR: https://git.openjdk.java.net/jfx/pull/8
Re: RFR: 8087980: Add property to disable Monocle cursor
On Tue, 8 Oct 2019 12:03:42 GMT, Dell Green <12861109+dellgr...@users.noreply.github.com> wrote: > Often on embedded systems a cursor is not a valid input modality. On some of > these systems, when the javafx toolkit initialises the native hardware > cursor, it produces artefacts which can be seen on screen (in the framebuffer > for example). This change adds a system property "monocle.cursor.enabled" > that can disable the creation of a native cursor in each of the Monocle > NativePlatform implementations in favour of a NullCursor which is a no-op > implementation of the NativeCursor abstract class that all native cursors > have to implement. > > NullCursor class already existed and was being returned for some > implementations like AndroidPlatform and HeadlessPlatform. This change builds > upon that and conditionally returns NullCursor for all platforms. > > A system property "monocle.debugcursor" has also been added to turn on > logging of which NativeCursor has been selected when the toolkit initialises. > > > > Commits: > - cfbbc7dd: JDK-8087980: Add property to disable Monocle cursor > > Changes: https://git.openjdk.java.net/jfx/pull/5/files > Webrev: https://webrevs.openjdk.java.net/jfx/5/webrev.00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8087980 > Stats: 49 lines in 8 files changed: 40 ins; 0 del; 9 mod > Patch: https://git.openjdk.java.net/jfx/pull/5.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/5/head:pull/5 This has not yet been reviewed. It will need at least one reviewer with a Reviewer role in the project. Disapproved by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/5
Re: RFR: 8231870: Updated armv6hf crosslibs script with new domains
On Tue, 8 Oct 2019 11:58:43 GMT, Kevin Rushforth wrote: > On Tue, 8 Oct 2019 08:41:40 GMT, Johan Vos wrote: > >> On Mon, 7 Oct 2019 19:58:20 GMT, Dell Green >> <12861109+dellgr...@users.noreply.github.com> wrote: >> >>> On Mon, 7 Oct 2019 17:42:21 GMT, Kenzie Togami >>> <2093023+kenziero...@users.noreply.github.com> wrote: >>> On Mon, 7 Oct 2019 17:30:11 GMT, Kevin Rushforth wrote: > On Mon, 7 Oct 2019 13:35:51 GMT, Dell Green > <12861109+dellgr...@users.noreply.github.com> wrote: > >> buildSrc/crosslibs-armv6hf.sh pulls down debian and raspbian packages to >> be able to cross compile javafx for arm hard float. Up to now the >> upstream distribution versions have been debian and raspbian wheezy, but >> these are now end of life and have been archived to servers that have >> different domain names. >> >> Tried to change to use jessie but this generates a whole load of >> __THROWNL errors, so for now have updated the domain names to point to >> new servers so that wheezy packages can still be retrieved and cross >> compilation succeeds. >> >> https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8231870 >> >> >> >> Commits: >> - bb4bcc9e: 8231870: Updated armv6hf crosslibs script with new resource >> domain names for wheezy >> >> Changes: https://git.openjdk.java.net/jfx/pull/8/files >> Webrev: https://webrevs.openjdk.java.net/jfx/8/webrev.00 >> Issue: https://bugs.openjdk.java.net/browse/JDK-8231870 >> Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod >> Patch: https://git.openjdk.java.net/jfx/pull/8.diff >> Fetch: git fetch https://git.openjdk.java.net/jfx pull/8/head:pull/8 > > buildSrc/crosslibs/crosslibs-armv6hf.sh line 232: > >> 231: http://archive.debian.org/debian/ wheezy main armhf \ >> 232: libatk1.0-dev \ >> 233: libatk1.0-0 \ > > The use of `http://` URLs to download artifacts is strongly discouraged, > since it isn't secure. Is there a valid `https://` URL that can be used > instead? I note that just substituting `http` with `https` in the above > URL does not work. > > buildSrc/crosslibs/crosslibs-armv6hf.sh line 392: > >> 391: $DESTINATION \ >> 392: http://legacy.raspbian.org/raspbian wheezy firmware armhf \ >> 393: libraspberrypi-dev > > Same comment hear about using an `https` URL if possible. > > I don't have any particular issue with this change. It does highlight an > existing problem where we are still using an `http` URL rather than > `https`. That may or may not be something we can solve here. In general a lot of Debian package URLs are not HTTPS by default because of apt's built-in signature checking, https://whydoesaptnotusehttps.com/. However, it does seem like it should at least be supported, so it might be a bug in the `debian.org` server config. Additionally, I see that the `getPackages` command doesn't check these signatures. It probably should, but that's another PR. >>> >>> https for legacy.raspbian.org works >> >> I confirm that without the patch, the "cross-build tools" can not be >> fetched. With this patch, the tools can be fetched and the build can be >> created using these tools. >> I think this PR is good as it is, as it fixes something that was broken. >> >> However, in general I think the concept of this crosslibs script is broken >> for a number of reasons: >> 1. for none of the other targets, we have a script for downloading the >> toolchain. >> 2. we have one big blob toolchain for all ARM devices, and do not take >> advantage of new compilers/libraries/CPU's. Maintaining toolchains requires >> work, and I think it is better that the OpenJFX repository focuses on the >> source code, not on the build context. >> >> Rethinking the concept of cross-compiliation involves much more than just >> downloading a cross-compiler and libs, and we should not fix that in a rush. >> >> I therefore propose to merge this PR. > > I am going to temporarily change the title in an attempt to force the jcheck > bot to run again. I'll change it back once done. Failing this, I will ask the > Skara admins to rerun the check if possible. If this doesn't work, we will > need to close this PR and have you open a new one. Looks like that worked and reran jcheck. PR: https://git.openjdk.java.net/jfx/pull/8
Re: RFR: 8231870: Updated armv6hf crosslibs script with new domains
On Tue, 8 Oct 2019 08:41:40 GMT, Johan Vos wrote: > On Mon, 7 Oct 2019 19:58:20 GMT, Dell Green > <12861109+dellgr...@users.noreply.github.com> wrote: > >> On Mon, 7 Oct 2019 17:42:21 GMT, Kenzie Togami >> <2093023+kenziero...@users.noreply.github.com> wrote: >> >>> On Mon, 7 Oct 2019 17:30:11 GMT, Kevin Rushforth wrote: >>> On Mon, 7 Oct 2019 13:35:51 GMT, Dell Green <12861109+dellgr...@users.noreply.github.com> wrote: > buildSrc/crosslibs-armv6hf.sh pulls down debian and raspbian packages to > be able to cross compile javafx for arm hard float. Up to now the > upstream distribution versions have been debian and raspbian wheezy, but > these are now end of life and have been archived to servers that have > different domain names. > > Tried to change to use jessie but this generates a whole load of > __THROWNL errors, so for now have updated the domain names to point to > new servers so that wheezy packages can still be retrieved and cross > compilation succeeds. > > https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8231870 > > > > Commits: > - bb4bcc9e: 8231870: Updated armv6hf crosslibs script with new resource > domain names for wheezy > > Changes: https://git.openjdk.java.net/jfx/pull/8/files > Webrev: https://webrevs.openjdk.java.net/jfx/8/webrev.00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8231870 > Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod > Patch: https://git.openjdk.java.net/jfx/pull/8.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/8/head:pull/8 buildSrc/crosslibs/crosslibs-armv6hf.sh line 232: > 231: http://archive.debian.org/debian/ wheezy main armhf \ > 232: libatk1.0-dev \ > 233: libatk1.0-0 \ The use of `http://` URLs to download artifacts is strongly discouraged, since it isn't secure. Is there a valid `https://` URL that can be used instead? I note that just substituting `http` with `https` in the above URL does not work. buildSrc/crosslibs/crosslibs-armv6hf.sh line 392: > 391: $DESTINATION \ > 392: http://legacy.raspbian.org/raspbian wheezy firmware armhf \ > 393: libraspberrypi-dev Same comment hear about using an `https` URL if possible. I don't have any particular issue with this change. It does highlight an existing problem where we are still using an `http` URL rather than `https`. That may or may not be something we can solve here. >>> >>> In general a lot of Debian package URLs are not HTTPS by default because of >>> apt's built-in signature checking, https://whydoesaptnotusehttps.com/. >>> However, it does seem like it should at least be supported, so it might be >>> a bug in the `debian.org` server config. >>> >>> Additionally, I see that the `getPackages` command doesn't check these >>> signatures. It probably should, but that's another PR. >> >> https for legacy.raspbian.org works > > I confirm that without the patch, the "cross-build tools" can not be fetched. > With this patch, the tools can be fetched and the build can be created using > these tools. > I think this PR is good as it is, as it fixes something that was broken. > > However, in general I think the concept of this crosslibs script is broken > for a number of reasons: > 1. for none of the other targets, we have a script for downloading the > toolchain. > 2. we have one big blob toolchain for all ARM devices, and do not take > advantage of new compilers/libraries/CPU's. Maintaining toolchains requires > work, and I think it is better that the OpenJFX repository focuses on the > source code, not on the build context. > > Rethinking the concept of cross-compiliation involves much more than just > downloading a cross-compiler and libs, and we should not fix that in a rush. > > I therefore propose to merge this PR. I am going to temporarily change the title in an attempt to force the jcheck bot to run again. I'll change it back once done. Failing this, I will ask the Skara admins to rerun the check if possible. If this doesn't work, we will need to close this PR and have you open a new one. PR: https://git.openjdk.java.net/jfx/pull/8
Re: RFR: 8231870: Updated armv6hf crosslibs script with new domains
On Mon, 7 Oct 2019 19:58:20 GMT, Dell Green <12861109+dellgr...@users.noreply.github.com> wrote: > On Mon, 7 Oct 2019 17:42:21 GMT, Kenzie Togami > <2093023+kenziero...@users.noreply.github.com> wrote: > >> On Mon, 7 Oct 2019 17:30:11 GMT, Kevin Rushforth wrote: >> >>> On Mon, 7 Oct 2019 13:35:51 GMT, Dell Green >>> <12861109+dellgr...@users.noreply.github.com> wrote: >>> buildSrc/crosslibs-armv6hf.sh pulls down debian and raspbian packages to be able to cross compile javafx for arm hard float. Up to now the upstream distribution versions have been debian and raspbian wheezy, but these are now end of life and have been archived to servers that have different domain names. Tried to change to use jessie but this generates a whole load of __THROWNL errors, so for now have updated the domain names to point to new servers so that wheezy packages can still be retrieved and cross compilation succeeds. https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8231870 Commits: - bb4bcc9e: 8231870: Updated armv6hf crosslibs script with new resource domain names for wheezy Changes: https://git.openjdk.java.net/jfx/pull/8/files Webrev: https://webrevs.openjdk.java.net/jfx/8/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8231870 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/8.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/8/head:pull/8 >>> >>> buildSrc/crosslibs/crosslibs-armv6hf.sh line 232: >>> 231: http://archive.debian.org/debian/ wheezy main armhf \ 232: libatk1.0-dev \ 233: libatk1.0-0 \ >>> >>> The use of `http://` URLs to download artifacts is strongly discouraged, >>> since it isn't secure. Is there a valid `https://` URL that can be used >>> instead? I note that just substituting `http` with `https` in the above URL >>> does not work. >>> >>> buildSrc/crosslibs/crosslibs-armv6hf.sh line 392: >>> 391: $DESTINATION \ 392: http://legacy.raspbian.org/raspbian wheezy firmware armhf \ 393: libraspberrypi-dev >>> >>> Same comment hear about using an `https` URL if possible. >>> >>> I don't have any particular issue with this change. It does highlight an >>> existing problem where we are still using an `http` URL rather than >>> `https`. That may or may not be something we can solve here. >> >> In general a lot of Debian package URLs are not HTTPS by default because of >> apt's built-in signature checking, https://whydoesaptnotusehttps.com/. >> However, it does seem like it should at least be supported, so it might be a >> bug in the `debian.org` server config. >> >> Additionally, I see that the `getPackages` command doesn't check these >> signatures. It probably should, but that's another PR. > > https for legacy.raspbian.org works I confirm that without the patch, the "cross-build tools" can not be fetched. With this patch, the tools can be fetched and the build can be created using these tools. I think this PR is good as it is, as it fixes something that was broken. However, in general I think the concept of this crosslibs script is broken for a number of reasons: 1. for none of the other targets, we have a script for downloading the toolchain. 2. we have one big blob toolchain for all ARM devices, and do not take advantage of new compilers/libraries/CPU's. Maintaining toolchains requires work, and I think it is better that the OpenJFX repository focuses on the source code, not on the build context. Rethinking the concept of cross-compiliation involves much more than just downloading a cross-compiler and libs, and we should not fix that in a rush. I therefore propose to merge this PR. PR: https://git.openjdk.java.net/jfx/pull/8
