KDE 4.1 hits the "shelfs"

If you use Linux and happen to use KDE as your window manager, you may be excited to hear that KDE 4.1 has finally been released.

And if you run Kubuntu, you can already upgrade to KDE 4.1 by performing these simple steps:

1. Type sudo vim /etc/apt/sources.list
2. Add the line deb http://ppa.launchpad.net/kubuntu-members-kde4/ubuntu hardy main
3. Save and exit (:wq! ... just in case you are not a "vimmer")
4. Finally, run sudo apt-get update and sudo apt-get -f dist-upgrade
5. Restart! :-)

The above works unless you run KDE 3.5 (meaning, the LTS-version of Kubuntu 8.0.4), in which case you will probably have to go through some tedious dependency fixing first (don't quote me on that, though...) because installing KDE 4.1 side-by-side KDE 3.5 didn't work when I tried it.

However, to be completely fair, I haven't spent much time looking into the problem and since others on the different Ubuntu communities on the web had the same dependency issues, I decided that it might not be worth the effort of trying and simply used the KDE4-version of Kubuntu 8.0.4... after all, you will probably have to reinstall and reconfigure your applications and settings after upgrading anyway.

Google versus Microsoft

Now that headline probably caught your attention. Nevertheless, the content is not quite as exciting, but it's nonetheless a funny and somewhat ironic observation that I made and that I want to share with you.

A couple of days ago I watched a webcast from the Google I/O developer days where Aaron Boodman from Google talked about standards and HTML 5.0 in Google Gears.

After watching it, I decided to do a little experiment and the expected results differed from those I actually got. I used the W3C Validator to check both MSN and Google to see whether the pages are valid according to the HTML standard.

It comes as a little surprise that the minimalistic Google.com fails validation with 59 errors, while Microsoft's (often regarded as the poster child of not following web standards) MSN is a valid XHTML page.

I am not going to moralise about it, nor will I preach about standards or analyze the results, I just thought it might lighten up your day as an "interesting fact nobody needs to know".

Oh and by the way... you better don't check this blog with the W3C Validator... and if you do: I am using Google's blog service so it's not my fault, I promise :-)

Give JavaFX a chance

JavaFX is not even released, yet, you can find numerous articles on the internet which give the impression that people all around are already digging its grave before it’s even born.

Personally, I very much wonder why… Sun Microsystems is doing a serious attempt to revive Java on the Desktop as well as giving the whole RIA-hype a go. Most articles I’ve read say: “who wants to install the Java Runtime?” or “there is Adobe Flex and Silverlight, Sun’s too late” and there is a truth to it. Windows, the most commonly used operating system does not ship with the Java Runtime anymore and an old version of Flash is installed out of the box with Windows. These are very valid assertions, however, for Flex/AIR you will need a newer version of Flash installed and Silverlight is, though smaller in size, no smoother to install than the Java Runtime.

I’ve even read an article where the author was questioning Sun’s motivation to introduce JavaFX Script rather than using XML. In my opinion, not using XML is very refreshing. Just look at Spring (being the prime example) and 99% of all the other Java Frameworks out there. Most of us end up writing nearly equally many lines in XML as in Java and I feel that XML is being abused for configuration rather than what it was invented for: data exchange. Furthermore, using a Domain Specific Language for GUI-development goes hand in hand with the current effort in the Java Community to introduce DSLs to speed up the development process (look at Apache ServiceMix’s DSL or the numerous DSL-additions to Groovy).

Anyway, back to JavaFX and its viability. As I previously mentioned I think that Sun is trying to revive Java on the desktop and if you take all the variables into account, they just might succeed.
I won’t wrap up quite yet, I want to share the issues at hand so you can possibly re-evaluate your opinion of JavaFX.

The Runtime-Issue

The biggest show-stopper at the moment might be the absence of the Java Runtime on many home-computers. How do you get a home-user to install a 15MB plugin in Internet Explorer or install the Java Runtime to run a Java application?

What many fail to see is that Sun is actually addressing this issue with the latest Java 1.6 update (1.6.10) by introducing modularity to the JRE. You can still install the full JRE, being appx 15MB in size, but if you just need Java to show your RIA-application in the browser, you get by with a subset which is about 5MB in size. In contrast, Silverlight is close to 5MB (including the .NET Runtime) and Adobe Flash is 1.5MB in size. Certainly, this means that Flash has the smallest footprint, but in the time of broadband, I don’t really think that 5MB is a big issue.

Sun will provide a Plugin Deployment Kit and thus the end-user will have no issues with getting your application to work. It will just be the same as with any other web application requiring a plugin to work.

Also, Sun provides a background upgrade mechanism. Essentially this means, if your application needs more features than the once currently being installed, the JRE will download the added modules on the fly.

The Development Environment Issue

This is a little bit Sun-typical. Invent a nice technology, kick it out the door and then walk away for somebody else to pick it up and make it useful. We’ve seen this before with JSF. It’s a good technology but why in god’s name weren’t there any development environments available from the start? It aids developers and is almost certainly a guarantee for fast market adoption (provided, the technology is useful). Sun could have worked with IDE vendors from the start to give JSF the attention it deserves and this will be a crucial factor if Sun wants JavaFX to succeed.

Certainly, Java developers like to write code and since we are incidentally also a bit lazy, we have perfected the art of HST (Hooking Shit Together)… most of us simply don’t like writing the same glue-code over and over again. Not that this is an issue with JavaFX Script (being a DSL designed for GUI-development), but still… designing a GUI graphically is more much better than the endless “coding-previewing-coding-previewing-…”.

Luckily, Sun has been thinking about this and there is a JavaFX-plugin for Netbeans on the way.

The UI Issue

Yes, Swing applications aren’t known to look like or perform like a Windows application or a GNOME-application or even a MacOS-application. Despite the fact that Swing performance has been greatly improved in the latest versions of Java and the fact, that your Swing-app can look very close to a native application, people just don’t forget how it was a couple of years ago.
Nowadays, we are more and more used to the fact that application vendors add their own little effects and thus, most applications just don’t look like the next and this will in turn help us getting better acceptance for an application not looking absolutely identical to other applications. Furthermore, Sun introduced a new Look And Feel called Nimbus, which looks modern and a little bit like the MacOS UI.

Last but certainly not least, the performance will improve by using Windows’ DirectX API to render your application. Your application will now be able to use the Graphic Card’s accelerative capabilities (just like Windows Vista does) and without having done any performance tests, I am looking forward to Java Apps having “almost native” performance.

Portability Issue

Not all is good, though. Even though the following might be a theoretical problem, I am in doubt of Sun’s “one framework for all devices”-marketing.

If you’ve ever been to JavaOne you probably know that Sun is never getting tired of telling us that Java has an enourmous market penetration with several billion people having Java-ready devices at home (imho, Java-Ready doesn’t mean that there is a useful Java Runtime installed on those devices).

Unfortunately, Suns neglect of the Micro Edition has lead to the fact that the most advanced phones today don’t even come with a Java Runtime pre-installed and those phones that do have a Java Runtime aren’t upgradable, which leads me to question if JavaFX will actually ever run on those telephones.

On the other hand, Set-Top Boxes or GPS devices are often upgradable and if you are in the business of developing software for these devices, you still may have use of JavaFX… As a mobile platform, however, I have my doubts. Maybe in a couple of years when Sun puts some work in the Java ME platform and convinces the big players to integrate it into their phones we have a chance at deploying JavaFX-based apps on them.

As more and more devices are portable, this will be another critical issue and providing that enough of us use JavaFX, I believe that this isn’t an insurmountable problem.


Ultimately, I think that despite the existence of Flex, Silverlight and numerous other RIA-frameworks, JavaFX definitely isn't a write-off. It's not solely for RIA, but an attempt to make a universal framework for "Rich Applications" based on Java. And even if it would be exclusively for internet applications, is competition such a bad thing? I don't see anybody questioning why there are different app servers or even operating systems. So let's wait for JavaFX and do a fair comparison when it's ready.

Change tracking regurgitated

Now I know, it's been quite some time since the last time I posted an article on my blog... Between being very busy with my projects at work, taking care of my lady and attending The Server Side Symposium in Prague, I finally finished my SCJD certification assignment (which I have been too busy to do for the last two years).

Last time I wrote about the automatic entity change tracking and I would like to share my new insights on the subject. The reason for this is, that some (including me) may find it somewhat disturbing to make the entities implement an interface or even extend another baseclass. Today, we gonna try the same thing using reflection.

So, just as before, we create an entity called Invoice. However, this time it does not implement or extend any other interface or abstract class. Thus, it should look as following:

@Entity
@Table(name = "invoice")
public class Invoice {
  @Id
  @GeneratedValue
  @Column(name = "id")
  private Integer id;
  @Column(name = "product");
  private String product;
  @Column(name = "receiver");
  private String receiver;
  @Column(name = "amount")
  private Double amount;
  @Column(name = "created")
  @Temporal(TemporalType.TIMESTAMP)
  private Date created;
  @Column(name = "created_by")
  private String createdBy;
  @Column(name = "changed")
  @Temporal(TemporalType.TIMESTAMP)
  private Date changed;
  @Column(name = "changed_by")
  private String changedBy;

  // ... getters/setters
}

As you can see, this time we are not implementing the Traceable interface. For this reason, we need to modify the AuditLogger Entity Listener class, which uses following code to identify an entity as being traceable:

if (entity instanceof Traceable) {
  ...
}

Understandably, this will now always evaluate to false!

Instead, we modify both the prePersist(Object) and preUpdate(Object) methods to do all the work using reflection. The next code example shows, how the methods should look like:

public class AuditLogger {
  ...
 
  public void prePersist(Object entity) {
    alterEntity(entity, "Created");
  }
 
  public void preUpdate(Object entity) {
    alterEntity(entity, "Changed");
  }
 
  private void alterEntity(Object entity, String partialPropertyName) {
    try {
      Class clazz = entity.getClass();
      Method m;
      String callerId = getCallerIdentity();
      m = clazz.getMethod("set" + partialPropertyName, Date.class);
      m.invoke(entity, new Date());
      m = clazz.getMethod("set" + partialPropertyName + "By", String.class);
      m.invoke(entity, callerId);
    } catch (NoSuchMethodException e) {
      System.out.println("Not a traceable entity.");
    } catch (InvocationTargetException e) {
      // unless something magic is going on in the setter, this shouldn't happen
    } catch (IllegalAccessException e) {
      System.err.println("Not allowed to access methods, check your security settings.");
    }
  }
 
  ...
}

Both prePersist and preUpdate call the alterEntity(Object, String) method which, in turn, does all the magic. It fetches method descriptors for the created/createdBy/changed/changedBy properties and invokes them on the entity instance handed to the listener. Pretty simple, huh :)

