Create Self Contained Package on Mac Randomly Fail

2016-05-09 Thread Tai Hu
I used ANT script to make self contained package for our JavaFX application 
(JDK 8u77). On both Windows 64bit and 32bit. I could generate .exe without any 
issue. However, on Mac OS X, my script randomly fail with a message as follows,

Error: Bundler "DMG Installer" (dmg) failed to produce a bundle.

Now I have to repeatedly build 4-5 times. Then one of them will succeed. Does 
anyone have idea on this issue? I have Apple Developer certificate installed, 
so my package is signed. I tried to turn of gate keeper on my MAC. But it did 
not help on build success rate at all.

Tai

[9] review request: 8156591: IllegalAccessError in JFXPanel after fix for JDK-8080395

2016-05-09 Thread Kevin Rushforth

Phil or Semyon,

Please review the following simple fix to comment out JFXPanel's use of 
the (now package-private) sun.awt.CausedFocusEvent class:


https://bugs.openjdk.java.net/browse/JDK-8156591
http://cr.openjdk.java.net/~kcr/8156591/webrev.00/

-- Kevin



9-dev unlocked following sanity testing

2016-05-09 Thread Kevin Rushforth




Re: Support for GTK 2 & 3 now in JFX

2016-05-09 Thread Jim Graham

Should we integrate that into prism.verbose output?

...jim

On 5/9/16 6:18 AM, David Hill wrote:


I added a new feature Friday and would like some help testing it.

This new feature (8087516: Conditional support for GTK 3 on Linux) allows us to 
use either GTK v2 or 3 with JavaFX.

The default has not changed - we will use gtk 2 by preference.

The help I need is for anyone doing testing on Linux with the current tree - 
like todays sanity testing. Adding

-Djdk.gtk.verbose=true

should output the version detected and used. I would appreciate a paste of that 
along with the OS version.

-Djdk.gtk.version=3

toggles the preferred version to GTK 3. Testing using that toggled would also 
be appreciated, along with a note to me
with the OS version.

thanks!



[9] Review request for 8150800: NullPointer exception in WebView

2016-05-09 Thread Murali Billa

Hi Kevin, Alexander

Please review below fix.

JBS : https://bugs.openjdk.java.net/browse/JDK-8150800

Webrev : http://cr.openjdk.java.net/~mbilla/8150800/webrev.00/


Thanks, 
Murali


Re: Request for backport of JDK-8144501

2016-05-09 Thread Jonathan Giles
Unfortunately openjfx-dev stripped the attachment, so please send that 
directly to me.


Are you certain that the linked changeset is the only change necessary 
to resolve the issue? A lot of code has changed in the selection models, 
and whilst the linked changeset is small enough that it can be 
backported, I'd be worried that it wasn't sufficient. If you haven't 
made a build with this change I can do it at some point, but please do 
flick through your test app.


Thanks,

-- Jonathan

On 10/05/16 6:25 AM, Robert Lichtenberger wrote:
We are currently experience null pointer problems that have their root 
cause in https://bugs.openjdk.java.net/browse/JDK-8144501.


The attached example demonstrates the problem: Click the first row, 
then Ctrl-Click the second row, then Ctrl-Click (i.e. deselect) the 
first row.


Up to jdk1.8.0_51 the output was (correct):
1Doe
1
---

but from jdk1.8.0_60 on the output is:
null
1
---

jdk-9-ea+116_linux-x64_bin.tar.gz shows correct output again.

Is there a way to backport the fixes (from 
http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/9b7e677b5314)?


Best regards,
Robert






Request for backport of JDK-8144501

2016-05-09 Thread Robert Lichtenberger
We are currently experience null pointer problems that have their root 
cause in https://bugs.openjdk.java.net/browse/JDK-8144501.


The attached example demonstrates the problem: Click the first row, then 
Ctrl-Click the second row, then Ctrl-Click (i.e. deselect) the first row.


Up to jdk1.8.0_51 the output was (correct):
1Doe
1
---

but from jdk1.8.0_60 on the output is:
null
1
---

jdk-9-ea+116_linux-x64_bin.tar.gz shows correct output again.

Is there a way to backport the fixes (from 
http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/9b7e677b5314)?


