Java XML Data Binding

I don't recall the last time I used DOM or SAX to process XML documents. Things have evolved and processing XML seems more and more an unnecessary low-level work. And that's because of the superior XML Data Binding. XML Data Binding is all about mapping objects to XML, and back again. It's not document-centric, but data-centric. After all, isn't XML a way of representing data ? The data is what matters. For example, if I have the following XML:

<customer>
     <code>128682</code>
     <name>Mr. Smith</name>
</customer>

I don't want to mess around with DOM objects or SAX events if I just need to get the data into Java objects. I just want to pass the XML to some method and get a Java Bean named Customer with properties code and name (of course the real advantage it's when the XML is a lot more complex). That's what XML Data Binding frameworks are for. And there's plenty of them. They typically work by generating classes from some provided XML Schema. You'll normally get the Java Beans that hold the data and a few classes responsible for the marshalling/unmarshalling of XML.

I tried a few when developing Axis2 web services. Axis2 supports several data binding frameworks and also provides its own implementation: ADB. For what I've seen of ADB I don't like it much. By default it generates Java Beans with strange looking code filled with inner classes. And although it claims that it can generate plain POJOs, I couldn't get them to work well.
There's also XMLBeans, which is known to be the most comprehensive out there. But it also generates a lot of classes and a lot of code.
A third, and in my opinion a better choice, is JibX. With JibX you can do things a little differently. Instead of letting JibX generate the Java Beans, I prefer to create them myself and then configure a short XML mapping file (in the simplest case, just to tell which class is the root element). JibX then generates only 2-3 classes responsible for mapping the XML to the Java Beans. This way my Java Beans stay clean and I have much less generated code.

But there are even more alternatives. I've used XStream several times and it's great. It doesn't generate any code, it's all done in runtime. It's similar to JibX : you also have to provide the Java Beans and some mapping configuration, but instead of generating code to handle the XML, it does everything in runtime. You could argue that XStream is better that JibX, but actually XStream also has some disadvantages: doesn't support XML namespaces, which is essential for web services development. I've used it in other situations, when I don't need XML namespaces.

I should also mention JAXB, Sun's official specification for XML Data Binding (JAXB is only a specification, but there's at least two implementations: JAXB RI and JaxME), but I still haven't tried it.

Thread pooling in Java 5

Only recently I began learning (and working with) Java 5's new features. When they announced the most emblematic new features there was an immediate reaction to them. Some people loved the new features, others hated it. To be true, I liked some things (like enumerations and generics) but never cared much about auto-boxing or varargs. However, I'm not going to talk about these popular features that almost everyone has heard of. It seems there's plenty more to know about Java 5. Today I discovered a fantastic (first impressions) and powerful new feature: java.util.concurrent package. This package provides several utilities to handle threads and locks, simplifying the whole process. For now I only tried one thing: creating thread pools. This is something that comes in handy very often and it's now very simple to do.

First, you have the usual Runnable that implements whatever you want the thread to do. In this simple example it just prints "hello".

public class WorkerThread implements Runnable {
    public void run() {
        System.out.println("hello");
    }
}

Now, let's imagine I want to create 300 WorkerThread s, but allowing only 5 threads simultaneously. So, a thread pool has to be created with size 5. Then I submit the 300 tasks to the pool, which only executes 5 at a time, queuing the rest. As one thread finishes, the next one in the queue starts.

ExecutorService pool = Executors.newFixedThreadPool(5);
for(int i=0; i<300; i++){
    pool.submit(new WorkerThread());
}

As simple as that. But there's a lot more to learn. For example, there's a new interface Callable, that you can use instead of Runnable. Callable allows the executing method to return arbitrary Objects and throw exceptions, something you couldn't do with Runnable's run() method. Look here for more information about this and other cool enhancements that didn't get the overall attention they deserve.

LCD Monitor guide

A few days ago my LCD monitor started making some strange noises. I knew that it wouldn't last long. It still works, but barely (the image goes black from time to time). Although I might try to get it fixed, I immediately started searching for a new one. Normally I like to learn about all the little differences and rate the available choices. However, there's just one little problem : there's hundreds of different monitors available!! No I didn't quit, but instead of collecting all the information I started eliminating most of them based on a few characteristics. So here's what I found out.

First and most important of all: the budget. Because I didn't want to buy a very expensive monitor, I think I reduced my choices to half :D

