Using Your Own Stuff Is Good

Using your own stuff is good! Nothing remarkable about that, almost every developer would agree on that. In fact this is how Microlog once was created. It was created out of a real need and I used it extensively from the beginning. As years has gone by, a lot of contributions has been made. The philosophy behind Microlog is that there should many different logging destinations, each suitable in its on special situations. Which logging destination you choose is a matter of taste and the technical circumstances. As a consequence I tend to use a small portion of Microlog, beside the core classes.

The project I am currently involved in has been running for several months before I joined. The initial team has been wise enough to choose Microlog. When I joined the project, Microlog V1.1.1 was used. Yesterday I was given the assignment of logging some low level details, that potentially could create a lot of logging output. To be able to control the logging with fine granularity, I needed the newest and hottest version of Microlog. Its support for hierarchical loggers, makes it possible to set different logging levels on different classes. In my case I wanted to use TRACE for one class, but DEBUG for the rest of the classes. In my own projects, I usually only import the classes that I really need and leave the rest out. In some cases I have used the binary version of Microlog and ProGuard to keep the packaged Microlog classes to a minimum. The current project is different, Maven is used for building. As such it uses a repository for its jar files.

I added Maven code to use the latest version of Microlog snapshot. When I used it on my own computer this worked like a charm, but one of my colleagues complained that he could not perform a build. It was missing a jar file from the Microlog repository. As it turned out, this jar was missing. It was available for Microlog V1.1.1, but not for the latest snapshot build. It was very easy to solve, just copy a directory and the repository was working the way it should.

Other problems emerged when configuring Microlog. The original idea was that the new PropertyConfigurator should be backward compatible, in order to make it easy to upgrade from Microlog 1.x.x to Microlog V2.0. I found one bug; a property name had changed. This was also easy to fix. Another deploy and the repository contained the fix. The other problem is that I have re-structured the packages, which means that all the appenders and formatters properties have changed. The re-structuring is very important, so I plan to keep the new package names. Although they break the backward compatibility. But since I have changed the major version number, I am not obliged to be 100% backward compatible. When writing this, a new idea has popped up in my head. Maybe I should implement a converter that converts from the old property format to the new property format. Is this a good idea? What do you think?

Using ProGuard to Shrink Microlog

There have been many users that are skeptical to use Microlog due to its size. The current snapshot is around 150 kb, while the latest final release is 127 kb. If you are doing a small MIDlet, this adds considerable overhead to your MIDlet. In normal cases you only use a fraction of all the classes. For example, you only use one or two appenders. The jar contains a lot of different appenders. But there is a solution. The solution is called ProGuard.

ProGuard is an application shrinker/optimizer/obfuscator for Java applications. It can be used from the command line or from your favorite IDE, such as Eclipse or NetBeans. ProGuard is an important tool in your MIDlet development toolbox.

The recipe for obfuscating your MIDlet and Microlog is as follows:

1. Select Window -> Preferences
2. Select the Java ME -> Packaging -> Obfuscation
3. Press the "Browse" button and select the directory where you installed ProGuard.
   
   
   
4. Select Project -> Properties
5. Set the dialog to the value according to this screenshot:
   
   
6. Select "Java Build Path"
7. Select the "Order & Export" tab. Check the Microlog jar like this
   
   
   
8. Select your project. Bring up the context menu (in Windows it is done by a right click). Select "Mobile Tools for Java" -> "Create Obfuscated Package". You should now have an obfuscated jar in the /deployed directory. If you run the project as a "Emulated Java ME JAD", you automatically use the obfuscated jar file.
   

For those of you that are not using Eclipse, you could use the following configuration when running ProGuard from the command line.

-overloadaggressively
-defaultpackage ''
-allowaccessmodification
-dontusemixedcaseclassnames
-keep class net.sf.microlog.appender.MemoryBufferAppender
-keep class net.sf.microlog.appender.ConsoleAppender
-keep class net.sf.microlog.format.PatternFormatter
-injars microlog.jar
-injars yourmidlet.jar

Copy the content and save it to a file, for example proguard.conf. Then you start ProGuard like this:

java -jar proguard.jar @proguard.conf.

By using ProGuard you reduce the size of your MIDlet jar. Unnecessary classes are removed, the code is optimized and obfuscated. And using Microlog does not mean lare overhead to your MIDlet. There are other alternatives to ProGuard, but ProGuard is the most widely and de-facot in the lovely world of Java ME.

Microlog is Still Alive!

It was a while since I wrote about what is happening to Microlog. I myself have not been working very much on Microlog the last couple of weeks. But fortunately there are more developers working on Microlog. At the end of last week, the Microlog project was joined by Jarle Hansen. He has been improving the Bluetooth logging in Microlog, to work better on Ubuntu Linux. He has also written an excellent article on the subject "Using MicroLog over Bluetooth with Ubuntu and Eclipse".

Therefore I have released a new snapshot of Microlog. The snapshot version includes the changes made by Jarle Hansen, as well as some minor changes made by me. The snapshot version is also available in the Microlog Maven repository as well.

Report from Presentation at JavaForum in Malmö and Gothenburg

Last week I did present Microlog at JavaForum both in Malmö and Gothenburg. JavaForum is the Swedish JUG. It was a great honor to be invited to both these places. These are my reflections and thoughts about my presentation.

