date:20180405

Re: gradle :web:test fails

2018-04-05 Thread Nir Lisker

Yes, I didn't build Webkit and the JDK is 10, but I thought the Webkit
tests would be skipped if it weren't built.

The filed bug should do it. Thanks.

- Nir

On Thu, Apr 5, 2018, 15:01 Kevin Rushforth 
wrote:

> Yes, this is very likely the issue. If you take the jfxwebkit.dll from
> the latest EA build of JDK 11 then you should be fine. Alternatively, if
> you have the patience to build webkit from source (at least once) then
> you can use that.
>
> Johan had a good idea that gradle :web:test should produce a warning if
> COMPILE_WEBKIT is false [1].
>
> I just now filed a bug [2] to track this.
>
> -- Kevin
>
> [1]
> https://github.com/javafxports/openjdk-jfx/issues/19#issuecomment-
> 378521501
> [2] https://bugs.openjdk.java.net/browse/JDK-8201176
>
>
> Murali Billa wrote:
> > Hi Lisker,
> >
> > +one more point:
> >
> > I think you are not compiling webkit . The command "gradle :web:test"
> picks the webkit dll from JDK (which can have older versions like 10 / 9) .
> >
> > You can compile webkit  with command " gradle -PCOMPILE_WEBKIT=true
> :web:test" and in this case webkit dll will be picked up from your source
> code repo (not from JDK).
> >
> > Thanks,
> > Murali
> >
> > -Original Message-
> > From: Murali Billa
> > Sent: Thursday, April 05, 2018 10:19 AM
> > To: Nir Lisker ; openjfx-dev@openjdk.java.net
> Mailing 
> > Subject: RE: gradle :web:test fails
> >
> > Hi Lisker,
> >
> > Can you print  the value of  useragentString ? Looks like you are using
> fxversion as 11 (you can print this value from  
> System.getProperty("javafx.runtime.version");)
> but the useragentstring does not contain 11.
> >
> > final WebView webView = new WebView();
> > final WebEngine webEngine = webView.getEngine();
> System.out.println(webEngine.getUserAgent());
> >
> >
> > Thanks,
> > Murali
> > -Original Message-
> > From: Nir Lisker 
> > Sent: Thursday, April 05, 2018 7:03 AM
> > To: openjfx-dev@openjdk.java.net Mailing 
> > Subject: gradle :web:test fails
> >
> > I'm running :web:test in revision 10889 and getting the following failing
> > test:
> >
> > test.javafx.scene.web.MiscellaneousTest > testUserAgentString FAILED
> > java.lang.AssertionError: UserAgentString does not contain JavaFX/11
> > at org.junit.Assert.fail(Assert.java:91)
> > at org.junit.Assert.assertTrue(Assert.java:43)
> > at
> > test.javafx.scene.web.MiscellaneousTest.lambda$testUserAgentString$12(
> MiscellaneousTest.java:441)
> >
> > 379 tests completed, 1 failed, 12 skipped :web:test FAILED
> >
> > Is this known?
> >
> > - Nir
> >
>

Review Request: JDK-8200587: Fix mistakes in FX API docs

2018-04-05 Thread Nir Lisker

Hi Kevin,

After JDK-8200749 is committed, please review the fixes for documentation
mistakes:

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

Thanks,
Nir

RE: CFV: New OpenJFX Committer: Rajath Kamath

2018-04-05 Thread Ambarish Rapte

Vote: Yes

-Original Message-
From: Guru 
Sent: Tuesday, April 03, 2018 2:12 PM
To: Kevin Rushforth 
Cc: openjfx-dev@openjdk.java.net
Subject: Re: CFV: New OpenJFX Committer: Rajath Kamath

Vote: YES

