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

2018-05-02 Thread 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 
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 
>> 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 
>>> *Sent:* Saturday, April 28, 2018 1:06 AM
>>> *To:* Murali Billa 
>>> *Cc:* openjfx-dev@openjdk.java.net Mailing >> >
>>> *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

2018-05-02 Thread Kevin Rushforth

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 
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 
*Sent:* Saturday, April 28, 2018 1:06 AM
*To:* Murali Billa 
*Cc:* openjfx-dev@openjdk.java.net Mailing 
*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

2018-05-02 Thread 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 
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 
> *Sent:* Saturday, April 28, 2018 1:06 AM
> *To:* Murali Billa 
> *Cc:* openjfx-dev@openjdk.java.net Mailing 
> *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

2018-05-02 Thread Murali Billa
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  
Sent: Saturday, April 28, 2018 1:06 AM
To: Murali Billa 
Cc: openjfx-dev@openjdk.java.net Mailing 
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: native libs in modules

2018-05-02 Thread Johan Vos
FYI, the native-libs-in-mods issue is being discussed on the panama-dev
list as well:
http://mail.openjdk.java.net/pipermail/panama-dev/2018-April/001543.html

- Johan

On Tue, May 1, 2018 at 6:01 PM Kevin Rushforth 
wrote:

>
>
> On 4/30/2018 8:58 AM, Michael Paus wrote:
> > Am 30.04.18 um 17:29 schrieb Kevin Rushforth:
> >> One thing to note is that unlike the JDK build, all class files for
> >> Windows, Linux, and Mac are set up to be built (but not shipped) on
> >> all three platforms, so it might be possible to create a jar file
> >> that would be the same on all three platforms. I don't know how
> >> feasible it would be or whether that the right direction to take or not.
> > If possible, I would like to see a change in this policy to not ship
> > certain fragments of the build. Especially I would like to have the
> > possibility to use a JavaFX based on OpenGL on Windows too. This would
> > make Java truly cross-platform and might offer a lot of possibilities
> > for better integration of external graphics tools like for example
> > tools based on JOGL. It might also offer the possibility to support
> > WebGL in the WebView in the future so that this gap can be closed too.
> > Am I just dreaming? What do others think?
>
> This is somewhat tangential to the issue of how to ship the native
> libraries and platform-specific classes for each platform. While it is
> true that the prism_es2 classes and native libraries are compiled on
> Windows platforms, they aren't part of the build artifacts, and aren't
> ever run or tested at all. So it wouldn't be as simple as shipping
> something that is currently not shipped. Doing so would require a bit of
> work, not to mention a bug tail since OpenGL drivers for Windows tend to
> be buggy (especially for Intel HD). As for WebGL, it would probably make
> more sense to use ANGLE to translate to D3D on Windows than try to rely
> on OpenGL being available everywhere.
>
> -- Kevin
>
> > Michael
>
>


Re: Bug in SceneBuilder 9

2018-05-02 Thread Johan Vos
Hi Sverre,

I think the best place to submit this issue is here:
https://bitbucket.org/gluon-oss/scenebuilder/issues?status=new=open

- Johan

On Wed, May 2, 2018 at 10:15 AM Sverre Moe  wrote:

> I think I have found a bug in SceneBuilder 9.
>
> I cannot find an existing bug report for this:
>
> https://www.oracle.com/search/results/_/N-8d?Ntt=SceneBuilder%20TitledPane=1=1=bugs=106=S3
>
> When adding a TitledPane, its default styling is not applied.
> Within SceneBuilder the TitledPane lacks the border and title
> styles(background, collapsible arrow). An empty TitledPane shows only
> the title and nothing more. It looks just like a Label or Text.
> Running the FXML with an Java 9 application shows the TitledPane as it
> should be.
>
> Where should I submit this bug report?
> bugreport.java.com, GitHub mirror or with Gluon?
>
> /Sverre
>


Bug in SceneBuilder 9

2018-05-02 Thread Sverre Moe
I think I have found a bug in SceneBuilder 9.

I cannot find an existing bug report for this:
https://www.oracle.com/search/results/_/N-8d?Ntt=SceneBuilder%20TitledPane=1=1=bugs=106=S3

When adding a TitledPane, its default styling is not applied.
Within SceneBuilder the TitledPane lacks the border and title
styles(background, collapsible arrow). An empty TitledPane shows only
the title and nothing more. It looks just like a Label or Text.
Running the FXML with an Java 9 application shows the TitledPane as it
should be.

Where should I submit this bug report?
bugreport.java.com, GitHub mirror or with Gluon?

/Sverre