Best regards,
Robert




Re: [graphics] [9] Review request for 8155903: Crash while running imported/w3c/canvas/2d.gradient.interpolate.overlap2.html

2016-05-09 Thread Jim Graham
That looks good for the case where Imin is zero, but it appears that we could also have overflow as well, with a single 
very tiny Imin the accumulation of estimatedSize with an "int" type could easily overflow and become essentially a 
random number.  Changing the estimatedSize variable to a float should prevent that related issue...


...jim

On 5/9/16 6:16 AM, Arunprasad Rajkumar wrote:

Hello Jim,

Thanks for your suggestions. As of now I taking an easy way to fix the issue, 
New changes are available at
http://cr.openjdk.java.net/~arajkumar/8155903/webrev.02

I couldn't write a reliable test case using public javafx APIs, the behavior is 
intermittent. However I could
consistently produce the issue using our DRT internal test case which is based 
on W3C functional test[1].

[1] 
http://w3c-test.org/2dcontext/fill-and-stroke-styles/2d.gradient.interpolate.overlap2.html

Thanks,
Arun

On 5/5/2016 11:51 PM, Jim Graham wrote:

Hi Arun,

The change you made to the calculateSingleArray method looks like it produces a 
bad array of color stops for the case
where Imin is 0.  You should fall into the calculateMultipleArray method 
instead which should not have any trouble
with zero length intervals.  At that point you don't have to have any code in 
calculateSingleArray that deals with
Imin being zero because that can be part of its calling contract.

That is the quick fix.

The harder fix that would let us maintain speed when there is a zero interval 
would be to teach the code what to do in
that special case. Basically a zero interval means that we have a case where 
approaching the interval point from the
left is interpolating towards colorA, but leaving that point from the right is 
interpolating from colorB, with a
sudden transition between those 2.  In that case, a zero interval shouldn't 
affect the Imin, since the Imin is trying
to determine the size of each interpolated region and we don't interpolate 
across a zero-sized interval.  So, the scan
for Imin would simply ignore zero length intervals.  Later, the code that 
populates the array in the
calculateSingleArray function would know that the zero length interval simply means swap 
in a new "from color" without
any actual interpolation.

Getting that harder fix right would require a lot of testing, so it may be 
better to do the quick fix now to stop the
exceptions and then deal with the optimization as a tweak filed for later...

...jim

On 05/05/2016 01:57 AM, Arunprasad Rajkumar wrote:

Hello Jim,

Please review the below patch.

JIRA: https://bugs.openjdk.java.net/browse/JDK-8155903

Webrev: http://cr.openjdk.java.net/~arajkumar/8155903/webrev.01

Issue: Divide by zero while adding multiple gradient stops at same offset.

Regards,
Arun







Re: Support for GTK 2 & 3 now in JFX

2016-05-09 Thread David Hill

On 5/9/16, 9:39 AM, Erik De Rijcke wrote:

Hi,

Are there any known limitations on the gtk3 backends (html5, wayland, ...) that 
could be used?

In short - no, but do tell if you find some :-)

The problem before was that you can't mix GTK2 & 3 in the same application, so SWT 
for example that is using GTK3 would crash and burn. With the addition of dynamic loading 
of GTK we can at least avoid that issue - at least as long as you tell the app which 
version to use. I have a task to investigate detecting if a version is already in use 
, but that has some portability 
issues and might not make the final product. I am not aware of any reason why there would 
be an issue - unless there is something with the GTK event loop.

Let me know if you give it a try.

Dave


regards,

Erik

On Mon, May 9, 2016 at 3:18 PM, David Hill > wrote:


I added a new feature Friday and would like some help testing it.

This new feature (8087516: Conditional support for GTK 3 on Linux) allows 
us to use either GTK v2 or 3 with JavaFX.

The default has not changed - we will use gtk 2 by preference.

The help I need is for anyone doing testing on Linux with the current tree 
- like todays sanity testing. Adding

-Djdk.gtk.verbose=true

should output the version detected and used. I would appreciate a paste of 
that along with the OS version.

-Djdk.gtk.version=3

toggles the preferred version to GTK 3. Testing using that toggled would 
also be appreciated, along with a note to me with the OS version.

