It seems my attachment has again been ‚consumed‘ by the list. Trying again with an archive containing the patch file.
Regards, Alexander
> Am 08.07.2016 um 23:28 schrieb Alexander Nyssen <alexan...@nyssen.org>: > > Hi Kevin, all, > > attached please find a revised patch, where I have added the required export > to PlatformImpl and have fixed the build script, so it does no longer break > when being executed in jigsaw mode. > > As swt is no named module yet, I have disabled the JUnit test in jigsaw mode > for now. We would probably have to set up swt as a named module to enable > this, and would further have to make swt-debug.jar available as an automated > module on its module path. But this is a different problem. > > Regards, > Alexander > > >> Am 30.06.2016 um 12:14 schrieb Alexander Nyssen <alexan...@nyssen.org>: >> >> Hi Kevin, >> >>> Am 30.06.2016 um 01:20 schrieb Kevin Rushforth <kevin.rushfo...@oracle.com>: >>> >>> Hi Alexander, >>> >>> I attached the patch to the bug: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8088147 >>> >>> If I build it and run the manual test in "legacy" mode, meaning run >>> everything with 9+109 and the legacy jfxrt.jar file, then it runs and the >>> cursor now changes. So this looks like a good starting point for a fix. >> >> Fine. >> >>> >>> I tried building and running this in Jigsaw mode (building with jdk-9+109, >>> but running the tests with a more recent JDK that includes modularization >>> support), and noticed two problems right away that must be addressed: >>> >>> 1. The unit tests for SWT are missing some of the jigsaw test tasks so the >>> build fails right away with an exception from gradle: >>> >>>> Task with name 'jigsawTestsLinux' not found in project ':swt'. >>> >>> Wiring up SWT-based tests to our unit test harness will take a bit more >>> work than what you have provided (not even counting the Mac issue, which >>> could be handled by excluding the test on Mac). In the short term, relying >>> on manual tests for this fix might be best. >>> >> >> I did not execute the tests in jigsaw mode yet, because other tests failed >> in this mode, too (as indicated in an earlier discussion). I will try to set >> things up in a virtual machine with Windows and/or Linux so I can work on >> the Gradle tests without having to deal with the Mac issue. The test harness >> will IMHO also be required for other contributions, and it would of course >> be fine if the automated test, I included in this patch, could be executed >> as well. >> >>> >>> 2. You have introduced a dependency on a new internal package, >>> com.sun.javafx.tk. If this is required in order to implement the fix, then >>> you will need to add this package to the list of packages exports to >>> javafx.swt in PlatformImpl; otherwise the following exception is thrown at >>> runtime: >>> >>> Exception in thread "JavaFX Application Thread" >>> java.lang.IllegalAccessError: class javafx.embed.swt.SWTCursors (in module >>> javafx.swt) cannot access class com.sun.javafx.tk.Toolkit (in module >>> javafx.graphics) because module javafx.graphics does not export >>> com.sun.javafx.tk to module javafx.swt >> >> This dependency is required unless there is public API to convert a platform >> image (which is provided by the image cursor frame) to an image. To me, >> Image image = >> Toolkit.getImageAccessor().fromPlatformImage(cursorFrame.getPlatformImage()); >> seemed to be the way to go. I will thus add the respective export in a >> revised patch. >> >>> >>> >>> I won't have time to sponsor this change until the second half of July, but >>> if others have time, the review can proceed and I'll pick it back up then >>> if it is in good enough shape to run. >> >> Especially setting up the SWT test harness will be kind of a blocker for >> succeeding contributions, so it would be nice if somebody could step in. >> >> Regards, >> Alexander >> >>> >>> -- Kevin >>> >>> >>> Kevin Rushforth wrote: >>>> Hi Alexander, >>>> >>>> It looks like your patch was stripped out by the mailing list server. >>>> >>>> Can you please send me the patch offline, as a zip file (so line endings >>>> are preserved across different systems), and I will unzip it and attach it >>>> to the bug report. >>>> >>>> -- Kevin >>>> >>>> >>>> Alexander Nyssen wrote: >>>>> Hi, >>>>> >>>>> I have worked on a first contribution related to JDK-8088147. Attached >>>>> please find a patch (created in extended Git format) that comprises the >>>>> related changes. I have augmented the implementation of >>>>> javafx.embed.swt.SWTCursors to handle the image cursor case. I further >>>>> adjusted javafx.scene.Scene to update the cursor frame (in addition to >>>>> the cursor) within synchronizeSceneProperties, so the cursor is not >>>>> cleared in the first pulse succeeding the cursor property change. >>>>> I have added an automated JUnit test (SWTCursorsTest) to the swt module, >>>>> as well as a manual test (SWTImageCursorTest) to the systemTests module, >>>>> with which the proper behavior can be verified. As no tests for SWT >>>>> existed so far, I updated the build.gradle and gradle.properties files to >>>>> support an SWT_TEST option, which allows to handle them similar to Swing >>>>> tests. I also added the respective SWT dependency to the systemTests >>>>> module. Please note that the JUnit test can currently not be executed >>>>> using Gradle on the Mac (where the manual test currently is the single >>>>> option; the automated tests are disabled), because there SWT-based tests >>>>> require the -XstartOnFirstThread option that is currently not supported >>>>> by the Gradle test runner (see >>>>> https://issues.gradle.org/browse/GRADLE-3290 for details). We would have >>>>> to use an ant task as a workaround. >>>>> >>>>> Regards, >>>>> Alexander >>>>> >>>>> >>>>> >> >
