Will there be an API for creating materials?

[Nir Lisker]

It seems that currently developers can't create their own material because
the abstract class Material is not designed to be subclassed, and so
PhongMaterial is the only one available.

Are there any plans to allow developers to subclass Material and crate
their own materials? Phong is somewhat old and other shaders are more
commonly used in the industry.

Re: Corrections for Javadoc

[Nir Lisker]

Add this to the list as well please:

javafx.scene.image.Image's constructors:

- Image(String url)
- Image(String url, boolean backgroundLoading)
- Image(String url, double requestedWidth, double requestedHeight, boolean
preserveRatio, boolean smooth)

all have a @see annotation pointing to a private constructor. This makes
the link in the generated docs do nothing.

On Wed, May 10, 2017 at 7:25 PM, Kevin Rushforth <kevin.rushfo...@oracle.com
> wrote:

> I just filed a new issue to catch any last minute typos:
>
> https://bugs.openjdk.java.net/browse/JDK-8180070
>
> I'll add your note to this new JBS bug.
>
> Thank you.
>
> -- Kevin
>
>
>
>
> Nir Lisker wrote:
>
>> I'm looking at build 168 of JDK9 and there are a few mistakes in the docs.
>> I can't submit issues to the JIRA so I'll list them here. A similar issue
>> was https://bugs.openjdk.java.net/browse/JDK-8177341.
>>
>>
>>- The following use "a Observable..." instead of "an Observable...".
>>- javafx.beans.property
>>  - ListProperty
>>  - MapProperty<K,V>
>>  - ReadOnlyListPropertyBase
>>  - SetProperty
>>   - javafx.beans.binding
>>  - NumberExpression
>>  - BooleanExpression
>>  - DoubleExpression
>>  - FloatExpression
>>  - IntegerExpression
>>  - ListExpression
>>  - LongExpression
>>  - MapExpression
>>  - ObjectExpression
>>  - SetExpression
>>  - StringExpression
>>  - javafx.scene.shape.ObservableFaceArray copies its description
>>from its superinteface ObservableIntegerArray, does not declare any API
>>methods and is listed under package javafx.scene.shape. It's not clear
>> at
>>all what this interface is. As it is, it looks like it's not meant to
>> be
>>exposed.
>>- javafx.collections.ObservableIntegerArray uses "a int[]" instead of
>>"an int[]". This writing ("a int") is found in java.lang.Integer as
>> well in
>>a few places.
>>
>> Nir
>>
>>
>

Corrections for Javadoc

[Nir Lisker]

I'm looking at build 168 of JDK9 and there are a few mistakes in the docs.
I can't submit issues to the JIRA so I'll list them here. A similar issue
was https://bugs.openjdk.java.net/browse/JDK-8177341.


   - The following use "a Observable..." instead of "an Observable...".
   - javafx.beans.property
 - ListProperty
 - MapProperty
 - ReadOnlyListPropertyBase
 - SetProperty
  - javafx.beans.binding
 - NumberExpression
 - BooleanExpression
 - DoubleExpression
 - FloatExpression
 - IntegerExpression
 - ListExpression
 - LongExpression
 - MapExpression
 - ObjectExpression
 - SetExpression
 - StringExpression
 - javafx.scene.shape.ObservableFaceArray copies its description
   from its superinteface ObservableIntegerArray, does not declare any API
   methods and is listed under package javafx.scene.shape. It's not clear at
   all what this interface is. As it is, it looks like it's not meant to be
   exposed.
   - javafx.collections.ObservableIntegerArray uses "a int[]" instead of
   "an int[]". This writing ("a int") is found in java.lang.Integer as well in
   a few places.

Nir

Re: Corrections for Javadoc

[Nir Lisker]

Another typo:

In javafx.scene.Scene, all onDragDone methods and the property use "@{code
Scene}" instead of "{@code Scene}".

On Wed, May 10, 2017 at 7:25 PM, Kevin Rushforth <kevin.rushfo...@oracle.com
> wrote:

> I just filed a new issue to catch any last minute typos:
>
> https://bugs.openjdk.java.net/browse/JDK-8180070
>
> I'll add your note to this new JBS bug.
>
> Thank you.
>
> -- Kevin
>
>
>
>
> Nir Lisker wrote:
>
>> I'm looking at build 168 of JDK9 and there are a few mistakes in the docs.
>> I can't submit issues to the JIRA so I'll list them here. A similar issue
>> was https://bugs.openjdk.java.net/browse/JDK-8177341.
>>
>>
>>- The following use "a Observable..." instead of "an Observable...".
>>- javafx.beans.property
>>  - ListProperty
>>  - MapProperty<K,V>
>>  - ReadOnlyListPropertyBase
>>  - SetProperty
>>   - javafx.beans.binding
>>  - NumberExpression
>>  - BooleanExpression
>>  - DoubleExpression
>>  - FloatExpression
>>  - IntegerExpression
>>  - ListExpression
>>  - LongExpression
>>  - MapExpression
>>  - ObjectExpression
>>  - SetExpression
>>  - StringExpression
>>  - javafx.scene.shape.ObservableFaceArray copies its description
>>from its superinteface ObservableIntegerArray, does not declare any API
>>methods and is listed under package javafx.scene.shape. It's not clear
>> at
>>all what this interface is. As it is, it looks like it's not meant to
>> be
>>exposed.
>>- javafx.collections.ObservableIntegerArray uses "a int[]" instead of
>>"an int[]". This writing ("a int") is found in java.lang.Integer as
>> well in
>>a few places.
>>
>> Nir
>>
>>
>

Re: Corrections for Javadoc

[Nir Lisker]

Yes, I saw that the due date on the report is the 24th.

I don't know if it's worth anyone's time, but there are simple scripts that
catch all sorts of spelling and grammar mistakes. Pretty sure it won't be
that hard to integrate one.

Default PointLight for Scene

[Nir Lisker]

A Scene supplies a default PointLight if it contains a 3D object. However,
adding a Light to any group in the scene removes the default light. Is it
possible to retain the light, or get a reference to it from the scene?

Re: Corrections for Javadoc

[Nir Lisker]

Hopefully this makes it in time:

javafx.scene.control.TreeView has wrong javadoc for the
queryAccessibleAttribute method. The source code uses javadoc blocks as
titles, but they should probably be regular comment blocks.
One of those blocks has been read as the doc for the method because that
method has no doc.

On Wed, May 10, 2017 at 7:25 PM, Kevin Rushforth <kevin.rushfo...@oracle.com
> wrote:

> I just filed a new issue to catch any last minute typos:
>
> https://bugs.openjdk.java.net/browse/JDK-8180070
>
> I'll add your note to this new JBS bug.
>
> Thank you.
>
> -- Kevin
>
>
>
>
> Nir Lisker wrote:
>
>> I'm looking at build 168 of JDK9 and there are a few mistakes in the docs.
>> I can't submit issues to the JIRA so I'll list them here. A similar issue
>> was https://bugs.openjdk.java.net/browse/JDK-8177341.
>>
>>
>>- The following use "a Observable..." instead of "an Observable...".
>>- javafx.beans.property
>>  - ListProperty
>>  - MapProperty<K,V>
>>  - ReadOnlyListPropertyBase
>>  - SetProperty
>>   - javafx.beans.binding
>>  - NumberExpression
>>  - BooleanExpression
>>  - DoubleExpression
>>  - FloatExpression
>>  - IntegerExpression
>>  - ListExpression
>>  - LongExpression
>>  - MapExpression
>>  - ObjectExpression
>>  - SetExpression
>>  - StringExpression
>>  - javafx.scene.shape.ObservableFaceArray copies its description
>>from its superinteface ObservableIntegerArray, does not declare any API
>>methods and is listed under package javafx.scene.shape. It's not clear
>> at
>>all what this interface is. As it is, it looks like it's not meant to
>> be
>>exposed.
>>- javafx.collections.ObservableIntegerArray uses "a int[]" instead of
>>"an int[]". This writing ("a int") is found in java.lang.Integer as
>> well in
>>a few places.
>>
>> Nir
>>
>>
>

Re: Default PointLight for Scene

[Nir Lisker]

Yes, I was referring to that line in the docs.

Wouldn't it be better to allow users to retain the default light?

On Tue, May 23, 2017 at 10:05 PM, Chien Yang <chien.y...@oracle.com> wrote:

> No, this light is created internally within JavaFX as a convenient light
> source if the scene doesn't have one. User can't access to it reference.
>
> You can find this information in the Scene class documentation:
>
> Class Scene
>
> ...
>
> A default headlight will be added to a scene that contains one or more
> Shape3D nodes, but no light nodes. This light source is a Color.WHITE
> PointLight placed at the camera position.
>
>
> - Chien
>
>
>
>
> On 05/23/2017 09:11 AM, Nir Lisker wrote:
>
>> A Scene supplies a default PointLight if it contains a 3D object. However,
>> adding a Light to any group in the scene removes the default light. Is it
>> possible to retain the light, or get a reference to it from the scene?
>>
>
>

Re: Corrections for Javadoc

[Nir Lisker]

Looks like the above didn't make it in time. Can it be fixed in the next
batch?

On Tue, May 23, 2017 at 9:26 PM, Nir Lisker <nlis...@gmail.com> wrote:

> Hopefully this makes it in time:
>
> javafx.scene.control.TreeView has wrong javadoc for the
> queryAccessibleAttribute method. The source code uses javadoc blocks as
> titles, but they should probably be regular comment blocks.
> One of those blocks has been read as the doc for the method because that
> method has no doc.
>
> On Wed, May 10, 2017 at 7:25 PM, Kevin Rushforth <
> kevin.rushfo...@oracle.com> wrote:
>
>> I just filed a new issue to catch any last minute typos:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8180070
>>
>> I'll add your note to this new JBS bug.
>>
>> Thank you.
>>
>> -- Kevin
>>
>>
>>
>>
>> Nir Lisker wrote:
>>
>>> I'm looking at build 168 of JDK9 and there are a few mistakes in the
>>> docs.
>>> I can't submit issues to the JIRA so I'll list them here. A similar issue
>>> was https://bugs.openjdk.java.net/browse/JDK-8177341.
>>>
>>>
>>>- The following use "a Observable..." instead of "an Observable...".
>>>- javafx.beans.property
>>>  - ListProperty
>>>  - MapProperty<K,V>
>>>  - ReadOnlyListPropertyBase
>>>  - SetProperty
>>>   - javafx.beans.binding
>>>  - NumberExpression
>>>  - BooleanExpression
>>>  - DoubleExpression
>>>  - FloatExpression
>>>  - IntegerExpression
>>>  - ListExpression
>>>  - LongExpression
>>>  - MapExpression
>>>  - ObjectExpression
>>>  - SetExpression
>>>  - StringExpression
>>>  - javafx.scene.shape.ObservableFaceArray copies its description
>>>from its superinteface ObservableIntegerArray, does not declare any
>>> API
>>>methods and is listed under package javafx.scene.shape. It's not
>>> clear at
>>>all what this interface is. As it is, it looks like it's not meant to
>>> be
>>>exposed.
>>>- javafx.collections.ObservableIntegerArray uses "a int[]" instead of
>>>"an int[]". This writing ("a int") is found in java.lang.Integer as
>>> well in
>>>a few places.
>>>
>>> Nir
>>>
>>>
>>
>

Re: Corrections for Javadoc

[Nir Lisker]

Another thing:

javafx.scene.canvas.GraphicsContext should have a link to Canvas, either in
the first sentence or as a @see, or both.

On Fri, May 12, 2017 at 12:02 AM, Kevin Rushforth <
kevin.rushfo...@oracle.com> wrote:

> Added. This is a questionable use of @see anyway.
>
> Thanks.
>
> -- Kevin
>
>
> Nir Lisker wrote:
>
> Add this to the list as well please:
>
> javafx.scene.image.Image's constructors:
>
> - Image(String url)
> - Image(String url, boolean backgroundLoading)
> - Image(String url, double requestedWidth, double requestedHeight, boolean
> preserveRatio, boolean smooth)
>
> all have a @see annotation pointing to a private constructor. This makes
> the link in the generated docs do nothing.
>
> On Wed, May 10, 2017 at 7:25 PM, Kevin Rushforth <
> kevin.rushfo...@oracle.com> wrote:
>
>> I just filed a new issue to catch any last minute typos:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8180070
>>
>> I'll add your note to this new JBS bug.
>>
>> Thank you.
>>
>> -- Kevin
>>
>>
>>
>>
>> Nir Lisker wrote:
>>
>>> I'm looking at build 168 of JDK9 and there are a few mistakes in the
>>> docs.
>>> I can't submit issues to the JIRA so I'll list them here. A similar issue
>>> was https://bugs.openjdk.java.net/browse/JDK-8177341.
>>>
>>>
>>>- The following use "a Observable..." instead of "an Observable...".
>>>- javafx.beans.property
>>>  - ListProperty
>>>  - MapProperty<K,V>
>>>  - ReadOnlyListPropertyBase
>>>  - SetProperty
>>>   - javafx.beans.binding
>>>  - NumberExpression
>>>  - BooleanExpression
>>>  - DoubleExpression
>>>  - FloatExpression
>>>  - IntegerExpression
>>>  - ListExpression
>>>  - LongExpression
>>>  - MapExpression
>>>  - ObjectExpression
>>>  - SetExpression
>>>  - StringExpression
>>>  - javafx.scene.shape.ObservableFaceArray copies its description
>>>from its superinteface ObservableIntegerArray, does not declare any
>>> API
>>>methods and is listed under package javafx.scene.shape. It's not
>>> clear at
>>>all what this interface is. As it is, it looks like it's not meant to
>>> be
>>>exposed.
>>>- javafx.collections.ObservableIntegerArray uses "a int[]" instead of
>>>"an int[]". This writing ("a int") is found in java.lang.Integer as
>>> well in
>>>a few places.
>>>
>>> Nir
>>>
>>>
>>
>

Re: OpenJFX initiative

[Nir Lisker]

> What do you mean by “go with Johan Vos’s experience”?

What he said here:
http://mail.openjdk.java.net/pipermail/openjfx-dev/2017-September/020801.html
.

On Sat, Sep 23, 2017 at 12:08 AM, John-Val Rose <johnvalr...@gmail.com>
wrote:

> The concept of “innovation” no longer seems to apply to JavaFX, at least
> not from Oracle’s perspective.
>
> If you read the official list of changes in the just-released Java 9, AWT
> (yes, AWT) has more changes than JavaFX and even then the only significant
> change is to make it Jigsaw compatible.
>
> A product like this needs a very clear “roadmap” of development and
> introduction of new features but the link on the Oracle JavaFX
> Documentation page for “roadmap” leads to a place known as “404”. I hope
> that’s not a room number in “Hotel California”.
>
> So, innovation for JavaFX falls back as a community responsibility but is
> very difficult without any cooperation from Oracle themselves.
>
> I personally have not been able to get any response from them except
> “float your ideas on the mailing list to see what interest there is”. Note,
> that “interest” is only from the community itself... and then what?
>
> What do you mean by “go with Johan Vos’s experience”? Yes, he and Gluon
> are fantastic innovators and have built a small company of top-notch talent
> and are able to crank-out new products and enhancements with impressive
> frequency.
>
> Are you suggesting we all start similar companies? Johan is a former
> Oracle employee and probably has a well-established relationship with them
> and access to knowledge that others don’t. Personally, I love what he’s
> doing and hope Gluon expands rapidly to enable as much innovation as
> possible.
>
> But what about the rest of us? What are we supposed to do? How do we get
> large-scale changes to happen?
>
> Well, I don’t know. But we’re better as a team than a bunch of individuals
> each trying to get some feature implemented in an uncoordinated fashion.
>
> The other real issue is that everyone seems to have their own perspective
> on exactly what JavaFX is or should be. That makes the community
> ineffective unless someone manages innovation for JavaFX in general.
>
> I’d be happy to be that person but sadly, it’s not for me to make that
> call. Johan is like the de facto “Head of Innovation for JavaFX” at the
> moment but he has his own agenda (mainly in the mobile space) and monetises
> his efforts.
>
> That’s what businesses do.
>
> So, I think we need to firstly establish just what JavaFX is *now* (even
> this is not clear) and also what it *should be* (where we coalesce
> everyone’s own ideas) so we can move forward.
>
> That is of course *if* JavaFX is actually going to “move forward” rather
> than “sideways”.
>
> Honestly though, if you’re not moving forward, you are really going
> backward as you watch the rest of the world disappear over the horizon...
>
> Graciously,
>
> John-Val Rose
>
> > On 22 Sep 2017, at 22:38, Nir Lisker <nlis...@gmail.com> wrote:
> >
> > I didn't see any update on the idea for our initiative. Are we still
> waiting for a reply from Oracle or do we go with Johan Vos's experience?
> >
> > I think that the least we can do without putting any work into this is
> have a semi-formal list of people who would like to work on this  and a
> list of what features we would be working on. I feel that I still don't
> know the scope of what we are trying to do, only pieces of it.
>

Re: OpenJFX initiative

[Nir Lisker]

I don't have any answer to those questions. A JEP is the only thing I can
think of.

On Sat, Sep 23, 2017 at 3:19 AM, John-Val Rose <johnvalr...@gmail.com>
wrote:

> Yes, well I'm sure there's a lot of truth to that as Johan has
> demonstrated.
>
> But, I think it's a bit of an over simplification.
>
> How do I know if *my* innovation (of say 9 months of effort) is "high-quality
> code that makes OpenJFX better"?
>
> I can do my best to write high-quality code but what exactly does "make
> OpenJFX better" mean? *I* might think it's better with WebGL and advanced
> 3D features but it seems most people disagree or are ambivalent towards
> such functionality.
>
> Who gets to say what does or doesn't get integrated?  And, how do I know
> *before* I potentially waste my effort whether it will or won't "make
> OpenJFX better" or be integrated?
>
> ​​
> Graciously,
>
> John-Val Rose
> Chief Scientist/Architect
> Rosethorn Technology
> Australia
>
> On 23 September 2017 at 09:08, Nir Lisker <nlis...@gmail.com> wrote:
>
>> > What do you mean by “go with Johan Vos’s experience”?
>>
>> What he said here: http://mail.openjdk.java.net/pipermail/openjfx-dev/
>> 2017-September/020801.html.
>>
>> On Sat, Sep 23, 2017 at 12:08 AM, John-Val Rose <johnvalr...@gmail.com>
>> wrote:
>>
>>> The concept of “innovation” no longer seems to apply to JavaFX, at least
>>> not from Oracle’s perspective.
>>>
>>> If you read the official list of changes in the just-released Java 9,
>>> AWT (yes, AWT) has more changes than JavaFX and even then the only
>>> significant change is to make it Jigsaw compatible.
>>>
>>> A product like this needs a very clear “roadmap” of development and
>>> introduction of new features but the link on the Oracle JavaFX
>>> Documentation page for “roadmap” leads to a place known as “404”. I hope
>>> that’s not a room number in “Hotel California”.
>>>
>>> So, innovation for JavaFX falls back as a community responsibility but
>>> is very difficult without any cooperation from Oracle themselves.
>>>
>>> I personally have not been able to get any response from them except
>>> “float your ideas on the mailing list to see what interest there is”. Note,
>>> that “interest” is only from the community itself... and then what?
>>>
>>> What do you mean by “go with Johan Vos’s experience”? Yes, he and Gluon
>>> are fantastic innovators and have built a small company of top-notch talent
>>> and are able to crank-out new products and enhancements with impressive
>>> frequency.
>>>
>>> Are you suggesting we all start similar companies? Johan is a former
>>> Oracle employee and probably has a well-established relationship with them
>>> and access to knowledge that others don’t. Personally, I love what he’s
>>> doing and hope Gluon expands rapidly to enable as much innovation as
>>> possible.
>>>
>>> But what about the rest of us? What are we supposed to do? How do we get
>>> large-scale changes to happen?
>>>
>>> Well, I don’t know. But we’re better as a team than a bunch of
>>> individuals each trying to get some feature implemented in an uncoordinated
>>> fashion.
>>>
>>> The other real issue is that everyone seems to have their own
>>> perspective on exactly what JavaFX is or should be. That makes the
>>> community ineffective unless someone manages innovation for JavaFX in
>>> general.
>>>
>>> I’d be happy to be that person but sadly, it’s not for me to make that
>>> call. Johan is like the de facto “Head of Innovation for JavaFX” at the
>>> moment but he has his own agenda (mainly in the mobile space) and monetises
>>> his efforts.
>>>
>>> That’s what businesses do.
>>>
>>> So, I think we need to firstly establish just what JavaFX is *now* (even
>>> this is not clear) and also what it *should be* (where we coalesce
>>> everyone’s own ideas) so we can move forward.
>>>
>>> That is of course *if* JavaFX is actually going to “move forward” rather
>>> than “sideways”.
>>>
>>> Honestly though, if you’re not moving forward, you are really going
>>> backward as you watch the rest of the world disappear over the horizon...
>>>
>>> Graciously,
>>>
>>> John-Val Rose
>>>
>>> > On 22 Sep 2017, at 22:38, Nir Lisker <nlis...@gmail.com> wrote:
>>> >
>>> > I didn't see any update on the idea for our initiative. Are we still
>>> waiting for a reply from Oracle or do we go with Johan Vos's experience?
>>> >
>>> > I think that the least we can do without putting any work into this is
>>> have a semi-formal list of people who would like to work on this  and a
>>> list of what features we would be working on. I feel that I still don't
>>> know the scope of what we are trying to do, only pieces of it.
>>>
>>
>>
>

OpenJFX initiative

[Nir Lisker]

I didn't see any update on the idea for our initiative. Are we still
waiting for a reply from Oracle or do we go with Johan Vos's experience?

I think that the least we can do without putting any work into this is have
a semi-formal list of people who would like to work on this  and a list of
what features we would be working on. I feel that I still don't know the
scope of what we are trying to do, only pieces of it.

Re: openjfx-dev Digest, Vol 71, Issue 15

[Nir Lisker]

Hi,

Thanks for the slides Laurent. Was the talk not recorded?

Would like to get in on the community effort discussion. If possible,
include me in it.

Thanks,
Nir

On Fri, Oct 13, 2017 at 3:00 PM, 
wrote:

> Send openjfx-dev mailing list submissions to
> openjfx-dev@openjdk.java.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://mail.openjdk.java.net/mailman/listinfo/openjfx-dev
> or, via email, send a message with subject or body 'help' to
> openjfx-dev-requ...@openjdk.java.net
>
> You can reach the person managing the list at
> openjfx-dev-ow...@openjdk.java.net
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of openjfx-dev digest..."
>
>
> Today's Topics:
>
>1. [10] Review request : JDK-8172856 : Out of memory exception
>   due to repeated style class changes (Ambarish Rapte)
>2. Multiselection in a TreeView (Scott Palmer)
>3. Result: New OpenJFX Committer: Prasanta Sadhukhan
>   (Kevin Rushforth)
>4. Re: [10] Review request for 8185634, 8185634: Java Fx-Swing
>   dialogs appearing behind main stage (Sergey Bylokhov)
>5. JavaOne slides about Marlin/FX renderer (Laurent Bourg?s)
>6. Re: JavaOne slides about Marlin/FX renderer (John-Val Rose)
>
>
> --
>
> Message: 1
> Date: Thu, 12 Oct 2017 05:53:01 -0700 (PDT)
> From: Ambarish Rapte 
> To: openjfx-dev@openjdk.java.net, Kevin Rushforth
> , Ajit Ghaisas <
> ajit.ghai...@oracle.com>
> Subject: [10] Review request : JDK-8172856 : Out of memory exception
> due to repeated style class changes
> Message-ID: <09c62752-05ac-49b0-a7de-21f3d89f3f93@default>
> Content-Type: text/plain; charset=us-ascii
>
> Hi,
>
>
>
> Please review the fix:
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8172856
>
> Webrev.00: http://cr.openjdk.java.net/~
> arapte/fx/8172856/webrev.00/
>
> Webrev.01: http://cr.openjdk.java.net/~
> arapte/fx/8172856/webrev.01/
>
>
>
> More description about the 2 fixes is mentioned at bug.
>
>
>
>
>
> Regards,
>
> Ambarish
>
>
>
>
> --
>
> Message: 2
> Date: Thu, 12 Oct 2017 09:32:28 -0400
> From: Scott Palmer 
> To: OpenJFX Mailing List 
> Subject: Multiselection in a TreeView
> Message-ID: <483b679b-24f0-4859-b43e-9d7fc112a...@gmail.com>
> Content-Type: text/plain;   charset=utf-8
>
> Try it.  It has a lot of issues.
> - SelectedItems ListChangeListener misses ?Remove? notifications
> - IndexOutOfBoundsExceptions
> - Selection of item by clicking on the collapse-node widget
>
> See https://bugs.openjdk.java.net/browse/JDK-8189228
>
> Scott
>
> --
>
> Message: 3
> Date: Thu, 12 Oct 2017 07:10:40 -0700
> From: Kevin Rushforth 
> To: regist...@openjdk.java.net, Prasanta Sadhukhan
> , "openjfx-dev@openjdk.java.net"
> 
> Subject: Result: New OpenJFX Committer: Prasanta Sadhukhan
> Message-ID: <59df77e0.10...@oracle.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Voting for Prasanta Sadhukhan [1] to OpenJFX Committer [2] is now closed.
>
> Yes: 8
> Veto: 0
> Abstain: 0
>
> According to the Bylaws definition of Lazy Consensus, this is sufficient
> to approve the nomination.
>
> -- Kevin
>
> [1] http://openjdk.java.net/census#psadhukhan
> [2]
> http://mail.openjdk.java.net/pipermail/openjfx-dev/2017-
> September/020850.html
>
>
>
> --
>
> Message: 4
> Date: Thu, 12 Oct 2017 12:44:42 -0700
> From: Sergey Bylokhov 
> To: Kevin Rushforth , Alexander Zvegintsev
> 
> Cc: "awt-...@openjdk.java.net" ,
> "openjfx-dev@openjdk.java.net" 
> Subject: Re: [10] Review request for 8185634, 8185634: Java Fx-Swing
> dialogs appearing behind main stage
> Message-ID: <8013fec4-ca01-7701-bc15-2fce01f88...@oracle.com>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> Looks fine.
> I am not sure but it looks like the fix has an assumption that the
> CPlatformWindow.setVisible() code will be executed on EDT/Appkit but it
> is not the case. This code can be executed on any thread(intentionally
> for crash), and it will be good to check that it works as expected by
> some stress test which will try to force the possible crash: 4 threads:
>   - show/dispose Swing Node
>   - show/dispose Dialog1/2/3 using different timeouts
>
> Will the current fix cover the native dialogs like
> FileDialog/PrintDialog on linux and windows?
>
> On 

Re: WebView and WebGL

[Nir Lisker]

I don't want to hijack the WebGL discussion but since it rolled into the 3D
library territory anyway I'll give my 2 cents.

3D enhancement are indeed not planned for Java10 (at the minimum) and
indeed you can't bring your own shader (asked already at
https://stackoverflow.com/questions/43622856/can-we-implement-our-own-materials-in-javafx),
but I agree with Mike - you can, maybe somewhat surprisingly, do quite a
lot with what there is.

