Marc, I think Joseph was referring to the fact that most Java applications today use either java.util.logging or log4j and they are unlikely to use another third party products logging interface unless it offers something truly worthwhile. Looking at the Delphi code examples it would that there is a requirement to bind to an API.
I am not sure that this is the case for the Java edition. I would hope not. Today many tools including JXInsight support the integration of logging events into external consoles and tracing/profiling models via static or dynamic registration of handlers or appenders.
I have to say that I am somewhat confused with the classification of message debugger. Don't all debuggers emit events (messages)? Is this a reference to transport mechanism used between debugged process and console? Will the source code appear in the console with step through capabilities?
The high degree of interest in the Java community related to logging has always fascinated especially when I see it cause so many performance problems in server applications. The costs benefit analysis around most implementations / introductions of logging is not very favourable. I know large software companies who have invested heavily, via common component architecture group, in creating general purpose logging facades.
The problem with logging is it is too easy. A large portion of logging calls are unwarranted and incorrect. The log entries have the amazingly ability to contain lots of data but rarely the required information in resolving an issue (there are lots of support organizations who can confirm this). I think one of the problems is that the developer more than likely does not understand who the target audience is for a log entry and what kind of issues are likely to occur in local called/calling code and when arising what information is relevant to the execution context. This is really a hard task for a developer who is meant to be getting the application logic working. There is also the issue of asking the developer of the actual codebase to be instrumented (logged enabled) to write the actual log statements. I also find logging statements to be not well maintained which could be as big a problem as not having logging in the source code.
A much bigger issue with logging is the lack of scalability (consoles, visualizations, processing) and inefficiency. Operations and support staff require patterns that have business meaning to be readily identifiable from logging events not neccessarily stored in a file. Currently logging systems look at each entry in isolation in determining whether it should be stored. Even worse this is somewhat static in terms of the log level defined in the source code and the logging system. This approach means that much more data needs to be written to the log store so that post processing tasks might have a slight chance in rebuilding parts of the execution context. Logging systems needs to work at the event pattern level and judge the log level in relation to previous events and expected events. Only at the pattern level (match) is a decision made to record the information and how much.
JXInsight as well as a number of other performance management products are providing this intelligent event pattern matching mechanism. JDBInsight (a subset of JXInsight) today turns JDBC invocations into resource transactions patterns via temporal and object casuality, filtering, aggregating, enhancing/enriching as well compressing (local and global loops).
TIBCO recently announced BusinessEvents which is based on the Rapide event pattern language described in the book "The Power of Events".
JXInsight Product Architect
"J2EE tuning, testing and tracing with JXInsight"http://www.jinspired.com