thanks!

-- 
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)



Re: Support for GTK 2 & 3 now in JFX

2016-05-09 Thread Erik De Rijcke
Hi,

Are there any known limitations on the gtk3 backends (html5, wayland, ...)
that could be used?

regards,

Erik

On Mon, May 9, 2016 at 3:18 PM, David Hill  wrote:

>
> I added a new feature Friday and would like some help testing it.
>
> This new feature (8087516: Conditional support for GTK 3 on Linux) allows
> us to use either GTK v2 or 3 with JavaFX.
>
> The default has not changed - we will use gtk 2 by preference.
>
> The help I need is for anyone doing testing on Linux with the current tree
> - like todays sanity testing. Adding
>
> -Djdk.gtk.verbose=true
>
> should output the version detected and used. I would appreciate a paste of
> that along with the OS version.
>
> -Djdk.gtk.version=3
>
> toggles the preferred version to GTK 3. Testing using that toggled would
> also be appreciated, along with a note to me with the OS version.
>
> thanks!
>
> --
> 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)
>
>


Support for GTK 2 & 3 now in JFX

2016-05-09 Thread David Hill


I added a new feature Friday and would like some help testing it.

This new feature (8087516: Conditional support for GTK 3 on Linux) allows us to 
use either GTK v2 or 3 with JavaFX.

The default has not changed - we will use gtk 2 by preference.

The help I need is for anyone doing testing on Linux with the current tree - 
like todays sanity testing. Adding

-Djdk.gtk.verbose=true

should output the version detected and used. I would appreciate a paste of that 
along with the OS version.

-Djdk.gtk.version=3

toggles the preferred version to GTK 3. Testing using that toggled would also 
be appreciated, along with a note to me with the OS version.

thanks!

--
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)



Re: [graphics] [9] Review request for 8155903: Crash while running imported/w3c/canvas/2d.gradient.interpolate.overlap2.html

2016-05-09 Thread Arunprasad Rajkumar

Hello Jim,

Thanks for your suggestions. As of now I taking an easy way to fix the 
issue, New changes are available at 
http://cr.openjdk.java.net/~arajkumar/8155903/webrev.02


I couldn't write a reliable test case using public javafx APIs, the 
behavior is intermittent. However I could consistently produce the issue 
using our DRT internal test case which is based on W3C functional test[1].


[1] 
http://w3c-test.org/2dcontext/fill-and-stroke-styles/2d.gradient.interpolate.overlap2.html


Thanks,
Arun

On 5/5/2016 11:51 PM, Jim Graham wrote:

Hi Arun,

The change you made to the calculateSingleArray method looks like it 
produces a bad array of color stops for the case where Imin is 0.  You 
should fall into the calculateMultipleArray method instead which 
should not have any trouble with zero length intervals.  At that point 
you don't have to have any code in calculateSingleArray that deals 
with Imin being zero because that can be part of its calling contract.


That is the quick fix.

The harder fix that would let us maintain speed when there is a zero 
interval would be to teach the code what to do in that special case. 
Basically a zero interval means that we have a case where approaching 
the interval point from the left is interpolating towards colorA, but 
leaving that point from the right is interpolating from colorB, with a 
sudden transition between those 2.  In that case, a zero interval 
shouldn't affect the Imin, since the Imin is trying to determine the 
size of each interpolated region and we don't interpolate across a 
zero-sized interval.  So, the scan for Imin would simply ignore zero 
length intervals.  Later, the code that populates the array in the 
calculateSingleArray function would know that the zero length interval 
simply means swap in a new "from color" without any actual interpolation.


Getting that harder fix right would require a lot of testing, so it 
may be better to do the quick fix now to stop the exceptions and then 
deal with the optimization as a tweak filed for later...


...jim

On 05/05/2016 01:57 AM, Arunprasad Rajkumar wrote:

Hello Jim,

Please review the below patch.

JIRA: https://bugs.openjdk.java.net/browse/JDK-8155903

Webrev: http://cr.openjdk.java.net/~arajkumar/8155903/webrev.01

Issue: Divide by zero while adding multiple gradient stops at same 
offset.


Regards,
Arun