Let us imagine a large java system, composed of independently
compiled modules and jars from multiple providers, without any
universal dependency other than the standard API.

On top of this collection of runtime dependencies, you have
built an interactive GUI framework.  Whenever there is an error
or a warning, you want to pop up an appropriate error dialog or
update a message panel.

Many of the plugin packages may not be designed for a GUI.
Preferably, they report errors by throwing appropriate checked
exceptions.  Sometimes, however, they could report some
additional details about exactly what went wrong.  Even though
they fulfill most requests, they might still call attention
to some problems along the way.  (E.g. ``Unable to load 2 of 100
files: file1, file2''.)  Any number of useful messages could be
presented to a user with a "more details" button.

Saving information for an error dialog is really no different
from logging in general.  In fact, there are probably many
useful error messages being saved to logs already, but
invisible to users.

Logging for users requires a little more care, however.  User
messages belong in resource files, in a simple format that can
be edited or translated by non-programmers.  If this step has
been taken, we can assume the message is appropriate for
presentation to an end-user.

Even so, logging for a GUI requires no features on the client
side that are not already available in the standard Java
``Logger'' in ``java.util.logging''.  Much third-party code is
likely to be using it already.  All you need is some custom
filtering, and formatting, which the logging service
conveniently supports.

To see how powerful this simple API can be, first read
https://blogs.oracle.com/corejavatechtips/logging-localized-message

Your usability experts and technical writers can edit and
correct the messages in the resource files.  A non-programmer
can add new languages at any time.

To select and format messages appropriately for GUI dialogs,
the framework needs to add a custom
``java.util.logging.Handler'' to the standard logging system.
We can add as many custom Handlers as we want.

Each Handler can have a custom ``Formatter'' or ``Filter'', to
decide what messages deserve to appear in an error dialog.  A
Handler can filter by package or class names, by
``java.util.logging.Level'', by message ID numbers, and more.

Before the GUI framework calls a service API from a plugin, it
can first clear the custom Handler's cache of messages.  After
the service returns or throws an exception, the GUI framework
can check the custom Handler to see if any SEVERE or WARNING
messages were logged.  If so, these could be included in an
error or warning dialog.  Preference could be given to error
messages logged first, or logged with a ResourceBundle.  If too
many messages fell into these categories, we could get prepend
a special tag to the logger name.

I strongly discourage any custom wrapping of the client API for
Logger.  There is nothing special about the way we need to log
these messages -- only in the way we format and present them.
Normal logging is still free to capture logging intended for
error dialogs.  The point of a standard Logging API is that it
is standard, and is used by all code, including third-party
code, without any compilation dependencies.

You might think using the standard Logger is too difficult for
most clients.  How difficult is this?

=>
Logger.getLogger(Foo.class.getName()).severe("fileNotFoundMessage", filename);
<=

That one-liner identifies the package and class originating the
message, specifies an error level, specifies multilingual
resource files ``Foo.properties'' (default) or
``Foo_es.properties'' (Spanish), and uses MessageFormat
to combine arguments like printf.

Of course a optional static convenience method could also be provided.

Logger was already designed for all the customization we need,
with a simple API we would do well to study.

Message IDs should remain unique for support calls.  These
could appear as an alphanumeric code in each error message and
would also serve as the logged message name.

Bill Harlan, June 2009