Perhaps the most limiting feature is not supporting industry standards of
3D modeling via converters (import/export). It has been suggested (
https://bugs.openjdk.java.net/browse/JDK-8091851) but last activity was 5
years ago. As for shaders (materials), lightings etc., from what I remember
by looking around in the source, it will take some effort to rewrite the
API to be able to accept custom ones but it's far from impossible. If Phong
is implemented there's little reason reason others won't fit (maybe
reflective surfaces don't work). Similarly a directional light can be based
on the implemented point light be using a cone instead of a sphere.

We've employed some clever tricks to get adequate "advanced features"
results and considering that all of it can be single-handedly run on iOS
and Android with Gluon Mobile (specifically JavaFXPorts) I think there *is*
a future in this direction and I'm willing to team up with whomever is
interested provided we can get minimal support from the Oracle team.

Re: Innovation (Was: WebView and WebGL)

[Nir Lisker]

I don't mind giving it a go but I wouldn't like doing the work and then it
not getting implemented (if the result is a success).

Personally, I think that the first thing we should do is make a list of
what exactly it is we are trying to do if only to get a sense of the
magnitude and be sure we have enough of the right people to finish it. Then
we would, in all probability, need to write a JEP (
http://openjdk.java.net/jeps/1) which also means we will need a project
lead. Then follow the JEP road and hope for the best I guess.

On Sun, Sep 10, 2017 at 11:29 PM, John-Val Rose <johnvalr...@gmail.com>
wrote:

> Nir,
>
> You're not "hijacking" anything - I think it's been established that this
> a broader "3D API support" issue. In fact, even broader than that.
>
> I'm only new on the JavaFX "scene" but I've looked through the history and
> tried to analyse the present and anticipate the future.
>
> It seems that there are 2 main groups of JavaFX users: one that takes it
> as it is and makes the most of it, sometimes in stunning and amazing ways
> but they don't seem to like to rock the boat or try to force the
> improvement of JavaFX itself so much.
>
> Then there's the others who get frustrated, ask for change, offer to
> enable change or put on their boots and make change. A lot of them seem to
> get "burned".
>
> We need people from both camps: one to showcase what can be done with what
> we have in surprising ways and the others to drive innovation.
>
> I'm clearly in the 2nd group and I'm finding that there are quite a few of
> us. I'm not so afraid of "getting burned" as we all take risks in life and
> if you are passionate about something, you just go with it.
>
> But, the most disappointing aspect is that Oracle staff are often "M.I.A."
> when discussing innovation and the future feature plans. As in this thread,
> Oracle haven't exactly been chiming-in (and yes, I know a lot of it has
> occurred outside of normal working hours).
>
> So Nir, Laurent (and the many others who are putting their hands up),
> perhaps we should collaborate and not just "casually". OpenJFX is, after
> all, "open" so perhaps a more formally coordinated team of motivated
> community members can pool our resources and skills and "Just do it" (with
> or without Oracle's help).
>
> I like what you are suggesting and what Sverre is requesting and what
> numerous others are wanting, and I for one *want* them to become realities.
>
> Quite frankly, I don't see these changes and innovations (especially)
> actually being realised any other way.
>
> Comments?
>
> Graciously,
>
> John-Val Rose
> Chief Scientist/Architect
> Rosethorn Technology
>
> > On 10 Sep 2017, at 23:13, Nir Lisker <nlis...@gmail.com> wrote:
> >
> > I don't want to hijack the WebGL discussion but since it rolled into the
> 3D
> > library territory anyway I'll give my 2 cents.
> >
> > 3D enhancement are indeed not planned for Java10 (at the minimum) and
> > indeed you can't bring your own shader (asked already at
> > https://stackoverflow.com/questions/43622856/can-we-
> implement-our-own-materials-in-javafx),
> > but I agree with Mike - you can, maybe somewhat surprisingly, do quite a
> > lot with what there is.
> >
> > Perhaps the most limiting feature is not supporting industry standards of
> > 3D modeling via converters (import/export). It has been suggested (
> > https://bugs.openjdk.java.net/browse/JDK-8091851) but last activity was
> 5
> > years ago. As for shaders (materials), lightings etc., from what I
> remember
> > by looking around in the source, it will take some effort to rewrite the
> > API to be able to accept custom ones but it's far from impossible. If
> Phong
> > is implemented there's little reason reason others won't fit (maybe
> > reflective surfaces don't work). Similarly a directional light can be
> based
> > on the implemented point light be using a cone instead of a sphere.
> >
> > We've employed some clever tricks to get adequate "advanced features"
> > results and considering that all of it can be single-handedly run on iOS
> > and Android with Gluon Mobile (specifically JavaFXPorts) I think there
> *is*
> > a future in this direction and I'm willing to team up with whomever is
> > interested provided we can get minimal support from the Oracle team.
>

Re: WebView and WebGL

[Nir Lisker]

It has been suggested already in
https://bugs.openjdk.java.net/browse/JDK-8091035.

Re: openjfx-dev Digest, Vol 73, Issue 20

[Nir Lisker]

John,

As as I said in the past I'm all for it. Just didn't see anything going on.
My personal preference is in the area of the 3D API. Iv'e already built on
top of it for my own use and I (personally) think that some of what Iv'e
done could be useful for the API. I also looked into the Prism HLSL code
(I'm not a HLSL dev) with the plan of adding more shaders. Not simple.

It still looks to me like JEPs are the best option. Currently I'm waiting
for the updated instructions for building OpenJFX as I rather spend 1 day
later than 4 now.

You can contact me privately if you want.

Nir

On Wed, Dec 13, 2017 at 10:53 AM, 
wrote:

>
> Message: 2
> Date: Wed, 13 Dec 2017 13:28:43 +1100
> From: John-Val Rose 
> To: Philip Race 
> Cc: "openjfx-dev@openjdk.java.net Mailing"
> 
> Subject: Re: Innovation again (was Re: Text classes)
> Message-ID:
>  gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> I posted this over a week ago:
>
> > I am willing to work with *anyone* (within Oracle or not) on the features
> that the community craves,
> > such as those I listed (and any others). Not just because ?many hands
> make light work? but because
> > I don?t know everything (or even close) and I need the knowledge and
> skills of others to assist me. Not
> > to mention that I have only 24 hours in a day like everyone else and,
> also like everyone else, some of
> > that time has to be devoted to earning an income.
> >
> > So, if there?s anyone reading this who has the time, the skills, the
> commitment and the passion to work hard (in your own time) to get these
> tasks done then please contact me privately.
>
> To my significant disappointment, only one person has contacted me since
> then in relation to this proposal.
>
> I'm beginning to think that I am completely out of touch with the JavaFX
> community, what they actually want and also with exactly *what* JavaFX is
> or is meant to be.
>
> I have reached out on this list and via Twitter in the hope that an
> inspired and passionate group of developers could come together, pool their
> resources and collaborate on taking JavaFX as far is it can possibly go as
> a fully-fledged hardware-accelerated graphics toolkit for the JVM.
>
> But... it seem that my "vision" for JavaFX is unique to me and I have to
> say that I really don't understand why that is.
>
> Is it that the JavaFX community see it as merely a Swing replacement or
> "upgrade" and that there just aren't people out there who want to do more
> sophisticated things with a Java-based toolkit or at least see performance
> increase dramatically?
>
> Or, do people feel that the kind of features you can find in say Qt cannot
> be added to JavaFX because it's a "Java thing": well all know how slow Java
> is and that if you want to do real animations, visualisations etc. then you
> have to use C++?
>
> Well, it's not the 1990s anymore.  Java is NOT the problem.
>
> So, what IS the problem?
>
> I have to say that as chief architect for my company, if the JavaFX
> community (and I include Oracle as a big part of that) simply don't want to
> see innovation in JavaFX, won't support or contribute to making it happen
> or feel they don't need it, causing JavaFX to lag further and further
> behind other graphic toolkits and never be capable of supporting such
> features as advanced animations, visualisations, games, 3D, VR, AR and have
> proper HTML5 support etc. then, despite being a huge Java fan and advocate,
> JavaFX simply can't even be on the table of technologies to choose from
> when I'm developing a technological strategy.
>
> So, I'd like to ask this multi-part question in the hope that as many
> people reply as possible:
>
> *** For *your* siutation, what is JavaFX, how do you want it to evolve and
> what does it mean to you? ***
>
> Maybe I really am "Robinson Crusoe"...
>
> ??
> Graciously,
>
> John-Val Rose
> Chief Scientist/Architect
> Rosethorn Technology
>
>
> On 6 December 2017 at 17:16, John-Val Rose  wrote:
>
> > Absolutely - there needs to be a viable community that is not just
> Oracle.
> >
> > So, is there one? If not, how do we build one?
> >
> > OK, so let me rephrase my earlier email:
> >
> > I am willing to work with *anyone* (within Oracle or not) on the features
> > that the community craves, such as those I listed (and any others). Not
> > just because ?many hands make light work? but because I don?t know
> > everything (or even close) and I need the knowledge and skills of others
> to
> > assist me. Not to mention that I have only 24 hours in a day like
> everyone
> > else and, also like everyone else, some of that time has to be devoted to
> > earning an income.
> >
> > So, if there?s anyone reading this who has the time, the skills, the
> > commitment and the passion to work 

Re: javadoc changes [was: openjfx-dev Digest, Vol 73, Issue 25]

[Nir Lisker]

Sorry about the subject line, I believe the gmail web client is not very
suitable for mailing lists. If anyone has suggestions about it please let
me know (privately or publicly).

The schedule is fine for me, 2-3 weeks should be more than enough.

I have 2 sets of changes in mind. One is corrections like the various "Fix
typos in FX API docs" issues which I want to get into 10. Honestly, I want
to use these as practice for submitting patches as not much can go wrong
and they can be evaluated quickly (without tests, backwards comp. issues
etc.). I have the list in a "non-human readable format" so I would need to
re-write it if you want me to send it somewhere. The second set is
expansion on current docs which I find lacking (comparing to Swing/AWT) and
that is more extensive, so I would think to get it into 11 (or if a timely
interim version suddenly appears then maybe that). Should I formulate a
full proposal on the second set?

Nir

On Fri, Dec 15, 2017 at 11:39 PM, Kevin Rushforth <
kevin.rushfo...@oracle.com> wrote:

> [fixed subject line]
>
> The freeze for the last planned integration prior to RDP2 will be on
> 1/15/2018 (end of the day Pacific time), so this is the deadline. RDP2
> starts on 1/18/2018. See the jdk10 project page [1] for all JDK 10 dates.
>
> I hope to fix at least a first pass of the build instructions to get rid
> of obsolete or incorrect instructions, and get something usable for each
> platform next week (before the Christmas holiday in the US).
>
> As for javadoc changes, are these simple changes to the text that you will
> propose? If so, it might be something we could add to JDK-8188314 (Fix
> typos in FX API docs) or maybe a follow-on, in which case you could just
> send diffs or email comments to attach to the JBS issue. Or is it something
> else you had in mind? Anything much beyond simple javadoc fixes should
> probably wait for the next release, but that still leaves a fair bit of
> room for improvements to the docs that can still go into 10 if you are of a
> mind to to do it.
>
> -- Kevin
>
> [1] http://openjdk.java.net/projects/jdk/10/
>
> [2] https://bugs.openjdk.java.net/browse/JDK-8188314
>
>
> Nir Lisker wrote:
>
>> Kevin,
>>
>> I wouldn't mind pushing javadoc changes into 10, but don't have OpenJFX
>> built yet as I'm waiting for updated instructions on that. Can you tell
>> when is RDP1 ending and when is it planned to update the build instructions
>> so I'll know what my time window is?
>>
>> Thanks,
>> Nir
>>
>>
>

Re: openjfx-dev Digest, Vol 73, Issue 25

[Nir Lisker]

Kevin,

I wouldn't mind pushing javadoc changes into 10, but don't have OpenJFX
built yet as I'm waiting for updated instructions on that. Can you tell
when is RDP1 ending and when is it planned to update the build instructions
so I'll know what my time window is?

Thanks,
Nir

On Fri, Dec 15, 2017 at 8:59 PM, 
wrote:

> Send openjfx-dev mailing list submissions to
> openjfx-dev@openjdk.java.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://mail.openjdk.java.net/mailman/listinfo/openjfx-dev
> or, via email, send a message with subject or body 'help' to
> openjfx-dev-requ...@openjdk.java.net
>
> You can reach the person managing the list at
> openjfx-dev-ow...@openjdk.java.net
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of openjfx-dev digest..."
>
>
> Today's Topics:
>
>1. Re: Innovation again (was Re: Text classes) (Michael Paus)
>2.  (Tamer KARAKAN)
>3. Re: Innovation ?essay? (John-Val Rose)
>4. PLEASE READ: JDK10 RDP1 process for JavaFX (Kevin Rushforth)
>
>
> --
>
> Message: 1
> Date: Fri, 15 Dec 2017 14:42:33 +0100
> From: Michael Paus 
> To: openjfx-dev@openjdk.java.net
> Subject: Re: Innovation again (was Re: Text classes)
> Message-ID: 
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> Hi,
> first of all I would like to say that I fully agree with everything that
> has been
> said so far in this thread and I am glad that someone is pushing this long
> overdue discussion. Please find my comments inline.
>
> Am 15.12.17 um 10:09 schrieb John-Val Rose:
> > [...]
> >
> > This initiative/team/group should not be "hidden" either - it should be
> > completely transparent and open to enable anyone to follow the thought
> > processes, the progress and the results and also to comment,
> constructively
> > criticise, make suggestions and even make small contributions. This team
> is
> > not operating in competition with Oracle - quite the opposite in fact.
> > It's there to complement the already great efforts of the Oracle JavaFX
> > team.
> >
> > I am familiar with "The Java EE Guardians" and while I am not proposing
> > that we do something with exactly the same model, their results speak for
> > themselves.  I am open to suggestions and ideas about how such a
> group/team
> > should be structured and the governance and actually hope that as many
> > people as possible chime-in with their own "2 cents".
> >
> > I'm just offering to be the central contact point for now and then the
> > consensus can determine how we proceed.
> A lot has already been discussed on this list and elsewhere but my
> impression
> is that all these ideas are forgotten faster than they are written up
> because
> there is no place to collect them and no person to organize and
> administer such
> a place. If such a place existed I would be more than happy to share my
> ideas
> with others.
> > Yes, Chris is absolutely spot-on about the build issues.  For the broader
> > community to be able to contribute or be motivated to contribute, the
> > process must be as simple as possible and first-things-first, we have to
> be
> > able to reliably build OpenJFX on all supported platforms.  No developer
> > wants to waste time with build issues; they just want to code.  I would
> > suggest that this is something Oracle prioritise ahead of perhaps
> > everything else with OpenJFX 9/10 (and that anyone who has advanced
> > knowledge of the tools or the DevOps pipeline try to help as well).
> Yes, I see this as a big stumbling stone as well. I would like to add
> that it would
> also be necessary to advertise the use of such builds and to harmonize the
> handling of version numbers of such builds. I currently have a lot of
> problems
> using my own builds as well as the EA builds from Oracle with the existing
> build tools and IDEs. Many of them get a hick-up if they encounter build
> versions
> beyond the current/official versions.
> >
> > As you can see, Chris has basically given us his feature/fix "wish list"
> > and I have received the wish lists of many others and, of course, I have
> my
> > own.
> >
> > One thing that I have often referred to is the *competitors* of JavaFX
> > (like Qt and Xamarin) and how we are lagging behind them and that the
> "gap"
> > is growing.  But one could argue that from another perspective, JavaFX is
> > actually itself its only real competitor being the official Java GUI
> > toolkit (having supplanted Swing).  I like this idea because we all know
> > there are about 11 million Java developers in the world and I am sure
> most
> > agree that Java (or the JVM) should have a first-class graphics toolkit
> so
> > all of us who love Java and who eat, breathe & live Java don't have to
> > "turn to the dark side" and 

TabPane bug: removing and adding a tab

[Nir Lisker]

Looks like there's a bug with TabPane which happens when a tab is removed
and quickly added back, before the layout is updated. This causes incorrect
positioning of the headers. It was posted on SO: https://stackoverflow.com/
questions/47616221/javafx-tabpane-tabs-dont-update-position/ and apparently
happens on 8, but not on 9.

Nir

Re: Paint Phase Debugging / Performance

[Nir Lisker]

Hi,

I'm having a performance issue myself. I'm using animations on 3D models
(in a 3D subscene) and when there are "too many" models the QuantumRenderer
thread is running 100% of the time and utilizing 20-25% of the CPU, though
the OS reports that overall all cores are at ~40%. The application is using
the d3d pipeline.

A typical pulse is

PULSE: 4078 [112ms:225ms]
T15 (11 +0ms): CSS Pass
T15 (11 +0ms): Layout Pass
T15 (12 +0ms): Update bounds
T15 (12 +95ms): Waiting for previous rendering
T15 (108 +0ms): Copy state to render graph
T12 (109 +115ms): Painting
T12 (224 +0ms): Presenting
Counters:
Nodes rendered: 651
Nodes visited during render: 651

Thread dumps show that QuantumRenderer is busy with tasks inside

at
com.sun.prism.impl.BaseMesh.buildPTGeometry(javafx.graphics@10-internal
/BaseMesh.java:584)
at
com.sun.prism.impl.BaseMesh.buildGeometry(javafx.graphics@10-internal
/BaseMesh.java:516)
at
com.sun.javafx.sg.prism.NGTriangleMesh.validate(javafx.graphics@10-internal
/NGTriangleMesh.java:75)
at
com.sun.javafx.sg.prism.NGShape3D.renderMeshView(javafx.graphics@10-internal
/NGShape3D.java:84)
at
com.sun.javafx.sg.prism.NGShape3D.renderContent(javafx.graphics@10-internal
/NGShape3D.java:201)
at
com.sun.javafx.sg.prism.NGNode.doRender(javafx.graphics@10-internal
/NGNode.java:2072)
at com.sun.javafx.sg.prism.NGNode.render(javafx.graphics@10-internal
/NGNode.java:1964)
at
com.sun.javafx.sg.prism.NGGroup.renderContent(javafx.graphics@10-internal
/NGGroup.java:270)
at
com.sun.javafx.sg.prism.NGNode.doRender(javafx.graphics@10-internal
/NGNode.java:2072)
at com.sun.javafx.sg.prism.NGNode.render(javafx.graphics@10-internal
/NGNode.java:1964)
at
com.sun.javafx.sg.prism.NGGroup.renderContent(javafx.graphics@10-internal
/NGGroup.java:270)
at
com.sun.javafx.sg.prism.NGNode.doRender(javafx.graphics@10-internal
/NGNode.java:2072)
at com.sun.javafx.sg.prism.NGNode.render(javafx.graphics@10-internal
/NGNode.java:1964)
at
com.sun.javafx.sg.prism.NGGroup.renderContent(javafx.graphics@10-internal
/NGGroup.java:270)
at
com.sun.javafx.sg.prism.NGNode.renderCached(javafx.graphics@10-internal
/NGNode.java:2379)
at
com.sun.javafx.sg.prism.NGNode.doRender(javafx.graphics@10-internal
/NGNode.java:2063)
at com.sun.javafx.sg.prism.NGNode.render(javafx.graphics@10-internal
/NGNode.java:1964)
at
com.sun.javafx.sg.prism.NGGroup.renderContent(javafx.graphics@10-internal
/NGGroup.java:270)
at
com.sun.javafx.sg.prism.NGNode.doRender(javafx.graphics@10-internal
/NGNode.java:2072)
at com.sun.javafx.sg.prism.NGNode.render(javafx.graphics@10-internal
/NGNode.java:1964)
at
com.sun.javafx.tk.quantum.ViewPainter.doPaint(javafx.graphics@10-internal
/ViewPainter.java:479)
at
com.sun.javafx.tk.quantum.ViewPainter.paintImpl(javafx.graphics@10-internal
/ViewPainter.java:328)
at
com.sun.javafx.tk.quantum.PresentingPainter.run(javafx.graphics@10-internal
/PresentingPainter.java:91)
at
java.util.concurrent.Executors$RunnableAdapter.call(java.base@10-internal
/Executors.java:514)
at java.util.concurrent.FutureTask.runAndReset(java.base@10-internal
/FutureTask.java:305)
at com.sun.javafx.tk.RenderJob.run(javafx.graphics@10-internal
/RenderJob.java:58)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(java.base@10-internal
/ThreadPoolExecutor.java:1135)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base@10-internal
/ThreadPoolExecutor.java:635)
at
com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(javafx.graphics@10-internal
/QuantumRenderer.java:125)
at java.lang.Thread.run(java.base@10-internal/Thread.java:844)

Does anyone have an idea on how to continue?

Thanks,
Nir


On Fri, May 4, 2018 at 10:30 AM, Matthew Elliot <
matthew.james.ell...@gmail.com> wrote:

> Hi Pedro,
>
> The first link I have read through many times, it is very useful for ideas
> but doesn't really flesh out or go into much detail on each topic. It also
> comments a few times on the problems we've encountered, 'what costs what'
> is difficult to understand / measure.
>
> The second link I hadn't found my way to and is definitely interesting to
> understand more about how things are working internally - thanks.
>
> Regards,
> Matt
>
>
> On 3 May 2018 at 19:17, Pedro Duque Vieira 
> wrote:
>
> > Hi Matthew,
> >
> > On the topic of documents with indications for improving performance.
> >
> > Don't know if you already found it, but there is a draft here (to which
> > I've made a small contribution):
> > https://wiki.openjdk.java.net/display/OpenJFX/Performance+
> Tips+and+Tricks
> >
> > A bit old though...
> >
> > And here:
> >
> > https://wiki.openjdk.java.net/display/OpenJFX/Performance+Ideas
> >
> >
> > --
> > Pedro Duque Vieira
> >
>

Re: Announcing EA builds of standalone JavaFX SDK

[Nir Lisker]

Thanks Kevin, that's good to hear.

Michael, adding the external jars as single entries is the simplest and
most granular way, but you can also define a library from those jars and
then add that single library to any project:

1. Add Library...
2. User Library
3. User Libraries...
4. New... (give it a name)
5. Add External JARs... (add all the jars)
6. OK/Apply everything.

This creates a single entry in the .classpath:



This should be the parallel to specifying a single folder from the command
line.

As for the runtime issue, is it finding the other modules?

- Nir

On Tue, May 8, 2018 at 3:39 PM, Michael Paus  wrote:

> Am 08.05.18 um 14:27 schrieb Tom Schindl:
>
> [...]
>>
>> 3. How do you properly configure an Eclipse (the latest 4.7.3a) project
>>> to use this module path. Adding the OpenJDK was no problem but how do
>>> you add the module path for JavaFX? I failed on that.
>>>
>>> You just open the Java Build Path-Properties-Page on the project and add
>> the external jars, not?
>>
>> Tom
>>
>
> That's one of the ways I tried it but ...
>
> 1. is that the intended way of doing it? On the command line you just
> specify a single folder.
>
> 2. I did this and it resolved all dependencies at compile time but I got
> an exception at runtime
>
> Error occurred during initialization of boot layer
> java.lang.module.FindException: Module javafx.fxml not found
>
> although I also added
>
> --add-modules=javafx.fxml,javafx.controls,javafx.web,javafx.media
>
> as VM arguments.
>
>

Re: Paint Phase Debugging / Performance

[Nir Lisker]

Hi Matthew,

This is a typical pulse, which indeed cases the effect of low FPS, and
that's what I'm trying to solve.

* Cache hints are ignored for 3D (but I tried anyway).
* -Dprism.showdirty and printrendergraph also don't work for 3D scenes
(though I can get an approximation with a 2D scene).
* There are no effects.

I'm working with Mission Control already, most of the instances in the GC
class histogram are related to animation
classes: InterpolationInterval$TangentDoubleInterpolationInterval
and NumberTangentInterpolator.

Looks like all all the discussed difficulties with diagnostics are enhanced
when it comes to 3D. Will have to dig deep on this one.

Thanks,
Nir

On Mon, May 7, 2018 at 9:07 PM, Matthew Elliot <
matthew.james.ell...@gmail.com> wrote:

> Hey Nir,
>
> I’m not sure if I can offer much support as I haven’t been into the 3D
> world but just to clarify, is it one pulse after another with long wait,
> paint phases? From what I’ve seen personally if you have painting of 100+
> milliseconds on every pulse you will be in big trouble / laggy as.
>
> On a one-off pulse like building a scene the first time I would say it is
> fine but regular paints that are longer are going to cause issues from my
> experience.
>
> Did you try profiling with mission controller to look at what garbage is
> being created / what hot methods there? Maybe it points you in a better
> direction / at least rule out your own code.
>
> With animations I guess you set cache hints already?
>
> Make sure you don’t have any effects on the animation as well, a Gaussian
> blur blend/drop shadow on an animation killed it for me.
> You can also try -Dprism.disableEffects= true to rule it out.
> You can also enable the prism option to show what is being painted on each
> pulse as an overlay. -Dprism.showdirty and there is another I forget to
> show how many times it was painted. (Not that your whole scene is painted
> when you expect a small part of it)
>
> Or some trial and error with the prism flags here to try narrow it down -
> Just open PrismSettings.java in your IDE or web browser.
>
> Code explains them better than most posts I’ve seen.
>
> Good luck.
> Matt
>
> Sent from my phone.
>
> On 7/05/2018, at 2:36 PM, Nir Lisker <nlis...@gmail.com> wrote:
>
> Hi,
>
> I'm having a performance issue myself. I'm using animations on 3D models
> (in a 3D subscene) and when there are "too many" models the QuantumRenderer
> thread is running 100% of the time and utilizing 20-25% of the CPU, though
> the OS reports that overall all cores are at ~40%. The application is using
> the d3d pipeline.
>
> A typical pulse is
>
> PULSE: 4078 [112ms:225ms]
> T15 (11 +0ms): CSS Pass
> T15 (11 +0ms): Layout Pass
> T15 (12 +0ms): Update bounds
> T15 (12 +95ms): Waiting for previous rendering
> T15 (108 +0ms): Copy state to render graph
> T12 (109 +115ms): Painting
> T12 (224 +0ms): Presenting
> Counters:
> Nodes rendered: 651
> Nodes visited during render: 651
>
> Thread dumps show that QuantumRenderer is busy with tasks inside
>
> at com.sun.prism.impl.BaseMesh.buildPTGeometry(javafx.
> graphics@10-internal/BaseMesh.java:584)
> at com.sun.prism.impl.BaseMesh.buildGeometry(javafx.graphics@
> 10-internal/BaseMesh.java:516)
> at com.sun.javafx.sg.prism.NGTriangleMesh.validate(
> javafx.graphics@10-internal/NGTriangleMesh.java:75)
> at com.sun.javafx.sg.prism.NGShape3D.renderMeshView(
> javafx.graphics@10-internal/NGShape3D.java:84)
> at com.sun.javafx.sg.prism.NGShape3D.renderContent(
> javafx.graphics@10-internal/NGShape3D.java:201)
> at com.sun.javafx.sg.prism.NGNode.doRender(javafx.
> graphics@10-internal/NGNode.java:2072)
> at com.sun.javafx.sg.prism.NGNode.render(javafx.graphics@
> 10-internal/NGNode.java:1964)
> at com.sun.javafx.sg.prism.NGGroup.renderContent(javafx.
> graphics@10-internal/NGGroup.java:270)
> at com.sun.javafx.sg.prism.NGNode.doRender(javafx.
> graphics@10-internal/NGNode.java:2072)
> at com.sun.javafx.sg.prism.NGNode.render(javafx.graphics@
> 10-internal/NGNode.java:1964)
> at com.sun.javafx.sg.prism.NGGroup.renderContent(javafx.
> graphics@10-internal/NGGroup.java:270)
> at com.sun.javafx.sg.prism.NGNode.doRender(javafx.
> graphics@10-internal/NGNode.java:2072)
> at com.sun.javafx.sg.prism.NGNode.render(javafx.graphics@
> 10-internal/NGNode.java:1964)
> at com.sun.javafx.sg.prism.NGGroup.renderContent(javafx.
> graphics@10-internal/NGGroup.java:270)
> at com.sun.javafx.sg.prism.NGNode.renderCached(javafx.
> graphics@10-internal/NGNode.java:2379)
> at com.sun.javafx.sg.prism.NGNode.doRender(javafx.
>

JDK-8195974: Replace use of java.util.logging in javafx with System logger

[Nir Lisker]

Hi Murali,

Can you have a look at https://bugs.openjdk.java.net/browse/JDK-8195974
please?

There are some usages of j.u.l in the web module I'd like your opinion on.
I'm not familiar with the intent of these pieces of code and would like to
know what the options are for advancing with this issue on that front.

Thanks,
Nir

Re: [11] RFR JDK-8202199 : Provide public, unsupported API for FX Swing interop

[Nir Lisker]

Hi Prasanta,

If @override is not added, then it will cause recursion between
> LightweightContent.java:130 and LightweightContent.java:187


I don't understand how the existence or lack thereof of an @Override can
cause or prevent recursion (bar reflection). Since all the methods of the
interface are overriden in SwingNode (regardless of the annotation) their
default implementation is not used, and SwingNode is recursion-free.
What is more worrisome is that if the interface methods are not overriden
in some other implementing class, there will be infinite recursion, but
this a fault in the design of the interface (I'd say), and out of scope for
this issue. On the up side, one of the methods in the interface is
deprecated, so it didn't go completely under the radar.

Personally, I force the use of @Override where applicable since it can only
help and I only brought this up since you uncommented 1 of the annotations
and left 2 others.

Thanks,
Nir

On Sat, May 5, 2018 at 6:20 PM, Prasanta Sadhukhan <
prasanta.sadhuk...@oracle.com> wrote:

> Updated webrev to modify java.desktop module-info.java (only difference
> between webrev7 and this) to remove the duplicate exports of sun.awt so we
> will have now
>
> exports sun.awt to
> jdk.accessibility,
> jdk.unsupported.desktop;
>
> http://cr.openjdk.java.net/~psadhukhan/fxswing.8/
>
> Regards
> Prasanta
>
> On 5/5/2018 2:28 PM, Prasanta Sadhukhan wrote:
>
>> Hi All,
>>
>> I have tried to address all comments from Nir, Phil, Mandy and Kevin got
>> so far in this webrev
>> http://cr.openjdk.java.net/~psadhukhan/fxswing.7
>>
>> >>In SwingNode, lines 870 -883, is there a reason that only the first
>> method uncommented @Override? I don't understand the comment that wants to
>> skip @Override.
>> If @override is not added, then it will cause recursion between
>> LightweightContent.java:130 and LightweightContent.java:187 thereby causing
>> StackOverflowError. I am also not sure about the comment of skipping
>> @Override but I have removed it from this webrev.
>>
>> Regards
>> Prasanta
>> On 5/5/2018 4:32 AM, Kevin Rushforth wrote:
>>
>>> My quick comments:
>>>
>>> 1. The changes to java.desktop module-info.java won't compile when
>>> applied to jdk-client, since there is already a qualified export of the
>>> sun.swing package to another internal class. Can you update your patch to
>>> be based off of jdk-client? I note that it requires a small patch to be
>>> able to build FX with JDK 11 (it's a known gradle issue), but it's not hard
>>> to do.
>>>
>>> 2. As I mentioned in an off-line email, the final version of the
>>> javafx.swing patch will need to use 'requires static
>>> jdk.unsupported.desktop' in its module-info.java, so that it will still run
>>> on JDK 10 EA. This means that you will need to ensure that
>>> jdk.unsupported.desktop is loaded via a service loader as discussed. This
>>> will not affect the public API at all, so that can proceed in parallel, but
>>> this needs to be fixed.
>>>
>>> 3. As I mentioned in my earlier reply to Mandy's comment, Swing interop
>>> apps will fail if a security manager is installed, because the
>>> jdk.unsupported.desktop classes are loaded by the app class loader. This
>>> can be sorted out later as a follow-on bug, with permissions added to the
>>> default policy file, etc.
>>>
>>> 4. As Phil mentioned, some docs would be good. They don't need to be all
>>> that detailed, since it isn't intended for use by applications, and will
>>> not be included in the published API docs bundle (i.e., it should be
>>> excluded from "make docs").
>>>
>>> I will do a more detailed review early next week.
>>>
>>> -- Kevin
>>>
>>> On 5/4/2018 1:53 PM, Phil Race wrote:
>>>
 Two quick comments.

 1) I'd like "Peer" removed from all the exported API.
 2) It is probably stable enough now that you can start to add some
 javadoc.

 -phil.

 On 05/04/2018 05:00 AM, Prasanta Sadhukhan wrote:

> Hi All,
>
> Please review an enhancement to remove the tight coupling of JDK
> internal class from FX so that
> when javafx.* modules are removed from Openjdk build in jdk11, FX in
> general, and fx swing interop, in particular, can still build and 
> function.
>
> Right now, FX uses 6 jdk internal packages
> sun.swing, sun.awt, java.awt.dnd.peer, sun.awt.dnd, sun.awt.image and
> sun.java2d.
>
> However, the goal is not to use qualified exports of these internal
> packages once FX is removed to be built along with JDK,
>
> The solution will define a new "jdk.unsupported.desktop" module that
> exports public API
> that is intended to be used by the javafx.swing module (but it does so
> with public exports and not qualified exports).
> The idea is the same as jdk.unsupported, in that it is documented as
> being unsupported.
> Further, since it is only intended to be used by javafx.swing, it need
> not be in the 

Re: [11] RFR JDK-8202199 : Provide public, unsupported API for FX Swing interop

[Nir Lisker]

Hi Prasanta,

In SwingNode, lines 870 -883, is there a reason that only the first method
uncommented @Override? I don't understand the comment that wants to skip
@Override.

Some minor code comments:

* LightweightFrameWrapper#isCompEqual: you can skip the 'if' and just
'return c != lwFrame.getLightweightFrame();'.
* Same with SwingInterOpUtils#isUngrabEvent.

* LightweightFrameWrapper#createUngrabEvent: you can directly 'return new
...' (I wouldn't comment about this had you not done this to the other
methods).

* LightweightContentWrapper: there're no new lines between non-empty
methods, especially in LightweightContentProxy. Is this an acceptable code
style?
* Same for DragSourceContextPeerWrapper and the proxy,
DragTargetContextPeerWrapper.
and DispatcherWrapper.

* Extra empty line(s) at the end of DropTargetContextPeerWrapper.

- Nir

On Fri, May 4, 2018 at 3:10 PM, Kevin Rushforth 
wrote:

> Thanks, Prasanta.
>
> As an additional note to reviewers:
>
> The JDK portion of this change (JDK-8202199) is the subject for this
> review.
>
> The FX webrev is enough to be able to test the JDK side, but will need
> additional refactoring (to allow it to continue to build / run with JDK 10)
> before being ready for review. If you spot something of concern in the FX
> webrev, please feel free to bring it up, but don't spend time doing a
> thorough review just yet.
>
> -- Kevin
>
>
>
> On 5/4/2018 5:00 AM, Prasanta Sadhukhan wrote:
>
>> Hi All,
>>
>> Please review an enhancement to remove the tight coupling of JDK internal
>> class from FX so that
>> when javafx.* modules are removed from Openjdk build in jdk11, FX in
>> general, and fx swing interop, in particular, can still build and function.
>>
>> Right now, FX uses 6 jdk internal packages
>> sun.swing, sun.awt, java.awt.dnd.peer, sun.awt.dnd, sun.awt.image and
>> sun.java2d.
>>
>> However, the goal is not to use qualified exports of these internal
>> packages once FX is removed to be built along with JDK,
>>
>> The solution will define a new "jdk.unsupported.desktop" module that
>> exports public API
>> that is intended to be used by the javafx.swing module (but it does so
>> with public exports and not qualified exports).
>> The idea is the same as jdk.unsupported, in that it is documented as
>> being unsupported.
>> Further, since it is only intended to be used by javafx.swing, it need
>> not be in the default module graph.
>>
>> The module-info.java will look like this:
>> |module jdk.unsupported.desktop { requires transitive java.desktop;
>> exports jdk.swing.interop; } |||
>> Enhancement: https://bugs.openjdk.java.net/browse/JDK-8202199,
>> https://bugs.openjdk.java.net/browse/JDK-8195811
>> webrev: cr.openjdk.java.net/~psadhukhan/fxswing.6/
>> CSR: https://bugs.openjdk.java.net/browse/JDK-8202175
>>
>> Regards
>> Prasanta
>> ||
>>
>>
>

Review Request: JDK-8195974: Replace use of java.util.logging in javafx with System logger

[Nir Lisker]

Hi,

Please review the fix approach for:

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

http://cr.openjdk.java.net/~nlisker/8195974/webrev.00/

Many details in the issue.

Thanks,
Nir

Re: Matrox Graphics Cards Problems

[Nir Lisker]

Hi Matthew,

Is there a way to get more details on why JavaFx fails to enable the D3D
> pipeline?


Add the VM argument -Dprism.verbose=true and post what it spits.

- Nir

On Thu, May 17, 2018 at 5:04 PM, Matthew Elliot <
matthew.james.ell...@gmail.com> wrote:

> Hi all,
>
> we have some customers in the wild who use Matrox 9148LP (9100 series)
> graphics cards because they drive more than 2 monitors and JavaFX always
> reports an error initializing HW pipeline and forcing gpu results in system
> instability.
>
> I checked the bug reports but couldn't see anything about JavaFX and Matrox
> cards.
>
> Questions
> Is anyone aware of an existing issue?
> Is there a way to get more details on why JavaFx fails to enable the D3D
> pipeline?
> Is there a list of known problematic graphics cards or a black list of
> graphics cards where JavaFX falls back?
>
> Thanks in advance,
> Matt
>

Re: OpenJFX status update

[Nir Lisker]

What will happen to the JavaDocs? Will they be removed from the EA docs and
upon release from the release docs?

- Nir

On Wed, May 16, 2018 at 12:59 AM, Kevin Rushforth <
kevin.rushfo...@oracle.com> wrote:

> I wanted to update you on the progress of the last couple weeks on the
> OpenJFX project:
>
> 1. As mentioned last week, we now have EA builds of OpenJFX 11 on java.net
> [1]. We intend to update this roughly weekly. Currently the build numbers
> match the corresponding JDK build number, but that will not necessarily be
> the case going forward, so don't assume that they are in sync.
>
> 2. Barring any build or staging issues, this week's OpenJFX 11 EA build
> will include the jmods as mentioned earlier [2] [3]
>
> 3. JavaFX has been removed from JDK 11 as of this week. Starting with
> jdk-11+14, early access builds of JDK 11 will not include JavaFX.
>
> 4. After jdk-11+14 is posted on java.net, and FX is no longer included in
> JDK 11, we will start using openjfx-11 as the fix version in JBS to
> distinguish it from JDK 11. We still expect to do a release of JavaFX 11
> around the same time as JDK 11, but using a different release number will
> help track the actual content of JavaFX 11 separately from JDK 11.
>
> 5. Once this settles down, possibly later this week, I hope to restart the
> discussion about OpenJFX policies, etc. I also hope to be a bit more
> responsive over the coming days / weeks than I have been for the last 3-4
> weeks. Getting the standalone OpenJFX working and removing JavaFX from the
> JDK was quite time consuming as you can probably imagine.
>
> If you have any general comments or questions about any of this, please
> reply to this thread. We may want to split out more detailed discussions
> into their own thread to make it easier to follow.
>
> -- Kevin
>
> [1] http://jdk.java.net/openjfx/
>
> [2] http://mail.openjdk.java.net/pipermail/openjfx-dev/2018-May/
> 021856.html
> [3] https://bugs.openjdk.java.net/browse/JDK-8202368
>
>

Re: [11] Review request: 8203378: JDK build fails to compile javafx.graphics module-info.java if FX was built with OpenJDK

[Nir Lisker]

Since the packager is being removed I don't see a reason to keep any
references to it. In any case, the Eclipse files are planned to be updated
[1] after j.u.l. is removed [2].

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

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

- Nir

On Mon, May 21, 2018 at 8:54 PM, Kevin Rushforth  wrote:

> Phil or Ajit,
>
> Please review the following simple fix:
>
> https://bugs.openjdk.java.net/browse/JDK-8203378
> http://cr.openjdk.java.net/~kcr/8203378/webrev.00/
>
> This removes one qualified export from javafx.graphics to the
> no-longer-built jdk.packager module. More details in JBS.
>
> Note to Eclipse users: This patch modifies the Eclipse files to remove
> references to jdk.packager. I would like a read from the users of Eclipse
> as to whether I should do this or not. I am equally happy to commit or
> revert my changes to these files.
>
> -- Kevin
>
>

Re: [11] Review request: 8203378: JDK build fails to compile javafx.graphics module-info.java if FX was built with OpenJDK

[Nir Lisker]

Fine by me.

- Nir

On Tue, May 22, 2018 at 12:29 AM, Kevin Rushforth <
kevin.rushfo...@oracle.com> wrote:

> In that case, why don't I revert my changes and let you remove the
> references after j.u.l is removed.
>
> -- Kevin
>
>
>
> On 5/21/2018 2:13 PM, Nir Lisker wrote:
>
> Since the packager is being removed I don't see a reason to keep any
> references to it. In any case, the Eclipse files are planned to be updated
> [1] after j.u.l. is removed [2].
>
> [1] http://mail.openjdk.java.net/pipermail/openjfx-dev/
> 2018-April/021740.html
>
> [2] https://bugs.openjdk.java.net/browse/JDK-8195974
>
> - Nir
>
> On Mon, May 21, 2018 at 8:54 PM, Kevin Rushforth <
> kevin.rushfo...@oracle.com> wrote:
>
>> Phil or Ajit,
>>
>> Please review the following simple fix:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8203378
>> http://cr.openjdk.java.net/~kcr/8203378/webrev.00/
>>
>> This removes one qualified export from javafx.graphics to the
>> no-longer-built jdk.packager module. More details in JBS.
>>
>> Note to Eclipse users: This patch modifies the Eclipse files to remove
>> references to jdk.packager. I would like a read from the users of Eclipse
>> as to whether I should do this or not. I am equally happy to commit or
>> revert my changes to these files.
>>
>> -- Kevin
>>
>>
>
>

Re: Review Request: JDK-8195974: Replace use of java.util.logging

[Nir Lisker]

Hi Daniel,

I see that you have changed javafx.base tests to stop using
> java.util.logging for verifying the log messages produced
> by javafx.base classes, and I was wondering whether that
> was really necessary?


This was the most acceptable approach. The reason is that using j.u.l.,
even in tests, causes problems for OpenJFX on Eclipse.

This was brought up a few times before: in a discussion about
Eclipse-specific files [1], in the issue comments [2], and in a discussion
about this issue [3].

I waited with the decision to remove j.u.l. completely until all its uses
were understood and I could determine that they are minor enough for a
replacement to be put in at the benefit of being able to develop OpenJFX on
Eclipse. I'm aware that changing code because an IDE doesn't handle it well
it isn't a good practice, but in this case there were no objections. In the
future, if an irreplaceable need to use j.u.l. arises, we can reevaluate
this point and see if Eclipse has made any changes to remove this conflict
(I'm not sure if they're planning to).

The availability of j.u.l. with respect to System.Logger isn't the issue.

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

[2]
https://bugs.openjdk.java.net/browse/JDK-8195974?focusedCommentId=14176654=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14176654

[3] http://mail.openjdk.java.net/pipermail/openjfx-dev/2018-May/021893.html

Best,
Nir

On Tue, May 22, 2018 at 3:01 PM, Daniel Fuchs 
wrote:

> Hi Nir,
>
> By default, the backend of System.Logger is java.util.logging,
> as long as the java.logging module is present and no
> custom LoggerFinder service has been deployed.
>
> This means that in a usual testing environment, if a library
> emits a log message using the System.Logger API, then a test
> for that library should still be able to observe that message
> using the regular java.util.logging APIs.
> (unless a LoggerFinder service has explicitly been deployed,
> or unless the test runs with a --limit-modules option that
> excludes java.logging).
>
> I see that you have changed javafx.base tests to stop using
> java.util.logging for verifying the log messages produced
> by javafx.base classes, and I was wondering whether that
> was really necessary?
> I mean - this could be necessary if the test was a whitebox
> test deployed by the test infrastructure in the same module
> than the code under test, and was therefore limited to only
> use those modules required by the module-info of that module,
> but if the test class is deployed on the class path / unnamed
> module then the test class  should still be able to
> configure/access java.logging to verify the behaviour
> of the module under test.
>
> best regards,
>
> -- daniel
>
>
> On 20/05/2018 13:00, openjfx-dev-requ...@openjdk.java.net wrote:
>
>> Hi,
>>
>> Please review the fix approach for:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8195974
>>
>> http://cr.openjdk.java.net/~nlisker/8195974/webrev.00/
>>
>> Many details in the issue.
>>
>> Thanks,
>> Nir
>>
>>
>

Re: Review Request: JDK-8195974: Replace use of java.util.logging

[Nir Lisker]

Tom, is there an Eclipse issue about this in Bugzilla? As I mentioned some
time ago, if I add the dependency to the .classpath it should function the
same as adding it to module-info.

On Tue, May 22, 2018 at 5:37 PM, Tom Schindl 
wrote:

> From a pure library developer point-of-view this would mean JavaFX would
> rely on an implementation detail of the JRE it runs (it's JUnit-Tests).
>
> Does this hold true if I run JavaFX on none Oracle VMs, like Eclipse J9
> - not that i plan but well you know ;-)
>
> Tom
>
> On 22.05.18 14:01, Daniel Fuchs wrote:
> > Hi Nir,
> >
> > By default, the backend of System.Logger is java.util.logging,
> > as long as the java.logging module is present and no
> > custom LoggerFinder service has been deployed.
> >
> > This means that in a usual testing environment, if a library
> > emits a log message using the System.Logger API, then a test
> > for that library should still be able to observe that message
> > using the regular java.util.logging APIs.
> > (unless a LoggerFinder service has explicitly been deployed,
> > or unless the test runs with a --limit-modules option that
> > excludes java.logging).
> >
> > I see that you have changed javafx.base tests to stop using
> > java.util.logging for verifying the log messages produced
> > by javafx.base classes, and I was wondering whether that
> > was really necessary?
> > I mean - this could be necessary if the test was a whitebox
> > test deployed by the test infrastructure in the same module
> > than the code under test, and was therefore limited to only
> > use those modules required by the module-info of that module,
> > but if the test class is deployed on the class path / unnamed
> > module then the test class  should still be able to
> > configure/access java.logging to verify the behaviour
> > of the module under test.
> >
> > best regards,
> >
> > -- daniel
> >
> >
> > On 20/05/2018 13:00, openjfx-dev-requ...@openjdk.java.net wrote:
> >> Hi,
> >>
> >> Please review the fix approach for:
> >>
> >> https://bugs.openjdk.java.net/browse/JDK-8195974
> >>
> >> http://cr.openjdk.java.net/~nlisker/8195974/webrev.00/
> >>
> >> Many details in the issue.
> >>
> >> Thanks,
> >> Nir
> >>
> >
>

Re: OpenJFX code review policies, etc.

[Nir Lisker]

Thanks for the detailed plan Kevin,

I will provide an initial list of reviewers to the registrar based on past
> contributions, and also recognizing Committers who have become experts in
> their area.


It will be a good idea to list the reviewers/experts (names and mail)
according to their field, as done in the outdated Wiki [1]. This way
contributors know who to address in a review request mail. Currently, I
need to filter a subcomponent in JIRA and see who provides the fixes there
to know who to ask.

B. We need to set formal guidelines for becoming a Reviewer. The JDK uses a
> threshold of 32 significant contributions. While we don't want to relax it
> too much, one thing I have been discussing informally with a few people is
> that a Committer with, say, 24 commits, who regularly participates in
> reviews, offering good feedback, might be just a good a reviewer (maybe
> even better) than someone with 32 commits who rarely, if ever, provides
> feedback on proposed bug fixes. I'm open for suggestions here.


Continuing the point above, it makes sense to me that a Reviewer role is
assigned per field (whether a "field" is module, a set of packages or
something else). While formally we need to give a list of Reviewers for
OpenJFX, practically I don't think a Reviewer who contributed 40 out of his
42 commits to javafx.base can (and probably wouldn't anyway) Review in
javafx.web. What I'm getting at is that whatever the threshold numbers are,
it makes sense, at least informally, to count per field. If I submit 5
contributions per module and pass the threshold, what exactly am I
qualified to Review?

Granted, the threshold numbers includes familiarizing oneself with code
patterns and tools which are global to the project, so to become a Reviewer
in a 2nd field takes much less effort than the first time.

This is just a point I wanted to make about the Reviewer role. We don't
have to change formal policies.

I propose that a New Feature, API addition, or behavioral change must be
> reviewed / approved by a "lead".


Can you give the guidelines by which a lead reviews / approves one of the
above?

D. All code review policies outlined above in #2 were followed prior to the
> PR being approved and merged into the develop branch on GitHub. This
> includes sending email to openjfx-dev when you first make a PR that you
> intend to have merged into the develop branch to give other reviewers who
> may not be watching all PRs a chance to comment before it is merged.


I would hope that the people in openjfx-dev who are not watching all PRs
will have a chance to comment before the work starts, and not when the work
is done and before it's merged. Visiting the mirror from time to time
reveals to me PRs that weren't mentioned on the mailing list. Those PRs
might be in conflict with work that isn't visible on GitHub. Iv'e brought
it up in a past discussion about the mirror - we need to centralize the
discussion medium. It's the normal price to pay for synchronization.

- Nir


[1] https://wiki.openjdk.java.net/display/OpenJFX/Code+Ownership

On Thu, May 24, 2018 at 1:16 AM, Kevin Rushforth  wrote:

> To: OpenJFX Developers
>
> As I mentioned in a message last week [1] I would like to restart the
> discussion we started a few months ago [2] around making it easier to
> contribute code to OpenJFX. To this end, I like to make some concrete
> proposals around code review / API review policies.
>
> Before getting to the details, I would like to acknowledge Gluon's
> contributions to the OpenJFX project, specifically those of Johan Vos. I am
> pleased to announce an expanded role for Johan Vos in the OpenJFX project.
> I would like to announce that starting now, Johan is effectively a co-lead
> for the purposes of setting direction, and approving new features for the
> Project.
>
> The short version of the proposal is:
>
> 1. Formalize the concept of Reviewers with an initial list of Reviewers
> and a defined criteria for adding additional Reviewers.
>
> 2. Revised code review policies for different types of changes: simple,
> low-impact fixes (1 Reviewer); higher-impact fixes (2 Reviewers + allow
> time for others to chime in); Features / API changes (CSR approval,
> including approval by a "lead", plus 3 Reviewers for the code)
>
> 3. Streamlining reviews of changes developed in the GitHub sandbox:
> provided that the review policy is followed to before a PR is merged into
> the develop branch in GitHub, a fast-track review can happen pointing to
> the changeset that was merged and the PR, which has review comments.
>
> Details follow.
>
> Quoting from my earlier message:
>
> "Code reviews are important to maintain high-quality contributions, but we
>> recognize that not every type of change needs the same level of review.
>> Without lowering our standards of quality, we want to make it easier to get
>> low-impact changes (simple bug fixes) accepted."
>>
>
> To that end, I propose the following 

Re: OpenJFX status update

[Nir Lisker]

I see, sorry about the false flag.

On Fri, May 18, 2018 at 11:13 PM, Kevin Rushforth <
kevin.rushfo...@oracle.com> wrote:

> I was somewhat imprecise. That should have read:
>
> We still expect to do a release of JavaFX 11 around the same time as JDK
> 11, but using a different **JBS release version** will help track the
> actual content of JavaFX 11 separately from JDK 11.
>
>
> The JavaFX version is still 11 as reported by the value of the system
> property "javafx.version" and in the names of the release bundles. No
> changes are needed. We are just prefixing the release value in JBS with
> "openjfx" before the "11" to distinguish it from the JDK 11 release.
>
> After JavaFX 11, we could have a discussion on whether to make the next
> version "12" or something else.
>
> -- Kevin
>
>
> On 5/18/2018 12:05 PM, Nir Lisker wrote:
>
> We still expect to do a release of JavaFX 11 around the same time as JDK
>> 11, but using a different release number will help track the actual content
>> of JavaFX 11 separately from JDK 11.
>
>
>  Iv'e just realized that not releasing JavaFX with version number 11 will
> cause confusion with all the '@since 11' tags. We could search for all
> '@since 11' and replace them with the new version number (maybe much to the
> confusion of users since it breaks continuity).
>
> - Nir
>
> On Wed, May 16, 2018 at 12:59 AM, Kevin Rushforth <
> kevin.rushfo...@oracle.com> wrote:
>
>> I wanted to update you on the progress of the last couple weeks on the
>> OpenJFX project:
>>
>> 1. As mentioned last week, we now have EA builds of OpenJFX 11 on
>> java.net [1]. We intend to update this roughly weekly. Currently the
>> build numbers match the corresponding JDK build number, but that will not
>> necessarily be the case going forward, so don't assume that they are in
>> sync.
>>
>> 2. Barring any build or staging issues, this week's OpenJFX 11 EA build
>> will include the jmods as mentioned earlier [2] [3]
>>
>> 3. JavaFX has been removed from JDK 11 as of this week. Starting with
>> jdk-11+14, early access builds of JDK 11 will not include JavaFX.
>>
>> 4. After jdk-11+14 is posted on java.net, and FX is no longer included
>> in JDK 11, we will start using openjfx-11 as the fix version in JBS to
>> distinguish it from JDK 11. We still expect to do a release of JavaFX 11
>> around the same time as JDK 11, but using a different release number will
>> help track the actual content of JavaFX 11 separately from JDK 11.
>>
>> 5. Once this settles down, possibly later this week, I hope to restart
>> the discussion about OpenJFX policies, etc. I also hope to be a bit more
>> responsive over the coming days / weeks than I have been for the last 3-4
>> weeks. Getting the standalone OpenJFX working and removing JavaFX from the
>> JDK was quite time consuming as you can probably imagine.
>>
>> If you have any general comments or questions about any of this, please
>> reply to this thread. We may want to split out more detailed discussions
>> into their own thread to make it easier to follow.
>>
>> -- Kevin
>>
>> [1] http://jdk.java.net/openjfx/
>>
>> [2] http://mail.openjdk.java.net/pipermail/openjfx-dev/2018-May/
>> 021856.html
>> [3] https://bugs.openjdk.java.net/browse/JDK-8202368
>>
>>
>
>

Re: JDK-8195974: Replace use of java.util.logging in javafx with System logger

[Nir Lisker]

>
> There was one other place where isDebug() was called, that being the mLog
> method. Did you replace the call ti isDebug() with a direct call to
> isLoggable instead?
>

Yes, I should have been clearer: I inlined `isDebug` into `mLog`, then
commented out `isDebug` so that if someone reads the commented-out code in
`main` they'll know what it is referring to. I just didn't see a point in
leaving a private static method just for this one use.

In any case, since "HelloService" is a test program, I see no problem with
> it continuing to use java.util.logging.


For Eclipse users this it still a problem since Eclipse includes the tests
in the module (it was discussed in the JIRA issue). Since the packager is
out of scope, I'll just patch the last remnant
in test.com.sun.javafx.binding.ErrorLoggingUtiltity and submit a Webrev
tomorrow or this weekend since all other changes are already prepared (and
mostly trivial).

- Nir

On Thu, May 17, 2018 at 11:39 PM, Kevin Rushforth <
kevin.rushfo...@oracle.com> wrote:

> I think it isn't worth doing anything for the packager. In any case, since
> "HelloService" is a test program, I see no problem with it continuing to
> use java.util.logging.
>
> Regarding your other comment:
>
> Thanks Murali, Iv'e also commented out isDebug() (though maybe it can be
> completely removed, only that the commented out code relies on it).
>
>
> There was one other place where isDebug() was called, that being the mLog
> method. Did you replace the call ti isDebug() with a direct call to
> isLoggable instead? Note that without the isLoggable check you will incur
> the redundant cost of the method calls + string construction.
>
> -- Kevin
>
>
>
> On 5/17/2018 1:25 PM, Nir Lisker wrote:
>
> Thanks Murali, Iv'e also commented out isDebug() (though maybe it can be
> completely removed, only that the commented out code relies on it).
>
> Kevin, after this change, HelloService in the packager is the only one
> requiring file handling. What is the future of the packager now? Is it
> worth supplying an alternative for these classes?
>
> - Nir
>
> On Thu, May 17, 2018 at 8:49 PM, Murali Billa <murali.bi...@oracle.com>
> wrote:
>
>> Hi Nir,
>>
>>
>>
>> Regarding “com.sun.javafx.webkit.drt.DumpRenderTree”, you can comment
>> out the below code in “main” method from DumpRenderTree.java file.
>>
>>
>>
>> if ( isDebug() ) {
>>
>> log.setLevel(Level.FINEST);
>>
>> FileHandler handler = new FileHandler("drt.log", true);
>>
>> handler.setFormatter(new Formatter() {
>>
>> @Override
>>
>> public String format(LogRecord record) {
>>
>> return formatMessage(record) + "\n";
>>
>> }
>>
>> });
>>
>> log.addHandler(handler);
>>
>> }
>>
>>
>>
>> Thanks,
>>
>> MUrali
>>
>> *From:* Murali Billa
>> *Sent:* Thursday, May 03, 2018 1:52 AM
>> *To:* Nir Lisker <nlis...@gmail.com>
>> *Cc:* openjfx-dev@openjdk.java.net Mailing <openjfx-dev@openjdk.java.net>
>> *Subject:* RE: JDK-8195974: Replace use of java.util.logging in javafx
>> with System logger
>>
>>
>>
>> Hi Nir,
>>
>>
>>
>> 1)  Regarding “verbose” flag usage:
>>
>> · Currently verbose flag is used to show log Levels
>> (FINER/FINE/INFO/WARNING) in WCMediaPlayer & WCMediaPlayerImpl.  I feel
>> it is not desirable to remove this flag as all these logs will start
>> appearing now by default.
>>
>> · We can try 2 options:
>>
>> a)   1st Option: We can change all INFO log messages to FINE  under
>> verbose flag (by leaving all log messages that use Level other than INFO
>> unchanged) and verbose flag can be removed.
>>
>> b)  If 1st option results in too much noise for WARNING log
>> messages, then we can keep the verbose flag and introduce a System Property
>> (for ex: javafx.web.verbose) to enable the flag. I won’t suggest reading
>> level value from log/config file.
>>
>>
>>
>> 2)  Regarding  “com.sun.javafx.webkit.drt.DumpRenderTree”,  I need
>> to check few more things (since we use “addHandler” in drt) and will get
>> back to you.
>>
>>
>>
>> Please let me know, if you have any queries for 1.
>>
>> Thanks,
>>
>> Murali
>>
>> *From:* Nir Lisker <nlis...@gmail.com>
>> *Sent:* Saturday, April 28, 2018 1:06 AM
>> *To:* Murali Billa <murali.bi...@oracle.com>
>> *Cc:* openjfx-dev@openjdk.java.net Mailing <openjfx-dev@openjdk.java.net>
>> *Subject:* JDK-8195974: Replace use of java.util.logging in javafx with
>> System logger
>>
>>
>>
>> Hi Murali,
>>
>>
>>
>> Can you have a look at https://bugs.openjdk.java.net/browse/JDK-8195974
>> please?
>>
>>
>>
>> There are some usages of j.u.l in the web module I'd like your opinion
>> on. I'm not familiar with the intent of these pieces of code and would like
>> to know what the options are for advancing with this issue on that front.
>>
>>
>>
>> Thanks,
>>
>> Nir
>>
>
>
>