Well, this is it! No more is needed and it is a neat way to solve the problem. Nevertheless, I would like to finish with a word to the performance geeks amongst us (I happen to be one of them): As it may be, you might oppose to the use of reflection. However, as of Java 1.5 (and even more so in Java 1.6), reflection has basically become so fast, that the added convenience of setting the properties transparent to the guy (or gal) implementing the domain model propably outweigh the minute execution time differences between static and reflective calls.

The road to yet more certifications

You probably wonder why this blog has not seen much activity during the recent weeks. As it so happens I am finally trying to use my voucher for the SCJD exam which I enrolled for two whole years ago.

While doing it, a thought struck my mind: What are the benefits to me, to get a bunch of certifications?

Personally, I sacrificed lot's of free time getting a fair amount of certifications. I am the proud owner of two SCJPs (I believe it was for version 1.2 and then for for 1.5), SCWCD for Java EE 5 (which for some weird reason seems to be exactly the same as for J2EE 1.4), SCBCD for Java EE 5, a Project Management certification and - believe it or not - an MCP for .Net Server Component Development... Even though I am a Java Developer at heart, I have done some work with C# and at the time it felt right to get certified. You may call me pragmatic in that way. I use what gets the job done and even though Java gets the job done almost every time, I do prefer writing a Windows Desktop application with Visual Studio rather than Swing :-)

Anyway, back to certifications. I told you that I am currently sacrificing even more of my spare time to finish my SCJD and despite it being an exercise of following Sun's specification to the "T", I find it exciting to do something more involved than the usual two hour radiobutton-clicking.

So: What is the benefit? In my humble opinion, I think that a certification in itself doesn't hold much value compared to real-life work experience. However, I use it as a tool to indulge myself in the subject matter and possibly discover things, which I haven't previously known or which I was aware of, but never really had the time to test. After all, you never know what they are going to ask once you sit in front of "the" screen with a lot of checkboxes and radiobuttons on.

Being entrusted by my employer to interview some of our applicants, I rarely read the certification section of the CV and as it seems, neither does my manager. It's a "nice to have", so to say. Surviving a number of Java projects, however, gives a better indication of whether a person can apply their knowledge or not.

Nonetheless, having certifications at least establishes some sort of baseline. It tells me: "Yeah, he knows the language" or "good, he knows that framework" and together with your work experience it may give you the edge on a position you want to secure for yourself.

So, these are my thoughts and right now I would love to hear your thoughts on the subject!