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