Re: OpenJFX status update

[Nir Lisker]

>
> We still expect to do a release of JavaFX 11 around the same time as JDK
> 11, but using a different release number will help track the actual content
> of JavaFX 11 separately from JDK 11.


 Iv'e just realized that not releasing JavaFX with version number 11 will
cause confusion with all the '@since 11' tags. We could search for all
'@since 11' and replace them with the new version number (maybe much to the
confusion of users since it breaks continuity).

- Nir

On Wed, May 16, 2018 at 12:59 AM, Kevin Rushforth <
kevin.rushfo...@oracle.com> wrote:

> I wanted to update you on the progress of the last couple weeks on the
> OpenJFX project:
>
> 1. As mentioned last week, we now have EA builds of OpenJFX 11 on java.net
> [1]. We intend to update this roughly weekly. Currently the build numbers
> match the corresponding JDK build number, but that will not necessarily be
> the case going forward, so don't assume that they are in sync.
>
> 2. Barring any build or staging issues, this week's OpenJFX 11 EA build
> will include the jmods as mentioned earlier [2] [3]
>
> 3. JavaFX has been removed from JDK 11 as of this week. Starting with
> jdk-11+14, early access builds of JDK 11 will not include JavaFX.
>
> 4. After jdk-11+14 is posted on java.net, and FX is no longer included in
> JDK 11, we will start using openjfx-11 as the fix version in JBS to
> distinguish it from JDK 11. We still expect to do a release of JavaFX 11
> around the same time as JDK 11, but using a different release number will
> help track the actual content of JavaFX 11 separately from JDK 11.
>
> 5. Once this settles down, possibly later this week, I hope to restart the
> discussion about OpenJFX policies, etc. I also hope to be a bit more
> responsive over the coming days / weeks than I have been for the last 3-4
> weeks. Getting the standalone OpenJFX working and removing JavaFX from the
> JDK was quite time consuming as you can probably imagine.
>
> If you have any general comments or questions about any of this, please
> reply to this thread. We may want to split out more detailed discussions
> into their own thread to make it easier to follow.
>
> -- Kevin
>
> [1] http://jdk.java.net/openjfx/
>
> [2] http://mail.openjdk.java.net/pipermail/openjfx-dev/2018-May/
> 021856.html
> [3] https://bugs.openjdk.java.net/browse/JDK-8202368
>
>

Re: JDK-8195974: Replace use of java.util.logging in javafx with System logger

[Nir Lisker]