> On 29-Mar-2018, at 10:12 PM, Kevin Rushforth  
> wrote:
> 
> I hereby nominate Rajath Kamath [1] to OpenJFX Committer.
> 
> Rajath is a member of JavaFX team at Oracle, who has contributed 17 
> changesets [2][3] to OpenJFX.
> 
> Votes are due by April 12, 2018.
> 
> Only current OpenJFX Committers [4] are eligible to vote on this nomination. 
> Votes must be cast in the open by replying to this mailing list.
> 
> For Lazy Consensus voting instructions, see [5]. Nomination to a project 
> Committer is described in [6].
> 
> By way of background, an earlier nomination failed [7]. Since then, Rajath 
> has contributed 2 more test fixes and 1 more product fix.
> 
> Thanks.
> 
> -- Kevin
> 
> [1] http://openjdk.java.net/census#rkamath
> 
> [2] 
> http://hg.openjdk.java.net/openjfx/jfx-dev/rt/log?revcount=20=auth
> or%28rkamath%29 [3] 
> http://hg.openjdk.java.net/openjfx/jfx-dev/rt/log?revcount=20=raja
> th.kamath
> 
> [4] http://openjdk.java.net/census#openjfx
> 
> [5] http://openjdk.java.net/bylaws#lazy-consensus
> 
> [6] http://openjdk.java.net/projects#project-committer
> 
> [7] 
> http://mail.openjdk.java.net/pipermail/openjfx-dev/2018-February/02149
> 9.html
>

Re: gradle :web:test fails

2018-04-05 Thread Kevin Rushforth

Yes, this is very likely the issue. If you take the jfxwebkit.dll from 
the latest EA build of JDK 11 then you should be fine. Alternatively, if 
you have the patience to build webkit from source (at least once) then 
you can use that.


Johan had a good idea that gradle :web:test should produce a warning if 
COMPILE_WEBKIT is false [1].


I just now filed a bug [2] to track this.

-- Kevin

[1] 
https://github.com/javafxports/openjdk-jfx/issues/19#issuecomment-378521501

[2] https://bugs.openjdk.java.net/browse/JDK-8201176


Murali Billa wrote:

Hi Lisker,

+one more point:

I think you are not compiling webkit . The command "gradle :web:test"  picks 
the webkit dll from JDK (which can have older versions like 10 / 9) .

You can compile webkit  with command " gradle -PCOMPILE_WEBKIT=true  :web:test" 
and in this case webkit dll will be picked up from your source code repo (not from JDK).

Thanks,
Murali

-Original Message-
From: Murali Billa 
Sent: Thursday, April 05, 2018 10:19 AM

To: Nir Lisker ; openjfx-dev@openjdk.java.net Mailing 

Subject: RE: gradle :web:test fails

Hi Lisker,

Can you print  the value of  useragentString ? Looks like you are using fxversion as 11 
(you can print this value from  System.getProperty("javafx.runtime.version");) 
but the useragentstring does not contain 11.

final WebView webView = new WebView();
final WebEngine webEngine = webView.getEngine(); System.out.println(webEngine.getUserAgent()); 



Thanks,
Murali
-Original Message-
From: Nir Lisker 
Sent: Thursday, April 05, 2018 7:03 AM
To: openjfx-dev@openjdk.java.net Mailing 
Subject: gradle :web:test fails

I'm running :web:test in revision 10889 and getting the following failing
test:

test.javafx.scene.web.MiscellaneousTest > testUserAgentString FAILED
java.lang.AssertionError: UserAgentString does not contain JavaFX/11
at org.junit.Assert.fail(Assert.java:91)
at org.junit.Assert.assertTrue(Assert.java:43)
at
test.javafx.scene.web.MiscellaneousTest.lambda$testUserAgentString$12(MiscellaneousTest.java:441)

379 tests completed, 1 failed, 12 skipped :web:test FAILED

Is this known?

- Nir

Re: CSSParser Color.parse() for unexpected CSS properties

2018-04-05 Thread Kevin Rushforth

OK, thanks. For the benefit of others who might be interested, this bug 
is now visible here:

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

-- Kevin

Matthew Elliot wrote:

Hi Kevin,

Priyanka from Oracle beat me to it and this small example hit the nail 
on the head immediately. The below will throw and swallow and 
IllegalArgumentException in CSSParser in the following method.

private ParsedValueImpl colorValueOfString(String str) {

import javafx.application.Application;
import javafx.scene.Scene;
import javafx.scene.control.Button;
import javafx.scene.layout.VBox;
import javafx.stage.Stage;

public class CssParserTest extends Application  {

@Override
public void start(Stage primaryStage) throws Exception {
primaryStage.setTitle("HBox Experiment 1");

Button button1 = new Button("Button Number 1");
Button button2 = new Button("Button Number 2");

VBox vbox = new VBox(button1, button2);
vbox.setStyle("-fx-alignment: top-center;");

Scene scene = new Scene(vbox, 200, 100);

primaryStage.setScene(scene);
primaryStage.show();
}

public static void main(String[] args) {
Application.launch(args);
}
}

There are at least 3 properties I have seen doing this and depending 
on the complexity of the CSS, in our case quite extensive it leads to 
a lot of throw/catch/ignore. :)

