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

[Kevin Rushforth]

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.billa at oracle.com 
> <mailto:murali.billa at 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 <nlisker at gmail.com <mailto:nlisker at gmail.com>>
>     *Cc:* openjfx-dev at openjdk.java.net
>     <mailto:openjfx-dev at openjdk.java.net> Mailing
>     <openjfx-dev at openjdk.java.net <mailto:openjfx-dev at 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)1^st 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 1^st 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 <nlisker at gmail.com <mailto:nlisker at gmail.com>>
>     *Sent:* Saturday, April 28, 2018 1:06 AM
>     *To:* Murali Billa <murali.billa at oracle.com
>     <mailto:murali.billa at oracle.com>>
>     *Cc:* openjfx-dev at openjdk.java.net
>     <mailto:openjfx-dev at openjdk.java.net> Mailing
>     <openjfx-dev at openjdk.java.net <mailto:openjfx-dev at 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
>     <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
>
>