Running tests fails with Unrecognized option: -Xpatch:javafx.base=/home/rli/PWEs/rt/build/testing/modules/javafx.base

[Robert Lichtenberger]

According to David Hill, one has to use ea109 as base JDK for OpenJFX 
development.


I was able to setup the repository so that gradle tasks works and was 
able to build and sdk:

[rli@rlimbus rt]$ ls build/sdk/lib/
amd64  javafx-mx.jar  javafx-swt.jar  javafx.properties  jfxrt.jar

However, when I try to run some tests (e.g. in the base-module), I just 
get loads of error messages:


[rli@rlimbus base]$ gradle test
:buildSrc:generateGrammarSource UP-TO-DATE
:buildSrc:compileJava UP-TO-DATE
...
Unrecognized option: 
-Xpatch:javafx.base=/home/rli/PWEs/rt/build/testing/modules/javafx.base

Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.
Unrecognized option: 
-Xpatch:javafx.base=/home/rli/PWEs/rt/build/testing/modules/javafx.base

Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.
java.io.IOException: Stream closed
at 
java.lang.ProcessBuilder$NullOutputStream.write(ProcessBuilder.java:443)

at java.io.OutputStream.write(OutputStream.java:116)
at 
java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:81)

Process 'Gradle Test Executor 2' finished with non-zero exit value 1
org.gradle.process.internal.ExecException: Process 'Gradle Test Executor 
2' finished with non-zero exit value 1
at 
org.gradle.process.internal.DefaultExecHandle$ExecResultImpl.assertNormalExitValue(DefaultExecHandle.java:367)


I've tried to use ea126 as base JDK but that fails (of course) with:
Error occurred during initialization of VM
java.lang.ClassCastException: 
jdk.internal.loader.ClassLoaders$AppClassLoader (in module: java.base) 
cannot be cast to java.net.URLClassLoader (in module: java.base)


So how can I setup a system that will execute tests (in order to be able 
to contribute tests and patches...)?

[9] Review request 8160837: WebEngine doesn't handle html5 color picker

[Guru Hb]

Hi Jonathan, Arun & Alexander Z,

Please review the fix for: https://bugs.openjdk.java.net/browse/JDK-8160837
Webrev : http://cr.openjdk.java.net/~ghb/8160837/webrev.00/

Thanks,
Guru

Re: ProgressIndicator indeterminate transition bugs

[Jonathan Giles]

As Chien notes, I don't think there is a strong argument for back 
porting here. Back porting is extremely restricted now (I don't know the 
precise amount of restriction, but my instinct says "a lot"). Kevin can 
confirm once he is back from vacation (next week), but I wouldn't hold 
out much hope.


Just think of this as Yet Another Reason To Upgrade To JDK 9 (or 
YARTUTJDK9 for easy remembering).


-- Jonathan

On 14/07/16 5:00 AM, Chien Yang wrote:

Hi Diego,

As far as I'm aware these fixes aren't candidates for back port to 8. 
We will have to evaluate them if you can provide us a good 
justification for doing so.


Thanks,
- Chien

On 7/13/16, 4:40 AM, Cirujano Cuesta, Diego wrote:

Hi Chien, Jonathan,

I saw treeNode and the progress indicator issues are all done as 
talked, GREAT!


Are they planned to be included in Java 8?

Cheers,
Diego

-Original Message-
From: Chien Yang [mailto:chien.y...@oracle.com]
Sent: Dienstag, 8. März 2016 20:41
To: Cirujano Cuesta, Diego; 
jonathan.gi...@oracle.com; openjfx-dev@openjdk.java.net

Subject: Re: ProgressIndicator indeterminate transition bugs

You may track the progress of this work with this JIRA for now. We 
are still investigating the scope and impact of this work. We may 
decide to create a new JIRA and resolve this as a duplicate if we 
decide to go with a better naming.


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

- Chien


On 03/08/16 01:58, Cirujano Cuesta, Diego wrote:
Great! In that case forget the patch I made, it doesn’t make sense 
until the treeVisible property is implemented. Is there any jira 
ticket that I could follow?


Thank you Jonathan.

From: Jonathan Giles [mailto:jonathan.gi...@oracle.com]
Sent: Dienstag, 8. März 2016 10:01
To: Cirujano Cuesta, Diego; openjfx-dev@openjdk.java.net
Subject: RE: ProgressIndicator indeterminate transition bugs

