Since the JUL loggers sit in the system class path, any formatter implementation
must be available also in the system class path. For simple Java applications
this is no issue, simply set the VM class path at startup, but this is no longer
true if the app deals with classloaders. I was bitten the first time using the
uberjar mechanism of Maven1 that uses an own classloader to extract the classes
from the embedded jars, my JUL formatter was simply no longer available. In a
Java EE environment your "simple" formatter is never used - unless you put your
jar with the formatter implementation into the JRE's ext directory or setup the
app server accordingly. However, I don't have to tell you, that as consequence
no web or enterprise app will be able to use its own version of this jar.
There is a reason why JUL was never a real success story.