Then there's the size. I own a 17" and I probably will buy another 17", but I still haven't discarded completely an 19" monitor. I won't get a better resolution with a 19", it's the same 1280x1024 that I get with a 17". Everything just looks a little bit bigger (mostly the fonts). I think it's not better or worse. It depends on the distance to the monitor. I read somewhere the distance from the eyes to the monitor should be twice the diagonal. Basically it comes down to which you feel more comfortable with. And I feel comfortable with the 17". Don't think it's the price...I surprisingly found a few 19" monitors cheaper than most 17". There's also the widescreen's, which may be better for some situations, like watching DVD's. But I'm still not sure about those...never worked with one so far.

At this point, the rules I outlined already exclude lots of monitors, but still there's too many and I'm lazy enough to just pick a few well-known brands instead of going trough all of them! Also, it helps if the monitor you want is available at your local stores (unless you want to buy online) and that should reduce a few more.

LCD Monitors have a lot of specifications, but not everything is important:

• Contrast ratio - The contrast ratio is an important factor, but different vendors calculate this value in a different way. So, it's not a reliable parameter. There are lots of 500:1, 700:1...and then there are a few 2000:1. Clearly this last one was measured differently. I just established a minimum here (500:1) and then pushed this parameter to the bottom of the decision-making process.

• Interface - every monitor has an analog input, and some have the better digital input (DVI). I'm not sure how much better is the digital input (some report better image quality, due to faster image render, because there's no analog/digital conversion) but I chose only monitors with DVI input.

• Brightness - this is almost everytime 250 cd/m2, so I completely ignored this.

• viewing angle - most monitors have 160/160, so I excluded everything worse than that. I like to be able to look at the monitor from different angles, and lower values don't allow good viewing.

• response time - I've seen values from 2ms to 12ms. From what I've found 12ms is very good and anything below that isn't that noticeable. Of course there are monitors with response times greater than 12ms (which I ruled out) but most of the new ones already have at least 12ms.

• dot pitch - this almost never varies, so I ignored this.

• power consumption - you could just ignore this, but if you care about the environment (and your bills) you could choose a monitor with better consumption. The best I saw was 30W when "on" and 1W in "standby".

• base - it's important to have the monitor well positioned, so the more options it gives you, the better. Possible adjustments are: rotate, tilt, height adjustment and pivot. Almost every monitor has tilt adjustment. Rotate it's also very common. Height adjustment is the most important to me, but it's not so common. Pivot is becoming more common, but I have no use for it.

• extras - some monitor have lot of extras, like speakers, USB ports, etc. I prefer not having to pay for these useless extras.

You might be asking: "so which one did you choose ?" :) Well, I have a small list but haven't made up my mind yet. And I also don't want to spoil you this wonderful experience of choosing monitors :P

Another simple and small

A while ago I reviewed HSQLDB, a small and fast java database. I've used it a few times quite successfully. I'm now developing a java desktop application and I needed a small in-memory database and the first choice was obviously HSQLDB. However, I decided to do some investigation to see what else is there. And surprisingly I stumbled upon HSQLDB apparent successor: H2. Quoted from their website:

The development of H2 was started in May 2004, but it was first published on December 14th 2005. The author of H2, Thomas Mueller, is also the original developer of Hypersonic SQL. In 2001, he joined PointBase Inc. where he created PointBase Micro. At that point, he had to discontinue Hypersonic SQL, but then the HSQLDB Group was formed to continued to work on the Hypersonic SQL codebase. The name H2 stands for Hypersonic 2; however H2 does not share any code with Hypersonic SQL or HSQLDB. H2 is built from scratch.

According to this, it's also faster than HSQLDB, which is always good. And after reading the documentation H2 feels more solid and robust. Maybe, it's because it has a few interesting features like cluster support, encrypted database and recovery tool. Also, data is not stored in text files with SQL inside, as with HSQLDB, which it always felt a bit clumsy to me.
I also like the provided SQL console: it's a web application that you can launch directly from the database jar. It could be more complete, but it works well and I specially like the auto-completion feature.
So, for now, I will be using H2 in my application and see if it's as reliable as it seems.

Kung-Fu Java

No, I'm not talking about any kung-fu variant from Indonesia. I'm talking about JavaBlackBelt. In their own words:

JavaBlackBelt is a community for Java and related technologies certifications.

