Garret Wilson Blog

Almost exactly a decade ago, I and my company, GlobalMentor, Inc., were part of a group of organizations that defined the modern ebook industry. As part of the Open eBook Forum, now the International Digital Publishing Forum (IDPF), we created a specification that have recently become popular on the newest reading devices from companies like Sony. I was development co-chair of the OEBPS 1.2, before it became known as EPUB, and I developed and released the first publicly available native OEB reading software.

Some days I feel like giving faith-based God-believers the benefit of the doubt (no pun intended), that their approach to reality is somehow reasonable. On other days, such as today reading about about how Phillip Garrido hears voices from God, the whole thing makes me sick. Reason will say that the Bible is full of myths. Abandoning reason and relying on personal communication with God puts you on the same shaky ground as Phillip Garrido, ready to believe that it's OK to let your own daughters be raped if you think God wants it so.

Several logging systems exist for Java. There is the Java logging built-in to the latest libraries, which doesn't allow very flexible configuration and doesn't even allow source code line-numbers in the log. There is also the tried-and-true Apache Log4j package, which offers great flexibility but isn't built-in to Java. These two systems have a lot in common, and oftentimes a project is forced to choose one or the other based mostly on the personal preferences of the team members. Once a project commits to a particular logging framework, it's not so easy to switch, as logging is pervasive in the code. Furthermore, logging framework choice is global, even if the framework chosen has flexible configuration. I've created a new logging framework that provides a simple, generalized interface that can be configured to delegate to your favorite logging system, or to rely on its own easy-to-use default implementation.

Serialization of objects has many uses in Java, including persistence of a particular state; communication with other applications; and storing of an application's configuration when the program is not running. The latter use case, storage of configuration information, has its own set of constraints that require special attention when serializing. Simply handing off a configuration object to some serialization service is not enough. Diligent planning of serialization is required to produce configuration files that are accessible to editing and flexible enough not to break as your application evolves.

A conundrum that repeatedly appears across all areas of software architecture is how to provide configuration information to those parts of the program that need it. Ideally the root module that loads or otherwise creates the configuration information would pass the information to the needed area. For example, MyApplication may load MyApplicationConfiguration and pass that to MyDialog via its constructor, allowing the dialog to tailor its information based upon the application's current settings.