Java comes with a built-in logging system java.util.logging which is really quite good. It is very simple to use, highly customisable at runtime and offers incredible extensibility. However, by default it doesn’t allow you to specify the format of your logging messages and this tends to make people angry (the default setting is to print everything to System.err, over 2 lines). In this article I’m going to talk a little bit about why you should use the built-in logging package and show you how to get runtime support for the formatting of log messages.
 in London)
Over the Air is going to be 48 of mobile development at Imperial College, London, from 4-5th April 2008. It will bringing together developers, designers, hackers and entrepreneurs to explorer the potential exciting future of wireless and mobile devices/applications.
The line of speakers is very exciting! I’m going, and I hope to see some of you there!
I recently switched to NetBeans 6.0 (from Eclipse) and it was a very nice experience. Profiling is completely integrated (on all platforms), J2ME and webapp support is awesome and NetBeans uses ant for building projects… so we got a headless builder for free. However, there were some problems that made me unable to poke the rest of our team into using it. NetBeans 6.1 Beta is out this week and it addresses most of them (most notably, sharable library descriptors somehow didn’t make the 6.0 release… they allow more than one person to work on a project).
We’ve been running a poll on the Javablog for a few weeks now and it seems most of you are using Eclipse… so why not give NB6.1 a try!
If you find any bugs, be sure to report them to the NetBeans issue tracker. Check out my personal wish list incase you agree with any of the requests:-
- Exclude classes from code completer
- ranking of code complete/hinter output
- Warning when implementing method does not have javadoc
- format source and make fields final
- Transitively required libraries not automatically added to runtime classpath
- Auto-generate serialVersionUID data member and value
- a hint for doing a static import
- should assertions be disabled by default for tests?
- LaTeX plugin not installing on NetBeans 6.0
- Run-time Test Libraries add Run-time Libraries
- Add support for MicroEmulator, drop support for MPowerPlayer
(wouldn’t it be nice if they generated such a list automatically… grr, bug handling software)
NB: Apologies for this not-entirely-Java-post, but I think NetBeans is due a post since Eclipse has had a few mentions around here.
This is the final post of a series where we have looked at persistence options in Java. In part 1 we looked at rolling your own lightweight solution and in part 2 we visited BerkeleyDB as an embeddable non-SQL solution. In this final piece, we look at the Java Persistence API (JPA) which was accepted as part of Enterprise Javabeans 3.0 (EJB3) in JSR-220.
Some time ago, I posted a tutorial for setting up a J2ME development environment on OS X. Since then, EclipseME has not been addressing any of the bugs that made it a pain to use and I have also moved on to NetBeans 6.0. In this post I will revisit how to set up a cross-platform J2ME development environment using Ant and Antenna to handle all the difficult pieces of the build process, but allowing your preferred IDE to perform pure-Java debugging through the use of the excellent MicroEmu “WTK”.
The test-develop cycle for writing J2ME applications can be significantly slowed down by the need to deploy the application onto the device. Given that most network operators charge extortionate data rates, the only real option is bluetooth deployment. In this post I present a solution that can be included as an Ant task. Note that it might not work for everyone as some operators and handset manufacturers intentionally disable bluetooth deployment of MIDlets.
J2ME is bare-bones and I recently realised that it doesn’t have any image encoders. Sure, you can create Image objects… but there is no way to persist them to disc or to send them over the network in a recognised format.
With the goal of creating a low-memory PNG encoder based on TinyLine GZIPInputStream, I wrote an uncompressed BMP encoder as a gentle introduction. I am posting it here (under the LGPL) incase it helps somebody out… I got tripped up by some file format details (including Endianness) so you don’t need to go through it.
Unfortunately, you won’t be able to load BMPs and display them without writing your own decoder! (J2ME only supports PNG)… but at least it allows you to communicate images with the outside world.
One of the biggest problems with J2ME is that there aren’t any great open source libraries out there. That’s one of Java’s greatest strengths. I intend to post a few of my J2ME utility classes here as I write them. I’m currently working on a hobby project which I intend to release here, and if it goes according to plan, I intend to reveal some bluetooth convenience classes.