It's basically an alternative to Sun's official certifications. And although you won't get the same recognition (not even close), JavaBlackBelt's exams cover a lot more ground than Sun's. You don't get evaluated only for your knowledge of official JDK libraries, but also from your knowledge of many popular technologies that a Java developer might find: Struts, Spring, XML, JDBC, Ant...just to name a few.
Also, the whole certification path is fun and very well thought. When you first register, you receive a white belt and from that you have to pass exams in order to receive the other belts, all the way to the black belt. To take an exam you also have to pay, but in contribution points, not money :) Contribution points are what holds JavaBlackBelt as a community. You receive contribution points by creating questions to a certain exam (it will be voted and filtered before getting into the real exam) or by evaluating other people's questions. Then, you can use your contributions points to take exams and also to participate in auctions. Auctions allow you to spend your contribution points in prizes (normally books or t-shirts).
For now, I have a yellow belt, but I made this post because I just successfully took the JDBC exam and I'm just one exam away from my orange belt. Wheeeeeh...err, I mean: YEAAHHH (with strong manly voice).

New breed of menus

Hi. It's been a long time since the last post, but finally I could get some free-blogging-time :)
A few weeks ago I installed Novell's Suse Linux Enterprise 10. I'm not planning on ditching Gentoo any time sooner, but I got curious about some of the innovations the folks at Novell are doing. And I also had a few disk-space to waste.
My main interest was to see in action the new menu interface. Instead of the regular list of applications, this one is quite different. It gives more importance to the favorite and recently used programs (never really cared much about this). To get to the rest of the applications you have a search mechanism. Begin typing the name of the application you want and see the options start converging to that name. Beagle is the technology behind this.
At first glance, it seems more productive, specially for keyboard-intensive users. Just start typing the name and you find the application quite fast. However, we still have to use the mouse: we have to click the button that opens that window (probably there is keyboard shortcut, but I didn't find out) and then click on the application name after you found it. I think I could have found the same application with the same amount of clicks in the old-fashioned menu (most of the times). But definitely there's a trend going on here. Everything in the computer is now searchable, even the applications. And this interface somehow reminds me of the auto-completion features in most programming IDEs: hit ctrl+space and you get a list of options, which you can refine by typing in the first letters. I really would like a menu as productive as this, without the need of any mouse click.

Another use of this kind of search is when we don't know the exact name of the application (just the description)...but that seems of interest only for real newbies. Sooner or later anyone knows the name of all applications.

So after spending some time using it, I really felt it slower, mainly because I had to open a second window after opening the menu. It could be a lot better if it was directly embebbed inside the menu window.

Oh No! More Ajax

Ok, now things are starting to become ridicule. Ajax this, Ajax that... everything has to be Ajax-enabled to be considered cool. What else can they think of ? An Ajax operating system ? Well...yes :)
Welcome to the wonderful world of AjaxOS, a place where every file is free... I know I'm being a little sarcastic...but just hearing the name sounds a little silly, to say the least. But I don't blame them. At this time, the word sells, so it's a perfect way of getting attention.
Anyway, this new operating system is in fact based on the well known Linspire Linux distribution. What they did was to integrate web (ajax enabled web) applications into the desktop. As cited on their site:

By seamlessly integrating the power of web based applications with Linspire, ajaxOS recognizes any compatible file (doc, svg, odf, txt, xls, etc...) and launches the most up-to-date AJAX software from a Firefox browser.

Actually it can be a good idea if it works well. I'm not saying this will be the future, but it's an alternative that has a few advantages, like a small installation or the ability to open any file format without having to install first the corresponding viewer/player. In some cases, this might be useful, like public-access computers as it reduces configuration and maintenance effort drastically, and may even provide a better service (public-access computers don't usually have all the software one might need at some time).
Anyway, it's still not availalable yet. Let's wait and see...

Ajax toolkits

Well, it appears Ajax is here to stay. I've already used some Ajax-like features in some projects but nothing too big yet. The thing that I like less in Ajax is JavaScript....yes, I know that without it, it's not Ajax :)
However, my gripe with JavaScript is not unique...
Recently I discovered two new frameworks for dealing with Ajax and both of them minimize JavaScript code to zero! At least, from the developers point of view. These are Google Web Toolkit and ZK. Both of them are Java frameworks, and they hide all the JavaScript away from the developer. The idea is to create an event-driven framework filled with rich GUI widgets that resemble desktop apps. The thing I liked in both frameworks is how Ajax is put inside the framework and away from the developer. It's not a framework to build Ajax, it's a framework to build rich web interfaces, that is powered on the inside by Ajax. How is this done ?
In these kind of applications there's three parts: client-side code, server-side code and the glue to bind them. Client-side code has to be JavaScript (along with html, CSS, etc) for the browser to interpret. Server-side code can be in almost any language, but in this case, it's Java. The third and the hardest to accomplish is the communication between the previous two. Ajax provided us with a way to create that communication, but coding it by hand is complicated and troublesome (although interesting to learn). What both frameworks provides us to simplify these tasks are:
First, they provide a way of building the web interface that is more similar to the way we build desktop apps. They both provide a rich set of graphical widgets, typical of desktop apps (of course, inside, this is translated into something the browser understands ;)). Second, and more importantly, all communication to the server-side is done automatically and transparently. From the point of view of interface design, you layout widgets that have events. From the point of view of the server, you have a simple Java API that handles events. Everything in between is given by the frameworks and executed automatically. This way, server code is like a traditional desktop app: event-driven.
Despite its similarities, GWT and ZK implement this idea quite differently. In GWT you do everything in Java, even specifying the layout and widgets. But instead of compiling your java files with good old javac, you use a compiler provided by GWT. This compiler will translate the java code you happily wrote into JavaScript. This is basically creating JavaScript without actually writing it :)
In ZK you create the widgets and the layout in XUL and XHTML (actually ZUML, which in the future may also support XAML and XQuery). Then create the event handlers in Java to do the server work. Binding Widgets and event handlers is done in ZUML, and it's easy to do.
I still don't have an opinion of which I like more. At first sight GWT seems easier to work with, but I'm always suspicious of generated code. ZK seems more flexible and it's based on several interesting technologies, like XUL. I believe both can have success, but I'm pretty sure the name google will show its weight, at least at first ;)

