From kevin.rushforth at oracle.com Mon Nov 2 15:44:43 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 02 Nov 2015 07:44:43 -0800 Subject: In(Sanity) Testing Mondays In-Reply-To: <56337F83.5080006@oracle.com> References: <56337F83.5080006@oracle.com> Message-ID: <563784EB.9010207@oracle.com> Please note that the US went off of daylight saving time yesterday morning, so the repo will be unlocked at 1pm PST which is an hour later for those outside the US. -- 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 David.Hill at Oracle.com Mon Nov 2 19:01:24 2015 From: David.Hill at Oracle.com (David Hill) Date: Mon, 02 Nov 2015 14:01:24 -0500 Subject: Debug Flags Wiki Page Message-ID: <5637B304.5050804@Oracle.com> Hi all, After Jim reminded me (again) with his recent email - I started a OpenJFX wiki page to note/document the various command line flags we have that are pretty much only documented in email. Please take a look at the rather spare page: https://wiki.openjdk.java.net/display/OpenJFX/Debug+Flags and either add missing ones in, or send me an email and I will add them. Corrections are also welcome, I typed this rather quickly. There are a handful of other ones I know about (mostly font or monocle related) that are covered in other wiki pages, but should be linked back at some point. Dave -- 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 Mon Nov 2 20:57:19 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 02 Nov 2015 12:57:19 -0800 Subject: 9-dev unlocked following sanity testing Message-ID: <5637CE2F.5090602@oracle.com> From james.graham at oracle.com Mon Nov 2 21:24:46 2015 From: james.graham at oracle.com (Jim Graham) Date: Mon, 02 Nov 2015 13:24:46 -0800 Subject: Windows Hi-DPI In-Reply-To: References: <94CE475E-320E-4B81-82F7-5BDBFEEA3386@gmail.com> <5633C9E5.8060503@oracle.com> <02A84A2E-AF14-4037-9B71-783DEEE86FF0@gmail.com> <5633D149.2040809@oracle.com> Message-ID: <5637D49E.6020905@oracle.com> For reference, I just ran the Ensemble8 demo on a Windows 10 laptop with a 200% scaled HiDPI screen (3000x2000) with integrated Intel HD Graphics 520 and it ran smooth as glass, even the 3D samples. The laptop also has an embedded nVidia 900 series GPU, but I need to figure out why it isn't getting used when I run FX. I'll note, though, that this laptop is using an older version of the nVidia drivers (354.15) which was installed by Windows and which is considered "up to date" when I run an update check in the nVidia Control Panel. You appear to be running 358.50 which is the latest WHQL version from nVidia's web site? I looked and nVidia doesn't even offer 354.15 even in their history of drivers... ...jim On 10/30/2015 5:40 PM, Felix Bembrick wrote: > Hi Jim, > > I have experimented with all those options with the following results: > > 1. Turning on verbose proves hardware acceleration is being used. > 2. Increasing texture size and fiddling with the amount of VRAM has no > effect on performance. > 3. Turning off Hi DPI changes the appearance of the app (i.e. controls > are too small etc.) but has no effect on performance. > 4. Disabling hardware acceleration makes it another order of magnitude > slower than before. > > So none of the options improved performance at all. All we know for > sure is that it's using D3D and that it is running so much slower than I > expected and so much so that it is unusable. > > Here's some of the initial output which hopefully shows something about > the issue: > > */Prism pipeline init order: d3d > Using native-based Pisces rasterizer > Using dirty region optimizations > Not using texture mask for primitives > Not forcing power of 2 sizes for textures > Using hardware CLAMP_TO_ZERO mode > Opting in for HiDPI pixel scaling > Prism pipeline name = com.sun.prism.d3d.D3DPipeline > Loading D3D native library ... > succeeded. > D3DPipelineManager: Created D3D9Ex device > Direct3D initialization succeeded > (X) Got class = class com.sun.prism.d3d.D3DPipeline > Initialized prism pipeline: com.sun.prism.d3d.D3DPipeline > Maximum supported texture size: 16384 > Maximum texture size clamped to 8192 > OS Information: > Windows version 10.0 build 10240 > D3D Driver Information: > NVIDIA GeForce GTX TITAN X > \\.\DISPLAY1 > Driver nvd3dum.dll, version 10.18.13.5850 > Pixel Shader version 3.0 > Device : ven_10DE, dev_17C2, subsys_113210DE > Max Multisamples supported: 4 > vsync: true vpipe: true > Loading Prism common native library .../* > */ succeeded. > PPSRenderer: scenario.effect - createShader: LinearConvolveShadow_28 > PPSRenderer: scenario.effect - createShader: LinearConvolve_8 > PPSRenderer: scenario.effect - createShader: LinearConvolve_64 > PPSRenderer: scenario.effect - createShader: Blend_ADD > PPSRenderer: scenario.effect - createShader: LinearConvolveShadow_16 > PPSRenderer: scenario.effect - createShader: LinearConvolve_12/* > > # > > > On 31 October 2015 at 07:21, Jim Graham > wrote: > > Other things to try: > > -Dprism.verbose=true (output should show the following > options are working) > > -Dglass.win.uiScale=1.0 (disables HiDPI) > -Dprism.order=sw (disables HW acceleration) > -Dprism.maxTextureSize=8192 (mentioned before - increases max > texture dims) > > -Dprism.maxvram=2G (increases maximum texture pool to 2GB) > -Dprism.targetvram=2G (combined with maxvram, increases > initial pool to 2GB) > > ...jim > > > On 10/30/15 12:59 PM, Felix Bembrick wrote: > > Hi Jim, > > I had Windows 10 on my previous machine and my wife's low-end PC > is also running Win10 and the same version of Java. > > But I have what is supposed to be the fastest graphics card of > all (GeForce GTX Titan X) and she has a very basic card. > > The only real difference is that she has a 22" monitor with a > resolution of 1920 X 1024 (?) and I have 2 4K monitors. > > Hi-DPI is supported in the sense that everything renders at the > correct size etc (unlike Swing) but it performs so slowly that > there must be something fundamentally wrong, especially since > JavaFX seems to be the only technology that's affected. > > On 31 Oct 2015, at 06:49, Jim Graham > > > wrote: > > It should be supported. Which version of Windows were you > using before? We've supported HiDPI on Windows since > JDK8u60 on all supported versions of Windows... > > ...jim > > On 10/27/15 11:24 PM, Felix Bembrick wrote: > I just installed JavaFX on my new Windows 10 machine > which is extremely powerful but has two 4K monitors and > while everything looks great and the right "size", the > performance is very sluggish to say the least. > > Is this because Hi-DPI is not yet supported in JavaFX on > Windows? > > Thanks, > > Fix > > From james.graham at oracle.com Mon Nov 2 21:27:46 2015 From: james.graham at oracle.com (Jim Graham) Date: Mon, 02 Nov 2015 13:27:46 -0800 Subject: Debug Flags Wiki Page In-Reply-To: <5637B304.5050804@Oracle.com> References: <5637B304.5050804@Oracle.com> Message-ID: <5637D552.6060706@oracle.com> Should we have a column for the default setting? Also, targetvram shouldn't be set higher unless you also set maxvram higher - we'll need a place to mention dependent properties. Should all of that just be mentioned in text in the description field? ...jim On 11/2/2015 11:01 AM, David Hill wrote: > > Hi all, > After Jim reminded me (again) with his recent email - I started a > OpenJFX wiki page to note/document the various command line flags we > have that are pretty much only documented in email. > > Please take a look at the rather spare page: > > https://wiki.openjdk.java.net/display/OpenJFX/Debug+Flags > > and either add missing ones in, or send me an email and I will add them. > Corrections are also welcome, I typed this rather quickly. > > There are a handful of other ones I know about (mostly font or monocle > related) that are covered in other wiki pages, but should be linked back > at some point. > > Dave > From David.Hill at Oracle.com Mon Nov 2 21:40:38 2015 From: David.Hill at Oracle.com (David Hill) Date: Mon, 02 Nov 2015 16:40:38 -0500 Subject: Debug Flags Wiki Page In-Reply-To: <5637D552.6060706@oracle.com> References: <5637B304.5050804@Oracle.com> <5637D552.6060706@oracle.com> Message-ID: <5637D856.9060706@Oracle.com> On 11/2/15, 4:27 PM, Jim Graham wrote: > Should we have a column for the default setting? > > Also, targetvram shouldn't be set higher unless you also set maxvram higher - we'll need a place to mention dependent properties. > > Should all of that just be mentioned in text in the description field? Default settings column ..... humm, probably a good idea, though there is precedence for just stuffing it in the description like we do in Javadoc. As much as I have wanted to do this for a while, I guess I have not thought too much about the format I was more along the lines of "build it, and they will come" (and suggest how to do it better). :-) The challenge of this as I found earlier is that the description is going to be 95% of the table. Another way to do this would be to dump the table and do paragraphs with the flag as the paragraph heading. That *might* flow better. Any thoughts on that ? Dave > > ...jim > > On 11/2/2015 11:01 AM, David Hill wrote: >> >> Hi all, >> After Jim reminded me (again) with his recent email - I started a >> OpenJFX wiki page to note/document the various command line flags we >> have that are pretty much only documented in email. >> >> Please take a look at the rather spare page: >> >> https://wiki.openjdk.java.net/display/OpenJFX/Debug+Flags >> >> and either add missing ones in, or send me an email and I will add them. >> Corrections are also welcome, I typed this rather quickly. >> >> There are a handful of other ones I know about (mostly font or monocle >> related) that are covered in other wiki pages, but should be linked back >> at some point. >> >> Dave >> -- 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 Mon Nov 2 21:50:10 2015 From: james.graham at oracle.com (Jim Graham) Date: Mon, 02 Nov 2015 13:50:10 -0800 Subject: Windows Hi-DPI In-Reply-To: <5637D49E.6020905@oracle.com> References: <94CE475E-320E-4B81-82F7-5BDBFEEA3386@gmail.com> <5633C9E5.8060503@oracle.com> <02A84A2E-AF14-4037-9B71-783DEEE86FF0@gmail.com> <5633D149.2040809@oracle.com> <5637D49E.6020905@oracle.com> Message-ID: <5637DA92.9080300@oracle.com> And with the nVidia GPU again smooth as glass. My driver is listed as: Driver nvd3dumx.dll, version 10.18.13.5415 Note that the umx.dll driver is the 64-bit display driver (found in System32 oddly enough because Windows is backwards that way). The version of the driver named um.dll (which your run seems to be using) is the 32-bit version of the driver (found in SysWOW64 which is where Windows puts 32-bit drivers on a Win64 system just to make things completely backwards). Are you running on the 32-bit VM? Have you tried the 64-bit VM? ...jim On 11/2/2015 1:24 PM, Jim Graham wrote: > For reference, I just ran the Ensemble8 demo on a Windows 10 laptop with > a 200% scaled HiDPI screen (3000x2000) with integrated Intel HD Graphics > 520 and it ran smooth as glass, even the 3D samples. > > The laptop also has an embedded nVidia 900 series GPU, but I need to > figure out why it isn't getting used when I run FX. I'll note, though, > that this laptop is using an older version of the nVidia drivers > (354.15) which was installed by Windows and which is considered "up to > date" when I run an update check in the nVidia Control Panel. You > appear to be running 358.50 which is the latest WHQL version from > nVidia's web site? I looked and nVidia doesn't even offer 354.15 even > in their history of drivers... > > ...jim > > On 10/30/2015 5:40 PM, Felix Bembrick wrote: >> Hi Jim, >> >> I have experimented with all those options with the following results: >> >> 1. Turning on verbose proves hardware acceleration is being used. >> 2. Increasing texture size and fiddling with the amount of VRAM has no >> effect on performance. >> 3. Turning off Hi DPI changes the appearance of the app (i.e. controls >> are too small etc.) but has no effect on performance. >> 4. Disabling hardware acceleration makes it another order of magnitude >> slower than before. >> >> So none of the options improved performance at all. All we know for >> sure is that it's using D3D and that it is running so much slower than I >> expected and so much so that it is unusable. >> >> Here's some of the initial output which hopefully shows something about >> the issue: >> >> */Prism pipeline init order: d3d >> Using native-based Pisces rasterizer >> Using dirty region optimizations >> Not using texture mask for primitives >> Not forcing power of 2 sizes for textures >> Using hardware CLAMP_TO_ZERO mode >> Opting in for HiDPI pixel scaling >> Prism pipeline name = com.sun.prism.d3d.D3DPipeline >> Loading D3D native library ... >> succeeded. >> D3DPipelineManager: Created D3D9Ex device >> Direct3D initialization succeeded >> (X) Got class = class com.sun.prism.d3d.D3DPipeline >> Initialized prism pipeline: com.sun.prism.d3d.D3DPipeline >> Maximum supported texture size: 16384 >> Maximum texture size clamped to 8192 >> OS Information: >> Windows version 10.0 build 10240 >> D3D Driver Information: >> NVIDIA GeForce GTX TITAN X >> \\.\DISPLAY1 >> Driver nvd3dum.dll, version 10.18.13.5850 >> Pixel Shader version 3.0 >> Device : ven_10DE, dev_17C2, subsys_113210DE >> Max Multisamples supported: 4 >> vsync: true vpipe: true >> Loading Prism common native library .../* >> */ succeeded. >> PPSRenderer: scenario.effect - createShader: LinearConvolveShadow_28 >> PPSRenderer: scenario.effect - createShader: LinearConvolve_8 >> PPSRenderer: scenario.effect - createShader: LinearConvolve_64 >> PPSRenderer: scenario.effect - createShader: Blend_ADD >> PPSRenderer: scenario.effect - createShader: LinearConvolveShadow_16 >> PPSRenderer: scenario.effect - createShader: LinearConvolve_12/* >> >> # >> >> >> On 31 October 2015 at 07:21, Jim Graham > > wrote: >> >> Other things to try: >> >> -Dprism.verbose=true (output should show the following >> options are working) >> >> -Dglass.win.uiScale=1.0 (disables HiDPI) >> -Dprism.order=sw (disables HW acceleration) >> -Dprism.maxTextureSize=8192 (mentioned before - increases max >> texture dims) >> >> -Dprism.maxvram=2G (increases maximum texture pool to 2GB) >> -Dprism.targetvram=2G (combined with maxvram, increases >> initial pool to 2GB) >> >> ...jim >> >> >> On 10/30/15 12:59 PM, Felix Bembrick wrote: >> >> Hi Jim, >> >> I had Windows 10 on my previous machine and my wife's low-end PC >> is also running Win10 and the same version of Java. >> >> But I have what is supposed to be the fastest graphics card of >> all (GeForce GTX Titan X) and she has a very basic card. >> >> The only real difference is that she has a 22" monitor with a >> resolution of 1920 X 1024 (?) and I have 2 4K monitors. >> >> Hi-DPI is supported in the sense that everything renders at the >> correct size etc (unlike Swing) but it performs so slowly that >> there must be something fundamentally wrong, especially since >> JavaFX seems to be the only technology that's affected. >> >> On 31 Oct 2015, at 06:49, Jim Graham >> > >> wrote: >> >> It should be supported. Which version of Windows were you >> using before? We've supported HiDPI on Windows since >> JDK8u60 on all supported versions of Windows... >> >> ...jim >> >> On 10/27/15 11:24 PM, Felix Bembrick wrote: >> I just installed JavaFX on my new Windows 10 machine >> which is extremely powerful but has two 4K monitors and >> while everything looks great and the right "size", the >> performance is very sluggish to say the least. >> >> Is this because Hi-DPI is not yet supported in JavaFX on >> Windows? >> >> Thanks, >> >> Fix >> >> From james.graham at oracle.com Mon Nov 2 21:54:59 2015 From: james.graham at oracle.com (Jim Graham) Date: Mon, 02 Nov 2015 13:54:59 -0800 Subject: Debug Flags Wiki Page In-Reply-To: <5637D856.9060706@Oracle.com> References: <5637B304.5050804@Oracle.com> <5637D552.6060706@oracle.com> <5637D856.9060706@Oracle.com> Message-ID: <5637DBB3.4010300@oracle.com> How about a table where there is a line of formatted info and then an open box below it with a description. Kind of like (hate ascii art): +---------+------+-------------------+---------------------------+ | foo.bar | 4096 | no dependencies | Sets the bar of the foo | +---------+------+-------------------+---------------------------+ | This sets the bar for the foo which affects all cases where | | we foo the bar and the bar doesn't have its own foo. | +----------------------------------------------------------------+ Some options won't require a description or will be batched together with a single description box perhaps... ...jim On 11/2/2015 1:40 PM, David Hill wrote: > On 11/2/15, 4:27 PM, Jim Graham wrote: >> Should we have a column for the default setting? >> >> Also, targetvram shouldn't be set higher unless you also set maxvram >> higher - we'll need a place to mention dependent properties. >> >> Should all of that just be mentioned in text in the description field? > Default settings column ..... humm, probably a good idea, though there > is precedence for just stuffing it in the description like we do in > Javadoc. > > As much as I have wanted to do this for a while, I guess I have not > thought too much about the format > I was more along the lines of "build it, and they will come" (and > suggest how to do it better). :-) > > The challenge of this as I found earlier is that the description is > going to be 95% of the table. > > Another way to do this would be to dump the table and do paragraphs with > the flag as the paragraph heading. That *might* flow better. > > Any thoughts on that ? > > Dave > >> >> ...jim >> >> On 11/2/2015 11:01 AM, David Hill wrote: >>> >>> Hi all, >>> After Jim reminded me (again) with his recent email - I started a >>> OpenJFX wiki page to note/document the various command line flags we >>> have that are pretty much only documented in email. >>> >>> Please take a look at the rather spare page: >>> >>> https://wiki.openjdk.java.net/display/OpenJFX/Debug+Flags >>> >>> and either add missing ones in, or send me an email and I will add them. >>> Corrections are also welcome, I typed this rather quickly. >>> >>> There are a handful of other ones I know about (mostly font or monocle >>> related) that are covered in other wiki pages, but should be linked back >>> at some point. >>> >>> Dave >>> > > From felix.bembrick at gmail.com Tue Nov 3 01:39:46 2015 From: felix.bembrick at gmail.com (Felix Bembrick) Date: Tue, 3 Nov 2015 12:39:46 +1100 Subject: pisces, produceFillAlphas In-Reply-To: References: <561FF83E.3000407@oracle.com> <5620261F.7060206@oracle.com> Message-ID: <9E5FE080-0D49-4A6B-9A51-CB5F70FAF320@gmail.com> Johan? I really need this kind of information and you seem to be the most qualified person to provide it. Cheers, Felix > On 31 Oct 2015, at 19:23, Felix Bembrick wrote: > > Hi Johan, > > Now that your workload has hopefully lessened a bit after J1, do you think you could find some time to address this question of mine from earlier? > > Thanks, > > Felix > >> On 18 Oct 2015, at 19:01, Felix Bembrick wrote: >> >> Hi Johan, >> >> If you have been getting acceptable but not stunning performance on Android and all this time hardware acceleration was not being utilised then it sounds like there is some serious room for some dramatic performance increases. >> >> Not being that familiar with the finer points of how JavaFX is implemented on Android, just how much work is involved in accessing that hardware acceleration? Any timeline? >> >> I expect that implementing this significant change could be a make-or-break factor in determining whether JavaFX is truly viable and successful on Android. >> >> Good luck Johan! >> >> Cheers, >> >> Felix >> >>> On 17 Oct 2015, at 19:49, Johan Vos wrote: >>> >>> As a follow-up on the second part: after about 2 years working on JavaFX on >>> Android, I discovered we are not even using Hardware Acceleration. We >>> create a SurfaceView and render on that, but it turns out SurfaceView is >>> never Hardware Accelerated. The positive thing is that this means there is >>> even more room for optimization :) >>> >>> - Johan >>> >>>> On Fri, Oct 16, 2015 at 7:55 PM, Johan Vos wrote: >>>> >>>> Hi, >>>> >>>> Thanks for the suggestions. There are 2 different things: >>>> >>>> 1. It seems indeed there is not much being cached, so there are definitely >>>> improvements possible. It also require e.g. VirtualFlow to use the >>>> Node.setCache(true) in order to cache. The combination of this with the >>>> prism.scrollcacheopt reduces the rendering calls. I think the only penalty >>>> is memory, but so far, we didn't run into issues with too high GC activity. >>>> >>>> 2. Calls to glDrawElements() inside nDrawIndexedQuads take about 100 times >>>> longer on the Nexus 6 compared to the iPhone 6 (e.g. 100,000ns vs 1000ns). >>>> I'll have to look into some EGL options. >>>> >>>> - Johan >>>> >>>> >>>> On Fri, Oct 16, 2015 at 12:18 AM, Jim Graham >>>> wrote: >>>> >>>>> Chien pointed out a system property that is currently disabling the >>>>> scrolling optimization. For its implementation look at CacheFilter.java, >>>>> in particular the invalidateByTranslation() method and all that it kicks >>>>> off. >>>>> >>>>> Another thing to look at is that we added alpha batching to the code >>>>> which should be batching all of the output of the produceAlphas calls into >>>>> a texture and then drawing all of the quads together - provided that they >>>>> are all being filled with simple colors (they can have alpha, but they >>>>> can't be gradients, etc.). This should be managed by the >>>>> BaseContext.updateMaskTexture() method which controls the single batch >>>>> texture. >>>>> >>>>> Again, are there similar number of invocations of the glDrawElements on >>>>> the 2 platforms? >>>>> >>>>> ...jim >>>>> >>>>>> On 10/15/15 12:30 PM, Johan Vos wrote: >>>>>> >>>>>> Thanks Jim. >>>>>> I tried with different optimization flags, but it doesn't make a big >>>>>> difference. Tracing it down to system calls, somehow the gl >>>>>> implementation seems be be slower (glDrawElements(GL_TRIANGLES, numQuads >>>>>> * 2 * 3, GL_UNSIGNED_SHORT, 0) takes more time on Android than on iOS) >>>>>> per invocation. The number of invocations is comparable between iOS and >>>>>> Android. >>>>>> >>>>>> If you can give me a direction on where to search for the disabled >>>>>> scrolling optimization, I'll try to re-enable that and see how it >>>>>> improves performance. It might be a huge and quick win... >>>>>> >>>>>> Thanks again, >>>>>> >>>>>> - Johan >>>>>> >>>>>> On Thu, Oct 15, 2015 at 9:02 PM, Jim Graham >>>>> > wrote: >>>>>> >>>>>> Perhaps optimization flags with the native compiler? Also, was it >>>>>> called a similar number of times on both? >>>>>> >>>>>> Ideally we'd just be using copyArea for the scrolling, but at one >>>>>> point we disabled the scrolling optimizations on retina MBP because >>>>>> they didn't work with a scale factor and I don't think we reenabled >>>>>> them yet. That would kill scrolling performance on mobile as a >>>>>> result of having to rerender the scene on each scroll regardless of >>>>>> how long produceAlphas takes... >>>>>> >>>>>> ...jim >>>>>> >>>>>> >>>>>> On 10/15/15 4:27 AM, Johan Vos wrote: >>>>>> >>>>>> After spending lots of time optimizing JavaFX on iOS, I am now >>>>>> at the point >>>>>> where scrolling is 10 times faster on iOS than on Android. >>>>>> The scrolling in the iOS version of the Gluon JavaOne mobile >>>>>> schedule >>>>>> builder is pretty good imho. On Android, it is much slower. I >>>>>> profiled and >>>>>> compared both, and it turns out that on Android, we spend lots >>>>>> of time in >>>>>> the native implementation of >>>>>> NativePiscesRasterizer.produceFillAlphas >>>>>> (implemented in native-prism/NativePiscesRasterizer.c) >>>>>> >>>>>> On average, calling this native function on an iPhone 6 takes >>>>>> 40,000ns >>>>>> whereas on a Nexus 6, this takes about 800,000ns. >>>>>> >>>>>> If anyone has a suggestion on how to improve or avoid this, I'm >>>>>> all ears. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> - Johan >>>> From vadim.pakhnushev at oracle.com Tue Nov 3 11:06:46 2015 From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev) Date: Tue, 3 Nov 2015 14:06:46 +0300 Subject: [9] Review request for 8140503: JavaFX "Pair" Hash Code Collisions Message-ID: <56389546.7000807@oracle.com> Hi Chien, Could you please review the fix: https://bugs.openjdk.java.net/browse/JDK-8140503 http://cr.openjdk.java.net/~vadim/8140503/webrev.00/ Thanks, Vadim From vadim.pakhnushev at oracle.com Tue Nov 3 14:04:05 2015 From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev) Date: Tue, 3 Nov 2015 17:04:05 +0300 Subject: [9] Review request for 8136892: Cannot get rid of OK and CANCEL buttons using pure FXML Message-ID: <5638BED5.9050102@oracle.com> Jonathan, Please review the fix: https://bugs.openjdk.java.net/browse/JDK-8136892 http://cr.openjdk.java.net/~vadim/8136892/webrev.00/ Thanks, Vadim From james.graham at oracle.com Tue Nov 3 19:35:46 2015 From: james.graham at oracle.com (Jim Graham) Date: Tue, 3 Nov 2015 11:35:46 -0800 Subject: [9] Review request for 8140503: JavaFX "Pair" Hash Code Collisions In-Reply-To: <56389546.7000807@oracle.com> References: <56389546.7000807@oracle.com> Message-ID: <56390C92.2020104@oracle.com> All this does is change the prime constant used to produce the hash value. Objects.hash(a, b) uses 31*hash(a) + hash(b) instead of the 13*hash(a) + hash(b) that the embedded implementation uses. I don't really think this is a bug. The fact that Integer objects make it easy to reverse engineer and compute collisions of any reasonable hash combination computation don't mean that the technique has a bug, it just means that the submitter can read the code and think of a counter-example. If there are practical problems being caused for some particular and popular use case by the use of this particular constant "13", then we need to understand those issues and come up with a more comprehensive solution than to simply hand off to another mechanism which uses the same procedure with a different prime constant... ...jim On 11/3/15 3:06 AM, Vadim Pakhnushev wrote: > Hi Chien, > > Could you please review the fix: > https://bugs.openjdk.java.net/browse/JDK-8140503 > http://cr.openjdk.java.net/~vadim/8140503/webrev.00/ > > Thanks, > Vadim From kevin.rushforth at oracle.com Tue Nov 3 19:47:45 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 03 Nov 2015 11:47:45 -0800 Subject: [9] Review request for 8140503: JavaFX "Pair" Hash Code Collisions In-Reply-To: <56390C92.2020104@oracle.com> References: <56389546.7000807@oracle.com> <56390C92.2020104@oracle.com> Message-ID: <56390F61.8040501@oracle.com> Using 13 versus 31 seems irrelevant, I agree. I think the important difference might be that Object.hash() starts the hashcode with a constant value of "1". Some of our hashCode implementation also do something similar -- see Point2D for example. I haven't looked at it closely enough to see if that matters, but it might. Btw, here is the definition for List.hashCode which I think is what Objects.hash ends up doing: int hashCode = 1; for (E e : list) hashCode = 31*hashCode + (e==null ? 0 : e.hashCode()); -- Kevin Jim Graham wrote: > All this does is change the prime constant used to produce the hash > value. > > Objects.hash(a, b) uses 31*hash(a) + hash(b) instead of the 13*hash(a) > + hash(b) that the embedded implementation uses. > > I don't really think this is a bug. The fact that Integer objects > make it easy to reverse engineer and compute collisions of any > reasonable hash combination computation don't mean that the technique > has a bug, it just means that the submitter can read the code and > think of a counter-example. > > If there are practical problems being caused for some particular and > popular use case by the use of this particular constant "13", then we > need to understand those issues and come up with a more comprehensive > solution than to simply hand off to another mechanism which uses the > same procedure with a different prime constant... > > ...jim > > On 11/3/15 3:06 AM, Vadim Pakhnushev wrote: >> Hi Chien, >> >> Could you please review the fix: >> https://bugs.openjdk.java.net/browse/JDK-8140503 >> http://cr.openjdk.java.net/~vadim/8140503/webrev.00/ >> >> Thanks, >> Vadim From vadim.pakhnushev at oracle.com Tue Nov 3 20:01:34 2015 From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev) Date: Tue, 3 Nov 2015 23:01:34 +0300 Subject: [9] Review request for 8140503: JavaFX "Pair" Hash Code Collisions In-Reply-To: <56390C92.2020104@oracle.com> References: <56389546.7000807@oracle.com> <56390C92.2020104@oracle.com> Message-ID: <5639129E.40201@oracle.com> Well, not exactly... Previously it was 13*hash(a) + hash(b) and now it's 31*(31 + hash(a)) + hash(b). And apparently it improves the quality somehow. I did a test with 100^4 combinations and collision probability dropped by the factor of 3 from 0.065% to 0.022%. Not really impressive, but still, and it uses well-defined utility method. Yeah, I know it's not really a bug since you don't want to rely on the hashCode at all... Thanks, Vadim On 03.11.2015 22:35, Jim Graham wrote: > All this does is change the prime constant used to produce the hash > value. > > Objects.hash(a, b) uses 31*hash(a) + hash(b) instead of the 13*hash(a) > + hash(b) that the embedded implementation uses. > > I don't really think this is a bug. The fact that Integer objects > make it easy to reverse engineer and compute collisions of any > reasonable hash combination computation don't mean that the technique > has a bug, it just means that the submitter can read the code and > think of a counter-example. > > If there are practical problems being caused for some particular and > popular use case by the use of this particular constant "13", then we > need to understand those issues and come up with a more comprehensive > solution than to simply hand off to another mechanism which uses the > same procedure with a different prime constant... > > ...jim > > On 11/3/15 3:06 AM, Vadim Pakhnushev wrote: >> Hi Chien, >> >> Could you please review the fix: >> https://bugs.openjdk.java.net/browse/JDK-8140503 >> http://cr.openjdk.java.net/~vadim/8140503/webrev.00/ >> >> Thanks, >> Vadim From vadim.pakhnushev at oracle.com Tue Nov 3 20:07:35 2015 From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev) Date: Tue, 3 Nov 2015 23:07:35 +0300 Subject: [9] Review request for 8140503: JavaFX "Pair" Hash Code Collisions In-Reply-To: <5639129E.40201@oracle.com> References: <56389546.7000807@oracle.com> <56390C92.2020104@oracle.com> <5639129E.40201@oracle.com> Message-ID: <56391407.80105@oracle.com> Hmm, yeah, the actual difference is in the prime number only (that is changing the algorithm only doesn't improve anything), so the only remaining reason to fix this is that Objects.hash guards against null values (and I forgot to mention it in the review). The key in Pair could actually be null and in this case hashCode will throw NPE. Vadim On 03.11.2015 23:01, Vadim Pakhnushev wrote: > Well, not exactly... Previously it was 13*hash(a) + hash(b) and now > it's 31*(31 + hash(a)) + hash(b). > And apparently it improves the quality somehow. I did a test with > 100^4 combinations and collision probability dropped by the factor of > 3 from 0.065% to 0.022%. > Not really impressive, but still, and it uses well-defined utility > method. > Yeah, I know it's not really a bug since you don't want to rely on the > hashCode at all... > > Thanks, > Vadim > > On 03.11.2015 22:35, Jim Graham wrote: >> All this does is change the prime constant used to produce the hash >> value. >> >> Objects.hash(a, b) uses 31*hash(a) + hash(b) instead of the >> 13*hash(a) + hash(b) that the embedded implementation uses. >> >> I don't really think this is a bug. The fact that Integer objects >> make it easy to reverse engineer and compute collisions of any >> reasonable hash combination computation don't mean that the technique >> has a bug, it just means that the submitter can read the code and >> think of a counter-example. >> >> If there are practical problems being caused for some particular and >> popular use case by the use of this particular constant "13", then we >> need to understand those issues and come up with a more comprehensive >> solution than to simply hand off to another mechanism which uses the >> same procedure with a different prime constant... >> >> ...jim >> >> On 11/3/15 3:06 AM, Vadim Pakhnushev wrote: >>> Hi Chien, >>> >>> Could you please review the fix: >>> https://bugs.openjdk.java.net/browse/JDK-8140503 >>> http://cr.openjdk.java.net/~vadim/8140503/webrev.00/ >>> >>> Thanks, >>> Vadim > From chien.yang at oracle.com Tue Nov 3 21:04:26 2015 From: chien.yang at oracle.com (Chien Yang) Date: Tue, 03 Nov 2015 13:04:26 -0800 Subject: [9] Review request for 8140503: JavaFX "Pair" Hash Code Collisions In-Reply-To: <56391407.80105@oracle.com> References: <56389546.7000807@oracle.com> <56390C92.2020104@oracle.com> <5639129E.40201@oracle.com> <56391407.80105@oracle.com> Message-ID: <5639215A.10403@oracle.com> > The key in Pair could actually be null and in this case hashCode will throw NPE. This might be a good enough reason to have this fix. - Chien On 11/3/15, 12:07 PM, Vadim Pakhnushev wrote: > Hmm, yeah, the actual difference is in the prime number only (that is > changing the algorithm only doesn't improve anything), so the only > remaining reason to fix this is that Objects.hash guards against null > values (and I forgot to mention it in the review). > The key in Pair could actually be null and in this case hashCode will > throw NPE. > > Vadim > > On 03.11.2015 23:01, Vadim Pakhnushev wrote: >> Well, not exactly... Previously it was 13*hash(a) + hash(b) and now >> it's 31*(31 + hash(a)) + hash(b). >> And apparently it improves the quality somehow. I did a test with >> 100^4 combinations and collision probability dropped by the factor of >> 3 from 0.065% to 0.022%. >> Not really impressive, but still, and it uses well-defined utility >> method. >> Yeah, I know it's not really a bug since you don't want to rely on >> the hashCode at all... >> >> Thanks, >> Vadim >> >> On 03.11.2015 22:35, Jim Graham wrote: >>> All this does is change the prime constant used to produce the hash >>> value. >>> >>> Objects.hash(a, b) uses 31*hash(a) + hash(b) instead of the >>> 13*hash(a) + hash(b) that the embedded implementation uses. >>> >>> I don't really think this is a bug. The fact that Integer objects >>> make it easy to reverse engineer and compute collisions of any >>> reasonable hash combination computation don't mean that the >>> technique has a bug, it just means that the submitter can read the >>> code and think of a counter-example. >>> >>> If there are practical problems being caused for some particular and >>> popular use case by the use of this particular constant "13", then >>> we need to understand those issues and come up with a more >>> comprehensive solution than to simply hand off to another mechanism >>> which uses the same procedure with a different prime constant... >>> >>> ...jim >>> >>> On 11/3/15 3:06 AM, Vadim Pakhnushev wrote: >>>> Hi Chien, >>>> >>>> Could you please review the fix: >>>> https://bugs.openjdk.java.net/browse/JDK-8140503 >>>> http://cr.openjdk.java.net/~vadim/8140503/webrev.00/ >>>> >>>> Thanks, >>>> Vadim >> > From alexander.kouznetsov at oracle.com Tue Nov 3 21:42:02 2015 From: alexander.kouznetsov at oracle.com (Alexander Kouznetsov) Date: Tue, 3 Nov 2015 13:42:02 -0800 Subject: [9] Review request for 8140503: JavaFX "Pair" Hash Code Collisions In-Reply-To: <56391407.80105@oracle.com> References: <56389546.7000807@oracle.com> <56390C92.2020104@oracle.com> <5639129E.40201@oracle.com> <56391407.80105@oracle.com> Message-ID: <56392A2A.9040701@oracle.com> After the fix, you should expect another incident report of Objects.hash(1, 0) == Objects.hash(0, 31) always true :-) I'd rather file another bug on key == null causing NPE and closing this one as incomplete or not an issue. Best regards, Alexander Kouznetsov (408) 276-0387 On 3 ??? 2015 12:07, Vadim Pakhnushev wrote: > Hmm, yeah, the actual difference is in the prime number only (that is > changing the algorithm only doesn't improve anything), so the only > remaining reason to fix this is that Objects.hash guards against null > values (and I forgot to mention it in the review). > The key in Pair could actually be null and in this case hashCode will > throw NPE. > > Vadim > > On 03.11.2015 23:01, Vadim Pakhnushev wrote: >> Well, not exactly... Previously it was 13*hash(a) + hash(b) and now >> it's 31*(31 + hash(a)) + hash(b). >> And apparently it improves the quality somehow. I did a test with >> 100^4 combinations and collision probability dropped by the factor of >> 3 from 0.065% to 0.022%. >> Not really impressive, but still, and it uses well-defined utility >> method. >> Yeah, I know it's not really a bug since you don't want to rely on >> the hashCode at all... >> >> Thanks, >> Vadim >> >> On 03.11.2015 22:35, Jim Graham wrote: >>> All this does is change the prime constant used to produce the hash >>> value. >>> >>> Objects.hash(a, b) uses 31*hash(a) + hash(b) instead of the >>> 13*hash(a) + hash(b) that the embedded implementation uses. >>> >>> I don't really think this is a bug. The fact that Integer objects >>> make it easy to reverse engineer and compute collisions of any >>> reasonable hash combination computation don't mean that the >>> technique has a bug, it just means that the submitter can read the >>> code and think of a counter-example. >>> >>> If there are practical problems being caused for some particular and >>> popular use case by the use of this particular constant "13", then >>> we need to understand those issues and come up with a more >>> comprehensive solution than to simply hand off to another mechanism >>> which uses the same procedure with a different prime constant... >>> >>> ...jim >>> >>> On 11/3/15 3:06 AM, Vadim Pakhnushev wrote: >>>> Hi Chien, >>>> >>>> Could you please review the fix: >>>> https://bugs.openjdk.java.net/browse/JDK-8140503 >>>> http://cr.openjdk.java.net/~vadim/8140503/webrev.00/ >>>> >>>> Thanks, >>>> Vadim >> > From alexander.kouznetsov at oracle.com Tue Nov 3 21:43:53 2015 From: alexander.kouznetsov at oracle.com (Alexander Kouznetsov) Date: Tue, 3 Nov 2015 13:43:53 -0800 Subject: [9] Review request for 8140503: JavaFX "Pair" Hash Code Collisions In-Reply-To: <56392A2A.9040701@oracle.com> References: <56389546.7000807@oracle.com> <56390C92.2020104@oracle.com> <5639129E.40201@oracle.com> <56391407.80105@oracle.com> <56392A2A.9040701@oracle.com> Message-ID: <56392A99.5050806@oracle.com> Moreover, the following two sentences: "However, this is an incorrect way to compute a hash code of two values." "This can lead to hard-to-find bugs anywhere that instances of Pair are used in a data structure like a HashSet or HashTable." seem to indicate misunderstanding of what hashcode is and how it is to be used. Best regards, Alexander Kouznetsov (408) 276-0387 On 3 ??? 2015 13:42, Alexander Kouznetsov wrote: > After the fix, you should expect another incident report of > > Objects.hash(1, 0) == Objects.hash(0, 31) > > always true :-) > > I'd rather file another bug on key == null causing NPE and closing > this one as incomplete or not an issue. > > Best regards, > Alexander Kouznetsov > (408) 276-0387 > > On 3 ??? 2015 12:07, Vadim Pakhnushev wrote: >> Hmm, yeah, the actual difference is in the prime number only (that is >> changing the algorithm only doesn't improve anything), so the only >> remaining reason to fix this is that Objects.hash guards against null >> values (and I forgot to mention it in the review). >> The key in Pair could actually be null and in this case hashCode will >> throw NPE. >> >> Vadim >> >> On 03.11.2015 23:01, Vadim Pakhnushev wrote: >>> Well, not exactly... Previously it was 13*hash(a) + hash(b) and now >>> it's 31*(31 + hash(a)) + hash(b). >>> And apparently it improves the quality somehow. I did a test with >>> 100^4 combinations and collision probability dropped by the factor >>> of 3 from 0.065% to 0.022%. >>> Not really impressive, but still, and it uses well-defined utility >>> method. >>> Yeah, I know it's not really a bug since you don't want to rely on >>> the hashCode at all... >>> >>> Thanks, >>> Vadim >>> >>> On 03.11.2015 22:35, Jim Graham wrote: >>>> All this does is change the prime constant used to produce the hash >>>> value. >>>> >>>> Objects.hash(a, b) uses 31*hash(a) + hash(b) instead of the >>>> 13*hash(a) + hash(b) that the embedded implementation uses. >>>> >>>> I don't really think this is a bug. The fact that Integer objects >>>> make it easy to reverse engineer and compute collisions of any >>>> reasonable hash combination computation don't mean that the >>>> technique has a bug, it just means that the submitter can read the >>>> code and think of a counter-example. >>>> >>>> If there are practical problems being caused for some particular >>>> and popular use case by the use of this particular constant "13", >>>> then we need to understand those issues and come up with a more >>>> comprehensive solution than to simply hand off to another mechanism >>>> which uses the same procedure with a different prime constant... >>>> >>>> ...jim >>>> >>>> On 11/3/15 3:06 AM, Vadim Pakhnushev wrote: >>>>> Hi Chien, >>>>> >>>>> Could you please review the fix: >>>>> https://bugs.openjdk.java.net/browse/JDK-8140503 >>>>> http://cr.openjdk.java.net/~vadim/8140503/webrev.00/ >>>>> >>>>> Thanks, >>>>> Vadim >>> >> > From alexander.kouznetsov at oracle.com Tue Nov 3 21:44:55 2015 From: alexander.kouznetsov at oracle.com (Alexander Kouznetsov) Date: Tue, 3 Nov 2015 13:44:55 -0800 Subject: [9] Review request for 8140503: JavaFX "Pair" Hash Code Collisions In-Reply-To: <56392A99.5050806@oracle.com> References: <56389546.7000807@oracle.com> <56390C92.2020104@oracle.com> <5639129E.40201@oracle.com> <56391407.80105@oracle.com> <56392A2A.9040701@oracle.com> <56392A99.5050806@oracle.com> Message-ID: <56392AD7.2070008@oracle.com> I've missed the most important one: "here is a trivial collision of two hash codes which should be different." Best regards, Alexander Kouznetsov (408) 276-0387 On 3 ??? 2015 13:43, Alexander Kouznetsov wrote: > Moreover, the following two sentences: > > "However, this is an incorrect way to compute a hash code of two values." > "This can lead to hard-to-find bugs anywhere that instances of Pair > are used in a data structure like a HashSet or HashTable." > > seem to indicate misunderstanding of what hashcode is and how it is to > be used. > > Best regards, > Alexander Kouznetsov > (408) 276-0387 > > On 3 ??? 2015 13:42, Alexander Kouznetsov wrote: >> After the fix, you should expect another incident report of >> >> Objects.hash(1, 0) == Objects.hash(0, 31) >> >> always true :-) >> >> I'd rather file another bug on key == null causing NPE and closing >> this one as incomplete or not an issue. >> >> Best regards, >> Alexander Kouznetsov >> (408) 276-0387 >> >> On 3 ??? 2015 12:07, Vadim Pakhnushev wrote: >>> Hmm, yeah, the actual difference is in the prime number only (that >>> is changing the algorithm only doesn't improve anything), so the >>> only remaining reason to fix this is that Objects.hash guards >>> against null values (and I forgot to mention it in the review). >>> The key in Pair could actually be null and in this case hashCode >>> will throw NPE. >>> >>> Vadim >>> >>> On 03.11.2015 23:01, Vadim Pakhnushev wrote: >>>> Well, not exactly... Previously it was 13*hash(a) + hash(b) and now >>>> it's 31*(31 + hash(a)) + hash(b). >>>> And apparently it improves the quality somehow. I did a test with >>>> 100^4 combinations and collision probability dropped by the factor >>>> of 3 from 0.065% to 0.022%. >>>> Not really impressive, but still, and it uses well-defined utility >>>> method. >>>> Yeah, I know it's not really a bug since you don't want to rely on >>>> the hashCode at all... >>>> >>>> Thanks, >>>> Vadim >>>> >>>> On 03.11.2015 22:35, Jim Graham wrote: >>>>> All this does is change the prime constant used to produce the >>>>> hash value. >>>>> >>>>> Objects.hash(a, b) uses 31*hash(a) + hash(b) instead of the >>>>> 13*hash(a) + hash(b) that the embedded implementation uses. >>>>> >>>>> I don't really think this is a bug. The fact that Integer objects >>>>> make it easy to reverse engineer and compute collisions of any >>>>> reasonable hash combination computation don't mean that the >>>>> technique has a bug, it just means that the submitter can read the >>>>> code and think of a counter-example. >>>>> >>>>> If there are practical problems being caused for some particular >>>>> and popular use case by the use of this particular constant "13", >>>>> then we need to understand those issues and come up with a more >>>>> comprehensive solution than to simply hand off to another >>>>> mechanism which uses the same procedure with a different prime >>>>> constant... >>>>> >>>>> ...jim >>>>> >>>>> On 11/3/15 3:06 AM, Vadim Pakhnushev wrote: >>>>>> Hi Chien, >>>>>> >>>>>> Could you please review the fix: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8140503 >>>>>> http://cr.openjdk.java.net/~vadim/8140503/webrev.00/ >>>>>> >>>>>> Thanks, >>>>>> Vadim >>>> >>> >> > From james.graham at oracle.com Tue Nov 3 22:05:24 2015 From: james.graham at oracle.com (Jim Graham) Date: Tue, 3 Nov 2015 14:05:24 -0800 Subject: [9] Review request for 8140503: JavaFX "Pair" Hash Code Collisions In-Reply-To: <56392A99.5050806@oracle.com> References: <56389546.7000807@oracle.com> <56390C92.2020104@oracle.com> <5639129E.40201@oracle.com> <56391407.80105@oracle.com> <56392A2A.9040701@oracle.com> <56392A99.5050806@oracle.com> Message-ID: <56392FA4.5080508@oracle.com> Absolutely, this report uncovered an unrelated NPE bug which is helpful, and apparently different constants might affect the collision probabilities (which were already very unlikely to begin with), but the bug report was definitely filed primarily as a misunderstanding. One thing to note - perhaps small numbers are more likely to be encountered so the larger the prime, the less likelihood of getting a collision. I wouldn't recommend using too large of a prime since the probability is already so low even with 13, and larger primes may increase the size of the byte code and compiled code since larger constants take more complicated instructions to deal with. Josh Bloch recommended a base of 17 and a multiplier of 37 in Chapter 3 of Effective Java, but he also admitted that the numbers were arbitrary except for the multiplier needing to be an odd prime. One reason 13 might be too low depends on the probability that Pair is used in hash cases with lots of very small numbers. Adding in a base prime and using a little bit larger prime multiplier quickly turns lots of small numbers into massively distributed hashes - even with 31 or 17/37. I kind of feel like using the existing utility is overkill for just 2 objects since it requires constructing an array object to use it. I'd be just as happy (perhaps even more so) if we just upgraded the code to check key for null and use a little larger prime, but keep it inlined... ...jim On 11/3/15 1:43 PM, Alexander Kouznetsov wrote: > Moreover, the following two sentences: > > "However, this is an incorrect way to compute a hash code of two values." > "This can lead to hard-to-find bugs anywhere that instances of Pair are > used in a data structure like a HashSet or HashTable." > > seem to indicate misunderstanding of what hashcode is and how it is to > be used. > > Best regards, > Alexander Kouznetsov > (408) 276-0387 > > On 3 ??? 2015 13:42, Alexander Kouznetsov wrote: >> After the fix, you should expect another incident report of >> >> Objects.hash(1, 0) == Objects.hash(0, 31) >> >> always true :-) >> >> I'd rather file another bug on key == null causing NPE and closing >> this one as incomplete or not an issue. >> >> Best regards, >> Alexander Kouznetsov >> (408) 276-0387 >> >> On 3 ??? 2015 12:07, Vadim Pakhnushev wrote: >>> Hmm, yeah, the actual difference is in the prime number only (that is >>> changing the algorithm only doesn't improve anything), so the only >>> remaining reason to fix this is that Objects.hash guards against null >>> values (and I forgot to mention it in the review). >>> The key in Pair could actually be null and in this case hashCode will >>> throw NPE. >>> >>> Vadim >>> >>> On 03.11.2015 23:01, Vadim Pakhnushev wrote: >>>> Well, not exactly... Previously it was 13*hash(a) + hash(b) and now >>>> it's 31*(31 + hash(a)) + hash(b). >>>> And apparently it improves the quality somehow. I did a test with >>>> 100^4 combinations and collision probability dropped by the factor >>>> of 3 from 0.065% to 0.022%. >>>> Not really impressive, but still, and it uses well-defined utility >>>> method. >>>> Yeah, I know it's not really a bug since you don't want to rely on >>>> the hashCode at all... >>>> >>>> Thanks, >>>> Vadim >>>> >>>> On 03.11.2015 22:35, Jim Graham wrote: >>>>> All this does is change the prime constant used to produce the hash >>>>> value. >>>>> >>>>> Objects.hash(a, b) uses 31*hash(a) + hash(b) instead of the >>>>> 13*hash(a) + hash(b) that the embedded implementation uses. >>>>> >>>>> I don't really think this is a bug. The fact that Integer objects >>>>> make it easy to reverse engineer and compute collisions of any >>>>> reasonable hash combination computation don't mean that the >>>>> technique has a bug, it just means that the submitter can read the >>>>> code and think of a counter-example. >>>>> >>>>> If there are practical problems being caused for some particular >>>>> and popular use case by the use of this particular constant "13", >>>>> then we need to understand those issues and come up with a more >>>>> comprehensive solution than to simply hand off to another mechanism >>>>> which uses the same procedure with a different prime constant... >>>>> >>>>> ...jim >>>>> >>>>> On 11/3/15 3:06 AM, Vadim Pakhnushev wrote: >>>>>> Hi Chien, >>>>>> >>>>>> Could you please review the fix: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8140503 >>>>>> http://cr.openjdk.java.net/~vadim/8140503/webrev.00/ >>>>>> >>>>>> Thanks, >>>>>> Vadim >>>> >>> >> > From kevin.rushforth at oracle.com Tue Nov 3 22:43:46 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 03 Nov 2015 14:43:46 -0800 Subject: [9] Review request for 8140503: JavaFX "Pair" Hash Code Collisions In-Reply-To: <56392FA4.5080508@oracle.com> References: <56389546.7000807@oracle.com> <56390C92.2020104@oracle.com> <5639129E.40201@oracle.com> <56391407.80105@oracle.com> <56392A2A.9040701@oracle.com> <56392A99.5050806@oracle.com> <56392FA4.5080508@oracle.com> Message-ID: <563938A2.70000@oracle.com> Inlining it seems like a fine way to go to me, too. As another point of reference, we use 7/31 in other places in JavaFX. -- Kevin Jim Graham wrote: > Absolutely, this report uncovered an unrelated NPE bug which is > helpful, and apparently different constants might affect the collision > probabilities (which were already very unlikely to begin with), but > the bug report was definitely filed primarily as a misunderstanding. > > One thing to note - perhaps small numbers are more likely to be > encountered so the larger the prime, the less likelihood of getting a > collision. I wouldn't recommend using too large of a prime since the > probability is already so low even with 13, and larger primes may > increase the size of the byte code and compiled code since larger > constants take more complicated instructions to deal with. Josh Bloch > recommended a base of 17 and a multiplier of 37 in Chapter 3 of > Effective Java, but he also admitted that the numbers were arbitrary > except for the multiplier needing to be an odd prime. > > One reason 13 might be too low depends on the probability that Pair is > used in hash cases with lots of very small numbers. Adding in a base > prime and using a little bit larger prime multiplier quickly turns > lots of small numbers into massively distributed hashes - even with 31 > or 17/37. > > I kind of feel like using the existing utility is overkill for just 2 > objects since it requires constructing an array object to use it. I'd > be just as happy (perhaps even more so) if we just upgraded the code > to check key for null and use a little larger prime, but keep it > inlined... > > ...jim > > On 11/3/15 1:43 PM, Alexander Kouznetsov wrote: >> Moreover, the following two sentences: >> >> "However, this is an incorrect way to compute a hash code of two >> values." >> "This can lead to hard-to-find bugs anywhere that instances of Pair are >> used in a data structure like a HashSet or HashTable." >> >> seem to indicate misunderstanding of what hashcode is and how it is to >> be used. >> >> Best regards, >> Alexander Kouznetsov >> (408) 276-0387 >> >> On 3 ??? 2015 13:42, Alexander Kouznetsov wrote: >>> After the fix, you should expect another incident report of >>> >>> Objects.hash(1, 0) == Objects.hash(0, 31) >>> >>> always true :-) >>> >>> I'd rather file another bug on key == null causing NPE and closing >>> this one as incomplete or not an issue. >>> >>> Best regards, >>> Alexander Kouznetsov >>> (408) 276-0387 >>> >>> On 3 ??? 2015 12:07, Vadim Pakhnushev wrote: >>>> Hmm, yeah, the actual difference is in the prime number only (that is >>>> changing the algorithm only doesn't improve anything), so the only >>>> remaining reason to fix this is that Objects.hash guards against null >>>> values (and I forgot to mention it in the review). >>>> The key in Pair could actually be null and in this case hashCode will >>>> throw NPE. >>>> >>>> Vadim >>>> >>>> On 03.11.2015 23:01, Vadim Pakhnushev wrote: >>>>> Well, not exactly... Previously it was 13*hash(a) + hash(b) and now >>>>> it's 31*(31 + hash(a)) + hash(b). >>>>> And apparently it improves the quality somehow. I did a test with >>>>> 100^4 combinations and collision probability dropped by the factor >>>>> of 3 from 0.065% to 0.022%. >>>>> Not really impressive, but still, and it uses well-defined utility >>>>> method. >>>>> Yeah, I know it's not really a bug since you don't want to rely on >>>>> the hashCode at all... >>>>> >>>>> Thanks, >>>>> Vadim >>>>> >>>>> On 03.11.2015 22:35, Jim Graham wrote: >>>>>> All this does is change the prime constant used to produce the hash >>>>>> value. >>>>>> >>>>>> Objects.hash(a, b) uses 31*hash(a) + hash(b) instead of the >>>>>> 13*hash(a) + hash(b) that the embedded implementation uses. >>>>>> >>>>>> I don't really think this is a bug. The fact that Integer objects >>>>>> make it easy to reverse engineer and compute collisions of any >>>>>> reasonable hash combination computation don't mean that the >>>>>> technique has a bug, it just means that the submitter can read the >>>>>> code and think of a counter-example. >>>>>> >>>>>> If there are practical problems being caused for some particular >>>>>> and popular use case by the use of this particular constant "13", >>>>>> then we need to understand those issues and come up with a more >>>>>> comprehensive solution than to simply hand off to another mechanism >>>>>> which uses the same procedure with a different prime constant... >>>>>> >>>>>> ...jim >>>>>> >>>>>> On 11/3/15 3:06 AM, Vadim Pakhnushev wrote: >>>>>>> Hi Chien, >>>>>>> >>>>>>> Could you please review the fix: >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8140503 >>>>>>> http://cr.openjdk.java.net/~vadim/8140503/webrev.00/ >>>>>>> >>>>>>> Thanks, >>>>>>> Vadim >>>>> >>>> >>> >> From alexander.matveev at oracle.com Wed Nov 4 02:51:03 2015 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Tue, 3 Nov 2015 18:51:03 -0800 Subject: [9] Review request for 8136480: Warnings printed to console from new GStreamer code Message-ID: <56397297.2060302@oracle.com> Hi Kirill, https://bugs.openjdk.java.net/browse/JDK-8136480 Please review the following: http://cr.openjdk.java.net/~almatvee/8136480/webrev.00 This warning message is printed, because we using 0.10 style caps for raw video. I do not see any needs to switch caps to new style. As solution this warning message is disabled. Thanks, Alexander From arunprasad.rajkumar at oracle.com Wed Nov 4 09:31:39 2015 From: arunprasad.rajkumar at oracle.com (Arunprasad Rajkumar) Date: Wed, 4 Nov 2015 15:01:39 +0530 Subject: [9] Review request for 8141388: Add Compiled Python Objects(*.pyc) into .hgignore Message-ID: <5639D07B.8070205@oracle.com> Hi Kevin, Alexander, Guru, Please review the below patch. JIRA: https://bugs.openjdk.java.net/browse/JDK-8141388 Webrev: http://cr.openjdk.java.net/~rchamyal/arunprasad/8141388/webrev.00/ Regards, Arun From N.C.C.Brown at kent.ac.uk Wed Nov 4 03:41:59 2015 From: N.C.C.Brown at kent.ac.uk (Neil Brown) Date: Wed, 4 Nov 2015 03:41:59 +0000 Subject: Missing Mac APIs in JavaFX Message-ID: <56397E87.7070109@kent.ac.uk> Hi, Short version: I believe JavaFX is lacking some Mac-related APIs which cannot be worked around without an internal com.sun.* call, and would like to request that the APIs be added/made public for JDK 9, perhaps as part of Jonathan Giles' work around JEP 253. I stand to be corrected on any of this... Long version: On Windows and Linux, files are generally opened via command-line arguments. On Mac, there is a file-open event issued to an application, e.g. you double-click a .txt file, TextEdit gets a file-open event. If TextEdit is not open, it will be launched, then a file-open event will be sent to it. Pre-JavaFX, the Java solution to receive these events was to use the com.apple.eawt.* packages, which Oracle added in JDK 7. However, it seems that these APIs don't play nice with FX. I've put some source code at the end of the email for a simple application which I bundled with infinitekind's appbundler fork for testing (https://bitbucket.org/infinitekind/appbundler/). No matter where you uncomment the setEAWTFileHandler call (search AAA, or BBB in the source), the .app always misses the initial load event which caused the application to open. The net result is if the user double-clicks an associated file, the JavaFX application will launch, but not load the file in question unless the user double-clicks it again. Needless to say, this is problematic. If you look at the FX source code, you can see that FX does set a file-open event handler with an empty implementation (com.sun.glass.ui.Application, line 83 in 8u60). Grepping the source code shows this method is not implemented anywhere in the source code, so FX is simply discarding the event. The only Java way I've found to let an FX application listen to the open files event is using a com.sun call in the Application constructor (see CCC in the source, and setFXFileHandler). Suggestions for a better work-around very welcome! The second API is a similar problem. JavaFX installs an application menu with standard options, including "Quit" (bound to Cmd-Q). If you leave Platform.setImplicitExit to its default value of true, all is well. Cmd-Q quits the application. However, if you setImplicitExit(false) (see YYY in the source), as our actual application must, problems arise. The quit handler now is a no-op, with no way of overriding it. Pressing Cmd-Q or right-clicking the dock and selecting quit is now totally ignored by the application, and from the user's perspective the app is unquittable by these normal means. The only work-around I've found is to set a quit handler in the same spot we set the file open handler (see ZZZ in the source: I've used Platform.exit for this example, in reality we have a nicer custom shutdown routine). My proposal is fairly straight-forward: the com.sun.glass.ui.Application.EventHandler class (and associated setEventHandler call) needs to become a public API in JDK 9, or else these issues will be impossible to work around post-modularisation. Initial file open and quit handler are the only ones biting us at the moment, but I suspect that whole handler class should be public, either as-is or by repurposing it into an EventHandler with some sort of AppEvent extends Event class. Thanks, Neil. ====== src/example/OpenApp.java ====== package example; import java.io.File; import java.util.ArrayList; import java.util.Arrays; import java.util.List; import java.util.stream.Collectors; import javafx.application.Application; import javafx.application.Platform; import javafx.collections.FXCollections; import javafx.collections.ListChangeListener; import javafx.collections.ObservableList; import javafx.scene.Scene; import javafx.scene.control.Label; import javafx.scene.control.Menu; import javafx.scene.control.MenuBar; import javafx.scene.layout.BorderPane; import javafx.stage.Stage; public class OpenApp extends Application { private static ObservableList requestedFiles = FXCollections.observableArrayList(); public static void main(String[] args) { // AAA: Uncommenting here, we miss initial load events: //setEAWTFileHandler(); launch(args); } @Override public void start(Stage stage) throws Exception { // YYY: this causes problems. //Platform.setImplicitExit(false); // BBB: Here also misses initial load events: //setEAWTFileHandler(); BorderPane bp = new BorderPane(); Label filename = new Label(""); bp.setCenter(filename); Runnable updateFiles = () -> filename.setText(requestedFiles.stream().map(File::getAbsolutePath).collect(Collectors.joining("\n"))); requestedFiles.addListener((ListChangeListener)c -> updateFiles.run()); updateFiles.run(); bp.setBottom(new Label("Example Application")); MenuBar menuBar = new MenuBar(new Menu("My Custom Menu")); menuBar.setUseSystemMenuBar(true); bp.setTop(menuBar); stage.setScene(new Scene(bp)); stage.show(); } public OpenApp() { // CCC: Constructor is the only time we are at the right point in // FX control flow. //setFXFileHandler(); } private static void setEAWTFileHandler() { com.apple.eawt.Application appleApp = com.apple.eawt.Application.getApplication(); appleApp.setOpenFileHandler(e -> { List files = new ArrayList(e.getFiles()); Platform.runLater(() -> requestedFiles.addAll(e.getFiles())); }); } private static void setFXFileHandler() { com.sun.glass.ui.Application glassApp = com.sun.glass.ui.Application.GetApplication(); glassApp.setEventHandler(new com.sun.glass.ui.Application.EventHandler() { @Override public void handleOpenFilesAction(com.sun.glass.ui.Application app, long time, String[] filenames) { List files = Arrays.stream(filenames).map(File::new).collect(Collectors.toList()); Platform.runLater(() -> requestedFiles.addAll(files)); super.handleOpenFilesAction(app, time, filenames); } // ZZZ: add our own quit handler, too /* @Override public void handleQuitAction(com.sun.glass.ui.Application app, long time) { Platform.exit(); super.handleQuitAction(app, time); } */ }); } } ====== build.xml (needs appbundler in ant lib, built from https://bitbucket.org/infinitekind/appbundler/) ====== From guru.hb at oracle.com Thu Nov 5 06:50:12 2015 From: guru.hb at oracle.com (Guru Hb) Date: Wed, 4 Nov 2015 22:50:12 -0800 (PST) Subject: WebKit Cache In-Reply-To: References: Message-ID: Hi John, - Oracle documentation says WebKit has an in-memory cache which can be overridden by ResponseCache, this is not the case. http://docs.oracle.com/javase/8/javafx/embedded-browser-tutorial/overview.htm#JFXWV135 -- "Other features". Explained below. - JDK-8014501 states the problem, but has been flagged "not an issue". Why is it not an issue? Handling network cache within the webkit engine would be more efficient rather than in java.net.ResponseCache. Currently its marked as Enhancement and will be taken forward based on priority. - signifant coding around "URL.setURLStreamHandlerFactory" and "URLConnection" interception produces a functional cache with significant performance gains, but is undone by problems deliberately introduced into URLLoader code. i can answer for "deliberately introduced into URLLoader code." : Webkit has 3 layer of cache (Memory and Disk based) Memory Cache : 1. Network level : storing raw network data, But this feature is not implemented for our javafx port. [Its by default provided in webkit2, JavaFX uses single process model not the webkit2] 2. Cached resource for images, scripts, stylesheets, xlsstylesheets and fonts (all resource decoded) 3. Page Cache (Entire DOM tree is cached, except the main page) This can be tested with Page forward and Page backward. "URLLoader code was setting setUsesCaches(false)" was added while fixing JDK-8112030, where webview had duplicate RAW data (in ResponseCache) and Decoded data (2 and 3 from above) inside the webcore. We should have updated our tutorial well after this fix. If you have considered below options, then please ignore 1. Making single page application and managing context with Z-Order. 2. Page navigation with Forward and backward. 3. lazy loading JavaScript files based on their first time usage 4. Choosing closest CDN for their 3rd party script files. Thanks, Guru -----Original Message----- From: John Maton [mailto:john2011uk at gmail.com] Sent: Saturday, October 17, 2015 3:14 PM To: openjfx-dev at openjdk.java.net Subject: WebKit Cache I have been trying to implement a disc based cache for WebView but with only partial success, I am particularly trying to cache the .js javascript external files which slow down the loading of javascript web pages a lot. The Oracle documentation states that: "When working with the WebView component, you should remember that it has the default in-memory cache. It means that any cached content is lost once the application containing the WebView component is closed. However, developers can implement cache at the application level by means of the java.net.ResponseCache class. " but this is not the case. I implemented an in-memory cache using the java.net.ResponseCache class but it is very rarely used by WebView - from time to time it stores and retrieves favicon.png from the cache - no performance gain. I confirmed by analysing the net traffic that WebView is not caching, thus confirming what is stated in JDK-8014501: "While navigating with JavaFX WebView component javafx.scene.web.WebView, it was found, that every request retrieves all resources from the server each time even if previous activities have just retrieved the resources. This behaviour was verified by capturing and analyzing the network traffic. The performance impact is considerable. " nothing seems to have come out of JDK-8014501, so I then wrote a cache handler using "URL.setURLStreamHandlerFactory" to intercept all URLConnections to the default sun handler. I had some success with this and was able to cache .js javascript files and increase performance significantly, but there were bugs on a few web sites, notably Outlook's email. On looking into the way my code was handled, I found for example that the URLLoader code was setting setUsesCaches(false) with the following comments in the code (at line 279 of URLLoader.java in current 1.8.0_66 code): // Given that WebKit has its own cache, do not use // any URLConnection caches, even if someone installs them. // As a side effect, this fixes the problem of WebPane not // working well with the plug-in cache, which was one of // the causes for RT-11880. So can somebody out there please give me a heads up on what is really going on? - Oracle documentation says WebKit has an in-memory cache which can be overriden by ResponseCache, this is not the case. - JDK-8014501 states the problem, but has been flagged "not an issue". Why is it not an issue? - signifant coding around "URL.setURLStreamHandlerFactory" and "URLConnection" interception produces a functional cache with significant performance gains, but is undone by problems deliberately introduced into URLLoader code. Thanks in advance for any feedback, John Maton From john2011uk at gmail.com Thu Nov 5 08:39:47 2015 From: john2011uk at gmail.com (John Maton) Date: Thu, 5 Nov 2015 09:39:47 +0100 Subject: WebKit Cache In-Reply-To: References: Message-ID: Guru Many thanks for all your input which I will evaluate. I have been able to reduce the initial page load time by a factor of 2 by using url connection interception and a disc cache, so webkit cannot be caching to disc and I consider that normal. However beyond that I cannot make much improvement, the webkit in-memory cache works too well. I would appreciate the ability to either disable it or work within it to handle the disc caching, at the moment there is too much code duplication between my disc cache and the webkit in-memory cache which causes me some performance loss. Currently I am able to cache all url's with http headers for Cache-Control, ETag and Expires. Some of these url's are missed by the webkit and I am able to cache them in-memory but the gain is marginal because of the code duplication. Maybe I could work with whoever is going to do the enhancements on your side? Best regardsL John Maton On Thursday, November 5, 2015, Guru Hb wrote: > Hi John, > > - Oracle documentation says WebKit has an in-memory cache which can be > overridden by ResponseCache, this is not the case. > > http://docs.oracle.com/javase/8/javafx/embedded-browser-tutorial/overview.htm#JFXWV135 > -- "Other features". Explained below. > - JDK-8014501 states the problem, but has been flagged "not an issue". Why > is it not an issue? > Handling network cache within the webkit engine would be more > efficient rather than in java.net.ResponseCache. Currently its marked as > Enhancement and will be taken forward based on priority. > - signifant coding around "URL.setURLStreamHandlerFactory" and > "URLConnection" interception produces a functional cache with significant > performance gains, but is undone by problems deliberately introduced into > URLLoader code. > i can answer for "deliberately introduced into URLLoader code." : > > Webkit has 3 layer of cache (Memory and Disk based) Memory Cache : > 1. Network level : storing raw network data, But this feature is > not implemented for our javafx port. > [Its by default provided in webkit2, JavaFX uses single process > model not the webkit2] > 2. Cached resource for images, scripts, stylesheets, > xlsstylesheets and fonts (all resource decoded) > 3. Page Cache (Entire DOM tree is cached, except the main page) > This can be tested with Page forward and Page backward. > > "URLLoader code was setting setUsesCaches(false)" was added while > fixing JDK-8112030, where webview had duplicate RAW data (in ResponseCache) > and Decoded data (2 and 3 from above) inside the webcore. We should have > updated our tutorial well after this fix. > > If you have considered below options, then please ignore > 1. Making single page application and managing context with Z-Order. > 2. Page navigation with Forward and backward. > 3. lazy loading JavaScript files based on their first time usage > 4. Choosing closest CDN for their 3rd party script files. > > Thanks, > Guru > > -----Original Message----- > From: John Maton [mailto:john2011uk at gmail.com ] > Sent: Saturday, October 17, 2015 3:14 PM > To: openjfx-dev at openjdk.java.net > Subject: WebKit Cache > > I have been trying to implement a disc based cache for WebView but with > only partial success, I am particularly trying to cache the .js javascript > external files which slow down the loading of javascript web pages a lot. > > The Oracle documentation states that: > "When working with the WebView component, you should remember that it has > the default in-memory cache. > It means that any cached content is lost once the application containing > the WebView component is closed. > However, developers can implement cache at the application level by means > of the java.net.ResponseCache class. " > > but this is not the case. I implemented an in-memory cache using the > java.net.ResponseCache class but it is very rarely used by WebView - from > time to time it stores and retrieves favicon.png from the cache - no > performance gain. > > I confirmed by analysing the net traffic that WebView is not caching, thus > confirming what is stated in JDK-8014501: > "While navigating with JavaFX WebView component javafx.scene.web.WebView, > it was found, that every request retrieves all resources from the server > each time even if previous activities have just retrieved the resources. > This behaviour was verified by capturing and analyzing the network traffic. > The performance impact is considerable. " > > nothing seems to have come out of JDK-8014501, so I then wrote a cache > handler using "URL.setURLStreamHandlerFactory" to intercept all > URLConnections to the default sun handler. I had some success with this and > was able to cache .js javascript files and increase performance > significantly, but there were bugs on a few web sites, notably Outlook's > email. > > On looking into the way my code was handled, I found for example that the > URLLoader code was setting setUsesCaches(false) with the following comments > in the code (at line 279 of URLLoader.java in current 1.8.0_66 code): > // Given that WebKit has its own cache, do not use > // any URLConnection caches, even if someone installs them. > // As a side effect, this fixes the problem of WebPane not > // working well with the plug-in cache, which was one of > // the causes for RT-11880. > > So can somebody out there please give me a heads up on what is really > going on? > > - Oracle documentation says WebKit has an in-memory cache which can be > overriden by ResponseCache, this is not the case. > - JDK-8014501 states the problem, but has been flagged "not an issue". > Why is it not an issue? > - signifant coding around "URL.setURLStreamHandlerFactory" and > "URLConnection" interception produces a functional cache with significant > performance gains, but is undone by problems deliberately introduced into > URLLoader code. > > Thanks in advance for any feedback, > John Maton > From Fabrizio.Giudici at tidalwave.it Thu Nov 5 12:37:34 2015 From: Fabrizio.Giudici at tidalwave.it (Fabrizio Giudici) Date: Thu, 05 Nov 2015 13:37:34 +0100 Subject: Question about what's on topic Message-ID: Hi. Is it appropriate to post here questions about why a certain API (e.g. in Java8) has been made in a way instead of another? Thanks. -- Fabrizio Giudici - Java Architect @ Tidalwave s.a.s. "We make Java work. Everywhere." http://tidalwave.it/fabrizio/blog - fabrizio.giudici at tidalwave.it From kevin.rushforth at oracle.com Thu Nov 5 12:59:18 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 05 Nov 2015 04:59:18 -0800 Subject: Question about what's on topic In-Reply-To: References: Message-ID: <563B52A6.7010207@oracle.com> Yes, that would be a fine topic. -- Kevin Fabrizio Giudici wrote: > Hi. > > Is it appropriate to post here questions about why a certain API (e.g. > in Java8) has been made in a way instead of another? > > Thanks. > From Fabrizio.Giudici at tidalwave.it Thu Nov 5 13:21:59 2015 From: Fabrizio.Giudici at tidalwave.it (Fabrizio Giudici) Date: Thu, 05 Nov 2015 14:21:59 +0100 Subject: Questions about Stream/Iterable/Files - and possibly the compiler Message-ID: Hello. My question is for the sake of curiosity, not being related to a real problem - or, better, the problem - which is tiny - can be fixed with a simple work around. But I'd like to blog a short post about it and I'd like to check I have all the context. It stemmed from a class about Java 8 that I recently taught and one of the participants asked about that. Everything starts from this code chunk that doensnt' compile: 1. Stream s = IntStream.rangeClosed(1, 10) // just as an example to quickly create a Stream .mapToObj(n -> "String #" + n); Files.write(Paths.get("/tmp/pippo.txt"), s); error: no suitable method found for write(Path,Stream) Files.write(Paths.get("/tmp/pippo.txt"), s); method Files.write(Path,byte[],OpenOption...) is not applicable (argument mismatch; Stream cannot be converted to byte[]) method Files.write(Path,Iterable,Charset,OpenOption...) is not applicable (argument mismatch; Stream cannot be converted to Iterable) method Files.write(Path,Iterable,OpenOption...) is not applicable (argument mismatch; Stream cannot be converted to Iterable) 2. Variation. Files.write(Paths.get("/tmp/pippo.txt"), (Iterable)s); This gives: Exception in thread "main" java.lang.ClassCastException: java.util.stream.IntPipeline$4 cannot be cast to java.lang.Iterable at StreamIteratorExample.main(StreamIteratorExample.java:13) Ok, so far it's the fact described here http://stackoverflow.com/questions/20129762/why-does-streamt-not-implement-iterablet on why Stream doesn't implement Iterable. Question A: Is the answer "because iterator() is usually supposed to be callable multiple times, while in a Stream it can't" correct? 3. This is the known trick around the problem: final Iterable i = s::iterator; Files.write(Paths.get("/tmp/pippo.txt"), i); It works and I think I understand why (Iterable has the same functional descriptor of Supplier, which is s::iterator, so they are compatible in assignment - right?). 4. But at this point putting it into the same line gives compilation error: Files.write(Paths.get("/tmp/pippo.txt"), s::iterator); error: no suitable method found for write(Path,s::iterator) Files.write(Paths.get("/tmp/pippo.txt"), s::iterator); method Files.write(Path,byte[],OpenOption...) is not applicable (argument mismatch; Array is not a functional interface) method Files.write(Path,Iterable,Charset,OpenOption...) is not applicable (argument mismatch; bad return type in method reference Iterator cannot be converted to Iterator) method Files.write(Path,Iterable,OpenOption...) is not applicable (argument mismatch; bad return type in method reference Iterator cannot be converted to Iterator) 5. This at last works: Files.write(Paths.get("/tmp/pippo.txt"), (Iterable)s::iterator); Question B: Why doesn't the compiler autonomously infer that s::iterator is compatible with Iterable and the cast is needed? At last, question C: Given all those premises, is there a specific reason for which Files.write() hasn't been overloaded with a version capable of accepting a Stream? It would have been the perfect complement of Files.lines() Thanks. -- Fabrizio Giudici - Java Architect @ Tidalwave s.a.s. "We make Java work. Everywhere." http://tidalwave.it/fabrizio/blog - fabrizio.giudici at tidalwave.it From kevin.rushforth at oracle.com Thu Nov 5 13:28:50 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 05 Nov 2015 05:28:50 -0800 Subject: Questions about Stream/Iterable/Files - and possibly the compiler In-Reply-To: References: Message-ID: <563B5992.8030302@oracle.com> I guess I misunderstood your question. I thought you had a question about a JavaFX API in JDK 8. This isn't the place to discuss other Java APIs. -- Kevin Fabrizio Giudici wrote: > Hello. > > My question is for the sake of curiosity, not being related to a real > problem - or, better, the problem - which is tiny - can be fixed with > a simple work around. But I'd like to blog a short post about it and > I'd like to check I have all the context. It stemmed from a class > about Java 8 that I recently taught and one of the participants asked > about that. > > > > Everything starts from this code chunk that doensnt' compile: > > 1. > > Stream s = IntStream.rangeClosed(1, 10) // just as an > example to quickly create a Stream > .mapToObj(n -> "String #" + n); > > Files.write(Paths.get("/tmp/pippo.txt"), s); > > error: no suitable method found for write(Path,Stream) > Files.write(Paths.get("/tmp/pippo.txt"), s); > method Files.write(Path,byte[],OpenOption...) is not applicable > (argument mismatch; Stream cannot be converted to byte[]) > method Files.write(Path,Iterable CharSequence>,Charset,OpenOption...) is not applicable > (argument mismatch; Stream cannot be converted to > Iterable) > method Files.write(Path,Iterable CharSequence>,OpenOption...) is not applicable > (argument mismatch; Stream cannot be converted to > Iterable) > > 2. Variation. > > Files.write(Paths.get("/tmp/pippo.txt"), (Iterable)s); > > This gives: > > Exception in thread "main" java.lang.ClassCastException: > java.util.stream.IntPipeline$4 cannot be cast to java.lang.Iterable > at StreamIteratorExample.main(StreamIteratorExample.java:13) > > Ok, so far it's the fact described here > > http://stackoverflow.com/questions/20129762/why-does-streamt-not-implement-iterablet > > > on why Stream doesn't implement Iterable. > > Question A: Is the answer "because iterator() is usually supposed to > be callable multiple times, while in a Stream it can't" correct? > > > 3. This is the known trick around the problem: > > final Iterable i = s::iterator; > Files.write(Paths.get("/tmp/pippo.txt"), i); > > It works and I think I understand why (Iterable has the same > functional descriptor of Supplier, which is s::iterator, so > they are compatible in assignment - right?). > > > 4. But at this point putting it into the same line gives compilation > error: > > Files.write(Paths.get("/tmp/pippo.txt"), s::iterator); > > error: no suitable method found for write(Path,s::iterator) > Files.write(Paths.get("/tmp/pippo.txt"), s::iterator); > method Files.write(Path,byte[],OpenOption...) is not applicable > (argument mismatch; Array is not a functional interface) > method Files.write(Path,Iterable CharSequence>,Charset,OpenOption...) is not applicable > (argument mismatch; bad return type in method reference > Iterator cannot be converted to Iterator) > method Files.write(Path,Iterable CharSequence>,OpenOption...) is not applicable > (argument mismatch; bad return type in method reference > Iterator cannot be converted to Iterator) > > 5. This at last works: > > Files.write(Paths.get("/tmp/pippo.txt"), > (Iterable)s::iterator); > > > Question B: Why doesn't the compiler autonomously infer that > s::iterator is compatible with Iterable and the cast is needed? > > At last, question C: Given all those premises, is there a specific > reason for which Files.write() hasn't been overloaded with a version > capable of accepting a Stream? It would have been the perfect > complement of Files.lines() > > > Thanks. > > > From Fabrizio.Giudici at tidalwave.it Thu Nov 5 13:53:10 2015 From: Fabrizio.Giudici at tidalwave.it (Fabrizio Giudici) Date: Thu, 05 Nov 2015 14:53:10 +0100 Subject: Questions about Stream/Iterable/Files - and possibly the compiler In-Reply-To: <563B5992.8030302@oracle.com> References: <563B5992.8030302@oracle.com> Message-ID: On Thu, 05 Nov 2015 14:28:50 +0100, Kevin Rushforth wrote: > I guess I misunderstood your question. I thought you had a question > about a JavaFX API in JDK 8. This isn't the place to discuss other Java > APIs. Oh.... well.... I see, my fault! I trusted the auto-completion of my email client... and I probably have to convince myself I can't use small fonts as I've been doing for years. Apologies to everyone. -- Fabrizio Giudici - Java Architect @ Tidalwave s.a.s. "We make Java work. Everywhere." http://tidalwave.it/fabrizio/blog - fabrizio.giudici at tidalwave.it From philip.race at oracle.com Thu Nov 5 17:52:04 2015 From: philip.race at oracle.com (Phil Race) Date: Thu, 05 Nov 2015 09:52:04 -0800 Subject: Questions about Stream/Iterable/Files - and possibly the compiler In-Reply-To: References: <563B5992.8030302@oracle.com> Message-ID: <563B9744.70906@oracle.com> For streams I recommend core-libs-dev at openjdk.java.net. That is probably the best place for your question. For compiler and language questions you might try compiler-dev at openjdk.java.net -phil. On 11/05/2015 05:53 AM, Fabrizio Giudici wrote: > On Thu, 05 Nov 2015 14:28:50 +0100, Kevin Rushforth > wrote: > >> I guess I misunderstood your question. I thought you had a question >> about a JavaFX API in JDK 8. This isn't the place to discuss other >> Java APIs. > > Oh.... well.... I see, my fault! I trusted the auto-completion of my > email client... and I probably have to convince myself I can't use > small fonts as I've been doing for years. > > Apologies to everyone. > > From kevin.rushforth at oracle.com Thu Nov 5 21:25:15 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 05 Nov 2015 13:25:15 -0800 Subject: [9] Review request: 8136966: Remove experimental, non-shipping glass SWT platform Message-ID: <563BC93B.3080609@oracle.com> David, Please review this very simple patch: https://bugs.openjdk.java.net/browse/JDK-8136966 http://cr.openjdk.java.net/~kcr/8136966/webrev.00/ Thanks. -- Kevin From rahman.usta.88 at gmail.com Fri Nov 6 10:48:05 2015 From: rahman.usta.88 at gmail.com (Rahman USTA) Date: Fri, 6 Nov 2015 12:48:05 +0200 Subject: Accessing JavaFX's StageHelper and ContextMenuContent in Jigsaw Message-ID: Hi all; I'm trying Jigsaw build with my JavaFX project, everything is fine but with two exceptions. javac could not find/access com.sun.javafx.scene.control.skin.ContextMenuContent and com.sun.javafx.stage.StageHelper classes. I'm using ContextMenuContent to add new menu items to webview's default context menu. I can set a new ContextMenu for Webviews but, I want to use actions of default menuitems as well. Code I'm doing something when application focus-out, but when an JavaFX Alert is shown, it acts as focus-out, to avoid this circumstances I'm using StageHelper Code How can I these needs with Jigsaw builds? Thanks. -- Rahman USTA Istanbul JUG https://github.com/rahmanusta From jonathan.giles at oracle.com Fri Nov 6 23:55:40 2015 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Sat, 7 Nov 2015 12:55:40 +1300 Subject: Accessing JavaFX's StageHelper and ContextMenuContent in Jigsaw In-Reply-To: References: Message-ID: <563D3DFC.2070203@oracle.com> Neither of these classes are currently planned to be moved into public API for JDK 9. You should file separate requests in bug tracker so we can discuss the feasibility of both of these classes. -- Jonathan On 6/11/15 11:48 PM, Rahman USTA wrote: > Hi all; > > I'm trying Jigsaw build with my JavaFX project, everything is fine but with > two exceptions. > > javac could not find/access > com.sun.javafx.scene.control.skin.ContextMenuContent > and com.sun.javafx.stage.StageHelper classes. > > I'm using ContextMenuContent to add new menu items to webview's default > context menu. I can set a new ContextMenu for Webviews but, I want to use > actions of default menuitems as well. Code > > > I'm doing something when application focus-out, but when an JavaFX Alert is > shown, it acts as focus-out, to avoid this circumstances I'm using > StageHelper Code > > > How can I these needs with Jigsaw builds? > > Thanks. > From kevin.rushforth at oracle.com Fri Nov 6 23:59:58 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 06 Nov 2015 15:59:58 -0800 Subject: Accessing JavaFX's StageHelper and ContextMenuContent in Jigsaw In-Reply-To: <563D3DFC.2070203@oracle.com> References: <563D3DFC.2070203@oracle.com> Message-ID: <563D3EFE.5070000@oracle.com> To give some additional context, here are some brief comments I wrote on jigsaw-dev (before suggesting that this topic move over here). 1) The StageHelper class is deliberately not exposed for good reasons, since it's purpose is to provide internal access to non-public state. 2) We moved most of the skin classes to a publicly exported javafx.scene.control.skin package as part of JEP 253, but that didn't include ContextMenuContent. 3) in addition to the two internal classes, you are also accessing a non-supported (and not documented) impl_* method which may or may not continue to work. Can you explain what you are trying to do with these classes? Perhaps there is an alternative? -- Kevin Jonathan Giles wrote: > Neither of these classes are currently planned to be moved into public > API for JDK 9. You should file separate requests in bug tracker so we > can discuss the feasibility of both of these classes. > > -- Jonathan > > On 6/11/15 11:48 PM, Rahman USTA wrote: >> Hi all; >> >> I'm trying Jigsaw build with my JavaFX project, everything is fine >> but with >> two exceptions. >> >> javac could not find/access >> com.sun.javafx.scene.control.skin.ContextMenuContent >> and com.sun.javafx.stage.StageHelper classes. >> >> I'm using ContextMenuContent to add new menu items to webview's default >> context menu. I can set a new ContextMenu for Webviews but, I want to >> use >> actions of default menuitems as well. Code >> >> >> >> I'm doing something when application focus-out, but when an JavaFX >> Alert is >> shown, it acts as focus-out, to avoid this circumstances I'm using >> StageHelper Code >> >> >> >> How can I these needs with Jigsaw builds? >> >> Thanks. >> > From james.graham at oracle.com Sat Nov 7 23:57:00 2015 From: james.graham at oracle.com (Jim Graham) Date: Sat, 7 Nov 2015 15:57:00 -0800 Subject: [8u/9] review request for 8139210: JavaFX rendering glitch when rendering many Paths using HW pipeline Message-ID: <563E8FCC.5050709@oracle.com> I've created 2 versions of the fix for this bug. One is low source impact but maintains the current convoluted role of the VertexBuffer class in the code base and makes it slightly more murky. The second fix touches a bunch of files, but it cleans up the use of the VB class throughout the code base. JBS: https://bugs.openjdk.java.net/browse/JDK-8139210 webrev for simple fix (8u & 9): http://cr.openjdk.java.net/~flar/JDK-8139210/webrev.00/ webrev for bigger fix (8u): http://cr.openjdk.java.net/~flar/JDK-8139210/webrev.alt8u.00/ webrev for bigger fix (9): http://cr.openjdk.java.net/~flar/JDK-8139210/webrev.alt9.00/ (the 2 webrevs differ *only* in the location of the TestGraphics.java file) We should consider this for both 8u and 9. I recommend going with the more complete fix for 9, but which is more appropriate for 8u? ...jim From mp at jugs.org Sun Nov 8 08:09:46 2015 From: mp at jugs.org (Dr. Michael Paus) Date: Sun, 8 Nov 2015 09:09:46 +0100 Subject: Missing Mac APIs in JavaFX In-Reply-To: <56397E87.7070109@kent.ac.uk> References: <56397E87.7070109@kent.ac.uk> Message-ID: <563F034A.7090509@jugs.org> Hi, I agree with you that these things should work as expected with JavaFX. Have you filed a bug report for them? In addition to the platform specific APIs I would prefer a common solution for common things though, like opening a file which is associated with your application. Michael Am 04.11.15 um 04:41 schrieb Neil Brown: > Hi, > > Short version: I believe JavaFX is lacking some Mac-related APIs which > cannot be worked around without an internal com.sun.* call, and would > like to request that the APIs be added/made public for JDK 9, perhaps > as part of Jonathan Giles' work around JEP 253. > > I stand to be corrected on any of this... > > Long version: On Windows and Linux, files are generally opened via > command-line arguments. On Mac, there is a file-open event issued to > an application, e.g. you double-click a .txt file, TextEdit gets a > file-open event. If TextEdit is not open, it will be launched, then a > file-open event will be sent to it. > > Pre-JavaFX, the Java solution to receive these events was to use the > com.apple.eawt.* packages, which Oracle added in JDK 7. However, it > seems that these APIs don't play nice with FX. > > I've put some source code at the end of the email for a simple > application which I bundled with infinitekind's appbundler fork for > testing (https://bitbucket.org/infinitekind/appbundler/). No matter > where you uncomment the setEAWTFileHandler call (search AAA, or BBB in > the source), the .app always misses the initial load event which > caused the application to open. The net result is if the user > double-clicks an associated file, the JavaFX application will launch, > but not load the file in question unless the user double-clicks it > again. Needless to say, this is problematic. > > If you look at the FX source code, you can see that FX does set a > file-open event handler with an empty implementation > (com.sun.glass.ui.Application, line 83 in 8u60). Grepping the source > code shows this method is not implemented anywhere in the source code, > so FX is simply discarding the event. The only Java way I've found to > let an FX application listen to the open files event is using a > com.sun call in the Application constructor (see CCC in the source, > and setFXFileHandler). Suggestions for a better work-around very > welcome! > > > The second API is a similar problem. JavaFX installs an application > menu with standard options, including "Quit" (bound to Cmd-Q). If you > leave Platform.setImplicitExit to its default value of true, all is > well. Cmd-Q quits the application. However, if you > setImplicitExit(false) (see YYY in the source), as our actual > application must, problems arise. The quit handler now is a no-op, > with no way of overriding it. Pressing Cmd-Q or right-clicking the > dock and selecting quit is now totally ignored by the application, and > from the user's perspective the app is unquittable by these normal > means. The only work-around I've found is to set a quit handler in > the same spot we set the file open handler (see ZZZ in the source: > I've used Platform.exit for this example, in reality we have a nicer > custom shutdown routine). > > > My proposal is fairly straight-forward: the > com.sun.glass.ui.Application.EventHandler class (and associated > setEventHandler call) needs to become a public API in JDK 9, or else > these issues will be impossible to work around post-modularisation. > Initial file open and quit handler are the only ones biting us at the > moment, but I suspect that whole handler class should be public, > either as-is or by repurposing it into an EventHandler with some sort > of AppEvent extends Event class. > > Thanks, > > Neil. > > ====== > src/example/OpenApp.java > ====== > package example; > > import java.io.File; > import java.util.ArrayList; > import java.util.Arrays; > import java.util.List; > import java.util.stream.Collectors; > import javafx.application.Application; > import javafx.application.Platform; > import javafx.collections.FXCollections; > import javafx.collections.ListChangeListener; > import javafx.collections.ObservableList; > import javafx.scene.Scene; > import javafx.scene.control.Label; > import javafx.scene.control.Menu; > import javafx.scene.control.MenuBar; > import javafx.scene.layout.BorderPane; > import javafx.stage.Stage; > > public class OpenApp extends Application > { > private static ObservableList requestedFiles = > FXCollections.observableArrayList(); > > public static void main(String[] args) > { > // AAA: Uncommenting here, we miss initial load events: > //setEAWTFileHandler(); > launch(args); > } > > @Override > public void start(Stage stage) throws Exception > { > // YYY: this causes problems. > //Platform.setImplicitExit(false); > // BBB: Here also misses initial load events: > //setEAWTFileHandler(); > > BorderPane bp = new BorderPane(); > Label filename = new Label(""); > bp.setCenter(filename); > Runnable updateFiles = () -> > filename.setText(requestedFiles.stream().map(File::getAbsolutePath).collect(Collectors.joining("\n"))); > requestedFiles.addListener((ListChangeListener)c > -> updateFiles.run()); > updateFiles.run(); > bp.setBottom(new Label("Example Application")); > MenuBar menuBar = new MenuBar(new Menu("My Custom Menu")); > menuBar.setUseSystemMenuBar(true); > bp.setTop(menuBar); > stage.setScene(new Scene(bp)); > stage.show(); > } > > public OpenApp() > { > // CCC: Constructor is the only time we are at the right point in > // FX control flow. > //setFXFileHandler(); > } > > private static void setEAWTFileHandler() > { > com.apple.eawt.Application appleApp = > com.apple.eawt.Application.getApplication(); > appleApp.setOpenFileHandler(e -> { > List files = new ArrayList(e.getFiles()); > Platform.runLater(() -> requestedFiles.addAll(e.getFiles())); > }); > } > > private static void setFXFileHandler() > { > com.sun.glass.ui.Application glassApp = > com.sun.glass.ui.Application.GetApplication(); > glassApp.setEventHandler(new > com.sun.glass.ui.Application.EventHandler() { > @Override > public void > handleOpenFilesAction(com.sun.glass.ui.Application app, long time, > String[] filenames) > { > List files = > Arrays.stream(filenames).map(File::new).collect(Collectors.toList()); > Platform.runLater(() -> requestedFiles.addAll(files)); > super.handleOpenFilesAction(app, time, filenames); > } > > // ZZZ: add our own quit handler, too > /* > @Override > public void handleQuitAction(com.sun.glass.ui.Application > app, long time) > { > Platform.exit(); > super.handleQuitAction(app, time); > } > */ > }); > } > > } > > ====== > build.xml (needs appbundler in ant lib, built from > https://bitbucket.org/infinitekind/appbundler/) > ====== > > > classpath="appbundler-1.0ea.jar" > classname="com.oracle.appbundler.AppBundlerTask"/> > > > > > > > > jvmrequired="1.8" > outputdirectory="." > name="OpenApp" > displayname="OpenApp" > executableName="OpenApp" > identifier="example.OpenApp" > shortversion="1.0" > version="1.0" > mainclassname="example.OpenApp"> > > name="Dummy document" > role="editor"> > > > > From markus at headcrashing.eu Sun Nov 8 08:17:42 2015 From: markus at headcrashing.eu (Markus KARG) Date: Sun, 8 Nov 2015 09:17:42 +0100 Subject: Missing Mac APIs in JavaFX In-Reply-To: <563F034A.7090509@jugs.org> References: <56397E87.7070109@kent.ac.uk> <563F034A.7090509@jugs.org> Message-ID: <000a01d119fd$f0b52a40$d21f7ec0$@eu> Side note: First launching a JavaFX application and then sending a file-open-event afterwards is also something Windows does since decades. Whether or not the old (file name paramater) or new (OLE event) method is used can be customized by the administrator for every single file type. So adding support for this actually is not Mac OS specific. -----Original Message----- From: openjfx-dev [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Dr. Michael Paus Sent: Sonntag, 8. November 2015 09:10 To: openjfx-dev at openjdk.java.net Subject: Re: Missing Mac APIs in JavaFX Hi, I agree with you that these things should work as expected with JavaFX. Have you filed a bug report for them? In addition to the platform specific APIs I would prefer a common solution for common things though, like opening a file which is associated with your application. Michael Am 04.11.15 um 04:41 schrieb Neil Brown: > Hi, > > Short version: I believe JavaFX is lacking some Mac-related APIs which > cannot be worked around without an internal com.sun.* call, and would > like to request that the APIs be added/made public for JDK 9, perhaps > as part of Jonathan Giles' work around JEP 253. > > I stand to be corrected on any of this... > > Long version: On Windows and Linux, files are generally opened via > command-line arguments. On Mac, there is a file-open event issued to > an application, e.g. you double-click a .txt file, TextEdit gets a > file-open event. If TextEdit is not open, it will be launched, then a > file-open event will be sent to it. > > Pre-JavaFX, the Java solution to receive these events was to use the > com.apple.eawt.* packages, which Oracle added in JDK 7. However, it > seems that these APIs don't play nice with FX. > > I've put some source code at the end of the email for a simple > application which I bundled with infinitekind's appbundler fork for > testing (https://bitbucket.org/infinitekind/appbundler/). No matter > where you uncomment the setEAWTFileHandler call (search AAA, or BBB in > the source), the .app always misses the initial load event which > caused the application to open. The net result is if the user > double-clicks an associated file, the JavaFX application will launch, > but not load the file in question unless the user double-clicks it > again. Needless to say, this is problematic. > > If you look at the FX source code, you can see that FX does set a > file-open event handler with an empty implementation > (com.sun.glass.ui.Application, line 83 in 8u60). Grepping the source > code shows this method is not implemented anywhere in the source code, > so FX is simply discarding the event. The only Java way I've found to > let an FX application listen to the open files event is using a > com.sun call in the Application constructor (see CCC in the source, > and setFXFileHandler). Suggestions for a better work-around very > welcome! > > > The second API is a similar problem. JavaFX installs an application > menu with standard options, including "Quit" (bound to Cmd-Q). If you > leave Platform.setImplicitExit to its default value of true, all is > well. Cmd-Q quits the application. However, if you > setImplicitExit(false) (see YYY in the source), as our actual > application must, problems arise. The quit handler now is a no-op, > with no way of overriding it. Pressing Cmd-Q or right-clicking the > dock and selecting quit is now totally ignored by the application, and > from the user's perspective the app is unquittable by these normal > means. The only work-around I've found is to set a quit handler in > the same spot we set the file open handler (see ZZZ in the source: > I've used Platform.exit for this example, in reality we have a nicer > custom shutdown routine). > > > My proposal is fairly straight-forward: the > com.sun.glass.ui.Application.EventHandler class (and associated > setEventHandler call) needs to become a public API in JDK 9, or else > these issues will be impossible to work around post-modularisation. > Initial file open and quit handler are the only ones biting us at the > moment, but I suspect that whole handler class should be public, > either as-is or by repurposing it into an EventHandler with some sort > of AppEvent extends Event class. > > Thanks, > > Neil. > > ====== > src/example/OpenApp.java > ====== > package example; > > import java.io.File; > import java.util.ArrayList; > import java.util.Arrays; > import java.util.List; > import java.util.stream.Collectors; > import javafx.application.Application; > import javafx.application.Platform; > import javafx.collections.FXCollections; > import javafx.collections.ListChangeListener; > import javafx.collections.ObservableList; > import javafx.scene.Scene; > import javafx.scene.control.Label; > import javafx.scene.control.Menu; > import javafx.scene.control.MenuBar; > import javafx.scene.layout.BorderPane; > import javafx.stage.Stage; > > public class OpenApp extends Application > { > private static ObservableList requestedFiles = > FXCollections.observableArrayList(); > > public static void main(String[] args) > { > // AAA: Uncommenting here, we miss initial load events: > //setEAWTFileHandler(); > launch(args); > } > > @Override > public void start(Stage stage) throws Exception > { > // YYY: this causes problems. > //Platform.setImplicitExit(false); > // BBB: Here also misses initial load events: > //setEAWTFileHandler(); > > BorderPane bp = new BorderPane(); > Label filename = new Label(""); > bp.setCenter(filename); > Runnable updateFiles = () -> > filename.setText(requestedFiles.stream().map(File::getAbsolutePath).collect(Collectors.joining("\n"))); > requestedFiles.addListener((ListChangeListener)c > -> updateFiles.run()); > updateFiles.run(); > bp.setBottom(new Label("Example Application")); > MenuBar menuBar = new MenuBar(new Menu("My Custom Menu")); > menuBar.setUseSystemMenuBar(true); > bp.setTop(menuBar); > stage.setScene(new Scene(bp)); > stage.show(); > } > > public OpenApp() > { > // CCC: Constructor is the only time we are at the right point in > // FX control flow. > //setFXFileHandler(); > } > > private static void setEAWTFileHandler() > { > com.apple.eawt.Application appleApp = > com.apple.eawt.Application.getApplication(); > appleApp.setOpenFileHandler(e -> { > List files = new ArrayList(e.getFiles()); > Platform.runLater(() -> requestedFiles.addAll(e.getFiles())); > }); > } > > private static void setFXFileHandler() > { > com.sun.glass.ui.Application glassApp = > com.sun.glass.ui.Application.GetApplication(); > glassApp.setEventHandler(new > com.sun.glass.ui.Application.EventHandler() { > @Override > public void > handleOpenFilesAction(com.sun.glass.ui.Application app, long time, > String[] filenames) > { > List files = > Arrays.stream(filenames).map(File::new).collect(Collectors.toList()); > Platform.runLater(() -> requestedFiles.addAll(files)); > super.handleOpenFilesAction(app, time, filenames); > } > > // ZZZ: add our own quit handler, too > /* > @Override > public void handleQuitAction(com.sun.glass.ui.Application > app, long time) > { > Platform.exit(); > super.handleQuitAction(app, time); > } > */ > }); > } > > } > > ====== > build.xml (needs appbundler in ant lib, built from > https://bitbucket.org/infinitekind/appbundler/) > ====== > > > classpath="appbundler-1.0ea.jar" > classname="com.oracle.appbundler.AppBundlerTask"/> > > > > > > > > jvmrequired="1.8" > outputdirectory="." > name="OpenApp" > displayname="OpenApp" > executableName="OpenApp" > identifier="example.OpenApp" > shortversion="1.0" > version="1.0" > mainclassname="example.OpenApp"> > > name="Dummy document" > role="editor"> > > > > From kevin.rushforth at oracle.com Mon Nov 9 21:05:20 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 09 Nov 2015 13:05:20 -0800 Subject: 9-dev unlocked following sanity testing Message-ID: <56410A90.7070502@oracle.com> From morris.meyer at oracle.com Tue Nov 10 21:37:20 2015 From: morris.meyer at oracle.com (Morris Meyer) Date: Tue, 10 Nov 2015 16:37:20 -0500 Subject: [9-dev] RFR: JDK-8142439: Ensemble8 media player slider issues Message-ID: <56426390.2060409@oracle.com> Kevin and Vadim, Could you please review my changes for the post-commit cleanup to JDK-8144354? Vadim regarding folding: if (timeSlider.isValueChanging()) { // multiply duration by percentage calculated by slider position if (duration != null) { mp.seek(duration.multiply(timeSlider.getValue() / 100.0)); } updateValues(); } else if (Math.abs(now.doubleValue() - old.doubleValue()) > 1.5) { // multiply duration by percentage calculated by slider position if (duration != null) { mp.seek(duration.multiply(timeSlider.getValue() / 100.0)); } } Pretty sure that is correct and cannot be folded as the updateValues() is necessary when with a slider changed value, and the click to seek value needs to stay unchanged. Thanks much, --morris WEBREV - http://cr.openjdk.java.net/~morris/JDK-8142439.01/ BUG - https://bugs.openjdk.java.net/browse/JDK-8142439 From tom.schindl at bestsolution.at Wed Nov 11 10:24:56 2015 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Wed, 11 Nov 2015 11:24:56 +0100 Subject: Followup on our Splash Screen discussion at JavaOne (using AWT-SplashScreen) Message-ID: <56431778.5010400@bestsolution.at> Hi Chris, Danno and OpenJFX-Group, Chris not sure you remember our discussion at JavaOne concerning a static splash that opens when using the java-packager. You said you think the AWT-Splash should work so I gave that a try today and in general AWT-Splash and JavaFX can be used together if you: a) start with java -jar .... b) start with java -splash:.... but it does not work with the java-packager :-( I've package up a sample application demonstrating showing the problem and uploaded it to drop box https://www.dropbox.com/s/6rtzmfdojqfoihh/TestSplash.zip?dl=0 Correct me if wrong but not supporting the AWT-Splash with java-packager is certainly a bug because one should be able to ship eg swing applications as well who might have used the AWT-Splash as well. Certainly AWT-Splash is fine with Java8 but for Java9 I would have to ship AWT with my application just to use the splash which a none started so my wish for Java9 would be if the packager would support opening a *static* splash-image and providing me a none AWT-bound API to bring it down. Tom -- 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 O.Schmidtmer at elo.com Wed Nov 11 13:35:57 2015 From: O.Schmidtmer at elo.com (Schmidtmer, Oliver) Date: Wed, 11 Nov 2015 13:35:57 +0000 Subject: JDK-8139844 com.sun.webkit.Timer is never fired if delay is too low Message-ID: <81E523EBFF9AF44789142FCB4E21911716232721@srvpemail01vm.ELO.local> Hello, I'm the submitter of JDK-8139844. A few of our customers are affected by this issue and we can only reproduce it when loading webpages from a specific machine, independent from which machine the client with the web view is started. As a workaround for our problem and JDK-8091962 I modified com.sun.webkit.Timer.fwkSetFireTime in 1.8.0_65-b17 - 32 bit as following and added some output to the calculations: private static void fwkSetFireTime(double fireTime) { long fireTimeMS = (long)Math.ceil(fireTime * 1000); if(fireTimeMS < 0){ double withoutCast = Math.ceil(fireTime * 1000); System.err.println( "fireTime=" + fireTime + " before cast=" + withoutCast + " after cast=" + ((long) withoutCast) + " as one step=" + ((long)Math.ceil(fireTime * 1000)) + " original calculation=" + fireTimeMS); fireTimeMS = 1; } getTimer().setFireTime(System.currentTimeMillis() + fireTimeMS); } Which produces the following output: fireTime=1.0E-9 before cast=1.0 after cast=1 as one step=1 original calculation=-9223372036854775808 fireTime=0.03379535675048828 before cast=34.0 after cast=34 as one step=34 original calculation=-9223372036854775808 fireTime=0.042267560958862305 before cast=43.0 after cast=43 as one step=43 original calculation=-9223372036854775808 fireTime=0.04301285743713379 before cast=44.0 after cast=44 as one step=44 original calculation=-9223372036854775808 fireTime=0.041814565658569336 before cast=42.0 after cast=42 as one step=42 original calculation=-9223372036854775808 fireTime=0.03879666328430176 before cast=39.0 after cast=39 as one step=39 original calculation=-9223372036854775808 fireTime=0.04811882972717285 before cast=49.0 after cast=49 as one step=49 original calculation=-9223372036854775808 fireTime=0.0494379997253418 before cast=50.0 after cast=50 as one step=50 original calculation=-9223372036854775808 fireTime=0.04372882843017578 before cast=44.0 after cast=44 as one step=44 original calculation=-9223372036854775808 fireTime=0.04262733459472656 before cast=43.0 after cast=43 as one step=43 original calculation=-9223372036854775808 fireTime=1.0E-9 before cast=1.0 after cast=1 as one step=1 original calculation=-9223372036854775808 fireTime=0.04141855239868164 before cast=42.0 after cast=42 as one step=42 original calculation=-9223372036854775808 fireTime=0.01515507698059082 before cast=16.0 after cast=16 as one step=16 original calculation=-9223372036854775808 fireTime=0.047502994537353516 before cast=48.0 after cast=48 as one step=48 original calculation=-9223372036854775808 It seems this only happens sometimes in the first calculation. Even when the ceiling & cast is done again with the same value it doesn't happen again. If I can do anything to help sorting this out I will happily do so. Regards, Oliver ________________________________ ELO Digital Office GmbH Firmensitz: T?binger Strasse 43, 70178 Stuttgart Fon: +49 711 806089-0, Fax: +49 711 806089-19, Web: www.elo.com Gesch?ftsf?hrer: Karl Heinz Mosbach, Matthias Thiele BW-Bank, Konto-Nr. 2089782, BLZ 600 501 01 IBAN: DE67600501010002089782 BIC: SOLADEST Registergericht Stuttgart HRB 15059 - USt-IdNr.: DE812471516 From danno.ferrin at oracle.com Wed Nov 11 15:23:48 2015 From: danno.ferrin at oracle.com (Danno Ferrin) Date: Wed, 11 Nov 2015 08:23:48 -0700 Subject: Followup on our Splash Screen discussion at JavaOne (using AWT-SplashScreen) In-Reply-To: <56431778.5010400@bestsolution.at> References: <56431778.5010400@bestsolution.at> Message-ID: <0C482C8F-F97B-43A2-A7EB-66C894BDB3BE@oracle.com> This is a known issue and is being tracked with JDK-8090606. https://bugs.openjdk.java.net/browse/JDK-8090606 > On Nov 11, 2015, at 3:24 AM, Tom Schindl wrote: > > Hi Chris, Danno and OpenJFX-Group, > > Chris not sure you remember our discussion at JavaOne concerning a > static splash that opens when using the java-packager. > > You said you think the AWT-Splash should work so I gave that a try today > and in general AWT-Splash and JavaFX can be used together if you: > a) start with java -jar .... > b) start with java -splash:.... > > but it does not work with the java-packager :-( > > I've package up a sample application demonstrating showing the problem > and uploaded it to drop box > https://www.dropbox.com/s/6rtzmfdojqfoihh/TestSplash.zip?dl=0 > > Correct me if wrong but not supporting the AWT-Splash with java-packager > is certainly a bug because one should be able to ship eg swing > applications as well who might have used the AWT-Splash as well. > > Certainly AWT-Splash is fine with Java8 but for Java9 I would have to > ship AWT with my application just to use the splash which a none started > so my wish for Java9 would be if the packager would support opening a > *static* splash-image and providing me a none AWT-bound API to bring it > down. > > Tom > > -- > 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 chris.bensen at oracle.com Wed Nov 11 16:28:28 2015 From: chris.bensen at oracle.com (Chris Bensen) Date: Wed, 11 Nov 2015 08:28:28 -0800 Subject: Followup on our Splash Screen discussion at JavaOne (using AWT-SplashScreen) In-Reply-To: <0C482C8F-F97B-43A2-A7EB-66C894BDB3BE@oracle.com> References: <56431778.5010400@bestsolution.at> <0C482C8F-F97B-43A2-A7EB-66C894BDB3BE@oracle.com> Message-ID: Hi Tom, Yes, I remember our conversation. Danno?s right, there?s an open bug. I thought it was resolved at some point. Each Operating System acts differently making it a tough problem. I?ll add it to my (very long) todo list and get to it as soon as I can. Thanks, Chris > On Nov 11, 2015, at 7:23 AM, Danno Ferrin wrote: > > This is a known issue and is being tracked with JDK-8090606. > > https://bugs.openjdk.java.net/browse/JDK-8090606 > >> On Nov 11, 2015, at 3:24 AM, Tom Schindl > wrote: >> >> Hi Chris, Danno and OpenJFX-Group, >> >> Chris not sure you remember our discussion at JavaOne concerning a >> static splash that opens when using the java-packager. >> >> You said you think the AWT-Splash should work so I gave that a try today >> and in general AWT-Splash and JavaFX can be used together if you: >> a) start with java -jar .... >> b) start with java -splash:.... >> >> but it does not work with the java-packager :-( >> >> I've package up a sample application demonstrating showing the problem >> and uploaded it to drop box >> https://www.dropbox.com/s/6rtzmfdojqfoihh/TestSplash.zip?dl=0 >> >> Correct me if wrong but not supporting the AWT-Splash with java-packager >> is certainly a bug because one should be able to ship eg swing >> applications as well who might have used the AWT-Splash as well. >> >> Certainly AWT-Splash is fine with Java8 but for Java9 I would have to >> ship AWT with my application just to use the splash which a none started >> so my wish for Java9 would be if the packager would support opening a >> *static* splash-image and providing me a none AWT-bound API to bring it >> down. >> >> Tom >> >> -- >> 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 guru.hb at oracle.com Thu Nov 12 10:19:08 2015 From: guru.hb at oracle.com (Guru Hb) Date: Thu, 12 Nov 2015 02:19:08 -0800 (PST) Subject: JDK-8139844 com.sun.webkit.Timer is never fired if delay is too low In-Reply-To: <81E523EBFF9AF44789142FCB4E21911716232721@srvpemail01vm.ELO.local> References: <81E523EBFF9AF44789142FCB4E21911716232721@srvpemail01vm.ELO.local> Message-ID: <949c22e1-f538-4cd2-90f7-e69e448a0e59@default> Hello Oliver, Could you please provide info where this problem is seen more often. OS type, version & 32 / 64 bit JDK version & 32 / 64 bit. (already mentioned 8u66 and 32 bit in email) fireTime (argument) value can't go less than "1.0E-9". As you pointed out the problem lies in "Math.ceil(fireTime * 1000)". Initially I have tested on window 7 64 bit and JDK 8u66 64 bit. Asserting the value if less than 0 in "fwkSetFireTime" would be a temporary solution. Thanks, Guru -----Original Message----- From: Schmidtmer, Oliver [mailto:O.Schmidtmer at elo.com] Sent: Wednesday, November 11, 2015 7:06 PM To: openjfx-dev at openjdk.java.net Subject: JDK-8139844 com.sun.webkit.Timer is never fired if delay is too low Hello, I'm the submitter of JDK-8139844. A few of our customers are affected by this issue and we can only reproduce it when loading webpages from a specific machine, independent from which machine the client with the web view is started. As a workaround for our problem and JDK-8091962 I modified com.sun.webkit.Timer.fwkSetFireTime in 1.8.0_65-b17 - 32 bit as following and added some output to the calculations: private static void fwkSetFireTime(double fireTime) { long fireTimeMS = (long)Math.ceil(fireTime * 1000); if(fireTimeMS < 0){ double withoutCast = Math.ceil(fireTime * 1000); System.err.println( "fireTime=" + fireTime + " before cast=" + withoutCast + " after cast=" + ((long) withoutCast) + " as one step=" + ((long)Math.ceil(fireTime * 1000)) + " original calculation=" + fireTimeMS); fireTimeMS = 1; } getTimer().setFireTime(System.currentTimeMillis() + fireTimeMS); } Which produces the following output: fireTime=1.0E-9 before cast=1.0 after cast=1 as one step=1 original calculation=-9223372036854775808 fireTime=0.03379535675048828 before cast=34.0 after cast=34 as one step=34 original calculation=-9223372036854775808 fireTime=0.042267560958862305 before cast=43.0 after cast=43 as one step=43 original calculation=-9223372036854775808 fireTime=0.04301285743713379 before cast=44.0 after cast=44 as one step=44 original calculation=-9223372036854775808 fireTime=0.041814565658569336 before cast=42.0 after cast=42 as one step=42 original calculation=-9223372036854775808 fireTime=0.03879666328430176 before cast=39.0 after cast=39 as one step=39 original calculation=-9223372036854775808 fireTime=0.04811882972717285 before cast=49.0 after cast=49 as one step=49 original calculation=-9223372036854775808 fireTime=0.0494379997253418 before cast=50.0 after cast=50 as one step=50 original calculation=-9223372036854775808 fireTime=0.04372882843017578 before cast=44.0 after cast=44 as one step=44 original calculation=-9223372036854775808 fireTime=0.04262733459472656 before cast=43.0 after cast=43 as one step=43 original calculation=-9223372036854775808 fireTime=1.0E-9 before cast=1.0 after cast=1 as one step=1 original calculation=-9223372036854775808 fireTime=0.04141855239868164 before cast=42.0 after cast=42 as one step=42 original calculation=-9223372036854775808 fireTime=0.01515507698059082 before cast=16.0 after cast=16 as one step=16 original calculation=-9223372036854775808 fireTime=0.047502994537353516 before cast=48.0 after cast=48 as one step=48 original calculation=-9223372036854775808 It seems this only happens sometimes in the first calculation. Even when the ceiling & cast is done again with the same value it doesn't happen again. If I can do anything to help sorting this out I will happily do so. Regards, Oliver ________________________________ ELO Digital Office GmbH Firmensitz: T?binger Strasse 43, 70178 Stuttgart Fon: +49 711 806089-0, Fax: +49 711 806089-19, Web: www.elo.com Gesch?ftsf?hrer: Karl Heinz Mosbach, Matthias Thiele BW-Bank, Konto-Nr. 2089782, BLZ 600 501 01 IBAN: DE67600501010002089782 BIC: SOLADEST Registergericht Stuttgart HRB 15059 - USt-IdNr.: DE812471516 From O.Schmidtmer at elo.com Thu Nov 12 15:51:43 2015 From: O.Schmidtmer at elo.com (Schmidtmer, Oliver) Date: Thu, 12 Nov 2015 15:51:43 +0000 Subject: AW: JDK-8139844 com.sun.webkit.Timer is never fired if delay is too low In-Reply-To: <949c22e1-f538-4cd2-90f7-e69e448a0e59@default> References: <81E523EBFF9AF44789142FCB4E21911716232721@srvpemail01vm.ELO.local> <949c22e1-f538-4cd2-90f7-e69e448a0e59@default> Message-ID: <81E523EBFF9AF44789142FCB4E219117162328C5@srvpemail01vm.ELO.local> Hello Guru, I've tested it with 8u51 32bit, 8u60 32bit and 8u65 32bit using windows 7 64bit where I can reproduce this every time against our test server. Indeed it doesn't happen with 8u65 64bit and 8u66 64bit on windows 7 64bit. I've not checked other 64bit JREs but can do so if wished. Mac OS X with 64bit JRE and Linux with 32bit&64bit JRE also don't seem to have this issue. Maybe this really happens only on windows with 32bit JREs. Thanks, Oliver -----Urspr?ngliche Nachricht----- Von: Guru Hb [mailto:guru.hb at oracle.com] Gesendet: Donnerstag, 12. November 2015 11:19 An: Schmidtmer, Oliver Cc: openjfx-dev at openjdk.java.net Betreff: RE: JDK-8139844 com.sun.webkit.Timer is never fired if delay is too low Hello Oliver, Could you please provide info where this problem is seen more often. OS type, version & 32 / 64 bit JDK version & 32 / 64 bit. (already mentioned 8u66 and 32 bit in email) fireTime (argument) value can't go less than "1.0E-9". As you pointed out the problem lies in "Math.ceil(fireTime * 1000)". Initially I have tested on window 7 64 bit and JDK 8u66 64 bit. Asserting the value if less than 0 in "fwkSetFireTime" would be a temporary solution. Thanks, Guru -----Original Message----- From: Schmidtmer, Oliver [mailto:O.Schmidtmer at elo.com] Sent: Wednesday, November 11, 2015 7:06 PM To: openjfx-dev at openjdk.java.net Subject: JDK-8139844 com.sun.webkit.Timer is never fired if delay is too low Hello, I'm the submitter of JDK-8139844. A few of our customers are affected by this issue and we can only reproduce it when loading webpages from a specific machine, independent from which machine the client with the web view is started. As a workaround for our problem and JDK-8091962 I modified com.sun.webkit.Timer.fwkSetFireTime in 1.8.0_65-b17 - 32 bit as following and added some output to the calculations: private static void fwkSetFireTime(double fireTime) { long fireTimeMS = (long)Math.ceil(fireTime * 1000); if(fireTimeMS < 0){ double withoutCast = Math.ceil(fireTime * 1000); System.err.println( "fireTime=" + fireTime + " before cast=" + withoutCast + " after cast=" + ((long) withoutCast) + " as one step=" + ((long)Math.ceil(fireTime * 1000)) + " original calculation=" + fireTimeMS); fireTimeMS = 1; } getTimer().setFireTime(System.currentTimeMillis() + fireTimeMS); } Which produces the following output: fireTime=1.0E-9 before cast=1.0 after cast=1 as one step=1 original calculation=-9223372036854775808 fireTime=0.03379535675048828 before cast=34.0 after cast=34 as one step=34 original calculation=-9223372036854775808 fireTime=0.042267560958862305 before cast=43.0 after cast=43 as one step=43 original calculation=-9223372036854775808 fireTime=0.04301285743713379 before cast=44.0 after cast=44 as one step=44 original calculation=-9223372036854775808 fireTime=0.041814565658569336 before cast=42.0 after cast=42 as one step=42 original calculation=-9223372036854775808 fireTime=0.03879666328430176 before cast=39.0 after cast=39 as one step=39 original calculation=-9223372036854775808 fireTime=0.04811882972717285 before cast=49.0 after cast=49 as one step=49 original calculation=-9223372036854775808 fireTime=0.0494379997253418 before cast=50.0 after cast=50 as one step=50 original calculation=-9223372036854775808 fireTime=0.04372882843017578 before cast=44.0 after cast=44 as one step=44 original calculation=-9223372036854775808 fireTime=0.04262733459472656 before cast=43.0 after cast=43 as one step=43 original calculation=-9223372036854775808 fireTime=1.0E-9 before cast=1.0 after cast=1 as one step=1 original calculation=-9223372036854775808 fireTime=0.04141855239868164 before cast=42.0 after cast=42 as one step=42 original calculation=-9223372036854775808 fireTime=0.01515507698059082 before cast=16.0 after cast=16 as one step=16 original calculation=-9223372036854775808 fireTime=0.047502994537353516 before cast=48.0 after cast=48 as one step=48 original calculation=-9223372036854775808 It seems this only happens sometimes in the first calculation. Even when the ceiling & cast is done again with the same value it doesn't happen again. If I can do anything to help sorting this out I will happily do so. Regards, Oliver ________________________________ ELO Digital Office GmbH Firmensitz: T?binger Strasse 43, 70178 Stuttgart Fon: +49 711 806089-0, Fax: +49 711 806089-19, Web: www.elo.com Gesch?ftsf?hrer: Karl Heinz Mosbach, Matthias Thiele BW-Bank, Konto-Nr. 2089782, BLZ 600 501 01 IBAN: DE67600501010002089782 BIC: SOLADEST Registergericht Stuttgart HRB 15059 - USt-IdNr.: DE812471516 ________________________________ ELO Digital Office GmbH Firmensitz: T?binger Strasse 43, 70178 Stuttgart Fon: +49 711 806089-0, Fax: +49 711 806089-19, Web: www.elo.com Gesch?ftsf?hrer: Karl Heinz Mosbach, Matthias Thiele BW-Bank, Konto-Nr. 2089782, BLZ 600 501 01 IBAN: DE67600501010002089782 BIC: SOLADEST Registergericht Stuttgart HRB 15059 - USt-IdNr.: DE812471516 From guru.hb at oracle.com Thu Nov 12 19:24:01 2015 From: guru.hb at oracle.com (Guru Hb) Date: Thu, 12 Nov 2015 11:24:01 -0800 (PST) Subject: [9] Review request for 8141345: Cannot build WebKit with bison3 (only on windows) Message-ID: <6f95d790-9dc9-409b-adaf-86e3e5e21c0c@default> Hi Kevin, Alexander & Vadim, JBS : https://bugs.openjdk.java.net/browse/JDK-8141345 Webrev : http://cr.openjdk.java.net/~ghb/8141345/webrev.00/ Tested on Windows (Bison 3.0.4), Linux and Mac. Thanks, Guru From arunprasad.rajkumar at oracle.com Fri Nov 13 11:52:22 2015 From: arunprasad.rajkumar at oracle.com (Arunprasad Rajkumar) Date: Fri, 13 Nov 2015 17:22:22 +0530 Subject: [9] Review request for 8141386: Unable to pass values to java functions which takes wrapper objects as arguments In-Reply-To: <5639D07B.8070205@oracle.com> References: <5639D07B.8070205@oracle.com> Message-ID: <5645CEF6.9070408@oracle.com> Hi Kevin, Alexander, Guru, Please review the below patch. JIRA: https://bugs.openjdk.java.net/browse/JDK-8141386 Webrev: http://cr.openjdk.java.net/~ghb/arunprasad/8141386/webrev.00 Regards, Arun From guru.hb at oracle.com Fri Nov 13 12:30:13 2015 From: guru.hb at oracle.com (Guru Hb) Date: Fri, 13 Nov 2015 04:30:13 -0800 (PST) Subject: AW: JDK-8139844 com.sun.webkit.Timer is never fired if delay is too low In-Reply-To: <81E523EBFF9AF44789142FCB4E219117162328C5@srvpemail01vm.ELO.local> References: <81E523EBFF9AF44789142FCB4E21911716232721@srvpemail01vm.ELO.local> <949c22e1-f538-4cd2-90f7-e69e448a0e59@default> <81E523EBFF9AF44789142FCB4E219117162328C5@srvpemail01vm.ELO.local> Message-ID: Command Line option while running the java ? Host and Test server (considering "every time against our test server") CPU Make & Model Windows 7 (64 bit) type (Professional / Home / etc..) ? Service pack version ? Are you using Oracle provided JDK or modified ? Both Host and Test server is having JDK or only JRE ? Tried myself on 8u51, 8u60 and 8u64 (all 32 bit JDK) , but couldn't re-produce here locally. Thanks, Guru -----Original Message----- From: Schmidtmer, Oliver [mailto:O.Schmidtmer at elo.com] Sent: Thursday, November 12, 2015 9:22 PM To: Guru Hb Cc: openjfx-dev at openjdk.java.net Subject: AW: JDK-8139844 com.sun.webkit.Timer is never fired if delay is too low Hello Guru, I've tested it with 8u51 32bit, 8u60 32bit and 8u65 32bit using windows 7 64bit where I can reproduce this every time against our test server. Indeed it doesn't happen with 8u65 64bit and 8u66 64bit on windows 7 64bit. I've not checked other 64bit JREs but can do so if wished. Mac OS X with 64bit JRE and Linux with 32bit&64bit JRE also don't seem to have this issue. Maybe this really happens only on windows with 32bit JREs. Thanks, Oliver -----Urspr?ngliche Nachricht----- Von: Guru Hb [mailto:guru.hb at oracle.com] Gesendet: Donnerstag, 12. November 2015 11:19 An: Schmidtmer, Oliver Cc: openjfx-dev at openjdk.java.net Betreff: RE: JDK-8139844 com.sun.webkit.Timer is never fired if delay is too low Hello Oliver, Could you please provide info where this problem is seen more often. OS type, version & 32 / 64 bit JDK version & 32 / 64 bit. (already mentioned 8u66 and 32 bit in email) fireTime (argument) value can't go less than "1.0E-9". As you pointed out the problem lies in "Math.ceil(fireTime * 1000)". Initially I have tested on window 7 64 bit and JDK 8u66 64 bit. Asserting the value if less than 0 in "fwkSetFireTime" would be a temporary solution. Thanks, Guru -----Original Message----- From: Schmidtmer, Oliver [mailto:O.Schmidtmer at elo.com] Sent: Wednesday, November 11, 2015 7:06 PM To: openjfx-dev at openjdk.java.net Subject: JDK-8139844 com.sun.webkit.Timer is never fired if delay is too low Hello, I'm the submitter of JDK-8139844. A few of our customers are affected by this issue and we can only reproduce it when loading webpages from a specific machine, independent from which machine the client with the web view is started. As a workaround for our problem and JDK-8091962 I modified com.sun.webkit.Timer.fwkSetFireTime in 1.8.0_65-b17 - 32 bit as following and added some output to the calculations: private static void fwkSetFireTime(double fireTime) { long fireTimeMS = (long)Math.ceil(fireTime * 1000); if(fireTimeMS < 0){ double withoutCast = Math.ceil(fireTime * 1000); System.err.println( "fireTime=" + fireTime + " before cast=" + withoutCast + " after cast=" + ((long) withoutCast) + " as one step=" + ((long)Math.ceil(fireTime * 1000)) + " original calculation=" + fireTimeMS); fireTimeMS = 1; } getTimer().setFireTime(System.currentTimeMillis() + fireTimeMS); } Which produces the following output: fireTime=1.0E-9 before cast=1.0 after cast=1 as one step=1 original calculation=-9223372036854775808 fireTime=0.03379535675048828 before cast=34.0 after cast=34 as one step=34 original calculation=-9223372036854775808 fireTime=0.042267560958862305 before cast=43.0 after cast=43 as one step=43 original calculation=-9223372036854775808 fireTime=0.04301285743713379 before cast=44.0 after cast=44 as one step=44 original calculation=-9223372036854775808 fireTime=0.041814565658569336 before cast=42.0 after cast=42 as one step=42 original calculation=-9223372036854775808 fireTime=0.03879666328430176 before cast=39.0 after cast=39 as one step=39 original calculation=-9223372036854775808 fireTime=0.04811882972717285 before cast=49.0 after cast=49 as one step=49 original calculation=-9223372036854775808 fireTime=0.0494379997253418 before cast=50.0 after cast=50 as one step=50 original calculation=-9223372036854775808 fireTime=0.04372882843017578 before cast=44.0 after cast=44 as one step=44 original calculation=-9223372036854775808 fireTime=0.04262733459472656 before cast=43.0 after cast=43 as one step=43 original calculation=-9223372036854775808 fireTime=1.0E-9 before cast=1.0 after cast=1 as one step=1 original calculation=-9223372036854775808 fireTime=0.04141855239868164 before cast=42.0 after cast=42 as one step=42 original calculation=-9223372036854775808 fireTime=0.01515507698059082 before cast=16.0 after cast=16 as one step=16 original calculation=-9223372036854775808 fireTime=0.047502994537353516 before cast=48.0 after cast=48 as one step=48 original calculation=-9223372036854775808 It seems this only happens sometimes in the first calculation. Even when the ceiling & cast is done again with the same value it doesn't happen again. If I can do anything to help sorting this out I will happily do so. Regards, Oliver ________________________________ ELO Digital Office GmbH Firmensitz: T?binger Strasse 43, 70178 Stuttgart Fon: +49 711 806089-0, Fax: +49 711 806089-19, Web: www.elo.com Gesch?ftsf?hrer: Karl Heinz Mosbach, Matthias Thiele BW-Bank, Konto-Nr. 2089782, BLZ 600 501 01 IBAN: DE67600501010002089782 BIC: SOLADEST Registergericht Stuttgart HRB 15059 - USt-IdNr.: DE812471516 ________________________________ ELO Digital Office GmbH Firmensitz: T?binger Strasse 43, 70178 Stuttgart Fon: +49 711 806089-0, Fax: +49 711 806089-19, Web: www.elo.com Gesch?ftsf?hrer: Karl Heinz Mosbach, Matthias Thiele BW-Bank, Konto-Nr. 2089782, BLZ 600 501 01 IBAN: DE67600501010002089782 BIC: SOLADEST Registergericht Stuttgart HRB 15059 - USt-IdNr.: DE812471516 From vadim.pakhnushev at oracle.com Fri Nov 13 14:50:23 2015 From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev) Date: Fri, 13 Nov 2015 17:50:23 +0300 Subject: In(Sanity) Testing Mondays Message-ID: <5645F8AF.3050808@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 PST until 1pm PST. Happy testing! Thanks, Vadim From kevin.rushforth at oracle.com Fri Nov 13 23:18:18 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 13 Nov 2015 15:18:18 -0800 Subject: JavaFX PulseLogger with JFR (Java Flight Recorder) Message-ID: <56466FBA.9080004@oracle.com> Have any JavaFX developers on the list used JFR (Java Flight Recorder) with the JavaFX pulse logger? If so, how useful has it been to you? Or are most of you (of those who use pulse logger for debugging) getting what you need from the PrintLogger, which is enabled by "-Djavafx.pulseLogger=true"? -- Kevin From elina.kleyman at oracle.com Sun Nov 15 18:08:28 2015 From: elina.kleyman at oracle.com (Elina Kleyman) Date: Sun, 15 Nov 2015 10:08:28 -0800 (PST) Subject: [9] Review request for JDK-8136898: HelloDialogs throws NPE for ExceptionDialog, showLinearWizard, and showBranchingWizard Message-ID: Hi Kevin, Chien, guys, Please review my suggested fix. JIRA: https://bugs.openjdk.java.net/browse/JDK-8136898 Webrev: http://cr.openjdk.java.net/~ekleyman/JDK-8136898/ Thanks, Elina From fastegal at swingempire.de Mon Nov 16 12:06:00 2015 From: fastegal at swingempire.de (fastegal at swingempire.de) Date: Mon, 16 Nov 2015 13:06:00 +0100 Subject: Bug when combining ListView and SortedList? In-Reply-To: <025E25CA98F8AE46BE306AB33F6A38D501276A01@ADEFUE01SMS003.cznet.zeiss.org> References: <025E25CA98F8AE46BE306AB33F6A38D5012769BB@ADEFUE01SMS003.cznet.zeiss.org> <025E25CA98F8AE46BE306AB33F6A38D501276A01@ADEFUE01SMS003.cznet.zeiss.org> Message-ID: <20151116130600.Horde.2gRfI1CJG6fAX4sc7i4p3w1@webmail.df.eu> Zitat von "Fisher, Robert" : > Done. > Mind to add the issue #? Note that there are tons of issues around incorrect selection notification/state after modifying the underlying items. One very basic problem in all core implementations is that they simply can't handle disjoint mutations (plus selectedItems/-Indices are firing incorrect notifications on there own behalf, which is a related though slightly different story). Have been reporting variants (and ranting and suggesting fixes) for ages ... and now seeing that some of those reports got tagged "nicetohave" ... doooohhh CU Jeanette From robert.fisher.ext at zeiss.com Mon Nov 16 15:10:55 2015 From: robert.fisher.ext at zeiss.com (Fisher, Robert) Date: Mon, 16 Nov 2015 15:10:55 +0000 Subject: Bug when combining ListView and SortedList? In-Reply-To: <20151116130600.Horde.2gRfI1CJG6fAX4sc7i4p3w1@webmail.df.eu> References: <025E25CA98F8AE46BE306AB33F6A38D5012769BB@ADEFUE01SMS003.cznet.zeiss.org> <025E25CA98F8AE46BE306AB33F6A38D501276A01@ADEFUE01SMS003.cznet.zeiss.org> <20151116130600.Horde.2gRfI1CJG6fAX4sc7i4p3w1@webmail.df.eu> Message-ID: <025E25CA98F8AE46BE306AB33F6A38D5012773C4@ADEFUE01SMS003.cznet.zeiss.org> https://bugs.openjdk.java.net/browse/JDK-8141124 This is a regression introduced in 1.8.0_60, so it might have a different origin than the problems you mention. Cheers, Rob -----Original Message----- From: openjfx-dev [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of fastegal at swingempire.de Sent: Montag, 16. November 2015 13:06 To: openjfx-dev at openjdk.java.net Subject: Re: Bug when combining ListView and SortedList? Zitat von "Fisher, Robert" : > Done. > Mind to add the issue #? Note that there are tons of issues around incorrect selection notification/state after modifying the underlying items. One very basic problem in all core implementations is that they simply can't handle disjoint mutations (plus selectedItems/-Indices are firing incorrect notifications on there own behalf, which is a related though slightly different story). Have been reporting variants (and ranting and suggesting fixes) for ages ... and now seeing that some of those reports got tagged "nicetohave" ... doooohhh CU Jeanette From elina.kleyman at oracle.com Mon Nov 16 15:15:41 2015 From: elina.kleyman at oracle.com (Elina Kleyman) Date: Mon, 16 Nov 2015 07:15:41 -0800 (PST) Subject: FW: [9] Review request for JDK-8136898: HelloDialogs throws NPE for ExceptionDialog, showLinearWizard, and showBranchingWizard Message-ID: <323ebf45-97fb-4ef7-ad79-863ef3473f63@default> Guys, ? Please see updated webrev with few changes: http://cr.openjdk.java.net/~ekleyman/JDK-8136898_2/ ? (On the way, as part of bug: HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8134716"JDK-8134716, usage of internal class com.sun.javafx.scene.control.skin.resources.ControlResources was removed from CommandLinksDialog.java) ? Thanks, Elina ? From: Elina Kleyman Sent: ????? 15 ?????? 2015 20:08 To: Kevin Rushforth; Chien Yang Cc: openjfx-dev at openjdk.java.net Subject: [9] Review request for JDK-8136898: HelloDialogs throws NPE for ExceptionDialog, showLinearWizard, and showBranchingWizard ? Hi Kevin, Chien, guys, ? Please review my suggested fix. ? JIRA: https://bugs.openjdk.java.net/browse/JDK-8136898 Webrev: http://cr.openjdk.java.net/~ekleyman/JDK-8136898/ ? Thanks, Elina ? From jonathan.giles at oracle.com Mon Nov 16 19:53:38 2015 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Tue, 17 Nov 2015 08:53:38 +1300 Subject: Bug when combining ListView and SortedList? In-Reply-To: <20151116130600.Horde.2gRfI1CJG6fAX4sc7i4p3w1@webmail.df.eu> References: <025E25CA98F8AE46BE306AB33F6A38D5012769BB@ADEFUE01SMS003.cznet.zeiss.org> <025E25CA98F8AE46BE306AB33F6A38D501276A01@ADEFUE01SMS003.cznet.zeiss.org> <20151116130600.Horde.2gRfI1CJG6fAX4sc7i4p3w1@webmail.df.eu> Message-ID: <564A3442.1080708@oracle.com> > > Have been reporting variants (and ranting and suggesting fixes) for > ages ... and now seeing that some of those reports got tagged > "nicetohave" ... doooohhh Jeanette, You are misinterpreting the 'nicetohave' label as a negative. The actual fact is that the 'nicetohave' label is applied to issues that we want to fix for JDK 9, but were too low priority in their current state and therefore would by default have been retargeted away from JDK 9. In other words, I purposefully added 'nicetohave' to a lot of the selection model issues I have assigned to me, so that I can try my very best to get them fixed in JDK 9. The alternative would have been to have them be retargeted away. Perhaps we should have called the label 'savefromrelegation'. -- Jonathan From kevin.rushforth at oracle.com Mon Nov 16 21:14:47 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 16 Nov 2015 13:14:47 -0800 Subject: 9-dev unlocked following sanity testing Message-ID: <564A4747.6020104@oracle.com> From jonathan.giles at oracle.com Tue Nov 17 00:12:42 2015 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Tue, 17 Nov 2015 13:12:42 +1300 Subject: [REVIEW REQUEST] JDK-8143033: Performance issue with JavaFX Message-ID: <564A70FA.8090304@oracle.com> Kevin, Leif, Could you please review the patch attached here: https://bugs.openjdk.java.net/browse/JDK-8143033 Whilst the patch itself is tiny, a sanity check that what I'm doing would be much appreciated. Refer to my comment in Jira for more context. Thanks, -- Jonathan From johan at lodgon.com Tue Nov 17 10:54:48 2015 From: johan at lodgon.com (Johan Vos) Date: Tue, 17 Nov 2015 11:54:48 +0100 Subject: JavaFX PulseLogger with JFR (Java Flight Recorder) In-Reply-To: <56466FBA.9080004@oracle.com> References: <56466FBA.9080004@oracle.com> Message-ID: I am using -Djavafx.pulseLogger=true often and I'm very happy with this. - Johan 2015-11-14 0:18 GMT+01:00 Kevin Rushforth : > Have any JavaFX developers on the list used JFR (Java Flight Recorder) > with the JavaFX pulse logger? If so, how useful has it been to you? > > Or are most of you (of those who use pulse logger for debugging) getting > what you need from the PrintLogger, which is enabled by > "-Djavafx.pulseLogger=true"? > > -- Kevin > > From felix.bembrick at gmail.com Tue Nov 17 10:56:22 2015 From: felix.bembrick at gmail.com (Felix Bembrick) Date: Tue, 17 Nov 2015 21:56:22 +1100 Subject: pisces, produceFillAlphas In-Reply-To: References: <561FF83E.3000407@oracle.com> <5620261F.7060206@oracle.com> Message-ID: Hi Johan, Have you been able to find enough time to be able to answer this question? In my present situation, clarity on these issues is extremely important to me and I would guess to many others as well. Thanks, Felix > On 18 Oct 2015, at 19:01, Felix Bembrick wrote: > > Hi Johan, > > If you have been getting acceptable but not stunning performance on Android and all this time hardware acceleration was not being utilised then it sounds like there is some serious room for some dramatic performance increases. > > Not being that familiar with the finer points of how JavaFX is implemented on Android, just how much work is involved in accessing that hardware acceleration? Any timeline? > > I expect that implementing this significant change could be a make-or-break factor in determining whether JavaFX is truly viable and successful on Android. > > Good luck Johan! > > Cheers, > > Felix > >> On 17 Oct 2015, at 19:49, Johan Vos wrote: >> >> As a follow-up on the second part: after about 2 years working on JavaFX on >> Android, I discovered we are not even using Hardware Acceleration. We >> create a SurfaceView and render on that, but it turns out SurfaceView is >> never Hardware Accelerated. The positive thing is that this means there is >> even more room for optimization :) >> >> - Johan >> >>> On Fri, Oct 16, 2015 at 7:55 PM, Johan Vos wrote: >>> >>> Hi, >>> >>> Thanks for the suggestions. There are 2 different things: >>> >>> 1. It seems indeed there is not much being cached, so there are definitely >>> improvements possible. It also require e.g. VirtualFlow to use the >>> Node.setCache(true) in order to cache. The combination of this with the >>> prism.scrollcacheopt reduces the rendering calls. I think the only penalty >>> is memory, but so far, we didn't run into issues with too high GC activity. >>> >>> 2. Calls to glDrawElements() inside nDrawIndexedQuads take about 100 times >>> longer on the Nexus 6 compared to the iPhone 6 (e.g. 100,000ns vs 1000ns). >>> I'll have to look into some EGL options. >>> >>> - Johan >>> >>> >>> On Fri, Oct 16, 2015 at 12:18 AM, Jim Graham >>> wrote: >>> >>>> Chien pointed out a system property that is currently disabling the >>>> scrolling optimization. For its implementation look at CacheFilter.java, >>>> in particular the invalidateByTranslation() method and all that it kicks >>>> off. >>>> >>>> Another thing to look at is that we added alpha batching to the code >>>> which should be batching all of the output of the produceAlphas calls into >>>> a texture and then drawing all of the quads together - provided that they >>>> are all being filled with simple colors (they can have alpha, but they >>>> can't be gradients, etc.). This should be managed by the >>>> BaseContext.updateMaskTexture() method which controls the single batch >>>> texture. >>>> >>>> Again, are there similar number of invocations of the glDrawElements on >>>> the 2 platforms? >>>> >>>> ...jim >>>> >>>>> On 10/15/15 12:30 PM, Johan Vos wrote: >>>>> >>>>> Thanks Jim. >>>>> I tried with different optimization flags, but it doesn't make a big >>>>> difference. Tracing it down to system calls, somehow the gl >>>>> implementation seems be be slower (glDrawElements(GL_TRIANGLES, numQuads >>>>> * 2 * 3, GL_UNSIGNED_SHORT, 0) takes more time on Android than on iOS) >>>>> per invocation. The number of invocations is comparable between iOS and >>>>> Android. >>>>> >>>>> If you can give me a direction on where to search for the disabled >>>>> scrolling optimization, I'll try to re-enable that and see how it >>>>> improves performance. It might be a huge and quick win... >>>>> >>>>> Thanks again, >>>>> >>>>> - Johan >>>>> >>>>> On Thu, Oct 15, 2015 at 9:02 PM, Jim Graham >>>> > wrote: >>>>> >>>>> Perhaps optimization flags with the native compiler? Also, was it >>>>> called a similar number of times on both? >>>>> >>>>> Ideally we'd just be using copyArea for the scrolling, but at one >>>>> point we disabled the scrolling optimizations on retina MBP because >>>>> they didn't work with a scale factor and I don't think we reenabled >>>>> them yet. That would kill scrolling performance on mobile as a >>>>> result of having to rerender the scene on each scroll regardless of >>>>> how long produceAlphas takes... >>>>> >>>>> ...jim >>>>> >>>>> >>>>> On 10/15/15 4:27 AM, Johan Vos wrote: >>>>> >>>>> After spending lots of time optimizing JavaFX on iOS, I am now >>>>> at the point >>>>> where scrolling is 10 times faster on iOS than on Android. >>>>> The scrolling in the iOS version of the Gluon JavaOne mobile >>>>> schedule >>>>> builder is pretty good imho. On Android, it is much slower. I >>>>> profiled and >>>>> compared both, and it turns out that on Android, we spend lots >>>>> of time in >>>>> the native implementation of >>>>> NativePiscesRasterizer.produceFillAlphas >>>>> (implemented in native-prism/NativePiscesRasterizer.c) >>>>> >>>>> On average, calling this native function on an iPhone 6 takes >>>>> 40,000ns >>>>> whereas on a Nexus 6, this takes about 800,000ns. >>>>> >>>>> If anyone has a suggestion on how to improve or avoid this, I'm >>>>> all ears. >>>>> >>>>> Thanks, >>>>> >>>>> - Johan >>> From fastegal at swingempire.de Tue Nov 17 12:34:27 2015 From: fastegal at swingempire.de (fastegal at swingempire.de) Date: Tue, 17 Nov 2015 13:34:27 +0100 Subject: Bug when combining ListView and SortedList? In-Reply-To: <025E25CA98F8AE46BE306AB33F6A38D5012773C4@ADEFUE01SMS003.cznet.zeiss.org> References: <025E25CA98F8AE46BE306AB33F6A38D5012769BB@ADEFUE01SMS003.cznet.zeiss.org> <025E25CA98F8AE46BE306AB33F6A38D501276A01@ADEFUE01SMS003.cznet.zeiss.org> <20151116130600.Horde.2gRfI1CJG6fAX4sc7i4p3w1@webmail.df.eu> <025E25CA98F8AE46BE306AB33F6A38D5012773C4@ADEFUE01SMS003.cznet.zeiss.org> Message-ID: <20151117133427.Horde.biuJWi9vbn1hqh-p69eUPg1@webmail.df.eu> Zitat von "Fisher, Robert" : > https://bugs.openjdk.java.net/browse/JDK-8141124 > > This is a regression introduced in 1.8.0_60, so it might have a > different origin than the problems you mention. > Thanks! You are right, the "visible" behavior indeed is a regression. The underlying reason - incorrect handling of disjoint changes - is the same, just a technical variant :-) Commented the issue. The old version "just" fired incorrect changes, the new doesn't even update the selection as needed. Cheers Jeanette From fastegal at swingempire.de Tue Nov 17 12:55:14 2015 From: fastegal at swingempire.de (fastegal at swingempire.de) Date: Tue, 17 Nov 2015 13:55:14 +0100 Subject: Bug when combining ListView and SortedList? In-Reply-To: <564A3442.1080708@oracle.com> References: <025E25CA98F8AE46BE306AB33F6A38D5012769BB@ADEFUE01SMS003.cznet.zeiss.org> <025E25CA98F8AE46BE306AB33F6A38D501276A01@ADEFUE01SMS003.cznet.zeiss.org> <20151116130600.Horde.2gRfI1CJG6fAX4sc7i4p3w1@webmail.df.eu> <564A3442.1080708@oracle.com> Message-ID: <20151117135514.Horde.lvVg5UtdoBlJ7OKNfAgA5g1@webmail.df.eu> Jonathan, thanks for the clarification, I indeed misunderstood the new tag. On the other hand: not all (related) selection issues are tagged as such, are those in danger of not being fixed for 9? Anyway, all of them _could_ be fixed in one stroke by throwing away the evil MultipleSelectionModelBase, particularly its usage of ReadOnlyUnbackedObservableList which forces those ominous manual change notifications (which are not trivial to get right). Instead, implement a bitset-backed observableList with the available (since 8, very sound in my experience) collections infrastructure that does all the heavy lifting plus a coupled (kind-of transformed) items list. You know where to find a POC replacement :-) CU Jeanette From elina.kleyman at oracle.com Tue Nov 17 15:57:04 2015 From: elina.kleyman at oracle.com (Elina Kleyman) Date: Tue, 17 Nov 2015 07:57:04 -0800 (PST) Subject: FW: [9] Review request for JDK-8134716 - Remove use of internal classes methods from toys/Hello Message-ID: Kevin, guys, HelloFPS.java and HelloHighContrast.java can't be removed, therefore they should be moved to rt/tests. Please review the following solution: BUG: https://bugs.openjdk.java.net/browse/JDK-8134716 WEBREV: http://cr.openjdk.java.net/~ekleyman/JDK-8134716/ Thanks, Elina From Sergey.Bylokhov at oracle.com Tue Nov 17 17:20:00 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 17 Nov 2015 20:20:00 +0300 Subject: Java 8 updates are causing "Apps that use non-public APIs will be rejected" In-Reply-To: References: Message-ID: <564B61C0.9010809@oracle.com> I think openjfx-dev at openjdk.java.net (cc) is correct place to ask this question. On 16.11.15 23:10, Ond?ej Kvasnovsk? wrote: > Hi, > > We are facing to an issue with latest Java updates when we try to > release apps into Apple app store. I have described the issue here, with > all my findings: > http://ondrej-kvasnovsky.blogspot.com/2015/10/java-8-update-60-is-causing-apps-that.html > > In short, the issue is that we are not able to release Java app into app > store since 1.8_60 because it uses private API (see the link above if > you want to know how to verify that). > > I spoke about this issue with Martijn Verburg and he pointed me to these > two issues: > https://bugs.openjdk.java.net/browse/JDK-8138650 - fixed for 8u72 > https://bugs.openjdk.java.net/browse/JDK-8138652 - permanent fix for 9 > (replace private libs with public ones) > > I have downloaded that jdk1.8.0_72 b05 JDK and run (downloaded from > https://jdk8.java.net/download.html): > otool -L > /Library/Java/JavaVirtualMachines/jdk1.8.0_72.jdk/Contents/Home/jre/lib/libjfxwebkit.dylib > | grep icu > /usr/lib/libicucore.A.dylib (compatibility version 1.0.0, current > version 51.1.0) > And it the issue is still there, Build b05 still references private API. > > I could even try to build and app and try to publish it for code review > by Apple... but since there is this reference, I do not believe it is > going to be successful. > > Since this issue https://bugs.openjdk.java.net/browse/JDK-8138650 is > considered to be fixed, but it seems it is not, could someone help with > that? > > > Best wishes, > Ondrej Kvasnovsky -- Best regards, Sergey. From kevin.rushforth at oracle.com Tue Nov 17 17:31:42 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 17 Nov 2015 09:31:42 -0800 Subject: Java 8 updates are causing "Apps that use non-public APIs will be rejected" In-Reply-To: <564B61C0.9010809@oracle.com> References: <564B61C0.9010809@oracle.com> Message-ID: <564B647E.8090508@oracle.com> [taking awt-dev off of this thread] The fix that was put into 8u72-b02 is that the packager will no longer include libjfxwebkit.dylib in the packaged app. Is this not working correctly? -- Kevin Sergey Bylokhov wrote: > I think openjfx-dev at openjdk.java.net (cc) is correct place to ask this > question. > > On 16.11.15 23:10, Ond?ej Kvasnovsk? wrote: >> Hi, >> >> We are facing to an issue with latest Java updates when we try to >> release apps into Apple app store. I have described the issue here, with >> all my findings: >> http://ondrej-kvasnovsky.blogspot.com/2015/10/java-8-update-60-is-causing-apps-that.html >> >> >> In short, the issue is that we are not able to release Java app into app >> store since 1.8_60 because it uses private API (see the link above if >> you want to know how to verify that). >> >> I spoke about this issue with Martijn Verburg and he pointed me to these >> two issues: >> https://bugs.openjdk.java.net/browse/JDK-8138650 - fixed for 8u72 >> https://bugs.openjdk.java.net/browse/JDK-8138652 - permanent fix for 9 >> (replace private libs with public ones) >> >> I have downloaded that jdk1.8.0_72 b05 JDK and run (downloaded from >> https://jdk8.java.net/download.html): >> otool -L >> /Library/Java/JavaVirtualMachines/jdk1.8.0_72.jdk/Contents/Home/jre/lib/libjfxwebkit.dylib >> >> | grep icu >> /usr/lib/libicucore.A.dylib (compatibility version 1.0.0, current >> version 51.1.0) >> And it the issue is still there, Build b05 still references private API. >> >> I could even try to build and app and try to publish it for code review >> by Apple... but since there is this reference, I do not believe it is >> going to be successful. >> >> Since this issue https://bugs.openjdk.java.net/browse/JDK-8138650 is >> considered to be fixed, but it seems it is not, could someone help with >> that? >> >> >> Best wishes, >> Ondrej Kvasnovsky > > From chris.bensen at oracle.com Tue Nov 17 17:37:20 2015 From: chris.bensen at oracle.com (Chris Bensen) Date: Tue, 17 Nov 2015 09:37:20 -0800 Subject: Java 8 updates are causing "Apps that use non-public APIs will be rejected" In-Reply-To: <564B647E.8090508@oracle.com> References: <564B61C0.9010809@oracle.com> <564B647E.8090508@oracle.com> Message-ID: There have been cases where Apple received the updated delivery and didn?t test the updated bits or sent the old rejection letter for some reason. I?m not exactly sure what it took and I?m not 100% sure this is the case but it required Apple to examine the new upload. I have an app that I?m about to go through the AppStore process. I will publish my findings. Chris > On Nov 17, 2015, at 9:31 AM, Kevin Rushforth wrote: > > [taking awt-dev off of this thread] > > The fix that was put into 8u72-b02 is that the packager will no longer include libjfxwebkit.dylib in the packaged app. Is this not working correctly? > > -- Kevin > > > Sergey Bylokhov wrote: >> I think openjfx-dev at openjdk.java.net (cc) is correct place to ask this question. >> >> On 16.11.15 23:10, Ond?ej Kvasnovsk? wrote: >>> Hi, >>> >>> We are facing to an issue with latest Java updates when we try to >>> release apps into Apple app store. I have described the issue here, with >>> all my findings: >>> http://ondrej-kvasnovsky.blogspot.com/2015/10/java-8-update-60-is-causing-apps-that.html >>> >>> In short, the issue is that we are not able to release Java app into app >>> store since 1.8_60 because it uses private API (see the link above if >>> you want to know how to verify that). >>> >>> I spoke about this issue with Martijn Verburg and he pointed me to these >>> two issues: >>> https://bugs.openjdk.java.net/browse/JDK-8138650 - fixed for 8u72 >>> https://bugs.openjdk.java.net/browse/JDK-8138652 - permanent fix for 9 >>> (replace private libs with public ones) >>> >>> I have downloaded that jdk1.8.0_72 b05 JDK and run (downloaded from >>> https://jdk8.java.net/download.html): >>> otool -L >>> /Library/Java/JavaVirtualMachines/jdk1.8.0_72.jdk/Contents/Home/jre/lib/libjfxwebkit.dylib >>> | grep icu >>> /usr/lib/libicucore.A.dylib (compatibility version 1.0.0, current >>> version 51.1.0) >>> And it the issue is still there, Build b05 still references private API. >>> >>> I could even try to build and app and try to publish it for code review >>> by Apple... but since there is this reference, I do not believe it is >>> going to be successful. >>> >>> Since this issue https://bugs.openjdk.java.net/browse/JDK-8138650 is >>> considered to be fixed, but it seems it is not, could someone help with >>> that? >>> >>> >>> Best wishes, >>> Ondrej Kvasnovsky >> >> From mp at jugs.org Tue Nov 17 18:50:19 2015 From: mp at jugs.org (Dr. Michael Paus) Date: Tue, 17 Nov 2015 19:50:19 +0100 Subject: Java 8 updates are causing "Apps that use non-public APIs will be rejected" In-Reply-To: <564B647E.8090508@oracle.com> References: <564B61C0.9010809@oracle.com> <564B647E.8090508@oracle.com> Message-ID: <564B76EB.3070805@jugs.org> Just in order to better understand this issue and the fix. Does this mean that the packager will now ALWAYS delete the libjfxwebkit.dylib when building a DMG file? That would mean that I could not bundle and distribute any application anymore for the Mac which uses a WebView. Have you considered the fact that many people do bundle their apps but have their own distribution channels and do not upload the apps to the Apple store. There should at least be some switch to override this behavior. Just my 2+1/2 cents. Michael Am 17.11.15 um 18:31 schrieb Kevin Rushforth: > [taking awt-dev off of this thread] > > The fix that was put into 8u72-b02 is that the packager will no longer > include libjfxwebkit.dylib in the packaged app. Is this not working > correctly? > > -- Kevin > > > Sergey Bylokhov wrote: >> I think openjfx-dev at openjdk.java.net (cc) is correct place to ask >> this question. >> >> On 16.11.15 23:10, Ond?ej Kvasnovsk? wrote: >>> Hi, >>> >>> We are facing to an issue with latest Java updates when we try to >>> release apps into Apple app store. I have described the issue here, >>> with >>> all my findings: >>> http://ondrej-kvasnovsky.blogspot.com/2015/10/java-8-update-60-is-causing-apps-that.html >>> >>> >>> In short, the issue is that we are not able to release Java app into >>> app >>> store since 1.8_60 because it uses private API (see the link above if >>> you want to know how to verify that). >>> >>> I spoke about this issue with Martijn Verburg and he pointed me to >>> these >>> two issues: >>> https://bugs.openjdk.java.net/browse/JDK-8138650 - fixed for 8u72 >>> https://bugs.openjdk.java.net/browse/JDK-8138652 - permanent fix for 9 >>> (replace private libs with public ones) >>> >>> I have downloaded that jdk1.8.0_72 b05 JDK and run (downloaded from >>> https://jdk8.java.net/download.html): >>> otool -L >>> /Library/Java/JavaVirtualMachines/jdk1.8.0_72.jdk/Contents/Home/jre/lib/libjfxwebkit.dylib >>> >>> | grep icu >>> /usr/lib/libicucore.A.dylib (compatibility version 1.0.0, current >>> version 51.1.0) >>> And it the issue is still there, Build b05 still references private >>> API. >>> >>> I could even try to build and app and try to publish it for code review >>> by Apple... but since there is this reference, I do not believe it is >>> going to be successful. >>> >>> Since this issue https://bugs.openjdk.java.net/browse/JDK-8138650 is >>> considered to be fixed, but it seems it is not, could someone help with >>> that? >>> >>> >>> Best wishes, >>> Ondrej Kvasnovsky >> >> From kevin.rushforth at oracle.com Tue Nov 17 18:57:16 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 17 Nov 2015 10:57:16 -0800 Subject: HEADS-UP: switching to gradle 2.8 for FX 9 builds Message-ID: <564B788C.504@oracle.com> As a heads-up, we will be switching FX 9 production builds to using gradle 2.8 for building in the near future. See: https://bugs.openjdk.java.net/browse/JDK-8090171 Very soon -- later this week if all goes well -- we will "flip the switch" to make 2.8 the default for building the FX jake bits (for Jigsaw). Not too long after that we will make 2.8 the default for 9-dev. Here is a rough timeline that we are considering: 11/20 - switch 9-jake nightly builds to gradle 2.8 12/4 - switch 9-dev nightly builds to gradle 2.8 12/7 - switch 9 master builds to gradle 2.8 12/11 - push change to make 2.8 the minimum supported version All developers will need to upgrade to gradle 2.8 before the 12/11 date. Note that you don't need to wait that long. I've been using gradle 2.8 for over a week on all of my machines (and earlier gradle 2.X versions for longer). Note that FX 8u will continue to build with gradle 1.8, although it is buildable with gradle 2.X for developers. -- Kevin From kevin.rushforth at oracle.com Tue Nov 17 19:00:14 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 17 Nov 2015 11:00:14 -0800 Subject: Java 8 updates are causing "Apps that use non-public APIs will be rejected" In-Reply-To: <564B76EB.3070805@jugs.org> References: <564B61C0.9010809@oracle.com> <564B647E.8090508@oracle.com> <564B76EB.3070805@jugs.org> Message-ID: <564B793E.1090501@oracle.com> Yes, this is correct. We consider this only a short term workaround for the problem. A longer term solution will be needed that will allow distributing WebView applications. Chris: is there a way to override this behavior? -- Kevin Dr. Michael Paus wrote: > Just in order to better understand this issue and the fix. Does this > mean that the packager > will now ALWAYS delete the libjfxwebkit.dylib when building a DMG > file? That would mean > that I could not bundle and distribute any application anymore for the > Mac which uses > a WebView. Have you considered the fact that many people do bundle > their apps but > have their own distribution channels and do not upload the apps to the > Apple store. > There should at least be some switch to override this behavior. > Just my 2+1/2 cents. > Michael > > > > > Am 17.11.15 um 18:31 schrieb Kevin Rushforth: >> [taking awt-dev off of this thread] >> >> The fix that was put into 8u72-b02 is that the packager will no >> longer include libjfxwebkit.dylib in the packaged app. Is this not >> working correctly? >> >> -- Kevin >> >> >> Sergey Bylokhov wrote: >>> I think openjfx-dev at openjdk.java.net (cc) is correct place to ask >>> this question. >>> >>> On 16.11.15 23:10, Ond?ej Kvasnovsk? wrote: >>>> Hi, >>>> >>>> We are facing to an issue with latest Java updates when we try to >>>> release apps into Apple app store. I have described the issue here, >>>> with >>>> all my findings: >>>> http://ondrej-kvasnovsky.blogspot.com/2015/10/java-8-update-60-is-causing-apps-that.html >>>> >>>> >>>> In short, the issue is that we are not able to release Java app >>>> into app >>>> store since 1.8_60 because it uses private API (see the link above if >>>> you want to know how to verify that). >>>> >>>> I spoke about this issue with Martijn Verburg and he pointed me to >>>> these >>>> two issues: >>>> https://bugs.openjdk.java.net/browse/JDK-8138650 - fixed for 8u72 >>>> https://bugs.openjdk.java.net/browse/JDK-8138652 - permanent fix for 9 >>>> (replace private libs with public ones) >>>> >>>> I have downloaded that jdk1.8.0_72 b05 JDK and run (downloaded from >>>> https://jdk8.java.net/download.html): >>>> otool -L >>>> /Library/Java/JavaVirtualMachines/jdk1.8.0_72.jdk/Contents/Home/jre/lib/libjfxwebkit.dylib >>>> >>>> | grep icu >>>> /usr/lib/libicucore.A.dylib (compatibility version 1.0.0, current >>>> version 51.1.0) >>>> And it the issue is still there, Build b05 still references private >>>> API. >>>> >>>> I could even try to build and app and try to publish it for code >>>> review >>>> by Apple... but since there is this reference, I do not believe it is >>>> going to be successful. >>>> >>>> Since this issue https://bugs.openjdk.java.net/browse/JDK-8138650 is >>>> considered to be fixed, but it seems it is not, could someone help >>>> with >>>> that? >>>> >>>> >>>> Best wishes, >>>> Ondrej Kvasnovsky >>> >>> > From kevin.rushforth at oracle.com Tue Nov 17 19:24:17 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 17 Nov 2015 11:24:17 -0800 Subject: HEADS-UP: switching to gradle 2.8 for FX 9 builds In-Reply-To: <564B788C.504@oracle.com> References: <564B788C.504@oracle.com> Message-ID: <564B7EE1.4020401@oracle.com> And of course right after I sent this out, I see that gradle 2.9 was released today. If testing looks good, we might switch to 2.9 instead. -- Kevin Kevin Rushforth wrote: > As a heads-up, we will be switching FX 9 production builds to using > gradle 2.8 for building in the near future. See: > > https://bugs.openjdk.java.net/browse/JDK-8090171 > > Very soon -- later this week if all goes well -- we will "flip the > switch" to make 2.8 the default for building the FX jake bits (for > Jigsaw). Not too long after that we will make 2.8 the default for 9-dev. > > Here is a rough timeline that we are considering: > > 11/20 - switch 9-jake nightly builds to gradle 2.8 > 12/4 - switch 9-dev nightly builds to gradle 2.8 > 12/7 - switch 9 master builds to gradle 2.8 > 12/11 - push change to make 2.8 the minimum supported version > > All developers will need to upgrade to gradle 2.8 before the 12/11 > date. Note that you don't need to wait that long. I've been using > gradle 2.8 for over a week on all of my machines (and earlier gradle > 2.X versions for longer). > > Note that FX 8u will continue to build with gradle 1.8, although it is > buildable with gradle 2.X for developers. > > -- Kevin > From chris.bensen at oracle.com Tue Nov 17 19:24:52 2015 From: chris.bensen at oracle.com (Chris Bensen) Date: Tue, 17 Nov 2015 11:24:52 -0800 Subject: Java 8 updates are causing "Apps that use non-public APIs will be rejected" In-Reply-To: <564B793E.1090501@oracle.com> References: <564B61C0.9010809@oracle.com> <564B647E.8090508@oracle.com> <564B76EB.3070805@jugs.org> <564B793E.1090501@oracle.com> Message-ID: <8BA68164-DC22-42D5-967B-C50C87862B0B@oracle.com> The change is only for the Mac App Store. You can easily look at the changeset associated with JDK-8138650 to verify this: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/761213753af4 This is the relevant code change: +++ b/modules/fxpackager/src/main/java/com/oracle/tools/packager/mac/MacAppStoreBundler.java Fri Oct 02 15:33:14 2015 -0600 @@ -290,13 +290,33 @@ I18N.getString("error.non-existent-runtime.advice"))); } - if (new File(baseDir, "Contents/Home/lib/libjfxmedia_qtkit.dylib").exists() - || new File(baseDir, "Contents/Home/jre/lib/libjfxmedia_qtkit.dylib").exists()) - { + int majorVersion; + int updateVersion; + + try { + majorVersion = Integer.parseInt(params.get(".runtime.version.major").toString()); + updateVersion = Integer.parseInt(params.get(".runtime.version.update").toString()); + } catch (Exception e) { + // assume the worst + majorVersion = 8; + updateVersion = 60; + } + + // Quicktime + // before 8u40 it was all of media + // after 8u40 QTKit dependencies are isolated in it's own library + if (majorVersion == 8 && updateVersion >= 40) { rules.add(JreUtils.Rule.suffixNeg("/lib/libjfxmedia_qtkit.dylib")); } else { rules.add(JreUtils.Rule.suffixNeg("/lib/libjfxmedia.dylib")); } + + // webkit + // 8u60 webkit started using an API Apple didn't like + if (majorVersion == 8 && updateVersion >= 60) { + rules.add(JreUtils.Rule.suffixNeg("/lib/libjfxwebkit.dylib")); + } + return rules.toArray(new JreUtils.Rule[rules.size()]); } Chris > On Nov 17, 2015, at 11:00 AM, Kevin Rushforth wrote: > > Yes, this is correct. We consider this only a short term workaround for the problem. A longer term solution will be needed that will allow distributing WebView applications. > > Chris: is there a way to override this behavior? > > -- Kevin > > > Dr. Michael Paus wrote: >> Just in order to better understand this issue and the fix. Does this mean that the packager >> will now ALWAYS delete the libjfxwebkit.dylib when building a DMG file? That would mean >> that I could not bundle and distribute any application anymore for the Mac which uses >> a WebView. Have you considered the fact that many people do bundle their apps but >> have their own distribution channels and do not upload the apps to the Apple store. >> There should at least be some switch to override this behavior. >> Just my 2+1/2 cents. >> Michael >> >> >> >> >> Am 17.11.15 um 18:31 schrieb Kevin Rushforth: >>> [taking awt-dev off of this thread] >>> >>> The fix that was put into 8u72-b02 is that the packager will no longer include libjfxwebkit.dylib in the packaged app. Is this not working correctly? >>> >>> -- Kevin >>> >>> >>> Sergey Bylokhov wrote: >>>> I think openjfx-dev at openjdk.java.net (cc) is correct place to ask this question. >>>> >>>> On 16.11.15 23:10, Ond?ej Kvasnovsk? wrote: >>>>> Hi, >>>>> >>>>> We are facing to an issue with latest Java updates when we try to >>>>> release apps into Apple app store. I have described the issue here, with >>>>> all my findings: >>>>> http://ondrej-kvasnovsky.blogspot.com/2015/10/java-8-update-60-is-causing-apps-that.html >>>>> >>>>> In short, the issue is that we are not able to release Java app into app >>>>> store since 1.8_60 because it uses private API (see the link above if >>>>> you want to know how to verify that). >>>>> >>>>> I spoke about this issue with Martijn Verburg and he pointed me to these >>>>> two issues: >>>>> https://bugs.openjdk.java.net/browse/JDK-8138650 - fixed for 8u72 >>>>> https://bugs.openjdk.java.net/browse/JDK-8138652 - permanent fix for 9 >>>>> (replace private libs with public ones) >>>>> >>>>> I have downloaded that jdk1.8.0_72 b05 JDK and run (downloaded from >>>>> https://jdk8.java.net/download.html): >>>>> otool -L >>>>> /Library/Java/JavaVirtualMachines/jdk1.8.0_72.jdk/Contents/Home/jre/lib/libjfxwebkit.dylib >>>>> | grep icu >>>>> /usr/lib/libicucore.A.dylib (compatibility version 1.0.0, current >>>>> version 51.1.0) >>>>> And it the issue is still there, Build b05 still references private API. >>>>> >>>>> I could even try to build and app and try to publish it for code review >>>>> by Apple... but since there is this reference, I do not believe it is >>>>> going to be successful. >>>>> >>>>> Since this issue https://bugs.openjdk.java.net/browse/JDK-8138650 is >>>>> considered to be fixed, but it seems it is not, could someone help with >>>>> that? >>>>> >>>>> >>>>> Best wishes, >>>>> Ondrej Kvasnovsky >>>> >>>> >> From jonathan.giles at oracle.com Tue Nov 17 19:35:43 2015 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Wed, 18 Nov 2015 08:35:43 +1300 Subject: Bug when combining ListView and SortedList? In-Reply-To: <20151117135514.Horde.lvVg5UtdoBlJ7OKNfAgA5g1@webmail.df.eu> References: <025E25CA98F8AE46BE306AB33F6A38D5012769BB@ADEFUE01SMS003.cznet.zeiss.org> <025E25CA98F8AE46BE306AB33F6A38D501276A01@ADEFUE01SMS003.cznet.zeiss.org> <20151116130600.Horde.2gRfI1CJG6fAX4sc7i4p3w1@webmail.df.eu> <564A3442.1080708@oracle.com> <20151117135514.Horde.lvVg5UtdoBlJ7OKNfAgA5g1@webmail.df.eu> Message-ID: <564B818F.2070107@oracle.com> If there are any that I've missed or that you think are higher priority, leave a comment in the jira issue or email me the issue IDs. -- Jonathan On 18/11/15 1:55 AM, fastegal at swingempire.de wrote: > > Jonathan, > > thanks for the clarification, I indeed misunderstood the new tag. > > On the other hand: not all (related) selection issues are tagged as such, > are those in danger of not being fixed for 9? > > Anyway, all of them _could_ be fixed in one stroke by throwing away > the evil MultipleSelectionModelBase, particularly its usage of > ReadOnlyUnbackedObservableList which forces those ominous manual > change notifications (which are not trivial to get right). > > Instead, implement a bitset-backed observableList with the available > (since 8, very sound in my experience) collections infrastructure > that does all the heavy lifting plus a coupled (kind-of transformed) > items list. You know where to find a POC replacement :-) > > CU > Jeanette > > > From danno.ferrin at oracle.com Tue Nov 17 19:54:55 2015 From: danno.ferrin at oracle.com (Danno Ferrin) Date: Tue, 17 Nov 2015 12:54:55 -0700 Subject: Java 8 updates are causing "Apps that use non-public APIs will be rejected" In-Reply-To: <564B76EB.3070805@jugs.org> References: <564B61C0.9010809@oracle.com> <564B647E.8090508@oracle.com> <564B76EB.3070805@jugs.org> Message-ID: <10870CA3-BFCA-4B57-A645-C49C7A76BB60@oracle.com> Not for a DMG file, just .pkgs that are intended for the app store. So .app, .dmg, and normal .pkgs will have unaltered jres. The Mac App Store .pkgs will be made to conform to mac app store standards. > On Nov 17, 2015, at 11:50 AM, Dr. Michael Paus wrote: > > Just in order to better understand this issue and the fix. Does this mean that the packager > will now ALWAYS delete the libjfxwebkit.dylib when building a DMG file? That would mean > that I could not bundle and distribute any application anymore for the Mac which uses > a WebView. Have you considered the fact that many people do bundle their apps but > have their own distribution channels and do not upload the apps to the Apple store. > There should at least be some switch to override this behavior. > Just my 2+1/2 cents. > Michael > > > > > Am 17.11.15 um 18:31 schrieb Kevin Rushforth: >> [taking awt-dev off of this thread] >> >> The fix that was put into 8u72-b02 is that the packager will no longer include libjfxwebkit.dylib in the packaged app. Is this not working correctly? >> >> -- Kevin >> >> >> Sergey Bylokhov wrote: >>> I think openjfx-dev at openjdk.java.net (cc) is correct place to ask this question. >>> >>> On 16.11.15 23:10, Ond?ej Kvasnovsk? wrote: >>>> Hi, >>>> >>>> We are facing to an issue with latest Java updates when we try to >>>> release apps into Apple app store. I have described the issue here, with >>>> all my findings: >>>> http://ondrej-kvasnovsky.blogspot.com/2015/10/java-8-update-60-is-causing-apps-that.html >>>> >>>> In short, the issue is that we are not able to release Java app into app >>>> store since 1.8_60 because it uses private API (see the link above if >>>> you want to know how to verify that). >>>> >>>> I spoke about this issue with Martijn Verburg and he pointed me to these >>>> two issues: >>>> https://bugs.openjdk.java.net/browse/JDK-8138650 - fixed for 8u72 >>>> https://bugs.openjdk.java.net/browse/JDK-8138652 - permanent fix for 9 >>>> (replace private libs with public ones) >>>> >>>> I have downloaded that jdk1.8.0_72 b05 JDK and run (downloaded from >>>> https://jdk8.java.net/download.html): >>>> otool -L >>>> /Library/Java/JavaVirtualMachines/jdk1.8.0_72.jdk/Contents/Home/jre/lib/libjfxwebkit.dylib >>>> | grep icu >>>> /usr/lib/libicucore.A.dylib (compatibility version 1.0.0, current >>>> version 51.1.0) >>>> And it the issue is still there, Build b05 still references private API. >>>> >>>> I could even try to build and app and try to publish it for code review >>>> by Apple... but since there is this reference, I do not believe it is >>>> going to be successful. >>>> >>>> Since this issue https://bugs.openjdk.java.net/browse/JDK-8138650 is >>>> considered to be fixed, but it seems it is not, could someone help with >>>> that? >>>> >>>> >>>> Best wishes, >>>> Ondrej Kvasnovsky >>> >>> > From johan.vos at gluonhq.com Tue Nov 17 19:59:39 2015 From: johan.vos at gluonhq.com (Johan Vos) Date: Tue, 17 Nov 2015 20:59:39 +0100 Subject: pisces, produceFillAlphas In-Reply-To: References: <561FF83E.3000407@oracle.com> <5620261F.7060206@oracle.com> Message-ID: This is an ongoing effort. Performance is #1 on my list, but it is also a very complex issue. I will inform this list on relevant progress I make. It is impossible to say how much time I need for this, but in the end, I'll get there (and only then I will be able to tell how much time it took). - Johan On Tue, Nov 17, 2015 at 11:56 AM, Felix Bembrick wrote: > Hi Johan, > > Have you been able to find enough time to be able to answer this question? > In my present situation, clarity on these issues is extremely important to > me and I would guess to many others as well. > > Thanks, > > Felix > > > On 18 Oct 2015, at 19:01, Felix Bembrick > wrote: > > > > Hi Johan, > > > > If you have been getting acceptable but not stunning performance on > Android and all this time hardware acceleration was not being utilised then > it sounds like there is some serious room for some dramatic performance > increases. > > > > Not being that familiar with the finer points of how JavaFX is > implemented on Android, just how much work is involved in accessing that > hardware acceleration? Any timeline? > > > > I expect that implementing this significant change could be a > make-or-break factor in determining whether JavaFX is truly viable and > successful on Android. > > > > Good luck Johan! > > > > Cheers, > > > > Felix > > > >> On 17 Oct 2015, at 19:49, Johan Vos wrote: > >> > >> As a follow-up on the second part: after about 2 years working on > JavaFX on > >> Android, I discovered we are not even using Hardware Acceleration. We > >> create a SurfaceView and render on that, but it turns out SurfaceView is > >> never Hardware Accelerated. The positive thing is that this means there > is > >> even more room for optimization :) > >> > >> - Johan > >> > >>> On Fri, Oct 16, 2015 at 7:55 PM, Johan Vos > wrote: > >>> > >>> Hi, > >>> > >>> Thanks for the suggestions. There are 2 different things: > >>> > >>> 1. It seems indeed there is not much being cached, so there are > definitely > >>> improvements possible. It also require e.g. VirtualFlow to use the > >>> Node.setCache(true) in order to cache. The combination of this with the > >>> prism.scrollcacheopt reduces the rendering calls. I think the only > penalty > >>> is memory, but so far, we didn't run into issues with too high GC > activity. > >>> > >>> 2. Calls to glDrawElements() inside nDrawIndexedQuads take about 100 > times > >>> longer on the Nexus 6 compared to the iPhone 6 (e.g. 100,000ns vs > 1000ns). > >>> I'll have to look into some EGL options. > >>> > >>> - Johan > >>> > >>> > >>> On Fri, Oct 16, 2015 at 12:18 AM, Jim Graham > >>> wrote: > >>> > >>>> Chien pointed out a system property that is currently disabling the > >>>> scrolling optimization. For its implementation look at > CacheFilter.java, > >>>> in particular the invalidateByTranslation() method and all that it > kicks > >>>> off. > >>>> > >>>> Another thing to look at is that we added alpha batching to the code > >>>> which should be batching all of the output of the produceAlphas calls > into > >>>> a texture and then drawing all of the quads together - provided that > they > >>>> are all being filled with simple colors (they can have alpha, but they > >>>> can't be gradients, etc.). This should be managed by the > >>>> BaseContext.updateMaskTexture() method which controls the single batch > >>>> texture. > >>>> > >>>> Again, are there similar number of invocations of the glDrawElements > on > >>>> the 2 platforms? > >>>> > >>>> ...jim > >>>> > >>>>> On 10/15/15 12:30 PM, Johan Vos wrote: > >>>>> > >>>>> Thanks Jim. > >>>>> I tried with different optimization flags, but it doesn't make a big > >>>>> difference. Tracing it down to system calls, somehow the gl > >>>>> implementation seems be be slower (glDrawElements(GL_TRIANGLES, > numQuads > >>>>> * 2 * 3, GL_UNSIGNED_SHORT, 0) takes more time on Android than on > iOS) > >>>>> per invocation. The number of invocations is comparable between iOS > and > >>>>> Android. > >>>>> > >>>>> If you can give me a direction on where to search for the disabled > >>>>> scrolling optimization, I'll try to re-enable that and see how it > >>>>> improves performance. It might be a huge and quick win... > >>>>> > >>>>> Thanks again, > >>>>> > >>>>> - Johan > >>>>> > >>>>> On Thu, Oct 15, 2015 at 9:02 PM, Jim Graham >>>>> > wrote: > >>>>> > >>>>> Perhaps optimization flags with the native compiler? Also, was it > >>>>> called a similar number of times on both? > >>>>> > >>>>> Ideally we'd just be using copyArea for the scrolling, but at one > >>>>> point we disabled the scrolling optimizations on retina MBP because > >>>>> they didn't work with a scale factor and I don't think we reenabled > >>>>> them yet. That would kill scrolling performance on mobile as a > >>>>> result of having to rerender the scene on each scroll regardless of > >>>>> how long produceAlphas takes... > >>>>> > >>>>> ...jim > >>>>> > >>>>> > >>>>> On 10/15/15 4:27 AM, Johan Vos wrote: > >>>>> > >>>>> After spending lots of time optimizing JavaFX on iOS, I am now > >>>>> at the point > >>>>> where scrolling is 10 times faster on iOS than on Android. > >>>>> The scrolling in the iOS version of the Gluon JavaOne mobile > >>>>> schedule > >>>>> builder is pretty good imho. On Android, it is much slower. I > >>>>> profiled and > >>>>> compared both, and it turns out that on Android, we spend lots > >>>>> of time in > >>>>> the native implementation of > >>>>> NativePiscesRasterizer.produceFillAlphas > >>>>> (implemented in native-prism/NativePiscesRasterizer.c) > >>>>> > >>>>> On average, calling this native function on an iPhone 6 takes > >>>>> 40,000ns > >>>>> whereas on a Nexus 6, this takes about 800,000ns. > >>>>> > >>>>> If anyone has a suggestion on how to improve or avoid this, I'm > >>>>> all ears. > >>>>> > >>>>> Thanks, > >>>>> > >>>>> - Johan > >>> > From morris.meyer at oracle.com Tue Nov 17 22:18:56 2015 From: morris.meyer at oracle.com (Morris Meyer) Date: Tue, 17 Nov 2015 17:18:56 -0500 Subject: [9] RFR: 8091485: Ensemble8: Review each sample description, playground, appearance, related docs and links Message-ID: <564BA7D0.2040805@oracle.com> Kevin, Jonathan and Leif, Could you please review my changes for 8091485? The issues that I found are enumerated in the bug description. Thanks much, --morris WEBREV - http://cr.openjdk.java.net/~morris/JDK-8091485.01/ BUG - https://bugs.openjdk.java.net/browse/JDK-8091485 From snfuchs at gmx.de Tue Nov 17 22:57:39 2015 From: snfuchs at gmx.de (Stefan Fuchs) Date: Tue, 17 Nov 2015 23:57:39 +0100 Subject: Java 8 updates are causing "Apps that use non-public APIs will be rejected" In-Reply-To: <564B793E.1090501@oracle.com> References: <564B61C0.9010809@oracle.com> <564B647E.8090508@oracle.com> <564B76EB.3070805@jugs.org> <564B793E.1090501@oracle.com> Message-ID: <564BB0E3.8090008@gmx.de> Hi Kevin, well, removing libjfxwebkit.dylib from dmg files would definitely break our application, as we heavily rely on WebView. Our application is not distributed via Mac App Store, but as a download from our website. I think removing libjfxwebkit.dylib from the dmg should be an opt-in for users, that want to upload their application to the Mac App Store. Stefan > Yes, this is correct. We consider this only a short term workaround > for the problem. A longer term solution will be needed that will allow > distributing WebView applications. > > Chris: is there a way to override this behavior? > > -- Kevin > > > Dr. Michael Paus wrote: >> Just in order to better understand this issue and the fix. Does this >> mean that the packager >> will now ALWAYS delete the libjfxwebkit.dylib when building a DMG >> file? That would mean >> that I could not bundle and distribute any application anymore for >> the Mac which uses >> a WebView. Have you considered the fact that many people do bundle >> their apps but >> have their own distribution channels and do not upload the apps to >> the Apple store. >> There should at least be some switch to override this behavior. >> Just my 2+1/2 cents. >> Michael >> >> >> >> >> Am 17.11.15 um 18:31 schrieb Kevin Rushforth: >>> [taking awt-dev off of this thread] >>> >>> The fix that was put into 8u72-b02 is that the packager will no >>> longer include libjfxwebkit.dylib in the packaged app. Is this not >>> working correctly? >>> >>> -- Kevin >>> >>> >>> Sergey Bylokhov wrote: >>>> I think openjfx-dev at openjdk.java.net (cc) is correct place to ask >>>> this question. >>>> >>>> On 16.11.15 23:10, Ond?ej Kvasnovsk? wrote: >>>>> Hi, >>>>> >>>>> We are facing to an issue with latest Java updates when we try to >>>>> release apps into Apple app store. I have described the issue >>>>> here, with >>>>> all my findings: >>>>> http://ondrej-kvasnovsky.blogspot.com/2015/10/java-8-update-60-is-causing-apps-that.html >>>>> >>>>> >>>>> In short, the issue is that we are not able to release Java app >>>>> into app >>>>> store since 1.8_60 because it uses private API (see the link above if >>>>> you want to know how to verify that). >>>>> >>>>> I spoke about this issue with Martijn Verburg and he pointed me to >>>>> these >>>>> two issues: >>>>> https://bugs.openjdk.java.net/browse/JDK-8138650 - fixed for 8u72 >>>>> https://bugs.openjdk.java.net/browse/JDK-8138652 - permanent fix >>>>> for 9 >>>>> (replace private libs with public ones) >>>>> >>>>> I have downloaded that jdk1.8.0_72 b05 JDK and run (downloaded from >>>>> https://jdk8.java.net/download.html): >>>>> otool -L >>>>> /Library/Java/JavaVirtualMachines/jdk1.8.0_72.jdk/Contents/Home/jre/lib/libjfxwebkit.dylib >>>>> >>>>> | grep icu >>>>> /usr/lib/libicucore.A.dylib (compatibility version 1.0.0, current >>>>> version 51.1.0) >>>>> And it the issue is still there, Build b05 still references >>>>> private API. >>>>> >>>>> I could even try to build and app and try to publish it for code >>>>> review >>>>> by Apple... but since there is this reference, I do not believe it is >>>>> going to be successful. >>>>> >>>>> Since this issue https://bugs.openjdk.java.net/browse/JDK-8138650 is >>>>> considered to be fixed, but it seems it is not, could someone help >>>>> with >>>>> that? >>>>> >>>>> >>>>> Best wishes, >>>>> Ondrej Kvasnovsky >>>> >>>> >> > From danno.ferrin at oracle.com Tue Nov 17 22:59:38 2015 From: danno.ferrin at oracle.com (Danno Ferrin) Date: Tue, 17 Nov 2015 15:59:38 -0700 Subject: Java 8 updates are causing "Apps that use non-public APIs will be rejected" In-Reply-To: <564BB0E3.8090008@gmx.de> References: <564B61C0.9010809@oracle.com> <564B647E.8090508@oracle.com> <564B76EB.3070805@jugs.org> <564B793E.1090501@oracle.com> <564BB0E3.8090008@gmx.de> Message-ID: <793E4FD7-B7AA-46F8-AD7F-A73903678082@oracle.com> We never remove it from a .dmg. Only if it is a .pkg targeting the Mac App Store do we remove it. > On Nov 17, 2015, at 3:57 PM, Stefan Fuchs wrote: > > Hi Kevin, > > well, removing libjfxwebkit.dylib from dmg files would definitely break our application, as we heavily rely on WebView. > Our application is not distributed via Mac App Store, but as a download from our website. > > I think removing libjfxwebkit.dylib from the dmg should be an opt-in for users, that want to upload their application to the Mac App Store. > > Stefan > > >> Yes, this is correct. We consider this only a short term workaround for the problem. A longer term solution will be needed that will allow distributing WebView applications. >> >> Chris: is there a way to override this behavior? >> >> -- Kevin >> >> >> Dr. Michael Paus wrote: >>> Just in order to better understand this issue and the fix. Does this mean that the packager >>> will now ALWAYS delete the libjfxwebkit.dylib when building a DMG file? That would mean >>> that I could not bundle and distribute any application anymore for the Mac which uses >>> a WebView. Have you considered the fact that many people do bundle their apps but >>> have their own distribution channels and do not upload the apps to the Apple store. >>> There should at least be some switch to override this behavior. >>> Just my 2+1/2 cents. >>> Michael >>> >>> >>> >>> >>> Am 17.11.15 um 18:31 schrieb Kevin Rushforth: >>>> [taking awt-dev off of this thread] >>>> >>>> The fix that was put into 8u72-b02 is that the packager will no longer include libjfxwebkit.dylib in the packaged app. Is this not working correctly? >>>> >>>> -- Kevin >>>> >>>> >>>> Sergey Bylokhov wrote: >>>>> I think openjfx-dev at openjdk.java.net (cc) is correct place to ask this question. >>>>> >>>>> On 16.11.15 23:10, Ond?ej Kvasnovsk? wrote: >>>>>> Hi, >>>>>> >>>>>> We are facing to an issue with latest Java updates when we try to >>>>>> release apps into Apple app store. I have described the issue here, with >>>>>> all my findings: >>>>>> http://ondrej-kvasnovsky.blogspot.com/2015/10/java-8-update-60-is-causing-apps-that.html >>>>>> >>>>>> In short, the issue is that we are not able to release Java app into app >>>>>> store since 1.8_60 because it uses private API (see the link above if >>>>>> you want to know how to verify that). >>>>>> >>>>>> I spoke about this issue with Martijn Verburg and he pointed me to these >>>>>> two issues: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8138650 - fixed for 8u72 >>>>>> https://bugs.openjdk.java.net/browse/JDK-8138652 - permanent fix for 9 >>>>>> (replace private libs with public ones) >>>>>> >>>>>> I have downloaded that jdk1.8.0_72 b05 JDK and run (downloaded from >>>>>> https://jdk8.java.net/download.html): >>>>>> otool -L >>>>>> /Library/Java/JavaVirtualMachines/jdk1.8.0_72.jdk/Contents/Home/jre/lib/libjfxwebkit.dylib >>>>>> | grep icu >>>>>> /usr/lib/libicucore.A.dylib (compatibility version 1.0.0, current >>>>>> version 51.1.0) >>>>>> And it the issue is still there, Build b05 still references private API. >>>>>> >>>>>> I could even try to build and app and try to publish it for code review >>>>>> by Apple... but since there is this reference, I do not believe it is >>>>>> going to be successful. >>>>>> >>>>>> Since this issue https://bugs.openjdk.java.net/browse/JDK-8138650 is >>>>>> considered to be fixed, but it seems it is not, could someone help with >>>>>> that? >>>>>> >>>>>> >>>>>> Best wishes, >>>>>> Ondrej Kvasnovsky >>>>> >>>>> >>> >> > From jonathan.giles at oracle.com Tue Nov 17 23:13:06 2015 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Wed, 18 Nov 2015 12:13:06 +1300 Subject: [Review request] 8090865: Please make Toolkit.enterNestedEventLoop and exitNestedEventLoop public API Message-ID: <564BB482.8020002@oracle.com> Hi all, Please review the new API proposal for the ability to enter and exit nested event loops at the URL below. The proposed patch file is attached to the jira issue. https://bugs.openjdk.java.net/browse/JDK-8090865 Thanks, -- Jonathan From jonathan.giles at oracle.com Tue Nov 17 23:13:08 2015 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Wed, 18 Nov 2015 12:13:08 +1300 Subject: [Review request] 8097917: add a pulse listener facility Message-ID: <564BB484.8050503@oracle.com> Hi all, Please review the new API proposal for a pulse listener API on Scene at the URL below. The proposed patch file is attached to the jira issue. https://bugs.openjdk.java.net/browse/JDK-8097917 Thanks, -- Jonathan From mik3hall at gmail.com Wed Nov 18 00:21:40 2015 From: mik3hall at gmail.com (Michael Hall) Date: Tue, 17 Nov 2015 18:21:40 -0600 Subject: Java 8 updates are causing "Apps that use non-public APIs will be rejected" In-Reply-To: <564B647E.8090508@oracle.com> References: <564B61C0.9010809@oracle.com> <564B647E.8090508@oracle.com> Message-ID: <9D2CB679-A23D-4361-BCB5-E0B920BA7741@gmail.com> > On Nov 17, 2015, at 11:31 AM, Kevin Rushforth wrote: > > [taking awt-dev off of this thread] > > The fix that was put into 8u72-b02 is that the packager will no longer include libjfxwebkit.dylib in the packaged app. Is this not working correctly? > I have downloaded that jdk1.8.0_72 b05 JDK and run (downloaded from https://jdk8.java.net/download.html ): > otool -L /Library/Java/JavaVirtualMachines/jdk1.8.0_72.jdk/Contents/Home/jre/lib/libjfxwebkit.dylib | grep icu > /usr/lib/libicucore.A.dylib (compatibility version 1.0.0, current version 51.1.0) > And it the issue is still there, Build b05 still references private API. If I followed this correctly the OP seems to be saying that libfxwebkit.dylib is present in 1.8.0_72 b05? So that fix did not work correctly somehow. Is there any chance the change, which was to remove this(?) was missed or disappeared between b02 and b05? Michael Hall From swpalmer at gmail.com Wed Nov 18 01:34:27 2015 From: swpalmer at gmail.com (Scott Palmer) Date: Tue, 17 Nov 2015 20:34:27 -0500 Subject: Java 8 updates are causing "Apps that use non-public APIs will be rejected" In-Reply-To: <9D2CB679-A23D-4361-BCB5-E0B920BA7741@gmail.com> References: <564B61C0.9010809@oracle.com> <564B647E.8090508@oracle.com> <9D2CB679-A23D-4361-BCB5-E0B920BA7741@gmail.com> Message-ID: <7068B4F1-7255-47F0-8254-9558D191F7A4@gmail.com> > On Nov 17, 2015, at 7:21 PM, Michael Hall wrote: > >> On Nov 17, 2015, at 11:31 AM, Kevin Rushforth wrote: >> >> [taking awt-dev off of this thread] >> >> The fix that was put into 8u72-b02 is that the packager will no longer include libjfxwebkit.dylib in the packaged app. Is this not working correctly? > >> I have downloaded that jdk1.8.0_72 b05 JDK and run (downloaded from https://jdk8.java.net/download.html ): >> otool -L /Library/Java/JavaVirtualMachines/jdk1.8.0_72.jdk/Contents/Home/jre/lib/libjfxwebkit.dylib | grep icu >> /usr/lib/libicucore.A.dylib (compatibility version 1.0.0, current version 51.1.0) >> And it the issue is still there, Build b05 still references private API. > > If I followed this correctly the OP seems to be saying that libfxwebkit.dylib is present in 1.8.0_72 b05? So that fix did not work correctly somehow. > Is there any chance the change, which was to remove this(?) was missed or disappeared between b02 and b05? > > Michael Hall What you?ve copied above shows that libfxwebkit.dylib is present in the JDK. Not that it is present in a JRE bundled in an App Store packaged application. The libfxwebkit.dylib still references the private API. which is why, as Kevin mentioned, that library is removed when packaging for the App Store. A longer term solution is still needed for those the want to use WebKit and still submit apps to the App Store. Scott From chris.nahr at gmail.com Wed Nov 18 12:24:44 2015 From: chris.nahr at gmail.com (Chris Nahr) Date: Wed, 18 Nov 2015 13:24:44 +0100 Subject: Stage.Min/MaxWidth/Height don't scale In-Reply-To: References: Message-ID: <564C6E0C.1050504@gmail.com> On Windows the minimum & maximum size properties of Stage don't scale to the current DPI settings, unlike all other drawing coordinates. The explicit size properties (setWidth/setHeight) do scale but setMinWidth, setMaxWidth, setMinHeight & setMaxHeight were apparently overlooked. Any values passed to them are interpreted as unscaled pixels. Below I've added a short sample program to demonstrate the issue. Minimum size should just cover the drawn rectangle plus margins, and maximum size should be twice as big. But running at 200% DPI the *maximum* size will just cover the rectangle whereas the minimum size will show only a fraction of the rectangle. (I'd file a bug report but my JIRA account didn't transition to the new bug tracking system, probably because I'm not an OpenJDK contributor.) -- Chris import javafx.application.Application; import javafx.scene.Scene; import javafx.scene.layout.StackPane; import javafx.scene.shape.Rectangle; import javafx.stage.Stage; public class StageSizeTest extends Application { @Override public void start(Stage primaryStage) { // draw scene-filling rectangle with margin final int margin = 10, size = 200; Rectangle rect = new Rectangle(margin, margin, size, size); StackPane root = new StackPane(rect); final int sceneSize = size + 2 * margin; Scene scene = new Scene(root, sceneSize, sceneSize); // add extra margin for non-client area final int stageSize = sceneSize + 3 * margin; primaryStage.setMinWidth(stageSize); primaryStage.setMinHeight(stageSize); primaryStage.setMaxWidth(2 * stageSize); primaryStage.setMaxHeight(2 * stageSize); primaryStage.setTitle("Stage Size Test"); primaryStage.setScene(scene); primaryStage.show(); } public static void main(String[] args) { launch(args); } } From tom.schindl at bestsolution.at Wed Nov 18 12:47:35 2015 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Wed, 18 Nov 2015 13:47:35 +0100 Subject: FXCanvas in a Java9 world Message-ID: <564C7367.6090902@bestsolution.at> Hi, This is just a short notice for those who require FXCanvas to integrate their applications in an existing SWT-Application - most notably Eclipse RCP or Eclipse IDE. I've created an defect in the Eclipse Bugtracking System [1] so that you can subscribe to it if you want to follow how this is proceeding. Not sure there's an explicit JBS-Entry already but Kevin might be able to point me towards it. Tom [1]https://bugs.eclipse.org/bugs/show_bug.cgi?id=482428 -- 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 kevin.rushforth at oracle.com Wed Nov 18 13:18:02 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 18 Nov 2015 05:18:02 -0800 Subject: Java 8 updates are causing "Apps that use non-public APIs will be rejected" In-Reply-To: References: Message-ID: <564C7A8A.3040109@oracle.com> [moving this back to the openjfx alias; Bcc awt-dev] The javapackager fix for JDK 8u72 does exactly this when generating .pkg files. So in short, libjfxwebkit.dylib is unchanged for 8u72, but will be excluded when generating an app for the Apple app store. -- Kevin Michael Hall wrote: >> On Nov 16, 2015, at 2:10 PM, Ond?ej Kvasnovsk? >> > wrote: >> >> >> >> I have downloaded that jdk1.8.0_72 b05 JDK and run (downloaded >> from https://jdk8.java.net/download.html): >> otool -L >> /Library/Java/JavaVirtualMachines/jdk1.8.0_72.jdk/Contents/Home/jre/lib/libjfxwebkit.dylib >> | grep icu > > Would a work-around not being implement the current recommended fix > yourself. Move this aside while you package or app and then put it > back. Or a little more extreme, just delete it. > I?m not that familiar with packager yet, do you know this is the jdk > that will be used by it for embedding? > > Michael Hall > > > > From kevin.rushforth at oracle.com Wed Nov 18 13:18:12 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 18 Nov 2015 05:18:12 -0800 Subject: Stage.Min/MaxWidth/Height don't scale In-Reply-To: <564C6E0C.1050504@gmail.com> References: <564C6E0C.1050504@gmail.com> Message-ID: <564C7A94.9040305@oracle.com> Hi Chris, Application developers can file bugs here: http://bugs.java.com/ Thanks. -- Kevin Chris Nahr wrote: > On Windows the minimum & maximum size properties of Stage don't scale > to the current DPI settings, unlike all other drawing coordinates. The > explicit size properties (setWidth/setHeight) do scale but > setMinWidth, setMaxWidth, setMinHeight & setMaxHeight were apparently > overlooked. Any values passed to them are interpreted as unscaled pixels. > > Below I've added a short sample program to demonstrate the issue. > Minimum size should just cover the drawn rectangle plus margins, and > maximum size should be twice as big. But running at 200% DPI the > *maximum* size will just cover the rectangle whereas the minimum size > will show only a fraction of the rectangle. > > (I'd file a bug report but my JIRA account didn't transition to the > new bug tracking system, probably because I'm not an OpenJDK > contributor.) > > -- Chris > > import javafx.application.Application; > import javafx.scene.Scene; > import javafx.scene.layout.StackPane; > import javafx.scene.shape.Rectangle; > import javafx.stage.Stage; > > public class StageSizeTest extends Application { > > @Override > public void start(Stage primaryStage) { > > // draw scene-filling rectangle with margin > final int margin = 10, size = 200; > Rectangle rect = new Rectangle(margin, margin, size, size); > StackPane root = new StackPane(rect); > final int sceneSize = size + 2 * margin; > Scene scene = new Scene(root, sceneSize, sceneSize); > > // add extra margin for non-client area > final int stageSize = sceneSize + 3 * margin; > primaryStage.setMinWidth(stageSize); > primaryStage.setMinHeight(stageSize); > primaryStage.setMaxWidth(2 * stageSize); > primaryStage.setMaxHeight(2 * stageSize); > > primaryStage.setTitle("Stage Size Test"); > primaryStage.setScene(scene); > primaryStage.show(); > } > > public static void main(String[] args) { > launch(args); > } > } From vgrazi at gmail.com Wed Nov 18 13:30:44 2015 From: vgrazi at gmail.com (Victor Grazi) Date: Wed, 18 Nov 2015 08:30:44 -0500 Subject: How to modify this mail list subscription? Message-ID: Does anyone know how to modify this mail list subscription? Thanks Victor From hastebrot at gmail.com Wed Nov 18 13:32:57 2015 From: hastebrot at gmail.com (Benjamin Gudehus) Date: Wed, 18 Nov 2015 14:32:57 +0100 Subject: JavaFX PulseLogger with JFR (Java Flight Recorder) In-Reply-To: References: <56466FBA.9080004@oracle.com> Message-ID: I tried the flight recorder once, but have not much experience with it. The console pulse logger is invaluable! I'd really be able to visualize the phases more, in a way development tools of modern web browsers do. Either a separate application like the flight recorder or a separate stage to show the phases like on the diagrams in the hands one presentation a few years ago about the pulse logger. I use a custom logger to be able to return the render duration to my JUnit tests. I can also display the status of the renderer in the status bar, but this is tricky because changing the status bar of cause triggers new events. The implementation of the pulse logger also needs some cleanup. --Benjamin On Nov 17, 2015 11:55 AM, "Johan Vos" wrote: > I am using -Djavafx.pulseLogger=true often and I'm very happy with this. > > - Johan > > 2015-11-14 0:18 GMT+01:00 Kevin Rushforth : > > > Have any JavaFX developers on the list used JFR (Java Flight Recorder) > > with the JavaFX pulse logger? If so, how useful has it been to you? > > > > Or are most of you (of those who use pulse logger for debugging) getting > > what you need from the PrintLogger, which is enabled by > > "-Djavafx.pulseLogger=true"? > > > > -- Kevin > > > > > From kevin.rushforth at oracle.com Wed Nov 18 13:33:48 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 18 Nov 2015 05:33:48 -0800 Subject: How to modify this mail list subscription? In-Reply-To: References: Message-ID: <564C7E3C.6030102@oracle.com> You can control your subscription here: http://mail.openjdk.java.net/mailman/listinfo/openjfx-dev -- Kevin Victor Grazi wrote: > Does anyone know how to modify this mail list subscription? > Thanks > Victor > From kevin.rushforth at oracle.com Wed Nov 18 13:52:23 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 18 Nov 2015 05:52:23 -0800 Subject: FXCanvas in a Java9 world In-Reply-To: <564C7367.6090902@bestsolution.at> References: <564C7367.6090902@bestsolution.at> Message-ID: <564C8297.50100@oracle.com> The JBS bug is here: https://bugs.openjdk.java.net/browse/JDK-8131888 -- Kevin Tom Schindl wrote: > Hi, > > This is just a short notice for those who require FXCanvas to integrate > their applications in an existing SWT-Application - most notably Eclipse > RCP or Eclipse IDE. > > I've created an defect in the Eclipse Bugtracking System [1] so that you > can subscribe to it if you want to follow how this is proceeding. Not > sure there's an explicit JBS-Entry already but Kevin might be able to > point me towards it. > > Tom > > [1]https://bugs.eclipse.org/bugs/show_bug.cgi?id=482428 > > From mp at jugs.org Wed Nov 18 14:02:37 2015 From: mp at jugs.org (Dr. Michael Paus) Date: Wed, 18 Nov 2015 15:02:37 +0100 Subject: Java 8 updates are causing "Apps that use non-public APIs will be rejected" In-Reply-To: <564C7A8A.3040109@oracle.com> References: <564C7A8A.3040109@oracle.com> Message-ID: <564C84FD.6050307@jugs.org> A lot of the confusion here is probably caused by the fact that I (and obviously others too) did not know about the possibility to distinguish between building for the Apple app store and building a package for self-distribution. Is this distinction made by either creating a DMG for self-distribution or a PKG for the Apple app store or is there even some other switch? I could live with that for the moment but is all this documented somewhere? At least the help function of the javapackager does not even mention the possibility of creating PKG files. Am 18.11.15 um 14:18 schrieb Kevin Rushforth: > [moving this back to the openjfx alias; Bcc awt-dev] > > The javapackager fix for JDK 8u72 does exactly this when generating > .pkg files. So in short, libjfxwebkit.dylib is unchanged for 8u72, but > will be excluded when generating an app for the Apple app store. > > -- Kevin > > > > Michael Hall wrote: >>> On Nov 16, 2015, at 2:10 PM, Ond?ej Kvasnovsk? >>> > >>> wrote: >>> >>> >>> >>> I have downloaded that jdk1.8.0_72 b05 JDK and run (downloaded from >>> https://jdk8.java.net/download.html): >>> otool -L >>> /Library/Java/JavaVirtualMachines/jdk1.8.0_72.jdk/Contents/Home/jre/lib/libjfxwebkit.dylib >>> | grep icu >> >> Would a work-around not being implement the current recommended fix >> yourself. Move this aside while you package or app and then put it >> back. Or a little more extreme, just delete it. >> I?m not that familiar with packager yet, do you know this is the jdk >> that will be used by it for embedding? >> >> Michael Hall >> >> >> >> From johan.vos at gluonhq.com Wed Nov 18 20:45:29 2015 From: johan.vos at gluonhq.com (Johan Vos) Date: Wed, 18 Nov 2015 21:45:29 +0100 Subject: Pausing Quantum Renderer Message-ID: Hi, On Android, a JavaFX Application might transfer control to another app (and become invisible) and enter the foreground later. In that case, the GLSurface we are rendering on becomes invalid. In order to avoid problems and save battery, we want to pause the renderer thread, but this turns out to be more difficult than I expected. When our app transfers control, we get a callback from Android. We intercept this in javafxports, and we set the Screen width/height to 0/0 as we don't want to render on the (invalid) surface while we lost control. When we regain control, we resize the Screen and the app renders again. The reason we set the width/height to 0/0 is because the PresentingPainter will call SceneState.isValid() and this returns false in case getWidth() or getHeight() are 0. However, SceneState extends PresentableState and it overrides the update method. It will call PresentatbleState.update() which will set the viewWidth to the width of the new Screen (hence, 0) , but after that it overwrites the viewWidth with camera.getViewWidth(). The latter still contains the old value. A quick inspection shows that camera.setViewWidth() is called when validate(...) is called on NGDefaultCamera, which is called by ES2Context.updateRenderTarget() which happens during rendering, hence *after* the PresentingPainter checks if the width is 0. So immediately after we set the width of the Screen to 0 (on the FX App Thread), a Pulse happens, and this one still things the screen is the original size. While the pulse is happening, the android system destroys our context, and the rendering fails. Moreover, the EGL system is in a unpredictable state (recreating the surface fails). A very dirty workaround for this is to wait for 1 pulse (with the new pulselistener API this should be possible) before we return from the callback method called by Android when the surface is about to be destroyed. That way, we will have 1 bogus rendering on an existing (but about-to-be-destroyed) surface. But it would be better if there is some way to tell the quantum renderer to immediately stop rendering. Existing pulses are no problem, as the renderLock guarantuees that we set the size to 0 only when no other thread (quantum renderer) has a lock on the renderLock. - Johan From David.Hill at Oracle.com Wed Nov 18 20:58:19 2015 From: David.Hill at Oracle.com (David Hill) Date: Wed, 18 Nov 2015 15:58:19 -0500 Subject: Pausing Quantum Renderer In-Reply-To: References: Message-ID: <564CE66B.3080109@Oracle.com> On 11/18/15, 3:45 PM, Johan Vos wrote: Johan, I think that it would be reasonable to put in something to Quantum that causes the render loop to "pause", and then resume later. I envision this toggle as causing the render loop to skip, rather than tinkering with the pulses. When resume is called, it might be best to treat the world as dirty. Added to Toolkit, this would allow someone like Monocle to make the toggles as is appropriate. If this works for you, perhaps you could prototype it ? regards, Dave > > On Android, a JavaFX Application might transfer control to another app (and > become invisible) and enter the foreground later. In that case, the > GLSurface we are rendering on becomes invalid. In order to avoid problems > and save battery, we want to pause the renderer thread, but this turns out > to be more difficult than I expected. > > When our app transfers control, we get a callback from Android. We > intercept this in javafxports, and we set the Screen width/height to 0/0 as > we don't want to render on the (invalid) surface while we lost control. > When we regain control, we resize the Screen and the app renders again. > > The reason we set the width/height to 0/0 is because the PresentingPainter > will call SceneState.isValid() and this returns false in case getWidth() or > getHeight() are 0. > > However, SceneState extends PresentableState and it overrides the update > method. It will call PresentatbleState.update() which will set the > viewWidth to the width of the new Screen (hence, 0) , but after that it > overwrites the viewWidth with camera.getViewWidth(). The latter still > contains the old value. A quick inspection shows that camera.setViewWidth() > is called when validate(...) is called on NGDefaultCamera, which is called > by ES2Context.updateRenderTarget() which happens during rendering, hence > *after* the PresentingPainter checks if the width is 0. > > So immediately after we set the width of the Screen to 0 (on the FX App > Thread), a Pulse happens, and this one still things the screen is the > original size. While the pulse is happening, the android system destroys > our context, and the rendering fails. Moreover, the EGL system is in a > unpredictable state (recreating the surface fails). > > A very dirty workaround for this is to wait for 1 pulse (with the new > pulselistener API this should be possible) before we return from the > callback method called by Android when the surface is about to be > destroyed. That way, we will have 1 bogus rendering on an existing (but > about-to-be-destroyed) surface. > > But it would be better if there is some way to tell the quantum renderer to > immediately stop rendering. Existing pulses are no problem, as the > renderLock guarantuees that we set the size to 0 only when no other thread > (quantum renderer) has a lock on the renderLock. > > - Johan -- 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 alexander.kouznetsov at oracle.com Thu Nov 19 01:02:12 2015 From: alexander.kouznetsov at oracle.com (Alexander Kouznetsov) Date: Wed, 18 Nov 2015 17:02:12 -0800 Subject: Pausing Quantum Renderer In-Reply-To: References: Message-ID: <564D1F94.4070905@oracle.com> Shouldn't this be an equivalent of minimizing the window? Best regards, Alexander Kouznetsov (408) 276-0387 On 18 ??? 2015 12:45, Johan Vos wrote: > Hi, > > On Android, a JavaFX Application might transfer control to another app (and > become invisible) and enter the foreground later. In that case, the > GLSurface we are rendering on becomes invalid. In order to avoid problems > and save battery, we want to pause the renderer thread, but this turns out > to be more difficult than I expected. > > When our app transfers control, we get a callback from Android. We > intercept this in javafxports, and we set the Screen width/height to 0/0 as > we don't want to render on the (invalid) surface while we lost control. > When we regain control, we resize the Screen and the app renders again. > > The reason we set the width/height to 0/0 is because the PresentingPainter > will call SceneState.isValid() and this returns false in case getWidth() or > getHeight() are 0. > > However, SceneState extends PresentableState and it overrides the update > method. It will call PresentatbleState.update() which will set the > viewWidth to the width of the new Screen (hence, 0) , but after that it > overwrites the viewWidth with camera.getViewWidth(). The latter still > contains the old value. A quick inspection shows that camera.setViewWidth() > is called when validate(...) is called on NGDefaultCamera, which is called > by ES2Context.updateRenderTarget() which happens during rendering, hence > *after* the PresentingPainter checks if the width is 0. > > So immediately after we set the width of the Screen to 0 (on the FX App > Thread), a Pulse happens, and this one still things the screen is the > original size. While the pulse is happening, the android system destroys > our context, and the rendering fails. Moreover, the EGL system is in a > unpredictable state (recreating the surface fails). > > A very dirty workaround for this is to wait for 1 pulse (with the new > pulselistener API this should be possible) before we return from the > callback method called by Android when the surface is about to be > destroyed. That way, we will have 1 bogus rendering on an existing (but > about-to-be-destroyed) surface. > > But it would be better if there is some way to tell the quantum renderer to > immediately stop rendering. Existing pulses are no problem, as the > renderLock guarantuees that we set the size to 0 only when no other thread > (quantum renderer) has a lock on the renderLock. > > - Johan From james.graham at oracle.com Thu Nov 19 01:21:16 2015 From: james.graham at oracle.com (Jim Graham) Date: Wed, 18 Nov 2015 17:21:16 -0800 Subject: Pausing Quantum Renderer In-Reply-To: <564D1F94.4070905@oracle.com> References: <564D1F94.4070905@oracle.com> Message-ID: <564D240C.9000104@oracle.com> And, even if it isn't, shouldn't we have a concept of "you can't draw right now, just go away and we'll tell you when it's available again" built into the Presentable API? You shouldn't have to set the dimensions to 0,0 to mean "I'm not here right now"... ...jim On 11/18/15 5:02 PM, Alexander Kouznetsov wrote: > Shouldn't this be an equivalent of minimizing the window? > > Best regards, > Alexander Kouznetsov > (408) 276-0387 > > On 18 ??? 2015 12:45, Johan Vos wrote: >> Hi, >> >> On Android, a JavaFX Application might transfer control to another app >> (and >> become invisible) and enter the foreground later. In that case, the >> GLSurface we are rendering on becomes invalid. In order to avoid problems >> and save battery, we want to pause the renderer thread, but this turns >> out >> to be more difficult than I expected. >> >> When our app transfers control, we get a callback from Android. We >> intercept this in javafxports, and we set the Screen width/height to >> 0/0 as >> we don't want to render on the (invalid) surface while we lost control. >> When we regain control, we resize the Screen and the app renders again. >> >> The reason we set the width/height to 0/0 is because the >> PresentingPainter >> will call SceneState.isValid() and this returns false in case >> getWidth() or >> getHeight() are 0. >> >> However, SceneState extends PresentableState and it overrides the update >> method. It will call PresentatbleState.update() which will set the >> viewWidth to the width of the new Screen (hence, 0) , but after that it >> overwrites the viewWidth with camera.getViewWidth(). The latter still >> contains the old value. A quick inspection shows that >> camera.setViewWidth() >> is called when validate(...) is called on NGDefaultCamera, which is >> called >> by ES2Context.updateRenderTarget() which happens during rendering, hence >> *after* the PresentingPainter checks if the width is 0. >> >> So immediately after we set the width of the Screen to 0 (on the FX App >> Thread), a Pulse happens, and this one still things the screen is the >> original size. While the pulse is happening, the android system destroys >> our context, and the rendering fails. Moreover, the EGL system is in a >> unpredictable state (recreating the surface fails). >> >> A very dirty workaround for this is to wait for 1 pulse (with the new >> pulselistener API this should be possible) before we return from the >> callback method called by Android when the surface is about to be >> destroyed. That way, we will have 1 bogus rendering on an existing (but >> about-to-be-destroyed) surface. >> >> But it would be better if there is some way to tell the quantum >> renderer to >> immediately stop rendering. Existing pulses are no problem, as the >> renderLock guarantuees that we set the size to 0 only when no other >> thread >> (quantum renderer) has a lock on the renderLock. >> >> - Johan > From dmitry.cherepanov at oracle.com Thu Nov 19 14:14:54 2015 From: dmitry.cherepanov at oracle.com (Dmitry Cherepanov) Date: Thu, 19 Nov 2015 17:14:54 +0300 Subject: [8u-dev] Review request: 8143314: Runtime not respected with INI-configuration while creating native bundle Message-ID: <564DD95E.6060109@oracle.com> Chris, Danno, Please review the following fix: https://bugs.openjdk.java.net/browse/JDK-8143314 http://cr.openjdk.java.net/~dcherepanov/8143314/webrev.0/ Dmitry From David.Hill at Oracle.com Thu Nov 19 14:41:05 2015 From: David.Hill at Oracle.com (David Hill) Date: Thu, 19 Nov 2015 09:41:05 -0500 Subject: Pausing Quantum Renderer In-Reply-To: <564D1F94.4070905@oracle.com> References: <564D1F94.4070905@oracle.com> Message-ID: <564DDF81.8040209@Oracle.com> On 11/18/15, 8:02 PM, Alexander Kouznetsov wrote: > Shouldn't this be an equivalent of minimizing the window? That just might work too, but may not be fast enough, would need to dig around in there to see how quickly it sets state so that the window would not be treated as dirty. If it needs to bubble up to the Stage, then probably not. Part of the issue here is that the native graphic context is lost when you get the notification from the system, and so you want to stop banging on that lost context immediately. As the render lock is probably held at this point, toggling something that says "don't try rendering for a bit" might be the best bet. Dave > > Best regards, > Alexander Kouznetsov > (408) 276-0387 > > On 18 ??? 2015 12:45, Johan Vos wrote: >> Hi, >> >> On Android, a JavaFX Application might transfer control to another app (and >> become invisible) and enter the foreground later. In that case, the >> GLSurface we are rendering on becomes invalid. In order to avoid problems >> and save battery, we want to pause the renderer thread, but this turns out >> to be more difficult than I expected. >> >> When our app transfers control, we get a callback from Android. We >> intercept this in javafxports, and we set the Screen width/height to 0/0 as >> we don't want to render on the (invalid) surface while we lost control. >> When we regain control, we resize the Screen and the app renders again. >> >> The reason we set the width/height to 0/0 is because the PresentingPainter >> will call SceneState.isValid() and this returns false in case getWidth() or >> getHeight() are 0. >> >> However, SceneState extends PresentableState and it overrides the update >> method. It will call PresentatbleState.update() which will set the >> viewWidth to the width of the new Screen (hence, 0) , but after that it >> overwrites the viewWidth with camera.getViewWidth(). The latter still >> contains the old value. A quick inspection shows that camera.setViewWidth() >> is called when validate(...) is called on NGDefaultCamera, which is called >> by ES2Context.updateRenderTarget() which happens during rendering, hence >> *after* the PresentingPainter checks if the width is 0. >> >> So immediately after we set the width of the Screen to 0 (on the FX App >> Thread), a Pulse happens, and this one still things the screen is the >> original size. While the pulse is happening, the android system destroys >> our context, and the rendering fails. Moreover, the EGL system is in a >> unpredictable state (recreating the surface fails). >> >> A very dirty workaround for this is to wait for 1 pulse (with the new >> pulselistener API this should be possible) before we return from the >> callback method called by Android when the surface is about to be >> destroyed. That way, we will have 1 bogus rendering on an existing (but >> about-to-be-destroyed) surface. >> >> But it would be better if there is some way to tell the quantum renderer to >> immediately stop rendering. Existing pulses are no problem, as the >> renderLock guarantuees that we set the size to 0 only when no other thread >> (quantum renderer) has a lock on the renderLock. >> >> - Johan > -- 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 chris.bensen at oracle.com Thu Nov 19 15:10:39 2015 From: chris.bensen at oracle.com (Chris Bensen) Date: Thu, 19 Nov 2015 07:10:39 -0800 Subject: [8u-dev] Review request: 8143314: Runtime not respected with INI-configuration while creating native bundle In-Reply-To: <564DD95E.6060109@oracle.com> References: <564DD95E.6060109@oracle.com> Message-ID: <39284841-96F3-4A4D-B8FB-F959777E0580@oracle.com> +1, but then again, I?m not Danno > On Nov 19, 2015, at 6:14 AM, Dmitry Cherepanov wrote: > > Chris, Danno, > > Please review the following fix: > > https://bugs.openjdk.java.net/browse/JDK-8143314 > http://cr.openjdk.java.net/~dcherepanov/8143314/webrev.0/ > > Dmitry > From kevin.rushforth at oracle.com Thu Nov 19 17:38:13 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 19 Nov 2015 09:38:13 -0800 Subject: HEADS-UP: switching to gradle 2.9 for FX 9 builds In-Reply-To: <564B7EE1.4020401@oracle.com> References: <564B788C.504@oracle.com> <564B7EE1.4020401@oracle.com> Message-ID: <564E0905.8080907@oracle.com> Testing with gradle 2.9 looks good, so: 's/2.8/2.9/' As a heads-up, we will be switching FX 9 production builds to use gradle 2.9 for building in the very near future. See: https://bugs.openjdk.java.net/browse/JDK-8090171 We will "flip the switch" to make 2.9 the default for building the FX jake bits (for Jigsaw) tomorrow. Not too long after that we will make 2.9 the default for 9-dev. Here is a rough timeline that we are planning: 11/20 - switch 9-jake nightly builds to gradle 2.9 12/1 - switch 9-dev nightly builds to gradle 2.9 12/7 - switch 9 master builds to gradle 2.9 (*) 12/14 - push change to make 2.9 the minimum supported version (*) All developers will need to upgrade to gradle 2.9 before the 12/14 date, but you don't need to wait that long. I've been using gradle 2.X successfully on all of my machines for some time now. Note that FX 8u will continue to build with gradle 1.8, although it is buildable with gradle 2.X for developers. (*) There is a possibility (unrelated to this) that we might skip the 9-dev --> 9 master integration for the week of 12/7 which would delay the last two dates by one week; however, developers should not count on having the extra time -- Kevin From swpalmer at gmail.com Thu Nov 19 19:49:36 2015 From: swpalmer at gmail.com (Scott Palmer) Date: Thu, 19 Nov 2015 14:49:36 -0500 Subject: Java 9 Questions Message-ID: I was just looking at the Java 9 EA pages and have a few questions (mostly JavaFX related). - There is a separate download for Java 9 + Jigsaw, but it has a much earlier build number (b86). Is Jigsaw not included with the of the latest (b92) download? - When looking at the Java 9 JEPs I see several that are UI related: - JEP 251: Multi-resolution Images - JEP 258: HarfBuzz Font-Layout Engine - JEP 265: Marlin Graphics Renderer All of these refer to Java2D or AWT. How is JavaFX affected? Is there no common ground for things like multi-resolution images and font layout for example? It is already cumbersome to deal with things like ImageIO because it depends on Java2d images and conversion is required to use JavaFX images. How does Jigsaw help with this? I hope I don?t have to pull in AWT/Swing just to load an image with ImageIO so that I can show it in my JavaFX application. (Too bad images or some base image class could not be made neutral to the UI toolkit being used.) I think there must be at least three different image loading mechanisms in the JDK now. Are there plans to consolidate this? Just curious where things are heading. Thanks, Scott From kevin.rushforth at oracle.com Thu Nov 19 19:56:53 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 19 Nov 2015 11:56:53 -0800 Subject: [9-jake] review request: 8090171: Switch production build of FX to gradle 2.9 Message-ID: <564E2985.6010801@oracle.com> David, Please review the simple change to the version check logic to use 2.9 as the preferred version of gradle (with 1.8 still being the default). https://bugs.openjdk.java.net/browse/JDK-8090171 http://cr.openjdk.java.net/~kcr/8090171/webrev.00/ NOTE: as stated in my "HEADS-UP" e-mail, this will be pushed to sandbox-9-jake first and later to 9-dev -- Kevin From kevin.rushforth at oracle.com Thu Nov 19 20:47:58 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 19 Nov 2015 12:47:58 -0800 Subject: Java 9 Questions In-Reply-To: References: Message-ID: <564E357E.5030104@oracle.com> Answers inline > - There is a separate download for Java 9 + Jigsaw, but it has a much earlier build number (b86). Is Jigsaw not included with the of the latest (b92) download? > Jigsaw builds are built from a separate sandbox forest: JDK: http://hg.openjdk.java.net/jigsaw/jake JavaFX: http://hg.openjdk.java.net/openjfx/sandbox-9-jake/rt Changesets are periodically synced from jdk9-dev to jigsaw/jake (and from openjfx 9-dev to openjfx/sandbox-9-jake). From the tags you can see that it has now been synced up with b92 (this happened earlier this week), so you should expect that to be reflected in the next EA build of Jigsaw. > - When looking at the Java 9 JEPs I see several that are UI related: > - JEP 251: Multi-resolution Images > - JEP 258: HarfBuzz Font-Layout Engine > - JEP 265: Marlin Graphics Renderer > > All of these refer to Java2D or AWT. How is JavaFX affected? Is there no common ground for things like multi-resolution images and font layout for example? > JavaFX is not affected directly, although we will look at pulling the improvements for Marlin into JavaFX if there is enough of a win. We currently don't have multi-resolution image support (but will look at this after we do the Hi-DPI improvements for FX). Harfbuzz is not relevant for FX. > It is already cumbersome to deal with things like ImageIO because it depends on Java2d images and conversion is required to use JavaFX images. How does Jigsaw help with this? I hope I don?t have to pull in AWT/Swing just to load an image with ImageIO so that I can show it in my JavaFX application. (Too bad images or some base image class could not be made neutral to the UI toolkit being used.) > I think there must be at least three different image loading mechanisms in the JDK now. Are there plans to consolidate this? > Sadly, the implementation of ImageIO is very Java2D-centric so without a fair bit of refactoring, there isn't a good waay to share the underlying code. As you know we don't yet have image writers or pluggable image loaders in JavaFX. As for whether jigsaw will help, not really, since all of AWT/Swing/Java2D is in the java.desktop module. > Just curious where things are heading. > We will be looking to plug the remaining gaps that currently require some applications to need to convert to/from BufferedImage and use Java2D. Probably in a 9 update release. -- Kevin Scott Palmer wrote: > I was just looking at the Java 9 EA pages and have a few questions (mostly JavaFX related). > > - There is a separate download for Java 9 + Jigsaw, but it has a much earlier build number (b86). Is Jigsaw not included with the of the latest (b92) download? > > - When looking at the Java 9 JEPs I see several that are UI related: > - JEP 251: Multi-resolution Images > - JEP 258: HarfBuzz Font-Layout Engine > - JEP 265: Marlin Graphics Renderer > > All of these refer to Java2D or AWT. How is JavaFX affected? Is there no common ground for things like multi-resolution images and font layout for example? > > It is already cumbersome to deal with things like ImageIO because it depends on Java2d images and conversion is required to use JavaFX images. How does Jigsaw help with this? I hope I don?t have to pull in AWT/Swing just to load an image with ImageIO so that I can show it in my JavaFX application. (Too bad images or some base image class could not be made neutral to the UI toolkit being used.) > I think there must be at least three different image loading mechanisms in the JDK now. Are there plans to consolidate this? > > Just curious where things are heading. > > Thanks, > > Scott From johan.vos at gluonhq.com Thu Nov 19 21:08:45 2015 From: johan.vos at gluonhq.com (Johan Vos) Date: Thu, 19 Nov 2015 22:08:45 +0100 Subject: Pausing Quantum Renderer In-Reply-To: <564CE66B.3080109@Oracle.com> References: <564CE66B.3080109@Oracle.com> Message-ID: After some experiments, here is my current thinking: Toolkit can have 2 new methods: pauseRenderer() resumeRenderer() When pauseRenderer is called, it should be guaranteed that after this call, no new pulses are fired until resumeRenderer is called. That is not hard, but it is not enough. Before we pause the pulses, the previous pulse probably submitted a renderJob to Prism, executed on the QuantumRenderer ThreadPoolExecutor. That job should run fine, as the next pulse (when we're back) will call GlassScene.waitForRenderingToComplete(). So we have to wait until there are no running or pending tasks in the QuantumRenderer as well. - Johan On Wed, Nov 18, 2015 at 9:58 PM, David Hill wrote: > On 11/18/15, 3:45 PM, Johan Vos wrote: > > Johan, > I think that it would be reasonable to put in something to Quantum > that causes the render loop to "pause", and then resume later. I envision > this toggle as causing the render loop to skip, rather than tinkering with > the pulses. > > When resume is called, it might be best to treat the world as dirty. > > Added to Toolkit, this would allow someone like Monocle to make the > toggles as is appropriate. > > If this works for you, perhaps you could prototype it ? > > regards, > Dave > > > >> On Android, a JavaFX Application might transfer control to another app >> (and >> become invisible) and enter the foreground later. In that case, the >> GLSurface we are rendering on becomes invalid. In order to avoid problems >> and save battery, we want to pause the renderer thread, but this turns out >> to be more difficult than I expected. >> >> When our app transfers control, we get a callback from Android. We >> intercept this in javafxports, and we set the Screen width/height to 0/0 >> as >> we don't want to render on the (invalid) surface while we lost control. >> When we regain control, we resize the Screen and the app renders again. >> >> The reason we set the width/height to 0/0 is because the PresentingPainter >> will call SceneState.isValid() and this returns false in case getWidth() >> or >> getHeight() are 0. >> >> However, SceneState extends PresentableState and it overrides the update >> method. It will call PresentatbleState.update() which will set the >> viewWidth to the width of the new Screen (hence, 0) , but after that it >> overwrites the viewWidth with camera.getViewWidth(). The latter still >> contains the old value. A quick inspection shows that >> camera.setViewWidth() >> is called when validate(...) is called on NGDefaultCamera, which is called >> by ES2Context.updateRenderTarget() which happens during rendering, hence >> *after* the PresentingPainter checks if the width is 0. >> >> So immediately after we set the width of the Screen to 0 (on the FX App >> Thread), a Pulse happens, and this one still things the screen is the >> original size. While the pulse is happening, the android system destroys >> our context, and the rendering fails. Moreover, the EGL system is in a >> unpredictable state (recreating the surface fails). >> >> A very dirty workaround for this is to wait for 1 pulse (with the new >> pulselistener API this should be possible) before we return from the >> callback method called by Android when the surface is about to be >> destroyed. That way, we will have 1 bogus rendering on an existing (but >> about-to-be-destroyed) surface. >> >> But it would be better if there is some way to tell the quantum renderer >> to >> immediately stop rendering. Existing pulses are no problem, as the >> renderLock guarantuees that we set the size to 0 only when no other thread >> (quantum renderer) has a lock on the renderLock. >> >> - Johan >> > > > -- > 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 Thu Nov 19 21:20:30 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 19 Nov 2015 13:20:30 -0800 Subject: Pausing Quantum Renderer In-Reply-To: References: <564CE66B.3080109@Oracle.com> Message-ID: <564E3D1E.5050703@oracle.com> This might be a tricky semantic to achieve, and great care will be needed to ensure no deadlocks or race conditions. Not running any more pulses after this method returns seems fine, but it might be better to let any existing renderJobs run (possibly discarding the results). This way you could send the pause message to the renderer as a special renderJob and not have to worry about jobs that are scheduled but not yet run. -- Kevin Johan Vos wrote: > After some experiments, here is my current thinking: > > Toolkit can have 2 new methods: > pauseRenderer() > resumeRenderer() > > When pauseRenderer is called, it should be guaranteed that after this call, > no new pulses are fired until resumeRenderer is called. > That is not hard, but it is not enough. Before we pause the pulses, the > previous pulse probably submitted a renderJob to Prism, executed on the > QuantumRenderer ThreadPoolExecutor. That job should run fine, as the next > pulse (when we're back) will call GlassScene.waitForRenderingToComplete(). > So we have to wait until there are no running or pending tasks in the > QuantumRenderer as well. > > - Johan > > > On Wed, Nov 18, 2015 at 9:58 PM, David Hill wrote: > > >> On 11/18/15, 3:45 PM, Johan Vos wrote: >> >> Johan, >> I think that it would be reasonable to put in something to Quantum >> that causes the render loop to "pause", and then resume later. I envision >> this toggle as causing the render loop to skip, rather than tinkering with >> the pulses. >> >> When resume is called, it might be best to treat the world as dirty. >> >> Added to Toolkit, this would allow someone like Monocle to make the >> toggles as is appropriate. >> >> If this works for you, perhaps you could prototype it ? >> >> regards, >> Dave >> >> >> >> >>> On Android, a JavaFX Application might transfer control to another app >>> (and >>> become invisible) and enter the foreground later. In that case, the >>> GLSurface we are rendering on becomes invalid. In order to avoid problems >>> and save battery, we want to pause the renderer thread, but this turns out >>> to be more difficult than I expected. >>> >>> When our app transfers control, we get a callback from Android. We >>> intercept this in javafxports, and we set the Screen width/height to 0/0 >>> as >>> we don't want to render on the (invalid) surface while we lost control. >>> When we regain control, we resize the Screen and the app renders again. >>> >>> The reason we set the width/height to 0/0 is because the PresentingPainter >>> will call SceneState.isValid() and this returns false in case getWidth() >>> or >>> getHeight() are 0. >>> >>> However, SceneState extends PresentableState and it overrides the update >>> method. It will call PresentatbleState.update() which will set the >>> viewWidth to the width of the new Screen (hence, 0) , but after that it >>> overwrites the viewWidth with camera.getViewWidth(). The latter still >>> contains the old value. A quick inspection shows that >>> camera.setViewWidth() >>> is called when validate(...) is called on NGDefaultCamera, which is called >>> by ES2Context.updateRenderTarget() which happens during rendering, hence >>> *after* the PresentingPainter checks if the width is 0. >>> >>> So immediately after we set the width of the Screen to 0 (on the FX App >>> Thread), a Pulse happens, and this one still things the screen is the >>> original size. While the pulse is happening, the android system destroys >>> our context, and the rendering fails. Moreover, the EGL system is in a >>> unpredictable state (recreating the surface fails). >>> >>> A very dirty workaround for this is to wait for 1 pulse (with the new >>> pulselistener API this should be possible) before we return from the >>> callback method called by Android when the surface is about to be >>> destroyed. That way, we will have 1 bogus rendering on an existing (but >>> about-to-be-destroyed) surface. >>> >>> But it would be better if there is some way to tell the quantum renderer >>> to >>> immediately stop rendering. Existing pulses are no problem, as the >>> renderLock guarantuees that we set the size to 0 only when no other thread >>> (quantum renderer) has a lock on the renderLock. >>> >>> - Johan >>> >>> >> -- >> 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 philip.race at oracle.com Fri Nov 20 03:23:48 2015 From: philip.race at oracle.com (Philip Race) Date: Thu, 19 Nov 2015 19:23:48 -0800 Subject: Java 9 Questions In-Reply-To: References: Message-ID: <564E9244.2030301@oracle.com> On 11/19/2015 11:49 AM, Scott Palmer wrote: > I was just looking at the Java 9 EA pages and have a few questions (mostly JavaFX related). > > - There is a separate download for Java 9 + Jigsaw, but it has a much earlier build number (b86). Is Jigsaw not included with the of the latest (b92) download? > > - When looking at the Java 9 JEPs I see several that are UI related: > - JEP 251: Multi-resolution Images > - JEP 258: HarfBuzz Font-Layout Engine > - JEP 265: Marlin Graphics Renderer > > All of these refer to Java2D or AWT. How is JavaFX affected? Is there no common ground for things like multi-resolution images and font layout for example? FX already has multi-res image support. But none of these JEPS directly relate to FX. > > It is already cumbersome to deal with things like ImageIO because it depends on Java2d images and conversion is required to use JavaFX images. How does Jigsaw help with this? I hope I don?t have to pull in AWT/Swing just to load an image with ImageIO so that I can show it in my JavaFX application. (Too bad images or some base image class could not be made neutral to the UI toolkit being used.) > I think there must be at least three different image loading mechanisms in the JDK now. Are there plans to consolidate this? jigsaw delivers all of AWT/2D/Swing as one module so won't help you reduce dependence on that if you need Image I/O. It was recognised a while back that JavaFX needs more support in imaging and image format support but it is not for JDK 9. Core SE had 4 image loading mechanisms 1) Toolkit.createImage (jdk 1.0) 2) com.sun.image.codec.jpeg (jdk 1.2 not standard, now retired) 3) Image I/O (1.4) 4) splashscreen (1.6) add FX and there is one more. IJG is at the bottom of all the JPEG support although versions differ. > > Just curious where things are heading. Consolidation is somewhat at odds with the module system here. If FX depends on java.desktop it is nearly impossible to consolidate all these so they can be shared as they are so much intertwined with the rest of the java.desktop module. Leaving aside SE, it is clear that FX needs more imaging support and how it is done should not add gobs of footprint or dependencies. -phil. > Thanks, > > Scott From chris.nahr at gmail.com Fri Nov 20 06:58:14 2015 From: chris.nahr at gmail.com (Chris Nahr) Date: Fri, 20 Nov 2015 07:58:14 +0100 Subject: Stage.Min/MaxWidth/Height don't scale In-Reply-To: References: Message-ID: <564EC486.7010201@gmail.com> Okay, I've submitted a bug report to bugs.java.com where it has been assigned Review ID JI-9026706. -- Chris Kevin Rushforth wrote: > Hi Chris, > > Application developers can file bugs here: > > http://bugs.java.com/ > > Thanks. > > -- Kevin From johan.vos at gluonhq.com Fri Nov 20 07:14:16 2015 From: johan.vos at gluonhq.com (Johan Vos) Date: Fri, 20 Nov 2015 08:14:16 +0100 Subject: Pausing Quantum Renderer In-Reply-To: <564E3D1E.5050703@oracle.com> References: <564CE66B.3080109@Oracle.com> <564E3D1E.5050703@oracle.com> Message-ID: I didn't plan to intercept or cancel pending/submitted jobs, but I have to wait until they are done before the android callback method returns. When Android is about to destroy the context, it will call the surfaceTextureDestroyed method on the Activity (the FXActivity in our case). As long as that method doesn't return, the context won't be destroyed. But once that method returns, the context might become invalid any moment. So if there are still jobs that want to do a swapBuffer after we return, those can crash or (even worse) corrupt the egl system. So it seems to me inside the implementation of surfaceTextureDestroyed, we need to achieve 2 things: 1. make sure no new pulses are generated. 2. don't return while the QuantumRenderer is still executing jobs. Those 2 things can be combined in a single Toolkit.pauseRenderer() but it might be better to only achieve the first task in Toolkit.pauseRenderer(). The contract for this method is than that no new pulses will be generated, but existing renderJobs might still be running when this method returns. The second thing, waiting for the renderJobs to be finished, can be done in the Android specific implementation. - Johan On Thu, Nov 19, 2015 at 10:20 PM, Kevin Rushforth < kevin.rushforth at oracle.com> wrote: > This might be a tricky semantic to achieve, and great care will be needed > to ensure no deadlocks or race conditions. Not running any more pulses > after this method returns seems fine, but it might be better to let any > existing renderJobs run (possibly discarding the results). This way you > could send the pause message to the renderer as a special renderJob and not > have to worry about jobs that are scheduled but not yet run. > > -- Kevin > > > > Johan Vos wrote: > >> After some experiments, here is my current thinking: >> >> Toolkit can have 2 new methods: >> pauseRenderer() >> resumeRenderer() >> >> When pauseRenderer is called, it should be guaranteed that after this >> call, >> no new pulses are fired until resumeRenderer is called. >> That is not hard, but it is not enough. Before we pause the pulses, the >> previous pulse probably submitted a renderJob to Prism, executed on the >> QuantumRenderer ThreadPoolExecutor. That job should run fine, as the next >> pulse (when we're back) will call GlassScene.waitForRenderingToComplete(). >> So we have to wait until there are no running or pending tasks in the >> QuantumRenderer as well. >> >> - Johan >> >> >> On Wed, Nov 18, 2015 at 9:58 PM, David Hill >> wrote: >> >> >> >>> On 11/18/15, 3:45 PM, Johan Vos wrote: >>> >>> Johan, >>> I think that it would be reasonable to put in something to Quantum >>> that causes the render loop to "pause", and then resume later. I envision >>> this toggle as causing the render loop to skip, rather than tinkering >>> with >>> the pulses. >>> >>> When resume is called, it might be best to treat the world as dirty. >>> >>> Added to Toolkit, this would allow someone like Monocle to make the >>> toggles as is appropriate. >>> >>> If this works for you, perhaps you could prototype it ? >>> >>> regards, >>> Dave >>> >>> >>> >>> >>> >>>> On Android, a JavaFX Application might transfer control to another app >>>> (and >>>> become invisible) and enter the foreground later. In that case, the >>>> GLSurface we are rendering on becomes invalid. In order to avoid >>>> problems >>>> and save battery, we want to pause the renderer thread, but this turns >>>> out >>>> to be more difficult than I expected. >>>> >>>> When our app transfers control, we get a callback from Android. We >>>> intercept this in javafxports, and we set the Screen width/height to 0/0 >>>> as >>>> we don't want to render on the (invalid) surface while we lost control. >>>> When we regain control, we resize the Screen and the app renders again. >>>> >>>> The reason we set the width/height to 0/0 is because the >>>> PresentingPainter >>>> will call SceneState.isValid() and this returns false in case getWidth() >>>> or >>>> getHeight() are 0. >>>> >>>> However, SceneState extends PresentableState and it overrides the update >>>> method. It will call PresentatbleState.update() which will set the >>>> viewWidth to the width of the new Screen (hence, 0) , but after that it >>>> overwrites the viewWidth with camera.getViewWidth(). The latter still >>>> contains the old value. A quick inspection shows that >>>> camera.setViewWidth() >>>> is called when validate(...) is called on NGDefaultCamera, which is >>>> called >>>> by ES2Context.updateRenderTarget() which happens during rendering, hence >>>> *after* the PresentingPainter checks if the width is 0. >>>> >>>> So immediately after we set the width of the Screen to 0 (on the FX App >>>> Thread), a Pulse happens, and this one still things the screen is the >>>> original size. While the pulse is happening, the android system destroys >>>> our context, and the rendering fails. Moreover, the EGL system is in a >>>> unpredictable state (recreating the surface fails). >>>> >>>> A very dirty workaround for this is to wait for 1 pulse (with the new >>>> pulselistener API this should be possible) before we return from the >>>> callback method called by Android when the surface is about to be >>>> destroyed. That way, we will have 1 bogus rendering on an existing (but >>>> about-to-be-destroyed) surface. >>>> >>>> But it would be better if there is some way to tell the quantum renderer >>>> to >>>> immediately stop rendering. Existing pulses are no problem, as the >>>> renderLock guarantuees that we set the size to 0 only when no other >>>> thread >>>> (quantum renderer) has a lock on the renderLock. >>>> >>>> - Johan >>>> >>>> >>>> >>> -- >>> 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 vadim.pakhnushev at oracle.com Fri Nov 20 14:30:41 2015 From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev) Date: Fri, 20 Nov 2015 17:30:41 +0300 Subject: In(Sanity) Testing Mondays Message-ID: <564F2E91.2070608@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 PST until 1pm PST. Happy testing! Thanks, Vadim From kevin.rushforth at oracle.com Fri Nov 20 15:16:49 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 20 Nov 2015 07:16:49 -0800 Subject: Stage.Min/MaxWidth/Height don't scale In-Reply-To: <564EC486.7010201@gmail.com> References: <564EC486.7010201@gmail.com> Message-ID: <564F3961.7040207@oracle.com> Thank you. -- Kevin Chris Nahr wrote: > Okay, I've submitted a bug report to bugs.java.com where it has been > assigned Review ID JI-9026706. > > -- Chris > > Kevin Rushforth wrote: >> Hi Chris, >> >> Application developers can file bugs here: >> >> http://bugs.java.com/ >> >> Thanks. >> >> -- Kevin From vadim.pakhnushev at oracle.com Fri Nov 20 17:31:43 2015 From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev) Date: Fri, 20 Nov 2015 20:31:43 +0300 Subject: [9] Review request for 8136535: JavaFX NumberAxis AutoRange Infinite Loop Message-ID: <564F58FF.8050201@oracle.com> Jonathan, Please review the fix: https://bugs.openjdk.java.net/browse/JDK-8136535 http://cr.openjdk.java.net/~vadim/8136535/webrev.00/ Thanks, Vadim From kevin.rushforth at oracle.com Fri Nov 20 23:58:22 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 20 Nov 2015 15:58:22 -0800 Subject: [9] API review request: 8090585: Provide an official API to start the JavaFX platform Message-ID: <564FB39E.4040801@oracle.com> Jonathan and all, Please review the following new API proposal to add the ability to explicitly start the FX runtime. https://bugs.openjdk.java.net/browse/JDK-8090585 http://cr.openjdk.java.net/~kcr/8090585/webrev.00/ -- Kevin From ali.ebrahimi1781 at gmail.com Sat Nov 21 10:57:56 2015 From: ali.ebrahimi1781 at gmail.com (Ali Ebrahimi) Date: Sat, 21 Nov 2015 14:27:56 +0330 Subject: [9] API review request: 8090585: Provide an official API to start the JavaFX platform In-Reply-To: <564FB39E.4040801@oracle.com> References: <564FB39E.4040801@oracle.com> Message-ID: Hi, I think there is an inconsistency between : PlatformImpl.java public static void startup(final Runnable r) { + startup(r, false); //************* here default value false + } and Platform.java + public static void startup(Runnable runnable) { + PlatformImpl.startup(runnable, true); //******** here default value true + } On Sat, Nov 21, 2015 at 3:28 AM, Kevin Rushforth wrote: > Jonathan and all, > > Please review the following new API proposal to add the ability to > explicitly start the FX runtime. > > https://bugs.openjdk.java.net/browse/JDK-8090585 > http://cr.openjdk.java.net/~kcr/8090585/webrev.00/ > > -- Kevin > > -- Best Regards, Ali Ebrahimi From johan.vos at gluonhq.com Sat Nov 21 20:23:05 2015 From: johan.vos at gluonhq.com (Johan Vos) Date: Sat, 21 Nov 2015 21:23:05 +0100 Subject: Pausing Quantum Renderer In-Reply-To: References: <564CE66B.3080109@Oracle.com> <564E3D1E.5050703@oracle.com> Message-ID: I have a working implementation that needs more stress-testing on different platforms, but it seems a good and easy solution so far. I have this on QuantumToolkit: @Override public void pauseRenderer(){ Application.invokeAndWait(() -> this.pause = true); PaintCollector.getInstance().waitForRenderingToComplete(); }; public void resumeRenderer(){ Application.invokeAndWait(() -> this.pause = false); }; pause is a boolean that is checked for in void pulse(boolean collect) { ... } The difficulty I mentioned in my previous mail (how do we know there are no renderJobs pending/running) was solved easily as there exists this PaintCollector.waitForRenderingToComplete method. This might make the pauseRenderer a bit slower, and maybe this is not needed in all usecases. In that case, we can remove it from the pauseRenderer() and we can add it either in the Monocle implementation that will call pauseRenderer, or in a Android/iOS specific code. However, it seems to me that if you want to pause the renderer, you most often want to make sure no one is still writing to the glSurface after the pauseRenderer method is called, so I think it makes sense to keep it there? - Johan On Fri, Nov 20, 2015 at 8:14 AM, Johan Vos wrote: > I didn't plan to intercept or cancel pending/submitted jobs, but I have to > wait until they are done before the android callback method returns. > > When Android is about to destroy the context, it will call the > surfaceTextureDestroyed method on the Activity (the FXActivity in our > case). As long as that method doesn't return, the context won't be > destroyed. But once that method returns, the context might become invalid > any moment. So if there are still jobs that want to do a swapBuffer after > we return, those can crash or (even worse) corrupt the egl system. > > So it seems to me inside the implementation of surfaceTextureDestroyed, we > need to achieve 2 things: > 1. make sure no new pulses are generated. > 2. don't return while the QuantumRenderer is still executing jobs. > > Those 2 things can be combined in a single Toolkit.pauseRenderer() but it > might be better to only achieve the first task in Toolkit.pauseRenderer(). > The contract for this method is than that no new pulses will be generated, > but existing renderJobs might still be running when this method returns. > The second thing, waiting for the renderJobs to be finished, can be done > in the Android specific implementation. > > - Johan > > > > On Thu, Nov 19, 2015 at 10:20 PM, Kevin Rushforth < > kevin.rushforth at oracle.com> wrote: > >> This might be a tricky semantic to achieve, and great care will be needed >> to ensure no deadlocks or race conditions. Not running any more pulses >> after this method returns seems fine, but it might be better to let any >> existing renderJobs run (possibly discarding the results). This way you >> could send the pause message to the renderer as a special renderJob and not >> have to worry about jobs that are scheduled but not yet run. >> >> -- Kevin >> >> >> >> Johan Vos wrote: >> >>> After some experiments, here is my current thinking: >>> >>> Toolkit can have 2 new methods: >>> pauseRenderer() >>> resumeRenderer() >>> >>> When pauseRenderer is called, it should be guaranteed that after this >>> call, >>> no new pulses are fired until resumeRenderer is called. >>> That is not hard, but it is not enough. Before we pause the pulses, the >>> previous pulse probably submitted a renderJob to Prism, executed on the >>> QuantumRenderer ThreadPoolExecutor. That job should run fine, as the next >>> pulse (when we're back) will call >>> GlassScene.waitForRenderingToComplete(). >>> So we have to wait until there are no running or pending tasks in the >>> QuantumRenderer as well. >>> >>> - Johan >>> >>> >>> On Wed, Nov 18, 2015 at 9:58 PM, David Hill >>> wrote: >>> >>> >>> >>>> On 11/18/15, 3:45 PM, Johan Vos wrote: >>>> >>>> Johan, >>>> I think that it would be reasonable to put in something to Quantum >>>> that causes the render loop to "pause", and then resume later. I >>>> envision >>>> this toggle as causing the render loop to skip, rather than tinkering >>>> with >>>> the pulses. >>>> >>>> When resume is called, it might be best to treat the world as dirty. >>>> >>>> Added to Toolkit, this would allow someone like Monocle to make the >>>> toggles as is appropriate. >>>> >>>> If this works for you, perhaps you could prototype it ? >>>> >>>> regards, >>>> Dave >>>> >>>> >>>> >>>> >>>> >>>>> On Android, a JavaFX Application might transfer control to another app >>>>> (and >>>>> become invisible) and enter the foreground later. In that case, the >>>>> GLSurface we are rendering on becomes invalid. In order to avoid >>>>> problems >>>>> and save battery, we want to pause the renderer thread, but this turns >>>>> out >>>>> to be more difficult than I expected. >>>>> >>>>> When our app transfers control, we get a callback from Android. We >>>>> intercept this in javafxports, and we set the Screen width/height to >>>>> 0/0 >>>>> as >>>>> we don't want to render on the (invalid) surface while we lost control. >>>>> When we regain control, we resize the Screen and the app renders again. >>>>> >>>>> The reason we set the width/height to 0/0 is because the >>>>> PresentingPainter >>>>> will call SceneState.isValid() and this returns false in case >>>>> getWidth() >>>>> or >>>>> getHeight() are 0. >>>>> >>>>> However, SceneState extends PresentableState and it overrides the >>>>> update >>>>> method. It will call PresentatbleState.update() which will set the >>>>> viewWidth to the width of the new Screen (hence, 0) , but after that it >>>>> overwrites the viewWidth with camera.getViewWidth(). The latter still >>>>> contains the old value. A quick inspection shows that >>>>> camera.setViewWidth() >>>>> is called when validate(...) is called on NGDefaultCamera, which is >>>>> called >>>>> by ES2Context.updateRenderTarget() which happens during rendering, >>>>> hence >>>>> *after* the PresentingPainter checks if the width is 0. >>>>> >>>>> So immediately after we set the width of the Screen to 0 (on the FX App >>>>> Thread), a Pulse happens, and this one still things the screen is the >>>>> original size. While the pulse is happening, the android system >>>>> destroys >>>>> our context, and the rendering fails. Moreover, the EGL system is in a >>>>> unpredictable state (recreating the surface fails). >>>>> >>>>> A very dirty workaround for this is to wait for 1 pulse (with the new >>>>> pulselistener API this should be possible) before we return from the >>>>> callback method called by Android when the surface is about to be >>>>> destroyed. That way, we will have 1 bogus rendering on an existing (but >>>>> about-to-be-destroyed) surface. >>>>> >>>>> But it would be better if there is some way to tell the quantum >>>>> renderer >>>>> to >>>>> immediately stop rendering. Existing pulses are no problem, as the >>>>> renderLock guarantuees that we set the size to 0 only when no other >>>>> thread >>>>> (quantum renderer) has a lock on the renderLock. >>>>> >>>>> - Johan >>>>> >>>>> >>>>> >>>> -- >>>> 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 nmalik1 at gmail.com Sat Nov 21 21:59:48 2015 From: nmalik1 at gmail.com (Nitin Malik) Date: Sat, 21 Nov 2015 16:59:48 -0500 Subject: JavaFX dependency injection Message-ID: This was asked recently ( http://mail.openjdk.java.net/pipermail/openjfx-dev/2015-October/018080.html) but I didnt see this addressed. Are there plans to have better integration with DI frameworks for views and controllers? For example, we have scenarios where multiple instances of the same view and controllers need to instantiated with different values. This is a frequent question that pops up on Stackoverflow and there apparently is no standard answer. It would help if suggested recipes and guidelines are made available. The solutions we have adopted - 1. Use a controller factory to lookup Spring bean (this isnt ideal because the factory needs to be aware of the bean name). 1a. For singleton controllers, the lookup can be done via class name. 2. Use a controller factory that holds a reference to a controller that was constructed in code with the various parameters. 3. An Afterburner-like framework that scans controller for an annotation and injects the values. Regards, Nitin From markus at headcrashing.eu Sun Nov 22 08:16:44 2015 From: markus at headcrashing.eu (Markus KARG) Date: Sun, 22 Nov 2015 09:16:44 +0100 Subject: JavaFX dependency injection In-Reply-To: References: Message-ID: <000301d124fe$204cc410$60e64c30$@eu> I think this issue identifies a problem caused by a deeper level of the Java stack: When will CDI become part of Java SE? -----Original Message----- From: openjfx-dev [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Nitin Malik Sent: Samstag, 21. November 2015 23:00 To: openjfx-dev at openjdk.java.net Subject: JavaFX dependency injection This was asked recently ( http://mail.openjdk.java.net/pipermail/openjfx-dev/2015-October/018080.html) but I didnt see this addressed. Are there plans to have better integration with DI frameworks for views and controllers? For example, we have scenarios where multiple instances of the same view and controllers need to instantiated with different values. This is a frequent question that pops up on Stackoverflow and there apparently is no standard answer. It would help if suggested recipes and guidelines are made available. The solutions we have adopted - 1. Use a controller factory to lookup Spring bean (this isnt ideal because the factory needs to be aware of the bean name). 1a. For singleton controllers, the lookup can be done via class name. 2. Use a controller factory that holds a reference to a controller that was constructed in code with the various parameters. 3. An Afterburner-like framework that scans controller for an annotation and injects the values. Regards, Nitin From johan.vos at gluonhq.com Sun Nov 22 11:24:45 2015 From: johan.vos at gluonhq.com (Johan Vos) Date: Sun, 22 Nov 2015 12:24:45 +0100 Subject: Pausing Quantum Renderer In-Reply-To: References: <564CE66B.3080109@Oracle.com> <564E3D1E.5050703@oracle.com> Message-ID: I implemented this in the javafxports clone of the OpenJFX 8u-dev repo, and the diff is here: https://bitbucket.org/javafxports/8u-dev-rt/commits/67a0fded8208095bd04efda6045aa257e245d6bc I am more than happy to create an issue in the openjdk bug system (enhancement?) and provide a patch there as well, but I think it needs a bit more discussion first? - Johan On Sat, Nov 21, 2015 at 9:23 PM, Johan Vos wrote: > I have a working implementation that needs more stress-testing on > different platforms, but it seems a good and easy solution so far. > I have this on QuantumToolkit: > > @Override > public void pauseRenderer(){ > Application.invokeAndWait(() -> this.pause = true); > PaintCollector.getInstance().waitForRenderingToComplete(); > }; > > public void resumeRenderer(){ > Application.invokeAndWait(() -> this.pause = false); > }; > > pause is a boolean that is checked for in > void pulse(boolean collect) { ... } > > The difficulty I mentioned in my previous mail (how do we know there are > no renderJobs pending/running) was solved easily as there exists this > PaintCollector.waitForRenderingToComplete method. > This might make the pauseRenderer a bit slower, and maybe this is not > needed in all usecases. In that case, we can remove it from the > pauseRenderer() and we can add it either in the Monocle implementation that > will call pauseRenderer, or in a Android/iOS specific code. > > However, it seems to me that if you want to pause the renderer, you most > often want to make sure no one is still writing to the glSurface after the > pauseRenderer method is called, so I think it makes sense to keep it there? > > - Johan > > > > > > > On Fri, Nov 20, 2015 at 8:14 AM, Johan Vos wrote: > >> I didn't plan to intercept or cancel pending/submitted jobs, but I have >> to wait until they are done before the android callback method returns. >> >> When Android is about to destroy the context, it will call the >> surfaceTextureDestroyed method on the Activity (the FXActivity in our >> case). As long as that method doesn't return, the context won't be >> destroyed. But once that method returns, the context might become invalid >> any moment. So if there are still jobs that want to do a swapBuffer after >> we return, those can crash or (even worse) corrupt the egl system. >> >> So it seems to me inside the implementation of surfaceTextureDestroyed, >> we need to achieve 2 things: >> 1. make sure no new pulses are generated. >> 2. don't return while the QuantumRenderer is still executing jobs. >> >> Those 2 things can be combined in a single Toolkit.pauseRenderer() but it >> might be better to only achieve the first task in Toolkit.pauseRenderer(). >> The contract for this method is than that no new pulses will be >> generated, but existing renderJobs might still be running when this method >> returns. >> The second thing, waiting for the renderJobs to be finished, can be done >> in the Android specific implementation. >> >> - Johan >> >> >> >> On Thu, Nov 19, 2015 at 10:20 PM, Kevin Rushforth < >> kevin.rushforth at oracle.com> wrote: >> >>> This might be a tricky semantic to achieve, and great care will be >>> needed to ensure no deadlocks or race conditions. Not running any more >>> pulses after this method returns seems fine, but it might be better to let >>> any existing renderJobs run (possibly discarding the results). This way you >>> could send the pause message to the renderer as a special renderJob and not >>> have to worry about jobs that are scheduled but not yet run. >>> >>> -- Kevin >>> >>> >>> >>> Johan Vos wrote: >>> >>>> After some experiments, here is my current thinking: >>>> >>>> Toolkit can have 2 new methods: >>>> pauseRenderer() >>>> resumeRenderer() >>>> >>>> When pauseRenderer is called, it should be guaranteed that after this >>>> call, >>>> no new pulses are fired until resumeRenderer is called. >>>> That is not hard, but it is not enough. Before we pause the pulses, the >>>> previous pulse probably submitted a renderJob to Prism, executed on the >>>> QuantumRenderer ThreadPoolExecutor. That job should run fine, as the >>>> next >>>> pulse (when we're back) will call >>>> GlassScene.waitForRenderingToComplete(). >>>> So we have to wait until there are no running or pending tasks in the >>>> QuantumRenderer as well. >>>> >>>> - Johan >>>> >>>> >>>> On Wed, Nov 18, 2015 at 9:58 PM, David Hill >>>> wrote: >>>> >>>> >>>> >>>>> On 11/18/15, 3:45 PM, Johan Vos wrote: >>>>> >>>>> Johan, >>>>> I think that it would be reasonable to put in something to Quantum >>>>> that causes the render loop to "pause", and then resume later. I >>>>> envision >>>>> this toggle as causing the render loop to skip, rather than tinkering >>>>> with >>>>> the pulses. >>>>> >>>>> When resume is called, it might be best to treat the world as dirty. >>>>> >>>>> Added to Toolkit, this would allow someone like Monocle to make the >>>>> toggles as is appropriate. >>>>> >>>>> If this works for you, perhaps you could prototype it ? >>>>> >>>>> regards, >>>>> Dave >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> On Android, a JavaFX Application might transfer control to another app >>>>>> (and >>>>>> become invisible) and enter the foreground later. In that case, the >>>>>> GLSurface we are rendering on becomes invalid. In order to avoid >>>>>> problems >>>>>> and save battery, we want to pause the renderer thread, but this >>>>>> turns out >>>>>> to be more difficult than I expected. >>>>>> >>>>>> When our app transfers control, we get a callback from Android. We >>>>>> intercept this in javafxports, and we set the Screen width/height to >>>>>> 0/0 >>>>>> as >>>>>> we don't want to render on the (invalid) surface while we lost >>>>>> control. >>>>>> When we regain control, we resize the Screen and the app renders >>>>>> again. >>>>>> >>>>>> The reason we set the width/height to 0/0 is because the >>>>>> PresentingPainter >>>>>> will call SceneState.isValid() and this returns false in case >>>>>> getWidth() >>>>>> or >>>>>> getHeight() are 0. >>>>>> >>>>>> However, SceneState extends PresentableState and it overrides the >>>>>> update >>>>>> method. It will call PresentatbleState.update() which will set the >>>>>> viewWidth to the width of the new Screen (hence, 0) , but after that >>>>>> it >>>>>> overwrites the viewWidth with camera.getViewWidth(). The latter still >>>>>> contains the old value. A quick inspection shows that >>>>>> camera.setViewWidth() >>>>>> is called when validate(...) is called on NGDefaultCamera, which is >>>>>> called >>>>>> by ES2Context.updateRenderTarget() which happens during rendering, >>>>>> hence >>>>>> *after* the PresentingPainter checks if the width is 0. >>>>>> >>>>>> So immediately after we set the width of the Screen to 0 (on the FX >>>>>> App >>>>>> Thread), a Pulse happens, and this one still things the screen is the >>>>>> original size. While the pulse is happening, the android system >>>>>> destroys >>>>>> our context, and the rendering fails. Moreover, the EGL system is in a >>>>>> unpredictable state (recreating the surface fails). >>>>>> >>>>>> A very dirty workaround for this is to wait for 1 pulse (with the new >>>>>> pulselistener API this should be possible) before we return from the >>>>>> callback method called by Android when the surface is about to be >>>>>> destroyed. That way, we will have 1 bogus rendering on an existing >>>>>> (but >>>>>> about-to-be-destroyed) surface. >>>>>> >>>>>> But it would be better if there is some way to tell the quantum >>>>>> renderer >>>>>> to >>>>>> immediately stop rendering. Existing pulses are no problem, as the >>>>>> renderLock guarantuees that we set the size to 0 only when no other >>>>>> thread >>>>>> (quantum renderer) has a lock on the renderLock. >>>>>> >>>>>> - Johan >>>>>> >>>>>> >>>>>> >>>>> -- >>>>> 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 jonathan.giles at oracle.com Sun Nov 22 20:05:48 2015 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Mon, 23 Nov 2015 09:05:48 +1300 Subject: [9] API review request: 8090585: Provide an official API to start the JavaFX platform In-Reply-To: References: <564FB39E.4040801@oracle.com> Message-ID: <5652201C.6070709@oracle.com> I don't believe there is any inconsistency here. We are preserving the existing semantics in PlatformImpl.startup to not prevent duplicate calls by default, whilst we are reversing the semantics for the public API in Platform, where we do prevent duplicate calls. The end result is that we have one public API (Platform.startup) with one set of semantics (prevent duplicate values). -- Jonathan On 21/11/15 11:57 PM, Ali Ebrahimi wrote: > Hi, > I think there is an inconsistency between : > > PlatformImpl.java > public static void startup(final Runnable r) { > + startup(r, false); //************* here default value false > + } > > and > > Platform.java > + public static void startup(Runnable runnable) { > + PlatformImpl.startup(runnable, true); //******** heredefault value true > + } > > On Sat, Nov 21, 2015 at 3:28 AM, Kevin Rushforth > > wrote: > > Jonathan and all, > > Please review the following new API proposal to add the ability to > explicitly start the FX runtime. > > https://bugs.openjdk.java.net/browse/JDK-8090585 > http://cr.openjdk.java.net/~kcr/8090585/webrev.00/ > > > -- Kevin > > > > > -- > > Best Regards, > Ali Ebrahimi From ali.ebrahimi1781 at gmail.com Sun Nov 22 20:26:20 2015 From: ali.ebrahimi1781 at gmail.com (Ali Ebrahimi) Date: Sun, 22 Nov 2015 23:56:20 +0330 Subject: [9] API review request: 8090585: Provide an official API to start the JavaFX platform In-Reply-To: <5652201C.6070709@oracle.com> References: <564FB39E.4040801@oracle.com> <5652201C.6070709@oracle.com> Message-ID: Hi, I know concerns here, but I think PlatformImpl.startup() and Platform.startup() should have same behavior from caller's POW. So I think if we can not have default behavior(duplicate calls) for public API so please change method name. My suggestions: Platform.safeStartup() or Platform.startPlatform or Platform.start On Sun, Nov 22, 2015 at 11:35 PM, Jonathan Giles wrote: > I don't believe there is any inconsistency here. We are preserving the > existing semantics in PlatformImpl.startup to not prevent duplicate calls > by default, whilst we are reversing the semantics for the public API in > Platform, where we do prevent duplicate calls. The end result is that we > have one public API (Platform.startup) with one set of semantics (prevent > duplicate values). > > -- Jonathan > > > On 21/11/15 11:57 PM, Ali Ebrahimi wrote: > > Hi, > I think there is an inconsistency between : > > PlatformImpl.java > > public static void startup(final Runnable r) { > + startup(r, false); //************* here default value false > > + } > > and > > Platform.java > > + public static void startup(Runnable runnable) { > + PlatformImpl.startup(runnable, true); //******** here default value true > > + } > > > > On Sat, Nov 21, 2015 at 3:28 AM, Kevin Rushforth < > kevin.rushforth at oracle.com> wrote: > >> Jonathan and all, >> >> Please review the following new API proposal to add the ability to >> explicitly start the FX runtime. >> >> https://bugs.openjdk.java.net/browse/JDK-8090585 >> http://cr.openjdk.java.net/~kcr/8090585/webrev.00/ >> >> -- Kevin >> >> > > > -- > > Best Regards, > Ali Ebrahimi > > > -- Best Regards, Ali Ebrahimi From hastebrot at gmail.com Sun Nov 22 22:33:05 2015 From: hastebrot at gmail.com (Benjamin Gudehus) Date: Sun, 22 Nov 2015 23:33:05 +0100 Subject: [9] API review request: 8090585: Provide an official API to start the JavaFX platform In-Reply-To: References: <564FB39E.4040801@oracle.com> <5652201C.6070709@oracle.com> Message-ID: Wow, this patch will simplify the architecture of JavaFX testing libraries/frameworks. >From my perspective it is important to have a method to start the FX runtime and thread. I guess one would just use `new Stage()` to create the primary Stage? Or do we need to register the primary Stage somewhere? This is a great. As a sidenote: Another use-case for testing is to be able to call the Application launch procedure multiple times (probably for different Application classes) without starting the FX runtime. TestFX currently uses custom code similar to the code in `LauncherImpl` to archive this. --Benjamin On Sun, Nov 22, 2015 at 9:26 PM, Ali Ebrahimi wrote: > Hi, > I know concerns here, but I think PlatformImpl.startup() and > Platform.startup() should have same behavior from caller's POW. > So I think if we can not have default behavior(duplicate calls) for public > API so please change method name. > My suggestions: Platform.safeStartup() or Platform.startPlatform or > Platform.start > > On Sun, Nov 22, 2015 at 11:35 PM, Jonathan Giles < > jonathan.giles at oracle.com> > wrote: > > > I don't believe there is any inconsistency here. We are preserving the > > existing semantics in PlatformImpl.startup to not prevent duplicate calls > > by default, whilst we are reversing the semantics for the public API in > > Platform, where we do prevent duplicate calls. The end result is that we > > have one public API (Platform.startup) with one set of semantics (prevent > > duplicate values). > > > > -- Jonathan > > > > > > On 21/11/15 11:57 PM, Ali Ebrahimi wrote: > > > > Hi, > > I think there is an inconsistency between : > > > > PlatformImpl.java > > > > public static void startup(final Runnable r) { > > + startup(r, false); //************* here default value false > > > > + } > > > > and > > > > Platform.java > > > > + public static void startup(Runnable runnable) { > > + PlatformImpl.startup(runnable, true); //******** here default > value true > > > > + } > > > > > > > > On Sat, Nov 21, 2015 at 3:28 AM, Kevin Rushforth < > > kevin.rushforth at oracle.com> wrote: > > > >> Jonathan and all, > >> > >> Please review the following new API proposal to add the ability to > >> explicitly start the FX runtime. > >> > >> https://bugs.openjdk.java.net/browse/JDK-8090585 > >> http://cr.openjdk.java.net/~kcr/8090585/webrev.00/ > >> > >> -- Kevin > >> > >> > > > > > > -- > > > > Best Regards, > > Ali Ebrahimi > > > > > > > > > -- > > Best Regards, > Ali Ebrahimi > From tom.schindl at bestsolution.at Mon Nov 23 08:38:39 2015 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Mon, 23 Nov 2015 09:38:39 +0100 Subject: JavaFX dependency injection In-Reply-To: References: Message-ID: <5652D08F.7080000@bestsolution.at> JavaFX is a UI-Toolkit and not an UI-Framework, JavaFX provides all the hooks needed to integrate with whatever DI-Container (Sping, Guice, ...) you want it to run on. I would go for 1. as the general recommendation and there are frameworks out there who do exactly this type of thing. Tom On 21.11.15 22:59, Nitin Malik wrote: > This was asked recently ( > http://mail.openjdk.java.net/pipermail/openjfx-dev/2015-October/018080.html) > but I didnt see this addressed. > > Are there plans to have better integration with DI frameworks for views and > controllers? > > For example, we have scenarios where multiple instances of the same view > and controllers need to instantiated with different values. This is a > frequent question that pops up on Stackoverflow and there apparently is no > standard answer. It would help if suggested recipes and guidelines are made > available. > > The solutions we have adopted - > 1. Use a controller factory to lookup Spring bean (this isnt ideal because > the factory needs to be aware of the bean name). > 1a. For singleton controllers, the lookup can be done via class name. > 2. Use a controller factory that holds a reference to a controller that was > constructed in code with the various parameters. > 3. An Afterburner-like framework that scans controller for an annotation > and injects the values. > > Regards, > Nitin > -- 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 kevin.rushforth at oracle.com Mon Nov 23 12:53:34 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 23 Nov 2015 04:53:34 -0800 Subject: [9] API review request: 8090585: Provide an official API to start the JavaFX platform In-Reply-To: References: <564FB39E.4040801@oracle.com> Message-ID: <56530C4E.1060101@oracle.com> This is intentional to preserve compatibility for existing internal code (testing tools and deployment code) to avoid regressions. I will file a follow-on issue to find and eliminate this difference, since it does seem like an unnecessary inconsistency. Thanks for pointing this out. -- Kevin Ali Ebrahimi wrote: > Hi, > I think there is an inconsistency between : > > PlatformImpl.java > public static void startup(final Runnable r) { > + startup(r, false); //************* here default value false > + } > > and > > Platform.java > + public static void startup(Runnable runnable) { > + PlatformImpl.startup(runnable, true); //******** here default value true > + } > > > On Sat, Nov 21, 2015 at 3:28 AM, Kevin Rushforth > > wrote: > > Jonathan and all, > > Please review the following new API proposal to add the ability to > explicitly start the FX runtime. > > https://bugs.openjdk.java.net/browse/JDK-8090585 > http://cr.openjdk.java.net/~kcr/8090585/webrev.00/ > > > -- Kevin > > > > > -- > > Best Regards, > Ali Ebrahimi From vadim.pakhnushev at oracle.com Mon Nov 23 14:11:06 2015 From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev) Date: Mon, 23 Nov 2015 17:11:06 +0300 Subject: [9] Review request for 8140503: JavaFX "Pair" Hash Code Collisions In-Reply-To: <563938A2.70000@oracle.com> References: <56389546.7000807@oracle.com> <56390C92.2020104@oracle.com> <5639129E.40201@oracle.com> <56391407.80105@oracle.com> <56392A2A.9040701@oracle.com> <56392A99.5050806@oracle.com> <56392FA4.5080508@oracle.com> <563938A2.70000@oracle.com> Message-ID: <56531E7A.1050805@oracle.com> Guys, Could you please review the updated fix? https://bugs.openjdk.java.net/browse/JDK-8140503 http://cr.openjdk.java.net/~vadim/8140503/webrev.01/ Thanks, Vadim On 04.11.2015 1:43, Kevin Rushforth wrote: > Inlining it seems like a fine way to go to me, too. As another point > of reference, we use 7/31 in other places in JavaFX. > > -- Kevin > > > Jim Graham wrote: >> Absolutely, this report uncovered an unrelated NPE bug which is >> helpful, and apparently different constants might affect the >> collision probabilities (which were already very unlikely to begin >> with), but the bug report was definitely filed primarily as a >> misunderstanding. >> >> One thing to note - perhaps small numbers are more likely to be >> encountered so the larger the prime, the less likelihood of getting a >> collision. I wouldn't recommend using too large of a prime since the >> probability is already so low even with 13, and larger primes may >> increase the size of the byte code and compiled code since larger >> constants take more complicated instructions to deal with. Josh Bloch >> recommended a base of 17 and a multiplier of 37 in Chapter 3 of >> Effective Java, but he also admitted that the numbers were arbitrary >> except for the multiplier needing to be an odd prime. >> >> One reason 13 might be too low depends on the probability that Pair >> is used in hash cases with lots of very small numbers. Adding in a >> base prime and using a little bit larger prime multiplier quickly >> turns lots of small numbers into massively distributed hashes - even >> with 31 or 17/37. >> >> I kind of feel like using the existing utility is overkill for just 2 >> objects since it requires constructing an array object to use it. I'd >> be just as happy (perhaps even more so) if we just upgraded the code >> to check key for null and use a little larger prime, but keep it >> inlined... >> >> ...jim >> >> On 11/3/15 1:43 PM, Alexander Kouznetsov wrote: >>> Moreover, the following two sentences: >>> >>> "However, this is an incorrect way to compute a hash code of two >>> values." >>> "This can lead to hard-to-find bugs anywhere that instances of Pair are >>> used in a data structure like a HashSet or HashTable." >>> >>> seem to indicate misunderstanding of what hashcode is and how it is to >>> be used. >>> >>> Best regards, >>> Alexander Kouznetsov >>> (408) 276-0387 >>> >>> On 3 ??? 2015 13:42, Alexander Kouznetsov wrote: >>>> After the fix, you should expect another incident report of >>>> >>>> Objects.hash(1, 0) == Objects.hash(0, 31) >>>> >>>> always true :-) >>>> >>>> I'd rather file another bug on key == null causing NPE and closing >>>> this one as incomplete or not an issue. >>>> >>>> Best regards, >>>> Alexander Kouznetsov >>>> (408) 276-0387 >>>> >>>> On 3 ??? 2015 12:07, Vadim Pakhnushev wrote: >>>>> Hmm, yeah, the actual difference is in the prime number only (that is >>>>> changing the algorithm only doesn't improve anything), so the only >>>>> remaining reason to fix this is that Objects.hash guards against null >>>>> values (and I forgot to mention it in the review). >>>>> The key in Pair could actually be null and in this case hashCode will >>>>> throw NPE. >>>>> >>>>> Vadim >>>>> >>>>> On 03.11.2015 23:01, Vadim Pakhnushev wrote: >>>>>> Well, not exactly... Previously it was 13*hash(a) + hash(b) and now >>>>>> it's 31*(31 + hash(a)) + hash(b). >>>>>> And apparently it improves the quality somehow. I did a test with >>>>>> 100^4 combinations and collision probability dropped by the factor >>>>>> of 3 from 0.065% to 0.022%. >>>>>> Not really impressive, but still, and it uses well-defined utility >>>>>> method. >>>>>> Yeah, I know it's not really a bug since you don't want to rely on >>>>>> the hashCode at all... >>>>>> >>>>>> Thanks, >>>>>> Vadim >>>>>> >>>>>> On 03.11.2015 22:35, Jim Graham wrote: >>>>>>> All this does is change the prime constant used to produce the hash >>>>>>> value. >>>>>>> >>>>>>> Objects.hash(a, b) uses 31*hash(a) + hash(b) instead of the >>>>>>> 13*hash(a) + hash(b) that the embedded implementation uses. >>>>>>> >>>>>>> I don't really think this is a bug. The fact that Integer objects >>>>>>> make it easy to reverse engineer and compute collisions of any >>>>>>> reasonable hash combination computation don't mean that the >>>>>>> technique has a bug, it just means that the submitter can read the >>>>>>> code and think of a counter-example. >>>>>>> >>>>>>> If there are practical problems being caused for some particular >>>>>>> and popular use case by the use of this particular constant "13", >>>>>>> then we need to understand those issues and come up with a more >>>>>>> comprehensive solution than to simply hand off to another mechanism >>>>>>> which uses the same procedure with a different prime constant... >>>>>>> >>>>>>> ...jim >>>>>>> >>>>>>> On 11/3/15 3:06 AM, Vadim Pakhnushev wrote: >>>>>>>> Hi Chien, >>>>>>>> >>>>>>>> Could you please review the fix: >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8140503 >>>>>>>> http://cr.openjdk.java.net/~vadim/8140503/webrev.00/ >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Vadim >>>>>> >>>>> >>>> >>> From David.Hill at Oracle.com Mon Nov 23 16:41:44 2015 From: David.Hill at Oracle.com (David Hill) Date: Mon, 23 Nov 2015 11:41:44 -0500 Subject: Pausing Quantum Renderer In-Reply-To: References: <564CE66B.3080109@Oracle.com> <564E3D1E.5050703@oracle.com> Message-ID: <565341C8.1070705@Oracle.com> On 11/22/15, 6:24 AM, Johan Vos wrote: > I implemented this in the javafxports clone of the OpenJFX 8u-dev repo, and the diff is here: > > https://bitbucket.org/javafxports/8u-dev-rt/commits/67a0fded8208095bd04efda6045aa257e245d6bc > > I am more than happy to create an issue in the openjdk bug system (enhancement?) and provide a patch there as well, but I think it needs a bit more discussion first? My only slight concern looking at the patch is where we bail out of pulse(). At the moment you have between: PulseLogger.pulseStart(); and because of the finally block, PulseLogger.pulseEnd(); my first thought was that the return should be before the try block as this is a "null" pulse. I think I am fine with it either way though. Please file a bug on this (does not need to be an enhancement). Dave > > - Johan > > On Sat, Nov 21, 2015 at 9:23 PM, Johan Vos > wrote: > > I have a working implementation that needs more stress-testing on different platforms, but it seems a good and easy solution so far. > I have this on QuantumToolkit: > > @Override > public void pauseRenderer(){ > Application.invokeAndWait(() -> this.pause = true); > PaintCollector.getInstance().waitForRenderingToComplete(); > }; > > public void resumeRenderer(){ > Application.invokeAndWait(() -> this.pause = false); > }; > > pause is a boolean that is checked for in > void pulse(boolean collect) { ... } > > The difficulty I mentioned in my previous mail (how do we know there are no renderJobs pending/running) was solved easily as there exists this PaintCollector.waitForRenderingToComplete method. > This might make the pauseRenderer a bit slower, and maybe this is not needed in all usecases. In that case, we can remove it from the pauseRenderer() and we can add it either in the Monocle implementation that will call pauseRenderer, or in a Android/iOS specific code. > > However, it seems to me that if you want to pause the renderer, you most often want to make sure no one is still writing to the glSurface after the pauseRenderer method is called, so I think it makes sense to keep it there? > > - Johan > > > > > > > On Fri, Nov 20, 2015 at 8:14 AM, Johan Vos > wrote: > > I didn't plan to intercept or cancel pending/submitted jobs, but I have to wait until they are done before the android callback method returns. > > When Android is about to destroy the context, it will call the > surfaceTextureDestroyed method on the Activity (the FXActivity in our case). As long as that method doesn't return, the context won't be destroyed. But once that method returns, the context might become invalid any moment. So if there are still jobs that want to do a swapBuffer after we return, those can crash or (even worse) corrupt the egl system. > > So it seems to me inside the implementation of surfaceTextureDestroyed, we need to achieve 2 things: > 1. make sure no new pulses are generated. > 2. don't return while the QuantumRenderer is still executing jobs. > > Those 2 things can be combined in a single Toolkit.pauseRenderer() but it might be better to only achieve the first task in Toolkit.pauseRenderer(). > The contract for this method is than that no new pulses will be generated, but existing renderJobs might still be running when this method returns. > The second thing, waiting for the renderJobs to be finished, can be done in the Android specific implementation. > > - Johan > > > > On Thu, Nov 19, 2015 at 10:20 PM, Kevin Rushforth > wrote: > > This might be a tricky semantic to achieve, and great care will be needed to ensure no deadlocks or race conditions. Not running any more pulses after this method returns seems fine, but it might be better to let any existing renderJobs run (possibly discarding the results). This way you could send the pause message to the renderer as a special renderJob and not have to worry about jobs that are scheduled but not yet run. > > -- Kevin > > > > Johan Vos wrote: > > After some experiments, here is my current thinking: > > Toolkit can have 2 new methods: > pauseRenderer() > resumeRenderer() > > When pauseRenderer is called, it should be guaranteed that after this call, > no new pulses are fired until resumeRenderer is called. > That is not hard, but it is not enough. Before we pause the pulses, the > previous pulse probably submitted a renderJob to Prism, executed on the > QuantumRenderer ThreadPoolExecutor. That job should run fine, as the next > pulse (when we're back) will call GlassScene.waitForRenderingToComplete(). > So we have to wait until there are no running or pending tasks in the > QuantumRenderer as well. > > - Johan > > > On Wed, Nov 18, 2015 at 9:58 PM, David Hill > wrote: > > > On 11/18/15, 3:45 PM, Johan Vos wrote: > > Johan, > I think that it would be reasonable to put in something to Quantum > that causes the render loop to "pause", and then resume later. I envision > this toggle as causing the render loop to skip, rather than tinkering with > the pulses. > > When resume is called, it might be best to treat the world as dirty. > > Added to Toolkit, this would allow someone like Monocle to make the > toggles as is appropriate. > > If this works for you, perhaps you could prototype it ? > > regards, > Dave > > > > > On Android, a JavaFX Application might transfer control to another app > (and > become invisible) and enter the foreground later. In that case, the > GLSurface we are rendering on becomes invalid. In order to avoid problems > and save battery, we want to pause the renderer thread, but this turns out > to be more difficult than I expected. > > When our app transfers control, we get a callback from Android. We > intercept this in javafxports, and we set the Screen width/height to 0/0 > as > we don't want to render on the (invalid) surface while we lost control. > When we regain control, we resize the Screen and the app renders again. > > The reason we set the width/height to 0/0 is because the PresentingPainter > will call SceneState.isValid() and this returns false in case getWidth() > or > getHeight() are 0. > > However, SceneState extends PresentableState and it overrides the update > method. It will call PresentatbleState.update() which will set the > viewWidth to the width of the new Screen (hence, 0) , but after that it > overwrites the viewWidth with camera.getViewWidth(). The latter still > contains the old value. A quick inspection shows that > camera.setViewWidth() > is called when validate(...) is called on NGDefaultCamera, which is called > by ES2Context.updateRenderTarget() which happens during rendering, hence > *after* the PresentingPainter checks if the width is 0. > > So immediately after we set the width of the Screen to 0 (on the FX App > Thread), a Pulse happens, and this one still things the screen is the > original size. While the pulse is happening, the android system destroys > our context, and the rendering fails. Moreover, the EGL system is in a > unpredictable state (recreating the surface fails). > > A very dirty workaround for this is to wait for 1 pulse (with the new > pulselistener API this should be possible) before we return from the > callback method called by Android when the surface is about to be > destroyed. That way, we will have 1 bogus rendering on an existing (but > about-to-be-destroyed) surface. > > But it would be better if there is some way to tell the quantum renderer > to > immediately stop rendering. Existing pulses are no problem, as the > renderLock guarantuees that we set the size to 0 only when no other thread > (quantum renderer) has a lock on the renderLock. > > - Johan > > > -- > 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) > > > > > > -- 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 morris.meyer at oracle.com Mon Nov 23 16:43:55 2015 From: morris.meyer at oracle.com (Morris Meyer) Date: Mon, 23 Nov 2015 11:43:55 -0500 Subject: Pausing Quantum Renderer In-Reply-To: References: <564CE66B.3080109@Oracle.com> <564E3D1E.5050703@oracle.com> Message-ID: <5653424B.2030301@oracle.com> As the original author of the Quantum toolkit and the renderer, this sort of addition goes against what I had in mind when designing the PaintCollector and the renderer. As the renderer is built around a ThreadPoolExecutor, stopping system functionality for an edge case is putting the cart before the horse. When a Window is miniaturized or set to zero size, or moved offscreen, there should be no pulses fired at the Window. This seems more like an issue of ensuring that if the window is 0x0 that it is not considered dirty, and if there is no dirty scene that nextPulseRequested() is never called. There does need to be work done on Quantum to ensure that it cycles down to no CPU usage when windows are hidden and/or miniaturized on battery operated devices. That needs to be done cleanly, but even then pausing the ThreadPoolExecutor seems to be the wrong way of going about it. The TPE model is more startup, work, then shutdown, and the QuantumToolkit intermediates JavaFX application state with that model. Best regards, --morris meyer On 11/22/15 6:24 AM, Johan Vos wrote: > I implemented this in the javafxports clone of the OpenJFX 8u-dev repo, and > the diff is here: > > https://bitbucket.org/javafxports/8u-dev-rt/commits/67a0fded8208095bd04efda6045aa257e245d6bc > > I am more than happy to create an issue in the openjdk bug system > (enhancement?) and provide a patch there as well, but I think it needs a > bit more discussion first? > > - Johan > > On Sat, Nov 21, 2015 at 9:23 PM, Johan Vos wrote: > >> I have a working implementation that needs more stress-testing on >> different platforms, but it seems a good and easy solution so far. >> I have this on QuantumToolkit: >> >> @Override >> public void pauseRenderer(){ >> Application.invokeAndWait(() -> this.pause = true); >> PaintCollector.getInstance().waitForRenderingToComplete(); >> }; >> >> public void resumeRenderer(){ >> Application.invokeAndWait(() -> this.pause = false); >> }; >> >> pause is a boolean that is checked for in >> void pulse(boolean collect) { ... } >> >> The difficulty I mentioned in my previous mail (how do we know there are >> no renderJobs pending/running) was solved easily as there exists this >> PaintCollector.waitForRenderingToComplete method. >> This might make the pauseRenderer a bit slower, and maybe this is not >> needed in all usecases. In that case, we can remove it from the >> pauseRenderer() and we can add it either in the Monocle implementation that >> will call pauseRenderer, or in a Android/iOS specific code. >> >> However, it seems to me that if you want to pause the renderer, you most >> often want to make sure no one is still writing to the glSurface after the >> pauseRenderer method is called, so I think it makes sense to keep it there? >> >> - Johan >> >> >> >> >> >> >> On Fri, Nov 20, 2015 at 8:14 AM, Johan Vos wrote: >> >>> I didn't plan to intercept or cancel pending/submitted jobs, but I have >>> to wait until they are done before the android callback method returns. >>> >>> When Android is about to destroy the context, it will call the >>> surfaceTextureDestroyed method on the Activity (the FXActivity in our >>> case). As long as that method doesn't return, the context won't be >>> destroyed. But once that method returns, the context might become invalid >>> any moment. So if there are still jobs that want to do a swapBuffer after >>> we return, those can crash or (even worse) corrupt the egl system. >>> >>> So it seems to me inside the implementation of surfaceTextureDestroyed, >>> we need to achieve 2 things: >>> 1. make sure no new pulses are generated. >>> 2. don't return while the QuantumRenderer is still executing jobs. >>> >>> Those 2 things can be combined in a single Toolkit.pauseRenderer() but it >>> might be better to only achieve the first task in Toolkit.pauseRenderer(). >>> The contract for this method is than that no new pulses will be >>> generated, but existing renderJobs might still be running when this method >>> returns. >>> The second thing, waiting for the renderJobs to be finished, can be done >>> in the Android specific implementation. >>> >>> - Johan >>> >>> >>> >>> On Thu, Nov 19, 2015 at 10:20 PM, Kevin Rushforth < >>> kevin.rushforth at oracle.com> wrote: >>> >>>> This might be a tricky semantic to achieve, and great care will be >>>> needed to ensure no deadlocks or race conditions. Not running any more >>>> pulses after this method returns seems fine, but it might be better to let >>>> any existing renderJobs run (possibly discarding the results). This way you >>>> could send the pause message to the renderer as a special renderJob and not >>>> have to worry about jobs that are scheduled but not yet run. >>>> >>>> -- Kevin >>>> >>>> >>>> >>>> Johan Vos wrote: >>>> >>>>> After some experiments, here is my current thinking: >>>>> >>>>> Toolkit can have 2 new methods: >>>>> pauseRenderer() >>>>> resumeRenderer() >>>>> >>>>> When pauseRenderer is called, it should be guaranteed that after this >>>>> call, >>>>> no new pulses are fired until resumeRenderer is called. >>>>> That is not hard, but it is not enough. Before we pause the pulses, the >>>>> previous pulse probably submitted a renderJob to Prism, executed on the >>>>> QuantumRenderer ThreadPoolExecutor. That job should run fine, as the >>>>> next >>>>> pulse (when we're back) will call >>>>> GlassScene.waitForRenderingToComplete(). >>>>> So we have to wait until there are no running or pending tasks in the >>>>> QuantumRenderer as well. >>>>> >>>>> - Johan >>>>> >>>>> >>>>> On Wed, Nov 18, 2015 at 9:58 PM, David Hill >>>>> wrote: >>>>> >>>>> >>>>> >>>>>> On 11/18/15, 3:45 PM, Johan Vos wrote: >>>>>> >>>>>> Johan, >>>>>> I think that it would be reasonable to put in something to Quantum >>>>>> that causes the render loop to "pause", and then resume later. I >>>>>> envision >>>>>> this toggle as causing the render loop to skip, rather than tinkering >>>>>> with >>>>>> the pulses. >>>>>> >>>>>> When resume is called, it might be best to treat the world as dirty. >>>>>> >>>>>> Added to Toolkit, this would allow someone like Monocle to make the >>>>>> toggles as is appropriate. >>>>>> >>>>>> If this works for you, perhaps you could prototype it ? >>>>>> >>>>>> regards, >>>>>> Dave >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> On Android, a JavaFX Application might transfer control to another app >>>>>>> (and >>>>>>> become invisible) and enter the foreground later. In that case, the >>>>>>> GLSurface we are rendering on becomes invalid. In order to avoid >>>>>>> problems >>>>>>> and save battery, we want to pause the renderer thread, but this >>>>>>> turns out >>>>>>> to be more difficult than I expected. >>>>>>> >>>>>>> When our app transfers control, we get a callback from Android. We >>>>>>> intercept this in javafxports, and we set the Screen width/height to >>>>>>> 0/0 >>>>>>> as >>>>>>> we don't want to render on the (invalid) surface while we lost >>>>>>> control. >>>>>>> When we regain control, we resize the Screen and the app renders >>>>>>> again. >>>>>>> >>>>>>> The reason we set the width/height to 0/0 is because the >>>>>>> PresentingPainter >>>>>>> will call SceneState.isValid() and this returns false in case >>>>>>> getWidth() >>>>>>> or >>>>>>> getHeight() are 0. >>>>>>> >>>>>>> However, SceneState extends PresentableState and it overrides the >>>>>>> update >>>>>>> method. It will call PresentatbleState.update() which will set the >>>>>>> viewWidth to the width of the new Screen (hence, 0) , but after that >>>>>>> it >>>>>>> overwrites the viewWidth with camera.getViewWidth(). The latter still >>>>>>> contains the old value. A quick inspection shows that >>>>>>> camera.setViewWidth() >>>>>>> is called when validate(...) is called on NGDefaultCamera, which is >>>>>>> called >>>>>>> by ES2Context.updateRenderTarget() which happens during rendering, >>>>>>> hence >>>>>>> *after* the PresentingPainter checks if the width is 0. >>>>>>> >>>>>>> So immediately after we set the width of the Screen to 0 (on the FX >>>>>>> App >>>>>>> Thread), a Pulse happens, and this one still things the screen is the >>>>>>> original size. While the pulse is happening, the android system >>>>>>> destroys >>>>>>> our context, and the rendering fails. Moreover, the EGL system is in a >>>>>>> unpredictable state (recreating the surface fails). >>>>>>> >>>>>>> A very dirty workaround for this is to wait for 1 pulse (with the new >>>>>>> pulselistener API this should be possible) before we return from the >>>>>>> callback method called by Android when the surface is about to be >>>>>>> destroyed. That way, we will have 1 bogus rendering on an existing >>>>>>> (but >>>>>>> about-to-be-destroyed) surface. >>>>>>> >>>>>>> But it would be better if there is some way to tell the quantum >>>>>>> renderer >>>>>>> to >>>>>>> immediately stop rendering. Existing pulses are no problem, as the >>>>>>> renderLock guarantuees that we set the size to 0 only when no other >>>>>>> thread >>>>>>> (quantum renderer) has a lock on the renderLock. >>>>>>> >>>>>>> - Johan >>>>>>> >>>>>>> >>>>>>> >>>>>> -- >>>>>> 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 Mon Nov 23 18:56:00 2015 From: David.Hill at Oracle.com (David Hill) Date: Mon, 23 Nov 2015 13:56:00 -0500 Subject: Pausing Quantum Renderer In-Reply-To: <5653424B.2030301@oracle.com> References: <564CE66B.3080109@Oracle.com> <564E3D1E.5050703@oracle.com> <5653424B.2030301@oracle.com> Message-ID: <56536140.4000709@Oracle.com> On 11/23/15, 11:43 AM, Morris Meyer wrote: > As the original author of the Quantum toolkit and the renderer, this sort of addition goes against what I had in mind when designing the PaintCollector and the renderer. As the renderer is built around a ThreadPoolExecutor, stopping system functionality for an edge case is putting the cart before the horse. > > When a Window is miniaturized or set to zero size, or moved offscreen, there should be no pulses fired at the Window. My concern with setting the window size to zero would be any additional work that is done. If there is a layout to go to 0,0 and then another layout when we go to the new real size then that is not something I like. Pausing the processing of the rendering as has been proposed here seems like one way to be minimally intrusive on a compute constrained devices. Another options would be to set the window visibility. A real concern regardless of what is done is the potential problem of multithreaded issues. Skipping render pulses for a period seems pretty safe from a multithreaded point of view. It also seems to be the least likely to cause a lot of throw away work. Another thought, setting a window to visible(false) at least takes it off the rendering queue (PaintCollector.getInstance().removeDirtyScene(this);). So in theory, walking through the window list and marking all of them as not visible. The problem I have with any approach along these lines is the risk that state will be confused or lost, or that we do a lot of additional work in a place where we are already going to cause work as a new graphics context and display size are being dropped in. Even something like setVisible(false) has a lot of notification work associated with it. Given the above, I would tend to stick with the proposed solution. Dave > > This seems more like an issue of ensuring that if the window is 0x0 that it is not considered dirty, and if there is no dirty scene that nextPulseRequested() is never called. > > There does need to be work done on Quantum to ensure that it cycles down to no CPU usage when windows are hidden and/or miniaturized on battery operated devices. That needs to be done cleanly, but even then pausing the ThreadPoolExecutor seems to be the wrong way of going about it. The TPE model is more startup, work, then shutdown, and the QuantumToolkit intermediates JavaFX application state with that model. > > Best regards, > > --morris meyer > > On 11/22/15 6:24 AM, Johan Vos wrote: >> I implemented this in the javafxports clone of the OpenJFX 8u-dev repo, and >> the diff is here: >> >> https://bitbucket.org/javafxports/8u-dev-rt/commits/67a0fded8208095bd04efda6045aa257e245d6bc >> >> I am more than happy to create an issue in the openjdk bug system >> (enhancement?) and provide a patch there as well, but I think it needs a >> bit more discussion first? >> >> - Johan >> >> On Sat, Nov 21, 2015 at 9:23 PM, Johan Vos wrote: >> >>> I have a working implementation that needs more stress-testing on >>> different platforms, but it seems a good and easy solution so far. >>> I have this on QuantumToolkit: >>> >>> @Override >>> public void pauseRenderer(){ >>> Application.invokeAndWait(() -> this.pause = true); >>> PaintCollector.getInstance().waitForRenderingToComplete(); >>> }; >>> >>> public void resumeRenderer(){ >>> Application.invokeAndWait(() -> this.pause = false); >>> }; >>> >>> pause is a boolean that is checked for in >>> void pulse(boolean collect) { ... } >>> >>> The difficulty I mentioned in my previous mail (how do we know there are >>> no renderJobs pending/running) was solved easily as there exists this >>> PaintCollector.waitForRenderingToComplete method. >>> This might make the pauseRenderer a bit slower, and maybe this is not >>> needed in all usecases. In that case, we can remove it from the >>> pauseRenderer() and we can add it either in the Monocle implementation that >>> will call pauseRenderer, or in a Android/iOS specific code. >>> >>> However, it seems to me that if you want to pause the renderer, you most >>> often want to make sure no one is still writing to the glSurface after the >>> pauseRenderer method is called, so I think it makes sense to keep it there? >>> >>> - Johan >>> >>> >>> >>> >>> >>> >>> On Fri, Nov 20, 2015 at 8:14 AM, Johan Vos wrote: >>> >>>> I didn't plan to intercept or cancel pending/submitted jobs, but I have >>>> to wait until they are done before the android callback method returns. >>>> >>>> When Android is about to destroy the context, it will call the >>>> surfaceTextureDestroyed method on the Activity (the FXActivity in our >>>> case). As long as that method doesn't return, the context won't be >>>> destroyed. But once that method returns, the context might become invalid >>>> any moment. So if there are still jobs that want to do a swapBuffer after >>>> we return, those can crash or (even worse) corrupt the egl system. >>>> >>>> So it seems to me inside the implementation of surfaceTextureDestroyed, >>>> we need to achieve 2 things: >>>> 1. make sure no new pulses are generated. >>>> 2. don't return while the QuantumRenderer is still executing jobs. >>>> >>>> Those 2 things can be combined in a single Toolkit.pauseRenderer() but it >>>> might be better to only achieve the first task in Toolkit.pauseRenderer(). >>>> The contract for this method is than that no new pulses will be >>>> generated, but existing renderJobs might still be running when this method >>>> returns. >>>> The second thing, waiting for the renderJobs to be finished, can be done >>>> in the Android specific implementation. >>>> >>>> - Johan >>>> >>>> >>>> >>>> On Thu, Nov 19, 2015 at 10:20 PM, Kevin Rushforth < >>>> kevin.rushforth at oracle.com> wrote: >>>> >>>>> This might be a tricky semantic to achieve, and great care will be >>>>> needed to ensure no deadlocks or race conditions. Not running any more >>>>> pulses after this method returns seems fine, but it might be better to let >>>>> any existing renderJobs run (possibly discarding the results). This way you >>>>> could send the pause message to the renderer as a special renderJob and not >>>>> have to worry about jobs that are scheduled but not yet run. >>>>> >>>>> -- Kevin >>>>> >>>>> >>>>> >>>>> Johan Vos wrote: >>>>> >>>>>> After some experiments, here is my current thinking: >>>>>> >>>>>> Toolkit can have 2 new methods: >>>>>> pauseRenderer() >>>>>> resumeRenderer() >>>>>> >>>>>> When pauseRenderer is called, it should be guaranteed that after this >>>>>> call, >>>>>> no new pulses are fired until resumeRenderer is called. >>>>>> That is not hard, but it is not enough. Before we pause the pulses, the >>>>>> previous pulse probably submitted a renderJob to Prism, executed on the >>>>>> QuantumRenderer ThreadPoolExecutor. That job should run fine, as the >>>>>> next >>>>>> pulse (when we're back) will call >>>>>> GlassScene.waitForRenderingToComplete(). >>>>>> So we have to wait until there are no running or pending tasks in the >>>>>> QuantumRenderer as well. >>>>>> >>>>>> - Johan >>>>>> >>>>>> >>>>>> On Wed, Nov 18, 2015 at 9:58 PM, David Hill >>>>>> wrote: >>>>>> >>>>>> >>>>>> >>>>>>> On 11/18/15, 3:45 PM, Johan Vos wrote: >>>>>>> >>>>>>> Johan, >>>>>>> I think that it would be reasonable to put in something to Quantum >>>>>>> that causes the render loop to "pause", and then resume later. I >>>>>>> envision >>>>>>> this toggle as causing the render loop to skip, rather than tinkering >>>>>>> with >>>>>>> the pulses. >>>>>>> >>>>>>> When resume is called, it might be best to treat the world as dirty. >>>>>>> >>>>>>> Added to Toolkit, this would allow someone like Monocle to make the >>>>>>> toggles as is appropriate. >>>>>>> >>>>>>> If this works for you, perhaps you could prototype it ? >>>>>>> >>>>>>> regards, >>>>>>> Dave >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> On Android, a JavaFX Application might transfer control to another app >>>>>>>> (and >>>>>>>> become invisible) and enter the foreground later. In that case, the >>>>>>>> GLSurface we are rendering on becomes invalid. In order to avoid >>>>>>>> problems >>>>>>>> and save battery, we want to pause the renderer thread, but this >>>>>>>> turns out >>>>>>>> to be more difficult than I expected. >>>>>>>> >>>>>>>> When our app transfers control, we get a callback from Android. We >>>>>>>> intercept this in javafxports, and we set the Screen width/height to >>>>>>>> 0/0 >>>>>>>> as >>>>>>>> we don't want to render on the (invalid) surface while we lost >>>>>>>> control. >>>>>>>> When we regain control, we resize the Screen and the app renders >>>>>>>> again. >>>>>>>> >>>>>>>> The reason we set the width/height to 0/0 is because the >>>>>>>> PresentingPainter >>>>>>>> will call SceneState.isValid() and this returns false in case >>>>>>>> getWidth() >>>>>>>> or >>>>>>>> getHeight() are 0. >>>>>>>> >>>>>>>> However, SceneState extends PresentableState and it overrides the >>>>>>>> update >>>>>>>> method. It will call PresentatbleState.update() which will set the >>>>>>>> viewWidth to the width of the new Screen (hence, 0) , but after that >>>>>>>> it >>>>>>>> overwrites the viewWidth with camera.getViewWidth(). The latter still >>>>>>>> contains the old value. A quick inspection shows that >>>>>>>> camera.setViewWidth() >>>>>>>> is called when validate(...) is called on NGDefaultCamera, which is >>>>>>>> called >>>>>>>> by ES2Context.updateRenderTarget() which happens during rendering, >>>>>>>> hence >>>>>>>> *after* the PresentingPainter checks if the width is 0. >>>>>>>> >>>>>>>> So immediately after we set the width of the Screen to 0 (on the FX >>>>>>>> App >>>>>>>> Thread), a Pulse happens, and this one still things the screen is the >>>>>>>> original size. While the pulse is happening, the android system >>>>>>>> destroys >>>>>>>> our context, and the rendering fails. Moreover, the EGL system is in a >>>>>>>> unpredictable state (recreating the surface fails). >>>>>>>> >>>>>>>> A very dirty workaround for this is to wait for 1 pulse (with the new >>>>>>>> pulselistener API this should be possible) before we return from the >>>>>>>> callback method called by Android when the surface is about to be >>>>>>>> destroyed. That way, we will have 1 bogus rendering on an existing >>>>>>>> (but >>>>>>>> about-to-be-destroyed) surface. >>>>>>>> >>>>>>>> But it would be better if there is some way to tell the quantum >>>>>>>> renderer >>>>>>>> to >>>>>>>> immediately stop rendering. Existing pulses are no problem, as the >>>>>>>> renderLock guarantuees that we set the size to 0 only when no other >>>>>>>> thread >>>>>>>> (quantum renderer) has a lock on the renderLock. >>>>>>>> >>>>>>>> - Johan >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> -- >>>>>>> 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) >>>>>>> >>>>>>> >>>>>>> >>>>>>> > -- 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 Mon Nov 23 19:01:37 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 23 Nov 2015 11:01:37 -0800 Subject: Pausing Quantum Renderer In-Reply-To: <56536140.4000709@Oracle.com> References: <564CE66B.3080109@Oracle.com> <564E3D1E.5050703@oracle.com> <5653424B.2030301@oracle.com> <56536140.4000709@Oracle.com> Message-ID: <56536291.5090600@oracle.com> I tend to agree that the current proposed solution seems minimally intrusive. The only other thought that I have is wondering whether we could treat it more like the case of a lost surface on Windows. This seems very similar to that case. -- Kevin David Hill wrote: > On 11/23/15, 11:43 AM, Morris Meyer wrote: >> As the original author of the Quantum toolkit and the renderer, this >> sort of addition goes against what I had in mind when designing the >> PaintCollector and the renderer. As the renderer is built around a >> ThreadPoolExecutor, stopping system functionality for an edge case is >> putting the cart before the horse. >> >> When a Window is miniaturized or set to zero size, or moved >> offscreen, there should be no pulses fired at the Window. > My concern with setting the window size to zero would be any > additional work that is done. If there is a layout to go to 0,0 and > then another layout when we go to the new real size then that is not > something I like. > > Pausing the processing of the rendering as has been proposed here > seems like one way to be minimally intrusive on a compute constrained > devices. > > Another options would be to set the window visibility. > > A real concern regardless of what is done is the potential problem of > multithreaded issues. > > Skipping render pulses for a period seems pretty safe from a > multithreaded point of view. It also seems to be the least likely to > cause a lot of throw away work. > > Another thought, setting a window to visible(false) at least takes it > off the rendering queue > (PaintCollector.getInstance().removeDirtyScene(this);). So in theory, > walking through the window list and marking all of them as not > visible. The problem I have with any approach along these lines is the > risk that state will be confused or lost, or that we do a lot of > additional work in a place where we are already going to cause work as > a new graphics context and display size are being dropped in. Even > something like setVisible(false) has a lot of notification work > associated with it. > > Given the above, I would tend to stick with the proposed solution. > > Dave > > >> >> This seems more like an issue of ensuring that if the window is 0x0 >> that it is not considered dirty, and if there is no dirty scene that >> nextPulseRequested() is never called. >> >> There does need to be work done on Quantum to ensure that it cycles >> down to no CPU usage when windows are hidden and/or miniaturized on >> battery operated devices. That needs to be done cleanly, but even >> then pausing the ThreadPoolExecutor seems to be the wrong way of >> going about it. The TPE model is more startup, work, then shutdown, >> and the QuantumToolkit intermediates JavaFX application state with >> that model. >> >> Best regards, >> >> --morris meyer >> >> On 11/22/15 6:24 AM, Johan Vos wrote: >>> I implemented this in the javafxports clone of the OpenJFX 8u-dev >>> repo, and >>> the diff is here: >>> >>> https://bitbucket.org/javafxports/8u-dev-rt/commits/67a0fded8208095bd04efda6045aa257e245d6bc >>> >>> >>> I am more than happy to create an issue in the openjdk bug system >>> (enhancement?) and provide a patch there as well, but I think it >>> needs a >>> bit more discussion first? >>> >>> - Johan >>> >>> On Sat, Nov 21, 2015 at 9:23 PM, Johan Vos >>> wrote: >>> >>>> I have a working implementation that needs more stress-testing on >>>> different platforms, but it seems a good and easy solution so far. >>>> I have this on QuantumToolkit: >>>> >>>> @Override >>>> public void pauseRenderer(){ >>>> Application.invokeAndWait(() -> this.pause = true); >>>> PaintCollector.getInstance().waitForRenderingToComplete(); >>>> }; >>>> >>>> public void resumeRenderer(){ >>>> Application.invokeAndWait(() -> this.pause = false); >>>> }; >>>> >>>> pause is a boolean that is checked for in >>>> void pulse(boolean collect) { ... } >>>> >>>> The difficulty I mentioned in my previous mail (how do we know >>>> there are >>>> no renderJobs pending/running) was solved easily as there exists this >>>> PaintCollector.waitForRenderingToComplete method. >>>> This might make the pauseRenderer a bit slower, and maybe this is not >>>> needed in all usecases. In that case, we can remove it from the >>>> pauseRenderer() and we can add it either in the Monocle >>>> implementation that >>>> will call pauseRenderer, or in a Android/iOS specific code. >>>> >>>> However, it seems to me that if you want to pause the renderer, you >>>> most >>>> often want to make sure no one is still writing to the glSurface >>>> after the >>>> pauseRenderer method is called, so I think it makes sense to keep >>>> it there? >>>> >>>> - Johan >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Fri, Nov 20, 2015 at 8:14 AM, Johan Vos >>>> wrote: >>>> >>>>> I didn't plan to intercept or cancel pending/submitted jobs, but I >>>>> have >>>>> to wait until they are done before the android callback method >>>>> returns. >>>>> >>>>> When Android is about to destroy the context, it will call the >>>>> surfaceTextureDestroyed method on the Activity (the FXActivity in our >>>>> case). As long as that method doesn't return, the context won't be >>>>> destroyed. But once that method returns, the context might become >>>>> invalid >>>>> any moment. So if there are still jobs that want to do a >>>>> swapBuffer after >>>>> we return, those can crash or (even worse) corrupt the egl system. >>>>> >>>>> So it seems to me inside the implementation of >>>>> surfaceTextureDestroyed, >>>>> we need to achieve 2 things: >>>>> 1. make sure no new pulses are generated. >>>>> 2. don't return while the QuantumRenderer is still executing jobs. >>>>> >>>>> Those 2 things can be combined in a single Toolkit.pauseRenderer() >>>>> but it >>>>> might be better to only achieve the first task in >>>>> Toolkit.pauseRenderer(). >>>>> The contract for this method is than that no new pulses will be >>>>> generated, but existing renderJobs might still be running when >>>>> this method >>>>> returns. >>>>> The second thing, waiting for the renderJobs to be finished, can >>>>> be done >>>>> in the Android specific implementation. >>>>> >>>>> - Johan >>>>> >>>>> >>>>> >>>>> On Thu, Nov 19, 2015 at 10:20 PM, Kevin Rushforth < >>>>> kevin.rushforth at oracle.com> wrote: >>>>> >>>>>> This might be a tricky semantic to achieve, and great care will be >>>>>> needed to ensure no deadlocks or race conditions. Not running any >>>>>> more >>>>>> pulses after this method returns seems fine, but it might be >>>>>> better to let >>>>>> any existing renderJobs run (possibly discarding the results). >>>>>> This way you >>>>>> could send the pause message to the renderer as a special >>>>>> renderJob and not >>>>>> have to worry about jobs that are scheduled but not yet run. >>>>>> >>>>>> -- Kevin >>>>>> >>>>>> >>>>>> >>>>>> Johan Vos wrote: >>>>>> >>>>>>> After some experiments, here is my current thinking: >>>>>>> >>>>>>> Toolkit can have 2 new methods: >>>>>>> pauseRenderer() >>>>>>> resumeRenderer() >>>>>>> >>>>>>> When pauseRenderer is called, it should be guaranteed that after >>>>>>> this >>>>>>> call, >>>>>>> no new pulses are fired until resumeRenderer is called. >>>>>>> That is not hard, but it is not enough. Before we pause the >>>>>>> pulses, the >>>>>>> previous pulse probably submitted a renderJob to Prism, executed >>>>>>> on the >>>>>>> QuantumRenderer ThreadPoolExecutor. That job should run fine, as >>>>>>> the >>>>>>> next >>>>>>> pulse (when we're back) will call >>>>>>> GlassScene.waitForRenderingToComplete(). >>>>>>> So we have to wait until there are no running or pending tasks >>>>>>> in the >>>>>>> QuantumRenderer as well. >>>>>>> >>>>>>> - Johan >>>>>>> >>>>>>> >>>>>>> On Wed, Nov 18, 2015 at 9:58 PM, David Hill >>>>>>> wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>>> On 11/18/15, 3:45 PM, Johan Vos wrote: >>>>>>>> >>>>>>>> Johan, >>>>>>>> I think that it would be reasonable to put in something to >>>>>>>> Quantum >>>>>>>> that causes the render loop to "pause", and then resume later. I >>>>>>>> envision >>>>>>>> this toggle as causing the render loop to skip, rather than >>>>>>>> tinkering >>>>>>>> with >>>>>>>> the pulses. >>>>>>>> >>>>>>>> When resume is called, it might be best to treat the world as >>>>>>>> dirty. >>>>>>>> >>>>>>>> Added to Toolkit, this would allow someone like Monocle to make >>>>>>>> the >>>>>>>> toggles as is appropriate. >>>>>>>> >>>>>>>> If this works for you, perhaps you could prototype it ? >>>>>>>> >>>>>>>> regards, >>>>>>>> Dave >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> On Android, a JavaFX Application might transfer control to >>>>>>>>> another app >>>>>>>>> (and >>>>>>>>> become invisible) and enter the foreground later. In that >>>>>>>>> case, the >>>>>>>>> GLSurface we are rendering on becomes invalid. In order to avoid >>>>>>>>> problems >>>>>>>>> and save battery, we want to pause the renderer thread, but this >>>>>>>>> turns out >>>>>>>>> to be more difficult than I expected. >>>>>>>>> >>>>>>>>> When our app transfers control, we get a callback from >>>>>>>>> Android. We >>>>>>>>> intercept this in javafxports, and we set the Screen >>>>>>>>> width/height to >>>>>>>>> 0/0 >>>>>>>>> as >>>>>>>>> we don't want to render on the (invalid) surface while we lost >>>>>>>>> control. >>>>>>>>> When we regain control, we resize the Screen and the app renders >>>>>>>>> again. >>>>>>>>> >>>>>>>>> The reason we set the width/height to 0/0 is because the >>>>>>>>> PresentingPainter >>>>>>>>> will call SceneState.isValid() and this returns false in case >>>>>>>>> getWidth() >>>>>>>>> or >>>>>>>>> getHeight() are 0. >>>>>>>>> >>>>>>>>> However, SceneState extends PresentableState and it overrides the >>>>>>>>> update >>>>>>>>> method. It will call PresentatbleState.update() which will set >>>>>>>>> the >>>>>>>>> viewWidth to the width of the new Screen (hence, 0) , but >>>>>>>>> after that >>>>>>>>> it >>>>>>>>> overwrites the viewWidth with camera.getViewWidth(). The >>>>>>>>> latter still >>>>>>>>> contains the old value. A quick inspection shows that >>>>>>>>> camera.setViewWidth() >>>>>>>>> is called when validate(...) is called on NGDefaultCamera, >>>>>>>>> which is >>>>>>>>> called >>>>>>>>> by ES2Context.updateRenderTarget() which happens during >>>>>>>>> rendering, >>>>>>>>> hence >>>>>>>>> *after* the PresentingPainter checks if the width is 0. >>>>>>>>> >>>>>>>>> So immediately after we set the width of the Screen to 0 (on >>>>>>>>> the FX >>>>>>>>> App >>>>>>>>> Thread), a Pulse happens, and this one still things the screen >>>>>>>>> is the >>>>>>>>> original size. While the pulse is happening, the android system >>>>>>>>> destroys >>>>>>>>> our context, and the rendering fails. Moreover, the EGL system >>>>>>>>> is in a >>>>>>>>> unpredictable state (recreating the surface fails). >>>>>>>>> >>>>>>>>> A very dirty workaround for this is to wait for 1 pulse (with >>>>>>>>> the new >>>>>>>>> pulselistener API this should be possible) before we return >>>>>>>>> from the >>>>>>>>> callback method called by Android when the surface is about to be >>>>>>>>> destroyed. That way, we will have 1 bogus rendering on an >>>>>>>>> existing >>>>>>>>> (but >>>>>>>>> about-to-be-destroyed) surface. >>>>>>>>> >>>>>>>>> But it would be better if there is some way to tell the quantum >>>>>>>>> renderer >>>>>>>>> to >>>>>>>>> immediately stop rendering. Existing pulses are no problem, as >>>>>>>>> the >>>>>>>>> renderLock guarantuees that we set the size to 0 only when no >>>>>>>>> other >>>>>>>>> thread >>>>>>>>> (quantum renderer) has a lock on the renderLock. >>>>>>>>> >>>>>>>>> - Johan >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> -- >>>>>>>> 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 Mon Nov 23 19:56:11 2015 From: james.graham at oracle.com (Jim Graham) Date: Mon, 23 Nov 2015 11:56:11 -0800 Subject: [9] Review request for 8140503: JavaFX "Pair" Hash Code Collisions In-Reply-To: <56531E7A.1050805@oracle.com> References: <56389546.7000807@oracle.com> <56390C92.2020104@oracle.com> <5639129E.40201@oracle.com> <56391407.80105@oracle.com> <56392A2A.9040701@oracle.com> <56392A99.5050806@oracle.com> <56392FA4.5080508@oracle.com> <563938A2.70000@oracle.com> <56531E7A.1050805@oracle.com> Message-ID: <56536F5B.30707@oracle.com> Looks fine to me. Perhaps the synopsis on the bug should be changed to "... hash code computation causes more collisions than it should"? ...jim On 11/23/15 6:11 AM, Vadim Pakhnushev wrote: > Guys, > Could you please review the updated fix? > > https://bugs.openjdk.java.net/browse/JDK-8140503 > http://cr.openjdk.java.net/~vadim/8140503/webrev.01/ > > Thanks, > Vadim > > On 04.11.2015 1:43, Kevin Rushforth wrote: >> Inlining it seems like a fine way to go to me, too. As another point >> of reference, we use 7/31 in other places in JavaFX. >> >> -- Kevin >> >> >> Jim Graham wrote: >>> Absolutely, this report uncovered an unrelated NPE bug which is >>> helpful, and apparently different constants might affect the >>> collision probabilities (which were already very unlikely to begin >>> with), but the bug report was definitely filed primarily as a >>> misunderstanding. >>> >>> One thing to note - perhaps small numbers are more likely to be >>> encountered so the larger the prime, the less likelihood of getting a >>> collision. I wouldn't recommend using too large of a prime since the >>> probability is already so low even with 13, and larger primes may >>> increase the size of the byte code and compiled code since larger >>> constants take more complicated instructions to deal with. Josh Bloch >>> recommended a base of 17 and a multiplier of 37 in Chapter 3 of >>> Effective Java, but he also admitted that the numbers were arbitrary >>> except for the multiplier needing to be an odd prime. >>> >>> One reason 13 might be too low depends on the probability that Pair >>> is used in hash cases with lots of very small numbers. Adding in a >>> base prime and using a little bit larger prime multiplier quickly >>> turns lots of small numbers into massively distributed hashes - even >>> with 31 or 17/37. >>> >>> I kind of feel like using the existing utility is overkill for just 2 >>> objects since it requires constructing an array object to use it. I'd >>> be just as happy (perhaps even more so) if we just upgraded the code >>> to check key for null and use a little larger prime, but keep it >>> inlined... >>> >>> ...jim >>> >>> On 11/3/15 1:43 PM, Alexander Kouznetsov wrote: >>>> Moreover, the following two sentences: >>>> >>>> "However, this is an incorrect way to compute a hash code of two >>>> values." >>>> "This can lead to hard-to-find bugs anywhere that instances of Pair are >>>> used in a data structure like a HashSet or HashTable." >>>> >>>> seem to indicate misunderstanding of what hashcode is and how it is to >>>> be used. >>>> >>>> Best regards, >>>> Alexander Kouznetsov >>>> (408) 276-0387 >>>> >>>> On 3 ??? 2015 13:42, Alexander Kouznetsov wrote: >>>>> After the fix, you should expect another incident report of >>>>> >>>>> Objects.hash(1, 0) == Objects.hash(0, 31) >>>>> >>>>> always true :-) >>>>> >>>>> I'd rather file another bug on key == null causing NPE and closing >>>>> this one as incomplete or not an issue. >>>>> >>>>> Best regards, >>>>> Alexander Kouznetsov >>>>> (408) 276-0387 >>>>> >>>>> On 3 ??? 2015 12:07, Vadim Pakhnushev wrote: >>>>>> Hmm, yeah, the actual difference is in the prime number only (that is >>>>>> changing the algorithm only doesn't improve anything), so the only >>>>>> remaining reason to fix this is that Objects.hash guards against null >>>>>> values (and I forgot to mention it in the review). >>>>>> The key in Pair could actually be null and in this case hashCode will >>>>>> throw NPE. >>>>>> >>>>>> Vadim >>>>>> >>>>>> On 03.11.2015 23:01, Vadim Pakhnushev wrote: >>>>>>> Well, not exactly... Previously it was 13*hash(a) + hash(b) and now >>>>>>> it's 31*(31 + hash(a)) + hash(b). >>>>>>> And apparently it improves the quality somehow. I did a test with >>>>>>> 100^4 combinations and collision probability dropped by the factor >>>>>>> of 3 from 0.065% to 0.022%. >>>>>>> Not really impressive, but still, and it uses well-defined utility >>>>>>> method. >>>>>>> Yeah, I know it's not really a bug since you don't want to rely on >>>>>>> the hashCode at all... >>>>>>> >>>>>>> Thanks, >>>>>>> Vadim >>>>>>> >>>>>>> On 03.11.2015 22:35, Jim Graham wrote: >>>>>>>> All this does is change the prime constant used to produce the hash >>>>>>>> value. >>>>>>>> >>>>>>>> Objects.hash(a, b) uses 31*hash(a) + hash(b) instead of the >>>>>>>> 13*hash(a) + hash(b) that the embedded implementation uses. >>>>>>>> >>>>>>>> I don't really think this is a bug. The fact that Integer objects >>>>>>>> make it easy to reverse engineer and compute collisions of any >>>>>>>> reasonable hash combination computation don't mean that the >>>>>>>> technique has a bug, it just means that the submitter can read the >>>>>>>> code and think of a counter-example. >>>>>>>> >>>>>>>> If there are practical problems being caused for some particular >>>>>>>> and popular use case by the use of this particular constant "13", >>>>>>>> then we need to understand those issues and come up with a more >>>>>>>> comprehensive solution than to simply hand off to another mechanism >>>>>>>> which uses the same procedure with a different prime constant... >>>>>>>> >>>>>>>> ...jim >>>>>>>> >>>>>>>> On 11/3/15 3:06 AM, Vadim Pakhnushev wrote: >>>>>>>>> Hi Chien, >>>>>>>>> >>>>>>>>> Could you please review the fix: >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8140503 >>>>>>>>> http://cr.openjdk.java.net/~vadim/8140503/webrev.00/ >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Vadim >>>>>>> >>>>>> >>>>> >>>> > From kevin.rushforth at oracle.com Mon Nov 23 20:12:01 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 23 Nov 2015 12:12:01 -0800 Subject: [9] Review request for 8140503: JavaFX "Pair" Hash Code Collisions In-Reply-To: <56536F5B.30707@oracle.com> References: <56389546.7000807@oracle.com> <56390C92.2020104@oracle.com> <5639129E.40201@oracle.com> <56391407.80105@oracle.com> <56392A2A.9040701@oracle.com> <56392A99.5050806@oracle.com> <56392FA4.5080508@oracle.com> <563938A2.70000@oracle.com> <56531E7A.1050805@oracle.com> <56536F5B.30707@oracle.com> Message-ID: <56537311.2060103@oracle.com> Looks good to me, too. -- Kevin Jim Graham wrote: > Looks fine to me. Perhaps the synopsis on the bug should be changed > to "... hash code computation causes more collisions than it should"? > > ...jim > > On 11/23/15 6:11 AM, Vadim Pakhnushev wrote: >> Guys, >> Could you please review the updated fix? >> >> https://bugs.openjdk.java.net/browse/JDK-8140503 >> http://cr.openjdk.java.net/~vadim/8140503/webrev.01/ >> >> Thanks, >> Vadim >> >> On 04.11.2015 1:43, Kevin Rushforth wrote: >>> Inlining it seems like a fine way to go to me, too. As another point >>> of reference, we use 7/31 in other places in JavaFX. >>> >>> -- Kevin >>> >>> >>> Jim Graham wrote: >>>> Absolutely, this report uncovered an unrelated NPE bug which is >>>> helpful, and apparently different constants might affect the >>>> collision probabilities (which were already very unlikely to begin >>>> with), but the bug report was definitely filed primarily as a >>>> misunderstanding. >>>> >>>> One thing to note - perhaps small numbers are more likely to be >>>> encountered so the larger the prime, the less likelihood of getting a >>>> collision. I wouldn't recommend using too large of a prime since the >>>> probability is already so low even with 13, and larger primes may >>>> increase the size of the byte code and compiled code since larger >>>> constants take more complicated instructions to deal with. Josh Bloch >>>> recommended a base of 17 and a multiplier of 37 in Chapter 3 of >>>> Effective Java, but he also admitted that the numbers were arbitrary >>>> except for the multiplier needing to be an odd prime. >>>> >>>> One reason 13 might be too low depends on the probability that Pair >>>> is used in hash cases with lots of very small numbers. Adding in a >>>> base prime and using a little bit larger prime multiplier quickly >>>> turns lots of small numbers into massively distributed hashes - even >>>> with 31 or 17/37. >>>> >>>> I kind of feel like using the existing utility is overkill for just 2 >>>> objects since it requires constructing an array object to use it. I'd >>>> be just as happy (perhaps even more so) if we just upgraded the code >>>> to check key for null and use a little larger prime, but keep it >>>> inlined... >>>> >>>> ...jim >>>> >>>> On 11/3/15 1:43 PM, Alexander Kouznetsov wrote: >>>>> Moreover, the following two sentences: >>>>> >>>>> "However, this is an incorrect way to compute a hash code of two >>>>> values." >>>>> "This can lead to hard-to-find bugs anywhere that instances of >>>>> Pair are >>>>> used in a data structure like a HashSet or HashTable." >>>>> >>>>> seem to indicate misunderstanding of what hashcode is and how it >>>>> is to >>>>> be used. >>>>> >>>>> Best regards, >>>>> Alexander Kouznetsov >>>>> (408) 276-0387 >>>>> >>>>> On 3 ??? 2015 13:42, Alexander Kouznetsov wrote: >>>>>> After the fix, you should expect another incident report of >>>>>> >>>>>> Objects.hash(1, 0) == Objects.hash(0, 31) >>>>>> >>>>>> always true :-) >>>>>> >>>>>> I'd rather file another bug on key == null causing NPE and closing >>>>>> this one as incomplete or not an issue. >>>>>> >>>>>> Best regards, >>>>>> Alexander Kouznetsov >>>>>> (408) 276-0387 >>>>>> >>>>>> On 3 ??? 2015 12:07, Vadim Pakhnushev wrote: >>>>>>> Hmm, yeah, the actual difference is in the prime number only >>>>>>> (that is >>>>>>> changing the algorithm only doesn't improve anything), so the only >>>>>>> remaining reason to fix this is that Objects.hash guards against >>>>>>> null >>>>>>> values (and I forgot to mention it in the review). >>>>>>> The key in Pair could actually be null and in this case hashCode >>>>>>> will >>>>>>> throw NPE. >>>>>>> >>>>>>> Vadim >>>>>>> >>>>>>> On 03.11.2015 23:01, Vadim Pakhnushev wrote: >>>>>>>> Well, not exactly... Previously it was 13*hash(a) + hash(b) and >>>>>>>> now >>>>>>>> it's 31*(31 + hash(a)) + hash(b). >>>>>>>> And apparently it improves the quality somehow. I did a test with >>>>>>>> 100^4 combinations and collision probability dropped by the factor >>>>>>>> of 3 from 0.065% to 0.022%. >>>>>>>> Not really impressive, but still, and it uses well-defined utility >>>>>>>> method. >>>>>>>> Yeah, I know it's not really a bug since you don't want to rely on >>>>>>>> the hashCode at all... >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Vadim >>>>>>>> >>>>>>>> On 03.11.2015 22:35, Jim Graham wrote: >>>>>>>>> All this does is change the prime constant used to produce the >>>>>>>>> hash >>>>>>>>> value. >>>>>>>>> >>>>>>>>> Objects.hash(a, b) uses 31*hash(a) + hash(b) instead of the >>>>>>>>> 13*hash(a) + hash(b) that the embedded implementation uses. >>>>>>>>> >>>>>>>>> I don't really think this is a bug. The fact that Integer objects >>>>>>>>> make it easy to reverse engineer and compute collisions of any >>>>>>>>> reasonable hash combination computation don't mean that the >>>>>>>>> technique has a bug, it just means that the submitter can read >>>>>>>>> the >>>>>>>>> code and think of a counter-example. >>>>>>>>> >>>>>>>>> If there are practical problems being caused for some particular >>>>>>>>> and popular use case by the use of this particular constant "13", >>>>>>>>> then we need to understand those issues and come up with a more >>>>>>>>> comprehensive solution than to simply hand off to another >>>>>>>>> mechanism >>>>>>>>> which uses the same procedure with a different prime constant... >>>>>>>>> >>>>>>>>> ...jim >>>>>>>>> >>>>>>>>> On 11/3/15 3:06 AM, Vadim Pakhnushev wrote: >>>>>>>>>> Hi Chien, >>>>>>>>>> >>>>>>>>>> Could you please review the fix: >>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8140503 >>>>>>>>>> http://cr.openjdk.java.net/~vadim/8140503/webrev.00/ >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Vadim >>>>>>>> >>>>>>> >>>>>> >>>>> >> From kevin.rushforth at oracle.com Mon Nov 23 20:16:13 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 23 Nov 2015 12:16:13 -0800 Subject: [9] API review request: 8090585: Provide an official API to start the JavaFX platform In-Reply-To: References: <564FB39E.4040801@oracle.com> <5652201C.6070709@oracle.com> Message-ID: <5653740D.3010901@oracle.com> PlatformImpl isn't API. It's an internal method in a non-public, non-documented class. I don't want to pick a less desirable name just because there is an internal method with the same name that works differently in 9. -- Kevin Ali Ebrahimi wrote: > Hi, > I know concerns here, but I think PlatformImpl.startup() and > Platform.startup() should have same behavior from caller's POW. > So I think if we can not have default behavior(duplicate calls) for > public API so please change method name. > My suggestions: Platform.safeStartup() or Platform.startPlatform > or Platform.start > > On Sun, Nov 22, 2015 at 11:35 PM, Jonathan Giles > > wrote: > > I don't believe there is any inconsistency here. We are preserving > the existing semantics in PlatformImpl.startup to not prevent > duplicate calls by default, whilst we are reversing the semantics > for the public API in Platform, where we do prevent duplicate > calls. The end result is that we have one public API > (Platform.startup) with one set of semantics (prevent duplicate > values). > > -- Jonathan > > > > On 21/11/15 11:57 PM, Ali Ebrahimi wrote: >> Hi, >> I think there is an inconsistency between : >> >> PlatformImpl.java >> public static void startup(final Runnable r) { >> + startup(r, false); //************* here default value false >> + } >> >> and >> >> Platform.java >> + public static void startup(Runnable runnable) { >> + PlatformImpl.startup(runnable, true); //******** here default value true >> + } >> >> >> On Sat, Nov 21, 2015 at 3:28 AM, Kevin Rushforth >> > >> wrote: >> >> Jonathan and all, >> >> Please review the following new API proposal to add the >> ability to explicitly start the FX runtime. >> >> https://bugs.openjdk.java.net/browse/JDK-8090585 >> http://cr.openjdk.java.net/~kcr/8090585/webrev.00/ >> >> >> -- Kevin >> >> >> >> >> -- >> >> Best Regards, >> Ali Ebrahimi > > > > > -- > > Best Regards, > Ali Ebrahimi From johan.vos at gluonhq.com Mon Nov 23 20:27:11 2015 From: johan.vos at gluonhq.com (Johan Vos) Date: Mon, 23 Nov 2015 21:27:11 +0100 Subject: Pausing Quantum Renderer In-Reply-To: <565341C8.1070705@Oracle.com> References: <564CE66B.3080109@Oracle.com> <564E3D1E.5050703@oracle.com> <565341C8.1070705@Oracle.com> Message-ID: The reason I have it in the try is because we need the finally block. In the postPulse() method, setPulseRunning() is called before the pulse() method will be called. Hence, if we want a null pulse we still have to call endPulseRunning() (which is in the finally block) or we will never have setPulseRunning() returning false anymore. - Johan On Mon, Nov 23, 2015 at 5:41 PM, David Hill wrote: > On 11/22/15, 6:24 AM, Johan Vos wrote: > > I implemented this in the javafxports clone of the OpenJFX 8u-dev repo, > and the diff is here: > > > https://bitbucket.org/javafxports/8u-dev-rt/commits/67a0fded8208095bd04efda6045aa257e245d6bc > > I am more than happy to create an issue in the openjdk bug system > (enhancement?) and provide a patch there as well, but I think it needs a > bit more discussion first? > > > My only slight concern looking at the patch is where we bail out of > pulse(). At the moment you have between: > PulseLogger.pulseStart(); > and because of the finally block, > PulseLogger.pulseEnd(); > > my first thought was that the return should be before the try block as > this is a "null" pulse. > > I think I am fine with it either way though. > > Please file a bug on this (does not need to be an enhancement). > > Dave > > > - Johan > > On Sat, Nov 21, 2015 at 9:23 PM, Johan Vos wrote: > >> I have a working implementation that needs more stress-testing on >> different platforms, but it seems a good and easy solution so far. >> I have this on QuantumToolkit: >> >> @Override >> public void pauseRenderer(){ >> Application.invokeAndWait(() -> this.pause = true); >> PaintCollector.getInstance().waitForRenderingToComplete(); >> }; >> >> public void resumeRenderer(){ >> Application.invokeAndWait(() -> this.pause = false); >> }; >> >> pause is a boolean that is checked for in >> void pulse(boolean collect) { ... } >> >> The difficulty I mentioned in my previous mail (how do we know there are >> no renderJobs pending/running) was solved easily as there exists this >> PaintCollector.waitForRenderingToComplete method. >> This might make the pauseRenderer a bit slower, and maybe this is not >> needed in all usecases. In that case, we can remove it from the >> pauseRenderer() and we can add it either in the Monocle implementation that >> will call pauseRenderer, or in a Android/iOS specific code. >> >> However, it seems to me that if you want to pause the renderer, you most >> often want to make sure no one is still writing to the glSurface after the >> pauseRenderer method is called, so I think it makes sense to keep it there? >> >> - Johan >> >> >> >> >> >> >> On Fri, Nov 20, 2015 at 8:14 AM, Johan Vos wrote: >> >>> I didn't plan to intercept or cancel pending/submitted jobs, but I have >>> to wait until they are done before the android callback method returns. >>> >>> When Android is about to destroy the context, it will call the >>> surfaceTextureDestroyed method on the Activity (the FXActivity in our >>> case). As long as that method doesn't return, the context won't be >>> destroyed. But once that method returns, the context might become invalid >>> any moment. So if there are still jobs that want to do a swapBuffer after >>> we return, those can crash or (even worse) corrupt the egl system. >>> >>> So it seems to me inside the implementation of surfaceTextureDestroyed, >>> we need to achieve 2 things: >>> 1. make sure no new pulses are generated. >>> 2. don't return while the QuantumRenderer is still executing jobs. >>> >>> Those 2 things can be combined in a single Toolkit.pauseRenderer() but >>> it might be better to only achieve the first task in >>> Toolkit.pauseRenderer(). >>> The contract for this method is than that no new pulses will be >>> generated, but existing renderJobs might still be running when this method >>> returns. >>> The second thing, waiting for the renderJobs to be finished, can be done >>> in the Android specific implementation. >>> >>> - Johan >>> >>> >>> >>> On Thu, Nov 19, 2015 at 10:20 PM, Kevin Rushforth < >>> kevin.rushforth at oracle.com> wrote: >>> >>>> This might be a tricky semantic to achieve, and great care will be >>>> needed to ensure no deadlocks or race conditions. Not running any more >>>> pulses after this method returns seems fine, but it might be better to let >>>> any existing renderJobs run (possibly discarding the results). This way you >>>> could send the pause message to the renderer as a special renderJob and not >>>> have to worry about jobs that are scheduled but not yet run. >>>> >>>> -- Kevin >>>> >>>> >>>> >>>> Johan Vos wrote: >>>> >>>>> After some experiments, here is my current thinking: >>>>> >>>>> Toolkit can have 2 new methods: >>>>> pauseRenderer() >>>>> resumeRenderer() >>>>> >>>>> When pauseRenderer is called, it should be guaranteed that after this >>>>> call, >>>>> no new pulses are fired until resumeRenderer is called. >>>>> That is not hard, but it is not enough. Before we pause the pulses, the >>>>> previous pulse probably submitted a renderJob to Prism, executed on the >>>>> QuantumRenderer ThreadPoolExecutor. That job should run fine, as the >>>>> next >>>>> pulse (when we're back) will call >>>>> GlassScene.waitForRenderingToComplete(). >>>>> So we have to wait until there are no running or pending tasks in the >>>>> QuantumRenderer as well. >>>>> >>>>> - Johan >>>>> >>>>> >>>>> On Wed, Nov 18, 2015 at 9:58 PM, David Hill >>>>> wrote: >>>>> >>>>> >>>>> >>>>>> On 11/18/15, 3:45 PM, Johan Vos wrote: >>>>>> >>>>>> Johan, >>>>>> I think that it would be reasonable to put in something to Quantum >>>>>> that causes the render loop to "pause", and then resume later. I >>>>>> envision >>>>>> this toggle as causing the render loop to skip, rather than tinkering >>>>>> with >>>>>> the pulses. >>>>>> >>>>>> When resume is called, it might be best to treat the world as dirty. >>>>>> >>>>>> Added to Toolkit, this would allow someone like Monocle to make the >>>>>> toggles as is appropriate. >>>>>> >>>>>> If this works for you, perhaps you could prototype it ? >>>>>> >>>>>> regards, >>>>>> Dave >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> On Android, a JavaFX Application might transfer control to another >>>>>>> app >>>>>>> (and >>>>>>> become invisible) and enter the foreground later. In that case, the >>>>>>> GLSurface we are rendering on becomes invalid. In order to avoid >>>>>>> problems >>>>>>> and save battery, we want to pause the renderer thread, but this >>>>>>> turns out >>>>>>> to be more difficult than I expected. >>>>>>> >>>>>>> When our app transfers control, we get a callback from Android. We >>>>>>> intercept this in javafxports, and we set the Screen width/height to >>>>>>> 0/0 >>>>>>> as >>>>>>> we don't want to render on the (invalid) surface while we lost >>>>>>> control. >>>>>>> When we regain control, we resize the Screen and the app renders >>>>>>> again. >>>>>>> >>>>>>> The reason we set the width/height to 0/0 is because the >>>>>>> PresentingPainter >>>>>>> will call SceneState.isValid() and this returns false in case >>>>>>> getWidth() >>>>>>> or >>>>>>> getHeight() are 0. >>>>>>> >>>>>>> However, SceneState extends PresentableState and it overrides the >>>>>>> update >>>>>>> method. It will call PresentatbleState.update() which will set the >>>>>>> viewWidth to the width of the new Screen (hence, 0) , but after that >>>>>>> it >>>>>>> overwrites the viewWidth with camera.getViewWidth(). The latter still >>>>>>> contains the old value. A quick inspection shows that >>>>>>> camera.setViewWidth() >>>>>>> is called when validate(...) is called on NGDefaultCamera, which is >>>>>>> called >>>>>>> by ES2Context.updateRenderTarget() which happens during rendering, >>>>>>> hence >>>>>>> *after* the PresentingPainter checks if the width is 0. >>>>>>> >>>>>>> So immediately after we set the width of the Screen to 0 (on the FX >>>>>>> App >>>>>>> Thread), a Pulse happens, and this one still things the screen is the >>>>>>> original size. While the pulse is happening, the android system >>>>>>> destroys >>>>>>> our context, and the rendering fails. Moreover, the EGL system is in >>>>>>> a >>>>>>> unpredictable state (recreating the surface fails). >>>>>>> >>>>>>> A very dirty workaround for this is to wait for 1 pulse (with the new >>>>>>> pulselistener API this should be possible) before we return from the >>>>>>> callback method called by Android when the surface is about to be >>>>>>> destroyed. That way, we will have 1 bogus rendering on an existing >>>>>>> (but >>>>>>> about-to-be-destroyed) surface. >>>>>>> >>>>>>> But it would be better if there is some way to tell the quantum >>>>>>> renderer >>>>>>> to >>>>>>> immediately stop rendering. Existing pulses are no problem, as the >>>>>>> renderLock guarantuees that we set the size to 0 only when no other >>>>>>> thread >>>>>>> (quantum renderer) has a lock on the renderLock. >>>>>>> >>>>>>> - Johan >>>>>>> >>>>>>> >>>>>>> >>>>>> -- >>>>>> 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) >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>> >> > > > -- > 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 Mon Nov 23 20:28:31 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 23 Nov 2015 12:28:31 -0800 Subject: [9] API review request: 8090585: Provide an official API to start the JavaFX platform In-Reply-To: References: <564FB39E.4040801@oracle.com> <5652201C.6070709@oracle.com> Message-ID: <565376EF.80306@oracle.com> Yes, you can just use "new Stage()" to create a stage for such an application to use. As for registering it as primary, we hadn't thought to provide such an API. I don't think it is needed, since the ability to embed the primary stage in an applet in a browser (which is not possible unless you run it as an Application via the plugin), is really the only thing that distinguishes a primary stage from any other Stage. As for launching multiple Applications, you still won't be able to do that by actually calling Application.launch more than once, but if you "roll your own" launcher you can accomplish the same thing. You can construct multiple Application objects, calling the init() and start() method of each. One thing to be aware of is that just like the JFXPanel case, you will probably want to call Platform.setImplicitExit(false) in this case. Otherwise, when the last Stage is closed, the JavaFX runtime will exit. -- Kevin Benjamin Gudehus wrote: > Wow, this patch will simplify the architecture of JavaFX testing > libraries/frameworks. > > From my perspective it is important to have a method to start the FX > runtime and thread. > > I guess one would just use `new Stage()` to create the primary Stage? Or do > we need to register the primary Stage somewhere? > > This is a great. > > As a sidenote: Another use-case for testing is to be able to call the > Application launch procedure multiple times (probably for different > Application classes) without starting the FX runtime. TestFX currently uses > custom code similar to the code in `LauncherImpl` to archive this. > > --Benjamin > > > > On Sun, Nov 22, 2015 at 9:26 PM, Ali Ebrahimi > wrote: > > >> Hi, >> I know concerns here, but I think PlatformImpl.startup() and >> Platform.startup() should have same behavior from caller's POW. >> So I think if we can not have default behavior(duplicate calls) for public >> API so please change method name. >> My suggestions: Platform.safeStartup() or Platform.startPlatform or >> Platform.start >> >> On Sun, Nov 22, 2015 at 11:35 PM, Jonathan Giles < >> jonathan.giles at oracle.com> >> wrote: >> >> >>> I don't believe there is any inconsistency here. We are preserving the >>> existing semantics in PlatformImpl.startup to not prevent duplicate calls >>> by default, whilst we are reversing the semantics for the public API in >>> Platform, where we do prevent duplicate calls. The end result is that we >>> have one public API (Platform.startup) with one set of semantics (prevent >>> duplicate values). >>> >>> -- Jonathan >>> >>> >>> On 21/11/15 11:57 PM, Ali Ebrahimi wrote: >>> >>> Hi, >>> I think there is an inconsistency between : >>> >>> PlatformImpl.java >>> >>> public static void startup(final Runnable r) { >>> + startup(r, false); //************* here default value false >>> >>> + } >>> >>> and >>> >>> Platform.java >>> >>> + public static void startup(Runnable runnable) { >>> + PlatformImpl.startup(runnable, true); //******** here default >>> >> value true >> >>> + } >>> >>> >>> >>> On Sat, Nov 21, 2015 at 3:28 AM, Kevin Rushforth < >>> kevin.rushforth at oracle.com> wrote: >>> >>> >>>> Jonathan and all, >>>> >>>> Please review the following new API proposal to add the ability to >>>> explicitly start the FX runtime. >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8090585 >>>> http://cr.openjdk.java.net/~kcr/8090585/webrev.00/ >>>> >>>> -- Kevin >>>> >>>> >>>> >>> -- >>> >>> Best Regards, >>> Ali Ebrahimi >>> >>> >>> >>> >> -- >> >> Best Regards, >> Ali Ebrahimi >> >> From vadim.pakhnushev at oracle.com Mon Nov 23 20:32:00 2015 From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev) Date: Mon, 23 Nov 2015 23:32:00 +0300 Subject: [9] Review request for 8140503: JavaFX "Pair" Hash Code Collisions In-Reply-To: <56536F5B.30707@oracle.com> References: <56389546.7000807@oracle.com> <56390C92.2020104@oracle.com> <5639129E.40201@oracle.com> <56391407.80105@oracle.com> <56392A2A.9040701@oracle.com> <56392A99.5050806@oracle.com> <56392FA4.5080508@oracle.com> <563938A2.70000@oracle.com> <56531E7A.1050805@oracle.com> <56536F5B.30707@oracle.com> Message-ID: <565377C0.4090803@oracle.com> How about "Improve javafx.util.Pair hash code computation" ? Vadim On 23.11.2015 22:56, Jim Graham wrote: > Looks fine to me. Perhaps the synopsis on the bug should be changed > to "... hash code computation causes more collisions than it should"? > > ...jim > > On 11/23/15 6:11 AM, Vadim Pakhnushev wrote: >> Guys, >> Could you please review the updated fix? >> >> https://bugs.openjdk.java.net/browse/JDK-8140503 >> http://cr.openjdk.java.net/~vadim/8140503/webrev.01/ >> >> Thanks, >> Vadim >> >> On 04.11.2015 1:43, Kevin Rushforth wrote: >>> Inlining it seems like a fine way to go to me, too. As another point >>> of reference, we use 7/31 in other places in JavaFX. >>> >>> -- Kevin >>> >>> >>> Jim Graham wrote: >>>> Absolutely, this report uncovered an unrelated NPE bug which is >>>> helpful, and apparently different constants might affect the >>>> collision probabilities (which were already very unlikely to begin >>>> with), but the bug report was definitely filed primarily as a >>>> misunderstanding. >>>> >>>> One thing to note - perhaps small numbers are more likely to be >>>> encountered so the larger the prime, the less likelihood of getting a >>>> collision. I wouldn't recommend using too large of a prime since the >>>> probability is already so low even with 13, and larger primes may >>>> increase the size of the byte code and compiled code since larger >>>> constants take more complicated instructions to deal with. Josh Bloch >>>> recommended a base of 17 and a multiplier of 37 in Chapter 3 of >>>> Effective Java, but he also admitted that the numbers were arbitrary >>>> except for the multiplier needing to be an odd prime. >>>> >>>> One reason 13 might be too low depends on the probability that Pair >>>> is used in hash cases with lots of very small numbers. Adding in a >>>> base prime and using a little bit larger prime multiplier quickly >>>> turns lots of small numbers into massively distributed hashes - even >>>> with 31 or 17/37. >>>> >>>> I kind of feel like using the existing utility is overkill for just 2 >>>> objects since it requires constructing an array object to use it. I'd >>>> be just as happy (perhaps even more so) if we just upgraded the code >>>> to check key for null and use a little larger prime, but keep it >>>> inlined... >>>> >>>> ...jim >>>> >>>> On 11/3/15 1:43 PM, Alexander Kouznetsov wrote: >>>>> Moreover, the following two sentences: >>>>> >>>>> "However, this is an incorrect way to compute a hash code of two >>>>> values." >>>>> "This can lead to hard-to-find bugs anywhere that instances of >>>>> Pair are >>>>> used in a data structure like a HashSet or HashTable." >>>>> >>>>> seem to indicate misunderstanding of what hashcode is and how it >>>>> is to >>>>> be used. >>>>> >>>>> Best regards, >>>>> Alexander Kouznetsov >>>>> (408) 276-0387 >>>>> >>>>> On 3 ??? 2015 13:42, Alexander Kouznetsov wrote: >>>>>> After the fix, you should expect another incident report of >>>>>> >>>>>> Objects.hash(1, 0) == Objects.hash(0, 31) >>>>>> >>>>>> always true :-) >>>>>> >>>>>> I'd rather file another bug on key == null causing NPE and closing >>>>>> this one as incomplete or not an issue. >>>>>> >>>>>> Best regards, >>>>>> Alexander Kouznetsov >>>>>> (408) 276-0387 >>>>>> >>>>>> On 3 ??? 2015 12:07, Vadim Pakhnushev wrote: >>>>>>> Hmm, yeah, the actual difference is in the prime number only >>>>>>> (that is >>>>>>> changing the algorithm only doesn't improve anything), so the only >>>>>>> remaining reason to fix this is that Objects.hash guards against >>>>>>> null >>>>>>> values (and I forgot to mention it in the review). >>>>>>> The key in Pair could actually be null and in this case hashCode >>>>>>> will >>>>>>> throw NPE. >>>>>>> >>>>>>> Vadim >>>>>>> >>>>>>> On 03.11.2015 23:01, Vadim Pakhnushev wrote: >>>>>>>> Well, not exactly... Previously it was 13*hash(a) + hash(b) and >>>>>>>> now >>>>>>>> it's 31*(31 + hash(a)) + hash(b). >>>>>>>> And apparently it improves the quality somehow. I did a test with >>>>>>>> 100^4 combinations and collision probability dropped by the factor >>>>>>>> of 3 from 0.065% to 0.022%. >>>>>>>> Not really impressive, but still, and it uses well-defined utility >>>>>>>> method. >>>>>>>> Yeah, I know it's not really a bug since you don't want to rely on >>>>>>>> the hashCode at all... >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Vadim >>>>>>>> >>>>>>>> On 03.11.2015 22:35, Jim Graham wrote: >>>>>>>>> All this does is change the prime constant used to produce the >>>>>>>>> hash >>>>>>>>> value. >>>>>>>>> >>>>>>>>> Objects.hash(a, b) uses 31*hash(a) + hash(b) instead of the >>>>>>>>> 13*hash(a) + hash(b) that the embedded implementation uses. >>>>>>>>> >>>>>>>>> I don't really think this is a bug. The fact that Integer objects >>>>>>>>> make it easy to reverse engineer and compute collisions of any >>>>>>>>> reasonable hash combination computation don't mean that the >>>>>>>>> technique has a bug, it just means that the submitter can read >>>>>>>>> the >>>>>>>>> code and think of a counter-example. >>>>>>>>> >>>>>>>>> If there are practical problems being caused for some particular >>>>>>>>> and popular use case by the use of this particular constant "13", >>>>>>>>> then we need to understand those issues and come up with a more >>>>>>>>> comprehensive solution than to simply hand off to another >>>>>>>>> mechanism >>>>>>>>> which uses the same procedure with a different prime constant... >>>>>>>>> >>>>>>>>> ...jim >>>>>>>>> >>>>>>>>> On 11/3/15 3:06 AM, Vadim Pakhnushev wrote: >>>>>>>>>> Hi Chien, >>>>>>>>>> >>>>>>>>>> Could you please review the fix: >>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8140503 >>>>>>>>>> http://cr.openjdk.java.net/~vadim/8140503/webrev.00/ >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Vadim >>>>>>>> >>>>>>> >>>>>> >>>>> >> From kevin.rushforth at oracle.com Mon Nov 23 21:09:42 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 23 Nov 2015 13:09:42 -0800 Subject: 9-dev unlocked following sanity testing Message-ID: <56538096.6090501@oracle.com> From fbrunnerlist at gmx.ch Mon Nov 23 23:15:26 2015 From: fbrunnerlist at gmx.ch (Florian Brunner) Date: Tue, 24 Nov 2015 00:15:26 +0100 Subject: JavaFX community site Message-ID: <1572520.mxpv0WpSaN@andor> Hi, There used to be a JavaFX community site with a nice blog aggregator and other useful information: http://community.java.net/community/javafx Now this gets redirected to a seemingly new platform: https://community.oracle.com/community/java The actual new sub-site for JavaFX can be found at (quite hidden, unfortunately): https://community.oracle.com/community/java/java_desktop/javafx_2.0_and_later Please fix the redirect link. Unfortunately, this site only seems to aggragte forum posts - no blog aggregator or other information. It would be great if you could bring those back. -Florian From kevin.rushforth at oracle.com Tue Nov 24 19:49:29 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 24 Nov 2015 11:49:29 -0800 Subject: Verona (JEP 223) Integration to JDK 9 Message-ID: <5654BF49.5030707@oracle.com> Hi, The Verona (JEP 223) Integration to JDK 9 is planned for next week as announced on the jdk9-dev mailing list [1]. This will have a small impact on JavaFX in that we will skip next week's integration from FX 9-dev into 9 master, for the same reason as the JDK. The anticipated FX-specific dates are: On or before Mon 30 Nov - Sync FX sandbox-9-verona [2] with FX 9 MASTER (build 94) Mon 30 Nov (evening) or Tue 1 Dec (morning) - Integrate sandbox-9-verona to 9 (MASTER) Wed 2 Dec - After promotion, sync down to FX 9-dev and sandbox-9-jake Thanks. -- Kevin [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-November/003100.html [2] http://hg.openjdk.java.net/openjfx/sandbox-9-verona/rt From donald.smith at oracle.com Tue Nov 24 20:26:34 2015 From: donald.smith at oracle.com (Donald Smith) Date: Tue, 24 Nov 2015 15:26:34 -0500 Subject: JavaFX community site In-Reply-To: <1572520.mxpv0WpSaN@andor> References: <1572520.mxpv0WpSaN@andor> Message-ID: <5654C7FA.1090502@oracle.com> Thanks, I've forwarded on to the community.oracle.com folks -- will let you know if I hear any reason why not to do it. Cheers, - Don On 23/11/2015 6:15 PM, Florian Brunner wrote: > Hi, > > There used to be a JavaFX community site with a nice blog aggregator and other > useful information: http://community.java.net/community/javafx > > Now this gets redirected to a seemingly new platform: > https://community.oracle.com/community/java > > The actual new sub-site for JavaFX can be found at (quite hidden, > unfortunately): > https://community.oracle.com/community/java/java_desktop/javafx_2.0_and_later > > Please fix the redirect link. > > Unfortunately, this site only seems to aggragte forum posts - no blog > aggregator or other information. > > It would be great if you could bring those back. > > -Florian From sven.reimers at gmail.com Tue Nov 24 20:31:24 2015 From: sven.reimers at gmail.com (Sven Reimers) Date: Tue, 24 Nov 2015 21:31:24 +0100 Subject: JavaFX community site In-Reply-To: <5654C7FA.1090502@oracle.com> References: <1572520.mxpv0WpSaN@andor> <5654C7FA.1090502@oracle.com> Message-ID: I already contacted people in charge (the reply all got me one more time). I think if we want to have a special area we should figure out someone who is willing to put some effort into adding content... The best aggregator out there is Jonathans Blog at the moment Ideas? Suggestions? Thanks Sven On Tue, Nov 24, 2015 at 9:26 PM, Donald Smith wrote: > Thanks, I've forwarded on to the community.oracle.com folks -- will let > you know if I hear any reason why not to do it. > > Cheers, > > - Don > > > On 23/11/2015 6:15 PM, Florian Brunner wrote: > >> Hi, >> >> There used to be a JavaFX community site with a nice blog aggregator and >> other >> useful information: http://community.java.net/community/javafx >> >> Now this gets redirected to a seemingly new platform: >> https://community.oracle.com/community/java >> >> The actual new sub-site for JavaFX can be found at (quite hidden, >> unfortunately): >> >> https://community.oracle.com/community/java/java_desktop/javafx_2.0_and_later >> >> Please fix the redirect link. >> >> Unfortunately, this site only seems to aggragte forum posts - no blog >> aggregator or other information. >> >> It would be great if you could bring those back. >> >> -Florian >> > > -- 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 james.graham at oracle.com Tue Nov 24 20:41:09 2015 From: james.graham at oracle.com (Jim Graham) Date: Tue, 24 Nov 2015 12:41:09 -0800 Subject: [9] Review request for 8140503: JavaFX "Pair" Hash Code Collisions In-Reply-To: <565377C0.4090803@oracle.com> References: <56389546.7000807@oracle.com> <56390C92.2020104@oracle.com> <5639129E.40201@oracle.com> <56391407.80105@oracle.com> <56392A2A.9040701@oracle.com> <56392A99.5050806@oracle.com> <56392FA4.5080508@oracle.com> <563938A2.70000@oracle.com> <56531E7A.1050805@oracle.com> <56536F5B.30707@oracle.com> <565377C0.4090803@oracle.com> Message-ID: <5654CB65.906@oracle.com> That sounds good. ...jim On 11/23/15 12:32 PM, Vadim Pakhnushev wrote: > How about "Improve javafx.util.Pair hash code computation" ? > > Vadim > > On 23.11.2015 22:56, Jim Graham wrote: >> Looks fine to me. Perhaps the synopsis on the bug should be changed >> to "... hash code computation causes more collisions than it should"? >> >> ...jim >> >> On 11/23/15 6:11 AM, Vadim Pakhnushev wrote: >>> Guys, >>> Could you please review the updated fix? >>> >>> https://bugs.openjdk.java.net/browse/JDK-8140503 >>> http://cr.openjdk.java.net/~vadim/8140503/webrev.01/ >>> >>> Thanks, >>> Vadim >>> >>> On 04.11.2015 1:43, Kevin Rushforth wrote: >>>> Inlining it seems like a fine way to go to me, too. As another point >>>> of reference, we use 7/31 in other places in JavaFX. >>>> >>>> -- Kevin >>>> >>>> >>>> Jim Graham wrote: >>>>> Absolutely, this report uncovered an unrelated NPE bug which is >>>>> helpful, and apparently different constants might affect the >>>>> collision probabilities (which were already very unlikely to begin >>>>> with), but the bug report was definitely filed primarily as a >>>>> misunderstanding. >>>>> >>>>> One thing to note - perhaps small numbers are more likely to be >>>>> encountered so the larger the prime, the less likelihood of getting a >>>>> collision. I wouldn't recommend using too large of a prime since the >>>>> probability is already so low even with 13, and larger primes may >>>>> increase the size of the byte code and compiled code since larger >>>>> constants take more complicated instructions to deal with. Josh Bloch >>>>> recommended a base of 17 and a multiplier of 37 in Chapter 3 of >>>>> Effective Java, but he also admitted that the numbers were arbitrary >>>>> except for the multiplier needing to be an odd prime. >>>>> >>>>> One reason 13 might be too low depends on the probability that Pair >>>>> is used in hash cases with lots of very small numbers. Adding in a >>>>> base prime and using a little bit larger prime multiplier quickly >>>>> turns lots of small numbers into massively distributed hashes - even >>>>> with 31 or 17/37. >>>>> >>>>> I kind of feel like using the existing utility is overkill for just 2 >>>>> objects since it requires constructing an array object to use it. I'd >>>>> be just as happy (perhaps even more so) if we just upgraded the code >>>>> to check key for null and use a little larger prime, but keep it >>>>> inlined... >>>>> >>>>> ...jim >>>>> >>>>> On 11/3/15 1:43 PM, Alexander Kouznetsov wrote: >>>>>> Moreover, the following two sentences: >>>>>> >>>>>> "However, this is an incorrect way to compute a hash code of two >>>>>> values." >>>>>> "This can lead to hard-to-find bugs anywhere that instances of >>>>>> Pair are >>>>>> used in a data structure like a HashSet or HashTable." >>>>>> >>>>>> seem to indicate misunderstanding of what hashcode is and how it >>>>>> is to >>>>>> be used. >>>>>> >>>>>> Best regards, >>>>>> Alexander Kouznetsov >>>>>> (408) 276-0387 >>>>>> >>>>>> On 3 ??? 2015 13:42, Alexander Kouznetsov wrote: >>>>>>> After the fix, you should expect another incident report of >>>>>>> >>>>>>> Objects.hash(1, 0) == Objects.hash(0, 31) >>>>>>> >>>>>>> always true :-) >>>>>>> >>>>>>> I'd rather file another bug on key == null causing NPE and closing >>>>>>> this one as incomplete or not an issue. >>>>>>> >>>>>>> Best regards, >>>>>>> Alexander Kouznetsov >>>>>>> (408) 276-0387 >>>>>>> >>>>>>> On 3 ??? 2015 12:07, Vadim Pakhnushev wrote: >>>>>>>> Hmm, yeah, the actual difference is in the prime number only >>>>>>>> (that is >>>>>>>> changing the algorithm only doesn't improve anything), so the only >>>>>>>> remaining reason to fix this is that Objects.hash guards against >>>>>>>> null >>>>>>>> values (and I forgot to mention it in the review). >>>>>>>> The key in Pair could actually be null and in this case hashCode >>>>>>>> will >>>>>>>> throw NPE. >>>>>>>> >>>>>>>> Vadim >>>>>>>> >>>>>>>> On 03.11.2015 23:01, Vadim Pakhnushev wrote: >>>>>>>>> Well, not exactly... Previously it was 13*hash(a) + hash(b) and >>>>>>>>> now >>>>>>>>> it's 31*(31 + hash(a)) + hash(b). >>>>>>>>> And apparently it improves the quality somehow. I did a test with >>>>>>>>> 100^4 combinations and collision probability dropped by the factor >>>>>>>>> of 3 from 0.065% to 0.022%. >>>>>>>>> Not really impressive, but still, and it uses well-defined utility >>>>>>>>> method. >>>>>>>>> Yeah, I know it's not really a bug since you don't want to rely on >>>>>>>>> the hashCode at all... >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Vadim >>>>>>>>> >>>>>>>>> On 03.11.2015 22:35, Jim Graham wrote: >>>>>>>>>> All this does is change the prime constant used to produce the >>>>>>>>>> hash >>>>>>>>>> value. >>>>>>>>>> >>>>>>>>>> Objects.hash(a, b) uses 31*hash(a) + hash(b) instead of the >>>>>>>>>> 13*hash(a) + hash(b) that the embedded implementation uses. >>>>>>>>>> >>>>>>>>>> I don't really think this is a bug. The fact that Integer objects >>>>>>>>>> make it easy to reverse engineer and compute collisions of any >>>>>>>>>> reasonable hash combination computation don't mean that the >>>>>>>>>> technique has a bug, it just means that the submitter can read >>>>>>>>>> the >>>>>>>>>> code and think of a counter-example. >>>>>>>>>> >>>>>>>>>> If there are practical problems being caused for some particular >>>>>>>>>> and popular use case by the use of this particular constant "13", >>>>>>>>>> then we need to understand those issues and come up with a more >>>>>>>>>> comprehensive solution than to simply hand off to another >>>>>>>>>> mechanism >>>>>>>>>> which uses the same procedure with a different prime constant... >>>>>>>>>> >>>>>>>>>> ...jim >>>>>>>>>> >>>>>>>>>> On 11/3/15 3:06 AM, Vadim Pakhnushev wrote: >>>>>>>>>>> Hi Chien, >>>>>>>>>>> >>>>>>>>>>> Could you please review the fix: >>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8140503 >>>>>>>>>>> http://cr.openjdk.java.net/~vadim/8140503/webrev.00/ >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Vadim >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>> > From jonathan.giles at oracle.com Tue Nov 24 20:47:45 2015 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Wed, 25 Nov 2015 09:47:45 +1300 Subject: JavaFX community site In-Reply-To: References: <1572520.mxpv0WpSaN@andor> <5654C7FA.1090502@oracle.com> Message-ID: <5654CCF1.9070505@oracle.com> Given I've been name checked I'll respond :-) I believe the JavaFX Community site was automated - it basically aggregated a number of blogs regardless of the individual blog posts relevance. The challenge was the upfront discovery of relevant websites and adding them to the aggregator. I am a little more discerning on my website (either jonathangiles.net or fxexperience.com), but I try not to exclude anything if there is some relevance. I guess the question becomes: what do people want? An RSS aggregator from a curated list of authors (where there will invariably be some irrelevant 'noise'), or something else? I am happy to help where I can. -- Jonathan On 25/11/15 9:31 AM, Sven Reimers wrote: > I already contacted people in charge (the reply all got me one more time). > > I think if we want to have a special area we should figure out someone who > is willing to put some effort into adding content... > > The best aggregator out there is Jonathans Blog at the moment > > Ideas? Suggestions? > > Thanks > > Sven > > On Tue, Nov 24, 2015 at 9:26 PM, Donald Smith > wrote: > >> Thanks, I've forwarded on to the community.oracle.com folks -- will let >> you know if I hear any reason why not to do it. >> >> Cheers, >> >> - Don >> >> >> On 23/11/2015 6:15 PM, Florian Brunner wrote: >> >>> Hi, >>> >>> There used to be a JavaFX community site with a nice blog aggregator and >>> other >>> useful information: http://community.java.net/community/javafx >>> >>> Now this gets redirected to a seemingly new platform: >>> https://community.oracle.com/community/java >>> >>> The actual new sub-site for JavaFX can be found at (quite hidden, >>> unfortunately): >>> >>> https://community.oracle.com/community/java/java_desktop/javafx_2.0_and_later >>> >>> Please fix the redirect link. >>> >>> Unfortunately, this site only seems to aggragte forum posts - no blog >>> aggregator or other information. >>> >>> It would be great if you could bring those back. >>> >>> -Florian >>> >> > From brianfromoregon at gmail.com Tue Nov 24 21:30:00 2015 From: brianfromoregon at gmail.com (Brian Harris) Date: Tue, 24 Nov 2015 13:30:00 -0800 Subject: JavaFX dependency injection In-Reply-To: <5652D08F.7080000@bestsolution.at> References: <5652D08F.7080000@bestsolution.at> Message-ID: Thanks Tom. Oracle fx team would be nice to hear your guidance as well. On Mon, Nov 23, 2015 at 12:38 AM, Tom Schindl wrote: > JavaFX is a UI-Toolkit and not an UI-Framework, JavaFX provides all the > hooks needed to integrate with whatever DI-Container (Sping, Guice, ...) > you want it to run on. > > I would go for 1. as the general recommendation and there are frameworks > out there who do exactly this type of thing. > > Tom > > On 21.11.15 22:59, Nitin Malik wrote: > > This was asked recently ( > > > http://mail.openjdk.java.net/pipermail/openjfx-dev/2015-October/018080.html > ) > > but I didnt see this addressed. > > > > Are there plans to have better integration with DI frameworks for views > and > > controllers? > > > > For example, we have scenarios where multiple instances of the same view > > and controllers need to instantiated with different values. This is a > > frequent question that pops up on Stackoverflow and there apparently is > no > > standard answer. It would help if suggested recipes and guidelines are > made > > available. > > > > The solutions we have adopted - > > 1. Use a controller factory to lookup Spring bean (this isnt ideal > because > > the factory needs to be aware of the bean name). > > 1a. For singleton controllers, the lookup can be done via class name. > > 2. Use a controller factory that holds a reference to a controller that > was > > constructed in code with the various parameters. > > 3. An Afterburner-like framework that scans controller for an annotation > > and injects the values. > > > > Regards, > > Nitin > > > > > -- > 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 eryzhikov at gmail.com Tue Nov 24 21:55:14 2015 From: eryzhikov at gmail.com (Eugene Ryzhikov) Date: Tue, 24 Nov 2015 16:55:14 -0500 Subject: Subject: JavaFX dependency injection In-Reply-To: References: Message-ID: <62DEFBF6-8CB3-4A4C-B002-AF69FCD65342@hotmail.com> At Gluon we?ve open-sourced the framework called Ignite just for this purpose. With this library, developers can use popular dependency injection frameworks in their JavaFX applications, including inside their FXML controllers. Gluon Ignite creates a common abstraction over several popular dependency injection frameworks (currently Guice, Spring, and Dagger). Full support of JSR-330 makes using dependency injection in JavaFX applications trivial. For more information take a look at our blog at http://gluonhq.com/announcing-gluon-ignite-easy-javafx-dependency-injection/ Eugene From nmalik1 at gmail.com Wed Nov 25 01:07:50 2015 From: nmalik1 at gmail.com (Nitin Malik) Date: Tue, 24 Nov 2015 20:07:50 -0500 Subject: Fwd: Subject: JavaFX dependency injection In-Reply-To: References: <62DEFBF6-8CB3-4A4C-B002-AF69FCD65342@hotmail.com> Message-ID: + mailgroup ---------- Forwarded message ---------- From: Nitin Malik Date: Tue, Nov 24, 2015 at 8:03 PM Subject: Re: Subject: JavaFX dependency injection To: Eugene Ryzhikov Hi Eugene, This look promising, but I dont think it addresses the multiple controller scenario (#1) I outlined in my original mail. Specifically looking at this line , the lookup is by class, not Spring bean. Are there plans to add support for this? Regards, Nitin On Tue, Nov 24, 2015 at 4:55 PM, Eugene Ryzhikov wrote: > > At Gluon we?ve open-sourced the framework called Ignite just for this > purpose. > > With this library, developers can use popular dependency injection > frameworks in their JavaFX applications, including inside their FXML > controllers. Gluon Ignite creates a common abstraction over several popular > dependency injection frameworks (currently Guice, Spring, and Dagger). Full > support of JSR-330 makes using dependency injection in JavaFX applications > trivial. > > For more information take a look at our blog at > > http://gluonhq.com/announcing-gluon-ignite-easy-javafx-dependency-injection/ > > Eugene > > > From vadim.pakhnushev at oracle.com Wed Nov 25 13:37:54 2015 From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev) Date: Wed, 25 Nov 2015 16:37:54 +0300 Subject: [9] Review request for 8139841: Axis class does not render ticks marks when tick labels are invisible Message-ID: <5655B9B2.902@oracle.com> Jonathan, Please review the fix: https://bugs.openjdk.java.net/browse/JDK-8139841 http://cr.openjdk.java.net/~vadim/8139841/webrev.00/ Thanks, Vadim From larry at answerrocket.com Wed Nov 25 14:33:04 2015 From: larry at answerrocket.com (Lawrence Parker) Date: Wed, 25 Nov 2015 09:33:04 -0500 Subject: TableCell.getTableRow() return value Message-ID: <6DA9A9B0-19A5-4A9E-9CAD-95D34D69A01A@answerrocket.com> Seems like getTableRow() should return TableRow instead of just TableRow. That way I wouldn?t have to cast getItem(). https://docs.oracle.com/javase/8/javafx/api/javafx/scene/control/TableCell.html @Override public void updateItem(Boolean isEnabled, boolean empty) { ... TestCase testCase = (TestCase)getTableRow().getItem(); This would be nicer: TestCase testCase = getTableRow().getItem(); Seems like an easy change to the getTableRow() method: public class TableCell extends IndexedCell { ... public final TableRow getTableRow() { return tableRow.get(); } Was this an oversight, or is there a reason that getTableRow() needs to return TableRow instead of TableRow? Thanks for any help. -Larry From nmalik1 at gmail.com Wed Nov 25 15:29:48 2015 From: nmalik1 at gmail.com (Nitin Malik) Date: Wed, 25 Nov 2015 10:29:48 -0500 Subject: Fwd: Subject: JavaFX dependency injection In-Reply-To: <6619398A-0103-4700-8E06-048090616731@gmail.com> References: <62DEFBF6-8CB3-4A4C-B002-AF69FCD65342@hotmail.com> <6619398A-0103-4700-8E06-048090616731@gmail.com> Message-ID: + mailgroup I dont think its non-standard. We have solved this by creating a factory that holds the bean id (and does a lookup when callback is invoked). Alternatively, to make the solution Spring-free, the factory can hold the controller object. Both these approaches work, but seem like a work around due to the restrictive API. I would like to get inputs from the Oracle folks on this. Nitin ---------- Forwarded message ---------- From: Eugene Ryzhikov Date: Tue, Nov 24, 2015 at 8:22 PM Subject: Re: Subject: JavaFX dependency injection To: Nitin Malik Cc: openjfx-dev Nitin, Ignite makes use of standard JavaFX API, which provides only controller class as a parameter to a controller factory. I imagine you're proposing that access to bean id would be given in some non-standard way? In any case, Ignite is an open source framework, and any type of contributions are welcome. If you have an idea which can add to existing functionality, please send us a pull request. We?ll be glad to discuss it. Eugene From: Nitin Malik Date: Tuesday, November 24, 2015 at 8:03 PM To: Eugene Ryzhikov Subject: Re: Subject: JavaFX dependency injection Hi Eugene, This look promising, but I dont think it addresses the multiple controller scenario (#1) I outlined in my original mail. Specifically looking at this line , the lookup is by class, not Spring bean. Are there plans to add support for this? Regards, Nitin On Tue, Nov 24, 2015 at 4:55 PM, Eugene Ryzhikov wrote: > > At Gluon we?ve open-sourced the framework called Ignite just for this > purpose. > > With this library, developers can use popular dependency injection > frameworks in their JavaFX applications, including inside their FXML > controllers. Gluon Ignite creates a common abstraction over several popular > dependency injection frameworks (currently Guice, Spring, and Dagger). Full > support of JSR-330 makes using dependency injection in JavaFX applications > trivial. > > For more information take a look at our blog at > > http://gluonhq.com/announcing-gluon-ignite-easy-javafx-dependency-injection/ > > Eugene > > > From matthieu at brouillard.fr Wed Nov 25 16:01:28 2015 From: matthieu at brouillard.fr (Matthieu BROUILLARD) Date: Wed, 25 Nov 2015 17:01:28 +0100 Subject: Subject: JavaFX dependency injection In-Reply-To: References: <62DEFBF6-8CB3-4A4C-B002-AF69FCD65342@hotmail.com> <6619398A-0103-4700-8E06-048090616731@gmail.com> Message-ID: Hi, This is not a new subject and I guess we already received answers in the past on this list: JavaFX team does not provide any DI mechanism just like core java teams do not provide any DI on java-se. What is provided is "only" the possibility to hook controller factory (which allows already a lot). It has been for a while since people started to use DI for JavaFX: - guice blog post July 2012: http://andrewtill.blogspot.be/2012/07/creating-javafx-controllers-using-guice.html - CDI blog post August 2012 : http://blog.matthieu.brouillard.fr/2012/08/06/fxml-javafx-powered-by-cdi-jboss-weld_6/ - then Adam Bien provided Afterburner in April 2013 : https://github.com/AdamBien/afterburner.fx - you can even use another DI engine with afterburner : http://blog.matthieu.brouillard.fr/2014/12/05/topgun-afterburner-finally-announced/ At AGFA, we used to have our own little CDI based framework to do DI, but we stopped due to memory consumption of weld-client at that time. As currently the only information provided by the controller factory is the controller class I would suggest you to use that instead of a bean id. And if you want a maintained javafx enabled DI framework, go with Afterburner or Gluon Ignite. Matthieu On Wed, Nov 25, 2015 at 4:29 PM, Nitin Malik wrote: > + mailgroup > > I dont think its non-standard. We have solved this by creating a factory > that holds the bean id (and does a lookup when callback is invoked). > Alternatively, to make the solution Spring-free, the factory can hold the > controller object. > > Both these approaches work, but seem like a work around due to the > restrictive API. > > I would like to get inputs from the Oracle folks on this. > > Nitin > > > ---------- Forwarded message ---------- > From: Eugene Ryzhikov > Date: Tue, Nov 24, 2015 at 8:22 PM > Subject: Re: Subject: JavaFX dependency injection > To: Nitin Malik > Cc: openjfx-dev > > > Nitin, > > Ignite makes use of standard JavaFX API, which provides only controller > class as a parameter to a controller factory. > I imagine you're proposing that access to bean id would be given in some > non-standard way? > > In any case, Ignite is an open source framework, and any type of > contributions are welcome. > If you have an idea which can add to existing functionality, please send us > a pull request. We?ll be glad to discuss it. > > Eugene > > From: Nitin Malik > Date: Tuesday, November 24, 2015 at 8:03 PM > To: Eugene Ryzhikov > Subject: Re: Subject: JavaFX dependency injection > > Hi Eugene, > > This look promising, but I dont think it addresses the multiple controller > scenario (#1) I outlined in my original mail. > > Specifically looking at this line > < > https://bitbucket.org/gluon-oss/ignite/src/c85197b33852b78b1a519dca2b1424314cb899fb/spring/src/main/java/com/gluonhq/ignite/spring/SpringContext.java?at=default&fileviewer=file-view-default#SpringContext.java-89 > >, > the lookup is by class, not Spring bean. Are there plans to add support for > this? > > Regards, > Nitin > > > On Tue, Nov 24, 2015 at 4:55 PM, Eugene Ryzhikov > wrote: > > > > > At Gluon we?ve open-sourced the framework called Ignite just for this > > purpose. > > > > With this library, developers can use popular dependency injection > > frameworks in their JavaFX applications, including inside their FXML > > controllers. Gluon Ignite creates a common abstraction over several > popular > > dependency injection frameworks (currently Guice, Spring, and Dagger). > Full > > support of JSR-330 makes using dependency injection in JavaFX > applications > > trivial. > > > > For more information take a look at our blog at > > > > > http://gluonhq.com/announcing-gluon-ignite-easy-javafx-dependency-injection/ > > > > Eugene > > > > > > > From danno.ferrin at oracle.com Wed Nov 25 16:38:01 2015 From: danno.ferrin at oracle.com (Danno Ferrin) Date: Wed, 25 Nov 2015 09:38:01 -0700 Subject: Bulk packager integration Message-ID: Kevin, Chris, Dmitry This is a bulk packager integration from the packager sandbox to the JavaFX Sandbox, please review. webrev: There are three changes outside of the fxpackager module that I think Kevin needs to give his approval for. Two changes are in the build.gradle. The first adds a concept of classesModuleExclude which is a regexp for files to exclude from the modular jar. This is to support creating the ant jar outside of the module system so that ant can read the required types and classes. The second change is to introduce JDK9_MODULES, read off of an environmental variable. This should point to your jmods directory (not explored modules, this must be jmods). This is to support the packagerdev target which now needs a pointer to the jmods which as of yet does not have a standard location relative to the JDK/JRE. The third change is the addition of another module-info.java.extra file. This one exposes the invocation API for JDeps to packager so the detectmodules can use it to sniff out modules from the classpath. The remainder of the changes are internal to the fxpackager modules and represent contributions from Chris Bensen, Dmitry Cherepanov, and myself finishing out the last details for JEP275. This patch should make it feature complete (but not bug complete, we got another milestone for that). --Danno From danno.ferrin at oracle.com Wed Nov 25 16:51:06 2015 From: danno.ferrin at oracle.com (Danno Ferrin) Date: Wed, 25 Nov 2015 09:51:06 -0700 Subject: Bulk packager integration In-Reply-To: References: Message-ID: <7552A67A-2D59-4FF5-B9FC-3F9E7A1E15BC@oracle.com> Here's the webrev: http://cr.openjdk.java.net/~shemnon/8080531/webrev.07/ (it's been a stressful morning) > On Nov 25, 2015, at 9:38 AM, Danno Ferrin wrote: > > Kevin, Chris, Dmitry > > This is a bulk packager integration from the packager sandbox to the JavaFX Sandbox, please review. > > webrev: > > There are three changes outside of the fxpackager module that I think Kevin needs to give his approval for. > > Two changes are in the build.gradle. The first adds a concept of classesModuleExclude which is a regexp for files to exclude from the modular jar. This is to support creating the ant jar outside of the module system so that ant can read the required types and classes. > > The second change is to introduce JDK9_MODULES, read off of an environmental variable. This should point to your jmods directory (not explored modules, this must be jmods). This is to support the packagerdev target which now needs a pointer to the jmods which as of yet does not have a standard location relative to the JDK/JRE. > > The third change is the addition of another module-info.java.extra file. This one exposes the invocation API for JDeps to packager so the detectmodules can use it to sniff out modules from the classpath. > > The remainder of the changes are internal to the fxpackager modules and represent contributions from Chris Bensen, Dmitry Cherepanov, and myself finishing out the last details for JEP275. This patch should make it feature complete (but not bug complete, we got another milestone for that). > > --Danno From jonathan.giles at oracle.com Wed Nov 25 16:57:13 2015 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Thu, 26 Nov 2015 05:57:13 +1300 Subject: TableCell.getTableRow() return value In-Reply-To: <6DA9A9B0-19A5-4A9E-9CAD-95D34D69A01A@answerrocket.com> References: <6DA9A9B0-19A5-4A9E-9CAD-95D34D69A01A@answerrocket.com> Message-ID: <48242950-9A01-4DDD-B0BB-641898FC8A0D@oracle.com> It was an oversight at the time, and (from memory) is now a breaking change to fix it, so for now it remains as it is, sadly. -- Jonathan Sent from a touch device. Please excuse my brevity. On 26 November 2015 03:33:04 GMT+13:00, Lawrence Parker wrote: >Seems like getTableRow() should return TableRow instead of just >TableRow. That way I wouldn?t have to cast getItem(). > > https://docs.oracle.com/javase/8/javafx/api/javafx/scene/control/TableCell.html > > > > > > @Override > public void updateItem(Boolean isEnabled, boolean empty) { >... > TestCase testCase = (TestCase)getTableRow().getItem(); > >This would be nicer: > > TestCase testCase = getTableRow().getItem(); > >Seems like an easy change to the getTableRow() method: > >public class TableCell extends IndexedCell { >... > public final TableRow getTableRow() { return tableRow.get(); } > > >Was this an oversight, or is there a reason that getTableRow() needs to >return TableRow instead of TableRow? > >Thanks for any help. > >-Larry From richard.bair at oracle.com Wed Nov 25 17:46:15 2015 From: richard.bair at oracle.com (Richard Bair) Date: Wed, 25 Nov 2015 09:46:15 -0800 Subject: TableCell.getTableRow() return value In-Reply-To: <48242950-9A01-4DDD-B0BB-641898FC8A0D@oracle.com> References: <6DA9A9B0-19A5-4A9E-9CAD-95D34D69A01A@answerrocket.com> <48242950-9A01-4DDD-B0BB-641898FC8A0D@oracle.com> Message-ID: You should be able to add generics compatibly, you just can't change the generics signature. One shot to get it right IIRC. > On Nov 25, 2015, at 8:57 AM, Jonathan Giles wrote: > > It was an oversight at the time, and (from memory) is now a breaking change to fix it, so for now it remains as it is, sadly. > > -- Jonathan > Sent from a touch device. Please excuse my brevity. > >> On 26 November 2015 03:33:04 GMT+13:00, Lawrence Parker wrote: >> Seems like getTableRow() should return TableRow instead of just >> TableRow. That way I wouldn?t have to cast getItem(). >> >> https://docs.oracle.com/javase/8/javafx/api/javafx/scene/control/TableCell.html >> >> >> >> >> >> @Override >> public void updateItem(Boolean isEnabled, boolean empty) { >> ... >> TestCase testCase = (TestCase)getTableRow().getItem(); >> >> This would be nicer: >> >> TestCase testCase = getTableRow().getItem(); >> >> Seems like an easy change to the getTableRow() method: >> >> public class TableCell extends IndexedCell { >> ... >> public final TableRow getTableRow() { return tableRow.get(); } >> >> >> Was this an oversight, or is there a reason that getTableRow() needs to >> return TableRow instead of TableRow? >> >> Thanks for any help. >> >> -Larry From kevin.rushforth at oracle.com Wed Nov 25 18:01:57 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 25 Nov 2015 10:01:57 -0800 Subject: [9, 8u] review request: [JAVADOC] Change docs to not refer to full-screen exclusive mode Message-ID: <5655F795.9060109@oracle.com> David, Please review this simple doc fix. https://bugs.openjdk.java.net/browse/JDK-8089847 http://cr.openjdk.java.net/~kcr/8089847/webrev.00/ Thanks. -- Kevin From jonathan.giles at oracle.com Wed Nov 25 20:37:23 2015 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Thu, 26 Nov 2015 09:37:23 +1300 Subject: TableCell.getTableRow() return value In-Reply-To: References: <6DA9A9B0-19A5-4A9E-9CAD-95D34D69A01A@answerrocket.com> <48242950-9A01-4DDD-B0BB-641898FC8A0D@oracle.com> Message-ID: <56561C03.4010904@oracle.com> I think in this situation you're right - I just made the change locally and did a full build of the SDK and all apps, and everything compiles. My Jira-foo is not strong enough to find the issue I'm thinking of, but I do recall an issue in one place in the TableView API about generics being added and it breaking something. I wish I could find it - I'll keep looking in any case. I will file a new JBS issue and will propose this change. We can try to put it into JDK 9 and give it time to bake, and see if anyone comes forward due to being broken by it... -- Jonathan On 26/11/15 6:46 AM, Richard Bair wrote: > You should be able to add generics compatibly, you just can't change the generics signature. One shot to get it right IIRC. > >> On Nov 25, 2015, at 8:57 AM, Jonathan Giles wrote: >> >> It was an oversight at the time, and (from memory) is now a breaking change to fix it, so for now it remains as it is, sadly. >> >> -- Jonathan >> Sent from a touch device. Please excuse my brevity. >> >>> On 26 November 2015 03:33:04 GMT+13:00, Lawrence Parker wrote: >>> Seems like getTableRow() should return TableRow instead of just >>> TableRow. That way I wouldn?t have to cast getItem(). >>> >>> https://docs.oracle.com/javase/8/javafx/api/javafx/scene/control/TableCell.html >>> >>> >>> >>> >>> >>> @Override >>> public void updateItem(Boolean isEnabled, boolean empty) { >>> ... >>> TestCase testCase = (TestCase)getTableRow().getItem(); >>> >>> This would be nicer: >>> >>> TestCase testCase = getTableRow().getItem(); >>> >>> Seems like an easy change to the getTableRow() method: >>> >>> public class TableCell extends IndexedCell { >>> ... >>> public final TableRow getTableRow() { return tableRow.get(); } >>> >>> >>> Was this an oversight, or is there a reason that getTableRow() needs to >>> return TableRow instead of TableRow? >>> >>> Thanks for any help. >>> >>> -Larry From larry at answerrocket.com Wed Nov 25 20:39:59 2015 From: larry at answerrocket.com (Lawrence Parker) Date: Wed, 25 Nov 2015 15:39:59 -0500 Subject: TableCell.getTableRow() return value In-Reply-To: <56561C03.4010904@oracle.com> References: <6DA9A9B0-19A5-4A9E-9CAD-95D34D69A01A@answerrocket.com> <48242950-9A01-4DDD-B0BB-641898FC8A0D@oracle.com> <56561C03.4010904@oracle.com> Message-ID: <08A9B518-C448-4B38-B9F6-7E0A60C4EBD9@answerrocket.com> Sounds good, thank you very much!! -Larry > On Nov 25, 2015, at 3:37 PM, Jonathan Giles wrote: > > I think in this situation you're right - I just made the change locally and did a full build of the SDK and all apps, and everything compiles. My Jira-foo is not strong enough to find the issue I'm thinking of, but I do recall an issue in one place in the TableView API about generics being added and it breaking something. I wish I could find it - I'll keep looking in any case. > > I will file a new JBS issue and will propose this change. We can try to put it into JDK 9 and give it time to bake, and see if anyone comes forward due to being broken by it... > > -- Jonathan > > On 26/11/15 6:46 AM, Richard Bair wrote: >> You should be able to add generics compatibly, you just can't change the generics signature. One shot to get it right IIRC. >> >>> On Nov 25, 2015, at 8:57 AM, Jonathan Giles wrote: >>> >>> It was an oversight at the time, and (from memory) is now a breaking change to fix it, so for now it remains as it is, sadly. >>> >>> -- Jonathan >>> Sent from a touch device. Please excuse my brevity. >>> >>>> On 26 November 2015 03:33:04 GMT+13:00, Lawrence Parker wrote: >>>> Seems like getTableRow() should return TableRow instead of just >>>> TableRow. That way I wouldn?t have to cast getItem(). >>>> >>>> https://docs.oracle.com/javase/8/javafx/api/javafx/scene/control/TableCell.html >>>> >>>> >>>> >>>> >>>> >>>> @Override >>>> public void updateItem(Boolean isEnabled, boolean empty) { >>>> ... >>>> TestCase testCase = (TestCase)getTableRow().getItem(); >>>> >>>> This would be nicer: >>>> >>>> TestCase testCase = getTableRow().getItem(); >>>> >>>> Seems like an easy change to the getTableRow() method: >>>> >>>> public class TableCell extends IndexedCell { >>>> ... >>>> public final TableRow getTableRow() { return tableRow.get(); } >>>> >>>> >>>> Was this an oversight, or is there a reason that getTableRow() needs to >>>> return TableRow instead of TableRow? >>>> >>>> Thanks for any help. >>>> >>>> -Larry > From kevin.rushforth at oracle.com Wed Nov 25 20:58:57 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 25 Nov 2015 12:58:57 -0800 Subject: TableCell.getTableRow() return value In-Reply-To: <56561C03.4010904@oracle.com> References: <6DA9A9B0-19A5-4A9E-9CAD-95D34D69A01A@answerrocket.com> <48242950-9A01-4DDD-B0BB-641898FC8A0D@oracle.com> <56561C03.4010904@oracle.com> Message-ID: <56562111.1050001@oracle.com> Sounds good. Thanks, Jonathan (and Richard for pointing this out). -- Kevin Jonathan Giles wrote: > I think in this situation you're right - I just made the change > locally and did a full build of the SDK and all apps, and everything > compiles. My Jira-foo is not strong enough to find the issue I'm > thinking of, but I do recall an issue in one place in the TableView > API about generics being added and it breaking something. I wish I > could find it - I'll keep looking in any case. > > I will file a new JBS issue and will propose this change. We can try > to put it into JDK 9 and give it time to bake, and see if anyone comes > forward due to being broken by it... > > -- Jonathan > > On 26/11/15 6:46 AM, Richard Bair wrote: >> You should be able to add generics compatibly, you just can't change >> the generics signature. One shot to get it right IIRC. >> >>> On Nov 25, 2015, at 8:57 AM, Jonathan Giles >>> wrote: >>> >>> It was an oversight at the time, and (from memory) is now a breaking >>> change to fix it, so for now it remains as it is, sadly. >>> >>> -- Jonathan >>> Sent from a touch device. Please excuse my brevity. >>> >>>> On 26 November 2015 03:33:04 GMT+13:00, Lawrence Parker >>>> wrote: >>>> Seems like getTableRow() should return TableRow instead of just >>>> TableRow. That way I wouldn?t have to cast getItem(). >>>> >>>> >>>> https://docs.oracle.com/javase/8/javafx/api/javafx/scene/control/TableCell.html >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> @Override >>>> public void updateItem(Boolean isEnabled, boolean empty) { >>>> ... >>>> TestCase testCase = (TestCase)getTableRow().getItem(); >>>> >>>> This would be nicer: >>>> >>>> TestCase testCase = getTableRow().getItem(); >>>> >>>> Seems like an easy change to the getTableRow() method: >>>> >>>> public class TableCell extends IndexedCell { >>>> ... >>>> public final TableRow getTableRow() { return tableRow.get(); } >>>> >>>> >>>> Was this an oversight, or is there a reason that getTableRow() >>>> needs to >>>> return TableRow instead of TableRow? >>>> >>>> Thanks for any help. >>>> >>>> -Larry > From jonathan.giles at oracle.com Wed Nov 25 21:00:12 2015 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Thu, 26 Nov 2015 10:00:12 +1300 Subject: TableCell.getTableRow() return value In-Reply-To: References: <6DA9A9B0-19A5-4A9E-9CAD-95D34D69A01A@answerrocket.com> <48242950-9A01-4DDD-B0BB-641898FC8A0D@oracle.com> Message-ID: <5656215C.9040403@oracle.com> I found the Jira issue I was looking for....unfortunately it lacks a lot of detail. I have just updated it to give the example of why it had to be backed out. https://bugs.openjdk.java.net/browse/JDK-8102370 Fortunately the issue was in another location, and I don't think we will have the same issue in this proposed change. -- Jonathan On 26/11/15 6:46 AM, Richard Bair wrote: > You should be able to add generics compatibly, you just can't change the generics signature. One shot to get it right IIRC. > >> On Nov 25, 2015, at 8:57 AM, Jonathan Giles wrote: >> >> It was an oversight at the time, and (from memory) is now a breaking change to fix it, so for now it remains as it is, sadly. >> >> -- Jonathan >> Sent from a touch device. Please excuse my brevity. >> >>> On 26 November 2015 03:33:04 GMT+13:00, Lawrence Parker wrote: >>> Seems like getTableRow() should return TableRow instead of just >>> TableRow. That way I wouldn?t have to cast getItem(). >>> >>> https://docs.oracle.com/javase/8/javafx/api/javafx/scene/control/TableCell.html >>> >>> >>> >>> >>> >>> @Override >>> public void updateItem(Boolean isEnabled, boolean empty) { >>> ... >>> TestCase testCase = (TestCase)getTableRow().getItem(); >>> >>> This would be nicer: >>> >>> TestCase testCase = getTableRow().getItem(); >>> >>> Seems like an easy change to the getTableRow() method: >>> >>> public class TableCell extends IndexedCell { >>> ... >>> public final TableRow getTableRow() { return tableRow.get(); } >>> >>> >>> Was this an oversight, or is there a reason that getTableRow() needs to >>> return TableRow instead of TableRow? >>> >>> Thanks for any help. >>> >>> -Larry From jonathan.giles at oracle.com Wed Nov 25 21:30:08 2015 From: jonathan.giles at oracle.com (Jonathan Giles) Date: Thu, 26 Nov 2015 10:30:08 +1300 Subject: TableCell.getTableRow() return value In-Reply-To: <5656215C.9040403@oracle.com> References: <6DA9A9B0-19A5-4A9E-9CAD-95D34D69A01A@answerrocket.com> <48242950-9A01-4DDD-B0BB-641898FC8A0D@oracle.com> <5656215C.9040403@oracle.com> Message-ID: <56562860.6060907@oracle.com> I have filed and attached the issue here: https://bugs.openjdk.java.net/browse/JDK-8144088 @Kevin - would you mind giving this a quick API review please? -- Jonathan On 26/11/15 10:00 AM, Jonathan Giles wrote: > I found the Jira issue I was looking for....unfortunately it lacks a > lot of detail. I have just updated it to give the example of why it > had to be backed out. > > https://bugs.openjdk.java.net/browse/JDK-8102370 > > Fortunately the issue was in another location, and I don't think we > will have the same issue in this proposed change. > > -- Jonathan > > On 26/11/15 6:46 AM, Richard Bair wrote: >> You should be able to add generics compatibly, you just can't change >> the generics signature. One shot to get it right IIRC. >> >>> On Nov 25, 2015, at 8:57 AM, Jonathan Giles >>> wrote: >>> >>> It was an oversight at the time, and (from memory) is now a breaking >>> change to fix it, so for now it remains as it is, sadly. >>> >>> -- Jonathan >>> Sent from a touch device. Please excuse my brevity. >>> >>>> On 26 November 2015 03:33:04 GMT+13:00, Lawrence Parker >>>> wrote: >>>> Seems like getTableRow() should return TableRow instead of just >>>> TableRow. That way I wouldn?t have to cast getItem(). >>>> >>>> https://docs.oracle.com/javase/8/javafx/api/javafx/scene/control/TableCell.html >>>> >>>> >>>> >>>> >>>> >>>> >>>> @Override >>>> public void updateItem(Boolean isEnabled, boolean empty) { >>>> ... >>>> TestCase testCase = (TestCase)getTableRow().getItem(); >>>> >>>> This would be nicer: >>>> >>>> TestCase testCase = getTableRow().getItem(); >>>> >>>> Seems like an easy change to the getTableRow() method: >>>> >>>> public class TableCell extends IndexedCell { >>>> ... >>>> public final TableRow getTableRow() { return tableRow.get(); } >>>> >>>> >>>> Was this an oversight, or is there a reason that getTableRow() >>>> needs to >>>> return TableRow instead of TableRow? >>>> >>>> Thanks for any help. >>>> >>>> -Larry > From kevin.rushforth at oracle.com Wed Nov 25 21:37:28 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 25 Nov 2015 13:37:28 -0800 Subject: TableCell.getTableRow() return value In-Reply-To: <56562860.6060907@oracle.com> References: <6DA9A9B0-19A5-4A9E-9CAD-95D34D69A01A@answerrocket.com> <48242950-9A01-4DDD-B0BB-641898FC8A0D@oracle.com> <5656215C.9040403@oracle.com> <56562860.6060907@oracle.com> Message-ID: <56562A18.2060002@oracle.com> Looks good to me. I also added a comment to the bug report. -- Kevin Jonathan Giles wrote: > I have filed and attached the issue here: > https://bugs.openjdk.java.net/browse/JDK-8144088 > > @Kevin - would you mind giving this a quick API review please? > > -- Jonathan > > On 26/11/15 10:00 AM, Jonathan Giles wrote: >> I found the Jira issue I was looking for....unfortunately it lacks a >> lot of detail. I have just updated it to give the example of why it >> had to be backed out. >> >> https://bugs.openjdk.java.net/browse/JDK-8102370 >> >> Fortunately the issue was in another location, and I don't think we >> will have the same issue in this proposed change. >> >> -- Jonathan >> >> On 26/11/15 6:46 AM, Richard Bair wrote: >>> You should be able to add generics compatibly, you just can't change >>> the generics signature. One shot to get it right IIRC. >>> >>>> On Nov 25, 2015, at 8:57 AM, Jonathan Giles >>>> wrote: >>>> >>>> It was an oversight at the time, and (from memory) is now a >>>> breaking change to fix it, so for now it remains as it is, sadly. >>>> >>>> -- Jonathan >>>> Sent from a touch device. Please excuse my brevity. >>>> >>>>> On 26 November 2015 03:33:04 GMT+13:00, Lawrence Parker >>>>> wrote: >>>>> Seems like getTableRow() should return TableRow instead of just >>>>> TableRow. That way I wouldn?t have to cast getItem(). >>>>> >>>>> https://docs.oracle.com/javase/8/javafx/api/javafx/scene/control/TableCell.html >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> @Override >>>>> public void updateItem(Boolean isEnabled, boolean empty) { >>>>> ... >>>>> TestCase testCase = (TestCase)getTableRow().getItem(); >>>>> >>>>> This would be nicer: >>>>> >>>>> TestCase testCase = getTableRow().getItem(); >>>>> >>>>> Seems like an easy change to the getTableRow() method: >>>>> >>>>> public class TableCell extends IndexedCell { >>>>> ... >>>>> public final TableRow getTableRow() { return tableRow.get(); } >>>>> >>>>> >>>>> Was this an oversight, or is there a reason that getTableRow() >>>>> needs to >>>>> return TableRow instead of TableRow? >>>>> >>>>> Thanks for any help. >>>>> >>>>> -Larry >> > From kevin.rushforth at oracle.com Thu Nov 26 01:49:23 2015 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 25 Nov 2015 17:49:23 -0800 Subject: Bulk packager integration In-Reply-To: <7552A67A-2D59-4FF5-B9FC-3F9E7A1E15BC@oracle.com> References: <7552A67A-2D59-4FF5-B9FC-3F9E7A1E15BC@oracle.com> Message-ID: <56566523.6050202@oracle.com> 1) I get the following error if I apply the patch and do a build: :fxpackager:compileJava/localhome/kcr/javafx/9-jake-kcr/jfx/rt/modules/fxpackager/src/main/java/com/oracle/tools/packager/JLinkBundlerHelper.java:3: error: package com.sun.tools.jdeps does not exist import com.sun.tools.jdeps.Main; ^ Does this require a newer version of JDK9 jigsaw or is there some other issue? If the former, then we need to solve a problem that isn't yet solved with the build environment on our Hudson machines before this can go in. 2) The JDK9_MODULES is a new variable that isn't currently defined. What should it be set to? It looks like it is only used by the packagerDev task, so might be OK. 3) The classesModuleExclude mechanism duplicates an existing mechanism to filter out classes from going into the modules. Are you sure this new mechanism is needed? After I fixed https://bugs.openjdk.java.net/browse/JDK-8142381 a couple weeks ago I no longer see any classes from ant-javafx.jar showing up in the fxpackager module. -- Kevin Danno Ferrin wrote: > Here's the webrev: http://cr.openjdk.java.net/~shemnon/8080531/webrev.07/ > (it's been a stressful morning) > > >> On Nov 25, 2015, at 9:38 AM, Danno Ferrin wrote: >> >> Kevin, Chris, Dmitry >> >> This is a bulk packager integration from the packager sandbox to the JavaFX Sandbox, please review. >> >> webrev: >> >> There are three changes outside of the fxpackager module that I think Kevin needs to give his approval for. >> >> Two changes are in the build.gradle. The first adds a concept of classesModuleExclude which is a regexp for files to exclude from the modular jar. This is to support creating the ant jar outside of the module system so that ant can read the required types and classes. >> >> The second change is to introduce JDK9_MODULES, read off of an environmental variable. This should point to your jmods directory (not explored modules, this must be jmods). This is to support the packagerdev target which now needs a pointer to the jmods which as of yet does not have a standard location relative to the JDK/JRE. >> >> The third change is the addition of another module-info.java.extra file. This one exposes the invocation API for JDeps to packager so the detectmodules can use it to sniff out modules from the classpath. >> >> The remainder of the changes are internal to the fxpackager modules and represent contributions from Chris Bensen, Dmitry Cherepanov, and myself finishing out the last details for JEP275. This patch should make it feature complete (but not bug complete, we got another milestone for that). >> >> --Danno >> > > From vadim.pakhnushev at oracle.com Fri Nov 27 14:30:24 2015 From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev) Date: Fri, 27 Nov 2015 17:30:24 +0300 Subject: In(Sanity) Testing Mondays Message-ID: <56586900.5040204@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 PST until 1pm PST. Happy testing! Thanks, Vadim From leif.samuelsson at oracle.com Mon Nov 30 00:30:11 2015 From: leif.samuelsson at oracle.com (Leif Samuelsson) Date: Sun, 29 Nov 2015 16:30:11 -0800 Subject: [9] Request for API review: 8143158 [Text, TextFlow] Make public API from internal "impl" APIs Message-ID: <565B9893.9010008@oracle.com> Kevin, Phil, et al, Please review the proposed new API for Text and TextFlow to open up existing internal methods for text selection, etc. Most of the new Text API is simply renaming of formerly deprecated methods, while the TextFlow API is added to expose underlying layout functionality and matches the corresponding Text API. https://bugs.openjdk.java.net/browse/JDK-8143158 Code review will follow. Thanks, Leif From guru.hb at oracle.com Mon Nov 30 06:52:11 2015 From: guru.hb at oracle.com (Guru Hb) Date: Sun, 29 Nov 2015 22:52:11 -0800 (PST) Subject: [9] Review request for 8140501 : WebView crashes when loading content in a locationlistener Message-ID: <0ff4e990-4c6a-429d-bf38-26c6c9308717@default> Hi Arunprasad, Alexander & Kevin, JBS : https://bugs.openjdk.java.net/browse/JDK-8140501 Webrev : http://cr.openjdk.java.net/~ghb/8140501/webrev.00/ Tested on Windows and Linux (both 64 bit). Thnaks, Guru From dmitry.cherepanov at oracle.com Mon Nov 30 12:28:04 2015 From: dmitry.cherepanov at oracle.com (Dmitry Cherepanov) Date: Mon, 30 Nov 2015 07:28:04 -0500 Subject: [9] Review request for 8091625: [Packager, Windows] launcher.exe stub should have version resource Message-ID: <565C40D4.3050106@oracle.com> Chris, Danno, Kevin, Please review the following fix https://bugs.openjdk.java.net/browse/JDK-8091625 http://cr.openjdk.java.net/~dcherepanov/8091625/webrev.v0/ Thanks, Dmitry From danno.ferrin at oracle.com Mon Nov 30 15:19:39 2015 From: danno.ferrin at oracle.com (Danno Ferrin) Date: Mon, 30 Nov 2015 08:19:39 -0700 Subject: Bulk packager integration In-Reply-To: <56566523.6050202@oracle.com> References: <7552A67A-2D59-4FF5-B9FC-3F9E7A1E15BC@oracle.com> <56566523.6050202@oracle.com> Message-ID: <24C28C93-95A8-428C-B4FA-3B4D6B25DB45@oracle.com> > On Nov 25, 2015, at 6:49 PM, Kevin Rushforth wrote: > > 1) I get the following error if I apply the patch and do a build: > > :fxpackager:compileJava/localhome/kcr/javafx/9-jake-kcr/jfx/rt/modules/fxpackager/src/main/java/com/oracle/tools/packager/JLinkBundlerHelper.java:3: error: package com.sun.tools.jdeps does not exist > import com.sun.tools.jdeps.Main; > ^ > > Does this require a newer version of JDK9 jigsaw or is there some other issue? If the former, then we need to solve a problem that isn't yet solved with the build environment on our Hudson machines before this can go in. > > Do you have the module-info.java.extra file loaded up? It may be a build issue since that file is not exported by default. Is this the same error we see when it doen't like the module boundaries? do we need to add some -XaddExports? It works for me, and the file is years old, so it may be order or operations issues with the JDK that is on the build server. I'll look into building from a public EA build of Java 9 then (if I have time, Chris or Dmitry may get to do that). > 2) The JDK9_MODULES is a new variable that isn't currently defined. What should it be set to? It looks like it is only used by the packagerDev task, so might be OK. > Right now it is for packagerdev, but going forward I see it being needed for the unit tests. > > 3) The classesModuleExclude mechanism duplicates an existing mechanism to filter out classes from going into the modules. Are you sure this new mechanism is needed? After I fixed https://bugs.openjdk.java.net/browse/JDK-8142381 a couple weeks ago I no longer see any classes from ant-javafx.jar showing up in the fxpackager module. > I'll look into removing that code then. > -- Kevin > > > Danno Ferrin wrote: >> >> Here's the webrev: http://cr.openjdk.java.net/~shemnon/8080531/webrev.07/ >> (it's been a stressful morning) >> >> >>> On Nov 25, 2015, at 9:38 AM, Danno Ferrin wrote: >>> >>> Kevin, Chris, Dmitry >>> >>> This is a bulk packager integration from the packager sandbox to the JavaFX Sandbox, please review. >>> >>> webrev: >>> >>> There are three changes outside of the fxpackager module that I think Kevin needs to give his approval for. >>> >>> Two changes are in the build.gradle. The first adds a concept of classesModuleExclude which is a regexp for files to exclude from the modular jar. This is to support creating the ant jar outside of the module system so that ant can read the required types and classes. >>> >>> The second change is to introduce JDK9_MODULES, read off of an environmental variable. This should point to your jmods directory (not explored modules, this must be jmods). This is to support the packagerdev target which now needs a pointer to the jmods which as of yet does not have a standard location relative to the JDK/JRE. >>> >>> The third change is the addition of another module-info.java.extra file. This one exposes the invocation API for JDeps to packager so the detectmodules can use it to sniff out modules from the classpath. >>> >>> The remainder of the changes are internal to the fxpackager modules and represent contributions from Chris Bensen, Dmitry Cherepanov, and myself finishing out the last details for JEP275. This patch should make it feature complete (but not bug complete, we got another milestone for that). >>> >>> --Danno >>> >> >> From dlemmermann at gmail.com Mon Nov 30 16:13:10 2015 From: dlemmermann at gmail.com (Dirk @ Google) Date: Mon, 30 Nov 2015 17:13:10 +0100 Subject: Future of JavaFX Message-ID: <3A17B208-9E52-44B3-9CE9-5164CFF15A8D@gmail.com> Hi there, there has been quite a shake-up in the JavaFX community last week when Shay Almog (Codename One) first responded to a blog of mine (dlemmermann.wordpress.com) with a lot of negative comments regarding JavaFX and its future. He then followed up with a long blog asking the question ?Should Oracle Spring-Clean JavaFX? (https://www.codenameone.com/blog/should-oracle-spring-clean-javafx.html ). I do understand that it is often a good strategy to not comment on stuff like this because commenting would just draw attention to it, but we have now reached the point where potential customers are questioning the sustainability of a JavaFX-based solution. They are now wondering if JavaFX will still be around in a few years. In my specific case the customer demands an answer from me and my partners within the next week, and if not convincing they will go with something / someone else. We will loose a contract worth around one million dollars because of one blog written by Shay with no follow-up from Oracle. What is needed is an official statement from Oracle / Oracle employees / JavaFX development team, saying that Oracle is still committed to JavaFX and that it will still be around for a while. Can somebody please do that? Dirk From neugens.limasoftware at gmail.com Mon Nov 30 16:25:11 2015 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Mon, 30 Nov 2015 17:25:11 +0100 Subject: Future of JavaFX In-Reply-To: <3A17B208-9E52-44B3-9CE9-5164CFF15A8D@gmail.com> References: <3A17B208-9E52-44B3-9CE9-5164CFF15A8D@gmail.com> Message-ID: My humble opinion is that what should happen to stop this FUD once and for all is that JavaFX becomes finally part of OpenJDK (as in same codebase and same build infrastructure) and a formal part of the Java API. I'm sure this will happen eventually and everything seems to go toward this goal, but it should move a bit faster. Cheers, Mario 2015-11-30 17:13 GMT+01:00 Dirk @ Google : > Hi there, > > there has been quite a shake-up in the JavaFX community last week when Shay Almog (Codename One) first responded to a blog of mine (dlemmermann.wordpress.com) with a lot of negative comments regarding JavaFX and its future. He then followed up with a long blog asking the question ?Should Oracle Spring-Clean JavaFX? (https://www.codenameone.com/blog/should-oracle-spring-clean-javafx.html ). > > I do understand that it is often a good strategy to not comment on stuff like this because commenting would just draw attention to it, but we have now reached the point where potential customers are questioning the sustainability of a JavaFX-based solution. They are now wondering if JavaFX will still be around in a few years. In my specific case the customer demands an answer from me and my partners within the next week, and if not convincing they will go with something / someone else. We will loose a contract worth around one million dollars because of one blog written by Shay with no follow-up from Oracle. > > What is needed is an official statement from Oracle / Oracle employees / JavaFX development team, saying that Oracle is still committed to JavaFX and that it will still be around for a while. Can somebody please do that? > > Dirk > > -- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens Proud GNU Classpath developer: http://www.classpath.org/ OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/ From donald.smith at oracle.com Mon Nov 30 16:35:00 2015 From: donald.smith at oracle.com (Donald Smith) Date: Mon, 30 Nov 2015 11:35:00 -0500 Subject: Future of JavaFX In-Reply-To: <3A17B208-9E52-44B3-9CE9-5164CFF15A8D@gmail.com> References: <3A17B208-9E52-44B3-9CE9-5164CFF15A8D@gmail.com> Message-ID: <565C7AB4.9050203@oracle.com> Oracle is still committed to JavaFX and it will still be around for a while. As of 7u6 we bundled JavaFX with the Oracle JDK, we've open sourced 100% of the code, we continue developing for it, etc. I understand that while there is both Swing and JavaFX available that people will continue to question the existence of each -- so be it. Each has it's own niches and benefits and our strategy, as it has been for years now, is to continue with each. - Don On 30/11/2015 11:13 AM, Dirk @ Google wrote: > Hi there, > > there has been quite a shake-up in the JavaFX community last week when Shay Almog (Codename One) first responded to a blog of mine (dlemmermann.wordpress.com) with a lot of negative comments regarding JavaFX and its future. He then followed up with a long blog asking the question ?Should Oracle Spring-Clean JavaFX? (https://www.codenameone.com/blog/should-oracle-spring-clean-javafx.html ). > > I do understand that it is often a good strategy to not comment on stuff like this because commenting would just draw attention to it, but we have now reached the point where potential customers are questioning the sustainability of a JavaFX-based solution. They are now wondering if JavaFX will still be around in a few years. In my specific case the customer demands an answer from me and my partners within the next week, and if not convincing they will go with something / someone else. We will loose a contract worth around one million dollars because of one blog written by Shay with no follow-up from Oracle. > > What is needed is an official statement from Oracle / Oracle employees / JavaFX development team, saying that Oracle is still committed to JavaFX and that it will still be around for a while. Can somebody please do that? > > Dirk > > From tomas.mikula at gmail.com Mon Nov 30 17:20:44 2015 From: tomas.mikula at gmail.com (Tomas Mikula) Date: Mon, 30 Nov 2015 12:20:44 -0500 Subject: Future of JavaFX In-Reply-To: <3A17B208-9E52-44B3-9CE9-5164CFF15A8D@gmail.com> References: <3A17B208-9E52-44B3-9CE9-5164CFF15A8D@gmail.com> Message-ID: The same blog post of Shay says that "Oracle never discontinues products." At least not officially. So there you have that. Given that the biggest achievement of JavaFX 9 will be if old things keep working in JDK 9, I wouldn't expect any new exciting JavaFX developments coming from Oracle. On Mon, Nov 30, 2015 at 11:13 AM, Dirk @ Google wrote: > Hi there, > > there has been quite a shake-up in the JavaFX community last week when > Shay Almog (Codename One) first responded to a blog of mine ( > dlemmermann.wordpress.com) with a lot of negative comments regarding > JavaFX and its future. He then followed up with a long blog asking the > question ?Should Oracle Spring-Clean JavaFX? ( > https://www.codenameone.com/blog/should-oracle-spring-clean-javafx.html < > https://www.codenameone.com/blog/should-oracle-spring-clean-javafx.html>). > > I do understand that it is often a good strategy to not comment on stuff > like this because commenting would just draw attention to it, but we have > now reached the point where potential customers are questioning the > sustainability of a JavaFX-based solution. They are now wondering if JavaFX > will still be around in a few years. In my specific case the customer > demands an answer from me and my partners within the next week, and if not > convincing they will go with something / someone else. We will loose a > contract worth around one million dollars because of one blog written by > Shay with no follow-up from Oracle. > > What is needed is an official statement from Oracle / Oracle employees / > JavaFX development team, saying that Oracle is still committed to JavaFX > and that it will still be around for a while. Can somebody please do that? > > Dirk > > > From dlemmermann at gmail.com Mon Nov 30 17:25:20 2015 From: dlemmermann at gmail.com (Dirk @ Google) Date: Mon, 30 Nov 2015 18:25:20 +0100 Subject: Future of JavaFX In-Reply-To: References: <3A17B208-9E52-44B3-9CE9-5164CFF15A8D@gmail.com> Message-ID: <630CB2E6-15BC-46DF-AFC6-E23BD9986AF7@gmail.com> Companies like the one in question need to know if something will be supported. ?Not discontinued? is not good enough for them. Dirk > Am 30.11.2015 um 18:20 schrieb Tomas Mikula : > > The same blog post of Shay says that "Oracle never discontinues products." At least not officially. So there you have that. > > Given that the biggest achievement of JavaFX 9 will be if old things keep working in JDK 9, I wouldn't expect any new exciting JavaFX developments coming from Oracle. > > On Mon, Nov 30, 2015 at 11:13 AM, Dirk @ Google > wrote: > Hi there, > > there has been quite a shake-up in the JavaFX community last week when Shay Almog (Codename One) first responded to a blog of mine (dlemmermann.wordpress.com ) with a lot of negative comments regarding JavaFX and its future. He then followed up with a long blog asking the question ?Should Oracle Spring-Clean JavaFX? (https://www.codenameone.com/blog/should-oracle-spring-clean-javafx.html >). > > I do understand that it is often a good strategy to not comment on stuff like this because commenting would just draw attention to it, but we have now reached the point where potential customers are questioning the sustainability of a JavaFX-based solution. They are now wondering if JavaFX will still be around in a few years. In my specific case the customer demands an answer from me and my partners within the next week, and if not convincing they will go with something / someone else. We will loose a contract worth around one million dollars because of one blog written by Shay with no follow-up from Oracle. > > What is needed is an official statement from Oracle / Oracle employees / JavaFX development team, saying that Oracle is still committed to JavaFX and that it will still be around for a while. Can somebody please do that? > > Dirk > > > From rcuprak at gmail.com Mon Nov 30 19:10:34 2015 From: rcuprak at gmail.com (Ryan Cuprak) Date: Mon, 30 Nov 2015 14:10:34 -0500 Subject: Future of JavaFX In-Reply-To: <630CB2E6-15BC-46DF-AFC6-E23BD9986AF7@gmail.com> References: <3A17B208-9E52-44B3-9CE9-5164CFF15A8D@gmail.com> <630CB2E6-15BC-46DF-AFC6-E23BD9986AF7@gmail.com> Message-ID: <9E9C4652-F0F4-4687-97A8-10BE50072CF2@gmail.com> Sent from my iPhone > On Nov 30, 2015, at 12:25 PM, Dirk @ Google wrote: > > Companies like the one in question need to know if something will be supported. ?Not discontinued? is not good enough for them. > > Dirk > >> Am 30.11.2015 um 18:20 schrieb Tomas Mikula : >> >> The same blog post of Shay says that "Oracle never discontinues products." At least not officially. So there you have that. >> >> Given that the biggest achievement of JavaFX 9 will be if old things keep working in JDK 9, I wouldn't expect any new exciting JavaFX developments coming from Oracle. >> >> On Mon, Nov 30, 2015 at 11:13 AM, Dirk @ Google > wrote: >> Hi there, >> >> there has been quite a shake-up in the JavaFX community last week when Shay Almog (Codename One) first responded to a blog of mine (dlemmermann.wordpress.com ) with a lot of negative comments regarding JavaFX and its future. He then followed up with a long blog asking the question ?Should Oracle Spring-Clean JavaFX? (https://www.codenameone.com/blog/should-oracle-spring-clean-javafx.html >). >> >> I do understand that it is often a good strategy to not comment on stuff like this because commenting would just draw attention to it, but we have now reached the point where potential customers are questioning the sustainability of a JavaFX-based solution. They are now wondering if JavaFX will still be around in a few years. In my specific case the customer demands an answer from me and my partners within the next week, and if not convincing they will go with something / someone else. We will loose a contract worth around one million dollars because of one blog written by Shay with no follow-up from Oracle. >> >> What is needed is an official statement from Oracle / Oracle employees / JavaFX development team, saying that Oracle is still committed to JavaFX and that it will still be around for a while. Can somebody please do that? >> >> Dirk > From fbrunnerlist at gmx.ch Mon Nov 30 20:35:05 2015 From: fbrunnerlist at gmx.ch (Florian Brunner) Date: Mon, 30 Nov 2015 21:35:05 +0100 Subject: Future of JavaFX In-Reply-To: <3A17B208-9E52-44B3-9CE9-5164CFF15A8D@gmail.com> References: <3A17B208-9E52-44B3-9CE9-5164CFF15A8D@gmail.com> Message-ID: <3555650.UByc31Jqhd@andor> I read this article as well some days ago. It has some very valid points, but all in all I think JavaFX is still the best option out there. That said I was quite surprised that I got confronted today with the very same article by colleagues of mine who are in charge with company-wide adoption of various technologies. They tend to agree with the article. Currently JavaFX is still just on our technology radar, but not promoted yet. And now they start thinking JavFX (and probably thus Java on desktop not even speaking about mobile platforms) won't make it and it's getting hard to convince them that JavaFX is actually a great option. Now reading this mail of yours, this article really seems to make waves. -Florian Am Montag, 30. November 2015, 17.13:10 schrieb Dirk @ Google: > Hi there, > > there has been quite a shake-up in the JavaFX community last week when Shay > Almog (Codename One) first responded to a blog of mine > (dlemmermann.wordpress.com) with a lot of negative comments regarding > JavaFX and its future. He then followed up with a long blog asking the > question ?Should Oracle Spring-Clean JavaFX? > (https://www.codenameone.com/blog/should-oracle-spring-clean-javafx.html > ). > > I do understand that it is often a good strategy to not comment on stuff > like this because commenting would just draw attention to it, but we have > now reached the point where potential customers are questioning the > sustainability of a JavaFX-based solution. They are now wondering if JavaFX > will still be around in a few years. In my specific case the customer > demands an answer from me and my partners within the next week, and if not > convincing they will go with something / someone else. We will loose a > contract worth around one million dollars because of one blog written by > Shay with no follow-up from Oracle. > > What is needed is an official statement from Oracle / Oracle employees / > JavaFX development team, saying that Oracle is still committed to JavaFX > and that it will still be around for a while. Can somebody please do that? > > Dirk From danielhilst at gmail.com Mon Nov 30 21:49:17 2015 From: danielhilst at gmail.com (Daniel.) Date: Mon, 30 Nov 2015 19:49:17 -0200 Subject: Future of JavaFX In-Reply-To: <3555650.UByc31Jqhd@andor> References: <3A17B208-9E52-44B3-9CE9-5164CFF15A8D@gmail.com> <3555650.UByc31Jqhd@andor> Message-ID: The company where I work is using and developing with JavaFX. We're not in production yet but have already some testing embedded systems with it running on a [possible]customer site. The main drawback is not having the same performance running from X than running directly from framebuffer. By not using X we have a other big drawback too that is not having x11vnc working, so every developer need to have a monitor with HDMI attached to our device. I have a task to "look for possible solutions" but I haven't found time to attend it yet. Regards, - dhs 2015-11-30 18:35 GMT-02:00 Florian Brunner : > I read this article as well some days ago. It has some very valid points, but > all in all I think JavaFX is still the best option out there. > > That said I was quite surprised that I got confronted today with the very same > article by colleagues of mine who are in charge with company-wide adoption of > various technologies. They tend to agree with the article. Currently JavaFX is > still just on our technology radar, but not promoted yet. And now they start > thinking JavFX (and probably thus Java on desktop not even speaking about > mobile platforms) won't make it and it's getting hard to convince them that > JavaFX is actually a great option. > > Now reading this mail of yours, this article really seems to make waves. > > -Florian > > > Am Montag, 30. November 2015, 17.13:10 schrieb Dirk @ Google: >> Hi there, >> >> there has been quite a shake-up in the JavaFX community last week when Shay >> Almog (Codename One) first responded to a blog of mine >> (dlemmermann.wordpress.com) with a lot of negative comments regarding >> JavaFX and its future. He then followed up with a long blog asking the >> question ?Should Oracle Spring-Clean JavaFX? >> (https://www.codenameone.com/blog/should-oracle-spring-clean-javafx.html >> ). >> >> I do understand that it is often a good strategy to not comment on stuff >> like this because commenting would just draw attention to it, but we have >> now reached the point where potential customers are questioning the >> sustainability of a JavaFX-based solution. They are now wondering if JavaFX >> will still be around in a few years. In my specific case the customer >> demands an answer from me and my partners within the next week, and if not >> convincing they will go with something / someone else. We will loose a >> contract worth around one million dollars because of one blog written by >> Shay with no follow-up from Oracle. >> >> What is needed is an official statement from Oracle / Oracle employees / >> JavaFX development team, saying that Oracle is still committed to JavaFX >> and that it will still be around for a while. Can somebody please do that? >> >> Dirk > -- "Do or do not. There is no try" Yoda Master From tbee at tbee.org Mon Nov 30 21:52:33 2015 From: tbee at tbee.org (Tom Eugelink) Date: Mon, 30 Nov 2015 22:52:33 +0100 Subject: Future of JavaFX In-Reply-To: <3555650.UByc31Jqhd@andor> References: <3A17B208-9E52-44B3-9CE9-5164CFF15A8D@gmail.com> <3555650.UByc31Jqhd@andor> Message-ID: <565CC521.9030905@tbee.org> There indeed seems to be negative buzz around JavaFX, and Oracle stopping with promoting it, is indeed confusing, at the very least. And it is noticeable everywhere; without wanting to wine, I really do have a nice JavaFX / JFXtras presentation, but it being declined on all conferences for me is a signal about the interest of the community in JavaFX. And let's be honest, Oracle's whole "let's do cloud and forget there are companies doing this many many years already" U turn is not contributing to the mood as well. OTOH, from what I hear VW has chosen to use JavaFX for it's in car systems. And I have just been on an interview for a traffic management system where they chose JavaFX over web based. So there also is adoption. But it will be slow. My gut says: give it time, and a bit of TLC promotionwise would not be bad. Tom On 30-11-2015 21:35, Florian Brunner wrote: > I read this article as well some days ago. It has some very valid points, but > all in all I think JavaFX is still the best option out there. > > That said I was quite surprised that I got confronted today with the very same > article by colleagues of mine who are in charge with company-wide adoption of > various technologies. They tend to agree with the article. Currently JavaFX is > still just on our technology radar, but not promoted yet. And now they start > thinking JavFX (and probably thus Java on desktop not even speaking about > mobile platforms) won't make it and it's getting hard to convince them that > JavaFX is actually a great option. > > Now reading this mail of yours, this article really seems to make waves. > > -Florian > > > Am Montag, 30. November 2015, 17.13:10 schrieb Dirk @ Google: >> Hi there, >> >> there has been quite a shake-up in the JavaFX community last week when Shay >> Almog (Codename One) first responded to a blog of mine >> (dlemmermann.wordpress.com) with a lot of negative comments regarding >> JavaFX and its future. He then followed up with a long blog asking the >> question ?Should Oracle Spring-Clean JavaFX? >> (https://www.codenameone.com/blog/should-oracle-spring-clean-javafx.html >> ). >> >> I do understand that it is often a good strategy to not comment on stuff >> like this because commenting would just draw attention to it, but we have >> now reached the point where potential customers are questioning the >> sustainability of a JavaFX-based solution. They are now wondering if JavaFX >> will still be around in a few years. In my specific case the customer >> demands an answer from me and my partners within the next week, and if not >> convincing they will go with something / someone else. We will loose a >> contract worth around one million dollars because of one blog written by >> Shay with no follow-up from Oracle. >> >> What is needed is an official statement from Oracle / Oracle employees / >> JavaFX development team, saying that Oracle is still committed to JavaFX >> and that it will still be around for a while. Can somebody please do that? >> >> Dirk From alexander.casall at saxsys.de Mon Nov 30 22:54:34 2015 From: alexander.casall at saxsys.de (Casall, Alexander) Date: Mon, 30 Nov 2015 22:54:34 +0000 Subject: Future of JavaFX References: Future of JavaFX Message-ID: <6C6CE4A9B94582468498929459CEEF711011D1E4@vmex1.saxsys.de> Don, thanks for your important contribution to this thread. What exactly means oracle continues to develop on fx? What is the roadmap? If I check the mercurial archives there are 10-12 people working constantly on FX in this year. The most work was done by a few of them. I'm not sure whether this is enought to move FX forward to engage more and more adopters. The core question is, are there any plans to put more ressources on fx? - Alex From: Donald Smith Sent: 30.11.15, 17:35 To: openjfx-dev at openjdk.java.net Mailing Subject: Re: Future of JavaFX Oracle is still committed to JavaFX and it will still be around for a while. As of 7u6 we bundled JavaFX with the Oracle JDK, we've open sourced 100% of the code, we continue developing for it, etc. I understand that while there is both Swing and JavaFX available that people will continue to question the existence of each -- so be it. Each has it's own niches and benefits and our strategy, as it has been for years now, is to continue with each. - Don On 30/11/2015 11:13 AM, Dirk @ Google wrote: > Hi there, > > there has been quite a shake-up in the JavaFX community last week when Shay Almog (Codename One) first responded to a blog of mine (https://www.codenameone.com/blog/should-oracle-spring-clean-javafx.html>). > > I do understand that it is often a good strategy to not comment on stuff like this because commenting would just draw attention to it, but we have now reached the point where potential customers are questioning the sustainability of a JavaFX-based solution. They are now wondering if JavaFX will still be around in a few years. In my specific case the customer demands an answer from me and my partners within the next week, and if not convincing they will go with something / someone else. We will loose a contract worth around one million dollars because of one blog written by Shay with no follow-up from Oracle. > > What is needed is an official statement from Oracle / Oracle employees / JavaFX development team, saying that Oracle is still committed to JavaFX and that it will still be around for a while. Can somebody please do that? > > Dirk > >