From ajit.ghaisas at oracle.com Mon Jan 1 07:01:26 2018 From: ajit.ghaisas at oracle.com (Ajit Ghaisas) Date: Sun, 31 Dec 2017 23:01:26 -0800 (PST) Subject: [10] Review request : JDK-8193041 : [TestBug] A new test case can be added to javafx/scene/control/ProgressIndicatorTest.java Message-ID: Hi, Request you to review following test addition : Issue : https://bugs.openjdk.java.net/browse/JDK-8193041 Fix for JDK 10 : http://cr.openjdk.java.net/~aghaisas/fx/8193041/webrev.0/ Regards, Ajit From mike.ennen at gmail.com Mon Jan 1 22:16:46 2018 From: mike.ennen at gmail.com (Michael Ennen) Date: Mon, 1 Jan 2018 15:16:46 -0700 Subject: Proposal For Inclusion of Robot and ParametersImpl in the Public API In-Reply-To: <5A3ADEAF.6000903@oracle.com> References: <5A25E463.1020309@oracle.com> <5A273A03.40902@oracle.com> <5A3AD041.8020301@oracle.com> <5A3ADEAF.6000903@oracle.com> Message-ID: I have created an orphan branch with the Robot API webrev: https://github.com/brcolow/openjfx/tree/robot-webrev You can clone/"download" it via: git clone https://github.com/brcolow/openjfx --branch robot-webrev --single-branch ~/robot-webrev This will use git to essentially download the webrev, without all the rest of the repository to ~/robot-webrev (or wherever you would like it to clone). Sorry I currently don't have an HTTP server for hosting the webrev. Thanks, Michael Ennen On Wed, Dec 20, 2017 at 3:05 PM, Kevin Rushforth wrote: > Sure, no problem. One quick comment is that a common way to solve this is > by delegating to an implementation class, which would then be sub-classes. > > > -- Kevin > > > Michael Ennen wrote: > > I am not trying to be a burden here. I understand that you may not have > time to hand-hold > to this degree. I will try and make progress, sorry for the follow up > question. > > On Wed, Dec 20, 2017 at 2:08 PM, Michael Ennen > wrote: > >> How can Robot call into the implementation when it is a super class of >> the implementations? >> >> On Wed, Dec 20, 2017 at 2:04 PM, Kevin Rushforth < >> kevin.rushforth at oracle.com> wrote: >> >>> >>> >>> Michael Ennen wrote: >>> >>> I have a question about how to proceed with the Robot code. >>> >>> The base abstract Robot class is: https://github.com/brcolow >>> /openjfx/blob/master/modules/javafx.graphics/src/main/java/j >>> avafx/scene/robot/Robot.java >>> >>> As you can see for each method, such as "getMouseX()" there is a "_" >>> prefixed method >>> which is abstract and a non-prefixed method: >>> >>> protected abstract int _getMouseX(); >>> >>> public int getMouseX() { >>> Application.checkEventThread(); >>> return _getMouseX(); >>> } >>> >>> I have copied this from the private Robot API. >>> >>> Is there a better way to do this? Would this pass review? >>> >>> >>> Yes there are better ways to do this. No it would not pass review, since >>> this would be leaking implementation into the public API. >>> >>> Rather than copying the public / protected methods from the internal >>> package, it probably makes more sense to start with what a Robot API should >>> look like and then have that call into the implementation (suitably >>> modified so it better matches the public API). For one thing you will then >>> leave the implementation, including the per-platform code, where it belongs >>> -- in glass. The Robot API can be informed by the current implementation, >>> but should not be defined by it. >>> >>> -- Kevin >>> >>> >>> >>> Thanks very much. >>> >>> >>> On Tue, Dec 5, 2017 at 5:29 PM, Kevin Rushforth < >>> kevin.rushforth at oracle.com> wrote: >>> >>>> Glad you got the build working. You can post back on this thread when >>>> you are ready. >>>> >>>> >>>> -- Kevin >>>> >>>> >>>> Michael Ennen wrote: >>>> >>>> Correction: >>>> >>>> Adding ""--add-exports javafx.graphics/javafx.scene.robot=ALL-UNNAMED" >>>> to buildSrc/addExports. >>>> >>>> For posterity :) >>>> >>>> On Mon, Dec 4, 2017 at 6:08 PM, Michael Ennen >>>> wrote: >>>> >>>>> Ah, indeed, missed adding "--add-opens javafx.graphics/javafx.scene.robot=ALL-UNNAMED" >>>>> to buildSrc/addExports. >>>>> Thanks for the guidance on that. >>>>> >>>>> I will continue to work on this in the GitHub repo and polish it up >>>>> (add javadocs, better method signatures, etc.) and >>>>> even plan on maybe improving the underlying native Robot >>>>> implementations (for example fixing/improving the >>>>> way color profiles are handled for MacRobot). >>>>> >>>>> I will also take a look at "fixing" JemmyFX to use the new public API >>>>> (as well as any other place in the JavaFX code >>>>> base that does). >>>>> >>>>> I was expecting that JDK 11 would be the appropriate time frame, >>>>> especially because it will be the release where >>>>> private APIs will be totally inaccessible, correct? >>>>> >>>>> After I get it in a reasonable state should I post back on this >>>>> mailing list thread or what would be the appropriate >>>>> way? >>>>> >>>>> Thanks Kevin. >>>>> >>>>> On Mon, Dec 4, 2017 at 5:12 PM, Kevin Rushforth < >>>>> kevin.rushforth at oracle.com> wrote: >>>>> >>>>>> This is a limitation of the the way --patch-modules works. You will >>>>>> need to add an entry in: >>>>>> >>>>>> buildSrc/addExports >>>>>> >>>>>> Btw, as for the proposal itself, this might need to be a JEP >>>>>> depending on the scope. In any case, it could be considered in the JDK 11 >>>>>> time frame, but there are several things that need to be worked out before >>>>>> making Robot a public API, including the fact that the JemmyFX framework in >>>>>> the openjfx/jfx/tests directory uses Robot. Once you get a working >>>>>> prototype, it would be interesting to discuss it in more detail. >>>>>> >>>>>> -- Kevin >>>>>> >>>>>> >>>>>> >>>>>> Michael Ennen wrote: >>>>>> >>>>>> Currently I am stuck with tests not being able to see the new >>>>>> "javafx.scene.robot" module: >>>>>> >>>>>> >>>>>> >>>>>> Task :systemTests:compileTestJava >>>>>> >>>>>> >>>>>> C:\Users\brcolow\dev\openjfx\tests\system\src\test\java\test\robot\com\sun\glass\ui\monocle\ModalDialogTest.java:34: >>>>>> error: package javafx.scene.robot is not visible >>>>>> import javafx.scene.robot.Robot; >>>>>> ^ >>>>>> (package javafx.scene.robot is declared in module javafx.graphics, which >>>>>> does not export it) >>>>>> C:\Users\brcolow\dev\openjfx\tests\system\src\test\java\test\robot\com\sun\glass\ui\monocle\RobotTest.java:33: >>>>>> error: package javafx.scene.robot is not visible >>>>>> import javafx.scene.robot.Robot; >>>>>> >>>>>> I have added: >>>>>> >>>>>> exports javafx.scene.robot; >>>>>> >>>>>> to: modules/javafx.graphics/src/main/java/module-info.java >>>>>> >>>>>> But this does not seem to be enough. >>>>>> >>>>>> On Sun, Dec 3, 2017 at 4:48 PM, Michael Ennen wrote: >>>>>> >>>>>> >>>>>> >>>>>> I am still working on all the necessary changes to actually allow openjfx >>>>>> to compile. >>>>>> Tons to learn in that arena and I know the code as it is written won't >>>>>> totally work. >>>>>> For example one can no longer: >>>>>> >>>>>> #include "com_sun_glass_ui_Robot.h" >>>>>> >>>>>> as in openjfx\modules\javafx.graphics\src\main\native-glass\win\Robot.cpp >>>>>> >>>>>> But I am not sure how those headers are generated and if I can just simply >>>>>> change >>>>>> it to "#include javafx_scene_robot_Robot.h" (which I very much doubt). >>>>>> >>>>>> On Sun, Dec 3, 2017 at 2:29 PM, Michael Ennen >>>>>> wrote: >>>>>> >>>>>> >>>>>> >>>>>> I have created a (small) proposal (building on the work of Benjamin >>>>>> Gudehaus) about moving some classes in to the public API so that TestFX (a >>>>>> JavaFX UI testing framework) can continue to work with future JDK releases. >>>>>> The somewhat nicely formatted proposal can be found as a Github gist: >>>>>> https://gist.github.com/brcolow/26370db6cab0355186d4a1d13b30fc19 >>>>>> >>>>>> All suggested changes can be found by using Github Compare View: >>>>>> https://github.com/brcolow/openjfx/compare/4ccdbbbce5234e2c5 >>>>>> e1f4f1cb8f20430feaa53b6...master >>>>>> >>>>>> But I have copied it to this email for convenience: >>>>>> >>>>>> ----------------------- PROPOSAL ----------------------- >>>>>> >>>>>> TestFX, the JavaFX GUI testing framework currently requires 4 (four) >>>>>> classes that are part of the JDK's private API. They are: >>>>>> >>>>>> [com.sun.glass.ui.Application](http://hg.openjdk.java.net/op >>>>>> enjfx/10-dev/rt/file/tip/modules/javafx.graphics/src/main/ >>>>>> java/com/sun/glass/ui/Application.java) >>>>>> [com.sun.glass.ui.Pixels](http://hg.openjdk.java.net/openjfx >>>>>> /10-dev/rt/file/tip/modules/javafx.graphics/src/main/java/ >>>>>> com/sun/glass/ui/Pixels.java) >>>>>> [com.sun.glass.ui.Robot](http://hg.openjdk.java.net/openjfx/ >>>>>> 10-dev/rt/file/tip/modules/javafx.graphics/src/main/java/com >>>>>> /sun/glass/ui/Robot.java) >>>>>> [com.sun.javafx.application.ParametersImpl](http://hg.openjdk.java.net/openjfx/10-dev/rt/file/tip/modules/javafx. >>>>>> graphics/src/main/java/com/sun/javafx/application/ParametersImpl.java ) >>>>>> >>>>>> In order to compile the project with Java 9, we use the following flags: >>>>>> >>>>>> ```sh >>>>>> --add-exports javafx.graphics/com.sun.glass.ui=org.testfx >>>>>> --add-exports javafx.graphics/com.sun.javafx.application=org.testfx >>>>>> ``` >>>>>> >>>>>> If the --add-exports flags are disabled in a future Java release TestFX >>>>>> will require these four classes to be moved into the public API to >>>>>> continue working. >>>>>> >>>>>> While these classes are probably not very useful for applications to use >>>>>> directly, any JavaFX application wanting to write UI tests will most >>>>>> likely >>>>>> use TestFX and thus they will indirectly be using these classes. >>>>>> >>>>>> JavaFX internal tests also use these classes for essentially the same >>>>>> purpose (UI tests). >>>>>> >>>>>> ### Details of Usage For Each Private API Class >>>>>> >>>>>> #### com.sun.javafx.application.ParametersImpl >>>>>> >>>>>> ##### TestFX Usage >>>>>> >>>>>> ```java >>>>>> ParametersImpl parameters = new ParametersImpl(applicationArgs); >>>>>> ParametersImpl.registerParameters(application, parameters); >>>>>> ``` >>>>>> >>>>>> The parameters are set on a constructed Application. >>>>>> >>>>>> ##### Suggested Public API Replacement >>>>>> >>>>>> `javafx.application.Application`: >>>>>> >>>>>> ```java >>>>>> /** >>>>>> * Sets the parameters for this Application. >>>>>> * >>>>>> *

>>>>>> * NOTE: this method should not be called from the Application >>>>>> constructor, >>>>>> * as it will return null. It may be called in the init() method or any >>>>>> * time after that. >>>>>> *