How much ?

Being a Java Developer I'm of course interested in knowing how other Java Developers are doing, specially in other parts of the world. I'm talking about money, of course... how much Java developers earn in "insert_country_name" ? It's not that I'm not happy with my current income, but we always want more if we can get it :)
Anyway, this JavaLobby's forum thread is a very interesting reading.

Online Office

For some reason, I've never been too fond of applets. Maybe because I saw too many bad examples on how to use an applet. However, my opinion changed dramatically, when I saw ThinkFree Office. Basically, it's the regular office you are used to, but inside an applet!!
You have Word, Excel and PowerPoint with all the features you can imagine. It's truly amazing how similar it is to the real thing. It works so good you could use it to substitute the real Office and save a few disk space. Just create a free account, and you get 30Mb of space for creating docs, spreadsheets, convert them to pdf, etc. Try the demo and see for yourself! One of the things that amazed me: you can even do fullscreen slideshows of powerpoints :)
Apart the usefulness, it's really the best applet I've seen.

Suuurrrooouuunnnnd

Santa Claus brought me a brand new Creative Sound Blaster Audigy card along with 5.1 speakers. I wasn't looking for a new sound card, but now I really love the sound I can get here...
I first installed the windows drivers, which confirmed the nice surround sound quality :)
I was a bit curious how Linux would handle the card, and specifically the 5.1 speakers. I had a few problems (and still have) with the Alsa drivers, but curiously not at first. The problem only manifests when I boot my PC directly in Linux (which I do most of the time). Instead of crystalline sound I got some horrible noise. However, if I first boot Windows and then reboot to Linux, everything is fine. It appears to be some kind of initialization code that is missing from the Alsa drivers.

Besides that annoyance (which I hope it ends soon), the sound in Linux is now a lot better than before. One of the first things I tried was to listen to the surround sound in a DVD. I had a few problems configuring Xine, but it worked nice on Mplayer. And yes, the sound is great :)
However, I noticed something missing comparing to windows drivers. When listening to music, I realized the music was playing only on the 2 front speakers. And in windows, besides playing on all 6 speakers, I could also select from a set of special effects (like the sound was playing inside a church, auditorium, etc). Of course, I wasn't hoping to have those special effects in Linux...and I don't miss them too. It's fun to try the first time, but who uses them, really ? :)
What bothered me was that the music didn't play on all 6 speakers. Well, I never thought about how things were done in Windows, but I soon figured why Linux only plays on 2 speakers. A surround sound (one that plays on all 6 speakers) must have the information on what to play on each speaker. The sounds and music on DVD are recorded in 6 channels....one for each speaker. But normal music is record in Stereo, which means 2 channels. So, normal music should be played only on 2 speakers. Fortunately there's a trick: I could tell it to play the same channel on several speakers. That's very easy to do in Alsa. However, it doesn't sound the same as in Windows. What I think Windows drivers do is apply some kind of audio filter to the duplicated channels. That filter gives the sound a more 3Dish feel. Nevertheless, the result is reasonable. And hopefully someone with time and patience creates a similar set of functions to be added transparently to Alsa (instead of specific to each driver), which would make it very flexible.

It's amazing how much we can do in Linux, even when we lack the manufacturer's drivers ;)