from:"Alexander Nyssen"

Review request for JDK-8173852: FXCanvas needs to invert rotation angle when forwarding a gesture event.

2017-02-03 Thread Alexander Nyssen

Hallo Kevin, hallo Alexander,

please review the following fix:

https://bugs.openjdk.java.net/browse/JDK-8173852 

http://cr.openjdk.java.net/~anyssen/8173852/webrev/ 


Best Regards,
Alexander

Re: Review request for 8166242: Removal of com.sun.javafx.embed.AbstractEvents

2016-09-22 Thread Alexander Nyssen

Hi Kevin,

I had already expected something like this (while I did not know the process in 
detail). It's definitely not an urgent thing, postponing it will not block 
other work. I already investigated it now, because applying it would probably 
make things easier when fixing other issues related to FXCanvas.

Best Regards,
Alexander

> Am 22.09.2016 um 14:21 schrieb Kevin Rushforth <kevin.rushfo...@oracle.com>:
> 
> Hi Alexander,
> 
> Since this is an enhancement, it needs to go through the FC extension process 
> indicated here:
> 
> http://openjdk.java.net/projects/jdk9/fc-extension-process
> 
> First and foremost, we will need to assess the impact of the change and 
> whether this is the right time to consider such a change. I note that since 
> this does not add additional functionality, but just refactors existing 
> functionality to be easier to maintain, we might at least consider it when/if 
> the recently announced schedule slip for JDK 9 becomes effective.
> 
> -- Kevin
> 
> 
> Alexander Nyssen wrote:
>> Hallo Kevin, Alexander Z, Vadim,
>> 
>> I have created an initial patch for the replacement of AbstractEvents with 
>> direct usage of JavaFX representations:
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8166242 
>> http://cr.openjdk.java.net/~anyssen/8166242/webrev.00/
>> 
>> Best Regards,
>> Alexander

Re: :graphics:compilePrismCompilers fails with latest 9-dev tip on my mac

2016-09-21 Thread Alexander Nyssen

Hi Dave,

I am using 2.11, as recommend. But as already said, the problem was on my side.

Best Regards,
Alexander