At the first presentation in Malmö there was around 50-60 people. I knew many of the people beforehand, which made me less nervous. The presentation went smoothly and I got some questions, that hinted me what to improve in the presentation. Unfortunately I did not had time to stay afterwards to get some more feedback.

Driving to the destination in Gothenburg at rush hours was not an easy task. My GPS device was out of battery, so I used Google Maps to find my directions. When no GPS device is attached, it uses GSM cells to figure out where you are. The accuracy is about 600 m in a city like Gothenburg. That is maybe enough when walking in a city to find out where to go, but by car that is not enough. What a shame I was not in a Hollywood movie, where the accuracy seems to much better than that. Anyway I found the place to be and was there on time.

Afterwards I had the opportunity to speak to some people in the audience. First of all I got a question about what Maven help I wanted. It is mainly about getting Maven to generate better packages for the releases. For more details see this discussion.

One other question I got, was "What is the reason for not being able to do printStackTrace() and re-direct it to a log? Or do you have any idea how to solve it?". The thing is that I have not found a way to re-direct to another destination within Java ME. The reasons are:

1. The System.err is final in the System class found in Java ME (CLDC). I do not know why this is, but it hinders you as a developer from setting these to something like a FileOutputStream or similar.
2. The method printStackTrace() comes in different flavors in Java SE. For example, the public void printStackTrace(PrintStream s) is useful to direct the stack trace to another destination than the default one. This is not available in Java

One workaround that works under some condition is to re-direct the output from your Java MIDlet outside the JVM found in your phone. On the Symbian platform there are such applications available. If the problem is reproducible in the WTK, you could run it look you normally do. By using the ConsoleAppender you get both the normal exception message along with the stack trace. BTW do you know any other workaround? If yes, please enlighten me.
That is all for now. Thanks to Björn Granvik and Rickard Thulin for inviting me to JavaForum.

"What is Soo Special About Microlog?"

"What is So Special About Microlog?", this was the first question I got this morning when arriving to work. This was asked by one of the Java Enterprise specialists at my work. Hmmm... let me think. I was a bit paralyzed by the question, although I should not be. This is not the first time I get this question, I get this question a lot (from people not working with Java ME).

My first answer was "size!". The Log4j jar is 389kB, but Microlog is about 110 kB. But the actual jar size is not what is interesting, but the overhead that Microlog add to the jar. In normal cases it is somewhere between 30-40 kB, depending on what you decide to use. I consider this to be little overhead considering that you get two appenders with two formatters and the configuration framework with the ability to configure via properties files and/or JAD settings files. Plus you get the ability to setup your loggers in a logging hierarchy. All in all, the small size of Microlog is one of its benefits.

My second answer was "remote logging". Log4j contains some remote logging destinations, like syslog daemons and JDBC. Microlog has also support for logging to syslog daemons. This is one of my personal favorites. It is easy to setup a syslog daemon and you get the logs on the server directly. I choose not to implement JDBC support in Microlog. First of all, it makes me sick to think about setting up a JDBC server. Secondly there is not many JDBC drivers available for Java ME with CLDC. Instead I implemented support for logging to Amazon S3. It is easy to setup and you have access to very much storage for a cheap price. Right now you can upload 1 GB for $0.03. Compare this to the price of setting up a JDBC server. You cannot work for many seconds before you have used up your $0.03! It is also very pratical to log to Amazon S3. For example you log to a file, when the file gets to big or when you log above a certain level, the file is copied to the server. As far as I know this is a unique feature, this is not implemented in Log4j and I do no know any other logging library which has suport for Amazon S3. And that is not all; Microlog has support for sending an SMS/MMS or e-mail as well. Log4j has support for e-mail which is based on a simple SMTP client. Micrologs implementation is a little bit smaller and smarter. It uses the Wireless Messaging API (JSR-205) to send an e-mail. The actual assembling of the e-mail and the sending code is less than 30 lines of code. Quite impressive if you ask me, but I am a little bit biased. What do you think? These are the most important remote loggers, but there are more. Please take a look at the Microlog documentation to find out more.

The second question was "how do people do logging if they do not have Microlog?". My answer was "I am not sure, but I guess that they log to the record store or to a file". But if you choose to log to the record store, they also need to implement some kind of log viewer. The data is stored as a byte[] in the record store, which is hard to read right away.

After some further discussion with my collegue, he ask me "...then people must be very happy when the find out about Microlog?". Yes in fact they they are. At least the people that I have spooken to. Of course, sometimes people have some issues with Microlog that they do not like or like to improve. But I always try to listen to the feedback I get and improve Microlog accordingly. In fact most of the important changes are based on feedback. So please continue giving me more feedback about Microlog.

Available on Twitter

I am now available on Twitter. Use the link to the left if you want to follow me on Twitter. This is kind of a experiment for me. I am not sure whether I like Twitter or not. But at least it is worth a try.

SourceForge Community Choice Awards, Please Vote for Microlog

Every year SourceForge honors the most popular projects in the Community Choice Awards. The first nomination period for this years awards has started. Read more about in this press release. If you find Microlog useful, please nominate it by going to the SourceForge project page and press the nominate button.

Edit: For your convenience, I have provided this link to get to the right place directly.