Disabling Apache POI Logging

Image via Wikipedia

In order to effectively disable the logging functionality in Apache POI you must use an alternative logger. This is accomplished by providing a property to the POILogFactory to override the default logger. Examining the partial code from the POILogFactory, we see that we can pass a logger name into it.

public static POILogger getLogger(final String cat)
    {
        POILogger logger = null;
        
        // If we haven't found out what logger to use yet,
        //  then do so now
        // Don't look it up until we're first asked, so
        //  that our users can set the system property
        //  between class loading and first use
        if(_loggerClassName == null) {
         try {
          _loggerClassName = System.getProperty("org.apache.poi.util.POILogger");//<<---------- Logger Name
         } catch(Exception e) {}
         
         // Use the default logger if none specified,
         //  or none could be fetched
         if(_loggerClassName == null) {
          _loggerClassName = _nullLogger.getClass().getName();
         }
        }
...

So we need to simply set the Logger property which can be accomplished from the command line. We will use the Apache Commons Logging Library to accomplish it.

-Dorg.apache.poi.util.POILogger=org.apache.commons.logging.impl.NoOpLog

Disabling Logging on Apache Commons Logger

I was looking for a quick way to disable logging on Apache Commons Logger so that I could do some testing without overhead. Here is a command line option for setting the logger to a no-op logger.

-Dorg.apache.commons.logging.Log=org.apache.commons.logging.impl.NoOpLog

Closures in Java 6

Image by Zoë Campbell via Flickr

Closure...

I met a really neat guy at JavaOne. His name is Llewellyn Falco. We met during the Java User Group (JUG) Sunday prior to the event. He was a participant in the un-conference we had set up to discuss topics of interest to the JUG community.

I was the moderator for a discussion of "languages on the JVM". The talk was slated for 45 minutes, but like all good discussions it evolved into a 4 hour talk. We started with about 12 people, and grew to half a conference hall room.

At one point we had devolved from JVM languages to simply the JVM. On my immediate right was Stephen Colebourne, and to his left was Llewellyn Falco. I asked what new features would you consider important in the JVM. Llewellyn said "closures". Stephen compiled a list of the top 10 items like: closures, continuations, AOP, Design by Contract, etc. After compiling the list, we asked the participants to pick three by vote tally on the cards for each topic. Closures won hands down.

I turned on the crowd..."Why do you want closures? What is the use case? Can you explain in simple terms what "closures" are for the common man, and why should I care?" I wanted a discussion. I wanted to make sure that I did not have a bunch of complacent sheep that wanted it because "everyone else wants it".

Llewellyn stepped up. He had an elegant explanation for closures, a use case, and clearly defined examples. He even quoted C#(EVIL...HISS!) and its use of closures. Stephen (who is more far more well versed than me), countered with some probing questions. Llewellyn did not falter, and answered the questions very quickly and eloquently.

The session ended on very pleasant terms, and we all had a great time.

Roll Forward...Two Days

I was in the JavaOne tent with Sven Reimers (Duke Award Winner and NetBeans Dream Team Member), and Martin Klähn (new community leader) chatting. Llewellyn came in with bloodshot eyes and told us he had JDK 6 "closures". He had been up late coming up with the code. He gave us a demo of what he had done. It was really cool! My partners in crime were leaving for another technical session, so I stayed and looked at the code. Finally, I came to the conclusion that something was not right. Llewellyn admitted he changed Object, and added extension methods to Object. 

This creates a "long tail" for Object which should be immutable. This is not a good idea. The question is where the extension methods end.


OK, I don't like playing with Object and using the classloader to cheat faith. His approach is cool! If you need "closures", and you can't wait for JDK 8; this is a solution. I am not opposed to improving developer productivity, I am just concerned about the extension of Object.


Please read Llewellyn Falco: Lamdbas in Java 1.6 blog on it. It is very well written, and offers the developer options. 

Thanks Llewellyn and Stephen! You are both awesome and brilliant. I am humbled at your great ideas, and I think we all have an opportunity to learn from your ideas.