Thanks Murali, Iv'e also commented out isDebug() (though maybe it can be
completely removed, only that the commented out code relies on it).

Kevin, after this change, HelloService in the packager is the only one
requiring file handling. What is the future of the packager now? Is it
worth supplying an alternative for these classes?

- Nir

On Thu, May 17, 2018 at 8:49 PM, Murali Billa <murali.bi...@oracle.com>
wrote:

> Hi Nir,
>
>
>
> Regarding “com.sun.javafx.webkit.drt.DumpRenderTree”, you can comment out
> the below code in “main” method from DumpRenderTree.java file.
>
>
>
> if ( isDebug() ) {
>
> log.setLevel(Level.FINEST);
>
> FileHandler handler = new FileHandler("drt.log", true);
>
> handler.setFormatter(new Formatter() {
>
> @Override
>
> public String format(LogRecord record) {
>
> return formatMessage(record) + "\n";
>
> }
>
> });
>
> log.addHandler(handler);
>
>     }
>
>
>
> Thanks,
>
> MUrali
>
> *From:* Murali Billa
> *Sent:* Thursday, May 03, 2018 1:52 AM
> *To:* Nir Lisker <nlis...@gmail.com>
> *Cc:* openjfx-dev@openjdk.java.net Mailing <openjfx-dev@openjdk.java.net>
> *Subject:* RE: JDK-8195974: Replace use of java.util.logging in javafx
> with System logger
>
>
>
> Hi Nir,
>
>
>
> 1)  Regarding “verbose” flag usage:
>
> · Currently verbose flag is used to show log Levels
> (FINER/FINE/INFO/WARNING) in WCMediaPlayer & WCMediaPlayerImpl.  I feel
> it is not desirable to remove this flag as all these logs will start
> appearing now by default.
>
> · We can try 2 options:
>
> a)   1st Option: We can change all INFO log messages to FINE  under
> verbose flag (by leaving all log messages that use Level other than INFO
> unchanged) and verbose flag can be removed.
>
> b)  If 1st option results in too much noise for WARNING log messages,
> then we can keep the verbose flag and introduce a System Property (for ex:
> javafx.web.verbose) to enable the flag. I won’t suggest reading level value
> from log/config file.
>
>
>
> 2)  Regarding  “com.sun.javafx.webkit.drt.DumpRenderTree”,  I need to
> check few more things (since we use “addHandler” in drt) and will get back
> to you.
>
>
>
> Please let me know, if you have any queries for 1.
>
> Thanks,
>
> Murali
>
> *From:* Nir Lisker <nlis...@gmail.com>
> *Sent:* Saturday, April 28, 2018 1:06 AM
> *To:* Murali Billa <murali.bi...@oracle.com>
> *Cc:* openjfx-dev@openjdk.java.net Mailing <openjfx-dev@openjdk.java.net>
> *Subject:* JDK-8195974: Replace use of java.util.logging in javafx with
> System logger
>
>
>
> Hi Murali,
>
>
>
> Can you have a look at https://bugs.openjdk.java.net/browse/JDK-8195974
> please?
>
>
>
> There are some usages of j.u.l in the web module I'd like your opinion on.
> I'm not familiar with the intent of these pieces of code and would like to
> know what the options are for advancing with this issue on that front.
>
>
>
> Thanks,
>
> Nir
>

Re: [11] Review request: 8200446: Update minimum boot JDK to 10

[Nir Lisker]

>
> Once this is done, we can start using JDK 10 features, such as 'var' for
> local variables (although please don't take this as a license to use 'var'
> gratuitously).


I'll remind that there's a style guide at
http://openjdk.java.net/projects/amber/LVTIstyle.html.

- Nir

On Thu, Jun 14, 2018 at 4:33 PM, Kevin Rushforth  wrote:

> Please review the following to bump the minimum boot JDK required for
> JavaFX builds to JDK 10. Note that the review will be done on github, but
> it is OK to reply to this thread with comments if you don't have a github
> account.
>
> https://bugs.openjdk.java.net/browse/JDK-8200446
> https://github.com/javafxports/openjdk-jfx/pull/61
>
> This also bumps the class file format to that of JDK 10. I note that we
> have been using JDK 10 to build the openjfx-11 builds for several months,
> and now that we've upgraded to gradle 4.8 we are ready to make JDK 10 the
> minimum.
>
> Once this is done, we can start using JDK 10 features, such as 'var' for
> local variables (although please don't take this as a license to use 'var'
> gratuitously).
>
> Thanks.
>
> -- Kevin
>
>

Change of default behavior of When

[Nir Lisker]

Hi all,

The class javafx.beans.binding.When is using eager evaluation of its
arguments [1]. Kevin and I discussed the idea of changing this default
behavior to the more intuitive lazy evaluation as done in a simple ternary
expression. This is a potentially breaking change for current code that
(for some reason) relies on both values being evaluated regardless of the
condition's value. This behavior is not documented.

If anyone has any reservations, please voice them over the next few days.

Thanks,
Nir

[1] https://bugs.openjdk.java.net/browse/JDK-8089579

gradle javadoc commands are SKIPPED

[Nir Lisker]

Hi,

When I run gradle javadoc (or for a specific module), all the javadoc tasks
are marked as SKIPPED. I don't remember this happening previously.

> Task :javadoc
> Task :base:javadoc SKIPPED
> Task :controls:javadoc SKIPPED
> Task :fxml:javadoc SKIPPED
> Task :fxpackagerservices:compileJava SKIPPED
> Task :fxpackagerservices:processResources SKIPPED
> Task :fxpackagerservices:classes SKIPPED
> Task :fxpackager:compileJava SKIPPED
> Task :fxpackager:copyDTtoPackager SKIPPED
> Task :fxpackager:copyRedistributableFiles SKIPPED
> Task :fxpackager:man SKIPPED
> Task :fxpackager:processResources SKIPPED
> Task :fxpackager:classes SKIPPED
> Task :fxpackager:javadoc SKIPPED
> Task :fxpackagerservices:javadoc SKIPPED
> Task :graphics:javadoc SKIPPED
> Task :media:javadoc SKIPPED
> Task :swing:javadoc SKIPPED
> Task :swt:compileJava UP-TO-DATE
> Task :swt:processResources NO-SOURCE
> Task :swt:classes
> Task :swt:javadoc SKIPPED
> Task :systemTests:compileJava NO-SOURCE
> Task :systemTests:processResources NO-SOURCE
> Task :systemTests:classes UP-TO-DATE
> Task :systemTests:javadoc SKIPPED
> Task :web:javadoc SKIPPED

What's causing this?

- Nir

Re: JDK-8195974: Replace use of java.util.logging in javafx with System logger

[Nir Lisker]

Thanks Murali,

I won’t suggest reading level value from log/config file.


Is that file user facing? If so, wouldn't ignoring the level set in the
file break current behavior? Would there need to be follow-up changes to
this file to remove the level setting from it?

About option (a), wouldn't removing the verbose flag (After changing INFO
to FINE) cause all the log messages to appear by default, as you've stated
in the first point, and we want to avoid that? We don't have a minimum log
level setting.

-Nir


On Wed, May 2, 2018 at 11:21 PM, Murali Billa <murali.bi...@oracle.com>
wrote:

> Hi Nir,
>
>
>
> 1)  Regarding “verbose” flag usage:
>
> · Currently verbose flag is used to show log Levels
> (FINER/FINE/INFO/WARNING) in WCMediaPlayer & WCMediaPlayerImpl.  I feel
> it is not desirable to remove this flag as all these logs will start
> appearing now by default.
>
> · We can try 2 options:
>
> a)   1st Option: We can change all INFO log messages to FINE  under
> verbose flag (by leaving all log messages that use Level other than INFO
> unchanged) and verbose flag can be removed.
>
> b)  If 1st option results in too much noise for WARNING log messages,
> then we can keep the verbose flag and introduce a System Property (for ex:
> javafx.web.verbose) to enable the flag. I won’t suggest reading level value
> from log/config file.
>
>
>
> 2)  Regarding  “com.sun.javafx.webkit.drt.DumpRenderTree”,  I need to
> check few more things (since we use “addHandler” in drt) and will get back
> to you.
>
>
>
> Please let me know, if you have any queries for 1.
>
> Thanks,
>
> Murali
>
> *From:* Nir Lisker <nlis...@gmail.com>
> *Sent:* Saturday, April 28, 2018 1:06 AM
> *To:* Murali Billa <murali.bi...@oracle.com>
> *Cc:* openjfx-dev@openjdk.java.net Mailing <openjfx-dev@openjdk.java.net>
> *Subject:* JDK-8195974: Replace use of java.util.logging in javafx with
> System logger
>
>
>
> Hi Murali,
>
>
>
> Can you have a look at https://bugs.openjdk.java.net/browse/JDK-8195974
> please?
>
>
>
> There are some usages of j.u.l in the web module I'd like your opinion on.
> I'm not familiar with the intent of these pieces of code and would like to
> know what the options are for advancing with this issue on that front.
>
>
>
> Thanks,
>
> Nir
>

Re: JDK-8195974: Replace use of java.util.logging in javafx with System logger

[Nir Lisker]

>
> Not sure what you mean by "that file".


Sorry, I meant the log/config file.

keeping the verbose flag but putting it on a System property


Then why not get a minimum level from a system property instead of a
general on/off flag?

Also, why is webkit.mediaplayer special in its usage of the logger (that it
requires its own property)?

- Nir

On Thu, May 3, 2018 at 3:31 AM, Kevin Rushforth <kevin.rushfo...@oracle.com>
wrote:

> inline
>
>
> On 5/2/2018 4:52 PM, Nir Lisker wrote:
>
>> Thanks Murali,
>>
>> I won’t suggest reading level value from log/config file.
>>
>>
>> Is that file user facing? If so, wouldn't ignoring the level set in the
>> file break current behavior? Would there need to be follow-up changes to
>> this file to remove the level setting from it?
>>
>
> Not sure what you mean by "that file". The WCMediaPlayer file? No, it
> isn't user-facing. Or did you mean something else?
>
> About option (a), wouldn't removing the verbose flag (After changing INFO
>> to FINE) cause all the log messages to appear by default, as you've stated
>> in the first point, and we want to avoid that? We don't have a minimum log
>> level setting.
>>
>
> By default the log level for all loggers is set at INFO -- thus the
> suggestion to change all of the INFO messages to FINE, which will not be
> logged by default. If we still end up with a bunch of extra WARNING or
> SEVERE log messages from from ordinary situations, then that would be a
> problem. Given that the implementation of WCMediaPlayer produces "noisier
> than typical" INFO log messages, it wouldn't surprise me that some of the
> WARNING log messages are things that the user shouldn't necessarily be
> warned about.
>
> In any case, the second suggestion of keeping the verbose flag but putting
> it on a System property might be less intrusive. And like the current
> solution, puts the control in the hands of the user.
>
> -- Kevin
>
>
> -Nir
>>
>>
>> On Wed, May 2, 2018 at 11:21 PM, Murali Billa <murali.bi...@oracle.com>
>> wrote:
>>
>> Hi Nir,
>>>
>>>
>>>
>>> 1)  Regarding “verbose” flag usage:
>>>
>>> · Currently verbose flag is used to show log Levels
>>> (FINER/FINE/INFO/WARNING) in WCMediaPlayer & WCMediaPlayerImpl.  I feel
>>> it is not desirable to remove this flag as all these logs will start
>>> appearing now by default.
>>>
>>> · We can try 2 options:
>>>
>>> a)   1st Option: We can change all INFO log messages to FINE  under
>>> verbose flag (by leaving all log messages that use Level other than INFO
>>> unchanged) and verbose flag can be removed.
>>>
>>> b)  If 1st option results in too much noise for WARNING log messages,
>>> then we can keep the verbose flag and introduce a System Property (for
>>> ex:
>>> javafx.web.verbose) to enable the flag. I won’t suggest reading level
>>> value
>>> from log/config file.
>>>
>>>
>>>
>>> 2)  Regarding  “com.sun.javafx.webkit.drt.DumpRenderTree”,  I need
>>> to
>>> check few more things (since we use “addHandler” in drt) and will get
>>> back
>>> to you.
>>>
>>>
>>>
>>> Please let me know, if you have any queries for 1.
>>>
>>> Thanks,
>>>
>>> Murali
>>>
>>> *From:* Nir Lisker <nlis...@gmail.com>
>>> *Sent:* Saturday, April 28, 2018 1:06 AM
>>> *To:* Murali Billa <murali.bi...@oracle.com>
>>> *Cc:* openjfx-dev@openjdk.java.net Mailing <openjfx-dev@openjdk.java.net
>>> >
>>> *Subject:* JDK-8195974: Replace use of java.util.logging in javafx with
>>> System logger
>>>
>>>
>>>
>>> Hi Murali,
>>>
>>>
>>>
>>> Can you have a look at https://bugs.openjdk.java.net/browse/JDK-8195974
>>> please?
>>>
>>>
>>>
>>> There are some usages of j.u.l in the web module I'd like your opinion
>>> on.
>>> I'm not familiar with the intent of these pieces of code and would like
>>> to
>>> know what the options are for advancing with this issue on that front.
>>>
>>>
>>>
>>> Thanks,
>>>
>>> Nir
>>>
>>>
>

Re: JDK-8195974: Replace use of java.util.logging in javafx with System logger

[Nir Lisker]

>
> Also, why is webkit.mediaplayer special in its usage of the logger (that
>> it requires its own property)?
>
>
> That's the real question: are the needs of the WebView media component so
> special that it justifies its own mechanism / property. I doubt it, which
> is why removing the verbose flag altogether seems the better choice as long
> as it isn't too intrusive / noisy.
>

Is the intrusiveness something that needs to be and can be tested? Can we
remove the flag and if needed later reinstate it via a system property?

 it wouldn't surprise me that some of the WARNING log messages are things
> that the user shouldn't necessarily be warned about.
>

>From my point of view, if the warning messages are of no interest to the
user, maybe they shouldn't be warning level.

- Nir

On Thu, May 3, 2018 at 2:42 PM, Kevin Rushforth <kevin.rushfo...@oracle.com>
wrote:

>
>
> On 5/2/2018 6:25 PM, Nir Lisker wrote:
>
> Not sure what you mean by "that file".
>
>
> Sorry, I meant the log/config file.
>
>
> I see. This isn't something that a library like JavaFX should read.
>
> keeping the verbose flag but putting it on a System property
>
>
> Then why not get a minimum level from a system property instead of a
> general on/off flag?
>
>
> Because that would be duplicating functionality that should be handled by
> the logger configuration itself (we can't set the logging level when using
> the PlatformLogger wrapper utility to System.Logger).
>
> Also, why is webkit.mediaplayer special in its usage of the logger (that
> it requires its own property)?
>
>
> That's the real question: are the needs of the WebView media component so
> special that it justifies its own mechanism / property. I doubt it, which
> is why removing the verbose flag altogether seems the better choice as long
> as it isn't too intrusive / noisy.
>
> -- Kevin
>
>
>
> - Nir
>
> On Thu, May 3, 2018 at 3:31 AM, Kevin Rushforth <
> kevin.rushfo...@oracle.com> wrote:
>
>> inline
>>
>>
>> On 5/2/2018 4:52 PM, Nir Lisker wrote:
>>
>>> Thanks Murali,
>>>
>>> I won’t suggest reading level value from log/config file.
>>>
>>>
>>> Is that file user facing? If so, wouldn't ignoring the level set in the
>>> file break current behavior? Would there need to be follow-up changes to
>>> this file to remove the level setting from it?
>>>
>>
>> Not sure what you mean by "that file". The WCMediaPlayer file? No, it
>> isn't user-facing. Or did you mean something else?
>>
>> About option (a), wouldn't removing the verbose flag (After changing INFO
>>> to FINE) cause all the log messages to appear by default, as you've
>>> stated
>>> in the first point, and we want to avoid that? We don't have a minimum
>>> log
>>> level setting.
>>>
>>
>> By default the log level for all loggers is set at INFO -- thus the
>> suggestion to change all of the INFO messages to FINE, which will not be
>> logged by default. If we still end up with a bunch of extra WARNING or
>> SEVERE log messages from from ordinary situations, then that would be a
>> problem. Given that the implementation of WCMediaPlayer produces "noisier
>> than typical" INFO log messages, it wouldn't surprise me that some of the
>> WARNING log messages are things that the user shouldn't necessarily be
>> warned about.
>>
>> In any case, the second suggestion of keeping the verbose flag but
>> putting it on a System property might be less intrusive. And like the
>> current solution, puts the control in the hands of the user.
>>
>> -- Kevin
>>
>>
>> -Nir
>>>
>>>
>>> On Wed, May 2, 2018 at 11:21 PM, Murali Billa <murali.bi...@oracle.com>
>>> wrote:
>>>
>>> Hi Nir,
>>>>
>>>>
>>>>
>>>> 1)  Regarding “verbose” flag usage:
>>>>
>>>> · Currently verbose flag is used to show log Levels
>>>> (FINER/FINE/INFO/WARNING) in WCMediaPlayer & WCMediaPlayerImpl.  I feel
>>>> it is not desirable to remove this flag as all these logs will start
>>>> appearing now by default.
>>>>
>>>> · We can try 2 options:
>>>>
>>>> a)   1st Option: We can change all INFO log messages to FINE  under
>>>> verbose flag (by leaving all log messages that use Level other than INFO
>>>> unchanged) and verbose flag can be removed.
>>>>
>>>> b)  If 1st option results 

JDK build fails on missing javah

[Nir Lisker]

After successfully building OpenJFX (11) Iv'e went on to build OpenJDK (11)
as instructed under "Integration with OpenJDK" (
http://hg.openjdk.java.net/jdk/jdk/raw-file/tip/doc/building.html).

When executing `bash configure
--with-import-modules=jfx_path\rt\build\modular-sdk` the build fails:

checking for java in Boot JDK... ok
checking for javac in Boot JDK... ok
checking for javah in Boot JDK... not found
configure: Your Boot JDK seems broken. This might be fixed by explicitly
setting --with-boot-jdk
configure: error: Could not find javah in the Boot JDK
configure exiting with result code 1

The boot JDK is 10, which does not have javah anymore, so it is no
surprise. I could point boot JDK to a previous version, but I don't think I
should. Does anyone know what I should do?

Nir

Re: Updated OpenJFX build instructions

[Nir Lisker]

Thanks Kevin,

I'm going through the process now on Win 10.

A few things to note:
- In the Platform Prerequisites/cygwin it says to make sure mercurial
package is installed. Later, under Common Prerequisites/Mercurial it says
"you can also install Mercurial as a cygwin package". It's not clear then
if it's needed or optional and if it replaces or complements the other hg
toolings.
- The link to Tortoise should be https://tortoisehg.bitbucket.io (not .org).
- Might be trivial but I would say it's worth noting that all commands
listed there are to be ran in cygwin.
- The hg clone command probably needs to have a note added about the
destination folder.

The problems starts after navigating to the /rt directory and executing
'gradle tasks' or `gradle projects`:

$ gradle tasks
:buildSrc:generateGrammarSource
A problem was found with the configuration of task
':buildSrc:generateGrammarSource'. Registering invalid inputs and outputs
via TaskInputs and TaskOutputs methods has been deprecated and is scheduled
to be removed in Gradle 5.0.
 - Directory 'D:\rt\buildSrc\src\main\antlr' specified for property '$1'
does not exist.
:buildSrc:generateGrammarSource UP-TO-DATE
:buildSrc:compileJava NO-SOURCE
:buildSrc:compileGroovy UP-TO-DATE
:buildSrc:processResources NO-SOURCE
:buildSrc:classes UP-TO-DATE
:buildSrc:jar UP-TO-DATE
:buildSrc:assemble UP-TO-DATE
:buildSrc:compileTestJava NO-SOURCE
:buildSrc:compileTestGroovy NO-SOURCE
:buildSrc:processTestResources NO-SOURCE
:buildSrc:testClasses UP-TO-DATE
:buildSrc:test NO-SOURCE
:buildSrc:check UP-TO-DATE
:buildSrc:build UP-TO-DATE

FAILURE: Build failed with an exception.

* Where:
Script 'D:\rt\buildSrc\win.gradle' line: 93

* What went wrong:
A problem occurred evaluating script.
> FAIL: WINSDK_DIR not defined

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or
--debug option to get more log output.

* Get more help at https://help.gradle.org

BUILD FAILED in 2s

---

I did not install DirectX SDK. Also the output of the above commands in the
instructions page seems out of date compared to the contents of the
directory... or I messed up.

Any ideas?



> I did a first pass over the build instructions on the OpenJFX Wiki [1].
> I think I cleaned up the worst of the inaccuracies, and added some
> information that will make it easier to build.
>
> I'm not the best person to see whether anything important is missing,
> though. Someone less familiar with the build should look it over and let
> me know what I've missed. I won't be able to get back to this until
> after the holidays and after JDK 10 RDP1 is over, but will take another
> pass at it then and incorporate the feedback.
>
> -- Kevin
>
> [1] https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX
>

Re: Updated OpenJFX build instructions

[Nir Lisker]

I did set them, but... if I set them in bash they disappear the next time I
launch it, which made me think they are not being set properly for some
reason even though they appear in `export -p` immediately after. Launching
bash as admin didn't do anything (I thought write permissions issue).

So I went to the /home/user/.bash_profile file and added the export
declarations there. Now they appear on `export -p` properly every launch. I
also did `gradle --stop` and `rm -rf build`, but `gradle clean` gives the
same error.

Otherwise, I also noticed that the folder VS150COMNTOOLS is pointing to
does not exist. I downloaded today VS 2017 Community version 15.5.2 (which
is what I set for MSVC_VER). This is as close as it gets:

---
Nir@Nir-Desktop /cygdrive/c/Program Files (x86)/Microsoft Visual
Studio/2017/Community
$ dir
Common7  Licenses  MSBuild  Team\ Tools  Xml
---

(no VC/Auxiliary/Build)

Is that directory supposed to be created by some process, I needed to
select some installation package for VS, or did something change from
version 14.x to 15.x?

Nir

On Sat, Dec 23, 2017 at 4:14 AM, Kevin Rushforth <kevin.rushfo...@oracle.com
> wrote:

> Thanks for the feedback...I'll note it.
>
> As for the build failure, did you install Visual Studio 2017 and set the
> two env variables (VS150COMNTOOLS and MSVC_VER) to point to it? If so, then
> it should determine WINSDK_DIR without anything else needed.
>
> -- Kevin
>
>
>
> Nir Lisker wrote:
>
> Thanks Kevin,
>
> I'm going through the process now on Win 10.
>
> A few things to note:
> - In the Platform Prerequisites/cygwin it says to make sure mercurial
> package is installed. Later, under Common Prerequisites/Mercurial it says
> "you can also install Mercurial as a cygwin package". It's not clear then
> if it's needed or optional and if it replaces or complements the other hg
> toolings.
> - The link to Tortoise should be https://tortoisehg.bitbucket.io (not
> .org).
> - Might be trivial but I would say it's worth noting that all commands
> listed there are to be ran in cygwin.
> - The hg clone command probably needs to have a note added about the
> destination folder.
>
> The problems starts after navigating to the /rt directory and executing
> 'gradle tasks' or `gradle projects`:
>
> $ gradle tasks
> :buildSrc:generateGrammarSource
> A problem was found with the configuration of task 
> ':buildSrc:generateGrammarSource'.
> Registering invalid inputs and outputs via TaskInputs and TaskOutputs
> methods has been deprecated and is scheduled to be removed in Gradle 5.0.
>  - Directory 'D:\rt\buildSrc\src\main\antlr' specified for property '$1'
> does not exist.
> :buildSrc:generateGrammarSource UP-TO-DATE
> :buildSrc:compileJava NO-SOURCE
> :buildSrc:compileGroovy UP-TO-DATE
> :buildSrc:processResources NO-SOURCE
> :buildSrc:classes UP-TO-DATE
> :buildSrc:jar UP-TO-DATE
> :buildSrc:assemble UP-TO-DATE
> :buildSrc:compileTestJava NO-SOURCE
> :buildSrc:compileTestGroovy NO-SOURCE
> :buildSrc:processTestResources NO-SOURCE
> :buildSrc:testClasses UP-TO-DATE
> :buildSrc:test NO-SOURCE
> :buildSrc:check UP-TO-DATE
> :buildSrc:build UP-TO-DATE
>
> FAILURE: Build failed with an exception.
>
> * Where:
> Script 'D:\rt\buildSrc\win.gradle' line: 93
>
> * What went wrong:
> A problem occurred evaluating script.
> > FAIL: WINSDK_DIR not defined
>
> * Try:
> Run with --stacktrace option to get the stack trace. Run with --info or
> --debug option to get more log output.
>
> * Get more help at https://help.gradle.org
>
> BUILD FAILED in 2s
>
> ---
>
> I did not install DirectX SDK. Also the output of the above commands in
> the instructions page seems out of date compared to the contents of the
> directory... or I messed up.
>
> Any ideas?
>
>
>
>> I did a first pass over the build instructions on the OpenJFX Wiki [1].
>> I think I cleaned up the worst of the inaccuracies, and added some
>> information that will make it easier to build.
>>
>> I'm not the best person to see whether anything important is missing,
>> though. Someone less familiar with the build should look it over and let
>> me know what I've missed. I won't be able to get back to this until
>> after the holidays and after JDK 10 RDP1 is over, but will take another
>> pass at it then and incorporate the feedback.
>>
>> -- Kevin
>>
>> [1] https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX
>>
>

Re: Updated OpenJFX build instructions

[Nir Lisker]

Just as I was about to ask Santa for a successful build Iv'e managed to do
it. Here are my conclusions for Win10 without WebKit:

1. vcvars32.bat
VS 2017 does not create vcvars32.bat by default, some components need to be
selected. I don't know which ones exactly, I think it's "VC++ 2017 v141
toolset (x86,x64)". The easiest way is to select the whole "Desktop
development with C++" workload which installs ~5.5GB of libraries and IDE
tools, which might or might not be useful.