>>>>>> * >>>>>> * @param parameters the parameters to set for this Application >>>>>> */ >>>>>> public final Parameters setParameters(String... parameters) { >>>>>> ParametersImpl parameters = new ParametersImpl(parameters); >>>>>> ParametersImpl.registerParameters(this, parameters); >>>>>> } >>>>>> ``` >>>>>> >>>>>> #### com.sun.glass.ui.Application >>>>>> >>>>>> ##### TestFX Usage >>>>>> >>>>>> ```java >>>>>> return Application.GetApplication().createRobot(); >>>>>> ``` >>>>>> >>>>>> The Application class is used to instantiate a Robot. >>>>>> >>>>>> ##### Suggested Public API Replacement >>>>>> >>>>>> `javafx.application.Application`: >>>>>> https://github.com/brcolow/openjfx/blob/master/modules/javaf >>>>>> x.graphics/src/main/java/javafx/application/Application.java#L527 >>>>>> >>>>>> #### com.sun.glass.ui.Pixels >>>>>> >>>>>> ##### TestFX Usage >>>>>> >>>>>> ```java >>>>>> @Override >>>>>> public Image getCaptureRegion(Rectangle2D region) { >>>>>> return waitForAsyncFx(RETRIEVAL_TIMEOUT_IN_MILLIS, () -> { >>>>>> Pixels glassPixels = useRobot().getScreenCapture( >>>>>> (int) region.getMinX(), (int) region.getMinY(), >>>>>> (int) region.getWidth(), (int) region.getHeight() >>>>>> ); >>>>>> return convertFromGlassPixels(glassPixels); >>>>>> }); >>>>>> } >>>>>> >>>>>> private Image convertFromGlassPixels(Pixels glassPixels) { >>>>>> int width = glassPixels.getWidth(); >>>>>> int height = glassPixels.getHeight(); >>>>>> WritableImage image = new WritableImage(width, height); >>>>>> >>>>>> int bytesPerComponent = glassPixels.getBytesPerComponent(); >>>>>> if (bytesPerComponent == INT_BUFFER_BYTES_PER_COMPONENT) { >>>>>> IntBuffer intBuffer = (IntBuffer) glassPixels.getPixels(); >>>>>> writeIntBufferToImage(intBuffer, image); >>>>>> } >>>>>> >>>>>> return image; >>>>>> } >>>>>> >>>>>> private void writeIntBufferToImage(IntBuffer intBuffer, >>>>>> WritableImage image) { >>>>>> PixelWriter pixelWriter = image.getPixelWriter(); >>>>>> double width = image.getWidth(); >>>>>> double height = image.getHeight(); >>>>>> >>>>>> for (int y = 0; y < height; y++) { >>>>>> for (int x = 0; x < width; x++) { >>>>>> int argb = intBuffer.get(); >>>>>> pixelWriter.setArgb(x, y, argb); >>>>>> } >>>>>> } >>>>>> } >>>>>> ``` >>>>>> >>>>>> Pixels is used to create a screen capture. >>>>>> >>>>>> ##### Suggested Public API Replacement >>>>>> >>>>>> Bypass needing to expose the Pixels class to the public API by >>>>>> changing the getScreenCapture method of Robot - that is, changing: >>>>>> >>>>>> `public Pixels getScreenCapture(int x, int y, int width, int height)` >>>>>> >>>>>> to: >>>>>> >>>>>> `public Image getScreenCapture(int x, int y, int width, int height)` >>>>>> >>>>>> #### com.sun.glass.ui.Robot >>>>>> >>>>>> ##### TestFX Usage >>>>>> >>>>>> Essentially every method of Robot is used: >>>>>> >>>>>> ``` >>>>>> public void keyPress(int code) >>>>>> public void keyRelease(int code) >>>>>> public int getMouseX() >>>>>> public int getMouseY() >>>>>> public void mouseMove(int x, int y) >>>>>> public void mousePress(int buttons) >>>>>> public void mouseRelease(int buttons) >>>>>> public void mouseWheel(int wheelAmt) >>>>>> public int getPixelColor(int x, int y) >>>>>> public Pixels getScreenCapture(int x, int y, int width, int height) >>>>>> ``` >>>>>> >>>>>> ##### Suggested Public API Replacement >>>>>> https://github.com/brcolow/openjfx/blob/master/modules/javaf >>>>>> x.graphics/src/main/java/javafx/scene/robot/Robot.java >>>>>> >>>>>> >>>>>> -- >>>>>> Michael Ennen >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Michael Ennen >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Michael Ennen >>>>> >>>> >>>> >>>> >>>> -- >>>> Michael Ennen >>>> >>>> >>> >>> >>> -- >>> Michael Ennen >>> >>> >> >> >> -- >> Michael Ennen >> > > > > -- > Michael Ennen > > From guru.hb at oracle.com Tue Jan 2 04:38:11 2018 From: guru.hb at oracle.com (Guru) Date: Tue, 2 Jan 2018 10:08:11 +0530 Subject: [11] Review request: 8194265: Webengine (webkit) crash when reading files using FileReader Message-ID: <51D8B389-0618-472F-8E51-0DC5D9EA8C15@oracle.com> Hi, Please review the fix for JBS : https://bugs.openjdk.java.net/browse/JDK-8194265 Web rev : http://cr.openjdk.java.net/~ghb/8194265/webrev.00/ Thanks, Guru From guru.hb at oracle.com Tue Jan 2 11:36:27 2018 From: guru.hb at oracle.com (Guru) Date: Tue, 2 Jan 2018 17:06:27 +0530 Subject: [11] Review request: 8194294 : [TEST BUG] Manual Test for WebView FileReader API Message-ID: <9EDD70A2-4821-4C2D-9968-E568876932AE@oracle.com> Hi, Please review the fix for JBS : https://bugs.openjdk.java.net/browse/JDK-8194294 webrev : http://cr.openjdk.java.net/~ghb/8194294/webrev.00 Thanks, Guru From francois.jaouen at mailoo.org Tue Jan 2 12:20:26 2018 From: francois.jaouen at mailoo.org (=?UTF-8?Q?Fran=c3=a7ois_Jaouen?=) Date: Tue, 2 Jan 2018 13:20:26 +0100 Subject: Turning off font anti-antialiasing patch Message-ID: <808ab4a7-a1d7-e8c0-3b35-ac127bbf0a8f@mailoo.org> While porting a swing application to JavaFX 8, I had to patch JavaFX 8 to disable font anti-aliasing on linux. But, for readibility of text,? I also had to reenable font hinting, in this case only. Since, I've found this open bug https://bugs.openjdk.java.net/browse/JDK-8092207. I will be glad to publish this contribution if it fits in OpenJFX plans. But as it requires some rework, let me know first if it has any interest. Fran?ois Jaouen From philip.race at oracle.com Tue Jan 2 16:41:22 2018 From: philip.race at oracle.com (Philip Race) Date: Tue, 02 Jan 2018 08:41:22 -0800 Subject: Turning off font anti-antialiasing patch In-Reply-To: <808ab4a7-a1d7-e8c0-3b35-ac127bbf0a8f@mailoo.org> References: <808ab4a7-a1d7-e8c0-3b35-ac127bbf0a8f@mailoo.org> Message-ID: <5A4BB632.6050508@oracle.com> This should be closed as will not fix. FX assumes and requires unhinted metrics so cannot work with B&W text which will not display properly with hinting. Most fonts will render really-really badly if not hinted when using B&W. Then there are the fonts which don't even have hints and so will render really-really badly anyway. -phil. On 1/2/18, 4:20 AM, Fran?ois Jaouen wrote: > While porting a swing application to JavaFX 8, I had to patch JavaFX 8 to disable font anti-aliasing on linux. > > But, for readibility of text, I also had to reenable font hinting, in this case only. > > Since, I've found this open bug https://bugs.openjdk.java.net/browse/JDK-8092207. > > I will be glad to publish this contribution if it fits in OpenJFX plans. But as it requires some rework, let me know first if it has any interest. > > Fran?ois Jaouen > From nlisker at gmail.com Wed Jan 3 09:11:29 2018 From: nlisker at gmail.com (Nir Lisker) Date: Wed, 3 Jan 2018 11:11:29 +0200 Subject: JDK build fails on missing javah In-Reply-To: References: Message-ID: I've gotten a reply from build-dev at openjdk.java.net ( http://mail.openjdk.java.net/pipermail/build-dev/2018-January/020552.html). The check for javah will be removed in the future. For now we have to use 9 as boot JDK: --with-boot-jdk='C:\Program Files\Java\jdk-9\' On Sun, Dec 31, 2017 at 2:43 PM, Nir Lisker wrote: > After successfully building OpenJFX (11) Iv'e went on to build OpenJDK > (11) as instructed under "Integration with OpenJDK" ( > http://hg.openjdk.java.net/jdk/jdk/raw-file/tip/doc/building.html). > > When executing `bash configure --with-import-modules=jfx_path\rt\build\modular-sdk` > the build fails: > > checking for java in Boot JDK... ok > checking for javac in Boot JDK... ok > checking for javah in Boot JDK... not found > configure: Your Boot JDK seems broken. This might be fixed by explicitly > setting --with-boot-jdk > configure: error: Could not find javah in the Boot JDK > configure exiting with result code 1 > > The boot JDK is 10, which does not have javah anymore, so it is no > surprise. I could point boot JDK to a previous version, but I don't think I > should. Does anyone know what I should do? > > Nir > From ajit.ghaisas at oracle.com Thu Jan 4 10:14:07 2018 From: ajit.ghaisas at oracle.com (Ajit Ghaisas) Date: Thu, 4 Jan 2018 02:14:07 -0800 (PST) Subject: [11] Review request : JDK-8187432 : ListView: EditEvent on start has incorrect index Message-ID: <7c1c70cb-1194-4488-ac79-e46f95b3a804@default> Hi, Request you to review following fix : Issue : https://bugs.openjdk.java.net/browse/JDK-8187432 Fix : http://cr.openjdk.java.net/~aghaisas/fx/8187432/webrev.0/ Regards, Ajit From murali.billa at oracle.com Thu Jan 4 10:47:19 2018 From: murali.billa at oracle.com (Murali Billa) Date: Thu, 4 Jan 2018 02:47:19 -0800 (PST) Subject: [11] Review request for 8193131: Need to remove SharedBuffer unit Test cases Message-ID: ? Hi, Please review the below simple fix. JIRA: https://bugs.openjdk.java.net/browse/JDK-8193131 ? Webrev: http://cr.openjdk.java.net/~mbilla/8193131/webrev.00/ ? Thanks, Murali From praveen.s.srivastava at oracle.com Fri Jan 5 04:59:59 2018 From: praveen.s.srivastava at oracle.com (Praveen Srivastava) Date: Fri, 5 Jan 2018 10:29:59 +0530 Subject: [11] Review Request: JDK-8190411 NPE in SliderSkin:140 if Slider.Tooltip.autohide is true In-Reply-To: References: Message-ID: <183f674b-6612-add1-c17a-094051614a40@oracle.com> Hi Ajit/Ambarish, Can you guys review this control fix , Kevin can review it later ? Thanks Praveen On 12/22/2017 4:56 PM, Prem Balakrishnan wrote: > Hi Kevin, Ajit > > > > Request you to review following fix: > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8190411 > > > > Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Epkbalakr/fx/8190411/webrev.00/"http://cr.openjdk.java.net/~pkbalakr/fx/8190411/webrev.00/ > > > > Regards, > > Prem > > From ambarish.rapte at oracle.com Fri Jan 5 07:31:38 2018 From: ambarish.rapte at oracle.com (Ambarish Rapte) Date: Thu, 4 Jan 2018 23:31:38 -0800 (PST) Subject: RFR : JDK-8157690 : [TabPane] Sorting tabs makes tab selection menu empty Message-ID: Hi Kevin & Ajit, Request you to review this fix, Webrev: http://cr.openjdk.java.net/~arapte/fx/8157690/webrev.00/ Issue: https://bugs.openjdk.java.net/browse/JDK-8157690 Regards, Ambarish From victor.drozdov at oracle.com Sat Jan 6 02:00:53 2018 From: victor.drozdov at oracle.com (victor.drozdov at oracle.com) Date: Fri, 5 Jan 2018 18:00:53 -0800 Subject: [10] Review request: 8194144: com.oracle.tools.packager.Bundler.execute() returns null on MAC Message-ID: <32b0484f-8c88-9f9c-d78d-6ef6afe8734c@oracle.com> Kevin, Please review my changes for fixing the issue: "JDK-8194144: com.oracle.tools.packager.Bundler.execute() returns null on MAC" JIRA: https://bugs.openjdk.java.net/browse/JDK-8194144 Webrev: http://cr.openjdk.java.net/~vdrozdov/JDK-8194144/webrev.00/ --Victor From alexander.matveev at oracle.com Sat Jan 6 04:39:05 2018 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Fri, 5 Jan 2018 20:39:05 -0800 Subject: [11] Review request for 8193313: MediaPlayer Leaking Native Memory Message-ID: <1d1abc79-442c-ce7d-b3b3-6583f2298d2c@oracle.com> Hi Kevin, Please review the following: https://bugs.openjdk.java.net/browse/JDK-8193313 Fixed large memory consumption with single track media files. Thanks, Alexander From victor.drozdov at oracle.com Sat Jan 6 05:17:37 2018 From: victor.drozdov at oracle.com (victor.drozdov at oracle.com) Date: Fri, 5 Jan 2018 21:17:37 -0800 Subject: [10] Review request: 8194488: "javapackager -singleton" is not working in linux Message-ID: <826911bc-c5c4-3ecf-86eb-e242c78de84e@oracle.com> Alexander, Please review my changes for fixing the issue: "JDK-8194488: "javapackager -singleton" is not working in linux" JIRA: https://bugs.openjdk.java.net/browse/JDK-8194488 Webrev: http://cr.openjdk.java.net/~vdrozdov/JDK-8194488/webrev.00/ --Victor From robert.hencke at gmail.com Sun Jan 7 14:06:29 2018 From: robert.hencke at gmail.com (Robert Hencke) Date: Sun, 07 Jan 2018 14:06:29 +0000 Subject: OpenJFX JIRA Location Message-ID: Hello, I was looking to contribute some minor fix-ups to the OpenJFX build scripts. As part of this, I found the page on the developer workflow here: https://wiki.openjdk.java.net/display/OpenJFX/Developer+Work+Flow It mentions that all contributions should first start with filing of a JIRA issue. However, the link to JIRA provided on this page ( https://javafx-jira.kenai.com/) does not seem to work. Is the JIRA site down, or maybe it moved? Thank you! Robert From mp at jugs.org Sun Jan 7 14:52:25 2018 From: mp at jugs.org (Michael Paus) Date: Sun, 7 Jan 2018 15:52:25 +0100 Subject: OpenJFX JIRA Location In-Reply-To: References: Message-ID: <4dfa04a5-fbb9-b836-8d21-b94fa512f110@jugs.org> The old JIRA has been moved here: https://bugs.openjdk.java.net/secure/Dashboard.jspa But this won't help you very much unless you are already an OpenJDK author or more because there is no public write access to this JIRA :-( Am 07.01.18 um 15:06 schrieb Robert Hencke: > Hello, > > I was looking to contribute some minor fix-ups to the OpenJFX build > scripts. As part of this, I found the page on the developer workflow here: > > https://wiki.openjdk.java.net/display/OpenJFX/Developer+Work+Flow > > It mentions that all contributions should first start with filing of a JIRA > issue. However, the link to JIRA provided on this page ( > https://javafx-jira.kenai.com/) does not seem to work. > > Is the JIRA site down, or maybe it moved? > > Thank you! > Robert From philip.race at oracle.com Sun Jan 7 17:40:12 2018 From: philip.race at oracle.com (Philip Race) Date: Sun, 07 Jan 2018 09:40:12 -0800 Subject: OpenJFX JIRA Location In-Reply-To: <4dfa04a5-fbb9-b836-8d21-b94fa512f110@jugs.org> References: <4dfa04a5-fbb9-b836-8d21-b94fa512f110@jugs.org> Message-ID: <5A525B7C.5050207@oracle.com> You can go to https://bugreport.java.com/, scroll to the bottom and start a new bug report. It goes into the same JIRA instance in a different project and is then trivially moved (by someone with write access) to the JDK project. Make sure you select javafx as the component. -phil. On 1/7/18, 6:52 AM, Michael Paus wrote: > The old JIRA has been moved here: > https://bugs.openjdk.java.net/secure/Dashboard.jspa > But this won't help you very much unless you are already an OpenJDK > author or more because > there is no public write access to this JIRA :-( > > Am 07.01.18 um 15:06 schrieb Robert Hencke: >> Hello, >> >> I was looking to contribute some minor fix-ups to the OpenJFX build >> scripts. As part of this, I found the page on the developer workflow >> here: >> >> https://wiki.openjdk.java.net/display/OpenJFX/Developer+Work+Flow >> >> It mentions that all contributions should first start with filing of >> a JIRA >> issue. However, the link to JIRA provided on this page ( >> https://javafx-jira.kenai.com/) does not seem to work. >> >> Is the JIRA site down, or maybe it moved? >> >> Thank you! >> Robert > > From mp at jugs.org Sun Jan 7 17:58:49 2018 From: mp at jugs.org (Michael Paus) Date: Sun, 7 Jan 2018 18:58:49 +0100 Subject: OpenJFX JIRA Location In-Reply-To: <5A525B7C.5050207@oracle.com> References: <4dfa04a5-fbb9-b836-8d21-b94fa512f110@jugs.org> <5A525B7C.5050207@oracle.com> Message-ID: Your proposal will normally end up in the JIRA repository within 1-2 days. And then what? As we are not talking about a bug report here, the proposal will most certainly raise some questions. Now how do you answer these questions? How do you discuss issues with the responsible people? Am 07.01.18 um 18:40 schrieb Philip Race: > You can go to https://bugreport.java.com/, scroll to the bottom and > start a new bug report. > > It goes into the same JIRA instance in a different project and is then > trivially moved > (by someone with write access) to the JDK project. > > Make sure you select javafx as the component. > > -phil. > > On 1/7/18, 6:52 AM, Michael Paus wrote: >> The old JIRA has been moved here: >> https://bugs.openjdk.java.net/secure/Dashboard.jspa >> But this won't help you very much unless you are already an OpenJDK >> author or more because >> there is no public write access to this JIRA :-( >> >> Am 07.01.18 um 15:06 schrieb Robert Hencke: >>> Hello, >>> >>> I was looking to contribute some minor fix-ups to the OpenJFX build >>> scripts.? As part of this, I found the page on the developer >>> workflow here: >>> >>> https://wiki.openjdk.java.net/display/OpenJFX/Developer+Work+Flow >>> >>> It mentions that all contributions should first start with filing of >>> a JIRA >>> issue.? However, the link to JIRA provided on this page ( >>> https://javafx-jira.kenai.com/) does not seem to work. >>> >>> Is the JIRA site down, or maybe it moved? >>> >>> Thank you! >>> Robert >> >> From neugens.limasoftware at gmail.com Sun Jan 7 18:13:58 2018 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Sun, 7 Jan 2018 19:13:58 +0100 Subject: OpenJFX JIRA Location In-Reply-To: References: <4dfa04a5-fbb9-b836-8d21-b94fa512f110@jugs.org> <5A525B7C.5050207@oracle.com> Message-ID: 2018-01-07 18:58 GMT+01:00 Michael Paus : > And then what? Robert wanted to contribute some fixes, he presumably has a couple of bugs that he can report (or perhaps that are already in the bug database), if the changes are minor, he can start doing that now by contributing the fixes on the mailing list, as described in details here: http://openjdk.java.net/contribute/ Cheers, Mario -- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens Proud GNU Classpath developer: http://www.classpath.org/ OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/ From philip.race at oracle.com Sun Jan 7 18:38:08 2018 From: philip.race at oracle.com (Philip Race) Date: Sun, 07 Jan 2018 10:38:08 -0800 Subject: OpenJFX JIRA Location In-Reply-To: References: <4dfa04a5-fbb9-b836-8d21-b94fa512f110@jugs.org> <5A525B7C.5050207@oracle.com> Message-ID: <5A526910.2060602@oracle.com> This mailing list is one option. -phil. On 1/7/18, 9:58 AM, Michael Paus wrote: > Your proposal will normally end up in the JIRA repository within 1-2 > days. > And then what? As we are not talking about a bug report here, the > proposal will most > certainly raise some questions. Now how do you answer these questions? > How do you > discuss issues with the responsible people? > > Am 07.01.18 um 18:40 schrieb Philip Race: >> You can go to https://bugreport.java.com/, scroll to the bottom and >> start a new bug report. >> >> It goes into the same JIRA instance in a different project and is >> then trivially moved >> (by someone with write access) to the JDK project. >> >> Make sure you select javafx as the component. >> >> -phil. >> >> On 1/7/18, 6:52 AM, Michael Paus wrote: >>> The old JIRA has been moved here: >>> https://bugs.openjdk.java.net/secure/Dashboard.jspa >>> But this won't help you very much unless you are already an OpenJDK >>> author or more because >>> there is no public write access to this JIRA :-( >>> >>> Am 07.01.18 um 15:06 schrieb Robert Hencke: >>>> Hello, >>>> >>>> I was looking to contribute some minor fix-ups to the OpenJFX build >>>> scripts. As part of this, I found the page on the developer >>>> workflow here: >>>> >>>> https://wiki.openjdk.java.net/display/OpenJFX/Developer+Work+Flow >>>> >>>> It mentions that all contributions should first start with filing >>>> of a JIRA >>>> issue. However, the link to JIRA provided on this page ( >>>> https://javafx-jira.kenai.com/) does not seem to work. >>>> >>>> Is the JIRA site down, or maybe it moved? >>>> >>>> Thank you! >>>> Robert >>> >>> > From robert.hencke at gmail.com Sun Jan 7 23:45:51 2018 From: robert.hencke at gmail.com (Robert Hencke) Date: Sun, 07 Jan 2018 23:45:51 +0000 Subject: OpenJFX JIRA Location In-Reply-To: <5A526910.2060602@oracle.com> References: <4dfa04a5-fbb9-b836-8d21-b94fa512f110@jugs.org> <5A525B7C.5050207@oracle.com> <5A526910.2060602@oracle.com> Message-ID: Phil, Mario, Michael, Thank you all for the guidance on how to proceed - it?s much appreciated. I?ll work on getting the Oracle Contributor Agreement filled out and sent in - look like that?s a prerequisite before anything else. The changes are pretty minor in scope - more enhancements than bugs. They?re just things I noticed while setting up the build locally to play with, that could be made a little easier. I?ll draft up a short summary and send it to the list after I get the contributor agreement squared away. Thanks again. Robert On Sun, Jan 7, 2018 at 1:38 PM Philip Race wrote: > This mailing list is one option. > > -phil. > > On 1/7/18, 9:58 AM, Michael Paus wrote: > > Your proposal will normally end up in the JIRA repository within 1-2 > > days. > > And then what? As we are not talking about a bug report here, the > > proposal will most > > certainly raise some questions. Now how do you answer these questions? > > How do you > > discuss issues with the responsible people? > > > > Am 07.01.18 um 18:40 schrieb Philip Race: > >> You can go to https://bugreport.java.com/, scroll to the bottom and > >> start a new bug report. > >> > >> It goes into the same JIRA instance in a different project and is > >> then trivially moved > >> (by someone with write access) to the JDK project. > >> > >> Make sure you select javafx as the component. > >> > >> -phil. > >> > >> On 1/7/18, 6:52 AM, Michael Paus wrote: > >>> The old JIRA has been moved here: > >>> https://bugs.openjdk.java.net/secure/Dashboard.jspa > >>> But this won't help you very much unless you are already an OpenJDK > >>> author or more because > >>> there is no public write access to this JIRA :-( > >>> > >>> Am 07.01.18 um 15:06 schrieb Robert Hencke: > >>>> Hello, > >>>> > >>>> I was looking to contribute some minor fix-ups to the OpenJFX build > >>>> scripts. As part of this, I found the page on the developer > >>>> workflow here: > >>>> > >>>> https://wiki.openjdk.java.net/display/OpenJFX/Developer+Work+Flow > >>>> > >>>> It mentions that all contributions should first start with filing > >>>> of a JIRA > >>>> issue. However, the link to JIRA provided on this page ( > >>>> https://javafx-jira.kenai.com/) does not seem to work. > >>>> > >>>> Is the JIRA site down, or maybe it moved? > >>>> > >>>> Thank you! > >>>> Robert > >>> > >>> > > > From nlisker at gmail.com Mon Jan 8 12:15:44 2018 From: nlisker at gmail.com (Nir Lisker) Date: Mon, 8 Jan 2018 14:15:44 +0200 Subject: Instructions for working on OpenJFX Message-ID: Hello, I have OpenJFX and OpenJDK built. I have also set up TortoiseHg and am working with Eclipse. I have several questions: 1. Are the instructions at https://wiki.openjdk.java.net/display/OpenJFX/Using+an+IDE still valid from JDK 8? There are old TODOs there. If not, can I get a quick update? 2. After importing the projects to Eclipse and working on the source, what steps need to be taken when the changes are to: a. only the docs? b. Java code? c. Prism code? Do I need to rebuild the JDK with JavaFX, rebuild only JavaFX, only compile etc? What tests do I need to run (e.g., I doubt I need to run regression tests when changing JavaDocs)? 3. Eclipse uses EJC (which I never had trouble with). Can this cause trouble? 4. After creating a local changeset and assuming there is already a JIRA issue for it and the fix approach was discussed, can I just push it and it will enter a review queue? Do I need to ask someone specifically for a review on the changeset ( https://wiki.openjdk.java.net/display/OpenJFX/Code+Ownership is old...)? Thanks, Nir From prem.balakrishnan at oracle.com Mon Jan 8 12:55:54 2018 From: prem.balakrishnan at oracle.com (Prem Balakrishnan) Date: Mon, 8 Jan 2018 04:55:54 -0800 (PST) Subject: [11] Review Request: JDK-8192800 Table auto resize ignores column resize policy Message-ID: Hi Kevin, Ajit Request you to review following fix: Bug: https://bugs.openjdk.java.net/browse/JDK-8192800 Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Epkbalakr/fx/8192800/webrev.00/"http://cr.openjdk.java.net/~pkbalakr/fx/8192800/webrev.00/ Regards, Prem From mike.ennen at gmail.com Mon Jan 8 22:27:09 2018 From: mike.ennen at gmail.com (Michael Ennen) Date: Mon, 8 Jan 2018 15:27:09 -0700 Subject: Proposal For Inclusion of Robot and ParametersImpl in the Public API In-Reply-To: <5A3ADEAF.6000903@oracle.com> References: <5A25E463.1020309@oracle.com> <5A273A03.40902@oracle.com> <5A3AD041.8020301@oracle.com> <5A3ADEAF.6000903@oracle.com> Message-ID: Hey Kevin, Hope you had a good holiday. Hopefully you will get some time in the coming weeks to review my work. Thanks! On Wed, Dec 20, 2017 at 3:05 PM, Kevin Rushforth wrote: > Sure, no problem. One quick comment is that a common way to solve this is > by delegating to an implementation class, which would then be sub-classes. > > > -- Kevin > > > Michael Ennen wrote: > > I am not trying to be a burden here. I understand that you may not have > time to hand-hold > to this degree. I will try and make progress, sorry for the follow up > question. > > On Wed, Dec 20, 2017 at 2:08 PM, Michael Ennen > wrote: > >> How can Robot call into the implementation when it is a super class of >> the implementations? >> >> On Wed, Dec 20, 2017 at 2:04 PM, Kevin Rushforth < >> kevin.rushforth at oracle.com> wrote: >> >>> >>> >>> Michael Ennen wrote: >>> >>> I have a question about how to proceed with the Robot code. >>> >>> The base abstract Robot class is: https://github.com/brcolow >>> /openjfx/blob/master/modules/javafx.graphics/src/main/java/j >>> avafx/scene/robot/Robot.java >>> >>> As you can see for each method, such as "getMouseX()" there is a "_" >>> prefixed method >>> which is abstract and a non-prefixed method: >>> >>> protected abstract int _getMouseX(); >>> >>> public int getMouseX() { >>> Application.checkEventThread(); >>> return _getMouseX(); >>> } >>> >>> I have copied this from the private Robot API. >>> >>> Is there a better way to do this? Would this pass review? >>> >>> >>> Yes there are better ways to do this. No it would not pass review, since >>> this would be leaking implementation into the public API. >>> >>> Rather than copying the public / protected methods from the internal >>> package, it probably makes more sense to start with what a Robot API should >>> look like and then have that call into the implementation (suitably >>> modified so it better matches the public API). For one thing you will then >>> leave the implementation, including the per-platform code, where it belongs >>> -- in glass. The Robot API can be informed by the current implementation, >>> but should not be defined by it. >>> >>> -- Kevin >>> >>> >>> >>> Thanks very much. >>> >>> >>> On Tue, Dec 5, 2017 at 5:29 PM, Kevin Rushforth < >>> kevin.rushforth at oracle.com> wrote: >>> >>>> Glad you got the build working. You can post back on this thread when >>>> you are ready. >>>> >>>> >>>> -- Kevin >>>> >>>> >>>> Michael Ennen wrote: >>>> >>>> Correction: >>>> >>>> Adding ""--add-exports javafx.graphics/javafx.scene.robot=ALL-UNNAMED" >>>> to buildSrc/addExports. >>>> >>>> For posterity :) >>>> >>>> On Mon, Dec 4, 2017 at 6:08 PM, Michael Ennen >>>> wrote: >>>> >>>>> Ah, indeed, missed adding "--add-opens javafx.graphics/javafx.scene.robot=ALL-UNNAMED" >>>>> to buildSrc/addExports. >>>>> Thanks for the guidance on that. >>>>> >>>>> I will continue to work on this in the GitHub repo and polish it up >>>>> (add javadocs, better method signatures, etc.) and >>>>> even plan on maybe improving the underlying native Robot >>>>> implementations (for example fixing/improving the >>>>> way color profiles are handled for MacRobot). >>>>> >>>>> I will also take a look at "fixing" JemmyFX to use the new public API >>>>> (as well as any other place in the JavaFX code >>>>> base that does). >>>>> >>>>> I was expecting that JDK 11 would be the appropriate time frame, >>>>> especially because it will be the release where >>>>> private APIs will be totally inaccessible, correct? >>>>> >>>>> After I get it in a reasonable state should I post back on this >>>>> mailing list thread or what would be the appropriate >>>>> way? >>>>> >>>>> Thanks Kevin. >>>>> >>>>> On Mon, Dec 4, 2017 at 5:12 PM, Kevin Rushforth < >>>>> kevin.rushforth at oracle.com> wrote: >>>>> >>>>>> This is a limitation of the the way --patch-modules works. You will >>>>>> need to add an entry in: >>>>>> >>>>>> buildSrc/addExports >>>>>> >>>>>> Btw, as for the proposal itself, this might need to be a JEP >>>>>> depending on the scope. In any case, it could be considered in the JDK 11 >>>>>> time frame, but there are several things that need to be worked out before >>>>>> making Robot a public API, including the fact that the JemmyFX framework in >>>>>> the openjfx/jfx/tests directory uses Robot. Once you get a working >>>>>> prototype, it would be interesting to discuss it in more detail. >>>>>> >>>>>> -- Kevin >>>>>> >>>>>> >>>>>> >>>>>> Michael Ennen wrote: >>>>>> >>>>>> Currently I am stuck with tests not being able to see the new >>>>>> "javafx.scene.robot" module: >>>>>> >>>>>> >>>>>> >>>>>> Task :systemTests:compileTestJava >>>>>> >>>>>> >>>>>> C:\Users\brcolow\dev\openjfx\tests\system\src\test\java\test\robot\com\sun\glass\ui\monocle\ModalDialogTest.java:34: >>>>>> error: package javafx.scene.robot is not visible >>>>>> import javafx.scene.robot.Robot; >>>>>> ^ >>>>>> (package javafx.scene.robot is declared in module javafx.graphics, which >>>>>> does not export it) >>>>>> C:\Users\brcolow\dev\openjfx\tests\system\src\test\java\test\robot\com\sun\glass\ui\monocle\RobotTest.java:33: >>>>>> error: package javafx.scene.robot is not visible >>>>>> import javafx.scene.robot.Robot; >>>>>> >>>>>> I have added: >>>>>> >>>>>> exports javafx.scene.robot; >>>>>> >>>>>> to: modules/javafx.graphics/src/main/java/module-info.java >>>>>> >>>>>> But this does not seem to be enough. >>>>>> >>>>>> On Sun, Dec 3, 2017 at 4:48 PM, Michael Ennen wrote: >>>>>> >>>>>> >>>>>> >>>>>> I am still working on all the necessary changes to actually allow openjfx >>>>>> to compile. >>>>>> Tons to learn in that arena and I know the code as it is written won't >>>>>> totally work. >>>>>> For example one can no longer: >>>>>> >>>>>> #include "com_sun_glass_ui_Robot.h" >>>>>> >>>>>> as in openjfx\modules\javafx.graphics\src\main\native-glass\win\Robot.cpp >>>>>> >>>>>> But I am not sure how those headers are generated and if I can just simply >>>>>> change >>>>>> it to "#include javafx_scene_robot_Robot.h" (which I very much doubt). >>>>>> >>>>>> On Sun, Dec 3, 2017 at 2:29 PM, Michael Ennen >>>>>> wrote: >>>>>> >>>>>> >>>>>> >>>>>> I have created a (small) proposal (building on the work of Benjamin >>>>>> Gudehaus) about moving some classes in to the public API so that TestFX (a >>>>>> JavaFX UI testing framework) can continue to work with future JDK releases. >>>>>> The somewhat nicely formatted proposal can be found as a Github gist: >>>>>> https://gist.github.com/brcolow/26370db6cab0355186d4a1d13b30fc19 >>>>>> >>>>>> All suggested changes can be found by using Github Compare View: >>>>>> https://github.com/brcolow/openjfx/compare/4ccdbbbce5234e2c5 >>>>>> e1f4f1cb8f20430feaa53b6...master >>>>>> >>>>>> But I have copied it to this email for convenience: >>>>>> >>>>>> ----------------------- PROPOSAL ----------------------- >>>>>> >>>>>> TestFX, the JavaFX GUI testing framework currently requires 4 (four) >>>>>> classes that are part of the JDK's private API. They are: >>>>>> >>>>>> [com.sun.glass.ui.Application](http://hg.openjdk.java.net/op >>>>>> enjfx/10-dev/rt/file/tip/modules/javafx.graphics/src/main/ >>>>>> java/com/sun/glass/ui/Application.java) >>>>>> [com.sun.glass.ui.Pixels](http://hg.openjdk.java.net/openjfx >>>>>> /10-dev/rt/file/tip/modules/javafx.graphics/src/main/java/ >>>>>> com/sun/glass/ui/Pixels.java) >>>>>> [com.sun.glass.ui.Robot](http://hg.openjdk.java.net/openjfx/ >>>>>> 10-dev/rt/file/tip/modules/javafx.graphics/src/main/java/com >>>>>> /sun/glass/ui/Robot.java) >>>>>> [com.sun.javafx.application.ParametersImpl](http://hg.openjdk.java.net/openjfx/10-dev/rt/file/tip/modules/javafx. >>>>>> graphics/src/main/java/com/sun/javafx/application/ParametersImpl.java ) >>>>>> >>>>>> In order to compile the project with Java 9, we use the following flags: >>>>>> >>>>>> ```sh >>>>>> --add-exports javafx.graphics/com.sun.glass.ui=org.testfx >>>>>> --add-exports javafx.graphics/com.sun.javafx.application=org.testfx >>>>>> ``` >>>>>> >>>>>> If the --add-exports flags are disabled in a future Java release TestFX >>>>>> will require these four classes to be moved into the public API to >>>>>> continue working. >>>>>> >>>>>> While these classes are probably not very useful for applications to use >>>>>> directly, any JavaFX application wanting to write UI tests will most >>>>>> likely >>>>>> use TestFX and thus they will indirectly be using these classes. >>>>>> >>>>>> JavaFX internal tests also use these classes for essentially the same >>>>>> purpose (UI tests). >>>>>> >>>>>> ### Details of Usage For Each Private API Class >>>>>> >>>>>> #### com.sun.javafx.application.ParametersImpl >>>>>> >>>>>> ##### TestFX Usage >>>>>> >>>>>> ```java >>>>>> ParametersImpl parameters = new ParametersImpl(applicationArgs); >>>>>> ParametersImpl.registerParameters(application, parameters); >>>>>> ``` >>>>>> >>>>>> The parameters are set on a constructed Application. >>>>>> >>>>>> ##### Suggested Public API Replacement >>>>>> >>>>>> `javafx.application.Application`: >>>>>> >>>>>> ```java >>>>>> /** >>>>>> * Sets the parameters for this Application. >>>>>> * >>>>>> *

>>>>>> * NOTE: this method should not be called from the Application >>>>>> constructor, >>>>>> * as it will return null. It may be called in the init() method or any >>>>>> * time after that. >>>>>> *

>>>>>> * >>>>>> * @param parameters the parameters to set for this Application >>>>>> */ >>>>>> public final Parameters setParameters(String... parameters) { >>>>>> ParametersImpl parameters = new ParametersImpl(parameters); >>>>>> ParametersImpl.registerParameters(this, parameters); >>>>>> } >>>>>> ``` >>>>>> >>>>>> #### com.sun.glass.ui.Application >>>>>> >>>>>> ##### TestFX Usage >>>>>> >>>>>> ```java >>>>>> return Application.GetApplication().createRobot(); >>>>>> ``` >>>>>> >>>>>> The Application class is used to instantiate a Robot. >>>>>> >>>>>> ##### Suggested Public API Replacement >>>>>> >>>>>> `javafx.application.Application`: >>>>>> https://github.com/brcolow/openjfx/blob/master/modules/javaf >>>>>> x.graphics/src/main/java/javafx/application/Application.java#L527 >>>>>> >>>>>> #### com.sun.glass.ui.Pixels >>>>>> >>>>>> ##### TestFX Usage >>>>>> >>>>>> ```java >>>>>> @Override >>>>>> public Image getCaptureRegion(Rectangle2D region) { >>>>>> return waitForAsyncFx(RETRIEVAL_TIMEOUT_IN_MILLIS, () -> { >>>>>> Pixels glassPixels = useRobot().getScreenCapture( >>>>>> (int) region.getMinX(), (int) region.getMinY(), >>>>>> (int) region.getWidth(), (int) region.getHeight() >>>>>> ); >>>>>> return convertFromGlassPixels(glassPixels); >>>>>> }); >>>>>> } >>>>>> >>>>>> private Image convertFromGlassPixels(Pixels glassPixels) { >>>>>> int width = glassPixels.getWidth(); >>>>>> int height = glassPixels.getHeight(); >>>>>> WritableImage image = new WritableImage(width, height); >>>>>> >>>>>> int bytesPerComponent = glassPixels.getBytesPerComponent(); >>>>>> if (bytesPerComponent == INT_BUFFER_BYTES_PER_COMPONENT) { >>>>>> IntBuffer intBuffer = (IntBuffer) glassPixels.getPixels(); >>>>>> writeIntBufferToImage(intBuffer, image); >>>>>> } >>>>>> >>>>>> return image; >>>>>> } >>>>>> >>>>>> private void writeIntBufferToImage(IntBuffer intBuffer, >>>>>> WritableImage image) { >>>>>> PixelWriter pixelWriter = image.getPixelWriter(); >>>>>> double width = image.getWidth(); >>>>>> double height = image.getHeight(); >>>>>> >>>>>> for (int y = 0; y < height; y++) { >>>>>> for (int x = 0; x < width; x++) { >>>>>> int argb = intBuffer.get(); >>>>>> pixelWriter.setArgb(x, y, argb); >>>>>> } >>>>>> } >>>>>> } >>>>>> ``` >>>>>> >>>>>> Pixels is used to create a screen capture. >>>>>> >>>>>> ##### Suggested Public API Replacement >>>>>> >>>>>> Bypass needing to expose the Pixels class to the public API by >>>>>> changing the getScreenCapture method of Robot - that is, changing: >>>>>> >>>>>> `public Pixels getScreenCapture(int x, int y, int width, int height)` >>>>>> >>>>>> to: >>>>>> >>>>>> `public Image getScreenCapture(int x, int y, int width, int height)` >>>>>> >>>>>> #### com.sun.glass.ui.Robot >>>>>> >>>>>> ##### TestFX Usage >>>>>> >>>>>> Essentially every method of Robot is used: >>>>>> >>>>>> ``` >>>>>> public void keyPress(int code) >>>>>> public void keyRelease(int code) >>>>>> public int getMouseX() >>>>>> public int getMouseY() >>>>>> public void mouseMove(int x, int y) >>>>>> public void mousePress(int buttons) >>>>>> public void mouseRelease(int buttons) >>>>>> public void mouseWheel(int wheelAmt) >>>>>> public int getPixelColor(int x, int y) >>>>>> public Pixels getScreenCapture(int x, int y, int width, int height) >>>>>> ``` >>>>>> >>>>>> ##### Suggested Public API Replacement >>>>>> https://github.com/brcolow/openjfx/blob/master/modules/javaf >>>>>> x.graphics/src/main/java/javafx/scene/robot/Robot.java >>>>>> >>>>>> >>>>>> -- >>>>>> Michael Ennen >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Michael Ennen >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Michael Ennen >>>>> >>>> >>>> >>>> >>>> -- >>>> Michael Ennen >>>> >>>> >>> >>> >>> -- >>> Michael Ennen >>> >>> >> >> >> -- >> Michael Ennen >> > > > > -- > Michael Ennen > > -- Michael Ennen From kevin.rushforth at oracle.com Mon Jan 8 23:28:31 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 08 Jan 2018 15:28:31 -0800 Subject: Proposal For Inclusion of Robot and ParametersImpl in the Public API In-Reply-To: References: <5A25E463.1020309@oracle.com> <5A273A03.40902@oracle.com> <5A3AD041.8020301@oracle.com> <5A3ADEAF.6000903@oracle.com> Message-ID: <5A53FE9F.6000304@oracle.com> I'll take a look some time after RDP2 of JDK 10. -- Kevin Michael Ennen wrote: > Hey Kevin, > > Hope you had a good holiday. Hopefully you will get some time in the > coming weeks > to review my work. > > Thanks! > > On Wed, Dec 20, 2017 at 3:05 PM, Kevin Rushforth > > wrote: > > Sure, no problem. One quick comment is that a common way to solve > this is by delegating to an implementation class, which would then > be sub-classes. > > > -- Kevin > > > Michael Ennen wrote: >> I am not trying to be a burden here. I understand that you may >> not have time to hand-hold >> to this degree. I will try and make progress, sorry for the >> follow up question. >> >> On Wed, Dec 20, 2017 at 2:08 PM, Michael Ennen >> > wrote: >> >> How can Robot call into the implementation when it is a super >> class of the implementations? >> >> On Wed, Dec 20, 2017 at 2:04 PM, Kevin Rushforth >> > > wrote: >> >> >> >> Michael Ennen wrote: >>> I have a question about how to proceed with the Robot code. >>> >>> The base abstract Robot class >>> is: https://github.com/brcolow/openjfx/blob/master/modules/javafx.graphics/src/main/java/javafx/scene/robot/Robot.java >>> >>> >>> As you can see for each method, such as "getMouseX()" >>> there is a "_" prefixed method >>> which is abstract and a non-prefixed method: >>> >>> protected abstract int _getMouseX(); >>> >>> public int getMouseX() { >>> Application.checkEventThread(); >>> return _getMouseX(); >>> } >>> >>> I have copied this from the private Robot API. >>> >>> Is there a better way to do this? Would this pass review? >> >> Yes there are better ways to do this. No it would not >> pass review, since this would be leaking implementation >> into the public API. >> >> Rather than copying the public / protected methods from >> the internal package, it probably makes more sense to >> start with what a Robot API should look like and then >> have that call into the implementation (suitably modified >> so it better matches the public API). For one thing you >> will then leave the implementation, including the >> per-platform code, where it belongs -- in glass. The >> Robot API can be informed by the current implementation, >> but should not be defined by it. >> >> -- Kevin >> >> >>> >>> Thanks very much. >>> >>> >>> On Tue, Dec 5, 2017 at 5:29 PM, Kevin Rushforth >>> >> > wrote: >>> >>> Glad you got the build working. You can post back on >>> this thread when you are ready. >>> >>> >>> -- Kevin >>> >>> >>> Michael Ennen wrote: >>>> Correction: >>>> >>>> Adding ""--add-exports >>>> javafx.graphics/javafx.scene.robot=ALL-UNNAMED" to >>>> buildSrc/addExports. >>>> >>>> For posterity :) >>>> >>>> On Mon, Dec 4, 2017 at 6:08 PM, Michael Ennen >>>> >>> > wrote: >>>> >>>> Ah, indeed, missed adding "--add-opens >>>> javafx.graphics/javafx.scene.robot=ALL-UNNAMED" >>>> to buildSrc/addExports. >>>> Thanks for the guidance on that. >>>> >>>> I will continue to work on this in the GitHub >>>> repo and polish it up (add javadocs, better >>>> method signatures, etc.) and >>>> even plan on maybe improving the underlying >>>> native Robot implementations (for example >>>> fixing/improving the >>>> way color profiles are handled for MacRobot). >>>> >>>> I will also take a look at "fixing" JemmyFX to >>>> use the new public API (as well as any other >>>> place in the JavaFX code >>>> base that does). >>>> >>>> I was expecting that JDK 11 would be the >>>> appropriate time frame, especially because it >>>> will be the release where >>>> private APIs will be totally inaccessible, correct? >>>> >>>> After I get it in a reasonable state should I >>>> post back on this mailing list thread or what >>>> would be the appropriate >>>> way? >>>> >>>> Thanks Kevin. >>>> >>>> On Mon, Dec 4, 2017 at 5:12 PM, Kevin Rushforth >>>> >>> > wrote: >>>> >>>> This is a limitation of the the way >>>> --patch-modules works. You will need to add >>>> an entry in: >>>> >>>> buildSrc/addExports >>>> >>>> Btw, as for the proposal itself, this might >>>> need to be a JEP depending on the scope. In >>>> any case, it could be considered in the JDK >>>> 11 time frame, but there are several things >>>> that need to be worked out before making >>>> Robot a public API, including the fact that >>>> the JemmyFX framework in the >>>> openjfx/jfx/tests directory uses Robot. >>>> Once you get a working prototype, it would >>>> be interesting to discuss it in more detail. >>>> >>>> -- Kevin >>>> >>>> >>>> >>>> Michael Ennen wrote: >>>>> Currently I am stuck with tests not being able to see the new >>>>> "javafx.scene.robot" module: >>>>> >>>>> >>>>>> Task :systemTests:compileTestJava >>>>>> >>>>> C:\Users\brcolow\dev\openjfx\tests\system\src\test\java\test\robot\com\sun\glass\ui\monocle\ModalDialogTest.java:34: >>>>> error: package javafx.scene.robot is not visible >>>>> import javafx.scene.robot.Robot; >>>>> ^ >>>>> (package javafx.scene.robot is declared in module javafx.graphics, which >>>>> does not export it) >>>>> C:\Users\brcolow\dev\openjfx\tests\system\src\test\java\test\robot\com\sun\glass\ui\monocle\RobotTest.java:33: >>>>> error: package javafx.scene.robot is not visible >>>>> import javafx.scene.robot.Robot; >>>>> >>>>> I have added: >>>>> >>>>> exports javafx.scene.robot; >>>>> >>>>> to: modules/javafx.graphics/src/main/java/module-info.java >>>>> >>>>> But this does not seem to be enough. >>>>> >>>>> On Sun, Dec 3, 2017 at 4:48 PM, Michael Ennen wrote: >>>>> >>>>> >>>>>> I am still working on all the necessary changes to actually allow openjfx >>>>>> to compile. >>>>>> Tons to learn in that arena and I know the code as it is written won't >>>>>> totally work. >>>>>> For example one can no longer: >>>>>> >>>>>> #include "com_sun_glass_ui_Robot.h" >>>>>> >>>>>> as in openjfx\modules\javafx.graphics\src\main\native-glass\win\Robot.cpp >>>>>> >>>>>> But I am not sure how those headers are generated and if I can just simply >>>>>> change >>>>>> it to "#include javafx_scene_robot_Robot.h" (which I very much doubt). >>>>>> >>>>>> On Sun, Dec 3, 2017 at 2:29 PM, Michael Ennen >>>>>> wrote: >>>>>> >>>>>> >>>>>>> I have created a (small) proposal (building on the work of Benjamin >>>>>>> Gudehaus) about moving some classes in to the public API so that TestFX (a >>>>>>> JavaFX UI testing framework) can continue to work with future JDK releases. >>>>>>> The somewhat nicely formatted proposal can be found as a Github gist: >>>>>>> >>>>>>> https://gist.github.com/brcolow/26370db6cab0355186d4a1d13b30fc19 >>>>>>> >>>>>>> All suggested changes can be found by using Github Compare View: >>>>>>> >>>>>>> https://github.com/brcolow/openjfx/compare/4ccdbbbce5234e2c5 >>>>>>> e1f4f1cb8f20430feaa53b6...master >>>>>>> >>>>>>> But I have copied it to this email for convenience: >>>>>>> >>>>>>> ----------------------- PROPOSAL ----------------------- >>>>>>> >>>>>>> TestFX, the JavaFX GUI testing framework currently requires 4 (four) >>>>>>> classes that are part of the JDK's private API. They are: >>>>>>> >>>>>>> [com.sun.glass.ui.Application](http://hg.openjdk.java.net/op >>>>>>> enjfx/10-dev/rt/file/tip/modules/javafx.graphics/src/main/ >>>>>>> java/com/sun/glass/ui/Application.java) >>>>>>> [com.sun.glass.ui.Pixels](http://hg.openjdk.java.net/openjfx >>>>>>> /10-dev/rt/file/tip/modules/javafx.graphics/src/main/java/ >>>>>>> com/sun/glass/ui/Pixels.java) >>>>>>> [com.sun.glass.ui.Robot](http://hg.openjdk.java.net/openjfx/ >>>>>>> 10-dev/rt/file/tip/modules/javafx.graphics/src/main/java/com >>>>>>> /sun/glass/ui/Robot.java) >>>>>>> [com.sun.javafx.application.Pa rametersImpl](http://hg.openjd >>>>>>> k.java.net/openjfx/10-dev/rt/file/tip/modules/javafx. >>>>>>> graphics/src/main/java/com/sun/javafx/application/ParametersImpl.java ) >>>>>>> >>>>>>> In order to compile the project with Java 9, we use the following flags: >>>>>>> >>>>>>> ```sh >>>>>>> --add-exports javafx.graphics/com.sun.glass.ui=org.testfx >>>>>>> --add-exports javafx.graphics/com.sun.javafx.application=org.testfx >>>>>>> ``` >>>>>>> >>>>>>> If the --add-exports flags are disabled in a future Java release TestFX >>>>>>> will require these four classes to be moved into the public API to >>>>>>> continue working. >>>>>>> >>>>>>> While these classes are probably not very useful for applications to use >>>>>>> directly, any JavaFX application wanting to write UI tests will most >>>>>>> likely >>>>>>> use TestFX and thus they will indirectly be using these classes. >>>>>>> >>>>>>> JavaFX internal tests also use these classes for essentially the same >>>>>>> purpose (UI tests). >>>>>>> >>>>>>> ### Details of Usage For Each Private API Class >>>>>>> >>>>>>> #### com.sun.javafx.application.ParametersImpl >>>>>>> >>>>>>> ##### TestFX Usage >>>>>>> >>>>>>> ```java >>>>>>> ParametersImpl parameters = new ParametersImpl(applicationArgs); >>>>>>> ParametersImpl.registerParameters(application, parameters); >>>>>>> ``` >>>>>>> >>>>>>> The parameters are set on a constructed Application. >>>>>>> >>>>>>> ##### Suggested Public API Replacement >>>>>>> >>>>>>> `javafx.application.Application`: >>>>>>> >>>>>>> ```java >>>>>>> /** >>>>>>> * Sets the parameters for this Application. >>>>>>> * >>>>>>> *

>>>>>>> * NOTE: this method should not be called from the Application >>>>>>> constructor, >>>>>>> * as it will return null. It may be called in the init() method or any >>>>>>> * time after that. >>>>>>> *

>>>>>>> * >>>>>>> * @param parameters the parameters to set for this Application >>>>>>> */ >>>>>>> public final Parameters setParameters(String... parameters) { >>>>>>> ParametersImpl parameters = new ParametersImpl(parameters); >>>>>>> ParametersImpl.registerParameters(this, parameters); >>>>>>> } >>>>>>> ``` >>>>>>> >>>>>>> #### com.sun.glass.ui.Application >>>>>>> >>>>>>> ##### TestFX Usage >>>>>>> >>>>>>> ```java >>>>>>> return Application.GetApplication().createRobot(); >>>>>>> ``` >>>>>>> >>>>>>> The Application class is used to instantiate a Robot. >>>>>>> >>>>>>> ##### Suggested Public API Replacement >>>>>>> >>>>>>> `javafx.application.Application`: >>>>>>> >>>>>>> https://github.com/brcolow/openjfx/blob/master/modules/javaf >>>>>>> x.graphics/src/main/java/javafx/application/Application.java#L527 >>>>>>> >>>>>>> #### com.sun.glass.ui.Pixels >>>>>>> >>>>>>> ##### TestFX Usage >>>>>>> >>>>>>> ```java >>>>>>> @Override >>>>>>> public Image getCaptureRegion(Rectangle2D region) { >>>>>>> return waitForAsyncFx(RETRIEVAL_TIMEOUT_IN_MILLIS, () -> { >>>>>>> Pixels glassPixels = useRobot().getScreenCapture( >>>>>>> (int) region.getMinX(), (int) region.getMinY(), >>>>>>> (int) region.getWidth(), (int) region.getHeight() >>>>>>> ); >>>>>>> return convertFromGlassPixels(glassPixels); >>>>>>> }); >>>>>>> } >>>>>>> >>>>>>> private Image convertFromGlassPixels(Pixels glassPixels) { >>>>>>> int width = glassPixels.getWidth(); >>>>>>> int height = glassPixels.getHeight(); >>>>>>> WritableImage image = new WritableImage(width, height); >>>>>>> >>>>>>> int bytesPerComponent = glassPixels.getBytesPerComponent(); >>>>>>> if (bytesPerComponent == INT_BUFFER_BYTES_PER_COMPONENT) { >>>>>>> IntBuffer intBuffer = (IntBuffer) glassPixels.getPixels(); >>>>>>> writeIntBufferToImage(intBuffer, image); >>>>>>> } >>>>>>> >>>>>>> return image; >>>>>>> } >>>>>>> >>>>>>> private void writeIntBufferToImage(IntBuffer intBuffer, >>>>>>> WritableImage image) { >>>>>>> PixelWriter pixelWriter = image.getPixelWriter(); >>>>>>> double width = image.getWidth(); >>>>>>> double height = image.getHeight(); >>>>>>> >>>>>>> for (int y = 0; y < height; y++) { >>>>>>> for (int x = 0; x < width; x++) { >>>>>>> int argb = intBuffer.get(); >>>>>>> pixelWriter.setArgb(x, y, argb); >>>>>>> } >>>>>>> } >>>>>>> } >>>>>>> ``` >>>>>>> >>>>>>> Pixels is used to create a screen capture. >>>>>>> >>>>>>> ##### Suggested Public API Replacement >>>>>>> >>>>>>> Bypass needing to expose the Pixels class to the public API by >>>>>>> changing the getScreenCapture method of Robot - that is, changing: >>>>>>> >>>>>>> `public Pixels getScreenCapture(int x, int y, int width, int height)` >>>>>>> >>>>>>> to: >>>>>>> >>>>>>> `public Image getScreenCapture(int x, int y, int width, int height)` >>>>>>> >>>>>>> #### com.sun.glass.ui.Robot >>>>>>> >>>>>>> ##### TestFX Usage >>>>>>> >>>>>>> Essentially every method of Robot is used: >>>>>>> >>>>>>> ``` >>>>>>> public void keyPress(int code) >>>>>>> public void keyRelease(int code) >>>>>>> public int getMouseX() >>>>>>> public int getMouseY() >>>>>>> public void mouseMove(int x, int y) >>>>>>> public void mousePress(int buttons) >>>>>>> public void mouseRelease(int buttons) >>>>>>> public void mouseWheel(int wheelAmt) >>>>>>> public int getPixelColor(int x, int y) >>>>>>> public Pixels getScreenCapture(int x, int y, int width, int height) >>>>>>> ``` >>>>>>> >>>>>>> ##### Suggested Public API Replacement >>>>>>> >>>>>>> https://github.com/brcolow/openjfx/blob/master/modules/javaf >>>>>>> x.graphics/src/main/java/javafx/scene/robot/Robot.java >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Michael Ennen >>>>>>> >>>>>>> >>>>>> -- >>>>>> Michael Ennen >>>>>> >>>>>> >>>>> >>>> >>>> >>>> >>>> >>>> -- >>>> Michael Ennen >>>> >>>> >>>> >>>> >>>> -- >>>> Michael Ennen >>> >>> >>> >>> >>> -- >>> Michael Ennen >> >> >> >> >> -- >> Michael Ennen >> >> >> >> >> -- >> Michael Ennen > > > > > -- > Michael Ennen From mike.ennen at gmail.com Mon Jan 8 23:31:34 2018 From: mike.ennen at gmail.com (Michael Ennen) Date: Mon, 8 Jan 2018 16:31:34 -0700 Subject: Proposal For Inclusion of Robot and ParametersImpl in the Public API In-Reply-To: <5A53FE9F.6000304@oracle.com> References: <5A25E463.1020309@oracle.com> <5A273A03.40902@oracle.com> <5A3AD041.8020301@oracle.com> <5A3ADEAF.6000903@oracle.com> <5A53FE9F.6000304@oracle.com> Message-ID: Sounds great. Much appreciated. On Mon, Jan 8, 2018 at 4:28 PM, Kevin Rushforth wrote: > I'll take a look some time after RDP2 of JDK 10. > > > -- Kevin > > > Michael Ennen wrote: > > Hey Kevin, > > Hope you had a good holiday. Hopefully you will get some time in the > coming weeks > to review my work. > > Thanks! > > On Wed, Dec 20, 2017 at 3:05 PM, Kevin Rushforth < > kevin.rushforth at oracle.com> wrote: > >> Sure, no problem. One quick comment is that a common way to solve this is >> by delegating to an implementation class, which would then be sub-classes. >> >> >> -- Kevin >> >> >> Michael Ennen wrote: >> >> I am not trying to be a burden here. I understand that you may not have >> time to hand-hold >> to this degree. I will try and make progress, sorry for the follow up >> question. >> >> On Wed, Dec 20, 2017 at 2:08 PM, Michael Ennen >> wrote: >> >>> How can Robot call into the implementation when it is a super class of >>> the implementations? >>> >>> On Wed, Dec 20, 2017 at 2:04 PM, Kevin Rushforth < >>> kevin.rushforth at oracle.com> wrote: >>> >>>> >>>> >>>> Michael Ennen wrote: >>>> >>>> I have a question about how to proceed with the Robot code. >>>> >>>> The base abstract Robot class is: https://github.com/brcolow >>>> /openjfx/blob/master/modules/javafx.graphics/src/main/java/j >>>> avafx/scene/robot/Robot.java >>>> >>>> As you can see for each method, such as "getMouseX()" there is a "_" >>>> prefixed method >>>> which is abstract and a non-prefixed method: >>>> >>>> protected abstract int _getMouseX(); >>>> >>>> public int getMouseX() { >>>> Application.checkEventThread(); >>>> return _getMouseX(); >>>> } >>>> >>>> I have copied this from the private Robot API. >>>> >>>> Is there a better way to do this? Would this pass review? >>>> >>>> >>>> Yes there are better ways to do this. No it would not pass review, >>>> since this would be leaking implementation into the public API. >>>> >>>> Rather than copying the public / protected methods from the internal >>>> package, it probably makes more sense to start with what a Robot API should >>>> look like and then have that call into the implementation (suitably >>>> modified so it better matches the public API). For one thing you will then >>>> leave the implementation, including the per-platform code, where it belongs >>>> -- in glass. The Robot API can be informed by the current implementation, >>>> but should not be defined by it. >>>> >>>> -- Kevin >>>> >>>> >>>> >>>> Thanks very much. >>>> >>>> >>>> On Tue, Dec 5, 2017 at 5:29 PM, Kevin Rushforth < >>>> kevin.rushforth at oracle.com> wrote: >>>> >>>>> Glad you got the build working. You can post back on this thread when >>>>> you are ready. >>>>> >>>>> >>>>> -- Kevin >>>>> >>>>> >>>>> Michael Ennen wrote: >>>>> >>>>> Correction: >>>>> >>>>> Adding ""--add-exports javafx.graphics/javafx.scene.robot=ALL-UNNAMED" >>>>> to buildSrc/addExports. >>>>> >>>>> For posterity :) >>>>> >>>>> On Mon, Dec 4, 2017 at 6:08 PM, Michael Ennen >>>>> wrote: >>>>> >>>>>> Ah, indeed, missed adding "--add-opens javafx.graphics/javafx.scene.robot=ALL-UNNAMED" >>>>>> to buildSrc/addExports. >>>>>> Thanks for the guidance on that. >>>>>> >>>>>> I will continue to work on this in the GitHub repo and polish it up >>>>>> (add javadocs, better method signatures, etc.) and >>>>>> even plan on maybe improving the underlying native Robot >>>>>> implementations (for example fixing/improving the >>>>>> way color profiles are handled for MacRobot). >>>>>> >>>>>> I will also take a look at "fixing" JemmyFX to use the new public API >>>>>> (as well as any other place in the JavaFX code >>>>>> base that does). >>>>>> >>>>>> I was expecting that JDK 11 would be the appropriate time frame, >>>>>> especially because it will be the release where >>>>>> private APIs will be totally inaccessible, correct? >>>>>> >>>>>> After I get it in a reasonable state should I post back on this >>>>>> mailing list thread or what would be the appropriate >>>>>> way? >>>>>> >>>>>> Thanks Kevin. >>>>>> >>>>>> On Mon, Dec 4, 2017 at 5:12 PM, Kevin Rushforth < >>>>>> kevin.rushforth at oracle.com> wrote: >>>>>> >>>>>>> This is a limitation of the the way --patch-modules works. You will >>>>>>> need to add an entry in: >>>>>>> >>>>>>> buildSrc/addExports >>>>>>> >>>>>>> Btw, as for the proposal itself, this might need to be a JEP >>>>>>> depending on the scope. In any case, it could be considered in the JDK 11 >>>>>>> time frame, but there are several things that need to be worked out before >>>>>>> making Robot a public API, including the fact that the JemmyFX framework in >>>>>>> the openjfx/jfx/tests directory uses Robot. Once you get a working >>>>>>> prototype, it would be interesting to discuss it in more detail. >>>>>>> >>>>>>> -- Kevin >>>>>>> >>>>>>> >>>>>>> >>>>>>> Michael Ennen wrote: >>>>>>> >>>>>>> Currently I am stuck with tests not being able to see the new >>>>>>> "javafx.scene.robot" module: >>>>>>> >>>>>>> >>>>>>> >>>>>>> Task :systemTests:compileTestJava >>>>>>> >>>>>>> >>>>>>> C:\Users\brcolow\dev\openjfx\tests\system\src\test\java\test\robot\com\sun\glass\ui\monocle\ModalDialogTest.java:34: >>>>>>> error: package javafx.scene.robot is not visible >>>>>>> import javafx.scene.robot.Robot; >>>>>>> ^ >>>>>>> (package javafx.scene.robot is declared in module javafx.graphics, which >>>>>>> does not export it) >>>>>>> C:\Users\brcolow\dev\openjfx\tests\system\src\test\java\test\robot\com\sun\glass\ui\monocle\RobotTest.java:33: >>>>>>> error: package javafx.scene.robot is not visible >>>>>>> import javafx.scene.robot.Robot; >>>>>>> >>>>>>> I have added: >>>>>>> >>>>>>> exports javafx.scene.robot; >>>>>>> >>>>>>> to: modules/javafx.graphics/src/main/java/module-info.java >>>>>>> >>>>>>> But this does not seem to be enough. >>>>>>> >>>>>>> On Sun, Dec 3, 2017 at 4:48 PM, Michael Ennen wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> I am still working on all the necessary changes to actually allow openjfx >>>>>>> to compile. >>>>>>> Tons to learn in that arena and I know the code as it is written won't >>>>>>> totally work. >>>>>>> For example one can no longer: >>>>>>> >>>>>>> #include "com_sun_glass_ui_Robot.h" >>>>>>> >>>>>>> as in openjfx\modules\javafx.graphics\src\main\native-glass\win\Robot.cpp >>>>>>> >>>>>>> But I am not sure how those headers are generated and if I can just simply >>>>>>> change >>>>>>> it to "#include javafx_scene_robot_Robot.h" (which I very much doubt). >>>>>>> >>>>>>> On Sun, Dec 3, 2017 at 2:29 PM, Michael Ennen >>>>>>> wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> I have created a (small) proposal (building on the work of Benjamin >>>>>>> Gudehaus) about moving some classes in to the public API so that TestFX (a >>>>>>> JavaFX UI testing framework) can continue to work with future JDK releases. >>>>>>> The somewhat nicely formatted proposal can be found as a Github gist: >>>>>>> https://gist.github.com/brcolow/26370db6cab0355186d4a1d13b30fc19 >>>>>>> >>>>>>> All suggested changes can be found by using Github Compare View: >>>>>>> https://github.com/brcolow/openjfx/compare/4ccdbbbce5234e2c5 >>>>>>> e1f4f1cb8f20430feaa53b6...master >>>>>>> >>>>>>> But I have copied it to this email for convenience: >>>>>>> >>>>>>> ----------------------- PROPOSAL ----------------------- >>>>>>> >>>>>>> TestFX, the JavaFX GUI testing framework currently requires 4 (four) >>>>>>> classes that are part of the JDK's private API. They are: >>>>>>> >>>>>>> [com.sun.glass.ui.Application](http://hg.openjdk.java.net/op >>>>>>> enjfx/10-dev/rt/file/tip/modules/javafx.graphics/src/main/ >>>>>>> java/com/sun/glass/ui/Application.java) >>>>>>> [com.sun.glass.ui.Pixels](http://hg.openjdk.java.net/openjfx >>>>>>> /10-dev/rt/file/tip/modules/javafx.graphics/src/main/java/ >>>>>>> com/sun/glass/ui/Pixels.java) >>>>>>> [com.sun.glass.ui.Robot](http://hg.openjdk.java.net/openjfx/ >>>>>>> 10-dev/rt/file/tip/modules/javafx.graphics/src/main/java/com >>>>>>> /sun/glass/ui/Robot.java) >>>>>>> [com.sun.javafx.application.ParametersImpl](http://hg.openjdk.java.net/openjfx/10-dev/rt/file/tip/modules/javafx. >>>>>>> graphics/src/main/java/com/sun/javafx/application/ParametersImpl.java ) >>>>>>> >>>>>>> In order to compile the project with Java 9, we use the following flags: >>>>>>> >>>>>>> ```sh >>>>>>> --add-exports javafx.graphics/com.sun.glass.ui=org.testfx >>>>>>> --add-exports javafx.graphics/com.sun.javafx.application=org.testfx >>>>>>> ``` >>>>>>> >>>>>>> If the --add-exports flags are disabled in a future Java release TestFX >>>>>>> will require these four classes to be moved into the public API to >>>>>>> continue working. >>>>>>> >>>>>>> While these classes are probably not very useful for applications to use >>>>>>> directly, any JavaFX application wanting to write UI tests will most >>>>>>> likely >>>>>>> use TestFX and thus they will indirectly be using these classes. >>>>>>> >>>>>>> JavaFX internal tests also use these classes for essentially the same >>>>>>> purpose (UI tests). >>>>>>> >>>>>>> ### Details of Usage For Each Private API Class >>>>>>> >>>>>>> #### com.sun.javafx.application.ParametersImpl >>>>>>> >>>>>>> ##### TestFX Usage >>>>>>> >>>>>>> ```java >>>>>>> ParametersImpl parameters = new ParametersImpl(applicationArgs); >>>>>>> ParametersImpl.registerParameters(application, parameters); >>>>>>> ``` >>>>>>> >>>>>>> The parameters are set on a constructed Application. >>>>>>> >>>>>>> ##### Suggested Public API Replacement >>>>>>> >>>>>>> `javafx.application.Application`: >>>>>>> >>>>>>> ```java >>>>>>> /** >>>>>>> * Sets the parameters for this Application. >>>>>>> * >>>>>>> *

>>>>>>> * NOTE: this method should not be called from the Application >>>>>>> constructor, >>>>>>> * as it will return null. It may be called in the init() method or any >>>>>>> * time after that. >>>>>>> *

>>>>>>> * >>>>>>> * @param parameters the parameters to set for this Application >>>>>>> */ >>>>>>> public final Parameters setParameters(String... parameters) { >>>>>>> ParametersImpl parameters = new ParametersImpl(parameters); >>>>>>> ParametersImpl.registerParameters(this, parameters); >>>>>>> } >>>>>>> ``` >>>>>>> >>>>>>> #### com.sun.glass.ui.Application >>>>>>> >>>>>>> ##### TestFX Usage >>>>>>> >>>>>>> ```java >>>>>>> return Application.GetApplication().createRobot(); >>>>>>> ``` >>>>>>> >>>>>>> The Application class is used to instantiate a Robot. >>>>>>> >>>>>>> ##### Suggested Public API Replacement >>>>>>> >>>>>>> `javafx.application.Application`: >>>>>>> https://github.com/brcolow/openjfx/blob/master/modules/javaf >>>>>>> x.graphics/src/main/java/javafx/application/Application.java#L527 >>>>>>> >>>>>>> #### com.sun.glass.ui.Pixels >>>>>>> >>>>>>> ##### TestFX Usage >>>>>>> >>>>>>> ```java >>>>>>> @Override >>>>>>> public Image getCaptureRegion(Rectangle2D region) { >>>>>>> return waitForAsyncFx(RETRIEVAL_TIMEOUT_IN_MILLIS, () -> { >>>>>>> Pixels glassPixels = useRobot().getScreenCapture( >>>>>>> (int) region.getMinX(), (int) region.getMinY(), >>>>>>> (int) region.getWidth(), (int) region.getHeight() >>>>>>> ); >>>>>>> return convertFromGlassPixels(glassPixels); >>>>>>> }); >>>>>>> } >>>>>>> >>>>>>> private Image convertFromGlassPixels(Pixels glassPixels) { >>>>>>> int width = glassPixels.getWidth(); >>>>>>> int height = glassPixels.getHeight(); >>>>>>> WritableImage image = new WritableImage(width, height); >>>>>>> >>>>>>> int bytesPerComponent = glassPixels.getBytesPerComponent(); >>>>>>> if (bytesPerComponent == INT_BUFFER_BYTES_PER_COMPONENT) { >>>>>>> IntBuffer intBuffer = (IntBuffer) glassPixels.getPixels(); >>>>>>> writeIntBufferToImage(intBuffer, image); >>>>>>> } >>>>>>> >>>>>>> return image; >>>>>>> } >>>>>>> >>>>>>> private void writeIntBufferToImage(IntBuffer intBuffer, >>>>>>> WritableImage image) { >>>>>>> PixelWriter pixelWriter = image.getPixelWriter(); >>>>>>> double width = image.getWidth(); >>>>>>> double height = image.getHeight(); >>>>>>> >>>>>>> for (int y = 0; y < height; y++) { >>>>>>> for (int x = 0; x < width; x++) { >>>>>>> int argb = intBuffer.get(); >>>>>>> pixelWriter.setArgb(x, y, argb); >>>>>>> } >>>>>>> } >>>>>>> } >>>>>>> ``` >>>>>>> >>>>>>> Pixels is used to create a screen capture. >>>>>>> >>>>>>> ##### Suggested Public API Replacement >>>>>>> >>>>>>> Bypass needing to expose the Pixels class to the public API by >>>>>>> changing the getScreenCapture method of Robot - that is, changing: >>>>>>> >>>>>>> `public Pixels getScreenCapture(int x, int y, int width, int height)` >>>>>>> >>>>>>> to: >>>>>>> >>>>>>> `public Image getScreenCapture(int x, int y, int width, int height)` >>>>>>> >>>>>>> #### com.sun.glass.ui.Robot >>>>>>> >>>>>>> ##### TestFX Usage >>>>>>> >>>>>>> Essentially every method of Robot is used: >>>>>>> >>>>>>> ``` >>>>>>> public void keyPress(int code) >>>>>>> public void keyRelease(int code) >>>>>>> public int getMouseX() >>>>>>> public int getMouseY() >>>>>>> public void mouseMove(int x, int y) >>>>>>> public void mousePress(int buttons) >>>>>>> public void mouseRelease(int buttons) >>>>>>> public void mouseWheel(int wheelAmt) >>>>>>> public int getPixelColor(int x, int y) >>>>>>> public Pixels getScreenCapture(int x, int y, int width, int height) >>>>>>> ``` >>>>>>> >>>>>>> ##### Suggested Public API Replacement >>>>>>> https://github.com/brcolow/openjfx/blob/master/modules/javaf >>>>>>> x.graphics/src/main/java/javafx/scene/robot/Robot.java >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Michael Ennen >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Michael Ennen >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Michael Ennen >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Michael Ennen >>>>> >>>>> >>>> >>>> >>>> -- >>>> Michael Ennen >>>> >>>> >>> >>> >>> -- >>> Michael Ennen >>> >> >> >> >> -- >> Michael Ennen >> >> > > > -- > Michael Ennen > > -- Michael Ennen From nlisker at gmail.com Tue Jan 9 17:44:41 2018 From: nlisker at gmail.com (Nir Lisker) Date: Tue, 9 Jan 2018 19:44:41 +0200 Subject: Error while pushing changeset Message-ID: Iv'e created a small documentation fix and tried to push it to http://hg.openjdk.java.net/openjfx/jfx-dev/rt. I got an error: abort: push creates new remote head 2152a80ee902! hint: pull and merge or see 'hg help push' for details about pushing new heads [command returned code 255 Tue Jan 09 19:40:10 2018] What can be the problem? From kevin.rushforth at oracle.com Tue Jan 9 18:50:52 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 09 Jan 2018 10:50:52 -0800 Subject: Error while pushing changeset In-Reply-To: References: Message-ID: <5A550F0C.50108@oracle.com> Why would you even try to push a changeset without getting it reviewed first??? This shows a lack of understanding about our processes and policies. Only committers have permission to push changesets, and only after review. Please familiarize yourself with the policies and procedures surrounding contributing to OpenJFX [1] [2] [3] [4] [5]. Once you are familiar with these policies and have signed the Oracle Contributor Agreement (OCA) you can work with someone to sponsor your change. -- Kevin [1] http://openjdk.java.net/contribute/ [2] http://www.oracle.com/technetwork/community/oca-486395.html [3] https://wiki.openjdk.java.net/display/OpenJFX/Submitting+a+Bug+Report [4] https://wiki.openjdk.java.net/display/OpenJFX/Code+Reviews [5] https://wiki.openjdk.java.net/display/OpenJFX/Committing+the+Code Nir Lisker wrote: > Iv'e created a small documentation fix and tried to push it to > http://hg.openjdk.java.net/openjfx/jfx-dev/rt. I got an error: > > abort: push creates new remote head 2152a80ee902! > hint: pull and merge or see 'hg help push' for details about pushing new > heads > [command returned code 255 Tue Jan 09 19:40:10 2018] > > What can be the problem? > From nlisker at gmail.com Tue Jan 9 19:32:07 2018 From: nlisker at gmail.com (Nir Lisker) Date: Tue, 9 Jan 2018 21:32:07 +0200 Subject: Error while pushing changeset In-Reply-To: <5A550F0C.50108@oracle.com> References: <5A550F0C.50108@oracle.com> Message-ID: > This shows a lack of understanding about our processes Yes it does, which is why I asked about it yesterday. I'll send a webrev. Thanks, Nir On Tue, Jan 9, 2018 at 8:50 PM, Kevin Rushforth wrote: > Why would you even try to push a changeset without getting it reviewed > first??? > > This shows a lack of understanding about our processes and policies. Only > committers have permission to push changesets, and only after review. > Please familiarize yourself with the policies and procedures surrounding > contributing to OpenJFX [1] [2] [3] [4] [5]. Once you are familiar with > these policies and have signed the Oracle Contributor Agreement (OCA) you > can work with someone to sponsor your change. > > -- Kevin > > [1] http://openjdk.java.net/contribute/ > [2] http://www.oracle.com/technetwork/community/oca-486395.html > [3] https://wiki.openjdk.java.net/display/OpenJFX/Submitting+a+Bug+Report > [4] https://wiki.openjdk.java.net/display/OpenJFX/Code+Reviews > [5] https://wiki.openjdk.java.net/display/OpenJFX/Committing+the+Code > > > > Nir Lisker wrote: > >> Iv'e created a small documentation fix and tried to push it to >> http://hg.openjdk.java.net/openjfx/jfx-dev/rt. I got an error: >> >> abort: push creates new remote head 2152a80ee902! >> hint: pull and merge or see 'hg help push' for details about pushing new >> heads >> [command returned code 255 Tue Jan 09 19:40:10 2018] >> >> What can be the problem? >> >> > From kevin.rushforth at oracle.com Tue Jan 9 19:37:49 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 09 Jan 2018 11:37:49 -0800 Subject: Error while pushing changeset In-Reply-To: References: <5A550F0C.50108@oracle.com> Message-ID: <5A551A0D.5090506@oracle.com> Nir Lisker wrote: > > This shows a lack of understanding about our processes > > Yes it does, which is why I asked about it yesterday. I'll send a webrev. Ah, I haven't gotten to your email from yesterday, since I was on vacation and am still catching up. If you can send a webrev, and a pointer to a JBS issue, I'll attach it for you. If there isn't an existing JBS issue, then please file one (and I'll see that it gets moved into the JDK project quickly). I also note that tith simple javadoc changes, this can be done prior to your OCA being recorded if you like. Thanks. -- Kevin > > Thanks, > Nir > > On Tue, Jan 9, 2018 at 8:50 PM, Kevin Rushforth > > wrote: > > Why would you even try to push a changeset without getting it > reviewed first??? > > This shows a lack of understanding about our processes and > policies. Only committers have permission to push changesets, and > only after review. Please familiarize yourself with the policies > and procedures surrounding contributing to OpenJFX [1] [2] [3] [4] > [5]. Once you are familiar with these policies and have signed the > Oracle Contributor Agreement (OCA) you can work with someone to > sponsor your change. > > -- Kevin > > [1] http://openjdk.java.net/contribute/ > > [2] http://www.oracle.com/technetwork/community/oca-486395.html > > [3] > https://wiki.openjdk.java.net/display/OpenJFX/Submitting+a+Bug+Report > > [4] https://wiki.openjdk.java.net/display/OpenJFX/Code+Reviews > > [5] > https://wiki.openjdk.java.net/display/OpenJFX/Committing+the+Code > > > > > Nir Lisker wrote: > > Iv'e created a small documentation fix and tried to push it to > http://hg.openjdk.java.net/openjfx/jfx-dev/rt > . I got an error: > > abort: push creates new remote head 2152a80ee902! > hint: pull and merge or see 'hg help push' for details about > pushing new > heads > [command returned code 255 Tue Jan 09 19:40:10 2018] > > What can be the problem? > > > From kevin.rushforth at oracle.com Tue Jan 9 19:43:53 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 09 Jan 2018 11:43:53 -0800 Subject: Error while pushing changeset In-Reply-To: <5A551A0D.5090506@oracle.com> References: <5A550F0C.50108@oracle.com> <5A551A0D.5090506@oracle.com> Message-ID: <5A551B79.9070708@oracle.com> > I also note that tith simple javadoc changes... "with" simple ... -- Kevin Kevin Rushforth wrote: > > > Nir Lisker wrote: >> > This shows a lack of understanding about our processes >> >> Yes it does, which is why I asked about it yesterday. I'll send a >> webrev. > > Ah, I haven't gotten to your email from yesterday, since I was on > vacation and am still catching up. If you can send a webrev, and a > pointer to a JBS issue, I'll attach it for you. If there isn't an > existing JBS issue, then please file one (and I'll see that it gets > moved into the JDK project quickly). I also note that tith simple > javadoc changes, this can be done prior to your OCA being recorded if > you like. > > Thanks. > > -- Kevin > > >> >> Thanks, >> Nir >> >> On Tue, Jan 9, 2018 at 8:50 PM, Kevin Rushforth >> > wrote: >> >> Why would you even try to push a changeset without getting it >> reviewed first??? >> >> This shows a lack of understanding about our processes and >> policies. Only committers have permission to push changesets, and >> only after review. Please familiarize yourself with the policies >> and procedures surrounding contributing to OpenJFX [1] [2] [3] [4] >> [5]. Once you are familiar with these policies and have signed the >> Oracle Contributor Agreement (OCA) you can work with someone to >> sponsor your change. >> >> -- Kevin >> >> [1] http://openjdk.java.net/contribute/ >> >> [2] http://www.oracle.com/technetwork/community/oca-486395.html >> >> [3] >> >> https://wiki.openjdk.java.net/display/OpenJFX/Submitting+a+Bug+Report >> >> >> [4] https://wiki.openjdk.java.net/display/OpenJFX/Code+Reviews >> >> [5] >> https://wiki.openjdk.java.net/display/OpenJFX/Committing+the+Code >> >> >> >> >> Nir Lisker wrote: >> >> Iv'e created a small documentation fix and tried to push it to >> http://hg.openjdk.java.net/openjfx/jfx-dev/rt >> . I got an error: >> >> abort: push creates new remote head 2152a80ee902! >> hint: pull and merge or see 'hg help push' for details about >> pushing new >> heads >> [command returned code 255 Tue Jan 09 19:40:10 2018] >> >> What can be the problem? >> >> From nlisker at gmail.com Tue Jan 9 19:55:14 2018 From: nlisker at gmail.com (Nir Lisker) Date: Tue, 9 Jan 2018 21:55:14 +0200 Subject: Error while pushing changeset In-Reply-To: <5A551B79.9070708@oracle.com> References: <5A550F0C.50108@oracle.com> <5A551A0D.5090506@oracle.com> <5A551B79.9070708@oracle.com> Message-ID: > > If there isn't an existing JBS issue, then please file one I thought I would point to "8188314: Fix typos in FX API docs" even though the exact changes I'm proposing are not listed there, but I can submit a new bug just for those if it really matters (it will be another Fix Typos issue). > I also note that with simple javadoc changes, this can be done prior to > your OCA being recorded if you like Yes, as a Participant. Iv'e signed the Sun CA some 7 years ago and this week signed the OCA in case it didn't transfer over. It's not crucial to handle it right now since the changes are trivial. I haven't gotten to your email from yesterday It's a bit of a loaded one so it can wait after the RDP. I only needed the minimum info to get these fixes before the RDP. - Nir On Tue, Jan 9, 2018 at 9:43 PM, Kevin Rushforth wrote: > > I also note that tith simple javadoc changes... > > "with" simple ... > > -- Kevin > > > > Kevin Rushforth wrote: > >> >> >> Nir Lisker wrote: >> >>> > This shows a lack of understanding about our processes >>> >>> Yes it does, which is why I asked about it yesterday. I'll send a webrev. >>> >> >> Ah, I haven't gotten to your email from yesterday, since I was on >> vacation and am still catching up. If you can send a webrev, and a pointer >> to a JBS issue, I'll attach it for you. If there isn't an existing JBS >> issue, then please file one (and I'll see that it gets moved into the JDK >> project quickly). I also note that tith simple javadoc changes, this can be >> done prior to your OCA being recorded if you like. >> >> Thanks. >> >> -- Kevin >> >> >> >>> Thanks, >>> Nir >>> >>> >>> On Tue, Jan 9, 2018 at 8:50 PM, Kevin Rushforth < >>> kevin.rushforth at oracle.com > wrote: >>> >>> Why would you even try to push a changeset without getting it >>> reviewed first??? >>> >>> This shows a lack of understanding about our processes and >>> policies. Only committers have permission to push changesets, and >>> only after review. Please familiarize yourself with the policies >>> and procedures surrounding contributing to OpenJFX [1] [2] [3] [4] >>> [5]. Once you are familiar with these policies and have signed the >>> Oracle Contributor Agreement (OCA) you can work with someone to >>> sponsor your change. >>> >>> -- Kevin >>> >>> [1] http://openjdk.java.net/contribute/ >>> >>> [2] http://www.oracle.com/technetwork/community/oca-486395.html >>> >>> [3] >>> https://wiki.openjdk.java.net/display/OpenJFX/Submitting+a+B >>> ug+Report >>> >> Bug+Report> >>> [4] https://wiki.openjdk.java.net/display/OpenJFX/Code+Reviews >>> >>> [5] >>> https://wiki.openjdk.java.net/display/OpenJFX/Committing+the+Code >>> >>> >>> >>> >>> Nir Lisker wrote: >>> >>> Iv'e created a small documentation fix and tried to push it to >>> http://hg.openjdk.java.net/openjfx/jfx-dev/rt >>> . I got an error: >>> >>> abort: push creates new remote head 2152a80ee902! >>> hint: pull and merge or see 'hg help push' for details about >>> pushing new >>> heads >>> [command returned code 255 Tue Jan 09 19:40:10 2018] >>> >>> What can be the problem? >>> >>> >> From kevin.rushforth at oracle.com Tue Jan 9 20:51:17 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 09 Jan 2018 12:51:17 -0800 Subject: Error while pushing changeset In-Reply-To: References: <5A550F0C.50108@oracle.com> <5A551A0D.5090506@oracle.com> <5A551B79.9070708@oracle.com> Message-ID: <5A552B45.3060001@oracle.com> Nir Lisker wrote: > > If there isn't an existing JBS issue, then please file one > > > I thought I would point to "8188314: Fix typos in FX API docs" even > though the exact changes I'm proposing are not listed there, but I can > submit a new bug just for those if it really matters (it will be > another Fix Typos issue). We'll need a new JBS bug, since that one is already resolved with a changeset (every changeset needs a unique bug ID). Feel free to use the same synopsis if you like. > > > I also note that with simple javadoc changes, this can be done > prior to your OCA being recorded if you like > > > Yes, as a Participant. Iv'e signed the Sun CA some 7 years ago and > this week signed the OCA in case it didn't transfer over. It's not > crucial to handle it right now since the changes are trivial. Good. > > I haven't gotten to your email from yesterday > > > It's a bit of a loaded one so it can wait after the RDP. I only needed > the minimum info to get these fixes before the RDP. OK. -- Kevin > - Nir > > On Tue, Jan 9, 2018 at 9:43 PM, Kevin Rushforth > > wrote: > > > I also note that tith simple javadoc changes... > > "with" simple ... > > -- Kevin > > > > Kevin Rushforth wrote: > > > > Nir Lisker wrote: > > > This shows a lack of understanding about our processes > > Yes it does, which is why I asked about it yesterday. I'll > send a webrev. > > > Ah, I haven't gotten to your email from yesterday, since I was > on vacation and am still catching up. If you can send a > webrev, and a pointer to a JBS issue, I'll attach it for you. > If there isn't an existing JBS issue, then please file one > (and I'll see that it gets moved into the JDK project > quickly). I also note that tith simple javadoc changes, this > can be done prior to your OCA being recorded if you like. > > Thanks. > > -- Kevin > > > > Thanks, > Nir > > > On Tue, Jan 9, 2018 at 8:50 PM, Kevin Rushforth > > >> wrote: > > Why would you even try to push a changeset without > getting it > reviewed first??? > > This shows a lack of understanding about our processes and > policies. Only committers have permission to push > changesets, and > only after review. Please familiarize yourself with > the policies > and procedures surrounding contributing to OpenJFX [1] > [2] [3] [4] > [5]. Once you are familiar with these policies and > have signed the > Oracle Contributor Agreement (OCA) you can work with > someone to > sponsor your change. > > -- Kevin > > [1] http://openjdk.java.net/contribute/ > > > > [2] > http://www.oracle.com/technetwork/community/oca-486395.html > > > > > [3] > > https://wiki.openjdk.java.net/display/OpenJFX/Submitting+a+Bug+Report > > > > > [4] > https://wiki.openjdk.java.net/display/OpenJFX/Code+Reviews > > > > > [5] > > https://wiki.openjdk.java.net/display/OpenJFX/Committing+the+Code > > > > > > > > Nir Lisker wrote: > > Iv'e created a small documentation fix and tried > to push it to > http://hg.openjdk.java.net/openjfx/jfx-dev/rt > > >. I got an > error: > > abort: push creates new remote head 2152a80ee902! > hint: pull and merge or see 'hg help push' for > details about > pushing new > heads > [command returned code 255 Tue Jan 09 19:40:10 2018] > > What can be the problem? > > > From murali.billa at oracle.com Tue Jan 9 20:53:23 2018 From: murali.billa at oracle.com (Murali Billa) Date: Tue, 9 Jan 2018 12:53:23 -0800 (PST) Subject: [11] Review request for 8193590: Memory leak when using WebView with Tooltip Message-ID: <31e83a0f-5ccf-4b64-a291-c8047f7467e5@default> ? Hi, Please review the below simple fix. JIRA: https://bugs.openjdk.java.net/browse/JDK-8193590 ? Webrev: http://cr.openjdk.java.net/~mbilla/8193590/webrev.01/ ? Thanks, Murali From nlisker at gmail.com Tue Jan 9 23:28:59 2018 From: nlisker at gmail.com (Nir Lisker) Date: Wed, 10 Jan 2018 01:28:59 +0200 Subject: Error while pushing changeset In-Reply-To: <5A552B45.3060001@oracle.com> References: <5A550F0C.50108@oracle.com> <5A551A0D.5090506@oracle.com> <5A551B79.9070708@oracle.com> <5A552B45.3060001@oracle.com> Message-ID: Submitted a new bug with ID: 9052190. On Tue, Jan 9, 2018 at 10:51 PM, Kevin Rushforth wrote: > > > Nir Lisker wrote: > > If there isn't an existing JBS issue, then please file one > > > I thought I would point to "8188314: Fix typos in FX API docs" even though > the exact changes I'm proposing are not listed there, but I can submit a > new bug just for those if it really matters (it will be another Fix Typos > issue). > > > We'll need a new JBS bug, since that one is already resolved with a > changeset (every changeset needs a unique bug ID). Feel free to use the > same synopsis if you like. > > > > >> I also note that with simple javadoc changes, this can be done prior to >> your OCA being recorded if you like > > > Yes, as a Participant. Iv'e signed the Sun CA some 7 years ago and this > week signed the OCA in case it didn't transfer over. It's not crucial to > handle it right now since the changes are trivial. > > > Good. > > > I haven't gotten to your email from yesterday > > > It's a bit of a loaded one so it can wait after the RDP. I only needed the > minimum info to get these fixes before the RDP. > > > OK. > > -- Kevin > > > - Nir > > On Tue, Jan 9, 2018 at 9:43 PM, Kevin Rushforth < > kevin.rushforth at oracle.com> wrote: > >> > I also note that tith simple javadoc changes... >> >> "with" simple ... >> >> -- Kevin >> >> >> >> Kevin Rushforth wrote: >> >>> >>> >>> Nir Lisker wrote: >>> >>>> > This shows a lack of understanding about our processes >>>> >>>> Yes it does, which is why I asked about it yesterday. I'll send a >>>> webrev. >>>> >>> >>> Ah, I haven't gotten to your email from yesterday, since I was on >>> vacation and am still catching up. If you can send a webrev, and a pointer >>> to a JBS issue, I'll attach it for you. If there isn't an existing JBS >>> issue, then please file one (and I'll see that it gets moved into the JDK >>> project quickly). I also note that tith simple javadoc changes, this can be >>> done prior to your OCA being recorded if you like. >>> >>> Thanks. >>> >>> -- Kevin >>> >>> >>> >>>> Thanks, >>>> Nir >>>> >>>> >>>> On Tue, Jan 9, 2018 at 8:50 PM, Kevin Rushforth < >>>> kevin.rushforth at oracle.com > wrote: >>>> >>>> Why would you even try to push a changeset without getting it >>>> reviewed first??? >>>> >>>> This shows a lack of understanding about our processes and >>>> policies. Only committers have permission to push changesets, and >>>> only after review. Please familiarize yourself with the policies >>>> and procedures surrounding contributing to OpenJFX [1] [2] [3] [4] >>>> [5]. Once you are familiar with these policies and have signed the >>>> Oracle Contributor Agreement (OCA) you can work with someone to >>>> sponsor your change. >>>> >>>> -- Kevin >>>> >>>> [1] http://openjdk.java.net/contribute/ >>>> >>>> [2] http://www.oracle.com/technetwork/community/oca-486395.html >>>> >>>> [3] >>>> https://wiki.openjdk.java.net/display/OpenJFX/Submitting+a+B >>>> ug+Report >>>> >>> Bug+Report> >>>> [4] https://wiki.openjdk.java.net/display/OpenJFX/Code+Reviews >>>> >>>> [5] >>>> https://wiki.openjdk.java.net/display/OpenJFX/Committing+the+Code >>>> >>>> >>>> >>>> >>>> Nir Lisker wrote: >>>> >>>> Iv'e created a small documentation fix and tried to push it to >>>> http://hg.openjdk.java.net/openjfx/jfx-dev/rt >>>> . I got an >>>> error: >>>> >>>> abort: push creates new remote head 2152a80ee902! >>>> hint: pull and merge or see 'hg help push' for details about >>>> pushing new >>>> heads >>>> [command returned code 255 Tue Jan 09 19:40:10 2018] >>>> >>>> What can be the problem? >>>> >>>> >>> > From kevin.rushforth at oracle.com Wed Jan 10 16:05:46 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 10 Jan 2018 08:05:46 -0800 Subject: Error while pushing changeset In-Reply-To: References: <5A550F0C.50108@oracle.com> <5A551A0D.5090506@oracle.com> <5A551B79.9070708@oracle.com> <5A552B45.3060001@oracle.com> Message-ID: <5A5639DA.6090901@oracle.com> The bug has now been moved to the JDK project, so the ID has changed to 8194871. https://bugs.openjdk.java.net/browse/JDK-8194871 I'll upload your webrev once you send it. Thanks. -- Kevin Nir Lisker wrote: > Submitted a new bug with ID: 9052190. > > On Tue, Jan 9, 2018 at 10:51 PM, Kevin Rushforth > > wrote: > > > > Nir Lisker wrote: >> >> If there isn't an existing JBS issue, then please file one >> >> >> I thought I would point to "8188314: Fix typos in FX API docs" >> even though the exact changes I'm proposing are not listed there, >> but I can submit a new bug just for those if it really matters >> (it will be another Fix Typos issue). > > We'll need a new JBS bug, since that one is already resolved with > a changeset (every changeset needs a unique bug ID). Feel free to > use the same synopsis if you like. > > >> >> >> I also note that with simple javadoc changes, this can be >> done prior to your OCA being recorded if you like >> >> >> Yes, as a Participant. Iv'e signed the Sun CA some 7 years ago >> and this week signed the OCA in case it didn't transfer over. >> It's not crucial to handle it right now since the changes are >> trivial. > > Good. > >> >> I haven't gotten to your email from yesterday >> >> >> It's a bit of a loaded one so it can wait after the RDP. I only >> needed the minimum info to get these fixes before the RDP. > > OK. > > -- Kevin > > >> - Nir >> >> On Tue, Jan 9, 2018 at 9:43 PM, Kevin Rushforth >> > >> wrote: >> >> > I also note that tith simple javadoc changes... >> >> "with" simple ... >> >> -- Kevin >> >> >> >> Kevin Rushforth wrote: >> >> >> >> Nir Lisker wrote: >> >> > This shows a lack of understanding about our processes >> >> Yes it does, which is why I asked about it yesterday. >> I'll send a webrev. >> >> >> Ah, I haven't gotten to your email from yesterday, since >> I was on vacation and am still catching up. If you can >> send a webrev, and a pointer to a JBS issue, I'll attach >> it for you. If there isn't an existing JBS issue, then >> please file one (and I'll see that it gets moved into the >> JDK project quickly). I also note that tith simple >> javadoc changes, this can be done prior to your OCA being >> recorded if you like. >> >> Thanks. >> >> -- Kevin >> >> >> >> Thanks, >> Nir >> >> >> On Tue, Jan 9, 2018 at 8:50 PM, Kevin Rushforth >> > >> > >> wrote: >> >> Why would you even try to push a changeset >> without getting it >> reviewed first??? >> >> This shows a lack of understanding about our >> processes and >> policies. Only committers have permission to push >> changesets, and >> only after review. Please familiarize yourself >> with the policies >> and procedures surrounding contributing to >> OpenJFX [1] [2] [3] [4] >> [5]. Once you are familiar with these policies >> and have signed the >> Oracle Contributor Agreement (OCA) you can work >> with someone to >> sponsor your change. >> >> -- Kevin >> >> [1] http://openjdk.java.net/contribute/ >> >> > > >> [2] >> http://www.oracle.com/technetwork/community/oca-486395.html >> >> >> > > >> [3] >> >> https://wiki.openjdk.java.net/display/OpenJFX/Submitting+a+Bug+Report >> >> >> > > >> [4] >> https://wiki.openjdk.java.net/display/OpenJFX/Code+Reviews >> >> >> > > >> [5] >> >> https://wiki.openjdk.java.net/display/OpenJFX/Committing+the+Code >> >> >> > > >> >> >> >> Nir Lisker wrote: >> >> Iv'e created a small documentation fix and >> tried to push it to >> http://hg.openjdk.java.net/openjfx/jfx-dev/rt >> >> >> > >. I >> got an error: >> >> abort: push creates new remote head 2152a80ee902! >> hint: pull and merge or see 'hg help push' >> for details about >> pushing new >> heads >> [command returned code 255 Tue Jan 09 >> 19:40:10 2018] >> >> What can be the problem? >> >> >> > From murali.billa at oracle.com Wed Jan 10 18:38:48 2018 From: murali.billa at oracle.com (Murali Billa) Date: Wed, 10 Jan 2018 10:38:48 -0800 (PST) Subject: [11] Review request for 8193368: [OS X] Remove redundant files Message-ID: ? Hi, Please review the below simple fix. JIRA: https://bugs.openjdk.java.net/browse/JDK-8193368 ? Webrev: http://cr.openjdk.java.net/~mbilla/8193368/webrev.00/ ? Thanks, Murali From kevin.rushforth at oracle.com Wed Jan 10 20:04:44 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 10 Jan 2018 12:04:44 -0800 Subject: Result: New OpenJFX Committer: Laurent =?ISO-8859-1?Q?Bourg=E8s?= Message-ID: <5A5671DC.7040900@oracle.com> Voting for Laurent Bourg?s [1] to OpenJFX Committer [2] is now closed. Yes: 8 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. -- Kevin [1] http://openjdk.java.net/census#lbourges [2] http://mail.openjdk.java.net/pipermail/openjfx-dev/2017-December/021116.html From nlisker at gmail.com Wed Jan 10 21:09:29 2018 From: nlisker at gmail.com (Nir Lisker) Date: Wed, 10 Jan 2018 23:09:29 +0200 Subject: Review request: 8194871: Fix mistakes in FX API docs Message-ID: Hi Kevin, Please review the attached webrev. I addressed a few fixes I found as I was working, so they are not listed in the JIRA report. About Transition#getParentTargetNode: The current behavior of parent-child relationship is that an animation can be added to multiple parent transitions. Each parent transition will see that animation as its child, however, the child will see only one of those animations as its parent - the one to which is was added last. This asymmetry is a recipe for trouble (and I argue should be addressed at some point). For this reason, the doc does not specify the "last one wins" behavior, so that no contract is created. This means that it's not clear which parent is going to be queried on each (recursive) invocation. Most of the changes could be backported to 8 and 9. In 9, the methods getRangeShape and getUnderlineShape of TextAreaSkin are also missing documentation. From kevin.rushforth at oracle.com Wed Jan 10 22:12:12 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 10 Jan 2018 14:12:12 -0800 Subject: Review request: 8194871: Fix mistakes in FX API docs In-Reply-To: References: Message-ID: <5A568FBC.4000006@oracle.com> Thank you for providing the patch. I uploaded it to cr.openjdk.java.net for easy browsing: http://cr.openjdk.java.net/~kcr/8194871/webrev.00/ I'll review it, and sponsor the change. Since I will be pushing it, I will need one more reviewer. My quick sanity checking shows trailing whitespace in two files, which would cause jcheck to fail: $ hg jcheck modules/javafx.controls/src/main/java/javafx/scene/control/TableView.java:209: Trailing whitespace modules/javafx.graphics/src/main/java/javafx/animation/Transition.java:161: Trailing whitespace I can fix this before I push. -- Kevin Nir Lisker wrote: > Hi Kevin, > > Please review the attached webrev. > > I addressed a few fixes I found as I was working, so they are not > listed in the JIRA report. > > About Transition#getParentTargetNode: > The current behavior of parent-child relationship is that an animation > can be added to multiple parent transitions. Each parent transition > will see that animation as its child, however, the child will see only > one of those animations as its parent - the one to which is was added > last. This asymmetry is a recipe for trouble (and I argue should be > addressed at some point). > For this reason, the doc does not specify the "last one wins" > behavior, so that no contract is created. This means that it's not > clear which parent is going to be queried on each (recursive) invocation. > > Most of the changes could be backported to 8 and 9. In 9, the methods > getRangeShape and getUnderlineShape of TextAreaSkin are also missing > documentation. From kevin.rushforth at oracle.com Wed Jan 10 22:14:04 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 10 Jan 2018 14:14:04 -0800 Subject: Review request: 8194871: Fix mistakes in FX API docs In-Reply-To: <5A568FBC.4000006@oracle.com> References: <5A568FBC.4000006@oracle.com> Message-ID: <5A56902C.1020200@oracle.com> > I'll review it, and sponsor the change. Since I will be pushing it, I will need one more reviewer. Actually, this is incorrect. As long as I list you as contributor, jcheck is perfectly happy with just me as reviewer. If anyone else wants to review it, too, that would be fine, but not necessary for this type of fix. -- Kevin Kevin Rushforth wrote: > Thank you for providing the patch. I uploaded it to > cr.openjdk.java.net for easy browsing: > > http://cr.openjdk.java.net/~kcr/8194871/webrev.00/ > > I'll review it, and sponsor the change. Since I will be pushing it, I > will need one more reviewer. > > My quick sanity checking shows trailing whitespace in two files, which > would cause jcheck to fail: > > $ hg jcheck > modules/javafx.controls/src/main/java/javafx/scene/control/TableView.java:209: > Trailing whitespace > modules/javafx.graphics/src/main/java/javafx/animation/Transition.java:161: > Trailing whitespace > > I can fix this before I push. > > -- Kevin > > > Nir Lisker wrote: >> Hi Kevin, >> >> Please review the attached webrev. >> >> I addressed a few fixes I found as I was working, so they are not >> listed in the JIRA report. >> >> About Transition#getParentTargetNode: >> The current behavior of parent-child relationship is that an >> animation can be added to multiple parent transitions. Each parent >> transition will see that animation as its child, however, the child >> will see only one of those animations as its parent - the one to >> which is was added last. This asymmetry is a recipe for trouble (and >> I argue should be addressed at some point). >> For this reason, the doc does not specify the "last one wins" >> behavior, so that no contract is created. This means that it's not >> clear which parent is going to be queried on each (recursive) >> invocation. >> >> Most of the changes could be backported to 8 and 9. In 9, the methods >> getRangeShape and getUnderlineShape of TextAreaSkin are also missing >> documentation. From nlisker at gmail.com Wed Jan 10 22:20:45 2018 From: nlisker at gmail.com (Nir Lisker) Date: Thu, 11 Jan 2018 00:20:45 +0200 Subject: Review request: 8194871: Fix mistakes in FX API docs In-Reply-To: <5A56902C.1020200@oracle.com> References: <5A568FBC.4000006@oracle.com> <5A56902C.1020200@oracle.com> Message-ID: Thanks, > modules/javafx.controls/src/main/java/javafx/scene/control/TableView.java:209: > Trailing whitespace That one is an empty line inside a code block, if it matters. On Thu, Jan 11, 2018 at 12:14 AM, Kevin Rushforth < kevin.rushforth at oracle.com> wrote: > > I'll review it, and sponsor the change. Since I will be pushing it, I > will need one more reviewer. > > Actually, this is incorrect. As long as I list you as contributor, jcheck > is perfectly happy with just me as reviewer. > > If anyone else wants to review it, too, that would be fine, but not > necessary for this type of fix. > > -- Kevin > > > > Kevin Rushforth wrote: > > Thank you for providing the patch. I uploaded it to cr.openjdk.java.net > for easy browsing: > > http://cr.openjdk.java.net/~kcr/8194871/webrev.00/ > > I'll review it, and sponsor the change. Since I will be pushing it, I will > need one more reviewer. > > My quick sanity checking shows trailing whitespace in two files, which > would cause jcheck to fail: > > $ hg jcheck > modules/javafx.controls/src/main/java/javafx/scene/control/TableView.java:209: > Trailing whitespace > modules/javafx.graphics/src/main/java/javafx/animation/Transition.java:161: > Trailing whitespace > > I can fix this before I push. > > -- Kevin > > > Nir Lisker wrote: > > Hi Kevin, > > Please review the attached webrev. > > I addressed a few fixes I found as I was working, so they are not listed > in the JIRA report. > > About Transition#getParentTargetNode: > The current behavior of parent-child relationship is that an animation can > be added to multiple parent transitions. Each parent transition will see > that animation as its child, however, the child will see only one of those > animations as its parent - the one to which is was added last. This > asymmetry is a recipe for trouble (and I argue should be addressed at some > point). > For this reason, the doc does not specify the "last one wins" behavior, so > that no contract is created. This means that it's not clear which parent is > going to be queried on each (recursive) invocation. > > Most of the changes could be backported to 8 and 9. In 9, the methods > getRangeShape and getUnderlineShape of TextAreaSkin are also missing > documentation. > > From kevin.rushforth at oracle.com Wed Jan 10 22:23:27 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 10 Jan 2018 14:23:27 -0800 Subject: Review request: 8194871: Fix mistakes in FX API docs In-Reply-To: References: <5A568FBC.4000006@oracle.com> <5A56902C.1020200@oracle.com> Message-ID: <5A56925F.7040101@oracle.com> I just removed the trailing whitespace (using the handy tools/scripts/checkWhiteSpace script with the '-F' option). -- Kevin Nir Lisker wrote: > Thanks, > > > modules/javafx.controls/src/main/java/javafx/scene/control/TableView.java:209: > Trailing whitespace > > > That one is an empty line inside a code block, if it matters. > > On Thu, Jan 11, 2018 at 12:14 AM, Kevin Rushforth > > wrote: > > > I'll review it, and sponsor the change. Since I will be pushing > it, I will need one more reviewer. > > Actually, this is incorrect. As long as I list you as contributor, > jcheck is perfectly happy with just me as reviewer. > > If anyone else wants to review it, too, that would be fine, but > not necessary for this type of fix. > > -- Kevin > > > > Kevin Rushforth wrote: >> Thank you for providing the patch. I uploaded it to >> cr.openjdk.java.net for easy browsing: >> >> http://cr.openjdk.java.net/~kcr/8194871/webrev.00/ >> >> >> I'll review it, and sponsor the change. Since I will be pushing >> it, I will need one more reviewer. >> >> My quick sanity checking shows trailing whitespace in two files, >> which would cause jcheck to fail: >> >> $ hg jcheck >> modules/javafx.controls/src/main/java/javafx/scene/control/TableView.java:209: >> Trailing whitespace >> modules/javafx.graphics/src/main/java/javafx/animation/Transition.java:161: >> Trailing whitespace >> >> I can fix this before I push. >> >> -- Kevin >> >> >> Nir Lisker wrote: >>> Hi Kevin, >>> >>> Please review the attached webrev. >>> >>> I addressed a few fixes I found as I was working, so they are >>> not listed in the JIRA report. >>> >>> About Transition#getParentTargetNode: >>> The current behavior of parent-child relationship is that an >>> animation can be added to multiple parent transitions. Each >>> parent transition will see that animation as its child, however, >>> the child will see only one of those animations as its parent - >>> the one to which is was added last. This asymmetry is a >>> recipe for trouble (and I argue should be addressed at some point). >>> For this reason, the doc does not specify the "last one wins" >>> behavior, so that no contract is created. This means that it's >>> not clear which parent is going to be queried on each >>> (recursive) invocation. >>> >>> Most of the changes could be backported to 8 and 9. In 9, the >>> methods getRangeShape and getUnderlineShape of TextAreaSkin are >>> also missing documentation. > > From kevin.rushforth at oracle.com Wed Jan 10 23:17:22 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 10 Jan 2018 15:17:22 -0800 Subject: Review request: 8194871: Fix mistakes in FX API docs In-Reply-To: <5A56925F.7040101@oracle.com> References: <5A568FBC.4000006@oracle.com> <5A56902C.1020200@oracle.com> <5A56925F.7040101@oracle.com> Message-ID: <5A569F02.3050006@oracle.com> The changes look good to me for the most part. I only have one comment. Node.java: - * The rectangular bounds that should be used for layout ... + * The rectangular (cuboid for 3D nodes) bounds that should be used for layout ... While technically correct, in that the layout bounds of a TriangleMesh or Sphere will be a 3D bounds, layout is a 2D operation, so this seems a bit misleading. If you still feel that a comment is desired, then I would recommend it not being in the opening sentence, but rather a note later in the description...something like: Note that for 3D shapes, the layout bounds is actually a rectangular box with X, Y, and Z values, although only X and Y are used in layout calculations. -- Kevin Kevin Rushforth wrote: > I just removed the trailing whitespace (using the handy > tools/scripts/checkWhiteSpace script with the '-F' option). > > -- Kevin > > > Nir Lisker wrote: >> Thanks, >> >> >> modules/javafx.controls/src/main/java/javafx/scene/control/TableView.java:209: >> Trailing whitespace >> >> >> That one is an empty line inside a code block, if it matters. >> >> On Thu, Jan 11, 2018 at 12:14 AM, Kevin Rushforth >> > wrote: >> >> > I'll review it, and sponsor the change. Since I will be pushing >> it, I will need one more reviewer. >> >> Actually, this is incorrect. As long as I list you as >> contributor, jcheck is perfectly happy with just me as reviewer. >> >> If anyone else wants to review it, too, that would be fine, but >> not necessary for this type of fix. >> >> -- Kevin >> >> >> >> Kevin Rushforth wrote: >>> Thank you for providing the patch. I uploaded it to >>> cr.openjdk.java.net for easy browsing: >>> >>> http://cr.openjdk.java.net/~kcr/8194871/webrev.00/ >>> >>> >>> I'll review it, and sponsor the change. Since I will be pushing >>> it, I will need one more reviewer. >>> >>> My quick sanity checking shows trailing whitespace in two files, >>> which would cause jcheck to fail: >>> >>> $ hg jcheck >>> modules/javafx.controls/src/main/java/javafx/scene/control/TableView.java:209: >>> Trailing whitespace >>> modules/javafx.graphics/src/main/java/javafx/animation/Transition.java:161: >>> Trailing whitespace >>> >>> I can fix this before I push. >>> >>> -- Kevin >>> >>> >>> Nir Lisker wrote: >>>> Hi Kevin, >>>> >>>> Please review the attached webrev. >>>> >>>> I addressed a few fixes I found as I was working, so they are >>>> not listed in the JIRA report. >>>> >>>> About Transition#getParentTargetNode: >>>> The current behavior of parent-child relationship is that an >>>> animation can be added to multiple parent transitions. Each >>>> parent transition will see that animation as its child, >>>> however, the child will see only one of those animations as its >>>> parent - the one to which is was added last. This asymmetry is >>>> a recipe for trouble (and I argue should be addressed at some >>>> point). >>>> For this reason, the doc does not specify the "last one wins" >>>> behavior, so that no contract is created. This means that it's >>>> not clear which parent is going to be queried on each >>>> (recursive) invocation. >>>> >>>> Most of the changes could be backported to 8 and 9. In 9, the >>>> methods getRangeShape and getUnderlineShape of TextAreaSkin are >>>> also missing documentation. >> >> From nlisker at gmail.com Thu Jan 11 00:15:27 2018 From: nlisker at gmail.com (Nir Lisker) Date: Thu, 11 Jan 2018 02:15:27 +0200 Subject: Review request: 8194871: Fix mistakes in FX API docs In-Reply-To: <5A569F02.3050006@oracle.com> References: <5A568FBC.4000006@oracle.com> <5A56902C.1020200@oracle.com> <5A56925F.7040101@oracle.com> <5A569F02.3050006@oracle.com> Message-ID: Yes, I initially had it as a note in the end saying something like this: Note that for nodes in a 3D Scene (or SubScene), layoutBounds is cuboid. but thought that for someone working with 3D, seeing a 2D discussion all the way until the end will be confusing. (Also thought about putting a footnote at the end of the first sentence, but that's not a recommended style as far as I know.) My only slight concern is that "3D shapes" might hint at the Shape3D class, while any node in a 3D environment will have 3D bounds. This is also a technicality, so I wouldn't mind either way. Feel free to make a final verdict. On Thu, Jan 11, 2018 at 1:17 AM, Kevin Rushforth wrote: > The changes look good to me for the most part. I only have one comment. > > Node.java: > > - * The rectangular bounds that should be used for layout ... > + * The rectangular (cuboid for 3D nodes) bounds that should be used > for layout ... > > While technically correct, in that the layout bounds of a TriangleMesh or > Sphere will be a 3D bounds, layout is a 2D operation, so this seems a bit > misleading. If you still feel that a comment is desired, then I would > recommend it not being in the opening sentence, but rather a note later in > the description...something like: > > Note that for 3D shapes, the layout bounds is actually a rectangular > box with X, Y, and Z values, although only X and Y are used in layout > calculations. > > > -- Kevin > > > Kevin Rushforth wrote: > > I just removed the trailing whitespace (using the handy > tools/scripts/checkWhiteSpace script with the '-F' option). > > -- Kevin > > > Nir Lisker wrote: > > Thanks, > > >> modules/javafx.controls/src/main/java/javafx/scene/control/TableView.java:209: >> Trailing whitespace > > > That one is an empty line inside a code block, if it matters. > > On Thu, Jan 11, 2018 at 12:14 AM, Kevin Rushforth < > kevin.rushforth at oracle.com> wrote: > >> > I'll review it, and sponsor the change. Since I will be pushing it, I >> will need one more reviewer. >> >> Actually, this is incorrect. As long as I list you as contributor, jcheck >> is perfectly happy with just me as reviewer. >> >> If anyone else wants to review it, too, that would be fine, but not >> necessary for this type of fix. >> >> -- Kevin >> >> >> >> Kevin Rushforth wrote: >> >> Thank you for providing the patch. I uploaded it to cr.openjdk.java.net >> for easy browsing: >> >> http://cr.openjdk.java.net/~kcr/8194871/webrev.00/ >> >> I'll review it, and sponsor the change. Since I will be pushing it, I >> will need one more reviewer. >> >> My quick sanity checking shows trailing whitespace in two files, which >> would cause jcheck to fail: >> >> $ hg jcheck >> modules/javafx.controls/src/main/java/javafx/scene/control/TableView.java:209: >> Trailing whitespace >> modules/javafx.graphics/src/main/java/javafx/animation/Transition.java:161: >> Trailing whitespace >> >> I can fix this before I push. >> >> -- Kevin >> >> >> Nir Lisker wrote: >> >> Hi Kevin, >> >> Please review the attached webrev. >> >> I addressed a few fixes I found as I was working, so they are not listed >> in the JIRA report. >> >> About Transition#getParentTargetNode: >> The current behavior of parent-child relationship is that an animation >> can be added to multiple parent transitions. Each parent transition will >> see that animation as its child, however, the child will see only one of >> those animations as its parent - the one to which is was added last. This >> asymmetry is a recipe for trouble (and I argue should be addressed at some >> point). >> For this reason, the doc does not specify the "last one wins" behavior, >> so that no contract is created. This means that it's not clear which parent >> is going to be queried on each (recursive) invocation. >> >> Most of the changes could be backported to 8 and 9. In 9, the methods >> getRangeShape and getUnderlineShape of TextAreaSkin are also missing >> documentation. >> >> > From kevin.rushforth at oracle.com Thu Jan 11 00:27:53 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 10 Jan 2018 16:27:53 -0800 Subject: Review request: 8194871: Fix mistakes in FX API docs In-Reply-To: References: <5A568FBC.4000006@oracle.com> <5A56902C.1020200@oracle.com> <5A56925F.7040101@oracle.com> <5A569F02.3050006@oracle.com> Message-ID: <5A56AF89.7050108@oracle.com> Since we are talking about the layout bounds of a node, I would avoid using the term '3D scene' (or subscene) since in this case it is the node that has the characteristic of 3D (geometry or transforms) associated with it. Anyway, let's go with the note at the end somewhere. Since layout is a 2D concept, I think it's fine if 3D users don't see anything about 3D until later. Do you want to send a delta patch for that? Or you can send an entire updated webrev. Whichever you prefer. -- Kevin Nir Lisker wrote: > Yes, I initially had it as a note in the end saying something like this: > > Note that for nodes in a 3D Scene (or SubScene), layoutBounds is > cuboid. > > but thought that for someone working with 3D, seeing a 2D discussion > all the way until the end will be confusing. (Also thought about > putting a footnote at the end of the first sentence, but that's not a > recommended style as far as I know.) > My only slight concern is that "3D shapes" might hint at the Shape3D > class, while any node in a 3D environment will have 3D bounds. This is > also a technicality, so I wouldn't mind either way. Feel free to make > a final verdict. > > On Thu, Jan 11, 2018 at 1:17 AM, Kevin Rushforth > > wrote: > > The changes look good to me for the most part. I only have one > comment. > > Node.java: > > - * The rectangular bounds that should be used for layout ... > + * The rectangular (cuboid for 3D nodes) bounds that should > be used for layout ... > > While technically correct, in that the layout bounds of a > TriangleMesh or Sphere will be a 3D bounds, layout is a 2D > operation, so this seems a bit misleading. If you still feel that > a comment is desired, then I would recommend it not being in the > opening sentence, but rather a note later in the > description...something like: > > Note that for 3D shapes, the layout bounds is actually a > rectangular box with X, Y, and Z values, although only X and Y are > used in layout calculations. > > > -- Kevin > > > Kevin Rushforth wrote: >> I just removed the trailing whitespace (using the handy >> tools/scripts/checkWhiteSpace script with the '-F' option). >> >> -- Kevin >> >> >> Nir Lisker wrote: >>> Thanks, >>> >>> >>> modules/javafx.controls/src/main/java/javafx/scene/control/TableView.java:209: >>> Trailing whitespace >>> >>> >>> That one is an empty line inside a code block, if it matters. >>> >>> On Thu, Jan 11, 2018 at 12:14 AM, Kevin Rushforth >>> > >>> wrote: >>> >>> > I'll review it, and sponsor the change. Since I will be >>> pushing it, I will need one more reviewer. >>> >>> Actually, this is incorrect. As long as I list you as >>> contributor, jcheck is perfectly happy with just me as reviewer. >>> >>> If anyone else wants to review it, too, that would be fine, >>> but not necessary for this type of fix. >>> >>> -- Kevin >>> >>> >>> >>> Kevin Rushforth wrote: >>>> Thank you for providing the patch. I uploaded it to >>>> cr.openjdk.java.net for easy >>>> browsing: >>>> >>>> http://cr.openjdk.java.net/~kcr/8194871/webrev.00/ >>>> >>>> >>>> I'll review it, and sponsor the change. Since I will be >>>> pushing it, I will need one more reviewer. >>>> >>>> My quick sanity checking shows trailing whitespace in two >>>> files, which would cause jcheck to fail: >>>> >>>> $ hg jcheck >>>> modules/javafx.controls/src/main/java/javafx/scene/control/TableView.java:209: >>>> Trailing whitespace >>>> modules/javafx.graphics/src/main/java/javafx/animation/Transition.java:161: >>>> Trailing whitespace >>>> >>>> I can fix this before I push. >>>> >>>> -- Kevin >>>> >>>> >>>> Nir Lisker wrote: >>>>> Hi Kevin, >>>>> >>>>> Please review the attached webrev. >>>>> >>>>> I addressed a few fixes I found as I was working, so they >>>>> are not listed in the JIRA report. >>>>> >>>>> About Transition#getParentTargetNode: >>>>> The current behavior of parent-child relationship is that >>>>> an animation can be added to multiple parent transitions. >>>>> Each parent transition will see that animation as its >>>>> child, however, the child will see only one of those >>>>> animations as its parent - the one to which is was added >>>>> last. This asymmetry is a recipe for trouble (and I argue >>>>> should be addressed at some point). >>>>> For this reason, the doc does not specify the "last one >>>>> wins" behavior, so that no contract is created. This means >>>>> that it's not clear which parent is going to be queried on >>>>> each (recursive) invocation. >>>>> >>>>> Most of the changes could be backported to 8 and 9. In 9, >>>>> the methods getRangeShape and getUnderlineShape of >>>>> TextAreaSkin are also missing documentation. >>> >>> > From kevin.rushforth at oracle.com Thu Jan 11 00:59:24 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 10 Jan 2018 16:59:24 -0800 Subject: Review request: 8194871: Fix mistakes in FX API docs In-Reply-To: References: <5A568FBC.4000006@oracle.com> <5A56902C.1020200@oracle.com> <5A56925F.7040101@oracle.com> <5A569F02.3050006@oracle.com> <5A56AF89.7050108@oracle.com> Message-ID: <5A56B6EC.2060208@oracle.com> Uploaded here: http://cr.openjdk.java.net/~kcr/8194871/webrev.01/ This looks good. +1 I'll push it tomorrow. -- Kevin Nir Lisker wrote: > Attached a new webrev. > > On Thu, Jan 11, 2018 at 2:27 AM, Kevin Rushforth > > wrote: > > Since we are talking about the layout bounds of a node, I would > avoid using the term '3D scene' (or subscene) since in this case > it is the node that has the characteristic of 3D (geometry or > transforms) associated with it. > > Anyway, let's go with the note at the end somewhere. Since layout > is a 2D concept, I think it's fine if 3D users don't see anything > about 3D until later. > > Do you want to send a delta patch for that? Or you can send an > entire updated webrev. Whichever you prefer. > > > -- Kevin > > > Nir Lisker wrote: >> Yes, I initially had it as a note in the end saying something >> like this: >> >> Note that for nodes in a 3D Scene (or SubScene), >> layoutBounds is cuboid. >> >> but thought that for someone working with 3D, seeing a 2D >> discussion all the way until the end will be confusing. (Also >> thought about putting a footnote at the end of the first >> sentence, but that's not a recommended style as far as I know.) >> My only slight concern is that "3D shapes" might hint at the >> Shape3D class, while any node in a 3D environment will have 3D >> bounds. This is also a technicality, so I wouldn't mind either >> way. Feel free to make a final verdict. >> >> On Thu, Jan 11, 2018 at 1:17 AM, Kevin Rushforth >> > >> wrote: >> >> The changes look good to me for the most part. I only have >> one comment. >> >> Node.java: >> >> - * The rectangular bounds that should be used for layout ... >> + * The rectangular (cuboid for 3D nodes) bounds that >> should be used for layout ... >> >> While technically correct, in that the layout bounds of a >> TriangleMesh or Sphere will be a 3D bounds, layout is a 2D >> operation, so this seems a bit misleading. If you still feel >> that a comment is desired, then I would recommend it not >> being in the opening sentence, but rather a note later in the >> description...something like: >> >> Note that for 3D shapes, the layout bounds is actually a >> rectangular box with X, Y, and Z values, although only X and >> Y are used in layout calculations. >> >> >> -- Kevin >> >> >> Kevin Rushforth wrote: >>> I just removed the trailing whitespace (using the handy >>> tools/scripts/checkWhiteSpace script with the '-F' option). >>> >>> -- Kevin >>> >>> >>> Nir Lisker wrote: >>>> Thanks, >>>> >>>> >>>> modules/javafx.controls/src/main/java/javafx/scene/control/TableView.java:209: >>>> Trailing whitespace >>>> >>>> >>>> That one is an empty line inside a code block, if it matters. >>>> >>>> On Thu, Jan 11, 2018 at 12:14 AM, Kevin Rushforth >>>> >>> > wrote: >>>> >>>> > I'll review it, and sponsor the change. Since I will >>>> be pushing it, I will need one more reviewer. >>>> >>>> Actually, this is incorrect. As long as I list you as >>>> contributor, jcheck is perfectly happy with just me as >>>> reviewer. >>>> >>>> If anyone else wants to review it, too, that would be >>>> fine, but not necessary for this type of fix. >>>> >>>> -- Kevin >>>> >>>> >>>> >>>> Kevin Rushforth wrote: >>>>> Thank you for providing the patch. I uploaded it to >>>>> cr.openjdk.java.net for >>>>> easy browsing: >>>>> >>>>> http://cr.openjdk.java.net/~kcr/8194871/webrev.00/ >>>>> >>>>> >>>>> I'll review it, and sponsor the change. Since I will >>>>> be pushing it, I will need one more reviewer. >>>>> >>>>> My quick sanity checking shows trailing whitespace in >>>>> two files, which would cause jcheck to fail: >>>>> >>>>> $ hg jcheck >>>>> modules/javafx.controls/src/main/java/javafx/scene/control/TableView.java:209: >>>>> Trailing whitespace >>>>> modules/javafx.graphics/src/main/java/javafx/animation/Transition.java:161: >>>>> Trailing whitespace >>>>> >>>>> I can fix this before I push. >>>>> >>>>> -- Kevin >>>>> >>>>> >>>>> Nir Lisker wrote: >>>>>> Hi Kevin, >>>>>> >>>>>> Please review the attached webrev. >>>>>> >>>>>> I addressed a few fixes I found as I was working, so >>>>>> they are not listed in the JIRA report. >>>>>> >>>>>> About Transition#getParentTargetNode: >>>>>> The current behavior of parent-child relationship is >>>>>> that an animation can be added to multiple parent >>>>>> transitions. Each parent transition will see that >>>>>> animation as its child, however, the child will see >>>>>> only one of those animations as its parent - the one >>>>>> to which is was added last. This asymmetry is a >>>>>> recipe for trouble (and I argue should be addressed >>>>>> at some point). >>>>>> For this reason, the doc does not specify the "last >>>>>> one wins" behavior, so that no contract is created. >>>>>> This means that it's not clear which parent is going >>>>>> to be queried on each (recursive) invocation. >>>>>> >>>>>> Most of the changes could be backported to 8 and 9. >>>>>> In 9, the methods getRangeShape and getUnderlineShape >>>>>> of TextAreaSkin are also missing documentation. >>>> >>>> >> > From kevin.rushforth at oracle.com Thu Jan 11 22:43:15 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 11 Jan 2018 14:43:15 -0800 Subject: [10, 11] Review request: 8193910: Version number in cssref.html and introduction_to_fxml.html is wrong Message-ID: <5A57E883.2040303@oracle.com> Hi Phil, Please review the following simple fix to the FX version number in our two standalone html doc pages: JBS: https://bugs.openjdk.java.net/browse/JDK-8193910 Webrev for 11: http://cr.openjdk.java.net/~kcr/8193910/webrev/ Webrev for 10: http://cr.openjdk.java.net/~kcr/8193910/10/webrev/ Thanks. -- Kevin From dipak.kumar at oracle.com Fri Jan 12 10:12:07 2018 From: dipak.kumar at oracle.com (Dipak Kumar) Date: Fri, 12 Jan 2018 02:12:07 -0800 (PST) Subject: [8u-Backport] Review request for 8185634 : Java Fx-Swing dialogs appearing behind main stage Message-ID: <11b1475d-0855-469a-90fd-6a6d93d14c91@default> Hi All, Please review the below patch (for 8u-backport) - Webrev : http://cr.openjdk.java.net/~dkumar/8185634/webrev.00/ JBS - https://bugs.openjdk.java.net/browse/JDK-8185634 Thanks, Dipak From kevin.rushforth at oracle.com Fri Jan 12 18:07:49 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 12 Jan 2018 10:07:49 -0800 Subject: [10] Review request: 8195003: javadoc html files must not use '@' as first character of a line Message-ID: <5A58F975.2070508@oracle.com> Please review the following simple doc fix: https://bugs.openjdk.java.net/browse/JDK-8195003 http://cr.openjdk.java.net/~kcr/8195003/webrev.00/ See the bug report for details. -- Kevin From jonathan.gibbons at oracle.com Fri Jan 12 18:09:43 2018 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 12 Jan 2018 10:09:43 -0800 Subject: [10] Review request: 8195003: javadoc html files must not use '@' as first character of a line In-Reply-To: <5A58F975.2070508@oracle.com> References: <5A58F975.2070508@oracle.com> Message-ID: Looks OK to me. -- Jon On 1/12/18 10:07 AM, Kevin Rushforth wrote: > Please review the following simple doc fix: > > https://bugs.openjdk.java.net/browse/JDK-8195003 > http://cr.openjdk.java.net/~kcr/8195003/webrev.00/ > > See the bug report for details. > > -- Kevin > From alexander.matveev at oracle.com Sat Jan 13 01:00:58 2018 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Fri, 12 Jan 2018 17:00:58 -0800 Subject: [11] Review request for 8088722: GSTPlatform cannot play MP4 files with multiple audio tracks Message-ID: <09562798-b595-d44d-0015-a598fcacd7d9@oracle.com> Hi Kevin, Please review the following: https://bugs.openjdk.java.net/browse/JDK-8088722 Instead of failing to load MP4 files with multiple audio tracks we will play it with first audio track found by MP4 demux. Thanks, Alexander From ambarish.rapte at oracle.com Sat Jan 13 08:36:59 2018 From: ambarish.rapte at oracle.com (Ambarish Rapte) Date: Sat, 13 Jan 2018 00:36:59 -0800 (PST) Subject: RFR : JDK-8193495 : TabPane does not update correctly tab positions in the header area after a quick remove and add operations Message-ID: Hi Kevin & Ajit, Please review this fix: Webrev: http://cr.openjdk.java.net/~arapte/fx/8193495/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8193495 This patch also fixes an another bug: https://bugs.openjdk.java.net/browse/JDK-8139967 Regards, Ambarish From prem.balakrishnan at oracle.com Mon Jan 15 08:45:46 2018 From: prem.balakrishnan at oracle.com (Prem Balakrishnan) Date: Mon, 15 Jan 2018 00:45:46 -0800 (PST) Subject: [11] Review Request: JDK-8167096 RFE: change the default INITIAL_DURATION_MS to match the behavior of JSpinner Message-ID: Hi Kevin, Ajit Request you to review following fix: Bug: https://bugs.openjdk.java.net/browse/JDK-8167096 Webrev: http://cr.openjdk.java.net/~pkbalakr/fx/8167096/webrev00/ Regards, Prem From nlisker at gmail.com Mon Jan 15 12:52:39 2018 From: nlisker at gmail.com (Nir Lisker) Date: Mon, 15 Jan 2018 14:52:39 +0200 Subject: fx 1.x issues in JBS Message-ID: Hello, JBS still has open issues for JavaFX 1 versions and they appear in searches even though there's nothing to do about them since that version is not supported anymore. Is it appropriate to close them all? There are also a lot in Resolved. - Nir From kevin.rushforth at oracle.com Mon Jan 15 15:29:37 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 15 Jan 2018 07:29:37 -0800 Subject: fx 1.x issues in JBS In-Reply-To: References: Message-ID: <5A5CC8E1.1060200@oracle.com> While I suspect many of them can be closed out at this point, it is not necessarily a given that they are irrelevant (the scene graph, animation, and graphics engine evolved from 1.x to 2.0). I agree that it would be good to take a pass over them and close out the ones that are no longer issues, but I they can't simply be closed out as a bulk close operation without looking at them. Also, you say "a lot in resolved" my response would be that I hope so. An issue that is resolved needs no more action and won't show up in searches for open bugs. So I guess I'm not sure what you mean by this. -- Kevin Nir Lisker wrote: > Hello, > > JBS still has open issues for JavaFX 1 versions and they appear in searches > even though there's nothing to do about them since that version is not > supported anymore. Is it appropriate to close them all? There are also a > lot in Resolved. > > - Nir > From kevin.rushforth at oracle.com Mon Jan 15 15:41:50 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 15 Jan 2018 07:41:50 -0800 Subject: [11] Review Request: JDK-8167096 RFE: change the default INITIAL_DURATION_MS to match the behavior of JSpinner In-Reply-To: References: Message-ID: <5A5CCBBE.7080505@oracle.com> Hi Prem, Since this adds new API, this needs a CSR. In general it is best to get any proposed API additions reviewed on this alias before spending much time on it. In this case, the newly proposed API is a simple property, and is the obvious solution, so the API itself looks fine. Can you please file the CSR? The code review can proceed in parallel with the CSR review. -- Kevin Prem Balakrishnan wrote: > > Hi Kevin, Ajit > > > > Request you to review following fix: > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8167096 > > > > Webrev: http://cr.openjdk.java.net/~pkbalakr/fx/8167096/webrev00/ > > > > > Regards, > > Prem > > > From dell.green at ideaworks.co.uk Mon Jan 15 15:56:42 2018 From: dell.green at ideaworks.co.uk (Dell Green) Date: Mon, 15 Jan 2018 15:56:42 +0000 Subject: Cross Compilling linux Arm OpenJdk9 javaFx References: <24180680-1b5b-4065-b8db-2ec749c8c04a.363286e8-7dac-4d57-b8bb-2c44600bf646.9a4a3b58-027a-41fa-ad45-3cbbb47f5182@emailsignatures365.codetwo.com> <24180680-1b5b-4065-b8db-2ec749c8c04a.78521923-80c4-4635-a03d-377c49a1f6af.ca4d5110-1b5a-47b3-8467-ccd901c0af40@emailsignatures365.codetwo.com> <24180680-1b5b-4065-b8db-2ec749c8c04a.20351617-59b7-420a-a052-8fdceacec718.f71e0189-2c9e-4027-bcc2-607200a4c55c@emailsignatures365.codetwo.com> Message-ID: <18d3efd1-1cae-62f3-c840-621ee746a457@ideaworks.co.uk> Currently use Arm java8 from Oracle and compile Openjfx for Arm and overlay libraries for current product line. Looking to test Java9 on Arm and upgrade product line in next generation release. Cross Compiling openJdk9 for Arm works fine Trying to compile openJfx from http://hg.openjdk.java.net/openjfx/jfx-dev/rt Running gradle -PCOMPILE_TARGETS=armv6hf produces swing errors even though COMPILE_SWING is false in build.gradle. home/dell/Documents/IwOpenJdk9/src/openjfx/rt/modules/javafx.swing/src/main/java/module-info.java:36: error: file should be on source path, or on patch path for module module javafx.swing { /home/dell/Documents/IwOpenJdk9/src/openjfx/rt/modules/javafx.swing/src/main/java/com/sun/javafx/embed/swing/SwingNodeHelper.java:26: error: file should be on source path, or on patch path for module package com.sun.javafx.embed.swing;.... Problem seems to be with build.gradle line 2154 which has swing tasks being disabled if COMPILE_SWING is false. However this code is commented out. /* should not be built, but needed in JMX tasks.all { if (!COMPILE_SWING) it.enabled = false } */ if I uncomment it these errors go away and the build completes. The resulting armv6hf-modular-sdk folder created by the build is added to jdk configure script with '-with-import-modules=' option as per build instructions. Building the jdk now fails with java.base module FindException, are these 2 problems related? Note: Recompile with -Xlint:unchecked for details. Error: Module javafx.base not found java.lang.module.FindException: Module javafx.base not found at java.base/java.lang.module.Resolver.findFail(Resolver.java:889) at java.base/java.lang.module.Resolver.resolve(Resolver.java:128) at java.base/java.lang.module.Configuration.resolve(Configuration.java:357) at java.base/java.lang.module.Configuration.resolve(Configuration.java:187) at jdk.jlink/jdk.tools.jlink.internal.Jlink$JlinkConfiguration.resolve(Jlink.java:242) at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.createImageProvider(JlinkTask.java:439) at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.createImage(JlinkTask.java:386) at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.run(JlinkTask.java:263) at jdk.jlink/jdk.tools.jlink.internal.Main.run(Main.java:54) at jdk.jlink/jdk.tools.jlink.internal.Main.main(Main.java:33) make3: *** [/home/dell/Documents/IwOpenJdk9/src/jdk9dev/build/linux-arm-normal-client-release/images/jre/bin/java] Error 1 Images.gmk:144: recipe for target '/home/dell/Documents/IwOpenJdk9/src/jdk9dev/build/linux-arm-normal-client-release/images/jre/bin/java' failed Dell Green Software Manager t: (+44) 203 668 9870 ideaworks.co.uk [cid:LogoEmailFootter_0829c9d5-b4ed-4548-99f2-5c300468734d.jpg] 206 Great Portland Street London W1W 5QJ [cid:bestcompanies2018_abc1b1a4-ffcc-4151-8af8-10f73f8862f6.png] This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you are not the intended recipient or the person responsible for delivering the email to the intended recipient, be advised that you have received this email in error and that any use, dissemination, forwarding, printing, or copying of this email is strictly prohibited. Any views or opinions presented are solely those of the author and do not necessarily represent those of Ideaworks Limited. Ideaworks (London) Limited, 206 Great Portland Street, London, W1W 5QJ. Company Registration No. 3943726 From nlisker at gmail.com Mon Jan 15 22:22:24 2018 From: nlisker at gmail.com (Nir Lisker) Date: Tue, 16 Jan 2018 00:22:24 +0200 Subject: fx 1.x issues in JBS In-Reply-To: <5A5CC8E1.1060200@oracle.com> References: <5A5CC8E1.1060200@oracle.com> Message-ID: I see, was not aware that there are enough similarities between 1.x and later versions. About Resolved issues, I thought that they are waiting for a fix confirmation to be Closed. On Mon, Jan 15, 2018 at 5:29 PM, Kevin Rushforth wrote: > While I suspect many of them can be closed out at this point, it is not > necessarily a given that they are irrelevant (the scene graph, animation, > and graphics engine evolved from 1.x to 2.0). I agree that it would be good > to take a pass over them and close out the ones that are no longer issues, > but I they can't simply be closed out as a bulk close operation without > looking at them. > > Also, you say "a lot in resolved" my response would be that I hope so. An > issue that is resolved needs no more action and won't show up in searches > for open bugs. So I guess I'm not sure what you mean by this. > > -- Kevin > > > > Nir Lisker wrote: > >> Hello, >> >> JBS still has open issues for JavaFX 1 versions and they appear in >> searches >> even though there's nothing to do about them since that version is not >> supported anymore. Is it appropriate to close them all? There are also a >> lot in Resolved. >> >> - Nir >> >> > From kevin.rushforth at oracle.com Tue Jan 16 01:00:53 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 15 Jan 2018 17:00:53 -0800 Subject: fx 1.x issues in JBS In-Reply-To: References: <5A5CC8E1.1060200@oracle.com> Message-ID: <5A5D4EC5.3020004@oracle.com> For practical purposes you can treat resolved and closed as the same. Resolved/fixed versus Closed/fixed does indeed mean what you think, but the majority of bugs are never verified, so that difference is really only of interest to the testing organization. I always treat them as the same in all filters (thus use "resoltuion is EMPTY" to look for open bugs, resolution = "Fixed" to looked for fixed bugs, etc., and don't query on the status for Resolved or Closed). -- Kevin Nir Lisker wrote: > I see, was not aware that there are enough similarities between 1.x > and later versions. About Resolved issues, I thought that they are > waiting for a fix confirmation to be Closed. > > On Mon, Jan 15, 2018 at 5:29 PM, Kevin Rushforth > > wrote: > > While I suspect many of them can be closed out at this point, it > is not necessarily a given that they are irrelevant (the scene > graph, animation, and graphics engine evolved from 1.x to 2.0). I > agree that it would be good to take a pass over them and close out > the ones that are no longer issues, but I they can't simply be > closed out as a bulk close operation without looking at them. > > Also, you say "a lot in resolved" my response would be that I hope > so. An issue that is resolved needs no more action and won't show > up in searches for open bugs. So I guess I'm not sure what you > mean by this. > > -- Kevin > > > > Nir Lisker wrote: > > Hello, > > JBS still has open issues for JavaFX 1 versions and they > appear in searches > even though there's nothing to do about them since that > version is not > supported anymore. Is it appropriate to close them all? There > are also a > lot in Resolved. > > - Nir > > > From rajath.kamath at oracle.com Tue Jan 16 09:36:38 2018 From: rajath.kamath at oracle.com (Rajath Kamath) Date: Tue, 16 Jan 2018 01:36:38 -0800 (PST) Subject: [11] Review Request - JDK-8165459: HTMLEditor clipboard toolbar buttons are disabled unexpectedly Message-ID: <61700936-13ca-41c7-986b-2149b0833362@default> Hi Guru\Murali, Please review a fix for HTMLEditor. Details of the fix in JBS: JBS : https://bugs.openjdk.java.net/browse/JDK-8165459 WebRev : http://cr.openjdk.java.net/~rkamath/8165459/webrev.00/ Thanks, Rajath From kevin.rushforth at oracle.com Tue Jan 16 18:57:18 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 16 Jan 2018 10:57:18 -0800 Subject: Changes for January 2018 CPU release (8u162, 9.0.4) synced into FX 8u-dev, 9u-dev, 10-dev, jfx-dev Message-ID: <5A5E4B0E.5090307@oracle.com> FYI, I have synced the OpenJFX changes from the just-released January 2018 CPU/PSU release (8u162, 9.0.4) into 8u-dev, 9u-dev, 10-dev, and jfx-dev. -- Kevin From philip.race at oracle.com Wed Jan 17 21:45:35 2018 From: philip.race at oracle.com (Phil Race) Date: Wed, 17 Jan 2018 13:45:35 -0800 Subject: [8u-Backport] Review request for 8185634 : Java Fx-Swing dialogs appearing behind main stage In-Reply-To: <11b1475d-0855-469a-90fd-6a6d93d14c91@default> References: <11b1475d-0855-469a-90fd-6a6d93d14c91@default> Message-ID: <74e85c96-5395-b382-9c98-05389c00f4d2@oracle.com> The AWT/Swing side of this needs to be bug https://bugs.openjdk.java.net/browse/JDK-8185634 One thing I notice is that in XWindowPeer.java the calculation for the value of transientForWindow is different .. because you don't have the fix for https://bugs.openjdk.java.net/browse/JDK-8021961 : "setAlwaysOnTop doesn't behave correctly in Linux/Solaris under certain scenarios" Do you first need to backport that too ? Maybe Semyon (who authored that fix) can say whether it matters .. -phil. On 01/12/2018 02:12 AM, Dipak Kumar wrote: > Hi All, > > > > Please review the below patch (for 8u-backport) - > > > > Webrev : http://cr.openjdk.java.net/~dkumar/8185634/webrev.00/ > > JBS - https://bugs.openjdk.java.net/browse/JDK-8185634 > > > > Thanks, > > Dipak From kevin.rushforth at oracle.com Wed Jan 17 21:43:11 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 17 Jan 2018 13:43:11 -0800 Subject: [8u-Backport] Review request for 8185634, 8187803 : Java Fx-Swing dialogs appearing behind main stage In-Reply-To: <11b1475d-0855-469a-90fd-6a6d93d14c91@default> References: <11b1475d-0855-469a-90fd-6a6d93d14c91@default> Message-ID: <5A5FC36F.6050301@oracle.com> Hi Dipak, To underscore the fact that the AWT part of the change has to be pushed under a separate bug ID I have modified the subject line. The FX half of the implementation changes look fine. I tested it on Linux and it works as expected. There are two problems with the unit tests: 1. The package name used in each of the three test files doesn't match the location in the directory tree. [This one must be fixed] 2. When used with the default boot JDK of 8u40, the unit tests will fail. This may not be a problem we care about, since they are robot tests and won't get run without explicitly enabling robot tests. [Feel free to ignore this point] As for the AWT half of the changes, you will need to get two (?) AWT Reviewers to approve, and then also get permission to backport this to jdk8u by sending email to jdk8u-dev requesting such permission. -- Kevin Dipak Kumar wrote: > > Hi All, > > > > Please review the below patch (for 8u-backport) -- > > > > Webrev : http://cr.openjdk.java.net/~dkumar/8185634/webrev.00/ > > > JBS - https://bugs.openjdk.java.net/browse/JDK-8185634 > > > > Thanks, > > Dipak > From kevin.rushforth at oracle.com Wed Jan 17 21:50:50 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 17 Jan 2018 13:50:50 -0800 Subject: [8u-Backport] Review request for 8185634, 8187803 : Java Fx-Swing dialogs appearing behind main stage In-Reply-To: <74e85c96-5395-b382-9c98-05389c00f4d2@oracle.com> References: <11b1475d-0855-469a-90fd-6a6d93d14c91@default> <74e85c96-5395-b382-9c98-05389c00f4d2@oracle.com> Message-ID: <5A5FC53A.7080803@oracle.com> I think you mean https://bugs.openjdk.java.net/browse/JDK-8187803 for the AWT/Swing side... -- Kevin Phil Race wrote: > The AWT/Swing side of this needs to be bug > https://bugs.openjdk.java.net/browse/JDK-8185634 > > One thing I notice is that in XWindowPeer.java the calculation for the > value of transientForWindow > is different .. because you don't have the fix for > https://bugs.openjdk.java.net/browse/JDK-8021961 : > "setAlwaysOnTop doesn't behave correctly in Linux/Solaris under > certain scenarios" > > Do you first need to backport that too ? Maybe Semyon (who authored > that fix) can say whether > it matters .. > > -phil. > > On 01/12/2018 02:12 AM, Dipak Kumar wrote: >> Hi All, >> >> >> Please review the below patch (for 8u-backport) - >> >> >> Webrev : http://cr.openjdk.java.net/~dkumar/8185634/webrev.00/ >> >> JBS - https://bugs.openjdk.java.net/browse/JDK-8185634 >> >> >> Thanks, >> >> Dipak > From alexey.semenyuk at oracle.com Wed Jan 17 22:01:53 2018 From: alexey.semenyuk at oracle.com (Alexey Semenyuk) Date: Wed, 17 Jan 2018 17:01:53 -0500 Subject: [10] Review request: 8195075: Old app window is not reactivatable Message-ID: <5ff7041c-d6c3-e682-8854-39d08871f2ad@oracle.com> Victor, Please review my changes for fixing the issue: "JDK-8195075: Old app window is not reactivatable" JIRA: https://bugs.openjdk.java.net/browse/JDK-8195075 Webrev: http://cr.openjdk.java.net/~asemenyuk/8195075/webrev.00/ - Alexey From kevin.rushforth at oracle.com Wed Jan 17 23:30:00 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 17 Jan 2018 15:30:00 -0800 Subject: [10] Review request: 8195075: Old app window is not reactivatable In-Reply-To: <5ff7041c-d6c3-e682-8854-39d08871f2ad@oracle.com> References: <5ff7041c-d6c3-e682-8854-39d08871f2ad@oracle.com> Message-ID: <5A5FDC78.8050007@oracle.com> I see that this bug was (correctly) targeted for 11 and not for 10. I guess the subject line is wrong? -- Kevin Alexey Semenyuk wrote: > Victor, > > Please review my changes for fixing the issue: "JDK-8195075: Old app > window is not reactivatable" > > JIRA: https://bugs.openjdk.java.net/browse/JDK-8195075 > Webrev: http://cr.openjdk.java.net/~asemenyuk/8195075/webrev.00/ > > - Alexey > From alexey.semenyuk at oracle.com Thu Jan 18 01:48:58 2018 From: alexey.semenyuk at oracle.com (Alexey Semenyuk) Date: Wed, 17 Jan 2018 20:48:58 -0500 Subject: [10] Review request: 8195075: Old app window is not reactivatable In-Reply-To: <5A5FDC78.8050007@oracle.com> References: <5ff7041c-d6c3-e682-8854-39d08871f2ad@oracle.com> <5A5FDC78.8050007@oracle.com> Message-ID: <4dd20295-58a8-c1be-532d-4407b811be11@oracle.com> Hi Kevin, My bad, I didn't look carefully at "Fix Version" in the JIRA record. Yes, the subject of the email is misleading. Should I resend it with the proper subject? - Alexey On 1/17/2018 6:30 PM, Kevin Rushforth wrote: > I see that this bug was (correctly) targeted for 11 and not for 10. I > guess the subject line is wrong? > > -- Kevin > > > Alexey Semenyuk wrote: >> Victor, >> >> Please review my changes for fixing the issue: "JDK-8195075: Old app >> window is not reactivatable" >> >> JIRA: https://bugs.openjdk.java.net/browse/JDK-8195075 >> Webrev: http://cr.openjdk.java.net/~asemenyuk/8195075/webrev.00/ >> >> - Alexey >> From dipak.kumar at oracle.com Thu Jan 18 05:48:11 2018 From: dipak.kumar at oracle.com (Dipak Kumar) Date: Wed, 17 Jan 2018 21:48:11 -0800 (PST) Subject: [8u-Backport] Review request for 8185634, 8187803 : Java Fx-Swing dialogs appearing behind main stage In-Reply-To: <5A5FC53A.7080803@oracle.com> References: <11b1475d-0855-469a-90fd-6a6d93d14c91@default> <74e85c96-5395-b382-9c98-05389c00f4d2@oracle.com> <5A5FC53A.7080803@oracle.com> Message-ID: <62fcf392-d5dc-40e3-8e59-715f208c05a3@default> Hi Semyon, Could you please review the changes (also have a look at Phil's comment in trailing mail) and let me know your comments. Thanks Kevin and Phil. I have incorporated the changes suggested for unit tests in JavaFx side. Request you to have a look. Please find updated webrev at - http://cr.openjdk.java.net/~dkumar/8185634/webrev.01/ . Thanks, Dipak -----Original Message----- From: Kevin Rushforth Sent: Thursday, January 18, 2018 3:21 AM To: Phil Race Cc: Dipak Kumar ; openjfx-dev at openjdk.java.net; awt-dev at openjdk.java.net Subject: Re: [8u-Backport] Review request for 8185634, 8187803 : Java Fx-Swing dialogs appearing behind main stage I think you mean https://bugs.openjdk.java.net/browse/JDK-8187803 for the AWT/Swing side... -- Kevin Phil Race wrote: > The AWT/Swing side of this needs to be bug > https://bugs.openjdk.java.net/browse/JDK-8185634 > > One thing I notice is that in XWindowPeer.java the calculation for the > value of transientForWindow is different .. because you don't have the > fix for > https://bugs.openjdk.java.net/browse/JDK-8021961 : > "setAlwaysOnTop doesn't behave correctly in Linux/Solaris under > certain scenarios" > > Do you first need to backport that too ? Maybe Semyon (who authored > that fix) can say whether it matters .. > > -phil. > > On 01/12/2018 02:12 AM, Dipak Kumar wrote: >> Hi All, >> >> >> Please review the below patch (for 8u-backport) - >> >> >> Webrev : http://cr.openjdk.java.net/~dkumar/8185634/webrev.00/ >> >> JBS - https://bugs.openjdk.java.net/browse/JDK-8185634 >> >> >> Thanks, >> >> Dipak > From ajit.ghaisas at oracle.com Thu Jan 18 08:25:22 2018 From: ajit.ghaisas at oracle.com (Ajit Ghaisas) Date: Thu, 18 Jan 2018 00:25:22 -0800 (PST) Subject: [11] Review request : JDK-8194913 : Focus traversal is broken if a Pane is added to a ToolBar Message-ID: <2cf70afb-ee22-47ca-a583-7194f4c07e34@default> Hi, Request you to review following fix : Issue : https://bugs.openjdk.java.net/browse/JDK-8194913 Fix : http://cr.openjdk.java.net/~aghaisas/fx/8194913/webrev.0/ Regards, Ajit From ambarish.rapte at oracle.com Thu Jan 18 13:58:47 2018 From: ambarish.rapte at oracle.com (Ambarish Rapte) Date: Thu, 18 Jan 2018 05:58:47 -0800 (PST) Subject: RFR : JDK-8154039 : Memory leak when selecting a tab which is not contained in TabPane::getTabs() Message-ID: <928d93b0-2506-4482-938b-9247a158cdea@default> Hi Kevin & Ajit, Please review this fix, Webrev: http://cr.openjdk.java.net/~arapte/fx/8154039/webrev.00/ Issue: https://bugs.openjdk.java.net/browse/JDK-8154039 Regards, Ambarish From kevin.rushforth at oracle.com Thu Jan 18 15:58:02 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 18 Jan 2018 07:58:02 -0800 Subject: [10] Review request: 8195075: Old app window is not reactivatable In-Reply-To: <4dd20295-58a8-c1be-532d-4407b811be11@oracle.com> References: <5ff7041c-d6c3-e682-8854-39d08871f2ad@oracle.com> <5A5FDC78.8050007@oracle.com> <4dd20295-58a8-c1be-532d-4407b811be11@oracle.com> Message-ID: <5A60C40A.7070308@oracle.com> No need. -- Kevin Alexey Semenyuk wrote: > Hi Kevin, > > My bad, I didn't look carefully at "Fix Version" in the JIRA record. > Yes, the subject of the email is misleading. Should I resend it with > the proper subject? > > - Alexey > > > On 1/17/2018 6:30 PM, Kevin Rushforth wrote: >> I see that this bug was (correctly) targeted for 11 and not for 10. I >> guess the subject line is wrong? >> >> -- Kevin >> >> >> Alexey Semenyuk wrote: >>> Victor, >>> >>> Please review my changes for fixing the issue: "JDK-8195075: Old app >>> window is not reactivatable" >>> >>> JIRA: https://bugs.openjdk.java.net/browse/JDK-8195075 >>> Webrev: http://cr.openjdk.java.net/~asemenyuk/8195075/webrev.00/ >>> >>> - Alexey >>> > From nlisker at gmail.com Thu Jan 18 21:36:21 2018 From: nlisker at gmail.com (Nir Lisker) Date: Thu, 18 Jan 2018 23:36:21 +0200 Subject: Instructions for working on OpenJFX Message-ID: Hi Kevin, Can you answer the questions I had in a previous mail please (question 4 is mostly answered)? http://mail.openjdk.java.net/pipermail/openjfx-dev/2018-January/021232.html Thanks, Nir From kevin.rushforth at oracle.com Fri Jan 19 00:10:27 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 18 Jan 2018 16:10:27 -0800 Subject: Instructions for working on OpenJFX In-Reply-To: References: Message-ID: <5A613773.3080502@oracle.com> I'm still a little behind on my email, but here are some quick answers. #1 - The NetBeans instructions are still mostly correct except that with FX 9 or later you can't compile or run code from within the IDE any more (and there isn't yet a release of NetBeans 9). Not sure about the other IDEs, but I suspect they are somewhat out of date. #2. You should be able to build just the FX bits (outside your IDE) using: gradle sdk -or- gradle javadoc depending on what you want to do (or you can build both targets). If you have a build of JDK 9 or later with FX bits in it, then you can use the build/run.args script to run with the just-built FX bits without rebuilding the JDK. java @build/run.args ... #3. I don't know since I don't use Eclipse; maybe someone on the list who uses Eclipse can answer. It might have to do with the level of JDK 9 support in Eclipse #4 - previously answered -- Kevin Nir Lisker wrote: > Hello, > > I have OpenJFX and OpenJDK built. I have also set up TortoiseHg and am > working with Eclipse. I have several questions: > > 1. Are the instructions at > https://wiki.openjdk.java.net/display/OpenJFX/Using+an+IDE still valid from > JDK 8? There are old TODOs there. If not, can I get a quick update? > > 2. After importing the projects to Eclipse and working on the source, what > steps need to be taken when the changes are to: > a. only the docs? > b. Java code? > c. Prism code? > Do I need to rebuild the JDK with JavaFX, rebuild only JavaFX, only compile > etc? What tests do I need to run (e.g., I doubt I need to run regression > tests when changing JavaDocs)? > > 3. Eclipse uses EJC (which I never had trouble with). Can this cause > trouble? > > 4. After creating a local changeset and assuming there is already a JIRA > issue for it and the fix approach was discussed, can I just push it and it > will enter a review queue? Do I need to ask someone specifically for a > review on the changeset ( > https://wiki.openjdk.java.net/display/OpenJFX/Code+Ownership is old...)? > > Thanks, > Nir > From kevin.rushforth at oracle.com Fri Jan 19 00:16:48 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 18 Jan 2018 16:16:48 -0800 Subject: [10, 11] Review request: 8193910: Version number in cssref.html and introduction_to_fxml.html is wrong In-Reply-To: <5A57E883.2040303@oracle.com> References: <5A57E883.2040303@oracle.com> Message-ID: <5A6138F0.4020702@oracle.com> Here is an updated webrev for jfx-dev (11) which avoids the hard-coded version number embedded in those two .html files: http://cr.openjdk.java.net/~kcr/8193910/webrev.01/ -- Kevin Kevin Rushforth wrote: > Hi Phil, > > Please review the following simple fix to the FX version number in our > two standalone html doc pages: > > JBS: https://bugs.openjdk.java.net/browse/JDK-8193910 > Webrev for 11: http://cr.openjdk.java.net/~kcr/8193910/webrev/ > Webrev for 10: http://cr.openjdk.java.net/~kcr/8193910/10/webrev/ > > Thanks. > > -- Kevin > From alexander.matveev at oracle.com Fri Jan 19 01:02:35 2018 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Thu, 18 Jan 2018 17:02:35 -0800 Subject: [11] Review request for 8191446: [Linux] Build and deliver the libav media stubs for openjfx build Message-ID: Hi Kevin, Please review the following: https://bugs.openjdk.java.net/browse/JDK-8191446 Added support for building libav stubs. Thanks, Alexander From lennart.borjeson at cinnober.com Fri Jan 19 13:46:05 2018 From: lennart.borjeson at cinnober.com (=?utf-8?B?TGVubmFydCBCw7ZyamVzb24=?=) Date: Fri, 19 Jan 2018 13:46:05 +0000 Subject: Instructions for working on OpenJFX In-Reply-To: <5A613773.3080502@oracle.com> References: <5A613773.3080502@oracle.com> Message-ID: <33FB79DB-DB19-49C5-958F-28ADFD27EA60@cinnober.com> 19 jan. 2018 kl. 01:10 skrev Kevin Rushforth >: #2. You should be able to build just the FX bits (outside your IDE) using: gradle sdk -or- gradle javadoc When building on my Mac, I've found that I must specify gradle --no-parallel sdk otherwise the build will consistently fail with: FAILURE: Build failed with an exception. * What went wrong: A problem was found with the configuration of task ':graphics:compileDecoraNativeShadersMac'. > Directory '/Users/lennartb/RaT/openJDK/javafx-10/modules/javafx.graphics/build/gensrc/headers/javafx.graphics' specified for property 'headers' does not exist. Best regards, /Lennart B?rjeson From kevin.rushforth at oracle.com Fri Jan 19 14:37:05 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 19 Jan 2018 06:37:05 -0800 Subject: Instructions for working on OpenJFX In-Reply-To: <33FB79DB-DB19-49C5-958F-28ADFD27EA60@cinnober.com> References: <5A613773.3080502@oracle.com> <33FB79DB-DB19-49C5-958F-28ADFD27EA60@cinnober.com> Message-ID: <5A620291.9000009@oracle.com> What version of gradle are you using? gradle 4.3, which is what we recommend / use in production, does not do parallel task execution by default. Are you enabling it in your gradle.properties file? Or maybe using a later version of gradle? -- Kevin Lennart B?rjeson wrote: > 19 jan. 2018 kl. 01:10 skrev Kevin Rushforth >: > > #2. You should be able to build just the FX bits (outside your IDE) using: > > gradle sdk > -or- > gradle javadoc > > > > When building on my Mac, I've found that I must specify > > gradle --no-parallel sdk > > otherwise the build will consistently fail with: > > > FAILURE: Build failed with an exception. > > * What went wrong: > A problem was found with the configuration of task ':graphics:compileDecoraNativeShadersMac'. > >> Directory '/Users/lennartb/RaT/openJDK/javafx-10/modules/javafx.graphics/build/gensrc/headers/javafx.graphics' specified for property 'headers' does not exist. >> > > > Best regards, > > /Lennart B?rjeson > From arunprasad.rajkumar at oracle.com Fri Jan 19 14:46:57 2018 From: arunprasad.rajkumar at oracle.com (Arunprasad Rajkumar) Date: Fri, 19 Jan 2018 20:16:57 +0530 Subject: [jfx-dev] Review request: 8194935: Cherry pick GTK WebKit 2.18.5 changes Message-ID: <4BEB3020-D2B2-4F73-B1D0-DCBAD3277C49@oracle.com> Hi, Please review the following fix, Bug: https://bugs.openjdk.java.net/browse/JDK-8194935 Patch: http://cr.openjdk.java.net/~arajkumar/8194935/webrev Thanks, Arun From kevin.rushforth at oracle.com Fri Jan 19 14:53:42 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 19 Jan 2018 06:53:42 -0800 Subject: [11] Review request for 8191446: [Linux] Build and deliver the libav media stubs for openjfx build In-Reply-To: References: Message-ID: <5A620676.6040806@oracle.com> Sure, I'll review/test it when I get a chance. As a note to other reviewers, this patch adds a new "BUILD_LIBAV_STUBS" flag to build.gradle to support building the libav stubs in support of running on multiple Linux systems that may have different versions of libav. Currently we only build these stubs when doing a closed build for Oracle JDK. This patch moves this build logic into the open, and is the last major [1] piece of closed build logic preventing open and closed builds from being identical. It would be helpful if someone outside Oracle could test this out on Linux and let us know whether it works for you. Alexander: can you add the information about the new flags(s) to JBS? Also, one thing I just thought of is that the new flag(s) could be added to gradle.properties.template for documentation. Thanks. -- Kevin [1] there is still some cleanup that needs to be done, but this is the last big piece Alexander Matveev wrote: > Hi Kevin, > > Please review the following: > https://bugs.openjdk.java.net/browse/JDK-8191446 > > Added support for building libav stubs. > > Thanks, > Alexander From lennart.borjeson at cinnober.com Fri Jan 19 14:59:34 2018 From: lennart.borjeson at cinnober.com (=?utf-8?B?TGVubmFydCBCw7ZyamVzb24=?=) Date: Fri, 19 Jan 2018 14:59:34 +0000 Subject: Instructions for working on OpenJFX In-Reply-To: <5A620291.9000009@oracle.com> References: <5A613773.3080502@oracle.com> <33FB79DB-DB19-49C5-958F-28ADFD27EA60@cinnober.com> <5A620291.9000009@oracle.com> Message-ID: <09E1B8D5-6865-49C8-8B3F-E6EB1798BB16@cinnober.com> > 19 jan. 2018 kl. 15:37 skrev Kevin Rushforth : > > What version of gradle are you using? gradle 4.3, which is what we recommend / use in production, does not do parallel task execution by default. Are you enabling it in your gradle.properties file? Or maybe using a later version of gradle? > > -- Kevin > Ah! Mea culpa; I do indeed have enabled it in my properties. Haven't touched it for a year, so it had completely slipped my mind. Anyway, the wiki should perhaps mention that parallel execution should be off? I spent several days trying to find the reason for the failure until I just happened to try --no-parallel. My linux build seem to work with parallel on, but that is perhaps only by pure luck? I'm using gradle 4.3.1, BTW. /Lennart > > Lennart B?rjeson wrote: >> 19 jan. 2018 kl. 01:10 skrev Kevin Rushforth >> >: >> >> #2. You should be able to build just the FX bits (outside your IDE) using: >> >> gradle sdk >> -or- >> gradle javadoc >> >> >> >> When building on my Mac, I've found that I must specify >> >> gradle --no-parallel sdk >> >> otherwise the build will consistently fail with: >> >> >> FAILURE: Build failed with an exception. >> >> * What went wrong: >> A problem was found with the configuration of task ':graphics:compileDecoraNativeShadersMac'. >> >> >>> Directory '/Users/lennartb/RaT/openJDK/javafx-10/modules/javafx.graphics/build/gensrc/headers/javafx.graphics' specified for property 'headers' does not exist. >>> >>> >> >> From kevin.rushforth at oracle.com Fri Jan 19 15:04:05 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 19 Jan 2018 07:04:05 -0800 Subject: Instructions for working on OpenJFX In-Reply-To: <09E1B8D5-6865-49C8-8B3F-E6EB1798BB16@cinnober.com> References: <5A613773.3080502@oracle.com> <33FB79DB-DB19-49C5-958F-28ADFD27EA60@cinnober.com> <5A620291.9000009@oracle.com> <09E1B8D5-6865-49C8-8B3F-E6EB1798BB16@cinnober.com> Message-ID: <5A6208E5.9010905@oracle.com> Sure we could add that to the Wiki. I'll put this on the list for next time I update it to incorporate other feedback. I'd guess that you are just getting lucky on Linux. -- Kevin Lennart B?rjeson wrote: >> 19 jan. 2018 kl. 15:37 skrev Kevin Rushforth : >> >> What version of gradle are you using? gradle 4.3, which is what we recommend / use in production, does not do parallel task execution by default. Are you enabling it in your gradle.properties file? Or maybe using a later version of gradle? >> >> -- Kevin >> >> > > Ah! Mea culpa; I do indeed have enabled it in my properties. Haven't touched it for a year, so it had completely slipped my mind. > > Anyway, the wiki should perhaps mention that parallel execution should be off? I spent several days trying to find the reason for the failure until I just happened to try --no-parallel. > > My linux build seem to work with parallel on, but that is perhaps only by pure luck? > > I'm using gradle 4.3.1, BTW. > > /Lennart > > >> Lennart B?rjeson wrote: >> >>> 19 jan. 2018 kl. 01:10 skrev Kevin Rushforth >>> >>>> : >>>> >>> #2. You should be able to build just the FX bits (outside your IDE) using: >>> >>> gradle sdk >>> -or- >>> gradle javadoc >>> >>> >>> >>> When building on my Mac, I've found that I must specify >>> >>> gradle --no-parallel sdk >>> >>> otherwise the build will consistently fail with: >>> >>> >>> FAILURE: Build failed with an exception. >>> >>> * What went wrong: >>> A problem was found with the configuration of task ':graphics:compileDecoraNativeShadersMac'. >>> >>> >>> >>>> Directory '/Users/lennartb/RaT/openJDK/javafx-10/modules/javafx.graphics/build/gensrc/headers/javafx.graphics' specified for property 'headers' does not exist. >>>> >>>> >>>> >>> > > > From semyon.sadetsky at oracle.com Fri Jan 19 16:50:46 2018 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Fri, 19 Jan 2018 08:50:46 -0800 Subject: [8u-Backport] Review request for 8185634, 8187803 : Java Fx-Swing dialogs appearing behind main stage In-Reply-To: <62fcf392-d5dc-40e3-8e59-715f208c05a3@default> References: <11b1475d-0855-469a-90fd-6a6d93d14c91@default> <74e85c96-5395-b382-9c98-05389c00f4d2@oracle.com> <5A5FC53A.7080803@oracle.com> <62fcf392-d5dc-40e3-8e59-715f208c05a3@default> Message-ID: <70d20d8c-5a87-368a-544d-fece5bf6cd50@oracle.com> Hi Phil, Dipak, The 8021961 fix was about invisible parent window. The current fix is independent from it so the change looks good. --Semyon On 01/17/2018 09:48 PM, Dipak Kumar wrote: > Hi Semyon, > > Could you please review the changes (also have a look at Phil's comment in trailing mail) and let me know your comments. > > Thanks Kevin and Phil. I have incorporated the changes suggested for unit tests in JavaFx side. Request you to have a look. > > Please find updated webrev at - http://cr.openjdk.java.net/~dkumar/8185634/webrev.01/ . > > Thanks, > Dipak > > -----Original Message----- > From: Kevin Rushforth > Sent: Thursday, January 18, 2018 3:21 AM > To: Phil Race > Cc: Dipak Kumar ; openjfx-dev at openjdk.java.net; awt-dev at openjdk.java.net > Subject: Re: [8u-Backport] Review request for 8185634, 8187803 : Java Fx-Swing dialogs appearing behind main stage > > I think you mean https://bugs.openjdk.java.net/browse/JDK-8187803 for the AWT/Swing side... > > -- Kevin > > > Phil Race wrote: >> The AWT/Swing side of this needs to be bug >> https://bugs.openjdk.java.net/browse/JDK-8185634 >> >> One thing I notice is that in XWindowPeer.java the calculation for the >> value of transientForWindow is different .. because you don't have the >> fix for >> https://bugs.openjdk.java.net/browse/JDK-8021961 : >> "setAlwaysOnTop doesn't behave correctly in Linux/Solaris under >> certain scenarios" >> >> Do you first need to backport that too ? Maybe Semyon (who authored >> that fix) can say whether it matters .. >> >> -phil. >> >> On 01/12/2018 02:12 AM, Dipak Kumar wrote: >>> Hi All, >>> >>> >>> Please review the below patch (for 8u-backport) - >>> >>> >>> Webrev : http://cr.openjdk.java.net/~dkumar/8185634/webrev.00/ >>> >>> JBS - https://bugs.openjdk.java.net/browse/JDK-8185634 >>> >>> >>> Thanks, >>> >>> Dipak From victor.drozdov at oracle.com Sat Jan 20 02:08:25 2018 From: victor.drozdov at oracle.com (victor.drozdov at oracle.com) Date: Fri, 19 Jan 2018 18:08:25 -0800 Subject: [11] Review request: 8195074: Improve signing mechanism on Mac 10.12+ Message-ID: <0d894f22-5671-3e28-1999-ae716ea8f32e@oracle.com> Kevin, Please review my changes for fixing the issue: " JDK-8195074: Improve signing mechanism on Mac 10.12+" JIRA: https://bugs.openjdk.java.net/browse/JDK-8195074 Webrev: http://cr.openjdk.java.net/~vdrozdov/JDK-8195074/webrev.00/ --Victor From rajath.kamath at oracle.com Mon Jan 22 09:00:12 2018 From: rajath.kamath at oracle.com (Rajath Kamath) Date: Mon, 22 Jan 2018 01:00:12 -0800 (PST) Subject: [11] Review Request - JDK-8089375: When WebWorker file is unaccessible, script should fail silently or post meaningful exception Message-ID: Hi , Please review this fix in the WebNodeAutomated test case. JBS : https://bugs.openjdk.java.net/browse/JDK-8089375 WebRev : http://cr.openjdk.java.net/~rkamath/8089375/webrev.00/ Thanks, Rajath From ambarish.rapte at oracle.com Mon Jan 22 18:28:28 2018 From: ambarish.rapte at oracle.com (Ambarish Rapte) Date: Mon, 22 Jan 2018 10:28:28 -0800 (PST) Subject: [11] RFR : JDK-8193311 : [Spinner] Default button not activated on ENTER Message-ID: <1ea81353-8ba2-4438-8d83-83dbee337e6f@default> Hi Kevin & Ajit, Request you to review this fix, Issue: https://bugs.openjdk.java.net/browse/JDK-8193311 Webrev: http://cr.openjdk.java.net/~arapte/fx/8193311/webrev.00/ Regards, Ambarish From johan.vos at gluonhq.com Wed Jan 24 10:42:25 2018 From: johan.vos at gluonhq.com (Johan Vos) Date: Wed, 24 Jan 2018 10:42:25 +0000 Subject: lipjpeg7 in static library Message-ID: Hi, We are currently building a native library for javafx_iio which includes libjpeg7. As a consequence, those symbols are included in the static libjavafx_iio.a on iOS. If we add other libraries (e.g. OpenCV) this can result in duplicate symbols, as the libjpeg7 library might be included in other frameworks as well. As a dirty hack, I build 2 versions of libjavafx_iio.a: one with libjpeg7, and one without. A better solution might be to prefix the symbols in the libjpeg7 files. Or are there better ideas? Thanks, - Johan From nlisker at gmail.com Wed Jan 24 11:28:40 2018 From: nlisker at gmail.com (Nir Lisker) Date: Wed, 24 Jan 2018 13:28:40 +0200 Subject: Instructions for working on OpenJFX In-Reply-To: <5A613773.3080502@oracle.com> References: <5A613773.3080502@oracle.com> Message-ID: If you're still catching up, I would like to verify that I should ignore project-level errors from the IDE. For example, Eclipse complains about the graphics project: Project 'graphics' is missing required source folder: 'build/resources/jsl-decora' Project 'graphics' is missing required source folder: 'build/resources/jsl-prism' and about the buildSource project: Project 'buildSrc' is missing required library: '...\rt\build\libs\ant-1.8.2.jar' Project 'buildSrc' is missing required library: '...\rt\build\libs\antlr-3.1.3.jar' Project 'buildSrc' is missing required library: '...\rt\build\libs\antlr-runtime-3.1.3.jar' Project 'buildSrc' is missing required library: '...\rt\build\libs\stringtemplate-3.2.jar' Project 'buildSrc' is missing required source folder: 'src/main/java' Project 'buildSrc' is missing required source folder: 'src/test/java' As long as the gradle tasks complete successfully I can ignore all that? - Nir On Fri, Jan 19, 2018 at 2:10 AM, Kevin Rushforth wrote: > I'm still a little behind on my email, but here are some quick answers. > > #1 - The NetBeans instructions are still mostly correct except that with > FX 9 or later you can't compile or run code from within the IDE any more > (and there isn't yet a release of NetBeans 9). Not sure about the other > IDEs, but I suspect they are somewhat out of date. > > > #2. You should be able to build just the FX bits (outside your IDE) using: > > gradle sdk > -or- > gradle javadoc > > depending on what you want to do (or you can build both targets). If you > have a build of JDK 9 or later with FX bits in it, then you can use the > build/run.args script to run with the just-built FX bits without rebuilding > the JDK. > > java @build/run.args ... > > > #3. I don't know since I don't use Eclipse; maybe someone on the list who > uses Eclipse can answer. It might have to do with the level of JDK 9 > support in Eclipse > > > #4 - previously answered > > -- Kevin > > > Nir Lisker wrote: > >> Hello, >> >> I have OpenJFX and OpenJDK built. I have also set up TortoiseHg and am >> working with Eclipse. I have several questions: >> >> 1. Are the instructions at >> https://wiki.openjdk.java.net/display/OpenJFX/Using+an+IDE still valid >> from >> JDK 8? There are old TODOs there. If not, can I get a quick update? >> >> 2. After importing the projects to Eclipse and working on the source, what >> steps need to be taken when the changes are to: >> a. only the docs? >> b. Java code? >> c. Prism code? >> Do I need to rebuild the JDK with JavaFX, rebuild only JavaFX, only >> compile >> etc? What tests do I need to run (e.g., I doubt I need to run regression >> tests when changing JavaDocs)? >> >> 3. Eclipse uses EJC (which I never had trouble with). Can this cause >> trouble? >> >> 4. After creating a local changeset and assuming there is already a JIRA >> issue for it and the fix approach was discussed, can I just push it and it >> will enter a review queue? Do I need to ask someone specifically for a >> review on the changeset ( >> https://wiki.openjdk.java.net/display/OpenJFX/Code+Ownership is old...)? >> >> Thanks, >> Nir >> >> > From philip.race at oracle.com Wed Jan 24 17:13:51 2018 From: philip.race at oracle.com (Phil Race) Date: Wed, 24 Jan 2018 09:13:51 -0800 Subject: lipjpeg7 in static library In-Reply-To: References: Message-ID: <35152583-ac8f-feb4-6ffe-9267ca28d626@oracle.com> Does libjavafx_iio.a really need to export the JPEG symbols ? On Windows, or Linux, or Solaris .. there are ways to limit the exported symbols from a library. I found this page for macos : https://developer.apple.com/library/content/documentation/MacOSX/Conceptual/BPFrameworks/Tasks/ExportingInterfaces.html Not a complete answer but maybe somewhere to start. -phil. On 01/24/2018 02:42 AM, Johan Vos wrote: > Hi, > > We are currently building a native library for javafx_iio which includes > libjpeg7. As a consequence, those symbols are included in the static > libjavafx_iio.a on iOS. If we add other libraries (e.g. OpenCV) this can > result in duplicate symbols, as the libjpeg7 library might be included in > other frameworks as well. > > As a dirty hack, I build 2 versions of libjavafx_iio.a: one with libjpeg7, > and one without. A better solution might be to prefix the symbols in the > libjpeg7 files. > > Or are there better ideas? > > Thanks, > > - Johan From kevin.rushforth at oracle.com Wed Jan 24 17:23:07 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 24 Jan 2018 09:23:07 -0800 Subject: lipjpeg7 in static library In-Reply-To: <35152583-ac8f-feb4-6ffe-9267ca28d626@oracle.com> References: <35152583-ac8f-feb4-6ffe-9267ca28d626@oracle.com> Message-ID: <5A68C0FB.9020004@oracle.com> Hiding the symbols seems like a better solution than shipping two binaries, and is probably easier than mangling the symbols. -- Kevin Phil Race wrote: > Does libjavafx_iio.a really need to export the JPEG symbols ? > On Windows, or Linux, or Solaris .. there are ways > to limit the exported symbols from a library. > > I found this page for macos : > > https://developer.apple.com/library/content/documentation/MacOSX/Conceptual/BPFrameworks/Tasks/ExportingInterfaces.html > > > Not a complete answer but maybe somewhere to start. > > -phil. > > On 01/24/2018 02:42 AM, Johan Vos wrote: >> Hi, >> >> We are currently building a native library for javafx_iio which includes >> libjpeg7. As a consequence, those symbols are included in the static >> libjavafx_iio.a on iOS. If we add other libraries (e.g. OpenCV) this can >> result in duplicate symbols, as the libjpeg7 library might be >> included in >> other frameworks as well. >> >> As a dirty hack, I build 2 versions of libjavafx_iio.a: one with >> libjpeg7, >> and one without. A better solution might be to prefix the symbols in the >> libjpeg7 files. >> >> Or are there better ideas? >> >> Thanks, >> >> - Johan > From kevin.rushforth at oracle.com Wed Jan 24 23:22:10 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 24 Jan 2018 15:22:10 -0800 Subject: Instructions for working on OpenJFX In-Reply-To: References: <5A613773.3080502@oracle.com> Message-ID: <5A691522.4060404@oracle.com> Yes, the IDE configs are for developer convenience only. You can feel free to ignore them. If someone wants to cleanup the Eclipse IDE files, that would be fine, too. -- Kevin Nir Lisker wrote: > If you're still catching up, I would like to verify that I should > ignore project-level errors from the IDE. For example, Eclipse > complains about the graphics project: > > Project 'graphics' is missing required source folder: > 'build/resources/jsl-decora' > Project 'graphics' is missing required source folder: > 'build/resources/jsl-prism' > > and about the buildSource project: > > Project 'buildSrc' is missing required library: > '...\rt\build\libs\ant-1.8.2.jar' > Project 'buildSrc' is missing required library: > '...\rt\build\libs\antlr-3.1.3.jar' > Project 'buildSrc' is missing required library: > '...\rt\build\libs\antlr-runtime-3.1.3.jar' > Project 'buildSrc' is missing required library: > '...\rt\build\libs\stringtemplate-3.2.jar' > Project 'buildSrc' is missing required source folder: 'src/main/java' > Project 'buildSrc' is missing required source folder: 'src/test/java' > > As long as the gradle tasks complete successfully I can ignore all that? > > - Nir > > On Fri, Jan 19, 2018 at 2:10 AM, Kevin Rushforth > > wrote: > > I'm still a little behind on my email, but here are some quick > answers. > > #1 - The NetBeans instructions are still mostly correct except > that with FX 9 or later you can't compile or run code from within > the IDE any more (and there isn't yet a release of NetBeans 9). > Not sure about the other IDEs, but I suspect they are somewhat out > of date. > > > #2. You should be able to build just the FX bits (outside your > IDE) using: > > gradle sdk > -or- > gradle javadoc > > depending on what you want to do (or you can build both targets). > If you have a build of JDK 9 or later with FX bits in it, then you > can use the build/run.args script to run with the just-built FX > bits without rebuilding the JDK. > > java @build/run.args ... > > > #3. I don't know since I don't use Eclipse; maybe someone on the > list who uses Eclipse can answer. It might have to do with the > level of JDK 9 support in Eclipse > > > #4 - previously answered > > -- Kevin > > > Nir Lisker wrote: > > Hello, > > I have OpenJFX and OpenJDK built. I have also set up > TortoiseHg and am > working with Eclipse. I have several questions: > > 1. Are the instructions at > https://wiki.openjdk.java.net/display/OpenJFX/Using+an+IDE > > still valid from > JDK 8? There are old TODOs there. If not, can I get a quick > update? > > 2. After importing the projects to Eclipse and working on the > source, what > steps need to be taken when the changes are to: > a. only the docs? > b. Java code? > c. Prism code? > Do I need to rebuild the JDK with JavaFX, rebuild only JavaFX, > only compile > etc? What tests do I need to run (e.g., I doubt I need to run > regression > tests when changing JavaDocs)? > > 3. Eclipse uses EJC (which I never had trouble with). Can this > cause > trouble? > > 4. After creating a local changeset and assuming there is > already a JIRA > issue for it and the fix approach was discussed, can I just > push it and it > will enter a review queue? Do I need to ask someone > specifically for a > review on the changeset ( > https://wiki.openjdk.java.net/display/OpenJFX/Code+Ownership > > is old...)? > > Thanks, > Nir > > > From kevin.rushforth at oracle.com Wed Jan 24 23:25:03 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 24 Jan 2018 15:25:03 -0800 Subject: [11] Review request for 8191446: [Linux] Build and deliver the libav media stubs for openjfx build In-Reply-To: <5A620676.6040806@oracle.com> References: <5A620676.6040806@oracle.com> Message-ID: <5A6915CF.7080406@oracle.com> Anyone outside of Oracle willing to give this a test drive? In any case, I plan to finish up my review today. -- Kevin Kevin Rushforth wrote: > Sure, I'll review/test it when I get a chance. > > As a note to other reviewers, this patch adds a new > "BUILD_LIBAV_STUBS" flag to build.gradle to support building the libav > stubs in support of running on multiple Linux systems that may have > different versions of libav. Currently we only build these stubs when > doing a closed build for Oracle JDK. This patch moves this build logic > into the open, and is the last major [1] piece of closed build logic > preventing open and closed builds from being identical. > > It would be helpful if someone outside Oracle could test this out on > Linux and let us know whether it works for you. > > Alexander: can you add the information about the new flags(s) to JBS? > > Also, one thing I just thought of is that the new flag(s) could be > added to gradle.properties.template for documentation. > > Thanks. > > -- Kevin > > [1] there is still some cleanup that needs to be done, but this is the > last big piece > > > Alexander Matveev wrote: >> Hi Kevin, >> >> Please review the following: >> https://bugs.openjdk.java.net/browse/JDK-8191446 >> >> Added support for building libav stubs. >> >> Thanks, >> Alexander From nlisker at gmail.com Thu Jan 25 02:46:00 2018 From: nlisker at gmail.com (Nir Lisker) Date: Thu, 25 Jan 2018 04:46:00 +0200 Subject: Instructions for working on OpenJFX In-Reply-To: <5A691522.4060404@oracle.com> References: <5A613773.3080502@oracle.com> <5A691522.4060404@oracle.com> Message-ID: Submitted 9052392 to fix Eclipse config files. On Thu, Jan 25, 2018 at 1:22 AM, Kevin Rushforth wrote: > Yes, the IDE configs are for developer convenience only. You can feel free > to ignore them. > > If someone wants to cleanup the Eclipse IDE files, that would be fine, too. > > > -- Kevin > > > Nir Lisker wrote: > > If you're still catching up, I would like to verify that I should ignore > project-level errors from the IDE. For example, Eclipse complains about the > graphics project: > > Project 'graphics' is missing required source folder: > 'build/resources/jsl-decora' > Project 'graphics' is missing required source folder: > 'build/resources/jsl-prism' > > and about the buildSource project: > > Project 'buildSrc' is missing required library: > '...\rt\build\libs\ant-1.8.2.jar' > Project 'buildSrc' is missing required library: > '...\rt\build\libs\antlr-3.1.3.jar' > Project 'buildSrc' is missing required library: '...\rt\build\libs\antlr- > runtime-3.1.3.jar' > Project 'buildSrc' is missing required library: '...\rt\build\libs\ > stringtemplate-3.2.jar' > Project 'buildSrc' is missing required source folder: 'src/main/java' > Project 'buildSrc' is missing required source folder: 'src/test/java' > > As long as the gradle tasks complete successfully I can ignore all that? > > - Nir > > On Fri, Jan 19, 2018 at 2:10 AM, Kevin Rushforth < > kevin.rushforth at oracle.com> wrote: > >> I'm still a little behind on my email, but here are some quick answers. >> >> #1 - The NetBeans instructions are still mostly correct except that with >> FX 9 or later you can't compile or run code from within the IDE any more >> (and there isn't yet a release of NetBeans 9). Not sure about the other >> IDEs, but I suspect they are somewhat out of date. >> >> >> #2. You should be able to build just the FX bits (outside your IDE) using: >> >> gradle sdk >> -or- >> gradle javadoc >> >> depending on what you want to do (or you can build both targets). If you >> have a build of JDK 9 or later with FX bits in it, then you can use the >> build/run.args script to run with the just-built FX bits without rebuilding >> the JDK. >> >> java @build/run.args ... >> >> >> #3. I don't know since I don't use Eclipse; maybe someone on the list who >> uses Eclipse can answer. It might have to do with the level of JDK 9 >> support in Eclipse >> >> >> #4 - previously answered >> >> -- Kevin >> >> >> Nir Lisker wrote: >> >>> Hello, >>> >>> I have OpenJFX and OpenJDK built. I have also set up TortoiseHg and am >>> working with Eclipse. I have several questions: >>> >>> 1. Are the instructions at >>> https://wiki.openjdk.java.net/display/OpenJFX/Using+an+IDE still valid >>> from >>> JDK 8? There are old TODOs there. If not, can I get a quick update? >>> >>> 2. After importing the projects to Eclipse and working on the source, >>> what >>> steps need to be taken when the changes are to: >>> a. only the docs? >>> b. Java code? >>> c. Prism code? >>> Do I need to rebuild the JDK with JavaFX, rebuild only JavaFX, only >>> compile >>> etc? What tests do I need to run (e.g., I doubt I need to run regression >>> tests when changing JavaDocs)? >>> >>> 3. Eclipse uses EJC (which I never had trouble with). Can this cause >>> trouble? >>> >>> 4. After creating a local changeset and assuming there is already a JIRA >>> issue for it and the fix approach was discussed, can I just push it and >>> it >>> will enter a review queue? Do I need to ask someone specifically for a >>> review on the changeset ( >>> https://wiki.openjdk.java.net/display/OpenJFX/Code+Ownership is old...)? >>> >>> Thanks, >>> Nir >>> >>> >> > From kevin.rushforth at oracle.com Thu Jan 25 12:57:16 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 25 Jan 2018 04:57:16 -0800 Subject: Instructions for working on OpenJFX In-Reply-To: References: <5A613773.3080502@oracle.com> <5A691522.4060404@oracle.com> Message-ID: <5A69D42C.7040007@oracle.com> Now available here: https://bugs.openjdk.java.net/browse/JDK-8196130 You can send me your patch and I'll review / push it. -- Kevin Nir Lisker wrote: > Submitted 9052392 to fix Eclipse config files. > > On Thu, Jan 25, 2018 at 1:22 AM, Kevin Rushforth > > wrote: > > Yes, the IDE configs are for developer convenience only. You can > feel free to ignore them. > > If someone wants to cleanup the Eclipse IDE files, that would be > fine, too. > > > -- Kevin > > > Nir Lisker wrote: >> If you're still catching up, I would like to verify that I should >> ignore project-level errors from the IDE. For example, Eclipse >> complains about the graphics project: >> >> Project 'graphics' is missing required source folder: >> 'build/resources/jsl-decora' >> Project 'graphics' is missing required source folder: >> 'build/resources/jsl-prism' >> >> and about the buildSource project: >> >> Project 'buildSrc' is missing required library: >> '...\rt\build\libs\ant-1.8.2.jar' >> Project 'buildSrc' is missing required library: >> '...\rt\build\libs\antlr-3.1.3.jar' >> Project 'buildSrc' is missing required library: >> '...\rt\build\libs\antlr-runtime-3.1.3.jar' >> Project 'buildSrc' is missing required library: >> '...\rt\build\libs\stringtemplate-3.2.jar' >> Project 'buildSrc' is missing required source folder: 'src/main/java' >> Project 'buildSrc' is missing required source folder: 'src/test/java' >> >> As long as the gradle tasks complete successfully I can ignore >> all that? >> >> - Nir >> >> On Fri, Jan 19, 2018 at 2:10 AM, Kevin Rushforth >> > >> wrote: >> >> I'm still a little behind on my email, but here are some >> quick answers. >> >> #1 - The NetBeans instructions are still mostly correct >> except that with FX 9 or later you can't compile or run code >> from within the IDE any more (and there isn't yet a release >> of NetBeans 9). Not sure about the other IDEs, but I suspect >> they are somewhat out of date. >> >> >> #2. You should be able to build just the FX bits (outside >> your IDE) using: >> >> gradle sdk >> -or- >> gradle javadoc >> >> depending on what you want to do (or you can build both >> targets). If you have a build of JDK 9 or later with FX bits >> in it, then you can use the build/run.args script to run with >> the just-built FX bits without rebuilding the JDK. >> >> java @build/run.args ... >> >> >> #3. I don't know since I don't use Eclipse; maybe someone on >> the list who uses Eclipse can answer. It might have to do >> with the level of JDK 9 support in Eclipse >> >> >> #4 - previously answered >> >> -- Kevin >> >> >> Nir Lisker wrote: >> >> Hello, >> >> I have OpenJFX and OpenJDK built. I have also set up >> TortoiseHg and am >> working with Eclipse. I have several questions: >> >> 1. Are the instructions at >> https://wiki.openjdk.java.net/display/OpenJFX/Using+an+IDE >> >> still valid from >> JDK 8? There are old TODOs there. If not, can I get a >> quick update? >> >> 2. After importing the projects to Eclipse and working on >> the source, what >> steps need to be taken when the changes are to: >> a. only the docs? >> b. Java code? >> c. Prism code? >> Do I need to rebuild the JDK with JavaFX, rebuild only >> JavaFX, only compile >> etc? What tests do I need to run (e.g., I doubt I need to >> run regression >> tests when changing JavaDocs)? >> >> 3. Eclipse uses EJC (which I never had trouble with). Can >> this cause >> trouble? >> >> 4. After creating a local changeset and assuming there is >> already a JIRA >> issue for it and the fix approach was discussed, can I >> just push it and it >> will enter a review queue? Do I need to ask someone >> specifically for a >> review on the changeset ( >> https://wiki.openjdk.java.net/display/OpenJFX/Code+Ownership >> >> is old...)? >> >> Thanks, >> Nir >> >> >> > From nlisker at gmail.com Thu Jan 25 13:36:41 2018 From: nlisker at gmail.com (Nir Lisker) Date: Thu, 25 Jan 2018 15:36:41 +0200 Subject: JDK-8196130: Eclipse configuration files need to be updated Message-ID: Iv'e removed all the classpath dependencies that were causing errors. I don't mind sorting out the rest of the files while at it, though for that there are a few things I'm not sure about: 1. Some dependencies are marked as optional and as such they don't cause errors, but they are still missing. Is it safe to remove them or is it possible that they will be created as some point? Examples are the 'base' module with "src/test/resources" and "src/main/resources" optional dependencies, and 'controls' module has the optional dependency "src/main/resources" commented out. 2. Can I assume that all other dependencies are really needed? (Eclipse won't complain about unused ones as far as I know.) 3. What are the formatting standards for XML (indentation, line length...)? >From a quick look I see different styles in different files. - Nir From kevin.rushforth at oracle.com Thu Jan 25 14:01:28 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 25 Jan 2018 06:01:28 -0800 Subject: JDK-8196130: Eclipse configuration files need to be updated In-Reply-To: References: Message-ID: <5A69E338.8000508@oracle.com> Nir Lisker wrote: > Iv'e removed all the classpath dependencies that were causing errors. > I don't mind sorting out the rest of the files while at it, though for > that there are a few things I'm not sure about: > > 1. Some dependencies are marked as optional and as such they don't > cause errors, but they are still missing. Is it safe to remove them or > is it possible that they will be created as some point? Some of them might be created...not sure without checking. I recommend running "gradle sdk" and then seeing if the dependencies are there. > Examples are the 'base' module with "src/test/resources" > and "src/main/resources" optional dependencies, and 'controls' module > has the optional dependency "src/main/resources" commented out. I see. You might as well leave them, but it probably doesn't matter. > 2. Can I assume that all other dependencies are really needed? > (Eclipse won't complain about unused ones as far as I know.) That seems best. > 3. What are the formatting standards for XML (indentation, line > length...)? From a quick look I see different styles in different files. For IDE files, we don't worry about formatting. In many cases they are auto-generated anyway. -- Kevin > > - Nir From kevin.rushforth at oracle.com Thu Jan 25 14:06:13 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 25 Jan 2018 06:06:13 -0800 Subject: JDK-8196130: Eclipse configuration files need to be updated In-Reply-To: <5A69E338.8000508@oracle.com> References: <5A69E338.8000508@oracle.com> Message-ID: <5A69E455.3010200@oracle.com> One more thing about the specific path you mentioned as not being there. These are still being created by 'gradle sdk', but the path is wrong (the files moved in JDK 9) and should be: build/gensrc/jsl-decora build/gensrc/jsl-prism You might want to take that into account. -- Kevin Kevin Rushforth wrote: > > > Nir Lisker wrote: >> Iv'e removed all the classpath dependencies that were causing errors. >> I don't mind sorting out the rest of the files while at it, though >> for that there are a few things I'm not sure about: >> >> 1. Some dependencies are marked as optional and as such they don't >> cause errors, but they are still missing. Is it safe to remove them >> or is it possible that they will be created as some point? > > Some of them might be created...not sure without checking. I recommend > running "gradle sdk" and then seeing if the dependencies are there. > >> Examples are the 'base' module with "src/test/resources" and >> "src/main/resources" optional dependencies, and 'controls' module has >> the optional dependency "src/main/resources" commented out. > > I see. You might as well leave them, but it probably doesn't matter. > >> 2. Can I assume that all other dependencies are really needed? >> (Eclipse won't complain about unused ones as far as I know.) > > That seems best. > >> 3. What are the formatting standards for XML (indentation, line >> length...)? From a quick look I see different styles in different files. > > For IDE files, we don't worry about formatting. In many cases they are > auto-generated anyway. > > -- Kevin > >> >> - Nir From nlisker at gmail.com Thu Jan 25 14:34:25 2018 From: nlisker at gmail.com (Nir Lisker) Date: Thu, 25 Jan 2018 16:34:25 +0200 Subject: JDK-8196130: Eclipse configuration files need to be updated In-Reply-To: <5A69E455.3010200@oracle.com> References: <5A69E338.8000508@oracle.com> <5A69E455.3010200@oracle.com> Message-ID: So this is why I was asking about the optional stuff: 'graphics' module has BOTH build/resources/jsl-decora build/resources/jsl-prism and build/gensrc/jsl-decora build/gensrc/jsl-prism That led me to think that when the new dependencies were added the old ones weren't removed. Those that weren't optional (like the /resources ones, which I removed) were easy to catch and we could have finished here. Those that are optional are not causing trouble even when missing because they are optional. gradle sdk does not create the ones which are marked optional that Iv'e surveyed, but I don't know if that's the only way they can be created. If I compare solely with gradle sdk then I can just remove whatever is missing on grounds that it's left over. - Nir On Thu, Jan 25, 2018 at 4:06 PM, Kevin Rushforth wrote: > One more thing about the specific path you mentioned as not being there. > > > > > These are still being created by 'gradle sdk', but the path is wrong (the > files moved in JDK 9) and should be: > > build/gensrc/jsl-decora > build/gensrc/jsl-prism > > You might want to take that into account. > > -- Kevin > > > > Kevin Rushforth wrote: > >> >> >> Nir Lisker wrote: >> >>> Iv'e removed all the classpath dependencies that were causing errors. I >>> don't mind sorting out the rest of the files while at it, though for that >>> there are a few things I'm not sure about: >>> >>> 1. Some dependencies are marked as optional and as such they don't cause >>> errors, but they are still missing. Is it safe to remove them or is it >>> possible that they will be created as some point? >>> >> >> Some of them might be created...not sure without checking. I recommend >> running "gradle sdk" and then seeing if the dependencies are there. >> >> Examples are the 'base' module with "src/test/resources" and >>> "src/main/resources" optional dependencies, and 'controls' module has the >>> optional dependency "src/main/resources" commented out. >>> >> >> I see. You might as well leave them, but it probably doesn't matter. >> >> 2. Can I assume that all other dependencies are really needed? (Eclipse >>> won't complain about unused ones as far as I know.) >>> >> >> That seems best. >> >> 3. What are the formatting standards for XML (indentation, line >>> length...)? From a quick look I see different styles in different files. >>> >> >> For IDE files, we don't worry about formatting. In many cases they are >> auto-generated anyway. >> >> -- Kevin >> >> >>> - Nir >>> >> From kevin.rushforth at oracle.com Thu Jan 25 15:24:36 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 25 Jan 2018 07:24:36 -0800 Subject: JDK-8196130: Eclipse configuration files need to be updated In-Reply-To: References: <5A69E338.8000508@oracle.com> <5A69E455.3010200@oracle.com> Message-ID: <5A69F6B4.3030103@oracle.com> Ah, I see. Then yes, just removing the old ones is fine. As for the larger question, unless there are dependencies on apps, you can assume that the only ones you care about are the ones created by "gradle sdk". -- Kevin Nir Lisker wrote: > So this is why I was asking about the optional stuff: 'graphics' > module has BOTH > > build/resources/jsl-decora > build/resources/jsl-prism > > and > > build/gensrc/jsl-decora > build/gensrc/jsl-prism > > That led me to think that when the new dependencies were added the old > ones weren't removed. Those that weren't optional (like the /resources > ones, which I removed) were easy to catch and we could have finished > here. Those that are optional are not causing trouble even when > missing because they are optional. > > gradle sdk does not create the ones which are marked optional that > Iv'e surveyed, but I don't know if that's the only way they can be > created. If I compare solely with gradle sdk then I can just remove > whatever is missing on grounds that it's left over. > > - Nir > > On Thu, Jan 25, 2018 at 4:06 PM, Kevin Rushforth > > wrote: > > One more thing about the specific path you mentioned as not being > there. > > path="build/resources/jsl-decora"/> > path="build/resources/jsl-prism"/> > > These are still being created by 'gradle sdk', but the path is > wrong (the files moved in JDK 9) and should be: > > build/gensrc/jsl-decora > build/gensrc/jsl-prism > > You might want to take that into account. > > -- Kevin > > > > Kevin Rushforth wrote: > > > > Nir Lisker wrote: > > Iv'e removed all the classpath dependencies that were > causing errors. I don't mind sorting out the rest of the > files while at it, though for that there are a few things > I'm not sure about: > > 1. Some dependencies are marked as optional and as such > they don't cause errors, but they are still missing. Is it > safe to remove them or is it possible that they will be > created as some point? > > > Some of them might be created...not sure without checking. I > recommend running "gradle sdk" and then seeing if the > dependencies are there. > > Examples are the 'base' module with "src/test/resources" > and "src/main/resources" optional dependencies, and > 'controls' module has the optional dependency > "src/main/resources" commented out. > > > I see. You might as well leave them, but it probably doesn't > matter. > > 2. Can I assume that all other dependencies are really > needed? (Eclipse won't complain about unused ones as far > as I know.) > > > That seems best. > > 3. What are the formatting standards for XML (indentation, > line length...)? From a quick look I see different styles > in different files. > > > For IDE files, we don't worry about formatting. In many cases > they are auto-generated anyway. > > -- Kevin > > > - Nir > > From johan.vos at gluonhq.com Thu Jan 25 15:36:18 2018 From: johan.vos at gluonhq.com (Johan Vos) Date: Thu, 25 Jan 2018 15:36:18 +0000 Subject: lipjpeg7 in static library In-Reply-To: <5A68C0FB.9020004@oracle.com> References: <35152583-ac8f-feb4-6ffe-9267ca28d626@oracle.com> <5A68C0FB.9020004@oracle.com> Message-ID: At the risk of being stupid, but I don't see how I could make the JPEG symbols invisible, as they are still needed by the native functions in javafx_iio (in jpegloader.c). If they are invisible, jpegloader.o won't be able to access them either, no? In the end, we link all static libs + object files in a single executable. If they were in the same file as jpegloader, I would make them static so they wouldn't be exported, but I don't know how I can make those symbols available to jpegloader.c without exporting them? - Johan On Wed, Jan 24, 2018 at 6:24 PM Kevin Rushforth wrote: > Hiding the symbols seems like a better solution than shipping two > binaries, and is probably easier than mangling the symbols. > > -- Kevin > > > Phil Race wrote: > > Does libjavafx_iio.a really need to export the JPEG symbols ? > > On Windows, or Linux, or Solaris .. there are ways > > to limit the exported symbols from a library. > > > > I found this page for macos : > > > > > https://developer.apple.com/library/content/documentation/MacOSX/Conceptual/BPFrameworks/Tasks/ExportingInterfaces.html > > > > > > Not a complete answer but maybe somewhere to start. > > > > -phil. > > > > On 01/24/2018 02:42 AM, Johan Vos wrote: > >> Hi, > >> > >> We are currently building a native library for javafx_iio which includes > >> libjpeg7. As a consequence, those symbols are included in the static > >> libjavafx_iio.a on iOS. If we add other libraries (e.g. OpenCV) this can > >> result in duplicate symbols, as the libjpeg7 library might be > >> included in > >> other frameworks as well. > >> > >> As a dirty hack, I build 2 versions of libjavafx_iio.a: one with > >> libjpeg7, > >> and one without. A better solution might be to prefix the symbols in the > >> libjpeg7 files. > >> > >> Or are there better ideas? > >> > >> Thanks, > >> > >> - Johan > > > From kevin.rushforth at oracle.com Thu Jan 25 15:41:13 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 25 Jan 2018 07:41:13 -0800 Subject: lipjpeg7 in static library In-Reply-To: References: <35152583-ac8f-feb4-6ffe-9267ca28d626@oracle.com> <5A68C0FB.9020004@oracle.com> Message-ID: <5A69FA99.9040004@oracle.com> > In the end, we link all static libs + object files in a single executable. I see. I had missed that you said "libjavafx_iio.a", meaning static linking. No, I don't know how to make that work, either. Name mangling might be the best solution then. -- Kevin Johan Vos wrote: > At the risk of being stupid, but I don't see how I could make the JPEG > symbols invisible, as they are still needed by the native functions in > javafx_iio (in jpegloader.c). > If they are invisible, jpegloader.o won't be able to access them > either, no? In the end, we link all static libs + object files in a > single executable. > If they were in the same file as jpegloader, I would make them static > so they wouldn't be exported, but I don't know how I can make those > symbols available to jpegloader.c without exporting them? > > - Johan > > On Wed, Jan 24, 2018 at 6:24 PM Kevin Rushforth > > wrote: > > Hiding the symbols seems like a better solution than shipping two > binaries, and is probably easier than mangling the symbols. > > -- Kevin > > > Phil Race wrote: > > Does libjavafx_iio.a really need to export the JPEG symbols ? > > On Windows, or Linux, or Solaris .. there are ways > > to limit the exported symbols from a library. > > > > I found this page for macos : > > > > > https://developer.apple.com/library/content/documentation/MacOSX/Conceptual/BPFrameworks/Tasks/ExportingInterfaces.html > > > > > > Not a complete answer but maybe somewhere to start. > > > > -phil. > > > > On 01/24/2018 02:42 AM, Johan Vos wrote: > >> Hi, > >> > >> We are currently building a native library for javafx_iio which > includes > >> libjpeg7. As a consequence, those symbols are included in the > static > >> libjavafx_iio.a on iOS. If we add other libraries (e.g. OpenCV) > this can > >> result in duplicate symbols, as the libjpeg7 library might be > >> included in > >> other frameworks as well. > >> > >> As a dirty hack, I build 2 versions of libjavafx_iio.a: one with > >> libjpeg7, > >> and one without. A better solution might be to prefix the > symbols in the > >> libjpeg7 files. > >> > >> Or are there better ideas? > >> > >> Thanks, > >> > >> - Johan > > > From nlisker at gmail.com Thu Jan 25 17:51:06 2018 From: nlisker at gmail.com (Nir Lisker) Date: Thu, 25 Jan 2018 19:51:06 +0200 Subject: JDK-8196130: Eclipse configuration files need to be updated In-Reply-To: <5A69F6B4.3030103@oracle.com> References: <5A69E338.8000508@oracle.com> <5A69E455.3010200@oracle.com> <5A69F6B4.3030103@oracle.com> Message-ID: Alright, cleaned that part. fxpackager build fails with an internal NPE in Eclipse, so I'm going to leave that alone and all of the projects that depends on it. Now that projects can be built there are errors in deeper levels: 1. All org.junit imports cannot be resolved. This causes tons of errors in various test folders obviously. All the .classpath files use which is a jar distributed with Eclipse (in the plugins folder) with version 4.12.0. Is this really where the imports are supposed to come from? How does it work in Netbeans or IntelliJ? 2. In the 'base' module, in "/src/main/java-jfr/com/sun/javafx/logging" there are imports of com.oracle.jrockit.jfr that can't be resolved. Where are these located? On Thu, Jan 25, 2018 at 5:24 PM, Kevin Rushforth wrote: > Ah, I see. Then yes, just removing the old ones is fine. > > As for the larger question, unless there are dependencies on apps, you can > assume that the only ones you care about are the ones created by "gradle > sdk". > > -- Kevin > > > > Nir Lisker wrote: > > So this is why I was asking about the optional stuff: 'graphics' module > has BOTH > > build/resources/jsl-decora > build/resources/jsl-prism > > and > > build/gensrc/jsl-decora > build/gensrc/jsl-prism > > That led me to think that when the new dependencies were added the old > ones weren't removed. Those that weren't optional (like the /resources > ones, which I removed) were easy to catch and we could have finished here. > Those that are optional are not causing trouble even when missing because > they are optional. > > gradle sdk does not create the ones which are marked optional that Iv'e > surveyed, but I don't know if that's the only way they can be created. If I > compare solely with gradle sdk then I can just remove whatever is missing > on grounds that it's left over. > > - Nir > > On Thu, Jan 25, 2018 at 4:06 PM, Kevin Rushforth < > kevin.rushforth at oracle.com> wrote: > >> One more thing about the specific path you mentioned as not being there. >> >> >> >> >> These are still being created by 'gradle sdk', but the path is wrong (the >> files moved in JDK 9) and should be: >> >> build/gensrc/jsl-decora >> build/gensrc/jsl-prism >> >> You might want to take that into account. >> >> -- Kevin >> >> >> >> Kevin Rushforth wrote: >> >>> >>> >>> Nir Lisker wrote: >>> >>>> Iv'e removed all the classpath dependencies that were causing errors. I >>>> don't mind sorting out the rest of the files while at it, though for that >>>> there are a few things I'm not sure about: >>>> >>>> 1. Some dependencies are marked as optional and as such they don't >>>> cause errors, but they are still missing. Is it safe to remove them or is >>>> it possible that they will be created as some point? >>>> >>> >>> Some of them might be created...not sure without checking. I recommend >>> running "gradle sdk" and then seeing if the dependencies are there. >>> >>> Examples are the 'base' module with "src/test/resources" and >>>> "src/main/resources" optional dependencies, and 'controls' module has the >>>> optional dependency "src/main/resources" commented out. >>>> >>> >>> I see. You might as well leave them, but it probably doesn't matter. >>> >>> 2. Can I assume that all other dependencies are really needed? (Eclipse >>>> won't complain about unused ones as far as I know.) >>>> >>> >>> That seems best. >>> >>> 3. What are the formatting standards for XML (indentation, line >>>> length...)? From a quick look I see different styles in different files. >>>> >>> >>> For IDE files, we don't worry about formatting. In many cases they are >>> auto-generated anyway. >>> >>> -- Kevin >>> >>> >>>> - Nir >>>> >>> > From kevin.rushforth at oracle.com Thu Jan 25 19:18:20 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 25 Jan 2018 11:18:20 -0800 Subject: [11] Review request: 8195801: Replace jdk.internal.misc.Unsafe with sun.misc.Unsafe in MarlinFX Message-ID: <5A6A2D7C.7010606@oracle.com> Hi Laurent and Phil, Please review the following fix: https://bugs.openjdk.java.net/browse/JDK-8195801 http://cr.openjdk.java.net/~kcr/8195801/webrev.00/ This removes the dependency on the internal jdk.internal.misc.Unsafe class, and goes back to using sun.misc.Unsafe, which is still available publicly as one of the critical APIs identified in JEP 260 [1]. This fix is one part of a larger effort to reduce the usage of internal APIs [2]. -- Kevin [1] http://openjdk.java.net/jeps/260 [2] https://bugs.openjdk.java.net/browse/JDK-8195798 From kevin.rushforth at oracle.com Fri Jan 26 19:20:59 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 26 Jan 2018 11:20:59 -0800 Subject: JDK-8196130: Eclipse configuration files need to be updated In-Reply-To: References: <5A69E338.8000508@oracle.com> <5A69E455.3010200@oracle.com> <5A69F6B4.3030103@oracle.com> Message-ID: <5A6B7F9B.5030103@oracle.com> inline Nir Lisker wrote: > Alright, cleaned that part. fxpackager build fails with an internal > NPE in Eclipse, so I'm going to leave that alone and all of the > projects that depends on it. > > Now that projects can be built there are errors in deeper levels: > > 1. All org.junit imports cannot be resolved. This causes tons of > errors in various test folders obviously. All the .classpath files use > > path="org.eclipse.jdt.junit.JUNIT_CONTAINER/4"/> > > which is a jar distributed with Eclipse (in the plugins folder) with > version 4.12.0. Is this really where the imports are supposed to come > from? How does it work in Netbeans or IntelliJ? For NetBeans we use their internal version of JUnit. I don't know about IntelliJ (maybe someone else on the list can answer that). > 2. In the 'base' module, in > "/src/main/java-jfr/com/sun/javafx/logging" there are imports of > com.oracle.jrockit.jfr that can't be resolved. Where are these located? These classes used to be part of the JFR commercial feature in the Oracle JDK. The java-jfr sources are obsolete and no longer built (and no longer buildable), so you can safely remove it from your IDE files. I also still see references to it in the netbeans/base project. I will file a bug to remove this obsolete code and fix the NetBeans references at the same time. -- Kevin > On Thu, Jan 25, 2018 at 5:24 PM, Kevin Rushforth > > wrote: > > Ah, I see. Then yes, just removing the old ones is fine. > > As for the larger question, unless there are dependencies on apps, > you can assume that the only ones you care about are the ones > created by "gradle sdk". > > -- Kevin > > > > Nir Lisker wrote: >> So this is why I was asking about the optional stuff: 'graphics' >> module has BOTH >> >> build/resources/jsl-decora >> build/resources/jsl-prism >> >> and >> >> build/gensrc/jsl-decora >> build/gensrc/jsl-prism >> >> That led me to think that when the new dependencies were added >> the old ones weren't removed. Those that weren't optional >> (like the /resources ones, which I removed) were easy to catch >> and we could have finished here. Those that are optional are not >> causing trouble even when missing because they are optional. >> >> gradle sdk does not create the ones which are marked optional >> that Iv'e surveyed, but I don't know if that's the only way they >> can be created. If I compare solely with gradle sdk then I can >> just remove whatever is missing on grounds that it's left over. >> >> - Nir >> >> On Thu, Jan 25, 2018 at 4:06 PM, Kevin Rushforth >> > >> wrote: >> >> One more thing about the specific path you mentioned as not >> being there. >> >> > path="build/resources/jsl-decora"/> >> > path="build/resources/jsl-prism"/> >> >> These are still being created by 'gradle sdk', but the path >> is wrong (the files moved in JDK 9) and should be: >> >> build/gensrc/jsl-decora >> build/gensrc/jsl-prism >> >> You might want to take that into account. >> >> -- Kevin >> >> >> >> Kevin Rushforth wrote: >> >> >> >> Nir Lisker wrote: >> >> Iv'e removed all the classpath dependencies that were >> causing errors. I don't mind sorting out the rest of >> the files while at it, though for that there are a >> few things I'm not sure about: >> >> 1. Some dependencies are marked as optional and as >> such they don't cause errors, but they are still >> missing. Is it safe to remove them or is it possible >> that they will be created as some point? >> >> >> Some of them might be created...not sure without >> checking. I recommend running "gradle sdk" and then >> seeing if the dependencies are there. >> >> Examples are the 'base' module with >> "src/test/resources" and "src/main/resources" >> optional dependencies, and 'controls' module has the >> optional dependency "src/main/resources" commented out. >> >> >> I see. You might as well leave them, but it probably >> doesn't matter. >> >> 2. Can I assume that all other dependencies are >> really needed? (Eclipse won't complain about unused >> ones as far as I know.) >> >> >> That seems best. >> >> 3. What are the formatting standards for XML >> (indentation, line length...)? From a quick look I >> see different styles in different files. >> >> >> For IDE files, we don't worry about formatting. In many >> cases they are auto-generated anyway. >> >> -- Kevin >> >> >> - Nir >> >> > From nlisker at gmail.com Sat Jan 27 22:48:27 2018 From: nlisker at gmail.com (Nir Lisker) Date: Sun, 28 Jan 2018 00:48:27 +0200 Subject: JDK-8196130: Eclipse configuration files need to be updated In-Reply-To: <5A6B7F9B.5030103@oracle.com> References: <5A69E338.8000508@oracle.com> <5A69E455.3010200@oracle.com> <5A69F6B4.3030103@oracle.com> <5A6B7F9B.5030103@oracle.com> Message-ID: Another question: do imports of javafx.* packages point to the javafx source or to the jdk compilation? For example, in the base module, the type test.javafx.beans.InvalidationListenerMock imports javafx.beans.InvalidationListener (twice, by the way, along with Observable). Should the imported class be the one in "rt\modules\javafx.base\src\main\java\javafx\beans\InvalidationListener.java" or the one in "jdk\modules\javafx.base\javafx\beans\InvalidationListener.class"? Currently, the way it is in the Eclipse files is that the jdk .class files are imported first[1], but it seemed odd to me - if I work on 2 files which depend on each other they should see the changes in each other at once. [1] http://hg.openjdk.java.net/openjfx/jfx-dev/rt/file/305d127c6ed5/modules/javafx.base/.classpath ("JRE_CONTAINER" is before "src/main/java"), - Nir On Fri, Jan 26, 2018 at 9:20 PM, Kevin Rushforth wrote: > inline > > Nir Lisker wrote: > > Alright, cleaned that part. fxpackager build fails with an internal NPE in > Eclipse, so I'm going to leave that alone and all of the projects that > depends on it. > > Now that projects can be built there are errors in deeper levels: > > 1. All org.junit imports cannot be resolved. This causes tons of errors in > various test folders obviously. All the .classpath files use > > > > which is a jar distributed with Eclipse (in the plugins folder) with > version 4.12.0. Is this really where the imports are supposed to come from? > How does it work in Netbeans or IntelliJ? > > > For NetBeans we use their internal version of JUnit. I don't know about > IntelliJ (maybe someone else on the list can answer that). > > 2. In the 'base' module, in "/src/main/java-jfr/com/sun/javafx/logging" > there are imports of com.oracle.jrockit.jfr that can't be resolved. Where > are these located? > > > These classes used to be part of the JFR commercial feature in the Oracle > JDK. The java-jfr sources are obsolete and no longer built (and no longer > buildable), so you can safely remove it from your IDE files. I also still > see references to it in the netbeans/base project. I will file a bug to > remove this obsolete code and fix the NetBeans references at the same time. > > -- Kevin > > > > On Thu, Jan 25, 2018 at 5:24 PM, Kevin Rushforth < > kevin.rushforth at oracle.com> wrote: > >> Ah, I see. Then yes, just removing the old ones is fine. >> >> As for the larger question, unless there are dependencies on apps, you >> can assume that the only ones you care about are the ones created by >> "gradle sdk". >> >> -- Kevin >> >> >> >> Nir Lisker wrote: >> >> So this is why I was asking about the optional stuff: 'graphics' module >> has BOTH >> >> build/resources/jsl-decora >> build/resources/jsl-prism >> >> and >> >> build/gensrc/jsl-decora >> build/gensrc/jsl-prism >> >> That led me to think that when the new dependencies were added the old >> ones weren't removed. Those that weren't optional (like the /resources >> ones, which I removed) were easy to catch and we could have finished here. >> Those that are optional are not causing trouble even when missing because >> they are optional. >> >> gradle sdk does not create the ones which are marked optional that Iv'e >> surveyed, but I don't know if that's the only way they can be created. If I >> compare solely with gradle sdk then I can just remove whatever is missing >> on grounds that it's left over. >> >> - Nir >> >> On Thu, Jan 25, 2018 at 4:06 PM, Kevin Rushforth < >> kevin.rushforth at oracle.com> wrote: >> >>> One more thing about the specific path you mentioned as not being there. >>> >>> >>> >>> >>> These are still being created by 'gradle sdk', but the path is wrong >>> (the files moved in JDK 9) and should be: >>> >>> build/gensrc/jsl-decora >>> build/gensrc/jsl-prism >>> >>> You might want to take that into account. >>> >>> -- Kevin >>> >>> >>> >>> Kevin Rushforth wrote: >>> >>>> >>>> >>>> Nir Lisker wrote: >>>> >>>>> Iv'e removed all the classpath dependencies that were causing errors. >>>>> I don't mind sorting out the rest of the files while at it, though for that >>>>> there are a few things I'm not sure about: >>>>> >>>>> 1. Some dependencies are marked as optional and as such they don't >>>>> cause errors, but they are still missing. Is it safe to remove them or is >>>>> it possible that they will be created as some point? >>>>> >>>> >>>> Some of them might be created...not sure without checking. I recommend >>>> running "gradle sdk" and then seeing if the dependencies are there. >>>> >>>> Examples are the 'base' module with "src/test/resources" and >>>>> "src/main/resources" optional dependencies, and 'controls' module has the >>>>> optional dependency "src/main/resources" commented out. >>>>> >>>> >>>> I see. You might as well leave them, but it probably doesn't matter. >>>> >>>> 2. Can I assume that all other dependencies are really needed? (Eclipse >>>>> won't complain about unused ones as far as I know.) >>>>> >>>> >>>> That seems best. >>>> >>>> 3. What are the formatting standards for XML (indentation, line >>>>> length...)? From a quick look I see different styles in different files. >>>>> >>>> >>>> For IDE files, we don't worry about formatting. In many cases they are >>>> auto-generated anyway. >>>> >>>> -- Kevin >>>> >>>> >>>>> - Nir >>>>> >>>> >> > From ajit.ghaisas at oracle.com Mon Jan 29 08:58:53 2018 From: ajit.ghaisas at oracle.com (Ajit Ghaisas) Date: Mon, 29 Jan 2018 00:58:53 -0800 (PST) Subject: [8u-backport] Review request : JDK-8193494 : Add a regression test case for JDK-8183100 Message-ID: <790a6f6e-1fae-4991-ab42-7852bd7e4c6d@default> Hi, Request you to review following 8u backport : Issue : https://bugs.openjdk.java.net/browse/JDK-8193494 Fix : http://cr.openjdk.java.net/~aghaisas/fx/8193494/8u/webrev.0/ Regards, Ajit From kevin.rushforth at oracle.com Tue Jan 30 03:04:24 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 29 Jan 2018 19:04:24 -0800 Subject: JDK-8196130: Eclipse configuration files need to be updated In-Reply-To: References: <5A69E338.8000508@oracle.com> <5A69E455.3010200@oracle.com> <5A69F6B4.3030103@oracle.com> <5A6B7F9B.5030103@oracle.com> Message-ID: <5A6FE0B8.1000903@oracle.com> > one in > "rt\modules\javafx.base\src\main\java\javafx\beans\InvalidationListener.java" > or the one in > "jdk\modules\javafx.base\javafx\beans\InvalidationListener.class"? Not sure I get what you mean. There isn't a jdk/modules/ directory created by the build. Perhaps this is an Eclipse construct that it uses to indicate the modules that are in the JDK that you are using? The FX build puts the class files in: rt/build/modular_sdk/modules/javafx.base/... -- Kevin Nir Lisker wrote: > Another question: do imports of javafx.* packages point to the javafx > source or to the jdk compilation? > > For example, in the base module, the type > test.javafx.beans.InvalidationListenerMock > imports javafx.beans.InvalidationListener (twice, by the way, along > with Observable). Should the imported class be the one in > "rt\modules\javafx.base\src\main\java\javafx\beans\InvalidationListener.java" > or the one in > "jdk\modules\javafx.base\javafx\beans\InvalidationListener.class"? > > Currently, the way it is in the Eclipse files is that the jdk .class > files are imported first[1], but it seemed odd to me - if I work on 2 > files which depend on each other they should see the changes in each > other at once. > > [1]http://hg.openjdk.java.net/openjfx/jfx-dev/rt/file/305d127c6ed5/modules/javafx.base/.classpath > ("JRE_CONTAINER" is before "src/main/java"), > > - Nir > > On Fri, Jan 26, 2018 at 9:20 PM, Kevin Rushforth > > wrote: > > inline > > Nir Lisker wrote: >> Alright, cleaned that part. fxpackager build fails with an >> internal NPE in Eclipse, so I'm going to leave that alone and all >> of the projects that depends on it. >> >> Now that projects can be built there are errors in deeper levels: >> >> 1. All org.junit imports cannot be resolved. This causes tons of >> errors in various test folders obviously. All the .classpath >> files use >> >> > path="org.eclipse.jdt.junit.JUNIT_CONTAINER/4"/> >> >> which is a jar distributed with Eclipse (in the plugins folder) >> with version 4.12.0. Is this really where the imports are >> supposed to come from? How does it work in Netbeans or IntelliJ? > > For NetBeans we use their internal version of JUnit. I don't know > about IntelliJ (maybe someone else on the list can answer that). > >> 2. In the 'base' module, in >> "/src/main/java-jfr/com/sun/javafx/logging" there are imports of >> com.oracle.jrockit.jfr that can't be resolved. Where are these >> located? > > These classes used to be part of the JFR commercial feature in the > Oracle JDK. The java-jfr sources are obsolete and no longer built > (and no longer buildable), so you can safely remove it from your > IDE files. I also still see references to it in the netbeans/base > project. I will file a bug to remove this obsolete code and fix > the NetBeans references at the same time. > > -- Kevin > > > >> On Thu, Jan 25, 2018 at 5:24 PM, Kevin Rushforth >> > >> wrote: >> >> Ah, I see. Then yes, just removing the old ones is fine. >> >> As for the larger question, unless there are dependencies on >> apps, you can assume that the only ones you care about are >> the ones created by "gradle sdk". >> >> -- Kevin >> >> >> >> Nir Lisker wrote: >>> So this is why I was asking about the optional stuff: >>> 'graphics' module has BOTH >>> >>> build/resources/jsl-decora >>> build/resources/jsl-prism >>> >>> and >>> >>> build/gensrc/jsl-decora >>> build/gensrc/jsl-prism >>> >>> That led me to think that when the new dependencies were >>> added the old ones weren't removed. Those that weren't >>> optional (like the /resources ones, which I removed) were >>> easy to catch and we could have finished here. Those that >>> are optional are not causing trouble even when missing >>> because they are optional. >>> >>> gradle sdk does not create the ones which are marked >>> optional that Iv'e surveyed, but I don't know if that's the >>> only way they can be created. If I compare solely with >>> gradle sdk then I can just remove whatever is missing on >>> grounds that it's left over. >>> >>> - Nir >>> >>> On Thu, Jan 25, 2018 at 4:06 PM, Kevin Rushforth >>> >> > wrote: >>> >>> One more thing about the specific path you mentioned as >>> not being there. >>> >>> >> path="build/resources/jsl-decora"/> >>> >> path="build/resources/jsl-prism"/> >>> >>> These are still being created by 'gradle sdk', but the >>> path is wrong (the files moved in JDK 9) and should be: >>> >>> build/gensrc/jsl-decora >>> build/gensrc/jsl-prism >>> >>> You might want to take that into account. >>> >>> -- Kevin >>> >>> >>> >>> Kevin Rushforth wrote: >>> >>> >>> >>> Nir Lisker wrote: >>> >>> Iv'e removed all the classpath dependencies that >>> were causing errors. I don't mind sorting out >>> the rest of the files while at it, though for >>> that there are a few things I'm not sure about: >>> >>> 1. Some dependencies are marked as optional and >>> as such they don't cause errors, but they are >>> still missing. Is it safe to remove them or is >>> it possible that they will be created as some point? >>> >>> >>> Some of them might be created...not sure without >>> checking. I recommend running "gradle sdk" and then >>> seeing if the dependencies are there. >>> >>> Examples are the 'base' module with >>> "src/test/resources" and "src/main/resources" >>> optional dependencies, and 'controls' module has >>> the optional dependency "src/main/resources" >>> commented out. >>> >>> >>> I see. You might as well leave them, but it probably >>> doesn't matter. >>> >>> 2. Can I assume that all other dependencies are >>> really needed? (Eclipse won't complain about >>> unused ones as far as I know.) >>> >>> >>> That seems best. >>> >>> 3. What are the formatting standards for XML >>> (indentation, line length...)? From a quick look >>> I see different styles in different files. >>> >>> >>> For IDE files, we don't worry about formatting. In >>> many cases they are auto-generated anyway. >>> >>> -- Kevin >>> >>> >>> - Nir >>> >>> >> > From guru.hb at oracle.com Tue Jan 30 03:47:38 2018 From: guru.hb at oracle.com (Guru) Date: Tue, 30 Jan 2018 09:17:38 +0530 Subject: [8u] Review request: 8196374: windows x86 webview-icu isAlphaNumericString crash Message-ID: <6EF34F34-6CA6-4090-A4A9-9D9C8180098E@oracle.com> Hi Arun & Murali, Please review the fix for JBS : https://bugs.openjdk.java.net/browse/JDK-8196374 Webrev : http://cr.openjdk.java.net/~ghb/8196374/webrev.00/ RC and solution updated in JBS. Thanks, Guru From murali.billa at oracle.com Tue Jan 30 05:04:09 2018 From: murali.billa at oracle.com (Murali Billa) Date: Mon, 29 Jan 2018 21:04:09 -0800 (PST) Subject: [11] Review request for 8195804: Remove unused qualified export of sun.net.www from java.base to javafx.web Message-ID: <222460fd-27f1-4b9f-a11a-9a549ad18c4b@default> ? Hi Kevin, Arun Please review the below simple fix. JIRA: https://bugs.openjdk.java.net/browse/JDK-8195804 ? Webrev: http://cr.openjdk.java.net/~mbilla/8195804/webrev.00/ Thanks, Murali From nlisker at gmail.com Tue Jan 30 07:52:29 2018 From: nlisker at gmail.com (Nir Lisker) Date: Tue, 30 Jan 2018 09:52:29 +0200 Subject: JDK-8196130: Eclipse configuration files need to be updated In-Reply-To: <5A6FE0B8.1000903@oracle.com> References: <5A69E338.8000508@oracle.com> <5A69E455.3010200@oracle.com> <5A69F6B4.3030103@oracle.com> <5A6B7F9B.5030103@oracle.com> <5A6FE0B8.1000903@oracle.com> Message-ID: This is what I mean: In the type /base/src/test/java/test/com/sun/javafx/collections/ListListenerHelperTest.java there are these imports: import test.javafx.collections.MockListObserver; import java.util.BitSet; import javafx.beans.Observable; The first one is the one in FX: rt\modules\javafx.base\src\test\java\test\javafx\collections\MockListObserver.java The second one is in the referenced JDK which was built with FX: jdk\modules\java.base\java\util\BitSet.class The third one exists in both: - in JFX it's in: rt\modules\javafx.base\src\main\java\javafx\beans\Observable.java - in the JDK it's in: jdk\modules\javafx.base\javafx\beans\Observable.class Does the question make sense now? On Tue, Jan 30, 2018 at 5:04 AM, Kevin Rushforth wrote: > > one in "rt\modules\javafx.base\src\main\java\javafx\beans\InvalidationListener.java" > or the one in "jdk\modules\javafx.base\javafx\beans\ > InvalidationListener.class"? > > > Not sure I get what you mean. There isn't a jdk/modules/ directory created > by the build. Perhaps this is an Eclipse construct that it uses to indicate > the modules that are in the JDK that you are using? The FX build puts the > class files in: > > rt/build/modular_sdk/modules/javafx.base/... > > > -- Kevin > > > Nir Lisker wrote: > > Another question: do imports of javafx.* packages point to the javafx > source or to the jdk compilation? > > For example, in the base module, the type test.javafx.beans.InvalidationListenerMock > imports javafx.beans.InvalidationListener (twice, by the way, along with > Observable). Should the imported class be the one in > "rt\modules\javafx.base\src\main\java\javafx\beans\InvalidationListener.java" > or the one in "jdk\modules\javafx.base\javafx\beans\ > InvalidationListener.class"? > > Currently, the way it is in the Eclipse files is that the jdk .class files > are imported first[1], but it seemed odd to me - if I work on 2 files which > depend on each other they should see the changes in each other at once. > > [1]http://hg.openjdk.java.net/openjfx/jfx-dev/rt/file/ > 305d127c6ed5/modules/javafx.base/.classpath ("JRE_CONTAINER" is before > "src/main/java"), > > - Nir > > On Fri, Jan 26, 2018 at 9:20 PM, Kevin Rushforth < > kevin.rushforth at oracle.com> wrote: > >> inline >> >> Nir Lisker wrote: >> >> Alright, cleaned that part. fxpackager build fails with an internal NPE >> in Eclipse, so I'm going to leave that alone and all of the projects that >> depends on it. >> >> Now that projects can be built there are errors in deeper levels: >> >> 1. All org.junit imports cannot be resolved. This causes tons of errors >> in various test folders obviously. All the .classpath files use >> >> >> >> which is a jar distributed with Eclipse (in the plugins folder) with >> version 4.12.0. Is this really where the imports are supposed to come from? >> How does it work in Netbeans or IntelliJ? >> >> >> For NetBeans we use their internal version of JUnit. I don't know about >> IntelliJ (maybe someone else on the list can answer that). >> >> 2. In the 'base' module, in "/src/main/java-jfr/com/sun/javafx/logging" >> there are imports of com.oracle.jrockit.jfr that can't be resolved. Where >> are these located? >> >> >> These classes used to be part of the JFR commercial feature in the Oracle >> JDK. The java-jfr sources are obsolete and no longer built (and no longer >> buildable), so you can safely remove it from your IDE files. I also still >> see references to it in the netbeans/base project. I will file a bug to >> remove this obsolete code and fix the NetBeans references at the same time. >> >> -- Kevin >> >> >> >> On Thu, Jan 25, 2018 at 5:24 PM, Kevin Rushforth < >> kevin.rushforth at oracle.com> wrote: >> >>> Ah, I see. Then yes, just removing the old ones is fine. >>> >>> As for the larger question, unless there are dependencies on apps, you >>> can assume that the only ones you care about are the ones created by >>> "gradle sdk". >>> >>> -- Kevin >>> >>> >>> >>> Nir Lisker wrote: >>> >>> So this is why I was asking about the optional stuff: 'graphics' module >>> has BOTH >>> >>> build/resources/jsl-decora >>> build/resources/jsl-prism >>> >>> and >>> >>> build/gensrc/jsl-decora >>> build/gensrc/jsl-prism >>> >>> That led me to think that when the new dependencies were added the old >>> ones weren't removed. Those that weren't optional (like the /resources >>> ones, which I removed) were easy to catch and we could have finished here. >>> Those that are optional are not causing trouble even when missing because >>> they are optional. >>> >>> gradle sdk does not create the ones which are marked optional that Iv'e >>> surveyed, but I don't know if that's the only way they can be created. If I >>> compare solely with gradle sdk then I can just remove whatever is missing >>> on grounds that it's left over. >>> >>> - Nir >>> >>> On Thu, Jan 25, 2018 at 4:06 PM, Kevin Rushforth < >>> kevin.rushforth at oracle.com> wrote: >>> >>>> One more thing about the specific path you mentioned as not being there. >>>> >>>> >>> path="build/resources/jsl-decora"/> >>>> >>> path="build/resources/jsl-prism"/> >>>> >>>> These are still being created by 'gradle sdk', but the path is wrong >>>> (the files moved in JDK 9) and should be: >>>> >>>> build/gensrc/jsl-decora >>>> build/gensrc/jsl-prism >>>> >>>> You might want to take that into account. >>>> >>>> -- Kevin >>>> >>>> >>>> >>>> Kevin Rushforth wrote: >>>> >>>>> >>>>> >>>>> Nir Lisker wrote: >>>>> >>>>>> Iv'e removed all the classpath dependencies that were causing errors. >>>>>> I don't mind sorting out the rest of the files while at it, though for that >>>>>> there are a few things I'm not sure about: >>>>>> >>>>>> 1. Some dependencies are marked as optional and as such they don't >>>>>> cause errors, but they are still missing. Is it safe to remove them or is >>>>>> it possible that they will be created as some point? >>>>>> >>>>> >>>>> Some of them might be created...not sure without checking. I recommend >>>>> running "gradle sdk" and then seeing if the dependencies are there. >>>>> >>>>> Examples are the 'base' module with "src/test/resources" and >>>>>> "src/main/resources" optional dependencies, and 'controls' module has the >>>>>> optional dependency "src/main/resources" commented out. >>>>>> >>>>> >>>>> I see. You might as well leave them, but it probably doesn't matter. >>>>> >>>>> 2. Can I assume that all other dependencies are really needed? >>>>>> (Eclipse won't complain about unused ones as far as I know.) >>>>>> >>>>> >>>>> That seems best. >>>>> >>>>> 3. What are the formatting standards for XML (indentation, line >>>>>> length...)? From a quick look I see different styles in different files. >>>>>> >>>>> >>>>> For IDE files, we don't worry about formatting. In many cases they are >>>>> auto-generated anyway. >>>>> >>>>> -- Kevin >>>>> >>>>> >>>>>> - Nir >>>>>> >>>>> >>> >> > From kevin.rushforth at oracle.com Tue Jan 30 19:03:42 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 30 Jan 2018 11:03:42 -0800 Subject: JDK-8196130: Eclipse configuration files need to be updated In-Reply-To: References: <5A69E338.8000508@oracle.com> <5A69E455.3010200@oracle.com> <5A69F6B4.3030103@oracle.com> <5A6B7F9B.5030103@oracle.com> <5A6FE0B8.1000903@oracle.com> Message-ID: <5A70C18E.30805@oracle.com> Oh, I see. You are pointing to the exploded modules for the JDK in build/XXXXX/jdk rather than the JDK image in build/XXXXX/images/jdk. Yes, I think it would be preferable to both reverse the order and also add in the location of the built class files. So the following order seems best: rt/modules/javafx.base/build/classes/main/javafx.base/ rt/modules/javafx.base/src/main/java/ jdk/modules/javafx.base -- Kevin Nir Lisker wrote: > This is what I mean: In the > type /base/src/test/java/test/com/sun/javafx/collections/ListListenerHelperTest.java > there are these imports: > > import test.javafx.collections.MockListObserver; > import java.util.BitSet; > import javafx.beans.Observable; > > The first one is the one in > FX: rt\modules\javafx.base\src\test\java\test\javafx\collections\MockListObserver.java > The second one is in the referenced JDK which was built with > FX: jdk\modules\java.base\java\util\BitSet.class > The third one exists in both: > - in JFX it's in: > rt\modules\javafx.base\src\main\java\javafx\beans\Observable.java > - in the JDK it's > in: jdk\modules\javafx.base\javafx\beans\Observable.class > > Does the question make sense now? > > On Tue, Jan 30, 2018 at 5:04 AM, Kevin Rushforth > > wrote: > > >> one in >> "rt\modules\javafx.base\src\main\java\javafx\beans\InvalidationListener.java" >> or the one in >> "jdk\modules\javafx.base\javafx\beans\InvalidationListener.class"? > > Not sure I get what you mean. There isn't a jdk/modules/ directory > created by the build. Perhaps this is an Eclipse construct that it > uses to indicate the modules that are in the JDK that you are > using? The FX build puts the class files in: > > rt/build/modular_sdk/modules/javafx.base/... > > > -- Kevin > > > Nir Lisker wrote: >> Another question: do imports of javafx.* packages point to the >> javafx source or to the jdk compilation? >> >> For example, in the base module, the type >> test.javafx.beans.InvalidationListenerMock >> imports javafx.beans.InvalidationListener (twice, by the way, >> along with Observable). Should the imported class be the one in >> "rt\modules\javafx.base\src\main\java\javafx\beans\InvalidationListener.java" >> or the one in >> "jdk\modules\javafx.base\javafx\beans\InvalidationListener.class"? >> >> Currently, the way it is in the Eclipse files is that the jdk >> .class files are imported first[1], but it seemed odd to me - if >> I work on 2 files which depend on each other they should see the >> changes in each other at once. >> >> [1]http://hg.openjdk.java.net/openjfx/jfx-dev/rt/file/305d127c6ed5/modules/javafx.base/.classpath >> >> ("JRE_CONTAINER" is before "src/main/java"), >> >> - Nir >> >> On Fri, Jan 26, 2018 at 9:20 PM, Kevin Rushforth >> > >> wrote: >> >> inline >> >> Nir Lisker wrote: >>> Alright, cleaned that part. fxpackager build fails with an >>> internal NPE in Eclipse, so I'm going to leave that alone >>> and all of the projects that depends on it. >>> >>> Now that projects can be built there are errors in deeper >>> levels: >>> >>> 1. All org.junit imports cannot be resolved. This causes >>> tons of errors in various test folders obviously. All the >>> .classpath files use >>> >>> >> path="org.eclipse.jdt.junit.JUNIT_CONTAINER/4"/> >>> >>> which is a jar distributed with Eclipse (in the plugins >>> folder) with version 4.12.0. Is this really where the >>> imports are supposed to come from? How does it work in >>> Netbeans or IntelliJ? >> >> For NetBeans we use their internal version of JUnit. I don't >> know about IntelliJ (maybe someone else on the list can >> answer that). >> >>> 2. In the 'base' module, in >>> "/src/main/java-jfr/com/sun/javafx/logging" there are >>> imports of com.oracle.jrockit.jfr that can't be resolved. >>> Where are these located? >> >> These classes used to be part of the JFR commercial feature >> in the Oracle JDK. The java-jfr sources are obsolete and no >> longer built (and no longer buildable), so you can safely >> remove it from your IDE files. I also still see references to >> it in the netbeans/base project. I will file a bug to remove >> this obsolete code and fix the NetBeans references at the >> same time. >> >> -- Kevin >> >> >> >>> On Thu, Jan 25, 2018 at 5:24 PM, Kevin Rushforth >>> >> > wrote: >>> >>> Ah, I see. Then yes, just removing the old ones is fine. >>> >>> As for the larger question, unless there are >>> dependencies on apps, you can assume that the only ones >>> you care about are the ones created by "gradle sdk". >>> >>> -- Kevin >>> >>> >>> >>> Nir Lisker wrote: >>>> So this is why I was asking about the optional stuff: >>>> 'graphics' module has BOTH >>>> >>>> build/resources/jsl-decora >>>> build/resources/jsl-prism >>>> >>>> and >>>> >>>> build/gensrc/jsl-decora >>>> build/gensrc/jsl-prism >>>> >>>> That led me to think that when the new dependencies >>>> were added the old ones weren't removed. Those that >>>> weren't optional (like the /resources ones, which I >>>> removed) were easy to catch and we could have finished >>>> here. Those that are optional are not causing trouble >>>> even when missing because they are optional. >>>> >>>> gradle sdk does not create the ones which are marked >>>> optional that Iv'e surveyed, but I don't know if that's >>>> the only way they can be created. If I compare solely >>>> with gradle sdk then I can just remove whatever is >>>> missing on grounds that it's left over. >>>> >>>> - Nir >>>> >>>> On Thu, Jan 25, 2018 at 4:06 PM, Kevin Rushforth >>>> >>> > wrote: >>>> >>>> One more thing about the specific path you >>>> mentioned as not being there. >>>> >>>> >>> path="build/resources/jsl-decora"/> >>>> >>> path="build/resources/jsl-prism"/> >>>> >>>> These are still being created by 'gradle sdk', but >>>> the path is wrong (the files moved in JDK 9) and >>>> should be: >>>> >>>> build/gensrc/jsl-decora >>>> build/gensrc/jsl-prism >>>> >>>> You might want to take that into account. >>>> >>>> -- Kevin >>>> >>>> >>>> >>>> Kevin Rushforth wrote: >>>> >>>> >>>> >>>> Nir Lisker wrote: >>>> >>>> Iv'e removed all the classpath dependencies >>>> that were causing errors. I don't mind >>>> sorting out the rest of the files while at >>>> it, though for that there are a few things >>>> I'm not sure about: >>>> >>>> 1. Some dependencies are marked as optional >>>> and as such they don't cause errors, but >>>> they are still missing. Is it safe to >>>> remove them or is it possible that they >>>> will be created as some point? >>>> >>>> >>>> Some of them might be created...not sure >>>> without checking. I recommend running "gradle >>>> sdk" and then seeing if the dependencies are there. >>>> >>>> Examples are the 'base' module with >>>> "src/test/resources" and >>>> "src/main/resources" optional dependencies, >>>> and 'controls' module has the optional >>>> dependency "src/main/resources" commented out. >>>> >>>> >>>> I see. You might as well leave them, but it >>>> probably doesn't matter. >>>> >>>> 2. Can I assume that all other dependencies >>>> are really needed? (Eclipse won't complain >>>> about unused ones as far as I know.) >>>> >>>> >>>> That seems best. >>>> >>>> 3. What are the formatting standards for >>>> XML (indentation, line length...)? From a >>>> quick look I see different styles in >>>> different files. >>>> >>>> >>>> For IDE files, we don't worry about formatting. >>>> In many cases they are auto-generated anyway. >>>> >>>> -- Kevin >>>> >>>> >>>> - Nir >>>> >>>> >>> >> > From nlisker at gmail.com Wed Jan 31 04:44:19 2018 From: nlisker at gmail.com (Nir Lisker) Date: Wed, 31 Jan 2018 06:44:19 +0200 Subject: JDK-8196130: Eclipse configuration files need to be updated In-Reply-To: <5A70C18E.30805@oracle.com> References: <5A69E338.8000508@oracle.com> <5A69E455.3010200@oracle.com> <5A69F6B4.3030103@oracle.com> <5A6B7F9B.5030103@oracle.com> <5A6FE0B8.1000903@oracle.com> <5A70C18E.30805@oracle.com> Message-ID: > > rt/modules/javafx.base/build/classes/main/javafx.base/ > rt/modules/javafx.base/src/main/java/ Why not rely on source first? Another question as I move along: there are imports from java.util.logging in base module, but the module-info doesn't require java.logging. How do I give access to these imports? On Tue, Jan 30, 2018 at 9:03 PM, Kevin Rushforth wrote: > Oh, I see. You are pointing to the exploded modules for the JDK in > build/XXXXX/jdk rather than the JDK image in build/XXXXX/images/jdk. > > Yes, I think it would be preferable to both reverse the order and also add > in the location of the built class files. So the following order seems best: > > rt/modules/javafx.base/build/classes/main/javafx.base/ > rt/modules/javafx.base/src/main/java/ > jdk/modules/javafx.base > > > -- Kevin > > > Nir Lisker wrote: > > This is what I mean: In the type /base/src/test/java/test/ > com/sun/javafx/collections/ListListenerHelperTest.java there are these > imports: > > import test.javafx.collections.MockListObserver; > import java.util.BitSet; > import javafx.beans.Observable; > > The first one is the one in FX: rt\modules\javafx.base\ > src\test\java\test\javafx\collections\MockListObserver.java > The second one is in the referenced JDK which was built with > FX: jdk\modules\java.base\java\util\BitSet.class > The third one exists in both: > - in JFX it's in: rt\modules\javafx.base\src\main\java\javafx\beans\ > Observable.java > - in the JDK it's in: jdk\modules\javafx.base\ > javafx\beans\Observable.class > > Does the question make sense now? > > On Tue, Jan 30, 2018 at 5:04 AM, Kevin Rushforth < > kevin.rushforth at oracle.com> wrote: > >> >> one in "rt\modules\javafx.base\src\main\java\javafx\beans\InvalidationListener.java" >> or the one in "jdk\modules\javafx.base\javafx\beans\InvalidationListener. >> class"? >> >> >> Not sure I get what you mean. There isn't a jdk/modules/ directory >> created by the build. Perhaps this is an Eclipse construct that it uses to >> indicate the modules that are in the JDK that you are using? The FX build >> puts the class files in: >> >> rt/build/modular_sdk/modules/javafx.base/... >> >> >> -- Kevin >> >> >> Nir Lisker wrote: >> >> Another question: do imports of javafx.* packages point to the javafx >> source or to the jdk compilation? >> >> For example, in the base module, the type test.javafx.beans.InvalidationListenerMock >> imports javafx.beans.InvalidationListener (twice, by the way, along with >> Observable). Should the imported class be the one in >> "rt\modules\javafx.base\src\main\java\javafx\beans\InvalidationListener.java" >> or the one in "jdk\modules\javafx.base\javafx\beans\InvalidationListener. >> class"? >> >> Currently, the way it is in the Eclipse files is that the jdk .class >> files are imported first[1], but it seemed odd to me - if I work on 2 files >> which depend on each other they should see the changes in each other at >> once. >> >> [1]http://hg.openjdk.java.net/openjfx/jfx-dev/rt/file/305d12 >> 7c6ed5/modules/javafx.base/.classpath ("JRE_CONTAINER" is before >> "src/main/java"), >> >> - Nir >> >> On Fri, Jan 26, 2018 at 9:20 PM, Kevin Rushforth < >> kevin.rushforth at oracle.com> wrote: >> >>> inline >>> >>> Nir Lisker wrote: >>> >>> Alright, cleaned that part. fxpackager build fails with an internal NPE >>> in Eclipse, so I'm going to leave that alone and all of the projects that >>> depends on it. >>> >>> Now that projects can be built there are errors in deeper levels: >>> >>> 1. All org.junit imports cannot be resolved. This causes tons of errors >>> in various test folders obviously. All the .classpath files use >>> >>> >>> >>> which is a jar distributed with Eclipse (in the plugins folder) with >>> version 4.12.0. Is this really where the imports are supposed to come from? >>> How does it work in Netbeans or IntelliJ? >>> >>> >>> For NetBeans we use their internal version of JUnit. I don't know about >>> IntelliJ (maybe someone else on the list can answer that). >>> >>> 2. In the 'base' module, in "/src/main/java-jfr/com/sun/javafx/logging" >>> there are imports of com.oracle.jrockit.jfr that can't be resolved. Where >>> are these located? >>> >>> >>> These classes used to be part of the JFR commercial feature in the >>> Oracle JDK. The java-jfr sources are obsolete and no longer built (and no >>> longer buildable), so you can safely remove it from your IDE files. I also >>> still see references to it in the netbeans/base project. I will file a bug >>> to remove this obsolete code and fix the NetBeans references at the same >>> time. >>> >>> -- Kevin >>> >>> >>> >>> On Thu, Jan 25, 2018 at 5:24 PM, Kevin Rushforth < >>> kevin.rushforth at oracle.com> wrote: >>> >>>> Ah, I see. Then yes, just removing the old ones is fine. >>>> >>>> As for the larger question, unless there are dependencies on apps, you >>>> can assume that the only ones you care about are the ones created by >>>> "gradle sdk". >>>> >>>> -- Kevin >>>> >>>> >>>> >>>> Nir Lisker wrote: >>>> >>>> So this is why I was asking about the optional stuff: 'graphics' module >>>> has BOTH >>>> >>>> build/resources/jsl-decora >>>> build/resources/jsl-prism >>>> >>>> and >>>> >>>> build/gensrc/jsl-decora >>>> build/gensrc/jsl-prism >>>> >>>> That led me to think that when the new dependencies were added the old >>>> ones weren't removed. Those that weren't optional (like the /resources >>>> ones, which I removed) were easy to catch and we could have finished here. >>>> Those that are optional are not causing trouble even when missing because >>>> they are optional. >>>> >>>> gradle sdk does not create the ones which are marked optional that Iv'e >>>> surveyed, but I don't know if that's the only way they can be created. If I >>>> compare solely with gradle sdk then I can just remove whatever is missing >>>> on grounds that it's left over. >>>> >>>> - Nir >>>> >>>> On Thu, Jan 25, 2018 at 4:06 PM, Kevin Rushforth < >>>> kevin.rushforth at oracle.com> wrote: >>>> >>>>> One more thing about the specific path you mentioned as not being >>>>> there. >>>>> >>>>> >>>> path="build/resources/jsl-decora"/> >>>>> >>>> path="build/resources/jsl-prism"/> >>>>> >>>>> These are still being created by 'gradle sdk', but the path is wrong >>>>> (the files moved in JDK 9) and should be: >>>>> >>>>> build/gensrc/jsl-decora >>>>> build/gensrc/jsl-prism >>>>> >>>>> You might want to take that into account. >>>>> >>>>> -- Kevin >>>>> >>>>> >>>>> >>>>> Kevin Rushforth wrote: >>>>> >>>>>> >>>>>> >>>>>> Nir Lisker wrote: >>>>>> >>>>>>> Iv'e removed all the classpath dependencies that were causing >>>>>>> errors. I don't mind sorting out the rest of the files while at it, though >>>>>>> for that there are a few things I'm not sure about: >>>>>>> >>>>>>> 1. Some dependencies are marked as optional and as such they don't >>>>>>> cause errors, but they are still missing. Is it safe to remove them or is >>>>>>> it possible that they will be created as some point? >>>>>>> >>>>>> >>>>>> Some of them might be created...not sure without checking. I >>>>>> recommend running "gradle sdk" and then seeing if the dependencies are >>>>>> there. >>>>>> >>>>>> Examples are the 'base' module with "src/test/resources" and >>>>>>> "src/main/resources" optional dependencies, and 'controls' module has the >>>>>>> optional dependency "src/main/resources" commented out. >>>>>>> >>>>>> >>>>>> I see. You might as well leave them, but it probably doesn't matter. >>>>>> >>>>>> 2. Can I assume that all other dependencies are really needed? >>>>>>> (Eclipse won't complain about unused ones as far as I know.) >>>>>>> >>>>>> >>>>>> That seems best. >>>>>> >>>>>> 3. What are the formatting standards for XML (indentation, line >>>>>>> length...)? From a quick look I see different styles in different files. >>>>>>> >>>>>> >>>>>> For IDE files, we don't worry about formatting. In many cases they >>>>>> are auto-generated anyway. >>>>>> >>>>>> -- Kevin >>>>>> >>>>>> >>>>>>> - Nir >>>>>>> >>>>>> >>>> >>> >> > From kevin.rushforth at oracle.com Wed Jan 31 14:21:51 2018 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 31 Jan 2018 06:21:51 -0800 Subject: JDK-8196130: Eclipse configuration files need to be updated In-Reply-To: References: <5A69E338.8000508@oracle.com> <5A69E455.3010200@oracle.com> <5A69F6B4.3030103@oracle.com> <5A6B7F9B.5030103@oracle.com> <5A6FE0B8.1000903@oracle.com> <5A70C18E.30805@oracle.com> Message-ID: <5A71D0FF.1040004@oracle.com> Nir Lisker wrote: > > rt/modules/javafx.base/build/classes/main/javafx.base/ > rt/modules/javafx.base/src/main/java/ > > > Why not rely on source first? Yes, that might work...you could try switching the order. > > Another question as I move along: there are imports > from java.util.logging in base module, but the module-info doesn't > require java.logging. How do I give access to these imports? The only references to java.util.logging are in the javafx.base unit tests, which are compiled and run in the unnamed modules (no module-info.java for the unit tests). -- Kevin > On Tue, Jan 30, 2018 at 9:03 PM, Kevin Rushforth > > wrote: > > Oh, I see. You are pointing to the exploded modules for the JDK > in build/XXXXX/jdk rather than the JDK image in > build/XXXXX/images/jdk. > > Yes, I think it would be preferable to both reverse the order and > also add in the location of the built class files. So the > following order seems best: > > rt/modules/javafx.base/build/classes/main/javafx.base/ > rt/modules/javafx.base/src/main/java/ > jdk/modules/javafx.base > > > -- Kevin > > > Nir Lisker wrote: >> This is what I mean: In the >> type /base/src/test/java/test/com/sun/javafx/collections/ListListenerHelperTest.java >> there are these imports: >> >> import test.javafx.collections.MockListObserver; >> import java.util.BitSet; >> import javafx.beans.Observable; >> >> The first one is the one in >> FX: rt\modules\javafx.base\src\test\java\test\javafx\collections\MockListObserver.java >> The second one is in the referenced JDK which was built with >> FX: jdk\modules\java.base\java\util\BitSet.class >> The third one exists in both: >> - in JFX it's in: >> rt\modules\javafx.base\src\main\java\javafx\beans\Observable.java >> - in the JDK it's >> in: jdk\modules\javafx.base\javafx\beans\Observable.class >> >> Does the question make sense now? >> >> On Tue, Jan 30, 2018 at 5:04 AM, Kevin Rushforth >> > >> wrote: >> >> >>> one in >>> "rt\modules\javafx.base\src\main\java\javafx\beans\InvalidationListener.java" >>> or the one in >>> "jdk\modules\javafx.base\javafx\beans\InvalidationListener.class"? >> >> Not sure I get what you mean. There isn't a jdk/modules/ >> directory created by the build. Perhaps this is an Eclipse >> construct that it uses to indicate the modules that are in >> the JDK that you are using? The FX build puts the class files in: >> >> rt/build/modular_sdk/modules/javafx.base/... >> >> >> -- Kevin >> >> >> Nir Lisker wrote: >>> Another question: do imports of javafx.* packages point to >>> the javafx source or to the jdk compilation? >>> >>> For example, in the base module, the type >>> test.javafx.beans.InvalidationListenerMock >>> imports javafx.beans.InvalidationListener (twice, by the >>> way, along with Observable). Should the imported class be >>> the one in >>> "rt\modules\javafx.base\src\main\java\javafx\beans\InvalidationListener.java" >>> or the one in >>> "jdk\modules\javafx.base\javafx\beans\InvalidationListener.class"? >>> >>> Currently, the way it is in the Eclipse files is that the >>> jdk .class files are imported first[1], but it seemed odd to >>> me - if I work on 2 files which depend on each other they >>> should see the changes in each other at once. >>> >>> [1]http://hg.openjdk.java.net/openjfx/jfx-dev/rt/file/305d127c6ed5/modules/javafx.base/.classpath >>> >>> ("JRE_CONTAINER" is before "src/main/java"), >>> >>> - Nir >>> >>> On Fri, Jan 26, 2018 at 9:20 PM, Kevin Rushforth >>> >> > wrote: >>> >>> inline >>> >>> Nir Lisker wrote: >>>> Alright, cleaned that part. fxpackager build fails with >>>> an internal NPE in Eclipse, so I'm going to leave that >>>> alone and all of the projects that depends on it. >>>> >>>> Now that projects can be built there are errors in >>>> deeper levels: >>>> >>>> 1. All org.junit imports cannot be resolved. This >>>> causes tons of errors in various test folders >>>> obviously. All the .classpath files use >>>> >>>> >>> path="org.eclipse.jdt.junit.JUNIT_CONTAINER/4"/> >>>> >>>> which is a jar distributed with Eclipse (in the plugins >>>> folder) with version 4.12.0. Is this really where the >>>> imports are supposed to come from? How does it work in >>>> Netbeans or IntelliJ? >>> >>> For NetBeans we use their internal version of JUnit. I >>> don't know about IntelliJ (maybe someone else on the >>> list can answer that). >>> >>>> 2. In the 'base' module, in >>>> "/src/main/java-jfr/com/sun/javafx/logging" there are >>>> imports of com.oracle.jrockit.jfr that can't be >>>> resolved. Where are these located? >>> >>> These classes used to be part of the JFR commercial >>> feature in the Oracle JDK. The java-jfr sources are >>> obsolete and no longer built (and no longer buildable), >>> so you can safely remove it from your IDE files. I also >>> still see references to it in the netbeans/base project. >>> I will file a bug to remove this obsolete code and fix >>> the NetBeans references at the same time. >>> >>> -- Kevin >>> >>> >>> >>>> On Thu, Jan 25, 2018 at 5:24 PM, Kevin Rushforth >>>> >>> > wrote: >>>> >>>> Ah, I see. Then yes, just removing the old ones is >>>> fine. >>>> >>>> As for the larger question, unless there are >>>> dependencies on apps, you can assume that the only >>>> ones you care about are the ones created by "gradle >>>> sdk". >>>> >>>> -- Kevin >>>> >>>> >>>> >>>> Nir Lisker wrote: >>>>> So this is why I was asking about the optional >>>>> stuff: 'graphics' module has BOTH >>>>> >>>>> build/resources/jsl-decora >>>>> build/resources/jsl-prism >>>>> >>>>> and >>>>> >>>>> build/gensrc/jsl-decora >>>>> build/gensrc/jsl-prism >>>>> >>>>> That led me to think that when the new >>>>> dependencies were added the old ones weren't >>>>> removed. Those that weren't optional (like the >>>>> /resources ones, which I removed) were easy to >>>>> catch and we could have finished here. Those that >>>>> are optional are not causing trouble even when >>>>> missing because they are optional. >>>>> >>>>> gradle sdk does not create the ones which are >>>>> marked optional that Iv'e surveyed, but I don't >>>>> know if that's the only way they can be created. >>>>> If I compare solely with gradle sdk then I can >>>>> just remove whatever is missing on grounds that >>>>> it's left over. >>>>> >>>>> - Nir >>>>> >>>>> On Thu, Jan 25, 2018 at 4:06 PM, Kevin Rushforth >>>>> >>>> > wrote: >>>>> >>>>> One more thing about the specific path you >>>>> mentioned as not being there. >>>>> >>>>> >>>> path="build/resources/jsl-decora"/> >>>>> >>>> path="build/resources/jsl-prism"/> >>>>> >>>>> These are still being created by 'gradle sdk', >>>>> but the path is wrong (the files moved in JDK >>>>> 9) and should be: >>>>> >>>>> build/gensrc/jsl-decora >>>>> build/gensrc/jsl-prism >>>>> >>>>> You might want to take that into account. >>>>> >>>>> -- Kevin >>>>> >>>>> >>>>> >>>>> Kevin Rushforth wrote: >>>>> >>>>> >>>>> >>>>> Nir Lisker wrote: >>>>> >>>>> Iv'e removed all the classpath >>>>> dependencies that were causing errors. >>>>> I don't mind sorting out the rest of >>>>> the files while at it, though for that >>>>> there are a few things I'm not sure about: >>>>> >>>>> 1. Some dependencies are marked as >>>>> optional and as such they don't cause >>>>> errors, but they are still missing. Is >>>>> it safe to remove them or is it >>>>> possible that they will be created as >>>>> some point? >>>>> >>>>> >>>>> Some of them might be created...not sure >>>>> without checking. I recommend running >>>>> "gradle sdk" and then seeing if the >>>>> dependencies are there. >>>>> >>>>> Examples are the 'base' module with >>>>> "src/test/resources" and >>>>> "src/main/resources" optional >>>>> dependencies, and 'controls' module >>>>> has the optional dependency >>>>> "src/main/resources" commented out. >>>>> >>>>> >>>>> I see. You might as well leave them, but >>>>> it probably doesn't matter. >>>>> >>>>> 2. Can I assume that all other >>>>> dependencies are really needed? >>>>> (Eclipse won't complain about unused >>>>> ones as far as I know.) >>>>> >>>>> >>>>> That seems best. >>>>> >>>>> 3. What are the formatting standards >>>>> for XML (indentation, line length...)? >>>>> From a quick look I see different >>>>> styles in different files. >>>>> >>>>> >>>>> For IDE files, we don't worry about >>>>> formatting. In many cases they are >>>>> auto-generated anyway. >>>>> >>>>> -- Kevin >>>>> >>>>> >>>>> - Nir >>>>> >>>>> >>>> >>> >> > From paulrussell70 at gmail.com Wed Jan 31 16:31:55 2018 From: paulrussell70 at gmail.com (Paul Ray Russell) Date: Wed, 31 Jan 2018 16:31:55 +0000 Subject: Community builds Message-ID: Hi OpenJFX - Anyone point me to a community build for Java9 with JavaFX already added? I understand I that i can't just overlay one on the other now? I'm seeking windows right now, but will need to target Linux and Mac in the end. Best, Paul From rajath.kamath at oracle.com Wed Jan 31 18:11:25 2018 From: rajath.kamath at oracle.com (Rajath Kamath) Date: Wed, 31 Jan 2018 10:11:25 -0800 (PST) Subject: [11] Review Request - JDK-8089454: [HTMLEditor] selection removes CENTER alignment Message-ID: Hi, Request to please review this fix in HTMLEditor. Details in JBS. JBS : https://bugs.openjdk.java.net/browse/JDK-8089454 WebRev : HYPERLINK "http://cr.openjdk.java.net/%7Erkamath/8089454/webrev.00/" http://cr.openjdk.java.net/~rkamath/8089454/webrev.00/ Thanks, Rajath