M.

On 4 April 2018 at 18:06, Kevin Rushforth > wrote:

Hi Matt,

Thank you for filing this bug.

Can you provide a standalone test case that reproduces this (a
.java and a .css file), so we can attach it to the bug? Our
WebBugs triage engineer will ask for this, and it will save time
if you can provide it now. Otherwise the bug report looks fine.

-- Kevin

Matthew Elliot wrote:

Hey David, thanks.
I have filed a bug via the Oracle website.

internal review ID : 9053225

Hopefully this was correct as it was also my first time.
Matt

On 4 April 2018 at 17:21, David Grieve
> wrote:

On 4/4/18 10:44 AM, Matthew Elliot wrote:

Hi David, thanks for the quick response, the parser does
seem to have
knowledge of the property and values as in the method ...

ParsedValueImpl valueFor(String property, Term root,
CSSLexer lexer) throws ParseException {}

it looks for particular properties for parsing... e.g.

} else if ("-fx-background-color".equals(prop)) {
return parsePaintLayers(root);
} else if ("-fx-background-image".equals(prop)) {
return parseURILayers(root);
} else if ("-fx-background-insets".equals(prop)) {
 return parseInsetsLayers(root);

... but fx-alignment and fx-shape for example aren't
listed here and fall
into this strange catch all place I noted in my previous
email.

My follow up questions would be:

1. Why does it hit this for standard css properties as
defined for JavaFX
components(fx-alignment, fx-shape, etc) I.e.
https://docs.oracle.com/
javafx/2/api/javafx/scene/doc-files/cssref.html (hbox,
vbox have
-fx-alignment)
2. Even if it is wanted to be extensible, isn't by default
attempting to
parse a color where the property is not known and
therefore triggering
exception throw / catch on the thread critical to UI perf
a less than
optimal solution? Could it be changed to handle this more
gracefully than
catch / ignore exceptions?

Is it worth raising a ticket for such a topic, would it
ever be considered
for improvement.

I think it is worth raising a ticket.

Thanks again,
Matt

On 4 April 2018 at 16:20, David Grieve
>
wrote:

The parser doesn't have any concept of what the
property is or value it
might have. This allows the addition of new properties
(such as an user
might add for their own CSS styles) without having to
modify the parser to
handle them.

On 4/4/18 10:03 AM, Matthew Elliot wrote:

Hi all, (first post).

I was profiling our PROD JavaFX application
recently I discovered
something
rather peculiar in the CSSParser. (jdk1.8.0_151)

RE: gradle :web:test fails

2018-04-05 Thread Murali Billa

Hi Lisker,

+one more point:

I think you are not compiling webkit . The command "gradle :web:test"  picks 
the webkit dll from JDK (which can have older versions like 10 / 9) .

You can compile webkit  with command " gradle -PCOMPILE_WEBKIT=true  :web:test" 
and in this case webkit dll will be picked up from your source code repo (not 
from JDK).

Thanks,
Murali

-Original Message-
From: Murali Billa 
Sent: Thursday, April 05, 2018 10:19 AM
To: Nir Lisker ; openjfx-dev@openjdk.java.net Mailing 

Subject: RE: gradle :web:test fails

Hi Lisker,

Can you print  the value of  useragentString ? Looks like you are using 
fxversion as 11 (you can print this value from  
System.getProperty("javafx.runtime.version");) but the useragentstring does not 
contain 11.

final WebView webView = new WebView();
final WebEngine webEngine = webView.getEngine(); 
System.out.println(webEngine.getUserAgent()); 


Thanks,
Murali
-Original Message-
From: Nir Lisker 
Sent: Thursday, April 05, 2018 7:03 AM
To: openjfx-dev@openjdk.java.net Mailing 
Subject: gradle :web:test fails

I'm running :web:test in revision 10889 and getting the following failing
test:

test.javafx.scene.web.MiscellaneousTest > testUserAgentString FAILED
java.lang.AssertionError: UserAgentString does not contain JavaFX/11
at org.junit.Assert.fail(Assert.java:91)
at org.junit.Assert.assertTrue(Assert.java:43)
at
test.javafx.scene.web.MiscellaneousTest.lambda$testUserAgentString$12(MiscellaneousTest.java:441)

379 tests completed, 1 failed, 12 skipped :web:test FAILED

Is this known?

- Nir

Re: CSSParser Color.parse() for unexpected CSS properties

2018-04-05 Thread Matthew Elliot

Hi Kevin,

Priyanka from Oracle beat me to it and this small example hit the nail on
the head immediately. The below will throw and swallow and
IllegalArgumentException in CSSParser in the following method.

private ParsedValueImpl colorValueOfString(String str) {



import javafx.application.Application;
import javafx.scene.Scene;
import javafx.scene.control.Button;
import javafx.scene.layout.VBox;
import javafx.stage.Stage;


public class CssParserTest extends Application  {


@Override
public void start(Stage primaryStage) throws Exception {
primaryStage.setTitle("HBox Experiment 1");

Button button1 = new Button("Button Number 1");
Button button2 = new Button("Button Number 2");

VBox vbox = new VBox(button1, button2);
vbox.setStyle("-fx-alignment: top-center;");

Scene scene = new Scene(vbox, 200, 100);

primaryStage.setScene(scene);
primaryStage.show();
}

public static void main(String[] args) {
Application.launch(args);
}
}

There are at least 3 properties I have seen doing this and depending on the
complexity of the CSS, in our case quite extensive it leads to a lot of
throw/catch/ignore. :)

M.


On 4 April 2018 at 18:06, Kevin Rushforth 
wrote:

> Hi Matt,
>
> Thank you for filing this bug.
>
> Can you provide a standalone test case that reproduces this (a .java and a
> .css file), so we can attach it to the bug? Our WebBugs triage engineer
> will ask for this, and it will save time if you can provide it now.
> Otherwise the bug report looks fine.
>
> -- Kevin
>
>
>
> Matthew Elliot wrote:
>
>> Hey David, thanks.
>> I have filed a bug via the Oracle website.
>>
>> internal review ID : 9053225
>>
>> Hopefully this was correct as it was also my first time.
>> Matt
>>
>>
>> On 4 April 2018 at 17:21, David Grieve  wrote:
>>
>>
>>
>>> On 4/4/18 10:44 AM, Matthew Elliot wrote:
>>>
>>> Hi David, thanks for the quick response, the parser does seem to have
>>> knowledge of the property and values as in the method ...
>>>
>>> ParsedValueImpl valueFor(String property, Term root, CSSLexer lexer)
>>> throws ParseException {}
>>>
>>> it looks for particular properties for parsing... e.g.
>>>
>>> } else if ("-fx-background-color".equals(prop)) {
>>> return parsePaintLayers(root);
>>> } else if ("-fx-background-image".equals(prop)) {
>>> return parseURILayers(root);
>>> } else if ("-fx-background-insets".equals(prop)) {
>>>  return parseInsetsLayers(root);
>>>
>>> ... but fx-alignment and fx-shape for example aren't listed here and fall
>>> into this strange catch all place I noted in my previous email.
>>>
>>> My follow up questions would be:
>>>
>>> 1. Why does it hit this for standard css properties as defined for JavaFX
>>> components(fx-alignment, fx-shape, etc) I.e. https://docs.oracle.com/
>>> javafx/2/api/javafx/scene/doc-files/cssref.html (hbox, vbox have
>>> -fx-alignment)
>>> 2. Even if it is wanted to be extensible, isn't by default attempting to
>>> parse a color where the property is not known and therefore triggering
>>> exception throw / catch on the thread critical to UI perf a less than
>>> optimal solution? Could it be changed to handle this more gracefully than
>>> catch / ignore exceptions?
>>>
>>> Is it worth raising a ticket for such a topic, would it ever be
>>> considered
>>> for improvement.
>>>
>>> I think it is worth raising a ticket.
>>>
>>>
>>> Thanks again,
>>> Matt
>>>
>>>
>>> On 4 April 2018 at 16:20, David Grieve  wrote:
>>>
>>>
>>>
 The parser doesn't have any concept of what the property is or value it
 might have. This allows the addition of new properties (such as an user
 might add for their own CSS styles) without having to modify the parser
 to
 handle them.



 On 4/4/18 10:03 AM, Matthew Elliot wrote:



> Hi all, (first post).
>
> I was profiling our PROD JavaFX application recently I discovered
> something
> rather peculiar in the CSSParser. (jdk1.8.0_151)
>
> I noticed several hundred IllegalArgumentExceptions on the
> JavaApplicationThread where for various unrelated css properties the
> CSSParser is trying to parse a color. While the exception is
> subsequently
> caught and swallowed silently doing this hundred of times on this
> thread
> is
> rather ugly and caused *minor* delays in the application thread.
>
> This happened for alignment, shape, and a few other properties where
> no-lookup case was found and it ended on approx. line 900 of the
> CSSParser
> in
>
> colorValueOfString()
>
> with a value like 'center'; clearly no color.
>
> // if the property value is another property, then it needs to be
> looked
> up.
> boolean needsLookup = isIdent && properties.containsKey(text);
> if (needsLookup || ((value

Will OpenJFX have a release ready in time for the Java 11 launch?

2018-04-05 Thread Mikael Christensen - QIAGEN

Hi,

This is a question about Oracle's statement that JavaFX will no longer be part 
of the SDK starting from Java 11:
https://blogs.oracle.com/java-platform-group/the-future-of-javafx-and-other-java-client-roadmap-updates

Is the plan, that when Java 11 is released (scheduled for September 2018), it 
will be possible to download a (prebuilt) JavaFX component from the OpenJFX?

Best, Mikael.

Re: Will OpenJFX have a release ready in time for the Java 11 launch?

2018-04-05 Thread Kevin Rushforth

Yes, this is the plan. There has been quite a lot of discussion on this, 
so I invite you to search the email archives [1]. Specifically, the 
recent "modules versus SDK's" thread [2]. You are welcome to join the 
mailing list [3] and contribute to the discussion if you like.


-- Kevin

[1] http://mail.openjdk.java.net/pipermail/openjfx-dev/
[2] 
http://mail.openjdk.java.net/pipermail/openjfx-dev/2018-March/021624.html

[3] http://mail.openjdk.java.net/mailman/listinfo/openjfx-dev


Mikael Christensen - QIAGEN wrote:

Hi,

This is a question about Oracle's statement that JavaFX will no longer be part 
of the SDK starting from Java 11:
https://blogs.oracle.com/java-platform-group/the-future-of-javafx-and-other-java-client-roadmap-updates

Is the plan, that when Java 11 is released (scheduled for September 2018), it 
will be possible to download a (prebuilt) JavaFX component from the OpenJFX?

Best, Mikael.

Re: HEADS-UP: Proposal to bump the minimum boot JDK for FX to JDK 10

2018-04-05 Thread Kevin Rushforth

I created a pull request [3] for this, and discovered that the CI builds 
for the GitHub sandbox are using JDK 9.0.4. Michael Ennen is fixing this 
by switching both the Travis and Appveyor CI builds to use JDK 10 [4].


Given the disruptive nature of bumping the minimum, I think it is wise 
to wait another day or two before taking any action on my proposal to 
bump the minimum (we can and should still proceed to upgrade the CI 
builds to use JDK 10). This will give others who might have concerns a 
chance to comment.


Comments?

-- Kevin

[3] https://github.com/javafxports/openjdk-jfx/pull/61

[4] https://github.com/javafxports/openjdk-jfx/pull/63


Kevin Rushforth wrote:
As mentioned in another thread [1] we should update the minimum boot 
JDK used to build FX to 10, which will allow the use of JDK 10 
langauge features, such as 'var', as well as JDK 10 APIs. It's also 
the right time to do this in general. I filed a new RFE [2] to track 
this and plan to send it out for review next week.


Please let me know if there are any concerns. We already use JDK 10 to 
build FX 11 ea bits. I presume that the travis and appveyor CI builds 
of the github mirror do the same?


-- Kevin

[1] 
http://mail.openjdk.java.net/pipermail/openjfx-dev/2018-March/021671.html


[2] https://bugs.openjdk.java.net/browse/JDK-8200446

Re: gradle :web:test fails

Review Request: JDK-8200587: Fix mistakes in FX API docs

RE: CFV: New OpenJFX Committer: Rajath Kamath

Re: gradle :web:test fails

Re: CSSParser Color.parse() for unexpected CSS properties

RE: gradle :web:test fails

Re: CSSParser Color.parse() for unexpected CSS properties

Will OpenJFX have a release ready in time for the Java 11 launch?

Re: Will OpenJFX have a release ready in time for the Java 11 launch?

Re: HEADS-UP: Proposal to bump the minimum boot JDK for FX to JDK 10

10 matches

Site Navigation

Mail list logo

Footer information