From kevin.rushforth at oracle.com Mon Jun 1 20:36:07 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 01 Jun 2015 13:36:07 -0700 Subject: 8u-dev and 9-dev unlocked following sanity testing Message-ID: <556CC237.6060409@oracle.com> From samir.hadzic.pro at gmail.com Tue Jun 2 08:03:11 2015 From: samir.hadzic.pro at gmail.com (Sam') Date: Tue, 2 Jun 2015 10:03:11 +0200 Subject: Trouble building JDK in debug mode Message-ID: Sorry to create a new post, I have not managed to reply to the other topic since I had deactivated the notifications.. I am building the JDK on Mac. I have specified "CONF=DebugNative" with the case sensitive in the gradle.properties file. You are speaking about -PCONF, but in the gradle I have specified only "CONF" since it was written like that in the comment above.. Finally after that, I'm following the steps specified here ( https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX#BuildingOpenJFX-Overlay-JDK8 ) in order to deploy my JDK. Afterwards, when launching Netbeans, I cannot see the local variables of JavaFX source code and debug it properly. From vadim.pakhnushev at oracle.com Tue Jun 2 09:39:30 2015 From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev) Date: Tue, 02 Jun 2015 12:39:30 +0300 Subject: [8u60, 9] Review request for RT-40632: LineChart.getData.clear() method exception Message-ID: <556D79D2.4000708@oracle.com> Jonathan, Please review the fix: https://javafx-jira.kenai.com/browse/RT-40632 http://cr.openjdk.java.net/~vadim/RT-40632/webrev.00/ Thanks, Vadim From anton.tarasov at oracle.com Tue Jun 2 14:37:46 2015 From: anton.tarasov at oracle.com (Anton V. Tarasov) Date: Tue, 02 Jun 2015 17:37:46 +0300 Subject: [8u60, 9] post-commit notification: RT-40630 [WebView] "outstanding resource locks detected" when playing youtube Message-ID: <556DBFBA.8010709@oracle.com> JIRA: https://javafx-jira.kenai.com/browse/RT-40630 webrev: http://cr.openjdk.java.net/~ant/RT-40630/webrev.0 Thanks, Anton. From vadim.pakhnushev at oracle.com Tue Jun 2 15:25:31 2015 From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev) Date: Tue, 02 Jun 2015 18:25:31 +0300 Subject: [8u60, 9] Review request for RT-46144: Refactor charts tests Message-ID: <556DCAEB.90005@oracle.com> Jonathan, Please review the fix: https://javafx-jira.kenai.com/browse/RT-46144 http://cr.openjdk.java.net/~vadim/RT-46144/webrev.00/ Thanks, Vadim From David.Hill at Oracle.com Tue Jun 2 18:58:12 2015 From: David.Hill at Oracle.com (David Hill) Date: Tue, 02 Jun 2015 14:58:12 -0400 Subject: Review for minimize on GTK. Message-ID: <556DFCC4.9020009@Oracle.com> Kevin, et al, (Note this fixed a regression post 8u20) jira: https://javafx-jira.kenai.com/browse/RT-40261 webrev: http://cr.openjdk.java.net/~ddhill/T-40261 We tell the WindowManager not to support minimization (meaning the window decoration), then we ask it to minimize programmatically. The WM ignores the programmatic request because we just told it too. The screen stops updating because the pulse thinks the window is not showing. Simple fix - remember the window manager functions, and if minimize is not present, enable it, minimize the window, then restore the original value. Tested with transparent & decorated. FullScreen also tested because that is something else we disable, but no negative effect seen. -- David Hill Java Embedded Development "A man's feet should be planted in his country, but his eyes should survey the world." -- George Santayana (1863 - 1952) From james.graham at oracle.com Tue Jun 2 21:04:41 2015 From: james.graham at oracle.com (Jim Graham) Date: Tue, 02 Jun 2015 14:04:41 -0700 Subject: Windows support for HiDPI displays, call for feedback and testing Message-ID: <556E1A69.2050309@oracle.com> https://jdk8.java.net/download.html The 8u60 b17 build should now contain changes recently made to support HiDPI displays on Windows. This will probably be most visible on laptops where the advertised DPI has been climbing in recent years. The main thing you might notice is that your windows and controls may (often) be larger than previously. Since we were already scaling the default font by the DPI, then any control whose sizing was based on CSS "em" measurements will already have been as large as it should have been and if your window and set of controls were all 100% sized that way then you will not see much difference. But, other size measurements and any other rendering not based on the default font or its "em" size will now be scaled to match. One common way for applications to be affected is when they had their Scene/Stage sized using raw numbers. We had been interpreting those sizes as pixels in Windows even if you had a 192DPI or higher display. If anything, this new support might fix a number of layout issues you may have been experiencing - in particular a number of tabs in Ensemble8 now have much more sensible layouts on Windows with a 192DPI or higher display. Now that all graphics are scaled the same as font-size-based graphics, there should be greater consistency all around. It would be great to get a lot of testing by various developers, not just for the obvious reason of making sure there are no regressions (we've already identified a minor regression on Linux where the first repaint looks wrong, but quickly fixes itself), but so that you can see if the sudden resizing of controls under various user environments with various DPI settings might create surprising sizing or layout issues for your application. We actually expect and hope that the opposite is true - that layouts and sizes will become more sane - but since Windows allows the user to control the default "user interface DPI" that is reported to applications, we need to be sure that our output remains sensible under the wide variety of settings we will encounter "in the wild". Hopefully your application will look great under the default settings you have on your machine, and should look great as well even if you've customized the DPI settings. If you are curious and want to test under a variety of "DPI"s, you can use one of two methods: 1. Windows provides control panels to change your DPI https://msdn.microsoft.com/en-us/library/windows/desktop/dn469266(v=vs.85).aspx#setting_dpi_by_using_control_panel * Note that we are currently in the class "System DPI aware" which means when you change the DPI setting in that control panel, you will have to reboot or log out/log in to make it take effect, even on the latest versions of Windows. We hope to become "Per Monitor DPI aware" in JDK9, but we need changes to AWT/Java2D and the java.exe manifest before we can embrace that feature in Windows 8.1. 2. We provide a command line property for overriding the DPI scaling: -Dglass.win.uiScale= = [NNN%] | [NNNdpi] | [N.NNNN] The standard scaling on windows assumes 96DPI as a target, so each of the following is identical: -Dglass.win.uiScale=200% (in cygwin shell) -Dglass.win.uiScale=200%% (in cmd.exe since it eats single '%' chars) -Dglass.win.uiScale=192dpi -Dglass.win.uiScale=2.00 The command line setting is much easier to use than the Control Panel because you do not have to log out and back in to test under a variety of settings, and you can even compare the application under different DPI settings side by side - just remember to double that %% sign in cmd.exe or your request for 150% scaling will be delivered to us as a request for 150x scaling. ;) (And, for the record, I viewed a number of test programs under that extreme scale factor before I learned to remember this idiosyncrasy of cmd.exe, and they looked fine, if not absurdly large...) MSDN also provides some suggestions for things to do to test your HiDPI application. Even though you've (hopefully) made no program changes to your application to get this support as we've (hopefully) done all of the leg work for you, some of these testing suggestions may help you make sure there are no bugs creeping in from our end: https://msdn.microsoft.com/en-us/library/windows/desktop/dd464659(v=vs.85).aspx (Scroll to the bottom for the "Testing Guidance" section) Finally, we provide 2 additional properties for debugging or overriding our default heuristics so that you can test various strategies: -Dglass.win.forceIntegerRenderScale=[true | false] (default is true so a 144dpi display is rendered at 2x and then downscaled for the proper 1.5x size on the screen - this strategy is very similar to how Mac OS deals with retina displays) -Dglass.win.renderScale= = [NNN%] | [NNNdpi] | [N.NNNN] (this can be completely independent of uiScale and controls the scale at which we render before we resize the buffer to match the uiScale as we blit to the screen. It also overrides the setting of the previous forceIntegerRenderScale property.) We hope the new HiDPI support improves the look and feel of your application on Windows and look forward to hearing any feedback or suggestions! ...jim From David.Hill at Oracle.com Tue Jun 2 21:41:32 2015 From: David.Hill at Oracle.com (David Hill) Date: Tue, 02 Jun 2015 17:41:32 -0400 Subject: Review for minimize on GTK. In-Reply-To: <556DFCC4.9020009@Oracle.com> References: <556DFCC4.9020009@Oracle.com> Message-ID: <556E230C.4040404@Oracle.com> On 6/2/15, 2:58 PM, David Hill wrote: Turns out there is a race case with the old fix, this one does something similar but seems to solve the race issue. webrev: http://cr.openjdk.java.net/~ddhill/RT-40261.2 > > Kevin, et al, > > (Note this fixed a regression post 8u20) > > jira: https://javafx-jira.kenai.com/browse/RT-40261 > webrev: http://cr.openjdk.java.net/~ddhill/T-40261 > > We tell the WindowManager not to support minimization (meaning the window decoration), then we ask it to minimize programmatically. The WM ignores the programmatic request because we just told it too. > The screen stops updating because the pulse thinks the window is not showing. > > Simple fix - remember the window manager functions, and if minimize is not present, enable it, minimize the window, then restore the original value. > > Tested with transparent & decorated. FullScreen also tested because that is something else we disable, but no negative effect seen. > -- David Hill Java Embedded Development "A man's feet should be planted in his country, but his eyes should survey the world." -- George Santayana (1863 - 1952) From kevin.rushforth at oracle.com Wed Jun 3 04:22:40 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 02 Jun 2015 21:22:40 -0700 Subject: [8u60, 9] review request: RT-40417: [CSS] NPE in com.sun.javafx.css.StyleManager.findMatchingStyles Message-ID: <556E8110.7080901@oracle.com> Jonathan and Leif, Please review the fix for the following MT failure in StyleManager: https://javafx-jira.kenai.com/browse/RT-40417 http://cr.openjdk.java.net/~kcr/RT-40417/webrev.00/ Details in the bug report. -- Kevin From jonathan.giles at oracle.com Wed Jun 3 06:17:29 2015 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Wed, 03 Jun 2015 18:17:29 +1200 Subject: Understanding the com.sun.* APIs being (ab)used by the community Message-ID: <556E9BF9.8020905@oracle.com> Hi folks, I've written a tool that analyses the output of JDeps. This allows for me to quickly understand what com.sun.* APIs are being used by projects. It basically just gives a tally of each com.sun.* class that is being used, given a directory of files that are output from JDeps (where each file is the output from running JDeps against a single jar file). The more of these JDeps text files I have, the more data I can have about what APIs are being (ab)used. Also, before I go further, lets try to keep this simple - I'd rather not have this discussion get political about the merits of modularity, choosing which APIs are most important, etc, etc, etc! I'm just a lowly engineer trying to make things as good as I can for you all. The remainder of the political discussion can start in ~2 weeks when I'm on vacation ;-) If you want to give me more data, please do the following from your computer, and then email me (off-list!) the resulting text file. My example command line instruction is what I run against Scene Builder, but please don't send me the output against your Scene Builder jar - I want to know what the output is against your projects. Here's the command line instruction (for my Windows 8 machine, your mileage may vary): jdeps -v SceneBuilder-8.0.0.jar > SceneBuilder-8.0.0.txt Send me (again, off-list!) the resulting text file. I don't want your jar files or anything else, I don't think my inbox could handle it :-) Thanks, -- Jonathan From anton.tarasov at oracle.com Wed Jun 3 15:53:41 2015 From: anton.tarasov at oracle.com (Anton Tarasov) Date: Wed, 03 Jun 2015 18:53:41 +0300 Subject: [9] review request: RT-46160 [WebView] "outstanding resource locks detected" when using clip in canvas Message-ID: <556F2305.90009@oracle.com> Hi Kevin, Vadim, Please review the fix: JIRA: https://javafx-jira.kenai.com/browse/RT-46160 webrev: http://cr.openjdk.java.net/~ant/RT-46160/webrev.0 Thanks, Anton. From herve.girod at gmail.com Wed Jun 3 16:01:33 2015 From: herve.girod at gmail.com (=?utf-8?Q?Herv=C3=A9_Girod?=) Date: Wed, 3 Jun 2015 18:01:33 +0200 Subject: Understanding the com.sun.* APIs being (ab)used by the community In-Reply-To: <556E9BF9.8020905@oracle.com> References: <556E9BF9.8020905@oracle.com> Message-ID: I know that it's the openjfx list, but are you also interested on other internal APIs usages? Herv? Sent from my iPhone > On Jun 3, 2015, at 08:17, Jonathan Giles wrote: > > Hi folks, > > I've written a tool that analyses the output of JDeps. This allows for me to quickly understand what com.sun.* APIs are being used by projects. It basically just gives a tally of each com.sun.* class that is being used, given a directory of files that are output from JDeps (where each file is the output from running JDeps against a single jar file). The more of these JDeps text files I have, the more data I can have about what APIs are being (ab)used. > > Also, before I go further, lets try to keep this simple - I'd rather not have this discussion get political about the merits of modularity, choosing which APIs are most important, etc, etc, etc! I'm just a lowly engineer trying to make things as good as I can for you all. The remainder of the political discussion can start in ~2 weeks when I'm on vacation ;-) > > If you want to give me more data, please do the following from your computer, and then email me (off-list!) the resulting text file. My example command line instruction is what I run against Scene Builder, but please don't send me the output against your Scene Builder jar - I want to know what the output is against your projects. > > Here's the command line instruction (for my Windows 8 machine, your mileage may vary): > > jdeps -v SceneBuilder-8.0.0.jar > SceneBuilder-8.0.0.txt > > Send me (again, off-list!) the resulting text file. I don't want your jar files or anything else, I don't think my inbox could handle it :-) > > Thanks, > -- Jonathan From kevin.rushforth at oracle.com Wed Jun 3 16:06:59 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 03 Jun 2015 09:06:59 -0700 Subject: Understanding the com.sun.* APIs being (ab)used by the community In-Reply-To: References: <556E9BF9.8020905@oracle.com> Message-ID: <556F2623.1030900@oracle.com> Do you mean elsewhere in the JDK? Those would be better discussed on either the jigsaw-interest list or on the relevant list for those APIs (e.g., awt, swing, java2d have their own lists). -- Kevin Herv? Girod wrote: > I know that it's the openjfx list, but are you also interested on other internal APIs usages? > > Herv? > > Sent from my iPhone > > >> On Jun 3, 2015, at 08:17, Jonathan Giles wrote: >> >> Hi folks, >> >> I've written a tool that analyses the output of JDeps. This allows for me to quickly understand what com.sun.* APIs are being used by projects. It basically just gives a tally of each com.sun.* class that is being used, given a directory of files that are output from JDeps (where each file is the output from running JDeps against a single jar file). The more of these JDeps text files I have, the more data I can have about what APIs are being (ab)used. >> >> Also, before I go further, lets try to keep this simple - I'd rather not have this discussion get political about the merits of modularity, choosing which APIs are most important, etc, etc, etc! I'm just a lowly engineer trying to make things as good as I can for you all. The remainder of the political discussion can start in ~2 weeks when I'm on vacation ;-) >> >> If you want to give me more data, please do the following from your computer, and then email me (off-list!) the resulting text file. My example command line instruction is what I run against Scene Builder, but please don't send me the output against your Scene Builder jar - I want to know what the output is against your projects. >> >> Here's the command line instruction (for my Windows 8 machine, your mileage may vary): >> >> jdeps -v SceneBuilder-8.0.0.jar > SceneBuilder-8.0.0.txt >> >> Send me (again, off-list!) the resulting text file. I don't want your jar files or anything else, I don't think my inbox could handle it :-) >> >> Thanks, >> -- Jonathan >> From philip.race at oracle.com Wed Jun 3 16:08:21 2015 From: philip.race at oracle.com (Phil Race) Date: Wed, 03 Jun 2015 09:08:21 -0700 Subject: Understanding the com.sun.* APIs being (ab)used by the community In-Reply-To: References: <556E9BF9.8020905@oracle.com> Message-ID: <556F2675.7030004@oracle.com> I can't speak for Jonathan on that point but if you find you are using something not on the list at the URL below, you may want to ask on the appropriate list what would be a suitable replacement https://wiki.openjdk.java.net/display/JDK8/Java+Dependency+Analysis+Tool Note that sometimes it can be out of your immediate control when you find its a 3rd party jar you import that has the dependency and then you would probably want to notify the authors of that code. -phil. On 06/03/2015 09:01 AM, Herv? Girod wrote: > I know that it's the openjfx list, but are you also interested on other internal APIs usages? > > Herv? > > Sent from my iPhone > >> On Jun 3, 2015, at 08:17, Jonathan Giles wrote: >> >> Hi folks, >> >> I've written a tool that analyses the output of JDeps. This allows for me to quickly understand what com.sun.* APIs are being used by projects. It basically just gives a tally of each com.sun.* class that is being used, given a directory of files that are output from JDeps (where each file is the output from running JDeps against a single jar file). The more of these JDeps text files I have, the more data I can have about what APIs are being (ab)used. >> >> Also, before I go further, lets try to keep this simple - I'd rather not have this discussion get political about the merits of modularity, choosing which APIs are most important, etc, etc, etc! I'm just a lowly engineer trying to make things as good as I can for you all. The remainder of the political discussion can start in ~2 weeks when I'm on vacation ;-) >> >> If you want to give me more data, please do the following from your computer, and then email me (off-list!) the resulting text file. My example command line instruction is what I run against Scene Builder, but please don't send me the output against your Scene Builder jar - I want to know what the output is against your projects. >> >> Here's the command line instruction (for my Windows 8 machine, your mileage may vary): >> >> jdeps -v SceneBuilder-8.0.0.jar > SceneBuilder-8.0.0.txt >> >> Send me (again, off-list!) the resulting text file. I don't want your jar files or anything else, I don't think my inbox could handle it :-) >> >> Thanks, >> -- Jonathan From herve.girod at gmail.com Wed Jun 3 16:19:28 2015 From: herve.girod at gmail.com (=?utf-8?Q?Herv=C3=A9_Girod?=) Date: Wed, 3 Jun 2015 18:19:28 +0200 Subject: Understanding the com.sun.* APIs being (ab)used by the community In-Reply-To: <556F2675.7030004@oracle.com> References: <556E9BF9.8020905@oracle.com> <556F2675.7030004@oracle.com> Message-ID: <8812311C-5288-4BAA-8F41-FE0FBB59FFF7@gmail.com> Thanks! However I have also jars which are using JavaFX on which I will use the tool against ! Sent from my iPhone > On Jun 3, 2015, at 18:08, Phil Race wrote: > > I can't speak for Jonathan on that point but if you find you are using > something not on the list at the URL below, you may want to ask > on the appropriate list what would be a suitable replacement > > https://wiki.openjdk.java.net/display/JDK8/Java+Dependency+Analysis+Tool > > Note that sometimes it can be out of your immediate control when you > find its a 3rd party jar you import that has the dependency and then you > would probably want to notify the authors of that code. > > -phil. > >> On 06/03/2015 09:01 AM, Herv? Girod wrote: >> I know that it's the openjfx list, but are you also interested on other internal APIs usages? >> >> Herv? >> >> Sent from my iPhone >> >>> On Jun 3, 2015, at 08:17, Jonathan Giles wrote: >>> >>> Hi folks, >>> >>> I've written a tool that analyses the output of JDeps. This allows for me to quickly understand what com.sun.* APIs are being used by projects. It basically just gives a tally of each com.sun.* class that is being used, given a directory of files that are output from JDeps (where each file is the output from running JDeps against a single jar file). The more of these JDeps text files I have, the more data I can have about what APIs are being (ab)used. >>> >>> Also, before I go further, lets try to keep this simple - I'd rather not have this discussion get political about the merits of modularity, choosing which APIs are most important, etc, etc, etc! I'm just a lowly engineer trying to make things as good as I can for you all. The remainder of the political discussion can start in ~2 weeks when I'm on vacation ;-) >>> >>> If you want to give me more data, please do the following from your computer, and then email me (off-list!) the resulting text file. My example command line instruction is what I run against Scene Builder, but please don't send me the output against your Scene Builder jar - I want to know what the output is against your projects. >>> >>> Here's the command line instruction (for my Windows 8 machine, your mileage may vary): >>> >>> jdeps -v SceneBuilder-8.0.0.jar > SceneBuilder-8.0.0.txt >>> >>> Send me (again, off-list!) the resulting text file. I don't want your jar files or anything else, I don't think my inbox could handle it :-) >>> >>> Thanks, >>> -- Jonathan > From morris.meyer at oracle.com Wed Jun 3 17:58:28 2015 From: morris.meyer at oracle.com (Morris Meyer) Date: Wed, 03 Jun 2015 13:58:28 -0400 Subject: [8u60, 9] review request for RT-37411: [Drag and Drop Linux] setDragView still doesn't work on linux Message-ID: <556F4044.4030409@oracle.com> David, Kevin et al, Please review this simple fix for RT-37411. It is pretty low risk vis-a-vis 8u60. Thanks much. --morris meyer JIRA - https://javafx-jira.kenai.com/browse/RT-37411 WEBREV - http://cr.openjdk.java.net/~morris/RT-37411.01/ From snfuchs at gmx.de Wed Jun 3 18:54:48 2015 From: snfuchs at gmx.de (Stefan Fuchs) Date: Wed, 03 Jun 2015 20:54:48 +0200 Subject: Understanding the com.sun.* APIs being (ab)used by the community In-Reply-To: <556E9BF9.8020905@oracle.com> References: <556E9BF9.8020905@oracle.com> Message-ID: <556F4D78.3040508@gmx.de> Hi Jonathan, thank you for your effort. Note however, that the output of the current version of jdeps may be incomplete. See https://bugs.openjdk.java.net/browse/JDK-8077349 Update jdeps to recognize JavaFX internal packages, which seems not to be fixed yet. Stefan > Hi folks, > > I've written a tool that analyses the output of JDeps. This allows for > me to quickly understand what com.sun.* APIs are being used by > projects. It basically just gives a tally of each com.sun.* class that > is being used, given a directory of files that are output from JDeps > (where each file is the output from running JDeps against a single jar > file). The more of these JDeps text files I have, the more data I can > have about what APIs are being (ab)used. > > Also, before I go further, lets try to keep this simple - I'd rather > not have this discussion get political about the merits of modularity, > choosing which APIs are most important, etc, etc, etc! I'm just a > lowly engineer trying to make things as good as I can for you all. The > remainder of the political discussion can start in ~2 weeks when I'm > on vacation ;-) > > If you want to give me more data, please do the following from your > computer, and then email me (off-list!) the resulting text file. My > example command line instruction is what I run against Scene Builder, > but please don't send me the output against your Scene Builder jar - I > want to know what the output is against your projects. > > Here's the command line instruction (for my Windows 8 machine, your > mileage may vary): > > jdeps -v SceneBuilder-8.0.0.jar > SceneBuilder-8.0.0.txt > > Send me (again, off-list!) the resulting text file. I don't want your > jar files or anything else, I don't think my inbox could handle it :-) > > Thanks, > -- Jonathan > From nipa at codefx.org Wed Jun 3 20:02:06 2015 From: nipa at codefx.org (Nicolai Parlog) Date: Wed, 03 Jun 2015 22:02:06 +0200 Subject: Understanding the com.sun.* APIs being (ab)used by the community In-Reply-To: <556F4D78.3040508@gmx.de> References: <556E9BF9.8020905@oracle.com> <556F4D78.3040508@gmx.de> Message-ID: <556F5D3E.6080308@codefx.org> Hi Stefan, running jdeps as shown in Jonathans post (with "-v") "[p]rints all class-level dependencies"[1]. This includes the ones which will not be accessible in Java 9. The bug you cite is based on a missing definition of some packages as internal API, so running with -jdkinternals will not list them as problematic. so long ... Nicolai [1] https://docs.oracle.com/javase/8/docs/technotes/tools/unix/jdeps.htm l On 03.06.2015 20:54, Stefan Fuchs wrote: > Hi Jonathan, > > thank you for your effort. > > Note however, that the output of the current version of jdeps may > be incomplete. > > See https://bugs.openjdk.java.net/browse/JDK-8077349 Update jdeps > to recognize JavaFX internal packages, which seems not to be fixed > yet. > > Stefan > > >> Hi folks, >> >> I've written a tool that analyses the output of JDeps. This >> allows for me to quickly understand what com.sun.* APIs are being >> used by projects. It basically just gives a tally of each >> com.sun.* class that is being used, given a directory of files >> that are output from JDeps (where each file is the output from >> running JDeps against a single jar file). The more of these JDeps >> text files I have, the more data I can have about what APIs are >> being (ab)used. >> >> Also, before I go further, lets try to keep this simple - I'd >> rather not have this discussion get political about the merits of >> modularity, choosing which APIs are most important, etc, etc, >> etc! I'm just a lowly engineer trying to make things as good as I >> can for you all. The remainder of the political discussion can >> start in ~2 weeks when I'm on vacation ;-) >> >> If you want to give me more data, please do the following from >> your computer, and then email me (off-list!) the resulting text >> file. My example command line instruction is what I run against >> Scene Builder, but please don't send me the output against your >> Scene Builder jar - I want to know what the output is against >> your projects. >> >> Here's the command line instruction (for my Windows 8 machine, >> your mileage may vary): >> >> jdeps -v SceneBuilder-8.0.0.jar > SceneBuilder-8.0.0.txt >> >> Send me (again, off-list!) the resulting text file. I don't want >> your jar files or anything else, I don't think my inbox could >> handle it :-) >> >> Thanks, -- Jonathan >> > -- PGP Key: http://keys.gnupg.net/pks/lookup?op=vindex&search=0xCA3BAD2E9CCCD509 Web: http://codefx.org a blog about software development http://do-foss.de Free and Open Source Software for the City of Dortmund Twitter: https://twitter.com/nipafx From kevin.rushforth at oracle.com Wed Jun 3 20:44:43 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 03 Jun 2015 13:44:43 -0700 Subject: Understanding the com.sun.* APIs being (ab)used by the community In-Reply-To: <556F5D3E.6080308@codefx.org> References: <556E9BF9.8020905@oracle.com> <556F4D78.3040508@gmx.de> <556F5D3E.6080308@codefx.org> Message-ID: <556F673B.10708@oracle.com> Right. They won't be flagged as problematic by the tool, but Jonathan knows which ones are -- namely, any JavaFX package that doesn't begin with "javafx." -- Kevin Nicolai Parlog wrote: > Hi Stefan, > > running jdeps as shown in Jonathans post (with "-v") "[p]rints all > class-level dependencies"[1]. This includes the ones which will not be > accessible in Java 9. > > The bug you cite is based on a missing definition of some packages as > internal API, so running with -jdkinternals will not list them as > problematic. > > so long ... Nicolai > > > [1] https://docs.oracle.com/javase/8/docs/technotes/tools/unix/jdeps.htm > l > > > > On 03.06.2015 20:54, Stefan Fuchs wrote: > >> Hi Jonathan, >> >> thank you for your effort. >> >> Note however, that the output of the current version of jdeps may >> be incomplete. >> >> See https://bugs.openjdk.java.net/browse/JDK-8077349 Update jdeps >> to recognize JavaFX internal packages, which seems not to be fixed >> yet. >> >> Stefan >> >> >> >>> Hi folks, >>> >>> I've written a tool that analyses the output of JDeps. This >>> allows for me to quickly understand what com.sun.* APIs are being >>> used by projects. It basically just gives a tally of each >>> com.sun.* class that is being used, given a directory of files >>> that are output from JDeps (where each file is the output from >>> running JDeps against a single jar file). The more of these JDeps >>> text files I have, the more data I can have about what APIs are >>> being (ab)used. >>> >>> Also, before I go further, lets try to keep this simple - I'd >>> rather not have this discussion get political about the merits of >>> modularity, choosing which APIs are most important, etc, etc, >>> etc! I'm just a lowly engineer trying to make things as good as I >>> can for you all. The remainder of the political discussion can >>> start in ~2 weeks when I'm on vacation ;-) >>> >>> If you want to give me more data, please do the following from >>> your computer, and then email me (off-list!) the resulting text >>> file. My example command line instruction is what I run against >>> Scene Builder, but please don't send me the output against your >>> Scene Builder jar - I want to know what the output is against >>> your projects. >>> >>> Here's the command line instruction (for my Windows 8 machine, >>> your mileage may vary): >>> >>> jdeps -v SceneBuilder-8.0.0.jar > SceneBuilder-8.0.0.txt >>> >>> Send me (again, off-list!) the resulting text file. I don't want >>> your jar files or anything else, I don't think my inbox could >>> handle it :-) >>> >>> Thanks, -- Jonathan >>> >>> > > From kevin.rushforth at oracle.com Wed Jun 3 22:00:22 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 03 Jun 2015 15:00:22 -0700 Subject: Trouble building JDK in debug mode In-Reply-To: References: Message-ID: <556F78F6.9010403@oracle.com> That should work. What platform are you using? How did you overlay your JavaFX bits? Are you sure it is using your build of jfxrt.jar? -- Kevin Sam' wrote: > Sorry to create a new post, I have not managed to reply to the other topic > since I had deactivated the notifications.. > > I am building the JDK on Mac. I have specified "CONF=DebugNative" with the > case sensitive in the gradle.properties file. > > You are speaking about -PCONF, but in the gradle I have specified only > "CONF" since it was written like that in the comment above.. > > Finally after that, I'm following the steps specified here ( > https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX#BuildingOpenJFX-Overlay-JDK8 > ) in order to deploy my JDK. Afterwards, when launching Netbeans, I cannot > see the local variables of JavaFX source code and debug it properly. > From jonathan.giles at oracle.com Wed Jun 3 22:05:02 2015 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Thu, 04 Jun 2015 10:05:02 +1200 Subject: Understanding the com.sun.* APIs being (ab)used by the community In-Reply-To: <556E9BF9.8020905@oracle.com> References: <556E9BF9.8020905@oracle.com> Message-ID: <556F7A0E.10802@oracle.com> Thanks everyone for emailing me your jdeps output - I now have 15 files and plenty of data to do some more analysis. You can stop emailing me files now! :-) Also, Nicolai and Kevin are correct - I'm not relying on JDeps to do any analysis of the output for me, I'm just using it to dump all referenced classes. I can then analyse the output of all the output files and group it into one report. -- Jonathan On 3/06/2015 6:17 p.m., Jonathan Giles wrote: > Hi folks, > > I've written a tool that analyses the output of JDeps. This allows for > me to quickly understand what com.sun.* APIs are being used by > projects. It basically just gives a tally of each com.sun.* class that > is being used, given a directory of files that are output from JDeps > (where each file is the output from running JDeps against a single jar > file). The more of these JDeps text files I have, the more data I can > have about what APIs are being (ab)used. > > Also, before I go further, lets try to keep this simple - I'd rather > not have this discussion get political about the merits of modularity, > choosing which APIs are most important, etc, etc, etc! I'm just a > lowly engineer trying to make things as good as I can for you all. The > remainder of the political discussion can start in ~2 weeks when I'm > on vacation ;-) > > If you want to give me more data, please do the following from your > computer, and then email me (off-list!) the resulting text file. My > example command line instruction is what I run against Scene Builder, > but please don't send me the output against your Scene Builder jar - I > want to know what the output is against your projects. > > Here's the command line instruction (for my Windows 8 machine, your > mileage may vary): > > jdeps -v SceneBuilder-8.0.0.jar > SceneBuilder-8.0.0.txt > > Send me (again, off-list!) the resulting text file. I don't want your > jar files or anything else, I don't think my inbox could handle it :-) > > Thanks, > -- Jonathan From snfuchs at gmx.de Wed Jun 3 22:30:38 2015 From: snfuchs at gmx.de (Stefan Fuchs) Date: Thu, 04 Jun 2015 00:30:38 +0200 Subject: Understanding the com.sun.* APIs being (ab)used by the community In-Reply-To: <556F673B.10708@oracle.com> References: <556E9BF9.8020905@oracle.com> <556F4D78.3040508@gmx.de> <556F5D3E.6080308@codefx.org> <556F673B.10708@oracle.com> Message-ID: <556F800E.9050007@gmx.de> Oh, of course, never mind then. Jdeps output from our application is on its way to Jonathan. Stefan > Right. They won't be flagged as problematic by the tool, but Jonathan > knows which ones are -- namely, any JavaFX package that doesn't begin > with "javafx." > > -- Kevin > > > Nicolai Parlog wrote: >> Hi Stefan, >> >> running jdeps as shown in Jonathans post (with "-v") "[p]rints all >> class-level dependencies"[1]. This includes the ones which will not be >> accessible in Java 9. >> >> The bug you cite is based on a missing definition of some packages as >> internal API, so running with -jdkinternals will not list them as >> problematic. >> >> so long ... Nicolai >> >> >> [1] https://docs.oracle.com/javase/8/docs/technotes/tools/unix/jdeps.htm >> l >> >> >> >> On 03.06.2015 20:54, Stefan Fuchs wrote: >>> Hi Jonathan, >>> >>> thank you for your effort. >>> >>> Note however, that the output of the current version of jdeps may >>> be incomplete. >>> >>> See https://bugs.openjdk.java.net/browse/JDK-8077349 Update jdeps >>> to recognize JavaFX internal packages, which seems not to be fixed >>> yet. >>> >>> Stefan >>> >>> >>>> Hi folks, >>>> >>>> I've written a tool that analyses the output of JDeps. This >>>> allows for me to quickly understand what com.sun.* APIs are being >>>> used by projects. It basically just gives a tally of each >>>> com.sun.* class that is being used, given a directory of files >>>> that are output from JDeps (where each file is the output from >>>> running JDeps against a single jar file). The more of these JDeps >>>> text files I have, the more data I can have about what APIs are >>>> being (ab)used. >>>> >>>> Also, before I go further, lets try to keep this simple - I'd >>>> rather not have this discussion get political about the merits of >>>> modularity, choosing which APIs are most important, etc, etc, >>>> etc! I'm just a lowly engineer trying to make things as good as I >>>> can for you all. The remainder of the political discussion can >>>> start in ~2 weeks when I'm on vacation ;-) >>>> >>>> If you want to give me more data, please do the following from >>>> your computer, and then email me (off-list!) the resulting text >>>> file. My example command line instruction is what I run against >>>> Scene Builder, but please don't send me the output against your >>>> Scene Builder jar - I want to know what the output is against >>>> your projects. >>>> >>>> Here's the command line instruction (for my Windows 8 machine, >>>> your mileage may vary): >>>> >>>> jdeps -v SceneBuilder-8.0.0.jar > SceneBuilder-8.0.0.txt >>>> >>>> Send me (again, off-list!) the resulting text file. I don't want >>>> your jar files or anything else, I don't think my inbox could >>>> handle it :-) >>>> >>>> Thanks, -- Jonathan >>>> >> > From kevin.rushforth at oracle.com Thu Jun 4 14:31:10 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 04 Jun 2015 07:31:10 -0700 Subject: Reminder: JavaFX JIRA issues moving to JBS tomorrow, June 5 In-Reply-To: <555E6389.30008@oracle.com> References: <555E6389.30008@oracle.com> Message-ID: <5570612E.7040203@oracle.com> As a reminder, the migration of FX bugs to JBS will happen tomorrow. The RT project in the JavaFX JIRA issue tracker will become read-only at 9:00 am Pacific time tomorrow morning. We expect the migration to be complete some time in the afternoon tomorrow. Also, our infrastructure team is planning to enable URL redirects from javafx-jira at kenai.com to bugs.java.com tomorrow afternoon, so unless they run into problems with this, existing URL links will work. -- Kevin Kevin Rushforth wrote: > As previously announced [1] we are in the process of migrating JavaFX > bugs to the JDK Bug System (JBS) [2] in the JDK project. > > The target date for this migration is Friday, June 5. The existing > JavaFX bug tracker will become permanently read-only on that date, and > will be decommissioned some time after the transition is complete. > After javafx-jira.kenai.com is retired, we will explore the > feasibility of setting up an automatic redirect to > bugs.openjdk.java.net so that existing URLs will work. In any case, > typing in an old RT-nnnnn number into JBS will open the bug even after > it is mapped into the JDK project. > > -- Kevin > > [1] > http://mail.openjdk.java.net/pipermail/openjfx-dev/2015-April/017083.html > [2] https://bugs.openjdk.java.net/ > From tbee at tbee.org Thu Jun 4 19:29:03 2015 From: tbee at tbee.org (Tom Eugelink) Date: Thu, 04 Jun 2015 21:29:03 +0200 Subject: right-to-left and clipping Message-ID: <5570A6FF.90409@tbee.org> Someone posted an issue with JFXtras Agenda and right-to-left node orientation. I fixed the part where dragging an appointment was using scene based coordinates and thus did not play nice with the automatic mirroring when right-to-left is activated. However, I also see rendering issues where clipping is used on a Text node to limit the visible descriptive text to the width and height of the appointment. After some fiddling I come to the conclusion that clipping apparently is not fully included in the mirroring. If it were, then the clip should render correctly, but OTOH it is not at its unmirrored position either. This partial behavior confuses me. In one situation I need to move the clip a illigical 20 pixels to the right when right-to-left is active. Very strange. Any ideas or suggestions what causes clipping to behave differently in the mirroring? Tom From ooo_saturn7 at mail.ru Thu Jun 4 20:54:43 2015 From: ooo_saturn7 at mail.ru (=?UTF-8?B?0JDQu9C10LrRgdCw0L3QtNGAINCh0LLQuNGA0LjQtNC+0LI=?=) Date: Thu, 04 Jun 2015 23:54:43 +0300 Subject: =?UTF-8?B?SmF2YUZ4OiBXZWJWaWV3IHBlcmZvbWFuY2UgaW4gV2luZG93IDc=?= Message-ID: <1433451283.417807613@f165.i.mail.ru> I have program and a webview which loads from http://lenta.ru site. I checked my program on centos 7.1 (64 bit, oracle jre 1.8.60) and on windows 7 (32 bit, oracle jre 1.8.60). There is a very very significant difference between them. On centos webview works a little bit slower then in firefox. However on win7 in comparison with centos perfomance is about 5-10 times worse. For example I can't scroll faster - I have to wait until the part of the page is rendered. How can it be solved (if it can)? -- ????????? ???????? From kevin.rushforth at oracle.com Fri Jun 5 00:21:19 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 04 Jun 2015 17:21:19 -0700 Subject: RESCHEDULED -> Re: Reminder: JavaFX JIRA issues moving to JBS tomorrow, June 5 In-Reply-To: <5570612E.7040203@oracle.com> References: <555E6389.30008@oracle.com> <5570612E.7040203@oracle.com> Message-ID: <5570EB7F.5060301@oracle.com> Due to a bug discovered in the migration script during the dry run, we will need to reschedule the migration. Exact date TBD as we will need to re-run series of testing. Our tentative target will be next Friday, June 12. Once confirmed, we will send another heads-up notice. -- Kevin Kevin Rushforth wrote: > As a reminder, the migration of FX bugs to JBS will happen tomorrow. > The RT project in the JavaFX JIRA issue tracker will become read-only > at 9:00 am Pacific time tomorrow morning. We expect the migration to > be complete some time in the afternoon tomorrow. > > Also, our infrastructure team is planning to enable URL redirects from > javafx-jira at kenai.com to bugs.java.com tomorrow afternoon, so unless > they run into problems with this, existing URL links will work. > > -- Kevin > > > Kevin Rushforth wrote: >> As previously announced [1] we are in the process of migrating JavaFX >> bugs to the JDK Bug System (JBS) [2] in the JDK project. >> >> The target date for this migration is Friday, June 5. The existing >> JavaFX bug tracker will become permanently read-only on that date, >> and will be decommissioned some time after the transition is >> complete. After javafx-jira.kenai.com is retired, we will explore the >> feasibility of setting up an automatic redirect to >> bugs.openjdk.java.net so that existing URLs will work. In any case, >> typing in an old RT-nnnnn number into JBS will open the bug even >> after it is mapped into the JDK project. >> >> -- Kevin >> >> [1] >> http://mail.openjdk.java.net/pipermail/openjfx-dev/2015-April/017083.html >> >> [2] https://bugs.openjdk.java.net/ >> From mp at jugs.org Fri Jun 5 09:18:08 2015 From: mp at jugs.org (Dr. Michael Paus) Date: Fri, 05 Jun 2015 11:18:08 +0200 Subject: Understanding the com.sun.* APIs being (ab)used by the community Message-ID: <55716950.1090107@jugs.org> As nobody has stated it explicitly so far I would like to ask what will happen to classes in Java9 which access methods that are within the javafx namespace but are declared private? Will code like this still work or not? public static double getPixelScale(Screen screen) throws NoSuchMethodException, SecurityException, IllegalAccessException, IllegalArgumentException, InvocationTargetException { Method m = Screen.class.getDeclaredMethod("getScale"); m.setAccessible(true); return ((Float) m.invoke(screen)).doubleValue(); } This hack for example is currently necessary because there is no other way to get at the current pixel scale of a HiDPI screen. From mp at jugs.org Fri Jun 5 10:03:41 2015 From: mp at jugs.org (Dr. Michael Paus) Date: Fri, 05 Jun 2015 12:03:41 +0200 Subject: Windows support for HiDPI displays, call for feedback and testing Message-ID: <557173FD.6090501@jugs.org> I cannot provide any Windows specific feedback on HiDPI displays because I don't own one but I am working on a MacBook Pro with Retina display and thus would like to ask a few questions in this context. How are other platforms (Mac, Linux) affected by the changes you made for the Windows support? (On my Mac I noticed a severe performance drop when using 8u60 which may possibly be related to these changes.) Are any of the special system properties you mentioned also usable on other platforms? Is there any way now to find out what the current pixel scale factor is? Without that knowledge it is impossible to do proper graphics on any HiDPI screen. (E.g., you can't position graphic elements correctly in order to get crisp lines or you can't get a crisp snapshot of a node if you don't take special actions based on the pixel scale.) From kevin.rushforth at oracle.com Fri Jun 5 15:28:02 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 05 Jun 2015 08:28:02 -0700 Subject: Understanding the com.sun.* APIs being (ab)used by the community In-Reply-To: <55716950.1090107@jugs.org> References: <55716950.1090107@jugs.org> Message-ID: <5571C002.90600@oracle.com> Yes, this will still work, although dipping into non-public state continues to be something we wouldn't recommend that an application rely on... -- Kevin Dr. Michael Paus wrote: > As nobody has stated it explicitly so far I would like to ask what > will happen > to classes in Java9 which access methods that are within the javafx > namespace but > are declared private? Will code like this still work or not? > > public static double getPixelScale(Screen screen) throws > NoSuchMethodException, SecurityException, IllegalAccessException, > IllegalArgumentException, InvocationTargetException { > Method m = Screen.class.getDeclaredMethod("getScale"); > m.setAccessible(true); > return ((Float) m.invoke(screen)).doubleValue(); > } > > This hack for example is currently necessary because there is no other > way to get at > the current pixel scale of a HiDPI screen. > > > From mp at jugs.org Fri Jun 5 15:37:00 2015 From: mp at jugs.org (Dr. Michael Paus) Date: Fri, 05 Jun 2015 17:37:00 +0200 Subject: Understanding the com.sun.* APIs being (ab)used by the community In-Reply-To: <5571C002.90600@oracle.com> References: <55716950.1090107@jugs.org> <5571C002.90600@oracle.com> Message-ID: <5571C21C.1060402@jugs.org> I promise to ditch that code as soon as there is a viable alternative. :-) Am 05.06.15 um 17:28 schrieb Kevin Rushforth: > Yes, this will still work, although dipping into non-public state > continues to be something we wouldn't recommend that an application > rely on... > > -- Kevin > > > Dr. Michael Paus wrote: >> As nobody has stated it explicitly so far I would like to ask what >> will happen >> to classes in Java9 which access methods that are within the javafx >> namespace but >> are declared private? Will code like this still work or not? >> >> public static double getPixelScale(Screen screen) throws >> NoSuchMethodException, SecurityException, IllegalAccessException, >> IllegalArgumentException, InvocationTargetException { >> Method m = Screen.class.getDeclaredMethod("getScale"); >> m.setAccessible(true); >> return ((Float) m.invoke(screen)).doubleValue(); >> } >> >> This hack for example is currently necessary because there is no >> other way to get at >> the current pixel scale of a HiDPI screen. >> >> >> From vadim.pakhnushev at oracle.com Fri Jun 5 18:33:01 2015 From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev) Date: Fri, 05 Jun 2015 21:33:01 +0300 Subject: In(Sanity) Testing Mondays Message-ID: <5571EB5D.2000208@oracle.com> Reminder, Monday is our weekly sanity testing. You can find your testing assignment at: https://wiki.openjdk.java.net/display/OpenJFX/Sanity+Testing Also please remember that the repo will be locked from 1am PDT until 1pm PDT. Happy testing! Thanks, Vadim From james.graham at oracle.com Fri Jun 5 20:49:06 2015 From: james.graham at oracle.com (Jim Graham) Date: Fri, 05 Jun 2015 13:49:06 -0700 Subject: Windows support for HiDPI displays, call for feedback and testing In-Reply-To: <557173FD.6090501@jugs.org> References: <557173FD.6090501@jugs.org> Message-ID: <55720B42.6040906@oracle.com> I actually use a retina MBP for testing - dual booting Windows and MacOS. There should be no changes at all on other platforms, particularly in regard to rendering speed. There was one small regression on Linux resulting in a bad first paint due to asynchronous initialization of the Window size, but no performance issues. Can you be more specific about where you see the performance drop? What kind of scene graph/animation? The system properties are all Windows specific, thus the "glass.win" prefix. In 9 we might generalize all of the HiDPI support and offer something more centralized, but those are just there for testing the new Windows support for now. We'll also look at how to advertise the pixel scaling to applications at that time. One thing to note is that the way that Mac retina support is done, if the user ever sets their control panel to anything other than "just pick the best conditions for this display" then there is pixel-scaling going on behind the scenes in the OS, so any attempts to try to line up with pixels will be muddied by the virtual DPI they are emulating at the system level. We'll also be looking at ways to bypass their built-in "virtualized" HiDPI support in a later release so that we can actually talk directly to display pixels regardless of CP settings. This virtualized scaling is mitigated by the fact that this HiDPI pixel stretching is happening on a HiDPI display and so any linear interpolation is hidden by tiny pixel sizes. To that end, we are doing something similar with Windows scaling. There are a number of places in the FX code that assume that it can predict an integer translation from the FX code and so we always render at integer scales so that integers in FX Scene coordinates map to integers in rendered pixel coordinates. We'll try to fix those in 9 so that we can do non-integer scaling, but until then there will be the same disconnect between trying to line up with display pixels and the actions of HiDPI as Mac OS already has... ...jim On 6/5/15 3:03 AM, Dr. Michael Paus wrote: > I cannot provide any Windows specific feedback on HiDPI displays because > I don't own one but I am working on a MacBook Pro with Retina display > and thus would like to ask a few questions in this context. > > How are other platforms (Mac, Linux) affected by the changes you made > for the Windows support? (On my Mac I noticed a severe performance drop > when using 8u60 which may possibly be related to these changes.) > > Are any of the special system properties you mentioned also usable on > other platforms? > > Is there any way now to find out what the current pixel scale factor is? > Without that knowledge it is impossible to do proper graphics on any > HiDPI screen. (E.g., you can't position graphic elements correctly in > order to get crisp lines or you can't get a crisp snapshot of a node if > you don't take special actions based on the pixel scale.) From chien.yang at oracle.com Fri Jun 5 21:32:01 2015 From: chien.yang at oracle.com (Chien Yang) Date: Fri, 05 Jun 2015 14:32:01 -0700 Subject: Code Review Request For RT-38179: [TabPane] TableView in TabPane has memory leak Message-ID: <55721551.1060801@oracle.com> Hi Kevin, Please the proposed fix with unit test included: JIRA: https://javafx-jira.kenai.com/browse/RT-38179 Webrev: http://cr.openjdk.java.net/~ckyang/RT-38179/webrev.00/ Thanks, - Chien From sven.reimers at gmail.com Sat Jun 6 15:17:24 2015 From: sven.reimers at gmail.com (Sven Reimers) Date: Sat, 6 Jun 2015 17:17:24 +0200 Subject: Tick marks on slider Message-ID: Hi, my assumption was that Slider s_v6 = new Slider(0, 100, 50); s_v6.setShowTickMarks(true); would show all tick marks (minor and major), but it seems that major ones are missing. If I add s_v6.setShowTickLabels(true) label and major ticks are shown. Seems there is no workaround? Shall I file a bug (seems I still can do this in a lightweight mode until transition is finished). -Sven -- Sven Reimers * Senior Expert Software Architect * Java Champion * NetBeans Dream Team Member: http://dreamteam.netbeans.org * Community Leader NetBeans: http://community.java.net/netbeans Desktop Java: http://community.java.net/javadesktop * JUG Leader JUG Bodensee: http://www.jug-bodensee.de * Duke's Choice Award Winner 2009 * Blog: https://www.java.net//blog/sven * XING: https://www.xing.com/profile/Sven_Reimers8 * LinkedIn: http://www.linkedin.com/in/svenreimers Join the NetBeans Groups: * XING: http://www.xing.com/group-20148.82db20 * NUGM: http://haug-server.dyndns.org/display/NUGM/Home * LinkedIn: http://www.linkedin.com/groups?gid=1860468 http://www.linkedin.com/groups?gid=107402 http://www.linkedin.com/groups?gid=1684717 * Oracle: https://mix.oracle.com/groups/18497 From mp at jugs.org Sat Jun 6 18:39:53 2015 From: mp at jugs.org (Dr. Michael Paus) Date: Sat, 06 Jun 2015 20:39:53 +0200 Subject: Windows support for HiDPI displays, call for feedback and testing In-Reply-To: <55720B42.6040906@oracle.com> References: <557173FD.6090501@jugs.org> <55720B42.6040906@oracle.com> Message-ID: <55733E79.7060509@jugs.org> Many thanks for the clarification. I'd also like to be more specific on the performance drop I observed but I have to admit that I don't have any idea what is going on there. The only thing I can say for sure is that I can consistently reproduce this drop in performance by switching between 8u45 and 8u60 (tested with b08 and b15). My application contains a map view (something similar to Google Maps) which displays an area of retina map tiles. By dragging with the mouse I can move this map around within the map pane. This works smoothly with 8u45 but is completely shaky with 8u60. I even experimented with various techniques to implement such a map view (single large image, single large canvas, individual images/canvases for each map tile) and they all show the same behavior, so it cannot be something which is specific to a particular implementation approach. During my test all tiles where already cached in memory, so I can exclude any file or network IO related issues. I tried to implement a little example where I just move around a large image but in this simple scenario the problem does not show up. So in order to do a bit more precise measuring I added an AnimationTimer to my map pane which I use to compute a new position of the map for each frame so that a point on the map moves along a circle. This helps to show the performance drop more precisely than moving around the map by hand. This is a smooth movement with 8u45 but shaky with 8u60. But one other observation puzzles me completely. The handle-method of the timer is called with a frame rate of 60 Hz even though the graphics output is shaky and has a visual frame rate of something between 2 - 5 Hz. It is new to me that something like this is technically possible. It looks as if the system is running at full speed but skips displaying most of the generated frames for some reason. Is such a behavior possible at all? Am 05.06.15 um 22:49 schrieb Jim Graham: > I actually use a retina MBP for testing - dual booting Windows and MacOS. > > There should be no changes at all on other platforms, particularly in > regard to rendering speed. There was one small regression on Linux > resulting in a bad first paint due to asynchronous initialization of > the Window size, but no performance issues. Can you be more specific > about where you see the performance drop? What kind of scene > graph/animation? > > The system properties are all Windows specific, thus the "glass.win" > prefix. In 9 we might generalize all of the HiDPI support and offer > something more centralized, but those are just there for testing the > new Windows support for now. We'll also look at how to advertise the > pixel scaling to applications at that time. > > One thing to note is that the way that Mac retina support is done, if > the user ever sets their control panel to anything other than "just > pick the best conditions for this display" then there is pixel-scaling > going on behind the scenes in the OS, so any attempts to try to line > up with pixels will be muddied by the virtual DPI they are emulating > at the system level. We'll also be looking at ways to bypass their > built-in "virtualized" HiDPI support in a later release so that we can > actually talk directly to display pixels regardless of CP settings. > > This virtualized scaling is mitigated by the fact that this HiDPI > pixel stretching is happening on a HiDPI display and so any linear > interpolation is hidden by tiny pixel sizes. > > To that end, we are doing something similar with Windows scaling. > There are a number of places in the FX code that assume that it can > predict an integer translation from the FX code and so we always > render at integer scales so that integers in FX Scene coordinates map > to integers in rendered pixel coordinates. We'll try to fix those in > 9 so that we can do non-integer scaling, but until then there will be > the same disconnect between trying to line up with display pixels and > the actions of HiDPI as Mac OS already has... > > ...jim > > On 6/5/15 3:03 AM, Dr. Michael Paus wrote: >> I cannot provide any Windows specific feedback on HiDPI displays because >> I don't own one but I am working on a MacBook Pro with Retina display >> and thus would like to ask a few questions in this context. >> >> How are other platforms (Mac, Linux) affected by the changes you made >> for the Windows support? (On my Mac I noticed a severe performance drop >> when using 8u60 which may possibly be related to these changes.) >> >> Are any of the special system properties you mentioned also usable on >> other platforms? >> >> Is there any way now to find out what the current pixel scale factor is? >> Without that knowledge it is impossible to do proper graphics on any >> HiDPI screen. (E.g., you can't position graphic elements correctly in >> order to get crisp lines or you can't get a crisp snapshot of a node if >> you don't take special actions based on the pixel scale.) From tbee at tbee.org Sun Jun 7 10:22:27 2015 From: tbee at tbee.org (Tom Eugelink) Date: Sun, 07 Jun 2015 12:22:27 +0200 Subject: right-to-left and clipping In-Reply-To: <5570A6FF.90409@tbee.org> References: <5570A6FF.90409@tbee.org> Message-ID: <55741B63.9020204@tbee.org> Well, I spent quite some time on the clipping and while it I still can't get every situation to play nice, the basic code to get the clipping on a text working in right-to-left node orientation seems to be: clip.x = text.width - text.parent.width https://github.com/JFXtras/jfxtras/blob/8.0/jfxtras-agenda/src/main/java/jfxtras/internal/scene/control/skin/agenda/base24hour/LayoutHelp.java#L89 So it seems that clipping is not including in the automatic mirror when entering right-to-left mode. I would think this is a bug? Tom On 4-6-2015 21:29, Tom Eugelink wrote: > Someone posted an issue with JFXtras Agenda and right-to-left node orientation. I fixed the part where dragging an appointment was using scene based coordinates and thus did not play nice with the automatic mirroring when right-to-left is activated. > > However, I also see rendering issues where clipping is used on a Text node to limit the visible descriptive text to the width and height of the appointment. After some fiddling I come to the conclusion that clipping apparently is not fully included in the mirroring. If it were, then the clip should render correctly, but OTOH it is not at its unmirrored position either. This partial behavior confuses me. In one situation I need to move the clip a illigical 20 pixels to the right when right-to-left is active. Very strange. Any ideas or suggestions what causes clipping to behave differently in the mirroring? > > Tom > > From kevin.rushforth at oracle.com Mon Jun 8 12:42:43 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 08 Jun 2015 05:42:43 -0700 Subject: Windows support for HiDPI displays, call for feedback and testing In-Reply-To: <55733E79.7060509@jugs.org> References: <557173FD.6090501@jugs.org> <55720B42.6040906@oracle.com> <55733E79.7060509@jugs.org> Message-ID: <55758DC3.5010905@oracle.com> Does the same slowdown happen on a non-Retina system? How large is your image? How large are the individual tiles? One thing that occurs to me is that your application might be thrashing texture memory (although I can't think of anything that changed in 8u60 that would affect this). You might try the following debug flag: java -Dprism.poolstats=true and see if there is a lot of thrashing of texture memory. Also, you can increase the memory that will be used for textures to, say, 1Gbyte (default is 512Mbytes) by: java -Dprism.maxvram=1g and see if that makes a difference. Jim might have additional suggestions. -- Kevin Dr. Michael Paus wrote: > Many thanks for the clarification. > > I'd also like to be more specific on the performance drop I observed > but I have to > admit that I don't have any idea what is going on there. The only > thing I can say > for sure is that I can consistently reproduce this drop in performance > by switching > between 8u45 and 8u60 (tested with b08 and b15). > > My application contains a map view (something similar to Google Maps) > which > displays an area of retina map tiles. By dragging with the mouse I can > move this > map around within the map pane. This works smoothly with 8u45 but is > completely > shaky with 8u60. I even experimented with various techniques to > implement such > a map view (single large image, single large canvas, individual > images/canvases for > each map tile) and they all show the same behavior, so it cannot be > something which > is specific to a particular implementation approach. During my test > all tiles where already > cached in memory, so I can exclude any file or network IO related issues. > > I tried to implement a little example where I just move around a large > image but in > this simple scenario the problem does not show up. > > So in order to do a bit more precise measuring I added an > AnimationTimer to my map pane > which I use to compute a new position of the map for each frame so > that a point on the map > moves along a circle. This helps to show the performance drop more > precisely than moving > around the map by hand. This is a smooth movement with 8u45 but shaky > with 8u60. > > But one other observation puzzles me completely. The handle-method of > the timer is called with > a frame rate of 60 Hz even though the graphics output is shaky and has > a visual frame rate > of something between 2 - 5 Hz. It is new to me that something like > this is technically possible. > It looks as if the system is running at full speed but skips > displaying most of the generated > frames for some reason. Is such a behavior possible at all? > > Am 05.06.15 um 22:49 schrieb Jim Graham: >> I actually use a retina MBP for testing - dual booting Windows and >> MacOS. >> >> There should be no changes at all on other platforms, particularly in >> regard to rendering speed. There was one small regression on Linux >> resulting in a bad first paint due to asynchronous initialization of >> the Window size, but no performance issues. Can you be more specific >> about where you see the performance drop? What kind of scene >> graph/animation? >> >> The system properties are all Windows specific, thus the "glass.win" >> prefix. In 9 we might generalize all of the HiDPI support and offer >> something more centralized, but those are just there for testing the >> new Windows support for now. We'll also look at how to advertise the >> pixel scaling to applications at that time. >> >> One thing to note is that the way that Mac retina support is done, if >> the user ever sets their control panel to anything other than "just >> pick the best conditions for this display" then there is >> pixel-scaling going on behind the scenes in the OS, so any attempts >> to try to line up with pixels will be muddied by the virtual DPI they >> are emulating at the system level. We'll also be looking at ways to >> bypass their built-in "virtualized" HiDPI support in a later release >> so that we can actually talk directly to display pixels regardless of >> CP settings. >> >> This virtualized scaling is mitigated by the fact that this HiDPI >> pixel stretching is happening on a HiDPI display and so any linear >> interpolation is hidden by tiny pixel sizes. >> >> To that end, we are doing something similar with Windows scaling. >> There are a number of places in the FX code that assume that it can >> predict an integer translation from the FX code and so we always >> render at integer scales so that integers in FX Scene coordinates map >> to integers in rendered pixel coordinates. We'll try to fix those in >> 9 so that we can do non-integer scaling, but until then there will be >> the same disconnect between trying to line up with display pixels and >> the actions of HiDPI as Mac OS already has... >> >> ...jim >> >> On 6/5/15 3:03 AM, Dr. Michael Paus wrote: >>> I cannot provide any Windows specific feedback on HiDPI displays >>> because >>> I don't own one but I am working on a MacBook Pro with Retina display >>> and thus would like to ask a few questions in this context. >>> >>> How are other platforms (Mac, Linux) affected by the changes you made >>> for the Windows support? (On my Mac I noticed a severe performance drop >>> when using 8u60 which may possibly be related to these changes.) >>> >>> Are any of the special system properties you mentioned also usable on >>> other platforms? >>> >>> Is there any way now to find out what the current pixel scale factor >>> is? >>> Without that knowledge it is impossible to do proper graphics on any >>> HiDPI screen. (E.g., you can't position graphic elements correctly in >>> order to get crisp lines or you can't get a crisp snapshot of a node if >>> you don't take special actions based on the pixel scale.) > From kevin.rushforth at oracle.com Mon Jun 8 12:43:12 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 08 Jun 2015 05:43:12 -0700 Subject: Tick marks on slider In-Reply-To: References: Message-ID: <55758DE0.6060709@oracle.com> Yes, please file a bug. -- Kevin Sven Reimers wrote: > Hi, > > my assumption was that > > Slider s_v6 = new Slider(0, 100, 50); > s_v6.setShowTickMarks(true); > > would show all tick marks (minor and major), but it seems that major ones > are missing. If I add > > s_v6.setShowTickLabels(true) > > label and major ticks are shown. Seems there is no workaround? > > Shall I file a bug (seems I still can do this in a lightweight mode until > transition is finished). > > -Sven > > From kevin.rushforth at oracle.com Mon Jun 8 12:44:17 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 08 Jun 2015 05:44:17 -0700 Subject: right-to-left and clipping In-Reply-To: <55741B63.9020204@tbee.org> References: <5570A6FF.90409@tbee.org> <55741B63.9020204@tbee.org> Message-ID: <55758E21.4050104@oracle.com> At first glance, I agree that this seems like a bug. Please file a JIRA issue with your test program. Thanks. -- Kevin Tom Eugelink wrote: > Well, I spent quite some time on the clipping and while it I still > can't get every situation to play nice, the basic code to get the > clipping on a text working in right-to-left node orientation seems to be: > > clip.x = text.width - text.parent.width > > https://github.com/JFXtras/jfxtras/blob/8.0/jfxtras-agenda/src/main/java/jfxtras/internal/scene/control/skin/agenda/base24hour/LayoutHelp.java#L89 > > > So it seems that clipping is not including in the automatic mirror > when entering right-to-left mode. I would think this is a bug? > > Tom > > > > > On 4-6-2015 21:29, Tom Eugelink wrote: >> Someone posted an issue with JFXtras Agenda and right-to-left node >> orientation. I fixed the part where dragging an appointment was using >> scene based coordinates and thus did not play nice with the automatic >> mirroring when right-to-left is activated. >> >> However, I also see rendering issues where clipping is used on a Text >> node to limit the visible descriptive text to the width and height of >> the appointment. After some fiddling I come to the conclusion that >> clipping apparently is not fully included in the mirroring. If it >> were, then the clip should render correctly, but OTOH it is not at >> its unmirrored position either. This partial behavior confuses me. In >> one situation I need to move the clip a illigical 20 pixels to the >> right when right-to-left is active. Very strange. Any ideas or >> suggestions what causes clipping to behave differently in the mirroring? >> >> Tom >> >> > From sven.reimers at gmail.com Mon Jun 8 13:13:01 2015 From: sven.reimers at gmail.com (Sven Reimers) Date: Mon, 8 Jun 2015 15:13:01 +0200 Subject: Tick marks on slider In-Reply-To: <55758DE0.6060709@oracle.com> References: <55758DE0.6060709@oracle.com> Message-ID: Done.. https://javafx-jira.kenai.com/browse/RT-46179 Sven P.S. If time permits I could have a look at a possible fix (somewhere down in NumberAxis I suppose) - interested? On Mon, Jun 8, 2015 at 2:43 PM, Kevin Rushforth wrote: > Yes, please file a bug. > > -- Kevin > > > > Sven Reimers wrote: > >> Hi, >> >> my assumption was that >> >> Slider s_v6 = new Slider(0, 100, 50); >> s_v6.setShowTickMarks(true); >> >> would show all tick marks (minor and major), but it seems that major ones >> are missing. If I add >> >> s_v6.setShowTickLabels(true) >> >> label and major ticks are shown. Seems there is no workaround? >> >> Shall I file a bug (seems I still can do this in a lightweight mode until >> transition is finished). >> >> -Sven >> >> >> > -- Sven Reimers * Senior Expert Software Architect * Java Champion * NetBeans Dream Team Member: http://dreamteam.netbeans.org * Community Leader NetBeans: http://community.java.net/netbeans Desktop Java: http://community.java.net/javadesktop * JUG Leader JUG Bodensee: http://www.jug-bodensee.de * Duke's Choice Award Winner 2009 * Blog: https://www.java.net//blog/sven * XING: https://www.xing.com/profile/Sven_Reimers8 * LinkedIn: http://www.linkedin.com/in/svenreimers Join the NetBeans Groups: * XING: http://www.xing.com/group-20148.82db20 * NUGM: http://haug-server.dyndns.org/display/NUGM/Home * LinkedIn: http://www.linkedin.com/groups?gid=1860468 http://www.linkedin.com/groups?gid=107402 http://www.linkedin.com/groups?gid=1684717 * Oracle: https://mix.oracle.com/groups/18497 From kevin.rushforth at oracle.com Mon Jun 8 14:07:06 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 08 Jun 2015 07:07:06 -0700 Subject: Tick marks on slider In-Reply-To: References: <55758DE0.6060709@oracle.com> Message-ID: <5575A18A.2030902@oracle.com> Sure, you are welcome to take a stab at it. It's too late for 8u60, though, unless a safe fix is found this week, since ZBB is the beginning of next week. Jonathan can comment further on it. -- Kevin Sven Reimers wrote: > Done.. > https://javafx-jira.kenai.com/browse/RT-46179 > > Sven > P.S. If time permits I could have a look at a possible fix (somewhere > down in NumberAxis I suppose) - interested? > > On Mon, Jun 8, 2015 at 2:43 PM, Kevin Rushforth > > wrote: > > Yes, please file a bug. > > -- Kevin > > > > Sven Reimers wrote: > > Hi, > > my assumption was that > > Slider s_v6 = new Slider(0, 100, 50); > s_v6.setShowTickMarks(true); > > would show all tick marks (minor and major), but it seems that > major ones > are missing. If I add > > s_v6.setShowTickLabels(true) > > label and major ticks are shown. Seems there is no workaround? > > Shall I file a bug (seems I still can do this in a lightweight > mode until > transition is finished). > > -Sven > > > > > > > -- > Sven Reimers > > * Senior Expert Software Architect > * Java Champion > * NetBeans Dream Team Member: http://dreamteam.netbeans.org > * Community Leader NetBeans: http://community.java.net/netbeans > Desktop Java: > http://community.java.net/javadesktop > * JUG Leader JUG Bodensee: http://www.jug-bodensee.de > * Duke's Choice Award Winner 2009 > * Blog: https://www.java.net//blog/sven > > * XING: https://www.xing.com/profile/Sven_Reimers8 > * LinkedIn: http://www.linkedin.com/in/svenreimers > > Join the NetBeans Groups: > * XING: http://www.xing.com/group-20148.82db20 > * NUGM: http://haug-server.dyndns.org/display/NUGM/Home > * LinkedIn: http://www.linkedin.com/groups?gid=1860468 > http://www.linkedin.com/groups?gid=107402 > http://www.linkedin.com/groups?gid=1684717 > * Oracle: https://mix.oracle.com/groups/18497 From david.dehaven at oracle.com Mon Jun 8 16:48:40 2015 From: david.dehaven at oracle.com (David DeHaven) Date: Mon, 8 Jun 2015 09:48:40 -0700 Subject: Understanding the com.sun.* APIs being (ab)used by the community In-Reply-To: <5571C002.90600@oracle.com> References: <55716950.1090107@jugs.org> <5571C002.90600@oracle.com> Message-ID: It'll work as long as the class in question (Screen in this case) is exported. If not, you'll likely get a security exception or CNFE. -DrD- > On Jun 5, 2015, at 8:28 AM, Kevin Rushforth wrote: > > Yes, this will still work, although dipping into non-public state continues to be something we wouldn't recommend that an application rely on... > > -- Kevin > > > Dr. Michael Paus wrote: >> As nobody has stated it explicitly so far I would like to ask what will happen >> to classes in Java9 which access methods that are within the javafx namespace but >> are declared private? Will code like this still work or not? >> >> public static double getPixelScale(Screen screen) throws NoSuchMethodException, SecurityException, IllegalAccessException, IllegalArgumentException, InvocationTargetException { >> Method m = Screen.class.getDeclaredMethod("getScale"); >> m.setAccessible(true); >> return ((Float) m.invoke(screen)).doubleValue(); >> } >> >> This hack for example is currently necessary because there is no other way to get at >> the current pixel scale of a HiDPI screen. >> >> >> From james.graham at oracle.com Mon Jun 8 18:33:14 2015 From: james.graham at oracle.com (Jim Graham) Date: Mon, 08 Jun 2015 11:33:14 -0700 Subject: Windows support for HiDPI displays, call for feedback and testing In-Reply-To: <55758DC3.5010905@oracle.com> References: <557173FD.6090501@jugs.org> <55720B42.6040906@oracle.com> <55733E79.7060509@jugs.org> <55758DC3.5010905@oracle.com> Message-ID: <5575DFEA.8040406@oracle.com> The only thing that might affect this was the change in the default size of the vram pool, but that happened in 8u40 which predates both of the builds involved in the experiment. I'd be curious as well to hear how the application is affected on non-retina screens, and Windows/D3D for that matter... ...jim On 6/8/15 5:42 AM, Kevin Rushforth wrote: > Does the same slowdown happen on a non-Retina system? > > How large is your image? How large are the individual tiles? One thing > that occurs to me is that your application might be thrashing texture > memory (although I can't think of anything that changed in 8u60 that > would affect this). You might try the following debug flag: > > java -Dprism.poolstats=true > > and see if there is a lot of thrashing of texture memory. Also, you can > increase the memory that will be used for textures to, say, 1Gbyte > (default is 512Mbytes) by: > > java -Dprism.maxvram=1g > > and see if that makes a difference. Jim might have additional suggestions. > > -- Kevin > > > Dr. Michael Paus wrote: >> Many thanks for the clarification. >> >> I'd also like to be more specific on the performance drop I observed >> but I have to >> admit that I don't have any idea what is going on there. The only >> thing I can say >> for sure is that I can consistently reproduce this drop in performance >> by switching >> between 8u45 and 8u60 (tested with b08 and b15). >> >> My application contains a map view (something similar to Google Maps) >> which >> displays an area of retina map tiles. By dragging with the mouse I can >> move this >> map around within the map pane. This works smoothly with 8u45 but is >> completely >> shaky with 8u60. I even experimented with various techniques to >> implement such >> a map view (single large image, single large canvas, individual >> images/canvases for >> each map tile) and they all show the same behavior, so it cannot be >> something which >> is specific to a particular implementation approach. During my test >> all tiles where already >> cached in memory, so I can exclude any file or network IO related issues. >> >> I tried to implement a little example where I just move around a large >> image but in >> this simple scenario the problem does not show up. >> >> So in order to do a bit more precise measuring I added an >> AnimationTimer to my map pane >> which I use to compute a new position of the map for each frame so >> that a point on the map >> moves along a circle. This helps to show the performance drop more >> precisely than moving >> around the map by hand. This is a smooth movement with 8u45 but shaky >> with 8u60. >> >> But one other observation puzzles me completely. The handle-method of >> the timer is called with >> a frame rate of 60 Hz even though the graphics output is shaky and has >> a visual frame rate >> of something between 2 - 5 Hz. It is new to me that something like >> this is technically possible. >> It looks as if the system is running at full speed but skips >> displaying most of the generated >> frames for some reason. Is such a behavior possible at all? >> >> Am 05.06.15 um 22:49 schrieb Jim Graham: >>> I actually use a retina MBP for testing - dual booting Windows and >>> MacOS. >>> >>> There should be no changes at all on other platforms, particularly in >>> regard to rendering speed. There was one small regression on Linux >>> resulting in a bad first paint due to asynchronous initialization of >>> the Window size, but no performance issues. Can you be more specific >>> about where you see the performance drop? What kind of scene >>> graph/animation? >>> >>> The system properties are all Windows specific, thus the "glass.win" >>> prefix. In 9 we might generalize all of the HiDPI support and offer >>> something more centralized, but those are just there for testing the >>> new Windows support for now. We'll also look at how to advertise the >>> pixel scaling to applications at that time. >>> >>> One thing to note is that the way that Mac retina support is done, if >>> the user ever sets their control panel to anything other than "just >>> pick the best conditions for this display" then there is >>> pixel-scaling going on behind the scenes in the OS, so any attempts >>> to try to line up with pixels will be muddied by the virtual DPI they >>> are emulating at the system level. We'll also be looking at ways to >>> bypass their built-in "virtualized" HiDPI support in a later release >>> so that we can actually talk directly to display pixels regardless of >>> CP settings. >>> >>> This virtualized scaling is mitigated by the fact that this HiDPI >>> pixel stretching is happening on a HiDPI display and so any linear >>> interpolation is hidden by tiny pixel sizes. >>> >>> To that end, we are doing something similar with Windows scaling. >>> There are a number of places in the FX code that assume that it can >>> predict an integer translation from the FX code and so we always >>> render at integer scales so that integers in FX Scene coordinates map >>> to integers in rendered pixel coordinates. We'll try to fix those in >>> 9 so that we can do non-integer scaling, but until then there will be >>> the same disconnect between trying to line up with display pixels and >>> the actions of HiDPI as Mac OS already has... >>> >>> ...jim >>> >>> On 6/5/15 3:03 AM, Dr. Michael Paus wrote: >>>> I cannot provide any Windows specific feedback on HiDPI displays >>>> because >>>> I don't own one but I am working on a MacBook Pro with Retina display >>>> and thus would like to ask a few questions in this context. >>>> >>>> How are other platforms (Mac, Linux) affected by the changes you made >>>> for the Windows support? (On my Mac I noticed a severe performance drop >>>> when using 8u60 which may possibly be related to these changes.) >>>> >>>> Are any of the special system properties you mentioned also usable on >>>> other platforms? >>>> >>>> Is there any way now to find out what the current pixel scale factor >>>> is? >>>> Without that knowledge it is impossible to do proper graphics on any >>>> HiDPI screen. (E.g., you can't position graphic elements correctly in >>>> order to get crisp lines or you can't get a crisp snapshot of a node if >>>> you don't take special actions based on the pixel scale.) >> From kevin.rushforth at oracle.com Mon Jun 8 20:04:28 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 08 Jun 2015 13:04:28 -0700 Subject: 8u-dev and 9-dev unlocked -- only more week to 8u60 ZBB Message-ID: <5575F54C.50708@oracle.com> 8u-dev and 9-dev are unlocked following this week's sanity testing. As a reminder there is only 1 more week before 8u60 ZBB. No additional restriction are in place this week, but please refer to [1] and [2] for the 8u-dev commit policies after this week. -- Kevin [1] http://mail.openjdk.java.net/pipermail/openjfx-dev/2015-May/017296.html [2] https://wiki.openjdk.java.net/display/OpenJFX/8u60 From kevin.rushforth at oracle.com Mon Jun 8 20:09:25 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 08 Jun 2015 13:09:25 -0700 Subject: 8u-dev and 9-dev unlocked -- only 1 more week to 8u60 ZBB In-Reply-To: <5575F54C.50708@oracle.com> References: <5575F54C.50708@oracle.com> Message-ID: <5575F675.9060703@oracle.com> [fixing the grammatical errors in the last e-mail] 8u-dev and 9-dev are unlocked following this week's sanity testing. As a reminder there is only 1 more week before 8u60 ZBB. No additional restrictions are in place this week, but please refer to [1] and [2] for the 8u-dev commit policies after this week. -- Kevin [1] http://mail.openjdk.java.net/pipermail/openjfx-dev/2015-May/017296.html [2] https://wiki.openjdk.java.net/display/OpenJFX/8u60 From anton.tarasov at oracle.com Mon Jun 8 22:36:42 2015 From: anton.tarasov at oracle.com (Anton Tarasov) Date: Tue, 09 Jun 2015 01:36:42 +0300 Subject: JavaFx: WebView perfomance in Window 7 In-Reply-To: <1433451283.417807613@f165.i.mail.ru> References: <1433451283.417807613@f165.i.mail.ru> Message-ID: <557618FA.7010208@oracle.com> Hi Alexander, It shouldn't be a problem with WebView. Likely that JFX on your Win7_32bit falls back to software rendering pipeline. You can check that with passing "-Dprism.verbose=true" to JVM. You'll see something like this: [java] Prism pipeline init order: es2 sw [java] Using native-based Pisces rasterizer [java] Using dirty region optimizations [java] Not using texture mask for primitives [java] Not forcing power of 2 sizes for textures [java] Using hardware CLAMP_TO_ZERO mode [java] Opting in for HiDPI pixel scaling [java] Prism pipeline name = com.sun.prism.es2.ES2Pipeline [java] Loading ES2 native library ... prism_es2 [java] succeeded. (This is what I get on my Mac, on Windows it should be d3d instead of es2) Just check the pipeline name. It'll likely be SWPipeline (Software). Also, you can force JFX to use D3D (though, I suspect it will fail in your case) with "-Dprism.order=d3d". Why JFX fails (in case it does) with D3D on your GPU is another question (hope someone else may help you with it). Regards, Anton. On 04/06/15 23:54, ????????? ???????? wrote: > I have program and a webview which loads from http://lenta.ru site. I checked my program on centos 7.1 (64 bit, oracle jre 1.8.60) and on windows 7 (32 bit, oracle jre 1.8.60). There is a very very significant difference between them. On centos webview works a little bit slower then in firefox. However on win7 in comparison with centos perfomance is about 5-10 times worse. For example I can't scroll faster - I have to wait until the part of the page is rendered. How can it be solved (if it can)? > > From tbee at tbee.org Tue Jun 9 03:54:37 2015 From: tbee at tbee.org (Tom Eugelink) Date: Tue, 09 Jun 2015 05:54:37 +0200 Subject: right-to-left and clipping In-Reply-To: <55758E21.4050104@oracle.com> References: <5570A6FF.90409@tbee.org> <55741B63.9020204@tbee.org> <55758E21.4050104@oracle.com> Message-ID: <5576637D.6070505@tbee.org> https://javafx-jira.kenai.com/browse/RT-46188 I cannot add sources to the issue, so I've attached them to this email. Tom On 8-6-2015 14:44, Kevin Rushforth wrote: > At first glance, I agree that this seems like a bug. Please file a JIRA issue with your test program. > > Thanks. > > -- Kevin > > > Tom Eugelink wrote: >> Well, I spent quite some time on the clipping and while it I still can't get every situation to play nice, the basic code to get the clipping on a text working in right-to-left node orientation seems to be: >> >> clip.x = text.width - text.parent.width >> >> https://github.com/JFXtras/jfxtras/blob/8.0/jfxtras-agenda/src/main/java/jfxtras/internal/scene/control/skin/agenda/base24hour/LayoutHelp.java#L89 >> >> So it seems that clipping is not including in the automatic mirror when entering right-to-left mode. I would think this is a bug? >> >> Tom >> >> >> >> >> On 4-6-2015 21:29, Tom Eugelink wrote: >>> Someone posted an issue with JFXtras Agenda and right-to-left node orientation. I fixed the part where dragging an appointment was using scene based coordinates and thus did not play nice with the automatic mirroring when right-to-left is activated. >>> >>> However, I also see rendering issues where clipping is used on a Text node to limit the visible descriptive text to the width and height of the appointment. After some fiddling I come to the conclusion that clipping apparently is not fully included in the mirroring. If it were, then the clip should render correctly, but OTOH it is not at its unmirrored position either. This partial behavior confuses me. In one situation I need to move the clip a illigical 20 pixels to the right when right-to-left is active. Very strange. Any ideas or suggestions what causes clipping to behave differently in the mirroring? >>> >>> Tom >>> >>> >> From samir.hadzic.pro at gmail.com Tue Jun 9 09:25:25 2015 From: samir.hadzic.pro at gmail.com (Sam') Date: Tue, 9 Jun 2015 11:25:25 +0200 Subject: Trouble building JDK in debug mode In-Reply-To: <556F78F6.9010403@oracle.com> References: <556F78F6.9010403@oracle.com> Message-ID: I'm using 10.9.5 OS X Mavericks and Netbeans IDE. Well I just followed the wiki and did "gradle zips" in order to generate my zip file. Then I extract the ZIP bundle into the JRE. I'm quite sure I'm using my own jfxrt because I had a bug with JavaFX, then I modified the source code to resolve it. I created the zip et unzipped it in the JRE and the bug was gone. So that must prove that my modification were considered. Be still, I can't access to local variables in Netbeans. But shouldn't the compilation be longer when compiling with debug enabled? Because I don't see a difference in time nor in size (for jfxrt).. ----------------------------------------- Hadzic Samir Ing?nieur informatique 06 45 91 51 93 2015-06-04 0:00 GMT+02:00 Kevin Rushforth : > That should work. What platform are you using? How did you overlay your > JavaFX bits? Are you sure it is using your build of jfxrt.jar? > > -- Kevin > > > > Sam' wrote: > >> Sorry to create a new post, I have not managed to reply to the other topic >> since I had deactivated the notifications.. >> >> I am building the JDK on Mac. I have specified "CONF=DebugNative" with the >> case sensitive in the gradle.properties file. >> >> You are speaking about -PCONF, but in the gradle I have specified only >> "CONF" since it was written like that in the comment above.. >> >> Finally after that, I'm following the steps specified here ( >> >> https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX#BuildingOpenJFX-Overlay-JDK8 >> ) in order to deploy my JDK. Afterwards, when launching Netbeans, I cannot >> see the local variables of JavaFX source code and debug it properly. >> >> > From anton.nashatyrev at oracle.com Tue Jun 9 11:16:09 2015 From: anton.nashatyrev at oracle.com (Anton Nashatyrev) Date: Tue, 09 Jun 2015 14:16:09 +0300 Subject: [8u60, 9] Review request for RT-46189 [WebView] NPE when running WebEngine without WebView Message-ID: <5576CAF9.1020701@oracle.com> Hi Anton, could you please review the fix: https://javafx-jira.kenai.com/browse/RT-46189 http://cr.openjdk.java.net/~anashaty/RT-46189/webrev.00/ Thanks! Anton. From mp at jugs.org Tue Jun 9 19:45:02 2015 From: mp at jugs.org (Dr. Michael Paus) Date: Tue, 09 Jun 2015 21:45:02 +0200 Subject: Windows support for HiDPI displays, call for feedback and testing In-Reply-To: <5575DFEA.8040406@oracle.com> References: <557173FD.6090501@jugs.org> <55720B42.6040906@oracle.com> <55733E79.7060509@jugs.org> <55758DC3.5010905@oracle.com> <5575DFEA.8040406@oracle.com> Message-ID: <5577423E.2090002@jugs.org> Hi I finally managed to set up a non-retina Windows 7 box and get my software running on it. I tried it with JDK 8u45 and 8u60b18. It worked with 8u45 out of the box and the performance was ok. With 8u60 the whole application seemed to be broken because all tiles where displayed at only half their normal size. The reason for this was that the system suddenly behaves like a retina device and System.getRenderScale returns 2.0 instead of 1.0 as before. This problem was easy to fix though because I just had to erase the tile cache manually. The decision to download retina tiles (512x512) or normal tiles (256x256) is based on this factor. I did not expect such a change between runs of the software. After fixing this issue the application behaved in the same way as with 8u45. So a semi-retina :-) Windows box does not seem to suffer from the performance drop. But there is something else I observed on the Mac. I found out that the performance drop seems to be triggered by an effect that I have added to the group containing all the ImageViews. Its a ColorAdjust effect which I used to control the brightness of the map. As soon as I remove it from the group the performance is ok again. Something else that has the same effect is to activate the caching of the group but I wonder why that was not necessary before. But again I failed to create some simple example to show this effect. It drives me nuts. Michael PS: I also tried the options proposed by Kevin but they did not change anything and the output suggest that I am not using too much vram. Am 08.06.15 um 20:33 schrieb Jim Graham: > The only thing that might affect this was the change in the default > size of the vram pool, but that happened in 8u40 which predates both > of the builds involved in the experiment. I'd be curious as well to > hear how the application is affected on non-retina screens, and > Windows/D3D for that matter... > > ...jim > > On 6/8/15 5:42 AM, Kevin Rushforth wrote: >> Does the same slowdown happen on a non-Retina system? >> >> How large is your image? How large are the individual tiles? One thing >> that occurs to me is that your application might be thrashing texture >> memory (although I can't think of anything that changed in 8u60 that >> would affect this). You might try the following debug flag: >> >> java -Dprism.poolstats=true >> >> and see if there is a lot of thrashing of texture memory. Also, you can >> increase the memory that will be used for textures to, say, 1Gbyte >> (default is 512Mbytes) by: >> >> java -Dprism.maxvram=1g >> >> and see if that makes a difference. Jim might have additional >> suggestions. >> >> -- Kevin >> >> >> Dr. Michael Paus wrote: >>> Many thanks for the clarification. >>> >>> I'd also like to be more specific on the performance drop I observed >>> but I have to >>> admit that I don't have any idea what is going on there. The only >>> thing I can say >>> for sure is that I can consistently reproduce this drop in performance >>> by switching >>> between 8u45 and 8u60 (tested with b08 and b15). >>> >>> My application contains a map view (something similar to Google Maps) >>> which >>> displays an area of retina map tiles. By dragging with the mouse I can >>> move this >>> map around within the map pane. This works smoothly with 8u45 but is >>> completely >>> shaky with 8u60. I even experimented with various techniques to >>> implement such >>> a map view (single large image, single large canvas, individual >>> images/canvases for >>> each map tile) and they all show the same behavior, so it cannot be >>> something which >>> is specific to a particular implementation approach. During my test >>> all tiles where already >>> cached in memory, so I can exclude any file or network IO related >>> issues. >>> >>> I tried to implement a little example where I just move around a large >>> image but in >>> this simple scenario the problem does not show up. >>> >>> So in order to do a bit more precise measuring I added an >>> AnimationTimer to my map pane >>> which I use to compute a new position of the map for each frame so >>> that a point on the map >>> moves along a circle. This helps to show the performance drop more >>> precisely than moving >>> around the map by hand. This is a smooth movement with 8u45 but shaky >>> with 8u60. >>> >>> But one other observation puzzles me completely. The handle-method of >>> the timer is called with >>> a frame rate of 60 Hz even though the graphics output is shaky and has >>> a visual frame rate >>> of something between 2 - 5 Hz. It is new to me that something like >>> this is technically possible. >>> It looks as if the system is running at full speed but skips >>> displaying most of the generated >>> frames for some reason. Is such a behavior possible at all? >>> >>> Am 05.06.15 um 22:49 schrieb Jim Graham: >>>> I actually use a retina MBP for testing - dual booting Windows and >>>> MacOS. >>>> >>>> There should be no changes at all on other platforms, particularly in >>>> regard to rendering speed. There was one small regression on Linux >>>> resulting in a bad first paint due to asynchronous initialization of >>>> the Window size, but no performance issues. Can you be more specific >>>> about where you see the performance drop? What kind of scene >>>> graph/animation? >>>> >>>> The system properties are all Windows specific, thus the "glass.win" >>>> prefix. In 9 we might generalize all of the HiDPI support and offer >>>> something more centralized, but those are just there for testing the >>>> new Windows support for now. We'll also look at how to advertise the >>>> pixel scaling to applications at that time. >>>> >>>> One thing to note is that the way that Mac retina support is done, if >>>> the user ever sets their control panel to anything other than "just >>>> pick the best conditions for this display" then there is >>>> pixel-scaling going on behind the scenes in the OS, so any attempts >>>> to try to line up with pixels will be muddied by the virtual DPI they >>>> are emulating at the system level. We'll also be looking at ways to >>>> bypass their built-in "virtualized" HiDPI support in a later release >>>> so that we can actually talk directly to display pixels regardless of >>>> CP settings. >>>> >>>> This virtualized scaling is mitigated by the fact that this HiDPI >>>> pixel stretching is happening on a HiDPI display and so any linear >>>> interpolation is hidden by tiny pixel sizes. >>>> >>>> To that end, we are doing something similar with Windows scaling. >>>> There are a number of places in the FX code that assume that it can >>>> predict an integer translation from the FX code and so we always >>>> render at integer scales so that integers in FX Scene coordinates map >>>> to integers in rendered pixel coordinates. We'll try to fix those in >>>> 9 so that we can do non-integer scaling, but until then there will be >>>> the same disconnect between trying to line up with display pixels and >>>> the actions of HiDPI as Mac OS already has... >>>> >>>> ...jim >>>> >>>> On 6/5/15 3:03 AM, Dr. Michael Paus wrote: >>>>> I cannot provide any Windows specific feedback on HiDPI displays >>>>> because >>>>> I don't own one but I am working on a MacBook Pro with Retina display >>>>> and thus would like to ask a few questions in this context. >>>>> >>>>> How are other platforms (Mac, Linux) affected by the changes you made >>>>> for the Windows support? (On my Mac I noticed a severe performance >>>>> drop >>>>> when using 8u60 which may possibly be related to these changes.) >>>>> >>>>> Are any of the special system properties you mentioned also usable on >>>>> other platforms? >>>>> >>>>> Is there any way now to find out what the current pixel scale factor >>>>> is? >>>>> Without that knowledge it is impossible to do proper graphics on any >>>>> HiDPI screen. (E.g., you can't position graphic elements correctly in >>>>> order to get crisp lines or you can't get a crisp snapshot of a >>>>> node if >>>>> you don't take special actions based on the pixel scale.) >>> From james.graham at oracle.com Tue Jun 9 22:19:42 2015 From: james.graham at oracle.com (Jim Graham) Date: Tue, 09 Jun 2015 15:19:42 -0700 Subject: Windows support for HiDPI displays, call for feedback and testing In-Reply-To: <5577423E.2090002@jugs.org> References: <557173FD.6090501@jugs.org> <55720B42.6040906@oracle.com> <55733E79.7060509@jugs.org> <55758DC3.5010905@oracle.com> <5575DFEA.8040406@oracle.com> <5577423E.2090002@jugs.org> Message-ID: <5577667E.8010003@oracle.com> Hi Michael, I'm not sure I understand the problem you were having with getRenderScale. What is "System.getRenderScale()"? Where are you getting that from? What is the tile cache and why was it affected by the hidden scale that we have been intending to not affect applications in any way (other than what the user can see visually on the screen)? Is this something you implement in your code? Since we apply the render scale under the covers it shouldn't matter what size your images are - they should be displayed scaled by the render scale. The only "scaling" that affects images is if you request foo. and we find a foo at 2x. then we will load it and internally downscale it by 2x when we render it, but that should be the same on both Mac and Windows. Just to be sure I understood that last paragraph correctly - adding a ColorAdjust to a group of ImageViews makes it slow down on 8u60, but not on 8u40. Having the same group without the ColorAdjust does not affect performance between 8u40 and 8u60. Setting the cache hints on the group slows it down on 8u60, but not 8u40. Did I get all of that correctly? ...jim On 6/9/2015 12:45 PM, Dr. Michael Paus wrote: > Hi > I finally managed to set up a non-retina Windows 7 box and > get my software running on it. I tried it with JDK 8u45 and 8u60b18. > > It worked with 8u45 out of the box and the performance was ok. > > With 8u60 the whole application seemed to be broken because all > tiles where displayed at only half their normal size. The reason for this > was that the system suddenly behaves like a retina device and > System.getRenderScale returns 2.0 instead of 1.0 as before. > This problem was easy to fix though because I just had to erase > the tile cache manually. The decision to download retina tiles > (512x512) or normal tiles (256x256) is based on this factor. > I did not expect such a change between runs of the software. > > After fixing this issue the application behaved in the same way > as with 8u45. So a semi-retina :-) Windows box does not seem to > suffer from the performance drop. > > But there is something else I observed on the Mac. I found out > that the performance drop seems to be triggered by an effect > that I have added to the group containing all the ImageViews. > Its a ColorAdjust effect which I used to control the brightness > of the map. As soon as I remove it from the group the performance > is ok again. Something else that has the same effect is to activate > the caching of the group but I wonder why that was not necessary > before. > > But again I failed to create some simple example to show this > effect. It drives me nuts. > > Michael > > PS: I also tried the options proposed by Kevin but they did not change > anything > and the output suggest that I am not using too much vram. > > > Am 08.06.15 um 20:33 schrieb Jim Graham: >> The only thing that might affect this was the change in the default >> size of the vram pool, but that happened in 8u40 which predates both >> of the builds involved in the experiment. I'd be curious as well to >> hear how the application is affected on non-retina screens, and >> Windows/D3D for that matter... >> >> ...jim >> >> On 6/8/15 5:42 AM, Kevin Rushforth wrote: >>> Does the same slowdown happen on a non-Retina system? >>> >>> How large is your image? How large are the individual tiles? One thing >>> that occurs to me is that your application might be thrashing texture >>> memory (although I can't think of anything that changed in 8u60 that >>> would affect this). You might try the following debug flag: >>> >>> java -Dprism.poolstats=true >>> >>> and see if there is a lot of thrashing of texture memory. Also, you can >>> increase the memory that will be used for textures to, say, 1Gbyte >>> (default is 512Mbytes) by: >>> >>> java -Dprism.maxvram=1g >>> >>> and see if that makes a difference. Jim might have additional >>> suggestions. >>> >>> -- Kevin >>> >>> >>> Dr. Michael Paus wrote: >>>> Many thanks for the clarification. >>>> >>>> I'd also like to be more specific on the performance drop I observed >>>> but I have to >>>> admit that I don't have any idea what is going on there. The only >>>> thing I can say >>>> for sure is that I can consistently reproduce this drop in performance >>>> by switching >>>> between 8u45 and 8u60 (tested with b08 and b15). >>>> >>>> My application contains a map view (something similar to Google Maps) >>>> which >>>> displays an area of retina map tiles. By dragging with the mouse I can >>>> move this >>>> map around within the map pane. This works smoothly with 8u45 but is >>>> completely >>>> shaky with 8u60. I even experimented with various techniques to >>>> implement such >>>> a map view (single large image, single large canvas, individual >>>> images/canvases for >>>> each map tile) and they all show the same behavior, so it cannot be >>>> something which >>>> is specific to a particular implementation approach. During my test >>>> all tiles where already >>>> cached in memory, so I can exclude any file or network IO related >>>> issues. >>>> >>>> I tried to implement a little example where I just move around a large >>>> image but in >>>> this simple scenario the problem does not show up. >>>> >>>> So in order to do a bit more precise measuring I added an >>>> AnimationTimer to my map pane >>>> which I use to compute a new position of the map for each frame so >>>> that a point on the map >>>> moves along a circle. This helps to show the performance drop more >>>> precisely than moving >>>> around the map by hand. This is a smooth movement with 8u45 but shaky >>>> with 8u60. >>>> >>>> But one other observation puzzles me completely. The handle-method of >>>> the timer is called with >>>> a frame rate of 60 Hz even though the graphics output is shaky and has >>>> a visual frame rate >>>> of something between 2 - 5 Hz. It is new to me that something like >>>> this is technically possible. >>>> It looks as if the system is running at full speed but skips >>>> displaying most of the generated >>>> frames for some reason. Is such a behavior possible at all? >>>> >>>> Am 05.06.15 um 22:49 schrieb Jim Graham: >>>>> I actually use a retina MBP for testing - dual booting Windows and >>>>> MacOS. >>>>> >>>>> There should be no changes at all on other platforms, particularly in >>>>> regard to rendering speed. There was one small regression on Linux >>>>> resulting in a bad first paint due to asynchronous initialization of >>>>> the Window size, but no performance issues. Can you be more specific >>>>> about where you see the performance drop? What kind of scene >>>>> graph/animation? >>>>> >>>>> The system properties are all Windows specific, thus the "glass.win" >>>>> prefix. In 9 we might generalize all of the HiDPI support and offer >>>>> something more centralized, but those are just there for testing the >>>>> new Windows support for now. We'll also look at how to advertise the >>>>> pixel scaling to applications at that time. >>>>> >>>>> One thing to note is that the way that Mac retina support is done, if >>>>> the user ever sets their control panel to anything other than "just >>>>> pick the best conditions for this display" then there is >>>>> pixel-scaling going on behind the scenes in the OS, so any attempts >>>>> to try to line up with pixels will be muddied by the virtual DPI they >>>>> are emulating at the system level. We'll also be looking at ways to >>>>> bypass their built-in "virtualized" HiDPI support in a later release >>>>> so that we can actually talk directly to display pixels regardless of >>>>> CP settings. >>>>> >>>>> This virtualized scaling is mitigated by the fact that this HiDPI >>>>> pixel stretching is happening on a HiDPI display and so any linear >>>>> interpolation is hidden by tiny pixel sizes. >>>>> >>>>> To that end, we are doing something similar with Windows scaling. >>>>> There are a number of places in the FX code that assume that it can >>>>> predict an integer translation from the FX code and so we always >>>>> render at integer scales so that integers in FX Scene coordinates map >>>>> to integers in rendered pixel coordinates. We'll try to fix those in >>>>> 9 so that we can do non-integer scaling, but until then there will be >>>>> the same disconnect between trying to line up with display pixels and >>>>> the actions of HiDPI as Mac OS already has... >>>>> >>>>> ...jim >>>>> >>>>> On 6/5/15 3:03 AM, Dr. Michael Paus wrote: >>>>>> I cannot provide any Windows specific feedback on HiDPI displays >>>>>> because >>>>>> I don't own one but I am working on a MacBook Pro with Retina display >>>>>> and thus would like to ask a few questions in this context. >>>>>> >>>>>> How are other platforms (Mac, Linux) affected by the changes you made >>>>>> for the Windows support? (On my Mac I noticed a severe performance >>>>>> drop >>>>>> when using 8u60 which may possibly be related to these changes.) >>>>>> >>>>>> Are any of the special system properties you mentioned also usable on >>>>>> other platforms? >>>>>> >>>>>> Is there any way now to find out what the current pixel scale factor >>>>>> is? >>>>>> Without that knowledge it is impossible to do proper graphics on any >>>>>> HiDPI screen. (E.g., you can't position graphic elements correctly in >>>>>> order to get crisp lines or you can't get a crisp snapshot of a >>>>>> node if >>>>>> you don't take special actions based on the pixel scale.) >>>> > From anton.tarasov at oracle.com Tue Jun 9 22:23:51 2015 From: anton.tarasov at oracle.com (Anton V. Tarasov) Date: Wed, 10 Jun 2015 01:23:51 +0300 Subject: [9] request for review: RT-46191 [WebView] zooming google maps hangs Message-ID: <55776777.4030600@oracle.com> Kevin, Jim, Please review the fix: JIRA: https://javafx-jira.kenai.com/browse/RT-46191 webrev: http://cr.openjdk.java.net/~ant/RT-46191/webrev.0 Thanks, Anton. From kevin.rushforth at oracle.com Wed Jun 10 00:20:20 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 09 Jun 2015 17:20:20 -0700 Subject: [8u60,9] review request: RT-39569: ConcurrentModificationException when closing APPLICATION_MODAL dialog Message-ID: <557782C4.4050502@oracle.com> David or Morris, Please review: https://javafx-jira.kenai.com/browse/RT-39569 http://cr.openjdk.java.net/~kcr/RT-39569/webrev.00/ -- Kevin From mp at jugs.org Wed Jun 10 07:39:10 2015 From: mp at jugs.org (Dr. Michael Paus) Date: Wed, 10 Jun 2015 09:39:10 +0200 Subject: Windows support for HiDPI displays, call for feedback and testing In-Reply-To: <5577667E.8010003@oracle.com> References: <557173FD.6090501@jugs.org> <55720B42.6040906@oracle.com> <55733E79.7060509@jugs.org> <55758DC3.5010905@oracle.com> <5575DFEA.8040406@oracle.com> <5577423E.2090002@jugs.org> <5577667E.8010003@oracle.com> Message-ID: <5577E99E.1080205@jugs.org> Hi Jim let me answer your last questions first. > Just to be sure I understood that last paragraph correctly > - adding a ColorAdjust to a group of ImageViews makes it slow down on 8u60, but not on 8u40. Yes, but I was not able to reproduce that behavior in a simple example. Otherwise I would have written an official bug report already. > Having the same group without the ColorAdjust does not affect performance between 8u40 and 8u60. Yes. > Setting the cache hints on the group slows it down on 8u60, but not 8u40. No. Setting group.setCache(true) also fixes the problem. So I currently have too options on the Mac. Either eliminate the ColorAdjust effect OR setCache(true). The first one is no real option because I need the functionality and the second seemed to be a waste of memory to me and was not needed until now. Now to your other questions. There was typo in my mail. Of course I wanted to say "Screen.getRenderScale" and not "System...". (I know this is private but read on ...) If I understand you correctly you are saying that all this HiDPI-handling is done under the covers and should be fully transparent to the programmer, whereas I think that this is not possible for non-trivial cases. (Is this foo. versus foo at 2x. handling documented anywhere?) Just a few questions: How do you determine which images to download from a server or database if you don't know the render scale? How do you handle cases where your images are read from a stream where you do not have a @2x name extension? (Same for other non-named image sources.) How do you draw thin (single pixel wide) lines if you don't know the render scale? How do you display an image at exactly 100% scale (like the option in Photoshop for example) if you don't know the render scale? How do you take a snapshot of a node at full resolution? For example a 500x500 canvas will be internally backed by a 1000x1000 image which looks crisp on your Retina screen. When you now take a snapshot of this canvas it will be a blurry 500x500 image. (At least that was the result when I last tried it.) There are workarounds for all these issues but only if you know the render scale. Michael Am 10.06.15 um 00:19 schrieb Jim Graham: > Hi Michael, > > I'm not sure I understand the problem you were having with > getRenderScale. > > What is "System.getRenderScale()"? Where are you getting that from? > > What is the tile cache and why was it affected by the hidden scale > that we have been intending to not affect applications in any way > (other than what the user can see visually on the screen)? Is this > something you implement in your code? > > Since we apply the render scale under the covers it shouldn't matter > what size your images are - they should be displayed scaled by the > render scale. The only "scaling" that affects images is if you > request foo. and we find a foo at 2x. then we will load > it and internally downscale it by 2x when we render it, but that > should be the same on both Mac and Windows. > > Just to be sure I understood that last paragraph correctly - adding a > ColorAdjust to a group of ImageViews makes it slow down on 8u60, but > not on 8u40. Having the same group without the ColorAdjust does not > affect performance between 8u40 and 8u60. Setting the cache hints on > the group slows it down on 8u60, but not 8u40. Did I get all of that > correctly? > > ...jim > > On 6/9/2015 12:45 PM, Dr. Michael Paus wrote: >> Hi >> I finally managed to set up a non-retina Windows 7 box and >> get my software running on it. I tried it with JDK 8u45 and 8u60b18. >> >> It worked with 8u45 out of the box and the performance was ok. >> >> With 8u60 the whole application seemed to be broken because all >> tiles where displayed at only half their normal size. The reason for >> this >> was that the system suddenly behaves like a retina device and >> System.getRenderScale returns 2.0 instead of 1.0 as before. >> This problem was easy to fix though because I just had to erase >> the tile cache manually. The decision to download retina tiles >> (512x512) or normal tiles (256x256) is based on this factor. >> I did not expect such a change between runs of the software. >> >> After fixing this issue the application behaved in the same way >> as with 8u45. So a semi-retina :-) Windows box does not seem to >> suffer from the performance drop. >> >> But there is something else I observed on the Mac. I found out >> that the performance drop seems to be triggered by an effect >> that I have added to the group containing all the ImageViews. >> Its a ColorAdjust effect which I used to control the brightness >> of the map. As soon as I remove it from the group the performance >> is ok again. Something else that has the same effect is to activate >> the caching of the group but I wonder why that was not necessary >> before. >> >> But again I failed to create some simple example to show this >> effect. It drives me nuts. >> >> Michael >> >> PS: I also tried the options proposed by Kevin but they did not change >> anything >> and the output suggest that I am not using too much vram. >> >> >> Am 08.06.15 um 20:33 schrieb Jim Graham: >>> The only thing that might affect this was the change in the default >>> size of the vram pool, but that happened in 8u40 which predates both >>> of the builds involved in the experiment. I'd be curious as well to >>> hear how the application is affected on non-retina screens, and >>> Windows/D3D for that matter... >>> >>> ...jim >>> >>> On 6/8/15 5:42 AM, Kevin Rushforth wrote: >>>> Does the same slowdown happen on a non-Retina system? >>>> >>>> How large is your image? How large are the individual tiles? One thing >>>> that occurs to me is that your application might be thrashing texture >>>> memory (although I can't think of anything that changed in 8u60 that >>>> would affect this). You might try the following debug flag: >>>> >>>> java -Dprism.poolstats=true >>>> >>>> and see if there is a lot of thrashing of texture memory. Also, you >>>> can >>>> increase the memory that will be used for textures to, say, 1Gbyte >>>> (default is 512Mbytes) by: >>>> >>>> java -Dprism.maxvram=1g >>>> >>>> and see if that makes a difference. Jim might have additional >>>> suggestions. >>>> >>>> -- Kevin >>>> >>>> >>>> Dr. Michael Paus wrote: >>>>> Many thanks for the clarification. >>>>> >>>>> I'd also like to be more specific on the performance drop I observed >>>>> but I have to >>>>> admit that I don't have any idea what is going on there. The only >>>>> thing I can say >>>>> for sure is that I can consistently reproduce this drop in >>>>> performance >>>>> by switching >>>>> between 8u45 and 8u60 (tested with b08 and b15). >>>>> >>>>> My application contains a map view (something similar to Google Maps) >>>>> which >>>>> displays an area of retina map tiles. By dragging with the mouse I >>>>> can >>>>> move this >>>>> map around within the map pane. This works smoothly with 8u45 but is >>>>> completely >>>>> shaky with 8u60. I even experimented with various techniques to >>>>> implement such >>>>> a map view (single large image, single large canvas, individual >>>>> images/canvases for >>>>> each map tile) and they all show the same behavior, so it cannot be >>>>> something which >>>>> is specific to a particular implementation approach. During my test >>>>> all tiles where already >>>>> cached in memory, so I can exclude any file or network IO related >>>>> issues. >>>>> >>>>> I tried to implement a little example where I just move around a >>>>> large >>>>> image but in >>>>> this simple scenario the problem does not show up. >>>>> >>>>> So in order to do a bit more precise measuring I added an >>>>> AnimationTimer to my map pane >>>>> which I use to compute a new position of the map for each frame so >>>>> that a point on the map >>>>> moves along a circle. This helps to show the performance drop more >>>>> precisely than moving >>>>> around the map by hand. This is a smooth movement with 8u45 but shaky >>>>> with 8u60. >>>>> >>>>> But one other observation puzzles me completely. The handle-method of >>>>> the timer is called with >>>>> a frame rate of 60 Hz even though the graphics output is shaky and >>>>> has >>>>> a visual frame rate >>>>> of something between 2 - 5 Hz. It is new to me that something like >>>>> this is technically possible. >>>>> It looks as if the system is running at full speed but skips >>>>> displaying most of the generated >>>>> frames for some reason. Is such a behavior possible at all? >>>>> >>>>> Am 05.06.15 um 22:49 schrieb Jim Graham: >>>>>> I actually use a retina MBP for testing - dual booting Windows and >>>>>> MacOS. >>>>>> >>>>>> There should be no changes at all on other platforms, >>>>>> particularly in >>>>>> regard to rendering speed. There was one small regression on Linux >>>>>> resulting in a bad first paint due to asynchronous initialization of >>>>>> the Window size, but no performance issues. Can you be more >>>>>> specific >>>>>> about where you see the performance drop? What kind of scene >>>>>> graph/animation? >>>>>> >>>>>> The system properties are all Windows specific, thus the "glass.win" >>>>>> prefix. In 9 we might generalize all of the HiDPI support and offer >>>>>> something more centralized, but those are just there for testing the >>>>>> new Windows support for now. We'll also look at how to advertise >>>>>> the >>>>>> pixel scaling to applications at that time. >>>>>> >>>>>> One thing to note is that the way that Mac retina support is >>>>>> done, if >>>>>> the user ever sets their control panel to anything other than "just >>>>>> pick the best conditions for this display" then there is >>>>>> pixel-scaling going on behind the scenes in the OS, so any attempts >>>>>> to try to line up with pixels will be muddied by the virtual DPI >>>>>> they >>>>>> are emulating at the system level. We'll also be looking at ways to >>>>>> bypass their built-in "virtualized" HiDPI support in a later release >>>>>> so that we can actually talk directly to display pixels >>>>>> regardless of >>>>>> CP settings. >>>>>> >>>>>> This virtualized scaling is mitigated by the fact that this HiDPI >>>>>> pixel stretching is happening on a HiDPI display and so any linear >>>>>> interpolation is hidden by tiny pixel sizes. >>>>>> >>>>>> To that end, we are doing something similar with Windows scaling. >>>>>> There are a number of places in the FX code that assume that it can >>>>>> predict an integer translation from the FX code and so we always >>>>>> render at integer scales so that integers in FX Scene coordinates >>>>>> map >>>>>> to integers in rendered pixel coordinates. We'll try to fix >>>>>> those in >>>>>> 9 so that we can do non-integer scaling, but until then there >>>>>> will be >>>>>> the same disconnect between trying to line up with display pixels >>>>>> and >>>>>> the actions of HiDPI as Mac OS already has... >>>>>> >>>>>> ...jim >>>>>> >>>>>> On 6/5/15 3:03 AM, Dr. Michael Paus wrote: >>>>>>> I cannot provide any Windows specific feedback on HiDPI displays >>>>>>> because >>>>>>> I don't own one but I am working on a MacBook Pro with Retina >>>>>>> display >>>>>>> and thus would like to ask a few questions in this context. >>>>>>> >>>>>>> How are other platforms (Mac, Linux) affected by the changes you >>>>>>> made >>>>>>> for the Windows support? (On my Mac I noticed a severe performance >>>>>>> drop >>>>>>> when using 8u60 which may possibly be related to these changes.) >>>>>>> >>>>>>> Are any of the special system properties you mentioned also >>>>>>> usable on >>>>>>> other platforms? >>>>>>> >>>>>>> Is there any way now to find out what the current pixel scale >>>>>>> factor >>>>>>> is? >>>>>>> Without that knowledge it is impossible to do proper graphics on >>>>>>> any >>>>>>> HiDPI screen. (E.g., you can't position graphic elements >>>>>>> correctly in >>>>>>> order to get crisp lines or you can't get a crisp snapshot of a >>>>>>> node if >>>>>>> you don't take special actions based on the pixel scale.) >>>>> >> From ooo_saturn7 at mail.ru Wed Jun 10 11:56:36 2015 From: ooo_saturn7 at mail.ru (=?UTF-8?B?0JDQu9C10LrRgdCw0L3QtNGAINCh0LLQuNGA0LjQtNC+0LI=?=) Date: Wed, 10 Jun 2015 14:56:36 +0300 Subject: =?UTF-8?B?SmF2YUZ4OiBub3QgU3RyaW5nIG51bGwgdmFsdWVzIGFuZCBiaW5kaW5n?= Message-ID: <1433937396.574617661@f137.i.mail.ru> I have a POJO class Test that has Integer and String fields (all of them can be null). And I have javafx form with TextFields. To bind Test fields to text fields I use adapter. Now I create an instance of Test (all fields will be null) Test test=new Test(); TestAdapter adapter=newTestAdapter(test); //the following line works, although String name=null nameTextField.textProperty().bindBidirectional(adapter.getNameProperty()); //the following line throws exception Integer id=null idTextField.textProperty().bindBidirectional(adapter.getIdProperty(),newNumberStringConverter()); This is the exception I get: >Exception in thread "JavaFX Application Thread" java.lang.NullPointerException at javafx.beans.property.adapter.JavaBeanIntegerProperty.lambda$get$38(JavaBeanIntegerProperty.java:95) at java.security.AccessController.doPrivileged(Native Method) at javafx.beans.property.adapter.JavaBeanIntegerProperty.get(JavaBeanIntegerProperty.java:92) at javafx.beans.binding.IntegerExpression.getValue(IntegerExpression.java:69) at javafx.beans.binding.IntegerExpression.getValue(IntegerExpression.java:44) at com.sun.javafx.binding.BidirectionalBinding.bind(BidirectionalBinding.java:88) at javafx.beans.binding.Bindings.bindBidirectional(Bindings.java:869) at javafx.beans.property.StringProperty.bindBidirectional(StringProperty.java:111) Everything works ok if I do this way test.setId(0); idTextField.textProperty().bindBidirectional(adapter.getIdProperty(),newNumberStringConverter()); However, you can imagine how ugly this solution is - I loose all the abilities of null value and for my CRUD application it is death. Please, help me to understand how to work with Integer(and Others?) null values with bindings and adapters. -- ????????? ???????? From tom.schindl at bestsolution.at Wed Jun 10 12:15:07 2015 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Wed, 10 Jun 2015 14:15:07 +0200 Subject: JavaFx: not String null values and binding In-Reply-To: <1433937396.574617661@f137.i.mail.ru> References: <1433937396.574617661@f137.i.mail.ru> Message-ID: <55782A4B.1000000@bestsolution.at> So if the value is null-able IntegerProperty is not the right type! You need to use a ObjectProperty but this is more of a user forum question. Tom On 10.06.15 13:56, ????????? ???????? wrote: > > I have a POJO class Test that has Integer and String fields (all of them can be null). And I have javafx form with TextFields. To bind Test fields to text fields I use adapter. Now I create an instance of Test (all fields will be null) > Test test=new Test(); > TestAdapter adapter=newTestAdapter(test); > //the following line works, although String name=null > nameTextField.textProperty().bindBidirectional(adapter.getNameProperty()); > //the following line throws exception Integer id=null > idTextField.textProperty().bindBidirectional(adapter.getIdProperty(),newNumberStringConverter()); > This is the exception I get: >> Exception in thread "JavaFX Application Thread" java.lang.NullPointerException at javafx.beans.property.adapter.JavaBeanIntegerProperty.lambda$get$38(JavaBeanIntegerProperty.java:95) at java.security.AccessController.doPrivileged(Native Method) at javafx.beans.property.adapter.JavaBeanIntegerProperty.get(JavaBeanIntegerProperty.java:92) at javafx.beans.binding.IntegerExpression.getValue(IntegerExpression.java:69) at javafx.beans.binding.IntegerExpression.getValue(IntegerExpression.java:44) at com.sun.javafx.binding.BidirectionalBinding.bind(BidirectionalBinding.java:88) at javafx.beans.binding.Bindings.bindBidirectional(Bindings.java:869) at javafx.beans.property.StringProperty.bindBidirectional(StringProperty.java:111) > Everything works ok if I do this way > test.setId(0); > idTextField.textProperty().bindBidirectional(adapter.getIdProperty(),newNumberStringConverter()); > However, you can imagine how ugly this solution is - I loose all the abilities of null value and for my CRUD application it is death. Please, help me to understand how to work with Integer(and Others?) null values with bindings and adapters. > > -- Thomas Schindl, CTO BestSolution.at EDV Systemhaus GmbH Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck http://www.bestsolution.at/ Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck From johan at lodgon.com Wed Jun 10 14:19:02 2015 From: johan at lodgon.com (Johan Vos) Date: Wed, 10 Jun 2015 16:19:02 +0200 Subject: RESCHEDULED -> Re: Reminder: JavaFX JIRA issues moving to JBS tomorrow, June 5 In-Reply-To: <5570EB7F.5060301@oracle.com> References: <555E6389.30008@oracle.com> <5570612E.7040203@oracle.com> <5570EB7F.5060301@oracle.com> Message-ID: The existing issue tracker is still read-only now. Will this stay read-only, or will there be a small window in which we can write? - Johan 2015-06-05 2:21 GMT+02:00 Kevin Rushforth : > Due to a bug discovered in the migration script during the dry run, we > will need to reschedule the migration. Exact date TBD as we will need to > re-run series of testing. > > Our tentative target will be next Friday, June 12. Once confirmed, we > will send another heads-up notice. > > -- Kevin > > > Kevin Rushforth wrote: > >> As a reminder, the migration of FX bugs to JBS will happen tomorrow. The >> RT project in the JavaFX JIRA issue tracker will become read-only at 9:00 >> am Pacific time tomorrow morning. We expect the migration to be complete >> some time in the afternoon tomorrow. >> >> Also, our infrastructure team is planning to enable URL redirects from >> javafx-jira at kenai.com to bugs.java.com tomorrow afternoon, so unless >> they run into problems with this, existing URL links will work. >> >> -- Kevin >> >> >> Kevin Rushforth wrote: >> >>> As previously announced [1] we are in the process of migrating JavaFX >>> bugs to the JDK Bug System (JBS) [2] in the JDK project. >>> >>> The target date for this migration is Friday, June 5. The existing >>> JavaFX bug tracker will become permanently read-only on that date, and will >>> be decommissioned some time after the transition is complete. After >>> javafx-jira.kenai.com is retired, we will explore the feasibility of >>> setting up an automatic redirect to bugs.openjdk.java.net so that >>> existing URLs will work. In any case, typing in an old RT-nnnnn number into >>> JBS will open the bug even after it is mapped into the JDK project. >>> >>> -- Kevin >>> >>> [1] >>> http://mail.openjdk.java.net/pipermail/openjfx-dev/2015-April/017083.html >>> [2] https://bugs.openjdk.java.net/ >>> >>> From johan at lodgon.com Wed Jun 10 14:20:05 2015 From: johan at lodgon.com (Johan Vos) Date: Wed, 10 Jun 2015 16:20:05 +0200 Subject: Dialog on iOS RT-40822 Message-ID: I have a fix for the missing support for enterNestedEventLoop on iOS: http://cr.openjdk.java.net/~jvos/RT-40822/webrev.00/ With this fix, Dialogs in iOS are working. - Johan From kevin.rushforth at oracle.com Wed Jun 10 14:52:36 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 10 Jun 2015 07:52:36 -0700 Subject: RESCHEDULED -> Re: Reminder: JavaFX JIRA issues moving to JBS tomorrow, June 5 In-Reply-To: References: <555E6389.30008@oracle.com> <5570612E.7040203@oracle.com> <5570EB7F.5060301@oracle.com> Message-ID: <55784F34.7030300@oracle.com> The FX JIRA issue tracker is still read-write. Are you having trouble accessing it? -- Kevin Johan Vos wrote: > The existing issue tracker is still read-only now. Will this stay > read-only, or will there be a small window in which we can write? > > - Johan > > > 2015-06-05 2:21 GMT+02:00 Kevin Rushforth >: > > Due to a bug discovered in the migration script during the dry > run, we will need to reschedule the migration. Exact date TBD as > we will need to re-run series of testing. > > Our tentative target will be next Friday, June 12. Once > confirmed, we will send another heads-up notice. > > -- Kevin > > > Kevin Rushforth wrote: > > As a reminder, the migration of FX bugs to JBS will happen > tomorrow. The RT project in the JavaFX JIRA issue tracker will > become read-only at 9:00 am Pacific time tomorrow morning. We > expect the migration to be complete some time in the afternoon > tomorrow. > > Also, our infrastructure team is planning to enable URL > redirects from javafx-jira at kenai.com > to bugs.java.com > tomorrow afternoon, so unless they run > into problems with this, existing URL links will work. > > -- Kevin > > > Kevin Rushforth wrote: > > As previously announced [1] we are in the process of > migrating JavaFX bugs to the JDK Bug System (JBS) [2] in > the JDK project. > > The target date for this migration is Friday, June 5. The > existing JavaFX bug tracker will become permanently > read-only on that date, and will be decommissioned some > time after the transition is complete. After > javafx-jira.kenai.com is > retired, we will explore the feasibility of setting up an > automatic redirect to bugs.openjdk.java.net > so that existing URLs will > work. In any case, typing in an old RT-nnnnn number into > JBS will open the bug even after it is mapped into the JDK > project. > > -- Kevin > > [1] > http://mail.openjdk.java.net/pipermail/openjfx-dev/2015-April/017083.html > > [2] https://bugs.openjdk.java.net/ > > From kirill.kirichenko at oracle.com Wed Jun 10 16:43:28 2015 From: kirill.kirichenko at oracle.com (Kirill Kirichenko) Date: Wed, 10 Jun 2015 19:43:28 +0300 Subject: [8u60, 9] review request: RT-46186: FX application hangs on exit when media gets stuck Message-ID: <55786930.9080701@oracle.com> Hi Alexander, Kevin. Could you please review the following fix? jira: https://javafx-jira.kenai.com/browse/RT-46186 wevrev: http://cr.openjdk.java.net/~stayer/RT-46186/webrev.00/ Please review and comment in JIRA if it's still in read-write mode ? K From kevin.rushforth at oracle.com Wed Jun 10 16:52:59 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 10 Jun 2015 09:52:59 -0700 Subject: [8u60,9] review request: RT-46186: FX application hangs on exit when media gets stuck In-Reply-To: <55786930.9080701@oracle.com> References: <55786930.9080701@oracle.com> Message-ID: <55786B6B.3000206@oracle.com> I'll review it in JIRA. FX JIRA will continue to be in read-write mode until Friday at 9am Pacific. If anyone has trouble writing to it before then, please let me know. -- Kevin Kirill Kirichenko wrote: > Hi Alexander, Kevin. > > Could you please review the following fix? > jira: https://javafx-jira.kenai.com/browse/RT-46186 > wevrev: http://cr.openjdk.java.net/~stayer/RT-46186/webrev.00/ > > Please review and comment in JIRA if it's still in read-write mode ? > > K From kevin.rushforth at oracle.com Wed Jun 10 21:54:04 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 10 Jun 2015 14:54:04 -0700 Subject: JavaFX JIRA issues moving to JBS Friday, June 12 In-Reply-To: <5570EB7F.5060301@oracle.com> References: <555E6389.30008@oracle.com> <5570612E.7040203@oracle.com> <5570EB7F.5060301@oracle.com> Message-ID: <5578B1FC.8070503@oracle.com> We are on track to perform the migration of FX JIRA issues to JBS this Friday, June 12. The RT project in the JavaFX JIRA issue tracker will become read-only at 9:00 am Pacific time Friday morning. JBS planned downtime is from 1:00 pm - 5:00 pm Pacific Friday afternoon, after which JavaFX bugs will be active in JBS. -- Kevin Kevin Rushforth wrote: > Due to a bug discovered in the migration script during the dry run, we > will need to reschedule the migration. Exact date TBD as we will need > to re-run series of testing. > > Our tentative target will be next Friday, June 12. Once confirmed, we > will send another heads-up notice. > > -- Kevin > > > Kevin Rushforth wrote: >> As a reminder, the migration of FX bugs to JBS will happen tomorrow. >> The RT project in the JavaFX JIRA issue tracker will become read-only >> at 9:00 am Pacific time tomorrow morning. We expect the migration to >> be complete some time in the afternoon tomorrow. >> >> Also, our infrastructure team is planning to enable URL redirects >> from javafx-jira at kenai.com to bugs.java.com tomorrow afternoon, so >> unless they run into problems with this, existing URL links will work. >> >> -- Kevin >> >> >> Kevin Rushforth wrote: >>> As previously announced [1] we are in the process of migrating >>> JavaFX bugs to the JDK Bug System (JBS) [2] in the JDK project. >>> >>> The target date for this migration is Friday, June 5. The existing >>> JavaFX bug tracker will become permanently read-only on that date, >>> and will be decommissioned some time after the transition is >>> complete. After javafx-jira.kenai.com is retired, we will explore >>> the feasibility of setting up an automatic redirect to >>> bugs.openjdk.java.net so that existing URLs will work. In any case, >>> typing in an old RT-nnnnn number into JBS will open the bug even >>> after it is mapped into the JDK project. >>> >>> -- Kevin >>> >>> [1] >>> http://mail.openjdk.java.net/pipermail/openjfx-dev/2015-April/017083.html >>> >>> [2] https://bugs.openjdk.java.net/ >>> From anton.tarasov at oracle.com Wed Jun 10 23:30:34 2015 From: anton.tarasov at oracle.com (Anton V. Tarasov) Date: Thu, 11 Jun 2015 02:30:34 +0300 Subject: [9] request for review: RT-34644 Webview radio button and checkboxes missing Message-ID: <5578C89A.60603@oracle.com> Hi Kevin, Please review the fix: JIRA: https://javafx-jira.kenai.com/browse/RT-34644 webrev: http://cr.openjdk.java.net/~ant/RT-34644/webrev.0 Thanks, Anton. From swpalmer at gmail.com Thu Jun 11 03:12:52 2015 From: swpalmer at gmail.com (Scott Palmer) Date: Wed, 10 Jun 2015 23:12:52 -0400 Subject: JavaFX printing on OS X is horribly broken Message-ID: <71AD4F04-158B-421D-95FB-F69EE9C930A4@gmail.com> The JavaFX bug https://javafx-jira.kenai.com/browse/RT-38198 refers to the JDK bug https://bugs.openjdk.java.net/browse/JDK-8064833 which appears to be back ported to 8u60 via https://bugs.openjdk.java.net/browse/JDK-8085925 I grabbed 8u60 b19 from jdk-8u60-ea-bin-b19-macosx-x86_64-09_jun_2015.dmg The download page wasn?t updated yet so I guessed the URL, which appears to give me a real b19: $ java -version java version "1.8.0_60-ea" Java(TM) SE Runtime Environment (build 1.8.0_60-ea-b19) Java HotSpot(TM) 64-Bit Server VM (build 25.60-b19, mixed mode) Based on the changeset graph at http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/graph/ it looked like b19 should include changeset http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/8e7854ac3257 But printing still doesn?t work. :-( The letters and glyph advances are still completely garbled. Have I made a mistake in my expectations for 8u60 b19 to contain a fix? Scott From philip.race at oracle.com Thu Jun 11 03:27:40 2015 From: philip.race at oracle.com (Phil Race) Date: Wed, 10 Jun 2015 20:27:40 -0700 Subject: JavaFX printing on OS X is horribly broken In-Reply-To: <71AD4F04-158B-421D-95FB-F69EE9C930A4@gmail.com> References: <71AD4F04-158B-421D-95FB-F69EE9C930A4@gmail.com> Message-ID: <5579002C.9090006@oracle.com> "dev" is not what is used to create the promoted builds. That would be master. Even then, the 8u60 backport is marked as fixed in build "team" so you are very premature in testing this unless you want to pull the 8u60 sources and build your own and test with that. Once "Resolved In Build:team" looks more like "Resolved In Build:b20" .. or something then you will know what to try. In other words it is team->master->b## and only the latter is useful to people who do not like creating their own buils from source. -phil. On 6/10/15 8:12 PM, Scott Palmer wrote: > The JavaFX bug https://javafx-jira.kenai.com/browse/RT-38198 refers to the JDK bug https://bugs.openjdk.java.net/browse/JDK-8064833 which appears to be back ported to 8u60 via https://bugs.openjdk.java.net/browse/JDK-8085925 > I grabbed 8u60 b19 from jdk-8u60-ea-bin-b19-macosx-x86_64-09_jun_2015.dmg The download page wasn?t updated yet so I guessed the URL, which appears to give me a real b19: > $ java -version > java version "1.8.0_60-ea" > Java(TM) SE Runtime Environment (build 1.8.0_60-ea-b19) > Java HotSpot(TM) 64-Bit Server VM (build 25.60-b19, mixed mode) > > Based on the changeset graph at http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/graph/ it looked like b19 should include changeset http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/8e7854ac3257 > > But printing still doesn?t work. :-( The letters and glyph advances are still completely garbled. > > Have I made a mistake in my expectations for 8u60 b19 to contain a fix? > > > Scott > From felix.bembrick at gmail.com Thu Jun 11 03:50:28 2015 From: felix.bembrick at gmail.com (Felix Bembrick) Date: Thu, 11 Jun 2015 13:50:28 +1000 Subject: Font rendering hints - RT-36146 - progress? Message-ID: I am following this one closely and hoping that some progress has been made and that a fix is planned but it's difficult to determine from the JIRA issue. Does anyone have any additional info on where this issue is at? Thanks, Felix From swpalmer at gmail.com Thu Jun 11 03:52:34 2015 From: swpalmer at gmail.com (Scott Palmer) Date: Wed, 10 Jun 2015 23:52:34 -0400 Subject: JavaFX printing on OS X is horribly broken In-Reply-To: <5579002C.9090006@oracle.com> References: <71AD4F04-158B-421D-95FB-F69EE9C930A4@gmail.com> <5579002C.9090006@oracle.com> Message-ID: <4372DBA4-BBE7-44C8-B658-8BD211FD6E0C@gmail.com> Ah, thanks for the insight. I was going to try building OpenJDK, but it requires an ancient version of XCode that I don?t feel like downloading for this one thing (another reason to convert the JDK build to use Gradle for everything), so I?ll likely just wait for b20+. I just wanted to be able to provide feedback ASAP in case my case wasn?t addressed, as I know JavaFX issues become harder to get fixed for 8u60 after this week as the ZBB code freeze starts Monday. Anyway, I?m glad it was just my mistake. Cheers, Scott > On Jun 10, 2015, at 11:27 PM, Phil Race wrote: > > "dev" is not what is used to create the promoted builds. That would be master. > Even then, the 8u60 backport is marked as fixed in build "team" so you are very premature > in testing this unless you want to pull the 8u60 sources and build your own and test with that. > > Once "Resolved In Build:team" > > looks more like "Resolved In Build:b20" .. or something then you will know what to try. > > In other words it is team->master->b## and only the latter is useful to people who > do not like creating their own buils from source. > > -phil. > > > On 6/10/15 8:12 PM, Scott Palmer wrote: >> The JavaFX bug https://javafx-jira.kenai.com/browse/RT-38198 refers to the JDK bug https://bugs.openjdk.java.net/browse/JDK-8064833 which appears to be back ported to 8u60 via https://bugs.openjdk.java.net/browse/JDK-8085925 >> I grabbed 8u60 b19 from jdk-8u60-ea-bin-b19-macosx-x86_64-09_jun_2015.dmg The download page wasn?t updated yet so I guessed the URL, which appears to give me a real b19: >> $ java -version >> java version "1.8.0_60-ea" >> Java(TM) SE Runtime Environment (build 1.8.0_60-ea-b19) >> Java HotSpot(TM) 64-Bit Server VM (build 25.60-b19, mixed mode) >> >> Based on the changeset graph at http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/graph/ it looked like b19 should include changeset http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/8e7854ac3257 >> >> But printing still doesn?t work. :-( The letters and glyph advances are still completely garbled. >> >> Have I made a mistake in my expectations for 8u60 b19 to contain a fix? >> >> >> Scott >> > From james.graham at oracle.com Thu Jun 11 05:30:36 2015 From: james.graham at oracle.com (Jim Graham) Date: Wed, 10 Jun 2015 22:30:36 -0700 Subject: Windows support for HiDPI displays, call for feedback and testing In-Reply-To: <5577E99E.1080205@jugs.org> References: <557173FD.6090501@jugs.org> <55720B42.6040906@oracle.com> <55733E79.7060509@jugs.org> <55758DC3.5010905@oracle.com> <5575DFEA.8040406@oracle.com> <5577423E.2090002@jugs.org> <5577667E.8010003@oracle.com> <5577E99E.1080205@jugs.org> Message-ID: <55791CFC.9000706@oracle.com> Hi Michael, On 6/10/15 12:39 AM, Dr. Michael Paus wrote: > If I understand you correctly you are saying that all this > HiDPI-handling is done under the covers and should > be fully transparent to the programmer, whereas I think that this is not > possible for non-trivial cases. > (Is this foo. versus foo at 2x. handling documented anywhere?) Unfortunately I think we are a little lax there in terms of our API documentation. I did find this blog by Richard that described this feature back when we released the retina Mac support: http://fxexperience.com/2012/11/retina-display-macbook-pro/ > Just a few questions: > > How do you determine which images to download from a server or database > if you don't know the render scale? Right now we only load one version of the image and we base it on the highest render scale on any screen. If it is more than 1.5x then we try to load @2x versions of any image. If no such image name exists then we load the regular image. So, if you say: new Image("foo.png"); and you have any screens that are 150% or greater we will first look for "foo at 2x.png" and only load "foo.png" if we don't find that file. Eventually we need to make this more formalized and extensible, and we also should be loading all variants of the image and using them dynamically as the output is scaled (whether it comes from a getRenderScale() or simply comes from zooming in). This is all a "work in progress" and there is no public API to control any of this other than to know that we'll use an @2x image if we find one. > How do you handle cases where your images are read from a stream where > you do not have a @2x name extension? > (Same for other non-named image sources.) We only do this processing when we are loading from some sort of URL where we can find a suffix and string-edit it to have the @2x sub-suffix. > How do you draw thin (single pixel wide) lines if you don't know the > render scale? On the other hand, why do you want to render a single pixel wide line? If your app is running on my Windows 8 laptop that has a 300DPI screen I won't be very happy using your app if you are determined to only render a single pixel. You should size your lines relative to the rest of the content and not try to size anything "by the pixel". On the other hand, there is some desire to have UI elements line up on crisp pixel boundaries so we do need to address "how do I draw a line that lines up on whole pixels" eventually and we haven't done that yet. > How do you display an image at exactly 100% scale (like the option in > Photoshop for example) if you don't know the render scale? We will eventually get there. Be aware, though, that even a native Mac app can't do what you ask because Mac OS virtualizes the pixels on you. I still need to dig and see if we can find a way to see past their virtualization, but native Mac apps are expected to do one of 2 things: - be unaware of HiDPI scaling and render at 1x - be aware of HiDPI scaling and render at exactly 2x on retina displays After you've done that, if the user has set their screen to "best for retina" in the control panel then your "aware" app will have its output go to the screen 1:1. If the user sets their screen to any other resolution, though, you will now be pixel scaled even though you voluntarily rendered at 2x already. > How do you take a snapshot of a node at full resolution? For example a > 500x500 canvas will be internally backed by a 1000x1000 > image which looks crisp on your Retina screen. When you now take a > snapshot of this canvas it will be a blurry 500x500 image. > (At least that was the result when I last tried it.) We'll need to advertise our internal scaling - that is coming in 9. > There are workarounds for all these issues but only if you know the > render scale. I realize, and I have this on my radar. Our first efforts have been to avoid the cases of "my app is horribly disfigured by system pixel stretching due to being DPI unaware" and "my app might be crisp, but it is unusably small on Windows". We're pretty much there now - apps should be of an appropriate size on all displays with only minimal pixel stretching artifacts (and at that, we only downsize by pixel stretching, never upsize, so this becomes a form of super sampling) - but we haven't yet provided the APIs for apps to go beyond the tradeoffs of our automatic support... ...jim From morris.meyer at oracle.com Thu Jun 11 22:54:09 2015 From: morris.meyer at oracle.com (Morris Meyer) Date: Thu, 11 Jun 2015 18:54:09 -0400 Subject: [9, 8u60] Review request for RT-46170: [Mac] setMaximize stops working Message-ID: <557A1191.1080006@oracle.com> David and Kevin, Please review this fix for stage.setMaximize() on Mac. We were missing the update to the Glass Window class that set the underlying window state, thus would never maximize again after the first maximize / de-maximize iteration. As this is localized in the one Glass-Mac JNI method it could be a possible candidate for inclusion in 8u60. Thanks much, --morris meyer JIRA - https://javafx-jira.kenai.com/browse/RT-46170 WEBREV - http://cr.openjdk.java.net/~morris/RT-46170.01/ From kevin.rushforth at oracle.com Fri Jun 12 16:08:57 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 12 Jun 2015 09:08:57 -0700 Subject: Result: New OpenJFX Committer: Anton Nashatyrev Message-ID: <557B0419.5050903@oracle.com> Voting for Anton Nashatyrev to OpenJFX Committer [1] is now closed. Yes: 4 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. -- Kevin [1] http://mail.openjdk.java.net/pipermail/openjfx-dev/2015-May/017324.html From ooo_saturn7 at mail.ru Fri Jun 12 17:06:54 2015 From: ooo_saturn7 at mail.ru (=?UTF-8?B?0JDQu9C10LrRgdCw0L3QtNGAINCh0LLQuNGA0LjQtNC+0LI=?=) Date: Fri, 12 Jun 2015 20:06:54 +0300 Subject: =?UTF-8?B?SmF2YUZ4OiB0YWIgcm91bmRlZCBjb3JuZXJzIC0gdmVyeSBzdHJhbmdlIGJl?= =?UTF-8?B?aGF2aW91cg==?= Message-ID: <1434128814.844613386@f353.i.mail.ru> I want to make tabs with rounded corners. And I have the following css code: . tab { -fx-border-radius:10 10 0 0; -fx-background-radius:10 10 0 0; } .tab:selected .focus-indicator { -fx-border-radius:10 10 0 0,10 10 00; } However, javafx adds some extra corners to tabs. Unfortunately I can't send a picture, however this question I asked at stackoverflow -? http://stackoverflow.com/questions/30690918/javafx-tab-rounded-corners ? and there I provided all the pictures. Is this a bug? if not, how to fix it? -- ????????? ???????? From kevin.rushforth at oracle.com Sat Jun 13 00:32:10 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 12 Jun 2015 17:32:10 -0700 Subject: COMPLETE: FX JIRA issues are now moved to JBS Message-ID: <557B7A0A.2060004@oracle.com> The migration of FX bugs to JBS [1] is complete. All of the open FX issues [2], along with any issues resolved since Jan 1, 2014, have been moved into the JDK project. The rest of the issues (those resolved prior to 2014) will move to the JDK project over the next week, and then the RT project will be locked down (although the issue redirect will still work). As a note to those (Authors and Committers) who have a JBS account: Do *not* create any new JIRA issues in the RT project in JBS! Use the JDK project. I. Helpful hints ----------------- There are a few subtle differences between the way JBS is configured and the way FX JIRA was configured but most of them are self-explanatory. I have highlighted a few things that may help a bit. * If you type the (old) RT-nnnnn number into the "Quick Search" box in JBS it will take you to the corresponding (new) JDK-mmmmmmm issue. * A redirect has been set up on the old server so that existing URLs will work. I don't know how long this will remain in place, but will ease the pain of the transition. For example [3]. * The FX Dev 8u60 Dashboard [4] has been recreated in JBS for tracking 8u60 issues for FX * Mapping from FX JIRA to JBS (this will make its way onto the OpenJFX Wiki [5] soon). Priority Mapping ---------------- Blocker --> P1 Critical --> P2 Major --> P3 Medium --> P4 Minor --> P5 Issuetype Mapping ----------------- Bug --> Bug Feature --> Enhancement Tweak --> Enhancement Improvement --> Enhancement Optimization --> Enhancement Test --> Bug Task --> Task Links Mapping ------------- "Depends On" --> "Is Blocked By" "Is Depended On By" --> "Blocks" [Others have the same name] Component / SubComponent Mapping -------------------------------- Empty --> javafx / none Accessibility --> javafx / accessibility Animation --> javafx / animation App Model --> javafx / application-lifecycle Build --> javafx / build Control --> javafx / controls Core Libraries --> javafx / base FXML --> javafx / fxml Glass --> javafx / window-toolkit Graphics --> javafx / graphics Localization --> javafx / localization Media --> javafx / media Other --> javafx / other Samples --> javafx / samples Scenegraph --> javafx / scenegraph Scenebuilder --> javafx / tools-scenebuilder Swing --> javafx / swing WebView --> javafx / web Deployment --> deploy / javafx Docs --> docs / javafx Installers --> install / javafx Packager --> >deploy / packager II. Important changes for committers ----------------------------------------------- Committers further need to be aware of the following important changes. I will capture most of this on the Wiki next week. 1. Use the new 7 digit JBS bug ID without the "JDK-" prefix for hg commit messages. This matches the JDK convention, and is a prerequisite to FX ever using jcheck (which we will want to do at some point in the future). The only exception to this is if you are backporting a bug that was already pushed to another codeline with RT-nnnnn in the comments. This should be rare except for bugs that are in progress, and that have already been pushed to the base release and you are working on the backports. For example: Good: 8012345: A very bad thing happens Reviewed-by: kcr Bad: JDK-8012345: A very bad thing happens Reviewed-by: kcr Obsolete; only use when backporting RT-12345 to another codeline: RT-12345: A very bad thing happens Reviewed-by: kcr 2. Use the main bug ID in your commit message (never the backport ID) This isn't a change from current policy, but since we will start using the backport issue type more often (see #3), it bears repeating. If JDK-8012345 is the main bug, that is, the JIRA with issue type = Bug, and JDK-8016789 is the backport issue for 8u60, then when you push the fix to 8u60 you will use 8012345 in your hg commit message. Always. 3. Create a backport rather than using multiple fix versions (in general) We have been very inconsistent about the use of backports in FX. It's time to move in the direction of JDK and stop using multiple fix versions on a JIRA issue. With JBS it's easy to create a backport issue (it was tedious and error prone in FX JIRA because of the lack of a proper backport issue type), so please try to do it for your backports. All it takes is going to the main bug and choosing the "Create Backport" option from the "More Actions" menu. Eventually, we may be able to use hgupdater which will automate this (and remove the burden of marking the JIRA issue as resolved/fixed and pasting in the changeset URL), but for now it's a manual step. Let me know if you have questions about any of this. -- Kevin [1] https://bugs.openjdk.java.net/ [2] https://bugs.openjdk.java.net/issues/?filter=24000 [3] https://javafx-jira.kenai.com/browse/RT-40000 [4] https://bugs.openjdk.java.net/secure/Dashboard.jspa?selectPageId=15119 [5] https://wiki.openjdk.java.net/display/OpenJFX/Submitting+a+Bug+Report From kevin.rushforth at oracle.com Sat Jun 13 00:36:22 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 12 Jun 2015 17:36:22 -0700 Subject: [8u60, 9] Review request: 8089063: Dotted Border clipped to the outside Message-ID: <557B7B06.7090606@oracle.com> Jim, Please review the following: https://bugs.openjdk.java.net/browse/JDK-8089063 http://cr.openjdk.java.net/~kcr/8089063/webrev.00/ -- Kevin From ooo_saturn7 at mail.ru Sat Jun 13 12:32:17 2015 From: ooo_saturn7 at mail.ru (=?UTF-8?B?0JDQu9C10LrRgdCw0L3QtNGAINCh0LLQuNGA0LjQtNC+0LI=?=) Date: Sat, 13 Jun 2015 15:32:17 +0300 Subject: =?UTF-8?B?SmF2YUZ4OiBjYW4gZGF0YSBiaW5kaW5nICh0ZXh0ZmllbGQpIGJlIHVzZWQg?= =?UTF-8?B?aW4gcHJvZHVjdGlvbiBtb2RlPw==?= Message-ID: <1434198737.491378745@f142.i.mail.ru> I use java 8.0.45. I have implemented my first javafx application (very simple) with data binding. However, biding from user input-> pojo seems to work with bugs. I've checked about 200 times. I entered new values in text fields and after that I checked model values. The same code, the same my behaviour. Sometimes everything works fine (in most cases - about 80-90%) sometimes model value!=textfield value. I've noticed the following. Data binding for some certain text field works,works and then at some point of time that binding stops working and all new values for this certain textfield are not passed to model. Nor exceptions. Nor any warnings. Nothing. Just binding doesn't work. I have 4 textfiled which are created via fxml. Two for string model type. One for integer. One for bigdecimal. The problem happens to all these fields(sometimes to one, sometimes to several). As my number fields can have null values, I use for example PropertyObject but not IntegerProperty (people from openjfx advised so). So is this JavaFx bug or what? P.S. I use felix osgi, weld cdi, and pax - I don't know if it matters... My code is the following: DTO - POJO Model public class Task { private String name; private Integer order; private BigDecimal weight; private String comment; private final PropertyChangeSupport propertyChangeSupport; public Task() { this.propertyChangeSupport = new PropertyChangeSupport(this); } public String getName() { return name; } public void setName(String name) { String pv = this.name ; this.name = name; propertyChangeSupport.firePropertyChange("name", pv, name); } public Integer getOrder() { return order; } public void setOrder(Integer order) { Integer pv = this.order; this.order = order; propertyChangeSupport.firePropertyChange("order", pv, this.order); } public BigDecimal getWeight() { return weight; } public void setWeight(BigDecimal weight) { BigDecimal pv = this.weight; this.weight = weight; propertyChangeSupport.firePropertyChange("weight", pv, weight); } public String getComment() { return comment; } public void setComment(String comment) { String pv = this.comment; this.comment = comment; propertyChangeSupport.firePropertyChange("comment", pv, this.comment); } public void addPropertyChangeListener(PropertyChangeListener listener) { propertyChangeSupport.addPropertyChangeListener(listener); } } Adapter public class TaskAdapter { private StringProperty nameProperty; private ObjectProperty orderProperty; private ObjectProperty weightProperty; private StringProperty commentProperty; public TaskAdapter(Task task) { try { nameProperty=new JavaBeanStringPropertyBuilder().bean(task).name("name").build(); orderProperty=new JavaBeanObjectPropertyBuilder().bean(task).name("order").build(); weightProperty=new JavaBeanObjectPropertyBuilder().bean(task).name("weight").build(); commentProperty=new JavaBeanStringPropertyBuilder().bean(task).name("comment").build(); } catch (NoSuchMethodException ex) { Logger.getLogger(this.getClass().getName()).log(Level.SEVERE, null, ex); } } public StringProperty getNameProperty() { return nameProperty; } public ObjectProperty getOrderProperty() { return orderProperty; } public ObjectProperty getWeightProperty() { return weightProperty; } public StringProperty getCommentProperty() { return commentProperty; } } BigDecimal Converter public class SimpleBigDecimalStringConverter extends StringConverter{ @Override public String toString(BigDecimal i) { if (i == null) { return "" ; } else { return i.toString(); } } @Override public BigDecimal fromString(String string) { if (string.trim().length() == 0) { return null ; } else { try { return new BigDecimal(string); } catch (NumberFormatException nfe) { return null ; } } } } IntegerConverter public class SimpleIntegerStringConverter extends StringConverter{ @Override public String toString(Integer i) { if (i == null) { return "" ; } else { return i.toString(); } } @Override public Integer fromString(String string) { if (string.trim().length() == 0) { return null ; } else { try { return Integer.valueOf(string); } catch (NumberFormatException nfe) { return null ; } } } } Initializing code Task task=new Task(); TaskAdapter adapter=new TaskAdapter(task); nameTextField.textProperty().bindBidirectional(adapter.getNameProperty()); orderTextField.textProperty().bindBidirectional(adapter.getOrderProperty(),new SimpleIntegerStringConverter()); weightTextField.textProperty().bindBidirectional(adapter.getWeightProperty(),new BigDecimalStringConverter()); commentTextField.textProperty().bindBidirectional(adapter.getCommentProperty()); From tom.schindl at bestsolution.at Sat Jun 13 14:10:13 2015 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Sat, 13 Jun 2015 16:10:13 +0200 Subject: JavaFx: can data binding (textfield) be used in production mode? In-Reply-To: <1434198737.491378745@f142.i.mail.ru> References: <1434198737.491378745@f142.i.mail.ru> Message-ID: <1E84A6CF-50F8-4F53-A8F2-ED3EEAFF1FF3@bestsolution.at> In the given sample the adapter is a local variable and hence it is garbage collected at some point in time and because javafx bindings are implemented with weaklisteners (see the javadoc) it will stop updateing your Bean! So it works as designed and your code is simply wrong! Tom Von meinem iPhone gesendet > Am 13.06.2015 um 14:32 schrieb ????????? ???????? : > > I use java 8.0.45. I have implemented my first javafx application (very simple) with data binding. However, biding from user input-> pojo seems to work with bugs. I've checked about 200 times. I entered new values in text fields and after that I checked model values. The same code, the same my behaviour. Sometimes everything works fine (in most cases - about 80-90%) sometimes model value!=textfield value. I've noticed the following. Data binding for some certain text field works,works and then at some point of time that binding stops working and all new values for this certain textfield are not passed to model. Nor exceptions. Nor any warnings. Nothing. Just binding doesn't work. > I have 4 textfiled which are created via fxml. Two for string model type. One for integer. One for bigdecimal. The problem happens to all these fields(sometimes to one, sometimes to several). As my number fields can have null values, I use for example PropertyObject but not IntegerProperty (people from openjfx advised so). > So is this JavaFx bug or what? P.S. I use felix osgi, weld cdi, and pax - I don't know if it matters... > My code is the following: > > DTO - POJO Model > public class Task { > > private String name; > > private Integer order; > > private BigDecimal weight; > > private String comment; > > private final PropertyChangeSupport propertyChangeSupport; > > public Task() { > this.propertyChangeSupport = new PropertyChangeSupport(this); > } > > public String getName() { > return name; > } > > public void setName(String name) { > String pv = this.name ; > this.name = name; > propertyChangeSupport.firePropertyChange("name", pv, name); > } > > public Integer getOrder() { > return order; > } > > public void setOrder(Integer order) { > Integer pv = this.order; > this.order = order; > propertyChangeSupport.firePropertyChange("order", pv, this.order); > } > > public BigDecimal getWeight() { > return weight; > } > > public void setWeight(BigDecimal weight) { > BigDecimal pv = this.weight; > this.weight = weight; > propertyChangeSupport.firePropertyChange("weight", pv, weight); > } > > public String getComment() { > return comment; > } > > public void setComment(String comment) { > String pv = this.comment; > this.comment = comment; > propertyChangeSupport.firePropertyChange("comment", pv, this.comment); > } > > public void addPropertyChangeListener(PropertyChangeListener listener) { > propertyChangeSupport.addPropertyChangeListener(listener); > } > > } > Adapter > public class TaskAdapter { > > private StringProperty nameProperty; > > private ObjectProperty orderProperty; > > private ObjectProperty weightProperty; > > private StringProperty commentProperty; > > public TaskAdapter(Task task) { > try { > nameProperty=new JavaBeanStringPropertyBuilder().bean(task).name("name").build(); > orderProperty=new JavaBeanObjectPropertyBuilder().bean(task).name("order").build(); > weightProperty=new JavaBeanObjectPropertyBuilder().bean(task).name("weight").build(); > commentProperty=new JavaBeanStringPropertyBuilder().bean(task).name("comment").build(); > } catch (NoSuchMethodException ex) { > Logger.getLogger(this.getClass().getName()).log(Level.SEVERE, null, ex); > } > } > > public StringProperty getNameProperty() { > return nameProperty; > } > > public ObjectProperty getOrderProperty() { > return orderProperty; > } > > public ObjectProperty getWeightProperty() { > return weightProperty; > } > > public StringProperty getCommentProperty() { > return commentProperty; > } > > } > BigDecimal Converter > public class SimpleBigDecimalStringConverter extends StringConverter{ > > @Override > public String toString(BigDecimal i) { > if (i == null) { > return "" ; > } else { > return i.toString(); > } > } > > @Override > public BigDecimal fromString(String string) { > if (string.trim().length() == 0) { > return null ; > } else { > try { > return new BigDecimal(string); > } catch (NumberFormatException nfe) { > return null ; > } > } > } > } > IntegerConverter > public class SimpleIntegerStringConverter extends StringConverter{ > > @Override > public String toString(Integer i) { > if (i == null) { > return "" ; > } else { > return i.toString(); > } > } > > @Override > public Integer fromString(String string) { > if (string.trim().length() == 0) { > return null ; > } else { > try { > return Integer.valueOf(string); > } catch (NumberFormatException nfe) { > return null ; > } > } > } > } > Initializing code > Task task=new Task(); > TaskAdapter adapter=new TaskAdapter(task); > nameTextField.textProperty().bindBidirectional(adapter.getNameProperty()); > orderTextField.textProperty().bindBidirectional(adapter.getOrderProperty(),new SimpleIntegerStringConverter()); > weightTextField.textProperty().bindBidirectional(adapter.getWeightProperty(),new BigDecimalStringConverter()); > commentTextField.textProperty().bindBidirectional(adapter.getCommentProperty()); From felix.bembrick at gmail.com Sun Jun 14 21:31:30 2015 From: felix.bembrick at gmail.com (Felix Bembrick) Date: Mon, 15 Jun 2015 07:31:30 +1000 Subject: Font rendering hints - RT-36146 - progress? In-Reply-To: References: Message-ID: ?Has anyone had a look at this, done some work on it or can provide some details as to its progress? Thanks, Felix? On 11 June 2015 at 13:50, Felix Bembrick wrote: > I am following this one closely and hoping that some progress has been > made and that a fix is planned but it's difficult to determine from the > JIRA issue. > > Does anyone have any additional info on where this issue is at? > > Thanks, > > Felix > From ooo_saturn7 at mail.ru Mon Jun 15 05:53:24 2015 From: ooo_saturn7 at mail.ru (=?UTF-8?B?0JDQu9C10LrRgdCw0L3QtNGAINCh0LLQuNGA0LjQtNC+0LI=?=) Date: Mon, 15 Jun 2015 08:53:24 +0300 Subject: =?UTF-8?B?SmF2YUZ4OiB3ZWJ2aWV3IHByaW50IHdpdGggc2NhbGUgMTAwJQ==?= Message-ID: <1434347604.864680804@f359.i.mail.ru> To print my html page I use the following code: PrinterJob job =PrinterJob.createPrinterJob();if(job !=null&& job.showPrintDialog(null)){ webView.getEngine().print(job); job.endJob();} The problem is that webview changes the scale of printing page. For example, when I print this html page in IE with fit to size 100% I get 16.8 cm. When I print in my java application I get 11.4cm. The size in html file I set in pt - my width is 475pt(A4 width=595pt,so 475pt=16.8cm). How to print with webview and to have 100% width and height? From ooo_saturn7 at mail.ru Mon Jun 15 05:54:10 2015 From: ooo_saturn7 at mail.ru (=?UTF-8?B?0JDQu9C10LrRgdCw0L3QtNGAINCh0LLQuNGA0LjQtNC+0LI=?=) Date: Mon, 15 Jun 2015 08:54:10 +0300 Subject: =?UTF-8?B?SmF2YUZ4OiBwcmludGVyIGRpYWxvZyBpcyBzaG93biBiZWhpbmQgbWFpbiB3?= =?UTF-8?B?aW5kb3coc3RhZ2Up?= Message-ID: <1434347650.147262500@f359.i.mail.ru> I use java8. I have a main window (stage) and when I click at button "print" the following code is executed: PrinterJob job =PrinterJob.createPrinterJob();if(job !=null&& job.showPrintDialog(null)){ webView.getEngine().print(job); job.endJob();} The printer dialog appears. But! it appears behind the main window but not in front of main window! This strange behaviour happens only when dialog appears the first time. The second and other times it's in front of the main window. How to fix it? -- ????????? ???????? From lehmann at media-interactive.de Mon Jun 15 10:24:44 2015 From: lehmann at media-interactive.de (Werner Lehmann) Date: Mon, 15 Jun 2015 12:24:44 +0200 Subject: JavaFx: printer dialog is shown behind main window(stage) In-Reply-To: <1434347650.147262500@f359.i.mail.ru> References: <1434347650.147262500@f359.i.mail.ru> Message-ID: <557EA7EC.2040504@media-interactive.de> Hi Alexander, this seems to be a known bug: https://bugs.openjdk.java.net/browse/JDK-8088395 Rgds Werner On 15.06.2015 07:54, ????????? ???????? wrote: > The printer dialog appears. But! it appears behind the main window > but not in front of main window! This strange behaviour happens only > when dialog appears the first time. The second and other times it's > in front of the main window. How to fix it? From kevin.rushforth at oracle.com Mon Jun 15 10:36:27 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 15 Jun 2015 03:36:27 -0700 Subject: Font rendering hints - RT-36146 - progress? In-Reply-To: References: Message-ID: <557EAAAB.5090905@oracle.com> It is one of many RFEs that we might consider for JDK 9, but have not committed to. I don't think Phil has looked into it recently, but perhaps he can provide an update on it. -- Kevin Felix Bembrick wrote: > ?Has anyone had a look at this, done some work on it or can provide some > details as to its progress? > > Thanks, > > Felix? > > On 11 June 2015 at 13:50, Felix Bembrick wrote: > > >> I am following this one closely and hoping that some progress has been >> made and that a fix is planned but it's difficult to determine from the >> JIRA issue. >> >> Does anyone have any additional info on where this issue is at? >> >> Thanks, >> >> Felix >> >> From kevin.rushforth at oracle.com Mon Jun 15 10:39:07 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 15 Jun 2015 03:39:07 -0700 Subject: In(Sanity) Testing Mondays Message-ID: <557EAB4B.6040203@oracle.com> Reminder, Monday (today) is our weekly sanity testing. You can find your testing assignment at: https://wiki.openjdk.java.net/display/OpenJFX/Sanity+Testing Also please remember that the repo will be locked from 1am PDT until 1pm PDT. Happy testing! Thanks. -- Kevin From felix.bembrick at gmail.com Mon Jun 15 12:00:23 2015 From: felix.bembrick at gmail.com (Felix Bembrick) Date: Mon, 15 Jun 2015 22:00:23 +1000 Subject: JavaFX features in JDK 9 Message-ID: <4A33E952-B3B0-4C19-9F5E-CBB10EC9E19B@gmail.com> I realise we are a long way off JDK 9 still and with crucial features such as Jigsaw still a little up in the air but is it possible someone could itemise the most likely new features, enhancements and bug fixes that we will see in JavaFX when JDK 9 is released? Of course it's purely speculation at this point but it would assist me greatly to have some of idea of where JavaFX is heading and which areas are seen as most important. Thanks, Felix From kirill.kirichenko at oracle.com Mon Jun 15 14:21:16 2015 From: kirill.kirichenko at oracle.com (Kirill Kirichenko) Date: Mon, 15 Jun 2015 17:21:16 +0300 Subject: [8u60,9] review request: 8088823: Advanced Media Player tab does not respond to "Time" slider on Windows Message-ID: <557EDF5C.5020901@oracle.com> Hi Alexander, Kevin. Could you please review the following fix? jbs: https://bugs.openjdk.java.net/browse/JDK-8088823 wevrev: http://cr.openjdk.java.net/~stayer/8088823/webrev.00/ Please review and comment in JBS. This patch partly fixes regression after https://bugs.openjdk.java.net/browse/JDK-8092944 and partly fixes missing parts. In JDK-8092944 DeliverSample fails in CBaseOutputPin::GetDeliveryBuffer with E_NOINTERFACE because m_pAllocator is NULL. So this patch does not ignore all errors that are not E_FAIL. Patch in gstqueue.c allows to generate GST_ELEMENT_ERROR even if there is no eos in the queue. Without this part _loop task is silently stops and application is not generating any errors. Patch in flvdemux.c just cleans redundancy. It's just not necessary. I'd say that some SQE effort is necessary for testing this patch better. K From mike at plan99.net Mon Jun 15 15:06:30 2015 From: mike at plan99.net (Mike Hearn) Date: Mon, 15 Jun 2015 17:06:30 +0200 Subject: Bug report: HostServicesFactory on Linux needs a more complete browsers list Message-ID: The file HostServicesFactory.java (I cannot find it in the JFX8+ repo) contains this line of code, for Linux. It should be re-arranged and extended for better compatibility: - static final String[] browsers = new String[]{"google-chrome", "firefox", "opera", "konqueror", "mozilla"}; + static final String[] browsers = new String[]{"xdg-open", "gnome-open", "google-chrome", "chromium", "firefox", "opera", "konqueror", "mozilla"}; From johan at lodgon.com Mon Jun 15 16:37:41 2015 From: johan at lodgon.com (Johan Vos) Date: Mon, 15 Jun 2015 18:37:41 +0200 Subject: HiDPI in monocle Message-ID: Hi, With the changes introduced in the fix for RT-27960 ( https://bugs.openjdk.java.net/browse/JDK-8098184), the hidpi support on Android is broken. As part of the changes in http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/670ed25ed138, we introduced a getScale method on NativeScreen, and the result of this method was used in the constructor of Screen (See MonocleApplication.java). As an example, on a Nexus 5 the getScale() would return 3.0, as the device has 1920x1080 physical pixels but we use a Scene with dimensions 640x360. I'm not sure how to map this getScale() to the new getPlatformScale() and getRenderScale() though? - Johan From philip.race at oracle.com Mon Jun 15 20:05:01 2015 From: philip.race at oracle.com (Phil Race) Date: Mon, 15 Jun 2015 13:05:01 -0700 Subject: Font rendering hints - RT-36146 - progress? In-Reply-To: References: Message-ID: <557F2FED.7050004@oracle.com> I would have to look at it starting more or less from scratch and I do not know that it would be as simple as providing a way to tweak DirectWrite rendering. The differences seem to be quite small differences in sub-pixel intensity and sub-pixel accumulation of the total advance. I do not know what API or client produced the 'native' rendering. And what if someone else wants something different again ? So I am not sure when we will get to looking into this and deciding if it makes sense. -phil. On 06/14/2015 02:31 PM, Felix Bembrick wrote: > ?Has anyone had a look at this, done some work on it or can provide some > details as to its progress? > > Thanks, > > Felix? > > On 11 June 2015 at 13:50, Felix Bembrick wrote: > >> I am following this one closely and hoping that some progress has been >> made and that a fix is planned but it's difficult to determine from the >> JIRA issue. >> >> Does anyone have any additional info on where this issue is at? >> >> Thanks, >> >> Felix >> From james.graham at oracle.com Mon Jun 15 20:29:14 2015 From: james.graham at oracle.com (Jim Graham) Date: Mon, 15 Jun 2015 13:29:14 -0700 Subject: HiDPI in monocle In-Reply-To: References: Message-ID: <557F359A.5050203@oracle.com> Screen.getPlatformScale() is the scaling from "FX pixels" to the pixels that the platform uses for events and window coordinates. Screen.getRenderScale() is the recommended scale for rendering - typically "ceil(platformScale)". There is also Window.getOutputScale() which defaults to getPlatformScale(). When rendering a scene we render at the render scale and then blit it to the size indicated by the output scale. When "renderscale = ceil(platformScale)", as it does on Windows, we may be rendering at 200% for a window that is at 150% on the screen, so the rendering happens at an integer pixel scale and then we get the size on the screen appropriate for what the Windows UI guidelines suggest. ...jim On 6/15/15 9:37 AM, Johan Vos wrote: > Hi, > > With the changes introduced in the fix for RT-27960 ( > https://bugs.openjdk.java.net/browse/JDK-8098184), the hidpi support on > Android is broken. > > As part of the changes in > http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/670ed25ed138, we > introduced a getScale method on NativeScreen, and the result of this method > was used in the constructor of Screen (See MonocleApplication.java). As an > example, on a Nexus 5 the getScale() would return 3.0, as the device has > 1920x1080 physical pixels but we use a Scene with dimensions 640x360. > > I'm not sure how to map this getScale() to the new getPlatformScale() and > getRenderScale() though? > > - Johan > From felix.bembrick at gmail.com Mon Jun 15 20:52:54 2015 From: felix.bembrick at gmail.com (Felix Bembrick) Date: Tue, 16 Jun 2015 06:52:54 +1000 Subject: Font rendering hints - RT-36146 - progress? In-Reply-To: <557F2FED.7050004@oracle.com> References: <557F2FED.7050004@oracle.com> Message-ID: The thing is that the way DirectWrite is utilised now by JavaFX either through which hints are applied by default or by some other way, the result is text which does not render exactly the same way as (almost) every native Windows application that also utilises DirectWrite. Wouldn't a simpler solution (or at least a first step) be just to tweak the hints and options until JavaFX font rendering on Windows matches the way native apps do it? I believe at the moment all the default options are selected so perhaps experimenting with some of the non-default options or examining actual code of some native apps to see which options/hints they are setting would arrive at a "best match" configuration that could replace the "all defaults" configuration we have now? Then, later down the track, these hints/options could potentially be made user-configurable. On 16 June 2015 at 06:05, Phil Race wrote: > I would have to look at it starting more or less from scratch > and I do not know that it would be as simple as providing a > way to tweak DirectWrite rendering. The > differences seem to be quite small differences in sub-pixel > intensity and sub-pixel accumulation of the total advance. > I do not know what API or client produced the 'native' rendering. > And what if someone else wants something different again ? > So I am not sure when we will get to looking into this and > deciding if it makes sense. > > -phil. > > > On 06/14/2015 02:31 PM, Felix Bembrick wrote: > >> ?Has anyone had a look at this, done some work on it or can provide some >> details as to its progress? >> >> Thanks, >> >> Felix? >> >> On 11 June 2015 at 13:50, Felix Bembrick >> wrote: >> >> I am following this one closely and hoping that some progress has been >>> made and that a fix is planned but it's difficult to determine from the >>> JIRA issue. >>> >>> Does anyone have any additional info on where this issue is at? >>> >>> Thanks, >>> >>> Felix >>> >>> > From kevin.rushforth at oracle.com Mon Jun 15 21:39:07 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 15 Jun 2015 14:39:07 -0700 Subject: 8u-dev and 9-dev unlocked -- Rampdown rules in effect for 8u-dev Message-ID: <557F45FB.5040203@oracle.com> 8u-dev and 9-dev are open following this week's testing. As previously communicated [1] and stated on the JavaFX Wiki [2] the following rampdown rules for 8u60 are in effect this week for pushing changes to 8u-dev: Mon, Jun 15 to Sun, Jun 21 -- regressions and critical bugs only, pre-commit review required All bug fixes require a pre-commit review; an exception is made for changesets that do not touch shipping code, such as fixes to unit tests and non-shipping examples/toys Changes should go to 9-dev first (which may be done with either a pre-commit or post-commit review) and then backported to 8u-dev for 8u60 with a pre-commit review. -- Kevin [1] http://mail.openjdk.java.net/pipermail/openjfx-dev/2015-May/017296.html [2] https://wiki.openjdk.java.net/display/OpenJFX/8u60 From philip.race at oracle.com Tue Jun 16 04:46:42 2015 From: philip.race at oracle.com (Phil Race) Date: Mon, 15 Jun 2015 21:46:42 -0700 Subject: Font rendering hints - RT-36146 - progress? In-Reply-To: References: <557F2FED.7050004@oracle.com> Message-ID: <557FAA32.5040703@oracle.com> If you can figure out some apps for which there is source and provide those tweaks that might help understand the differences but I am not sure it will be as straightforward as you hope. -phil.. On 6/15/15 1:52 PM, Felix Bembrick wrote: > The thing is that the way DirectWrite is utilised now by JavaFX either > through which hints are applied by default or by some other way, the > result is text which does not render exactly the same way as (almost) > every native Windows application that also utilises DirectWrite. > > Wouldn't a simpler solution (or at least a first step) be just to > tweak the hints and options until JavaFX font rendering on Windows > matches the way native apps do it? I believe at the moment all the > default options are selected so perhaps experimenting with some of the > non-default options or examining actual code of some native apps to > see which options/hints they are setting would arrive at a "best > match" configuration that could replace the "all defaults" > configuration we have now? > > Then, later down the track, these hints/options could potentially be > made user-configurable. > > On 16 June 2015 at 06:05, Phil Race > wrote: > > I would have to look at it starting more or less from scratch > and I do not know that it would be as simple as providing a > way to tweak DirectWrite rendering. The > differences seem to be quite small differences in sub-pixel > intensity and sub-pixel accumulation of the total advance. > I do not know what API or client produced the 'native' rendering. > And what if someone else wants something different again ? > So I am not sure when we will get to looking into this and > deciding if it makes sense. > > -phil. > > > On 06/14/2015 02:31 PM, Felix Bembrick wrote: > > ?Has anyone had a look at this, done some work on it or can > provide some > details as to its progress? > > Thanks, > > Felix? > > On 11 June 2015 at 13:50, Felix Bembrick > > > wrote: > > I am following this one closely and hoping that some > progress has been > made and that a fix is planned but it's difficult to > determine from the > JIRA issue. > > Does anyone have any additional info on where this issue > is at? > > Thanks, > > Felix > > > From johan at lodgon.com Tue Jun 16 11:13:44 2015 From: johan at lodgon.com (Johan Vos) Date: Tue, 16 Jun 2015 13:13:44 +0200 Subject: HiDPI in monocle In-Reply-To: <557F359A.5050203@oracle.com> References: <557F359A.5050203@oracle.com> Message-ID: In MonocleApplication, a Screen is created. It used to be call the constructor with the last argument (float scale) set to 1.0f, but I changed that to NativeScreen.getScale() which has this javadoc: /** * Return the scale factor between the physical pixels and the logical pixels * e.g. hdpi = 1.5, xhdpi = 2.0 */ With the new Screen constructor, it seems to me both the UIScale and the RenderScale need to be set to the NativeScreen.getScale(). If I do that on my Nexus 5 where getScale() returns 3, however, only 1/3 of the screen is used. It seems presentableState.width is set to 1/3 of the logical width which is 1/3 of the physical width. I have 1080 physical pixels, 360 logical pixels, but presentableState.width is only 120. Looking at the diff in RT-27960, there are probably changes required in MonocleApplication and MonocleWindow as well? - Johan 2015-06-15 22:29 GMT+02:00 Jim Graham : > Screen.getPlatformScale() is the scaling from "FX pixels" to the pixels > that the platform uses for events and window coordinates. > Screen.getRenderScale() is the recommended scale for rendering - typically > "ceil(platformScale)". > > There is also Window.getOutputScale() which defaults to > getPlatformScale(). When rendering a scene we render at the render scale > and then blit it to the size indicated by the output scale. When > "renderscale = ceil(platformScale)", as it does on Windows, we may be > rendering at 200% for a window that is at 150% on the screen, so the > rendering happens at an integer pixel scale and then we get the size on the > screen appropriate for what the Windows UI guidelines suggest. > > ...jim > > > On 6/15/15 9:37 AM, Johan Vos wrote: > >> Hi, >> >> With the changes introduced in the fix for RT-27960 ( >> https://bugs.openjdk.java.net/browse/JDK-8098184), the hidpi support on >> Android is broken. >> >> As part of the changes in >> http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/670ed25ed138, we >> introduced a getScale method on NativeScreen, and the result of this >> method >> was used in the constructor of Screen (See MonocleApplication.java). As an >> example, on a Nexus 5 the getScale() would return 3.0, as the device has >> 1920x1080 physical pixels but we use a Scene with dimensions 640x360. >> >> I'm not sure how to map this getScale() to the new getPlatformScale() and >> getRenderScale() though? >> >> - Johan >> >> From johan at lodgon.com Tue Jun 16 13:55:42 2015 From: johan at lodgon.com (Johan Vos) Date: Tue, 16 Jun 2015 15:55:42 +0200 Subject: HiDPI in monocle In-Reply-To: References: <557F359A.5050203@oracle.com> Message-ID: Update: I have HiDPI working on Android-Monocle again, mainly by passing the physical width/height to the Screen constructor. (e.g. 1920, 1080). I had to remove some preprocessing on event detection in the Android layer, as this is now done in a generic way -- I'm always happy to remove some of my Android-specific code! The issue I still have though is that Screen.getPrimary().getVisualBounds() now returns the physical coordinates (1920, 1080) instead of the logical ones. Looking at the implementation of Screen.getVisualBounds, it seems to me this always returns the width/height from the com.sun.glass.ui.Screen. So in this case, I assume the width/height that need to be passed to the com.sun.glass.ui.Screen constructor are *not* the physical ones, but the logical ones? But if I do that, I get the issue described in my previous mail. Any help with sample dimensions on other platforms are very much appreciated. Thanks, - Johan 2015-06-16 13:13 GMT+02:00 Johan Vos : > In MonocleApplication, a Screen is created. It used to be call the > constructor with the last argument (float scale) set to 1.0f, but I changed > that to NativeScreen.getScale() which has this javadoc: > /** > * Return the scale factor between the physical pixels and the logical > pixels > * e.g. hdpi = 1.5, xhdpi = 2.0 > */ > > With the new Screen constructor, it seems to me both the UIScale and the > RenderScale need to be set to the NativeScreen.getScale(). If I do that on > my Nexus 5 where getScale() returns 3, however, only 1/3 of the screen is > used. It seems presentableState.width is set to 1/3 of the logical width > which is 1/3 of the physical width. I have 1080 physical pixels, 360 > logical pixels, but presentableState.width is only 120. > > Looking at the diff in RT-27960, there are probably changes required in > MonocleApplication and MonocleWindow as well? > > - Johan > > > 2015-06-15 22:29 GMT+02:00 Jim Graham : > >> Screen.getPlatformScale() is the scaling from "FX pixels" to the pixels >> that the platform uses for events and window coordinates. >> Screen.getRenderScale() is the recommended scale for rendering - typically >> "ceil(platformScale)". >> >> There is also Window.getOutputScale() which defaults to >> getPlatformScale(). When rendering a scene we render at the render scale >> and then blit it to the size indicated by the output scale. When >> "renderscale = ceil(platformScale)", as it does on Windows, we may be >> rendering at 200% for a window that is at 150% on the screen, so the >> rendering happens at an integer pixel scale and then we get the size on the >> screen appropriate for what the Windows UI guidelines suggest. >> >> ...jim >> >> >> On 6/15/15 9:37 AM, Johan Vos wrote: >> >>> Hi, >>> >>> With the changes introduced in the fix for RT-27960 ( >>> https://bugs.openjdk.java.net/browse/JDK-8098184), the hidpi support on >>> Android is broken. >>> >>> As part of the changes in >>> http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/670ed25ed138, we >>> introduced a getScale method on NativeScreen, and the result of this >>> method >>> was used in the constructor of Screen (See MonocleApplication.java). As >>> an >>> example, on a Nexus 5 the getScale() would return 3.0, as the device has >>> 1920x1080 physical pixels but we use a Scene with dimensions 640x360. >>> >>> I'm not sure how to map this getScale() to the new getPlatformScale() and >>> getRenderScale() though? >>> >>> - Johan >>> >>> > From ondra.pelech at gmail.com Sun Jun 14 23:02:53 2015 From: ondra.pelech at gmail.com (Ondra Pelech) Date: Mon, 15 Jun 2015 01:02:53 +0200 Subject: Building OpenJFX with WebKit Message-ID: Hello, I'm trying to build OpenJFX with WebKit, but I'm missing the dependency com.sun.webkit:webview-deps:1.3 I've come across this thread from May http://comments.gmane.org/gmane.comp.java.openjdk.openjfx.devel/9447 but webkit:webview-deps:1.3 is still not on maven central is there another place I can get it from? or how can I build it myself? thank you, best regards Ondra Building Webkit configuration /Release/ into /home/ondra/Projects/rt/modules/web/build/linux :web:compileNativeLinux FAILED FAILURE: Build failed with an exception. * Where: Build file '/home/ondra/Projects/rt/build.gradle' line: 2512 * What went wrong: Execution failed for task ':web:compileNativeLinux'. > Could not resolve all dependencies for configuration ':web:webkit'. > Could not find com.sun.webkit:webview-deps:1.3. Required by: rt:web:unspecified From info at michaelhoffer.de Tue Jun 16 15:04:02 2015 From: info at michaelhoffer.de (Michael Hoffer) Date: Tue, 16 Jun 2015 17:04:02 +0200 Subject: Building OpenJFX with WebKit Message-ID: Hi Ondra, I was able to build WebKit after reverting the version number from 1.3 to 1.2. On Linux there should be a package called libicu48. I guess it is equivalent to webview-deps 1.3. If you install it WebKit should compile. Regards, Michael 2015-06-15 1:02 GMT+02:00 Ondra Pelech : > Hello, > I'm trying to build OpenJFX with WebKit, but I'm missing the > dependency com.sun.webkit:webview-deps:1.3 > I've come across this thread from May > http://comments.gmane.org/gmane.comp.java.openjdk.openjfx.devel/9447 > but webkit:webview-deps:1.3 is still not on maven central > is there another place I can get it from? or how can I build it myself? > > thank you, best regards > Ondra > > > > Building Webkit configuration /Release/ into > /home/ondra/Projects/rt/modules/web/build/linux > :web:compileNativeLinux FAILED > > FAILURE: Build failed with an exception. > > * Where: > Build file '/home/ondra/Projects/rt/build.gradle' line: 2512 > > * What went wrong: > Execution failed for task ':web:compileNativeLinux'. > > Could not resolve all dependencies for configuration ':web:webkit'. > > Could not find com.sun.webkit:webview-deps:1.3. > Required by: > rt:web:unspecified > -- Dipl.-Math. Michael Hoffer Twitter: @mihosoft Webpage: www.mihosoft.eu Goethe-Zentrum f?r Wissenschaftliches Rechnen (G-CSC) Goethe-Universit?t Kettenhofweg 139 60325 Frankfurt am Main phone: +49 69 798 25254 info at michaelhoffer.de From james.graham at oracle.com Tue Jun 16 19:58:43 2015 From: james.graham at oracle.com (Jim Graham) Date: Tue, 16 Jun 2015 12:58:43 -0700 Subject: HiDPI in monocle In-Reply-To: References: <557F359A.5050203@oracle.com> Message-ID: <55807FF3.8060304@oracle.com> The Windows code recalculates the screen bounds into DPI-virtualized versions before it constructs the Screen objects. They are virtualized into FX coordinates such that placing a window at those bounds, when run through the platformScale, will result in a window of the appropriate pixel size to cover the screen. Does that make sense? On Mac, they talk "FX" coordinates for the screen bounds and window sizes already so there is no such translation going on. ...jim On 6/16/15 6:55 AM, Johan Vos wrote: > Update: > I have HiDPI working on Android-Monocle again, mainly by passing the > physical width/height to the Screen constructor. (e.g. 1920, 1080). I > had to remove some preprocessing on event detection in the Android > layer, as this is now done in a generic way -- I'm always happy to > remove some of my Android-specific code! > > The issue I still have though is that > Screen.getPrimary().getVisualBounds() now returns the physical > coordinates (1920, 1080) instead of the logical ones. > Looking at the implementation of Screen.getVisualBounds, it seems to me > this always returns the width/height from the com.sun.glass.ui.Screen. > So in this case, I assume the width/height that need to be passed to the > com.sun.glass.ui.Screen constructor are *not* the physical ones, but the > logical ones? But if I do that, I get the issue described in my previous > mail. > > Any help with sample dimensions on other platforms are very much > appreciated. > > Thanks, > > - Johan > > > > 2015-06-16 13:13 GMT+02:00 Johan Vos >: > > In MonocleApplication, a Screen is created. It used to be call the > constructor with the last argument (float scale) set to 1.0f, but I > changed that to NativeScreen.getScale() which has this javadoc: > /** > * Return the scale factor between the physical pixels and the > logical pixels > * e.g. hdpi = 1.5, xhdpi = 2.0 > */ > > With the new Screen constructor, it seems to me both the UIScale and > the RenderScale need to be set to the NativeScreen.getScale(). If I > do that on my Nexus 5 where getScale() returns 3, however, only 1/3 > of the screen is used. It seems presentableState.width is set to 1/3 > of the logical width which is 1/3 of the physical width. I have 1080 > physical pixels, 360 logical pixels, but presentableState.width is > only 120. > > Looking at the diff in RT-27960, there are probably changes required > in MonocleApplication and MonocleWindow as well? > > - Johan > > > 2015-06-15 22:29 GMT+02:00 Jim Graham >: > > Screen.getPlatformScale() is the scaling from "FX pixels" to the > pixels that the platform uses for events and window coordinates. > Screen.getRenderScale() is the recommended scale for rendering - > typically "ceil(platformScale)". > > There is also Window.getOutputScale() which defaults to > getPlatformScale(). When rendering a scene we render at the > render scale and then blit it to the size indicated by the > output scale. When "renderscale = ceil(platformScale)", as it > does on Windows, we may be rendering at 200% for a window that > is at 150% on the screen, so the rendering happens at an integer > pixel scale and then we get the size on the screen appropriate > for what the Windows UI guidelines suggest. > > ...jim > > > On 6/15/15 9:37 AM, Johan Vos wrote: > > Hi, > > With the changes introduced in the fix for RT-27960 ( > https://bugs.openjdk.java.net/browse/JDK-8098184), the hidpi > support on > Android is broken. > > As part of the changes in > http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/670ed25ed138, > we > introduced a getScale method on NativeScreen, and the result > of this method > was used in the constructor of Screen (See > MonocleApplication.java). As an > example, on a Nexus 5 the getScale() would return 3.0, as > the device has > 1920x1080 physical pixels but we use a Scene with dimensions > 640x360. > > I'm not sure how to map this getScale() to the new > getPlatformScale() and > getRenderScale() though? > > - Johan > > > From ooo_saturn7 at mail.ru Tue Jun 16 20:58:35 2015 From: ooo_saturn7 at mail.ru (=?UTF-8?B?0JDQu9C10LrRgdCw0L3QtNGAINCh0LLQuNGA0LjQtNC+0LI=?=) Date: Tue, 16 Jun 2015 23:58:35 +0300 Subject: =?UTF-8?B?V2ViVmlldyBkb2Vzbid0IHJlbmRlciBodG1sIGlucHV0IGVsZW1lbnRz?= Message-ID: <1434488315.695076445@f355.i.mail.ru> I have very simple html code that includes 5 inputs with type="radio" (in one column) and webview in javafx8 which loads this page. The problem is the following - sometimes these radios are rendered sometimes not. For example, I start application - webview loads page, however there is empty space where these radio must be. But, when I move mouse at the area where these radios must be, they appear. I see this problem in linux - centos,ubuntu and windows xp. I've not seen this problem in Win7. How to fix it? From kevin.rushforth at oracle.com Tue Jun 16 21:11:56 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 16 Jun 2015 14:11:56 -0700 Subject: WebView doesn't render html input elements In-Reply-To: <1434488315.695076445@f355.i.mail.ru> References: <1434488315.695076445@f355.i.mail.ru> Message-ID: <5580911C.1000202@oracle.com> Do you have more than 100 total controls visible in your web page? If so, this is probably https://bugs.openjdk.java.net/browse/JDK-8093303 which was just fixed in 8u60. -- Kevin ????????? ???????? wrote: > I have very simple html code that includes 5 inputs with type="radio" (in one column) and webview in javafx8 which loads this page. The problem is the following - sometimes these radios are rendered sometimes not. For example, I start application - webview loads page, however there is empty space where these radio must be. But, when I move mouse at the area where these radios must be, they appear. I see this problem in linux - centos,ubuntu and windows xp. I've not seen this problem in Win7. How to fix it? > From ooo_saturn7 at mail.ru Tue Jun 16 22:08:23 2015 From: ooo_saturn7 at mail.ru (=?UTF-8?B?0JDQu9C10LrRgdCw0L3QtNGAINCh0LLQuNGA0LjQtNC+0LI=?=) Date: Wed, 17 Jun 2015 01:08:23 +0300 Subject: =?UTF-8?B?UmVbMl06IFdlYlZpZXcgZG9lc24ndCByZW5kZXIgaHRtbCBpbnB1dCBlbGVt?= =?UTF-8?B?ZW50cw==?= In-Reply-To: <5580911C.1000202@oracle.com> References: <1434488315.695076445@f355.i.mail.ru> <5580911C.1000202@oracle.com> Message-ID: <1434492502.943709502@f368.i.mail.ru> Thank you for your answer. No, I have only 5(five!) inputs on page. And I use oracle java 8.60. ???????, 16 ???? 2015, 14:11 -07:00 ?? Kevin Rushforth : >Do you have more than 100 total controls visible in your web page? If >so, this is probably https://bugs.openjdk.java.net/browse/JDK-8093303 >which was just fixed in 8u60. > >-- Kevin > > >????????? ???????? wrote: >> I have very simple html code that includes 5 inputs with type="radio" (in one column) and webview in javafx8 which loads this page. The problem is the following - sometimes these radios are rendered sometimes not. For example, I start application - webview loads page, however there is empty space where these radio must be. But, when I move mouse at the area where these radios must be, they appear. I see this problem in linux - centos,ubuntu and windows xp. I've not seen this problem in Win7. How to fix it? >> From ooo_saturn7 at mail.ru Tue Jun 16 22:21:33 2015 From: ooo_saturn7 at mail.ru (=?UTF-8?B?0JDQu9C10LrRgdCw0L3QtNGAINCh0LLQuNGA0LjQtNC+0LI=?=) Date: Wed, 17 Jun 2015 01:21:33 +0300 Subject: =?UTF-8?B?UmVbM106IFdlYlZpZXcgZG9lc24ndCByZW5kZXIgaHRtbCBpbnB1dCBlbGVt?= =?UTF-8?B?ZW50cw==?= Message-ID: <1434493292.589831578@f329.i.mail.ru> When I opened this page there were not any radios (but this page must have 5 radios). After that I moved mouse above 1,3,4,5 radio. See the result at the picture. -- ????????? ???????? From ooo_saturn7 at mail.ru Wed Jun 17 05:35:38 2015 From: ooo_saturn7 at mail.ru (=?UTF-8?B?0JDQu9C10LrRgdCw0L3QtNGAINCh0LLQuNGA0LjQtNC+0LI=?=) Date: Wed, 17 Jun 2015 08:35:38 +0300 Subject: =?UTF-8?B?V2ViVmlldyBkb2Vzbid0IHJlbmRlciBpbnB1dHMgLSBkZW1vIGNvZGU=?= Message-ID: <1434519338.636465191@f428.i.mail.ru> I have very simple html code (no css, nor js) that includes five inputs with type="radio" (in one column) and webview in JavaFX 8 which loads this page. The problem is the following - sometimes these radios are rendered sometimes not. For example, I start application - webview loads page, however there is empty space where these radio must be (these inputs are not rendered,they are not seen). But, when I move mouse over the area where these radios must be, they appear. I see this problem in Linux - Centos, Ubuntu and Windows XP. I've not seen this problem in Win7. Here is the code I tested. All the program consists of two classes: public class JavaFXApplication extends Application { private int count=0; @Override public void start(Stage primaryStage) { final Button printButton = new Button("Print"); final WebView webPage = new WebView(); final WebEngine webEngine = webPage.getEngine(); printButton.setOnAction(new EventHandler() { @Override public void handle(ActionEvent e) { String html="\n" + " \n" + "\n" + "\n" + " \n" + " \n" + " \n" + "\n" + "\n" + "

\n" + "????? ?? ?? ?? ????\n" + "????????? ????????? ???????

???????? ?????:

\n" + "\n" + "
\n" + "????????? ????????, ?????? ????
\n" + "?????? ????, ??? ?????
\n" + "?? ????, ?? ?????, ????? ???????
\n" + "?????? ?????, ??? ????
\n" + "?????? ?????
\n" + "
"; html+=count; count++; webEngine.loadContent(html); } }); HBox hbox = new HBox(); hbox.getChildren().addAll(printButton); BorderPane borderPane = new BorderPane(); borderPane.setTop(hbox); borderPane.setCenter(webPage); Scene scene = new Scene(borderPane, 300, 250); primaryStage.setTitle("WebView radio bugs"); primaryStage.setScene(scene); primaryStage.show(); } } And the second class public class JavaApplication { /** * @param args the command line arguments */ public static void main(String[] args) { Application.launch(JavaFXApplication.class, args); } } After that I click Print button. After every clicking count++. Compiled openjdk 1.8.45. Tested winxp oracle 1.8.40, centos71,ubuntu 12 oracle 1.8.60. The image from xp. 29 clicks after that no radios. Moved mouse over 1,3,5: . The result is on the image I attached. Please, answer. From David.Hill at Oracle.com Wed Jun 17 17:24:15 2015 From: David.Hill at Oracle.com (David Hill) Date: Wed, 17 Jun 2015 13:24:15 -0400 Subject: Review for ARM build change Message-ID: <5581AD3F.6020105@Oracle.com> Bug: https://bugs.openjdk.java.net/browse/JDK-8088110 Diff is in the text (one line). This change adds support for soft float i.MX6 -- David Hill Java Embedded Development "A man's feet should be planted in his country, but his eyes should survey the world." -- George Santayana (1863 - 1952) From David.Hill at Oracle.com Wed Jun 17 17:31:50 2015 From: David.Hill at Oracle.com (David Hill) Date: Wed, 17 Jun 2015 13:31:50 -0400 Subject: Changing -W to -Wextra for Linux builds Message-ID: <5581AF06.60401@Oracle.com> https://bugs.openjdk.java.net/browse/JDK-8088200 patch is attached to the bug, same fix multiple times: diff -r 132033191951 buildSrc/armv5sf.gradle --- a/buildSrc/armv5sf.gradle Fri May 29 17:09:06 2015 -0400 +++ b/buildSrc/armv5sf.gradle Fri May 29 20:39:07 2015 -0400 @@ -96,7 +96,7 @@ def commonFlags = [ "-fno-strict-aliasing", "-fPIC", "-fno-omit-frame-pointer", // optimization flags - "-W", "-Wall", "-Wno-unused", "-Wno-parentheses", "-Werror=implicit-function-declaration"] // warning flags + "-Wextra", "-Wall", "-Wno-unused", "-Wno-parentheses", "-Werror=implicit-function-declaration"] // warning flags // Specify the compilation parameters and link parameters def ccFlags = [ commonFlags, "-I$JDK_HOME/include", "-I$JDK_HOME/include/$jniPlatform", "-c", -- David Hill Java Embedded Development "A man's feet should be planted in his country, but his eyes should survey the world." -- George Santayana (1863 - 1952) From tobi at ultramixer.com Wed Jun 17 22:29:02 2015 From: tobi at ultramixer.com (Tobi) Date: Thu, 18 Jun 2015 00:29:02 +0200 Subject: JavaFX Metal port ob Mac OSX 10.11 El Capitan Message-ID: <81E8C218-4721-4BA0-8212-B479D3EE32E5@ultramixer.com> Hi, Are there any plans to port prism to use the new fast metal rendering pipeline on the upcoming OSX 10.11? Best regards, Tobi From kevin.rushforth at oracle.com Wed Jun 17 22:42:42 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 17 Jun 2015 15:42:42 -0700 Subject: JavaFX Metal port ob Mac OSX 10.11 El Capitan In-Reply-To: <81E8C218-4721-4BA0-8212-B479D3EE32E5@ultramixer.com> References: <81E8C218-4721-4BA0-8212-B479D3EE32E5@ultramixer.com> Message-ID: <5581F7E2.3090102@oracle.com> No immediate plans, but we would like to look into it. The problem is that it would be another pipeline to support, since we can't drop support for OS X 10.9 or 10.10 any time soon. This is also the reason we haven't done a DirectX 11 port. -- Kevin Tobi wrote: > Hi, > > Are there any plans to port prism to use the new fast metal rendering pipeline on the upcoming OSX 10.11? > > Best regards, > Tobi From anton.tarasov at oracle.com Thu Jun 18 15:30:20 2015 From: anton.tarasov at oracle.com (Anton V. Tarasov) Date: Thu, 18 Jun 2015 18:30:20 +0300 Subject: [9] request for review: JDK-8089990 [WebView] fix the race with generate/copy the InspectorJS* files Message-ID: <5582E40C.70706@oracle.com> Hi Kevin, Please, review the fix: JIRA: https://bugs.openjdk.java.net/browse/JDK-8089990 webrev: http://cr.openjdk.java.net/~ant/JDK-8089990/webrev.0 Thanks, Anton. From steve.hruda at hexagongeospatial.com Thu Jun 18 19:05:53 2015 From: steve.hruda at hexagongeospatial.com (Hruda, Steve) Date: Thu, 18 Jun 2015 19:05:53 +0000 Subject: Windows - Building OpenJFX with Webkit - Missing webview-deps:1.3 Message-ID: Hi, I tried to build the JFX?s Webkit version by using Michael?s mentioned workaround on windows, but I wasn?t successful. http://mail.openjdk.java.net/pipermail/openjfx-dev/2015-June/017424.html Is there another workaround? ?Or can anyone send me the needed file so that I can temporary add it to my private repository. Thanks in advance, Steve Diese E-Mail wurde versandt im Auftrag des Unternehmens Intergraph Ges.m.b.H. Vertretungsberechtigte Gesch?ftsf?hrer: Maximilian Weber Sitz der Gesellschaft: Margaretenstra?e 70/I/1, 1050 Wien, ?sterreich, Tel. +43 (1) 9610567-0 Eingetragen beim Handelsgericht Wien, Firmenbuch-Nr.: FN 116859 b Umsatzsteuer-Identifikationsnummer / VAT-ID: ATU15138401, Steuer-Nummer: 264/4807 This E-Mail has been sent on behalf of the company Intergraph Ges.m.b.H. Authorised Managing Directors: Maximilian Weber Registered office and Austrian headquarters: Margaretenstr. 70/I/1, 1050 Wien, Austria, Tel. +43 (1) 9610567-0 The company is recorded at the commercial court of Vienna under the company register number FN 116859 b VAT-ID: ATU15138401, Austrian Tax ID: 264/4807 Diese E-Mail (mit zugeh?rigen Dateien) enth?lt m?glicherweise Informationen, die vertraulich sind, dem Urheberrecht unterliegen oder ein Gesch?ftsgeheimnis darstellen. Falls Sie diese Nachricht irrt?mlicherweise erhalten haben, benachrichtigen Sie uns bitte umgehend, indem Sie eine Antwort senden, und l?schen Sie bitte diese E-Mail und Ihre Antwort darauf. S?mtliche aufgef?hrten Ansichten oder Meinungen sind ausschlie?lich diejenigen des Autors und entsprechen nicht notwendigerweise denen des Unternehmens Intergraph. This E-Mail (and any attachments) may be confidential and protected by legal privilege. If you are not the intended recipient please notify us immediately by replying to the sender and delete this E-Mail and your reply from your system. All the views and opinions published here are solely based on the author's own opinion and should not be considered necessarily as reflecting the opinion of Intergraph. From anton.tarasov at oracle.com Fri Jun 19 13:57:29 2015 From: anton.tarasov at oracle.com (Anton V. Tarasov) Date: Fri, 19 Jun 2015 16:57:29 +0300 Subject: Building OpenJFX with WebKit In-Reply-To: References: Message-ID: <55841FC9.5000109@oracle.com> Hi Ondra, Michael, On 16.06.2015 18:04, Michael Hoffer wrote: > Hi Ondra, > > I was able to build WebKit after reverting the version number from 1.3 to > 1.2. On Linux there should be a package called libicu48. I guess it is > equivalent to webview-deps 1.3. If you install it WebKit should compile. webview-deps 1.3 for Linux contains the following set of ICU 48: libicudata.a libicui18n.a libicuio.a libicuuc.a > > Regards, > Michael > > 2015-06-15 1:02 GMT+02:00 Ondra Pelech : > >> Hello, >> I'm trying to build OpenJFX with WebKit, but I'm missing the >> dependency com.sun.webkit:webview-deps:1.3 >> I've come across this thread from May >> http://comments.gmane.org/gmane.comp.java.openjdk.openjfx.devel/9447 >> but webkit:webview-deps:1.3 is still not on maven central We're going to put it in Central soon. Sorry for the delay. Regards, Anton. >> is there another place I can get it from? or how can I build it myself? >> >> thank you, best regards >> Ondra >> >> >> >> Building Webkit configuration /Release/ into >> /home/ondra/Projects/rt/modules/web/build/linux >> :web:compileNativeLinux FAILED >> >> FAILURE: Build failed with an exception. >> >> * Where: >> Build file '/home/ondra/Projects/rt/build.gradle' line: 2512 >> >> * What went wrong: >> Execution failed for task ':web:compileNativeLinux'. >>> Could not resolve all dependencies for configuration ':web:webkit'. >> > Could not find com.sun.webkit:webview-deps:1.3. >> Required by: >> rt:web:unspecified >> > > From anton.tarasov at oracle.com Fri Jun 19 14:03:19 2015 From: anton.tarasov at oracle.com (Anton V. Tarasov) Date: Fri, 19 Jun 2015 17:03:19 +0300 Subject: JavaFx: webview print with scale 100% In-Reply-To: <1434347604.864680804@f359.i.mail.ru> References: <1434347604.864680804@f359.i.mail.ru> Message-ID: <55842127.5020707@oracle.com> Hi Alexander, Could you please create and send a simple test case (fully functioning) with the exact URL of a page you're printing? Regards, Anotn. On 15.06.2015 8:53, ????????? ???????? wrote: > To print my html page I use the following code: > PrinterJob job =PrinterJob.createPrinterJob();if(job !=null&& job.showPrintDialog(null)){ > webView.getEngine().print(job); > job.endJob();} > The problem is that webview changes the scale of printing page. For example, when I print this html page in IE with fit to size 100% I get 16.8 cm. When I print in my java application I get 11.4cm. The size in html file I set in pt - my width is 475pt(A4 width=595pt,so 475pt=16.8cm). How to print with webview and to have 100% width and height? From anton.tarasov at oracle.com Fri Jun 19 14:06:52 2015 From: anton.tarasov at oracle.com (Anton V. Tarasov) Date: Fri, 19 Jun 2015 17:06:52 +0300 Subject: Windows - Building OpenJFX with Webkit - Missing webview-deps:1.3 In-Reply-To: References: Message-ID: <558421FC.3010008@oracle.com> Hi Hruda, On Windows you won't be able to build it with webview-deps 1.2 as you need ICU built for static linking. We're going to resume the activity of pushing the proper deps to Maven Central in the nearest time. Sorry for the incovinence. Anton. On 18.06.2015 22:05, Hruda, Steve wrote: > Hi, > I tried to build the JFX?s Webkit version by using Michael?s mentioned workaround on windows, but I wasn?t successful. > > http://mail.openjdk.java.net/pipermail/openjfx-dev/2015-June/017424.html > > Is there another workaround? > > ?Or can anyone send me the needed file so that I can temporary add it to my private repository. > > Thanks in advance, > Steve > > > > > Diese E-Mail wurde versandt im Auftrag des Unternehmens Intergraph Ges.m.b.H. > Vertretungsberechtigte Gesch?ftsf?hrer: Maximilian Weber > Sitz der Gesellschaft: Margaretenstra?e 70/I/1, 1050 Wien, ?sterreich, Tel. +43 (1) 9610567-0 > Eingetragen beim Handelsgericht Wien, Firmenbuch-Nr.: FN 116859 b > Umsatzsteuer-Identifikationsnummer / VAT-ID: ATU15138401, Steuer-Nummer: 264/4807 > > This E-Mail has been sent on behalf of the company Intergraph Ges.m.b.H. > Authorised Managing Directors: Maximilian Weber > Registered office and Austrian headquarters: Margaretenstr. 70/I/1, 1050 Wien, Austria, Tel. +43 (1) 9610567-0 > The company is recorded at the commercial court of Vienna under the company register number FN 116859 b > VAT-ID: ATU15138401, Austrian Tax ID: 264/4807 > > Diese E-Mail (mit zugeh?rigen Dateien) enth?lt m?glicherweise Informationen, die vertraulich sind, dem Urheberrecht unterliegen oder ein Gesch?ftsgeheimnis darstellen. Falls Sie diese Nachricht irrt?mlicherweise erhalten haben, benachrichtigen Sie uns bitte umgehend, indem Sie eine Antwort senden, und l?schen Sie bitte diese E-Mail und Ihre Antwort darauf. S?mtliche aufgef?hrten Ansichten oder Meinungen sind ausschlie?lich diejenigen des Autors und entsprechen nicht notwendigerweise denen des Unternehmens Intergraph. > > This E-Mail (and any attachments) may be confidential and protected by legal privilege. If you are not the intended recipient please notify us immediately by replying to the sender and delete this E-Mail and your reply from your system. All the views and opinions published here are solely based on the author's own opinion and should not be considered necessarily as reflecting the opinion of Intergraph. > > > > From ondra.pelech at gmail.com Fri Jun 19 18:19:03 2015 From: ondra.pelech at gmail.com (Ondra Pelech) Date: Fri, 19 Jun 2015 20:19:03 +0200 Subject: Building OpenJFX with WebKit In-Reply-To: <55841FC9.5000109@oracle.com> References: <55841FC9.5000109@oracle.com> Message-ID: lowering the version of webview-deps 1.3 --> 1.2 seems to be a step forward! but now I have another problem as you mentioned, there's this dependency on *.a static ICU libraries (why? why not depend on *.so?) in Fedora 20 there are only available dynamic *.so libraries (packages libicu and libicu-devel) so is there an easy way of obtaining those *.a? or do you have a rough estimate when would these libraries be available on central via webview-deps:1.3? thanks again, cheers On Fri, Jun 19, 2015 at 3:57 PM, Anton V. Tarasov wrote: > Hi Ondra, Michael, > > On 16.06.2015 18:04, Michael Hoffer wrote: >> >> Hi Ondra, >> >> I was able to build WebKit after reverting the version number from 1.3 to >> 1.2. On Linux there should be a package called libicu48. I guess it is >> equivalent to webview-deps 1.3. If you install it WebKit should compile. > > > webview-deps 1.3 for Linux contains the following set of ICU 48: > > libicudata.a > libicui18n.a > libicuio.a > libicuuc.a > >> >> Regards, >> Michael >> >> 2015-06-15 1:02 GMT+02:00 Ondra Pelech : >> >>> Hello, >>> I'm trying to build OpenJFX with WebKit, but I'm missing the >>> dependency com.sun.webkit:webview-deps:1.3 >>> I've come across this thread from May >>> http://comments.gmane.org/gmane.comp.java.openjdk.openjfx.devel/9447 >>> but webkit:webview-deps:1.3 is still not on maven central > > > We're going to put it in Central soon. Sorry for the delay. > > Regards, > Anton. > > > >>> is there another place I can get it from? or how can I build it myself? >>> >>> thank you, best regards >>> Ondra >>> >>> >>> >>> Building Webkit configuration /Release/ into >>> /home/ondra/Projects/rt/modules/web/build/linux >>> :web:compileNativeLinux FAILED >>> >>> FAILURE: Build failed with an exception. >>> >>> * Where: >>> Build file '/home/ondra/Projects/rt/build.gradle' line: 2512 >>> >>> * What went wrong: >>> Execution failed for task ':web:compileNativeLinux'. >>>> >>>> Could not resolve all dependencies for configuration ':web:webkit'. >>> >>> > Could not find com.sun.webkit:webview-deps:1.3. >>> Required by: >>> rt:web:unspecified >>> >> >> > From David.Hill at Oracle.com Fri Jun 19 20:29:39 2015 From: David.Hill at Oracle.com (David Hill) Date: Fri, 19 Jun 2015 16:29:39 -0400 Subject: review request: GTK resize issue Message-ID: <55847BB3.2080608@Oracle.com> https://bugs.openjdk.java.net/browse/JDK-8088811 webrev: http://cr.openjdk.java.net/~ddhill/8088811/ There were two issues addressed here: * fixed a boolean check before we call to make the window resizable (order of operations issue) * changed the function used to mark the window resizable (to gtk_window_set_resizable()) gtk_window_set_has_resize_grip() is only GTK3, and has a deprecated tag there, so it is odd that it was used. The test application works properly now, but I need to think about and perform more testing before I push this. -- David Hill Java Embedded Development "A man's feet should be planted in his country, but his eyes should survey the world." -- George Santayana (1863 - 1952) From ozemale at ozemail.com.au Sat Jun 20 04:21:11 2015 From: ozemale at ozemail.com.au (John C. Turnbull) Date: Sat, 20 Jun 2015 14:21:11 +1000 Subject: WebGL support in WebView Message-ID: <010501d0ab10$8a45efd0$9ed1cf70$@ozemail.com.au> When will WebView support WebGL? Thanks, -jct From kevin.rushforth at oracle.com Sat Jun 20 13:25:30 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Sat, 20 Jun 2015 06:25:30 -0700 Subject: WebGL support in WebView In-Reply-To: <010501d0ab10$8a45efd0$9ed1cf70$@ozemail.com.au> References: <010501d0ab10$8a45efd0$9ed1cf70$@ozemail.com.au> Message-ID: <558569CA.3090205@oracle.com> This is tracked by https://bugs.openjdk.java.net/browse/JDK-8091035 but is currently not targeted to a release. We could look into it for JDK 9 as a target of opportunity, but do not have concrete plans to do so. -- Kevin John C. Turnbull wrote: > When will WebView support WebGL? > > > > Thanks, > > > > -jct > > From kevin.rushforth at oracle.com Sat Jun 20 14:03:28 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Sat, 20 Jun 2015 07:03:28 -0700 Subject: In(Sanity) Testing Mondays Message-ID: <558572B0.6080207@oracle.com> Reminder, Monday is our weekly sanity testing. You can find your testing assignment at: https://wiki.openjdk.java.net/display/OpenJFX/Sanity+Testing Also please remember that the 8u-dev and 9-dev repos will be locked on Monday from 1am PDT until 1pm PDT. Additional rules will apply to 8u-dev once it is open back up on Monday afternoon. Happy testing! Thanks. -- Kevin From andrew.brygin at oracle.com Mon Jun 22 09:39:48 2015 From: andrew.brygin at oracle.com (Andrew Brygin) Date: Mon, 22 Jun 2015 12:39:48 +0300 Subject: Building OpenJFX with WebKit In-Reply-To: References: <55841FC9.5000109@oracle.com> Message-ID: <5587D7E4.7070407@oracle.com> Hello Ondra, please see my comment inline. On 6/19/2015 9:19 PM, Ondra Pelech wrote: > lowering the version of webview-deps 1.3 --> 1.2 seems to be a step forward! > but now I have another problem > > as you mentioned, there's this dependency on *.a static ICU libraries > (why? why not depend on *.so?) If you are going to use the result of your build on the same system, then the dependency on *.so is just fine. However, if you want to use your binaries on other linux ditors, the static ICU libraries is the only option: There are various major version of the ICU among modern linux distors: from 48 to 54 for now, and they export different set of symbols. > in Fedora 20 there are only available dynamic *.so libraries (packages > libicu and libicu-devel) > > so is there an easy way of obtaining those *.a? * download source bundle: http://download.icu-project.org/files/icu4c/4.8.1.1/icu4c-4_8_1_1-src.tgz * unpack it to some location * cd /icu/source * ./configure --enable-static * make * sudo make install The default prefix /usr/local works fine, the webkit build uses pkg-config to locate libraries. Thanks, Andrew > or do you have a rough estimate when would these libraries be > available on central via webview-deps:1.3? > thanks again, cheers > > > On Fri, Jun 19, 2015 at 3:57 PM, Anton V. Tarasov > wrote: >> Hi Ondra, Michael, >> >> On 16.06.2015 18:04, Michael Hoffer wrote: >>> Hi Ondra, >>> >>> I was able to build WebKit after reverting the version number from 1.3 to >>> 1.2. On Linux there should be a package called libicu48. I guess it is >>> equivalent to webview-deps 1.3. If you install it WebKit should compile. >> >> webview-deps 1.3 for Linux contains the following set of ICU 48: >> >> libicudata.a >> libicui18n.a >> libicuio.a >> libicuuc.a >> >>> Regards, >>> Michael >>> >>> 2015-06-15 1:02 GMT+02:00 Ondra Pelech : >>> >>>> Hello, >>>> I'm trying to build OpenJFX with WebKit, but I'm missing the >>>> dependency com.sun.webkit:webview-deps:1.3 >>>> I've come across this thread from May >>>> http://comments.gmane.org/gmane.comp.java.openjdk.openjfx.devel/9447 >>>> but webkit:webview-deps:1.3 is still not on maven central >> >> We're going to put it in Central soon. Sorry for the delay. >> >> Regards, >> Anton. >> >> >> >>>> is there another place I can get it from? or how can I build it myself? >>>> >>>> thank you, best regards >>>> Ondra >>>> >>>> >>>> >>>> Building Webkit configuration /Release/ into >>>> /home/ondra/Projects/rt/modules/web/build/linux >>>> :web:compileNativeLinux FAILED >>>> >>>> FAILURE: Build failed with an exception. >>>> >>>> * Where: >>>> Build file '/home/ondra/Projects/rt/build.gradle' line: 2512 >>>> >>>> * What went wrong: >>>> Execution failed for task ':web:compileNativeLinux'. >>>>> Could not resolve all dependencies for configuration ':web:webkit'. >>>> > Could not find com.sun.webkit:webview-deps:1.3. >>>> Required by: >>>> rt:web:unspecified >>>> >>> From anton.tarasov at oracle.com Mon Jun 22 12:14:35 2015 From: anton.tarasov at oracle.com (Anton V. Tarasov) Date: Mon, 22 Jun 2015 15:14:35 +0300 Subject: Building OpenJFX with WebKit In-Reply-To: References: <55841FC9.5000109@oracle.com> Message-ID: <5587FC2B.9020202@oracle.com> Hi Ondra, On 19.06.2015 21:19, Ondra Pelech wrote: > lowering the version of webview-deps 1.3 --> 1.2 seems to be a step forward! > but now I have another problem > > as you mentioned, there's this dependency on *.a static ICU libraries > (why? why not depend on *.so?) > in Fedora 20 there are only available dynamic *.so libraries (packages > libicu and libicu-devel) [Anrew answered this question] > > so is there an easy way of obtaining those *.a? > or do you have a rough estimate when would these libraries be > available on central via webview-deps:1.3? When we pass 8u60 "hot phase" and get to be a little bit more flexible with our resources. So, roughly it may take ~2 weeks or so until new webview-deps appear on Central, I guess. Regards Anton. > thanks again, cheers > > > On Fri, Jun 19, 2015 at 3:57 PM, Anton V. Tarasov > wrote: >> Hi Ondra, Michael, >> >> On 16.06.2015 18:04, Michael Hoffer wrote: >>> Hi Ondra, >>> >>> I was able to build WebKit after reverting the version number from 1.3 to >>> 1.2. On Linux there should be a package called libicu48. I guess it is >>> equivalent to webview-deps 1.3. If you install it WebKit should compile. >> >> webview-deps 1.3 for Linux contains the following set of ICU 48: >> >> libicudata.a >> libicui18n.a >> libicuio.a >> libicuuc.a >> >>> Regards, >>> Michael >>> >>> 2015-06-15 1:02 GMT+02:00 Ondra Pelech : >>> >>>> Hello, >>>> I'm trying to build OpenJFX with WebKit, but I'm missing the >>>> dependency com.sun.webkit:webview-deps:1.3 >>>> I've come across this thread from May >>>> http://comments.gmane.org/gmane.comp.java.openjdk.openjfx.devel/9447 >>>> but webkit:webview-deps:1.3 is still not on maven central >> >> We're going to put it in Central soon. Sorry for the delay. >> >> Regards, >> Anton. >> >> >> >>>> is there another place I can get it from? or how can I build it myself? >>>> >>>> thank you, best regards >>>> Ondra >>>> >>>> >>>> >>>> Building Webkit configuration /Release/ into >>>> /home/ondra/Projects/rt/modules/web/build/linux >>>> :web:compileNativeLinux FAILED >>>> >>>> FAILURE: Build failed with an exception. >>>> >>>> * Where: >>>> Build file '/home/ondra/Projects/rt/build.gradle' line: 2512 >>>> >>>> * What went wrong: >>>> Execution failed for task ':web:compileNativeLinux'. >>>>> Could not resolve all dependencies for configuration ':web:webkit'. >>>> > Could not find com.sun.webkit:webview-deps:1.3. >>>> Required by: >>>> rt:web:unspecified >>>> >>> From kevin.rushforth at oracle.com Mon Jun 22 20:26:48 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 22 Jun 2015 13:26:48 -0700 Subject: 8u-dev and 9-dev unlocked -- Rampdown rules in effect for 8u-dev Message-ID: <55886F88.7080109@oracle.com> 8u-dev and 9-dev are open following this week's testing. As previously communicated [1] and stated on the JavaFX Wiki [2] the following rampdown rules for 8u60 are in effect this week for pushing changes to 8u-dev: Mon, Jun 22 to Sun, Jun 28 ? regressions and critical bugs only, tech lead approval required All bug fixes going into 8u-dev require a pre-commit review and an additional "+1" from me; an exception is made for changesets that do not touch shipping code, such as fixes to unit tests and non-shipping examples/toys Changes should go to 9-dev first (which may be done with either a pre-commit or post-commit review) and then backported to 8u-dev for 8u60 with a pre-commit review. -- Kevin [1] http://mail.openjdk.java.net/pipermail/openjfx-dev/2015-May/017296.html [2] https://wiki.openjdk.java.net/display/OpenJFX/8u60 From steve.hruda at hexagongeospatial.com Tue Jun 23 14:40:01 2015 From: steve.hruda at hexagongeospatial.com (Hruda, Steve) Date: Tue, 23 Jun 2015 14:40:01 +0000 Subject: Patch for JDK-8090098 - [regression] Webview - getTimezoneOffset() of a ISO strings returns a wrong value Message-ID: Hi, I've created a 8u-dev patch for the following WeKit regression which comes with 8u60. https://bugs.openjdk.java.net/browse/JDK-8090098 Please can someone of you apply this patch to fix the getTimezoneOffset() issue. I have no access to the repository -> my OCA is still pending. In addition I tried to test this patch , but I wasn't able to build the necessary jfxwebkit.dll on my windows system (https://www.mail-archive.com/openjfx-dev at openjdk.java.net/msg09439.html )..... but I got no compile erros on Mac. Patch download: https://drive.google.com/file/d/0B7P_rknS1TWxM3BSTTU2OVZ4dGM/view?usp=sharing The patch includes the following WebKit fixes: Changeset 174377 - [Win] DateMath's calculateUTFOffset does not account for DST. http://trac.webkit.org/changeset/174377 Changeset 175078 - String(new Date(Mar 30 2014 01:00:00)) is wrong in CET http://trac.webkit.org/changeset/175078 Changeset 181360 - [Win] 17 different JSC tests started to fail in DST http://trac.webkit.org/changeset/181360 Please let me know if you need further information. Thanks in advance! Best Regards Steve Diese E-Mail wurde versandt im Auftrag des Unternehmens Intergraph Ges.m.b.H. Vertretungsberechtigte Gesch?ftsf?hrer: Maximilian Weber Sitz der Gesellschaft: Margaretenstra?e 70/I/1, 1050 Wien, ?sterreich, Tel. +43 (1) 9610567-0 Eingetragen beim Handelsgericht Wien, Firmenbuch-Nr.: FN 116859 b Umsatzsteuer-Identifikationsnummer / VAT-ID: ATU15138401, Steuer-Nummer: 264/4807 This E-Mail has been sent on behalf of the company Intergraph Ges.m.b.H. Authorised Managing Directors: Maximilian Weber Registered office and Austrian headquarters: Margaretenstr. 70/I/1, 1050 Wien, Austria, Tel. +43 (1) 9610567-0 The company is recorded at the commercial court of Vienna under the company register number FN 116859 b VAT-ID: ATU15138401, Austrian Tax ID: 264/4807 Diese E-Mail (mit zugeh?rigen Dateien) enth?lt m?glicherweise Informationen, die vertraulich sind, dem Urheberrecht unterliegen oder ein Gesch?ftsgeheimnis darstellen. Falls Sie diese Nachricht irrt?mlicherweise erhalten haben, benachrichtigen Sie uns bitte umgehend, indem Sie eine Antwort senden, und l?schen Sie bitte diese E-Mail und Ihre Antwort darauf. S?mtliche aufgef?hrten Ansichten oder Meinungen sind ausschlie?lich diejenigen des Autors und entsprechen nicht notwendigerweise denen des Unternehmens Intergraph. This E-Mail (and any attachments) may be confidential and protected by legal privilege. If you are not the intended recipient please notify us immediately by replying to the sender and delete this E-Mail and your reply from your system. All the views and opinions published here are solely based on the author's own opinion and should not be considered necessarily as reflecting the opinion of Intergraph. From kevin.rushforth at oracle.com Tue Jun 23 14:48:22 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 23 Jun 2015 07:48:22 -0700 Subject: Patch for JDK-8090098 - [regression] Webview - getTimezoneOffset() of a ISO strings returns a wrong value In-Reply-To: References: Message-ID: <558971B6.1060901@oracle.com> Hi Steve, Thank you for taking the time to create this patch. I will add this information to the bug report. Since your OCA is in progress we will take a look at your patch, but will need indication from the OCA office that it the OCA has been received before we could push it. And just to be clear, you won't have access to the repository even with an OCA. What the OCA will do is allow you to contribute patches. I will note that it is likely too late for 8u60, but Anton can evaluate it and post his comment in the bug report. -- Kevin Hruda, Steve wrote: > Hi, > I've created a 8u-dev patch for the following WeKit regression which comes with 8u60. > https://bugs.openjdk.java.net/browse/JDK-8090098 > > Please can someone of you apply this patch to fix the getTimezoneOffset() issue. I have no access to the repository -> my OCA is still pending. > > In addition I tried to test this patch , but I wasn't able to build the necessary jfxwebkit.dll on my windows system (https://www.mail-archive.com/openjfx-dev at openjdk.java.net/msg09439.html )..... but I got no compile erros on Mac. > > Patch download: > https://drive.google.com/file/d/0B7P_rknS1TWxM3BSTTU2OVZ4dGM/view?usp=sharing > > The patch includes the following WebKit fixes: > Changeset 174377 - [Win] DateMath's calculateUTFOffset does not account for DST. > http://trac.webkit.org/changeset/174377 > > Changeset 175078 - String(new Date(Mar 30 2014 01:00:00)) is wrong in CET > http://trac.webkit.org/changeset/175078 > > Changeset 181360 - [Win] 17 different JSC tests started to fail in DST > http://trac.webkit.org/changeset/181360 > > Please let me know if you need further information. > > Thanks in advance! > Best Regards > Steve > > > > Diese E-Mail wurde versandt im Auftrag des Unternehmens Intergraph Ges.m.b.H. > Vertretungsberechtigte Gesch?ftsf?hrer: Maximilian Weber > Sitz der Gesellschaft: Margaretenstra?e 70/I/1, 1050 Wien, ?sterreich, Tel. +43 (1) 9610567-0 > Eingetragen beim Handelsgericht Wien, Firmenbuch-Nr.: FN 116859 b > Umsatzsteuer-Identifikationsnummer / VAT-ID: ATU15138401, Steuer-Nummer: 264/4807 > > This E-Mail has been sent on behalf of the company Intergraph Ges.m.b.H. > Authorised Managing Directors: Maximilian Weber > Registered office and Austrian headquarters: Margaretenstr. 70/I/1, 1050 Wien, Austria, Tel. +43 (1) 9610567-0 > The company is recorded at the commercial court of Vienna under the company register number FN 116859 b > VAT-ID: ATU15138401, Austrian Tax ID: 264/4807 > > Diese E-Mail (mit zugeh?rigen Dateien) enth?lt m?glicherweise Informationen, die vertraulich sind, dem Urheberrecht unterliegen oder ein Gesch?ftsgeheimnis darstellen. Falls Sie diese Nachricht irrt?mlicherweise erhalten haben, benachrichtigen Sie uns bitte umgehend, indem Sie eine Antwort senden, und l?schen Sie bitte diese E-Mail und Ihre Antwort darauf. S?mtliche aufgef?hrten Ansichten oder Meinungen sind ausschlie?lich diejenigen des Autors und entsprechen nicht notwendigerweise denen des Unternehmens Intergraph. > > This E-Mail (and any attachments) may be confidential and protected by legal privilege. If you are not the intended recipient please notify us immediately by replying to the sender and delete this E-Mail and your reply from your system. All the views and opinions published here are solely based on the author's own opinion and should not be considered necessarily as reflecting the opinion of Intergraph. > > > From anton.tarasov at oracle.com Tue Jun 23 15:28:21 2015 From: anton.tarasov at oracle.com (Anton V. Tarasov) Date: Tue, 23 Jun 2015 18:28:21 +0300 Subject: [9/8u60] Request for review: JDK-8087932 [Mac] intermittent crash on exit in WebView Message-ID: <55897B15.2020809@oracle.com> Hi Kevin, Please review the fix: JBS: https://bugs.openjdk.java.net/browse/JDK-8087932 webrev: http://cr.openjdk.java.net/~ant/JDK-8087932/webrev.0 Thanks, Anton. From anton.tarasov at oracle.com Tue Jun 23 15:45:44 2015 From: anton.tarasov at oracle.com (Anton V. Tarasov) Date: Tue, 23 Jun 2015 18:45:44 +0300 Subject: Patch for JDK-8090098 - [regression] Webview - getTimezoneOffset() of a ISO strings returns a wrong value In-Reply-To: <558971B6.1060901@oracle.com> References: <558971B6.1060901@oracle.com> Message-ID: <55897F27.9050104@oracle.com> On 23.06.2015 17:48, Kevin Rushforth wrote: > Hi Steve, > > Thank you for taking the time to create this patch. I will add this information to the bug report. > > Since your OCA is in progress we will take a look at your patch, but will need indication from the > OCA office that it the OCA has been received before we could push it. And just to be clear, you > won't have access to the repository even with an OCA. What the OCA will do is allow you to > contribute patches. > > I will note that it is likely too late for 8u60, but Anton can evaluate it and post his comment in > the bug report. Kevin, I'm checking it. Steve, thanks for the participation! Regards, Anton. > > -- Kevin > > > Hruda, Steve wrote: >> Hi, >> I've created a 8u-dev patch for the following WeKit regression which comes with 8u60. >> https://bugs.openjdk.java.net/browse/JDK-8090098 >> >> Please can someone of you apply this patch to fix the getTimezoneOffset() issue. I have no access >> to the repository -> my OCA is still pending. >> >> In addition I tried to test this patch , but I wasn't able to build the necessary jfxwebkit.dll >> on my windows system (https://www.mail-archive.com/openjfx-dev at openjdk.java.net/msg09439.html >> )..... but I got no compile erros on Mac. >> >> Patch download: >> https://drive.google.com/file/d/0B7P_rknS1TWxM3BSTTU2OVZ4dGM/view?usp=sharing >> >> The patch includes the following WebKit fixes: >> Changeset 174377 - [Win] DateMath's calculateUTFOffset does not account for DST. >> http://trac.webkit.org/changeset/174377 >> >> Changeset 175078 - String(new Date(Mar 30 2014 01:00:00)) is wrong in CET >> http://trac.webkit.org/changeset/175078 >> >> Changeset 181360 - [Win] 17 different JSC tests started to fail in DST >> http://trac.webkit.org/changeset/181360 >> >> Please let me know if you need further information. >> >> Thanks in advance! >> Best Regards >> Steve >> >> >> >> Diese E-Mail wurde versandt im Auftrag des Unternehmens Intergraph Ges.m.b.H. >> Vertretungsberechtigte Gesch?ftsf?hrer: Maximilian Weber >> Sitz der Gesellschaft: Margaretenstra?e 70/I/1, 1050 Wien, ?sterreich, Tel. +43 (1) 9610567-0 >> Eingetragen beim Handelsgericht Wien, Firmenbuch-Nr.: FN 116859 b >> Umsatzsteuer-Identifikationsnummer / VAT-ID: ATU15138401, Steuer-Nummer: 264/4807 >> >> This E-Mail has been sent on behalf of the company Intergraph Ges.m.b.H. >> Authorised Managing Directors: Maximilian Weber >> Registered office and Austrian headquarters: Margaretenstr. 70/I/1, 1050 Wien, Austria, Tel. +43 >> (1) 9610567-0 >> The company is recorded at the commercial court of Vienna under the company register number FN >> 116859 b >> VAT-ID: ATU15138401, Austrian Tax ID: 264/4807 >> >> Diese E-Mail (mit zugeh?rigen Dateien) enth?lt m?glicherweise Informationen, die vertraulich >> sind, dem Urheberrecht unterliegen oder ein Gesch?ftsgeheimnis darstellen. Falls Sie diese >> Nachricht irrt?mlicherweise erhalten haben, benachrichtigen Sie uns bitte umgehend, indem Sie >> eine Antwort senden, und l?schen Sie bitte diese E-Mail und Ihre Antwort darauf. S?mtliche >> aufgef?hrten Ansichten oder Meinungen sind ausschlie?lich diejenigen des Autors und entsprechen >> nicht notwendigerweise denen des Unternehmens Intergraph. >> >> This E-Mail (and any attachments) may be confidential and protected by legal privilege. If you >> are not the intended recipient please notify us immediately by replying to the sender and delete >> this E-Mail and your reply from your system. All the views and opinions published here are solely >> based on the author's own opinion and should not be considered necessarily as reflecting the >> opinion of Intergraph. >> >> From steve.hruda at hexagongeospatial.com Tue Jun 23 16:15:41 2015 From: steve.hruda at hexagongeospatial.com (Hruda, Steve) Date: Tue, 23 Jun 2015 16:15:41 +0000 Subject: Patch for JDK-8090098 - [regression] Webview - getTimezoneOffset() of a ISO strings returns a wrong value In-Reply-To: <558971B6.1060901@oracle.com> References: <558971B6.1060901@oracle.com> Message-ID: Hi Kevin, I misunderstand something ... about the OCA. My OCA has been processed and I'm listed on the OCA signatories page http://www.oracle.com/technetwork/community/oca-486395.html#h Therefore this should not the problem. Best Regards, Steve Diese E-Mail wurde versandt im Auftrag des Unternehmens Intergraph Ges.m.b.H. Vertretungsberechtigte Gesch?ftsf?hrer: Maximilian Weber Sitz der Gesellschaft: Margaretenstra?e 70/I/1, 1050 Wien, ?sterreich, Tel. +43 (1) 9610567-0 Eingetragen beim Handelsgericht Wien, Firmenbuch-Nr.: FN 116859 b Umsatzsteuer-Identifikationsnummer / VAT-ID: ATU15138401, Steuer-Nummer: 264/4807 This E-Mail has been sent on behalf of the company Intergraph Ges.m.b.H. Authorised Managing Directors: Maximilian Weber Registered office and Austrian headquarters: Margaretenstr. 70/I/1, 1050 Wien, Austria, Tel. +43 (1) 9610567-0 The company is recorded at the commercial court of Vienna under the company register number FN 116859 b VAT-ID: ATU15138401, Austrian Tax ID: 264/4807 Diese E-Mail (mit zugeh?rigen Dateien) enth?lt m?glicherweise Informationen, die vertraulich sind, dem Urheberrecht unterliegen oder ein Gesch?ftsgeheimnis darstellen. Falls Sie diese Nachricht irrt?mlicherweise erhalten haben, benachrichtigen Sie uns bitte umgehend, indem Sie eine Antwort senden, und l?schen Sie bitte diese E-Mail und Ihre Antwort darauf. S?mtliche aufgef?hrten Ansichten oder Meinungen sind ausschlie?lich diejenigen des Autors und entsprechen nicht notwendigerweise denen des Unternehmens Intergraph. This E-Mail (and any attachments) may be confidential and protected by legal privilege. If you are not the intended recipient please notify us immediately by replying to the sender and delete this E-Mail and your reply from your system. All the views and opinions published here are solely based on the author's own opinion and should not be considered necessarily as reflecting the opinion of Intergraph. -----Original Message----- From: Kevin Rushforth [mailto:kevin.rushforth at oracle.com] Sent: Tuesday, June 23, 2015 4:48 PM To: Hruda, Steve Cc: openjfx-dev at openjdk.java.net Subject: Re: Patch for JDK-8090098 - [regression] Webview - getTimezoneOffset() of a ISO strings returns a wrong value Hi Steve, Thank you for taking the time to create this patch. I will add this information to the bug report. Since your OCA is in progress we will take a look at your patch, but will need indication from the OCA office that it the OCA has been received before we could push it. And just to be clear, you won't have access to the repository even with an OCA. What the OCA will do is allow you to contribute patches. I will note that it is likely too late for 8u60, but Anton can evaluate it and post his comment in the bug report. -- Kevin Hruda, Steve wrote: > Hi, > I've created a 8u-dev patch for the following WeKit regression which comes with 8u60. > https://bugs.openjdk.java.net/browse/JDK-8090098 > > Please can someone of you apply this patch to fix the getTimezoneOffset() issue. I have no access to the repository -> my OCA is still pending. > > In addition I tried to test this patch , but I wasn't able to build the necessary jfxwebkit.dll on my windows system (https://www.mail-archive.com/openjfx-dev at openjdk.java.net/msg09439.html )..... but I got no compile erros on Mac. > > Patch download: > https://drive.google.com/file/d/0B7P_rknS1TWxM3BSTTU2OVZ4dGM/view?usp= > sharing > > The patch includes the following WebKit fixes: > Changeset 174377 - [Win] DateMath's calculateUTFOffset does not account for DST. > http://trac.webkit.org/changeset/174377 > > Changeset 175078 - String(new Date(Mar 30 2014 01:00:00)) is wrong in > CET > http://trac.webkit.org/changeset/175078 > > Changeset 181360 - [Win] 17 different JSC tests started to fail in DST > http://trac.webkit.org/changeset/181360 > > Please let me know if you need further information. > > Thanks in advance! > Best Regards > Steve > > > > Diese E-Mail wurde versandt im Auftrag des Unternehmens Intergraph Ges.m.b.H. > Vertretungsberechtigte Gesch?ftsf?hrer: Maximilian Weber Sitz der > Gesellschaft: Margaretenstra?e 70/I/1, 1050 Wien, ?sterreich, Tel. +43 > (1) 9610567-0 Eingetragen beim Handelsgericht Wien, Firmenbuch-Nr.: FN > 116859 b Umsatzsteuer-Identifikationsnummer / VAT-ID: ATU15138401, > Steuer-Nummer: 264/4807 > > This E-Mail has been sent on behalf of the company Intergraph Ges.m.b.H. > Authorised Managing Directors: Maximilian Weber Registered office and > Austrian headquarters: Margaretenstr. 70/I/1, 1050 Wien, Austria, Tel. > +43 (1) 9610567-0 The company is recorded at the commercial court of > Vienna under the company register number FN 116859 b > VAT-ID: ATU15138401, Austrian Tax ID: 264/4807 > > Diese E-Mail (mit zugeh?rigen Dateien) enth?lt m?glicherweise Informationen, die vertraulich sind, dem Urheberrecht unterliegen oder ein Gesch?ftsgeheimnis darstellen. Falls Sie diese Nachricht irrt?mlicherweise erhalten haben, benachrichtigen Sie uns bitte umgehend, indem Sie eine Antwort senden, und l?schen Sie bitte diese E-Mail und Ihre Antwort darauf. S?mtliche aufgef?hrten Ansichten oder Meinungen sind ausschlie?lich diejenigen des Autors und entsprechen nicht notwendigerweise denen des Unternehmens Intergraph. > > This E-Mail (and any attachments) may be confidential and protected by legal privilege. If you are not the intended recipient please notify us immediately by replying to the sender and delete this E-Mail and your reply from your system. All the views and opinions published here are solely based on the author's own opinion and should not be considered necessarily as reflecting the opinion of Intergraph. > > > From kevin.rushforth at oracle.com Tue Jun 23 16:18:57 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 23 Jun 2015 09:18:57 -0700 Subject: Patch for JDK-8090098 - [regression] Webview - getTimezoneOffset() of a ISO strings returns a wrong value In-Reply-To: References: <558971B6.1060901@oracle.com> Message-ID: <558986F1.8090704@oracle.com> OK, good. I see you there. -- Kevin Hruda, Steve wrote: > Hi Kevin, > I misunderstand something ... about the OCA. > > My OCA has been processed and I'm listed on the OCA signatories page http://www.oracle.com/technetwork/community/oca-486395.html#h > Therefore this should not the problem. > > Best Regards, > Steve > > > > > > > Diese E-Mail wurde versandt im Auftrag des Unternehmens Intergraph Ges.m.b.H. > Vertretungsberechtigte Gesch?ftsf?hrer: Maximilian Weber > Sitz der Gesellschaft: Margaretenstra?e 70/I/1, 1050 Wien, ?sterreich, Tel. +43 (1) 9610567-0 > Eingetragen beim Handelsgericht Wien, Firmenbuch-Nr.: FN 116859 b > Umsatzsteuer-Identifikationsnummer / VAT-ID: ATU15138401, Steuer-Nummer: 264/4807 > > This E-Mail has been sent on behalf of the company Intergraph Ges.m.b.H. > Authorised Managing Directors: Maximilian Weber > Registered office and Austrian headquarters: Margaretenstr. 70/I/1, 1050 Wien, Austria, Tel. +43 (1) 9610567-0 > The company is recorded at the commercial court of Vienna under the company register number FN 116859 b > VAT-ID: ATU15138401, Austrian Tax ID: 264/4807 > > Diese E-Mail (mit zugeh?rigen Dateien) enth?lt m?glicherweise Informationen, die vertraulich sind, dem Urheberrecht unterliegen oder ein Gesch?ftsgeheimnis darstellen. Falls Sie diese Nachricht irrt?mlicherweise erhalten haben, benachrichtigen Sie uns bitte umgehend, indem Sie eine Antwort senden, und l?schen Sie bitte diese E-Mail und Ihre Antwort darauf. S?mtliche aufgef?hrten Ansichten oder Meinungen sind ausschlie?lich diejenigen des Autors und entsprechen nicht notwendigerweise denen des Unternehmens Intergraph. > > This E-Mail (and any attachments) may be confidential and protected by legal privilege. If you are not the intended recipient please notify us immediately by replying to the sender and delete this E-Mail and your reply from your system. All the views and opinions published here are solely based on the author's own opinion and should not be considered necessarily as reflecting the opinion of Intergraph. > > > -----Original Message----- > From: Kevin Rushforth [mailto:kevin.rushforth at oracle.com] > Sent: Tuesday, June 23, 2015 4:48 PM > To: Hruda, Steve > Cc: openjfx-dev at openjdk.java.net > Subject: Re: Patch for JDK-8090098 - [regression] Webview - getTimezoneOffset() of a ISO strings returns a wrong value > > Hi Steve, > > Thank you for taking the time to create this patch. I will add this information to the bug report. > > Since your OCA is in progress we will take a look at your patch, but will need indication from the OCA office that it the OCA has been received before we could push it. And just to be clear, you won't have access to the repository even with an OCA. What the OCA will do is allow you to contribute patches. > > I will note that it is likely too late for 8u60, but Anton can evaluate it and post his comment in the bug report. > > -- Kevin > > > Hruda, Steve wrote: > >> Hi, >> I've created a 8u-dev patch for the following WeKit regression which comes with 8u60. >> https://bugs.openjdk.java.net/browse/JDK-8090098 >> >> Please can someone of you apply this patch to fix the getTimezoneOffset() issue. I have no access to the repository -> my OCA is still pending. >> >> In addition I tried to test this patch , but I wasn't able to build the necessary jfxwebkit.dll on my windows system (https://www.mail-archive.com/openjfx-dev at openjdk.java.net/msg09439.html )..... but I got no compile erros on Mac. >> >> Patch download: >> https://drive.google.com/file/d/0B7P_rknS1TWxM3BSTTU2OVZ4dGM/view?usp= >> sharing >> >> The patch includes the following WebKit fixes: >> Changeset 174377 - [Win] DateMath's calculateUTFOffset does not account for DST. >> http://trac.webkit.org/changeset/174377 >> >> Changeset 175078 - String(new Date(Mar 30 2014 01:00:00)) is wrong in >> CET >> http://trac.webkit.org/changeset/175078 >> >> Changeset 181360 - [Win] 17 different JSC tests started to fail in DST >> http://trac.webkit.org/changeset/181360 >> >> Please let me know if you need further information. >> >> Thanks in advance! >> Best Regards >> Steve >> >> >> >> Diese E-Mail wurde versandt im Auftrag des Unternehmens Intergraph Ges.m.b.H. >> Vertretungsberechtigte Gesch?ftsf?hrer: Maximilian Weber Sitz der >> Gesellschaft: Margaretenstra?e 70/I/1, 1050 Wien, ?sterreich, Tel. +43 >> (1) 9610567-0 Eingetragen beim Handelsgericht Wien, Firmenbuch-Nr.: FN >> 116859 b Umsatzsteuer-Identifikationsnummer / VAT-ID: ATU15138401, >> Steuer-Nummer: 264/4807 >> >> This E-Mail has been sent on behalf of the company Intergraph Ges.m.b.H. >> Authorised Managing Directors: Maximilian Weber Registered office and >> Austrian headquarters: Margaretenstr. 70/I/1, 1050 Wien, Austria, Tel. >> +43 (1) 9610567-0 The company is recorded at the commercial court of >> Vienna under the company register number FN 116859 b >> VAT-ID: ATU15138401, Austrian Tax ID: 264/4807 >> >> Diese E-Mail (mit zugeh?rigen Dateien) enth?lt m?glicherweise Informationen, die vertraulich sind, dem Urheberrecht unterliegen oder ein Gesch?ftsgeheimnis darstellen. Falls Sie diese Nachricht irrt?mlicherweise erhalten haben, benachrichtigen Sie uns bitte umgehend, indem Sie eine Antwort senden, und l?schen Sie bitte diese E-Mail und Ihre Antwort darauf. S?mtliche aufgef?hrten Ansichten oder Meinungen sind ausschlie?lich diejenigen des Autors und entsprechen nicht notwendigerweise denen des Unternehmens Intergraph. >> >> This E-Mail (and any attachments) may be confidential and protected by legal privilege. If you are not the intended recipient please notify us immediately by replying to the sender and delete this E-Mail and your reply from your system. All the views and opinions published here are solely based on the author's own opinion and should not be considered necessarily as reflecting the opinion of Intergraph. >> >> >> >> > > From steve.hruda at hexagongeospatial.com Tue Jun 23 16:25:44 2015 From: steve.hruda at hexagongeospatial.com (Hruda, Steve) Date: Tue, 23 Jun 2015 16:25:44 +0000 Subject: Patch for JDK-8090098 - [regression] Webview - getTimezoneOffset() of a ISO strings returns a wrong value In-Reply-To: <55897F27.9050104@oracle.com> References: <558971B6.1060901@oracle.com> <55897F27.9050104@oracle.com> Message-ID: Very cool Anton. I would be great if that pach could be added to 8u60, otherwise our all our customers have to avoid Java 8u60. Regards, Steve Diese E-Mail wurde versandt im Auftrag des Unternehmens Intergraph Ges.m.b.H. Vertretungsberechtigte Gesch?ftsf?hrer: Maximilian Weber Sitz der Gesellschaft: Margaretenstra?e 70/I/1, 1050 Wien, ?sterreich, Tel. +43 (1) 9610567-0 Eingetragen beim Handelsgericht Wien, Firmenbuch-Nr.: FN 116859 b Umsatzsteuer-Identifikationsnummer / VAT-ID: ATU15138401, Steuer-Nummer: 264/4807 This E-Mail has been sent on behalf of the company Intergraph Ges.m.b.H. Authorised Managing Directors: Maximilian Weber Registered office and Austrian headquarters: Margaretenstr. 70/I/1, 1050 Wien, Austria, Tel. +43 (1) 9610567-0 The company is recorded at the commercial court of Vienna under the company register number FN 116859 b VAT-ID: ATU15138401, Austrian Tax ID: 264/4807 Diese E-Mail (mit zugeh?rigen Dateien) enth?lt m?glicherweise Informationen, die vertraulich sind, dem Urheberrecht unterliegen oder ein Gesch?ftsgeheimnis darstellen. Falls Sie diese Nachricht irrt?mlicherweise erhalten haben, benachrichtigen Sie uns bitte umgehend, indem Sie eine Antwort senden, und l?schen Sie bitte diese E-Mail und Ihre Antwort darauf. S?mtliche aufgef?hrten Ansichten oder Meinungen sind ausschlie?lich diejenigen des Autors und entsprechen nicht notwendigerweise denen des Unternehmens Intergraph. This E-Mail (and any attachments) may be confidential and protected by legal privilege. If you are not the intended recipient please notify us immediately by replying to the sender and delete this E-Mail and your reply from your system. All the views and opinions published here are solely based on the author's own opinion and should not be considered necessarily as reflecting the opinion of Intergraph. -----Original Message----- From: Anton V. Tarasov [mailto:anton.tarasov at oracle.com] Sent: Tuesday, June 23, 2015 5:46 PM To: Kevin Rushforth; Hruda, Steve Cc: openjfx-dev at openjdk.java.net Subject: Re: Patch for JDK-8090098 - [regression] Webview - getTimezoneOffset() of a ISO strings returns a wrong value On 23.06.2015 17:48, Kevin Rushforth wrote: > Hi Steve, > > Thank you for taking the time to create this patch. I will add this information to the bug report. > > Since your OCA is in progress we will take a look at your patch, but > will need indication from the OCA office that it the OCA has been > received before we could push it. And just to be clear, you won't have > access to the repository even with an OCA. What the OCA will do is allow you to contribute patches. > > I will note that it is likely too late for 8u60, but Anton can > evaluate it and post his comment in the bug report. Kevin, I'm checking it. Steve, thanks for the participation! Regards, Anton. > > -- Kevin > > > Hruda, Steve wrote: >> Hi, >> I've created a 8u-dev patch for the following WeKit regression which comes with 8u60. >> https://bugs.openjdk.java.net/browse/JDK-8090098 >> >> Please can someone of you apply this patch to fix the >> getTimezoneOffset() issue. I have no access to the repository -> my OCA is still pending. >> >> In addition I tried to test this patch , but I wasn't able to build >> the necessary jfxwebkit.dll on my windows system >> (https://www.mail-archive.com/openjfx-dev at openjdk.java.net/msg09439.h >> tml )..... but I got no compile erros on Mac. >> >> Patch download: >> https://drive.google.com/file/d/0B7P_rknS1TWxM3BSTTU2OVZ4dGM/view?usp >> =sharing >> >> The patch includes the following WebKit fixes: >> Changeset 174377 - [Win] DateMath's calculateUTFOffset does not account for DST. >> http://trac.webkit.org/changeset/174377 >> >> Changeset 175078 - String(new Date(Mar 30 2014 01:00:00)) is wrong >> in CET >> http://trac.webkit.org/changeset/175078 >> >> Changeset 181360 - [Win] 17 different JSC tests started to fail in >> DST >> http://trac.webkit.org/changeset/181360 >> >> Please let me know if you need further information. >> >> Thanks in advance! >> Best Regards >> Steve >> >> >> >> Diese E-Mail wurde versandt im Auftrag des Unternehmens Intergraph Ges.m.b.H. >> Vertretungsberechtigte Gesch?ftsf?hrer: Maximilian Weber Sitz der >> Gesellschaft: Margaretenstra?e 70/I/1, 1050 Wien, ?sterreich, Tel. >> +43 (1) 9610567-0 Eingetragen beim Handelsgericht Wien, >> Firmenbuch-Nr.: FN 116859 b Umsatzsteuer-Identifikationsnummer / >> VAT-ID: ATU15138401, Steuer-Nummer: 264/4807 >> >> This E-Mail has been sent on behalf of the company Intergraph Ges.m.b.H. >> Authorised Managing Directors: Maximilian Weber Registered office and >> Austrian headquarters: Margaretenstr. 70/I/1, 1050 Wien, Austria, >> Tel. +43 >> (1) 9610567-0 >> The company is recorded at the commercial court of Vienna under the >> company register number FN >> 116859 b >> VAT-ID: ATU15138401, Austrian Tax ID: 264/4807 >> >> Diese E-Mail (mit zugeh?rigen Dateien) enth?lt m?glicherweise >> Informationen, die vertraulich sind, dem Urheberrecht unterliegen >> oder ein Gesch?ftsgeheimnis darstellen. Falls Sie diese Nachricht >> irrt?mlicherweise erhalten haben, benachrichtigen Sie uns bitte >> umgehend, indem Sie eine Antwort senden, und l?schen Sie bitte diese >> E-Mail und Ihre Antwort darauf. S?mtliche aufgef?hrten Ansichten oder Meinungen sind ausschlie?lich diejenigen des Autors und entsprechen nicht notwendigerweise denen des Unternehmens Intergraph. >> >> This E-Mail (and any attachments) may be confidential and protected >> by legal privilege. If you are not the intended recipient please >> notify us immediately by replying to the sender and delete this >> E-Mail and your reply from your system. All the views and opinions >> published here are solely based on the author's own opinion and should not be considered necessarily as reflecting the opinion of Intergraph. >> >> From ooo_saturn7 at mail.ru Tue Jun 23 17:21:13 2015 From: ooo_saturn7 at mail.ru (=?UTF-8?B?0JDQu9C10LrRgdCw0L3QtNGAINCh0LLQuNGA0LjQtNC+0LI=?=) Date: Tue, 23 Jun 2015 20:21:13 +0300 Subject: =?UTF-8?B?V2ViVmlldyBkb2Vzbid0IHJlbmRlciBodG1sIGlucHV0IGVsZW1lbnRz?= Message-ID: <1435080073.878236372@f221.i.mail.ru> I have very simple html code (no css, nor js) that includes five inputs with type="radio" (in one column) and webview in JavaFX 8 which loads this page. The problem is the following - sometimes these radios are rendered sometimes not. For example, I start application - webview loads page, however there is empty space where these radio must be (these inputs are not rendered,they are not seen). But, when I move mouse over the area where these radios must be, they appear. I see this problem in Linux - Centos, Ubuntu and Windows XP. I've not seen this problem in Win7. Here is the code I tested. All the program consists of two classes: public class JavaFXApplication extends Application { ????private int count=0; ????@Override ????public void start(Stage primaryStage) { ????????final Button printButton = new Button("Print"); ????????final WebView webPage = new WebView(); ????????final WebEngine webEngine = webPage.getEngine(); ????????printButton.setOnAction(new EventHandler() { ????????????@Override public void handle(ActionEvent e) { ????????????????String html="\n" + " \n" + "\n" + "\n" + " \n" + " \n" + " \n" + "\n" + "\n" + "

\n" + "????? ?? ?? ?? ????\n" + "????????? ????????? ???????

???????? ?????:

\n" + "\n" + "
\n" + "????????? ????????, ?????? ????
\n" + "?????? ????, ??? ?????
\n" + "?? ????, ?? ?????, ????? ???????
\n" + "?????? ?????, ??? ????
\n" + "?????? ?????
\n" + "
"; ????????????????html+=count; ????????????????count++; ????????????????webEngine.loadContent(html); ????????????} ????????}); ????????HBox hbox = new HBox(); ????????hbox.getChildren().addAll(printButton); ????????BorderPane borderPane = new BorderPane(); ????????borderPane.setTop(hbox); ????????borderPane.setCenter(webPage); ????????Scene scene = new Scene(borderPane, 300, 250); ????????primaryStage.setTitle("WebView radio bugs"); ????????primaryStage.setScene(scene); ?????????primaryStage.show(); ????} } And the second class public class JavaApplication { ????/** ?????* @param args the command line arguments ?????*/ ????public static void main(String[] args) { ????????Application.launch(JavaFXApplication.class, args); ????} } After that I click Print button. After every clicking count++. Compiled openjdk 1.8.45. Tested winxp oracle 1.8.40, centos71,ubuntu 12 oracle 1.8.60. The image from xp. 29 clicks after that no radios. Moved mouse over 1,3,5: . The result is on the image I attached. Please, answer. -- ????????? ???????? From ondra.pelech at gmail.com Tue Jun 23 23:40:08 2015 From: ondra.pelech at gmail.com (Ondra Pelech) Date: Wed, 24 Jun 2015 01:40:08 +0200 Subject: Building OpenJFX with WebKit In-Reply-To: <5587D7E4.7070407@oracle.com> References: <55841FC9.5000109@oracle.com> <5587D7E4.7070407@oracle.com> Message-ID: thank you, I followed your advice one exception was that I had to perform export CXXFLAGS="$CXXFLAGS -fPIC" export CFLAGS="$CFLAGS -fPIC" ./configure --enable-static --enable-shared instead of the "./configure --enable-static" for successful build of openjfx itself, I also had to copy around some .java and .gif files but eventually the build succeeded the result is here if somebody will find it hopeful javafx-sdk-overlay.zip built with webkit support (libjfxwebkit.so) and maybe some other features on Fedora 20 x86_64 from http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/c14d3344e474 https://drive.google.com/file/d/0B4YDtjfjMOS7QnFoMjgwMTAzSVk/view?usp=sharing On Mon, Jun 22, 2015 at 11:39 AM, Andrew Brygin wrote: > Hello Ondra, > > please see my comment inline. > > On 6/19/2015 9:19 PM, Ondra Pelech wrote: >> >> lowering the version of webview-deps 1.3 --> 1.2 seems to be a step >> forward! >> but now I have another problem >> >> as you mentioned, there's this dependency on *.a static ICU libraries >> (why? why not depend on *.so?) > > If you are going to use the result of your build on the same system, then > the dependency on *.so is just fine. However, if you want to use your > binaries on other linux ditors, the static ICU libraries is the only option: > There are various major version of the ICU among modern linux distors: > from 48 to 54 for now, and they export different set of symbols. > >> in Fedora 20 there are only available dynamic *.so libraries (packages >> libicu and libicu-devel) >> >> so is there an easy way of obtaining those *.a? > > * download source bundle: > http://download.icu-project.org/files/icu4c/4.8.1.1/icu4c-4_8_1_1-src.tgz > > * unpack it to some location > > * cd /icu/source > > * ./configure --enable-static > > * make > > * sudo make install > > The default prefix /usr/local works fine, the webkit build uses pkg-config > to locate libraries. > > Thanks, > Andrew > >> or do you have a rough estimate when would these libraries be >> available on central via webview-deps:1.3? >> thanks again, cheers >> >> >> On Fri, Jun 19, 2015 at 3:57 PM, Anton V. Tarasov >> wrote: >>> >>> Hi Ondra, Michael, >>> >>> On 16.06.2015 18:04, Michael Hoffer wrote: >>>> >>>> Hi Ondra, >>>> >>>> I was able to build WebKit after reverting the version number from 1.3 >>>> to >>>> 1.2. On Linux there should be a package called libicu48. I guess it is >>>> equivalent to webview-deps 1.3. If you install it WebKit should compile. >>> >>> >>> webview-deps 1.3 for Linux contains the following set of ICU 48: >>> >>> libicudata.a >>> libicui18n.a >>> libicuio.a >>> libicuuc.a >>> >>>> Regards, >>>> Michael >>>> >>>> 2015-06-15 1:02 GMT+02:00 Ondra Pelech : >>>> >>>>> Hello, >>>>> I'm trying to build OpenJFX with WebKit, but I'm missing the >>>>> dependency com.sun.webkit:webview-deps:1.3 >>>>> I've come across this thread from May >>>>> http://comments.gmane.org/gmane.comp.java.openjdk.openjfx.devel/9447 >>>>> but webkit:webview-deps:1.3 is still not on maven central >>> >>> >>> We're going to put it in Central soon. Sorry for the delay. >>> >>> Regards, >>> Anton. >>> >>> >>> >>>>> is there another place I can get it from? or how can I build it myself? >>>>> >>>>> thank you, best regards >>>>> Ondra >>>>> >>>>> >>>>> >>>>> Building Webkit configuration /Release/ into >>>>> /home/ondra/Projects/rt/modules/web/build/linux >>>>> :web:compileNativeLinux FAILED >>>>> >>>>> FAILURE: Build failed with an exception. >>>>> >>>>> * Where: >>>>> Build file '/home/ondra/Projects/rt/build.gradle' line: 2512 >>>>> >>>>> * What went wrong: >>>>> Execution failed for task ':web:compileNativeLinux'. >>>>>> >>>>>> Could not resolve all dependencies for configuration ':web:webkit'. >>>>> >>>>> > Could not find com.sun.webkit:webview-deps:1.3. >>>>> Required by: >>>>> rt:web:unspecified >>>>> >>>> > From javier at opensuse.org Wed Jun 24 11:01:27 2015 From: javier at opensuse.org (Javier Llorente) Date: Wed, 24 Jun 2015 13:01:27 +0200 Subject: Building OpenJFX fails (missing resources) Message-ID: <558A8E07.60405@opensuse.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello everyone! I'm trying to build OpenJFX (8u60) on openSUSE 13.2 and got the following for the SDK task: [...] Internal error. Missing resources [/resources/web-files/javafx-loading-100x100.gif] com.sun.javafx.tools.packager.PackagerException: Error: -includedt requires the java deployment toolkit, which is not included in this distribution [...] FAILURE: Build failed with an exception. * Where: Build file '/home/javier/projects/rt/build.gradle' line: 3263 * What went wrong: Execution failed for task ':apps:appsJarLinux'. > The following error occurred while executing this line: /home/javier/projects/rt/apps/scenebuilder/build.xml:14: The following error occurred while executing this line: /home/javier/projects/rt/apps/scenebuilder/samples/build.xml:9: The following error occurred while executing this line: /home/javier/projects/rt/apps/scenebuilder/samples/AirportApp/nbproject/jfx-impl.xml:1465: The following error occurred while executing this line: /home/javier/projects/rt/apps/scenebuilder/samples/AirportApp/nbproject/jfx-impl.xml:2969: The following error occurred while executing this line: /home/javier/projects/rt/apps/scenebuilder/samples/AirportApp/nbproject/jfx-impl.xml:2055: Error: Bundler "WebStart JNLP Bundler" (jnlp) failed to produce a bundle. If I comment the line mentioned above (3263), it builds successfully. Nevertheless, If I copy the SDK overlay to the JDK path and try to build a JavaFX sample application on NetBeans 8.0.2, I get the same error about the missing resources and the not included java deployment toolkit. I have come across a message on this mailing list about that; "hg: openjfx/8u-dev/rt: RT-35778: Packager should use closed source version of deployment toolkit" http://mail.openjdk.java.net/pipermail/openjfx-dev/2014-February/012656.html thanks to a Debian bug report; "openjfx: fxpackager missing files" https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=771514 I would like to know if there are any plans to make the required resources open source so that OpenJFX is usable on NetBeans. Thanks. Greetings, - -- Javier Llorente -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlWKjgcACgkQdV3zWWOPFxQdHwCcDh/aF0++GiBYsBRrNticcfBx fZEAnRT7wHre9YvR04eublueCnBchWxl =fHxv -----END PGP SIGNATURE----- From steve at weblite.ca Wed Jun 24 15:41:20 2015 From: steve at weblite.ca (Steve Hannah) Date: Wed, 24 Jun 2015 08:41:20 -0700 Subject: Differences between WebView and Webkit Message-ID: I have a javascript app that is not loading in the JavaFX webview (JDK8). User agent string indicates WebKit 537.44, so I downloaded the nightly build for WebKit 537.44 to test, and the app works in that. No errors are reported in the webview (I've hooked up change listeners, error listeners, etc...), and I hooked up Firebug lite - but it also doesn't report any errors -- likely either errors are occurring before the page is loaded (i.e. before Firebug lite is added). Does WebKit 537.44 use the exact same Javascript engine as the WebView that reports 537.44 as the webkit version - or are there some differences? -- Steve Hannah Web Lite Solutions Corp. From anton.tarasov at oracle.com Wed Jun 24 16:12:01 2015 From: anton.tarasov at oracle.com (Anton V. Tarasov) Date: Wed, 24 Jun 2015 19:12:01 +0300 Subject: WebView doesn't render html input elements In-Reply-To: <1435080073.878236372@f221.i.mail.ru> References: <1435080073.878236372@f221.i.mail.ru> Message-ID: <558AD6D1.8000900@oracle.com> Hi Alexander, Yes, the issue exists indeed. I've filed it as: JDK-8129800 [WebView] controls not showing up initially on Linux. However, I don't reproduce it with your test but with a slightly different one. Anyway, thanks for reporting it. Regards, Anton. On 23.06.2015 20:21, ????????? ???????? wrote: > I have very simple html code (no css, nor js) that includes five inputs with type="radio" (in one column) and webview in JavaFX 8 which loads this page. > > The problem is the following - sometimes these radios are rendered sometimes not. > > For example, I start application - webview loads page, however there is empty space where these radio must be (these inputs are not rendered,they are not seen). But, when I move mouse over the area where these radios must be, they appear. > > I see this problem in Linux - Centos, Ubuntu and Windows XP. I've not seen this problem in Win7. > > Here is the code I tested. All the program consists of two classes: > > public class JavaFXApplication extends Application { > private int count=0; > @Override > public void start(Stage primaryStage) { > final Button printButton = new Button("Print"); > final WebView webPage = new WebView(); > final WebEngine webEngine = webPage.getEngine(); > printButton.setOnAction(new EventHandler() { > @Override public void handle(ActionEvent e) { > String html="\n" + > " \n" + > "\n" + > "\n" + > " \n" + > " \n" + > " \n" + > "\n" + > "\n" + > "

\n" + > "????? ?? ?? ?? ????\n" + > "????????? ????????? ???????

???????? ?????:

\n" + > "\n" + > "
\n" + > "????????? ????????, ?????? ????
\n" + > "?????? ????, ??? ?????
\n" + > "?? ????, ?? ?????, ????? ???????
\n" + > "?????? ?????, ??? ????
\n" + > "?????? ?????
\n" + > "
"; > html+=count; > count++; > webEngine.loadContent(html); > } > }); > HBox hbox = new HBox(); > hbox.getChildren().addAll(printButton); > BorderPane borderPane = new BorderPane(); > borderPane.setTop(hbox); > borderPane.setCenter(webPage); > Scene scene = new Scene(borderPane, 300, 250); > primaryStage.setTitle("WebView radio bugs"); > primaryStage.setScene(scene); > primaryStage.show(); > } > } > > And the second class > > public class JavaApplication { > /** > * @param args the command line arguments > */ > public static void main(String[] args) { > Application.launch(JavaFXApplication.class, args); > } > } > > After that I click Print button. After every clicking count++. Compiled openjdk 1.8.45. Tested winxp oracle 1.8.40, centos71,ubuntu 12 oracle 1.8.60. The image from xp. 29 clicks after that no radios. Moved mouse over 1,3,5: . The result is on the image I attached. Please, answer. > > From kevin.rushforth at oracle.com Wed Jun 24 20:12:49 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 24 Jun 2015 13:12:49 -0700 Subject: [8u60, 9] review request: 8088665: Windows native binaries have inconsistent "Product version" Message-ID: <558B0F41.7010301@oracle.com> David, Chris, and Danno, Please review the following: https://bugs.openjdk.java.net/browse/JDK-8088665 http://cr.openjdk.java.net/~kcr/8088665/webrev.00/ These are changes to the windows native 'rc' command to match the JDK's version numbering. Details are in JIRA. -- Kevin From steve at weblite.ca Thu Jun 25 04:39:00 2015 From: steve at weblite.ca (Steve Hannah) Date: Wed, 24 Jun 2015 21:39:00 -0700 Subject: Differences between WebView and Webkit In-Reply-To: References: Message-ID: To sort of answer my own question, I found out that the JavaFX webview is missing quite a few APIs that are present in Webkit. This is the result of the HTML test I ran: https://html5test.com/s/71bdbe284015d02b.html This gives me a starting point so I can create polyfills if I want to move forward. Steve On Wed, Jun 24, 2015 at 8:41 AM, Steve Hannah wrote: > I have a javascript app that is not loading in the JavaFX webview (JDK8). > User agent string indicates WebKit 537.44, so I downloaded the nightly > build for WebKit 537.44 to test, and the app works in that. > > No errors are reported in the webview (I've hooked up change listeners, > error listeners, etc...), and I hooked up Firebug lite - but it also > doesn't report any errors -- likely either errors are occurring before the > page is loaded (i.e. before Firebug lite is added). > > Does WebKit 537.44 use the exact same Javascript engine as the WebView > that reports 537.44 as the webkit version - or are there some differences? > > -- > Steve Hannah > Web Lite Solutions Corp. > -- Steve Hannah Web Lite Solutions Corp. From ooo_saturn7 at mail.ru Thu Jun 25 06:03:01 2015 From: ooo_saturn7 at mail.ru (=?UTF-8?B?0JDQu9C10LrRgdCw0L3QtNGAINCh0LLQuNGA0LjQtNC+0LI=?=) Date: Thu, 25 Jun 2015 09:03:01 +0300 Subject: =?UTF-8?B?UmVbMl06IFdlYlZpZXcgZG9lc24ndCByZW5kZXIgaHRtbCBpbnB1dCBlbGVt?= =?UTF-8?B?ZW50cw==?= In-Reply-To: <558AD6D1.8000900@oracle.com> References: <1435080073.878236372@f221.i.mail.ru> <558AD6D1.8000900@oracle.com> Message-ID: <1435212181.887260853@f375.i.mail.ru> Hi Anton. Thank you for answer. Please,note that this problem is not only in linux. The same I saw in windows XP but never in windows 7. Maybe it will help. ?????, 24 ???? 2015, 19:12 +03:00 ?? "Anton V. Tarasov" : >Hi Alexander, > >Yes, the issue exists indeed. I've filed it as: JDK-8129800 [WebView] controls not showing up initially on Linux. However, I don't reproduce it with your test but with a slightly different one. > >Anyway, thanks for reporting it. > >Regards, >Anton. > >On 23.06.2015 20:21, ????????? ???????? wrote: >> I have very simple html code (no css, nor js) that includes five inputs with type="radio" (in one column) and webview in JavaFX 8 which loads this page. The problem is the following - sometimes these radios are rendered sometimes not. For example, I start application - webview loads page, however there is empty space where these radio must be (these inputs are not rendered,they are not seen). But, when I move mouse over the area where these radios must be, they appear. I see this problem in Linux - Centos, Ubuntu and Windows XP. I've not seen this problem in Win7. Here is the code I tested. All the program consists of two classes: public class JavaFXApplication extends Application { ????private int count=0; ????@Override ????public void start(Stage primaryStage) { ????????final Button printButton = new Button("Print"); ????????final WebView webPage = new WebView(); ????????final WebEngine webEngine = webPage.getEngine(); ????????printButton.setOnAction(new EventHandler() { ????????????@Override public void handle(ActionEvent e) { ????????????????String html="\n" + " \n" + "\n" + "\n" + " \n" + " \n" + " \n" + "\n" + "\n" + "

\n" + "????? ?? ?? ?? ????\n" + "????????? ????????? ???????

???????? ?????:

\n" + "\n" + "
\n" + "????????? ????????, ?????? ????
\n" + "?????? ????, ??? ?????
\n" + "?? ????, ?? ?????, ????? ???????
\n" + "?????? ?????, ??? ????
\n" + "?????? ?????
\n" + "
"; ????????????????html+=count; ????????????????count++; ????????????????webEngine.loadContent(html); ????????????} ????????}); ????????HBox hbox = new HBox(); ????????hbox.getChildren().addAll(printButton); ????????BorderPane borderPane = new BorderPane(); ????????borderPane.setTop(hbox); ????????borderPane.setCenter(webPage); ????????Scene scene = new Scene(borderPane, 300, 250); ????????primaryStage.setTitle("WebView radio bugs"); ????????primaryStage.setScene(scene); ?????????primaryStage.show(); ????} } And the second class public class JavaApplication { ????/** ?????* @param args the command line arguments ?????*/ ????public static void main(String[] args) { ????????Application.launch(JavaFXApplication.class, args); ????} } After that I click Print button. After every clicking count++. Compiled openjdk 1.8.45. Tested winxp oracle 1.8.40, centos71,ubuntu 12 oracle 1.8.60. The image from xp. 29 clicks after that no radios. Moved mouse over 1,3,5: . The result is on the image I attached. Please, answer. > From anton.tarasov at oracle.com Thu Jun 25 09:05:33 2015 From: anton.tarasov at oracle.com (Anton Tarasov) Date: Thu, 25 Jun 2015 12:05:33 +0300 Subject: WebView doesn't render html input elements In-Reply-To: <1435212181.887260853@f375.i.mail.ru> References: <1435080073.878236372@f221.i.mail.ru> <558AD6D1.8000900@oracle.com> <1435212181.887260853@f375.i.mail.ru> Message-ID: <558BC45D.2020905@oracle.com> On 25.06.2015 09:03, ????????? ???????? wrote: > Hi Anton. > Thank you for answer. Please,note that this problem is not only in > linux. The same I saw in windows XP but never in windows 7. Maybe it > will help. I don't see it on Win7 as well. WinXP is not a supported platform for JFX 8+. Still, I will add your comment to JIRA. Thanks. Regards, Anton. > > > ?????, 24 ???? 2015, 19:12 +03:00 ?? "Anton V. Tarasov" > : > > Hi Alexander, > > Yes, the issue exists indeed. I've filed it as: JDK-8129800 > [WebView] > controls not showing up initially on Linux. However, I don't > reproduce it with your test but with a slightly different one. > > Anyway, thanks for reporting it. > > Regards, > Anton. > > On 23.06.2015 20:21, ????????? ???????? wrote: >> I have very simple html code (no css, nor js) that includes five inputs with type="radio" (in one column) and webview in JavaFX 8 which loads this page. >> >> The problem is the following - sometimes these radios are rendered sometimes not. >> >> For example, I start application - webview loads page, however there is empty space where these radio must be (these inputs are not rendered,they are not seen). But, when I move mouse over the area where these radios must be, they appear. >> >> I see this problem in Linux - Centos, Ubuntu and Windows XP. I've not seen this problem in Win7. >> >> Here is the code I tested. All the program consists of two classes: >> >> public class JavaFXApplication extends Application { >> private int count=0; >> @Override >> public void start(Stage primaryStage) { >> final Button printButton = new Button("Print"); >> final WebView webPage = new WebView(); >> final WebEngine webEngine = webPage.getEngine(); >> printButton.setOnAction(new EventHandler() { >> @Override public void handle(ActionEvent e) { >> String html="\n" + >> " \n" + >> "\n" + >> "\n" + >> " \n" + >> " \n" + >> " \n" + >> "\n" + >> "\n" + >> "

\n" + >> "????? ?? ?? ?? ????\n" + >> "????????? ????????? ???????

???????? ?????:

\n" + >> "\n" + >> "
\n" + >> "????????? ????????, ?????? ????
\n" + >> "?????? ????, ??? ?????
\n" + >> "?? ????, ?? ?????, ????? ???????
\n" + >> "?????? ?????, ??? ????
\n" + >> "?????? ?????
\n" + >> "
"; >> html+=count; >> count++; >> webEngine.loadContent(html); >> } >> }); >> HBox hbox = new HBox(); >> hbox.getChildren().addAll(printButton); >> BorderPane borderPane = new BorderPane(); >> borderPane.setTop(hbox); >> borderPane.setCenter(webPage); >> Scene scene = new Scene(borderPane, 300, 250); >> primaryStage.setTitle("WebView radio bugs"); >> primaryStage.setScene(scene); >> primaryStage.show(); >> } >> } >> >> And the second class >> >> public class JavaApplication { >> /** >> * @param args the command line arguments >> */ >> public static void main(String[] args) { >> Application.launch(JavaFXApplication.class, args); >> } >> } >> >> After that I click Print button. After every clicking count++. Compiled openjdk 1.8.45. Tested winxp oracle 1.8.40, centos71,ubuntu 12 oracle 1.8.60. The image from xp. 29 clicks after that no radios. Moved mouse over 1,3,5: . The result is on the image I attached. Please, answer. >> >> > > From kevin.rushforth at oracle.com Thu Jun 25 12:57:30 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 25 Jun 2015 05:57:30 -0700 Subject: WebView doesn't render html input elements In-Reply-To: <1435212181.887260853@f375.i.mail.ru> References: <1435080073.878236372@f221.i.mail.ru> <558AD6D1.8000900@oracle.com> <1435212181.887260853@f375.i.mail.ru> Message-ID: <558BFABA.9040207@oracle.com> Windows XP is not a supported platform. I suspect a driver issue on Linux, but we'll take a look at the test case Anton filed and see what we find. -- Kevin ????????? ???????? wrote: > Hi Anton. > Thank you for answer. Please,note that this problem is not only in linux. The same I saw in windows XP but never in windows 7. Maybe it will help. > > > ?????, 24 ???? 2015, 19:12 +03:00 ?? "Anton V. Tarasov" : > >> Hi Alexander, >> >> Yes, the issue exists indeed. I've filed it as: JDK-8129800 [WebView] controls not showing up initially on Linux. However, I >> > don't reproduce it with your test but with a slightly different > one. > >> Anyway, thanks for reporting it. >> >> Regards, >> Anton. >> >> On 23.06.2015 20:21, ????????? ???????? wrote: >> >>> I have very simple html code (no css, nor js) that includes five inputs with type="radio" (in one column) and webview in JavaFX 8 which loads this page. >>> > > The problem is the following - sometimes these radios are rendered sometimes not. > > For example, I start application - webview loads page, however there is empty space where these radio must be (these inputs are not rendered,they are not seen). But, when I move mouse over the area where these radios must be, they appear. > > I see this problem in Linux - Centos, Ubuntu and Windows XP. I've not seen this problem in Win7. > > Here is the code I tested. All the program consists of two classes: > > public class JavaFXApplication extends Application { > private int count=0; > @Override > public void start(Stage primaryStage) { > final Button printButton = new Button("Print"); > final WebView webPage = new WebView(); > final WebEngine webEngine = webPage.getEngine(); > printButton.setOnAction(new EventHandler() { > @Override public void handle(ActionEvent e) { > String html="\n" + > " \n" + > "\n" + > "\n" + > " \n" + > " \n" + > " \n" + > "\n" + > "\n" + > "

\n" + > "????? ?? ?? ?? ????\n" + > "????????? ????????? ???????

???????? ?????:

\n" + > "\n" + > "
\n" + > "????????? ????????, ?????? ????
\n" + > "?????? ????, ??? ?????
\n" + > "?? ????, ?? ?????, ????? ???????
\n" + > "?????? ?????, ??? ????
\n" + > "?????? ?????
\n" + > "
"; > html+=count; > count++; > webEngine.loadContent(html); > } > }); > HBox hbox = new HBox(); > hbox.getChildren().addAll(printButton); > BorderPane borderPane = new BorderPane(); > borderPane.setTop(hbox); > borderPane.setCenter(webPage); > Scene scene = new Scene(borderPane, 300, 250); > primaryStage.setTitle("WebView radio bugs"); > primaryStage.setScene(scene); > primaryStage.show(); > } > } > > And the second class > > public class JavaApplication { > /** > * @param args the command line arguments > */ > public static void main(String[] args) { > Application.launch(JavaFXApplication.class, args); > } > } > > After that I click Print button. After every clicking count++. Compiled openjdk 1.8.45. Tested winxp oracle 1.8.40, centos71,ubuntu 12 oracle 1.8.60. The image from xp. 29 clicks after that no radios. Moved mouse over 1,3,5: . The result is on the image I attached. Please, answer. > > > > > From anton.tarasov at oracle.com Thu Jun 25 13:46:31 2015 From: anton.tarasov at oracle.com (Anton V. Tarasov) Date: Thu, 25 Jun 2015 16:46:31 +0300 Subject: Differences between WebView and Webkit In-Reply-To: References: Message-ID: <558C0637.9040404@oracle.com> Hi Steve, You're correct, WebView doesn't include all the features that WebKit provides. This is configured at a compile time with a set of preprocessor definitions. The reason is that a feature may not work from scratch for WebView and may require additional code changes in WebView port. So, every feature should be explored before including into WebView. Regards, Anton. On 25.06.2015 7:39, Steve Hannah wrote: > To sort of answer my own question, I found out that the JavaFX webview is > missing quite a few APIs that are present in Webkit. This is the result of > the HTML test I ran: > https://html5test.com/s/71bdbe284015d02b.html > > This gives me a starting point so I can create polyfills if I want to move > forward. > > Steve > > On Wed, Jun 24, 2015 at 8:41 AM, Steve Hannah wrote: > >> I have a javascript app that is not loading in the JavaFX webview (JDK8). >> User agent string indicates WebKit 537.44, so I downloaded the nightly >> build for WebKit 537.44 to test, and the app works in that. >> >> No errors are reported in the webview (I've hooked up change listeners, >> error listeners, etc...), and I hooked up Firebug lite - but it also >> doesn't report any errors -- likely either errors are occurring before the >> page is loaded (i.e. before Firebug lite is added). >> >> Does WebKit 537.44 use the exact same Javascript engine as the WebView >> that reports 537.44 as the webkit version - or are there some differences? >> >> -- >> Steve Hannah >> Web Lite Solutions Corp. >> > > From swpalmer at gmail.com Fri Jun 26 16:49:18 2015 From: swpalmer at gmail.com (Scott Palmer) Date: Fri, 26 Jun 2015 12:49:18 -0400 Subject: EA downloads? Message-ID: <8FAE76EE-FD60-4984-A2A2-A83AE84A6A0C@gmail.com> Is there a reason that the 8u early access download page hasn?t been updated with either 8u60 b20 or b21 ? The downloads are available if you guess the URL. https://jdk8.java.net/download.html I still see it offering b19. Scott From morris.meyer at oracle.com Fri Jun 26 16:55:24 2015 From: morris.meyer at oracle.com (Morris Meyer) Date: Fri, 26 Jun 2015 12:55:24 -0400 Subject: [8u60] Request for Review: 8094649: [Mac] Intermittent crash after starting Multitouch support Message-ID: <558D83FC.9060704@oracle.com> Kevin and David, Please review the following one-line fix to 8094649. This issue was caused by a race condition between start of touch tracking and the closing out the splash screen without removing the touch tracking. It was messaging the invalid ObjC object for the GlassViewDelegate and crashing. This has been tested using HelloSanity and using the test app linked in this issue. --morris WEBREV - http://cr.openjdk.java.net/~morris/JDK-8094649.01/ JBS - https://bugs.openjdk.java.net/browse/JDK-8094649 From kevin.rushforth at oracle.com Fri Jun 26 17:32:24 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 26 Jun 2015 10:32:24 -0700 Subject: EA downloads? In-Reply-To: <8FAE76EE-FD60-4984-A2A2-A83AE84A6A0C@gmail.com> References: <8FAE76EE-FD60-4984-A2A2-A83AE84A6A0C@gmail.com> Message-ID: <558D8CA8.9090401@oracle.com> Thanks for letting us know. I reported this. They just fixed it. -- Kevin Scott Palmer wrote: > Is there a reason that the 8u early access download page hasn?t been updated with either 8u60 b20 or b21 ? The downloads are available if you guess the URL. > https://jdk8.java.net/download.html I still see it offering b19. > > Scott > > From kevin.rushforth at oracle.com Fri Jun 26 18:42:50 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 26 Jun 2015 11:42:50 -0700 Subject: [8u60,9] review request: 8090074: Update copyright header for files modified in 2015 Message-ID: <558D9D2A.2080201@oracle.com> David, Please review (just needs a sanity check) the following: https://bugs.openjdk.java.net/browse/JDK-8090074 http://cr.openjdk.java.net/~kcr/8090074/webrev.00/ Thanks. -- Kevin From vadim.pakhnushev at oracle.com Fri Jun 26 19:16:03 2015 From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev) Date: Fri, 26 Jun 2015 22:16:03 +0300 Subject: In(Sanity) Testing Mondays Message-ID: <558DA4F3.2080006@oracle.com> Reminder, Monday is our weekly sanity testing. You can find your testing assignment at: https://wiki.openjdk.java.net/display/OpenJFX/Sanity+Testing Also please remember that the repo will be locked from 1am PDT until 1pm PDT. Happy testing! Thanks, Vadim From kevin.rushforth at oracle.com Fri Jun 26 19:22:35 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 26 Jun 2015 12:22:35 -0700 Subject: In(Sanity) Testing Mondays In-Reply-To: <558DA4F3.2080006@oracle.com> References: <558DA4F3.2080006@oracle.com> Message-ID: <558DA67B.8080902@oracle.com> As a follow-up to this, 8u-dev will remain locked until at least after the promoted build in case there is a need for a respin, since this is the last build before RDP2 and forking the 8u60 stabilization repo. 9-dev will open up at 1pm PDT on Monday per usual. Sanity testing this week should continue be done on 8u-dev, specifically looking for possible regressions from recent changes. Starting next week we will likely switch to sanity testing 9-dev. -- Kevin Vadim Pakhnushev wrote: > Reminder, Monday is our weekly sanity testing. > > You can find your testing assignment at: > > https://wiki.openjdk.java.net/display/OpenJFX/Sanity+Testing > > Also please remember that the repo will be locked from 1am PDT until > 1pm PDT. > > Happy testing! > > Thanks, > Vadim From felix.bembrick at gmail.com Sat Jun 27 03:08:48 2015 From: felix.bembrick at gmail.com (Felix Bembrick) Date: Sat, 27 Jun 2015 13:08:48 +1000 Subject: JavaFX features in JDK 9 In-Reply-To: <4A33E952-B3B0-4C19-9F5E-CBB10EC9E19B@gmail.com> References: <4A33E952-B3B0-4C19-9F5E-CBB10EC9E19B@gmail.com> Message-ID: Anyone got anything or is there a link somewhere that talks about these? On 15 June 2015 at 22:00, Felix Bembrick wrote: > I realise we are a long way off JDK 9 still and with crucial features such > as Jigsaw still a little up in the air but is it possible someone could > itemise the most likely new features, enhancements and bug fixes that we > will see in JavaFX when JDK 9 is released? > > Of course it's purely speculation at this point but it would assist me > greatly to have some of idea of where JavaFX is heading and which areas are > seen as most important. > > Thanks, > > Felix From ooo_saturn7 at mail.ru Sat Jun 27 06:30:45 2015 From: ooo_saturn7 at mail.ru (=?UTF-8?B?0JDQu9C10LrRgdCw0L3QtNGAINCh0LLQuNGA0LjQtNC+0LI=?=) Date: Sat, 27 Jun 2015 09:30:45 +0300 Subject: =?UTF-8?B?UmVbMl06IEphdmFGeDogd2VidmlldyBwcmludCB3aXRoIHNjYWxlIDEwMCU=?= In-Reply-To: <55842127.5020707@oracle.com> References: <1434347604.864680804@f359.i.mail.ru> <55842127.5020707@oracle.com> Message-ID: <1435386645.817842663@f371.i.mail.ru> Hi Anton, I send all files. If you open index.html in IE and printpreview->set scale 100% -> print , you will get 16.8 cm of div on paper. If you you print via application I did you will get quite different size. ???????, 19 ???? 2015, 17:03 +03:00 ?? "Anton V. Tarasov" : >Hi Alexander, > >Could you please create and send a simple test case (fully functioning) with the exact URL of a page >you're printing? > >Regards, >Anotn. > >On 15.06.2015 8:53, ????????? ???????? wrote: >> To print my html page I use the following code: >> PrinterJob job =PrinterJob.createPrinterJob();if(job !=null&& job.showPrintDialog(null)){ >> webView.getEngine().print(job); >> job.endJob();} >> The problem is that webview changes the scale of printing page. For example, when I print this html page in IE with fit to size 100% I get 16.8 cm. When I print in my java application I get 11.4cm. The size in html file I set in pt - my width is 475pt(A4 width=595pt,so 475pt=16.8cm). How to print with webview and to have 100% width and height? > -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: index.html URL: From kevin.rushforth at oracle.com Sat Jun 27 15:07:44 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Sat, 27 Jun 2015 08:07:44 -0700 Subject: JavaFX features in JDK 9 In-Reply-To: References: <4A33E952-B3B0-4C19-9F5E-CBB10EC9E19B@gmail.com> Message-ID: <558EBC40.3020300@oracle.com> Hi Felix, Sorry for the delay. Most of us were still pretty focused on 8u60, but we are turning our attention to JDK 9 now. The focus for JDK 9 is Jigsaw. The currently planned big features (JEPs) for FX in JDK 9 are these: JEP 253: Prepare JavaFX UI Controls & CSS APIs for Modularization JEP 257: Update JavaFX/Media to Newer Version of GStreamer Related to Jigasw, we intend to look into new API for heavily used internal methods / classes since they will no longer be accessible otherwise. We also plan to update WebKit at least one more time, and will likely do a few RFEs such as better Hi-DPI support (with API control) on Mac, Windows, Linux. We don't currently plan any other big features for 9, but will consider additional RFEs if they are important to enough developers and if they fit into the time frame. -- Kevin Felix Bembrick wrote: > Anyone got anything or is there a link somewhere that talks about these? > > On 15 June 2015 at 22:00, Felix Bembrick wrote: > > >> I realise we are a long way off JDK 9 still and with crucial features such >> as Jigsaw still a little up in the air but is it possible someone could >> itemise the most likely new features, enhancements and bug fixes that we >> will see in JavaFX when JDK 9 is released? >> >> Of course it's purely speculation at this point but it would assist me >> greatly to have some of idea of where JavaFX is heading and which areas are >> seen as most important. >> >> Thanks, >> >> Felix >> From mikegps1 at gmail.com Sat Jun 27 18:16:15 2015 From: mikegps1 at gmail.com (Mike) Date: Sat, 27 Jun 2015 11:16:15 -0700 Subject: JavaFX features in JDK 9 In-Reply-To: <558EBC40.3020300@oracle.com> References: <4A33E952-B3B0-4C19-9F5E-CBB10EC9E19B@gmail.com> <558EBC40.3020300@oracle.com> Message-ID: a lot of FULL blown Webrtc support and building something in Javafx (like Scene Builder) that Proves Webrtc support would be awesome. Ditto to Webgl support. On Sat, Jun 27, 2015 at 8:07 AM, Kevin Rushforth wrote: > Hi Felix, > > Sorry for the delay. Most of us were still pretty focused on 8u60, but we > are turning our attention to JDK 9 now. > > The focus for JDK 9 is Jigsaw. The currently planned big features (JEPs) > for FX in JDK 9 are these: > > JEP 253: Prepare JavaFX UI Controls & CSS APIs for Modularization > JEP 257: Update JavaFX/Media to Newer Version of GStreamer > > Related to Jigasw, we intend to look into new API for heavily used > internal methods / classes since they will no longer be accessible > otherwise. We also plan to update WebKit at least one more time, and will > likely do a few RFEs such as better Hi-DPI support (with API control) on > Mac, Windows, Linux. > > We don't currently plan any other big features for 9, but will consider > additional RFEs if they are important to enough developers and if they fit > into the time frame. > > -- Kevin > > > > Felix Bembrick wrote: > >> Anyone got anything or is there a link somewhere that talks about these? >> >> On 15 June 2015 at 22:00, Felix Bembrick >> wrote: >> >> >> >>> I realise we are a long way off JDK 9 still and with crucial features >>> such >>> as Jigsaw still a little up in the air but is it possible someone could >>> itemise the most likely new features, enhancements and bug fixes that we >>> will see in JavaFX when JDK 9 is released? >>> >>> Of course it's purely speculation at this point but it would assist me >>> greatly to have some of idea of where JavaFX is heading and which areas >>> are >>> seen as most important. >>> >>> Thanks, >>> >>> Felix >>> >>> >> From webczat_200 at poczta.onet.pl Sat Jun 27 18:36:12 2015 From: webczat_200 at poczta.onet.pl (=?UTF-8?B?TWljaGHFgiBaZWdhbg==?=) Date: Sat, 27 Jun 2015 20:36:12 +0200 Subject: JavaFX features in JDK 9 In-Reply-To: References: <4A33E952-B3B0-4C19-9F5E-CBB10EC9E19B@gmail.com> <558EBC40.3020300@oracle.com> Message-ID: <558EED1C.8030005@poczta.onet.pl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 What about accessibility work? Work on it has been started, but not sure if it is still targetted for 9. W dniu 2015-06-27 o 20:16, Mike pisze: > a lot of FULL blown Webrtc support and building something in Javafx > (like Scene Builder) that Proves Webrtc support would be awesome. > Ditto to Webgl support. > > On Sat, Jun 27, 2015 at 8:07 AM, Kevin Rushforth > > wrote: > >> Hi Felix, >> >> Sorry for the delay. Most of us were still pretty focused on >> 8u60, but we are turning our attention to JDK 9 now. >> >> The focus for JDK 9 is Jigsaw. The currently planned big features >> (JEPs) for FX in JDK 9 are these: >> >> JEP 253: Prepare JavaFX UI Controls & CSS APIs for >> Modularization JEP 257: Update JavaFX/Media to Newer Version of >> GStreamer >> >> Related to Jigasw, we intend to look into new API for heavily >> used internal methods / classes since they will no longer be >> accessible otherwise. We also plan to update WebKit at least one >> more time, and will likely do a few RFEs such as better Hi-DPI >> support (with API control) on Mac, Windows, Linux. >> >> We don't currently plan any other big features for 9, but will >> consider additional RFEs if they are important to enough >> developers and if they fit into the time frame. >> >> -- Kevin >> >> >> >> Felix Bembrick wrote: >> >>> Anyone got anything or is there a link somewhere that talks >>> about these? >>> >>> On 15 June 2015 at 22:00, Felix Bembrick >>> wrote: >>> >>> >>> >>>> I realise we are a long way off JDK 9 still and with crucial >>>> features such as Jigsaw still a little up in the air but is >>>> it possible someone could itemise the most likely new >>>> features, enhancements and bug fixes that we will see in >>>> JavaFX when JDK 9 is released? >>>> >>>> Of course it's purely speculation at this point but it would >>>> assist me greatly to have some of idea of where JavaFX is >>>> heading and which areas are seen as most important. >>>> >>>> Thanks, >>>> >>>> Felix >>>> >>>> >>> -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVju0bAAoJEHb1CzgxXKwYYRAP/iPJ43tu3Q56oXLr+SjD+Qqc xtBs9Fb3k3FJlPmqDlq3mbvW4RkpGNDUi71OlocYJ1v5C719samTd1mqpKHubJj7 0mZHUmISswaJRcnXnXmIQL8i7tX+XvK2JSHV8mwEcZ7rCIHAz2qxxQMnAlGKw7MV tSzWtTCAuSjI7auN8Lew2lmAXD9NRe3+Tuyq4tcWK9O3UTI5CZl1KiX4MTS6/wGU xJVr+k1EMMVckOUhRkLfNy332x/dsxdvw0dBo+7P8h/mKZWYcDGop/z3YLRj0zAx /JEKaGLsJa72Mn2X8kTnzNRNXkrHKoomp7J0jnWrrys6n7fR9712neIkU9x8+cqU Lcuo19yPhUFaarBZS1YE/aA7SLZ25aKOlyq0WhWTv/SPzOTsWy4zccA0mXKat2NR otHimPOwQoK/Bk3XKb1DdLF9prpN207T9dQKS5hisYdwAoGpm92QtEjLz0YShM6K a74KjmtH5siUu6dLFGgbDFrfbPRIN3EnShPtQ66pXeNkBUsdFbet0nGnsLfquVee 3NfDg/LlworKlH86ZNHywTZzFNanPqFEL532M+kqlnuAMhw0hen5SGFy25xhDe1S urcnhaCFY1pdiefwMt9kOGEqFDMx1wQGQSbzIn+7B9a5HJAScB+cfO1GU/iUGcmH to+Ebbq5p3a8y1OeQVCt =SPDE -----END PGP SIGNATURE----- From felix.bembrick at gmail.com Sat Jun 27 18:36:31 2015 From: felix.bembrick at gmail.com (Felix Bembrick) Date: Sun, 28 Jun 2015 04:36:31 +1000 Subject: JavaFX features in JDK 9 In-Reply-To: References: <4A33E952-B3B0-4C19-9F5E-CBB10EC9E19B@gmail.com> <558EBC40.3020300@oracle.com> Message-ID: <0195069C-4F7C-487F-A791-562A39C6262A@gmail.com> I have to say that I agree with Mike that WebGL support is an absolute must especially when you consider how rudimentary the current JavaFX 3D features are. > On 28 Jun 2015, at 04:16, Mike wrote: > > a lot of FULL blown Webrtc support and building something in Javafx (like Scene Builder) that Proves Webrtc support would be awesome. Ditto to Webgl support. > > On Sat, Jun 27, 2015 at 8:07 AM, Kevin Rushforth wrote: >> Hi Felix, >> >> Sorry for the delay. Most of us were still pretty focused on 8u60, but we are turning our attention to JDK 9 now. >> >> The focus for JDK 9 is Jigsaw. The currently planned big features (JEPs) for FX in JDK 9 are these: >> >> JEP 253: Prepare JavaFX UI Controls & CSS APIs for Modularization >> JEP 257: Update JavaFX/Media to Newer Version of GStreamer >> >> Related to Jigasw, we intend to look into new API for heavily used internal methods / classes since they will no longer be accessible otherwise. We also plan to update WebKit at least one more time, and will likely do a few RFEs such as better Hi-DPI support (with API control) on Mac, Windows, Linux. >> >> We don't currently plan any other big features for 9, but will consider additional RFEs if they are important to enough developers and if they fit into the time frame. >> >> -- Kevin >> >> >> >> Felix Bembrick wrote: >>> Anyone got anything or is there a link somewhere that talks about these? >>> >>> On 15 June 2015 at 22:00, Felix Bembrick wrote: >>> >>> >>>> I realise we are a long way off JDK 9 still and with crucial features such >>>> as Jigsaw still a little up in the air but is it possible someone could >>>> itemise the most likely new features, enhancements and bug fixes that we >>>> will see in JavaFX when JDK 9 is released? >>>> >>>> Of course it's purely speculation at this point but it would assist me >>>> greatly to have some of idea of where JavaFX is heading and which areas are >>>> seen as most important. >>>> >>>> Thanks, >>>> >>>> Felix >>>> > From felix.bembrick at gmail.com Sat Jun 27 18:38:53 2015 From: felix.bembrick at gmail.com (Felix Bembrick) Date: Sun, 28 Jun 2015 04:38:53 +1000 Subject: JavaFX features in JDK 9 In-Reply-To: <558EBC40.3020300@oracle.com> References: <4A33E952-B3B0-4C19-9F5E-CBB10EC9E19B@gmail.com> <558EBC40.3020300@oracle.com> Message-ID: <4B7EEABB-980B-4C2A-8E5B-5ECC1D9C6765@gmail.com> Thanks Kevin but I am left a little underwhelmed by this tiny list. It seems that JavaFX is perhaps the slowest evolving technology in history in many respects which is very disappointing. > On 28 Jun 2015, at 01:07, Kevin Rushforth wrote: > > Hi Felix, > > Sorry for the delay. Most of us were still pretty focused on 8u60, but we are turning our attention to JDK 9 now. > > The focus for JDK 9 is Jigsaw. The currently planned big features (JEPs) for FX in JDK 9 are these: > > JEP 253: Prepare JavaFX UI Controls & CSS APIs for Modularization > JEP 257: Update JavaFX/Media to Newer Version of GStreamer > > Related to Jigasw, we intend to look into new API for heavily used internal methods / classes since they will no longer be accessible otherwise. We also plan to update WebKit at least one more time, and will likely do a few RFEs such as better Hi-DPI support (with API control) on Mac, Windows, Linux. > > We don't currently plan any other big features for 9, but will consider additional RFEs if they are important to enough developers and if they fit into the time frame. > > -- Kevin > > > Felix Bembrick wrote: >> Anyone got anything or is there a link somewhere that talks about these? >> >> On 15 June 2015 at 22:00, Felix Bembrick wrote: >> >> >>> I realise we are a long way off JDK 9 still and with crucial features such >>> as Jigsaw still a little up in the air but is it possible someone could >>> itemise the most likely new features, enhancements and bug fixes that we >>> will see in JavaFX when JDK 9 is released? >>> >>> Of course it's purely speculation at this point but it would assist me >>> greatly to have some of idea of where JavaFX is heading and which areas are >>> seen as most important. >>> >>> Thanks, >>> >>> Felix >>> From mikegps1 at gmail.com Sat Jun 27 19:24:34 2015 From: mikegps1 at gmail.com (Mike) Date: Sat, 27 Jun 2015 12:24:34 -0700 Subject: JavaFX features in JDK 9 In-Reply-To: <4B7EEABB-980B-4C2A-8E5B-5ECC1D9C6765@gmail.com> References: <4A33E952-B3B0-4C19-9F5E-CBB10EC9E19B@gmail.com> <558EBC40.3020300@oracle.com> <4B7EEABB-980B-4C2A-8E5B-5ECC1D9C6765@gmail.com> Message-ID: Felix how many full time Engineers does Oracle have on Javafx and Java? How does this break up? How many open source contributors are Committing often? On Sat, Jun 27, 2015 at 11:38 AM, Felix Bembrick wrote: > Thanks Kevin but I am left a little underwhelmed by this tiny list. It > seems that JavaFX is perhaps the slowest evolving technology in history in > many respects which is very disappointing. > > > > On 28 Jun 2015, at 01:07, Kevin Rushforth > wrote: > > > > Hi Felix, > > > > Sorry for the delay. Most of us were still pretty focused on 8u60, but > we are turning our attention to JDK 9 now. > > > > The focus for JDK 9 is Jigsaw. The currently planned big features (JEPs) > for FX in JDK 9 are these: > > > > JEP 253: Prepare JavaFX UI Controls & CSS APIs for Modularization > > JEP 257: Update JavaFX/Media to Newer Version of GStreamer > > > > Related to Jigasw, we intend to look into new API for heavily used > internal methods / classes since they will no longer be accessible > otherwise. We also plan to update WebKit at least one more time, and will > likely do a few RFEs such as better Hi-DPI support (with API control) on > Mac, Windows, Linux. > > > > We don't currently plan any other big features for 9, but will consider > additional RFEs if they are important to enough developers and if they fit > into the time frame. > > > > -- Kevin > > > > > > Felix Bembrick wrote: > >> Anyone got anything or is there a link somewhere that talks about these? > >> > >> On 15 June 2015 at 22:00, Felix Bembrick > wrote: > >> > >> > >>> I realise we are a long way off JDK 9 still and with crucial features > such > >>> as Jigsaw still a little up in the air but is it possible someone could > >>> itemise the most likely new features, enhancements and bug fixes that > we > >>> will see in JavaFX when JDK 9 is released? > >>> > >>> Of course it's purely speculation at this point but it would assist me > >>> greatly to have some of idea of where JavaFX is heading and which > areas are > >>> seen as most important. > >>> > >>> Thanks, > >>> > >>> Felix > >>> > From felix.bembrick at gmail.com Sat Jun 27 19:37:13 2015 From: felix.bembrick at gmail.com (Felix Bembrick) Date: Sun, 28 Jun 2015 05:37:13 +1000 Subject: JavaFX features in JDK 9 In-Reply-To: References: <4A33E952-B3B0-4C19-9F5E-CBB10EC9E19B@gmail.com> <558EBC40.3020300@oracle.com> <4B7EEABB-980B-4C2A-8E5B-5ECC1D9C6765@gmail.com> Message-ID: Why are you asking me? On 28 June 2015 at 05:24, Mike wrote: > Felix how many full time Engineers does Oracle have on Javafx and Java? > How does this break up? How many open source contributors are Committing > often? > > On Sat, Jun 27, 2015 at 11:38 AM, Felix Bembrick > wrote: > >> Thanks Kevin but I am left a little underwhelmed by this tiny list. It >> seems that JavaFX is perhaps the slowest evolving technology in history in >> many respects which is very disappointing. >> >> >> > On 28 Jun 2015, at 01:07, Kevin Rushforth >> wrote: >> > >> > Hi Felix, >> > >> > Sorry for the delay. Most of us were still pretty focused on 8u60, but >> we are turning our attention to JDK 9 now. >> > >> > The focus for JDK 9 is Jigsaw. The currently planned big features >> (JEPs) for FX in JDK 9 are these: >> > >> > JEP 253: Prepare JavaFX UI Controls & CSS APIs for Modularization >> > JEP 257: Update JavaFX/Media to Newer Version of GStreamer >> > >> > Related to Jigasw, we intend to look into new API for heavily used >> internal methods / classes since they will no longer be accessible >> otherwise. We also plan to update WebKit at least one more time, and will >> likely do a few RFEs such as better Hi-DPI support (with API control) on >> Mac, Windows, Linux. >> > >> > We don't currently plan any other big features for 9, but will consider >> additional RFEs if they are important to enough developers and if they fit >> into the time frame. >> > >> > -- Kevin >> > >> > >> > Felix Bembrick wrote: >> >> Anyone got anything or is there a link somewhere that talks about >> these? >> >> >> >> On 15 June 2015 at 22:00, Felix Bembrick >> wrote: >> >> >> >> >> >>> I realise we are a long way off JDK 9 still and with crucial features >> such >> >>> as Jigsaw still a little up in the air but is it possible someone >> could >> >>> itemise the most likely new features, enhancements and bug fixes that >> we >> >>> will see in JavaFX when JDK 9 is released? >> >>> >> >>> Of course it's purely speculation at this point but it would assist me >> >>> greatly to have some of idea of where JavaFX is heading and which >> areas are >> >>> seen as most important. >> >>> >> >>> Thanks, >> >>> >> >>> Felix >> >>> >> > > From mikegps1 at gmail.com Sat Jun 27 20:12:23 2015 From: mikegps1 at gmail.com (Mike) Date: Sat, 27 Jun 2015 13:12:23 -0700 Subject: JavaFX features in JDK 9 In-Reply-To: References: <4A33E952-B3B0-4C19-9F5E-CBB10EC9E19B@gmail.com> <558EBC40.3020300@oracle.com> <4B7EEABB-980B-4C2A-8E5B-5ECC1D9C6765@gmail.com> Message-ID: I thought you knew. Your spending a lot of time researching information about your upcoming blog post so I thought that was part of your common knowledge. On Sat, Jun 27, 2015 at 12:37 PM, Felix Bembrick wrote: > Why are you asking me? > > On 28 June 2015 at 05:24, Mike wrote: > >> Felix how many full time Engineers does Oracle have on Javafx and Java? >> How does this break up? How many open source contributors are Committing >> often? >> >> On Sat, Jun 27, 2015 at 11:38 AM, Felix Bembrick < >> felix.bembrick at gmail.com> wrote: >> >>> Thanks Kevin but I am left a little underwhelmed by this tiny list. It >>> seems that JavaFX is perhaps the slowest evolving technology in history in >>> many respects which is very disappointing. >>> >>> >>> > On 28 Jun 2015, at 01:07, Kevin Rushforth >>> wrote: >>> > >>> > Hi Felix, >>> > >>> > Sorry for the delay. Most of us were still pretty focused on 8u60, but >>> we are turning our attention to JDK 9 now. >>> > >>> > The focus for JDK 9 is Jigsaw. The currently planned big features >>> (JEPs) for FX in JDK 9 are these: >>> > >>> > JEP 253: Prepare JavaFX UI Controls & CSS APIs for Modularization >>> > JEP 257: Update JavaFX/Media to Newer Version of GStreamer >>> > >>> > Related to Jigasw, we intend to look into new API for heavily used >>> internal methods / classes since they will no longer be accessible >>> otherwise. We also plan to update WebKit at least one more time, and will >>> likely do a few RFEs such as better Hi-DPI support (with API control) on >>> Mac, Windows, Linux. >>> > >>> > We don't currently plan any other big features for 9, but will >>> consider additional RFEs if they are important to enough developers and if >>> they fit into the time frame. >>> > >>> > -- Kevin >>> > >>> > >>> > Felix Bembrick wrote: >>> >> Anyone got anything or is there a link somewhere that talks about >>> these? >>> >> >>> >> On 15 June 2015 at 22:00, Felix Bembrick >>> wrote: >>> >> >>> >> >>> >>> I realise we are a long way off JDK 9 still and with crucial >>> features such >>> >>> as Jigsaw still a little up in the air but is it possible someone >>> could >>> >>> itemise the most likely new features, enhancements and bug fixes >>> that we >>> >>> will see in JavaFX when JDK 9 is released? >>> >>> >>> >>> Of course it's purely speculation at this point but it would assist >>> me >>> >>> greatly to have some of idea of where JavaFX is heading and which >>> areas are >>> >>> seen as most important. >>> >>> >>> >>> Thanks, >>> >>> >>> >>> Felix >>> >>> >>> >> >> > From tbee at tbee.org Sun Jun 28 08:06:36 2015 From: tbee at tbee.org (Tom Eugelink) Date: Sun, 28 Jun 2015 10:06:36 +0200 Subject: JavaFX features in JDK 9 In-Reply-To: References: <4A33E952-B3B0-4C19-9F5E-CBB10EC9E19B@gmail.com> <558EBC40.3020300@oracle.com> <4B7EEABB-980B-4C2A-8E5B-5ECC1D9C6765@gmail.com> Message-ID: <558FAB0C.1090505@tbee.org> I have no direct knowledge of anything Oracle, but based on recent press releases Oracle has put "the cloud" up front and center. So I'm betting a lot of resources will go into that, and a lot of projects not in line with that goal will be reduced to maintenance mode. Personally I see the reduced effort in mobile as a sign of this, and possibly also this (maybe) underwhelming list. Big American multinationals have a tendency to be managed as an 'oil tanker' instead of a 'hive', so once the ship has been put on a certain course, everything will be focused on that. (This in no way is a fact or a judgement - I would not pretend to know how to run a multinational - it is merely a personal observation. I do think that, if my observation is correct, they're very late to the party.) Tom On 27-6-2015 22:12, Mike wrote: > I thought you knew. Your spending a lot of time researching information > about your upcoming blog post so I thought that was part of your common > knowledge. > > On Sat, Jun 27, 2015 at 12:37 PM, Felix Bembrick > wrote: > >> Why are you asking me? >> >> On 28 June 2015 at 05:24, Mike wrote: >> >>> Felix how many full time Engineers does Oracle have on Javafx and Java? >>> How does this break up? How many open source contributors are Committing >>> often? >>> >>> On Sat, Jun 27, 2015 at 11:38 AM, Felix Bembrick < >>> felix.bembrick at gmail.com> wrote: >>> >>>> Thanks Kevin but I am left a little underwhelmed by this tiny list. It >>>> seems that JavaFX is perhaps the slowest evolving technology in history in >>>> many respects which is very disappointing. >>>> >>>> >>>>> On 28 Jun 2015, at 01:07, Kevin Rushforth >>>> wrote: >>>>> Hi Felix, >>>>> >>>>> Sorry for the delay. Most of us were still pretty focused on 8u60, but >>>> we are turning our attention to JDK 9 now. >>>>> The focus for JDK 9 is Jigsaw. The currently planned big features >>>> (JEPs) for FX in JDK 9 are these: >>>>> JEP 253: Prepare JavaFX UI Controls & CSS APIs for Modularization >>>>> JEP 257: Update JavaFX/Media to Newer Version of GStreamer >>>>> >>>>> Related to Jigasw, we intend to look into new API for heavily used >>>> internal methods / classes since they will no longer be accessible >>>> otherwise. We also plan to update WebKit at least one more time, and will >>>> likely do a few RFEs such as better Hi-DPI support (with API control) on >>>> Mac, Windows, Linux. >>>>> We don't currently plan any other big features for 9, but will >>>> consider additional RFEs if they are important to enough developers and if >>>> they fit into the time frame. >>>>> -- Kevin >>>>> >>>>> >>>>> Felix Bembrick wrote: >>>>>> Anyone got anything or is there a link somewhere that talks about >>>> these? >>>>>> On 15 June 2015 at 22:00, Felix Bembrick >>>> wrote: >>>>>> >>>>>>> I realise we are a long way off JDK 9 still and with crucial >>>> features such >>>>>>> as Jigsaw still a little up in the air but is it possible someone >>>> could >>>>>>> itemise the most likely new features, enhancements and bug fixes >>>> that we >>>>>>> will see in JavaFX when JDK 9 is released? >>>>>>> >>>>>>> Of course it's purely speculation at this point but it would assist >>>> me >>>>>>> greatly to have some of idea of where JavaFX is heading and which >>>> areas are >>>>>>> seen as most important. >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Felix >>>>>>> >>> From steve.hruda at hexagongeospatial.com Mon Jun 29 15:39:27 2015 From: steve.hruda at hexagongeospatial.com (Hruda, Steve) Date: Mon, 29 Jun 2015 15:39:27 +0000 Subject: Patch for JDK-8090098 - [regression] Webview - getTimezoneOffset() of a ISO strings returns a wrong value Message-ID: Hi Anton & Kevin, we read your comments in the JDK bug system and analyzed WebKit's changesets again. We?ve found the code which made this regression. http://trac.webkit.org/changeset/159892 This changeset doesn't handle one special case, which was handled by the previous code.... double diff = ((localSystemTime.wHour - offsetHour) * secondsPerHour) + ((localSystemTime.wMinute - offsetMinute) * 60); (http://trac.webkit.org/browser/trunk/Source/WTF/wtf/DateMath.cpp?annotate=blame#L481 ) The diff is wrong if the calculated the offsetTime is one day before in case of the extreme values (e.g. midnight) where the offsetHour of the UTC time is 23 because of the day difference. In case of all other OS systems you will see the same code -> http://trac.webkit.org/browser/trunk/Source/WTF/wtf/DateMath.cpp?annotate=blame#L495 But there are two additional lines -> 497 & 497 which fixes this special case? if (diff < 0) diff += secondsPerDay; That means ?. localSystemTime.wHour = 0; offsetHour=23 ? which causes a negative value ? and the diff+=secondsPerDay ensures that the diff result would be one Hour instead of -23 hours We?ve found the attached V8DateTests.js (renamed to .txt) and adjusted it a little bit to get the results logged in the browsers console. As you can see at ?ResulBeforeOurBugFix.txt? and ?ResultAfterOurBugFix.txt?, we were able to fix 6 tests which failed before out bug fix. assertEquals("Sat Oct 25 2014 23:00:00 GMT+0200 (W. Europe Daylight Time)", (new Date(2014, 9, 25, 23, 0)).toString()); assertEquals("Sat, 25 Oct 2014 21:00:00 GMT", (new Date(2014, 9, 25, 23, 0)).toUTCString()); assertEquals("Sat Oct 25 2014 23:59:00 GMT+0200 (W. Europe Daylight Time)", (new Date(2014, 9, 25, 23, 59)).toString()); assertEquals("Sat, 25 Oct 2014 21:59:00 GMT", (new Date(2014, 9, 25, 23, 59)).toUTCString()); assertEquals("Sun Oct 26 2014 00:00:00 GMT+0200 (W. Europe Daylight Time)", (new Date(2014, 9, 26, 0, 0)).toString()); assertEquals("Sun Oct 26 2014 00:59:00 GMT+0200 (W. Europe Daylight Time)", (new Date(2014, 9, 26, 0, 59)).toString()); In addition we found out that WebKit also have problems in case of Windows in case of the change from winter to summer time. Winter to summer time: assertEquals("Sun Mar 30 2014 03:00:00 GMT+0200 (W. Europe Daylight Time)", (new Date(2014, 2, 30, 2, 0)).toString()); assertEquals("Sun, 30 Mar 2014 01:00:00 GMT", (new Date(2014, 2, 30, 2, 0)).toUTCString()); assertEquals("Sun Mar 30 2014 03:59:00 GMT+0200 (W. Europe Daylight Time)", (new Date(2014, 2, 30, 2, 59)).toString()); assertEquals("Sun, 30 Mar 2014 01:59:00 GMT", (new Date(2014, 2, 30, 2, 59)).toUTCString()); Summer to winter time: assertEquals("Sun Oct 26 2014 02:00:00 GMT+0200 (W. Europe Daylight Time)", (new Date(2014, 9, 26, 2, 0)).toString()); assertEquals("Sun, 26 Oct 2014 00:00:00 GMT", (new Date(2014, 9, 26, 2, 0)).toUTCString()); assertEquals("Sun Oct 26 2014 02:59:00 GMT+0200 (W. Europe Daylight Time)", (new Date(2014, 9, 26, 2, 59)).toString()); assertEquals("Sun, 26 Oct 2014 00:59:00 GMT", (new Date(2014, 9, 26, 2, 59)).toUTCString()); We will try to find a solution for that, but I think that the priority of this issue is lower than the priority of the opened regression. It would be amazing if you can add the patch of my previous and these additional two lines (DateMath.cpp) to the JDK8u60. Best Regards, Steve Diese E-Mail wurde versandt im Auftrag des Unternehmens Intergraph Ges.m.b.H. Vertretungsberechtigte Gesch?ftsf?hrer: Maximilian Weber Sitz der Gesellschaft: Margaretenstra?e 70/I/1, 1050 Wien, ?sterreich, Tel. +43 (1) 9610567-0 Eingetragen beim Handelsgericht Wien, Firmenbuch-Nr.: FN 116859 b Umsatzsteuer-Identifikationsnummer / VAT-ID: ATU15138401, Steuer-Nummer: 264/4807 This E-Mail has been sent on behalf of the company Intergraph Ges.m.b.H. Authorised Managing Directors: Maximilian Weber Registered office and Austrian headquarters: Margaretenstr. 70/I/1, 1050 Wien, Austria, Tel. +43 (1) 9610567-0 The company is recorded at the commercial court of Vienna under the company register number FN 116859 b VAT-ID: ATU15138401, Austrian Tax ID: 264/4807 Diese E-Mail (mit zugeh?rigen Dateien) enth?lt m?glicherweise Informationen, die vertraulich sind, dem Urheberrecht unterliegen oder ein Gesch?ftsgeheimnis darstellen. Falls Sie diese Nachricht irrt?mlicherweise erhalten haben, benachrichtigen Sie uns bitte umgehend, indem Sie eine Antwort senden, und l?schen Sie bitte diese E-Mail und Ihre Antwort darauf. S?mtliche aufgef?hrten Ansichten oder Meinungen sind ausschlie?lich diejenigen des Autors und entsprechen nicht notwendigerweise denen des Unternehmens Intergraph. This E-Mail (and any attachments) may be confidential and protected by legal privilege. If you are not the intended recipient please notify us immediately by replying to the sender and delete this E-Mail and your reply from your system. All the views and opinions published here are solely based on the author's own opinion and should not be considered necessarily as reflecting the opinion of Intergraph. -----Original Message----- From: openjfx-dev [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Hruda, Steve Sent: Tuesday, June 23, 2015 6:26 PM To: Anton V. Tarasov; Kevin Rushforth Cc: openjfx-dev at openjdk.java.net Subject: RE: Patch for JDK-8090098 - [regression] Webview - getTimezoneOffset() of a ISO strings returns a wrong value Very cool Anton. I would be great if that pach could be added to 8u60, otherwise our all our customers have to avoid Java 8u60. Regards, Steve Diese E-Mail wurde versandt im Auftrag des Unternehmens Intergraph Ges.m.b.H. Vertretungsberechtigte Gesch?ftsf?hrer: Maximilian Weber Sitz der Gesellschaft: Margaretenstra?e 70/I/1, 1050 Wien, ?sterreich, Tel. +43 (1) 9610567-0 Eingetragen beim Handelsgericht Wien, Firmenbuch-Nr.: FN 116859 b Umsatzsteuer-Identifikationsnummer / VAT-ID: ATU15138401, Steuer-Nummer: 264/4807 This E-Mail has been sent on behalf of the company Intergraph Ges.m.b.H. Authorised Managing Directors: Maximilian Weber Registered office and Austrian headquarters: Margaretenstr. 70/I/1, 1050 Wien, Austria, Tel. +43 (1) 9610567-0 The company is recorded at the commercial court of Vienna under the company register number FN 116859 b VAT-ID: ATU15138401, Austrian Tax ID: 264/4807 Diese E-Mail (mit zugeh?rigen Dateien) enth?lt m?glicherweise Informationen, die vertraulich sind, dem Urheberrecht unterliegen oder ein Gesch?ftsgeheimnis darstellen. Falls Sie diese Nachricht irrt?mlicherweise erhalten haben, benachrichtigen Sie uns bitte umgehend, indem Sie eine Antwort senden, und l?schen Sie bitte diese E-Mail und Ihre Antwort darauf. S?mtliche aufgef?hrten Ansichten oder Meinungen sind ausschlie?lich diejenigen des Autors und entsprechen nicht notwendigerweise denen des Unternehmens Intergraph. This E-Mail (and any attachments) may be confidential and protected by legal privilege. If you are not the intended recipient please notify us immediately by replying to the sender and delete this E-Mail and your reply from your system. All the views and opinions published here are solely based on the author's own opinion and should not be considered necessarily as reflecting the opinion of Intergraph. -----Original Message----- From: Anton V. Tarasov [mailto:anton.tarasov at oracle.com] Sent: Tuesday, June 23, 2015 5:46 PM To: Kevin Rushforth; Hruda, Steve Cc: openjfx-dev at openjdk.java.net Subject: Re: Patch for JDK-8090098 - [regression] Webview - getTimezoneOffset() of a ISO strings returns a wrong value On 23.06.2015 17:48, Kevin Rushforth wrote: > Hi Steve, > > Thank you for taking the time to create this patch. I will add this information to the bug report. > > Since your OCA is in progress we will take a look at your patch, but > will need indication from the OCA office that it the OCA has been > received before we could push it. And just to be clear, you won't have > access to the repository even with an OCA. What the OCA will do is allow you to contribute patches. > > I will note that it is likely too late for 8u60, but Anton can > evaluate it and post his comment in the bug report. Kevin, I'm checking it. Steve, thanks for the participation! Regards, Anton. > > -- Kevin > > > Hruda, Steve wrote: >> Hi, >> I've created a 8u-dev patch for the following WeKit regression which comes with 8u60. >> https://bugs.openjdk.java.net/browse/JDK-8090098 >> >> Please can someone of you apply this patch to fix the >> getTimezoneOffset() issue. I have no access to the repository -> my OCA is still pending. >> >> In addition I tried to test this patch , but I wasn't able to build >> the necessary jfxwebkit.dll on my windows system >> (https://www.mail-archive.com/openjfx-dev at openjdk.java.net/msg09439.h >> tml )..... but I got no compile erros on Mac. >> >> Patch download: >> https://drive.google.com/file/d/0B7P_rknS1TWxM3BSTTU2OVZ4dGM/view?usp >> =sharing >> >> The patch includes the following WebKit fixes: >> Changeset 174377 - [Win] DateMath's calculateUTFOffset does not account for DST. >> http://trac.webkit.org/changeset/174377 >> >> Changeset 175078 - String(new Date(Mar 30 2014 01:00:00)) is wrong >> in CET >> http://trac.webkit.org/changeset/175078 >> >> Changeset 181360 - [Win] 17 different JSC tests started to fail in >> DST >> http://trac.webkit.org/changeset/181360 >> >> Please let me know if you need further information. >> >> Thanks in advance! >> Best Regards >> Steve >> >> >> >> Diese E-Mail wurde versandt im Auftrag des Unternehmens Intergraph Ges.m.b.H. >> Vertretungsberechtigte Gesch?ftsf?hrer: Maximilian Weber Sitz der >> Gesellschaft: Margaretenstra?e 70/I/1, 1050 Wien, ?sterreich, Tel. >> +43 (1) 9610567-0 Eingetragen beim Handelsgericht Wien, >> Firmenbuch-Nr.: FN 116859 b Umsatzsteuer-Identifikationsnummer / >> VAT-ID: ATU15138401, Steuer-Nummer: 264/4807 >> >> This E-Mail has been sent on behalf of the company Intergraph Ges.m.b.H. >> Authorised Managing Directors: Maximilian Weber Registered office and >> Austrian headquarters: Margaretenstr. 70/I/1, 1050 Wien, Austria, >> Tel. +43 >> (1) 9610567-0 >> The company is recorded at the commercial court of Vienna under the >> company register number FN >> 116859 b >> VAT-ID: ATU15138401, Austrian Tax ID: 264/4807 >> >> Diese E-Mail (mit zugeh?rigen Dateien) enth?lt m?glicherweise >> Informationen, die vertraulich sind, dem Urheberrecht unterliegen >> oder ein Gesch?ftsgeheimnis darstellen. Falls Sie diese Nachricht >> irrt?mlicherweise erhalten haben, benachrichtigen Sie uns bitte >> umgehend, indem Sie eine Antwort senden, und l?schen Sie bitte diese >> E-Mail und Ihre Antwort darauf. S?mtliche aufgef?hrten Ansichten oder Meinungen sind ausschlie?lich diejenigen des Autors und entsprechen nicht notwendigerweise denen des Unternehmens Intergraph. >> >> This E-Mail (and any attachments) may be confidential and protected >> by legal privilege. If you are not the intended recipient please >> notify us immediately by replying to the sender and delete this >> E-Mail and your reply from your system. All the views and opinions >> published here are solely based on the author's own opinion and should not be considered necessarily as reflecting the opinion of Intergraph. >> >> -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ResultBeforeOurBugFix.txt URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ResultAfterOurBugFix.txt URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: V8DateTests.txt URL: From kevin.rushforth at oracle.com Mon Jun 29 18:30:15 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 29 Jun 2015 11:30:15 -0700 Subject: JavaFX features in JDK 9 In-Reply-To: <558EED1C.8030005@poczta.onet.pl> References: <4A33E952-B3B0-4C19-9F5E-CBB10EC9E19B@gmail.com> <558EBC40.3020300@oracle.com> <558EED1C.8030005@poczta.onet.pl> Message-ID: <55918EB7.3060807@oracle.com> JavaFX accessibility is already implemented and was delivered in JDK 8u40. -- Kevin Micha? Zegan wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > What about accessibility work? Work on it has been started, but not > sure if it is still targetted for 9. > > W dniu 2015-06-27 o 20:16, Mike pisze: > >> a lot of FULL blown Webrtc support and building something in Javafx >> (like Scene Builder) that Proves Webrtc support would be awesome. >> Ditto to Webgl support. >> >> On Sat, Jun 27, 2015 at 8:07 AM, Kevin Rushforth >> > >>> wrote: >>> >>> Hi Felix, >>> >>> Sorry for the delay. Most of us were still pretty focused on >>> 8u60, but we are turning our attention to JDK 9 now. >>> >>> The focus for JDK 9 is Jigsaw. The currently planned big features >>> (JEPs) for FX in JDK 9 are these: >>> >>> JEP 253: Prepare JavaFX UI Controls & CSS APIs for >>> Modularization JEP 257: Update JavaFX/Media to Newer Version of >>> GStreamer >>> >>> Related to Jigasw, we intend to look into new API for heavily >>> used internal methods / classes since they will no longer be >>> accessible otherwise. We also plan to update WebKit at least one >>> more time, and will likely do a few RFEs such as better Hi-DPI >>> support (with API control) on Mac, Windows, Linux. >>> >>> We don't currently plan any other big features for 9, but will >>> consider additional RFEs if they are important to enough >>> developers and if they fit into the time frame. >>> >>> -- Kevin >>> >>> >>> >>> Felix Bembrick wrote: >>> >>> >>>> Anyone got anything or is there a link somewhere that talks >>>> about these? >>>> >>>> On 15 June 2015 at 22:00, Felix Bembrick >>>> wrote: >>>> >>>> >>>> >>>> >>>>> I realise we are a long way off JDK 9 still and with crucial >>>>> features such as Jigsaw still a little up in the air but is >>>>> it possible someone could itemise the most likely new >>>>> features, enhancements and bug fixes that we will see in >>>>> JavaFX when JDK 9 is released? >>>>> >>>>> Of course it's purely speculation at this point but it would >>>>> assist me greatly to have some of idea of where JavaFX is >>>>> heading and which areas are seen as most important. >>>>> >>>>> Thanks, >>>>> >>>>> Felix >>>>> >>>>> >>>>> > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > > iQIcBAEBAgAGBQJVju0bAAoJEHb1CzgxXKwYYRAP/iPJ43tu3Q56oXLr+SjD+Qqc > xtBs9Fb3k3FJlPmqDlq3mbvW4RkpGNDUi71OlocYJ1v5C719samTd1mqpKHubJj7 > 0mZHUmISswaJRcnXnXmIQL8i7tX+XvK2JSHV8mwEcZ7rCIHAz2qxxQMnAlGKw7MV > tSzWtTCAuSjI7auN8Lew2lmAXD9NRe3+Tuyq4tcWK9O3UTI5CZl1KiX4MTS6/wGU > xJVr+k1EMMVckOUhRkLfNy332x/dsxdvw0dBo+7P8h/mKZWYcDGop/z3YLRj0zAx > /JEKaGLsJa72Mn2X8kTnzNRNXkrHKoomp7J0jnWrrys6n7fR9712neIkU9x8+cqU > Lcuo19yPhUFaarBZS1YE/aA7SLZ25aKOlyq0WhWTv/SPzOTsWy4zccA0mXKat2NR > otHimPOwQoK/Bk3XKb1DdLF9prpN207T9dQKS5hisYdwAoGpm92QtEjLz0YShM6K > a74KjmtH5siUu6dLFGgbDFrfbPRIN3EnShPtQ66pXeNkBUsdFbet0nGnsLfquVee > 3NfDg/LlworKlH86ZNHywTZzFNanPqFEL532M+kqlnuAMhw0hen5SGFy25xhDe1S > urcnhaCFY1pdiefwMt9kOGEqFDMx1wQGQSbzIn+7B9a5HJAScB+cfO1GU/iUGcmH > to+Ebbq5p3a8y1OeQVCt > =SPDE > -----END PGP SIGNATURE----- > From anton.tarasov at oracle.com Mon Jun 29 18:42:50 2015 From: anton.tarasov at oracle.com (Anton Tarasov) Date: Mon, 29 Jun 2015 21:42:50 +0300 Subject: Patch for JDK-8090098 - [regression] Webview - getTimezoneOffset() of a ISO strings returns a wrong value In-Reply-To: References: Message-ID: <559191AA.8030800@oracle.com> Hi Steve, Ok, I'll investigate it. Thanks, Anton. On 29.06.2015 18:39, Hruda, Steve wrote: > > Hi Anton & Kevin, > > we read your comments in the JDK bug system and analyzed WebKit's > changesets again. > > We?ve found the code which made this regression. > > http://trac.webkit.org/changeset/159892 > > This changeset doesn't handle one special case, which was handled by > the previous code.... > > double diff = ((localSystemTime.wHour - offsetHour) * secondsPerHour) > + ((localSystemTime.wMinute - offsetMinute) *60); > > > (http://trac.webkit.org/browser/trunk/Source/WTF/wtf/DateMath.cpp?annotate=blame#L481 > ) > > The diff is wrong if the calculated the offsetTime is one day before > in case of the extreme values (e.g. midnight) where the offsetHour of > the UTC time is 23 because of the day difference. > > In case of all other OS systems you will see the same code -> > http://trac.webkit.org/browser/trunk/Source/WTF/wtf/DateMath.cpp?annotate=blame#L495 > > But there are two additional lines -> 497 & 497 which fixes this > special case? > > *if*(diff<0) > > diff += secondsPerDay; > > > That means ?. > > localSystemTime.wHour = 0; > > offsetHour=23 ? which causes a negative value ? and the > diff+=secondsPerDay ensures that the diff result would be one Hour > instead of -23 hours > > We?ve found the attached V8DateTests.js (renamed to .txt) and adjusted > it a little bit to get the results logged in the browsers console. > > As you can see at ?ResulBeforeOurBugFix.txt? and > ?ResultAfterOurBugFix.txt?, we were able to fix 6 tests which failed > before out bug fix. > > assertEquals("Sat Oct 25 2014 23:00:00 GMT+0200 (W. Europe Daylight > Time)", > > (new Date(2014, 9, 25, 23, 0)).toString()); > > assertEquals("Sat, 25 Oct 2014 21:00:00 GMT", > > (new Date(2014, 9, 25, 23, 0)).toUTCString()); > > assertEquals("Sat Oct 25 2014 23:59:00 GMT+0200 (W. Europe Daylight > Time)", > > (new Date(2014, 9, 25, 23, 59)).toString()); > > assertEquals("Sat, 25 Oct 2014 21:59:00 GMT", > > (new Date(2014, 9, 25, 23, 59)).toUTCString()); > > assertEquals("Sun Oct 26 2014 00:00:00 GMT+0200 (W. Europe Daylight > Time)", > > (new Date(2014, 9, 26, 0, 0)).toString()); > > assertEquals("Sun Oct 26 2014 00:59:00 GMT+0200 (W. Europe Daylight > Time)", > > (new Date(2014, 9, 26, 0, 59)).toString()); > > In addition we found out that WebKit also have problems in case of > Windows in case of the change from winter to summer time. > > *_Winter to summer time:_* > > assertEquals("Sun Mar 30 2014 03:00:00 GMT+0200 (W. Europe Daylight > Time)", > > (new Date(2014, 2, 30, 2, 0)).toString()); > > assertEquals("Sun, 30 Mar 2014 01:00:00 GMT", > > (new Date(2014, 2, 30, 2, 0)).toUTCString()); > > assertEquals("Sun Mar 30 2014 03:59:00 GMT+0200 (W. Europe Daylight > Time)", > > (new Date(2014, 2, 30, 2, 59)).toString()); > > assertEquals("Sun, 30 Mar 2014 01:59:00 GMT", > > (new Date(2014, 2, 30, 2, 59)).toUTCString()); > > *_Summer to winter time:_* > > assertEquals("Sun Oct 26 2014 02:00:00 GMT+0200 (W. Europe Daylight > Time)", > > (new Date(2014, 9, 26, 2, 0)).toString()); > > assertEquals("Sun, 26 Oct 2014 00:00:00 GMT", > > (new Date(2014, 9, 26, 2, 0)).toUTCString()); > > assertEquals("Sun Oct 26 2014 02:59:00 GMT+0200 (W. Europe Daylight > Time)", > > (new Date(2014, 9, 26, 2, 59)).toString()); > > assertEquals("Sun, 26 Oct 2014 00:59:00 GMT", > > (new Date(2014, 9, 26, 2, 59)).toUTCString()); > > We will try to find a solution for that, but I think that the priority > of this issue is lower than the priority of the opened regression. > > It would be amazing if you can add the patch of my previous and these > additional two lines (DateMath.cpp) to the JDK8u60. > > Best Regards, > > Steve > > > Diese E-Mail wurde versandt im Auftrag des Unternehmens Intergraph > Ges.m.b.H. > Vertretungsberechtigte Gesch?ftsf?hrer: Maximilian Weber > Sitz der Gesellschaft: Margaretenstra?e 70/I/1, 1050 Wien, ?sterreich, > Tel. +43 (1) 9610567-0 > Eingetragen beim Handelsgericht Wien, Firmenbuch-Nr.: FN 116859 b > Umsatzsteuer-Identifikationsnummer / VAT-ID: ATU15138401, > Steuer-Nummer: 264/4807 > > This E-Mail has been sent on behalf of the company Intergraph Ges.m.b.H. > Authorised Managing Directors: Maximilian Weber > Registered office and Austrian headquarters: Margaretenstr. 70/I/1, > 1050 Wien, Austria, Tel. +43 (1) 9610567-0 > The company is recorded at the commercial court of Vienna under the > company register number FN 116859 b > VAT-ID: ATU15138401, Austrian Tax ID: 264/4807 > > Diese E-Mail (mit zugeh?rigen Dateien) enth?lt m?glicherweise > Informationen, die vertraulich sind, dem Urheberrecht unterliegen oder > ein Gesch?ftsgeheimnis darstellen. Falls Sie diese Nachricht > irrt?mlicherweise erhalten haben, benachrichtigen Sie uns bitte > umgehend, indem Sie eine Antwort senden, und l?schen Sie bitte diese > E-Mail und Ihre Antwort darauf. S?mtliche aufgef?hrten Ansichten oder > Meinungen sind ausschlie?lich diejenigen des Autors und entsprechen > nicht notwendigerweise denen des Unternehmens Intergraph. > > This E-Mail (and any attachments) may be confidential and protected by > legal privilege. If you are not the intended recipient please notify > us immediately by replying to the sender and delete this E-Mail and > your reply from your system. All the views and opinions published here > are solely based on the author's own opinion and should not be > considered necessarily as reflecting the opinion of Intergraph. > > -----Original Message----- > > From: openjfx-dev [mailto:openjfx-dev-bounces at openjdk.java.net] On > Behalf Of Hruda, Steve > > Sent: Tuesday, June 23, 2015 6:26 PM > > To: Anton V. Tarasov; Kevin Rushforth > > Cc: openjfx-dev at openjdk.java.net > > Subject: RE: Patch for JDK-8090098 - [regression] Webview - > getTimezoneOffset() of a ISO strings returns a wrong value > > Very cool Anton. > > I would be great if that pach could be added to 8u60, otherwise our > all our customers have to avoid Java 8u60. > > Regards, > > Steve > > Diese E-Mail wurde versandt im Auftrag des Unternehmens Intergraph > Ges.m.b.H. > > Vertretungsberechtigte Gesch?ftsf?hrer: Maximilian Weber Sitz der > Gesellschaft: Margaretenstra?e 70/I/1, 1050 Wien, ?sterreich, Tel. +43 > (1) 9610567-0 Eingetragen beim Handelsgericht Wien, Firmenbuch-Nr.: FN > 116859 b Umsatzsteuer-Identifikationsnummer / VAT-ID: ATU15138401, > Steuer-Nummer: 264/4807 > > This E-Mail has been sent on behalf of the company Intergraph Ges.m.b.H. > > Authorised Managing Directors: Maximilian Weber Registered office and > Austrian headquarters: Margaretenstr. 70/I/1, 1050 Wien, Austria, Tel. > +43 (1) 9610567-0 The company is recorded at the commercial court of > Vienna under the company register number FN 116859 b > > VAT-ID: ATU15138401, Austrian Tax ID: 264/4807 > > Diese E-Mail (mit zugeh?rigen Dateien) enth?lt m?glicherweise > Informationen, die vertraulich sind, dem Urheberrecht unterliegen oder > ein Gesch?ftsgeheimnis darstellen. Falls Sie diese Nachricht > irrt?mlicherweise erhalten haben, benachrichtigen Sie uns bitte > umgehend, indem Sie eine Antwort senden, und l?schen Sie bitte diese > E-Mail und Ihre Antwort darauf. S?mtliche aufgef?hrten Ansichten oder > Meinungen sind ausschlie?lich diejenigen des Autors und entsprechen > nicht notwendigerweise denen des Unternehmens Intergraph. > > This E-Mail (and any attachments) may be confidential and protected by > legal privilege. If you are not the intended recipient please notify > us immediately by replying to the sender and delete this E-Mail and > your reply from your system. All the views and opinions published here > are solely based on the author's own opinion and should not be > considered necessarily as reflecting the opinion of Intergraph. > > -----Original Message----- > > From: Anton V. Tarasov [mailto:anton.tarasov at oracle.com] > > Sent: Tuesday, June 23, 2015 5:46 PM > > To: Kevin Rushforth; Hruda, Steve > > Cc: openjfx-dev at openjdk.java.net > > Subject: Re: Patch for JDK-8090098 - [regression] Webview - > getTimezoneOffset() of a ISO strings returns a wrong value > > On 23.06.2015 17:48, Kevin Rushforth wrote: > > > Hi Steve, > > > > > > Thank you for taking the time to create this patch. I will add this information to > the bug report. > > > > > > Since your OCA is in progress we will take a look at your patch, but > > > will need indication from the OCA office that it the OCA has been > > > received before we could push it. And just to be clear, you won't have > > > access to the repository even with an OCA. What the OCA will do is allow you to > contribute patches. > > > > > > I will note that it is likely too late for 8u60, but Anton can > > > evaluate it and post his comment in the bug report. > > Kevin, > > I'm checking it. > > Steve, thanks for the participation! > > Regards, > > Anton. > > > > > > -- Kevin > > > > > > > > > Hruda, Steve wrote: > > >> Hi, > > >> I've created a 8u-dev patch for the following WeKit regression which comes with 8u60. > > >>https://bugs.openjdk.java.net/browse/JDK-8090098 > > >> > > >> Please can someone of you apply this patch to fix the > > >> getTimezoneOffset() issue. I have no access to the repository -> my > OCA is still pending. > > >> > > >> In addition I tried to test this patch , but I wasn't able to build > > >> the necessary jfxwebkit.dll on my windows system > > >> (https://www.mail-archive.com/openjfx-dev at openjdk.java.net/msg09439.h > > >> tml )..... but I got no compile erros on Mac. > > >> > > >> Patch download: > > >>https://drive.google.com/file/d/0B7P_rknS1TWxM3BSTTU2OVZ4dGM/view?usp > > >> =sharing > > >> > > >> The patch includes the following WebKit fixes: > > >> Changeset 174377 - [Win] DateMath's calculateUTFOffset does not account for DST. > > >>http://trac.webkit.org/changeset/174377 > > >> > > >> Changeset 175078 - String(new Date(Mar 30 2014 01:00:00)) is wrong > > >> in CET > > >>http://trac.webkit.org/changeset/175078 > > >> > > >> Changeset 181360 - [Win] 17 different JSC tests started to fail in > > >> DST > > >>http://trac.webkit.org/changeset/181360 > > >> > > >> Please let me know if you need further information. > > >> > > >> Thanks in advance! > > >> Best Regards > > >> Steve > > >> > > >> > > >> > > >> Diese E-Mail wurde versandt im Auftrag des Unternehmens Intergraph > Ges.m.b.H. > > >> Vertretungsberechtigte Gesch?ftsf?hrer: Maximilian Weber Sitz der > > >> Gesellschaft: Margaretenstra?e 70/I/1, 1050 Wien, ?sterreich, Tel. > > >> +43 (1) 9610567-0 Eingetragen beim Handelsgericht Wien, > > >> Firmenbuch-Nr.: FN 116859 b Umsatzsteuer-Identifikationsnummer / > > >> VAT-ID: ATU15138401, Steuer-Nummer: 264/4807 > > >> > > >> This E-Mail has been sent on behalf of the company Intergraph Ges.m.b.H. > > >> Authorised Managing Directors: Maximilian Weber Registered office and > > >> Austrian headquarters: Margaretenstr. 70/I/1, 1050 Wien, Austria, > > >> Tel. +43 > > >> (1) 9610567-0 > > >> The company is recorded at the commercial court of Vienna under the > > >> company register number FN > > >> 116859 b > > >> VAT-ID: ATU15138401, Austrian Tax ID: 264/4807 > > >> > > >> Diese E-Mail (mit zugeh?rigen Dateien) enth?lt m?glicherweise > > >> Informationen, die vertraulich sind, dem Urheberrecht unterliegen > > >> oder ein Gesch?ftsgeheimnis darstellen. Falls Sie diese Nachricht > > >> irrt?mlicherweise erhalten haben, benachrichtigen Sie uns bitte > > >> umgehend, indem Sie eine Antwort senden, und l?schen Sie bitte diese > > >> E-Mail und Ihre Antwort darauf. S?mtliche aufgef?hrten Ansichten > oder Meinungen sind ausschlie?lich diejenigen des Autors und > entsprechen nicht notwendigerweise denen des Unternehmens Intergraph. > > >> > > >> This E-Mail (and any attachments) may be confidential and protected > > >> by legal privilege. If you are not the intended recipient please > > >> notify us immediately by replying to the sender and delete this > > >> E-Mail and your reply from your system. All the views and opinions > > >> published here are solely based on the author's own opinion and should not be > considered necessarily as reflecting the opinion of Intergraph. > > >> > > >> > From webczat_200 at poczta.onet.pl Mon Jun 29 18:58:52 2015 From: webczat_200 at poczta.onet.pl (=?UTF-8?B?TWljaGHFgiBaZWdhbg==?=) Date: Mon, 29 Jun 2015 20:58:52 +0200 Subject: JavaFX features in JDK 9 In-Reply-To: <55918EB7.3060807@oracle.com> References: <4A33E952-B3B0-4C19-9F5E-CBB10EC9E19B@gmail.com> <558EBC40.3020300@oracle.com> <558EED1C.8030005@poczta.onet.pl> <55918EB7.3060807@oracle.com> Message-ID: <5591956C.3080607@poczta.onet.pl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I saw it, and it seems promising, but: first, there is probably, or I heard it wrong? no public api for making accessibility related stuff... Also, I believe there is no linux accessibility bridge as opposed to windows and mac. And I do not know if I am wrong, or when this is going to be implemented. W dniu 2015-06-29 o 20:30, Kevin Rushforth pisze: > JavaFX accessibility is already implemented and was delivered in > JDK 8u40. > > -- Kevin > > > Micha? Zegan wrote: What about accessibility work? Work on it has > been started, but not sure if it is still targetted for 9. > > W dniu 2015-06-27 o 20:16, Mike pisze: > >>>> a lot of FULL blown Webrtc support and building something in >>>> Javafx (like Scene Builder) that Proves Webrtc support would >>>> be awesome. Ditto to Webgl support. >>>> >>>> On Sat, Jun 27, 2015 at 8:07 AM, Kevin Rushforth >>>> >>> >>>>> wrote: >>>>> >>>>> Hi Felix, >>>>> >>>>> Sorry for the delay. Most of us were still pretty focused >>>>> on 8u60, but we are turning our attention to JDK 9 now. >>>>> >>>>> The focus for JDK 9 is Jigsaw. The currently planned big >>>>> features (JEPs) for FX in JDK 9 are these: >>>>> >>>>> JEP 253: Prepare JavaFX UI Controls & CSS APIs for >>>>> Modularization JEP 257: Update JavaFX/Media to Newer >>>>> Version of GStreamer >>>>> >>>>> Related to Jigasw, we intend to look into new API for >>>>> heavily used internal methods / classes since they will no >>>>> longer be accessible otherwise. We also plan to update >>>>> WebKit at least one more time, and will likely do a few >>>>> RFEs such as better Hi-DPI support (with API control) on >>>>> Mac, Windows, Linux. >>>>> >>>>> We don't currently plan any other big features for 9, but >>>>> will consider additional RFEs if they are important to >>>>> enough developers and if they fit into the time frame. >>>>> >>>>> -- Kevin >>>>> >>>>> >>>>> >>>>> Felix Bembrick wrote: >>>>> >>>>> >>>>>> Anyone got anything or is there a link somewhere that >>>>>> talks about these? >>>>>> >>>>>> On 15 June 2015 at 22:00, Felix Bembrick >>>>>> wrote: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> I realise we are a long way off JDK 9 still and with >>>>>>> crucial features such as Jigsaw still a little up in >>>>>>> the air but is it possible someone could itemise the >>>>>>> most likely new features, enhancements and bug fixes >>>>>>> that we will see in JavaFX when JDK 9 is released? >>>>>>> >>>>>>> Of course it's purely speculation at this point but it >>>>>>> would assist me greatly to have some of idea of where >>>>>>> JavaFX is heading and which areas are seen as most >>>>>>> important. >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Felix >>>>>>> >>>>>>> >>>>>>> >> -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVkZVqAAoJEHb1CzgxXKwYqsYP/juj0ul7azGWmrI1l2nuD8wu eZ1tYezUb/ri8BYbMdsLHA+Pl2ECCN2/Hah8ihXOFnYfYiQ0EVpAKzrVpVEshXgf S5SEPHwFpp2hggN+pO25KoIuFQxJ26lomIALzj2jSyk4DabSO0SAkPvEHHO/UhhZ 7K3UkQMjaA3vLthXZde0gfF8iwXYpYogrZhN/YewKDtRg4zB3hWIJiIQkoq6f0Rp QcsjW4dC/gbhKh1CVIFJlreYanrKOTrjc2VOkEah/nCAwbL4cjLdwIEhXAWIxWd4 OM12QSEHVYoZpqMmq4yXeeyiJ/bGdYOY0KndFjIx8Ay0BA0F7qOymdx15qG2gRCQ F0spfKNnzmaVsl8Y9Wi10OSR9HWDqmyPxQdudjbY1VG4UTs0xGqAcRuZefw5X1IP KZliDKvxLe2eYMzBbD/zKeq0ukZG1oNyudI4EsktcS4cSJ/sWVBRyz3hXU1gFh+R gKCjig2k32p4pHTVfqR7BvNEZro3u7vNA1+5WRw1q981btUC9vE/2x1V+pka403P u1bUTI/YtyOrs8/7G6EsQzG33jE8ZBkw5YN9R34Y/cOdCEDfGmQtDOYXVkf1hYdS qiFsIiOLbeTHtufFzbnLLWxaYrxvWzeFnDmPUka/7VC3q5+n7v/UGEvON7uj1s3D hcl6m3KzObQspC2cfKv/ =PrDH -----END PGP SIGNATURE----- From kevin.rushforth at oracle.com Mon Jun 29 20:02:36 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 29 Jun 2015 13:02:36 -0700 Subject: 9-dev unlocked; 8u-dev still locked Message-ID: <5591A45C.70303@oracle.com> The 9-dev repo is now open following this week's sanity testing. The usual policies apply to changes going into 9 (no additional restrictions). The 8u-dev repo remains locked. -- Kevin From kevin.rushforth at oracle.com Mon Jun 29 20:40:57 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 29 Jun 2015 13:40:57 -0700 Subject: JavaFX features in JDK 9 In-Reply-To: <5591956C.3080607@poczta.onet.pl> References: <4A33E952-B3B0-4C19-9F5E-CBB10EC9E19B@gmail.com> <558EBC40.3020300@oracle.com> <558EED1C.8030005@poczta.onet.pl> <55918EB7.3060807@oracle.com> <5591956C.3080607@poczta.onet.pl> Message-ID: <5591AD59.3040000@oracle.com> There is public API in 8u40 to support accessibility. Applications using standard JavaFX controls can, for example, use the accessibleText property to define the text that the screen reader will speak or the accessibleHelp property to provide a more detailed description. These properties have reasonable defaults, but can be overridden by applications. Additionally, if you use the "labelFor" property to point to a Control that the Label is associated with, the accessibility framework will use that when the screen reader is active. Custom controls can override the queryAccessibleAttribute, executeAccessibleAction, and notifyAccessibleAttributeChanged methods. As for platform support, we currently support Windows and Mac platforms. We have no plan to make FX accessible on Linux . -- Kevin Micha? Zegan wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > I saw it, and it seems promising, but: first, there is probably, or I > heard it wrong? no public api for making accessibility related stuff... > Also, I believe there is no linux accessibility bridge as opposed to > windows and mac. And I do not know if I am wrong, or when this is > going to be implemented. > > W dniu 2015-06-29 o 20:30, Kevin Rushforth pisze: > >> JavaFX accessibility is already implemented and was delivered in >> JDK 8u40. >> >> -- Kevin >> >> >> Micha? Zegan wrote: What about accessibility work? Work on it has >> been started, but not sure if it is still targetted for 9. >> >> W dniu 2015-06-27 o 20:16, Mike pisze: >> >> >>>>> a lot of FULL blown Webrtc support and building something in >>>>> Javafx (like Scene Builder) that Proves Webrtc support would >>>>> be awesome. Ditto to Webgl support. >>>>> >>>>> On Sat, Jun 27, 2015 at 8:07 AM, Kevin Rushforth >>>>> >>>> >>>>> >>>>>> wrote: >>>>>> >>>>>> Hi Felix, >>>>>> >>>>>> Sorry for the delay. Most of us were still pretty focused >>>>>> on 8u60, but we are turning our attention to JDK 9 now. >>>>>> >>>>>> The focus for JDK 9 is Jigsaw. The currently planned big >>>>>> features (JEPs) for FX in JDK 9 are these: >>>>>> >>>>>> JEP 253: Prepare JavaFX UI Controls & CSS APIs for >>>>>> Modularization JEP 257: Update JavaFX/Media to Newer >>>>>> Version of GStreamer >>>>>> >>>>>> Related to Jigasw, we intend to look into new API for >>>>>> heavily used internal methods / classes since they will no >>>>>> longer be accessible otherwise. We also plan to update >>>>>> WebKit at least one more time, and will likely do a few >>>>>> RFEs such as better Hi-DPI support (with API control) on >>>>>> Mac, Windows, Linux. >>>>>> >>>>>> We don't currently plan any other big features for 9, but >>>>>> will consider additional RFEs if they are important to >>>>>> enough developers and if they fit into the time frame. >>>>>> >>>>>> -- Kevin >>>>>> >>>>>> >>>>>> >>>>>> Felix Bembrick wrote: >>>>>> >>>>>> >>>>>> >>>>>>> Anyone got anything or is there a link somewhere that >>>>>>> talks about these? >>>>>>> >>>>>>> On 15 June 2015 at 22:00, Felix Bembrick >>>>>>> wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> I realise we are a long way off JDK 9 still and with >>>>>>>> crucial features such as Jigsaw still a little up in >>>>>>>> the air but is it possible someone could itemise the >>>>>>>> most likely new features, enhancements and bug fixes >>>>>>>> that we will see in JavaFX when JDK 9 is released? >>>>>>>> >>>>>>>> Of course it's purely speculation at this point but it >>>>>>>> would assist me greatly to have some of idea of where >>>>>>>> JavaFX is heading and which areas are seen as most >>>>>>>> important. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Felix >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > > iQIcBAEBAgAGBQJVkZVqAAoJEHb1CzgxXKwYqsYP/juj0ul7azGWmrI1l2nuD8wu > eZ1tYezUb/ri8BYbMdsLHA+Pl2ECCN2/Hah8ihXOFnYfYiQ0EVpAKzrVpVEshXgf > S5SEPHwFpp2hggN+pO25KoIuFQxJ26lomIALzj2jSyk4DabSO0SAkPvEHHO/UhhZ > 7K3UkQMjaA3vLthXZde0gfF8iwXYpYogrZhN/YewKDtRg4zB3hWIJiIQkoq6f0Rp > QcsjW4dC/gbhKh1CVIFJlreYanrKOTrjc2VOkEah/nCAwbL4cjLdwIEhXAWIxWd4 > OM12QSEHVYoZpqMmq4yXeeyiJ/bGdYOY0KndFjIx8Ay0BA0F7qOymdx15qG2gRCQ > F0spfKNnzmaVsl8Y9Wi10OSR9HWDqmyPxQdudjbY1VG4UTs0xGqAcRuZefw5X1IP > KZliDKvxLe2eYMzBbD/zKeq0ukZG1oNyudI4EsktcS4cSJ/sWVBRyz3hXU1gFh+R > gKCjig2k32p4pHTVfqR7BvNEZro3u7vNA1+5WRw1q981btUC9vE/2x1V+pka403P > u1bUTI/YtyOrs8/7G6EsQzG33jE8ZBkw5YN9R34Y/cOdCEDfGmQtDOYXVkf1hYdS > qiFsIiOLbeTHtufFzbnLLWxaYrxvWzeFnDmPUka/7VC3q5+n7v/UGEvON7uj1s3D > hcl6m3KzObQspC2cfKv/ > =PrDH > -----END PGP SIGNATURE----- > From webczat_200 at poczta.onet.pl Mon Jun 29 20:45:02 2015 From: webczat_200 at poczta.onet.pl (=?UTF-8?B?TWljaGHFgiBaZWdhbg==?=) Date: Mon, 29 Jun 2015 22:45:02 +0200 Subject: JavaFX features in JDK 9 In-Reply-To: <5591AD59.3040000@oracle.com> References: <4A33E952-B3B0-4C19-9F5E-CBB10EC9E19B@gmail.com> <558EBC40.3020300@oracle.com> <558EED1C.8030005@poczta.onet.pl> <55918EB7.3060807@oracle.com> <5591956C.3080607@poczta.onet.pl> <5591AD59.3040000@oracle.com> Message-ID: <5591AE4E.3000409@poczta.onet.pl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Does it mean platform support for linux won't be implemented now, or at all? I usually use windows, but still depend on that support because I sometimes use linux, so I am interested about that. W dniu 2015-06-29 o 22:40, Kevin Rushforth pisze: > There is public API in 8u40 to support accessibility. Applications > using standard JavaFX controls can, for example, use the > accessibleText property to define the text that the screen reader > will speak or the accessibleHelp property to provide a more > detailed description. These properties have reasonable defaults, > but can be overridden by applications. Additionally, if you use the > "labelFor" property to point to a Control that the Label is > associated with, the accessibility framework will use that when the > screen reader is active. > > Custom controls can override the queryAccessibleAttribute, > executeAccessibleAction, and notifyAccessibleAttributeChanged > methods. > > As for platform support, we currently support Windows and Mac > platforms. We have no plan to make FX accessible on Linux . > > -- Kevin > > > Micha? Zegan wrote: I saw it, and it seems promising, but: first, > there is probably, or I heard it wrong? no public api for making > accessibility related stuff... Also, I believe there is no linux > accessibility bridge as opposed to windows and mac. And I do not > know if I am wrong, or when this is going to be implemented. > > W dniu 2015-06-29 o 20:30, Kevin Rushforth pisze: > >>>> JavaFX accessibility is already implemented and was delivered >>>> in JDK 8u40. >>>> >>>> -- Kevin >>>> >>>> >>>> Micha? Zegan wrote: What about accessibility work? Work on it >>>> has been started, but not sure if it is still targetted for >>>> 9. >>>> >>>> W dniu 2015-06-27 o 20:16, Mike pisze: >>>> >>>> >>>>>>> a lot of FULL blown Webrtc support and building >>>>>>> something in Javafx (like Scene Builder) that Proves >>>>>>> Webrtc support would be awesome. Ditto to Webgl >>>>>>> support. >>>>>>> >>>>>>> On Sat, Jun 27, 2015 at 8:07 AM, Kevin Rushforth >>>>>>> >>>>>> >>>>>>> >>>>>>>> wrote: >>>>>>>> >>>>>>>> Hi Felix, >>>>>>>> >>>>>>>> Sorry for the delay. Most of us were still pretty >>>>>>>> focused on 8u60, but we are turning our attention to >>>>>>>> JDK 9 now. >>>>>>>> >>>>>>>> The focus for JDK 9 is Jigsaw. The currently planned >>>>>>>> big features (JEPs) for FX in JDK 9 are these: >>>>>>>> >>>>>>>> JEP 253: Prepare JavaFX UI Controls & CSS APIs for >>>>>>>> Modularization JEP 257: Update JavaFX/Media to Newer >>>>>>>> Version of GStreamer >>>>>>>> >>>>>>>> Related to Jigasw, we intend to look into new API for >>>>>>>> heavily used internal methods / classes since they >>>>>>>> will no longer be accessible otherwise. We also plan >>>>>>>> to update WebKit at least one more time, and will >>>>>>>> likely do a few RFEs such as better Hi-DPI support >>>>>>>> (with API control) on Mac, Windows, Linux. >>>>>>>> >>>>>>>> We don't currently plan any other big features for 9, >>>>>>>> but will consider additional RFEs if they are >>>>>>>> important to enough developers and if they fit into >>>>>>>> the time frame. >>>>>>>> >>>>>>>> -- Kevin >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Felix Bembrick wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> Anyone got anything or is there a link somewhere >>>>>>>>> that talks about these? >>>>>>>>> >>>>>>>>> On 15 June 2015 at 22:00, Felix Bembrick >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> I realise we are a long way off JDK 9 still and >>>>>>>>>> with crucial features such as Jigsaw still a >>>>>>>>>> little up in the air but is it possible someone >>>>>>>>>> could itemise the most likely new features, >>>>>>>>>> enhancements and bug fixes that we will see in >>>>>>>>>> JavaFX when JDK 9 is released? >>>>>>>>>> >>>>>>>>>> Of course it's purely speculation at this point >>>>>>>>>> but it would assist me greatly to have some of >>>>>>>>>> idea of where JavaFX is heading and which areas >>>>>>>>>> are seen as most important. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> Felix >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >> -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVka5MAAoJEHb1CzgxXKwYbKwP/RFa3NjMnXWFc6o5EzIFYlh3 5ExLUgu+IVWr1fewrf+KTcR9WmyXWN2ju8zkRb7nhjSiA+5XAf3vbvUBGTaaa1A4 92Fd0W2Mfj8M9F3Px5QP1TMS1BO7GrO12zsB+obmBvWA/xWy0GEoctja8ohT5aNf hs7foi4pZRK6abMvxd94WdSNh/KhzqNvllD3tIkqlasTOOH1i7bEreQ9sxN6+DRF JB87JSRuml7rYEgsOSx5Z2EE7YdgqYjdfHSAIwBvqkRDQZuOp8RrWzU6wFyyzhlm RtuAQJWj1I2DNbZE9iCNJzYqajnp0OellbxGr9SrJaVPpqNjjbw6zoGZ3bhgCAow BAZUlllG9UVoKcl1bHDvmB01RG2JP7RtBByS0cbqGQM0/YqtknbNWpl2r5kTVyH1 EZnfkXmXYi/lqgyRBf1/WqlJnuT10ra7oAQytUajZ3cQJNbRwuFycV0yvbGo11xS eaQO2ECgYyubLE8vsnw1L+2U4wLAMXY9Q3Ob1kLq12UEYB8WMoLZ+IAixUUJ6abB reI+epG/Bh27R0fHChkHEgY65TIMRt8RtOXxzs+Nf0VVAC4Lj9378Y8ZEr14RbcZ mO+5TvyqfDhyIP4WevGDF2/tQTvlsAzl7UuiTtD3pWZ+CpN2WeNimBHPN2ZI6lii Mfj0LIA1IawOjtYjlnHz =lXSV -----END PGP SIGNATURE----- From jack at moxley.co.uk Tue Jun 30 07:12:55 2015 From: jack at moxley.co.uk (Jack Moxley) Date: Tue, 30 Jun 2015 08:12:55 +0100 Subject: JavaFX features in JDK 9 In-Reply-To: <5591AE4E.3000409@poczta.onet.pl> References: <4A33E952-B3B0-4C19-9F5E-CBB10EC9E19B@gmail.com> <558EBC40.3020300@oracle.com> <558EED1C.8030005@poczta.onet.pl> <55918EB7.3060807@oracle.com> <5591956C.3080607@poczta.onet.pl> <5591AD59.3040000@oracle.com> <5591AE4E.3000409@poczta.onet.pl> Message-ID: write once, run anywhere Sent from my iPhone > On 29 Jun 2015, at 21:45, Micha? Zegan wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Does it mean platform support for linux won't be implemented now, or > at all? > I usually use windows, but still depend on that support because I > sometimes use linux, so I am interested about that. > > W dniu 2015-06-29 o 22:40, Kevin Rushforth pisze: >> There is public API in 8u40 to support accessibility. Applications >> using standard JavaFX controls can, for example, use the >> accessibleText property to define the text that the screen reader >> will speak or the accessibleHelp property to provide a more >> detailed description. These properties have reasonable defaults, >> but can be overridden by applications. Additionally, if you use the >> "labelFor" property to point to a Control that the Label is >> associated with, the accessibility framework will use that when the >> screen reader is active. >> >> Custom controls can override the queryAccessibleAttribute, >> executeAccessibleAction, and notifyAccessibleAttributeChanged >> methods. >> >> As for platform support, we currently support Windows and Mac >> platforms. We have no plan to make FX accessible on Linux . >> >> -- Kevin >> >> >> Micha? Zegan wrote: I saw it, and it seems promising, but: first, >> there is probably, or I heard it wrong? no public api for making >> accessibility related stuff... Also, I believe there is no linux >> accessibility bridge as opposed to windows and mac. And I do not >> know if I am wrong, or when this is going to be implemented. >> >> W dniu 2015-06-29 o 20:30, Kevin Rushforth pisze: >> >>>>> JavaFX accessibility is already implemented and was delivered >>>>> in JDK 8u40. >>>>> >>>>> -- Kevin >>>>> >>>>> >>>>> Micha? Zegan wrote: What about accessibility work? Work on it >>>>> has been started, but not sure if it is still targetted for >>>>> 9. >>>>> >>>>> W dniu 2015-06-27 o 20:16, Mike pisze: >>>>> >>>>> >>>>>>>> a lot of FULL blown Webrtc support and building >>>>>>>> something in Javafx (like Scene Builder) that Proves >>>>>>>> Webrtc support would be awesome. Ditto to Webgl >>>>>>>> support. >>>>>>>> >>>>>>>> On Sat, Jun 27, 2015 at 8:07 AM, Kevin Rushforth >>>>>>>> >>>>>>> >>>>>>>> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Hi Felix, >>>>>>>>> >>>>>>>>> Sorry for the delay. Most of us were still pretty >>>>>>>>> focused on 8u60, but we are turning our attention to >>>>>>>>> JDK 9 now. >>>>>>>>> >>>>>>>>> The focus for JDK 9 is Jigsaw. The currently planned >>>>>>>>> big features (JEPs) for FX in JDK 9 are these: >>>>>>>>> >>>>>>>>> JEP 253: Prepare JavaFX UI Controls & CSS APIs for >>>>>>>>> Modularization JEP 257: Update JavaFX/Media to Newer >>>>>>>>> Version of GStreamer >>>>>>>>> >>>>>>>>> Related to Jigasw, we intend to look into new API for >>>>>>>>> heavily used internal methods / classes since they >>>>>>>>> will no longer be accessible otherwise. We also plan >>>>>>>>> to update WebKit at least one more time, and will >>>>>>>>> likely do a few RFEs such as better Hi-DPI support >>>>>>>>> (with API control) on Mac, Windows, Linux. >>>>>>>>> >>>>>>>>> We don't currently plan any other big features for 9, >>>>>>>>> but will consider additional RFEs if they are >>>>>>>>> important to enough developers and if they fit into >>>>>>>>> the time frame. >>>>>>>>> >>>>>>>>> -- Kevin >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Felix Bembrick wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> Anyone got anything or is there a link somewhere >>>>>>>>>> that talks about these? >>>>>>>>>> >>>>>>>>>> On 15 June 2015 at 22:00, Felix Bembrick >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> I realise we are a long way off JDK 9 still and >>>>>>>>>>> with crucial features such as Jigsaw still a >>>>>>>>>>> little up in the air but is it possible someone >>>>>>>>>>> could itemise the most likely new features, >>>>>>>>>>> enhancements and bug fixes that we will see in >>>>>>>>>>> JavaFX when JDK 9 is released? >>>>>>>>>>> >>>>>>>>>>> Of course it's purely speculation at this point >>>>>>>>>>> but it would assist me greatly to have some of >>>>>>>>>>> idea of where JavaFX is heading and which areas >>>>>>>>>>> are seen as most important. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> >>>>>>>>>>> Felix > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > > iQIcBAEBAgAGBQJVka5MAAoJEHb1CzgxXKwYbKwP/RFa3NjMnXWFc6o5EzIFYlh3 > 5ExLUgu+IVWr1fewrf+KTcR9WmyXWN2ju8zkRb7nhjSiA+5XAf3vbvUBGTaaa1A4 > 92Fd0W2Mfj8M9F3Px5QP1TMS1BO7GrO12zsB+obmBvWA/xWy0GEoctja8ohT5aNf > hs7foi4pZRK6abMvxd94WdSNh/KhzqNvllD3tIkqlasTOOH1i7bEreQ9sxN6+DRF > JB87JSRuml7rYEgsOSx5Z2EE7YdgqYjdfHSAIwBvqkRDQZuOp8RrWzU6wFyyzhlm > RtuAQJWj1I2DNbZE9iCNJzYqajnp0OellbxGr9SrJaVPpqNjjbw6zoGZ3bhgCAow > BAZUlllG9UVoKcl1bHDvmB01RG2JP7RtBByS0cbqGQM0/YqtknbNWpl2r5kTVyH1 > EZnfkXmXYi/lqgyRBf1/WqlJnuT10ra7oAQytUajZ3cQJNbRwuFycV0yvbGo11xS > eaQO2ECgYyubLE8vsnw1L+2U4wLAMXY9Q3Ob1kLq12UEYB8WMoLZ+IAixUUJ6abB > reI+epG/Bh27R0fHChkHEgY65TIMRt8RtOXxzs+Nf0VVAC4Lj9378Y8ZEr14RbcZ > mO+5TvyqfDhyIP4WevGDF2/tQTvlsAzl7UuiTtD3pWZ+CpN2WeNimBHPN2ZI6lii > Mfj0LIA1IawOjtYjlnHz > =lXSV > -----END PGP SIGNATURE----- From felix.bembrick at gmail.com Tue Jun 30 07:38:18 2015 From: felix.bembrick at gmail.com (Felix Bembrick) Date: Tue, 30 Jun 2015 17:38:18 +1000 Subject: JavaFX features in JDK 9 In-Reply-To: References: <4A33E952-B3B0-4C19-9F5E-CBB10EC9E19B@gmail.com> <558EBC40.3020300@oracle.com> <558EED1C.8030005@poczta.onet.pl> <55918EB7.3060807@oracle.com> <5591956C.3080607@poczta.onet.pl> <5591AD59.3040000@oracle.com> <5591AE4E.3000409@poczta.onet.pl> Message-ID: To be fair Jack, WORA is/was used in reference to the Java language itself; not JavaFX. Felix On 30 June 2015 at 17:12, Jack Moxley wrote: > write once, run anywhere > > Sent from my iPhone > > > On 29 Jun 2015, at 21:45, Micha? Zegan > wrote: > > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > Does it mean platform support for linux won't be implemented now, or > > at all? > > I usually use windows, but still depend on that support because I > > sometimes use linux, so I am interested about that. > > > > W dniu 2015-06-29 o 22:40, Kevin Rushforth pisze: > >> There is public API in 8u40 to support accessibility. Applications > >> using standard JavaFX controls can, for example, use the > >> accessibleText property to define the text that the screen reader > >> will speak or the accessibleHelp property to provide a more > >> detailed description. These properties have reasonable defaults, > >> but can be overridden by applications. Additionally, if you use the > >> "labelFor" property to point to a Control that the Label is > >> associated with, the accessibility framework will use that when the > >> screen reader is active. > >> > >> Custom controls can override the queryAccessibleAttribute, > >> executeAccessibleAction, and notifyAccessibleAttributeChanged > >> methods. > >> > >> As for platform support, we currently support Windows and Mac > >> platforms. We have no plan to make FX accessible on Linux . > >> > >> -- Kevin > >> > >> > >> Micha? Zegan wrote: I saw it, and it seems promising, but: first, > >> there is probably, or I heard it wrong? no public api for making > >> accessibility related stuff... Also, I believe there is no linux > >> accessibility bridge as opposed to windows and mac. And I do not > >> know if I am wrong, or when this is going to be implemented. > >> > >> W dniu 2015-06-29 o 20:30, Kevin Rushforth pisze: > >> > >>>>> JavaFX accessibility is already implemented and was delivered > >>>>> in JDK 8u40. > >>>>> > >>>>> -- Kevin > >>>>> > >>>>> > >>>>> Micha? Zegan wrote: What about accessibility work? Work on it > >>>>> has been started, but not sure if it is still targetted for > >>>>> 9. > >>>>> > >>>>> W dniu 2015-06-27 o 20:16, Mike pisze: > >>>>> > >>>>> > >>>>>>>> a lot of FULL blown Webrtc support and building > >>>>>>>> something in Javafx (like Scene Builder) that Proves > >>>>>>>> Webrtc support would be awesome. Ditto to Webgl > >>>>>>>> support. > >>>>>>>> > >>>>>>>> On Sat, Jun 27, 2015 at 8:07 AM, Kevin Rushforth > >>>>>>>> >>>>>>>> > >>>>>>>> > >>>>>>>>> wrote: > >>>>>>>>> > >>>>>>>>> Hi Felix, > >>>>>>>>> > >>>>>>>>> Sorry for the delay. Most of us were still pretty > >>>>>>>>> focused on 8u60, but we are turning our attention to > >>>>>>>>> JDK 9 now. > >>>>>>>>> > >>>>>>>>> The focus for JDK 9 is Jigsaw. The currently planned > >>>>>>>>> big features (JEPs) for FX in JDK 9 are these: > >>>>>>>>> > >>>>>>>>> JEP 253: Prepare JavaFX UI Controls & CSS APIs for > >>>>>>>>> Modularization JEP 257: Update JavaFX/Media to Newer > >>>>>>>>> Version of GStreamer > >>>>>>>>> > >>>>>>>>> Related to Jigasw, we intend to look into new API for > >>>>>>>>> heavily used internal methods / classes since they > >>>>>>>>> will no longer be accessible otherwise. We also plan > >>>>>>>>> to update WebKit at least one more time, and will > >>>>>>>>> likely do a few RFEs such as better Hi-DPI support > >>>>>>>>> (with API control) on Mac, Windows, Linux. > >>>>>>>>> > >>>>>>>>> We don't currently plan any other big features for 9, > >>>>>>>>> but will consider additional RFEs if they are > >>>>>>>>> important to enough developers and if they fit into > >>>>>>>>> the time frame. > >>>>>>>>> > >>>>>>>>> -- Kevin > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Felix Bembrick wrote: > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> Anyone got anything or is there a link somewhere > >>>>>>>>>> that talks about these? > >>>>>>>>>> > >>>>>>>>>> On 15 June 2015 at 22:00, Felix Bembrick > >>>>>>>>>> wrote: > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>> I realise we are a long way off JDK 9 still and > >>>>>>>>>>> with crucial features such as Jigsaw still a > >>>>>>>>>>> little up in the air but is it possible someone > >>>>>>>>>>> could itemise the most likely new features, > >>>>>>>>>>> enhancements and bug fixes that we will see in > >>>>>>>>>>> JavaFX when JDK 9 is released? > >>>>>>>>>>> > >>>>>>>>>>> Of course it's purely speculation at this point > >>>>>>>>>>> but it would assist me greatly to have some of > >>>>>>>>>>> idea of where JavaFX is heading and which areas > >>>>>>>>>>> are seen as most important. > >>>>>>>>>>> > >>>>>>>>>>> Thanks, > >>>>>>>>>>> > >>>>>>>>>>> Felix > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG v2 > > > > iQIcBAEBAgAGBQJVka5MAAoJEHb1CzgxXKwYbKwP/RFa3NjMnXWFc6o5EzIFYlh3 > > 5ExLUgu+IVWr1fewrf+KTcR9WmyXWN2ju8zkRb7nhjSiA+5XAf3vbvUBGTaaa1A4 > > 92Fd0W2Mfj8M9F3Px5QP1TMS1BO7GrO12zsB+obmBvWA/xWy0GEoctja8ohT5aNf > > hs7foi4pZRK6abMvxd94WdSNh/KhzqNvllD3tIkqlasTOOH1i7bEreQ9sxN6+DRF > > JB87JSRuml7rYEgsOSx5Z2EE7YdgqYjdfHSAIwBvqkRDQZuOp8RrWzU6wFyyzhlm > > RtuAQJWj1I2DNbZE9iCNJzYqajnp0OellbxGr9SrJaVPpqNjjbw6zoGZ3bhgCAow > > BAZUlllG9UVoKcl1bHDvmB01RG2JP7RtBByS0cbqGQM0/YqtknbNWpl2r5kTVyH1 > > EZnfkXmXYi/lqgyRBf1/WqlJnuT10ra7oAQytUajZ3cQJNbRwuFycV0yvbGo11xS > > eaQO2ECgYyubLE8vsnw1L+2U4wLAMXY9Q3Ob1kLq12UEYB8WMoLZ+IAixUUJ6abB > > reI+epG/Bh27R0fHChkHEgY65TIMRt8RtOXxzs+Nf0VVAC4Lj9378Y8ZEr14RbcZ > > mO+5TvyqfDhyIP4WevGDF2/tQTvlsAzl7UuiTtD3pWZ+CpN2WeNimBHPN2ZI6lii > > Mfj0LIA1IawOjtYjlnHz > > =lXSV > > -----END PGP SIGNATURE----- > > From mikegps1 at gmail.com Tue Jun 30 08:13:00 2015 From: mikegps1 at gmail.com (Mike) Date: Tue, 30 Jun 2015 01:13:00 -0700 Subject: JavaFX features in JDK 9 In-Reply-To: References: <4A33E952-B3B0-4C19-9F5E-CBB10EC9E19B@gmail.com> <558EBC40.3020300@oracle.com> <558EED1C.8030005@poczta.onet.pl> <55918EB7.3060807@oracle.com> <5591956C.3080607@poczta.onet.pl> <5591AD59.3040000@oracle.com> <5591AE4E.3000409@poczta.onet.pl> Message-ID: write once, run anywhere This about sums it up! On Tue, Jun 30, 2015 at 12:12 AM, Jack Moxley wrote: > write once, run anywhere > > Sent from my iPhone > > > On 29 Jun 2015, at 21:45, Micha? Zegan > wrote: > > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > Does it mean platform support for linux won't be implemented now, or > > at all? > > I usually use windows, but still depend on that support because I > > sometimes use linux, so I am interested about that. > > > > W dniu 2015-06-29 o 22:40, Kevin Rushforth pisze: > >> There is public API in 8u40 to support accessibility. Applications > >> using standard JavaFX controls can, for example, use the > >> accessibleText property to define the text that the screen reader > >> will speak or the accessibleHelp property to provide a more > >> detailed description. These properties have reasonable defaults, > >> but can be overridden by applications. Additionally, if you use the > >> "labelFor" property to point to a Control that the Label is > >> associated with, the accessibility framework will use that when the > >> screen reader is active. > >> > >> Custom controls can override the queryAccessibleAttribute, > >> executeAccessibleAction, and notifyAccessibleAttributeChanged > >> methods. > >> > >> As for platform support, we currently support Windows and Mac > >> platforms. We have no plan to make FX accessible on Linux . > >> > >> -- Kevin > >> > >> > >> Micha? Zegan wrote: I saw it, and it seems promising, but: first, > >> there is probably, or I heard it wrong? no public api for making > >> accessibility related stuff... Also, I believe there is no linux > >> accessibility bridge as opposed to windows and mac. And I do not > >> know if I am wrong, or when this is going to be implemented. > >> > >> W dniu 2015-06-29 o 20:30, Kevin Rushforth pisze: > >> > >>>>> JavaFX accessibility is already implemented and was delivered > >>>>> in JDK 8u40. > >>>>> > >>>>> -- Kevin > >>>>> > >>>>> > >>>>> Micha? Zegan wrote: What about accessibility work? Work on it > >>>>> has been started, but not sure if it is still targetted for > >>>>> 9. > >>>>> > >>>>> W dniu 2015-06-27 o 20:16, Mike pisze: > >>>>> > >>>>> > >>>>>>>> a lot of FULL blown Webrtc support and building > >>>>>>>> something in Javafx (like Scene Builder) that Proves > >>>>>>>> Webrtc support would be awesome. Ditto to Webgl > >>>>>>>> support. > >>>>>>>> > >>>>>>>> On Sat, Jun 27, 2015 at 8:07 AM, Kevin Rushforth > >>>>>>>> >>>>>>>> > >>>>>>>> > >>>>>>>>> wrote: > >>>>>>>>> > >>>>>>>>> Hi Felix, > >>>>>>>>> > >>>>>>>>> Sorry for the delay. Most of us were still pretty > >>>>>>>>> focused on 8u60, but we are turning our attention to > >>>>>>>>> JDK 9 now. > >>>>>>>>> > >>>>>>>>> The focus for JDK 9 is Jigsaw. The currently planned > >>>>>>>>> big features (JEPs) for FX in JDK 9 are these: > >>>>>>>>> > >>>>>>>>> JEP 253: Prepare JavaFX UI Controls & CSS APIs for > >>>>>>>>> Modularization JEP 257: Update JavaFX/Media to Newer > >>>>>>>>> Version of GStreamer > >>>>>>>>> > >>>>>>>>> Related to Jigasw, we intend to look into new API for > >>>>>>>>> heavily used internal methods / classes since they > >>>>>>>>> will no longer be accessible otherwise. We also plan > >>>>>>>>> to update WebKit at least one more time, and will > >>>>>>>>> likely do a few RFEs such as better Hi-DPI support > >>>>>>>>> (with API control) on Mac, Windows, Linux. > >>>>>>>>> > >>>>>>>>> We don't currently plan any other big features for 9, > >>>>>>>>> but will consider additional RFEs if they are > >>>>>>>>> important to enough developers and if they fit into > >>>>>>>>> the time frame. > >>>>>>>>> > >>>>>>>>> -- Kevin > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Felix Bembrick wrote: > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> Anyone got anything or is there a link somewhere > >>>>>>>>>> that talks about these? > >>>>>>>>>> > >>>>>>>>>> On 15 June 2015 at 22:00, Felix Bembrick > >>>>>>>>>> wrote: > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>> I realise we are a long way off JDK 9 still and > >>>>>>>>>>> with crucial features such as Jigsaw still a > >>>>>>>>>>> little up in the air but is it possible someone > >>>>>>>>>>> could itemise the most likely new features, > >>>>>>>>>>> enhancements and bug fixes that we will see in > >>>>>>>>>>> JavaFX when JDK 9 is released? > >>>>>>>>>>> > >>>>>>>>>>> Of course it's purely speculation at this point > >>>>>>>>>>> but it would assist me greatly to have some of > >>>>>>>>>>> idea of where JavaFX is heading and which areas > >>>>>>>>>>> are seen as most important. > >>>>>>>>>>> > >>>>>>>>>>> Thanks, > >>>>>>>>>>> > >>>>>>>>>>> Felix > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG v2 > > > > iQIcBAEBAgAGBQJVka5MAAoJEHb1CzgxXKwYbKwP/RFa3NjMnXWFc6o5EzIFYlh3 > > 5ExLUgu+IVWr1fewrf+KTcR9WmyXWN2ju8zkRb7nhjSiA+5XAf3vbvUBGTaaa1A4 > > 92Fd0W2Mfj8M9F3Px5QP1TMS1BO7GrO12zsB+obmBvWA/xWy0GEoctja8ohT5aNf > > hs7foi4pZRK6abMvxd94WdSNh/KhzqNvllD3tIkqlasTOOH1i7bEreQ9sxN6+DRF > > JB87JSRuml7rYEgsOSx5Z2EE7YdgqYjdfHSAIwBvqkRDQZuOp8RrWzU6wFyyzhlm > > RtuAQJWj1I2DNbZE9iCNJzYqajnp0OellbxGr9SrJaVPpqNjjbw6zoGZ3bhgCAow > > BAZUlllG9UVoKcl1bHDvmB01RG2JP7RtBByS0cbqGQM0/YqtknbNWpl2r5kTVyH1 > > EZnfkXmXYi/lqgyRBf1/WqlJnuT10ra7oAQytUajZ3cQJNbRwuFycV0yvbGo11xS > > eaQO2ECgYyubLE8vsnw1L+2U4wLAMXY9Q3Ob1kLq12UEYB8WMoLZ+IAixUUJ6abB > > reI+epG/Bh27R0fHChkHEgY65TIMRt8RtOXxzs+Nf0VVAC4Lj9378Y8ZEr14RbcZ > > mO+5TvyqfDhyIP4WevGDF2/tQTvlsAzl7UuiTtD3pWZ+CpN2WeNimBHPN2ZI6lii > > Mfj0LIA1IawOjtYjlnHz > > =lXSV > > -----END PGP SIGNATURE----- > > From felix.bembrick at gmail.com Tue Jun 30 08:42:52 2015 From: felix.bembrick at gmail.com (Felix Bembrick) Date: Tue, 30 Jun 2015 18:42:52 +1000 Subject: JavaFX features in JDK 9 In-Reply-To: References: <4A33E952-B3B0-4C19-9F5E-CBB10EC9E19B@gmail.com> <558EBC40.3020300@oracle.com> <558EED1C.8030005@poczta.onet.pl> <55918EB7.3060807@oracle.com> <5591956C.3080607@poczta.onet.pl> <5591AD59.3040000@oracle.com> <5591AE4E.3000409@poczta.onet.pl> Message-ID: <3BECEB07-DEA7-480C-82C9-BF957E7EFD50@gmail.com> JavaFX has *never* claimed to be write once, run anyway > On 30 Jun 2015, at 18:13, Mike wrote: > > write once, run anywhere > > This about sums it up! > > > >> On Tue, Jun 30, 2015 at 12:12 AM, Jack Moxley wrote: >> >> write once, run anywhere >> >> Sent from my iPhone >> >>>> On 29 Jun 2015, at 21:45, Micha? Zegan >>> wrote: >>> >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> Does it mean platform support for linux won't be implemented now, or >>> at all? >>> I usually use windows, but still depend on that support because I >>> sometimes use linux, so I am interested about that. >>> >>> W dniu 2015-06-29 o 22:40, Kevin Rushforth pisze: >>>> There is public API in 8u40 to support accessibility. Applications >>>> using standard JavaFX controls can, for example, use the >>>> accessibleText property to define the text that the screen reader >>>> will speak or the accessibleHelp property to provide a more >>>> detailed description. These properties have reasonable defaults, >>>> but can be overridden by applications. Additionally, if you use the >>>> "labelFor" property to point to a Control that the Label is >>>> associated with, the accessibility framework will use that when the >>>> screen reader is active. >>>> >>>> Custom controls can override the queryAccessibleAttribute, >>>> executeAccessibleAction, and notifyAccessibleAttributeChanged >>>> methods. >>>> >>>> As for platform support, we currently support Windows and Mac >>>> platforms. We have no plan to make FX accessible on Linux . >>>> >>>> -- Kevin >>>> >>>> >>>> Micha? Zegan wrote: I saw it, and it seems promising, but: first, >>>> there is probably, or I heard it wrong? no public api for making >>>> accessibility related stuff... Also, I believe there is no linux >>>> accessibility bridge as opposed to windows and mac. And I do not >>>> know if I am wrong, or when this is going to be implemented. >>>> >>>> W dniu 2015-06-29 o 20:30, Kevin Rushforth pisze: >>>> >>>>>>> JavaFX accessibility is already implemented and was delivered >>>>>>> in JDK 8u40. >>>>>>> >>>>>>> -- Kevin >>>>>>> >>>>>>> >>>>>>> Micha? Zegan wrote: What about accessibility work? Work on it >>>>>>> has been started, but not sure if it is still targetted for >>>>>>> 9. >>>>>>> >>>>>>> W dniu 2015-06-27 o 20:16, Mike pisze: >>>>>>> >>>>>>> >>>>>>>>>> a lot of FULL blown Webrtc support and building >>>>>>>>>> something in Javafx (like Scene Builder) that Proves >>>>>>>>>> Webrtc support would be awesome. Ditto to Webgl >>>>>>>>>> support. >>>>>>>>>> >>>>>>>>>> On Sat, Jun 27, 2015 at 8:07 AM, Kevin Rushforth >>>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> Hi Felix, >>>>>>>>>>> >>>>>>>>>>> Sorry for the delay. Most of us were still pretty >>>>>>>>>>> focused on 8u60, but we are turning our attention to >>>>>>>>>>> JDK 9 now. >>>>>>>>>>> >>>>>>>>>>> The focus for JDK 9 is Jigsaw. The currently planned >>>>>>>>>>> big features (JEPs) for FX in JDK 9 are these: >>>>>>>>>>> >>>>>>>>>>> JEP 253: Prepare JavaFX UI Controls & CSS APIs for >>>>>>>>>>> Modularization JEP 257: Update JavaFX/Media to Newer >>>>>>>>>>> Version of GStreamer >>>>>>>>>>> >>>>>>>>>>> Related to Jigasw, we intend to look into new API for >>>>>>>>>>> heavily used internal methods / classes since they >>>>>>>>>>> will no longer be accessible otherwise. We also plan >>>>>>>>>>> to update WebKit at least one more time, and will >>>>>>>>>>> likely do a few RFEs such as better Hi-DPI support >>>>>>>>>>> (with API control) on Mac, Windows, Linux. >>>>>>>>>>> >>>>>>>>>>> We don't currently plan any other big features for 9, >>>>>>>>>>> but will consider additional RFEs if they are >>>>>>>>>>> important to enough developers and if they fit into >>>>>>>>>>> the time frame. >>>>>>>>>>> >>>>>>>>>>> -- Kevin >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Felix Bembrick wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Anyone got anything or is there a link somewhere >>>>>>>>>>>> that talks about these? >>>>>>>>>>>> >>>>>>>>>>>> On 15 June 2015 at 22:00, Felix Bembrick >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> I realise we are a long way off JDK 9 still and >>>>>>>>>>>>> with crucial features such as Jigsaw still a >>>>>>>>>>>>> little up in the air but is it possible someone >>>>>>>>>>>>> could itemise the most likely new features, >>>>>>>>>>>>> enhancements and bug fixes that we will see in >>>>>>>>>>>>> JavaFX when JDK 9 is released? >>>>>>>>>>>>> >>>>>>>>>>>>> Of course it's purely speculation at this point >>>>>>>>>>>>> but it would assist me greatly to have some of >>>>>>>>>>>>> idea of where JavaFX is heading and which areas >>>>>>>>>>>>> are seen as most important. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> >>>>>>>>>>>>> Felix >>> -----BEGIN PGP SIGNATURE----- >>> Version: GnuPG v2 >>> >>> iQIcBAEBAgAGBQJVka5MAAoJEHb1CzgxXKwYbKwP/RFa3NjMnXWFc6o5EzIFYlh3 >>> 5ExLUgu+IVWr1fewrf+KTcR9WmyXWN2ju8zkRb7nhjSiA+5XAf3vbvUBGTaaa1A4 >>> 92Fd0W2Mfj8M9F3Px5QP1TMS1BO7GrO12zsB+obmBvWA/xWy0GEoctja8ohT5aNf >>> hs7foi4pZRK6abMvxd94WdSNh/KhzqNvllD3tIkqlasTOOH1i7bEreQ9sxN6+DRF >>> JB87JSRuml7rYEgsOSx5Z2EE7YdgqYjdfHSAIwBvqkRDQZuOp8RrWzU6wFyyzhlm >>> RtuAQJWj1I2DNbZE9iCNJzYqajnp0OellbxGr9SrJaVPpqNjjbw6zoGZ3bhgCAow >>> BAZUlllG9UVoKcl1bHDvmB01RG2JP7RtBByS0cbqGQM0/YqtknbNWpl2r5kTVyH1 >>> EZnfkXmXYi/lqgyRBf1/WqlJnuT10ra7oAQytUajZ3cQJNbRwuFycV0yvbGo11xS >>> eaQO2ECgYyubLE8vsnw1L+2U4wLAMXY9Q3Ob1kLq12UEYB8WMoLZ+IAixUUJ6abB >>> reI+epG/Bh27R0fHChkHEgY65TIMRt8RtOXxzs+Nf0VVAC4Lj9378Y8ZEr14RbcZ >>> mO+5TvyqfDhyIP4WevGDF2/tQTvlsAzl7UuiTtD3pWZ+CpN2WeNimBHPN2ZI6lii >>> Mfj0LIA1IawOjtYjlnHz >>> =lXSV >>> -----END PGP SIGNATURE----- >> >> From jack at moxley.co.uk Tue Jun 30 11:13:07 2015 From: jack at moxley.co.uk (Jack Moxley) Date: Tue, 30 Jun 2015 12:13:07 +0100 Subject: JavaFX features in JDK 9 In-Reply-To: <3BECEB07-DEA7-480C-82C9-BF957E7EFD50@gmail.com> References: <4A33E952-B3B0-4C19-9F5E-CBB10EC9E19B@gmail.com> <558EBC40.3020300@oracle.com> <558EED1C.8030005@poczta.onet.pl> <55918EB7.3060807@oracle.com> <5591956C.3080607@poczta.onet.pl> <5591AD59.3040000@oracle.com> <5591AE4E.3000409@poczta.onet.pl> <3BECEB07-DEA7-480C-82C9-BF957E7EFD50@gmail.com> Message-ID: <6D4A8ED9-A096-4E1E-9516-9BC48AC69C8D@moxley.co.uk> Maybe it should its aspirations a little higher, especially with the advent of unity, webgl or even scenegraph impls such as jmonkeyengine that do. Sent from my iPhone > On 30 Jun 2015, at 09:42, Felix Bembrick wrote: > > JavaFX has *never* claimed to be write once, run anyway > > >> On 30 Jun 2015, at 18:13, Mike wrote: >> >> write once, run anywhere >> >> This about sums it up! >> >> >> >>> On Tue, Jun 30, 2015 at 12:12 AM, Jack Moxley wrote: >>> >>> write once, run anywhere >>> >>> Sent from my iPhone >>> >>>>> On 29 Jun 2015, at 21:45, Micha? Zegan >>>> wrote: >>>> >>>> -----BEGIN PGP SIGNED MESSAGE----- >>>> Hash: SHA1 >>>> >>>> Does it mean platform support for linux won't be implemented now, or >>>> at all? >>>> I usually use windows, but still depend on that support because I >>>> sometimes use linux, so I am interested about that. >>>> >>>> W dniu 2015-06-29 o 22:40, Kevin Rushforth pisze: >>>>> There is public API in 8u40 to support accessibility. Applications >>>>> using standard JavaFX controls can, for example, use the >>>>> accessibleText property to define the text that the screen reader >>>>> will speak or the accessibleHelp property to provide a more >>>>> detailed description. These properties have reasonable defaults, >>>>> but can be overridden by applications. Additionally, if you use the >>>>> "labelFor" property to point to a Control that the Label is >>>>> associated with, the accessibility framework will use that when the >>>>> screen reader is active. >>>>> >>>>> Custom controls can override the queryAccessibleAttribute, >>>>> executeAccessibleAction, and notifyAccessibleAttributeChanged >>>>> methods. >>>>> >>>>> As for platform support, we currently support Windows and Mac >>>>> platforms. We have no plan to make FX accessible on Linux . >>>>> >>>>> -- Kevin >>>>> >>>>> >>>>> Micha? Zegan wrote: I saw it, and it seems promising, but: first, >>>>> there is probably, or I heard it wrong? no public api for making >>>>> accessibility related stuff... Also, I believe there is no linux >>>>> accessibility bridge as opposed to windows and mac. And I do not >>>>> know if I am wrong, or when this is going to be implemented. >>>>> >>>>> W dniu 2015-06-29 o 20:30, Kevin Rushforth pisze: >>>>> >>>>>>>> JavaFX accessibility is already implemented and was delivered >>>>>>>> in JDK 8u40. >>>>>>>> >>>>>>>> -- Kevin >>>>>>>> >>>>>>>> >>>>>>>> Micha? Zegan wrote: What about accessibility work? Work on it >>>>>>>> has been started, but not sure if it is still targetted for >>>>>>>> 9. >>>>>>>> >>>>>>>> W dniu 2015-06-27 o 20:16, Mike pisze: >>>>>>>> >>>>>>>> >>>>>>>>>>> a lot of FULL blown Webrtc support and building >>>>>>>>>>> something in Javafx (like Scene Builder) that Proves >>>>>>>>>>> Webrtc support would be awesome. Ditto to Webgl >>>>>>>>>>> support. >>>>>>>>>>> >>>>>>>>>>> On Sat, Jun 27, 2015 at 8:07 AM, Kevin Rushforth >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> Hi Felix, >>>>>>>>>>>> >>>>>>>>>>>> Sorry for the delay. Most of us were still pretty >>>>>>>>>>>> focused on 8u60, but we are turning our attention to >>>>>>>>>>>> JDK 9 now. >>>>>>>>>>>> >>>>>>>>>>>> The focus for JDK 9 is Jigsaw. The currently planned >>>>>>>>>>>> big features (JEPs) for FX in JDK 9 are these: >>>>>>>>>>>> >>>>>>>>>>>> JEP 253: Prepare JavaFX UI Controls & CSS APIs for >>>>>>>>>>>> Modularization JEP 257: Update JavaFX/Media to Newer >>>>>>>>>>>> Version of GStreamer >>>>>>>>>>>> >>>>>>>>>>>> Related to Jigasw, we intend to look into new API for >>>>>>>>>>>> heavily used internal methods / classes since they >>>>>>>>>>>> will no longer be accessible otherwise. We also plan >>>>>>>>>>>> to update WebKit at least one more time, and will >>>>>>>>>>>> likely do a few RFEs such as better Hi-DPI support >>>>>>>>>>>> (with API control) on Mac, Windows, Linux. >>>>>>>>>>>> >>>>>>>>>>>> We don't currently plan any other big features for 9, >>>>>>>>>>>> but will consider additional RFEs if they are >>>>>>>>>>>> important to enough developers and if they fit into >>>>>>>>>>>> the time frame. >>>>>>>>>>>> >>>>>>>>>>>> -- Kevin >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Felix Bembrick wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> Anyone got anything or is there a link somewhere >>>>>>>>>>>>> that talks about these? >>>>>>>>>>>>> >>>>>>>>>>>>> On 15 June 2015 at 22:00, Felix Bembrick >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> I realise we are a long way off JDK 9 still and >>>>>>>>>>>>>> with crucial features such as Jigsaw still a >>>>>>>>>>>>>> little up in the air but is it possible someone >>>>>>>>>>>>>> could itemise the most likely new features, >>>>>>>>>>>>>> enhancements and bug fixes that we will see in >>>>>>>>>>>>>> JavaFX when JDK 9 is released? >>>>>>>>>>>>>> >>>>>>>>>>>>>> Of course it's purely speculation at this point >>>>>>>>>>>>>> but it would assist me greatly to have some of >>>>>>>>>>>>>> idea of where JavaFX is heading and which areas >>>>>>>>>>>>>> are seen as most important. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Felix >>>> -----BEGIN PGP SIGNATURE----- >>>> Version: GnuPG v2 >>>> >>>> iQIcBAEBAgAGBQJVka5MAAoJEHb1CzgxXKwYbKwP/RFa3NjMnXWFc6o5EzIFYlh3 >>>> 5ExLUgu+IVWr1fewrf+KTcR9WmyXWN2ju8zkRb7nhjSiA+5XAf3vbvUBGTaaa1A4 >>>> 92Fd0W2Mfj8M9F3Px5QP1TMS1BO7GrO12zsB+obmBvWA/xWy0GEoctja8ohT5aNf >>>> hs7foi4pZRK6abMvxd94WdSNh/KhzqNvllD3tIkqlasTOOH1i7bEreQ9sxN6+DRF >>>> JB87JSRuml7rYEgsOSx5Z2EE7YdgqYjdfHSAIwBvqkRDQZuOp8RrWzU6wFyyzhlm >>>> RtuAQJWj1I2DNbZE9iCNJzYqajnp0OellbxGr9SrJaVPpqNjjbw6zoGZ3bhgCAow >>>> BAZUlllG9UVoKcl1bHDvmB01RG2JP7RtBByS0cbqGQM0/YqtknbNWpl2r5kTVyH1 >>>> EZnfkXmXYi/lqgyRBf1/WqlJnuT10ra7oAQytUajZ3cQJNbRwuFycV0yvbGo11xS >>>> eaQO2ECgYyubLE8vsnw1L+2U4wLAMXY9Q3Ob1kLq12UEYB8WMoLZ+IAixUUJ6abB >>>> reI+epG/Bh27R0fHChkHEgY65TIMRt8RtOXxzs+Nf0VVAC4Lj9378Y8ZEr14RbcZ >>>> mO+5TvyqfDhyIP4WevGDF2/tQTvlsAzl7UuiTtD3pWZ+CpN2WeNimBHPN2ZI6lii >>>> Mfj0LIA1IawOjtYjlnHz >>>> =lXSV >>>> -----END PGP SIGNATURE----- >>> >>> From felix.bembrick at gmail.com Tue Jun 30 11:16:00 2015 From: felix.bembrick at gmail.com (Felix Bembrick) Date: Tue, 30 Jun 2015 21:16:00 +1000 Subject: JavaFX features in JDK 9 In-Reply-To: <6D4A8ED9-A096-4E1E-9516-9BC48AC69C8D@moxley.co.uk> References: <4A33E952-B3B0-4C19-9F5E-CBB10EC9E19B@gmail.com> <558EBC40.3020300@oracle.com> <558EED1C.8030005@poczta.onet.pl> <55918EB7.3060807@oracle.com> <5591956C.3080607@poczta.onet.pl> <5591AD59.3040000@oracle.com> <5591AE4E.3000409@poczta.onet.pl> <3BECEB07-DEA7-480C-82C9-BF957E7EFD50@gmail.com> <6D4A8ED9-A096-4E1E-9516-9BC48AC69C8D@moxley.co.uk> Message-ID: <20230153-DC3C-4A7D-8885-B494B2984594@gmail.com> Well, we are all at the whim of Oracle executives decisions with the added help of third parties such as Gluon and RoboVM. The future of JavaFX really is in *our* hands. > On 30 Jun 2015, at 21:13, Jack Moxley wrote: > > Maybe it should its aspirations a little higher, especially with the advent of unity, webgl or even scenegraph impls such as jmonkeyengine that do. > > Sent from my iPhone > >> On 30 Jun 2015, at 09:42, Felix Bembrick wrote: >> >> JavaFX has *never* claimed to be write once, run anyway >> >> >>> On 30 Jun 2015, at 18:13, Mike wrote: >>> >>> write once, run anywhere >>> >>> This about sums it up! >>> >>> >>> >>>> On Tue, Jun 30, 2015 at 12:12 AM, Jack Moxley wrote: >>>> >>>> write once, run anywhere >>>> >>>> Sent from my iPhone >>>> >>>>>> On 29 Jun 2015, at 21:45, Micha? Zegan >>>>> wrote: >>>>> >>>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>> Hash: SHA1 >>>>> >>>>> Does it mean platform support for linux won't be implemented now, or >>>>> at all? >>>>> I usually use windows, but still depend on that support because I >>>>> sometimes use linux, so I am interested about that. >>>>> >>>>> W dniu 2015-06-29 o 22:40, Kevin Rushforth pisze: >>>>>> There is public API in 8u40 to support accessibility. Applications >>>>>> using standard JavaFX controls can, for example, use the >>>>>> accessibleText property to define the text that the screen reader >>>>>> will speak or the accessibleHelp property to provide a more >>>>>> detailed description. These properties have reasonable defaults, >>>>>> but can be overridden by applications. Additionally, if you use the >>>>>> "labelFor" property to point to a Control that the Label is >>>>>> associated with, the accessibility framework will use that when the >>>>>> screen reader is active. >>>>>> >>>>>> Custom controls can override the queryAccessibleAttribute, >>>>>> executeAccessibleAction, and notifyAccessibleAttributeChanged >>>>>> methods. >>>>>> >>>>>> As for platform support, we currently support Windows and Mac >>>>>> platforms. We have no plan to make FX accessible on Linux . >>>>>> >>>>>> -- Kevin >>>>>> >>>>>> >>>>>> Micha? Zegan wrote: I saw it, and it seems promising, but: first, >>>>>> there is probably, or I heard it wrong? no public api for making >>>>>> accessibility related stuff... Also, I believe there is no linux >>>>>> accessibility bridge as opposed to windows and mac. And I do not >>>>>> know if I am wrong, or when this is going to be implemented. >>>>>> >>>>>> W dniu 2015-06-29 o 20:30, Kevin Rushforth pisze: >>>>>> >>>>>>>>> JavaFX accessibility is already implemented and was delivered >>>>>>>>> in JDK 8u40. >>>>>>>>> >>>>>>>>> -- Kevin >>>>>>>>> >>>>>>>>> >>>>>>>>> Micha? Zegan wrote: What about accessibility work? Work on it >>>>>>>>> has been started, but not sure if it is still targetted for >>>>>>>>> 9. >>>>>>>>> >>>>>>>>> W dniu 2015-06-27 o 20:16, Mike pisze: >>>>>>>>> >>>>>>>>> >>>>>>>>>>>> a lot of FULL blown Webrtc support and building >>>>>>>>>>>> something in Javafx (like Scene Builder) that Proves >>>>>>>>>>>> Webrtc support would be awesome. Ditto to Webgl >>>>>>>>>>>> support. >>>>>>>>>>>> >>>>>>>>>>>> On Sat, Jun 27, 2015 at 8:07 AM, Kevin Rushforth >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> Hi Felix, >>>>>>>>>>>>> >>>>>>>>>>>>> Sorry for the delay. Most of us were still pretty >>>>>>>>>>>>> focused on 8u60, but we are turning our attention to >>>>>>>>>>>>> JDK 9 now. >>>>>>>>>>>>> >>>>>>>>>>>>> The focus for JDK 9 is Jigsaw. The currently planned >>>>>>>>>>>>> big features (JEPs) for FX in JDK 9 are these: >>>>>>>>>>>>> >>>>>>>>>>>>> JEP 253: Prepare JavaFX UI Controls & CSS APIs for >>>>>>>>>>>>> Modularization JEP 257: Update JavaFX/Media to Newer >>>>>>>>>>>>> Version of GStreamer >>>>>>>>>>>>> >>>>>>>>>>>>> Related to Jigasw, we intend to look into new API for >>>>>>>>>>>>> heavily used internal methods / classes since they >>>>>>>>>>>>> will no longer be accessible otherwise. We also plan >>>>>>>>>>>>> to update WebKit at least one more time, and will >>>>>>>>>>>>> likely do a few RFEs such as better Hi-DPI support >>>>>>>>>>>>> (with API control) on Mac, Windows, Linux. >>>>>>>>>>>>> >>>>>>>>>>>>> We don't currently plan any other big features for 9, >>>>>>>>>>>>> but will consider additional RFEs if they are >>>>>>>>>>>>> important to enough developers and if they fit into >>>>>>>>>>>>> the time frame. >>>>>>>>>>>>> >>>>>>>>>>>>> -- Kevin >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Felix Bembrick wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> Anyone got anything or is there a link somewhere >>>>>>>>>>>>>> that talks about these? >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 15 June 2015 at 22:00, Felix Bembrick >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> I realise we are a long way off JDK 9 still and >>>>>>>>>>>>>>> with crucial features such as Jigsaw still a >>>>>>>>>>>>>>> little up in the air but is it possible someone >>>>>>>>>>>>>>> could itemise the most likely new features, >>>>>>>>>>>>>>> enhancements and bug fixes that we will see in >>>>>>>>>>>>>>> JavaFX when JDK 9 is released? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Of course it's purely speculation at this point >>>>>>>>>>>>>>> but it would assist me greatly to have some of >>>>>>>>>>>>>>> idea of where JavaFX is heading and which areas >>>>>>>>>>>>>>> are seen as most important. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Felix >>>>> -----BEGIN PGP SIGNATURE----- >>>>> Version: GnuPG v2 >>>>> >>>>> iQIcBAEBAgAGBQJVka5MAAoJEHb1CzgxXKwYbKwP/RFa3NjMnXWFc6o5EzIFYlh3 >>>>> 5ExLUgu+IVWr1fewrf+KTcR9WmyXWN2ju8zkRb7nhjSiA+5XAf3vbvUBGTaaa1A4 >>>>> 92Fd0W2Mfj8M9F3Px5QP1TMS1BO7GrO12zsB+obmBvWA/xWy0GEoctja8ohT5aNf >>>>> hs7foi4pZRK6abMvxd94WdSNh/KhzqNvllD3tIkqlasTOOH1i7bEreQ9sxN6+DRF >>>>> JB87JSRuml7rYEgsOSx5Z2EE7YdgqYjdfHSAIwBvqkRDQZuOp8RrWzU6wFyyzhlm >>>>> RtuAQJWj1I2DNbZE9iCNJzYqajnp0OellbxGr9SrJaVPpqNjjbw6zoGZ3bhgCAow >>>>> BAZUlllG9UVoKcl1bHDvmB01RG2JP7RtBByS0cbqGQM0/YqtknbNWpl2r5kTVyH1 >>>>> EZnfkXmXYi/lqgyRBf1/WqlJnuT10ra7oAQytUajZ3cQJNbRwuFycV0yvbGo11xS >>>>> eaQO2ECgYyubLE8vsnw1L+2U4wLAMXY9Q3Ob1kLq12UEYB8WMoLZ+IAixUUJ6abB >>>>> reI+epG/Bh27R0fHChkHEgY65TIMRt8RtOXxzs+Nf0VVAC4Lj9378Y8ZEr14RbcZ >>>>> mO+5TvyqfDhyIP4WevGDF2/tQTvlsAzl7UuiTtD3pWZ+CpN2WeNimBHPN2ZI6lii >>>>> Mfj0LIA1IawOjtYjlnHz >>>>> =lXSV >>>>> -----END PGP SIGNATURE----- > From jack at moxley.co.uk Tue Jun 30 11:16:45 2015 From: jack at moxley.co.uk (Jack Moxley) Date: Tue, 30 Jun 2015 12:16:45 +0100 Subject: JavaFX features in JDK 9 In-Reply-To: <6D4A8ED9-A096-4E1E-9516-9BC48AC69C8D@moxley.co.uk> References: <4A33E952-B3B0-4C19-9F5E-CBB10EC9E19B@gmail.com> <558EBC40.3020300@oracle.com> <558EED1C.8030005@poczta.onet.pl> <55918EB7.3060807@oracle.com> <5591956C.3080607@poczta.onet.pl> <5591AD59.3040000@oracle.com> <5591AE4E.3000409@poczta.onet.pl> <3BECEB07-DEA7-480C-82C9-BF957E7EFD50@gmail.com> <6D4A8ED9-A096-4E1E-9516-9BC48AC69C8D@moxley.co.uk> Message-ID: That should of read 'set its aspirations higher' Sent from my iPhone > On 30 Jun 2015, at 12:13, Jack Moxley wrote: > > Maybe it should its aspirations a little higher, especially with the advent of unity, webgl or even scenegraph impls such as jmonkeyengine that do. > > Sent from my iPhone > >> On 30 Jun 2015, at 09:42, Felix Bembrick wrote: >> >> JavaFX has *never* claimed to be write once, run anyway >> >> >>> On 30 Jun 2015, at 18:13, Mike wrote: >>> >>> write once, run anywhere >>> >>> This about sums it up! >>> >>> >>> >>>> On Tue, Jun 30, 2015 at 12:12 AM, Jack Moxley wrote: >>>> >>>> write once, run anywhere >>>> >>>> Sent from my iPhone >>>> >>>>>> On 29 Jun 2015, at 21:45, Micha? Zegan >>>>> wrote: >>>>> >>>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>> Hash: SHA1 >>>>> >>>>> Does it mean platform support for linux won't be implemented now, or >>>>> at all? >>>>> I usually use windows, but still depend on that support because I >>>>> sometimes use linux, so I am interested about that. >>>>> >>>>> W dniu 2015-06-29 o 22:40, Kevin Rushforth pisze: >>>>>> There is public API in 8u40 to support accessibility. Applications >>>>>> using standard JavaFX controls can, for example, use the >>>>>> accessibleText property to define the text that the screen reader >>>>>> will speak or the accessibleHelp property to provide a more >>>>>> detailed description. These properties have reasonable defaults, >>>>>> but can be overridden by applications. Additionally, if you use the >>>>>> "labelFor" property to point to a Control that the Label is >>>>>> associated with, the accessibility framework will use that when the >>>>>> screen reader is active. >>>>>> >>>>>> Custom controls can override the queryAccessibleAttribute, >>>>>> executeAccessibleAction, and notifyAccessibleAttributeChanged >>>>>> methods. >>>>>> >>>>>> As for platform support, we currently support Windows and Mac >>>>>> platforms. We have no plan to make FX accessible on Linux . >>>>>> >>>>>> -- Kevin >>>>>> >>>>>> >>>>>> Micha? Zegan wrote: I saw it, and it seems promising, but: first, >>>>>> there is probably, or I heard it wrong? no public api for making >>>>>> accessibility related stuff... Also, I believe there is no linux >>>>>> accessibility bridge as opposed to windows and mac. And I do not >>>>>> know if I am wrong, or when this is going to be implemented. >>>>>> >>>>>> W dniu 2015-06-29 o 20:30, Kevin Rushforth pisze: >>>>>> >>>>>>>>> JavaFX accessibility is already implemented and was delivered >>>>>>>>> in JDK 8u40. >>>>>>>>> >>>>>>>>> -- Kevin >>>>>>>>> >>>>>>>>> >>>>>>>>> Micha? Zegan wrote: What about accessibility work? Work on it >>>>>>>>> has been started, but not sure if it is still targetted for >>>>>>>>> 9. >>>>>>>>> >>>>>>>>> W dniu 2015-06-27 o 20:16, Mike pisze: >>>>>>>>> >>>>>>>>> >>>>>>>>>>>> a lot of FULL blown Webrtc support and building >>>>>>>>>>>> something in Javafx (like Scene Builder) that Proves >>>>>>>>>>>> Webrtc support would be awesome. Ditto to Webgl >>>>>>>>>>>> support. >>>>>>>>>>>> >>>>>>>>>>>> On Sat, Jun 27, 2015 at 8:07 AM, Kevin Rushforth >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> Hi Felix, >>>>>>>>>>>>> >>>>>>>>>>>>> Sorry for the delay. Most of us were still pretty >>>>>>>>>>>>> focused on 8u60, but we are turning our attention to >>>>>>>>>>>>> JDK 9 now. >>>>>>>>>>>>> >>>>>>>>>>>>> The focus for JDK 9 is Jigsaw. The currently planned >>>>>>>>>>>>> big features (JEPs) for FX in JDK 9 are these: >>>>>>>>>>>>> >>>>>>>>>>>>> JEP 253: Prepare JavaFX UI Controls & CSS APIs for >>>>>>>>>>>>> Modularization JEP 257: Update JavaFX/Media to Newer >>>>>>>>>>>>> Version of GStreamer >>>>>>>>>>>>> >>>>>>>>>>>>> Related to Jigasw, we intend to look into new API for >>>>>>>>>>>>> heavily used internal methods / classes since they >>>>>>>>>>>>> will no longer be accessible otherwise. We also plan >>>>>>>>>>>>> to update WebKit at least one more time, and will >>>>>>>>>>>>> likely do a few RFEs such as better Hi-DPI support >>>>>>>>>>>>> (with API control) on Mac, Windows, Linux. >>>>>>>>>>>>> >>>>>>>>>>>>> We don't currently plan any other big features for 9, >>>>>>>>>>>>> but will consider additional RFEs if they are >>>>>>>>>>>>> important to enough developers and if they fit into >>>>>>>>>>>>> the time frame. >>>>>>>>>>>>> >>>>>>>>>>>>> -- Kevin >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Felix Bembrick wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> Anyone got anything or is there a link somewhere >>>>>>>>>>>>>> that talks about these? >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 15 June 2015 at 22:00, Felix Bembrick >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> I realise we are a long way off JDK 9 still and >>>>>>>>>>>>>>> with crucial features such as Jigsaw still a >>>>>>>>>>>>>>> little up in the air but is it possible someone >>>>>>>>>>>>>>> could itemise the most likely new features, >>>>>>>>>>>>>>> enhancements and bug fixes that we will see in >>>>>>>>>>>>>>> JavaFX when JDK 9 is released? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Of course it's purely speculation at this point >>>>>>>>>>>>>>> but it would assist me greatly to have some of >>>>>>>>>>>>>>> idea of where JavaFX is heading and which areas >>>>>>>>>>>>>>> are seen as most important. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Felix >>>>> -----BEGIN PGP SIGNATURE----- >>>>> Version: GnuPG v2 >>>>> >>>>> iQIcBAEBAgAGBQJVka5MAAoJEHb1CzgxXKwYbKwP/RFa3NjMnXWFc6o5EzIFYlh3 >>>>> 5ExLUgu+IVWr1fewrf+KTcR9WmyXWN2ju8zkRb7nhjSiA+5XAf3vbvUBGTaaa1A4 >>>>> 92Fd0W2Mfj8M9F3Px5QP1TMS1BO7GrO12zsB+obmBvWA/xWy0GEoctja8ohT5aNf >>>>> hs7foi4pZRK6abMvxd94WdSNh/KhzqNvllD3tIkqlasTOOH1i7bEreQ9sxN6+DRF >>>>> JB87JSRuml7rYEgsOSx5Z2EE7YdgqYjdfHSAIwBvqkRDQZuOp8RrWzU6wFyyzhlm >>>>> RtuAQJWj1I2DNbZE9iCNJzYqajnp0OellbxGr9SrJaVPpqNjjbw6zoGZ3bhgCAow >>>>> BAZUlllG9UVoKcl1bHDvmB01RG2JP7RtBByS0cbqGQM0/YqtknbNWpl2r5kTVyH1 >>>>> EZnfkXmXYi/lqgyRBf1/WqlJnuT10ra7oAQytUajZ3cQJNbRwuFycV0yvbGo11xS >>>>> eaQO2ECgYyubLE8vsnw1L+2U4wLAMXY9Q3Ob1kLq12UEYB8WMoLZ+IAixUUJ6abB >>>>> reI+epG/Bh27R0fHChkHEgY65TIMRt8RtOXxzs+Nf0VVAC4Lj9378Y8ZEr14RbcZ >>>>> mO+5TvyqfDhyIP4WevGDF2/tQTvlsAzl7UuiTtD3pWZ+CpN2WeNimBHPN2ZI6lii >>>>> Mfj0LIA1IawOjtYjlnHz >>>>> =lXSV >>>>> -----END PGP SIGNATURE----- >>>> >>>> From mike at plan99.net Tue Jun 30 11:21:25 2015 From: mike at plan99.net (Mike Hearn) Date: Tue, 30 Jun 2015 13:21:25 +0200 Subject: JavaFX features in JDK 9 In-Reply-To: <6D4A8ED9-A096-4E1E-9516-9BC48AC69C8D@moxley.co.uk> References: <4A33E952-B3B0-4C19-9F5E-CBB10EC9E19B@gmail.com> <558EBC40.3020300@oracle.com> <558EED1C.8030005@poczta.onet.pl> <55918EB7.3060807@oracle.com> <5591956C.3080607@poczta.onet.pl> <5591AD59.3040000@oracle.com> <5591AE4E.3000409@poczta.onet.pl> <3BECEB07-DEA7-480C-82C9-BF957E7EFD50@gmail.com> <6D4A8ED9-A096-4E1E-9516-9BC48AC69C8D@moxley.co.uk> Message-ID: Be fair, chaps. WebGL is not exactly accessible. Desktop Linux is an extremely niche platform. JFX is open source. If someone wants accessibility support on Linux, they can certainly contribute patches to implement it. The JDK9 plan looks OK to me. It doesn't sound exciting but "support Jigsaw" actually translates to a fairly large set of new features, as stuff that had to be done by hacking the internals before will finally get surfaced with proper documented APIs. It'll make the developer experience more pleasant. With respect to things like "support WebRTC" or "support WebGL" - seriously? WebRTC is useful for exactly one kind of app, video chat. It seems to have been driven primarily so Google could make a Skype competitor inside Gmail without having to make a downloadable plugin. There are already many competing video call apps that work fine. As for WebGL, you can already do OpenGL from within Java just fine. Being able to do arbitrary GL within an FX scene graph would be nice for some apps, but of course, on Windows you'd really need to be using Direct3D or some kind of performance-hurting translation layer as WebGL itself uses. If I had a single wish it'd be for better rich text support, like a rich text editor component (maybe based on Tomas Mikula's work). I know that WebKit can be used to do this but it's always been sort of glitchy and what you get out is HTML which then can't be rendered easily in a regular TextView. Unlike many of these other suggestions such a component would be useful for business apps, and a basic one seems achievable in a reasonable budget especially if it's based on Tomas' existing code. On Tue, Jun 30, 2015 at 1:13 PM, Jack Moxley wrote: > Maybe it should its aspirations a little higher, especially with the > advent of unity, webgl or even scenegraph impls such as jmonkeyengine that > do. > > Sent from my iPhone > > > On 30 Jun 2015, at 09:42, Felix Bembrick > wrote: > > > > JavaFX has *never* claimed to be write once, run anyway > > > > > >> On 30 Jun 2015, at 18:13, Mike wrote: > >> > >> write once, run anywhere > >> > >> This about sums it up! > >> > >> > >> > >>> On Tue, Jun 30, 2015 at 12:12 AM, Jack Moxley > wrote: > >>> > >>> write once, run anywhere > >>> > >>> Sent from my iPhone > >>> > >>>>> On 29 Jun 2015, at 21:45, Micha? Zegan > >>>> wrote: > >>>> > >>>> -----BEGIN PGP SIGNED MESSAGE----- > >>>> Hash: SHA1 > >>>> > >>>> Does it mean platform support for linux won't be implemented now, or > >>>> at all? > >>>> I usually use windows, but still depend on that support because I > >>>> sometimes use linux, so I am interested about that. > >>>> > >>>> W dniu 2015-06-29 o 22:40, Kevin Rushforth pisze: > >>>>> There is public API in 8u40 to support accessibility. Applications > >>>>> using standard JavaFX controls can, for example, use the > >>>>> accessibleText property to define the text that the screen reader > >>>>> will speak or the accessibleHelp property to provide a more > >>>>> detailed description. These properties have reasonable defaults, > >>>>> but can be overridden by applications. Additionally, if you use the > >>>>> "labelFor" property to point to a Control that the Label is > >>>>> associated with, the accessibility framework will use that when the > >>>>> screen reader is active. > >>>>> > >>>>> Custom controls can override the queryAccessibleAttribute, > >>>>> executeAccessibleAction, and notifyAccessibleAttributeChanged > >>>>> methods. > >>>>> > >>>>> As for platform support, we currently support Windows and Mac > >>>>> platforms. We have no plan to make FX accessible on Linux . > >>>>> > >>>>> -- Kevin > >>>>> > >>>>> > >>>>> Micha? Zegan wrote: I saw it, and it seems promising, but: first, > >>>>> there is probably, or I heard it wrong? no public api for making > >>>>> accessibility related stuff... Also, I believe there is no linux > >>>>> accessibility bridge as opposed to windows and mac. And I do not > >>>>> know if I am wrong, or when this is going to be implemented. > >>>>> > >>>>> W dniu 2015-06-29 o 20:30, Kevin Rushforth pisze: > >>>>> > >>>>>>>> JavaFX accessibility is already implemented and was delivered > >>>>>>>> in JDK 8u40. > >>>>>>>> > >>>>>>>> -- Kevin > >>>>>>>> > >>>>>>>> > >>>>>>>> Micha? Zegan wrote: What about accessibility work? Work on it > >>>>>>>> has been started, but not sure if it is still targetted for > >>>>>>>> 9. > >>>>>>>> > >>>>>>>> W dniu 2015-06-27 o 20:16, Mike pisze: > >>>>>>>> > >>>>>>>> > >>>>>>>>>>> a lot of FULL blown Webrtc support and building > >>>>>>>>>>> something in Javafx (like Scene Builder) that Proves > >>>>>>>>>>> Webrtc support would be awesome. Ditto to Webgl > >>>>>>>>>>> support. > >>>>>>>>>>> > >>>>>>>>>>> On Sat, Jun 27, 2015 at 8:07 AM, Kevin Rushforth > >>>>>>>>>>> >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>> wrote: > >>>>>>>>>>>> > >>>>>>>>>>>> Hi Felix, > >>>>>>>>>>>> > >>>>>>>>>>>> Sorry for the delay. Most of us were still pretty > >>>>>>>>>>>> focused on 8u60, but we are turning our attention to > >>>>>>>>>>>> JDK 9 now. > >>>>>>>>>>>> > >>>>>>>>>>>> The focus for JDK 9 is Jigsaw. The currently planned > >>>>>>>>>>>> big features (JEPs) for FX in JDK 9 are these: > >>>>>>>>>>>> > >>>>>>>>>>>> JEP 253: Prepare JavaFX UI Controls & CSS APIs for > >>>>>>>>>>>> Modularization JEP 257: Update JavaFX/Media to Newer > >>>>>>>>>>>> Version of GStreamer > >>>>>>>>>>>> > >>>>>>>>>>>> Related to Jigasw, we intend to look into new API for > >>>>>>>>>>>> heavily used internal methods / classes since they > >>>>>>>>>>>> will no longer be accessible otherwise. We also plan > >>>>>>>>>>>> to update WebKit at least one more time, and will > >>>>>>>>>>>> likely do a few RFEs such as better Hi-DPI support > >>>>>>>>>>>> (with API control) on Mac, Windows, Linux. > >>>>>>>>>>>> > >>>>>>>>>>>> We don't currently plan any other big features for 9, > >>>>>>>>>>>> but will consider additional RFEs if they are > >>>>>>>>>>>> important to enough developers and if they fit into > >>>>>>>>>>>> the time frame. > >>>>>>>>>>>> > >>>>>>>>>>>> -- Kevin > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> Felix Bembrick wrote: > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>>> Anyone got anything or is there a link somewhere > >>>>>>>>>>>>> that talks about these? > >>>>>>>>>>>>> > >>>>>>>>>>>>> On 15 June 2015 at 22:00, Felix Bembrick > >>>>>>>>>>>>> wrote: > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>>> I realise we are a long way off JDK 9 still and > >>>>>>>>>>>>>> with crucial features such as Jigsaw still a > >>>>>>>>>>>>>> little up in the air but is it possible someone > >>>>>>>>>>>>>> could itemise the most likely new features, > >>>>>>>>>>>>>> enhancements and bug fixes that we will see in > >>>>>>>>>>>>>> JavaFX when JDK 9 is released? > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Of course it's purely speculation at this point > >>>>>>>>>>>>>> but it would assist me greatly to have some of > >>>>>>>>>>>>>> idea of where JavaFX is heading and which areas > >>>>>>>>>>>>>> are seen as most important. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Thanks, > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Felix > >>>> -----BEGIN PGP SIGNATURE----- > >>>> Version: GnuPG v2 > >>>> > >>>> iQIcBAEBAgAGBQJVka5MAAoJEHb1CzgxXKwYbKwP/RFa3NjMnXWFc6o5EzIFYlh3 > >>>> 5ExLUgu+IVWr1fewrf+KTcR9WmyXWN2ju8zkRb7nhjSiA+5XAf3vbvUBGTaaa1A4 > >>>> 92Fd0W2Mfj8M9F3Px5QP1TMS1BO7GrO12zsB+obmBvWA/xWy0GEoctja8ohT5aNf > >>>> hs7foi4pZRK6abMvxd94WdSNh/KhzqNvllD3tIkqlasTOOH1i7bEreQ9sxN6+DRF > >>>> JB87JSRuml7rYEgsOSx5Z2EE7YdgqYjdfHSAIwBvqkRDQZuOp8RrWzU6wFyyzhlm > >>>> RtuAQJWj1I2DNbZE9iCNJzYqajnp0OellbxGr9SrJaVPpqNjjbw6zoGZ3bhgCAow > >>>> BAZUlllG9UVoKcl1bHDvmB01RG2JP7RtBByS0cbqGQM0/YqtknbNWpl2r5kTVyH1 > >>>> EZnfkXmXYi/lqgyRBf1/WqlJnuT10ra7oAQytUajZ3cQJNbRwuFycV0yvbGo11xS > >>>> eaQO2ECgYyubLE8vsnw1L+2U4wLAMXY9Q3Ob1kLq12UEYB8WMoLZ+IAixUUJ6abB > >>>> reI+epG/Bh27R0fHChkHEgY65TIMRt8RtOXxzs+Nf0VVAC4Lj9378Y8ZEr14RbcZ > >>>> mO+5TvyqfDhyIP4WevGDF2/tQTvlsAzl7UuiTtD3pWZ+CpN2WeNimBHPN2ZI6lii > >>>> Mfj0LIA1IawOjtYjlnHz > >>>> =lXSV > >>>> -----END PGP SIGNATURE----- > >>> > >>> > > From jack at moxley.co.uk Tue Jun 30 11:21:38 2015 From: jack at moxley.co.uk (Jack Moxley) Date: Tue, 30 Jun 2015 12:21:38 +0100 Subject: JavaFX features in JDK 9 In-Reply-To: <20230153-DC3C-4A7D-8885-B494B2984594@gmail.com> References: <4A33E952-B3B0-4C19-9F5E-CBB10EC9E19B@gmail.com> <558EBC40.3020300@oracle.com> <558EED1C.8030005@poczta.onet.pl> <55918EB7.3060807@oracle.com> <5591956C.3080607@poczta.onet.pl> <5591AD59.3040000@oracle.com> <5591AE4E.3000409@poczta.onet.pl> <3BECEB07-DEA7-480C-82C9-BF957E7EFD50@gmail.com> <6D4A8ED9-A096-4E1E-9516-9BC48AC69C8D@moxley.co.uk> <20230153-DC3C-4A7D-8885-B494B2984594@gmail.com> Message-ID: I suppose i should stop shouting from the sidelines, roll up my sleeves and get my hands dirty, what can i do as a lowly developer to help? Sent from my iPhone > On 30 Jun 2015, at 12:16, Felix Bembrick wrote: > > Well, we are all at the whim of Oracle executives decisions with the added help of third parties such as Gluon and RoboVM. The future of JavaFX really is in *our* hands. > > > >> On 30 Jun 2015, at 21:13, Jack Moxley wrote: >> >> Maybe it should its aspirations a little higher, especially with the advent of unity, webgl or even scenegraph impls such as jmonkeyengine that do. >> >> Sent from my iPhone >> >>> On 30 Jun 2015, at 09:42, Felix Bembrick wrote: >>> >>> JavaFX has *never* claimed to be write once, run anyway >>> >>> >>>> On 30 Jun 2015, at 18:13, Mike wrote: >>>> >>>> write once, run anywhere >>>> >>>> This about sums it up! >>>> >>>> >>>> >>>>> On Tue, Jun 30, 2015 at 12:12 AM, Jack Moxley wrote: >>>>> >>>>> write once, run anywhere >>>>> >>>>> Sent from my iPhone >>>>> >>>>>>> On 29 Jun 2015, at 21:45, Micha? Zegan >>>>>> wrote: >>>>>> >>>>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>>> Hash: SHA1 >>>>>> >>>>>> Does it mean platform support for linux won't be implemented now, or >>>>>> at all? >>>>>> I usually use windows, but still depend on that support because I >>>>>> sometimes use linux, so I am interested about that. >>>>>> >>>>>> W dniu 2015-06-29 o 22:40, Kevin Rushforth pisze: >>>>>>> There is public API in 8u40 to support accessibility. Applications >>>>>>> using standard JavaFX controls can, for example, use the >>>>>>> accessibleText property to define the text that the screen reader >>>>>>> will speak or the accessibleHelp property to provide a more >>>>>>> detailed description. These properties have reasonable defaults, >>>>>>> but can be overridden by applications. Additionally, if you use the >>>>>>> "labelFor" property to point to a Control that the Label is >>>>>>> associated with, the accessibility framework will use that when the >>>>>>> screen reader is active. >>>>>>> >>>>>>> Custom controls can override the queryAccessibleAttribute, >>>>>>> executeAccessibleAction, and notifyAccessibleAttributeChanged >>>>>>> methods. >>>>>>> >>>>>>> As for platform support, we currently support Windows and Mac >>>>>>> platforms. We have no plan to make FX accessible on Linux . >>>>>>> >>>>>>> -- Kevin >>>>>>> >>>>>>> >>>>>>> Micha? Zegan wrote: I saw it, and it seems promising, but: first, >>>>>>> there is probably, or I heard it wrong? no public api for making >>>>>>> accessibility related stuff... Also, I believe there is no linux >>>>>>> accessibility bridge as opposed to windows and mac. And I do not >>>>>>> know if I am wrong, or when this is going to be implemented. >>>>>>> >>>>>>> W dniu 2015-06-29 o 20:30, Kevin Rushforth pisze: >>>>>>> >>>>>>>>>> JavaFX accessibility is already implemented and was delivered >>>>>>>>>> in JDK 8u40. >>>>>>>>>> >>>>>>>>>> -- Kevin >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Micha? Zegan wrote: What about accessibility work? Work on it >>>>>>>>>> has been started, but not sure if it is still targetted for >>>>>>>>>> 9. >>>>>>>>>> >>>>>>>>>> W dniu 2015-06-27 o 20:16, Mike pisze: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>> a lot of FULL blown Webrtc support and building >>>>>>>>>>>>> something in Javafx (like Scene Builder) that Proves >>>>>>>>>>>>> Webrtc support would be awesome. Ditto to Webgl >>>>>>>>>>>>> support. >>>>>>>>>>>>> >>>>>>>>>>>>> On Sat, Jun 27, 2015 at 8:07 AM, Kevin Rushforth >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Hi Felix, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Sorry for the delay. Most of us were still pretty >>>>>>>>>>>>>> focused on 8u60, but we are turning our attention to >>>>>>>>>>>>>> JDK 9 now. >>>>>>>>>>>>>> >>>>>>>>>>>>>> The focus for JDK 9 is Jigsaw. The currently planned >>>>>>>>>>>>>> big features (JEPs) for FX in JDK 9 are these: >>>>>>>>>>>>>> >>>>>>>>>>>>>> JEP 253: Prepare JavaFX UI Controls & CSS APIs for >>>>>>>>>>>>>> Modularization JEP 257: Update JavaFX/Media to Newer >>>>>>>>>>>>>> Version of GStreamer >>>>>>>>>>>>>> >>>>>>>>>>>>>> Related to Jigasw, we intend to look into new API for >>>>>>>>>>>>>> heavily used internal methods / classes since they >>>>>>>>>>>>>> will no longer be accessible otherwise. We also plan >>>>>>>>>>>>>> to update WebKit at least one more time, and will >>>>>>>>>>>>>> likely do a few RFEs such as better Hi-DPI support >>>>>>>>>>>>>> (with API control) on Mac, Windows, Linux. >>>>>>>>>>>>>> >>>>>>>>>>>>>> We don't currently plan any other big features for 9, >>>>>>>>>>>>>> but will consider additional RFEs if they are >>>>>>>>>>>>>> important to enough developers and if they fit into >>>>>>>>>>>>>> the time frame. >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- Kevin >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Felix Bembrick wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Anyone got anything or is there a link somewhere >>>>>>>>>>>>>>> that talks about these? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 15 June 2015 at 22:00, Felix Bembrick >>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I realise we are a long way off JDK 9 still and >>>>>>>>>>>>>>>> with crucial features such as Jigsaw still a >>>>>>>>>>>>>>>> little up in the air but is it possible someone >>>>>>>>>>>>>>>> could itemise the most likely new features, >>>>>>>>>>>>>>>> enhancements and bug fixes that we will see in >>>>>>>>>>>>>>>> JavaFX when JDK 9 is released? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Of course it's purely speculation at this point >>>>>>>>>>>>>>>> but it would assist me greatly to have some of >>>>>>>>>>>>>>>> idea of where JavaFX is heading and which areas >>>>>>>>>>>>>>>> are seen as most important. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Felix >>>>>> -----BEGIN PGP SIGNATURE----- >>>>>> Version: GnuPG v2 >>>>>> >>>>>> iQIcBAEBAgAGBQJVka5MAAoJEHb1CzgxXKwYbKwP/RFa3NjMnXWFc6o5EzIFYlh3 >>>>>> 5ExLUgu+IVWr1fewrf+KTcR9WmyXWN2ju8zkRb7nhjSiA+5XAf3vbvUBGTaaa1A4 >>>>>> 92Fd0W2Mfj8M9F3Px5QP1TMS1BO7GrO12zsB+obmBvWA/xWy0GEoctja8ohT5aNf >>>>>> hs7foi4pZRK6abMvxd94WdSNh/KhzqNvllD3tIkqlasTOOH1i7bEreQ9sxN6+DRF >>>>>> JB87JSRuml7rYEgsOSx5Z2EE7YdgqYjdfHSAIwBvqkRDQZuOp8RrWzU6wFyyzhlm >>>>>> RtuAQJWj1I2DNbZE9iCNJzYqajnp0OellbxGr9SrJaVPpqNjjbw6zoGZ3bhgCAow >>>>>> BAZUlllG9UVoKcl1bHDvmB01RG2JP7RtBByS0cbqGQM0/YqtknbNWpl2r5kTVyH1 >>>>>> EZnfkXmXYi/lqgyRBf1/WqlJnuT10ra7oAQytUajZ3cQJNbRwuFycV0yvbGo11xS >>>>>> eaQO2ECgYyubLE8vsnw1L+2U4wLAMXY9Q3Ob1kLq12UEYB8WMoLZ+IAixUUJ6abB >>>>>> reI+epG/Bh27R0fHChkHEgY65TIMRt8RtOXxzs+Nf0VVAC4Lj9378Y8ZEr14RbcZ >>>>>> mO+5TvyqfDhyIP4WevGDF2/tQTvlsAzl7UuiTtD3pWZ+CpN2WeNimBHPN2ZI6lii >>>>>> Mfj0LIA1IawOjtYjlnHz >>>>>> =lXSV >>>>>> -----END PGP SIGNATURE----- >> From felix.bembrick at gmail.com Tue Jun 30 11:33:33 2015 From: felix.bembrick at gmail.com (Felix Bembrick) Date: Tue, 30 Jun 2015 21:33:33 +1000 Subject: JavaFX features in JDK 9 In-Reply-To: References: <4A33E952-B3B0-4C19-9F5E-CBB10EC9E19B@gmail.com> <558EBC40.3020300@oracle.com> <558EED1C.8030005@poczta.onet.pl> <55918EB7.3060807@oracle.com> <5591956C.3080607@poczta.onet.pl> <5591AD59.3040000@oracle.com> <5591AE4E.3000409@poczta.onet.pl> <3BECEB07-DEA7-480C-82C9-BF957E7EFD50@gmail.com> <6D4A8ED9-A096-4E1E-9516-9BC48AC69C8D@moxley.co.uk> <20230153-DC3C-4A7D-8885-B494B2984594@gmail.com> Message-ID: Mike, I believe it is essential that the JavaFX WebView supports WebGL as this is where a lot of the OpenGL work is being done now. At the moment, JavaFX WebView is limited to Lite Mode of Google Maps for example so it is not really compatible with an external browser. Other than that, there has to be a seamless way of integrating custom shaders and arbitrary OpenGL in a way that works in conjunction with the scene graph. Current 3D support in JavaFX is "token" at best... On 30 June 2015 at 21:21, Jack Moxley wrote: > I suppose i should stop shouting from the sidelines, roll up my sleeves > and get my hands dirty, what can i do as a lowly developer to help? > > Sent from my iPhone > > > On 30 Jun 2015, at 12:16, Felix Bembrick > wrote: > > > > Well, we are all at the whim of Oracle executives decisions with the > added help of third parties such as Gluon and RoboVM. The future of JavaFX > really is in *our* hands. > > > > > > > >> On 30 Jun 2015, at 21:13, Jack Moxley wrote: > >> > >> Maybe it should its aspirations a little higher, especially with the > advent of unity, webgl or even scenegraph impls such as jmonkeyengine that > do. > >> > >> Sent from my iPhone > >> > >>> On 30 Jun 2015, at 09:42, Felix Bembrick > wrote: > >>> > >>> JavaFX has *never* claimed to be write once, run anyway > >>> > >>> > >>>> On 30 Jun 2015, at 18:13, Mike wrote: > >>>> > >>>> write once, run anywhere > >>>> > >>>> This about sums it up! > >>>> > >>>> > >>>> > >>>>> On Tue, Jun 30, 2015 at 12:12 AM, Jack Moxley > wrote: > >>>>> > >>>>> write once, run anywhere > >>>>> > >>>>> Sent from my iPhone > >>>>> > >>>>>>> On 29 Jun 2015, at 21:45, Micha? Zegan > > >>>>>> wrote: > >>>>>> > >>>>>> -----BEGIN PGP SIGNED MESSAGE----- > >>>>>> Hash: SHA1 > >>>>>> > >>>>>> Does it mean platform support for linux won't be implemented now, or > >>>>>> at all? > >>>>>> I usually use windows, but still depend on that support because I > >>>>>> sometimes use linux, so I am interested about that. > >>>>>> > >>>>>> W dniu 2015-06-29 o 22:40, Kevin Rushforth pisze: > >>>>>>> There is public API in 8u40 to support accessibility. Applications > >>>>>>> using standard JavaFX controls can, for example, use the > >>>>>>> accessibleText property to define the text that the screen reader > >>>>>>> will speak or the accessibleHelp property to provide a more > >>>>>>> detailed description. These properties have reasonable defaults, > >>>>>>> but can be overridden by applications. Additionally, if you use the > >>>>>>> "labelFor" property to point to a Control that the Label is > >>>>>>> associated with, the accessibility framework will use that when the > >>>>>>> screen reader is active. > >>>>>>> > >>>>>>> Custom controls can override the queryAccessibleAttribute, > >>>>>>> executeAccessibleAction, and notifyAccessibleAttributeChanged > >>>>>>> methods. > >>>>>>> > >>>>>>> As for platform support, we currently support Windows and Mac > >>>>>>> platforms. We have no plan to make FX accessible on Linux . > >>>>>>> > >>>>>>> -- Kevin > >>>>>>> > >>>>>>> > >>>>>>> Micha? Zegan wrote: I saw it, and it seems promising, but: first, > >>>>>>> there is probably, or I heard it wrong? no public api for making > >>>>>>> accessibility related stuff... Also, I believe there is no linux > >>>>>>> accessibility bridge as opposed to windows and mac. And I do not > >>>>>>> know if I am wrong, or when this is going to be implemented. > >>>>>>> > >>>>>>> W dniu 2015-06-29 o 20:30, Kevin Rushforth pisze: > >>>>>>> > >>>>>>>>>> JavaFX accessibility is already implemented and was delivered > >>>>>>>>>> in JDK 8u40. > >>>>>>>>>> > >>>>>>>>>> -- Kevin > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> Micha? Zegan wrote: What about accessibility work? Work on it > >>>>>>>>>> has been started, but not sure if it is still targetted for > >>>>>>>>>> 9. > >>>>>>>>>> > >>>>>>>>>> W dniu 2015-06-27 o 20:16, Mike pisze: > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>>>> a lot of FULL blown Webrtc support and building > >>>>>>>>>>>>> something in Javafx (like Scene Builder) that Proves > >>>>>>>>>>>>> Webrtc support would be awesome. Ditto to Webgl > >>>>>>>>>>>>> support. > >>>>>>>>>>>>> > >>>>>>>>>>>>> On Sat, Jun 27, 2015 at 8:07 AM, Kevin Rushforth > >>>>>>>>>>>>> >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Hi Felix, > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Sorry for the delay. Most of us were still pretty > >>>>>>>>>>>>>> focused on 8u60, but we are turning our attention to > >>>>>>>>>>>>>> JDK 9 now. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> The focus for JDK 9 is Jigsaw. The currently planned > >>>>>>>>>>>>>> big features (JEPs) for FX in JDK 9 are these: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> JEP 253: Prepare JavaFX UI Controls & CSS APIs for > >>>>>>>>>>>>>> Modularization JEP 257: Update JavaFX/Media to Newer > >>>>>>>>>>>>>> Version of GStreamer > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Related to Jigasw, we intend to look into new API for > >>>>>>>>>>>>>> heavily used internal methods / classes since they > >>>>>>>>>>>>>> will no longer be accessible otherwise. We also plan > >>>>>>>>>>>>>> to update WebKit at least one more time, and will > >>>>>>>>>>>>>> likely do a few RFEs such as better Hi-DPI support > >>>>>>>>>>>>>> (with API control) on Mac, Windows, Linux. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> We don't currently plan any other big features for 9, > >>>>>>>>>>>>>> but will consider additional RFEs if they are > >>>>>>>>>>>>>> important to enough developers and if they fit into > >>>>>>>>>>>>>> the time frame. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> -- Kevin > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Felix Bembrick wrote: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Anyone got anything or is there a link somewhere > >>>>>>>>>>>>>>> that talks about these? > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> On 15 June 2015 at 22:00, Felix Bembrick > >>>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> I realise we are a long way off JDK 9 still and > >>>>>>>>>>>>>>>> with crucial features such as Jigsaw still a > >>>>>>>>>>>>>>>> little up in the air but is it possible someone > >>>>>>>>>>>>>>>> could itemise the most likely new features, > >>>>>>>>>>>>>>>> enhancements and bug fixes that we will see in > >>>>>>>>>>>>>>>> JavaFX when JDK 9 is released? > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> Of course it's purely speculation at this point > >>>>>>>>>>>>>>>> but it would assist me greatly to have some of > >>>>>>>>>>>>>>>> idea of where JavaFX is heading and which areas > >>>>>>>>>>>>>>>> are seen as most important. > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> Thanks, > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> Felix > >>>>>> -----BEGIN PGP SIGNATURE----- > >>>>>> Version: GnuPG v2 > >>>>>> > >>>>>> iQIcBAEBAgAGBQJVka5MAAoJEHb1CzgxXKwYbKwP/RFa3NjMnXWFc6o5EzIFYlh3 > >>>>>> 5ExLUgu+IVWr1fewrf+KTcR9WmyXWN2ju8zkRb7nhjSiA+5XAf3vbvUBGTaaa1A4 > >>>>>> 92Fd0W2Mfj8M9F3Px5QP1TMS1BO7GrO12zsB+obmBvWA/xWy0GEoctja8ohT5aNf > >>>>>> hs7foi4pZRK6abMvxd94WdSNh/KhzqNvllD3tIkqlasTOOH1i7bEreQ9sxN6+DRF > >>>>>> JB87JSRuml7rYEgsOSx5Z2EE7YdgqYjdfHSAIwBvqkRDQZuOp8RrWzU6wFyyzhlm > >>>>>> RtuAQJWj1I2DNbZE9iCNJzYqajnp0OellbxGr9SrJaVPpqNjjbw6zoGZ3bhgCAow > >>>>>> BAZUlllG9UVoKcl1bHDvmB01RG2JP7RtBByS0cbqGQM0/YqtknbNWpl2r5kTVyH1 > >>>>>> EZnfkXmXYi/lqgyRBf1/WqlJnuT10ra7oAQytUajZ3cQJNbRwuFycV0yvbGo11xS > >>>>>> eaQO2ECgYyubLE8vsnw1L+2U4wLAMXY9Q3Ob1kLq12UEYB8WMoLZ+IAixUUJ6abB > >>>>>> reI+epG/Bh27R0fHChkHEgY65TIMRt8RtOXxzs+Nf0VVAC4Lj9378Y8ZEr14RbcZ > >>>>>> mO+5TvyqfDhyIP4WevGDF2/tQTvlsAzl7UuiTtD3pWZ+CpN2WeNimBHPN2ZI6lii > >>>>>> Mfj0LIA1IawOjtYjlnHz > >>>>>> =lXSV > >>>>>> -----END PGP SIGNATURE----- > >> > > From swpalmer at gmail.com Tue Jun 30 12:09:13 2015 From: swpalmer at gmail.com (Scott Palmer) Date: Tue, 30 Jun 2015 08:09:13 -0400 Subject: JavaFX features in JDK 9 In-Reply-To: References: <4A33E952-B3B0-4C19-9F5E-CBB10EC9E19B@gmail.com> <558EBC40.3020300@oracle.com> <558EED1C.8030005@poczta.onet.pl> <55918EB7.3060807@oracle.com> <5591956C.3080607@poczta.onet.pl> <5591AD59.3040000@oracle.com> <5591AE4E.3000409@poczta.onet.pl> <3BECEB07-DEA7-480C-82C9-BF957E7EFD50@gmail.com> <6D4A8ED9-A096-4E1E-9516-9BC48AC69C8D@moxley.co.uk> Message-ID: > On Jun 30, 2015, at 7:21 AM, Mike Hearn wrote: > > ... > With respect to things like "support WebRTC" or "support WebGL" - > seriously? WebRTC is useful for exactly one kind of app, video chat. It > seems to have been driven primarily so Google could make a Skype competitor > inside Gmail without having to make a downloadable plugin. There are > already many competing video call apps that work fine. Video streaming, conferencing, etc. are important technologies. But if you are going with a Java UI, there isn?t much point in handcuffing yourself to a Web UI that will have a far worse user experience. > > As for WebGL, you can already do OpenGL from within Java just fine. Not ?just fine" in a JavaFX app though. With no access to native window handles or an OpenGL surface it?s not so simple. You have to fall back to AWT/Swing or go native and then you?ve got issues with the OpenGL parts not being well integrated into the rest of the UI. My commercial application has to create a separate AWT window to implement a video preview to avoid performance issues. With the AWT window I can get the native window handle and blit directly to the window without extra copies of uncompressed HD video frames. > Being > able to do arbitrary GL within an FX scene graph would be nice for some > apps, but of course, on Windows you'd really need to be using Direct3D or > some kind of performance-hurting translation layer as WebGL itself uses. Exactly. Access to a native drawing surface has been discussed for a long time. It would be nice to see some progress made with JavaFX 9. > If I had a single wish it'd be for better rich text support, like a rich > text editor component (maybe based on Tomas Mikula's work). That would be a great area for improvement. I personally would like to see my request for extensible media support (from 2008) to get some attention https://bugs.openjdk.java.net/browse/JDK-8091063 It should be possible (and reasonable) to write a non-linear editor like Final Cut Pro in Java (and some JNI) with a JavaFX UI. :-) Scott > > On Tue, Jun 30, 2015 at 1:13 PM, Jack Moxley wrote: > >> Maybe it should its aspirations a little higher, especially with the >> advent of unity, webgl or even scenegraph impls such as jmonkeyengine that >> do. >> >> Sent from my iPhone >> >>> On 30 Jun 2015, at 09:42, Felix Bembrick >> wrote: >>> >>> JavaFX has *never* claimed to be write once, run anyway >>> >>> >>>> On 30 Jun 2015, at 18:13, Mike wrote: >>>> >>>> write once, run anywhere >>>> >>>> This about sums it up! >>>> >>>> >>>> >>>>> On Tue, Jun 30, 2015 at 12:12 AM, Jack Moxley >> wrote: >>>>> >>>>> write once, run anywhere >>>>> >>>>> Sent from my iPhone >>>>> >>>>>>> On 29 Jun 2015, at 21:45, Micha? Zegan >>>>>> wrote: >>>>>> >>>>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>>> Hash: SHA1 >>>>>> >>>>>> Does it mean platform support for linux won't be implemented now, or >>>>>> at all? >>>>>> I usually use windows, but still depend on that support because I >>>>>> sometimes use linux, so I am interested about that. >>>>>> >>>>>> W dniu 2015-06-29 o 22:40, Kevin Rushforth pisze: >>>>>>> There is public API in 8u40 to support accessibility. Applications >>>>>>> using standard JavaFX controls can, for example, use the >>>>>>> accessibleText property to define the text that the screen reader >>>>>>> will speak or the accessibleHelp property to provide a more >>>>>>> detailed description. These properties have reasonable defaults, >>>>>>> but can be overridden by applications. Additionally, if you use the >>>>>>> "labelFor" property to point to a Control that the Label is >>>>>>> associated with, the accessibility framework will use that when the >>>>>>> screen reader is active. >>>>>>> >>>>>>> Custom controls can override the queryAccessibleAttribute, >>>>>>> executeAccessibleAction, and notifyAccessibleAttributeChanged >>>>>>> methods. >>>>>>> >>>>>>> As for platform support, we currently support Windows and Mac >>>>>>> platforms. We have no plan to make FX accessible on Linux . >>>>>>> >>>>>>> -- Kevin >>>>>>> >>>>>>> >>>>>>> Micha? Zegan wrote: I saw it, and it seems promising, but: first, >>>>>>> there is probably, or I heard it wrong? no public api for making >>>>>>> accessibility related stuff... Also, I believe there is no linux >>>>>>> accessibility bridge as opposed to windows and mac. And I do not >>>>>>> know if I am wrong, or when this is going to be implemented. >>>>>>> >>>>>>> W dniu 2015-06-29 o 20:30, Kevin Rushforth pisze: >>>>>>> >>>>>>>>>> JavaFX accessibility is already implemented and was delivered >>>>>>>>>> in JDK 8u40. >>>>>>>>>> >>>>>>>>>> -- Kevin >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Micha? Zegan wrote: What about accessibility work? Work on it >>>>>>>>>> has been started, but not sure if it is still targetted for >>>>>>>>>> 9. >>>>>>>>>> >>>>>>>>>> W dniu 2015-06-27 o 20:16, Mike pisze: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>> a lot of FULL blown Webrtc support and building >>>>>>>>>>>>> something in Javafx (like Scene Builder) that Proves >>>>>>>>>>>>> Webrtc support would be awesome. Ditto to Webgl >>>>>>>>>>>>> support. >>>>>>>>>>>>> >>>>>>>>>>>>> On Sat, Jun 27, 2015 at 8:07 AM, Kevin Rushforth >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Hi Felix, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Sorry for the delay. Most of us were still pretty >>>>>>>>>>>>>> focused on 8u60, but we are turning our attention to >>>>>>>>>>>>>> JDK 9 now. >>>>>>>>>>>>>> >>>>>>>>>>>>>> The focus for JDK 9 is Jigsaw. The currently planned >>>>>>>>>>>>>> big features (JEPs) for FX in JDK 9 are these: >>>>>>>>>>>>>> >>>>>>>>>>>>>> JEP 253: Prepare JavaFX UI Controls & CSS APIs for >>>>>>>>>>>>>> Modularization JEP 257: Update JavaFX/Media to Newer >>>>>>>>>>>>>> Version of GStreamer >>>>>>>>>>>>>> >>>>>>>>>>>>>> Related to Jigasw, we intend to look into new API for >>>>>>>>>>>>>> heavily used internal methods / classes since they >>>>>>>>>>>>>> will no longer be accessible otherwise. We also plan >>>>>>>>>>>>>> to update WebKit at least one more time, and will >>>>>>>>>>>>>> likely do a few RFEs such as better Hi-DPI support >>>>>>>>>>>>>> (with API control) on Mac, Windows, Linux. >>>>>>>>>>>>>> >>>>>>>>>>>>>> We don't currently plan any other big features for 9, >>>>>>>>>>>>>> but will consider additional RFEs if they are >>>>>>>>>>>>>> important to enough developers and if they fit into >>>>>>>>>>>>>> the time frame. >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- Kevin >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Felix Bembrick wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Anyone got anything or is there a link somewhere >>>>>>>>>>>>>>> that talks about these? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 15 June 2015 at 22:00, Felix Bembrick >>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I realise we are a long way off JDK 9 still and >>>>>>>>>>>>>>>> with crucial features such as Jigsaw still a >>>>>>>>>>>>>>>> little up in the air but is it possible someone >>>>>>>>>>>>>>>> could itemise the most likely new features, >>>>>>>>>>>>>>>> enhancements and bug fixes that we will see in >>>>>>>>>>>>>>>> JavaFX when JDK 9 is released? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Of course it's purely speculation at this point >>>>>>>>>>>>>>>> but it would assist me greatly to have some of >>>>>>>>>>>>>>>> idea of where JavaFX is heading and which areas >>>>>>>>>>>>>>>> are seen as most important. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Felix >> From info at michaelhoffer.de Tue Jun 30 12:29:50 2015 From: info at michaelhoffer.de (Michael Hoffer) Date: Tue, 30 Jun 2015 14:29:50 +0200 Subject: JavaFX features in JDK 9 In-Reply-To: References: <4A33E952-B3B0-4C19-9F5E-CBB10EC9E19B@gmail.com> <558EBC40.3020300@oracle.com> <558EED1C.8030005@poczta.onet.pl> <55918EB7.3060807@oracle.com> <5591956C.3080607@poczta.onet.pl> <5591AD59.3040000@oracle.com> <5591AE4E.3000409@poczta.onet.pl> <3BECEB07-DEA7-480C-82C9-BF957E7EFD50@gmail.com> <6D4A8ED9-A096-4E1E-9516-9BC48AC69C8D@moxley.co.uk> Message-ID: Hi all, I agree that we need WebGL support in JavaFX. Recently, I made some experiments with integrating the Qt based WebView/WebEngine into JavaFX via synchronized shared memory buffers (see https://www.youtube.com/watch?v=FlIrY1SlNM4 and https://www.youtube.com/watch?v=CQXG77O2MqQ). what can i do as a lowly developer to help? The implementation is highly experimental and there is a lot of work to do. Any help is highly appreciated! The advantage compared to the JavaFX WebKit project is that it is not necessary to fork WebKit. The downside is that the integration is not as good. Updating to a new versionof Qt WebView/WebEngine, however, is relatively easy since I'm using a QPainter that draws to a shared memory buffer. JavaFX gets access to the buffer via JNI. What concerns me is the limited API to directly draw buffers without performing too much copying. Therefore, *we need a public equivalent of NGExternalNode* (used by SwingNode, integrates Swing into JavaFX). Kevin, do you think this is realistic for JavaFX 9? Anyway, here is a link to the github repo: https://github.com/miho/VFXWebKit Regards, Michael 2015-06-30 14:09 GMT+02:00 Scott Palmer : > > > On Jun 30, 2015, at 7:21 AM, Mike Hearn wrote: > > > > ... > > With respect to things like "support WebRTC" or "support WebGL" - > > seriously? WebRTC is useful for exactly one kind of app, video chat. It > > seems to have been driven primarily so Google could make a Skype > competitor > > inside Gmail without having to make a downloadable plugin. There are > > already many competing video call apps that work fine. > > Video streaming, conferencing, etc. are important technologies. But if > you are going with a Java UI, there isn?t much point in handcuffing > yourself to a Web UI that will have a far worse user experience. > > > > > As for WebGL, you can already do OpenGL from within Java just fine. > > Not ?just fine" in a JavaFX app though. With no access to native window > handles or an OpenGL surface it?s not so simple. You have to fall back to > AWT/Swing or go native and then you?ve got issues with the OpenGL parts not > being well integrated into the rest of the UI. My commercial application > has to create a separate AWT window to implement a video preview to avoid > performance issues. With the AWT window I can get the native window handle > and blit directly to the window without extra copies of uncompressed HD > video frames. > > > Being > > able to do arbitrary GL within an FX scene graph would be nice for some > > apps, but of course, on Windows you'd really need to be using Direct3D or > > some kind of performance-hurting translation layer as WebGL itself uses. > > Exactly. Access to a native drawing surface has been discussed for a long > time. It would be nice to see some progress made with JavaFX 9. > > > If I had a single wish it'd be for better rich text support, like a rich > > text editor component (maybe based on Tomas Mikula's work). > > That would be a great area for improvement. > > I personally would like to see my request for extensible media support > (from 2008) to get some attention > https://bugs.openjdk.java.net/browse/JDK-8091063 > It should be possible (and reasonable) to write a non-linear editor like > Final Cut Pro in Java (and some JNI) with a JavaFX UI. > :-) > > > Scott > > > > > On Tue, Jun 30, 2015 at 1:13 PM, Jack Moxley wrote: > > > >> Maybe it should its aspirations a little higher, especially with the > >> advent of unity, webgl or even scenegraph impls such as jmonkeyengine > that > >> do. > >> > >> Sent from my iPhone > >> > >>> On 30 Jun 2015, at 09:42, Felix Bembrick > >> wrote: > >>> > >>> JavaFX has *never* claimed to be write once, run anyway > >>> > >>> > >>>> On 30 Jun 2015, at 18:13, Mike wrote: > >>>> > >>>> write once, run anywhere > >>>> > >>>> This about sums it up! > >>>> > >>>> > >>>> > >>>>> On Tue, Jun 30, 2015 at 12:12 AM, Jack Moxley > >> wrote: > >>>>> > >>>>> write once, run anywhere > >>>>> > >>>>> Sent from my iPhone > >>>>> > >>>>>>> On 29 Jun 2015, at 21:45, Micha? Zegan > > >>>>>> wrote: > >>>>>> > >>>>>> -----BEGIN PGP SIGNED MESSAGE----- > >>>>>> Hash: SHA1 > >>>>>> > >>>>>> Does it mean platform support for linux won't be implemented now, or > >>>>>> at all? > >>>>>> I usually use windows, but still depend on that support because I > >>>>>> sometimes use linux, so I am interested about that. > >>>>>> > >>>>>> W dniu 2015-06-29 o 22:40, Kevin Rushforth pisze: > >>>>>>> There is public API in 8u40 to support accessibility. Applications > >>>>>>> using standard JavaFX controls can, for example, use the > >>>>>>> accessibleText property to define the text that the screen reader > >>>>>>> will speak or the accessibleHelp property to provide a more > >>>>>>> detailed description. These properties have reasonable defaults, > >>>>>>> but can be overridden by applications. Additionally, if you use the > >>>>>>> "labelFor" property to point to a Control that the Label is > >>>>>>> associated with, the accessibility framework will use that when the > >>>>>>> screen reader is active. > >>>>>>> > >>>>>>> Custom controls can override the queryAccessibleAttribute, > >>>>>>> executeAccessibleAction, and notifyAccessibleAttributeChanged > >>>>>>> methods. > >>>>>>> > >>>>>>> As for platform support, we currently support Windows and Mac > >>>>>>> platforms. We have no plan to make FX accessible on Linux . > >>>>>>> > >>>>>>> -- Kevin > >>>>>>> > >>>>>>> > >>>>>>> Micha? Zegan wrote: I saw it, and it seems promising, but: first, > >>>>>>> there is probably, or I heard it wrong? no public api for making > >>>>>>> accessibility related stuff... Also, I believe there is no linux > >>>>>>> accessibility bridge as opposed to windows and mac. And I do not > >>>>>>> know if I am wrong, or when this is going to be implemented. > >>>>>>> > >>>>>>> W dniu 2015-06-29 o 20:30, Kevin Rushforth pisze: > >>>>>>> > >>>>>>>>>> JavaFX accessibility is already implemented and was delivered > >>>>>>>>>> in JDK 8u40. > >>>>>>>>>> > >>>>>>>>>> -- Kevin > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> Micha? Zegan wrote: What about accessibility work? Work on it > >>>>>>>>>> has been started, but not sure if it is still targetted for > >>>>>>>>>> 9. > >>>>>>>>>> > >>>>>>>>>> W dniu 2015-06-27 o 20:16, Mike pisze: > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>>>> a lot of FULL blown Webrtc support and building > >>>>>>>>>>>>> something in Javafx (like Scene Builder) that Proves > >>>>>>>>>>>>> Webrtc support would be awesome. Ditto to Webgl > >>>>>>>>>>>>> support. > >>>>>>>>>>>>> > >>>>>>>>>>>>> On Sat, Jun 27, 2015 at 8:07 AM, Kevin Rushforth > >>>>>>>>>>>>> >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Hi Felix, > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Sorry for the delay. Most of us were still pretty > >>>>>>>>>>>>>> focused on 8u60, but we are turning our attention to > >>>>>>>>>>>>>> JDK 9 now. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> The focus for JDK 9 is Jigsaw. The currently planned > >>>>>>>>>>>>>> big features (JEPs) for FX in JDK 9 are these: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> JEP 253: Prepare JavaFX UI Controls & CSS APIs for > >>>>>>>>>>>>>> Modularization JEP 257: Update JavaFX/Media to Newer > >>>>>>>>>>>>>> Version of GStreamer > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Related to Jigasw, we intend to look into new API for > >>>>>>>>>>>>>> heavily used internal methods / classes since they > >>>>>>>>>>>>>> will no longer be accessible otherwise. We also plan > >>>>>>>>>>>>>> to update WebKit at least one more time, and will > >>>>>>>>>>>>>> likely do a few RFEs such as better Hi-DPI support > >>>>>>>>>>>>>> (with API control) on Mac, Windows, Linux. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> We don't currently plan any other big features for 9, > >>>>>>>>>>>>>> but will consider additional RFEs if they are > >>>>>>>>>>>>>> important to enough developers and if they fit into > >>>>>>>>>>>>>> the time frame. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> -- Kevin > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Felix Bembrick wrote: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Anyone got anything or is there a link somewhere > >>>>>>>>>>>>>>> that talks about these? > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> On 15 June 2015 at 22:00, Felix Bembrick > >>>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> I realise we are a long way off JDK 9 still and > >>>>>>>>>>>>>>>> with crucial features such as Jigsaw still a > >>>>>>>>>>>>>>>> little up in the air but is it possible someone > >>>>>>>>>>>>>>>> could itemise the most likely new features, > >>>>>>>>>>>>>>>> enhancements and bug fixes that we will see in > >>>>>>>>>>>>>>>> JavaFX when JDK 9 is released? > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> Of course it's purely speculation at this point > >>>>>>>>>>>>>>>> but it would assist me greatly to have some of > >>>>>>>>>>>>>>>> idea of where JavaFX is heading and which areas > >>>>>>>>>>>>>>>> are seen as most important. > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> Thanks, > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> Felix > >> > > -- Dipl.-Math. Michael Hoffer Twitter: @mihosoft Webpage: www.mihosoft.eu Goethe-Zentrum f?r Wissenschaftliches Rechnen (G-CSC) Goethe-Universit?t Kettenhofweg 139 60325 Frankfurt am Main phone: +49 69 798 25254 info at michaelhoffer.de From anton.tarasov at oracle.com Tue Jun 30 18:00:35 2015 From: anton.tarasov at oracle.com (Anton V. Tarasov) Date: Tue, 30 Jun 2015 21:00:35 +0300 Subject: Patch for JDK-8090098 - [regression] Webview - getTimezoneOffset() of a ISO strings returns a wrong value In-Reply-To: <559191AA.8030800@oracle.com> References: <559191AA.8030800@oracle.com> Message-ID: <5592D943.3090407@oracle.com> Steve, I applied your suggestion and it worked on Windows. The missed check you discovered could really be a mistake in WebKit, because Apple dropped releasing (and shipping nightly builds for) Safari for Windows at 2012. Safari 5.1.7 was the last version. I downloaded and checked it. The date bug is not reproducible with it, but this gives us almost nothing taking into account the version is much outdated. So that Windows code path might not have been well tested, since http://trac.webkit.org/changeset/159892 was commited... (WebKit Win port is still supported and can be built on your own.) What I can do else to verify the changes is to run WebKit LayoutTests aimed at date testing and see if there're no regressions. Also, please put the info you posted into JIRA. Regards, Anton. On 29.06.2015 21:42, Anton Tarasov wrote: > Hi Steve, > > Ok, I'll investigate it. > > Thanks, > Anton. > > On 29.06.2015 18:39, Hruda, Steve wrote: >> >> Hi Anton & Kevin, >> >> we read your comments in the JDK bug system and analyzed WebKit's changesets again. >> >> We?ve found the code which made this regression. >> >> http://trac.webkit.org/changeset/159892 >> >> This changeset doesn't handle one special case, which was handled by the previous code.... >> >> double diff = ((localSystemTime.wHour - offsetHour) * secondsPerHour) + ((localSystemTime.wMinute >> - offsetMinute) *60); >> >> >> (http://trac.webkit.org/browser/trunk/Source/WTF/wtf/DateMath.cpp?annotate=blame#L481 ) >> >> The diff is wrong if the calculated the offsetTime is one day before in case of the extreme >> values (e.g. midnight) where the offsetHour of the UTC time is 23 because of the day difference. >> >> In case of all other OS systems you will see the same code -> >> http://trac.webkit.org/browser/trunk/Source/WTF/wtf/DateMath.cpp?annotate=blame#L495 >> >> But there are two additional lines -> 497 & 497 which fixes this special case? >> >> *if*(diff<0) >> >> diff += secondsPerDay; >> >> >> That means ?. >> >> localSystemTime.wHour = 0; >> >> offsetHour=23 ? which causes a negative value ? and the diff+=secondsPerDay ensures that the diff >> result would be one Hour instead of -23 hours >> >> We?ve found the attached V8DateTests.js (renamed to .txt) and adjusted it a little bit to get the >> results logged in the browsers console. >> >> As you can see at ?ResulBeforeOurBugFix.txt? and ?ResultAfterOurBugFix.txt?, we were able to fix >> 6 tests which failed before out bug fix. >> >> assertEquals("Sat Oct 25 2014 23:00:00 GMT+0200 (W. Europe Daylight Time)", >> >> (new Date(2014, 9, 25, 23, 0)).toString()); >> >> assertEquals("Sat, 25 Oct 2014 21:00:00 GMT", >> >> (new Date(2014, 9, 25, 23, 0)).toUTCString()); >> >> assertEquals("Sat Oct 25 2014 23:59:00 GMT+0200 (W. Europe Daylight Time)", >> >> (new Date(2014, 9, 25, 23, 59)).toString()); >> >> assertEquals("Sat, 25 Oct 2014 21:59:00 GMT", >> >> (new Date(2014, 9, 25, 23, 59)).toUTCString()); >> >> assertEquals("Sun Oct 26 2014 00:00:00 GMT+0200 (W. Europe Daylight Time)", >> >> (new Date(2014, 9, 26, 0, 0)).toString()); >> >> assertEquals("Sun Oct 26 2014 00:59:00 GMT+0200 (W. Europe Daylight Time)", >> >> (new Date(2014, 9, 26, 0, 59)).toString()); >> >> In addition we found out that WebKit also have problems in case of Windows in case of the change >> from winter to summer time. >> >> *_Winter to summer time:_* >> >> assertEquals("Sun Mar 30 2014 03:00:00 GMT+0200 (W. Europe Daylight Time)", >> >> (new Date(2014, 2, 30, 2, 0)).toString()); >> >> assertEquals("Sun, 30 Mar 2014 01:00:00 GMT", >> >> (new Date(2014, 2, 30, 2, 0)).toUTCString()); >> >> assertEquals("Sun Mar 30 2014 03:59:00 GMT+0200 (W. Europe Daylight Time)", >> >> (new Date(2014, 2, 30, 2, 59)).toString()); >> >> assertEquals("Sun, 30 Mar 2014 01:59:00 GMT", >> >> (new Date(2014, 2, 30, 2, 59)).toUTCString()); >> >> *_Summer to winter time:_* >> >> assertEquals("Sun Oct 26 2014 02:00:00 GMT+0200 (W. Europe Daylight Time)", >> >> (new Date(2014, 9, 26, 2, 0)).toString()); >> >> assertEquals("Sun, 26 Oct 2014 00:00:00 GMT", >> >> (new Date(2014, 9, 26, 2, 0)).toUTCString()); >> >> assertEquals("Sun Oct 26 2014 02:59:00 GMT+0200 (W. Europe Daylight Time)", >> >> (new Date(2014, 9, 26, 2, 59)).toString()); >> >> assertEquals("Sun, 26 Oct 2014 00:59:00 GMT", >> >> (new Date(2014, 9, 26, 2, 59)).toUTCString()); >> >> We will try to find a solution for that, but I think that the priority of this issue is lower >> than the priority of the opened regression. >> >> It would be amazing if you can add the patch of my previous and these additional two lines >> (DateMath.cpp) to the JDK8u60. >> >> Best Regards, >> >> Steve >> >> >> Diese E-Mail wurde versandt im Auftrag des Unternehmens Intergraph Ges.m.b.H. >> Vertretungsberechtigte Gesch?ftsf?hrer: Maximilian Weber >> Sitz der Gesellschaft: Margaretenstra?e 70/I/1, 1050 Wien, ?sterreich, Tel. +43 (1) 9610567-0 >> Eingetragen beim Handelsgericht Wien, Firmenbuch-Nr.: FN 116859 b >> Umsatzsteuer-Identifikationsnummer / VAT-ID: ATU15138401, Steuer-Nummer: 264/4807 >> >> This E-Mail has been sent on behalf of the company Intergraph Ges.m.b.H. >> Authorised Managing Directors: Maximilian Weber >> Registered office and Austrian headquarters: Margaretenstr. 70/I/1, 1050 Wien, Austria, Tel. +43 >> (1) 9610567-0 >> The company is recorded at the commercial court of Vienna under the company register number FN >> 116859 b >> VAT-ID: ATU15138401, Austrian Tax ID: 264/4807 >> >> Diese E-Mail (mit zugeh?rigen Dateien) enth?lt m?glicherweise Informationen, die vertraulich >> sind, dem Urheberrecht unterliegen oder ein Gesch?ftsgeheimnis darstellen. Falls Sie diese >> Nachricht irrt?mlicherweise erhalten haben, benachrichtigen Sie uns bitte umgehend, indem Sie >> eine Antwort senden, und l?schen Sie bitte diese E-Mail und Ihre Antwort darauf. S?mtliche >> aufgef?hrten Ansichten oder Meinungen sind ausschlie?lich diejenigen des Autors und entsprechen >> nicht notwendigerweise denen des Unternehmens Intergraph. >> >> This E-Mail (and any attachments) may be confidential and protected by legal privilege. If you >> are not the intended recipient please notify us immediately by replying to the sender and delete >> this E-Mail and your reply from your system. All the views and opinions published here are solely >> based on the author's own opinion and should not be considered necessarily as reflecting the >> opinion of Intergraph. >> >> -----Original Message----- >> >> From: openjfx-dev [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Hruda, Steve >> >> Sent: Tuesday, June 23, 2015 6:26 PM >> >> To: Anton V. Tarasov; Kevin Rushforth >> >> Cc: openjfx-dev at openjdk.java.net >> >> Subject: RE: Patch for JDK-8090098 - [regression] Webview - getTimezoneOffset() of a ISO strings >> returns a wrong value >> >> Very cool Anton. >> >> I would be great if that pach could be added to 8u60, otherwise our all our customers have to >> avoid Java 8u60. >> >> Regards, >> >> Steve >> >> Diese E-Mail wurde versandt im Auftrag des Unternehmens Intergraph Ges.m.b.H. >> >> Vertretungsberechtigte Gesch?ftsf?hrer: Maximilian Weber Sitz der Gesellschaft: Margaretenstra?e >> 70/I/1, 1050 Wien, ?sterreich, Tel. +43 (1) 9610567-0 Eingetragen beim Handelsgericht Wien, >> Firmenbuch-Nr.: FN 116859 b Umsatzsteuer-Identifikationsnummer / VAT-ID: ATU15138401, >> Steuer-Nummer: 264/4807 >> >> This E-Mail has been sent on behalf of the company Intergraph Ges.m.b.H. >> >> Authorised Managing Directors: Maximilian Weber Registered office and Austrian headquarters: >> Margaretenstr. 70/I/1, 1050 Wien, Austria, Tel. +43 (1) 9610567-0 The company is recorded at the >> commercial court of Vienna under the company register number FN 116859 b >> >> VAT-ID: ATU15138401, Austrian Tax ID: 264/4807 >> >> Diese E-Mail (mit zugeh?rigen Dateien) enth?lt m?glicherweise Informationen, die vertraulich >> sind, dem Urheberrecht unterliegen oder ein Gesch?ftsgeheimnis darstellen. Falls Sie diese >> Nachricht irrt?mlicherweise erhalten haben, benachrichtigen Sie uns bitte umgehend, indem Sie >> eine Antwort senden, und l?schen Sie bitte diese E-Mail und Ihre Antwort darauf. S?mtliche >> aufgef?hrten Ansichten oder Meinungen sind ausschlie?lich diejenigen des Autors und entsprechen >> nicht notwendigerweise denen des Unternehmens Intergraph. >> >> This E-Mail (and any attachments) may be confidential and protected by legal privilege. If you >> are not the intended recipient please notify us immediately by replying to the sender and delete >> this E-Mail and your reply from your system. All the views and opinions published here are solely >> based on the author's own opinion and should not be considered necessarily as reflecting the >> opinion of Intergraph. >> >> -----Original Message----- >> >> From: Anton V. Tarasov [mailto:anton.tarasov at oracle.com] >> >> Sent: Tuesday, June 23, 2015 5:46 PM >> >> To: Kevin Rushforth; Hruda, Steve >> >> Cc: openjfx-dev at openjdk.java.net >> >> Subject: Re: Patch for JDK-8090098 - [regression] Webview - getTimezoneOffset() of a ISO strings >> returns a wrong value >> >> On 23.06.2015 17:48, Kevin Rushforth wrote: >> >> > Hi Steve, >> >> > >> >> > Thank you for taking the time to create this patch. I will add this information to the bug report. >> >> > >> >> > Since your OCA is in progress we will take a look at your patch, but >> >> > will need indication from the OCA office that it the OCA has been >> >> > received before we could push it. And just to be clear, you won't have >> >> > access to the repository even with an OCA. What the OCA will do is allow you to contribute >> patches. >> >> > >> >> > I will note that it is likely too late for 8u60, but Anton can >> >> > evaluate it and post his comment in the bug report. >> >> Kevin, >> >> I'm checking it. >> >> Steve, thanks for the participation! >> >> Regards, >> >> Anton. >> >> > >> >> > -- Kevin >> >> > >> >> > >> >> > Hruda, Steve wrote: >> >> >> Hi, >> >> >> I've created a 8u-dev patch for the following WeKit regression which comes with 8u60. >> >> >>https://bugs.openjdk.java.net/browse/JDK-8090098 >> >> >> >> >> >> Please can someone of you apply this patch to fix the >> >> >> getTimezoneOffset() issue. I have no access to the repository -> my OCA is still pending. >> >> >> >> >> >> In addition I tried to test this patch , but I wasn't able to build >> >> >> the necessary jfxwebkit.dll on my windows system >> >> >> (https://www.mail-archive.com/openjfx-dev at openjdk.java.net/msg09439.h >> >> >> tml )..... but I got no compile erros on Mac. >> >> >> >> >> >> Patch download: >> >> >>https://drive.google.com/file/d/0B7P_rknS1TWxM3BSTTU2OVZ4dGM/view?usp >> >> >> =sharing >> >> >> >> >> >> The patch includes the following WebKit fixes: >> >> >> Changeset 174377 - [Win] DateMath's calculateUTFOffset does not account for DST. >> >> >>http://trac.webkit.org/changeset/174377 >> >> >> >> >> >> Changeset 175078 - String(new Date(Mar 30 2014 01:00:00)) is wrong >> >> >> in CET >> >> >>http://trac.webkit.org/changeset/175078 >> >> >> >> >> >> Changeset 181360 - [Win] 17 different JSC tests started to fail in >> >> >> DST >> >> >>http://trac.webkit.org/changeset/181360 >> >> >> >> >> >> Please let me know if you need further information. >> >> >> >> >> >> Thanks in advance! >> >> >> Best Regards >> >> >> Steve >> >> >> >> >> >> >> >> >> >> >> >> Diese E-Mail wurde versandt im Auftrag des Unternehmens Intergraph Ges.m.b.H. >> >> >> Vertretungsberechtigte Gesch?ftsf?hrer: Maximilian Weber Sitz der >> >> >> Gesellschaft: Margaretenstra?e 70/I/1, 1050 Wien, ?sterreich, Tel. >> >> >> +43 (1) 9610567-0 Eingetragen beim Handelsgericht Wien, >> >> >> Firmenbuch-Nr.: FN 116859 b Umsatzsteuer-Identifikationsnummer / >> >> >> VAT-ID: ATU15138401, Steuer-Nummer: 264/4807 >> >> >> >> >> >> This E-Mail has been sent on behalf of the company Intergraph Ges.m.b.H. >> >> >> Authorised Managing Directors: Maximilian Weber Registered office and >> >> >> Austrian headquarters: Margaretenstr. 70/I/1, 1050 Wien, Austria, >> >> >> Tel. +43 >> >> >> (1) 9610567-0 >> >> >> The company is recorded at the commercial court of Vienna under the >> >> >> company register number FN >> >> >> 116859 b >> >> >> VAT-ID: ATU15138401, Austrian Tax ID: 264/4807 >> >> >> >> >> >> Diese E-Mail (mit zugeh?rigen Dateien) enth?lt m?glicherweise >> >> >> Informationen, die vertraulich sind, dem Urheberrecht unterliegen >> >> >> oder ein Gesch?ftsgeheimnis darstellen. Falls Sie diese Nachricht >> >> >> irrt?mlicherweise erhalten haben, benachrichtigen Sie uns bitte >> >> >> umgehend, indem Sie eine Antwort senden, und l?schen Sie bitte diese >> >> >> E-Mail und Ihre Antwort darauf. S?mtliche aufgef?hrten Ansichten oder Meinungen sind >> ausschlie?lich diejenigen des Autors und entsprechen nicht notwendigerweise denen des >> Unternehmens Intergraph. >> >> >> >> >> >> This E-Mail (and any attachments) may be confidential and protected >> >> >> by legal privilege. If you are not the intended recipient please >> >> >> notify us immediately by replying to the sender and delete this >> >> >> E-Mail and your reply from your system. All the views and opinions >> >> >> published here are solely based on the author's own opinion and should not be considered >> necessarily as reflecting the opinion of Intergraph. >> >> >> >> >> >> >> > From steve.hruda at hexagongeospatial.com Tue Jun 30 18:13:51 2015 From: steve.hruda at hexagongeospatial.com (Hruda, Steve) Date: Tue, 30 Jun 2015 18:13:51 +0000 Subject: Patch for JDK-8090098 - [regression] Webview - getTimezoneOffset() of a ISO strings returns a wrong value In-Reply-To: <5592D943.3090407@oracle.com> References: <559191AA.8030800@oracle.com> <5592D943.3090407@oracle.com> Message-ID: Hi Anton, thanks for the detailed information and the good news. You talk about JDK's jira? Am I right? ..... I don't have an access for that JIRA system since the JavaFX's Jira has moved to the JDK Bug System. About the Apple stuff. I know that Apple dropped Windows Safari support and in my opinion is this a very bad situation for WebKit (in case of Windows).... and especially since Google and Opera using Google's Blink engine. In case of the JDK it would be more practicable to switch from WebKit to Blink, because this engine is still used by Companies which have Windows end-users. There is a high probability that WebKit get more such bugs if there is no big player like Google or Apple who has the man power to fix such OS dependent issues. Last questions: Do you need any additional information from my side? And is it possible to integrate this fix in 8u60? Thanks in advance! Best Regards, Steve Diese E-Mail wurde versandt im Auftrag des Unternehmens Intergraph Ges.m.b.H. Vertretungsberechtigte Gesch?ftsf?hrer: Maximilian Weber Sitz der Gesellschaft: Margaretenstra?e 70/I/1, 1050 Wien, ?sterreich, Tel. +43 (1) 9610567-0 Eingetragen beim Handelsgericht Wien, Firmenbuch-Nr.: FN 116859 b Umsatzsteuer-Identifikationsnummer / VAT-ID: ATU15138401, Steuer-Nummer: 264/4807 This E-Mail has been sent on behalf of the company Intergraph Ges.m.b.H. Authorised Managing Directors: Maximilian Weber Registered office and Austrian headquarters: Margaretenstr. 70/I/1, 1050 Wien, Austria, Tel. +43 (1) 9610567-0 The company is recorded at the commercial court of Vienna under the company register number FN 116859 b VAT-ID: ATU15138401, Austrian Tax ID: 264/4807 Diese E-Mail (mit zugeh?rigen Dateien) enth?lt m?glicherweise Informationen, die vertraulich sind, dem Urheberrecht unterliegen oder ein Gesch?ftsgeheimnis darstellen. Falls Sie diese Nachricht irrt?mlicherweise erhalten haben, benachrichtigen Sie uns bitte umgehend, indem Sie eine Antwort senden, und l?schen Sie bitte diese E-Mail und Ihre Antwort darauf. S?mtliche aufgef?hrten Ansichten oder Meinungen sind ausschlie?lich diejenigen des Autors und entsprechen nicht notwendigerweise denen des Unternehmens Intergraph. This E-Mail (and any attachments) may be confidential and protected by legal privilege. If you are not the intended recipient please notify us immediately by replying to the sender and delete this E-Mail and your reply from your system. All the views and opinions published here are solely based on the author's own opinion and should not be considered necessarily as reflecting the opinion of Intergraph. -----Original Message----- From: Anton V. Tarasov [mailto:anton.tarasov at oracle.com] Sent: Tuesday, June 30, 2015 8:01 PM To: Hruda, Steve; Kevin Rushforth Cc: openjfx-dev at openjdk.java.net Subject: Re: Patch for JDK-8090098 - [regression] Webview - getTimezoneOffset() of a ISO strings returns a wrong value Steve, I applied your suggestion and it worked on Windows. The missed check you discovered could really be a mistake in WebKit, because Apple dropped releasing (and shipping nightly builds for) Safari for Windows at 2012. Safari 5.1.7 was the last version. I downloaded and checked it. The date bug is not reproducible with it, but this gives us almost nothing taking into account the version is much outdated. So that Windows code path might not have been well tested, since http://trac.webkit.org/changeset/159892 was commited... (WebKit Win port is still supported and can be built on your own.) What I can do else to verify the changes is to run WebKit LayoutTests aimed at date testing and see if there're no regressions. Also, please put the info you posted into JIRA. Regards, Anton. On 29.06.2015 21:42, Anton Tarasov wrote: > Hi Steve, > > Ok, I'll investigate it. > > Thanks, > Anton. > > On 29.06.2015 18:39, Hruda, Steve wrote: >> >> Hi Anton & Kevin, >> >> we read your comments in the JDK bug system and analyzed WebKit's changesets again. >> >> We?ve found the code which made this regression. >> >> http://trac.webkit.org/changeset/159892 >> >> This changeset doesn't handle one special case, which was handled by the previous code.... >> >> double diff = ((localSystemTime.wHour - offsetHour) * secondsPerHour) >> + ((localSystemTime.wMinute >> - offsetMinute) *60); >> >> >> (http://trac.webkit.org/browser/trunk/Source/WTF/wtf/DateMath.cpp?ann >> otate=blame#L481 ) >> >> The diff is wrong if the calculated the offsetTime is one day before >> in case of the extreme values (e.g. midnight) where the offsetHour of the UTC time is 23 because of the day difference. >> >> In case of all other OS systems you will see the same code -> >> http://trac.webkit.org/browser/trunk/Source/WTF/wtf/DateMath.cpp?anno >> tate=blame#L495 >> >> But there are two additional lines -> 497 & 497 which fixes this >> special case? >> >> *if*(diff<0) >> >> diff += secondsPerDay; >> >> >> That means ?. >> >> localSystemTime.wHour = 0; >> >> offsetHour=23 ? which causes a negative value ? and the >> diff+=secondsPerDay ensures that the diff result would be one Hour >> instead of -23 hours >> >> We?ve found the attached V8DateTests.js (renamed to .txt) and >> adjusted it a little bit to get the results logged in the browsers console. >> >> As you can see at ?ResulBeforeOurBugFix.txt? and >> ?ResultAfterOurBugFix.txt?, we were able to fix >> 6 tests which failed before out bug fix. >> >> assertEquals("Sat Oct 25 2014 23:00:00 GMT+0200 (W. Europe Daylight >> Time)", >> >> (new Date(2014, 9, 25, 23, 0)).toString()); >> >> assertEquals("Sat, 25 Oct 2014 21:00:00 GMT", >> >> (new Date(2014, 9, 25, 23, 0)).toUTCString()); >> >> assertEquals("Sat Oct 25 2014 23:59:00 GMT+0200 (W. Europe Daylight >> Time)", >> >> (new Date(2014, 9, 25, 23, 59)).toString()); >> >> assertEquals("Sat, 25 Oct 2014 21:59:00 GMT", >> >> (new Date(2014, 9, 25, 23, 59)).toUTCString()); >> >> assertEquals("Sun Oct 26 2014 00:00:00 GMT+0200 (W. Europe Daylight >> Time)", >> >> (new Date(2014, 9, 26, 0, 0)).toString()); >> >> assertEquals("Sun Oct 26 2014 00:59:00 GMT+0200 (W. Europe Daylight >> Time)", >> >> (new Date(2014, 9, 26, 0, 59)).toString()); >> >> In addition we found out that WebKit also have problems in case of >> Windows in case of the change from winter to summer time. >> >> *_Winter to summer time:_* >> >> assertEquals("Sun Mar 30 2014 03:00:00 GMT+0200 (W. Europe Daylight >> Time)", >> >> (new Date(2014, 2, 30, 2, 0)).toString()); >> >> assertEquals("Sun, 30 Mar 2014 01:00:00 GMT", >> >> (new Date(2014, 2, 30, 2, 0)).toUTCString()); >> >> assertEquals("Sun Mar 30 2014 03:59:00 GMT+0200 (W. Europe Daylight >> Time)", >> >> (new Date(2014, 2, 30, 2, 59)).toString()); >> >> assertEquals("Sun, 30 Mar 2014 01:59:00 GMT", >> >> (new Date(2014, 2, 30, 2, 59)).toUTCString()); >> >> *_Summer to winter time:_* >> >> assertEquals("Sun Oct 26 2014 02:00:00 GMT+0200 (W. Europe Daylight >> Time)", >> >> (new Date(2014, 9, 26, 2, 0)).toString()); >> >> assertEquals("Sun, 26 Oct 2014 00:00:00 GMT", >> >> (new Date(2014, 9, 26, 2, 0)).toUTCString()); >> >> assertEquals("Sun Oct 26 2014 02:59:00 GMT+0200 (W. Europe Daylight >> Time)", >> >> (new Date(2014, 9, 26, 2, 59)).toString()); >> >> assertEquals("Sun, 26 Oct 2014 00:59:00 GMT", >> >> (new Date(2014, 9, 26, 2, 59)).toUTCString()); >> >> We will try to find a solution for that, but I think that the >> priority of this issue is lower than the priority of the opened regression. >> >> It would be amazing if you can add the patch of my previous and these >> additional two lines >> (DateMath.cpp) to the JDK8u60. >> >> Best Regards, >> >> Steve >> >> >> Diese E-Mail wurde versandt im Auftrag des Unternehmens Intergraph Ges.m.b.H. >> Vertretungsberechtigte Gesch?ftsf?hrer: Maximilian Weber Sitz der >> Gesellschaft: Margaretenstra?e 70/I/1, 1050 Wien, ?sterreich, Tel. >> +43 (1) 9610567-0 Eingetragen beim Handelsgericht Wien, >> Firmenbuch-Nr.: FN 116859 b Umsatzsteuer-Identifikationsnummer / >> VAT-ID: ATU15138401, Steuer-Nummer: 264/4807 >> >> This E-Mail has been sent on behalf of the company Intergraph Ges.m.b.H. >> Authorised Managing Directors: Maximilian Weber Registered office and >> Austrian headquarters: Margaretenstr. 70/I/1, 1050 Wien, Austria, >> Tel. +43 >> (1) 9610567-0 >> The company is recorded at the commercial court of Vienna under the >> company register number FN >> 116859 b >> VAT-ID: ATU15138401, Austrian Tax ID: 264/4807 >> >> Diese E-Mail (mit zugeh?rigen Dateien) enth?lt m?glicherweise >> Informationen, die vertraulich sind, dem Urheberrecht unterliegen >> oder ein Gesch?ftsgeheimnis darstellen. Falls Sie diese Nachricht >> irrt?mlicherweise erhalten haben, benachrichtigen Sie uns bitte >> umgehend, indem Sie eine Antwort senden, und l?schen Sie bitte diese >> E-Mail und Ihre Antwort darauf. S?mtliche aufgef?hrten Ansichten oder Meinungen sind ausschlie?lich diejenigen des Autors und entsprechen nicht notwendigerweise denen des Unternehmens Intergraph. >> >> This E-Mail (and any attachments) may be confidential and protected >> by legal privilege. If you are not the intended recipient please >> notify us immediately by replying to the sender and delete this >> E-Mail and your reply from your system. All the views and opinions >> published here are solely based on the author's own opinion and should not be considered necessarily as reflecting the opinion of Intergraph. >> >> -----Original Message----- >> >> From: openjfx-dev [mailto:openjfx-dev-bounces at openjdk.java.net] On >> Behalf Of Hruda, Steve >> >> Sent: Tuesday, June 23, 2015 6:26 PM >> >> To: Anton V. Tarasov; Kevin Rushforth >> >> Cc: openjfx-dev at openjdk.java.net >> >> Subject: RE: Patch for JDK-8090098 - [regression] Webview - >> getTimezoneOffset() of a ISO strings returns a wrong value >> >> Very cool Anton. >> >> I would be great if that pach could be added to 8u60, otherwise our >> all our customers have to avoid Java 8u60. >> >> Regards, >> >> Steve >> >> Diese E-Mail wurde versandt im Auftrag des Unternehmens Intergraph Ges.m.b.H. >> >> Vertretungsberechtigte Gesch?ftsf?hrer: Maximilian Weber Sitz der >> Gesellschaft: Margaretenstra?e 70/I/1, 1050 Wien, ?sterreich, Tel. >> +43 (1) 9610567-0 Eingetragen beim Handelsgericht Wien, >> Firmenbuch-Nr.: FN 116859 b Umsatzsteuer-Identifikationsnummer / >> VAT-ID: ATU15138401, >> Steuer-Nummer: 264/4807 >> >> This E-Mail has been sent on behalf of the company Intergraph Ges.m.b.H. >> >> Authorised Managing Directors: Maximilian Weber Registered office and Austrian headquarters: >> Margaretenstr. 70/I/1, 1050 Wien, Austria, Tel. +43 (1) 9610567-0 The >> company is recorded at the commercial court of Vienna under the >> company register number FN 116859 b >> >> VAT-ID: ATU15138401, Austrian Tax ID: 264/4807 >> >> Diese E-Mail (mit zugeh?rigen Dateien) enth?lt m?glicherweise >> Informationen, die vertraulich sind, dem Urheberrecht unterliegen >> oder ein Gesch?ftsgeheimnis darstellen. Falls Sie diese Nachricht >> irrt?mlicherweise erhalten haben, benachrichtigen Sie uns bitte >> umgehend, indem Sie eine Antwort senden, und l?schen Sie bitte diese >> E-Mail und Ihre Antwort darauf. S?mtliche aufgef?hrten Ansichten oder Meinungen sind ausschlie?lich diejenigen des Autors und entsprechen nicht notwendigerweise denen des Unternehmens Intergraph. >> >> This E-Mail (and any attachments) may be confidential and protected >> by legal privilege. If you are not the intended recipient please >> notify us immediately by replying to the sender and delete this >> E-Mail and your reply from your system. All the views and opinions >> published here are solely based on the author's own opinion and should not be considered necessarily as reflecting the opinion of Intergraph. >> >> -----Original Message----- >> >> From: Anton V. Tarasov [mailto:anton.tarasov at oracle.com] >> >> Sent: Tuesday, June 23, 2015 5:46 PM >> >> To: Kevin Rushforth; Hruda, Steve >> >> Cc: openjfx-dev at openjdk.java.net >> >> Subject: Re: Patch for JDK-8090098 - [regression] Webview - >> getTimezoneOffset() of a ISO strings returns a wrong value >> >> On 23.06.2015 17:48, Kevin Rushforth wrote: >> >> > Hi Steve, >> >> > >> >> > Thank you for taking the time to create this patch. I will add this information to the bug report. >> >> > >> >> > Since your OCA is in progress we will take a look at your patch, >> > but >> >> > will need indication from the OCA office that it the OCA has been >> >> > received before we could push it. And just to be clear, you won't >> > have >> >> > access to the repository even with an OCA. What the OCA will do is >> > allow you to contribute >> patches. >> >> > >> >> > I will note that it is likely too late for 8u60, but Anton can >> >> > evaluate it and post his comment in the bug report. >> >> Kevin, >> >> I'm checking it. >> >> Steve, thanks for the participation! >> >> Regards, >> >> Anton. >> >> > >> >> > -- Kevin >> >> > >> >> > >> >> > Hruda, Steve wrote: >> >> >> Hi, >> >> >> I've created a 8u-dev patch for the following WeKit regression which comes with 8u60. >> >> >>https://bugs.openjdk.java.net/browse/JDK-8090098 >> >> >> >> >> >> Please can someone of you apply this patch to fix the >> >> >> getTimezoneOffset() issue. I have no access to the repository -> my OCA is still pending. >> >> >> >> >> >> In addition I tried to test this patch , but I wasn't able to >> >> build >> >> >> the necessary jfxwebkit.dll on my windows system >> >> >> (https://www.mail-archive.com/openjfx-dev at openjdk.java.net/msg0943 >> >> 9.h >> >> >> tml )..... but I got no compile erros on Mac. >> >> >> >> >> >> Patch download: >> >> >>https://drive.google.com/file/d/0B7P_rknS1TWxM3BSTTU2OVZ4dGM/view?u >> >>sp >> >> >> =sharing >> >> >> >> >> >> The patch includes the following WebKit fixes: >> >> >> Changeset 174377 - [Win] DateMath's calculateUTFOffset does not account for DST. >> >> >>http://trac.webkit.org/changeset/174377 >> >> >> >> >> >> Changeset 175078 - String(new Date(Mar 30 2014 01:00:00)) is >> >> wrong >> >> >> in CET >> >> >>http://trac.webkit.org/changeset/175078 >> >> >> >> >> >> Changeset 181360 - [Win] 17 different JSC tests started to fail in >> >> >> DST >> >> >>http://trac.webkit.org/changeset/181360 >> >> >> >> >> >> Please let me know if you need further information. >> >> >> >> >> >> Thanks in advance! >> >> >> Best Regards >> >> >> Steve >> >> >> >> >> >> >> >> >> >> >> >> Diese E-Mail wurde versandt im Auftrag des Unternehmens Intergraph Ges.m.b.H. >> >> >> Vertretungsberechtigte Gesch?ftsf?hrer: Maximilian Weber Sitz der >> >> >> Gesellschaft: Margaretenstra?e 70/I/1, 1050 Wien, ?sterreich, Tel. >> >> >> +43 (1) 9610567-0 Eingetragen beim Handelsgericht Wien, >> >> >> Firmenbuch-Nr.: FN 116859 b Umsatzsteuer-Identifikationsnummer / >> >> >> VAT-ID: ATU15138401, Steuer-Nummer: 264/4807 >> >> >> >> >> >> This E-Mail has been sent on behalf of the company Intergraph Ges.m.b.H. >> >> >> Authorised Managing Directors: Maximilian Weber Registered office >> >> and >> >> >> Austrian headquarters: Margaretenstr. 70/I/1, 1050 Wien, Austria, >> >> >> Tel. +43 >> >> >> (1) 9610567-0 >> >> >> The company is recorded at the commercial court of Vienna under >> >> the >> >> >> company register number FN >> >> >> 116859 b >> >> >> VAT-ID: ATU15138401, Austrian Tax ID: 264/4807 >> >> >> >> >> >> Diese E-Mail (mit zugeh?rigen Dateien) enth?lt m?glicherweise >> >> >> Informationen, die vertraulich sind, dem Urheberrecht unterliegen >> >> >> oder ein Gesch?ftsgeheimnis darstellen. Falls Sie diese Nachricht >> >> >> irrt?mlicherweise erhalten haben, benachrichtigen Sie uns bitte >> >> >> umgehend, indem Sie eine Antwort senden, und l?schen Sie bitte >> >> diese >> >> >> E-Mail und Ihre Antwort darauf. S?mtliche aufgef?hrten Ansichten >> >> oder Meinungen sind >> ausschlie?lich diejenigen des Autors und entsprechen nicht >> notwendigerweise denen des Unternehmens Intergraph. >> >> >> >> >> >> This E-Mail (and any attachments) may be confidential and >> >> protected >> >> >> by legal privilege. If you are not the intended recipient please >> >> >> notify us immediately by replying to the sender and delete this >> >> >> E-Mail and your reply from your system. All the views and opinions >> >> >> published here are solely based on the author's own opinion and >> >> should not be considered >> necessarily as reflecting the opinion of Intergraph. >> >> >> >> >> >> >> > From anton.tarasov at oracle.com Tue Jun 30 18:39:38 2015 From: anton.tarasov at oracle.com (Anton V. Tarasov) Date: Tue, 30 Jun 2015 21:39:38 +0300 Subject: Patch for JDK-8090098 - [regression] Webview - getTimezoneOffset() of a ISO strings returns a wrong value In-Reply-To: References: <559191AA.8030800@oracle.com> <5592D943.3090407@oracle.com> Message-ID: <5592E269.6050200@oracle.com> On 30.06.2015 21:13, Hruda, Steve wrote: > Hi Anton, > thanks for the detailed information and the good news. > > You talk about JDK's jira? Am I right? ..... I don't have an access for that JIRA system since the JavaFX's Jira has moved to the JDK Bug System. Ah, ok. Then I'll quote your e-mail. > > About the Apple stuff. > I know that Apple dropped Windows Safari support and in my opinion is this a very bad situation for WebKit (in case of Windows).... and especially since Google and Opera using Google's Blink engine. > > In case of the JDK it would be more practicable to switch from WebKit to Blink, because this engine is still used by Companies which have Windows end-users. > > There is a high probability that WebKit get more such bugs if there is no big player like Google or Apple who has the man power to fix such OS dependent issues. I see. However, switching to Blink is another story. Honestly, we're not planning it in the nearest future. This requires extra resources which we don't have at the moment... > > Last questions: > Do you need any additional information from my side? And is it possible to integrate this fix in 8u60? From my side, I'll do a sanity check with WebKit LayoutTests, then if it goes well, we can consider commiting this to 8u60. @Kevin, do you think we can? Also, as an option for you (Steve). You can post the changes to the WebKit alias and ask if they think this is a valid fix for the issue. Any confirmation from the WebKit team would help us to make sure the fix is reliable. Thanks! Anton. > > Thanks in advance! > Best Regards, > Steve > > > > > Diese E-Mail wurde versandt im Auftrag des Unternehmens Intergraph Ges.m.b.H. > Vertretungsberechtigte Gesch?ftsf?hrer: Maximilian Weber > Sitz der Gesellschaft: Margaretenstra?e 70/I/1, 1050 Wien, ?sterreich, Tel. +43 (1) 9610567-0 > Eingetragen beim Handelsgericht Wien, Firmenbuch-Nr.: FN 116859 b > Umsatzsteuer-Identifikationsnummer / VAT-ID: ATU15138401, Steuer-Nummer: 264/4807 > > This E-Mail has been sent on behalf of the company Intergraph Ges.m.b.H. > Authorised Managing Directors: Maximilian Weber > Registered office and Austrian headquarters: Margaretenstr. 70/I/1, 1050 Wien, Austria, Tel. +43 (1) 9610567-0 > The company is recorded at the commercial court of Vienna under the company register number FN 116859 b > VAT-ID: ATU15138401, Austrian Tax ID: 264/4807 > > Diese E-Mail (mit zugeh?rigen Dateien) enth?lt m?glicherweise Informationen, die vertraulich sind, dem Urheberrecht unterliegen oder ein Gesch?ftsgeheimnis darstellen. Falls Sie diese Nachricht irrt?mlicherweise erhalten haben, benachrichtigen Sie uns bitte umgehend, indem Sie eine Antwort senden, und l?schen Sie bitte diese E-Mail und Ihre Antwort darauf. S?mtliche aufgef?hrten Ansichten oder Meinungen sind ausschlie?lich diejenigen des Autors und entsprechen nicht notwendigerweise denen des Unternehmens Intergraph. > > This E-Mail (and any attachments) may be confidential and protected by legal privilege. If you are not the intended recipient please notify us immediately by replying to the sender and delete this E-Mail and your reply from your system. All the views and opinions published here are solely based on the author's own opinion and should not be considered necessarily as reflecting the opinion of Intergraph. > > > -----Original Message----- > From: Anton V. Tarasov [mailto:anton.tarasov at oracle.com] > Sent: Tuesday, June 30, 2015 8:01 PM > To: Hruda, Steve; Kevin Rushforth > Cc: openjfx-dev at openjdk.java.net > Subject: Re: Patch for JDK-8090098 - [regression] Webview - getTimezoneOffset() of a ISO strings returns a wrong value > > Steve, > > I applied your suggestion and it worked on Windows. > > The missed check you discovered could really be a mistake in WebKit, because Apple dropped releasing (and shipping nightly builds for) Safari for Windows at 2012. > Safari 5.1.7 was the last version. I downloaded and checked it. The date bug is not reproducible with it, but this gives us almost nothing taking into account the version is much outdated. > > So that Windows code path might not have been well tested, since > http://trac.webkit.org/changeset/159892 was commited... > > (WebKit Win port is still supported and can be built on your own.) > > What I can do else to verify the changes is to run WebKit LayoutTests aimed at date testing and see if there're no regressions. > > Also, please put the info you posted into JIRA. > > Regards, > Anton. > > On 29.06.2015 21:42, Anton Tarasov wrote: >> Hi Steve, >> >> Ok, I'll investigate it. >> >> Thanks, >> Anton. >> >> On 29.06.2015 18:39, Hruda, Steve wrote: >>> Hi Anton & Kevin, >>> >>> we read your comments in the JDK bug system and analyzed WebKit's changesets again. >>> >>> We?ve found the code which made this regression. >>> >>> http://trac.webkit.org/changeset/159892 >>> >>> This changeset doesn't handle one special case, which was handled by the previous code.... >>> >>> double diff = ((localSystemTime.wHour - offsetHour) * secondsPerHour) >>> + ((localSystemTime.wMinute >>> - offsetMinute) *60); >>> >>> >>> (http://trac.webkit.org/browser/trunk/Source/WTF/wtf/DateMath.cpp?ann >>> otate=blame#L481 ) >>> >>> The diff is wrong if the calculated the offsetTime is one day before >>> in case of the extreme values (e.g. midnight) where the offsetHour of the UTC time is 23 because of the day difference. >>> >>> In case of all other OS systems you will see the same code -> >>> http://trac.webkit.org/browser/trunk/Source/WTF/wtf/DateMath.cpp?anno >>> tate=blame#L495 >>> >>> But there are two additional lines -> 497 & 497 which fixes this >>> special case? >>> >>> *if*(diff<0) >>> >>> diff += secondsPerDay; >>> >>> >>> That means ?. >>> >>> localSystemTime.wHour = 0; >>> >>> offsetHour=23 ? which causes a negative value ? and the >>> diff+=secondsPerDay ensures that the diff result would be one Hour >>> instead of -23 hours >>> >>> We?ve found the attached V8DateTests.js (renamed to .txt) and >>> adjusted it a little bit to get the results logged in the browsers console. >>> >>> As you can see at ?ResulBeforeOurBugFix.txt? and >>> ?ResultAfterOurBugFix.txt?, we were able to fix >>> 6 tests which failed before out bug fix. >>> >>> assertEquals("Sat Oct 25 2014 23:00:00 GMT+0200 (W. Europe Daylight >>> Time)", >>> >>> (new Date(2014, 9, 25, 23, 0)).toString()); >>> >>> assertEquals("Sat, 25 Oct 2014 21:00:00 GMT", >>> >>> (new Date(2014, 9, 25, 23, 0)).toUTCString()); >>> >>> assertEquals("Sat Oct 25 2014 23:59:00 GMT+0200 (W. Europe Daylight >>> Time)", >>> >>> (new Date(2014, 9, 25, 23, 59)).toString()); >>> >>> assertEquals("Sat, 25 Oct 2014 21:59:00 GMT", >>> >>> (new Date(2014, 9, 25, 23, 59)).toUTCString()); >>> >>> assertEquals("Sun Oct 26 2014 00:00:00 GMT+0200 (W. Europe Daylight >>> Time)", >>> >>> (new Date(2014, 9, 26, 0, 0)).toString()); >>> >>> assertEquals("Sun Oct 26 2014 00:59:00 GMT+0200 (W. Europe Daylight >>> Time)", >>> >>> (new Date(2014, 9, 26, 0, 59)).toString()); >>> >>> In addition we found out that WebKit also have problems in case of >>> Windows in case of the change from winter to summer time. >>> >>> *_Winter to summer time:_* >>> >>> assertEquals("Sun Mar 30 2014 03:00:00 GMT+0200 (W. Europe Daylight >>> Time)", >>> >>> (new Date(2014, 2, 30, 2, 0)).toString()); >>> >>> assertEquals("Sun, 30 Mar 2014 01:00:00 GMT", >>> >>> (new Date(2014, 2, 30, 2, 0)).toUTCString()); >>> >>> assertEquals("Sun Mar 30 2014 03:59:00 GMT+0200 (W. Europe Daylight >>> Time)", >>> >>> (new Date(2014, 2, 30, 2, 59)).toString()); >>> >>> assertEquals("Sun, 30 Mar 2014 01:59:00 GMT", >>> >>> (new Date(2014, 2, 30, 2, 59)).toUTCString()); >>> >>> *_Summer to winter time:_* >>> >>> assertEquals("Sun Oct 26 2014 02:00:00 GMT+0200 (W. Europe Daylight >>> Time)", >>> >>> (new Date(2014, 9, 26, 2, 0)).toString()); >>> >>> assertEquals("Sun, 26 Oct 2014 00:00:00 GMT", >>> >>> (new Date(2014, 9, 26, 2, 0)).toUTCString()); >>> >>> assertEquals("Sun Oct 26 2014 02:59:00 GMT+0200 (W. Europe Daylight >>> Time)", >>> >>> (new Date(2014, 9, 26, 2, 59)).toString()); >>> >>> assertEquals("Sun, 26 Oct 2014 00:59:00 GMT", >>> >>> (new Date(2014, 9, 26, 2, 59)).toUTCString()); >>> >>> We will try to find a solution for that, but I think that the >>> priority of this issue is lower than the priority of the opened regression. >>> >>> It would be amazing if you can add the patch of my previous and these >>> additional two lines >>> (DateMath.cpp) to the JDK8u60. >>> >>> Best Regards, >>> >>> Steve >>> >>> >>> Diese E-Mail wurde versandt im Auftrag des Unternehmens Intergraph Ges.m.b.H. >>> Vertretungsberechtigte Gesch?ftsf?hrer: Maximilian Weber Sitz der >>> Gesellschaft: Margaretenstra?e 70/I/1, 1050 Wien, ?sterreich, Tel. >>> +43 (1) 9610567-0 Eingetragen beim Handelsgericht Wien, >>> Firmenbuch-Nr.: FN 116859 b Umsatzsteuer-Identifikationsnummer / >>> VAT-ID: ATU15138401, Steuer-Nummer: 264/4807 >>> >>> This E-Mail has been sent on behalf of the company Intergraph Ges.m.b.H. >>> Authorised Managing Directors: Maximilian Weber Registered office and >>> Austrian headquarters: Margaretenstr. 70/I/1, 1050 Wien, Austria, >>> Tel. +43 >>> (1) 9610567-0 >>> The company is recorded at the commercial court of Vienna under the >>> company register number FN >>> 116859 b >>> VAT-ID: ATU15138401, Austrian Tax ID: 264/4807 >>> >>> Diese E-Mail (mit zugeh?rigen Dateien) enth?lt m?glicherweise >>> Informationen, die vertraulich sind, dem Urheberrecht unterliegen >>> oder ein Gesch?ftsgeheimnis darstellen. Falls Sie diese Nachricht >>> irrt?mlicherweise erhalten haben, benachrichtigen Sie uns bitte >>> umgehend, indem Sie eine Antwort senden, und l?schen Sie bitte diese >>> E-Mail und Ihre Antwort darauf. S?mtliche aufgef?hrten Ansichten oder Meinungen sind ausschlie?lich diejenigen des Autors und entsprechen nicht notwendigerweise denen des Unternehmens Intergraph. >>> >>> This E-Mail (and any attachments) may be confidential and protected >>> by legal privilege. If you are not the intended recipient please >>> notify us immediately by replying to the sender and delete this >>> E-Mail and your reply from your system. All the views and opinions >>> published here are solely based on the author's own opinion and should not be considered necessarily as reflecting the opinion of Intergraph. >>> >>> -----Original Message----- >>> >>> From: openjfx-dev [mailto:openjfx-dev-bounces at openjdk.java.net] On >>> Behalf Of Hruda, Steve >>> >>> Sent: Tuesday, June 23, 2015 6:26 PM >>> >>> To: Anton V. Tarasov; Kevin Rushforth >>> >>> Cc: openjfx-dev at openjdk.java.net >>> >>> Subject: RE: Patch for JDK-8090098 - [regression] Webview - >>> getTimezoneOffset() of a ISO strings returns a wrong value >>> >>> Very cool Anton. >>> >>> I would be great if that pach could be added to 8u60, otherwise our >>> all our customers have to avoid Java 8u60. >>> >>> Regards, >>> >>> Steve >>> >>> Diese E-Mail wurde versandt im Auftrag des Unternehmens Intergraph Ges.m.b.H. >>> >>> Vertretungsberechtigte Gesch?ftsf?hrer: Maximilian Weber Sitz der >>> Gesellschaft: Margaretenstra?e 70/I/1, 1050 Wien, ?sterreich, Tel. >>> +43 (1) 9610567-0 Eingetragen beim Handelsgericht Wien, >>> Firmenbuch-Nr.: FN 116859 b Umsatzsteuer-Identifikationsnummer / >>> VAT-ID: ATU15138401, >>> Steuer-Nummer: 264/4807 >>> >>> This E-Mail has been sent on behalf of the company Intergraph Ges.m.b.H. >>> >>> Authorised Managing Directors: Maximilian Weber Registered office and Austrian headquarters: >>> Margaretenstr. 70/I/1, 1050 Wien, Austria, Tel. +43 (1) 9610567-0 The >>> company is recorded at the commercial court of Vienna under the >>> company register number FN 116859 b >>> >>> VAT-ID: ATU15138401, Austrian Tax ID: 264/4807 >>> >>> Diese E-Mail (mit zugeh?rigen Dateien) enth?lt m?glicherweise >>> Informationen, die vertraulich sind, dem Urheberrecht unterliegen >>> oder ein Gesch?ftsgeheimnis darstellen. Falls Sie diese Nachricht >>> irrt?mlicherweise erhalten haben, benachrichtigen Sie uns bitte >>> umgehend, indem Sie eine Antwort senden, und l?schen Sie bitte diese >>> E-Mail und Ihre Antwort darauf. S?mtliche aufgef?hrten Ansichten oder Meinungen sind ausschlie?lich diejenigen des Autors und entsprechen nicht notwendigerweise denen des Unternehmens Intergraph. >>> >>> This E-Mail (and any attachments) may be confidential and protected >>> by legal privilege. If you are not the intended recipient please >>> notify us immediately by replying to the sender and delete this >>> E-Mail and your reply from your system. All the views and opinions >>> published here are solely based on the author's own opinion and should not be considered necessarily as reflecting the opinion of Intergraph. >>> >>> -----Original Message----- >>> >>> From: Anton V. Tarasov [mailto:anton.tarasov at oracle.com] >>> >>> Sent: Tuesday, June 23, 2015 5:46 PM >>> >>> To: Kevin Rushforth; Hruda, Steve >>> >>> Cc: openjfx-dev at openjdk.java.net >>> >>> Subject: Re: Patch for JDK-8090098 - [regression] Webview - >>> getTimezoneOffset() of a ISO strings returns a wrong value >>> >>> On 23.06.2015 17:48, Kevin Rushforth wrote: >>> >>>> Hi Steve, >>>> Thank you for taking the time to create this patch. I will add this information to the bug report. >>>> Since your OCA is in progress we will take a look at your patch, >>>> but >>>> will need indication from the OCA office that it the OCA has been >>>> received before we could push it. And just to be clear, you won't >>>> have >>>> access to the repository even with an OCA. What the OCA will do is >>>> allow you to contribute >>> patches. >>> >>>> I will note that it is likely too late for 8u60, but Anton can >>>> evaluate it and post his comment in the bug report. >>> Kevin, >>> >>> I'm checking it. >>> >>> Steve, thanks for the participation! >>> >>> Regards, >>> >>> Anton. >>> >>>> -- Kevin >>>> Hruda, Steve wrote: >>>>> Hi, >>>>> I've created a 8u-dev patch for the following WeKit regression which comes with 8u60. >>>>> https://bugs.openjdk.java.net/browse/JDK-8090098 >>>>> Please can someone of you apply this patch to fix the >>>>> getTimezoneOffset() issue. I have no access to the repository -> my OCA is still pending. >>>>> In addition I tried to test this patch , but I wasn't able to >>>>> build >>>>> the necessary jfxwebkit.dll on my windows system >>>>> (https://www.mail-archive.com/openjfx-dev at openjdk.java.net/msg0943 >>>>> 9.h >>>>> tml )..... but I got no compile erros on Mac. >>>>> Patch download: >>>>> https://drive.google.com/file/d/0B7P_rknS1TWxM3BSTTU2OVZ4dGM/view?u >>>>> sp >>>>> =sharing >>>>> The patch includes the following WebKit fixes: >>>>> Changeset 174377 - [Win] DateMath's calculateUTFOffset does not account for DST. >>>>> http://trac.webkit.org/changeset/174377 >>>>> Changeset 175078 - String(new Date(Mar 30 2014 01:00:00)) is >>>>> wrong >>>>> in CET >>>>> http://trac.webkit.org/changeset/175078 >>>>> Changeset 181360 - [Win] 17 different JSC tests started to fail in >>>>> DST >>>>> http://trac.webkit.org/changeset/181360 >>>>> Please let me know if you need further information. >>>>> Thanks in advance! >>>>> Best Regards >>>>> Steve >>>>> Diese E-Mail wurde versandt im Auftrag des Unternehmens Intergraph Ges.m.b.H. >>>>> Vertretungsberechtigte Gesch?ftsf?hrer: Maximilian Weber Sitz der >>>>> Gesellschaft: Margaretenstra?e 70/I/1, 1050 Wien, ?sterreich, Tel. >>>>> +43 (1) 9610567-0 Eingetragen beim Handelsgericht Wien, >>>>> Firmenbuch-Nr.: FN 116859 b Umsatzsteuer-Identifikationsnummer / >>>>> VAT-ID: ATU15138401, Steuer-Nummer: 264/4807 >>>>> This E-Mail has been sent on behalf of the company Intergraph Ges.m.b.H. >>>>> Authorised Managing Directors: Maximilian Weber Registered office >>>>> and >>>>> Austrian headquarters: Margaretenstr. 70/I/1, 1050 Wien, Austria, >>>>> Tel. +43 >>>>> (1) 9610567-0 >>>>> The company is recorded at the commercial court of Vienna under >>>>> the >>>>> company register number FN >>>>> 116859 b >>>>> VAT-ID: ATU15138401, Austrian Tax ID: 264/4807 >>>>> Diese E-Mail (mit zugeh?rigen Dateien) enth?lt m?glicherweise >>>>> Informationen, die vertraulich sind, dem Urheberrecht unterliegen >>>>> oder ein Gesch?ftsgeheimnis darstellen. Falls Sie diese Nachricht >>>>> irrt?mlicherweise erhalten haben, benachrichtigen Sie uns bitte >>>>> umgehend, indem Sie eine Antwort senden, und l?schen Sie bitte >>>>> diese >>>>> E-Mail und Ihre Antwort darauf. S?mtliche aufgef?hrten Ansichten >>>>> oder Meinungen sind >>> ausschlie?lich diejenigen des Autors und entsprechen nicht >>> notwendigerweise denen des Unternehmens Intergraph. >>> >>>>> This E-Mail (and any attachments) may be confidential and >>>>> protected >>>>> by legal privilege. If you are not the intended recipient please >>>>> notify us immediately by replying to the sender and delete this >>>>> E-Mail and your reply from your system. All the views and opinions >>>>> published here are solely based on the author's own opinion and >>>>> should not be considered >>> necessarily as reflecting the opinion of Intergraph. >>> From anton.tarasov at oracle.com Tue Jun 30 18:43:06 2015 From: anton.tarasov at oracle.com (Anton V. Tarasov) Date: Tue, 30 Jun 2015 21:43:06 +0300 Subject: JavaFx: webview print with scale 100% In-Reply-To: <1435386645.817842663@f371.i.mail.ru> References: <1434347604.864680804@f359.i.mail.ru> <55842127.5020707@oracle.com> <1435386645.817842663@f371.i.mail.ru> Message-ID: <5592E33A.8030109@oracle.com> Hi Alexander, Thanks for posting the samples. I'll check the printing stuff and will update on results. Regards, Anton. On 27.06.2015 9:30, ????????? ???????? wrote: > Hi Anton, > > I send all files. If you open index.html in IE and printpreview->set scale 100% -> print , you > will get 16.8 cm of div on paper. > > If you you print via application I did you will get quite different size. > > > ???????, 19 ???? 2015, 17:03 +03:00 ?? "Anton V. Tarasov" : > > Hi Alexander, > > Could you please create and send a simple test case (fully functioning) with the exact URL of > a page > you're printing? > > Regards, > Anotn. > > On 15.06.2015 8:53, ????????? ???????? wrote: > > To print my html page I use the following code: > > PrinterJob job =PrinterJob.createPrinterJob();if(job !=null&& job.showPrintDialog(null)){ > > webView.getEngine().print(job); > > job.endJob();} > > The problem is that webview changes the scale of printing page. For example, when I print > this html page in IE with fit to size 100% I get 16.8 cm. When I print in my java application > I get 11.4cm. The size in html file I set in pt - my width is 475pt(A4 width=595pt,so > 475pt=16.8cm). How to print with webview and to have 100% width and height? > > From steve.hruda at hexagongeospatial.com Tue Jun 30 18:50:24 2015 From: steve.hruda at hexagongeospatial.com (Hruda, Steve) Date: Tue, 30 Jun 2015 18:50:24 +0000 Subject: Patch for JDK-8090098 - [regression] Webview - getTimezoneOffset() of a ISO strings returns a wrong value In-Reply-To: <5592E269.6050200@oracle.com> References: <559191AA.8030800@oracle.com> <5592D943.3090407@oracle.com> <5592E269.6050200@oracle.com> Message-ID: Yesterday I added my patch to the associated bug entry -> https://bugs.webkit.org/show_bug.cgi?id=137003 It seems that someone landed my patch for automated commit but the WebKit Commit Bot rejected my patch because of some stupid formatting mistakes (tabs instead of spaces ...). I corrected the styling and uploaded a new patch. I set the commit-queue flag to "?" as mentioned on the https://www.webkit.org/coding/contributing.html & https://trac.webkit.org/wiki/CommitQueue page. Diese E-Mail wurde versandt im Auftrag des Unternehmens Intergraph Ges.m.b.H. Vertretungsberechtigte Gesch?ftsf?hrer: Maximilian Weber Sitz der Gesellschaft: Margaretenstra?e 70/I/1, 1050 Wien, ?sterreich, Tel. +43 (1) 9610567-0 Eingetragen beim Handelsgericht Wien, Firmenbuch-Nr.: FN 116859 b Umsatzsteuer-Identifikationsnummer / VAT-ID: ATU15138401, Steuer-Nummer: 264/4807 This E-Mail has been sent on behalf of the company Intergraph Ges.m.b.H. Authorised Managing Directors: Maximilian Weber Registered office and Austrian headquarters: Margaretenstr. 70/I/1, 1050 Wien, Austria, Tel. +43 (1) 9610567-0 The company is recorded at the commercial court of Vienna under the company register number FN 116859 b VAT-ID: ATU15138401, Austrian Tax ID: 264/4807 Diese E-Mail (mit zugeh?rigen Dateien) enth?lt m?glicherweise Informationen, die vertraulich sind, dem Urheberrecht unterliegen oder ein Gesch?ftsgeheimnis darstellen. Falls Sie diese Nachricht irrt?mlicherweise erhalten haben, benachrichtigen Sie uns bitte umgehend, indem Sie eine Antwort senden, und l?schen Sie bitte diese E-Mail und Ihre Antwort darauf. S?mtliche aufgef?hrten Ansichten oder Meinungen sind ausschlie?lich diejenigen des Autors und entsprechen nicht notwendigerweise denen des Unternehmens Intergraph. This E-Mail (and any attachments) may be confidential and protected by legal privilege. If you are not the intended recipient please notify us immediately by replying to the sender and delete this E-Mail and your reply from your system. All the views and opinions published here are solely based on the author's own opinion and should not be considered necessarily as reflecting the opinion of Intergraph. -----Original Message----- From: Anton V. Tarasov [mailto:anton.tarasov at oracle.com] Sent: Tuesday, June 30, 2015 8:40 PM To: Hruda, Steve; Kevin Rushforth Cc: openjfx-dev at openjdk.java.net Subject: Re: Patch for JDK-8090098 - [regression] Webview - getTimezoneOffset() of a ISO strings returns a wrong value On 30.06.2015 21:13, Hruda, Steve wrote: > Hi Anton, > thanks for the detailed information and the good news. > > You talk about JDK's jira? Am I right? ..... I don't have an access for that JIRA system since the JavaFX's Jira has moved to the JDK Bug System. Ah, ok. Then I'll quote your e-mail. > > About the Apple stuff. > I know that Apple dropped Windows Safari support and in my opinion is this a very bad situation for WebKit (in case of Windows).... and especially since Google and Opera using Google's Blink engine. > > In case of the JDK it would be more practicable to switch from WebKit to Blink, because this engine is still used by Companies which have Windows end-users. > > There is a high probability that WebKit get more such bugs if there is no big player like Google or Apple who has the man power to fix such OS dependent issues. I see. However, switching to Blink is another story. Honestly, we're not planning it in the nearest future. This requires extra resources which we don't have at the moment... > > Last questions: > Do you need any additional information from my side? And is it possible to integrate this fix in 8u60? From my side, I'll do a sanity check with WebKit LayoutTests, then if it goes well, we can consider commiting this to 8u60. @Kevin, do you think we can? Also, as an option for you (Steve). You can post the changes to the WebKit alias and ask if they think this is a valid fix for the issue. Any confirmation from the WebKit team would help us to make sure the fix is reliable. Thanks! Anton. > > Thanks in advance! > Best Regards, > Steve > > > > > Diese E-Mail wurde versandt im Auftrag des Unternehmens Intergraph Ges.m.b.H. > Vertretungsberechtigte Gesch?ftsf?hrer: Maximilian Weber Sitz der > Gesellschaft: Margaretenstra?e 70/I/1, 1050 Wien, ?sterreich, Tel. +43 > (1) 9610567-0 Eingetragen beim Handelsgericht Wien, Firmenbuch-Nr.: FN > 116859 b Umsatzsteuer-Identifikationsnummer / VAT-ID: ATU15138401, > Steuer-Nummer: 264/4807 > > This E-Mail has been sent on behalf of the company Intergraph Ges.m.b.H. > Authorised Managing Directors: Maximilian Weber Registered office and > Austrian headquarters: Margaretenstr. 70/I/1, 1050 Wien, Austria, Tel. > +43 (1) 9610567-0 The company is recorded at the commercial court of > Vienna under the company register number FN 116859 b > VAT-ID: ATU15138401, Austrian Tax ID: 264/4807 > > Diese E-Mail (mit zugeh?rigen Dateien) enth?lt m?glicherweise Informationen, die vertraulich sind, dem Urheberrecht unterliegen oder ein Gesch?ftsgeheimnis darstellen. Falls Sie diese Nachricht irrt?mlicherweise erhalten haben, benachrichtigen Sie uns bitte umgehend, indem Sie eine Antwort senden, und l?schen Sie bitte diese E-Mail und Ihre Antwort darauf. S?mtliche aufgef?hrten Ansichten oder Meinungen sind ausschlie?lich diejenigen des Autors und entsprechen nicht notwendigerweise denen des Unternehmens Intergraph. > > This E-Mail (and any attachments) may be confidential and protected by legal privilege. If you are not the intended recipient please notify us immediately by replying to the sender and delete this E-Mail and your reply from your system. All the views and opinions published here are solely based on the author's own opinion and should not be considered necessarily as reflecting the opinion of Intergraph. > > > -----Original Message----- > From: Anton V. Tarasov [mailto:anton.tarasov at oracle.com] > Sent: Tuesday, June 30, 2015 8:01 PM > To: Hruda, Steve; Kevin Rushforth > Cc: openjfx-dev at openjdk.java.net > Subject: Re: Patch for JDK-8090098 - [regression] Webview - > getTimezoneOffset() of a ISO strings returns a wrong value > > Steve, > > I applied your suggestion and it worked on Windows. > > The missed check you discovered could really be a mistake in WebKit, because Apple dropped releasing (and shipping nightly builds for) Safari for Windows at 2012. > Safari 5.1.7 was the last version. I downloaded and checked it. The date bug is not reproducible with it, but this gives us almost nothing taking into account the version is much outdated. > > So that Windows code path might not have been well tested, since > http://trac.webkit.org/changeset/159892 was commited... > > (WebKit Win port is still supported and can be built on your own.) > > What I can do else to verify the changes is to run WebKit LayoutTests aimed at date testing and see if there're no regressions. > > Also, please put the info you posted into JIRA. > > Regards, > Anton. > > On 29.06.2015 21:42, Anton Tarasov wrote: >> Hi Steve, >> >> Ok, I'll investigate it. >> >> Thanks, >> Anton. >> >> On 29.06.2015 18:39, Hruda, Steve wrote: >>> Hi Anton & Kevin, >>> >>> we read your comments in the JDK bug system and analyzed WebKit's changesets again. >>> >>> We?ve found the code which made this regression. >>> >>> http://trac.webkit.org/changeset/159892 >>> >>> This changeset doesn't handle one special case, which was handled by the previous code.... >>> >>> double diff = ((localSystemTime.wHour - offsetHour) * >>> secondsPerHour) >>> + ((localSystemTime.wMinute >>> - offsetMinute) *60); >>> >>> >>> (http://trac.webkit.org/browser/trunk/Source/WTF/wtf/DateMath.cpp?an >>> n >>> otate=blame#L481 ) >>> >>> The diff is wrong if the calculated the offsetTime is one day before >>> in case of the extreme values (e.g. midnight) where the offsetHour of the UTC time is 23 because of the day difference. >>> >>> In case of all other OS systems you will see the same code -> >>> http://trac.webkit.org/browser/trunk/Source/WTF/wtf/DateMath.cpp?ann >>> o >>> tate=blame#L495 >>> >>> But there are two additional lines -> 497 & 497 which fixes this >>> special case? >>> >>> *if*(diff<0) >>> >>> diff += secondsPerDay; >>> >>> >>> That means ?. >>> >>> localSystemTime.wHour = 0; >>> >>> offsetHour=23 ? which causes a negative value ? and the >>> diff+=secondsPerDay ensures that the diff result would be one Hour >>> instead of -23 hours >>> >>> We?ve found the attached V8DateTests.js (renamed to .txt) and >>> adjusted it a little bit to get the results logged in the browsers console. >>> >>> As you can see at ?ResulBeforeOurBugFix.txt? and >>> ?ResultAfterOurBugFix.txt?, we were able to fix >>> 6 tests which failed before out bug fix. >>> >>> assertEquals("Sat Oct 25 2014 23:00:00 GMT+0200 (W. Europe Daylight >>> Time)", >>> >>> (new Date(2014, 9, 25, 23, 0)).toString()); >>> >>> assertEquals("Sat, 25 Oct 2014 21:00:00 GMT", >>> >>> (new Date(2014, 9, 25, 23, 0)).toUTCString()); >>> >>> assertEquals("Sat Oct 25 2014 23:59:00 GMT+0200 (W. Europe >>> Daylight Time)", >>> >>> (new Date(2014, 9, 25, 23, 59)).toString()); >>> >>> assertEquals("Sat, 25 Oct 2014 21:59:00 GMT", >>> >>> (new Date(2014, 9, 25, 23, 59)).toUTCString()); >>> >>> assertEquals("Sun Oct 26 2014 00:00:00 GMT+0200 (W. Europe >>> Daylight Time)", >>> >>> (new Date(2014, 9, 26, 0, 0)).toString()); >>> >>> assertEquals("Sun Oct 26 2014 00:59:00 GMT+0200 (W. Europe Daylight >>> Time)", >>> >>> (new Date(2014, 9, 26, 0, 59)).toString()); >>> >>> In addition we found out that WebKit also have problems in case of >>> Windows in case of the change from winter to summer time. >>> >>> *_Winter to summer time:_* >>> >>> assertEquals("Sun Mar 30 2014 03:00:00 GMT+0200 (W. Europe Daylight >>> Time)", >>> >>> (new Date(2014, 2, 30, 2, 0)).toString()); >>> >>> assertEquals("Sun, 30 Mar 2014 01:00:00 GMT", >>> >>> (new Date(2014, 2, 30, 2, 0)).toUTCString()); >>> >>> assertEquals("Sun Mar 30 2014 03:59:00 GMT+0200 (W. Europe >>> Daylight Time)", >>> >>> (new Date(2014, 2, 30, 2, 59)).toString()); >>> >>> assertEquals("Sun, 30 Mar 2014 01:59:00 GMT", >>> >>> (new Date(2014, 2, 30, 2, 59)).toUTCString()); >>> >>> *_Summer to winter time:_* >>> >>> assertEquals("Sun Oct 26 2014 02:00:00 GMT+0200 (W. Europe Daylight >>> Time)", >>> >>> (new Date(2014, 9, 26, 2, 0)).toString()); >>> >>> assertEquals("Sun, 26 Oct 2014 00:00:00 GMT", >>> >>> (new Date(2014, 9, 26, 2, 0)).toUTCString()); >>> >>> assertEquals("Sun Oct 26 2014 02:59:00 GMT+0200 (W. Europe >>> Daylight Time)", >>> >>> (new Date(2014, 9, 26, 2, 59)).toString()); >>> >>> assertEquals("Sun, 26 Oct 2014 00:59:00 GMT", >>> >>> (new Date(2014, 9, 26, 2, 59)).toUTCString()); >>> >>> We will try to find a solution for that, but I think that the >>> priority of this issue is lower than the priority of the opened regression. >>> >>> It would be amazing if you can add the patch of my previous and >>> these additional two lines >>> (DateMath.cpp) to the JDK8u60. >>> >>> Best Regards, >>> >>> Steve >>> >>> >>> Diese E-Mail wurde versandt im Auftrag des Unternehmens Intergraph Ges.m.b.H. >>> Vertretungsberechtigte Gesch?ftsf?hrer: Maximilian Weber Sitz der >>> Gesellschaft: Margaretenstra?e 70/I/1, 1050 Wien, ?sterreich, Tel. >>> +43 (1) 9610567-0 Eingetragen beim Handelsgericht Wien, >>> Firmenbuch-Nr.: FN 116859 b Umsatzsteuer-Identifikationsnummer / >>> VAT-ID: ATU15138401, Steuer-Nummer: 264/4807 >>> >>> This E-Mail has been sent on behalf of the company Intergraph Ges.m.b.H. >>> Authorised Managing Directors: Maximilian Weber Registered office >>> and Austrian headquarters: Margaretenstr. 70/I/1, 1050 Wien, >>> Austria, Tel. +43 >>> (1) 9610567-0 >>> The company is recorded at the commercial court of Vienna under the >>> company register number FN >>> 116859 b >>> VAT-ID: ATU15138401, Austrian Tax ID: 264/4807 >>> >>> Diese E-Mail (mit zugeh?rigen Dateien) enth?lt m?glicherweise >>> Informationen, die vertraulich sind, dem Urheberrecht unterliegen >>> oder ein Gesch?ftsgeheimnis darstellen. Falls Sie diese Nachricht >>> irrt?mlicherweise erhalten haben, benachrichtigen Sie uns bitte >>> umgehend, indem Sie eine Antwort senden, und l?schen Sie bitte diese >>> E-Mail und Ihre Antwort darauf. S?mtliche aufgef?hrten Ansichten oder Meinungen sind ausschlie?lich diejenigen des Autors und entsprechen nicht notwendigerweise denen des Unternehmens Intergraph. >>> >>> This E-Mail (and any attachments) may be confidential and protected >>> by legal privilege. If you are not the intended recipient please >>> notify us immediately by replying to the sender and delete this >>> E-Mail and your reply from your system. All the views and opinions >>> published here are solely based on the author's own opinion and should not be considered necessarily as reflecting the opinion of Intergraph. >>> >>> -----Original Message----- >>> >>> From: openjfx-dev [mailto:openjfx-dev-bounces at openjdk.java.net] On >>> Behalf Of Hruda, Steve >>> >>> Sent: Tuesday, June 23, 2015 6:26 PM >>> >>> To: Anton V. Tarasov; Kevin Rushforth >>> >>> Cc: openjfx-dev at openjdk.java.net >>> >>> Subject: RE: Patch for JDK-8090098 - [regression] Webview - >>> getTimezoneOffset() of a ISO strings returns a wrong value >>> >>> Very cool Anton. >>> >>> I would be great if that pach could be added to 8u60, otherwise our >>> all our customers have to avoid Java 8u60. >>> >>> Regards, >>> >>> Steve >>> >>> Diese E-Mail wurde versandt im Auftrag des Unternehmens Intergraph Ges.m.b.H. >>> >>> Vertretungsberechtigte Gesch?ftsf?hrer: Maximilian Weber Sitz der >>> Gesellschaft: Margaretenstra?e 70/I/1, 1050 Wien, ?sterreich, Tel. >>> +43 (1) 9610567-0 Eingetragen beim Handelsgericht Wien, >>> Firmenbuch-Nr.: FN 116859 b Umsatzsteuer-Identifikationsnummer / >>> VAT-ID: ATU15138401, >>> Steuer-Nummer: 264/4807 >>> >>> This E-Mail has been sent on behalf of the company Intergraph Ges.m.b.H. >>> >>> Authorised Managing Directors: Maximilian Weber Registered office and Austrian headquarters: >>> Margaretenstr. 70/I/1, 1050 Wien, Austria, Tel. +43 (1) 9610567-0 >>> The company is recorded at the commercial court of Vienna under the >>> company register number FN 116859 b >>> >>> VAT-ID: ATU15138401, Austrian Tax ID: 264/4807 >>> >>> Diese E-Mail (mit zugeh?rigen Dateien) enth?lt m?glicherweise >>> Informationen, die vertraulich sind, dem Urheberrecht unterliegen >>> oder ein Gesch?ftsgeheimnis darstellen. Falls Sie diese Nachricht >>> irrt?mlicherweise erhalten haben, benachrichtigen Sie uns bitte >>> umgehend, indem Sie eine Antwort senden, und l?schen Sie bitte diese >>> E-Mail und Ihre Antwort darauf. S?mtliche aufgef?hrten Ansichten oder Meinungen sind ausschlie?lich diejenigen des Autors und entsprechen nicht notwendigerweise denen des Unternehmens Intergraph. >>> >>> This E-Mail (and any attachments) may be confidential and protected >>> by legal privilege. If you are not the intended recipient please >>> notify us immediately by replying to the sender and delete this >>> E-Mail and your reply from your system. All the views and opinions >>> published here are solely based on the author's own opinion and should not be considered necessarily as reflecting the opinion of Intergraph. >>> >>> -----Original Message----- >>> >>> From: Anton V. Tarasov [mailto:anton.tarasov at oracle.com] >>> >>> Sent: Tuesday, June 23, 2015 5:46 PM >>> >>> To: Kevin Rushforth; Hruda, Steve >>> >>> Cc: openjfx-dev at openjdk.java.net >>> >>> Subject: Re: Patch for JDK-8090098 - [regression] Webview - >>> getTimezoneOffset() of a ISO strings returns a wrong value >>> >>> On 23.06.2015 17:48, Kevin Rushforth wrote: >>> >>>> Hi Steve, >>>> Thank you for taking the time to create this patch. I will add this information to the bug report. >>>> Since your OCA is in progress we will take a look at your patch, >>>> but will need indication from the OCA office that it the OCA has >>>> been received before we could push it. And just to be clear, you >>>> won't have access to the repository even with an OCA. What the OCA >>>> will do is allow you to contribute >>> patches. >>> >>>> I will note that it is likely too late for 8u60, but Anton can >>>> evaluate it and post his comment in the bug report. >>> Kevin, >>> >>> I'm checking it. >>> >>> Steve, thanks for the participation! >>> >>> Regards, >>> >>> Anton. >>> >>>> -- Kevin >>>> Hruda, Steve wrote: >>>>> Hi, >>>>> I've created a 8u-dev patch for the following WeKit regression which comes with 8u60. >>>>> https://bugs.openjdk.java.net/browse/JDK-8090098 >>>>> Please can someone of you apply this patch to fix the >>>>> getTimezoneOffset() issue. I have no access to the repository -> my OCA is still pending. >>>>> In addition I tried to test this patch , but I wasn't able to >>>>> build the necessary jfxwebkit.dll on my windows system >>>>> (https://www.mail-archive.com/openjfx-dev at openjdk.java.net/msg0943 >>>>> 9.h >>>>> tml )..... but I got no compile erros on Mac. >>>>> Patch download: >>>>> https://drive.google.com/file/d/0B7P_rknS1TWxM3BSTTU2OVZ4dGM/view? >>>>> u >>>>> sp >>>>> =sharing >>>>> The patch includes the following WebKit fixes: >>>>> Changeset 174377 - [Win] DateMath's calculateUTFOffset does not account for DST. >>>>> http://trac.webkit.org/changeset/174377 >>>>> Changeset 175078 - String(new Date(Mar 30 2014 01:00:00)) is >>>>> wrong in CET >>>>> http://trac.webkit.org/changeset/175078 >>>>> Changeset 181360 - [Win] 17 different JSC tests started to fail in >>>>> DST >>>>> http://trac.webkit.org/changeset/181360 >>>>> Please let me know if you need further information. >>>>> Thanks in advance! >>>>> Best Regards >>>>> Steve >>>>> Diese E-Mail wurde versandt im Auftrag des Unternehmens Intergraph Ges.m.b.H. >>>>> Vertretungsberechtigte Gesch?ftsf?hrer: Maximilian Weber Sitz der >>>>> Gesellschaft: Margaretenstra?e 70/I/1, 1050 Wien, ?sterreich, Tel. >>>>> +43 (1) 9610567-0 Eingetragen beim Handelsgericht Wien, >>>>> Firmenbuch-Nr.: FN 116859 b Umsatzsteuer-Identifikationsnummer / >>>>> VAT-ID: ATU15138401, Steuer-Nummer: 264/4807 This E-Mail has been >>>>> sent on behalf of the company Intergraph Ges.m.b.H. >>>>> Authorised Managing Directors: Maximilian Weber Registered office >>>>> and Austrian headquarters: Margaretenstr. 70/I/1, 1050 Wien, >>>>> Austria, Tel. +43 >>>>> (1) 9610567-0 >>>>> The company is recorded at the commercial court of Vienna under >>>>> the company register number FN >>>>> 116859 b >>>>> VAT-ID: ATU15138401, Austrian Tax ID: 264/4807 Diese E-Mail (mit >>>>> zugeh?rigen Dateien) enth?lt m?glicherweise Informationen, die >>>>> vertraulich sind, dem Urheberrecht unterliegen oder ein >>>>> Gesch?ftsgeheimnis darstellen. Falls Sie diese Nachricht >>>>> irrt?mlicherweise erhalten haben, benachrichtigen Sie uns bitte >>>>> umgehend, indem Sie eine Antwort senden, und l?schen Sie bitte >>>>> diese E-Mail und Ihre Antwort darauf. S?mtliche aufgef?hrten >>>>> Ansichten oder Meinungen sind >>> ausschlie?lich diejenigen des Autors und entsprechen nicht >>> notwendigerweise denen des Unternehmens Intergraph. >>> >>>>> This E-Mail (and any attachments) may be confidential and >>>>> protected by legal privilege. If you are not the intended >>>>> recipient please notify us immediately by replying to the sender >>>>> and delete this E-Mail and your reply from your system. All the >>>>> views and opinions published here are solely based on the author's >>>>> own opinion and should not be considered >>> necessarily as reflecting the opinion of Intergraph. >>> From anton.tarasov at oracle.com Tue Jun 30 18:59:46 2015 From: anton.tarasov at oracle.com (Anton V. Tarasov) Date: Tue, 30 Jun 2015 21:59:46 +0300 Subject: Patch for JDK-8090098 - [regression] Webview - getTimezoneOffset() of a ISO strings returns a wrong value In-Reply-To: References: <559191AA.8030800@oracle.com> <5592D943.3090407@oracle.com> <5592E269.6050200@oracle.com> Message-ID: <5592E722.9050202@oracle.com> On 30.06.2015 21:50, Hruda, Steve wrote: > Yesterday I added my patch to the associated bug entry -> https://bugs.webkit.org/show_bug.cgi?id=137003 > > It seems that someone landed my patch for automated commit but the WebKit Commit Bot rejected my patch because of some stupid formatting mistakes (tabs instead of spaces ...). Oh, don't tab please ) > > I corrected the styling and uploaded a new patch. I set the commit-queue flag to "?" as mentioned on the https://www.webkit.org/coding/contributing.html & https://trac.webkit.org/wiki/CommitQueue page. > Sounds great! Looking forward for the results then. Thanks, Anton. > > > > Diese E-Mail wurde versandt im Auftrag des Unternehmens Intergraph Ges.m.b.H. > Vertretungsberechtigte Gesch?ftsf?hrer: Maximilian Weber > Sitz der Gesellschaft: Margaretenstra?e 70/I/1, 1050 Wien, ?sterreich, Tel. +43 (1) 9610567-0 > Eingetragen beim Handelsgericht Wien, Firmenbuch-Nr.: FN 116859 b > Umsatzsteuer-Identifikationsnummer / VAT-ID: ATU15138401, Steuer-Nummer: 264/4807 > > This E-Mail has been sent on behalf of the company Intergraph Ges.m.b.H. > Authorised Managing Directors: Maximilian Weber > Registered office and Austrian headquarters: Margaretenstr. 70/I/1, 1050 Wien, Austria, Tel. +43 (1) 9610567-0 > The company is recorded at the commercial court of Vienna under the company register number FN 116859 b > VAT-ID: ATU15138401, Austrian Tax ID: 264/4807 > > Diese E-Mail (mit zugeh?rigen Dateien) enth?lt m?glicherweise Informationen, die vertraulich sind, dem Urheberrecht unterliegen oder ein Gesch?ftsgeheimnis darstellen. Falls Sie diese Nachricht irrt?mlicherweise erhalten haben, benachrichtigen Sie uns bitte umgehend, indem Sie eine Antwort senden, und l?schen Sie bitte diese E-Mail und Ihre Antwort darauf. S?mtliche aufgef?hrten Ansichten oder Meinungen sind ausschlie?lich diejenigen des Autors und entsprechen nicht notwendigerweise denen des Unternehmens Intergraph. > > This E-Mail (and any attachments) may be confidential and protected by legal privilege. If you are not the intended recipient please notify us immediately by replying to the sender and delete this E-Mail and your reply from your system. All the views and opinions published here are solely based on the author's own opinion and should not be considered necessarily as reflecting the opinion of Intergraph. > > > -----Original Message----- > From: Anton V. Tarasov [mailto:anton.tarasov at oracle.com] > Sent: Tuesday, June 30, 2015 8:40 PM > To: Hruda, Steve; Kevin Rushforth > Cc: openjfx-dev at openjdk.java.net > Subject: Re: Patch for JDK-8090098 - [regression] Webview - getTimezoneOffset() of a ISO strings returns a wrong value > > On 30.06.2015 21:13, Hruda, Steve wrote: >> Hi Anton, >> thanks for the detailed information and the good news. >> >> You talk about JDK's jira? Am I right? ..... I don't have an access for that JIRA system since the JavaFX's Jira has moved to the JDK Bug System. > Ah, ok. Then I'll quote your e-mail. > >> About the Apple stuff. >> I know that Apple dropped Windows Safari support and in my opinion is this a very bad situation for WebKit (in case of Windows).... and especially since Google and Opera using Google's Blink engine. >> >> In case of the JDK it would be more practicable to switch from WebKit to Blink, because this engine is still used by Companies which have Windows end-users. >> >> There is a high probability that WebKit get more such bugs if there is no big player like Google or Apple who has the man power to fix such OS dependent issues. > I see. However, switching to Blink is another story. Honestly, we're not planning it in the nearest future. This requires extra resources which we don't have at the moment... > >> Last questions: >> Do you need any additional information from my side? And is it possible to integrate this fix in 8u60? > From my side, I'll do a sanity check with WebKit LayoutTests, then if it goes well, we can consider commiting this to 8u60. > > @Kevin, do you think we can? > > Also, as an option for you (Steve). You can post the changes to the WebKit alias and ask if they think this is a valid fix for the issue. Any confirmation from the WebKit team would help us to make sure the fix is reliable. > > Thanks! > Anton. > >> Thanks in advance! >> Best Regards, >> Steve >> >> >> >> >> Diese E-Mail wurde versandt im Auftrag des Unternehmens Intergraph Ges.m.b.H. >> Vertretungsberechtigte Gesch?ftsf?hrer: Maximilian Weber Sitz der >> Gesellschaft: Margaretenstra?e 70/I/1, 1050 Wien, ?sterreich, Tel. +43 >> (1) 9610567-0 Eingetragen beim Handelsgericht Wien, Firmenbuch-Nr.: FN >> 116859 b Umsatzsteuer-Identifikationsnummer / VAT-ID: ATU15138401, >> Steuer-Nummer: 264/4807 >> >> This E-Mail has been sent on behalf of the company Intergraph Ges.m.b.H. >> Authorised Managing Directors: Maximilian Weber Registered office and >> Austrian headquarters: Margaretenstr. 70/I/1, 1050 Wien, Austria, Tel. >> +43 (1) 9610567-0 The company is recorded at the commercial court of >> Vienna under the company register number FN 116859 b >> VAT-ID: ATU15138401, Austrian Tax ID: 264/4807 >> >> Diese E-Mail (mit zugeh?rigen Dateien) enth?lt m?glicherweise Informationen, die vertraulich sind, dem Urheberrecht unterliegen oder ein Gesch?ftsgeheimnis darstellen. Falls Sie diese Nachricht irrt?mlicherweise erhalten haben, benachrichtigen Sie uns bitte umgehend, indem Sie eine Antwort senden, und l?schen Sie bitte diese E-Mail und Ihre Antwort darauf. S?mtliche aufgef?hrten Ansichten oder Meinungen sind ausschlie?lich diejenigen des Autors und entsprechen nicht notwendigerweise denen des Unternehmens Intergraph. >> >> This E-Mail (and any attachments) may be confidential and protected by legal privilege. If you are not the intended recipient please notify us immediately by replying to the sender and delete this E-Mail and your reply from your system. All the views and opinions published here are solely based on the author's own opinion and should not be considered necessarily as reflecting the opinion of Intergraph. >> >> >> -----Original Message----- >> From: Anton V. Tarasov [mailto:anton.tarasov at oracle.com] >> Sent: Tuesday, June 30, 2015 8:01 PM >> To: Hruda, Steve; Kevin Rushforth >> Cc: openjfx-dev at openjdk.java.net >> Subject: Re: Patch for JDK-8090098 - [regression] Webview - >> getTimezoneOffset() of a ISO strings returns a wrong value >> >> Steve, >> >> I applied your suggestion and it worked on Windows. >> >> The missed check you discovered could really be a mistake in WebKit, because Apple dropped releasing (and shipping nightly builds for) Safari for Windows at 2012. >> Safari 5.1.7 was the last version. I downloaded and checked it. The date bug is not reproducible with it, but this gives us almost nothing taking into account the version is much outdated. >> >> So that Windows code path might not have been well tested, since >> http://trac.webkit.org/changeset/159892 was commited... >> >> (WebKit Win port is still supported and can be built on your own.) >> >> What I can do else to verify the changes is to run WebKit LayoutTests aimed at date testing and see if there're no regressions. >> >> Also, please put the info you posted into JIRA. >> >> Regards, >> Anton. >> >> On 29.06.2015 21:42, Anton Tarasov wrote: >>> Hi Steve, >>> >>> Ok, I'll investigate it. >>> >>> Thanks, >>> Anton. >>> >>> On 29.06.2015 18:39, Hruda, Steve wrote: >>>> Hi Anton & Kevin, >>>> >>>> we read your comments in the JDK bug system and analyzed WebKit's changesets again. >>>> >>>> We?ve found the code which made this regression. >>>> >>>> http://trac.webkit.org/changeset/159892 >>>> >>>> This changeset doesn't handle one special case, which was handled by the previous code.... >>>> >>>> double diff = ((localSystemTime.wHour - offsetHour) * >>>> secondsPerHour) >>>> + ((localSystemTime.wMinute >>>> - offsetMinute) *60); >>>> >>>> >>>> (http://trac.webkit.org/browser/trunk/Source/WTF/wtf/DateMath.cpp?an >>>> n >>>> otate=blame#L481 ) >>>> >>>> The diff is wrong if the calculated the offsetTime is one day before >>>> in case of the extreme values (e.g. midnight) where the offsetHour of the UTC time is 23 because of the day difference. >>>> >>>> In case of all other OS systems you will see the same code -> >>>> http://trac.webkit.org/browser/trunk/Source/WTF/wtf/DateMath.cpp?ann >>>> o >>>> tate=blame#L495 >>>> >>>> But there are two additional lines -> 497 & 497 which fixes this >>>> special case? >>>> >>>> *if*(diff<0) >>>> >>>> diff += secondsPerDay; >>>> >>>> >>>> That means ?. >>>> >>>> localSystemTime.wHour = 0; >>>> >>>> offsetHour=23 ? which causes a negative value ? and the >>>> diff+=secondsPerDay ensures that the diff result would be one Hour >>>> instead of -23 hours >>>> >>>> We?ve found the attached V8DateTests.js (renamed to .txt) and >>>> adjusted it a little bit to get the results logged in the browsers console. >>>> >>>> As you can see at ?ResulBeforeOurBugFix.txt? and >>>> ?ResultAfterOurBugFix.txt?, we were able to fix >>>> 6 tests which failed before out bug fix. >>>> >>>> assertEquals("Sat Oct 25 2014 23:00:00 GMT+0200 (W. Europe Daylight >>>> Time)", >>>> >>>> (new Date(2014, 9, 25, 23, 0)).toString()); >>>> >>>> assertEquals("Sat, 25 Oct 2014 21:00:00 GMT", >>>> >>>> (new Date(2014, 9, 25, 23, 0)).toUTCString()); >>>> >>>> assertEquals("Sat Oct 25 2014 23:59:00 GMT+0200 (W. Europe >>>> Daylight Time)", >>>> >>>> (new Date(2014, 9, 25, 23, 59)).toString()); >>>> >>>> assertEquals("Sat, 25 Oct 2014 21:59:00 GMT", >>>> >>>> (new Date(2014, 9, 25, 23, 59)).toUTCString()); >>>> >>>> assertEquals("Sun Oct 26 2014 00:00:00 GMT+0200 (W. Europe >>>> Daylight Time)", >>>> >>>> (new Date(2014, 9, 26, 0, 0)).toString()); >>>> >>>> assertEquals("Sun Oct 26 2014 00:59:00 GMT+0200 (W. Europe Daylight >>>> Time)", >>>> >>>> (new Date(2014, 9, 26, 0, 59)).toString()); >>>> >>>> In addition we found out that WebKit also have problems in case of >>>> Windows in case of the change from winter to summer time. >>>> >>>> *_Winter to summer time:_* >>>> >>>> assertEquals("Sun Mar 30 2014 03:00:00 GMT+0200 (W. Europe Daylight >>>> Time)", >>>> >>>> (new Date(2014, 2, 30, 2, 0)).toString()); >>>> >>>> assertEquals("Sun, 30 Mar 2014 01:00:00 GMT", >>>> >>>> (new Date(2014, 2, 30, 2, 0)).toUTCString()); >>>> >>>> assertEquals("Sun Mar 30 2014 03:59:00 GMT+0200 (W. Europe >>>> Daylight Time)", >>>> >>>> (new Date(2014, 2, 30, 2, 59)).toString()); >>>> >>>> assertEquals("Sun, 30 Mar 2014 01:59:00 GMT", >>>> >>>> (new Date(2014, 2, 30, 2, 59)).toUTCString()); >>>> >>>> *_Summer to winter time:_* >>>> >>>> assertEquals("Sun Oct 26 2014 02:00:00 GMT+0200 (W. Europe Daylight >>>> Time)", >>>> >>>> (new Date(2014, 9, 26, 2, 0)).toString()); >>>> >>>> assertEquals("Sun, 26 Oct 2014 00:00:00 GMT", >>>> >>>> (new Date(2014, 9, 26, 2, 0)).toUTCString()); >>>> >>>> assertEquals("Sun Oct 26 2014 02:59:00 GMT+0200 (W. Europe >>>> Daylight Time)", >>>> >>>> (new Date(2014, 9, 26, 2, 59)).toString()); >>>> >>>> assertEquals("Sun, 26 Oct 2014 00:59:00 GMT", >>>> >>>> (new Date(2014, 9, 26, 2, 59)).toUTCString()); >>>> >>>> We will try to find a solution for that, but I think that the >>>> priority of this issue is lower than the priority of the opened regression. >>>> >>>> It would be amazing if you can add the patch of my previous and >>>> these additional two lines >>>> (DateMath.cpp) to the JDK8u60. >>>> >>>> Best Regards, >>>> >>>> Steve >>>> >>>> >>>> Diese E-Mail wurde versandt im Auftrag des Unternehmens Intergraph Ges.m.b.H. >>>> Vertretungsberechtigte Gesch?ftsf?hrer: Maximilian Weber Sitz der >>>> Gesellschaft: Margaretenstra?e 70/I/1, 1050 Wien, ?sterreich, Tel. >>>> +43 (1) 9610567-0 Eingetragen beim Handelsgericht Wien, >>>> Firmenbuch-Nr.: FN 116859 b Umsatzsteuer-Identifikationsnummer / >>>> VAT-ID: ATU15138401, Steuer-Nummer: 264/4807 >>>> >>>> This E-Mail has been sent on behalf of the company Intergraph Ges.m.b.H. >>>> Authorised Managing Directors: Maximilian Weber Registered office >>>> and Austrian headquarters: Margaretenstr. 70/I/1, 1050 Wien, >>>> Austria, Tel. +43 >>>> (1) 9610567-0 >>>> The company is recorded at the commercial court of Vienna under the >>>> company register number FN >>>> 116859 b >>>> VAT-ID: ATU15138401, Austrian Tax ID: 264/4807 >>>> >>>> Diese E-Mail (mit zugeh?rigen Dateien) enth?lt m?glicherweise >>>> Informationen, die vertraulich sind, dem Urheberrecht unterliegen >>>> oder ein Gesch?ftsgeheimnis darstellen. Falls Sie diese Nachricht >>>> irrt?mlicherweise erhalten haben, benachrichtigen Sie uns bitte >>>> umgehend, indem Sie eine Antwort senden, und l?schen Sie bitte diese >>>> E-Mail und Ihre Antwort darauf. S?mtliche aufgef?hrten Ansichten oder Meinungen sind ausschlie?lich diejenigen des Autors und entsprechen nicht notwendigerweise denen des Unternehmens Intergraph. >>>> >>>> This E-Mail (and any attachments) may be confidential and protected >>>> by legal privilege. If you are not the intended recipient please >>>> notify us immediately by replying to the sender and delete this >>>> E-Mail and your reply from your system. All the views and opinions >>>> published here are solely based on the author's own opinion and should not be considered necessarily as reflecting the opinion of Intergraph. >>>> >>>> -----Original Message----- >>>> >>>> From: openjfx-dev [mailto:openjfx-dev-bounces at openjdk.java.net] On >>>> Behalf Of Hruda, Steve >>>> >>>> Sent: Tuesday, June 23, 2015 6:26 PM >>>> >>>> To: Anton V. Tarasov; Kevin Rushforth >>>> >>>> Cc: openjfx-dev at openjdk.java.net >>>> >>>> Subject: RE: Patch for JDK-8090098 - [regression] Webview - >>>> getTimezoneOffset() of a ISO strings returns a wrong value >>>> >>>> Very cool Anton. >>>> >>>> I would be great if that pach could be added to 8u60, otherwise our >>>> all our customers have to avoid Java 8u60. >>>> >>>> Regards, >>>> >>>> Steve >>>> >>>> Diese E-Mail wurde versandt im Auftrag des Unternehmens Intergraph Ges.m.b.H. >>>> >>>> Vertretungsberechtigte Gesch?ftsf?hrer: Maximilian Weber Sitz der >>>> Gesellschaft: Margaretenstra?e 70/I/1, 1050 Wien, ?sterreich, Tel. >>>> +43 (1) 9610567-0 Eingetragen beim Handelsgericht Wien, >>>> Firmenbuch-Nr.: FN 116859 b Umsatzsteuer-Identifikationsnummer / >>>> VAT-ID: ATU15138401, >>>> Steuer-Nummer: 264/4807 >>>> >>>> This E-Mail has been sent on behalf of the company Intergraph Ges.m.b.H. >>>> >>>> Authorised Managing Directors: Maximilian Weber Registered office and Austrian headquarters: >>>> Margaretenstr. 70/I/1, 1050 Wien, Austria, Tel. +43 (1) 9610567-0 >>>> The company is recorded at the commercial court of Vienna under the >>>> company register number FN 116859 b >>>> >>>> VAT-ID: ATU15138401, Austrian Tax ID: 264/4807 >>>> >>>> Diese E-Mail (mit zugeh?rigen Dateien) enth?lt m?glicherweise >>>> Informationen, die vertraulich sind, dem Urheberrecht unterliegen >>>> oder ein Gesch?ftsgeheimnis darstellen. Falls Sie diese Nachricht >>>> irrt?mlicherweise erhalten haben, benachrichtigen Sie uns bitte >>>> umgehend, indem Sie eine Antwort senden, und l?schen Sie bitte diese >>>> E-Mail und Ihre Antwort darauf. S?mtliche aufgef?hrten Ansichten oder Meinungen sind ausschlie?lich diejenigen des Autors und entsprechen nicht notwendigerweise denen des Unternehmens Intergraph. >>>> >>>> This E-Mail (and any attachments) may be confidential and protected >>>> by legal privilege. If you are not the intended recipient please >>>> notify us immediately by replying to the sender and delete this >>>> E-Mail and your reply from your system. All the views and opinions >>>> published here are solely based on the author's own opinion and should not be considered necessarily as reflecting the opinion of Intergraph. >>>> >>>> -----Original Message----- >>>> >>>> From: Anton V. Tarasov [mailto:anton.tarasov at oracle.com] >>>> >>>> Sent: Tuesday, June 23, 2015 5:46 PM >>>> >>>> To: Kevin Rushforth; Hruda, Steve >>>> >>>> Cc: openjfx-dev at openjdk.java.net >>>> >>>> Subject: Re: Patch for JDK-8090098 - [regression] Webview - >>>> getTimezoneOffset() of a ISO strings returns a wrong value >>>> >>>> On 23.06.2015 17:48, Kevin Rushforth wrote: >>>> >>>>> Hi Steve, >>>>> Thank you for taking the time to create this patch. I will add this information to the bug report. >>>>> Since your OCA is in progress we will take a look at your patch, >>>>> but will need indication from the OCA office that it the OCA has >>>>> been received before we could push it. And just to be clear, you >>>>> won't have access to the repository even with an OCA. What the OCA >>>>> will do is allow you to contribute >>>> patches. >>>> >>>>> I will note that it is likely too late for 8u60, but Anton can >>>>> evaluate it and post his comment in the bug report. >>>> Kevin, >>>> >>>> I'm checking it. >>>> >>>> Steve, thanks for the participation! >>>> >>>> Regards, >>>> >>>> Anton. >>>> >>>>> -- Kevin >>>>> Hruda, Steve wrote: >>>>>> Hi, >>>>>> I've created a 8u-dev patch for the following WeKit regression which comes with 8u60. >>>>>> https://bugs.openjdk.java.net/browse/JDK-8090098 >>>>>> Please can someone of you apply this patch to fix the >>>>>> getTimezoneOffset() issue. I have no access to the repository -> my OCA is still pending. >>>>>> In addition I tried to test this patch , but I wasn't able to >>>>>> build the necessary jfxwebkit.dll on my windows system >>>>>> (https://www.mail-archive.com/openjfx-dev at openjdk.java.net/msg0943 >>>>>> 9.h >>>>>> tml )..... but I got no compile erros on Mac. >>>>>> Patch download: >>>>>> https://drive.google.com/file/d/0B7P_rknS1TWxM3BSTTU2OVZ4dGM/view? >>>>>> u >>>>>> sp >>>>>> =sharing >>>>>> The patch includes the following WebKit fixes: >>>>>> Changeset 174377 - [Win] DateMath's calculateUTFOffset does not account for DST. >>>>>> http://trac.webkit.org/changeset/174377 >>>>>> Changeset 175078 - String(new Date(Mar 30 2014 01:00:00)) is >>>>>> wrong in CET >>>>>> http://trac.webkit.org/changeset/175078 >>>>>> Changeset 181360 - [Win] 17 different JSC tests started to fail in >>>>>> DST >>>>>> http://trac.webkit.org/changeset/181360 >>>>>> Please let me know if you need further information. >>>>>> Thanks in advance! >>>>>> Best Regards >>>>>> Steve >>>>>> Diese E-Mail wurde versandt im Auftrag des Unternehmens Intergraph Ges.m.b.H. >>>>>> Vertretungsberechtigte Gesch?ftsf?hrer: Maximilian Weber Sitz der >>>>>> Gesellschaft: Margaretenstra?e 70/I/1, 1050 Wien, ?sterreich, Tel. >>>>>> +43 (1) 9610567-0 Eingetragen beim Handelsgericht Wien, >>>>>> Firmenbuch-Nr.: FN 116859 b Umsatzsteuer-Identifikationsnummer / >>>>>> VAT-ID: ATU15138401, Steuer-Nummer: 264/4807 This E-Mail has been >>>>>> sent on behalf of the company Intergraph Ges.m.b.H. >>>>>> Authorised Managing Directors: Maximilian Weber Registered office >>>>>> and Austrian headquarters: Margaretenstr. 70/I/1, 1050 Wien, >>>>>> Austria, Tel. +43 >>>>>> (1) 9610567-0 >>>>>> The company is recorded at the commercial court of Vienna under >>>>>> the company register number FN >>>>>> 116859 b >>>>>> VAT-ID: ATU15138401, Austrian Tax ID: 264/4807 Diese E-Mail (mit >>>>>> zugeh?rigen Dateien) enth?lt m?glicherweise Informationen, die >>>>>> vertraulich sind, dem Urheberrecht unterliegen oder ein >>>>>> Gesch?ftsgeheimnis darstellen. Falls Sie diese Nachricht >>>>>> irrt?mlicherweise erhalten haben, benachrichtigen Sie uns bitte >>>>>> umgehend, indem Sie eine Antwort senden, und l?schen Sie bitte >>>>>> diese E-Mail und Ihre Antwort darauf. S?mtliche aufgef?hrten >>>>>> Ansichten oder Meinungen sind >>>> ausschlie?lich diejenigen des Autors und entsprechen nicht >>>> notwendigerweise denen des Unternehmens Intergraph. >>>> >>>>>> This E-Mail (and any attachments) may be confidential and >>>>>> protected by legal privilege. If you are not the intended >>>>>> recipient please notify us immediately by replying to the sender >>>>>> and delete this E-Mail and your reply from your system. All the >>>>>> views and opinions published here are solely based on the author's >>>>>> own opinion and should not be considered >>>> necessarily as reflecting the opinion of Intergraph. >>>> From kevin.rushforth at oracle.com Tue Jun 30 20:45:15 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 30 Jun 2015 13:45:15 -0700 Subject: Patch for JDK-8090098 - [regression] Webview - getTimezoneOffset() of a ISO strings returns a wrong value In-Reply-To: <5592E269.6050200@oracle.com> References: <559191AA.8030800@oracle.com> <5592D943.3090407@oracle.com> <5592E269.6050200@oracle.com> Message-ID: <5592FFDB.5090501@oracle.com> Anton V. Tarasov wrote: > On 30.06.2015 21:13, Hruda, Steve wrote: >> Hi Anton, >> thanks for the detailed information and the good news. >> >> You talk about JDK's jira? Am I right? ..... I don't have an access >> for that JIRA system since the JavaFX's Jira has moved to the JDK Bug >> System. > > Ah, ok. Then I'll quote your e-mail. > >> >> About the Apple stuff. >> I know that Apple dropped Windows Safari support and in my opinion is >> this a very bad situation for WebKit (in case of Windows).... and >> especially since Google and Opera using Google's Blink engine. >> >> In case of the JDK it would be more practicable to switch from WebKit >> to Blink, because this engine is still used by Companies which have >> Windows end-users. >> >> There is a high probability that WebKit get more such bugs if there >> is no big player like Google or Apple who has the man power to fix >> such OS dependent issues. > > I see. However, switching to Blink is another story. Honestly, we're > not planning it in the nearest future. This requires extra resources > which we don't have at the moment... > >> >> Last questions: >> Do you need any additional information from my side? And is it >> possible to integrate this fix in 8u60? > > From my side, I'll do a sanity check with WebKit LayoutTests, then if > it goes well, we can consider commiting this to 8u60. > > @Kevin, do you think we can? Very unlikely. The JDK release team would need to approve, and only release-critical issues may be considered at this point (it would be hard to argue that this is release-critical since it has already been deferred). -- Kevin > Also, as an option for you (Steve). You can post the changes to the > WebKit alias and ask if they think this is a valid fix for the issue. > Any confirmation from the WebKit team would help us to make sure the > fix is reliable. > > Thanks! > Anton. > >> >> Thanks in advance! >> Best Regards, >> Steve >> >> >> >> >> Diese E-Mail wurde versandt im Auftrag des Unternehmens Intergraph >> Ges.m.b.H. >> Vertretungsberechtigte Gesch?ftsf?hrer: Maximilian Weber >> Sitz der Gesellschaft: Margaretenstra?e 70/I/1, 1050 Wien, >> ?sterreich, Tel. +43 (1) 9610567-0 >> Eingetragen beim Handelsgericht Wien, Firmenbuch-Nr.: FN 116859 b >> Umsatzsteuer-Identifikationsnummer / VAT-ID: ATU15138401, >> Steuer-Nummer: 264/4807 >> >> This E-Mail has been sent on behalf of the company Intergraph Ges.m.b.H. >> Authorised Managing Directors: Maximilian Weber >> Registered office and Austrian headquarters: Margaretenstr. 70/I/1, >> 1050 Wien, Austria, Tel. +43 (1) 9610567-0 >> The company is recorded at the commercial court of Vienna under the >> company register number FN 116859 b >> VAT-ID: ATU15138401, Austrian Tax ID: 264/4807 >> >> Diese E-Mail (mit zugeh?rigen Dateien) enth?lt m?glicherweise >> Informationen, die vertraulich sind, dem Urheberrecht unterliegen >> oder ein Gesch?ftsgeheimnis darstellen. Falls Sie diese Nachricht >> irrt?mlicherweise erhalten haben, benachrichtigen Sie uns bitte >> umgehend, indem Sie eine Antwort senden, und l?schen Sie bitte diese >> E-Mail und Ihre Antwort darauf. S?mtliche aufgef?hrten Ansichten oder >> Meinungen sind ausschlie?lich diejenigen des Autors und entsprechen >> nicht notwendigerweise denen des Unternehmens Intergraph. >> >> This E-Mail (and any attachments) may be confidential and protected >> by legal privilege. If you are not the intended recipient please >> notify us immediately by replying to the sender and delete this >> E-Mail and your reply from your system. All the views and opinions >> published here are solely based on the author's own opinion and >> should not be considered necessarily as reflecting the opinion of >> Intergraph. >> >> >> -----Original Message----- >> From: Anton V. Tarasov [mailto:anton.tarasov at oracle.com] >> Sent: Tuesday, June 30, 2015 8:01 PM >> To: Hruda, Steve; Kevin Rushforth >> Cc: openjfx-dev at openjdk.java.net >> Subject: Re: Patch for JDK-8090098 - [regression] Webview - >> getTimezoneOffset() of a ISO strings returns a wrong value >> >> Steve, >> >> I applied your suggestion and it worked on Windows. >> >> The missed check you discovered could really be a mistake in WebKit, >> because Apple dropped releasing (and shipping nightly builds for) >> Safari for Windows at 2012. >> Safari 5.1.7 was the last version. I downloaded and checked it. The >> date bug is not reproducible with it, but this gives us almost >> nothing taking into account the version is much outdated. >> >> So that Windows code path might not have been well tested, since >> http://trac.webkit.org/changeset/159892 was commited... >> >> (WebKit Win port is still supported and can be built on your own.) >> >> What I can do else to verify the changes is to run WebKit LayoutTests >> aimed at date testing and see if there're no regressions. >> >> Also, please put the info you posted into JIRA. >> >> Regards, >> Anton. >> >> On 29.06.2015 21:42, Anton Tarasov wrote: >>> Hi Steve, >>> >>> Ok, I'll investigate it. >>> >>> Thanks, >>> Anton. >>> >>> On 29.06.2015 18:39, Hruda, Steve wrote: >>>> Hi Anton & Kevin, >>>> >>>> we read your comments in the JDK bug system and analyzed WebKit's >>>> changesets again. >>>> >>>> We?ve found the code which made this regression. >>>> >>>> http://trac.webkit.org/changeset/159892 >>>> >>>> This changeset doesn't handle one special case, which was handled >>>> by the previous code.... >>>> >>>> double diff = ((localSystemTime.wHour - offsetHour) * secondsPerHour) >>>> + ((localSystemTime.wMinute >>>> - offsetMinute) *60); >>>> >>>> >>>> (http://trac.webkit.org/browser/trunk/Source/WTF/wtf/DateMath.cpp?ann >>>> otate=blame#L481 ) >>>> >>>> The diff is wrong if the calculated the offsetTime is one day before >>>> in case of the extreme values (e.g. midnight) where the offsetHour >>>> of the UTC time is 23 because of the day difference. >>>> >>>> In case of all other OS systems you will see the same code -> >>>> http://trac.webkit.org/browser/trunk/Source/WTF/wtf/DateMath.cpp?anno >>>> tate=blame#L495 >>>> >>>> But there are two additional lines -> 497 & 497 which fixes this >>>> special case? >>>> >>>> *if*(diff<0) >>>> >>>> diff += secondsPerDay; >>>> >>>> >>>> That means ?. >>>> >>>> localSystemTime.wHour = 0; >>>> >>>> offsetHour=23 ? which causes a negative value ? and the >>>> diff+=secondsPerDay ensures that the diff result would be one Hour >>>> instead of -23 hours >>>> >>>> We?ve found the attached V8DateTests.js (renamed to .txt) and >>>> adjusted it a little bit to get the results logged in the browsers >>>> console. >>>> >>>> As you can see at ?ResulBeforeOurBugFix.txt? and >>>> ?ResultAfterOurBugFix.txt?, we were able to fix >>>> 6 tests which failed before out bug fix. >>>> >>>> assertEquals("Sat Oct 25 2014 23:00:00 GMT+0200 (W. Europe Daylight >>>> Time)", >>>> >>>> (new Date(2014, 9, 25, 23, 0)).toString()); >>>> >>>> assertEquals("Sat, 25 Oct 2014 21:00:00 GMT", >>>> >>>> (new Date(2014, 9, 25, 23, 0)).toUTCString()); >>>> >>>> assertEquals("Sat Oct 25 2014 23:59:00 GMT+0200 (W. Europe Daylight >>>> Time)", >>>> >>>> (new Date(2014, 9, 25, 23, 59)).toString()); >>>> >>>> assertEquals("Sat, 25 Oct 2014 21:59:00 GMT", >>>> >>>> (new Date(2014, 9, 25, 23, 59)).toUTCString()); >>>> >>>> assertEquals("Sun Oct 26 2014 00:00:00 GMT+0200 (W. Europe Daylight >>>> Time)", >>>> >>>> (new Date(2014, 9, 26, 0, 0)).toString()); >>>> >>>> assertEquals("Sun Oct 26 2014 00:59:00 GMT+0200 (W. Europe Daylight >>>> Time)", >>>> >>>> (new Date(2014, 9, 26, 0, 59)).toString()); >>>> >>>> In addition we found out that WebKit also have problems in case of >>>> Windows in case of the change from winter to summer time. >>>> >>>> *_Winter to summer time:_* >>>> >>>> assertEquals("Sun Mar 30 2014 03:00:00 GMT+0200 (W. Europe Daylight >>>> Time)", >>>> >>>> (new Date(2014, 2, 30, 2, 0)).toString()); >>>> >>>> assertEquals("Sun, 30 Mar 2014 01:00:00 GMT", >>>> >>>> (new Date(2014, 2, 30, 2, 0)).toUTCString()); >>>> >>>> assertEquals("Sun Mar 30 2014 03:59:00 GMT+0200 (W. Europe Daylight >>>> Time)", >>>> >>>> (new Date(2014, 2, 30, 2, 59)).toString()); >>>> >>>> assertEquals("Sun, 30 Mar 2014 01:59:00 GMT", >>>> >>>> (new Date(2014, 2, 30, 2, 59)).toUTCString()); >>>> >>>> *_Summer to winter time:_* >>>> >>>> assertEquals("Sun Oct 26 2014 02:00:00 GMT+0200 (W. Europe Daylight >>>> Time)", >>>> >>>> (new Date(2014, 9, 26, 2, 0)).toString()); >>>> >>>> assertEquals("Sun, 26 Oct 2014 00:00:00 GMT", >>>> >>>> (new Date(2014, 9, 26, 2, 0)).toUTCString()); >>>> >>>> assertEquals("Sun Oct 26 2014 02:59:00 GMT+0200 (W. Europe Daylight >>>> Time)", >>>> >>>> (new Date(2014, 9, 26, 2, 59)).toString()); >>>> >>>> assertEquals("Sun, 26 Oct 2014 00:59:00 GMT", >>>> >>>> (new Date(2014, 9, 26, 2, 59)).toUTCString()); >>>> >>>> We will try to find a solution for that, but I think that the >>>> priority of this issue is lower than the priority of the opened >>>> regression. >>>> >>>> It would be amazing if you can add the patch of my previous and these >>>> additional two lines >>>> (DateMath.cpp) to the JDK8u60. >>>> >>>> Best Regards, >>>> >>>> Steve >>>> >>>> >>>> Diese E-Mail wurde versandt im Auftrag des Unternehmens Intergraph >>>> Ges.m.b.H. >>>> Vertretungsberechtigte Gesch?ftsf?hrer: Maximilian Weber Sitz der >>>> Gesellschaft: Margaretenstra?e 70/I/1, 1050 Wien, ?sterreich, Tel. >>>> +43 (1) 9610567-0 Eingetragen beim Handelsgericht Wien, >>>> Firmenbuch-Nr.: FN 116859 b Umsatzsteuer-Identifikationsnummer / >>>> VAT-ID: ATU15138401, Steuer-Nummer: 264/4807 >>>> >>>> This E-Mail has been sent on behalf of the company Intergraph >>>> Ges.m.b.H. >>>> Authorised Managing Directors: Maximilian Weber Registered office and >>>> Austrian headquarters: Margaretenstr. 70/I/1, 1050 Wien, Austria, >>>> Tel. +43 >>>> (1) 9610567-0 >>>> The company is recorded at the commercial court of Vienna under the >>>> company register number FN >>>> 116859 b >>>> VAT-ID: ATU15138401, Austrian Tax ID: 264/4807 >>>> >>>> Diese E-Mail (mit zugeh?rigen Dateien) enth?lt m?glicherweise >>>> Informationen, die vertraulich sind, dem Urheberrecht unterliegen >>>> oder ein Gesch?ftsgeheimnis darstellen. Falls Sie diese Nachricht >>>> irrt?mlicherweise erhalten haben, benachrichtigen Sie uns bitte >>>> umgehend, indem Sie eine Antwort senden, und l?schen Sie bitte diese >>>> E-Mail und Ihre Antwort darauf. S?mtliche aufgef?hrten Ansichten >>>> oder Meinungen sind ausschlie?lich diejenigen des Autors und >>>> entsprechen nicht notwendigerweise denen des Unternehmens Intergraph. >>>> >>>> This E-Mail (and any attachments) may be confidential and protected >>>> by legal privilege. If you are not the intended recipient please >>>> notify us immediately by replying to the sender and delete this >>>> E-Mail and your reply from your system. All the views and opinions >>>> published here are solely based on the author's own opinion and >>>> should not be considered necessarily as reflecting the opinion of >>>> Intergraph. >>>> >>>> -----Original Message----- >>>> >>>> From: openjfx-dev [mailto:openjfx-dev-bounces at openjdk.java.net] On >>>> Behalf Of Hruda, Steve >>>> >>>> Sent: Tuesday, June 23, 2015 6:26 PM >>>> >>>> To: Anton V. Tarasov; Kevin Rushforth >>>> >>>> Cc: openjfx-dev at openjdk.java.net >>>> >>>> Subject: RE: Patch for JDK-8090098 - [regression] Webview - >>>> getTimezoneOffset() of a ISO strings returns a wrong value >>>> >>>> Very cool Anton. >>>> >>>> I would be great if that pach could be added to 8u60, otherwise our >>>> all our customers have to avoid Java 8u60. >>>> >>>> Regards, >>>> >>>> Steve >>>> >>>> Diese E-Mail wurde versandt im Auftrag des Unternehmens Intergraph >>>> Ges.m.b.H. >>>> >>>> Vertretungsberechtigte Gesch?ftsf?hrer: Maximilian Weber Sitz der >>>> Gesellschaft: Margaretenstra?e 70/I/1, 1050 Wien, ?sterreich, Tel. >>>> +43 (1) 9610567-0 Eingetragen beim Handelsgericht Wien, >>>> Firmenbuch-Nr.: FN 116859 b Umsatzsteuer-Identifikationsnummer / >>>> VAT-ID: ATU15138401, >>>> Steuer-Nummer: 264/4807 >>>> >>>> This E-Mail has been sent on behalf of the company Intergraph >>>> Ges.m.b.H. >>>> >>>> Authorised Managing Directors: Maximilian Weber Registered office >>>> and Austrian headquarters: >>>> Margaretenstr. 70/I/1, 1050 Wien, Austria, Tel. +43 (1) 9610567-0 The >>>> company is recorded at the commercial court of Vienna under the >>>> company register number FN 116859 b >>>> >>>> VAT-ID: ATU15138401, Austrian Tax ID: 264/4807 >>>> >>>> Diese E-Mail (mit zugeh?rigen Dateien) enth?lt m?glicherweise >>>> Informationen, die vertraulich sind, dem Urheberrecht unterliegen >>>> oder ein Gesch?ftsgeheimnis darstellen. Falls Sie diese Nachricht >>>> irrt?mlicherweise erhalten haben, benachrichtigen Sie uns bitte >>>> umgehend, indem Sie eine Antwort senden, und l?schen Sie bitte diese >>>> E-Mail und Ihre Antwort darauf. S?mtliche aufgef?hrten Ansichten >>>> oder Meinungen sind ausschlie?lich diejenigen des Autors und >>>> entsprechen nicht notwendigerweise denen des Unternehmens Intergraph. >>>> >>>> This E-Mail (and any attachments) may be confidential and protected >>>> by legal privilege. If you are not the intended recipient please >>>> notify us immediately by replying to the sender and delete this >>>> E-Mail and your reply from your system. All the views and opinions >>>> published here are solely based on the author's own opinion and >>>> should not be considered necessarily as reflecting the opinion of >>>> Intergraph. >>>> >>>> -----Original Message----- >>>> >>>> From: Anton V. Tarasov [mailto:anton.tarasov at oracle.com] >>>> >>>> Sent: Tuesday, June 23, 2015 5:46 PM >>>> >>>> To: Kevin Rushforth; Hruda, Steve >>>> >>>> Cc: openjfx-dev at openjdk.java.net >>>> >>>> Subject: Re: Patch for JDK-8090098 - [regression] Webview - >>>> getTimezoneOffset() of a ISO strings returns a wrong value >>>> >>>> On 23.06.2015 17:48, Kevin Rushforth wrote: >>>> >>>>> Hi Steve, >>>>> Thank you for taking the time to create this patch. I will add >>>>> this information to the bug report. >>>>> Since your OCA is in progress we will take a look at your patch, >>>>> but >>>>> will need indication from the OCA office that it the OCA has been >>>>> received before we could push it. And just to be clear, you won't >>>>> have >>>>> access to the repository even with an OCA. What the OCA will do is >>>>> allow you to contribute >>>> patches. >>>> >>>>> I will note that it is likely too late for 8u60, but Anton can >>>>> evaluate it and post his comment in the bug report. >>>> Kevin, >>>> >>>> I'm checking it. >>>> >>>> Steve, thanks for the participation! >>>> >>>> Regards, >>>> >>>> Anton. >>>> >>>>> -- Kevin >>>>> Hruda, Steve wrote: >>>>>> Hi, >>>>>> I've created a 8u-dev patch for the following WeKit regression >>>>>> which comes with 8u60. >>>>>> https://bugs.openjdk.java.net/browse/JDK-8090098 >>>>>> Please can someone of you apply this patch to fix the >>>>>> getTimezoneOffset() issue. I have no access to the repository -> >>>>>> my OCA is still pending. >>>>>> In addition I tried to test this patch , but I wasn't able to >>>>>> build >>>>>> the necessary jfxwebkit.dll on my windows system >>>>>> (https://www.mail-archive.com/openjfx-dev at openjdk.java.net/msg0943 >>>>>> 9.h >>>>>> tml )..... but I got no compile erros on Mac. >>>>>> Patch download: >>>>>> https://drive.google.com/file/d/0B7P_rknS1TWxM3BSTTU2OVZ4dGM/view?u >>>>>> sp >>>>>> =sharing >>>>>> The patch includes the following WebKit fixes: >>>>>> Changeset 174377 - [Win] DateMath's calculateUTFOffset does not >>>>>> account for DST. >>>>>> http://trac.webkit.org/changeset/174377 >>>>>> Changeset 175078 - String(new Date(Mar 30 2014 01:00:00)) is >>>>>> wrong >>>>>> in CET >>>>>> http://trac.webkit.org/changeset/175078 >>>>>> Changeset 181360 - [Win] 17 different JSC tests started to fail in >>>>>> DST >>>>>> http://trac.webkit.org/changeset/181360 >>>>>> Please let me know if you need further information. >>>>>> Thanks in advance! >>>>>> Best Regards >>>>>> Steve >>>>>> Diese E-Mail wurde versandt im Auftrag des Unternehmens >>>>>> Intergraph Ges.m.b.H. >>>>>> Vertretungsberechtigte Gesch?ftsf?hrer: Maximilian Weber Sitz der >>>>>> Gesellschaft: Margaretenstra?e 70/I/1, 1050 Wien, ?sterreich, Tel. >>>>>> +43 (1) 9610567-0 Eingetragen beim Handelsgericht Wien, >>>>>> Firmenbuch-Nr.: FN 116859 b Umsatzsteuer-Identifikationsnummer / >>>>>> VAT-ID: ATU15138401, Steuer-Nummer: 264/4807 >>>>>> This E-Mail has been sent on behalf of the company Intergraph >>>>>> Ges.m.b.H. >>>>>> Authorised Managing Directors: Maximilian Weber Registered office >>>>>> and >>>>>> Austrian headquarters: Margaretenstr. 70/I/1, 1050 Wien, Austria, >>>>>> Tel. +43 >>>>>> (1) 9610567-0 >>>>>> The company is recorded at the commercial court of Vienna under >>>>>> the >>>>>> company register number FN >>>>>> 116859 b >>>>>> VAT-ID: ATU15138401, Austrian Tax ID: 264/4807 >>>>>> Diese E-Mail (mit zugeh?rigen Dateien) enth?lt m?glicherweise >>>>>> Informationen, die vertraulich sind, dem Urheberrecht unterliegen >>>>>> oder ein Gesch?ftsgeheimnis darstellen. Falls Sie diese Nachricht >>>>>> irrt?mlicherweise erhalten haben, benachrichtigen Sie uns bitte >>>>>> umgehend, indem Sie eine Antwort senden, und l?schen Sie bitte >>>>>> diese >>>>>> E-Mail und Ihre Antwort darauf. S?mtliche aufgef?hrten Ansichten >>>>>> oder Meinungen sind >>>> ausschlie?lich diejenigen des Autors und entsprechen nicht >>>> notwendigerweise denen des Unternehmens Intergraph. >>>> >>>>>> This E-Mail (and any attachments) may be confidential and >>>>>> protected >>>>>> by legal privilege. If you are not the intended recipient please >>>>>> notify us immediately by replying to the sender and delete this >>>>>> E-Mail and your reply from your system. All the views and opinions >>>>>> published here are solely based on the author's own opinion and >>>>>> should not be considered >>>> necessarily as reflecting the opinion of Intergraph. >>>> > From steve.hruda at hexagongeospatial.com Tue Jun 30 20:47:40 2015 From: steve.hruda at hexagongeospatial.com (Hruda, Steve) Date: Tue, 30 Jun 2015 20:47:40 +0000 Subject: Patch for JDK-8090098 - [regression] Webview - getTimezoneOffset() of a ISO strings returns a wrong value In-Reply-To: <5592FFDB.5090501@oracle.com> References: <559191AA.8030800@oracle.com> <5592D943.3090407@oracle.com> <5592E269.6050200@oracle.com> <5592FFDB.5090501@oracle.com> Message-ID: Is a regression not release critical? Diese E-Mail wurde versandt im Auftrag des Unternehmens Intergraph Ges.m.b.H. Vertretungsberechtigte Gesch?ftsf?hrer: Maximilian Weber Sitz der Gesellschaft: Margaretenstra?e 70/I/1, 1050 Wien, ?sterreich, Tel. +43 (1) 9610567-0 Eingetragen beim Handelsgericht Wien, Firmenbuch-Nr.: FN 116859 b Umsatzsteuer-Identifikationsnummer / VAT-ID: ATU15138401, Steuer-Nummer: 264/4807 This E-Mail has been sent on behalf of the company Intergraph Ges.m.b.H. Authorised Managing Directors: Maximilian Weber Registered office and Austrian headquarters: Margaretenstr. 70/I/1, 1050 Wien, Austria, Tel. +43 (1) 9610567-0 The company is recorded at the commercial court of Vienna under the company register number FN 116859 b VAT-ID: ATU15138401, Austrian Tax ID: 264/4807 Diese E-Mail (mit zugeh?rigen Dateien) enth?lt m?glicherweise Informationen, die vertraulich sind, dem Urheberrecht unterliegen oder ein Gesch?ftsgeheimnis darstellen. Falls Sie diese Nachricht irrt?mlicherweise erhalten haben, benachrichtigen Sie uns bitte umgehend, indem Sie eine Antwort senden, und l?schen Sie bitte diese E-Mail und Ihre Antwort darauf. S?mtliche aufgef?hrten Ansichten oder Meinungen sind ausschlie?lich diejenigen des Autors und entsprechen nicht notwendigerweise denen des Unternehmens Intergraph. This E-Mail (and any attachments) may be confidential and protected by legal privilege. If you are not the intended recipient please notify us immediately by replying to the sender and delete this E-Mail and your reply from your system. All the views and opinions published here are solely based on the author's own opinion and should not be considered necessarily as reflecting the opinion of Intergraph. -----Original Message----- From: Kevin Rushforth [mailto:kevin.rushforth at oracle.com] Sent: Tuesday, June 30, 2015 10:45 PM To: Anton V. Tarasov Cc: Hruda, Steve; openjfx-dev at openjdk.java.net Subject: Re: Patch for JDK-8090098 - [regression] Webview - getTimezoneOffset() of a ISO strings returns a wrong value Anton V. Tarasov wrote: > On 30.06.2015 21:13, Hruda, Steve wrote: >> Hi Anton, >> thanks for the detailed information and the good news. >> >> You talk about JDK's jira? Am I right? ..... I don't have an access >> for that JIRA system since the JavaFX's Jira has moved to the JDK Bug >> System. > > Ah, ok. Then I'll quote your e-mail. > >> >> About the Apple stuff. >> I know that Apple dropped Windows Safari support and in my opinion is >> this a very bad situation for WebKit (in case of Windows).... and >> especially since Google and Opera using Google's Blink engine. >> >> In case of the JDK it would be more practicable to switch from WebKit >> to Blink, because this engine is still used by Companies which have >> Windows end-users. >> >> There is a high probability that WebKit get more such bugs if there >> is no big player like Google or Apple who has the man power to fix >> such OS dependent issues. > > I see. However, switching to Blink is another story. Honestly, we're > not planning it in the nearest future. This requires extra resources > which we don't have at the moment... > >> >> Last questions: >> Do you need any additional information from my side? And is it >> possible to integrate this fix in 8u60? > > From my side, I'll do a sanity check with WebKit LayoutTests, then if > it goes well, we can consider commiting this to 8u60. > > @Kevin, do you think we can? Very unlikely. The JDK release team would need to approve, and only release-critical issues may be considered at this point (it would be hard to argue that this is release-critical since it has already been deferred). -- Kevin > Also, as an option for you (Steve). You can post the changes to the > WebKit alias and ask if they think this is a valid fix for the issue. > Any confirmation from the WebKit team would help us to make sure the > fix is reliable. > > Thanks! > Anton. > >> >> Thanks in advance! >> Best Regards, >> Steve >> >> >> >> >> Diese E-Mail wurde versandt im Auftrag des Unternehmens Intergraph >> Ges.m.b.H. >> Vertretungsberechtigte Gesch?ftsf?hrer: Maximilian Weber Sitz der >> Gesellschaft: Margaretenstra?e 70/I/1, 1050 Wien, ?sterreich, Tel. >> +43 (1) 9610567-0 Eingetragen beim Handelsgericht Wien, >> Firmenbuch-Nr.: FN 116859 b Umsatzsteuer-Identifikationsnummer / >> VAT-ID: ATU15138401, >> Steuer-Nummer: 264/4807 >> >> This E-Mail has been sent on behalf of the company Intergraph Ges.m.b.H. >> Authorised Managing Directors: Maximilian Weber Registered office and >> Austrian headquarters: Margaretenstr. 70/I/1, >> 1050 Wien, Austria, Tel. +43 (1) 9610567-0 The company is recorded at >> the commercial court of Vienna under the company register number FN >> 116859 b >> VAT-ID: ATU15138401, Austrian Tax ID: 264/4807 >> >> Diese E-Mail (mit zugeh?rigen Dateien) enth?lt m?glicherweise >> Informationen, die vertraulich sind, dem Urheberrecht unterliegen >> oder ein Gesch?ftsgeheimnis darstellen. Falls Sie diese Nachricht >> irrt?mlicherweise erhalten haben, benachrichtigen Sie uns bitte >> umgehend, indem Sie eine Antwort senden, und l?schen Sie bitte diese >> E-Mail und Ihre Antwort darauf. S?mtliche aufgef?hrten Ansichten oder >> Meinungen sind ausschlie?lich diejenigen des Autors und entsprechen >> nicht notwendigerweise denen des Unternehmens Intergraph. >> >> This E-Mail (and any attachments) may be confidential and protected >> by legal privilege. If you are not the intended recipient please >> notify us immediately by replying to the sender and delete this >> E-Mail and your reply from your system. All the views and opinions >> published here are solely based on the author's own opinion and >> should not be considered necessarily as reflecting the opinion of >> Intergraph. >> >> >> -----Original Message----- >> From: Anton V. Tarasov [mailto:anton.tarasov at oracle.com] >> Sent: Tuesday, June 30, 2015 8:01 PM >> To: Hruda, Steve; Kevin Rushforth >> Cc: openjfx-dev at openjdk.java.net >> Subject: Re: Patch for JDK-8090098 - [regression] Webview - >> getTimezoneOffset() of a ISO strings returns a wrong value >> >> Steve, >> >> I applied your suggestion and it worked on Windows. >> >> The missed check you discovered could really be a mistake in WebKit, >> because Apple dropped releasing (and shipping nightly builds for) >> Safari for Windows at 2012. >> Safari 5.1.7 was the last version. I downloaded and checked it. The >> date bug is not reproducible with it, but this gives us almost >> nothing taking into account the version is much outdated. >> >> So that Windows code path might not have been well tested, since >> http://trac.webkit.org/changeset/159892 was commited... >> >> (WebKit Win port is still supported and can be built on your own.) >> >> What I can do else to verify the changes is to run WebKit LayoutTests >> aimed at date testing and see if there're no regressions. >> >> Also, please put the info you posted into JIRA. >> >> Regards, >> Anton. >> >> On 29.06.2015 21:42, Anton Tarasov wrote: >>> Hi Steve, >>> >>> Ok, I'll investigate it. >>> >>> Thanks, >>> Anton. >>> >>> On 29.06.2015 18:39, Hruda, Steve wrote: >>>> Hi Anton & Kevin, >>>> >>>> we read your comments in the JDK bug system and analyzed WebKit's >>>> changesets again. >>>> >>>> We?ve found the code which made this regression. >>>> >>>> http://trac.webkit.org/changeset/159892 >>>> >>>> This changeset doesn't handle one special case, which was handled >>>> by the previous code.... >>>> >>>> double diff = ((localSystemTime.wHour - offsetHour) * >>>> secondsPerHour) >>>> + ((localSystemTime.wMinute >>>> - offsetMinute) *60); >>>> >>>> >>>> (http://trac.webkit.org/browser/trunk/Source/WTF/wtf/DateMath.cpp?a >>>> nn >>>> otate=blame#L481 ) >>>> >>>> The diff is wrong if the calculated the offsetTime is one day >>>> before in case of the extreme values (e.g. midnight) where the >>>> offsetHour of the UTC time is 23 because of the day difference. >>>> >>>> In case of all other OS systems you will see the same code -> >>>> http://trac.webkit.org/browser/trunk/Source/WTF/wtf/DateMath.cpp?an >>>> no >>>> tate=blame#L495 >>>> >>>> But there are two additional lines -> 497 & 497 which fixes this >>>> special case? >>>> >>>> *if*(diff<0) >>>> >>>> diff += secondsPerDay; >>>> >>>> >>>> That means ?. >>>> >>>> localSystemTime.wHour = 0; >>>> >>>> offsetHour=23 ? which causes a negative value ? and the >>>> diff+=secondsPerDay ensures that the diff result would be one Hour >>>> instead of -23 hours >>>> >>>> We?ve found the attached V8DateTests.js (renamed to .txt) and >>>> adjusted it a little bit to get the results logged in the browsers >>>> console. >>>> >>>> As you can see at ?ResulBeforeOurBugFix.txt? and >>>> ?ResultAfterOurBugFix.txt?, we were able to fix >>>> 6 tests which failed before out bug fix. >>>> >>>> assertEquals("Sat Oct 25 2014 23:00:00 GMT+0200 (W. Europe Daylight >>>> Time)", >>>> >>>> (new Date(2014, 9, 25, 23, 0)).toString()); >>>> >>>> assertEquals("Sat, 25 Oct 2014 21:00:00 GMT", >>>> >>>> (new Date(2014, 9, 25, 23, 0)).toUTCString()); >>>> >>>> assertEquals("Sat Oct 25 2014 23:59:00 GMT+0200 (W. Europe >>>> Daylight Time)", >>>> >>>> (new Date(2014, 9, 25, 23, 59)).toString()); >>>> >>>> assertEquals("Sat, 25 Oct 2014 21:59:00 GMT", >>>> >>>> (new Date(2014, 9, 25, 23, 59)).toUTCString()); >>>> >>>> assertEquals("Sun Oct 26 2014 00:00:00 GMT+0200 (W. Europe >>>> Daylight Time)", >>>> >>>> (new Date(2014, 9, 26, 0, 0)).toString()); >>>> >>>> assertEquals("Sun Oct 26 2014 00:59:00 GMT+0200 (W. Europe Daylight >>>> Time)", >>>> >>>> (new Date(2014, 9, 26, 0, 59)).toString()); >>>> >>>> In addition we found out that WebKit also have problems in case of >>>> Windows in case of the change from winter to summer time. >>>> >>>> *_Winter to summer time:_* >>>> >>>> assertEquals("Sun Mar 30 2014 03:00:00 GMT+0200 (W. Europe Daylight >>>> Time)", >>>> >>>> (new Date(2014, 2, 30, 2, 0)).toString()); >>>> >>>> assertEquals("Sun, 30 Mar 2014 01:00:00 GMT", >>>> >>>> (new Date(2014, 2, 30, 2, 0)).toUTCString()); >>>> >>>> assertEquals("Sun Mar 30 2014 03:59:00 GMT+0200 (W. Europe >>>> Daylight Time)", >>>> >>>> (new Date(2014, 2, 30, 2, 59)).toString()); >>>> >>>> assertEquals("Sun, 30 Mar 2014 01:59:00 GMT", >>>> >>>> (new Date(2014, 2, 30, 2, 59)).toUTCString()); >>>> >>>> *_Summer to winter time:_* >>>> >>>> assertEquals("Sun Oct 26 2014 02:00:00 GMT+0200 (W. Europe Daylight >>>> Time)", >>>> >>>> (new Date(2014, 9, 26, 2, 0)).toString()); >>>> >>>> assertEquals("Sun, 26 Oct 2014 00:00:00 GMT", >>>> >>>> (new Date(2014, 9, 26, 2, 0)).toUTCString()); >>>> >>>> assertEquals("Sun Oct 26 2014 02:59:00 GMT+0200 (W. Europe >>>> Daylight Time)", >>>> >>>> (new Date(2014, 9, 26, 2, 59)).toString()); >>>> >>>> assertEquals("Sun, 26 Oct 2014 00:59:00 GMT", >>>> >>>> (new Date(2014, 9, 26, 2, 59)).toUTCString()); >>>> >>>> We will try to find a solution for that, but I think that the >>>> priority of this issue is lower than the priority of the opened >>>> regression. >>>> >>>> It would be amazing if you can add the patch of my previous and >>>> these additional two lines >>>> (DateMath.cpp) to the JDK8u60. >>>> >>>> Best Regards, >>>> >>>> Steve >>>> >>>> >>>> Diese E-Mail wurde versandt im Auftrag des Unternehmens Intergraph >>>> Ges.m.b.H. >>>> Vertretungsberechtigte Gesch?ftsf?hrer: Maximilian Weber Sitz der >>>> Gesellschaft: Margaretenstra?e 70/I/1, 1050 Wien, ?sterreich, Tel. >>>> +43 (1) 9610567-0 Eingetragen beim Handelsgericht Wien, >>>> Firmenbuch-Nr.: FN 116859 b Umsatzsteuer-Identifikationsnummer / >>>> VAT-ID: ATU15138401, Steuer-Nummer: 264/4807 >>>> >>>> This E-Mail has been sent on behalf of the company Intergraph >>>> Ges.m.b.H. >>>> Authorised Managing Directors: Maximilian Weber Registered office >>>> and Austrian headquarters: Margaretenstr. 70/I/1, 1050 Wien, >>>> Austria, Tel. +43 >>>> (1) 9610567-0 >>>> The company is recorded at the commercial court of Vienna under the >>>> company register number FN >>>> 116859 b >>>> VAT-ID: ATU15138401, Austrian Tax ID: 264/4807 >>>> >>>> Diese E-Mail (mit zugeh?rigen Dateien) enth?lt m?glicherweise >>>> Informationen, die vertraulich sind, dem Urheberrecht unterliegen >>>> oder ein Gesch?ftsgeheimnis darstellen. Falls Sie diese Nachricht >>>> irrt?mlicherweise erhalten haben, benachrichtigen Sie uns bitte >>>> umgehend, indem Sie eine Antwort senden, und l?schen Sie bitte >>>> diese E-Mail und Ihre Antwort darauf. S?mtliche aufgef?hrten >>>> Ansichten oder Meinungen sind ausschlie?lich diejenigen des Autors >>>> und entsprechen nicht notwendigerweise denen des Unternehmens Intergraph. >>>> >>>> This E-Mail (and any attachments) may be confidential and protected >>>> by legal privilege. If you are not the intended recipient please >>>> notify us immediately by replying to the sender and delete this >>>> E-Mail and your reply from your system. All the views and opinions >>>> published here are solely based on the author's own opinion and >>>> should not be considered necessarily as reflecting the opinion of >>>> Intergraph. >>>> >>>> -----Original Message----- >>>> >>>> From: openjfx-dev [mailto:openjfx-dev-bounces at openjdk.java.net] On >>>> Behalf Of Hruda, Steve >>>> >>>> Sent: Tuesday, June 23, 2015 6:26 PM >>>> >>>> To: Anton V. Tarasov; Kevin Rushforth >>>> >>>> Cc: openjfx-dev at openjdk.java.net >>>> >>>> Subject: RE: Patch for JDK-8090098 - [regression] Webview - >>>> getTimezoneOffset() of a ISO strings returns a wrong value >>>> >>>> Very cool Anton. >>>> >>>> I would be great if that pach could be added to 8u60, otherwise our >>>> all our customers have to avoid Java 8u60. >>>> >>>> Regards, >>>> >>>> Steve >>>> >>>> Diese E-Mail wurde versandt im Auftrag des Unternehmens Intergraph >>>> Ges.m.b.H. >>>> >>>> Vertretungsberechtigte Gesch?ftsf?hrer: Maximilian Weber Sitz der >>>> Gesellschaft: Margaretenstra?e 70/I/1, 1050 Wien, ?sterreich, Tel. >>>> +43 (1) 9610567-0 Eingetragen beim Handelsgericht Wien, >>>> Firmenbuch-Nr.: FN 116859 b Umsatzsteuer-Identifikationsnummer / >>>> VAT-ID: ATU15138401, >>>> Steuer-Nummer: 264/4807 >>>> >>>> This E-Mail has been sent on behalf of the company Intergraph >>>> Ges.m.b.H. >>>> >>>> Authorised Managing Directors: Maximilian Weber Registered office >>>> and Austrian headquarters: >>>> Margaretenstr. 70/I/1, 1050 Wien, Austria, Tel. +43 (1) 9610567-0 >>>> The company is recorded at the commercial court of Vienna under the >>>> company register number FN 116859 b >>>> >>>> VAT-ID: ATU15138401, Austrian Tax ID: 264/4807 >>>> >>>> Diese E-Mail (mit zugeh?rigen Dateien) enth?lt m?glicherweise >>>> Informationen, die vertraulich sind, dem Urheberrecht unterliegen >>>> oder ein Gesch?ftsgeheimnis darstellen. Falls Sie diese Nachricht >>>> irrt?mlicherweise erhalten haben, benachrichtigen Sie uns bitte >>>> umgehend, indem Sie eine Antwort senden, und l?schen Sie bitte >>>> diese E-Mail und Ihre Antwort darauf. S?mtliche aufgef?hrten >>>> Ansichten oder Meinungen sind ausschlie?lich diejenigen des Autors >>>> und entsprechen nicht notwendigerweise denen des Unternehmens Intergraph. >>>> >>>> This E-Mail (and any attachments) may be confidential and protected >>>> by legal privilege. If you are not the intended recipient please >>>> notify us immediately by replying to the sender and delete this >>>> E-Mail and your reply from your system. All the views and opinions >>>> published here are solely based on the author's own opinion and >>>> should not be considered necessarily as reflecting the opinion of >>>> Intergraph. >>>> >>>> -----Original Message----- >>>> >>>> From: Anton V. Tarasov [mailto:anton.tarasov at oracle.com] >>>> >>>> Sent: Tuesday, June 23, 2015 5:46 PM >>>> >>>> To: Kevin Rushforth; Hruda, Steve >>>> >>>> Cc: openjfx-dev at openjdk.java.net >>>> >>>> Subject: Re: Patch for JDK-8090098 - [regression] Webview - >>>> getTimezoneOffset() of a ISO strings returns a wrong value >>>> >>>> On 23.06.2015 17:48, Kevin Rushforth wrote: >>>> >>>>> Hi Steve, >>>>> Thank you for taking the time to create this patch. I will add >>>>> this information to the bug report. >>>>> Since your OCA is in progress we will take a look at your patch, >>>>> but will need indication from the OCA office that it the OCA has >>>>> been received before we could push it. And just to be clear, you >>>>> won't have access to the repository even with an OCA. What the OCA >>>>> will do is allow you to contribute >>>> patches. >>>> >>>>> I will note that it is likely too late for 8u60, but Anton can >>>>> evaluate it and post his comment in the bug report. >>>> Kevin, >>>> >>>> I'm checking it. >>>> >>>> Steve, thanks for the participation! >>>> >>>> Regards, >>>> >>>> Anton. >>>> >>>>> -- Kevin >>>>> Hruda, Steve wrote: >>>>>> Hi, >>>>>> I've created a 8u-dev patch for the following WeKit regression >>>>>> which comes with 8u60. >>>>>> https://bugs.openjdk.java.net/browse/JDK-8090098 >>>>>> Please can someone of you apply this patch to fix the >>>>>> getTimezoneOffset() issue. I have no access to the repository -> >>>>>> my OCA is still pending. >>>>>> In addition I tried to test this patch , but I wasn't able to >>>>>> build the necessary jfxwebkit.dll on my windows system >>>>>> (https://www.mail-archive.com/openjfx-dev at openjdk.java.net/msg094 >>>>>> 3 >>>>>> 9.h >>>>>> tml )..... but I got no compile erros on Mac. >>>>>> Patch download: >>>>>> https://drive.google.com/file/d/0B7P_rknS1TWxM3BSTTU2OVZ4dGM/view >>>>>> ?u >>>>>> sp >>>>>> =sharing >>>>>> The patch includes the following WebKit fixes: >>>>>> Changeset 174377 - [Win] DateMath's calculateUTFOffset does not >>>>>> account for DST. >>>>>> http://trac.webkit.org/changeset/174377 >>>>>> Changeset 175078 - String(new Date(Mar 30 2014 01:00:00)) is >>>>>> wrong in CET >>>>>> http://trac.webkit.org/changeset/175078 >>>>>> Changeset 181360 - [Win] 17 different JSC tests started to fail >>>>>> in DST >>>>>> http://trac.webkit.org/changeset/181360 >>>>>> Please let me know if you need further information. >>>>>> Thanks in advance! >>>>>> Best Regards >>>>>> Steve >>>>>> Diese E-Mail wurde versandt im Auftrag des Unternehmens >>>>>> Intergraph Ges.m.b.H. >>>>>> Vertretungsberechtigte Gesch?ftsf?hrer: Maximilian Weber Sitz der >>>>>> Gesellschaft: Margaretenstra?e 70/I/1, 1050 Wien, ?sterreich, Tel. >>>>>> +43 (1) 9610567-0 Eingetragen beim Handelsgericht Wien, >>>>>> Firmenbuch-Nr.: FN 116859 b Umsatzsteuer-Identifikationsnummer / >>>>>> VAT-ID: ATU15138401, Steuer-Nummer: 264/4807 This E-Mail has been >>>>>> sent on behalf of the company Intergraph Ges.m.b.H. >>>>>> Authorised Managing Directors: Maximilian Weber Registered office >>>>>> and Austrian headquarters: Margaretenstr. 70/I/1, 1050 Wien, >>>>>> Austria, Tel. +43 >>>>>> (1) 9610567-0 >>>>>> The company is recorded at the commercial court of Vienna under >>>>>> the company register number FN >>>>>> 116859 b >>>>>> VAT-ID: ATU15138401, Austrian Tax ID: 264/4807 Diese E-Mail (mit >>>>>> zugeh?rigen Dateien) enth?lt m?glicherweise Informationen, die >>>>>> vertraulich sind, dem Urheberrecht unterliegen oder ein >>>>>> Gesch?ftsgeheimnis darstellen. Falls Sie diese Nachricht >>>>>> irrt?mlicherweise erhalten haben, benachrichtigen Sie uns bitte >>>>>> umgehend, indem Sie eine Antwort senden, und l?schen Sie bitte >>>>>> diese E-Mail und Ihre Antwort darauf. S?mtliche aufgef?hrten >>>>>> Ansichten oder Meinungen sind >>>> ausschlie?lich diejenigen des Autors und entsprechen nicht >>>> notwendigerweise denen des Unternehmens Intergraph. >>>> >>>>>> This E-Mail (and any attachments) may be confidential and >>>>>> protected by legal privilege. If you are not the intended >>>>>> recipient please notify us immediately by replying to the sender >>>>>> and delete this E-Mail and your reply from your system. All the >>>>>> views and opinions published here are solely based on the >>>>>> author's own opinion and should not be considered >>>> necessarily as reflecting the opinion of Intergraph. >>>> > From kevin.rushforth at oracle.com Tue Jun 30 21:16:32 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 30 Jun 2015 14:16:32 -0700 Subject: Patch for JDK-8090098 - [regression] Webview - getTimezoneOffset() of a ISO strings returns a wrong value In-Reply-To: References: <559191AA.8030800@oracle.com> <5592D943.3090407@oracle.com> <5592E269.6050200@oracle.com> <5592FFDB.5090501@oracle.com> Message-ID: <55930730.6050302@oracle.com> Not by itself, although regressions are certainly taken very seriously. In any case, the process is to get this into 9-dev (once it has been reviewed), test it thoroughly, and then consider whether we can make a case for taking it to the 8u60 release team. -- Kevin Hruda, Steve wrote: > Is a regression not release critical? > > > > > Diese E-Mail wurde versandt im Auftrag des Unternehmens Intergraph Ges.m.b.H. > Vertretungsberechtigte Gesch?ftsf?hrer: Maximilian Weber > Sitz der Gesellschaft: Margaretenstra?e 70/I/1, 1050 Wien, ?sterreich, Tel. +43 (1) 9610567-0 > Eingetragen beim Handelsgericht Wien, Firmenbuch-Nr.: FN 116859 b > Umsatzsteuer-Identifikationsnummer / VAT-ID: ATU15138401, Steuer-Nummer: 264/4807 > > This E-Mail has been sent on behalf of the company Intergraph Ges.m.b.H. > Authorised Managing Directors: Maximilian Weber > Registered office and Austrian headquarters: Margaretenstr. 70/I/1, 1050 Wien, Austria, Tel. +43 (1) 9610567-0 > The company is recorded at the commercial court of Vienna under the company register number FN 116859 b > VAT-ID: ATU15138401, Austrian Tax ID: 264/4807 > > Diese E-Mail (mit zugeh?rigen Dateien) enth?lt m?glicherweise Informationen, die vertraulich sind, dem Urheberrecht unterliegen oder ein Gesch?ftsgeheimnis darstellen. Falls Sie diese Nachricht irrt?mlicherweise erhalten haben, benachrichtigen Sie uns bitte umgehend, indem Sie eine Antwort senden, und l?schen Sie bitte diese E-Mail und Ihre Antwort darauf. S?mtliche aufgef?hrten Ansichten oder Meinungen sind ausschlie?lich diejenigen des Autors und entsprechen nicht notwendigerweise denen des Unternehmens Intergraph. > > This E-Mail (and any attachments) may be confidential and protected by legal privilege. If you are not the intended recipient please notify us immediately by replying to the sender and delete this E-Mail and your reply from your system. All the views and opinions published here are solely based on the author's own opinion and should not be considered necessarily as reflecting the opinion of Intergraph. > > > -----Original Message----- > From: Kevin Rushforth [mailto:kevin.rushforth at oracle.com] > Sent: Tuesday, June 30, 2015 10:45 PM > To: Anton V. Tarasov > Cc: Hruda, Steve; openjfx-dev at openjdk.java.net > Subject: Re: Patch for JDK-8090098 - [regression] Webview - getTimezoneOffset() of a ISO strings returns a wrong value > > > > Anton V. Tarasov wrote: > >> On 30.06.2015 21:13, Hruda, Steve wrote: >> >>> Hi Anton, >>> thanks for the detailed information and the good news. >>> >>> You talk about JDK's jira? Am I right? ..... I don't have an access >>> for that JIRA system since the JavaFX's Jira has moved to the JDK Bug >>> System. >>> >> Ah, ok. Then I'll quote your e-mail. >> >> >>> About the Apple stuff. >>> I know that Apple dropped Windows Safari support and in my opinion is >>> this a very bad situation for WebKit (in case of Windows).... and >>> especially since Google and Opera using Google's Blink engine. >>> >>> In case of the JDK it would be more practicable to switch from WebKit >>> to Blink, because this engine is still used by Companies which have >>> Windows end-users. >>> >>> There is a high probability that WebKit get more such bugs if there >>> is no big player like Google or Apple who has the man power to fix >>> such OS dependent issues. >>> >> I see. However, switching to Blink is another story. Honestly, we're >> not planning it in the nearest future. This requires extra resources >> which we don't have at the moment... >> >> >>> Last questions: >>> Do you need any additional information from my side? And is it >>> possible to integrate this fix in 8u60? >>> >> From my side, I'll do a sanity check with WebKit LayoutTests, then if >> it goes well, we can consider commiting this to 8u60. >> >> @Kevin, do you think we can? >> > > Very unlikely. The JDK release team would need to approve, and only release-critical issues may be considered at this point (it would be hard to argue that this is release-critical since it has already been deferred). > > -- Kevin > > > >> Also, as an option for you (Steve). You can post the changes to the >> WebKit alias and ask if they think this is a valid fix for the issue. >> Any confirmation from the WebKit team would help us to make sure the >> fix is reliable. >> >> Thanks! >> Anton. >> >> >>> Thanks in advance! >>> Best Regards, >>> Steve >>> >>> >>> >>> >>> Diese E-Mail wurde versandt im Auftrag des Unternehmens Intergraph >>> Ges.m.b.H. >>> Vertretungsberechtigte Gesch?ftsf?hrer: Maximilian Weber Sitz der >>> Gesellschaft: Margaretenstra?e 70/I/1, 1050 Wien, ?sterreich, Tel. >>> +43 (1) 9610567-0 Eingetragen beim Handelsgericht Wien, >>> Firmenbuch-Nr.: FN 116859 b Umsatzsteuer-Identifikationsnummer / >>> VAT-ID: ATU15138401, >>> Steuer-Nummer: 264/4807 >>> >>> This E-Mail has been sent on behalf of the company Intergraph Ges.m.b.H. >>> Authorised Managing Directors: Maximilian Weber Registered office and >>> Austrian headquarters: Margaretenstr. 70/I/1, >>> 1050 Wien, Austria, Tel. +43 (1) 9610567-0 The company is recorded at >>> the commercial court of Vienna under the company register number FN >>> 116859 b >>> VAT-ID: ATU15138401, Austrian Tax ID: 264/4807 >>> >>> Diese E-Mail (mit zugeh?rigen Dateien) enth?lt m?glicherweise >>> Informationen, die vertraulich sind, dem Urheberrecht unterliegen >>> oder ein Gesch?ftsgeheimnis darstellen. Falls Sie diese Nachricht >>> irrt?mlicherweise erhalten haben, benachrichtigen Sie uns bitte >>> umgehend, indem Sie eine Antwort senden, und l?schen Sie bitte diese >>> E-Mail und Ihre Antwort darauf. S?mtliche aufgef?hrten Ansichten oder >>> Meinungen sind ausschlie?lich diejenigen des Autors und entsprechen >>> nicht notwendigerweise denen des Unternehmens Intergraph. >>> >>> This E-Mail (and any attachments) may be confidential and protected >>> by legal privilege. If you are not the intended recipient please >>> notify us immediately by replying to the sender and delete this >>> E-Mail and your reply from your system. All the views and opinions >>> published here are solely based on the author's own opinion and >>> should not be considered necessarily as reflecting the opinion of >>> Intergraph. >>> >>> >>> -----Original Message----- >>> From: Anton V. Tarasov [mailto:anton.tarasov at oracle.com] >>> Sent: Tuesday, June 30, 2015 8:01 PM >>> To: Hruda, Steve; Kevin Rushforth >>> Cc: openjfx-dev at openjdk.java.net >>> Subject: Re: Patch for JDK-8090098 - [regression] Webview - >>> getTimezoneOffset() of a ISO strings returns a wrong value >>> >>> Steve, >>> >>> I applied your suggestion and it worked on Windows. >>> >>> The missed check you discovered could really be a mistake in WebKit, >>> because Apple dropped releasing (and shipping nightly builds for) >>> Safari for Windows at 2012. >>> Safari 5.1.7 was the last version. I downloaded and checked it. The >>> date bug is not reproducible with it, but this gives us almost >>> nothing taking into account the version is much outdated. >>> >>> So that Windows code path might not have been well tested, since >>> http://trac.webkit.org/changeset/159892 was commited... >>> >>> (WebKit Win port is still supported and can be built on your own.) >>> >>> What I can do else to verify the changes is to run WebKit LayoutTests >>> aimed at date testing and see if there're no regressions. >>> >>> Also, please put the info you posted into JIRA. >>> >>> Regards, >>> Anton. >>> >>> On 29.06.2015 21:42, Anton Tarasov wrote: >>> >>>> Hi Steve, >>>> >>>> Ok, I'll investigate it. >>>> >>>> Thanks, >>>> Anton. >>>> >>>> On 29.06.2015 18:39, Hruda, Steve wrote: >>>> >>>>> Hi Anton & Kevin, >>>>> >>>>> we read your comments in the JDK bug system and analyzed WebKit's >>>>> changesets again. >>>>> >>>>> We?ve found the code which made this regression. >>>>> >>>>> http://trac.webkit.org/changeset/159892 >>>>> >>>>> This changeset doesn't handle one special case, which was handled >>>>> by the previous code.... >>>>> >>>>> double diff = ((localSystemTime.wHour - offsetHour) * >>>>> secondsPerHour) >>>>> + ((localSystemTime.wMinute >>>>> - offsetMinute) *60); >>>>> >>>>> >>>>> (http://trac.webkit.org/browser/trunk/Source/WTF/wtf/DateMath.cpp?a >>>>> nn >>>>> otate=blame#L481 ) >>>>> >>>>> The diff is wrong if the calculated the offsetTime is one day >>>>> before in case of the extreme values (e.g. midnight) where the >>>>> offsetHour of the UTC time is 23 because of the day difference. >>>>> >>>>> In case of all other OS systems you will see the same code -> >>>>> http://trac.webkit.org/browser/trunk/Source/WTF/wtf/DateMath.cpp?an >>>>> no >>>>> tate=blame#L495 >>>>> >>>>> But there are two additional lines -> 497 & 497 which fixes this >>>>> special case? >>>>> >>>>> *if*(diff<0) >>>>> >>>>> diff += secondsPerDay; >>>>> >>>>> >>>>> That means ?. >>>>> >>>>> localSystemTime.wHour = 0; >>>>> >>>>> offsetHour=23 ? which causes a negative value ? and the >>>>> diff+=secondsPerDay ensures that the diff result would be one Hour >>>>> instead of -23 hours >>>>> >>>>> We?ve found the attached V8DateTests.js (renamed to .txt) and >>>>> adjusted it a little bit to get the results logged in the browsers >>>>> console. >>>>> >>>>> As you can see at ?ResulBeforeOurBugFix.txt? and >>>>> ?ResultAfterOurBugFix.txt?, we were able to fix >>>>> 6 tests which failed before out bug fix. >>>>> >>>>> assertEquals("Sat Oct 25 2014 23:00:00 GMT+0200 (W. Europe Daylight >>>>> Time)", >>>>> >>>>> (new Date(2014, 9, 25, 23, 0)).toString()); >>>>> >>>>> assertEquals("Sat, 25 Oct 2014 21:00:00 GMT", >>>>> >>>>> (new Date(2014, 9, 25, 23, 0)).toUTCString()); >>>>> >>>>> assertEquals("Sat Oct 25 2014 23:59:00 GMT+0200 (W. Europe >>>>> Daylight Time)", >>>>> >>>>> (new Date(2014, 9, 25, 23, 59)).toString()); >>>>> >>>>> assertEquals("Sat, 25 Oct 2014 21:59:00 GMT", >>>>> >>>>> (new Date(2014, 9, 25, 23, 59)).toUTCString()); >>>>> >>>>> assertEquals("Sun Oct 26 2014 00:00:00 GMT+0200 (W. Europe >>>>> Daylight Time)", >>>>> >>>>> (new Date(2014, 9, 26, 0, 0)).toString()); >>>>> >>>>> assertEquals("Sun Oct 26 2014 00:59:00 GMT+0200 (W. Europe Daylight >>>>> Time)", >>>>> >>>>> (new Date(2014, 9, 26, 0, 59)).toString()); >>>>> >>>>> In addition we found out that WebKit also have problems in case of >>>>> Windows in case of the change from winter to summer time. >>>>> >>>>> *_Winter to summer time:_* >>>>> >>>>> assertEquals("Sun Mar 30 2014 03:00:00 GMT+0200 (W. Europe Daylight >>>>> Time)", >>>>> >>>>> (new Date(2014, 2, 30, 2, 0)).toString()); >>>>> >>>>> assertEquals("Sun, 30 Mar 2014 01:00:00 GMT", >>>>> >>>>> (new Date(2014, 2, 30, 2, 0)).toUTCString()); >>>>> >>>>> assertEquals("Sun Mar 30 2014 03:59:00 GMT+0200 (W. Europe >>>>> Daylight Time)", >>>>> >>>>> (new Date(2014, 2, 30, 2, 59)).toString()); >>>>> >>>>> assertEquals("Sun, 30 Mar 2014 01:59:00 GMT", >>>>> >>>>> (new Date(2014, 2, 30, 2, 59)).toUTCString()); >>>>> >>>>> *_Summer to winter time:_* >>>>> >>>>> assertEquals("Sun Oct 26 2014 02:00:00 GMT+0200 (W. Europe Daylight >>>>> Time)", >>>>> >>>>> (new Date(2014, 9, 26, 2, 0)).toString()); >>>>> >>>>> assertEquals("Sun, 26 Oct 2014 00:00:00 GMT", >>>>> >>>>> (new Date(2014, 9, 26, 2, 0)).toUTCString()); >>>>> >>>>> assertEquals("Sun Oct 26 2014 02:59:00 GMT+0200 (W. Europe >>>>> Daylight Time)", >>>>> >>>>> (new Date(2014, 9, 26, 2, 59)).toString()); >>>>> >>>>> assertEquals("Sun, 26 Oct 2014 00:59:00 GMT", >>>>> >>>>> (new Date(2014, 9, 26, 2, 59)).toUTCString()); >>>>> >>>>> We will try to find a solution for that, but I think that the >>>>> priority of this issue is lower than the priority of the opened >>>>> regression. >>>>> >>>>> It would be amazing if you can add the patch of my previous and >>>>> these additional two lines >>>>> (DateMath.cpp) to the JDK8u60. >>>>> >>>>> Best Regards, >>>>> >>>>> Steve >>>>> >>>>> >>>>> Diese E-Mail wurde versandt im Auftrag des Unternehmens Intergraph >>>>> Ges.m.b.H. >>>>> Vertretungsberechtigte Gesch?ftsf?hrer: Maximilian Weber Sitz der >>>>> Gesellschaft: Margaretenstra?e 70/I/1, 1050 Wien, ?sterreich, Tel. >>>>> +43 (1) 9610567-0 Eingetragen beim Handelsgericht Wien, >>>>> Firmenbuch-Nr.: FN 116859 b Umsatzsteuer-Identifikationsnummer / >>>>> VAT-ID: ATU15138401, Steuer-Nummer: 264/4807 >>>>> >>>>> This E-Mail has been sent on behalf of the company Intergraph >>>>> Ges.m.b.H. >>>>> Authorised Managing Directors: Maximilian Weber Registered office >>>>> and Austrian headquarters: Margaretenstr. 70/I/1, 1050 Wien, >>>>> Austria, Tel. +43 >>>>> (1) 9610567-0 >>>>> The company is recorded at the commercial court of Vienna under the >>>>> company register number FN >>>>> 116859 b >>>>> VAT-ID: ATU15138401, Austrian Tax ID: 264/4807 >>>>> >>>>> Diese E-Mail (mit zugeh?rigen Dateien) enth?lt m?glicherweise >>>>> Informationen, die vertraulich sind, dem Urheberrecht unterliegen >>>>> oder ein Gesch?ftsgeheimnis darstellen. Falls Sie diese Nachricht >>>>> irrt?mlicherweise erhalten haben, benachrichtigen Sie uns bitte >>>>> umgehend, indem Sie eine Antwort senden, und l?schen Sie bitte >>>>> diese E-Mail und Ihre Antwort darauf. S?mtliche aufgef?hrten >>>>> Ansichten oder Meinungen sind ausschlie?lich diejenigen des Autors >>>>> und entsprechen nicht notwendigerweise denen des Unternehmens Intergraph. >>>>> >>>>> This E-Mail (and any attachments) may be confidential and protected >>>>> by legal privilege. If you are not the intended recipient please >>>>> notify us immediately by replying to the sender and delete this >>>>> E-Mail and your reply from your system. All the views and opinions >>>>> published here are solely based on the author's own opinion and >>>>> should not be considered necessarily as reflecting the opinion of >>>>> Intergraph. >>>>> >>>>> -----Original Message----- >>>>> >>>>> From: openjfx-dev [mailto:openjfx-dev-bounces at openjdk.java.net] On >>>>> Behalf Of Hruda, Steve >>>>> >>>>> Sent: Tuesday, June 23, 2015 6:26 PM >>>>> >>>>> To: Anton V. Tarasov; Kevin Rushforth >>>>> >>>>> Cc: openjfx-dev at openjdk.java.net >>>>> >>>>> Subject: RE: Patch for JDK-8090098 - [regression] Webview - >>>>> getTimezoneOffset() of a ISO strings returns a wrong value >>>>> >>>>> Very cool Anton. >>>>> >>>>> I would be great if that pach could be added to 8u60, otherwise our >>>>> all our customers have to avoid Java 8u60. >>>>> >>>>> Regards, >>>>> >>>>> Steve >>>>> >>>>> Diese E-Mail wurde versandt im Auftrag des Unternehmens Intergraph >>>>> Ges.m.b.H. >>>>> >>>>> Vertretungsberechtigte Gesch?ftsf?hrer: Maximilian Weber Sitz der >>>>> Gesellschaft: Margaretenstra?e 70/I/1, 1050 Wien, ?sterreich, Tel. >>>>> +43 (1) 9610567-0 Eingetragen beim Handelsgericht Wien, >>>>> Firmenbuch-Nr.: FN 116859 b Umsatzsteuer-Identifikationsnummer / >>>>> VAT-ID: ATU15138401, >>>>> Steuer-Nummer: 264/4807 >>>>> >>>>> This E-Mail has been sent on behalf of the company Intergraph >>>>> Ges.m.b.H. >>>>> >>>>> Authorised Managing Directors: Maximilian Weber Registered office >>>>> and Austrian headquarters: >>>>> Margaretenstr. 70/I/1, 1050 Wien, Austria, Tel. +43 (1) 9610567-0 >>>>> The company is recorded at the commercial court of Vienna under the >>>>> company register number FN 116859 b >>>>> >>>>> VAT-ID: ATU15138401, Austrian Tax ID: 264/4807 >>>>> >>>>> Diese E-Mail (mit zugeh?rigen Dateien) enth?lt m?glicherweise >>>>> Informationen, die vertraulich sind, dem Urheberrecht unterliegen >>>>> oder ein Gesch?ftsgeheimnis darstellen. Falls Sie diese Nachricht >>>>> irrt?mlicherweise erhalten haben, benachrichtigen Sie uns bitte >>>>> umgehend, indem Sie eine Antwort senden, und l?schen Sie bitte >>>>> diese E-Mail und Ihre Antwort darauf. S?mtliche aufgef?hrten >>>>> Ansichten oder Meinungen sind ausschlie?lich diejenigen des Autors >>>>> und entsprechen nicht notwendigerweise denen des Unternehmens Intergraph. >>>>> >>>>> This E-Mail (and any attachments) may be confidential and protected >>>>> by legal privilege. If you are not the intended recipient please >>>>> notify us immediately by replying to the sender and delete this >>>>> E-Mail and your reply from your system. All the views and opinions >>>>> published here are solely based on the author's own opinion and >>>>> should not be considered necessarily as reflecting the opinion of >>>>> Intergraph. >>>>> >>>>> -----Original Message----- >>>>> >>>>> From: Anton V. Tarasov [mailto:anton.tarasov at oracle.com] >>>>> >>>>> Sent: Tuesday, June 23, 2015 5:46 PM >>>>> >>>>> To: Kevin Rushforth; Hruda, Steve >>>>> >>>>> Cc: openjfx-dev at openjdk.java.net >>>>> >>>>> Subject: Re: Patch for JDK-8090098 - [regression] Webview - >>>>> getTimezoneOffset() of a ISO strings returns a wrong value >>>>> >>>>> On 23.06.2015 17:48, Kevin Rushforth wrote: >>>>> >>>>> >>>>>> Hi Steve, >>>>>> Thank you for taking the time to create this patch. I will add >>>>>> this information to the bug report. >>>>>> Since your OCA is in progress we will take a look at your patch, >>>>>> but will need indication from the OCA office that it the OCA has >>>>>> been received before we could push it. And just to be clear, you >>>>>> won't have access to the repository even with an OCA. What the OCA >>>>>> will do is allow you to contribute >>>>>> >>>>> patches. >>>>> >>>>> >>>>>> I will note that it is likely too late for 8u60, but Anton can >>>>>> evaluate it and post his comment in the bug report. >>>>>> >>>>> Kevin, >>>>> >>>>> I'm checking it. >>>>> >>>>> Steve, thanks for the participation! >>>>> >>>>> Regards, >>>>> >>>>> Anton. >>>>> >>>>> >>>>>> -- Kevin >>>>>> Hruda, Steve wrote: >>>>>> >>>>>>> Hi, >>>>>>> I've created a 8u-dev patch for the following WeKit regression >>>>>>> which comes with 8u60. >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8090098 >>>>>>> Please can someone of you apply this patch to fix the >>>>>>> getTimezoneOffset() issue. I have no access to the repository -> >>>>>>> my OCA is still pending. >>>>>>> In addition I tried to test this patch , but I wasn't able to >>>>>>> build the necessary jfxwebkit.dll on my windows system >>>>>>> (https://www.mail-archive.com/openjfx-dev at openjdk.java.net/msg094 >>>>>>> 3 >>>>>>> 9.h >>>>>>> tml )..... but I got no compile erros on Mac. >>>>>>> Patch download: >>>>>>> https://drive.google.com/file/d/0B7P_rknS1TWxM3BSTTU2OVZ4dGM/view >>>>>>> ?u >>>>>>> sp >>>>>>> =sharing >>>>>>> The patch includes the following WebKit fixes: >>>>>>> Changeset 174377 - [Win] DateMath's calculateUTFOffset does not >>>>>>> account for DST. >>>>>>> http://trac.webkit.org/changeset/174377 >>>>>>> Changeset 175078 - String(new Date(Mar 30 2014 01:00:00)) is >>>>>>> wrong in CET >>>>>>> http://trac.webkit.org/changeset/175078 >>>>>>> Changeset 181360 - [Win] 17 different JSC tests started to fail >>>>>>> in DST >>>>>>> http://trac.webkit.org/changeset/181360 >>>>>>> Please let me know if you need further information. >>>>>>> Thanks in advance! >>>>>>> Best Regards >>>>>>> Steve >>>>>>> Diese E-Mail wurde versandt im Auftrag des Unternehmens >>>>>>> Intergraph Ges.m.b.H. >>>>>>> Vertretungsberechtigte Gesch?ftsf?hrer: Maximilian Weber Sitz der >>>>>>> Gesellschaft: Margaretenstra?e 70/I/1, 1050 Wien, ?sterreich, Tel. >>>>>>> +43 (1) 9610567-0 Eingetragen beim Handelsgericht Wien, >>>>>>> Firmenbuch-Nr.: FN 116859 b Umsatzsteuer-Identifikationsnummer / >>>>>>> VAT-ID: ATU15138401, Steuer-Nummer: 264/4807 This E-Mail has been >>>>>>> sent on behalf of the company Intergraph Ges.m.b.H. >>>>>>> Authorised Managing Directors: Maximilian Weber Registered office >>>>>>> and Austrian headquarters: Margaretenstr. 70/I/1, 1050 Wien, >>>>>>> Austria, Tel. +43 >>>>>>> (1) 9610567-0 >>>>>>> The company is recorded at the commercial court of Vienna under >>>>>>> the company register number FN >>>>>>> 116859 b >>>>>>> VAT-ID: ATU15138401, Austrian Tax ID: 264/4807 Diese E-Mail (mit >>>>>>> zugeh?rigen Dateien) enth?lt m?glicherweise Informationen, die >>>>>>> vertraulich sind, dem Urheberrecht unterliegen oder ein >>>>>>> Gesch?ftsgeheimnis darstellen. Falls Sie diese Nachricht >>>>>>> irrt?mlicherweise erhalten haben, benachrichtigen Sie uns bitte >>>>>>> umgehend, indem Sie eine Antwort senden, und l?schen Sie bitte >>>>>>> diese E-Mail und Ihre Antwort darauf. S?mtliche aufgef?hrten >>>>>>> Ansichten oder Meinungen sind >>>>>>> >>>>> ausschlie?lich diejenigen des Autors und entsprechen nicht >>>>> notwendigerweise denen des Unternehmens Intergraph. >>>>> >>>>> >>>>>>> This E-Mail (and any attachments) may be confidential and >>>>>>> protected by legal privilege. If you are not the intended >>>>>>> recipient please notify us immediately by replying to the sender >>>>>>> and delete this E-Mail and your reply from your system. All the >>>>>>> views and opinions published here are solely based on the >>>>>>> author's own opinion and should not be considered >>>>>>> >>>>> necessarily as reflecting the opinion of Intergraph. >>>>> >>>>> > > From chien.yang at oracle.com Tue Jun 30 21:33:12 2015 From: chien.yang at oracle.com (Chien Yang) Date: Tue, 30 Jun 2015 14:33:12 -0700 Subject: [8u60] Code Review Request For JDK-8130122: Horizontal ListView incorrectly displays long data Message-ID: <55930B18.8020101@oracle.com> Hi Kevin, Please review this proposed fix for a late-breaking regression found during this week's sanity testing: JBS: https://bugs.openjdk.java.net/browse/JDK-8130122 Webrev: http://cr.openjdk.java.net/~ckyang/JDK-8130122/webrev.01/ Thanks, - Chien