diff doc/devel/logging.md @ 0:61d41facf527

initial v8 import (history reset)
author Peter Mehlitz <Peter.C.Mehlitz@nasa.gov>
date Fri, 23 Jan 2015 10:14:01 -0800
parents
children
line wrap: on
line diff
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/doc/devel/logging.md	Fri Jan 23 10:14:01 2015 -0800
@@ -0,0 +1,31 @@
+# The JPF Logging API #
+There is one simple rule: do not use `System.out` or `System.err` for any permanent logging
+
+
+Of course we all do this temporarily during debugging, but it really shouldn't stay in the code. The logging infrastructure is quite easy to use. Just declare a static `Logger` instance with an appropriate id (either package or logging topic) at the top of your class, and then use the `Logger` API to create output:
+
+~~~~~~~~ {.java}
+...
+import java.util.logging.Level;
+import java.util.logging.Logger;
+
+package x.y.z;
+
+class MyClass .. {
+  static Logger log = JPF.getLogger("x.y.z");
+  ...
+    log.severe("there was an error");
+  ...
+    log.warning("there was a problem");
+  ...
+    log.info("something FYI");
+  ...
+    if (log.isLoggable(Level.FINE)){    // (1) don't create garbage
+        log.fine("this is some detailed info about: " + something);
+    }
+  ...
+}
+~~~~~~~~
+
+Note that there is only one instance for each `Logger` ID, i.e. you can have a corresponding static field in all your relevant classes, and don't have to share the fields. Another aspect that is mostly important for the lower log levels (e.g. `FINE`) is that you should't concatenate log messages in operations that occur frequently, since the corresponding `StringBuilder` instances can cause performance degradations even if the log level is not set (the arguments still get evaluated). In this case, encapsulate the logging in `log.isLoggable(level){..}` blocks.
+