JDK-8102272 : Remove javafx-logging and replace with direct use of java.util.logging
  • Type: Enhancement
  • Component: javafx
  • Sub-Component: controls
  • Affected Version: 8
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2012-08-23
  • Updated: 2015-06-16
  • Resolved: 2012-12-20
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 8
8Fixed
Related Reports
Blocks :  
JDK-8116056 - Upgrade to use PlatformLogger.Level instead of primitive int type
Duplicate :  
JDK-8098893 - Synchronize PlatformLogger with JDK7
Sub Tasks
JDK-8102763 :  
Replace use of javafx-logging in Glass with java.util.logging - Resolved
JDK-8102764 :  
Remove Glass dependency on javafx-logging - Closed
Description
We don't get any benefit out of having an abstraction layer for logging. We could use java.util.logging directly instead of PlatformLogger. PulseLogger could be moved into a leaf package such as Glass.

Affected components are:

javafx-concurrent (PlatformLogger)
javafx-ui-controls (PlatformLogger, in both code and tests)
javafx-ui-common (both PlatformLogger and PulseLogger)
javafx-ui-quantum (PlatformLogger and PulseLogger)
prism-common (PlatformLogger and PulseLogger)
javafx-sg-common (PulseLogger)
glass-mat (PlatformLogger)
javafx-sg-prism (PulseLogger)
toys/HelloWorld (PlatformLogger)
Comments
FYI, RT-24460 is going to be the task (should have been a tweak!) for removing javafx-logging. The comment I put there is repeated here: "I think moving PulseLogger into Glass is the best thing to do. However it is presently open source, and so we can't really do this until after the glass code is open sourced. So for the time being, we'll keep the javafx-logging project around."
20-12-2012
(RT) Revision: 2034 Changeset: 56b4b95afb0171d83bafd79b98137964486c2efb [56b4b95afb01] Parents: 2033 Author: Richard Bair <richard.bair@oracle.com> Date: December 19, 2012 9:16:21 PM PST Labels: tip Fix for RT-24458: Remove javafx-logging and replace with direct use of java.util.logging. I did not remove the javafx-logging project in this change set. Will look at that separately. (RT-Closed) Revision: 17673 Changeset: e4e6f9df04c2e431a8b566a6a115e3bbeb9db178 [e4e6f9df04c2] Parents: 17672 Author: Richard Bair <richard.bair@oracle.com> Date: December 19, 2012 9:16:36 PM PST Labels: tip Fix for RT-24458: Remove javafx-logging and replace with direct use of java.util.logging. I did not remove the javafx-logging project in this change set. Will look at that separately.
20-12-2012
> I'm building with JDK7 and I'm getting the following build failure: > > error: package sun.util.logging does not exist When javac is compiling code it doesn't link against rt.jar by default. Instead it uses special symbol file lib/ct.sym with class stubs. And the answer to my question is: javac -XDignore.symbol.file That's what javac uses for compiling rt.jar.
04-12-2012
A summary of opinions in a recent e-mail thread. If I misrepresented or overly abbreviated your statements, please correct me. Artem: Let's do this. Let's use the most lightweight option. Kevin: If we are going to do it, now is the time Mandy: sun.util.logging will be in the base module, java.util.logging won't. sun.util.logging will use j.u.l. when it is available. Recommends using s.u.l. Steve: Let's pick a solution that is good enough and go with it. Daniel: s.u.l. is a good fit
21-11-2012
After a small amount of digging into the Logger situation we have: java.util.logging is standard in Java 1.4 and later, and of course is a huge resource hog, and pulls in lots of extra classes sun.util.logging was adding in java 1.7 to address the hog factor, and is intended for internal groups like us. The API is not a 1x1 match with java.util.logging (no separate Level class is in PlatformLogger, Logger -> PlatformLogger). This logger was simplified so as not to pull in as many classes as java.util.logging does. com.sun.javafx.logging appears to be a clone of sun.util.logging into javafx namespace. The class names are the same, the Level values are in PlatformLogger like sun.util.logger. There are about 30-40 uses of this class in JFX. Conclusions: * As long as we require Java 1.6, we cannot use the java 1.7+ preferred sun.util.logging * switching from com.sun.javafx.logging to java.util.logging would be effort that will need to be at least partially undone when we can move to sun.util.logging * when we switch to java 1.7 as a minimum, we should be able to refactor the current uses of com.sun.javafx.logging.PlatformLogger -> com.sun.logging.PlatformLogger (likely with minimal effort)
07-09-2012
What we want to do is to use the sun.util.logging.PlatformLogger, rather than using JDK logging directly. However this then needs to be done after we stop building on Java 6. But we have other stuff in javafx-logging now, such as the pulse logger, which should continue to exist.
24-08-2012
Assign to Richard to determine whether we want to do this at all.
24-08-2012
Agreed!
24-08-2012
RT-10201 suggests the com.sun.javafx.logging package be removed as soon as we switch to an FX version that only supports JDK 7+ since there's already sun.util.logging.PlatformLogger which does basically the same thing. FX 8.0 is going to support JDK8 only, so this is clearly a good task for this release to remove the com.sun.javafx.logging and switch over to using the JDK package instead.
24-08-2012
The problem is that JDK logging is a behemoth and pulls in a lot of additional classes. You'll find that AWT also has an indirect access to logging such that it only uses JDK logging if somebody else has fired it up, otherwise it just does a quick toString. That was the main reason behind adding the logger indirection.
23-08-2012