Microlog 2.2.0 Provides Reliable Small-Footprint J2ME and Android Logging
Some developers seem to think that logging is not really all that useful or important. I've worked with people who have this view. They think that the only way to solve a problem is to launch your program within an IDE or debugger, insert break points, look at variables, step ahead a statement or five, etc.
This method indeed is suitable for some problems. But it's not by any means suitable for all situations. Take, for example, multithreaded applications. Or, what about the case of very intermittent errors in a critical operational system that runs on a 24/7 basis? If you've got 168 hours a week to sit there running the application manually within your IDE, in parallel with the operational runs, waiting for that once in every 5-32 days anomaly (and really hoping that when it occurs operationally it also occurs within your IDE launched and monitored run) -- well, go right ahead and enjoy yourself!
But, guess what: there's a good chance that these unusual, intermittent failures won't be repeatable, and they won't occur in your IDE or debugger driven run, or any attempted rerun! They're intermittent! So, now what do you do? The damaging failure has occured once again, your boss is hovering over you saying "Well, you were watching it. So what happened, and why?" And you... umm... haven't a clue?
Logging has been an important component of operational systems since the inception of operational computing systems. A log is simply a very basic monitor. What complicated system runs without instrumentation to enable the operators to assess the performance of the system? Are we in a "nominal" state (i.e., nothing unusual stands out), or is something flashing an edge or out-of-bounds condition? That's what logs are for.
OK. So much for lecturing against logging naysayers. Just take it from someone who has decades of experience in the area: logging is of critical importance for operational systems.
is a small, yet powerful logging library for mobile devices based on the Log4j API. Supports Java ME (J2ME) and Android. Logs to device, to PC or to servers online. Used in all phases from development on emulator/device to outdoor field-testing.
The benefits of Microlog include:
- Easy to set up
- Similar to Log4j
- Many different logging destinations: Console, RecordStore, File, Canvas, Form, Bluetooth, ... (many more)
- Different formatters for different needs
Now, I think I'm in the minority of developers in that a requirement of the software engineering work I do is that the operational system has access to me on a 24/7 basis. I mean, it's a requirement of my job that a text message sent by the operational system can immediately get to me. My Blackberry is within hearing range (almost) constantly. I've even created my own custom messages to send to myself based on certain criteria being met by scripts I've created to troll the data situation.
Why? Because certain messages from the operational system might require an immediate response from me (and others). We're supposed to be up and running 24/7. We have a number of nines of availability that we've contracted to provide. We don't want to fall below the required nines. Our future viability as a data center design, development, and operational management team depends on success in fulfilling the required uptime.
Microlog makes it easy to notify developers or operators that anomalies or potential problems may have emerged. Of course, you can also use it for basic debugging as you develop or update a new application. And it's tuned for JavaME and Android. For that to be the case, it has to be lightweight and fast. It's also mature, having been around since 2005.
If you're working on JavaME or Android code, and you need help with assessing the characteristics of operational code, or code that is intended for an operational environment, Microlog looks to me like something quite worthy of your investigation.
In December 2008, Joseph D. Darcy blogged about leading Sun's efforts to develop a set of small language changes for JDK 7. This announcement led Sun to create Project Coin, an official conduit for receiving language enhancement proposalcoin_final_five"> none of these operators made the final cut...
Terrence Barr provides an OREDEV Wrap-Up (& looking forward to next year!):
Just returned fromRelated Topics >>