That all sounds good.

As for the packager, it will likely continue to be a source of issues like this now that it is gone from the JDK, and isn't part of the unbundled FX builds.


I just filed a bug [1] to remove the qualified export from javafx.graphics to jdk.packager (and to disable building the packager even when building using an Oracle JDK) -- see my recent reply to the OpenJFX updates thread [1]. Perhaps I should expand that issue to remove references to it from the IDE files as well.

Ultimately, we should delete modules/jdk.packager* and the references to it in build.gradle, etc., but that can be done as a follow-on cleanup issue, which I just filed [3]. Note that the source code would still available for anyone who wants it, either from the openjfx/10u-dev/rt repo or from the openjfx/jfx-dev/rt repo using the jdk-11+13 tag.

-- Kevin

[1] https://bugs.openjdk.java.net/browse/JDK-8203378
[2] http://mail.openjdk.java.net/pipermail/openjfx-dev/2018-May/021894.html
[3] https://bugs.openjdk.java.net/browse/JDK-8203379


On 5/17/2018 2:07 PM, Nir Lisker wrote:

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





Reply via email to