The plan is that a new public API will be developed that matches the 
expectations, whilst retaining the existing treeVisible semantics in 
that API. Chien will be looking into this in the coming weeks. At 
that point we can properly fix these issues.


-- Jonathan
Sent from a touch device. Please excuse my brevity.
On 8 March 2016 21:53:07 GMT+13:00, "Cirujano Cuesta, 
Diego"> 
wrote:


Hi all,

As I understood in the comments(JDK-8094829, JDK-8094078), 
treeVisible is buggy. Is it still buggy? If yes, is there intention 
to fix the treeVisible behavior? In case of fixing this it could be 
used to fix this issue. If I am not wrong, treeVisible is still used 
by Node, SwingNode and MediaView.


@Jonathan As you mentioned in JDK-8094829 "having a correctly 
working treeVisible property would be immensely useful." And I am 
completely agree and I would like to add that having in the public 
API would be even better :-).


Thank you,
Diego

-Original Message-
From: Jonathan Giles [mailto:jonathan.gi...@oracle.com]
Sent: Sonntag, 28. Februar 2016 22:54
To: Cirujano Cuesta, Diego;
openjfx-dev@openjdk.java.net
Subject: Re: ProgressIndicator indeterminate transition bugs

If you can, are you able to file bug reports for these?

-- Jonathan

On 29/02/16 10:49 AM, Cirujano Cuesta, Diego wrote:

   Hi all,

   We found two important bugs in ProgressIndicator that are related 
with the following tickets:


   https://bugs.openjdk.java.net/browse/JDK-8094829
   https://bugs.openjdk.java.net/browse/JDK-8094078

   Now are quite critical because in a 4K monitor may cause 
OutOfMemoryException.


   Using the following example:
   "
   public class JFXMain extends Application{

@Override
public void start(Stage primaryStage) throws Exception {
HBox root = new HBox();
ToggleButton toggleButton = new ToggleButton();
ProgressIndicator progressIndicator = new 
ProgressIndicator(ProgressIndicator.INDETERMINATE_PROGRESS);

StackPane stackPane = new StackPane(progressIndicator);
stackPane.visibleProperty().bind(toggleButton.selectedProperty());
root.getChildren().addAll(toggleButton, stackPane);
primaryStage.setScene(new Scene(root));
primaryStage.show();
}
   }
   "

   ** First bug **

   Starting the Progress Indicator with indeterminate progress will
   trigger: rebuildTimeline by ProgressIndicatorSkin and in line 599
   start the animation even is not shown already:
   indeterminateTransition.playFromStart();

   ** Second bug **

   With the last commits in ProgressIndicator, as commented in 
JDK-8094829, the listeners do not care about the real visibility of 
the node(before it was used impl_treeVisibleProperty()). The 
consequence is that the ProgressIndicator in the example won´t be 
stopped.


   I can imagine that impl_treeVisibleProperty() should not be used 
and Jonathan G. said: " but I can't reliably fix that without an API 
such as 

Review: Clean up module relative paths in build.gradle

[David Hill]

Chien,
  could you review:
https://bugs.openjdk.java.net/browse/JDK-8161227

webrev: http://cr.openjdk.java.net/~ddhill/8161227 



--
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: ProgressIndicator indeterminate transition bugs

[Chien Yang]

Hi Diego,

As far as I'm aware these fixes aren't candidates for back port to 8. We 
will have to evaluate them if you can provide us a good justification 
for doing so.


Thanks,
- Chien

On 7/13/16, 4:40 AM, Cirujano Cuesta, Diego wrote:

Hi Chien, Jonathan,

I saw treeNode and the progress indicator issues are all done as talked, GREAT!

Are they planned to be included in Java 8?

Cheers,
Diego

-Original Message-
From: Chien Yang [mailto:chien.y...@oracle.com]
Sent: Dienstag, 8. März 2016 20:41
To: Cirujano Cuesta, Diego; 
jonathan.gi...@oracle.com; openjfx-dev@openjdk.java.net
Subject: Re: ProgressIndicator indeterminate transition bugs

You may track the progress of this work with this JIRA for now. We are still 
investigating the scope and impact of this work. We may decide to create a new 
JIRA and resolve this as a duplicate if we decide to go with a better naming.

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

- Chien