> Am 21.09.2016 um 15:39 schrieb David Hill <david.h...@oracle.com>:
> 
> On 9/21/16, 2:58 AM, Alexander Nyssen wrote:
>> Hi all,
>> 
>> having updated 9-dev to the latest tip, the gradle build now fails on my Mac 
>> with the following errors. Updating JIGSAW home to ea136 did not resolve the 
>> problems. Any ideas?
> 
> What version of gradle are you using ?
> 
> 
> Dave
>> 
>> Best Regards,
>> Alexander
>> 
>> :graphics:compilePrismCompilers
>> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:26:
>>  error: package com.sun.scenario.effect.compiler does not exist
>> import com.sun.scenario.effect.compiler.JSLC;
>>^
>> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:27:
>>  error: package com.sun.scenario.effect.compiler.JSLC does not exist
>> import com.sun.scenario.effect.compiler.JSLC.JSLCInfo;
>> ^
>> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:28:
>>  error: package com.sun.scenario.effect.compiler does not exist
>> import com.sun.scenario.effect.compiler.JSLParser;
>>^
>> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:29:
>>  error: package com.sun.scenario.effect.compiler.model does not exist
>> import com.sun.scenario.effect.compiler.model.BaseType;
>>  ^
>> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:30:
>>  error: package com.sun.scenario.effect.compiler.model does not exist
>> import com.sun.scenario.effect.compiler.model.Qualifier;
>>  ^
>> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:31:
>>  error: package com.sun.scenario.effect.compiler.model does not exist
>> import com.sun.scenario.effect.compiler.model.Variable;
>>  ^
>> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:32:
>>  error: package com.sun.scenario.effect.compiler.tree does not exist
>> import com.sun.scenario.effect.compiler.tree.ProgramUnit;
>> ^
>> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:33:
>>  error: package com.sun.scenario.effect.compiler.tree does not exist
>> import com.sun.scenario.effect.compiler.tree.TreeScanner;
>> ^
>> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:34:
>>  error: package com.sun.scenario.effect.compiler.tree does not exist
>> import com.sun.scenario.effect.compiler.tree.VariableExpr;
>> ^
>> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:205:
>>  error: cannot find symbol
>> private static ShaderInfo getMaskInfo(JSLCInfo jslcinfo, MaskType 
>> maskType)
>>   ^
>>   symbol:   class JSLCInfo
>>   location: class CompileJSL
>> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:211:
>>  error: cannot find symbol
>> private static ShaderInfo getMaskInfo(JSLCInfo jslcinfo, AlphaMaskType 
>> maskType)
>>   ^
>>   symbol:   class JSLCInfo
>>   location: class CompileJSL
>> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:217:
>>  error: cannot find symbol
>> private static ShaderInfo getMaskInfo(JSLCInfo jslcinfo, String maskName,
>>   ^
>>   symbol:   class JSLCInfo
>>   location: class CompileJSL
>> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:228:
>>  error: cannot find symbol
>> private static ShaderInfo getPaintInfo(JSLCInfo jslcinfo, String 
>> paintName,
>>

Re: :graphics:compilePrismCompilers fails with latest 9-dev tip on my mac

2016-09-21 Thread Alexander Nyssen

Hi Vadim,

you were right. My build.gradle was tampered. Sorry for the noise.

Best Regards,
Alexander

> Am 21.09.2016 um 12:11 schrieb Vadim Pakhnushev <vadim.pakhnus...@oracle.com>:
> 
> And you don't have any local modifications?
> That's strange, I just tried it on my mac and it works fine.
> Let's see your gradle --debug log then.
> 
> Vadim
> 
> On 21.09.2016 11:23, Alexander Nyssen wrote:
>> Hi Vadim,
>> 
>> unfortunately both does not help, the problem persists.
>> 
>> Best Regards,
>> Alexander
>> 
>>> Am 21.09.2016 um 10:02 schrieb Vadim Pakhnushev 
>>> <vadim.pakhnus...@oracle.com>:
>>> 
>>> Hi Alexander,
>>> 
>>> This happens because in the 
>>> https://bugs.openjdk.java.net/browse/JDK-8165809 these parts of build were 
>>> reworked.
>>> You could start with gradle cleanAll, if it doesn't help, then rm -r build 
>>> buildSrc/build should help.
>>> 
>>> Thanks,
>>> Vadim
>>> 
>>> On 21.09.2016 9:58, Alexander Nyssen wrote:
>>>> Hi all,
>>>> 
>>>> having updated 9-dev to the latest tip, the gradle build now fails on my 
>>>> Mac with the following errors. Updating JIGSAW home to ea136 did not 
>>>> resolve the problems. Any ideas?
>>>> 
>>>> Best Regards,
>>>> Alexander
>>>> 
>>>> :graphics:compilePrismCompilers
>>>> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:26:
>>>>  error: package com.sun.scenario.effect.compiler does not exist
>>>> import com.sun.scenario.effect.compiler.JSLC;
>>>>^
>>>> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:27:
>>>>  error: package com.sun.scenario.effect.compiler.JSLC does not exist
>>>> import com.sun.scenario.effect.compiler.JSLC.JSLCInfo;
>>>> ^
>>>> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:28:
>>>>  error: package com.sun.scenario.effect.compiler does not exist
>>>> import com.sun.scenario.effect.compiler.JSLParser;
>>>>^
>>>> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:29:
>>>>  error: package com.sun.scenario.effect.compiler.model does not exist
>>>> import com.sun.scenario.effect.compiler.model.BaseType;
>>>>  ^
>>>> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:30:
>>>>  error: package com.sun.scenario.effect.compiler.model does not exist
>>>> import com.sun.scenario.effect.compiler.model.Qualifier;
>>>>  ^
>>>> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:31:
>>>>  error: package com.sun.scenario.effect.compiler.model does not exist
>>>> import com.sun.scenario.effect.compiler.model.Variable;
>>>>  ^
>>>> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:32:
>>>>  error: package com.sun.scenario.effect.compiler.tree does not exist
>>>> import com.sun.scenario.effect.compiler.tree.ProgramUnit;
>>>> ^
>>>> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:33:
>>>>  error: package com.sun.scenario.effect.compiler.tree does not exist
>>>> import com.sun.scenario.effect.compiler.tree.TreeScanner;
>>>> ^
>>>> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:34:
>>>>  error: package com.sun.scenario.effect.compiler.tree does not exist
>>>> import com.sun.scenario.effect.compiler.tree.VariableExpr;
>>>> ^
>>>> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:205:
>>>>  error: cannot find symbol
>>>>

Re: :graphics:compilePrismCompilers fails with latest 9-dev tip on my mac

2016-09-21 Thread Alexander Nyssen

Hi Vadim,

unfortunately both does not help, the problem persists.

Best Regards,
Alexander

> Am 21.09.2016 um 10:02 schrieb Vadim Pakhnushev <vadim.pakhnus...@oracle.com>:
> 
> Hi Alexander,
> 
> This happens because in the https://bugs.openjdk.java.net/browse/JDK-8165809 
> these parts of build were reworked.
> You could start with gradle cleanAll, if it doesn't help, then rm -r build 
> buildSrc/build should help.
> 
> Thanks,
> Vadim
> 
> On 21.09.2016 9:58, Alexander Nyssen wrote:
>> Hi all,
>> 
>> having updated 9-dev to the latest tip, the gradle build now fails on my Mac 
>> with the following errors. Updating JIGSAW home to ea136 did not resolve the 
>> problems. Any ideas?
>> 
>> Best Regards,
>> Alexander
>> 
>> :graphics:compilePrismCompilers
>> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:26:
>>  error: package com.sun.scenario.effect.compiler does not exist
>> import com.sun.scenario.effect.compiler.JSLC;
>>^
>> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:27:
>>  error: package com.sun.scenario.effect.compiler.JSLC does not exist
>> import com.sun.scenario.effect.compiler.JSLC.JSLCInfo;
>> ^
>> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:28:
>>  error: package com.sun.scenario.effect.compiler does not exist
>> import com.sun.scenario.effect.compiler.JSLParser;
>>^
>> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:29:
>>  error: package com.sun.scenario.effect.compiler.model does not exist
>> import com.sun.scenario.effect.compiler.model.BaseType;
>>  ^
>> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:30:
>>  error: package com.sun.scenario.effect.compiler.model does not exist
>> import com.sun.scenario.effect.compiler.model.Qualifier;
>>  ^
>> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:31:
>>  error: package com.sun.scenario.effect.compiler.model does not exist
>> import com.sun.scenario.effect.compiler.model.Variable;
>>  ^
>> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:32:
>>  error: package com.sun.scenario.effect.compiler.tree does not exist
>> import com.sun.scenario.effect.compiler.tree.ProgramUnit;
>> ^
>> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:33:
>>  error: package com.sun.scenario.effect.compiler.tree does not exist
>> import com.sun.scenario.effect.compiler.tree.TreeScanner;
>> ^
>> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:34:
>>  error: package com.sun.scenario.effect.compiler.tree does not exist
>> import com.sun.scenario.effect.compiler.tree.VariableExpr;
>> ^
>> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:205:
>>  error: cannot find symbol
>> private static ShaderInfo getMaskInfo(JSLCInfo jslcinfo, MaskType 
>> maskType)
>>   ^
>>   symbol:   class JSLCInfo
>>   location: class CompileJSL
>> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:211:
>>  error: cannot find symbol
>> private static ShaderInfo getMaskInfo(JSLCInfo jslcinfo, AlphaMaskType 
>> maskType)
>>   ^
>>   symbol:   class JSLCInfo
>>   location: class CompileJSL
>> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:217:
>>  error: cannot find symbol
>> private static ShaderInfo getMaskInfo(JSLCInfo jslcinfo, String maskName,
>>   ^
>>   symbol:   class JSLCInfo
>>   location: class CompileJSL
>> /Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graph

:graphics:compilePrismCompilers fails with latest 9-dev tip on my mac

2016-09-21 Thread Alexander Nyssen

Hi all, 

having updated 9-dev to the latest tip, the gradle build now fails on my Mac 
with the following errors. Updating JIGSAW home to ea136 did not resolve the 
problems. Any ideas?

Best Regards,
Alexander

:graphics:compilePrismCompilers
/Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:26:
 error: package com.sun.scenario.effect.compiler does not exist
import com.sun.scenario.effect.compiler.JSLC;
   ^
/Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:27:
 error: package com.sun.scenario.effect.compiler.JSLC does not exist
import com.sun.scenario.effect.compiler.JSLC.JSLCInfo;
^
/Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:28:
 error: package com.sun.scenario.effect.compiler does not exist
import com.sun.scenario.effect.compiler.JSLParser;
   ^
/Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:29:
 error: package com.sun.scenario.effect.compiler.model does not exist
import com.sun.scenario.effect.compiler.model.BaseType;
 ^
/Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:30:
 error: package com.sun.scenario.effect.compiler.model does not exist
import com.sun.scenario.effect.compiler.model.Qualifier;
 ^
/Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:31:
 error: package com.sun.scenario.effect.compiler.model does not exist
import com.sun.scenario.effect.compiler.model.Variable;
 ^
/Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:32:
 error: package com.sun.scenario.effect.compiler.tree does not exist
import com.sun.scenario.effect.compiler.tree.ProgramUnit;
^
/Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:33:
 error: package com.sun.scenario.effect.compiler.tree does not exist
import com.sun.scenario.effect.compiler.tree.TreeScanner;
^
/Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:34:
 error: package com.sun.scenario.effect.compiler.tree does not exist
import com.sun.scenario.effect.compiler.tree.VariableExpr;
^
/Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:205:
 error: cannot find symbol
private static ShaderInfo getMaskInfo(JSLCInfo jslcinfo, MaskType maskType)
  ^
  symbol:   class JSLCInfo
  location: class CompileJSL
/Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:211:
 error: cannot find symbol
private static ShaderInfo getMaskInfo(JSLCInfo jslcinfo, AlphaMaskType 
maskType)
  ^
  symbol:   class JSLCInfo
  location: class CompileJSL
/Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:217:
 error: cannot find symbol
private static ShaderInfo getMaskInfo(JSLCInfo jslcinfo, String maskName,
  ^
  symbol:   class JSLCInfo
  location: class CompileJSL
/Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:228:
 error: cannot find symbol
private static ShaderInfo getPaintInfo(JSLCInfo jslcinfo, String paintName,
   ^
  symbol:   class JSLCInfo
  location: class CompileJSL
/Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:239:
 error: cannot find symbol
private static void compileColorPaint(JSLCInfo jslcinfo, ShaderInfo 
maskInfo, boolean alphaTest)
  ^
  symbol:   class JSLCInfo
  location: class CompileJSL
/Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:248:
 error: cannot find symbol
private static void compileGradientPaint(JSLCInfo jslcinfo,
 ^
  symbol:   class JSLCInfo
  location: class CompileJSL
/Users/nyssen/mercurial/openjfx/9-dev/rt-JDK-8166242/modules/javafx.graphics/src/main/jsl-prism/CompileJSL.java:272:
 error: cannot find symbol
private static void compileAlphaGradientPaint(JSLCInfo jslcinfo,

Re: Necessity of com.sun.javafx.embed.AbstractEvents

2016-09-18 Thread Alexander Nyssen

Hi Artem,

> Am 17.09.2016 um 00:12 schrieb Artem Ananiev <artem.anan...@oracle.com>:
> 
> Hi, Alexander,
> 
> I believe I introduced that extra abstraction layer for FX/Swing events long 
> time ago. At that time, we thought we might eventually want to embed 
> different components than just JavaFX, but it doesn't make any sense these 
> days. JFXPanel and FXCanvas contain a lot of FX specific code, they can't be 
> used to embed anything than FX. I agree that AbstractEvents is redundant and 
> can be replaced by FX events.

thanks for clarifying this. I have raised JDK-8166242 
<https://bugs.openjdk.java.net/browse/JDK-8166242> (Removal of 
com.sun.javafx.embed.AbstractEvents) to keep track of the issue.

> 
> BTW, SwingNode (which is opposite to JFXPanel, it's to embed Swing into FX) 
> doesn't use AbstractEvents, but operates directly with FX events.

That sounds like an additional argument for the removal of AbstractEvents. 
Thanks for having pointed that out.

Just to mention it (in case somebody searches for such functionality), within 
GEF we have introduced something comparable for embedding SWT controls (in the 
context of an FXCanvas). We called it FXControlAdapter 
(https://github.com/eclipse/gef/blob/master/org.eclipse.gef.fx.swt/src/org/eclipse/gef/fx/swt/controls/FXControlAdapter.java).
 It’s still pretty basic, but might be a good starting point.
> 
> Thanks,
> 
> Artem

Best Regards,
Alexander

> 
> On 9/16/16, 2:03 AM, Alexander Nyssen wrote:
>> Hi Alexander Z., Kevin,
>> 
>> while working on JDK-8143596 (FXCanvas does not forward touch
>> gestures to embedded scene) I came across some „smell“ that I would
>> like to discuss. That is, the information about events that is
>> exchanged between JFXPanel/FXCanvas and the
>> EmbeddedScene/EmbeddedStage is currently encoded via constants of
>> com.sun.javafx.embed.AbstractEvents. That is, FXCanvas and JFXPanel
>> map SWT and AWT event information to constants in AbstractEvents,
>> which are finally mapped to a JavaFX representations within
>> EmbeddedScene.
>> 
>> Without knowing the motivation behind this indirection, and without
>> having tried it in detail yet, for me it seems as if AbstractEvents
>> was superfluous and JavaFX representations could directly be used to
>> transfer this information instead. In case of
>> EmbeddedSceneInterface#inputMethodEvent() for instance,
>> AbstractEvents was already bypassed, as here EventType is used as a
>> parameter (instead of an AbstractEvents constant). Also, the modifier
>> constants defined within AbstractEvents are only used in case of key
>> events, while for mouse (and now gesture events) boolean parameters
>> are used to transport this information (which could also be done in
>> case of key events).
>> 
>> What do you think? In case you share my assessment I would propose to
>> file a separate issue for this, and I could offer to investigate it
>> after JDK-8143596 has been resolved (I would not want to mingle it).
>> 
>> Best Regards,
> 
>> Alexander

Necessity of com.sun.javafx.embed.AbstractEvents

2016-09-16 Thread Alexander Nyssen

Hi Alexander Z., Kevin,

while working on JDK-8143596 (FXCanvas does not forward touch gestures to 
embedded scene) I came across some „smell“ that I would like to discuss. That 
is, the information about events that is exchanged between JFXPanel/FXCanvas 
and the EmbeddedScene/EmbeddedStage is currently encoded via constants of 
com.sun.javafx.embed.AbstractEvents. That is, FXCanvas and JFXPanel map SWT and 
AWT event information to constants in AbstractEvents, which are finally mapped 
to a JavaFX representations within EmbeddedScene.

Without knowing the motivation behind this indirection, and without having 
tried it in detail yet, for me it seems as if AbstractEvents was superfluous 
and JavaFX representations could directly be used to transfer this information 
instead. In case of EmbeddedSceneInterface#inputMethodEvent() for instance, 
AbstractEvents was already bypassed, as here EventType is used as a parameter 
(instead of an AbstractEvents constant). Also, the modifier constants defined 
within AbstractEvents are only used in case of key events, while for mouse (and 
now gesture events) boolean parameters are used to transport this information 
(which could also be done in case of key events).

What do you think? In case you share my assessment I would propose to file a 
separate issue for this, and I could offer to investigate it after JDK-8143596 
has been resolved (I would not want to mingle it).

Best Regards,
Alexander

Review request [2] for 8143596: FXCanvas does not forward touch gestures to embedded scene

2016-09-15 Thread Alexander Nyssen

Hallo Alexander Z., Kevin,

I have adjusted the patch for JDK-8143596 to reflect the initial review finding 
of Alexander Z. and to fix some whitespace issues:

https://bugs.openjdk.java.net/browse/JDK-8143596
http://cr.openjdk.java.net/~anyssen/8143596/webrev.01/ 


Best Regards
Alexander

> Anfang der weitergeleiteten Nachricht:
> 
> Von: Alexander Nyßen 
> Betreff: Review request for 8143596: FXCanvas does not forward touch gestures 
> to embedded scene
> Datum: 10. September 2016 um 13:58:54 MESZ
> An: openjfx-dev@openjdk.java.net
> 
> Hi Alexander Z., Kevin,
> 
> I have adopted my latest patch for JDK-8143596 (uploaded yesterday as patch 
> file) to the latest tip and created a webrev for it (the uploaded patch is 
> therefore now obsolete):
> 
> https://bugs.openjdk.java.net/browse/JDK-8143596
> http://cr.openjdk.java.net/~anyssen/8143596/webrev.00/
> 
> Best Regards,
> Alexander

Re: javafx.embed.swt.* regarded as JDK internal API by jdeps of jdk9-ea135

2016-09-14 Thread Alexander Nyssen

Hi Kevin,


> Am 14.09.2016 um 22:38 schrieb Kevin Rushforth <kevin.rushfo...@oracle.com>:
> 
> I can't speak to what Tom is expecting, but javafx-swt.jar will not be an 
> explicit module. It will be delivered as an automatic (implicit) module. This 
> is required because swt.jar is not modularized.

of course you can’t. Neither can I, but I thought it worth to ask explicitly 
here in order to unveil a potential misunderstanding. I personally thought the 
plan was to turn javafx-swt.jar into an explicit module and to have swt.jar as 
the automatic one, which is the reason I asked for a schedule. So thanks for 
clarifying this.

> 
> The proposed approach of loading this into a Layer defined by the 
> OSGi-Adapter-Hook should work without the javafx-swt.jar file needing to have 
> a module-info.class file (at least the Jigsaw team believes that it will 
> work). This still needs to be tested.

If I can support this to some extent please let me know. We (that is the 
Eclipse Graphical Editing Framework project in this case) will basically be 
lost if this is not going to work, as we have committed ourselves to JavaFX and 
FXCanvas is our single „bridge“ back to the Eclipse Workbench/SWT world. 

> 
> — Kevin

Best Regards 
Alexander

> 
> 
> Alexander Nyssen wrote:
>> 
>> Tom, 
>> 
>> just to make that explicit: you expected it to be shipped as an explicit and 
>> not as an automatic, implicit module by the OpenJFX team?
>> 
>> Regards,
>> Alexander
>> 
>>   
>>> Am 14.09.2016 um 09:26 schrieb Tom Schindl <tom.schi...@bestsolution.at> 
>>> <mailto:tom.schi...@bestsolution.at>:
>>> 
>>> I expect javafx.swt to be shipped with the jdk/jre - i can not repackage 
>>> and ship openjfx code from eclipse.org
>>> 
>>> Tom
>>> 
>>> Von meinem iPhone gesendet
>>> 
>>> 
>>>> Am 14.09.2016 um 08:51 schrieb Alexander Nyssen <alexan...@nyssen.org> 
>>>> <mailto:alexan...@nyssen.org>:
>>>> 
>>>> Hi Tom, Kevin,
>>>> 
>>>> I have to admit that - now - I am somehow confused. At first glance "the 
>>>> expectation is that javafx.swt will be added as an automatic (and thus 
>>>> named) module in a layer“ and "it will not be an autom[at]ic-module but a 
>>>> named one loaded in a […] layer“ sounds like a contradiction. Tom, did you 
>>>> plan to „repackage“ the automatic (and thus implicitly defined) javafx.swt 
>>>> module as an explicit one as part of e(fx)clipse, or did you - like me - 
>>>> expect that javafx.swt will yet be turned into an explicit module by the 
>>>> OpenJFX team?
>>>> 
>>>> Best Regards,
>>>> Alexander
>>>> 
>>>>   
>>>>> Am 14.09.2016 um 00:51 schrieb Tom Schindl <tom.schi...@bestsolution.at> 
>>>>> <mailto:tom.schi...@bestsolution.at>:
>>>>> 
>>>>> Hi,
>>>>> 
>>>>> javafx.swt can never be a module loaded by default but we need to
>>>>> construct a new layer who has the SWT-Bundle-Classloader as the parent.
>>>>> 
>>>>> So no it will not be an automic-module but a named one loaded in a
>>>>> secondary layer (eg by the efxclipse OSGi-Adapter-Hook) - at least this
>>>>> is the theory. I didn't have time yet to follow this path yet.
>>>>> 
>>>>> Tom
>>>>> 
>>>>> 
>>>>>> On 13.09.16 20:31, Alexander Nyssen wrote:
>>>>>> Hi Kevin,
>>>>>> 
>>>>>>   
>>>>>>> Am 13.09.2016 um 16:30 schrieb Kevin Rushforth 
>>>>>>> <kevin.rushfo...@oracle.com> <mailto:kevin.rushfo...@oracle.com>:
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> Alexander Nyssen wrote:
>>>>>>> 
>>>>>>>> Hi Kevin,
>>>>>>>> 
>>>>>>>>   
>>>>>>>>> Am 13.09.2016 um 15:42 schrieb Kevin Rushforth 
>>>>>>>>> <kevin.rushfo...@oracle.com <mailto:kevin.rushfo...@oracle.com> 
>>>>>>>>> <mailto:kevin.rushfo...@oracle.com> 
>>>>>>>>> <mailto:kevin.rushfo...@oracle.com>>:
>>>>>>>>> 
>>>>>>>>> That seems surprising since javafx.swt is not part of the JDK runtime 
&

Re: javafx.embed.swt.* regarded as JDK internal API by jdeps of jdk9-ea135

2016-09-14 Thread Alexander Nyssen

Tom, 

just to make that explicit: you expected it to be shipped as an explicit and 
not as an automatic, implicit module by the OpenJFX team?

Regards,
Alexander

> Am 14.09.2016 um 09:26 schrieb Tom Schindl <tom.schi...@bestsolution.at>:
> 
> I expect javafx.swt to be shipped with the jdk/jre - i can not repackage and 
> ship openjfx code from eclipse.org
> 
> Tom
> 
> Von meinem iPhone gesendet
> 
>> Am 14.09.2016 um 08:51 schrieb Alexander Nyssen <alexan...@nyssen.org>:
>> 
>> Hi Tom, Kevin,
>> 
>> I have to admit that - now - I am somehow confused. At first glance "the 
>> expectation is that javafx.swt will be added as an automatic (and thus 
>> named) module in a layer“ and "it will not be an autom[at]ic-module but a 
>> named one loaded in a […] layer“ sounds like a contradiction. Tom, did you 
>> plan to „repackage“ the automatic (and thus implicitly defined) javafx.swt 
>> module as an explicit one as part of e(fx)clipse, or did you - like me - 
>> expect that javafx.swt will yet be turned into an explicit module by the 
>> OpenJFX team?
>> 
>> Best Regards,
>> Alexander
>> 
>>> Am 14.09.2016 um 00:51 schrieb Tom Schindl <tom.schi...@bestsolution.at>:
>>> 
>>> Hi,
>>> 
>>> javafx.swt can never be a module loaded by default but we need to
>>> construct a new layer who has the SWT-Bundle-Classloader as the parent.
>>> 
>>> So no it will not be an automic-module but a named one loaded in a
>>> secondary layer (eg by the efxclipse OSGi-Adapter-Hook) - at least this
>>> is the theory. I didn't have time yet to follow this path yet.
>>> 
>>> Tom
>>> 
>>>> On 13.09.16 20:31, Alexander Nyssen wrote:
>>>> Hi Kevin,
>>>> 
>>>>> Am 13.09.2016 um 16:30 schrieb Kevin Rushforth 
>>>>> <kevin.rushfo...@oracle.com>:
>>>>> 
>>>>> 
>>>>> 
>>>>> Alexander Nyssen wrote:
>>>>>> Hi Kevin,
>>>>>> 
>>>>>>> Am 13.09.2016 um 15:42 schrieb Kevin Rushforth 
>>>>>>> <kevin.rushfo...@oracle.com <mailto:kevin.rushfo...@oracle.com>>:
>>>>>>> 
>>>>>>> That seems surprising since javafx.swt is not part of the JDK runtime 
>>>>>>> image. I suspect that this is either an issue with jdeps itself or with 
>>>>>>> how you are running jdeps. What was the command line you were using?
>>>>>> 
>>>>>> I used: for i in */bin; do 
>>>>>> /Library/Java/JavaVirtualMachines/jdk-9_ea135.jdk/Contents/Home/bin/jdeps
>>>>>>  -jdkinternals $i; done >> deps.txt
>>>>> 
>>>>> That doesn't show how javafx-swt.jar is being referenced. javafx-swt.jar 
>>>>> is delivered with the JDK, but is not loaded by default (or at least it 
>>>>> should not be).
>>>> 
>>>> Is there a way to find out? Do I have to provide additional options? Using 
>>>> jdk-9-ea109 the same command line did not result in javafx.swt being 
>>>> regarded as JDK internal.
>>>> 
>>>>> 
>>>>> 
>>>>>>> As for your second question, the expectation is that javafx.swt will be 
>>>>>>> added as an automatic (and thus named) module in a layer, but that 
>>>>>>> still needs to be tested. We currently do all of our own testing by 
>>>>>>> adding it as an automatic module on the module path as follows:
>>>>>>> 
>>>>>>> $ java --module-path $JAVA_HOME/lib/javafx-swt.jar --add-modules 
>>>>>>> javafx.swt my.pkg.MyApp
>>>>>> 
>>>>>> I see. Is there a concrete schedule?
>>>>> 
>>>>> If you mean is there a concrete schedule for the Eclipse folks to do the 
>>>>> work to verify that javafx.swt can be loaded in a layer, I can't comment 
>>>>> on that, since this work is outside the scope of the JDK. Perhaps Tom 
>>>>> Schindl can respond?
>>>> 
>>>> I thought the plan was to turn javafx.swt into an explicit module and not 
>>>> an (implicit) automatic one, and I was referring to when this was 
>>>> finalized. Seems I got that wrong.
>>>> 
>>>>> 
>>>>> — Kevin
>>>> 
>>>> Best Regards,
>>>> Alexander
>>>> 
>>>>> 
>>>>>> 
>>>>>>> 
>>>>>>> — Kevin
>>>>>> 
>>>>>> Best Regards,
>>>>>> Alexander
>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> Alexander Nyssen wrote:
>>>>>>>> Hi all,
>>>>>>>> 
>>>>>>>> I used a recent jdeps (from jdk9-ea135) to check the Eclipse GEF code 
>>>>>>>> base and was astonished to see that all dependencies to 
>>>>>>>> javafx.embed.swt.* now seem to be regarded as JDK internal API. I 
>>>>>>>> assume this is just a temporal inconsistency. Therefore, let me ask 
>>>>>>>> when it is planned to transfer the javafx.swt module into a proper 
>>>>>>>> named JIGSAW module to resolve this. The Eclipse community relies on 
>>>>>>>> using the javafx.swt module in an OSGi environment (see 
>>>>>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=482428), and it would 
>>>>>>>> certainly be good if conformance tests could be started as early as 
>>>>>>>> possible.
>>>>>>>> 
>>>>>>>> Best Regards,
>>>>>>>> Alexander
>>> 
>>> 
>>> -- 
>>> 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
>> 
>

Re: javafx.embed.swt.* regarded as JDK internal API by jdeps of jdk9-ea135

2016-09-14 Thread Alexander Nyssen

Hi Tom, Kevin,

I have to admit that - now - I am somehow confused. At first glance "the 
expectation is that javafx.swt will be added as an automatic (and thus named) 
module in a layer“ and "it will not be an autom[at]ic-module but a named one 
loaded in a […] layer“ sounds like a contradiction. Tom, did you plan to 
„repackage“ the automatic (and thus implicitly defined) javafx.swt module as an 
explicit one as part of e(fx)clipse, or did you - like me - expect that 
javafx.swt will yet be turned into an explicit module by the OpenJFX team?

Best Regards,
Alexander

> Am 14.09.2016 um 00:51 schrieb Tom Schindl <tom.schi...@bestsolution.at>:
> 
> Hi,
> 
> javafx.swt can never be a module loaded by default but we need to
> construct a new layer who has the SWT-Bundle-Classloader as the parent.
> 
> So no it will not be an automic-module but a named one loaded in a
> secondary layer (eg by the efxclipse OSGi-Adapter-Hook) - at least this
> is the theory. I didn't have time yet to follow this path yet.
> 
> Tom
> 
> On 13.09.16 20:31, Alexander Nyssen wrote:
>> Hi Kevin,
>> 
>>> Am 13.09.2016 um 16:30 schrieb Kevin Rushforth <kevin.rushfo...@oracle.com>:
>>> 
>>> 
>>> 
>>> Alexander Nyssen wrote:
>>>> Hi Kevin,
>>>> 
>>>>> Am 13.09.2016 um 15:42 schrieb Kevin Rushforth 
>>>>> <kevin.rushfo...@oracle.com <mailto:kevin.rushfo...@oracle.com>>:
>>>>> 
>>>>> That seems surprising since javafx.swt is not part of the JDK runtime 
>>>>> image. I suspect that this is either an issue with jdeps itself or with 
>>>>> how you are running jdeps. What was the command line you were using?
>>>> 
>>>> I used: for i in */bin; do 
>>>> /Library/Java/JavaVirtualMachines/jdk-9_ea135.jdk/Contents/Home/bin/jdeps 
>>>> -jdkinternals $i; done >> deps.txt
>>> 
>>> That doesn't show how javafx-swt.jar is being referenced. javafx-swt.jar is 
>>> delivered with the JDK, but is not loaded by default (or at least it should 
>>> not be).
>> 
>> Is there a way to find out? Do I have to provide additional options? Using 
>> jdk-9-ea109 the same command line did not result in javafx.swt being 
>> regarded as JDK internal.
>> 
>>> 
>>> 
>>>>> As for your second question, the expectation is that javafx.swt will be 
>>>>> added as an automatic (and thus named) module in a layer, but that still 
>>>>> needs to be tested. We currently do all of our own testing by adding it 
>>>>> as an automatic module on the module path as follows:
>>>>> 
>>>>> $ java --module-path $JAVA_HOME/lib/javafx-swt.jar --add-modules 
>>>>> javafx.swt my.pkg.MyApp
>>>> 
>>>> I see. Is there a concrete schedule?
>>> 
>>> If you mean is there a concrete schedule for the Eclipse folks to do the 
>>> work to verify that javafx.swt can be loaded in a layer, I can't comment on 
>>> that, since this work is outside the scope of the JDK. Perhaps Tom Schindl 
>>> can respond?
>> 
>> I thought the plan was to turn javafx.swt into an explicit module and not an 
>> (implicit) automatic one, and I was referring to when this was finalized. 
>> Seems I got that wrong.
>> 
>>> 
>>> — Kevin
>> 
>> Best Regards,
>> Alexander
>> 
>>> 
>>>> 
>>>>> 
>>>>> — Kevin
>>>> 
>>>> Best Regards,
>>>> Alexander
>>>> 
>>>>> 
>>>>> 
>>>>> Alexander Nyssen wrote:
>>>>>> Hi all,
>>>>>> 
>>>>>> I used a recent jdeps (from jdk9-ea135) to check the Eclipse GEF code 
>>>>>> base and was astonished to see that all dependencies to 
>>>>>> javafx.embed.swt.* now seem to be regarded as JDK internal API. I assume 
>>>>>> this is just a temporal inconsistency. Therefore, let me ask when it is 
>>>>>> planned to transfer the javafx.swt module into a proper named JIGSAW 
>>>>>> module to resolve this. The Eclipse community relies on using the 
>>>>>> javafx.swt module in an OSGi environment (see 
>>>>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=482428), and it would 
>>>>>> certainly be good if conformance tests could be started as early as 
>>>>>> possible.
>>>>>> 
>>>>>> Best Regards,
>>>>>> Alexander
>>>>>> 
>>>>>> 
>>>> 
>> 
> 
> 
> -- 
> 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

Re: javafx.embed.swt.* regarded as JDK internal API by jdeps of jdk9-ea135

2016-09-13 Thread Alexander Nyssen

Hi Kevin,

> Am 13.09.2016 um 16:30 schrieb Kevin Rushforth <kevin.rushfo...@oracle.com>:
> 
> 
> 
> Alexander Nyssen wrote:
>> Hi Kevin,
>> 
>>> Am 13.09.2016 um 15:42 schrieb Kevin Rushforth <kevin.rushfo...@oracle.com 
>>> <mailto:kevin.rushfo...@oracle.com>>:
>>> 
>>> That seems surprising since javafx.swt is not part of the JDK runtime 
>>> image. I suspect that this is either an issue with jdeps itself or with how 
>>> you are running jdeps. What was the command line you were using?
>> 
>> I used: for i in */bin; do 
>> /Library/Java/JavaVirtualMachines/jdk-9_ea135.jdk/Contents/Home/bin/jdeps 
>> -jdkinternals $i; done >> deps.txt
> 
> That doesn't show how javafx-swt.jar is being referenced. javafx-swt.jar is 
> delivered with the JDK, but is not loaded by default (or at least it should 
> not be).

Is there a way to find out? Do I have to provide additional options? Using 
jdk-9-ea109 the same command line did not result in javafx.swt being regarded 
as JDK internal.

> 
> 
>>> As for your second question, the expectation is that javafx.swt will be 
>>> added as an automatic (and thus named) module in a layer, but that still 
>>> needs to be tested. We currently do all of our own testing by adding it as 
>>> an automatic module on the module path as follows:
>>> 
>>>  $ java --module-path $JAVA_HOME/lib/javafx-swt.jar --add-modules 
>>> javafx.swt my.pkg.MyApp
>> 
>> I see. Is there a concrete schedule?
> 
> If you mean is there a concrete schedule for the Eclipse folks to do the work 
> to verify that javafx.swt can be loaded in a layer, I can't comment on that, 
> since this work is outside the scope of the JDK. Perhaps Tom Schindl can 
> respond?

I thought the plan was to turn javafx.swt into an explicit module and not an 
(implicit) automatic one, and I was referring to when this was finalized. Seems 
I got that wrong.

> 
> — Kevin

Best Regards,
Alexander

> 
>> 
>>> 
>>> — Kevin
>> 
>> Best Regards,
>> Alexander
>> 
>>> 
>>> 
>>> Alexander Nyssen wrote:
>>>> Hi all,
>>>> 
>>>> I used a recent jdeps (from jdk9-ea135) to check the Eclipse GEF code base 
>>>> and was astonished to see that all dependencies to javafx.embed.swt.* now 
>>>> seem to be regarded as JDK internal API. I assume this is just a temporal 
>>>> inconsistency. Therefore, let me ask when it is planned to transfer the 
>>>> javafx.swt module into a proper named JIGSAW module to resolve this. The 
>>>> Eclipse community relies on using the javafx.swt module in an OSGi 
>>>> environment (see https://bugs.eclipse.org/bugs/show_bug.cgi?id=482428), 
>>>> and it would certainly be good if conformance tests could be started as 
>>>> early as possible.
>>>> 
>>>> Best Regards,
>>>> Alexander
>>>> 
>>>> 
>>

Re: javafx.embed.swt.* regarded as JDK internal API by jdeps of jdk9-ea135

2016-09-13 Thread Alexander Nyssen

Hi Kevin,

> Am 13.09.2016 um 15:42 schrieb Kevin Rushforth <kevin.rushfo...@oracle.com>:
> 
> That seems surprising since javafx.swt is not part of the JDK runtime image. 
> I suspect that this is either an issue with jdeps itself or with how you are 
> running jdeps. What was the command line you were using?

I used: for i in */bin; do 
/Library/Java/JavaVirtualMachines/jdk-9_ea135.jdk/Contents/Home/bin/jdeps 
-jdkinternals $i; done >> deps.txt

> 
> As for your second question, the expectation is that javafx.swt will be added 
> as an automatic (and thus named) module in a layer, but that still needs to 
> be tested. We currently do all of our own testing by adding it as an 
> automatic module on the module path as follows:
> 
>   $ java --module-path $JAVA_HOME/lib/javafx-swt.jar --add-modules javafx.swt 
> my.pkg.MyApp

I see. Is there a concrete schedule?

> 
> — Kevin

Best Regards,
Alexander

> 
> 
> Alexander Nyssen wrote:
>> Hi all,
>> 
>> I used a recent jdeps (from jdk9-ea135) to check the Eclipse GEF code base 
>> and was astonished to see that all dependencies to javafx.embed.swt.* now 
>> seem to be regarded as JDK internal API. I assume this is just a temporal 
>> inconsistency. Therefore, let me ask when it is planned to transfer the 
>> javafx.swt module into a proper named JIGSAW module to resolve this. The 
>> Eclipse community relies on using the javafx.swt module in an OSGi 
>> environment (see https://bugs.eclipse.org/bugs/show_bug.cgi?id=482428), and 
>> it would certainly be good if conformance tests could be started as early as 
>> possible.
>> 
>> Best Regards,
>> Alexander
>> 
>>

javafx.embed.swt.* regarded as JDK internal API by jdeps of jdk9-ea135

2016-09-13 Thread Alexander Nyssen

Hi all,

I used a recent jdeps (from jdk9-ea135) to check the Eclipse GEF code base and 
was astonished to see that all dependencies to javafx.embed.swt.* now seem to 
be regarded as JDK internal API. I assume this is just a temporal 
inconsistency. Therefore, let me ask when it is planned to transfer the 
javafx.swt module into a proper named JIGSAW module to resolve this. The 
Eclipse community relies on using the javafx.swt module in an OSGi environment 
(see https://bugs.eclipse.org/bugs/show_bug.cgi?id=482428), and it would 
certainly be good if conformance tests could be started as early as possible.

Best Regards,
Alexander

Re: [PATCH] 8143596: FXCanvas does not forward touch gestures to embedded scene

2016-08-18 Thread Alexander Nyssen

Hi Kevin,

I think we can go for option 1) and can approach the manual test as you 
outlined in your second comment. Attached please find an updated patch, which 
no longer contains the SWT upgrade but instead provides a respective comment 
within the manual test. I have also updated the manual test to provide detailed 
test steps and expectations, which were still missing in the initial patch.

I could get hold of a Windows PC with touch screen today and can confirm proper 
behavior there as well. Please note that while my patch contains handling of 
SWIPE events, I was not able to obtain any SWIPE events from SWT, neither on 
Windows 10 nor on MaxOS El Capitan, while PAN, ROTATE, and ZOOM events were 
properly delivered on both platforms (which is why I have excluded SWIPE from 
the manual test). I further noticed one difference of behavior on both 
platforms: while on MacOS SWT delivers inertia events for PAN, this is not the 
case on Windows (here, the gesture end event is always the last event that is 
delivered), but this is rather an SWT issue and cannot be handled by FXCanvas.

Even while we go with option 1), upgrading the SWT library would not be a bad 
idea, as the version currently used (3.7.2) is from 2012. Maybe you could open 
a separate issue for it, which does not „block“ this issue but simply „relates“ 
to it?

Best Regards,
Alexander

> Am 17.08.2016 um 23:42 schrieb Kevin Rushforth <kevin.rushfo...@oracle.com>:
> 
> I uploaded the patch. I also added a comment [1] to the bug report with a 
> concern about updating the dependent SWT library. You can read the details in 
> the bug report.
> 
> -- Kevin
> 
> [1] 
> https://bugs.openjdk.java.net/browse/JDK-8143596?focusedCommentId=13989256=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13989256
> 
> 
> Alexander Nyssen wrote:
>> Hi all, Kevin,
>> 
>> attached please find a patch for JDK-8143596 
>> <https://bugs.openjdk.java.net/browse/JDK-8143596> (FXCanvas does not 
>> forward touch gestures to embedded scene). The patch depends on the most 
>> recent patch I provided for JDK-8161282 (revision 15_08_16, which was 
>> already uploaded). I developed and tested it on MacOSX, as SWT does not 
>> support any gestures on Linux. I could not test it on Windows yet, but will 
>> try to do so tomorrow (I cannot use my virtual machine but need to get hold 
>> of a windows device with touch support). I have added a simple manual test 
>> but no automated test yet.
>> 
>> Best Regards,
>> Alexander
>> 
>> =
>> 
>>

Re: Marking synthesized scroll events as such.

2016-08-16 Thread Alexander Nyssen

Having started to work on JDK-8143596 
<https://bugs.openjdk.java.net/browse/JDK-8143596> today, I have to provide an 
update on this: those PAN gesture events that are emulated by SWT should indeed 
be ignored by FXCanvas (as done by our FXCanvasEX implementation), because:

a) SCROLL gestures (START, SCROLL, FINISH) may otherwise not be properly 
recognized by JavaFX code (because they are always ‚disturbed‘ by intermediate 
synthesized mouse scroll events).
b) JavaFX does not emulate such events, so forwarding would result in a 
different behavior in case of the SWT integration (compared to JavaFX native).

Regards,
Alexander

> Am 16.08.2016 um 08:55 schrieb Alexander Nyssen <alexan...@nyssen.org>:
> 
> Hi all,
> 
> as I am currently working on FXCanvas, there is one aspect I would like to 
> discuss, which is closely related to JDK-8161282 
> <https://bugs.openjdk.java.net/browse/JDK-8161282> (FXCanvas does not forward 
> horizontal mouse scroll events to the embedded scene) and JDK-8143596 
> <https://bugs.openjdk.java.net/browse/JDK-8143596> (FXCanvas does not forward 
> touch gestures to embedded scene), namely handling of synthesized scroll 
> events. That is, SWT synthesizes mouse wheel scroll events from PAN gesture 
> events, and these are forwarded to the embedded scene (the patch I provided 
> for JDK-8161282 does not change this behavior, it simply ensures horizontal 
> and vertical mouse wheel events are processed equally) while not being marked 
> as synthesized (unlike MouseEvent, ScrollEvent does not provide a 
> ‚synthesized‘ flag). JavaFX natively seems to do likewise with SWIPE events, 
> which seem to yield synthesized scroll events as well. 
> 
> Wouldn’t it be appropriate to introduce a synthesized flag and mark such kind 
> of events as being synthesized? Within the Eclipse GEF’s FXCanvasEx we have 
> sorted out scroll events synthesized form PAN events completely (and any 
> client code may do likewise without accessing internal API, so this is no 
> JIGSAW related issue), but I think it in general be nice if client code could 
> properly decide, whether it wants to deal with these events or rather handle 
> the native gesture events instead (as soon as JDK-8143596 is resolved this 
> would even be possible in an SWT-integrated scenario).
> 
> I would raise an issue via webbug for this, if my thoughts are shared.
> 
> Regards,
> Alexander
> 
>

Re: [PATCH] 8161282: FXCanvas does not forward horizontal mouse scroll events to the embedded scene

2016-08-16 Thread Alexander Nyssen

You might even take the one I attached. I just recognized I still had some 
unused imports in the manual test case (I am still not familiar with IntelliJ).

Regards,
Alexander



> Am 15.08.2016 um 19:26 schrieb Kevin Rushforth <kevin.rushfo...@oracle.com>:
> 
> OK, I'll upload this revised version of the patch today.
> 
> -- Kevin
> 
> 
> Alexander Nyssen wrote:
>> 
>> Hi Kevin,
>> 
>> please consider the following updated patch instead, which contains an 
>> additional null-check.
>> 
>> Regards
>> Alexander
>> 
>> 
>> 
>> 
>>> Am 12.08.2016 um 16:04 schrieb Alexander Nyssen <alexan...@nyssen.org 
>>> <mailto:alexan...@nyssen.org>>:
>>> 
>>> Hi Kevin,
>>> 
>>> attached please find an initial patch for 
>>> https://bugs.openjdk.java.net/browse/JDK-8161282 
>>> <https://bugs.openjdk.java.net/browse/JDK-8161282>.
>>> 
>>> The patch is not as minimal as I had hoped, as the EmbeddedSceneInterface 
>>> had to be changed to differentiate between mouse and scroll events (while 
>>> up to now, scroll events are handled as mouse events), but for me this 
>>> seemed necessary to fix this issue properly. As a result, JFXPanel had to 
>>> be adjusted as well to comply to the changes in the EmbeddedSceneInterface, 
>>> while its behavior should not have changed.
>>> 
>>> As horizontal mouse events cannot be synthesized via Display.post(Event) 
>>> yet (an open issue for SWT), I did not add an automated test, but instead 
>>> added a manual one (FXCanvasMouseWheelEventsTest). Therefore, this patch 
>>> does not depend on the patch I provided earlier for JDK-8160325.
>>> 
>>> Best Regards,
>>> Alexander
>>> 
>>> 
>>> 
>>> 
>> 
>> =

Marking synthesized scroll events as such.

2016-08-16 Thread Alexander Nyssen

Hi all,

as I am currently working on FXCanvas, there is one aspect I would like to 
discuss, which is closely related to JDK-8161282 
 (FXCanvas does not forward 
horizontal mouse scroll events to the embedded scene) and JDK-8143596 
 (FXCanvas does not forward 
touch gestures to embedded scene), namely handling of synthesized scroll 
events. That is, SWT synthesizes mouse wheel scroll events from PAN gesture 
events, and these are forwarded to the embedded scene (the patch I provided for 
JDK-8161282 does not change this behavior, it simply ensures horizontal and 
vertical mouse wheel events are processed equally) while not being marked as 
synthesized (unlike MouseEvent, ScrollEvent does not provide a ‚synthesized‘ 
flag). JavaFX natively seems to do likewise with SWIPE events, which seem to 
yield synthesized scroll events as well. 

Wouldn’t it be appropriate to introduce a synthesized flag and mark such kind 
of events as being synthesized? Within the Eclipse GEF’s FXCanvasEx we have 
sorted out scroll events synthesized form PAN events completely (and any client 
code may do likewise without accessing internal API, so this is no JIGSAW 
related issue), but I think it in general be nice if client code could properly 
decide, whether it wants to deal with these events or rather handle the native 
gesture events instead (as soon as JDK-8143596 is resolved this would even be 
possible in an SWT-integrated scenario).

I would raise an issue via webbug for this, if my thoughts are shared.

Regards,
Alexander

Re: [PATCH] 8161282: FXCanvas does not forward horizontal mouse scroll events to the embedded scene

2016-08-15 Thread Alexander Nyssen

Hi Kevin,

please consider the following updated patch instead, which contains an 
additional null-check.

Regards
Alexander


> Am 12.08.2016 um 16:04 schrieb Alexander Nyssen <alexan...@nyssen.org>:
> 
> Hi Kevin,
> 
> attached please find an initial patch for 
> https://bugs.openjdk.java.net/browse/JDK-8161282 
> <https://bugs.openjdk.java.net/browse/JDK-8161282>.
> 
> The patch is not as minimal as I had hoped, as the EmbeddedSceneInterface had 
> to be changed to differentiate between mouse and scroll events (while up to 
> now, scroll events are handled as mouse events), but for me this seemed 
> necessary to fix this issue properly. As a result, JFXPanel had to be 
> adjusted as well to comply to the changes in the EmbeddedSceneInterface, 
> while its behavior should not have changed.
> 
> As horizontal mouse events cannot be synthesized via Display.post(Event) yet 
> (an open issue for SWT), I did not add an automated test, but instead added a 
> manual one (FXCanvasMouseWheelEventsTest). Therefore, this patch does not 
> depend on the patch I provided earlier for JDK-8160325.
> 
> Best Regards,
> Alexander
> 
> 
> 
>

[PATCH] 8161282: FXCanvas does not forward horizontal mouse scroll events to the embedded scene

2016-08-12 Thread Alexander Nyssen

Hi Kevin,

attached please find an initial patch for 
https://bugs.openjdk.java.net/browse/JDK-8161282 
.

The patch is not as minimal as I had hoped, as the EmbeddedSceneInterface had 
to be changed to differentiate between mouse and scroll events (while up to 
now, scroll events are handled as mouse events), but for me this seemed 
necessary to fix this issue properly. As a result, JFXPanel had to be adjusted 
as well to comply to the changes in the EmbeddedSceneInterface, while its 
behavior should not have changed.

As horizontal mouse events cannot be synthesized via Display.post(Event) yet 
(an open issue for SWT), I did not add an automated test, but instead added a 
manual one (FXCanvasMouseWheelEventsTest). Therefore, this patch does not 
depend on the patch I provided earlier for JDK-8160325.

Best Regards,
Alexander

Re: [PATCH] 8160325: Provide a public API to obtain the FXCanvas for an embedded scene.

2016-08-11 Thread Alexander Nyssen

Hi Kevin,

attached please find a revised patch that contains the corrections you 
requested. The patch is now applicable to the new module structure (modues with 
'javafx.' prefix).

Regards,
Alexander


> Am 12.08.2016 um 00:00 schrieb Kevin Rushforth <kevin.rushfo...@oracle.com>:
> 
> 
> 
> Alexander Nyssen wrote:
>> 
>> Hi Kevin,
>> 
>> thanks for your feedback. Please fin my comments inline.
>> 
>>   
>>> Am 09.08.2016 um 03:10 schrieb Kevin Rushforth <kevin.rushfo...@oracle.com> 
>>> <mailto:kevin.rushfo...@oracle.com>:
>>> 
>>> I uploaded the patch, reviewed it, and provided comments in the bug report. 
>>> The short version is:
>>> 
>>> * The new API looks good
>>> 
>>> * There is a missing '@since 9' in the javadoc comments along with a few 
>>> typos / style issues
>>> 
>> I will take care of it. Is there a style guide?
>>   
> 
> Not a current one. The ones I pointed out in the JBS issue were either 
> grammatical or capitalization (other than the '@since' which is required for 
> all new API).
> 
>>> * Rather than using reflection and setAccessible in the implementation, 
>>> please add a public getHostContainer method to EmbeddedWindow (since it is 
>>> an internal method, there is no concern with doing that -- it isn't API).
>>> 
>> Such a getHost() method was already introduced to EmbeddedWindow as part of 
>> the patch (to obtain the HostContainer from it). The reflection code within 
>> getFXCanvas() is used to access the enclosing instance (i.e. the FXCanvas) 
>> of the HostContainer. We could only circumvent this by introducing a 
>> constructor to HostContainer and by passing in the enclosing FXCanvas 
>> instance explicitly (so we can query it via an explicit getter, which would 
>> have to be introduced in addition). Would you prefer that?
>>   
> 
> Ah, I see what you are doing now. There is an easier way, then. Just add a 
> default (package) scope 'fxCanvas' variable in the inner class initialized to 
> 'FXCanvas.this' and you will be able to access it directly, since an instance 
> of an inner class can always get access to the instance of the enclosing 
> class.
> 
> private class HostContainer implements HostInterface {
> final FXCanvas fxCanvas = FXCanvas.this;
> ...
> 
> I updated the bug report with this and the other style issues. I haven't 
> tested it yet, but other than the listed issues it looks very close to being 
> done.
> 
> -- Kevin
> 
> 
>>   
>>> Additionally, I requested JDK 9 release team approval for this. The 
>>> approval process can proceed in parallel with your addressing the issues I 
>>> raised.
>>> 
>>> — Kevin
>>> 
>> Regards,
>> Alexander
>> 
>>   
>>> Alexander Nyssen wrote:
>>> 
>>>> Hi Kevin,
>>>> 
>>>> attached please find a revised patch. My comments are inlined.
>>>> 
>>>>   
>>>>> Am 28.07.2016 um 18:03 schrieb Kevin Rushforth 
>>>>> <kevin.rushfo...@oracle.com <mailto:kevin.rushfo...@oracle.com> 
>>>>> <mailto:kevin.rushfo...@oracle.com> <mailto:kevin.rushfo...@oracle.com>>:
>>>>> 
>>>>> Hi
>>>>> 
>>>>> Alexander Nyssen wrote:
>>>>> 
>>>>>> Hi,
>>>>>> 
>>>>>> I have added my comments below:
>>>>>> 
>>>>>> 
>>>>>>   
>>>>>>> Am 28.07.2016 um 17:22 schrieb Kevin Rushforth 
>>>>>>> <kevin.rushfo...@oracle.com <mailto:kevin.rushfo...@oracle.com> 
>>>>>>> <mailto:kevin.rushfo...@oracle.com> 
>>>>>>> <mailto:kevin.rushfo...@oracle.com>>:
>>>>>>> 
>>>>>>> I got the attachment, since Alexander also CCed me directly. I will 
>>>>>>> attach it shortly.
>>>>>>> 
>>>>>> Thanks!
>>>>>>   
>>>>> Done.
>>>>> 
>>>>> 
>>>>>>> I do have two comments on this:
>>>>>>> 
>>>>>>> 1) We are past Feature Freeze, so all Enhancements need formal JDK 9 
>>>>>>> R-team approval [1][2]. In this case, the justification can be internal 
>>>>>>> API that is no longer accessible in JDK

Re: [PATCH] 8160325: Provide a public API to obtain the FXCanvas for an embedded scene.

2016-08-09 Thread Alexander Nyssen

Hi Kevin,

thanks for your feedback. Please fin my comments inline.

> Am 09.08.2016 um 03:10 schrieb Kevin Rushforth <kevin.rushfo...@oracle.com>:
> 
> I uploaded the patch, reviewed it, and provided comments in the bug report. 
> The short version is:
> 
> * The new API looks good
> 
> * There is a missing '@since 9' in the javadoc comments along with a few 
> typos / style issues

I will take care of it. Is there a style guide?

> 
> * Rather than using reflection and setAccessible in the implementation, 
> please add a public getHostContainer method to EmbeddedWindow (since it is an 
> internal method, there is no concern with doing that -- it isn't API).

Such a getHost() method was already introduced to EmbeddedWindow as part of the 
patch (to obtain the HostContainer from it). The reflection code within 
getFXCanvas() is used to access the enclosing instance (i.e. the FXCanvas) of 
the HostContainer. We could only circumvent this by introducing a constructor 
to HostContainer and by passing in the enclosing FXCanvas instance explicitly 
(so we can query it via an explicit getter, which would have to be introduced 
in addition). Would you prefer that?

> 
> Additionally, I requested JDK 9 release team approval for this. The approval 
> process can proceed in parallel with your addressing the issues I raised.
> 
> — Kevin

Regards,
Alexander

> 
> 
> Alexander Nyssen wrote:
>> Hi Kevin,
>> 
>> attached please find a revised patch. My comments are inlined.
>> 
>>> Am 28.07.2016 um 18:03 schrieb Kevin Rushforth <kevin.rushfo...@oracle.com 
>>> <mailto:kevin.rushfo...@oracle.com>>:
>>> 
>>> Hi
>>> 
>>> Alexander Nyssen wrote:
>>>> Hi,
>>>> 
>>>> I have added my comments below:
>>>> 
>>>> 
>>>>> Am 28.07.2016 um 17:22 schrieb Kevin Rushforth 
>>>>> <kevin.rushfo...@oracle.com <mailto:kevin.rushfo...@oracle.com>>:
>>>>> 
>>>>> I got the attachment, since Alexander also CCed me directly. I will 
>>>>> attach it shortly.
>>>> 
>>>> Thanks!
>>> 
>>> Done.
>>> 
>> 
>>>>> I do have two comments on this:
>>>>> 
>>>>> 1) We are past Feature Freeze, so all Enhancements need formal JDK 9 
>>>>> R-team approval [1][2]. In this case, the justification can be internal 
>>>>> API that is no longer accessible in JDK 9 due to Jigsaw (I would be very 
>>>>> reluctant to consider any other Enhancement request this late in the 
>>>>> process), but I will need to look at it and then take it through the 
>>>>> approval process, provided that I feel it is in scope.
>>>> 
>>>> I was not aware about this, but I would of course appreciate if it could 
>>>> be included (due to Jigsaw). Thanks for considering it at least.
>>> 
>>> I'll take a closer look tomorrow or Monday (no more time today). At first 
>>> glance it seems like something reasonable to take forward.
>> 
>> That sounds promising. Thanks!
>> 
>>> 
>>>>> 2) Some of the changes you list seem unrelated to this enhancement and 
>>>>> are better done as separate issues (e.g., the rework of the 
>>>>> SWTCursorsTest). Also, I am unconvinced of the need to force GTK 2; in 
>>>>> fact it seems at odds with the work we have done with JEP 283 [3].
>>>> 
>>>> Well, the test case refactoring is somehow related, as I introduced the 
>>>> common SWT rule while introducing the second SWT test. However, I could 
>>>> provide it as a separate contribution if that was wished (and a JIRA issue 
>>>> was provided), but the rest of this contribution of course requires it as 
>>>> a prerequisite. If this enhancement could not be included in JDK 9, I 
>>>> would have to provide it as a separate contribution, as I would have to 
>>>> re-introduce FXCanvasTest in other succeeding bugfix contributions 
>>>> (JDK-8143596, JDK-8143596).
>>> 
>>> I see. I did take a quick look at this and the test changes seem fine as 
>>> part of this. I see you created the new test with 'hg cp' (or similar) 
>>> which records it as a copy of the SWTCursorsTest.java file, which given the 
>>> number of changes is not needed (and not really useful), but that's easy to 
>>> fix.
>> 
>> Done (I copied it within IntelliJ and the IDE seems to have applied hg copy).
>> 
>>> 
>>> There are sever

Re: [PATCH] 8088147: FXCanvas: implement custom cursors (revised)

2016-07-27 Thread Alexander Nyssen

Hi Kevin,

sorry for that (I’m a Git guy and don’t feel very comfortable with Mercurial 
yet). I have attached a revised patch that (hopefully) provides the correct 
changes. 

Regards,
Alexander



> Am 27.07.2016 um 18:51 schrieb Kevin Rushforth <kevin.rushfo...@oracle.com>:
> 
> I attached the patch to the JBS issue. You have introduced a bug in the 
> SWTCursorsTest.java JUnit test -- it appears to be an almost-exact copy of 
> the manual test (including the now-incorrect class name). Also, you have 
> inadvertently included an unwanted modification to .idea/modules.xml that 
> should be reverted. Please send a new patch with the above two fixed.
> 
> The rest looks fine to me, but I will wait to verify until you provide an 
> update to fix the unit test.
> 
> As for the JIGSAW mode tests, I agree that can/should be a follow-on effort.
> 
> -- Kevin
> 
> 
> Alexander Nyssen wrote:
>> 
>> Hi Kevin, all, 
>> 
>> attached please find an updated patch and my replies to Kevin’s comments at 
>> https://bugs.openjdk.java.net/browse/JDK-8088147: 
>> <https://bugs.openjdk.java.net/browse/JDK-8088147:>
>> 
>>> build.gradle 
>>> 
>>> 1. In the following: 
>>> 
>>> + if (IS_JIGSAW_TEST) { 
>>> + enabled = false // FIXME: JIGSAW -- support this with modules 
>>> + logger.info <http://logger.info/>("JIGSAW Testing disabled for swt") 
>>> 
>>> I verified that it correctly skips this in JIGSAW mode. Can you look into 
>>> implementing this, though? It should not be difficult, and once we switch 
>>> to only supporting Jigsaw mode the tests will never be run until this is 
>>> done. If it does turn out to be too much work, then we could consider it as 
>>> a follow-on. 
>>> 
>> 
>> As already indicated in an earlier mail I would prefer to treat building up 
>> JIGSAW tests as a follow-on. I have not gained much experience with JIGSAW 
>> yet, but I would be willing to support this as far as I can. The problem I 
>> currently see is that SWT is still an automatic module, and JIGSAW-based SWT 
>> tests would have to access code from the swt-debug.jar, which is as well an 
>> automatic module. AFAIK, we would have to turn SWT into a named module first 
>> in order to make swt-debug.jar available on its module path. That seems to 
>> be out of scope here and should probably be investigated in an own issue.
>> 
>>> 2. Platform logic: 
>>> 
>>> + if(IS_MAC){ 
>>> + enabled = false 
>>> ... 
>>> + } 
>>> + if(IS_LINUX){ 
>>> 
>>> Normally we would handle this in the test itself by using assumeTrue and 
>>> platform checks. In this case, though, since it applies to all SWT tests 
>>> run on Mac (or Linux in case of the warning), this seems fine. 
>>> 
>>> Please fix the spacing to match our coding conventions, though. There 
>>> should be a space after the 'if' and a space before the '{'. So: 
>>> 
>>> if (IS_MAC) { 
>> 
>> Ok. fine. We could even try to get SWT tests working on Mac by falling back 
>> to ant-based test execution here, but I would propose to handle this in a 
>> different issue as well (after all, this issue is about SWT image cursors 
>> and not about building up an SWT test harness).
>> 
>>> modules/swt/src/main/java/javafx/embed/swt/SWTCursors.java 
>>> 
>>> 3. Spacing issues: 
>>> 
>>> + if(display == null){ 
>>> 
>>> Please add a space after '(' and before '}' 
>>> 
>>> 
>>> -} 
>>> +} 
>>> \ No newline at end of file 
>>> 
>>> Please restore the newline after the last line. 
>> 
>> Done.
>> 
>>> SWTCursorsTest.java 
>>> 
>>> 4. Need a blank line before the package declaration: 
>>> 
>>> + */ 
>>> +package test.javafx.embed.swt; 
>>> +
>> 
>> Done.
>> 
>>> 5. Can you sort the imports alphabetically? 
>> 
>> I organized the imports and removed unused ones. It seems they are pretty 
>> much consistent with those of the other SWT classes.
>> 
>> 
>>> 6. Since the test loops waiting on a latch, please add a 10 second timeout 
>>> for the test: 
>>> 
>>> @Test(timeout=1) 
>>> public void testImageCursor() throws Throwable { 
>> 
>> Done.
>> 
>>> SWTImageCursorTest.java 
>>> 
>>> 7. The following can use a lambda (as the setOnMouseEntered already did). 
>>>

Re: [PATCH] 8088147: FXCanvas: implement custom cursors (revised)

2016-07-27 Thread Alexander Nyssen

Hi Kevin, all, 

attached please find an updated patch and my replies to Kevin’s comments at 
https://bugs.openjdk.java.net/browse/JDK-8088147:

> build.gradle 
> 
> 1. In the following: 
> 
> + if (IS_JIGSAW_TEST) { 
> + enabled = false // FIXME: JIGSAW -- support this with modules 
> + logger.info("JIGSAW Testing disabled for swt") 
> 
> I verified that it correctly skips this in JIGSAW mode. Can you look into 
> implementing this, though? It should not be difficult, and once we switch to 
> only supporting Jigsaw mode the tests will never be run until this is done. 
> If it does turn out to be too much work, then we could consider it as a 
> follow-on. 
> 

As already indicated in an earlier mail I would prefer to treat building up 
JIGSAW tests as a follow-on. I have not gained much experience with JIGSAW yet, 
but I would be willing to support this as far as I can. The problem I currently 
see is that SWT is still an automatic module, and JIGSAW-based SWT tests would 
have to access code from the swt-debug.jar, which is as well an automatic 
module. AFAIK, we would have to turn SWT into a named module first in order to 
make swt-debug.jar available on its module path. That seems to be out of scope 
here and should probably be investigated in an own issue.

> 2. Platform logic: 
> 
> + if(IS_MAC){ 
> + enabled = false 
> ... 
> + } 
> + if(IS_LINUX){ 
> 
> Normally we would handle this in the test itself by using assumeTrue and 
> platform checks. In this case, though, since it applies to all SWT tests run 
> on Mac (or Linux in case of the warning), this seems fine. 
> 
> Please fix the spacing to match our coding conventions, though. There should 
> be a space after the 'if' and a space before the '{'. So: 
> 
> if (IS_MAC) { 

Ok. fine. We could even try to get SWT tests working on Mac by falling back to 
ant-based test execution here, but I would propose to handle this in a 
different issue as well (after all, this issue is about SWT image cursors and 
not about building up an SWT test harness).

> modules/swt/src/main/java/javafx/embed/swt/SWTCursors.java 
> 
> 3. Spacing issues: 
> 
> + if(display == null){ 
> 
> Please add a space after '(' and before '}' 
> 
> 
> -} 
> +} 
> \ No newline at end of file 
> 
> Please restore the newline after the last line. 

Done.

> SWTCursorsTest.java 
> 
> 4. Need a blank line before the package declaration: 
> 
> + */ 
> +package test.javafx.embed.swt; 
> +

Done.

> 5. Can you sort the imports alphabetically? 

I organized the imports and removed unused ones. It seems they are pretty much 
consistent with those of the other SWT classes.


> 6. Since the test loops waiting on a latch, please add a 10 second timeout 
> for the test: 
> 
> @Test(timeout=1) 
> public void testImageCursor() throws Throwable { 

Done.

> SWTImageCursorTest.java 
> 
> 7. The following can use a lambda (as the setOnMouseEntered already did). 
> 
> + rect.setOnMouseExited(new EventHandler() { 
> + @Override 
> + public void handle(MouseEvent event) { 
> + scene.setCursor(null); 
> + } 
> + });

Done.

Kevin, thanks for picking this up.

Regards,
Alexander


> Am 27.07.2016 um 01:15 schrieb Kevin Rushforth <kevin.rushfo...@oracle.com>:
> 
> Picking this back up again, I have just added my comments to JBS issue.
> 
> https://bugs.openjdk.java.net/browse/JDK-8088147
> 
> The comments are minor in scope, so I suspect it will be ready for final 
> review after one more iteration. It will need one other reviewer, since I am 
> sponsoring the change.
> 
> Could someone else review this as well (maybe Alexander Z or Sergey)?
> 
> -- Kevin
> 
> 
> Kevin Rushforth wrote:
>> I'm back, and given that the review will take some time anyway, I will 
>> sponsor this once the review is complete. I see that Guru uploaded the patch 
>> for you (thanks, Guru) so I can test it next week.
>> 
>> -- Kevin
>> 
>> 
>> Alexander Nyssen wrote:
>>> It seems I was unsuccessful again. If somebody would be willing to sponsor 
>>> this contribution while Kevin is away (or at least update the patch 
>>> provided for JDK-8088147), I could mail the patch privately.
>>> 
>>> Regards,
>>> Alexander
>>> 
>>> 
>>>> Am 11.07.2016 um 19:59 schrieb Alexander Nyssen <alexan...@nyssen.org>:
>>>> 
>>>> It seems my attachment has again been ‚consumed‘ by the list. Trying again 
>>>> with an archive containing the patch file.
>>>> 
>>>> Regards,
>>>> Alexander
>>>> 
>>>> 
>>>>   
>>>>> Am 0

Re: [PATCH] 8088147: FXCanvas: implement custom cursors (revised)

2016-07-12 Thread Alexander Nyssen

It seems I was unsuccessful again. If somebody would be willing to sponsor this 
contribution while Kevin is away (or at least update the patch provided for 
JDK-8088147), I could mail the patch privately.

Regards,
Alexander

> Am 11.07.2016 um 19:59 schrieb Alexander Nyssen <alexan...@nyssen.org>:
> 
> It seems my attachment has again been ‚consumed‘ by the list. Trying again 
> with an archive containing the patch file.
> 
> Regards,
> Alexander
> 
> 
>> Am 08.07.2016 um 23:28 schrieb Alexander Nyssen <alexan...@nyssen.org>:
>> 
>> Hi Kevin, all, 
>> 
>> attached please find a revised patch, where I have added the required export 
>> to PlatformImpl and have fixed the build script, so it does no longer break 
>> when being executed in jigsaw mode. 
>> 
>> As swt is no named module yet, I have disabled the JUnit test in jigsaw mode 
>> for now. We would probably have to set up swt as a named module to enable 
>> this, and would further have to make swt-debug.jar available as an automated 
>> module on its module path. But this is a different problem.
>> 
>> Regards,
>> Alexander
>> 
>> 
>>> Am 30.06.2016 um 12:14 schrieb Alexander Nyssen <alexan...@nyssen.org>:
>>> 
>>> Hi Kevin,
>>> 
>>>> Am 30.06.2016 um 01:20 schrieb Kevin Rushforth 
>>>> <kevin.rushfo...@oracle.com>:
>>>> 
>>>> Hi Alexander,
>>>> 
>>>> I attached the patch to the bug:
>>>> 
>>>> https://bugs.openjdk.java.net/browse/JDK-8088147
>>>> 
>>>> If I build it and run the manual test in "legacy" mode, meaning run 
>>>> everything with 9+109 and the legacy jfxrt.jar file, then it runs and the 
>>>> cursor now changes. So this looks like a good starting point for a fix.
>>> 
>>> Fine.
>>> 
>>>> 
>>>> I tried building and running this in Jigsaw mode (building with jdk-9+109, 
>>>> but running the tests with a more recent JDK that includes modularization 
>>>> support), and noticed two problems right away that must be addressed:
>>>> 
>>>> 1. The unit tests for SWT are missing some of the jigsaw test tasks so the 
>>>> build fails right away with an exception from gradle:
>>>> 
>>>>> Task with name 'jigsawTestsLinux' not found in project ':swt'.
>>>> 
>>>> Wiring up SWT-based tests to our unit test harness will take a bit more 
>>>> work than what you have provided (not even counting the Mac issue, which 
>>>> could be handled by excluding the test on Mac). In the short term, relying 
>>>> on manual tests for this fix might be best.
>>>> 
>>> 
>>> I did not execute the tests in jigsaw mode yet, because other tests failed 
>>> in this mode, too (as indicated in an earlier discussion). I will try to 
>>> set things up in a virtual machine with Windows and/or Linux so I can work 
>>> on the Gradle tests without having to deal with the Mac issue. The test 
>>> harness will IMHO also be required for other contributions, and it would of 
>>> course be fine if the automated test, I included in this patch, could be 
>>> executed as well.
>>> 
>>>> 
>>>> 2. You have introduced a dependency on a new internal package, 
>>>> com.sun.javafx.tk. If this is required in order to implement the fix, then 
>>>> you will need to add this package to the list of packages exports to 
>>>> javafx.swt in PlatformImpl; otherwise the following exception is thrown at 
>>>> runtime:
>>>> 
>>>> Exception in thread "JavaFX Application Thread" 
>>>> java.lang.IllegalAccessError: class javafx.embed.swt.SWTCursors (in module 
>>>> javafx.swt) cannot access class com.sun.javafx.tk.Toolkit (in module 
>>>> javafx.graphics) because module javafx.graphics does not export 
>>>> com.sun.javafx.tk to module javafx.swt
>>> 
>>> This dependency is required unless there is public API to convert a 
>>> platform image (which is provided by the image cursor frame) to an image. 
>>> To me, 
>>> Image image = 
>>> Toolkit.getImageAccessor().fromPlatformImage(cursorFrame.getPlatformImage());
>>> seemed to be the way to go. I will thus add the respective export in a 
>>> revised patch.
>>> 
>>>> 
>>>> 
>>>> I won't have time to sponsor this change until the second half of July, 
>>>&g

Re: [PATCH] 8088147: FXCanvas: implement custom cursors (revised)

2016-07-11 Thread Alexander Nyssen

It seems my attachment has again been ‚consumed‘ by the list. Trying again with 
an archive containing the patch file.

Regards,
Alexander


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

Re: [PATCH] 8088147: FXCanvas: implement custom cursors

2016-06-30 Thread Alexander Nyssen

Hi Kevin,

> Am 30.06.2016 um 01:20 schrieb Kevin Rushforth <kevin.rushfo...@oracle.com>:
> 
> Hi Alexander,
> 
> I attached the patch to the bug:
> 
> https://bugs.openjdk.java.net/browse/JDK-8088147
> 
> If I build it and run the manual test in "legacy" mode, meaning run 
> everything with 9+109 and the legacy jfxrt.jar file, then it runs and the 
> cursor now changes. So this looks like a good starting point for a fix.

Fine.

> 
> I tried building and running this in Jigsaw mode (building with jdk-9+109, 
> but running the tests with a more recent JDK that includes modularization 
> support), and noticed two problems right away that must be addressed:
> 
> 1. The unit tests for SWT are missing some of the jigsaw test tasks so the 
> build fails right away with an exception from gradle:
> 
>   > Task with name 'jigsawTestsLinux' not found in project ':swt'.
> 
> Wiring up SWT-based tests to our unit test harness will take a bit more work 
> than what you have provided (not even counting the Mac issue, which could be 
> handled by excluding the test on Mac). In the short term, relying on manual 
> tests for this fix might be best.
> 

I did not execute the tests in jigsaw mode yet, because other tests failed in 
this mode, too (as indicated in an earlier discussion). I will try to set 
things up in a virtual machine with Windows and/or Linux so I can work on the 
Gradle tests without having to deal with the Mac issue. The test harness will 
IMHO also be required for other contributions, and it would of course be fine 
if the automated test, I included in this patch, could be executed as well.

> 
> 2. You have introduced a dependency on a new internal package, 
> com.sun.javafx.tk. If this is required in order to implement the fix, then 
> you will need to add this package to the list of packages exports to 
> javafx.swt in PlatformImpl; otherwise the following exception is thrown at 
> runtime:
> 
> Exception in thread "JavaFX Application Thread" java.lang.IllegalAccessError: 
> class javafx.embed.swt.SWTCursors (in module javafx.swt) cannot access class 
> com.sun.javafx.tk.Toolkit (in module javafx.graphics) because module 
> javafx.graphics does not export com.sun.javafx.tk to module javafx.swt

This dependency is required unless there is public API to convert a platform 
image (which is provided by the image cursor frame) to an image. To me, 
  Image image = 
Toolkit.getImageAccessor().fromPlatformImage(cursorFrame.getPlatformImage());
seemed to be the way to go. I will thus add the respective export in a revised 
patch.

> 
> 
> I won't have time to sponsor this change until the second half of July, but 
> if others have time, the review can proceed and I'll pick it back up then if 
> it is in good enough shape to run.

Especially setting up the SWT test harness will be kind of a blocker for 
succeeding contributions, so it would be nice if somebody could step in.

Regards,
Alexander

> 
> -- Kevin
> 
> 
> Kevin Rushforth wrote:
>> Hi Alexander,
>> 
>> It looks like your patch was stripped out by the mailing list server.
>> 
>> Can you please send me the patch offline, as a zip file (so line endings are 
>> preserved across different systems), and I will unzip it and attach it to 
>> the bug report.
>> 
>> -- Kevin
>> 
>> 
>> Alexander Nyssen wrote:
>>> Hi,
>>> 
>>> I have worked on a first contribution related to JDK-8088147. Attached 
>>> please find a patch (created in extended Git format) that comprises the 
>>> related changes. I have augmented the implementation of 
>>> javafx.embed.swt.SWTCursors to handle the image cursor case. I further 
>>> adjusted javafx.scene.Scene to update the cursor frame (in addition to the 
>>> cursor) within synchronizeSceneProperties, so the cursor is not cleared in 
>>> the first pulse succeeding the cursor property change.
>>> I have added an automated JUnit test (SWTCursorsTest) to the swt module, as 
>>> well as a manual test (SWTImageCursorTest) to the systemTests module, with 
>>> which the proper behavior can be verified. As no tests for SWT existed so 
>>> far, I updated the build.gradle and gradle.properties files to support an 
>>> SWT_TEST option, which allows to handle them similar to Swing tests. I also 
>>> added the respective SWT dependency to the systemTests module. Please note 
>>> that the JUnit test can currently not be executed using Gradle on the Mac 
>>> (where the manual test currently is the single option; the automated tests 
>>> are disabled), because there SWT-based tests require the 
>>> -XstartOnFirstThread option that is currently not supported by the Gradle 
>>> test runner (see https://issues.gradle.org/browse/GRADLE-3290 for details). 
>>> We would have to use an ant task as a workaround.
>>> 
>>> Regards,
>>> Alexander
>>> 
>>> 
>>>

[PATCH] 8088147: FXCanvas: implement custom cursors

2016-06-23 Thread Alexander Nyssen

Hi,

I have worked on a first contribution related to JDK-8088147. Attached please 
find a patch (created in extended Git format) that comprises the related 
changes. I have augmented the implementation of javafx.embed.swt.SWTCursors to 
handle the image cursor case. I further adjusted javafx.scene.Scene to update 
the cursor frame (in addition to the cursor) within synchronizeSceneProperties, 
so the cursor is not cleared in the first pulse succeeding the cursor property 
change. 

I have added an automated JUnit test (SWTCursorsTest) to the swt module, as 
well as a manual test (SWTImageCursorTest) to the systemTests module, with 
which the proper behavior can be verified. As no tests for SWT existed so far, 
I updated the build.gradle and gradle.properties files to support an SWT_TEST 
option, which allows to handle them similar to Swing tests. I also added the 
respective SWT dependency to the systemTests module. Please note that the JUnit 
test can currently not be executed using Gradle on the Mac (where the manual 
test currently is the single option; the automated tests are disabled), because 
there SWT-based tests require the -XstartOnFirstThread option that is currently 
not supported by the Gradle test runner (see 
https://issues.gradle.org/browse/GRADLE-3290 for details). We would have to use 
an ant task as a workaround.

Regards,
Alexander

Re: LocalDateTimeStringConverterTest seem to fail if default locale is different to en_US

2016-06-18 Thread Alexander Nyssen

Hi Kevin,

> Am 17.06.2016 um 17:44 schrieb Kevin Rushforth <kevin.rushfo...@oracle.com>:
> 
> It seems like the test is not written to handle multiple Locales, so if you 
> could file a bug, we'll fix it (I note that it could probably be in a 
> "BeforeClass" block as one-time setup rather than setting it before each 
> test).

of course, a ‚BeforeClass' is more appropriate here. I just wanted to point out 
that its an invalid assumption regarding the default locale that causes the 
tests to fail. Will I be able to do that via JIRA directly after the OCA has 
been processed, or will ‚WebBug‘ still be the way to go?

> 
> As for your other test failures, I presume you are using FX 9-dev? Are you 
> running in "legacy" mode (building and testing with jdk-9+109 with no 
> JIGSAW_HOME being set)? If so, I haven't seen that error before. We 
> continuously run tests in this mode with no failures. Did you remove (and not 
> just rename) jfxrt.jar from your jdk-9 boot JDK?

Yes, I am targeting FX-9-dev. Following the instructions at 
https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX#BuildingOpenJFX-EnvironmentVariables
 
<https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX#BuildingOpenJFX-EnvironmentVariables>,
 I setup JAVA_HOME and JDK_HOME to point to jdk-9_ea109 (without jfxrt.jar) as 
well as JIGSAW_HOME to point to jdk-9_ea122. The instructions do not seem to 
mention something as „legacy“ mode. Maybe you should update them (at least the 
’Testing’ section) to make that clear, especially if all control tests fail in 
‚non-legacy‘ mode. 

If I remove the JIGSAW_HOME and apply the above mentioned fix to 
LocalDateTimeStringConverterTest, all tests pass successfully, except the 
following three web tests:

test.javafx.scene.web.JavaScriptBridgeTest > testMethodCallWithWrapperObjects 
FAILED
java.lang.NullPointerException
at 
test.javafx.scene.web.JavaScriptBridgeTest.lambda$testMethodCallWithWrapperObjects$8(JavaScriptBridgeTest.java:385)

test.javafx.scene.web.JavaScriptBridgeTest > 
testJSStringToJavaCharSpecilization FAILED
java.lang.AssertionError: expected:<111> but was:<0>
at org.junit.Assert.fail(Assert.java:91)
at org.junit.Assert.failNotEquals(Assert.java:645)
at org.junit.Assert.assertEquals(Assert.java:126)
at org.junit.Assert.assertEquals(Assert.java:470)
at org.junit.Assert.assertEquals(Assert.java:454)
at 
test.javafx.scene.web.JavaScriptBridgeTest.lambda$testJSStringToJavaCharSpecilization$9(JavaScriptBridgeTest.java:404)

test.javafx.scene.web.LoadTest > loadJarFile FAILED
java.lang.AssertionError: netscape.javascript.JSException: ReferenceError: 
Can't find variable: jsr0
at test.javafx.scene.web.TestBase.submit(TestBase.java:205)
at test.javafx.scene.web.TestBase.executeScript(TestBase.java:216)
at test.javafx.scene.web.LoadTest.loadJarFile(LoadTest.java:285)

Caused by:
netscape.javascript.JSException: ReferenceError: Can't find variable: 
jsr0

Any idea about these? I am running Mac OS X El Capitan on my machine. Maybe 
that’s important.

Regards,
Alexander


> 
> -- Kevin
> 
> 
> Alexander Nyssen wrote:
>> 
>> Hi,
>> 
>> I could resolve this by changing the setup method of 
>> LocalDateTimeStringConverterTest to the following:
>> 
>> @Before public void setup() {
>> // tests require that default locale is English
>> Locale.setDefault(Locale.ENGLISH);
>> }
>> Maybe that should be added to make it robust.
>> 
>> Unfortunately, I am now stuck, because the succeeding controls tests fail, 
>> as it seems all with the following NoClassDefFoundError:
>> 
>> test.javafx.scene.control.TreeViewTest > test_rt_31200_tableRow FAILED
>> java.lang.NoClassDefFoundError: javafx.scene.control.Control
>> at 
>> test.javafx.scene.control.TreeViewTest.setup(TreeViewTest.java:121)
>> 
>> 7133 tests completed, 6326 failed, 239 skipped
>> :controls:test FAILED
>> 
>> FAILURE: Build failed with an exception.
>> 
>> The build succeeded (using gradle). Any idea what might be wrong? 
>> 
>> Regards,
>> Alexander
>> 
>>   
>>> Am 17.06.2016 um 07:56 schrieb Alexander Nyssen <alexan...@nyssen.org> 
>>> <mailto:alexan...@nyssen.org>:
>>> 
>>> Hi,
>>> 
>>> in order to be able to contribute to OpenJFX, I am currently trying to set 
>>> up my development environment. After checking out the latest head from hg 
>>> clone http://hg.openjdk.java.net/openjfx/9-dev/rt 
>>> <http://hg.openjdk.java.net/openjfx/9-dev/rt> 
>>> <http://hg.openjdk.java.net/openjfx/9-dev/rt>

Re: LocalDateTimeStringConverterTest seem to fail if default locale is different to en_US

2016-06-17 Thread Alexander Nyssen

Hi,

I could resolve this by changing the setup method of 
LocalDateTimeStringConverterTest to the following:

@Before public void setup() {
// tests require that default locale is English
Locale.setDefault(Locale.ENGLISH);
}
Maybe that should be added to make it robust.

Unfortunately, I am now stuck, because the succeeding controls tests fail, as 
it seems all with the following NoClassDefFoundError:

test.javafx.scene.control.TreeViewTest > test_rt_31200_tableRow FAILED
java.lang.NoClassDefFoundError: javafx.scene.control.Control
at test.javafx.scene.control.TreeViewTest.setup(TreeViewTest.java:121)

7133 tests completed, 6326 failed, 239 skipped
:controls:test FAILED

FAILURE: Build failed with an exception.

The build succeeded (using gradle). Any idea what might be wrong? 

Regards,
Alexander

> Am 17.06.2016 um 07:56 schrieb Alexander Nyssen <alexan...@nyssen.org>:
> 
> Hi,
> 
> in order to be able to contribute to OpenJFX, I am currently trying to set up 
> my development environment. After checking out the latest head from hg clone 
> http://hg.openjdk.java.net/openjfx/9-dev/rt 
> <http://hg.openjdk.java.net/openjfx/9-dev/rt>, compilation succeeds, but 
> tests fail with the following:
> 
> test.javafx.util.converter.LocalDateTimeStringConverterTest > 
> converter_with_specified_formatter_and_parser[0] FAILED
> org.junit.ComparisonFailure: expected:<12 Januar[y] 1985, 12:34:56> but 
> was:<12 Januar[] 1985, 12:34:56>
> at org.junit.Assert.assertEquals(Assert.java:123)
> at org.junit.Assert.assertEquals(Assert.java:145)
> at 
> test.javafx.util.converter.LocalDateTimeStringConverterTest.converter_with_specified_formatter_and_parser(LocalDateTimeStringConverterTest.java:144)
> 
> test.javafx.util.converter.LocalDateTimeStringConverterTest > 
> converter_with_specified_formatter_and_null_parser[0] FAILED
> org.junit.ComparisonFailure: expected:<12 Januar[y] 1985, 12:34:56> but 
> was:<12 Januar[] 1985, 12:34:56>
> at org.junit.Assert.assertEquals(Assert.java:123)
> at org.junit.Assert.assertEquals(Assert.java:145)
> at 
> test.javafx.util.converter.LocalDateTimeStringConverterTest.converter_with_specified_formatter_and_null_parser(LocalDateTimeStringConverterTest.java:152)
> 
> test.javafx.util.converter.LocalDateTimeStringConverterTest > 
> converter_with_specified_formatter_and_parser[1] FAILED
> org.junit.ComparisonFailure: expected:<12 Januar[y] 1985, 12:34:56> but 
> was:<12 Januar[] 1985, 12:34:56>
> at org.junit.Assert.assertEquals(Assert.java:123)
> at org.junit.Assert.assertEquals(Assert.java:145)
> at 
> test.javafx.util.converter.LocalDateTimeStringConverterTest.converter_with_specified_formatter_and_parser(LocalDateTimeStringConverterTest.java:144)
> 
> test.javafx.util.converter.LocalDateTimeStringConverterTest > 
> converter_with_specified_formatter_and_null_parser[1] FAILED
> org.junit.ComparisonFailure: expected:<12 Januar[y] 1985, 12:34:56> but 
> was:<12 Januar[] 1985, 12:34:56>
> at org.junit.Assert.assertEquals(Assert.java:123)
> at org.junit.Assert.assertEquals(Assert.java:145)
> at 
> test.javafx.util.converter.LocalDateTimeStringConverterTest.converter_with_specified_formatter_and_null_parser(LocalDateTimeStringConverterTest.java:152)
> 
> test.javafx.util.converter.LocalDateTimeStringConverterTest > 
> converter_with_specified_formatter_and_parser[2] FAILED
> org.junit.ComparisonFailure: expected:<12 Januar[y] 1985, 12:34:56> but 
> was:<12 Januar[] 1985, 12:34:56>
> at org.junit.Assert.assertEquals(Assert.java:123)
> at org.junit.Assert.assertEquals(Assert.java:145)
> at 
> test.javafx.util.converter.LocalDateTimeStringConverterTest.converter_with_specified_formatter_and_parser(LocalDateTimeStringConverterTest.java:144)
> 
> test.javafx.util.converter.LocalDateTimeStringConverterTest > 
> converter_with_specified_formatter_and_null_parser[2] FAILED
> org.junit.ComparisonFailure: expected:<12 Januar[y] 1985, 12:34:56> but 
> was:<12 Januar[] 1985, 12:34:56>
> at org.junit.Assert.assertEquals(Assert.java:123)
> at org.junit.Assert.assertEquals(Assert.java:145)
> at 
> test.javafx.util.converter.LocalDateTimeStringConverterTest.converter_with_specified_formatter_and_null_parser(LocalDateTimeStringConverterTest.java:152)
> 
> It seems they are not robust against having a default locale different to 
> en_US (Januar is the correct German translation for January; my default 
> locale seems to be de_DE).
> 
> Regards,
> Alexander
>

LocalDateTimeStringConverterTest seem to fail if default locale is different to en_US

2016-06-16 Thread Alexander Nyssen

Hi,

in order to be able to contribute to OpenJFX, I am currently trying to set up 
my development environment. After checking out the latest head from hg clone 
http://hg.openjdk.java.net/openjfx/9-dev/rt 
, compilation succeeds, but tests 
fail with the following:

test.javafx.util.converter.LocalDateTimeStringConverterTest > 
converter_with_specified_formatter_and_parser[0] FAILED
org.junit.ComparisonFailure: expected:<12 Januar[y] 1985, 12:34:56> but 
was:<12 Januar[] 1985, 12:34:56>
at org.junit.Assert.assertEquals(Assert.java:123)
at org.junit.Assert.assertEquals(Assert.java:145)
at 
test.javafx.util.converter.LocalDateTimeStringConverterTest.converter_with_specified_formatter_and_parser(LocalDateTimeStringConverterTest.java:144)

test.javafx.util.converter.LocalDateTimeStringConverterTest > 
converter_with_specified_formatter_and_null_parser[0] FAILED
org.junit.ComparisonFailure: expected:<12 Januar[y] 1985, 12:34:56> but 
was:<12 Januar[] 1985, 12:34:56>
at org.junit.Assert.assertEquals(Assert.java:123)
at org.junit.Assert.assertEquals(Assert.java:145)
at 
test.javafx.util.converter.LocalDateTimeStringConverterTest.converter_with_specified_formatter_and_null_parser(LocalDateTimeStringConverterTest.java:152)

test.javafx.util.converter.LocalDateTimeStringConverterTest > 
converter_with_specified_formatter_and_parser[1] FAILED
org.junit.ComparisonFailure: expected:<12 Januar[y] 1985, 12:34:56> but 
was:<12 Januar[] 1985, 12:34:56>
at org.junit.Assert.assertEquals(Assert.java:123)
at org.junit.Assert.assertEquals(Assert.java:145)
at 
test.javafx.util.converter.LocalDateTimeStringConverterTest.converter_with_specified_formatter_and_parser(LocalDateTimeStringConverterTest.java:144)

test.javafx.util.converter.LocalDateTimeStringConverterTest > 
converter_with_specified_formatter_and_null_parser[1] FAILED
org.junit.ComparisonFailure: expected:<12 Januar[y] 1985, 12:34:56> but 
was:<12 Januar[] 1985, 12:34:56>
at org.junit.Assert.assertEquals(Assert.java:123)
at org.junit.Assert.assertEquals(Assert.java:145)
at 
test.javafx.util.converter.LocalDateTimeStringConverterTest.converter_with_specified_formatter_and_null_parser(LocalDateTimeStringConverterTest.java:152)

test.javafx.util.converter.LocalDateTimeStringConverterTest > 
converter_with_specified_formatter_and_parser[2] FAILED
org.junit.ComparisonFailure: expected:<12 Januar[y] 1985, 12:34:56> but 
was:<12 Januar[] 1985, 12:34:56>
at org.junit.Assert.assertEquals(Assert.java:123)
at org.junit.Assert.assertEquals(Assert.java:145)
at 
test.javafx.util.converter.LocalDateTimeStringConverterTest.converter_with_specified_formatter_and_parser(LocalDateTimeStringConverterTest.java:144)

test.javafx.util.converter.LocalDateTimeStringConverterTest > 
converter_with_specified_formatter_and_null_parser[2] FAILED
org.junit.ComparisonFailure: expected:<12 Januar[y] 1985, 12:34:56> but 
was:<12 Januar[] 1985, 12:34:56>
at org.junit.Assert.assertEquals(Assert.java:123)
at org.junit.Assert.assertEquals(Assert.java:145)
at 
test.javafx.util.converter.LocalDateTimeStringConverterTest.converter_with_specified_formatter_and_null_parser(LocalDateTimeStringConverterTest.java:152)

It seems they are not robust against having a default locale different to en_US 
(Januar is the correct German translation for January; my default locale seems 
to be de_DE).

Regards,
Alexander

Review request for JDK-8173852: FXCanvas needs to invert rotation angle when forwarding a gesture event.

Re: Review request for 8166242: Removal of com.sun.javafx.embed.AbstractEvents

Re: :graphics:compilePrismCompilers fails with latest 9-dev tip on my mac

Re: :graphics:compilePrismCompilers fails with latest 9-dev tip on my mac

Re: :graphics:compilePrismCompilers fails with latest 9-dev tip on my mac

:graphics:compilePrismCompilers fails with latest 9-dev tip on my mac

Re: Necessity of com.sun.javafx.embed.AbstractEvents

Necessity of com.sun.javafx.embed.AbstractEvents

Review request [2] for 8143596: FXCanvas does not forward touch gestures to embedded scene

Re: javafx.embed.swt.* regarded as JDK internal API by jdeps of jdk9-ea135

Re: javafx.embed.swt.* regarded as JDK internal API by jdeps of jdk9-ea135

Re: javafx.embed.swt.* regarded as JDK internal API by jdeps of jdk9-ea135

Re: javafx.embed.swt.* regarded as JDK internal API by jdeps of jdk9-ea135

Re: javafx.embed.swt.* regarded as JDK internal API by jdeps of jdk9-ea135

javafx.embed.swt.* regarded as JDK internal API by jdeps of jdk9-ea135

Re: [PATCH] 8143596: FXCanvas does not forward touch gestures to embedded scene

Re: Marking synthesized scroll events as such.

Re: [PATCH] 8161282: FXCanvas does not forward horizontal mouse scroll events to the embedded scene

Marking synthesized scroll events as such.

Re: [PATCH] 8161282: FXCanvas does not forward horizontal mouse scroll events to the embedded scene

[PATCH] 8161282: FXCanvas does not forward horizontal mouse scroll events to the embedded scene

Re: [PATCH] 8160325: Provide a public API to obtain the FXCanvas for an embedded scene.

Re: [PATCH] 8160325: Provide a public API to obtain the FXCanvas for an embedded scene.

Re: [PATCH] 8088147: FXCanvas: implement custom cursors (revised)

Re: [PATCH] 8088147: FXCanvas: implement custom cursors (revised)

Re: [PATCH] 8088147: FXCanvas: implement custom cursors (revised)

Re: [PATCH] 8088147: FXCanvas: implement custom cursors (revised)

Re: [PATCH] 8088147: FXCanvas: implement custom cursors

[PATCH] 8088147: FXCanvas: implement custom cursors

Re: LocalDateTimeStringConverterTest seem to fail if default locale is different to en_US

Re: LocalDateTimeStringConverterTest seem to fail if default locale is different to en_US

LocalDateTimeStringConverterTest seem to fail if default locale is different to en_US

32 matches

Site Navigation

Mail list logo

Footer information