2. MSVC_VER
This variable is NOT the VS version, which for VS 2017 is 15.x. I don't
know what that version specifies, but it needs to be the one under
"C:\Program Files (x86)\Microsoft Visual
Studio\2017\Community\VC\Tools\MSVC\$VERSION$". For me it was 14.12.25827.
using the wrong version causes the build to fail during the task
":graphics:compileDecoraNativeShadersWin" with the cause that a file
"cl.exe" cannot be found (there are 4 of these files under the above path,
I don't remember which it was).

3. env variables (chapter 1)
Cygwin converts the system variables on startup. Any vars that are required
in addition need to be specified with `export`. The build instructions show
to export JAVA_HOME, but later under Environment Variables it is set as a
system env var.
Additionally, for me, using `export` in cygwin did not save them and they
had to be reentered on each launch. I still don't know why, gradle was not
running. An alternative was to specify them under "/home/$USER$/.bash_profile"
which is ran on startup, but on Windows there can be a conflict with the
newline characters (\r\n vs \n) which messes up their definition.
Eventually, I settled on just specifying them as system env vars. This has
the advantage of not messing with slashes and quotes because Windows allows
you to navigate to the file/folder and takes care of the path.
Using `export -p` can verify that the paths are set correctly.

4. env variables (chapter 2)
For required files or folders it will be easier to list them and ask for
full paths instead of partial paths because at the end of the day this is
what the build script wants. For example:
- vcvars32.bat: "C:\Program Files (x86)\Microsoft Visual
Studio\2017\$EDITION$\VC\Auxiliary\Build\vcvars32.bat"
- cl.exe: root folder for all files "C:\Program Files (x86)\Microsoft
Visual Studio\2017\$EDITION$\VC\Tools\MSVC\$VERSION$\bin"
...
This bypasses installation details. It does require to change the build
script though.

Haven't set up anything else yet.

Merry Christmas,
Nir


On Sat, Dec 23, 2017 at 4:29 PM, Kevin Rushforth <kevin.rushfo...@oracle.com
> wrote:

> It's quite possible that Microsoft changed something in their installation
> of Visual Studio. We are relying on the VC/Auxiliary/Build directory being
> created as part of the (default) Visual Studio installation so we can find
> vcvars32.bat. You might look in your installation and see whether that file
> exists somewhere else. If it does, then point VS150COMNTOOLS to the
> directory containing that bat file.
>
> I won't have any more time to look at it this until after the new
> year...maybe someone else on the list can help?
>
>
> -- Kevin
>
>
> Nir Lisker wrote:
>
> I did set them, but... if I set them in bash they disappear the next time
> I launch it, which made me think they are not being set properly for some
> reason even though they appear in `export -p` immediately after. Launching
> bash as admin didn't do anything (I thought write permissions issue).
>
> So I went to the /home/user/.bash_profile file and added the export
> declarations there. Now they appear on `export -p` properly every launch. I
> also did `gradle --stop` and `rm -rf build`, but `gradle clean` gives the
> same error.
>
> Otherwise, I also noticed that the folder VS150COMNTOOLS is pointing to
> does not exist. I downloaded today VS 2017 Community version 15.5.2 (which
> is what I set for MSVC_VER). This is as close as it gets:
>
> ---
> Nir@Nir-Desktop /cygdrive/c/Program Files (x86)/Microsoft Visual
> Studio/2017/Community
> $ dir
> Common7  Licenses  MSBuild  Team\ Tools  Xml
> ---
>
> (no VC/Auxiliary/Build)
>
> Is that directory supposed to be created by some process, I needed to
> select some installation package for VS, or did something change from
> version 14.x to 15.x?
>
> Nir
>
> On Sat, Dec 23, 2017 at 4:14 AM, Kevin Rushforth <
> kevin.rushfo...@oracle.com> wrote:
>
>> Thanks for the feedback...I'll note it.
>>
>> As for the build failure, did you install Visual Studio 2017 and set the
>> two env variables (VS150COMNTOOLS and MSVC_VER) to point to it? If so, then
>> it should determine WINSDK_DIR without anything else needed.
>>
>> -- Kevin
>>
>>
>>
>> Nir Lisker 

Re: Error while pushing changeset

[Nir Lisker]

>
> If there isn't an existing JBS issue, then please file one


I thought I would point to "8188314: Fix typos in FX API docs" even though
the exact changes I'm proposing are not listed there, but I can submit a
new bug just for those if it really matters (it will be another Fix Typos
issue).


> I also note that with simple javadoc changes, this can be done prior to
> your OCA being recorded if you like


Yes, as a Participant. Iv'e signed the Sun CA some 7 years ago and this
week signed the OCA in case it didn't transfer over. It's not crucial to
handle it right now since the changes are trivial.

I haven't gotten to your email from yesterday


It's a bit of a loaded one so it can wait after the RDP. I only needed the
minimum info to get these fixes before the RDP.

- Nir

On Tue, Jan 9, 2018 at 9:43 PM, Kevin Rushforth <kevin.rushfo...@oracle.com>
wrote:

> > I also note that tith simple javadoc changes...
>
> "with" simple ...
>
> -- Kevin
>
>
>
> Kevin Rushforth wrote:
>
>>
>>
>> Nir Lisker wrote:
>>
>>> > This shows a lack of understanding about our processes
>>>
>>> Yes it does, which is why I asked about it yesterday. I'll send a webrev.
>>>
>>
>> Ah, I haven't gotten to your email from yesterday, since I was on
>> vacation and am still catching up. If you can send a webrev, and a pointer
>> to a JBS issue, I'll attach it for you. If there isn't an existing JBS
>> issue, then please file one (and I'll see that it gets moved into the JDK
>> project quickly). I also note that tith simple javadoc changes, this can be
>> done prior to your OCA being recorded if you like.
>>
>> Thanks.
>>
>> -- Kevin
>>
>>
>>
>>> Thanks,
>>> Nir
>>>
>>>
>>> On Tue, Jan 9, 2018 at 8:50 PM, Kevin Rushforth <
>>> kevin.rushfo...@oracle.com <mailto:kevin.rushfo...@oracle.com>> wrote:
>>>
>>> Why would you even try to push a changeset without getting it
>>> reviewed first???
>>>
>>> This shows a lack of understanding about our processes and
>>> policies. Only committers have permission to push changesets, and
>>> only after review. Please familiarize yourself with the policies
>>> and procedures surrounding contributing to OpenJFX [1] [2] [3] [4]
>>> [5]. Once you are familiar with these policies and have signed the
>>> Oracle Contributor Agreement (OCA) you can work with someone to
>>> sponsor your change.
>>>
>>> -- Kevin
>>>
>>> [1] http://openjdk.java.net/contribute/
>>> <http://openjdk.java.net/contribute/>
>>> [2] http://www.oracle.com/technetwork/community/oca-486395.html
>>> <http://www.oracle.com/technetwork/community/oca-486395.html>
>>> [3]
>>> https://wiki.openjdk.java.net/display/OpenJFX/Submitting+a+B
>>> ug+Report
>>> <https://wiki.openjdk.java.net/display/OpenJFX/Submitting+a+
>>> Bug+Report>
>>> [4] https://wiki.openjdk.java.net/display/OpenJFX/Code+Reviews
>>> <https://wiki.openjdk.java.net/display/OpenJFX/Code+Reviews>
>>> [5]
>>> https://wiki.openjdk.java.net/display/OpenJFX/Committing+the+Code
>>> <https://wiki.openjdk.java.net/display/OpenJFX/Committing+the+Code>
>>>
>>>
>>>
>>> Nir Lisker wrote:
>>>
>>> Iv'e created a small documentation fix and tried to push it to
>>> http://hg.openjdk.java.net/openjfx/jfx-dev/rt
>>> <http://hg.openjdk.java.net/openjfx/jfx-dev/rt>. I got an error:
>>>
>>> abort: push creates new remote head 2152a80ee902!
>>> hint: pull and merge or see 'hg help push' for details about
>>> pushing new
>>> heads
>>> [command returned code 255 Tue Jan 09 19:40:10 2018]
>>>
>>> What can be the problem?
>>>
>>>
>>

Re: Error while pushing changeset

[Nir Lisker]

> This shows a lack of understanding about our processes

Yes it does, which is why I asked about it yesterday. I'll send a webrev.

Thanks,
Nir

On Tue, Jan 9, 2018 at 8:50 PM, Kevin Rushforth <kevin.rushfo...@oracle.com>
wrote:

> Why would you even try to push a changeset without getting it reviewed
> first???
>
> This shows a lack of understanding about our processes and policies. Only
> committers have permission to push changesets, and only after review.
> Please familiarize yourself with the policies and procedures surrounding
> contributing to OpenJFX [1] [2] [3] [4] [5]. Once you are familiar with
> these policies and have signed the Oracle Contributor Agreement (OCA) you
> can work with someone to sponsor your change.
>
> -- Kevin
>
> [1] http://openjdk.java.net/contribute/
> [2] http://www.oracle.com/technetwork/community/oca-486395.html
> [3] https://wiki.openjdk.java.net/display/OpenJFX/Submitting+a+Bug+Report
> [4] https://wiki.openjdk.java.net/display/OpenJFX/Code+Reviews
> [5] https://wiki.openjdk.java.net/display/OpenJFX/Committing+the+Code
>
>
>
> Nir Lisker wrote:
>
>> Iv'e created a small documentation fix and tried to push it to
>> http://hg.openjdk.java.net/openjfx/jfx-dev/rt. I got an error:
>>
>> abort: push creates new remote head 2152a80ee902!
>> hint: pull and merge or see 'hg help push' for details about pushing new
>> heads
>> [command returned code 255 Tue Jan 09 19:40:10 2018]
>>
>> What can be the problem?
>>
>>
>

Error while pushing changeset

[Nir Lisker]

Iv'e created a small documentation fix and tried to push it to
http://hg.openjdk.java.net/openjfx/jfx-dev/rt. I got an error:

abort: push creates new remote head 2152a80ee902!
hint: pull and merge or see 'hg help push' for details about pushing new
heads
[command returned code 255 Tue Jan 09 19:40:10 2018]

What can be the problem?

Re: Error while pushing changeset

[Nir Lisker]

Submitted a new bug with ID: 9052190.

On Tue, Jan 9, 2018 at 10:51 PM, Kevin Rushforth <kevin.rushfo...@oracle.com
> wrote:

>
>
> Nir Lisker wrote:
>
> If there isn't an existing JBS issue, then please file one
>
>
> I thought I would point to "8188314: Fix typos in FX API docs" even though
> the exact changes I'm proposing are not listed there, but I can submit a
> new bug just for those if it really matters (it will be another Fix Typos
> issue).
>
>
> We'll need a new JBS bug, since that one is already resolved with a
> changeset (every changeset needs a unique bug ID). Feel free to use the
> same synopsis if you like.
>
>
>
>
>> I also note that with simple javadoc changes, this can be done prior to
>> your OCA being recorded if you like
>
>
> Yes, as a Participant. Iv'e signed the Sun CA some 7 years ago and this
> week signed the OCA in case it didn't transfer over. It's not crucial to
> handle it right now since the changes are trivial.
>
>
> Good.
>
>
> I haven't gotten to your email from yesterday
>
>
> It's a bit of a loaded one so it can wait after the RDP. I only needed the
> minimum info to get these fixes before the RDP.
>
>
> OK.
>
> -- Kevin
>
>
> - Nir
>
> On Tue, Jan 9, 2018 at 9:43 PM, Kevin Rushforth <
> kevin.rushfo...@oracle.com> wrote:
>
>> > I also note that tith simple javadoc changes...
>>
>> "with" simple ...
>>
>> -- Kevin
>>
>>
>>
>> Kevin Rushforth wrote:
>>
>>>
>>>
>>> Nir Lisker wrote:
>>>
>>>> > This shows a lack of understanding about our processes
>>>>
>>>> Yes it does, which is why I asked about it yesterday. I'll send a
>>>> webrev.
>>>>
>>>
>>> Ah, I haven't gotten to your email from yesterday, since I was on
>>> vacation and am still catching up. If you can send a webrev, and a pointer
>>> to a JBS issue, I'll attach it for you. If there isn't an existing JBS
>>> issue, then please file one (and I'll see that it gets moved into the JDK
>>> project quickly). I also note that tith simple javadoc changes, this can be
>>> done prior to your OCA being recorded if you like.
>>>
>>> Thanks.
>>>
>>> -- Kevin
>>>
>>>
>>>
>>>> Thanks,
>>>> Nir
>>>>
>>>>
>>>> On Tue, Jan 9, 2018 at 8:50 PM, Kevin Rushforth <
>>>> kevin.rushfo...@oracle.com <mailto:kevin.rushfo...@oracle.com>> wrote:
>>>>
>>>> Why would you even try to push a changeset without getting it
>>>> reviewed first???
>>>>
>>>> This shows a lack of understanding about our processes and
>>>> policies. Only committers have permission to push changesets, and
>>>> only after review. Please familiarize yourself with the policies
>>>> and procedures surrounding contributing to OpenJFX [1] [2] [3] [4]
>>>> [5]. Once you are familiar with these policies and have signed the
>>>> Oracle Contributor Agreement (OCA) you can work with someone to
>>>> sponsor your change.
>>>>
>>>> -- Kevin
>>>>
>>>> [1] http://openjdk.java.net/contribute/
>>>> <http://openjdk.java.net/contribute/>
>>>> [2] http://www.oracle.com/technetwork/community/oca-486395.html
>>>> <http://www.oracle.com/technetwork/community/oca-486395.html>
>>>> [3]
>>>> https://wiki.openjdk.java.net/display/OpenJFX/Submitting+a+B
>>>> ug+Report
>>>> <https://wiki.openjdk.java.net/display/OpenJFX/Submitting+a+
>>>> Bug+Report>
>>>> [4] https://wiki.openjdk.java.net/display/OpenJFX/Code+Reviews
>>>> <https://wiki.openjdk.java.net/display/OpenJFX/Code+Reviews>
>>>> [5]
>>>> https://wiki.openjdk.java.net/display/OpenJFX/Committing+the+Code
>>>> <https://wiki.openjdk.java.net/display/OpenJFX/Committing+the+Code>
>>>>
>>>>
>>>>
>>>> Nir Lisker wrote:
>>>>
>>>> Iv'e created a small documentation fix and tried to push it to
>>>> http://hg.openjdk.java.net/openjfx/jfx-dev/rt
>>>> <http://hg.openjdk.java.net/openjfx/jfx-dev/rt>. I got an
>>>> error:
>>>>
>>>> abort: push creates new remote head 2152a80ee902!
>>>> hint: pull and merge or see 'hg help push' for details about
>>>> pushing new
>>>> heads
>>>> [command returned code 255 Tue Jan 09 19:40:10 2018]
>>>>
>>>> What can be the problem?
>>>>
>>>>
>>>
>

Review request: 8194871: Fix mistakes in FX API docs

[Nir Lisker]

Hi Kevin,

Please review the attached webrev.

I addressed a few fixes I found as I was working, so they are not listed in
the JIRA report.

About Transition#getParentTargetNode:
The current behavior of parent-child relationship is that an animation can
be added to multiple parent transitions. Each parent transition will see
that animation as its child, however, the child will see only one of those
animations as its parent - the one to which is was added last. This
asymmetry is a recipe for trouble (and I argue should be addressed at some
point).
For this reason, the doc does not specify the "last one wins" behavior, so
that no contract is created. This means that it's not clear which parent is
going to be queried on each (recursive) invocation.

Most of the changes could be backported to 8 and 9. In 9, the methods
getRangeShape and getUnderlineShape of TextAreaSkin are also missing
documentation.

Re: Review request: 8194871: Fix mistakes in FX API docs

[Nir Lisker]

Thanks,


> modules/javafx.controls/src/main/java/javafx/scene/control/TableView.java:209:
> Trailing whitespace


That one is an empty line inside a code block, if it matters.

On Thu, Jan 11, 2018 at 12:14 AM, Kevin Rushforth <
kevin.rushfo...@oracle.com> wrote:

> > I'll review it, and sponsor the change. Since I will be pushing it, I
> will need one more reviewer.
>
> Actually, this is incorrect. As long as I list you as contributor, jcheck
> is perfectly happy with just me as reviewer.
>
> If anyone else wants to review it, too, that would be fine, but not
> necessary for this type of fix.
>
> -- Kevin
>
>
>
> Kevin Rushforth wrote:
>
> Thank you for providing the patch. I uploaded it to cr.openjdk.java.net
> for easy browsing:
>
> http://cr.openjdk.java.net/~kcr/8194871/webrev.00/
>
> I'll review it, and sponsor the change. Since I will be pushing it, I will
> need one more reviewer.
>
> My quick sanity checking shows trailing whitespace in two files, which
> would cause jcheck to fail:
>
> $ hg jcheck
> modules/javafx.controls/src/main/java/javafx/scene/control/TableView.java:209:
> Trailing whitespace
> modules/javafx.graphics/src/main/java/javafx/animation/Transition.java:161:
> Trailing whitespace
>
> I can fix this before I push.
>
> -- Kevin
>
>
> Nir Lisker wrote:
>
> Hi Kevin,
>
> Please review the attached webrev.
>
> I addressed a few fixes I found as I was working, so they are not listed
> in the JIRA report.
>
> About Transition#getParentTargetNode:
> The current behavior of parent-child relationship is that an animation can
> be added to multiple parent transitions. Each parent transition will see
> that animation as its child, however, the child will see only one of those
> animations as its parent - the one to which is was added last. This
> asymmetry is a recipe for trouble (and I argue should be addressed at some
> point).
> For this reason, the doc does not specify the "last one wins" behavior, so
> that no contract is created. This means that it's not clear which parent is
> going to be queried on each (recursive) invocation.
>
> Most of the changes could be backported to 8 and 9. In 9, the methods
> getRangeShape and getUnderlineShape of TextAreaSkin are also missing
> documentation.
>
>

Re: Review request: 8194871: Fix mistakes in FX API docs

[Nir Lisker]

Yes, I initially had it as a note in the end saying something like this:

 Note that for nodes in a 3D Scene (or SubScene), layoutBounds is
cuboid.

but thought that for someone working with 3D, seeing a 2D discussion all
the way until the end will be confusing. (Also thought about putting a
footnote at the end of the first sentence, but that's not a recommended
style as far as I know.)
My only slight concern is that "3D shapes" might hint at the Shape3D class,
while any node in a 3D environment will have 3D bounds. This is also a
technicality, so I wouldn't mind either way. Feel free to make a final
verdict.

On Thu, Jan 11, 2018 at 1:17 AM, Kevin Rushforth <kevin.rushfo...@oracle.com
> wrote:

> The changes look good to me for the most part. I only have one comment.
>
> Node.java:
>
> - * The rectangular bounds that should be used for layout ...
> + * The rectangular (cuboid for 3D nodes) bounds that should be used
> for layout ...
>
> While technically correct, in that the layout bounds of a TriangleMesh or
> Sphere will be a 3D bounds, layout is a 2D operation, so this seems a bit
> misleading. If you still feel that a comment is desired, then I would
> recommend it not being in the opening sentence, but rather a note later in
> the description...something like:
>
> Note that for 3D shapes, the layout bounds is actually a rectangular
> box with X, Y, and Z values, although only X and Y are used in layout
> calculations.
>
>
> -- Kevin
>
>
> Kevin Rushforth wrote:
>
> I just removed the trailing whitespace (using the handy
> tools/scripts/checkWhiteSpace script with the '-F' option).
>
> -- Kevin
>
>
> Nir Lisker wrote:
>
> Thanks,
>
>
>> modules/javafx.controls/src/main/java/javafx/scene/control/TableView.java:209:
>> Trailing whitespace
>
>
> That one is an empty line inside a code block, if it matters.
>
> On Thu, Jan 11, 2018 at 12:14 AM, Kevin Rushforth <
> kevin.rushfo...@oracle.com> wrote:
>
>> > I'll review it, and sponsor the change. Since I will be pushing it, I
>> will need one more reviewer.
>>
>> Actually, this is incorrect. As long as I list you as contributor, jcheck
>> is perfectly happy with just me as reviewer.
>>
>> If anyone else wants to review it, too, that would be fine, but not
>> necessary for this type of fix.
>>
>> -- Kevin
>>
>>
>>
>> Kevin Rushforth wrote:
>>
>> Thank you for providing the patch. I uploaded it to cr.openjdk.java.net
>> for easy browsing:
>>
>> http://cr.openjdk.java.net/~kcr/8194871/webrev.00/
>>
>> I'll review it, and sponsor the change. Since I will be pushing it, I
>> will need one more reviewer.
>>
>> My quick sanity checking shows trailing whitespace in two files, which
>> would cause jcheck to fail:
>>
>> $ hg jcheck
>> modules/javafx.controls/src/main/java/javafx/scene/control/TableView.java:209:
>> Trailing whitespace
>> modules/javafx.graphics/src/main/java/javafx/animation/Transition.java:161:
>> Trailing whitespace
>>
>> I can fix this before I push.
>>
>> -- Kevin
>>
>>
>> Nir Lisker wrote:
>>
>> Hi Kevin,
>>
>> Please review the attached webrev.
>>
>> I addressed a few fixes I found as I was working, so they are not listed
>> in the JIRA report.
>>
>> About Transition#getParentTargetNode:
>> The current behavior of parent-child relationship is that an animation
>> can be added to multiple parent transitions. Each parent transition will
>> see that animation as its child, however, the child will see only one of
>> those animations as its parent - the one to which is was added last. This
>> asymmetry is a recipe for trouble (and I argue should be addressed at some
>> point).
>> For this reason, the doc does not specify the "last one wins" behavior,
>> so that no contract is created. This means that it's not clear which parent
>> is going to be queried on each (recursive) invocation.
>>
>> Most of the changes could be backported to 8 and 9. In 9, the methods
>> getRangeShape and getUnderlineShape of TextAreaSkin are also missing
>> documentation.
>>
>>
>

Instructions for working on OpenJFX

[Nir Lisker]

Hello,

I have OpenJFX and OpenJDK built. I have also set up TortoiseHg and am
working with Eclipse. I have several questions:

1. Are the instructions at
https://wiki.openjdk.java.net/display/OpenJFX/Using+an+IDE still valid from
JDK 8? There are old TODOs there. If not, can I get a quick update?

2. After importing the projects to Eclipse and working on the source, what
steps need to be taken when the changes are to:
a. only the docs?
b. Java code?
c. Prism code?
Do I need to rebuild the JDK with JavaFX, rebuild only JavaFX, only compile
etc? What tests do I need to run (e.g., I doubt I need to run regression
tests when changing JavaDocs)?

3. Eclipse uses EJC (which I never had trouble with). Can this cause
trouble?

4. After creating a local changeset and assuming there is already a JIRA
issue for it and the fix approach was discussed, can I just push it and it
will enter a review queue? Do I need to ask someone specifically for a
review on the changeset (
https://wiki.openjdk.java.net/display/OpenJFX/Code+Ownership is old...)?

Thanks,
Nir

Re: fx 1.x issues in JBS

[Nir Lisker]

I see, was not aware that there are enough similarities between 1.x and
later versions. About Resolved issues, I thought that they are waiting for
a fix confirmation to be Closed.

On Mon, Jan 15, 2018 at 5:29 PM, Kevin Rushforth <kevin.rushfo...@oracle.com
> wrote:

> While I suspect many of them can be closed out at this point, it is not
> necessarily a given that they are irrelevant (the scene graph, animation,
> and graphics engine evolved from 1.x to 2.0). I agree that it would be good
> to take a pass over them and close out the ones that are no longer issues,
> but I they can't simply be closed out as a bulk close operation without
> looking at them.
>
> Also, you say "a lot in resolved" my response would be that I hope so. An
> issue that is resolved needs no more action and won't show up in searches
> for open bugs. So I guess I'm not sure what you mean by this.
>
> -- Kevin
>
>
>
> Nir Lisker wrote:
>
>> Hello,
>>
>> JBS still has open issues for JavaFX 1 versions and they appear in
>> searches
>> even though there's nothing to do about them since that version is not
>> supported anymore. Is it appropriate to close them all? There are also a
>> lot in Resolved.
>>
>> - Nir
>>
>>
>

fx 1.x issues in JBS

[Nir Lisker]

Hello,

JBS still has open issues for JavaFX 1 versions and they appear in searches
even though there's nothing to do about them since that version is not
supported anymore. Is it appropriate to close them all? There are also a
lot in Resolved.

- Nir

Re: Instructions for working on OpenJFX

[Nir Lisker]

Submitted 9052392 to fix Eclipse config files.

On Thu, Jan 25, 2018 at 1:22 AM, Kevin Rushforth <kevin.rushfo...@oracle.com
> wrote:

> Yes, the IDE configs are for developer convenience only. You can feel free
> to ignore them.
>
> If someone wants to cleanup the Eclipse IDE files, that would be fine, too.
>
>
> -- Kevin
>
>
> Nir Lisker wrote:
>
> If you're still catching up, I would like to verify that I should ignore
> project-level errors from the IDE. For example, Eclipse complains about the
> graphics project:
>
> Project 'graphics' is missing required source folder:
> 'build/resources/jsl-decora'
> Project 'graphics' is missing required source folder:
> 'build/resources/jsl-prism'
>
> and about the buildSource project:
>
> Project 'buildSrc' is missing required library:
> '...\rt\build\libs\ant-1.8.2.jar'
> Project 'buildSrc' is missing required library:
> '...\rt\build\libs\antlr-3.1.3.jar'
> Project 'buildSrc' is missing required library: '...\rt\build\libs\antlr-
> runtime-3.1.3.jar'
> Project 'buildSrc' is missing required library: '...\rt\build\libs\
> stringtemplate-3.2.jar'
> Project 'buildSrc' is missing required source folder: 'src/main/java'
> Project 'buildSrc' is missing required source folder: 'src/test/java'
>
> As long as the gradle tasks complete successfully I can ignore all that?
>
> - Nir
>
> On Fri, Jan 19, 2018 at 2:10 AM, Kevin Rushforth <
> kevin.rushfo...@oracle.com> wrote:
>
>> I'm still a little behind on my email, but here are some quick answers.
>>
>> #1 - The NetBeans instructions are still mostly correct except that with
>> FX 9 or later you can't compile or run code from within the IDE any more
>> (and there isn't yet a release of NetBeans 9). Not sure about the other
>> IDEs, but I suspect they are somewhat out of date.
>>
>>
>> #2. You should be able to build just the FX bits (outside your IDE) using:
>>
>>gradle sdk
>> -or-
>>gradle javadoc
>>
>> depending on what you want to do (or you can build both targets). If you
>> have a build of JDK 9 or later with FX bits in it, then you can use the
>> build/run.args script to run with the just-built FX bits without rebuilding
>> the JDK.
>>
>> java @build/run.args ...
>>
>>
>> #3. I don't know since I don't use Eclipse; maybe someone on the list who
>> uses Eclipse can answer. It might have to do with the level of JDK 9
>> support in Eclipse
>>
>>
>> #4 - previously answered
>>
>> -- Kevin
>>
>>
>> Nir Lisker wrote:
>>
>>> Hello,
>>>
>>> I have OpenJFX and OpenJDK built. I have also set up TortoiseHg and am
>>> working with Eclipse. I have several questions:
>>>
>>> 1. Are the instructions at
>>> https://wiki.openjdk.java.net/display/OpenJFX/Using+an+IDE still valid
>>> from
>>> JDK 8? There are old TODOs there. If not, can I get a quick update?
>>>
>>> 2. After importing the projects to Eclipse and working on the source,
>>> what
>>> steps need to be taken when the changes are to:
>>> a. only the docs?
>>> b. Java code?
>>> c. Prism code?
>>> Do I need to rebuild the JDK with JavaFX, rebuild only JavaFX, only
>>> compile
>>> etc? What tests do I need to run (e.g., I doubt I need to run regression
>>> tests when changing JavaDocs)?
>>>
>>> 3. Eclipse uses EJC (which I never had trouble with). Can this cause
>>> trouble?
>>>
>>> 4. After creating a local changeset and assuming there is already a JIRA
>>> issue for it and the fix approach was discussed, can I just push it and
>>> it
>>> will enter a review queue? Do I need to ask someone specifically for a
>>> review on the changeset (
>>> https://wiki.openjdk.java.net/display/OpenJFX/Code+Ownership is old...)?
>>>
>>> Thanks,
>>> Nir
>>>
>>>
>>
>

JDK-8196130: Eclipse configuration files need to be updated

[Nir Lisker]

Iv'e removed all the classpath dependencies that were causing errors. I
don't mind sorting out the rest of the files while at it, though for that
there are a few things I'm not sure about:

1. Some dependencies are marked as optional and as such they don't cause
errors, but they are still missing. Is it safe to remove them or is it
possible that they will be created as some point?
Examples are the 'base' module with "src/test/resources"
and "src/main/resources" optional dependencies, and 'controls' module has
the optional dependency "src/main/resources" commented out.

2. Can I assume that all other dependencies are really needed? (Eclipse
won't complain about unused ones as far as I know.)

3. What are the formatting standards for XML (indentation, line length...)?
>From a quick look I see different styles in different files.

- Nir

Re: JDK-8196130: Eclipse configuration files need to be updated

[Nir Lisker]

So this is why I was asking about the optional stuff: 'graphics' module has
BOTH

build/resources/jsl-decora
build/resources/jsl-prism

and

build/gensrc/jsl-decora
build/gensrc/jsl-prism

That led me to think that when the new dependencies were added the old ones
weren't removed. Those that weren't optional (like the /resources ones,
which I removed) were easy to catch and we could have finished here. Those
that are optional are not causing trouble even when missing because they
are optional.

gradle sdk does not create the ones which are marked optional that Iv'e
surveyed, but I don't know if that's the only way they can be created. If I
compare solely with gradle sdk then I can just remove whatever is missing
on grounds that it's left over.

- Nir

On Thu, Jan 25, 2018 at 4:06 PM, Kevin Rushforth <kevin.rushfo...@oracle.com
> wrote:

> One more thing about the specific path you mentioned as not being there.
>
> 
> 
>
> These are still being created by 'gradle sdk', but the path is wrong (the
> files moved in JDK 9) and should be:
>
> build/gensrc/jsl-decora
> build/gensrc/jsl-prism
>
> You might want to take that into account.
>
> -- Kevin
>
>
>
> Kevin Rushforth wrote:
>
>>
>>
>> Nir Lisker wrote:
>>
>>> Iv'e removed all the classpath dependencies that were causing errors. I
>>> don't mind sorting out the rest of the files while at it, though for that
>>> there are a few things I'm not sure about:
>>>
>>> 1. Some dependencies are marked as optional and as such they don't cause
>>> errors, but they are still missing. Is it safe to remove them or is it
>>> possible that they will be created as some point?
>>>
>>
>> Some of them might be created...not sure without checking. I recommend
>> running "gradle sdk" and then seeing if the dependencies are there.
>>
>> Examples are the 'base' module with "src/test/resources" and
>>> "src/main/resources" optional dependencies, and 'controls' module has the
>>> optional dependency "src/main/resources" commented out.
>>>
>>
>> I see. You might as well leave them, but it probably doesn't matter.
>>
>> 2. Can I assume that all other dependencies are really needed? (Eclipse
>>> won't complain about unused ones as far as I know.)
>>>
>>
>> That seems best.
>>
>> 3. What are the formatting standards for XML (indentation, line
>>> length...)? From a quick look I see different styles in different files.
>>>
>>
>> For IDE files, we don't worry about formatting. In many cases they are
>> auto-generated anyway.
>>
>> -- Kevin
>>
>>
>>> - Nir
>>>
>>

Re: JDK-8196130: Eclipse configuration files need to be updated

[Nir Lisker]

>
> rt/modules/javafx.base/build/classes/main/javafx.base/
> rt/modules/javafx.base/src/main/java/


Why not rely on source first?

Another question as I move along: there are imports from java.util.logging
in base module, but the module-info doesn't require java.logging. How do I
give access to these imports?

On Tue, Jan 30, 2018 at 9:03 PM, Kevin Rushforth <kevin.rushfo...@oracle.com
> wrote:

> Oh, I see. You are pointing to the exploded modules  for the JDK in
> build/X/jdk rather than the JDK image in build/X/images/jdk.
>
> Yes, I think it would be preferable to both reverse the order and also add
> in the location of the built class files. So the following order seems best:
>
> rt/modules/javafx.base/build/classes/main/javafx.base/
> rt/modules/javafx.base/src/main/java/
> jdk/modules/javafx.base
>
>
> -- Kevin
>
>
> Nir Lisker wrote:
>
> This is what I mean: In the type /base/src/test/java/test/
> com/sun/javafx/collections/ListListenerHelperTest.java there are these
> imports:
>
> import test.javafx.collections.MockListObserver;
> import java.util.BitSet;
> import javafx.beans.Observable;
>
> The first one is the one in FX: rt\modules\javafx.base\
> src\test\java\test\javafx\collections\MockListObserver.java
> The second one is in the referenced JDK which was built with
> FX: jdk\modules\java.base\java\util\BitSet.class
> The third one exists in both:
> - in JFX it's in: rt\modules\javafx.base\src\main\java\javafx\beans\
> Observable.java
> - in the JDK it's in: jdk\modules\javafx.base\
> javafx\beans\Observable.class
>
> Does the question make sense now?
>
> On Tue, Jan 30, 2018 at 5:04 AM, Kevin Rushforth <
> kevin.rushfo...@oracle.com> wrote:
>
>>
>> one in 
>> "rt\modules\javafx.base\src\main\java\javafx\beans\InvalidationListener.java"
>> or the one in "jdk\modules\javafx.base\javafx\beans\InvalidationListener.
>> class"?
>>
>>
>> Not sure I get what you mean. There isn't a jdk/modules/ directory
>> created by the build. Perhaps this is an Eclipse construct that it uses to
>> indicate the modules that are in the JDK that you are using? The FX build
>> puts the class files in:
>>
>> rt/build/modular_sdk/modules/javafx.base/...
>>
>>
>> -- Kevin
>>
>>
>> Nir Lisker wrote:
>>
>> Another question: do imports of javafx.* packages point to the javafx
>> source or to the jdk compilation?
>>
>> For example, in the base module, the type 
>> test.javafx.beans.InvalidationListenerMock
>> imports javafx.beans.InvalidationListener (twice, by the way, along with
>> Observable). Should the imported class be the one in
>> "rt\modules\javafx.base\src\main\java\javafx\beans\InvalidationListener.java"
>> or the one in "jdk\modules\javafx.base\javafx\beans\InvalidationListener.
>> class"?
>>
>> Currently, the way it is in the Eclipse files is that the jdk .class
>> files are imported first[1], but it seemed odd to me - if I work on 2 files
>> which depend on each other they should see the changes in each other at
>> once.
>>
>> [1]http://hg.openjdk.java.net/openjfx/jfx-dev/rt/file/305d12
>> 7c6ed5/modules/javafx.base/.classpath ("JRE_CONTAINER" is before
>> "src/main/java"),
>>
>> - Nir
>>
>> On Fri, Jan 26, 2018 at 9:20 PM, Kevin Rushforth <
>> kevin.rushfo...@oracle.com> wrote:
>>
>>> inline
>>>
>>> Nir Lisker wrote:
>>>
>>> Alright, cleaned that part. fxpackager build fails with an internal NPE
>>> in Eclipse, so I'm going to leave that alone and all of the projects that
>>> depends on it.
>>>
>>> Now that projects can be built there are errors in deeper levels:
>>>
>>> 1. All org.junit imports cannot be resolved. This causes tons of errors
>>> in various test folders obviously. All the .classpath files use
>>>
>>> 
>>>
>>> which is a jar distributed with Eclipse (in the plugins folder) with
>>> version 4.12.0. Is this really where the imports are supposed to come from?
>>> How does it work in Netbeans or IntelliJ?
>>>
>>>
>>> For NetBeans we use their internal version of JUnit. I don't know about
>>> IntelliJ (maybe someone else on the list can answer that).
>>>
>>> 2. In the 'base' module, in "/src/main/java-jfr/com/sun/javafx/logging"
>>> there are imports of com.oracle.jrockit.jfr that can't be resolved. Where
>>> are these located?
>>>
>>>
>>> These

Re: JDK-8196130: Eclipse configuration files need to be updated

[Nir Lisker]

Alright, got most of them ready.

About buildSrc:
- What is
"rt\buildSrc\build\generated-src\antlr\com\sun\scenario\effect\compiler"
supposed to be? It is listed as a source folder but it's empty.
- The project lists dependencies such as "build/libs/swt-debug.jar", JUnit
and a JRE/JDK, but doesn't need any of them (from Eclipse's point of view).
I see the base module listing this project as a dependency, but it's not
used. Where is it located in the dependency chain?

On Thu, Feb 1, 2018 at 9:48 PM, Kevin Rushforth <kevin.rushfo...@oracle.com>
wrote:

> It probably makes sense to submit what you have now as a partially working
> solution.
>
> As for Eclipse making any changes, I'm not sure there is a spec you could
> point to ... we do some of the same magic that I'm sure other projects have
> had to do w.r.t running tests:
>
> * We have test "shims" for white-box testing that we add into our modules
> when running tests (this requires copying all of the class files for our
> modules and adding the shim classes on top of that)
>
> * We build the tests separately (the tests are in a separate source set in
> gradle) without a module-info so that they run in the unnamed module. This
> allows them to access JUnit, etc., as well as any public package of any
> module in the system. As such we need to explicitly list any internal
> packages that they use from the module they are testing. These are listed
> in src/test/addExports
>
>
> -- Kevin
>
>
> Nir Lisker wrote:
>
> Looks like I understood the problem. Eclipse does not support (yet)
> multiple modules per project. Do you know any specifications I can point
> them to to fix this properly?
>
> The current workaround would be to add 'requires' for all the modules
> which are used in tests as well. This change is local and would be excluded
> from webrevs.
>
> At this point I can either submit the partially fixed Eclipse files, which
> work with main code fully and with test code only if the above fix is used;
> or wait until Eclipse sorts it out.
>
> On Wed, Jan 31, 2018 at 4:21 PM, Kevin Rushforth <
> kevin.rushfo...@oracle.com> wrote:
>
>>
>>
>> Nir Lisker wrote:
>>
>> rt/modules/javafx.base/build/classes/main/javafx.base/
>>> rt/modules/javafx.base/src/main/java/
>>
>>
>> Why not rely on source first?
>>
>>
>> Yes, that might work...you could try switching the order.
>>
>>
>>
>> Another question as I move along: there are imports
>> from java.util.logging in base module, but the module-info doesn't
>> require java.logging. How do I give access to these imports?
>>
>>
>> The only references to java.util.logging are in the javafx.base unit
>> tests, which are compiled and run in the unnamed modules (no
>> module-info.java for the unit tests).
>>
>> -- Kevin
>>
>>
>>
>> On Tue, Jan 30, 2018 at 9:03 PM, Kevin Rushforth <
>> kevin.rushfo...@oracle.com> wrote:
>>
>>> Oh, I see. You are pointing to the exploded modules  for the JDK in
>>> build/X/jdk rather than the JDK image in build/X/images/jdk.
>>>
>>> Yes, I think it would be preferable to both reverse the order and also
>>> add in the location of the built class files. So the following order seems
>>> best:
>>>
>>> rt/modules/javafx.base/build/classes/main/javafx.base/
>>> rt/modules/javafx.base/src/main/java/
>>> jdk/modules/javafx.base
>>>
>>>
>>> -- Kevin
>>>
>>>
>>> Nir Lisker wrote:
>>>
>>> This is what I mean: In the type /base/src/test/java/test/
>>> com/sun/javafx/collections/ListListenerHelperTest.java there are these
>>> imports:
>>>
>>> import test.javafx.collections.MockListObserver;
>>> import java.util.BitSet;
>>> import javafx.beans.Observable;
>>>
>>> The first one is the one in FX: rt\modules\javafx.base\src
>>> \test\java\test\javafx\collections\MockListObserver.java
>>> The second one is in the referenced JDK which was built with
>>> FX: jdk\modules\java.base\java\util\BitSet.class
>>> The third one exists in both:
>>> - in JFX it's in: rt\modules\javafx.base\src\mai
>>> n\java\javafx\beans\Observable.java
>>> - in the JDK it's in: jdk\modules\javafx.base\ja
>>> vafx\beans\Observable.class
>>>
>>> Does the question make sense now?
>>>
>>> On Tue, Jan 30, 2018 at 5:04 AM, Kevin Rushforth <
>>> kevin.rushfo...@oracle.com> wrote:
>>>
>>>>
>>&

Re: JDK-8196130: Eclipse configuration files need to be updated

[Nir Lisker]

Another question: do imports of javafx.* packages point to the javafx
source or to the jdk compilation?

For example, in the base module, the type
test.javafx.beans.InvalidationListenerMock
imports javafx.beans.InvalidationListener (twice, by the way, along with
Observable). Should the imported class be the one in
"rt\modules\javafx.base\src\main\java\javafx\beans\InvalidationListener.java"
or the one in
"jdk\modules\javafx.base\javafx\beans\InvalidationListener.class"?

Currently, the way it is in the Eclipse files is that the jdk .class files
are imported first[1], but it seemed odd to me - if I work on 2 files which
depend on each other they should see the changes in each other at once.

[1]
http://hg.openjdk.java.net/openjfx/jfx-dev/rt/file/305d127c6ed5/modules/javafx.base/.classpath
("JRE_CONTAINER" is before "src/main/java"),

- Nir

On Fri, Jan 26, 2018 at 9:20 PM, Kevin Rushforth <kevin.rushfo...@oracle.com
> wrote:

> inline
>
> Nir Lisker wrote:
>
> Alright, cleaned that part. fxpackager build fails with an internal NPE in
> Eclipse, so I'm going to leave that alone and all of the projects that
> depends on it.
>
> Now that projects can be built there are errors in deeper levels:
>
> 1. All org.junit imports cannot be resolved. This causes tons of errors in
> various test folders obviously. All the .classpath files use
>
> 
>
> which is a jar distributed with Eclipse (in the plugins folder) with
> version 4.12.0. Is this really where the imports are supposed to come from?
> How does it work in Netbeans or IntelliJ?
>
>
> For NetBeans we use their internal version of JUnit. I don't know about
> IntelliJ (maybe someone else on the list can answer that).
>
> 2. In the 'base' module, in "/src/main/java-jfr/com/sun/javafx/logging"
> there are imports of com.oracle.jrockit.jfr that can't be resolved. Where
> are these located?
>
>
> These classes used to be part of the JFR commercial feature in the Oracle
> JDK. The java-jfr sources are obsolete and no longer built (and no longer
> buildable), so you can safely remove it from your IDE files. I also still
> see references to it in the netbeans/base project. I will file a bug to
> remove this obsolete code and fix the NetBeans references at the same time.
>
> -- Kevin
>
>
>
> On Thu, Jan 25, 2018 at 5:24 PM, Kevin Rushforth <
> kevin.rushfo...@oracle.com> wrote:
>
>> Ah, I see. Then yes, just removing the old ones is fine.
>>
>> As for the larger question, unless there are dependencies on apps, you
>> can assume that the only ones you care about are the ones created by
>> "gradle sdk".
>>
>> -- Kevin
>>
>>
>>
>> Nir Lisker wrote:
>>
>> So this is why I was asking about the optional stuff: 'graphics' module
>> has BOTH
>>
>> build/resources/jsl-decora
>> build/resources/jsl-prism
>>
>> and
>>
>> build/gensrc/jsl-decora
>> build/gensrc/jsl-prism
>>
>> That led me to think that when the new dependencies were added the old
>> ones weren't removed. Those that weren't optional (like the /resources
>> ones, which I removed) were easy to catch and we could have finished here.
>> Those that are optional are not causing trouble even when missing because
>> they are optional.
>>
>> gradle sdk does not create the ones which are marked optional that Iv'e
>> surveyed, but I don't know if that's the only way they can be created. If I
>> compare solely with gradle sdk then I can just remove whatever is missing
>> on grounds that it's left over.
>>
>> - Nir
>>
>> On Thu, Jan 25, 2018 at 4:06 PM, Kevin Rushforth <
>> kevin.rushfo...@oracle.com> wrote:
>>
>>> One more thing about the specific path you mentioned as not being there.
>>>
>>> 
>>> 
>>>
>>> These are still being created by 'gradle sdk', but the path is wrong
>>> (the files moved in JDK 9) and should be:
>>>
>>> build/gensrc/jsl-decora
>>> build/gensrc/jsl-prism
>>>
>>> You might want to take that into account.
>>>
>>> -- Kevin
>>>
>>>
>>>
>>> Kevin Rushforth wrote:
>>>
>>>>
>>>>
>>>> Nir Lisker wrote:
>>>>
>>>>> Iv'e removed all the classpath dependencies that were causing errors.
>>>>> I don't mind sorting out the rest of the files while at it, though for 
>>>>> that
>>>>> there are a few things I'm not sure about:
>>>>>
>>>>> 1. Some dependencies are marked as optional and as s

Re: More community participation in JavaFX

[Nir Lisker]

 Hello,

As someone who has recently made the climb and managed to build OpenJFX
with OpenJDK on Win 10 I might have some relevant input.

--- Building OpenJFX ---

* With the recently updated instructions on the Wiki, building OpenJFX is
not that hard. Having to build OpenJDK for that was a real headache because
their instructions and build tools are not up to date (
https://bugs.openjdk.java.net/browse/JDK-8194645).
* The above doesn't mean that the process shouldn't be made easier.
Ideally, it would be the as easy as working on most open source projects on
Github (not advocating git over hg): clone into the IDE and start working;
when a fix is ready, submit a PR. Don't know if it's technically possible
in this case, but it's a target.
* The repository needs a good cleanup before contributors start cloning (
bugs.openjdk.java.net/browse/JDK-8196198).

--- Working on OpenJFX ---

* It should be clear which tests need to run for a specific patch. Changes
can be made anywhere from the documentation level to native code level and
there's no reason to run the same tests for all of these. If the process
can be automate it's even better.
* The Webrev tool seems archaic to me (and part of its output is broken as
far as I could tell). An IDE can create diff patches with a couple of
clicks.
* The Jcheck tool seems archaic to me. It should be ported to IDE
formatters which are to be distributed with the source. No reason to run a
tool that tells me which whitespaces I need to go back and change when
something like Ctrl+Shift+F in an IDE finishes the job.

--- Wiki ---

* The Wiki could be open sourced as well (like other Wikis). I could
definitely update a page or 2 there and so would other developers as they
gain knowledge. I don't know yet how permissions for that should be handled.
* Code conventions should be clearly listed.
* Separate sections with instructions should be made for: (1) cloning and
building, (2) modifying, (3) running tests, (4) submitting, and (5)
reviewing.
* Old sections should be cleaned up (I don't think Discussions is useful
anymore).

--- Review policy ---

* I have no experience with review policies or project roles so I can't
help here much (maybe after a discussion starts).
* One thing I do know is that reviewers should be extremely knowledgeable,
which means that there aren't many qualified. Because of this, if it
becomes "too" easy to contribute to OpenJFX, careful measures need to be
taken as to not to swamp the few reviewers with many patches (though some
would say this is an ideal situation). Some sort of review queue might help
with organization instead of the current email system. I have no concrete
solution for this.

- Nir


Message: 1
> Date: Thu, 01 Feb 2018 15:26:24 -0800
> From: Kevin Rushforth 
> To: "openjfx-dev@openjdk.java.net" 
> Subject: More community participation in JavaFX
> Message-ID: <5a73a220.7030...@oracle.com>
> Content-Type: text/plain; charset=windows-1252; format=flowed
>
> To: OpenJFX Developers
>
> We are looking to grow the community of contributors to the OpenJFX
> project, especially serious contributors who will stick around long
> enough to become reviewers, to help us keep the platform vibrant. To
> this end we are looking at ways to encourage more participation and make
> it easier for interested folks to contribute.
>
> We are specifically looking to discuss ideas around the following areas:
>
> * Easing barriers to contribution (e.g., making JavaFX easier to build,
> better documentation, making it easier to test changes)
>
> * Code review policies
>
> * API / feature review policies
>
> * Code review tools (we currently use webrev, but that isn't set in stone)
>
>
> To keep this thread productive, the following are explicitly out of scope:
>
> * Discussion of specific features or bugs that you would like to
> implement (or wish someone else would)
>
> * Discussion about platform support
>
> * Discussion about version control systems (e.g., hg versus git),
> hosting of the OpenJFX repos and bug database (e.g., OpenJDK versus
> github), etc...at least for now. We are aware of the potential benefits
> of such changes, but we'd like to focus our efforts on higher-leverage
> things we can do in the short term.
>
> * Discussion about the requirement of a signed OCA to become a contributor
>
> * Off-topic or tangential commentary about OpenJFX that isn't directly
> related to the topic at hand
>
>
> As a starting point for discussion, here are some areas I think need
> improvement; I'm sure there are others:
>
> I. Helping contributors get started
>
> It isn?t as easy to get started with OpenJFX as it should be. We want to
> make it easier for potential OpenJFX contributors to get started. Here
> are some ideas that I think might help:
>
> * Improve the build instructions / Wiki (I made a first start, but there
> is much more to be done)
>
> * Make the build itself more resilient where 

Re: JDK-8196130: Eclipse configuration files need to be updated

[Nir Lisker]

This is what I mean: In the
type 
/base/src/test/java/test/com/sun/javafx/collections/ListListenerHelperTest.java
there are these imports:

import test.javafx.collections.MockListObserver;
import java.util.BitSet;
import javafx.beans.Observable;

The first one is the one in
FX: 
rt\modules\javafx.base\src\test\java\test\javafx\collections\MockListObserver.java
The second one is in the referenced JDK which was built with
FX: jdk\modules\java.base\java\util\BitSet.class
The third one exists in both:
- in JFX it's in:
rt\modules\javafx.base\src\main\java\javafx\beans\Observable.java
- in the JDK it's in: jdk\modules\javafx.base\javafx\beans\Observable.class

Does the question make sense now?

On Tue, Jan 30, 2018 at 5:04 AM, Kevin Rushforth <kevin.rushfo...@oracle.com
> wrote:

>
> one in 
> "rt\modules\javafx.base\src\main\java\javafx\beans\InvalidationListener.java"
> or the one in "jdk\modules\javafx.base\javafx\beans\
> InvalidationListener.class"?
>
>
> Not sure I get what you mean. There isn't a jdk/modules/ directory created
> by the build. Perhaps this is an Eclipse construct that it uses to indicate
> the modules that are in the JDK that you are using? The FX build puts the
> class files in:
>
> rt/build/modular_sdk/modules/javafx.base/...
>
>
> -- Kevin
>
>
> Nir Lisker wrote:
>
> Another question: do imports of javafx.* packages point to the javafx
> source or to the jdk compilation?
>
> For example, in the base module, the type 
> test.javafx.beans.InvalidationListenerMock
> imports javafx.beans.InvalidationListener (twice, by the way, along with
> Observable). Should the imported class be the one in
> "rt\modules\javafx.base\src\main\java\javafx\beans\InvalidationListener.java"
> or the one in "jdk\modules\javafx.base\javafx\beans\
> InvalidationListener.class"?
>
> Currently, the way it is in the Eclipse files is that the jdk .class files
> are imported first[1], but it seemed odd to me - if I work on 2 files which
> depend on each other they should see the changes in each other at once.
>
> [1]http://hg.openjdk.java.net/openjfx/jfx-dev/rt/file/
> 305d127c6ed5/modules/javafx.base/.classpath ("JRE_CONTAINER" is before
> "src/main/java"),
>
> - Nir
>
> On Fri, Jan 26, 2018 at 9:20 PM, Kevin Rushforth <
> kevin.rushfo...@oracle.com> wrote:
>
>> inline
>>
>> Nir Lisker wrote:
>>
>> Alright, cleaned that part. fxpackager build fails with an internal NPE
>> in Eclipse, so I'm going to leave that alone and all of the projects that
>> depends on it.
>>
>> Now that projects can be built there are errors in deeper levels:
>>
>> 1. All org.junit imports cannot be resolved. This causes tons of errors
>> in various test folders obviously. All the .classpath files use
>>
>> 
>>
>> which is a jar distributed with Eclipse (in the plugins folder) with
>> version 4.12.0. Is this really where the imports are supposed to come from?
>> How does it work in Netbeans or IntelliJ?
>>
>>
>> For NetBeans we use their internal version of JUnit. I don't know about
>> IntelliJ (maybe someone else on the list can answer that).
>>
>> 2. In the 'base' module, in "/src/main/java-jfr/com/sun/javafx/logging"
>> there are imports of com.oracle.jrockit.jfr that can't be resolved. Where
>> are these located?
>>
>>
>> These classes used to be part of the JFR commercial feature in the Oracle
>> JDK. The java-jfr sources are obsolete and no longer built (and no longer
>> buildable), so you can safely remove it from your IDE files. I also still
>> see references to it in the netbeans/base project. I will file a bug to
>> remove this obsolete code and fix the NetBeans references at the same time.
>>
>> -- Kevin
>>
>>
>>
>> On Thu, Jan 25, 2018 at 5:24 PM, Kevin Rushforth <
>> kevin.rushfo...@oracle.com> wrote:
>>
>>> Ah, I see. Then yes, just removing the old ones is fine.
>>>
>>> As for the larger question, unless there are dependencies on apps, you
>>> can assume that the only ones you care about are the ones created by
>>> "gradle sdk".
>>>
>>> -- Kevin
>>>
>>>
>>>
>>> Nir Lisker wrote:
>>>
>>> So this is why I was asking about the optional stuff: 'graphics' module
>>> has BOTH
>>>
>>> build/resources/jsl-decora
>>> build/resources/jsl-prism
>>>
>>> and
>>>
>>> build/gensrc/jsl-decora
>>> build/gensrc/jsl-prism
>>>
>>> That led me to think that when the ne

Re: More community participation in JavaFX

[Nir Lisker]

So if a community ran GitHub is used for staging, who will approve PRs for
the code and the Wiki of the GitHub repo?

On Mon, Feb 5, 2018 at 2:40 AM, Michael Ennen <mike.en...@gmail.com> wrote:

> Great points, Nir. We share the same hopes. I just wanted to piggy-back on
> the
> wiki thing:
>
> " * The Wiki could be open sourced as well (like other Wikis). I could
> definitely update a page or 2 there and so would other developers as they
> gain knowledge. I don't know yet how permissions for that should be
> handled."
>
> This is another thing that we could use the GitHub staging repository for.
> The staging repository could have a wiki (projects on GitHub can have one)
> that is editable by all, and then maybe once a month or so someone with
> permissions
> to edit to official wiki can sync with the new, reviewed changes (the
> once-a-month
> time constraint is very flexible).
>
> I am just trying to explain how the GitHub repository "one-way mirror"
> (potentially linked
> with/managed by Adopt an OpenJDK) can act as a staging ground for all
> kinds of contributions to
> OpenJFX.
>
> By the way, I am trying to cleanup the groundwork I did on getting
> Appveyor builds to
> run for openjfx, if indeed it is decided to setup such a staging
> repository. You can
> see my efforts here: https://raw.githubusercontent.com/brcolow/openjfx/
> f1b8978849fc371683b40931c17020421acc0057/appveyor.yml
>
> If the GitHub repository was setup, changes such as these to add CI
> infrastructure would
> never be adopted by upstream OpenJFX, but would allow for developer's to
> get good
> feedback on test results for all supported platforms when they open a PR.
> Merging a PR
> on the public GitHub repository means, in my opinion, that it is ready to
> be opened as
> an upstream bug/feature request. Automating the process with patch sets,
> webrevs, formatting/lint
> results, etc. would be the most ideal situation and I would be happy to
> contribute to these
> efforts.
>
> Regards,
>
> Michael Ennen
>
>
>
> On Sun, Feb 4, 2018 at 5:29 PM, Nir Lisker <nlis...@gmail.com> wrote:
>
>>  Hello,
>>
>> As someone who has recently made the climb and managed to build OpenJFX
>> with OpenJDK on Win 10 I might have some relevant input.
>>
>> --- Building OpenJFX ---
>>
>> * With the recently updated instructions on the Wiki, building OpenJFX is
>> not that hard. Having to build OpenJDK for that was a real headache
>> because
>> their instructions and build tools are not up to date (
>> https://bugs.openjdk.java.net/browse/JDK-8194645).
>> * The above doesn't mean that the process shouldn't be made easier.
>> Ideally, it would be the as easy as working on most open source projects
>> on
>> Github (not advocating git over hg): clone into the IDE and start working;
>> when a fix is ready, submit a PR. Don't know if it's technically possible
>> in this case, but it's a target.
>> * The repository needs a good cleanup before contributors start cloning (
>> bugs.openjdk.java.net/browse/JDK-8196198).
>>
>> --- Working on OpenJFX ---
>>
>> * It should be clear which tests need to run for a specific patch. Changes
>> can be made anywhere from the documentation level to native code level and
>> there's no reason to run the same tests for all of these. If the process
>> can be automate it's even better.
>> * The Webrev tool seems archaic to me (and part of its output is broken as
>> far as I could tell). An IDE can create diff patches with a couple of
>> clicks.
>> * The Jcheck tool seems archaic to me. It should be ported to IDE
>> formatters which are to be distributed with the source. No reason to run a
>> tool that tells me which whitespaces I need to go back and change when
>> something like Ctrl+Shift+F in an IDE finishes the job.
>>
>> --- Wiki ---
>>
>> * The Wiki could be open sourced as well (like other Wikis). I could
>> definitely update a page or 2 there and so would other developers as they
>> gain knowledge. I don't know yet how permissions for that should be
>> handled.
>> * Code conventions should be clearly listed.
>> * Separate sections with instructions should be made for: (1) cloning and
>> building, (2) modifying, (3) running tests, (4) submitting, and (5)
>> reviewing.
>> * Old sections should be cleaned up (I don't think Discussions is useful
>> anymore).
>>
>> --- Review policy ---
>>
>> * I have no experience with review policies or project roles so I can't
>> help here much (maybe after a discussion starts).
>> * One 

Re: More community participation in JavaFX

[Nir Lisker]

Another thing to be careful about with the sandbox/staging idea is the
confusion that will arise with duplication. There will be 2 issue trackers
(JBS and GitHub (or GitHub-like)), 2 repo addresses, 2 wikis, and maybe 2
discussion lists. For those "in the know" this will be a simple matter, but
for a potential contributor this can be a gamebreaker if not handled
appropriately.

Dalibor Topic's suggestion of contacting other mirrors can be instrumental
in solving these problems.

- Nir

On Mon, Feb 5, 2018 at 4:41 PM, Kevin Rushforth <kevin.rushfo...@oracle.com>
wrote:

> Yes, this sounds like a good step in the right direction. This would give
> anyone (with a signed OCA) the ability to create their own branch, commit
> changes to it, submit a PR, etc.
>
> I presume there will be a branch that is an exact mirror of the jfx-dev
> repo on OpenJDK in addition to the development branch in the sandbox?
>
> The only thing to consider is whether it should be Committers or Reviewers
> that have rights to merge into the sandbox development branch. There are
> pros / cons of each. I'd probably lean towards having it be Committers,
> with the idea that a Committer needs to sponsor the patch anyway and would
> then be able to "take it the rest of the way". The only downside I see is
> that you could end up with a few patches that get accepted into the sandbox
> dev branch, but never make it to the upstream jfx-dev repo (or not without
> significant change). I doubt this will be a big problem in practice.
>
> Either way, this could also provide a good alternative to webrev when
> reviewing the final changes.
>
> -- Kevin
>
>
>
> Johan Vos wrote:
>
>> Hi Michael,
>>
>> This proposal is very much in line with my thinking as well.
>> The problem is not that we don't have a github clone of OpenJFX. We have a
>> number of them (e.g. I created https://github.com/javafxports/jfx-dev
>> some
>> months ago). We just need a single one that is updated constantly from
>> mainstream, and standardize on that. Let's call that "sandbox" (I would be
>> ok with staging as well, but sandbox is imho more inviting to people who
>> want to try something drastic, e.g. support for Vulkan)
>>
>> The main issue is how to get contributions, review them, and eventually
>> send them upstream.
>>
>> The PR review process is extremely important. If we lower that bar, we
>> loose quality. If the bar is too high, great PR's won't be accepted
>> upstream as there is not enough review time to review it.
>>
>> I agree giving the current OpenJFX committers merge rights for the
>> "sandbox" repository makes sense. Once a public contribution is merged by
>> one of those committers, that same committer can send it upstream to the
>> existing OpenJFX repository. Additional checks will be performed there,
>> mainly in order to make sure the overall "Feel of Java" is preserved. To
>> that purpose, it would help to have a closer alignment with the OpenJDK
>> community.
>>
>> We have to be aware that this will increase the workload of the current
>> committers and reviewers. That is the price we pay for standardization.
>> Rather than everyone creating his own forks of a UI framework in Java, we
>> invest a lot in creating a single, generally agreed one.
>>
>> So in summary, I'm +1 on a 2-phase approach: "open" commits allowed in
>> staging. OpenJFX committers accept PR's (if they are of good quality) and
>> prepare upstream commits for OpenJFX. We hope there will be more
>> contributors who become committers and reviewers in the medium term.
>>
>> - Johan
>>
>> On Mon, Feb 5, 2018 at 3:57 AM Michael Ennen <mike.en...@gmail.com>
>> wrote:
>>
>>
>>
>>> Those are great questions, and I think with Kevin/Oracle/other OpenJFX
>>> devs
>>> help we
>>> can figure something out.
>>>
>>> My thinking is that the PR would be reviewed by basically anyone who has
>>> free time.
>>> I think that, at first, only OpenJFX committers will be able to merge
>>> PRs.
>>> They would
>>> do the final review/merge to the staging repo after it has been reviewed
>>> by
>>> the "wider audience"
>>> which includes people without commit rights (people like us). Then, as
>>> this
>>> thing evolves,
>>> based on the pool of people who are contributing both pull requests and
>>> PR
>>> reviews,
>>> the committers will be able to grant commit privileges to some people in
>>> that pool.
>>>
&

Re: JDK-8196130: Eclipse configuration files need to be updated

[Nir Lisker]

Attached webrev for .classpath changes for all javafx.xxx projects under
/modules (though 2 of them are not modules).

Change details:
- The files were completely rewritten for Eclipse's current modular
support, version 4.8M5, which is pre-release.
- Some projects also need to change module-info.java for test code to
identify imports properly due to bugs in Eclipse. These changes are
excluded from the Webrev.
- Since I didn't build Webkit, the web module has extra errors which I
couldn't address, so the fix does not guarantee that this module will
compile even with Webkit.
- The swt project has external org.eclipse.swt imports which weren't
addressed.

Let's call this round 1. Next rounds will be when Eclipse fixes some bugs
and when the source repo is cleaned from unused projects.

- Nir

On Fri, Feb 2, 2018 at 6:52 PM, Nir Lisker <nlis...@gmail.com> wrote:

> Alright, got most of them ready.
>
> About buildSrc:
> - What is 
> "rt\buildSrc\build\generated-src\antlr\com\sun\scenario\effect\compiler"
> supposed to be? It is listed as a source folder but it's empty.
> - The project lists dependencies such as "build/libs/swt-debug.jar", JUnit
> and a JRE/JDK, but doesn't need any of them (from Eclipse's point of view).
> I see the base module listing this project as a dependency, but it's not
> used. Where is it located in the dependency chain?
>
> On Thu, Feb 1, 2018 at 9:48 PM, Kevin Rushforth <
> kevin.rushfo...@oracle.com> wrote:
>
>> It probably makes sense to submit what you have now as a partially
>> working solution.
>>
>> As for Eclipse making any changes, I'm not sure there is a spec you could
>> point to ... we do some of the same magic that I'm sure other projects have
>> had to do w.r.t running tests:
>>
>> * We have test "shims" for white-box testing that we add into our modules
>> when running tests (this requires copying all of the class files for our
>> modules and adding the shim classes on top of that)
>>
>> * We build the tests separately (the tests are in a separate source set
>> in gradle) without a module-info so that they run in the unnamed module.
>> This allows them to access JUnit, etc., as well as any public package of
>> any module in the system. As such we need to explicitly list any internal
>> packages that they use from the module they are testing. These are listed
>> in src/test/addExports
>>
>>
>> -- Kevin
>>
>>
>> Nir Lisker wrote:
>>
>> Looks like I understood the problem. Eclipse does not support (yet)
>> multiple modules per project. Do you know any specifications I can point
>> them to to fix this properly?
>>
>> The current workaround would be to add 'requires' for all the modules
>> which are used in tests as well. This change is local and would be excluded
>> from webrevs.
>>
>> At this point I can either submit the partially fixed Eclipse files,
>> which work with main code fully and with test code only if the above fix is
>> used; or wait until Eclipse sorts it out.
>>
>> On Wed, Jan 31, 2018 at 4:21 PM, Kevin Rushforth <
>> kevin.rushfo...@oracle.com> wrote:
>>
>>>
>>>
>>> Nir Lisker wrote:
>>>
>>> rt/modules/javafx.base/build/classes/main/javafx.base/
>>>> rt/modules/javafx.base/src/main/java/
>>>
>>>
>>> Why not rely on source first?
>>>
>>>
>>> Yes, that might work...you could try switching the order.
>>>
>>>
>>>
>>> Another question as I move along: there are imports
>>> from java.util.logging in base module, but the module-info doesn't
>>> require java.logging. How do I give access to these imports?
>>>
>>>
>>> The only references to java.util.logging are in the javafx.base unit
>>> tests, which are compiled and run in the unnamed modules (no
>>> module-info.java for the unit tests).
>>>
>>> -- Kevin
>>>
>>>
>>>
>>> On Tue, Jan 30, 2018 at 9:03 PM, Kevin Rushforth <
>>> kevin.rushfo...@oracle.com> wrote:
>>>
>>>> Oh, I see. You are pointing to the exploded modules  for the JDK in
>>>> build/X/jdk rather than the JDK image in build/X/images/jdk.
>>>>
>>>> Yes, I think it would be preferable to both reverse the order and also
>>>> add in the location of the built class files. So the following order seems
>>>> best:
>>>>
>>>> rt/modules/javafx.base/build/classes/main/javafx.base/
>>>> rt/modules/javafx.base/src/main/java/
>>>>

Updating class javafx.beans.binding.When

[Nir Lisker]

Hi,

I was looking at https://bugs.openjdk.java.net/browse/JDK-8089579, which
prompted me to have a look at When. There are a few points I would like to
address:

* StringConditionBuilder#otherwise(ObservableStringValue) does not check
for null as other condition builders do. This results in a deeper NPE
when StringCondition tries to register a listener to the
ObservableStringValue.

* I would like a (re)evaluation on the above bug ticket and thoughts on the
proposal of "on demand evaluation" using a Supplier or a similar method.
The behavior of the intended implementation would be to evaluate 'then' and
'otherwise' whenever their condition is met, and only then.

* The class can benefit from some small refactoring, such as using
Objects.requireNonNull for null checks and some code reuse to reduce the
chance of bugs such as the missing null check of StringConditionBuilder.

* There are a few Javadoc corrections and some clarifications of the
current behavior could be beneficial as well.

I can work on all of the above. How to proceed?

- Nir

Additional info on JDK-8197536: TableView, ListView: unexpected scrolling behaviour on up/down keys

[Nir Lisker]

I tested the issue. It is not present in 1.8.0_152-b16, but it is present
in 9+181 and 10-ea+37.

- Nir

Re: Repositories, AdoptOpenJDK and github

[Nir Lisker]

Thank you!

My concerns (not complaints) and questions:

1. Developer forks the github repo, enhances it, and creates a PR.

2. He discusses it with a committer, and eventually the PR is accepted.


As I said before, we need to be careful where the discussion is made. PRs
on GitHub have their own thread and there's also the mailing list. Maybe
someone from Oracle already has done work related to the PR, and this will
only be known if a JBS issue is submitted or a mailing list thread is
started. Isn't this supposed to happen before starting to work on a PR even
(ideally)?

If you want to contribute, you can create PR's. The idea is that OpenJFX
> committers can merge PR's in this repository.


Are these PRs linked/related in some way to JBS? Currently, one would
submit a JIRA ticket, then work under that roof. Is that something the
committer will do after the PR has been merged?

How would you verify the identity of committers (or contributors for the
purpose of OCA) for GitHub? If I become a committer, I wouldn't want
someone to create an account with my name and ask you to give them
committer rights.

Generally, as a non-committer, is it intended that I'll be able to work
through both Oracle's and GitHub's channels? For one issue I can submit a
PR and have a committer handle the webrev in my name, and for another issue
I can do it myself?

- Nir

Re: Updating class javafx.beans.binding.When

[Nir Lisker]

Iv'e managed to refactor a large portion of the class. About a 1/3 of the
(repetitious) code was removed.

On Tue, Feb 6, 2018 at 1:08 AM, Nir Lisker <nlis...@gmail.com> wrote:

> Hi,
>
> I was looking at https://bugs.openjdk.java.net/browse/JDK-8089579, which
> prompted me to have a look at When. There are a few points I would like to
> address:
>
> * StringConditionBuilder#otherwise(ObservableStringValue) does not check
> for null as other condition builders do. This results in a deeper NPE
> when StringCondition tries to register a listener to the
> ObservableStringValue.
>
> * I would like a (re)evaluation on the above bug ticket and thoughts on
> the proposal of "on demand evaluation" using a Supplier or a similar
> method. The behavior of the intended implementation would be to evaluate
> 'then' and 'otherwise' whenever their condition is met, and only then.
>
> * The class can benefit from some small refactoring, such as using
> Objects.requireNonNull for null checks and some code reuse to reduce the
> chance of bugs such as the missing null check of StringConditionBuilder.
>
> * There are a few Javadoc corrections and some clarifications of the
> current behavior could be beneficial as well.
>
> I can work on all of the above. How to proceed?
>
> - Nir
>

Re: Updating class javafx.beans.binding.When

[Nir Lisker]

OK, let's wait with this until I figure out if there's a problem with the
test suit.

On Fri, Feb 16, 2018 at 11:46 PM, Kevin Rushforth <
kevin.rushfo...@oracle.com> wrote:

> This will take me a bit more time to look at than I have right now (and
> Monday is a US holiday), so one quick comment for now:
>
> The refactoring must not alter any public API signatures for exported
> packagers, and must be behavior neutral. So if there are unit tests that
> pass without your fix and fail with your fix, then you will need to alter
> your fix, unless you can show that the tests are testing an implementation
> detail that would not affect an application that just uses public API.
>
>
> -- Kevin
>
>
> Nir Lisker wrote:
>
> Let's start with the refactoring then. Before I submit a bug let's check
> that this plan makes sense. Attached webrev for discussion.
>
> Changes:
> * Main change was to the XxxCondition classes. Instead of having 4
> combinations of primitives and observables I used the unification approach
> that NumberConditionBuilder took with wrapping the value in a constant
> observable. I also replaced these classes with a generic wrappers
> XxxConditionHolders which hold the binding part of the XxxCondition class.
>
> * I attempted to generify XxxConditionBuilders as well. The attempt is
> ConditionBuilder and an example implementation was done for boolean only -
> BooleanConditionBuilder2. I think that it doesn't gain much.
>
> * Added BooleanConstant class in internal API (it was missing for some
> reason).
>
> * The handling of Numbers in the original class is a bit weird in my eyes.
> The compile time return types are DoubleBinding if one or both values are
> double and NumberBinding otherwise [1]. On the other hand, the runtime
> return types takes special care to return a binding class based on widening
> conventions and the docs don't mention anything about that. In my change,
> the runtime type is always DoubleBinding (though I kept a placeholder
> if-else chain) and that saves some code. The user can always call
> floatValue() etc. anyway.
>
> Between backwards compatibility and limitations of generics this is the
> best I could come up with.
>
> Additional notes:
>
> * Running the tests from gradle causes some of the When tests to fail and
> I don't know why, it's hard to debug. I wrote my own ad-hoc test for one of
> the failed tests and it passes.
>
> * I noticed that StringConstant extends StringExpression while all the
> other classes just implement their respective ObservableXxxValue. Don't
> know why, but I can align these classes to one of those choices.
>
> [1] https://docs.oracle.com/javase/9/docs/api/javafx/beans/binding/When.
> NumberConditionBuilder.html
>
> On Thu, Feb 15, 2018 at 5:04 AM, Kevin Rushforth <
> kevin.rushfo...@oracle.com> wrote:
>
>> Sorry for the delay in responding. I was traveling when this was sent and
>> barely able to keep up with urgent email / tasks.
>>
>> Most of what you suggest below seems good. My only concern is whether the
>> "on demand" evaluation will have any side effects. Conceptually, it seems
>> like the right thing to do.
>>
>> The refactoring you propose is probably best done as a separate bug fix,
>> so that we don't mix behavioral changes with refactoring, unless you think
>> that the refactoring is intertwined with the fix.
>>
>> If you would like to work on a fix, that would be good. It will need to
>> include new unit tests, plus ensuring that the existing unit tests pass.
>>
>> Thanks.
>>
>> -- Kevin
>>
>>
>>
>> Nir Lisker wrote:
>>
>>> Hi,
>>>
>>> I was looking at https://bugs.openjdk.java.net/browse/JDK-8089579, which
>>> prompted me to have a look at When. There are a few points I would like
>>> to
>>> address:
>>>
>>> * StringConditionBuilder#otherwise(ObservableStringValue) does not check
>>> for null as other condition builders do. This results in a deeper NPE
>>> when StringCondition tries to register a listener to the
>>> ObservableStringValue.
>>>
>>> * I would like a (re)evaluation on the above bug ticket and thoughts on
>>> the
>>> proposal of "on demand evaluation" using a Supplier or a similar method.
>>> The behavior of the intended implementation would be to evaluate 'then'
>>> and
>>> 'otherwise' whenever their condition is met, and only then.
>>>
>>> * The class can benefit from some small refactoring, such as using
>>> Objects.requireNonNull for null checks and some code reuse to reduce the
>>> chance of bugs such as the missing null check of StringConditionBuilder.
>>>
>>> * There are a few Javadoc corrections and some clarifications of the
>>> current behavior could be beneficial as well.
>>>
>>> I can work on all of the above. How to proceed?
>>>
>>> - Nir
>>>
>>>
>>
>

Re: Updating class javafx.beans.binding.When

[Nir Lisker]

Let's start with the refactoring then. Before I submit a bug let's check
that this plan makes sense. Attached webrev for discussion.

Changes:
* Main change was to the XxxCondition classes. Instead of having 4
combinations of primitives and observables I used the unification approach
that NumberConditionBuilder took with wrapping the value in a constant
observable. I also replaced these classes with a generic wrappers
XxxConditionHolders which hold the binding part of the XxxCondition class.

* I attempted to generify XxxConditionBuilders as well. The attempt is
ConditionBuilder and an example implementation was done for boolean only -
BooleanConditionBuilder2. I think that it doesn't gain much.

* Added BooleanConstant class in internal API (it was missing for some
reason).

* The handling of Numbers in the original class is a bit weird in my eyes.
The compile time return types are DoubleBinding if one or both values are
double and NumberBinding otherwise [1]. On the other hand, the runtime
return types takes special care to return a binding class based on widening
conventions and the docs don't mention anything about that. In my change,
the runtime type is always DoubleBinding (though I kept a placeholder
if-else chain) and that saves some code. The user can always call
floatValue() etc. anyway.

Between backwards compatibility and limitations of generics this is the
best I could come up with.

Additional notes:

* Running the tests from gradle causes some of the When tests to fail and I
don't know why, it's hard to debug. I wrote my own ad-hoc test for one of
the failed tests and it passes.

* I noticed that StringConstant extends StringExpression while all the
other classes just implement their respective ObservableXxxValue. Don't
know why, but I can align these classes to one of those choices.

[1]
https://docs.oracle.com/javase/9/docs/api/javafx/beans/binding/When.NumberConditionBuilder.html

On Thu, Feb 15, 2018 at 5:04 AM, Kevin Rushforth <kevin.rushfo...@oracle.com
> wrote:

> Sorry for the delay in responding. I was traveling when this was sent and
> barely able to keep up with urgent email / tasks.
>
> Most of what you suggest below seems good. My only concern is whether the
> "on demand" evaluation will have any side effects. Conceptually, it seems
> like the right thing to do.
>
> The refactoring you propose is probably best done as a separate bug fix,
> so that we don't mix behavioral changes with refactoring, unless you think
> that the refactoring is intertwined with the fix.
>
> If you would like to work on a fix, that would be good. It will need to
> include new unit tests, plus ensuring that the existing unit tests pass.
>
> Thanks.
>
> -- Kevin
>
>
>
> Nir Lisker wrote:
>
>> Hi,
>>
>> I was looking at https://bugs.openjdk.java.net/browse/JDK-8089579, which
>> prompted me to have a look at When. There are a few points I would like to
>> address:
>>
>> * StringConditionBuilder#otherwise(ObservableStringValue) does not check
>> for null as other condition builders do. This results in a deeper NPE
>> when StringCondition tries to register a listener to the
>> ObservableStringValue.
>>
>> * I would like a (re)evaluation on the above bug ticket and thoughts on
>> the
>> proposal of "on demand evaluation" using a Supplier or a similar method.
>> The behavior of the intended implementation would be to evaluate 'then'
>> and
>> 'otherwise' whenever their condition is met, and only then.
>>
>> * The class can benefit from some small refactoring, such as using
>> Objects.requireNonNull for null checks and some code reuse to reduce the
>> chance of bugs such as the missing null check of StringConditionBuilder.
>>
>> * There are a few Javadoc corrections and some clarifications of the
>> current behavior could be beneficial as well.
>>
>> I can work on all of the above. How to proceed?
>>
>> - Nir
>>
>>
>

Re: JDK build fails on missing javah

[Nir Lisker]

I've gotten a reply from build-...@openjdk.java.net (
http://mail.openjdk.java.net/pipermail/build-dev/2018-January/020552.html).
The check for javah will be removed in the future. For now we have to use 9
as boot JDK:

--with-boot-jdk='C:\Program Files\Java\jdk-9\'

On Sun, Dec 31, 2017 at 2:43 PM, Nir Lisker <nlis...@gmail.com> wrote:

> After successfully building OpenJFX (11) Iv'e went on to build OpenJDK
> (11) as instructed under "Integration with OpenJDK" (
> http://hg.openjdk.java.net/jdk/jdk/raw-file/tip/doc/building.html).
>
> When executing `bash configure  
> --with-import-modules=jfx_path\rt\build\modular-sdk`
> the build fails:
>
> checking for java in Boot JDK... ok
> checking for javac in Boot JDK... ok
> checking for javah in Boot JDK... not found
> configure: Your Boot JDK seems broken. This might be fixed by explicitly
> setting --with-boot-jdk
> configure: error: Could not find javah in the Boot JDK
> configure exiting with result code 1
>
> The boot JDK is 10, which does not have javah anymore, so it is no
> surprise. I could point boot JDK to a previous version, but I don't think I
> should. Does anyone know what I should do?
>
> Nir
>

Code conventions formalization

[Nir Lisker]

Hi all,

As we're getting closer to 12 and the GitHub repo is gaining traction, I
think we should start formalizing in writing the exact code conventions we
want to use to decrease future mess. The wiki has some rules [1], but there
are areas which are still fuzzy. The check tools could also use an update.

Just a few specific points:

* Line length limit vary greatly even withing the same class.
* Number of empty lines before and after closing bracer `}` of classes (and
inner classes) varies.
* Annotations sometimes appear on the same line and sometimes above what
they are annotating.
* I recommend we enforce using @Override wherever applicable, it can only
help.
* Usage of 'var' (should probably link to the style guide by Stuart Marks).

After we decide on what we care about and in what way, we should supply a
formatter for each IDE (either in the repo or another source) so that
contributors can easily plug it in and get everything right.

- Nir

[1] https://wiki.openjdk.java.net/display/OpenJFX/Code+Style+Rules

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

[Nir Lisker]

Hi Kevin,

Please review the fix for:

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

I did not include a fix for
https://github.com/javafxports/openjdk-jfx/issues/122, which is pending.

Re: Swing module's module-info file

[Nir Lisker]

And both newimlp and oldimpl packages compile for you?

On Tue, Aug 7, 2018 at 8:04 PM, Tom Schindl 
wrote:

> Hi Nir,
>
> I'm using OpenJDK-11 in my eclipse for development so I have that module
> included.
>
> Tom
>
> On 07.08.18 18:34, Nir Lisker wrote:
> > So you rebuilt the JDK with the new jdk.unsupported.desktop module?
> >
> > On Tue, Aug 7, 2018 at 3:11 PM, Tom Schindl  > <mailto:tom.schi...@bestsolution.at>> wrote:
> >
> > Well I simply added the folder to my class-folders and things then
> work
> > perfectly fine inside Eclipse
> >
> > Tom
> >
> > On 07.08.18 14:02, Nir Lisker wrote:
> > > Thanks for the info. I'm working on updating the Eclipse files and
> > this is
> > > causing problems for javafx.swing. When will the minimum version
> > be bumped
> > > to 11?
> > >
> > > On Tue, Aug 7, 2018 at 7:51 AM, Prasanta Sadhukhan <
> > > prasanta.sadhuk...@oracle.com
> > <mailto:prasanta.sadhuk...@oracle.com>> wrote:
> > >
> > >> This is because if fx is compiled with a jdk version which does
> > not have
> > >> jdk.unsupported.desktop module then having module-info.java in
> > its original
> > >> place would cause compilation error as module-info.java contains
> > >>
> > >> requires static jdk.unsupported.desktop;
> > >>
> > >> So, the idea was to copy the file into a directory which is not
> > on the
> > >> module-source-path. Then build.gradle copy it from there to gensrc
> > >> directory optionally filtering the above line
> > >>  task copyModuleInfo(type: Copy, description: "copy module-info
> > file to
> > >> gensrc") {
> > >> from "src/main/module-info/module-info.java"
> > >> into "$buildDir/gensrc/java/"
> > >> filter { line->
> > >> !HAS_UNSUPPORTED_DESKTOP &&
> > line.contains('jdk.unsupported.desktop')
> > >> ? null : line
> > >> }
> > >> }
> > >>
> > >> Regards
> > >> Prasanta
> > >>
> > >> On 8/7/2018 6:42 AM, Nir Lisker wrote:
> > >>
> > >>> Hi,
> > >>>
> > >>> I didn't follow all the latest changes to the Swing module, but
> > I notice
> > >>> now its module-info.java file is not in the same place where
> > other modules
> > >>> have theirs:
> > >>>
> > >>> It's under javafx.swing\src\main\module-info instead of
> > >>> javafx.\src\main\java.
> > >>>
> > >>> Is there a reason for this?
> > >>>
> > >>> - Nir
> > >>>
> > >>
> > >>
> >
> > --
> > Tom Schindl, CTO
> > BestSolution.at EDV Systemhaus GmbH
> > Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck
> > Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
> >
> >
>
> --
> Tom Schindl, CTO
> BestSolution.at EDV Systemhaus GmbH
> Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck
> Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
>

JDK-8209015: Update Eclipse project files

[Nir Lisker]

Hi,

After the removal of some dependencies on JDK modules the Eclipse classpath
files should be updated to allow developers to work on Eclipse without
needing to do tricky configuration themselves. Iv'e submitted a JBS issue
[1] to track the progress.

There were discussion about removing IDE-specific files in the JBS [2] and
on GitHub (see links in JBS issue). It seems that the idea was dropped and
I propose to close this issue. A discussion on this issue can be found on
the mailing list [3].

On to the technical discussion:

Iv'e put up a gist with my classpath files [4], but Swing still gives me
problems with an NPE during the build.

On 08.08.18 08:55, Tom Schindl wrote:
> > Hi Nir,
> >
> > I currently use the attached stash to make Eclipse compile all modules.
> >
> > Unfortunately I have to modify the following java-Files to get away
> > without any compile errors:
> > * Dialog => Added a method getDialog() instead of directly accessing the
> > field
>

We have to wait for the fix [5], there's no workaround.


> > * javafx.fxml => Add a static require for controls
> > * javafx.web  => Add a static require for java.management
>
> Looking once more I think read-edges are completely missing in Eclipse
> for projects. I can patch other projects to get a read-edge but not the
> project itself!
>
> In the end what we want is to patch eg the javafx.fxml-module to have a
> read-edge for javafx.control. I don't see how this can be done with the
> current Eclipse setup!
>
> My work around today is to add static-require and I don't see a way
> around that.
>

It's possible to do it in the classpath file as Iv'e shown in [6], but I
don't know if JUnit will work. I seem to have general JUnit problems. Can
you try with my files and unmodified module-info.java files and see which
projects can run JUnit? They should all compile.

The bulk of the work for modular support is tracked under [7] and they want
input from users, so try to help them. There's also a UI specific issue for
modular projects [8].

- Nir

[1] https://bugs.openjdk.java.net/browse/JDK-8209015

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

[3]
http://mail.openjdk.java.net/pipermail/openjfx-dev/2018-April/021740.html

[4] https://gist.github.com/nlisker/fd2d42f6467c069cf8c4cc054ba0ea40

[5] https://bugs.eclipse.org/bugs/show_bug.cgi?id=536330

[6] https://bugs.eclipse.org/bugs/show_bug.cgi?id=526963

[7] https://bugs.eclipse.org/bugs/show_bug.cgi?id=526831

[8] https://bugs.eclipse.org/bugs/show_bug.cgi?id=536330

Swing module's module-info file

[Nir Lisker]

Hi,

I didn't follow all the latest changes to the Swing module, but I notice
now its module-info.java file is not in the same place where other modules
have theirs:

It's under javafx.swing\src\main\module-info instead of
javafx.\src\main\java.

Is there a reason for this?

- Nir

Re: Swing module's module-info file

[Nir Lisker]

Ah, yes, I was trying to see what modifications each project needs so I
didn't have it modified.

Can you share your Swing .classpath? Eclipse gives me a NPE during the
build task, I think something broke.

On Tue, Aug 7, 2018 at 8:54 PM, Tom Schindl 
wrote:

> Oh but naturally my .classpath-File is modified
>
> Tom
>
> On 07.08.18 19:51, Tom Schindl wrote:
> > Yes they do!
> >
> > Tom
> >
> > On 07.08.18 19:36, Nir Lisker wrote:
> >> And both newimlp and oldimpl packages compile for you?
> >>
> >> On Tue, Aug 7, 2018 at 8:04 PM, Tom Schindl <
> tom.schi...@bestsolution.at
> >> <mailto:tom.schi...@bestsolution.at>> wrote:
> >>
> >> Hi Nir,
> >>
> >> I'm using OpenJDK-11 in my eclipse for development so I have that
> module
> >> included.
> >>
> >> Tom
> >>
> >> On 07.08.18 18:34, Nir Lisker wrote:
> >> > So you rebuilt the JDK with the new jdk.unsupported.desktop
> module?
> >> >
> >> > On Tue, Aug 7, 2018 at 3:11 PM, Tom Schindl <
> tom.schi...@bestsolution.at <mailto:tom.schi...@bestsolution.at>
> >> > <mailto:tom.schi...@bestsolution.at <mailto:tom.schindl@
> bestsolution.at>>>
> >> wrote:
> >> >
> >> > Well I simply added the folder to my class-folders and things
> then work
> >> > perfectly fine inside Eclipse
> >> >
> >> > Tom
> >> >
> >> > On 07.08.18 14:02, Nir Lisker wrote:
> >> > > Thanks for the info. I'm working on updating the Eclipse
> files and
> >> > this is
> >> > > causing problems for javafx.swing. When will the minimum
> version
> >> > be bumped
> >> > > to 11?
> >> > >
> >> > > On Tue, Aug 7, 2018 at 7:51 AM, Prasanta Sadhukhan <
> >> > > prasanta.sadhuk...@oracle.com <mailto:prasanta.sadhukhan@
> oracle.com>
> >> > <mailto:prasanta.sadhuk...@oracle.com
> >> <mailto:prasanta.sadhuk...@oracle.com>>> wrote:
> >> > >
> >> > >> This is because if fx is compiled with a jdk version which
> does
> >> > not have
> >> > >> jdk.unsupported.desktop module then having
> module-info.java in
> >> > its original
> >> > >> place would cause compilation error as module-info.java
> >> contains
> >> > >>
> >> > >> requires static jdk.unsupported.desktop;
> >> > >>
> >> > >> So, the idea was to copy the file into a directory which
> is not
> >> > on the
> >> > >> module-source-path. Then build.gradle copy it from there to
> >> gensrc
> >> > >> directory optionally filtering the above line
> >> > >>  task copyModuleInfo(type: Copy, description: "copy
> module-info
> >> > file to
> >> > >> gensrc") {
> >> > >> from "src/main/module-info/module-info.java"
> >> > >> into "$buildDir/gensrc/java/"
> >> > >> filter { line->
> >> > >> !HAS_UNSUPPORTED_DESKTOP &&
> >> > line.contains('jdk.unsupported.desktop')
> >> > >> ? null : line
> >> > >> }
> >> > >> }
> >> > >>
> >> > >> Regards
> >> > >> Prasanta
> >> > >>
> >> > >> On 8/7/2018 6:42 AM, Nir Lisker wrote:
> >> > >>
> >> > >>> Hi,
> >> > >>>
> >> > >>> I didn't follow all the latest changes to the Swing
> >> module, but
> >> > I notice
> >> > >>> now its module-info.java file is not in the same place
> where
> >> > other modules
> >> > >>> have theirs:
> >> > >>>
> >> > >>> It's under javafx.swing\src\main\module-info instead of
> >> > >>> javafx.\src\main\java.
> >> > >>>
> >> > >>> Is there a reason for this?
> >> > >>>
> >> > >>> - Nir
> >> > >>>
> >> > >>
> >> > >>
> >> >
> >> > --
> >> > Tom Schindl, CTO
> >> > BestSolution.at EDV Systemhaus GmbH
> >> > Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck
> >> > Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
> >> >
> >> >
> >>
> >> --
> >> Tom Schindl, CTO
> >> BestSolution.at EDV Systemhaus GmbH
> >> Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck
> >> Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
> >>
> >>
> >
>
> --
> Tom Schindl, CTO
> BestSolution.at EDV Systemhaus GmbH
> Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck
> Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
>

Review Request: JDK-8209015: Update Eclipse project files

[Nir Lisker]

Hi,

Please review the fix for:

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

Thanks,
Nir

Re: Swing module's module-info file

[Nir Lisker]

Thanks for the info. I'm working on updating the Eclipse files and this is
causing problems for javafx.swing. When will the minimum version be bumped
to 11?

On Tue, Aug 7, 2018 at 7:51 AM, Prasanta Sadhukhan <
prasanta.sadhuk...@oracle.com> wrote:

> This is because if fx is compiled with a jdk version which does not have
> jdk.unsupported.desktop module then having module-info.java in its original
> place would cause compilation error as module-info.java contains
>
> requires static jdk.unsupported.desktop;
>
> So, the idea was to copy the file into a directory which is not on the
> module-source-path. Then build.gradle copy it from there to gensrc
> directory optionally filtering the above line
>  task copyModuleInfo(type: Copy, description: "copy module-info file to
> gensrc") {
> from "src/main/module-info/module-info.java"
> into "$buildDir/gensrc/java/"
> filter { line->
> !HAS_UNSUPPORTED_DESKTOP && 
> line.contains('jdk.unsupported.desktop')
> ? null : line
> }
> }
>
> Regards
> Prasanta
>
> On 8/7/2018 6:42 AM, Nir Lisker wrote:
>
>> Hi,
>>
>> I didn't follow all the latest changes to the Swing module, but I notice
>> now its module-info.java file is not in the same place where other modules
>> have theirs:
>>
>> It's under javafx.swing\src\main\module-info instead of
>> javafx.\src\main\java.
>>
>> Is there a reason for this?
>>
>> - Nir
>>
>
>

Re: Fate of jdk.packager and jdk.packager.services?

[Nir Lisker]

Hi Lennart,

You should be able to use the packager from JDK 10, see
https://bugs.openjdk.java.net/browse/JDK-8203379.

There is a draft for a replacement, see
https://bugs.openjdk.java.net/browse/JDK-8200758.

- Nir

On Tue, Aug 7, 2018 at 12:28 PM, Lennart Börjeson 
wrote:

> I'm migrating to JDK 11 and OpenJFX 11, and would like to continue using
> the packager and the associated packager service (i.e. the UserJvmOptions).
>
> AFAIK, those are gone from the available binary builds, but still there in
> the code. Is there a way to use them without resorting to build openjfx
> myself? If not, is there some alternative to the UserJvmOptions?
>
>
> (I'm currently working around my problems by building both openjfx and the
> JDK, and bundling openjfx with the JDK, just like in the good old days...)
>
> Best regards,
>
> /Lennart Börjeson
>
>
>

Re: Swing module's module-info file

[Nir Lisker]

So you rebuilt the JDK with the new jdk.unsupported.desktop module?

On Tue, Aug 7, 2018 at 3:11 PM, Tom Schindl 
wrote:

> Well I simply added the folder to my class-folders and things then work
> perfectly fine inside Eclipse
>
> Tom
>
> On 07.08.18 14:02, Nir Lisker wrote:
> > Thanks for the info. I'm working on updating the Eclipse files and this
> is
> > causing problems for javafx.swing. When will the minimum version be
> bumped
> > to 11?
> >
> > On Tue, Aug 7, 2018 at 7:51 AM, Prasanta Sadhukhan <
> > prasanta.sadhuk...@oracle.com> wrote:
> >
> >> This is because if fx is compiled with a jdk version which does not have
> >> jdk.unsupported.desktop module then having module-info.java in its
> original
> >> place would cause compilation error as module-info.java contains
> >>
> >> requires static jdk.unsupported.desktop;
> >>
> >> So, the idea was to copy the file into a directory which is not on the
> >> module-source-path. Then build.gradle copy it from there to gensrc
> >> directory optionally filtering the above line
> >>  task copyModuleInfo(type: Copy, description: "copy module-info file to
> >> gensrc") {
> >> from "src/main/module-info/module-info.java"
> >> into "$buildDir/gensrc/java/"
> >> filter { line->
> >> !HAS_UNSUPPORTED_DESKTOP && line.contains('jdk.
> unsupported.desktop')
> >> ? null : line
> >> }
> >> }
> >>
> >> Regards
> >> Prasanta
> >>
> >> On 8/7/2018 6:42 AM, Nir Lisker wrote:
> >>
> >>> Hi,
> >>>
> >>> I didn't follow all the latest changes to the Swing module, but I
> notice
> >>> now its module-info.java file is not in the same place where other
> modules
> >>> have theirs:
> >>>
> >>> It's under javafx.swing\src\main\module-info instead of
> >>> javafx.\src\main\java.
> >>>
> >>> Is there a reason for this?
> >>>
> >>> - Nir
> >>>
> >>
> >>
>
> --
> Tom Schindl, CTO
> BestSolution.at EDV Systemhaus GmbH
> Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck
> Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
>

Re: Swing module's module-info file

[Nir Lisker]

Yes, but since this thread was about the Swing module's module-info I'll
start another thread with the link to the JBS issue I created a few days
ago about Eclipse.

On Wed, Aug 8, 2018 at 10:10 AM, Tom Schindl 
wrote:

> Hi,
>
> On 08.08.18 08:55, Tom Schindl wrote:
> > Hi Nir,
> >
> > I currently use the attached stash to make Eclipse compile all modules.
> >
> > Unfortunately I have to modify the following java-Files to get away
> > without any compile errors:
> > * Dialog => Added a method getDialog() instead of directly accessing the
> > field
> > * javafx.fxml => Add a static require for controls
> > * javafx.web  => Add a static require for java.management
>
> Looking once more I think read-edges are completely missing in Eclipse
> for projects. I can patch other projects to get a read-edge but not the
> project itself!
>
> In the end what we want is to patch eg the javafx.fxml-module to have a
> read-edge for javafx.control. I don't see how this can be done with the
> current Eclipse setup!
>
> My work around today is to add static-require and I don't see a way
> around that.
>
> Tom
>
> --
> Tom Schindl, CTO
> BestSolution.at EDV Systemhaus GmbH
> Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck
> Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
>

JDK-8208761: Update constant collections to use the new immutable collections

[Nir Lisker]

Hi All,

Iv'e been working on updating OpenJFX to use the Java 9 immutable
collections [1]. If you know of any additional location which can be
updated, please add a comment or reply here.

New code should be mindful of these collections' existence (contributors
and reviewers alike) so that we don't need to continuously iterate over the
platform to update it.

[1] https://bugs.openjdk.java.net/browse/JDK-8208761

Thanks,
Nir

Re: How to access com.sun.webkit.network.CookieManager at JDK 10?

[Nir Lisker]

Sorry, my reply was not phrased well. Whether you declare a
module-info.java or not, you still have to add-exports either via command
line or during runtime. What I meant with not needing to declare a
dependency in module-info.java is that you don't need a 'requires' (or
add-reads) because the unnamed module reads everything be default.

So, in your case you need a command line "--add-exports
javafx.web/com.sun.webkit.network=my.app.Test" (or the equivalent runtime
code) and "requires javafx.web" in the module-info.java. The latter is
what's not needed if you don't declare a module.

- Nir

On Fri, Aug 24, 2018 at 4:43 PM Miroslav Nachev <
mnachev.nscenter...@gmail.com> wrote:

> Now I adopted the application to be module, adding this:
> module my.app.Test {
> requires controlsfx;
> requires javafx.base;
> requires javafx.controls;
> }
>
> What is the next step?
>
>
> On Fri, Aug 24, 2018 at 4:02 PM Nir Lisker  wrote:
>
>> Hi Miro,
>>
>> Can I use the 2nd option with declaration in the source code, or the only
>>> possible option is to pass as parameter when starting the application?
>>>
>>
>> If your app is not a module then you don't have a module-info.java in
>> your source code to declare the dependency. What you can do is export a
>> package during runtime with the addExports method [1].
>>
>> [1]
>> https://docs.oracle.com/javase/10/docs/api/java/lang/Module.html#addExports(java.lang.String,java.lang.Module)
>>
>> On Fri, Aug 24, 2018 at 12:38 PM Miroslav Nachev <
>> mnachev.nscenter...@gmail.com> wrote:
>>
>>> Hi Arun,
>>>
>>> Thank you. I'm already using the first option, but then I need to access
>>> other methods and classes that are not available.
>>> Can I use the 2nd option with declaration in the source code, or the only
>>> possible option is to pass as parameter when starting the application?
>>>
>>>
>>> Miro.
>>>
>>> On Fri, Aug 24, 2018 at 12:04 PM Arunprasad Rajkumar <
>>> arunprasad.rajku...@oracle.com> wrote:
>>>
>>> > Hello Miro,
>>> >
>>> > CookieManager is a module private class, which is not exposed to
>>> outside.
>>> >
>>> > I could think of two options,
>>> >
>>> > 1. com.sun.webkit.network.CookieManager is a type of
>>> > java.net.CookieHandler, that means after instantiating WebEngine, you
>>> can
>>> > call CookieHandler.getDefault() to get the instance of CookieManager.
>>> > new WebEngine();
>>> > CookieHandler cookieHandler = CookieHandler.getDefault(); //
>>> This
>>> > will be an instance of com.sun.webkit.network.CookieManager
>>> >
>>> > 2. Export the module private implementation using
>>> > "--add-exports=javafx.web/com.sun.webkit.network=ALL-UNNAMED”
>>> >
>>> > Thanks,
>>> > Arun
>>> >
>>> > > On 24-Aug-2018, at 12:27 PM, Miroslav Nachev <
>>> > mnachev.nscenter...@gmail.com> wrote:
>>> > >
>>> > > Hi,
>>> > >
>>> > > I have apps that work well on JDK8, but on JDK10 I do not have
>>> access to
>>> > > some classes, for example, com.sun.webkit.network.CookieManager. This
>>> > class
>>> > > is the only one, that is up to date (RFC 6265) and is part of Java.
>>> The
>>> > > java.net.CookieManager class is obsolete: RFC 2965. The Cookie
>>> solution
>>> > in
>>> > > Apache HttpComponents is very complicated, difficult to use, and is
>>> > mostly
>>> > > not compatible with JDK and JavaFX.
>>> > > In fact, I use JavaFX CookieManager in the following 3 scenarios:
>>> > >
>>> > >   - When using WebEngine (JavaFX 8).
>>> > >   - JavaFX Desktop App to store frequently used words in text and
>>> other
>>> > >   fields (TextField, etc.).
>>> > >   - To store session parameters in JavaFX Desktop Clients that uses
>>> REST
>>> > >   WS or Web Sockets to connect to the Web Server (App Server).
>>> > >
>>> > > Is there any way to enable access to
>>> com.sun.webkit.network.CookieManager
>>> > > at JDK 10?
>>> > >
>>> > >
>>> > > Regards,
>>> > > Miro.
>>> >
>>> >
>>>
>>

Re: How to access com.sun.webkit.network.CookieManager at JDK 10?

[Nir Lisker]

Hi Miro,

Can I use the 2nd option with declaration in the source code, or the only
> possible option is to pass as parameter when starting the application?
>

If your app is not a module then you don't have a module-info.java in your
source code to declare the dependency. What you can do is export a package
during runtime with the addExports method [1].

[1]
https://docs.oracle.com/javase/10/docs/api/java/lang/Module.html#addExports(java.lang.String,java.lang.Module)

On Fri, Aug 24, 2018 at 12:38 PM Miroslav Nachev <
mnachev.nscenter...@gmail.com> wrote:

> Hi Arun,
>
> Thank you. I'm already using the first option, but then I need to access
> other methods and classes that are not available.
> Can I use the 2nd option with declaration in the source code, or the only
> possible option is to pass as parameter when starting the application?
>
>
> Miro.
>
> On Fri, Aug 24, 2018 at 12:04 PM Arunprasad Rajkumar <
> arunprasad.rajku...@oracle.com> wrote:
>
> > Hello Miro,
> >
> > CookieManager is a module private class, which is not exposed to outside.
> >
> > I could think of two options,
> >
> > 1. com.sun.webkit.network.CookieManager is a type of
> > java.net.CookieHandler, that means after instantiating WebEngine, you can
> > call CookieHandler.getDefault() to get the instance of CookieManager.
> > new WebEngine();
> > CookieHandler cookieHandler = CookieHandler.getDefault(); // This
> > will be an instance of com.sun.webkit.network.CookieManager
> >
> > 2. Export the module private implementation using
> > "--add-exports=javafx.web/com.sun.webkit.network=ALL-UNNAMED”
> >
> > Thanks,
> > Arun
> >
> > > On 24-Aug-2018, at 12:27 PM, Miroslav Nachev <
> > mnachev.nscenter...@gmail.com> wrote:
> > >
> > > Hi,
> > >
> > > I have apps that work well on JDK8, but on JDK10 I do not have access
> to
> > > some classes, for example, com.sun.webkit.network.CookieManager. This
> > class
> > > is the only one, that is up to date (RFC 6265) and is part of Java. The
> > > java.net.CookieManager class is obsolete: RFC 2965. The Cookie solution
> > in
> > > Apache HttpComponents is very complicated, difficult to use, and is
> > mostly
> > > not compatible with JDK and JavaFX.
> > > In fact, I use JavaFX CookieManager in the following 3 scenarios:
> > >
> > >   - When using WebEngine (JavaFX 8).
> > >   - JavaFX Desktop App to store frequently used words in text and other
> > >   fields (TextField, etc.).
> > >   - To store session parameters in JavaFX Desktop Clients that uses
> REST
> > >   WS or Web Sockets to connect to the Web Server (App Server).
> > >
> > > Is there any way to enable access to
> com.sun.webkit.network.CookieManager
> > > at JDK 10?
> > >
> > >
> > > Regards,
> > > Miro.
> >
> >
>

Re: INFO: JFX Issue

[Nir Lisker]

Hi,

Shouldn't it be marked as In Progress in this case?

- Nir

On Wed, Aug 22, 2018 at 12:37 AM Kevin Rushforth 
wrote:

> Hi Ankit,
>
> This one is actively under development by Murali; it was just targeted
> to openjfx12 today. If you have any comments on this enhancement that
> might be helpful, you can add them to JBS or share them on the list.
>
> Thanks.
>
> -- Kevin
>
>
> On 8/21/2018 1:44 PM, ankit srivastav wrote:
> > Team,
> >
> > I would like to work on below issue, let me know if anyone else is
> working
> > on the same.
> >
> > https://bugs.openjdk.java.net/browse/JDK-8207772
> >
> >
> > --Ankit
>
>

Animation enhancements

[Nir Lisker]

Hi All,

Iv'e taken upon myself to handle most of the enhancement proposals for
animations (I could fine). A list of all these can be found here [1]. Some
of the proposals are more viable than others (I do not outright suggest
that they all be implemented).

For those of you who are interested in this area, I ask for you input on
these (here or on the issues), or other related enhancements you'd like so
we can gather enough public opinion and plan ahead.

[1]
https://bugs.openjdk.java.net/browse/JDK-8092408?jql=project%20%3D%20JDK%20AND%20issuetype%20%3D%20Enhancement%20AND%20component%20%3D%20javafx%20AND%20Subcomponent%20%3D%20animation%20AND%20assignee%20%3D%20nlisker

Thanks,
Nir

Re: JavaFX website

[Nir Lisker]

1. I would like access, thanks. I'll be able to update the Eclipse
instructions and some of the Windows build instructions.

2. I submitted https://bugs.openjdk.java.net/browse/JDK-8210360. It's going
to take a large effort to go over every page there and see what needs
changing. If enough people join the task we could (and should) have it
updated for openjfx12.

On Tue, Sep 4, 2018 at 3:49 PM Kevin Rushforth 
wrote:

> 1. The OpenJFX Wiki on openjdk.java.net is ideal for maintaining pages
> related to the Project itself. This can be supplemented by other Wikis.
> As for access, any OpenJFX Project Author (or Committer) can have write
> access to the Wiki. Just let me know if you want access, but it isn't
> activated yet.
>
> 2. This is where the community could really help as noted by Johan and
> others. The tutorials are indeed out of date. If you want to file a JBS
> bug and assign it to me, I can see what needs to be done to either
> correct (if simple) or archive pages that are so out of date as to be
> useless (or worse, misleading).
>
> -- Kevin
>
>
>
> On 9/4/2018 1:18 AM, Nir Lisker wrote:
> > 1.  Yes. The OpenJFX wiki is editable only by specific people (or only
> > Kevin) and it requires a lot of updating. We need either to be able to
> > submit changes to it, or to use the GitHub wiki which is collaborative by
> > design, in which case we need to hide the OpenJFX wiki to avoid
> confusion.
> >
> > 2. Yes. The tutorials [1] are slightly outdated (and SceneBuilder should
> > disappear from there ASAP and point to Gluon). I don't know who controls
> > those pages.
> >
> > 3. No. There's not enough traction. Jonathan Giles collects some "links
> of
> > the week" and the semi-zombified /r/JavaFX subreddit is enough to
> indicate
> > that we shouldn't invest yet in this direction.
> >
> > [1] https://docs.oracle.com/javase/8/javase-clienttechnologies.htm
> >
> > - Nir
> >
> > On Tue, Sep 4, 2018 at 10:02 AM Johan Vos  wrote:
> >
> >> It has been mentioned a number of times that JavaFX would benefit from a
> >> JavaFX website.
> >> I see a number of options that fall in the category website:
> >>
> >> 1. A set of pages with details on what OpenJFX is, how to build, where
> to
> >> download and get release notes, how to contribute, roadmap,... That is
> what
> >> I believe can perfectly be done in the OpenJFX wiki. It can be the
> >> reference manual
> >>
> >> 2. A set of pages targeting new and existing JavaFX developers, with a
> >> focus on where to download, how to get started (maven/gradle/IDE's),
> where
> >> to get docs/tutorials and probably with some links to third party
> libraries
> >> (free/commercial). This is sort of the user manual.
> >>
> >> 3. A highly interactive community site, gathering tweets/blog posts etc,
> >> more or less similar to what James Weaver and Gerrit Grunwald did years
> >> ago.
> >>
> >> For 1: I think this is up to us (OpenJFX committers) to maintain and
> >> improve. It will also benefit the people here.
> >>
> >> For 2: This is the most important thing, I believe. It would be great
> if a
> >> number of people from this list step up to organize this. It can be a
> >> static website, a github page, or anything else. I don't think this
> >> strictly belongs under OpenJFX (which I consider to be the technical
> >> development umbrella) but it's extremely important to have.
> >> I think this is a perfect opportunity for people and companies who want
> to
> >> get more active in JavaFX to get involved in.
> >>
> >> For 3: That would be nice, but I think it's too ambitious for now. I
> would
> >> be happy with a static, simple, clear website.
> >>
> >> - Johan
> >>
>
>

Re: Animation enhancements

[Nir Lisker]

Hi Brian,

Thanks for the input. How is "starting" different from "started" etc.?

On Mon, Sep 10, 2018 at 6:23 PM Brian Hudson 
wrote:

> I would love to see "Animation needs more events" resolved [1].
>
> Maybe following events: started, paused, resumed, cycleStarted, cycleEnded,
> stopped/ended? These additional life cycle events would allow me to do some
> things with animations/transitions that I've been struggling to do.
>
> There may even be use cases events for starting, pausing, resuming,
> cycleStarting, cycleEnding, stopping/ending.
>
> [1]: https://bugs.openjdk.java.net/browse/JDK-8092408
>

Re: Instructions for working on OpenJFX

[Nir Lisker]

If you're still catching up, I would like to verify that I should ignore
project-level errors from the IDE. For example, Eclipse complains about the
graphics project:

Project 'graphics' is missing required source folder:
'build/resources/jsl-decora'
Project 'graphics' is missing required source folder:
'build/resources/jsl-prism'

and about the buildSource project:

Project 'buildSrc' is missing required library:
'...\rt\build\libs\ant-1.8.2.jar'
Project 'buildSrc' is missing required library:
'...\rt\build\libs\antlr-3.1.3.jar'
Project 'buildSrc' is missing required library:
'...\rt\build\libs\antlr-runtime-3.1.3.jar'
Project 'buildSrc' is missing required library:
'...\rt\build\libs\stringtemplate-3.2.jar'
Project 'buildSrc' is missing required source folder: 'src/main/java'
Project 'buildSrc' is missing required source folder: 'src/test/java'

As long as the gradle tasks complete successfully I can ignore all that?

- Nir

On Fri, Jan 19, 2018 at 2:10 AM, Kevin Rushforth <kevin.rushfo...@oracle.com
> wrote:

> I'm still a little behind on my email, but here are some quick answers.
>
> #1 - The NetBeans instructions are still mostly correct except that with
> FX 9 or later you can't compile or run code from within the IDE any more
> (and there isn't yet a release of NetBeans 9). Not sure about the other
> IDEs, but I suspect they are somewhat out of date.
>
>
> #2. You should be able to build just the FX bits (outside your IDE) using:
>
>gradle sdk
> -or-
>gradle javadoc
>
> depending on what you want to do (or you can build both targets). If you
> have a build of JDK 9 or later with FX bits in it, then you can use the
> build/run.args script to run with the just-built FX bits without rebuilding
> the JDK.
>
> java @build/run.args ...
>
>
> #3. I don't know since I don't use Eclipse; maybe someone on the list who
> uses Eclipse can answer. It might have to do with the level of JDK 9
> support in Eclipse
>
>
> #4 - previously answered
>
> -- Kevin
>
>
> Nir Lisker wrote:
>
>> Hello,
>>
>> I have OpenJFX and OpenJDK built. I have also set up TortoiseHg and am
>> working with Eclipse. I have several questions:
>>
>> 1. Are the instructions at
>> https://wiki.openjdk.java.net/display/OpenJFX/Using+an+IDE still valid
>> from
>> JDK 8? There are old TODOs there. If not, can I get a quick update?
>>
>> 2. After importing the projects to Eclipse and working on the source, what
>> steps need to be taken when the changes are to:
>> a. only the docs?
>> b. Java code?
>> c. Prism code?
>> Do I need to rebuild the JDK with JavaFX, rebuild only JavaFX, only
>> compile
>> etc? What tests do I need to run (e.g., I doubt I need to run regression
>> tests when changing JavaDocs)?
>>
>> 3. Eclipse uses EJC (which I never had trouble with). Can this cause
>> trouble?
>>
>> 4. After creating a local changeset and assuming there is already a JIRA
>> issue for it and the fix approach was discussed, can I just push it and it
>> will enter a review queue? Do I need to ask someone specifically for a
>> review on the changeset (
>> https://wiki.openjdk.java.net/display/OpenJFX/Code+Ownership is old...)?
>>
>> Thanks,
>> Nir
>>
>>
>

JDK-8210361: Add images to docs for public API classes of controls

[Nir Lisker]

Hi,

Iv'e started working on JDK-8210361 [1] and I'd like my comment there
addressed before continuing.

[1] https://bugs.openjdk.java.net/browse/JDK-8210361

Thanks,
Nir

Re: Animation enhancements

[Nir Lisker]

So the "-ed" events are synchronous? That is, in case of "started", the
animation needs to wait until the event handling finished and then start.
In the case of "starting", the animation would start and call the event
handler asynchronously (like "finished" does now).

Synchronous events can be problematic because they interfere with the
running of the animation. A "cycleStarting" (for example) handler will need
to suspend the animation somehow before each cycle for an unknown duration
(because it can't know what you put in the handler code). This can be done
in practice via something like Future, but I'm skeptical about how much
this would fit with the current animation semantics.

There is a case for "starting" though, which is that it doesn't interfere
with a running animation, and that it can be used as a
"prepare-then-start", as you said. But what happens when the animation is
embedded in a sequential and parallel transitions?

I agree that other "-ed" events are not that useful. We can discuss a
"prepare-then-start" mechanism.

On Tue, Sep 11, 2018 at 4:09 PM Brian Hudson 
wrote:

> starting: Indicates that the animation is about to start. This is the last
> opportunity to change an aspect of the animation that cannot be changed
> once the animation has started. PathTransition duration for example.
>
> started: The animation has started.
>
> The "-ed" actions are really what I've had a need for, other than
> "starting" I can't really think of use cases for the other "-ing" events
>
> On Tue, Sep 11, 2018 at 4:42 AM Nir Lisker  wrote:
>
>> Hi Brian,
>>
>> Thanks for the input. How is "starting" different from "started" etc.?
>>
>> On Mon, Sep 10, 2018 at 6:23 PM Brian Hudson 
>> wrote:
>>
>>> I would love to see "Animation needs more events" resolved [1].
>>>
>>> Maybe following events: started, paused, resumed, cycleStarted,
>>> cycleEnded,
>>> stopped/ended? These additional life cycle events would allow me to do
>>> some
>>> things with animations/transitions that I've been struggling to do.
>>>
>>> There may even be use cases events for starting, pausing, resuming,
>>> cycleStarting, cycleEnding, stopping/ending.
>>>
>>> [1]: https://bugs.openjdk.java.net/browse/JDK-8092408
>>>
>>

Re: Animation enhancements

[Nir Lisker]

Alright, Iv'e queued the multiple event handlers issue after the additional
event types issue.

On Tue, Sep 11, 2018 at 5:15 PM Rick Walker 
wrote:

> Thank you, yes that looks like it, I had not seen that comment.
>
> On Tue, 11 Sep 2018 at 09:51, Nir Lisker  wrote:
>
>> Hi Rick,
>>
>> Seems to me like multiple onFinished event handlers [1]. The first
>> comment there lists a plan for multiple event handlers in general.
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8091406
>>
>> On Tue, Sep 11, 2018 at 4:07 PM Rick Walker 
>> wrote:
>>
>>> Dear Nir,
>>>
>>> Please forgive me if I am not following protocol - I rarely contribute
>>> to this mailing list.
>>>
>>> I find myself constantly wrapping an animation within a
>>> ParallelTransition or SerialTransition so that setOnFinished can be called
>>> twice - once for the core animation and again by higher level code.
>>> Can you figure out a way to do this in a cleaner, simpler way?
>>>
>>> Like this:
>>>
>>>   public Animation getFadeOut()
>>>   {
>>> // create a transition to fade out this node
>>> FadeTransition fade = new FadeTransition(Duration.millis(300), this);
>>> fade.setFromValue(this.getOpacity());
>>> fade.setToValue(0);
>>>
>>> // when complete, do something
>>> fade.setOnFinished(e -> { /* do something here */ });
>>>
>>> // wrap the fade out transition so that the caller of this method
>>> can separately call setOnFinished()
>>> ParallelTransition pt = new ParallelTransition();
>>> pt.getChildren().setAll(fade);
>>> return pt;
>>>   }
>>>
>>> Best regards,
>>> Rick Walker
>>>
>>>
>>> On Tue, 11 Sep 2018 at 04:54, Nir Lisker  wrote:
>>>
>>>> Hi Brian,
>>>>
>>>> Thanks for the input. How is "starting" different from "started" etc.?
>>>>
>>>> On Mon, Sep 10, 2018 at 6:23 PM Brian Hudson 
>>>> wrote:
>>>>
>>>> > I would love to see "Animation needs more events" resolved [1].
>>>> >
>>>> > Maybe following events: started, paused, resumed, cycleStarted,
>>>> cycleEnded,
>>>> > stopped/ended? These additional life cycle events would allow me to
>>>> do some
>>>> > things with animations/transitions that I've been struggling to do.
>>>> >
>>>> > There may even be use cases events for starting, pausing, resuming,
>>>> > cycleStarting, cycleEnding, stopping/ending.
>>>> >
>>>> > [1]: https://bugs.openjdk.java.net/browse/JDK-8092408
>>>> >
>>>>
>>>
>>>
>>> --
>>> Richard P. Walker
>>> thoughtslin...@gmail.com
>>>
>>> This email is intended only for the use of the individual(s) to whom it
>>> is addressed and may be privileged and confidential. Unauthorised use or
>>> disclosure is prohibited. If you receive this e-mail in error, please
>>> advise immediately and delete the original message. This message may have
>>> been altered without your or our knowledge and the sender does not accept
>>> any liability for any errors or omissions in the message.
>>>
>>> Ce courriel est confidentiel et protégé. L'expéditeur ne renonce pas aux
>>> droits et obligations qui s'y rapportent. Toute diffusion, utilisation ou
>>> copie de ce message ou des renseignements qu'il contient par une personne
>>> autre que le (les) destinataire(s) désigné(s) est interdite. Si vous
>>> recevez ce courriel par erreur, veuillez m'en aviser immédiatement, par
>>> retour de courriel ou par un autre moyen.
>>>
>>
>
> --
> Richard P. Walker
> thoughtslin...@gmail.com
>
> This email is intended only for the use of the individual(s) to whom it is
> addressed and may be privileged and confidential. Unauthorised use or
> disclosure is prohibited. If you receive this e-mail in error, please
> advise immediately and delete the original message. This message may have
> been altered without your or our knowledge and the sender does not accept
> any liability for any errors or omissions in the message.
>
> Ce courriel est confidentiel et protégé. L'expéditeur ne renonce pas aux
> droits et obligations qui s'y rapportent. Toute diffusion, utilisation ou
> copie de ce message ou des renseignements qu'il contient par une personne
> autre que le (les) destinataire(s) désigné(s) est interdite. Si vous
> recevez ce courriel par erreur, veuillez m'en aviser immédiatement, par
> retour de courriel ou par un autre moyen.
>

Re: Animation enhancements

[Nir Lisker]

So the questions remain about embedded animations. If an animation has a
"starting" and it is embedded, should it pause a sequential animation? This
is the same problem with the the cycle synchronous events. For parallel,
does it delay only itself so that the animations are not parallel anymore?
Or, we could ignore this event when embedded. Do you have any other idea?

On Tue, Sep 11, 2018 at 6:50 PM Brian Hudson 
wrote:

> Async: started, cycleStarted, cycleEnded, ended, paused, resumed
>
> A "starting" event would have to be synchronous to work as I described.
> The other "-ing" events probably aren't useful an cause the complications
> you describe.
>
>
>
> On Tue, Sep 11, 2018 at 10:11 AM Nir Lisker  wrote:
>
>> So the "-ed" events are synchronous? That is, in case of "started", the
>> animation needs to wait until the event handling finished and then start.
>> In the case of "starting", the animation would start and call the event
>> handler asynchronously (like "finished" does now).
>>
>> Synchronous events can be problematic because they interfere with the
>> running of the animation. A "cycleStarting" (for example) handler will need
>> to suspend the animation somehow before each cycle for an unknown duration
>> (because it can't know what you put in the handler code). This can be done
>> in practice via something like Future, but I'm skeptical about how much
>> this would fit with the current animation semantics.
>>
>> There is a case for "starting" though, which is that it doesn't interfere
>> with a running animation, and that it can be used as a
>> "prepare-then-start", as you said. But what happens when the animation is
>> embedded in a sequential and parallel transitions?
>>
>> I agree that other "-ed" events are not that useful. We can discuss a
>> "prepare-then-start" mechanism.
>>
>> On Tue, Sep 11, 2018 at 4:09 PM Brian Hudson 
>> wrote:
>>
>>> starting: Indicates that the animation is about to start. This is the
>>> last opportunity to change an aspect of the animation that cannot be
>>> changed once the animation has started. PathTransition duration for example.
>>>
>>> started: The animation has started.
>>>
>>> The "-ed" actions are really what I've had a need for, other than
>>> "starting" I can't really think of use cases for the other "-ing" events
>>>
>>> On Tue, Sep 11, 2018 at 4:42 AM Nir Lisker  wrote:
>>>
>>>> Hi Brian,
>>>>
>>>> Thanks for the input. How is "starting" different from "started" etc.?
>>>>
>>>> On Mon, Sep 10, 2018 at 6:23 PM Brian Hudson 
>>>> wrote:
>>>>
>>>>> I would love to see "Animation needs more events" resolved [1].
>>>>>
>>>>> Maybe following events: started, paused, resumed, cycleStarted,
>>>>> cycleEnded,
>>>>> stopped/ended? These additional life cycle events would allow me to do
>>>>> some
>>>>> things with animations/transitions that I've been struggling to do.
>>>>>
>>>>> There may even be use cases events for starting, pausing, resuming,
>>>>> cycleStarting, cycleEnding, stopping/ending.
>>>>>
>>>>> [1]: https://bugs.openjdk.java.net/browse/JDK-8092408
>>>>>
>>>>