On 03/08/16 01:58, Cirujano Cuesta, Diego wrote:

Great! In that case forget the patch I made, it doesn’t make sense until the 
treeVisible property is implemented. Is there any jira ticket that I could 
follow?

Thank you Jonathan.

From: Jonathan Giles [mailto:jonathan.gi...@oracle.com]
Sent: Dienstag, 8. März 2016 10:01
To: Cirujano Cuesta, Diego; openjfx-dev@openjdk.java.net
Subject: RE: ProgressIndicator indeterminate transition bugs

The plan is that a new public API will be developed that matches the 
expectations, whilst retaining the existing treeVisible semantics in that API. 
Chien will be looking into this in the coming weeks. At that point we can 
properly fix these issues.

-- Jonathan
Sent from a touch device. Please excuse my brevity.
On 8 March 2016 21:53:07 GMT+13:00, "Cirujano Cuesta, 
Diego">  
wrote:

Hi all,

As I understood in the comments(JDK-8094829, JDK-8094078), treeVisible is 
buggy. Is it still buggy? If yes, is there intention to fix the treeVisible 
behavior? In case of fixing this it could be used to fix this issue. If I am 
not wrong, treeVisible is still used by Node, SwingNode and MediaView.

@Jonathan As you mentioned in JDK-8094829 "having a correctly working treeVisible 
property would be immensely useful." And I am completely agree and I would like to 
add that having in the public API would be even better :-).

Thank you,
Diego

-Original Message-
From: Jonathan Giles [mailto:jonathan.gi...@oracle.com]
Sent: Sonntag, 28. Februar 2016 22:54
To: Cirujano Cuesta, Diego;
openjfx-dev@openjdk.java.net
Subject: Re: ProgressIndicator indeterminate transition bugs

If you can, are you able to file bug reports for these?

-- Jonathan

On 29/02/16 10:49 AM, Cirujano Cuesta, Diego wrote:

   Hi all,

   We found two important bugs in ProgressIndicator that are related with the 
following tickets:

   https://bugs.openjdk.java.net/browse/JDK-8094829
   https://bugs.openjdk.java.net/browse/JDK-8094078

   Now are quite critical because in a 4K monitor may cause 
OutOfMemoryException.

   Using the following example:
   "
   public class JFXMain extends Application{

@Override
public void start(Stage primaryStage) throws Exception {
HBox root = new HBox();
ToggleButton toggleButton = new ToggleButton();
ProgressIndicator progressIndicator = new 
ProgressIndicator(ProgressIndicator.INDETERMINATE_PROGRESS);
StackPane stackPane = new StackPane(progressIndicator);
stackPane.visibleProperty().bind(toggleButton.selectedProperty());
root.getChildren().addAll(toggleButton, stackPane);
primaryStage.setScene(new Scene(root));
primaryStage.show();
}
   }
   "

   ** First bug **

   Starting the Progress Indicator with indeterminate progress will
   trigger: rebuildTimeline by ProgressIndicatorSkin and in line 599
   start the animation even is not shown already:
   indeterminateTransition.playFromStart();

   ** Second bug **

   With the last commits in ProgressIndicator, as commented in JDK-8094829, the 
listeners do not care about the real visibility of the node(before it was used 
impl_treeVisibleProperty()). The consequence is that the ProgressIndicator in 
the example won´t be stopped.

   I can imagine that impl_treeVisibleProperty() should not be used and Jonathan G. said: 
" but I can't reliably fix that without an API such as what I expect the treeVisible 
API should do." But we did not find such alternative property.

   The solution we though is the usage of internal tree visible property like 
this:

   1. Modify method:
   "
