I pushed updates to github taking into account much of the feedback I received. The updated code has the following: 1) Simplified 2.0 API for logger and adapter writers. The idea is to make it much easier to write adapters/loggers and reduce risk of bugs by removing application facing API specifics such as formatting and Logger method signatures from adapter/logger implementations. Future enhancements to Logger may be made with less concern about breaking binary compatibility. 2) Maintain binary compatibility with all pre 2.0 adapters while not restricting future additions to the Logger interface. New Logger methods will work with old adapters. The tradeoff is that old loggers will not have access to the raw messagePattern - LocationAwareLogger does not support this. Non LocationAwareLoggers will not have access to the message parameters. So, Logback filtering on the raw messagePattern (using a pre 2.0 compatible logback) will be slightly less accurate, but it will be no worse than in 1.6 when using a wrapper such as XLogger. New 2.0 style loggers and adapters should have a maven dependency for the 2.0 slf4j-api. This will in no way break existing apps that for whatever reason may also bring in "other" 1.6 components as long as the app is compiled and deployed on Java 5+. 3) Addition of log Entry objects similar to Message objects that have been discussed. This design does not attempt to unify audit and access log APIs, but otherwise provides all of the capabilities of Message objects with the additional benefit that Entry objects can control Level and Marker. For example, an advanced application writer may have a custom EventEntry class that properly translates domain specific details to Level & Marker, such as map EventType.SECURITY_VIOLATION to Level.WARN, etc. A StructuredData object may accept syslog severities, but automatically translate to the appropriate slf4j Level in order to support adapters that do not understand StructuredData. 4) The log Entry interface is minimal, with additional interfaces adding functionality. Adapters that support additional functionality can use "instanceof". Future version of SLF4J may introduce additional features exposed through new interfaces without breaking compatibility with older adapters. 5) Support for logger.withFormatter(Formatter x) while maintaining Logger immutability and support for pre 2.0 loggers. I am not proposing this be included in the 2.0 API. But I feel that it is valuable to explore how this type of feature (formatting or whatever else may come) could be added to loggers in the future while the 2.0 API is being worked out. 6) I removed supplementalData and the numerous arg1...arg6 methods. I agree with Joern that it is probably best to avoid Google Collections style methods given the relatively low cost of implicit Object[] creation. There may be some value to supplementalData, but under this 2.0 proposal, it could be added any time in the future, so no use worrying about it now. Disclaimers - Unit tests pass with both 1.6 and 2.0 style adapters, but I haven't fully tested them for things like FQCN. And, of course, claims of binary compatibility while introducing features are nothing more than theory until fully tested. - A new interface LoggingProvider specifies what must be implemented for 2.0 style adapters. But, adapters still also implement Logger by extending AbstractLogger. The class hierarchy and clarity may be better if 2.0 adapters simply implemented LoggingProvider with a LoggerImpl created by LoggerFactory. - Legacy adapters are wrapped each time they are created. It may be better to cache them in LoggerFactory with a WeakHashMap<[old]Logger, WeakReference<[wrapped]Logger>> to save some cycles and GC. - Class naming and package structure needs some work - LoggingProvider, Level, Entry and various Entry sub interfaces, etc. - deserialization needs work. The new code is available at https://github.com/jvasileff/slf4j/tree/topic-jdk5-varargs An additional test branch that reverts all adapters, XLogger, and EventLogger to 1.6.2 source for basic compatibility testing is available at https://github.com/jvasileff/slf4j/tree/topic-jdk5-legacy-adapter-test John