review: @native annotations

[David Hill]

Kevin, Guru,

The javac tool now provides the ability to generate native headers as needed. 
This removes the need to run the javah tool as a separate step in the build 
pipeline. The feature is enabled in javac by using the new -h option, which is 
used to specify a directory in which the header files should be written. Header 
files will be generated for any class which has either native methods, or 
constant fields annotated with a new annotation of type 
java.lang.annotation.Native. (Since JDK 1.8)

This should ease the transition to a modular build by allowing us to remove one 
extra javah step.

These two change sets add @Native annotations to classes that we need in native that are 
not currently  being generated automatically with javac -h. In two cases, I removed 
"empty" header includes (the javah generated header does not have any 
meaningful content).

https://bugs.openjdk.java.net/browse/JDK-8166230
http://cr.openjdk.java.net/~ddhill/8166230 graphics, media

https://bugs.openjdk.java.net/browse/JDK-8166231
http://cr.openjdk.java.net/~ddhill/8166231 webkit

Note that the actual conversion to using the javac -h step will happen at a 
later date. These changesets just allow us to get ready for that future, and 
reduce the risk of merge conflicts later.


--
David Hill
Java Embedded Development

"A man's feet should be planted in his country, but his eyes should survey the 
world."
-- George Santayana (1863 - 1952)

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

[Artem Ananiev]

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.


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


Thanks,

Artem

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

[9] Review Request:

[Chris Bensen]

Kevin,

Add modules and limit modules are broken in some situations.

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

Webrev: http://cr.openjdk.java.net/~cbensen/JDK-8166172/webrev.00/ 


Chris

Re: In(Sanity) Testing Mondays

[Kevin Rushforth]

As next week is JavaOne, I won't be online during the day on Monday. 
Unless there is an unexpected show-stopper bug, please consider the repo 
to be "unlocked" at 1pm PT on Monday.


-- Kevin


Vadim Pakhnushev wrote:

Reminder, Monday is our weekly sanity testing.

You can find your testing assignment at:
https://wiki.openjdk.java.net/display/OpenJFX/Sanity+Testing

Also please remember that the repo will be locked from 1am PST until 
1pm PST.


Happy testing!

Thanks,
Vadim

In(Sanity) Testing Mondays

[Vadim Pakhnushev]

Reminder, Monday is our weekly sanity testing.

You can find your testing assignment at:
https://wiki.openjdk.java.net/display/OpenJFX/Sanity+Testing

Also please remember that the repo will be locked from 1am PST until 1pm 
PST.


Happy testing!

Thanks,
Vadim

Necessity of com.sun.javafx.embed.AbstractEvents

[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