The CodeMonitor^TM for Java is a monitoring system for Java bytecode. It injects logging statements into the classes of an Java application at selectable places.

It helps you to generate logging-output at specific places inside your Java software, without the necessity to edit the source-code.

Monitoring (of Java bytecode) is therefore an activity separated from the normal way of “writing” software, and enables a flexible view into emerging or existent Java applications. It helps tremendously in the finding and identifying of software's bugs and in the assurance of software's quality.

Why CodeMonitor^TM for Java?  CodeMonitor minimizes the costs of development of your applications and maximizes your insight into your application - both at runtime and during development. CodeMonitor offers many essential features needed for monitoring enterprise applications which you will not find in any other logging or debugging system.

Monitoring vs. debugging.  Debuggers are special tools used by software developers to find bugs inside software systems. They are often used interactively to step through a particular program or to execute the program until it hits a specific breakpoint. With debuggers developers are able to watch internals of a running program, to examine its live state, and to directly change modifyable variables.

The drawbacks of debuggers are that they require runtime environments with special debugging support, which aren't always available, especially on production systems. Debuggers change the threading behaviour of the debugged software dramatically and often mask difficult to find timing bugs, especially in distributed applications. The strength of liveness has its drawbacks too, because a running debugger requires the active attention of a developer, whose time is expensive and also not always available. Debugging sometimes degrades developer discipline because debugging is thought of as a “one shot activity” to hunt bugs, but not as a planned and systematic activity to enhance product quality and to find and prevent bugs from the beginning. The setup generated during debugging is often wasted and lost, and therefore not reusable as part of quality assurance later on in the project.

Monitoring vs. logging.  Logging is a low-tech method sometimes called “poor man's debugging” used in situations where a debugger is not available or could not be successfully used, for example in distributed enterprise applications. With the insertion of logging and tracing statements into the source code of a program developers try to get an understanding of the program's behaviour. The developer selects points in the source where he or she manually writes some output statements, compiles the source to bytecode, and deploys the generated class-files to the runtime environment, where they are executed. This time-consuming process needs the source-code and a development environment to compile it, both aren't always available, especially on test- and production-systems.

Manually written logging statements are “noise” injected into source-code which implements functionality relevant to the customer. Not only that this way important program-structure gets hidden, which endangers developer's understanding of the program and therefore it's quality, writing logging statements manually is tedious, error-prone and a source of bugs in its own. On some projects logging statements count up to more than 50% of code written, which unnecessarily wastes developers' important time, because it is not used for the implementation of functionality.

Automatic insertion of monitoring code doesn't depend on the availability of source-code or a development environment and isn't as inflexible, error-prone, and time-consuming as manually writing logging statements. Automatic insertion eases developer's life, because the discipline necessary to systematically monitor the program's behaviour is embodied in XML-documents, which specify what, how, and where to monitor, and is enforced by CodeMonitor. The documents themselves may become part of the program's system documentation and are reusable in later stages of the program's life-cycle, even it's operation.

Monitoring vs. aspect-weaving.  While most logging toolkits solve the problem of managing and viewing the logging output, they doesn't support the developer in writing corresponding logging statements. This task is done manually by the developer who is responsible for a specific piece of program code. The new trend of aspect oriented programming tries to support this task by defining aspects, which are put into some selectable places. The drawback of this approach is the necessity to use special programming languages with special compilers, whose use must be allowed for in an early stage of a development project. To get benefits from this technology for projects which have already reached a later stage or are even deployed to customers is nearly impossible to achieve.

CodeMonitor^TM for Java supports standard logging toolkits.  CodeMonitor supports different logging toolkits and systems. Currently adaptors for the Logging API of Java introduced with JDK 1.4, Log4J and LogKit of the Apache's Jakarta project, and simple stream-output are available.

No lock into CodeMonitor^TM for Java.  Most tool provider strive to lock customers into their products. At tangentum technologies we believe in the freedom of choice and therefore only act as catalysts in the interest of our customers. We like to play an important role in the development, but don't like to become part of its results.