protected void updateAnimation(boolean isTreeVisible) { "
   2. Remove current calls to method in
   "
@Override protected void handleControlPropertyChanged(String p) {
super.handleControlPropertyChanged(p);

if 

Yet another test bug review request.

[Andrey Rusakov]

Hello, everyone!
Please take a look at another testbug fix from me.
Bug: JDK-8161287 
Webrev: 8161287/webrev.00 


Same fix is applicable for both 8 and 9 test workspaces.

[9] Review request for 8161053: Passing objects between JavaScript (JavaFX / WebKit) and Java causes a memory leak

[Murali Billa]

Hi Arun, Guru, Ankit


Please review below fix.

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


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





Thanks,

Murali

Fwd: Update Notification: Bug Report - JDK-8161282

[Alexander Nyßen]

> Hi all,
> 
> http://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8161282 has been 
> resolved as a duplicate of 
> http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8143596, but IMHO this is 
> not the case, as JDK-8143596 is related to touch gesture events, whereas 
> JDK-81611282 refers to mouse scroll events. I would propose to either update 
> JDK-8143596 or not resolve JDK-8161282 as a duplicate.
> 
> Regards,
> Alexander


> Von: bug-report-daemon...@oracle.com
> Datum: 13. Juli 2016 um 14:01:25 MESZ
> An: nys...@itemis.de
> Betreff: Update Notification: Bug Report  - JDK-8161282
> 
> [This is an automated response. Please do not reply.]
> 
> Dear Java Developer,
> 
> We have finished evaluating your report and have assigned it a Bug ID: 
> JDK-8161282. The issue is visible on bugs.java.com at the following url 
> http://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8161282 .
> 
> We work to resolve the issues that are submitted to us according to their 
> impact to the community as a whole, and make no promises as to the time or 
> release in which a bug might be fixed. If this issue has a significant impact 
> on your project you may want to consider using one of the technical support 
> offerings available at Oracle Support.
> 
> Regards, 
> Java Developer Support

RE: ProgressIndicator indeterminate transition bugs

[Cirujano Cuesta, Diego]

Hi Chien, Jonathan,

I saw treeNode and the progress indicator issues are all done as talked, GREAT! 

Are they planned to be included in Java 8?

Cheers,
Diego

-Original Message-
From: Chien Yang [mailto:chien.y...@oracle.com] 
Sent: Dienstag, 8. März 2016 20:41
To: Cirujano Cuesta, Diego ; 
jonathan.gi...@oracle.com; openjfx-dev@openjdk.java.net
Subject: Re: ProgressIndicator indeterminate transition bugs

You may track the progress of this work with this JIRA for now. We are still 
investigating the scope and impact of this work. We may decide to create a new 
JIRA and resolve this as a duplicate if we decide to go with a better naming.

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

- Chien


On 03/08/16 01:58, Cirujano Cuesta, Diego wrote:
> Great! In that case forget the patch I made, it doesn’t make sense until the 
> treeVisible property is implemented. Is there any jira ticket that I could 
> follow?
>
> Thank you Jonathan.
>
> From: Jonathan Giles [mailto:jonathan.gi...@oracle.com]
> Sent: Dienstag, 8. März 2016 10:01
> To: Cirujano Cuesta, Diego; openjfx-dev@openjdk.java.net
> Subject: RE: ProgressIndicator indeterminate transition bugs
>
> The plan is that a new public API will be developed that matches the 
> expectations, whilst retaining the existing treeVisible semantics in that 
> API. Chien will be looking into this in the coming weeks. At that point we 
> can properly fix these issues.
>
> -- Jonathan
> Sent from a touch device. Please excuse my brevity.
> On 8 March 2016 21:53:07 GMT+13:00, "Cirujano Cuesta, Diego" 
> > 
> wrote:
>
> Hi all,
>
> As I understood in the comments(JDK-8094829, JDK-8094078), treeVisible is 
> buggy. Is it still buggy? If yes, is there intention to fix the treeVisible 
> behavior? In case of fixing this it could be used to fix this issue. If I am 
> not wrong, treeVisible is still used by Node, SwingNode and MediaView.
>
> @Jonathan As you mentioned in JDK-8094829 "having a correctly working 
> treeVisible property would be immensely useful." And I am completely agree 
> and I would like to add that having in the public API would be even better 
> :-).
>
> Thank you,
> Diego
>
> -Original Message-
> From: Jonathan Giles [mailto:jonathan.gi...@oracle.com]
> Sent: Sonntag, 28. Februar 2016 22:54
> To: Cirujano Cuesta, Diego; 
> openjfx-dev@openjdk.java.net
> Subject: Re: ProgressIndicator indeterminate transition bugs
>
> If you can, are you able to file bug reports for these?
>
> -- Jonathan
>
> On 29/02/16 10:49 AM, Cirujano Cuesta, Diego wrote:
>
>   Hi all,
>
>   We found two important bugs in ProgressIndicator that are related with the 
> following tickets:
>
>   https://bugs.openjdk.java.net/browse/JDK-8094829
>   https://bugs.openjdk.java.net/browse/JDK-8094078
>
>   Now are quite critical because in a 4K monitor may cause 
> OutOfMemoryException.
>
>   Using the following example:
>   "
>   public class JFXMain extends Application{
>
>@Override
>public void start(Stage primaryStage) throws Exception {
>HBox root = new HBox();
>ToggleButton toggleButton = new ToggleButton();
>ProgressIndicator progressIndicator = new 
> ProgressIndicator(ProgressIndicator.INDETERMINATE_PROGRESS);
>StackPane stackPane = new StackPane(progressIndicator);
>stackPane.visibleProperty().bind(toggleButton.selectedProperty());
>root.getChildren().addAll(toggleButton, stackPane);
>primaryStage.setScene(new Scene(root));
>primaryStage.show();
>}
>   }
>   "
>
>   ** First bug **
>
>   Starting the Progress Indicator with indeterminate progress will
>   trigger: rebuildTimeline by ProgressIndicatorSkin and in line 599
>   start the animation even is not shown already:
>   indeterminateTransition.playFromStart();
>
>   ** Second bug **
>
>   With the last commits in ProgressIndicator, as commented in JDK-8094829, 
> the listeners do not care about the real visibility of the node(before it was 
> used impl_treeVisibleProperty()). The consequence is that the 
> ProgressIndicator in the example won´t be stopped.
>
>   I can imagine that impl_treeVisibleProperty() should not be used and 
> Jonathan G. said: " but I can't reliably fix that without an API such as what 
> I expect the treeVisible API should do." But we did not find such alternative 
> property.
>
>   The solution we though is the usage of internal tree visible property like 
> this:
>
>   1. Modify method:
>   "
>protected void updateAnimation(boolean isTreeVisible) { "
>   2. Remove current calls to method in
>   "
>@Override protected void handleControlPropertyChanged(String p) {
>super.handleControlPropertyChanged(p);
>
>if ("INDETERMINATE".equals(p)) {
>initialize();
>} else if 

Test bug fix review request.

[Andrey Rusakov]

Hi everyone.
Please take a look at my fix for openjfx test: JDK-8157589 
, webrev: 8157589/ 



With best regards, Andrew.

[webkit] [9] Review request for 8160769: [WebView] Unable to tile SVG image using css background property

[Arunprasad Rajkumar]

Hello Guru, Alexander Z, Murali,

Please review the following fix.

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

Webrev: http://cr.openjdk.java.net/~arajkumar/8160769/webrev.00

Issue: Unable to tile SVG image using css background property

Analysis: For tiled SVG image drawing, WebCore creates a temporary 
Graphics buffer(ImageBufferJava)[1] and renders SVG contents into it. 
Once the SVG is rendered in the temporary graphics buffer, WebCore will 
call Image::drawPattern to tile it on the WebPage's back buffer. As soon 
as drawing is completed, temporary graphics buffer will be destroyed.


FX WebView's GraphicsContext APIs are asynchronous in nature(rendered in 
FX render thread using RenderQueue), so temporary graphics buffer would 
have been destroyed even before rendering the SVG content into it. At 
later point of time, when Image::drawPattern is executed in render 
thread, it will be accessing a GraphicsContext of an destroyed object.


Solution: Before destroying an Native ImageBuffer, flush all its render 
queue commands synchronously, So that it's content will be rendered as 
expected.


[1] 
http://trac.webkit.org/browser/trunk/Source/WebCore/svg/graphics/SVGImage.cpp?rev=187486#L202


Regards,
Arun

[webkit] [9] Review request for 8161258: [Win] Timer functionality is broken after JDK-8089563

[Arunprasad Rajkumar]

Hello Guru, Murali,

Please review the following fix.

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

Webrev: http://cr.openjdk.java.net/~arajkumar/8161258/webrev.00

Issue: Timer functionality is broken after JDK-8161258 in Windows.

Analysis: Our monotonically increasing time implementation for windows 
is based on glib's g_get_monotonic_time[1] function which returns time 
in microseconds. So the windows implementation of g_get_monotonic_time 
multiplies the ticks in millisecond by 1000 to convert to microseconds.


Solution: WTF::monotonicallyIncreasingTime() expects time in seconds, so 
we need to divide by value returned by GetTickCount64 by 1000, since it 
is in milliseconds.


Regards,
Arun