April 11th, 2010

Five things you didn’t know about Java Serialization

Ted Neward has started a new series of articles on IBM developer works. The series is entitled “5 things you didn’t know about…” and the first installment is about Java object serialization.

Most of the Java developers must be familiar with the topic as even the first tutorials teach how to serialize an object [graph] to the disk or to the network. At least I knew that in order for my class to be serialized, it had to implement the Serializable marker interface and make sure that all my class’s fields are serializable as well. Finally I needed to call a special method on the ObjectOutputStream to store the object or to ObjectInputStream to load it back. Later on, I learned why it is so important to have the serial version ID static field.

Well, this is nothing compared to what I found in Ted’s article. Do read it if you want to broaden your scope and follow the series either at developer works or on this blog for the next 5 things that you did not know.

When you can’t throw an exception

Another article from IBM developer works. This time it comes from Elliot Rusty Harold. It deals with the case when you have to override or implement a method from a superclass or interface that does not throw a checked exception. And for some reason you have an exceptional situation in your implementation.

You can’t throw the exception, as your code will not even compile – it is not allowed for the overriding method to throw checked exceptions that are not defined in the superclass. You should not leave the exception unhandled as well – it is a very bad practice, which may lead to unpredictable behavior. It is not a good idea to throw unchecked exceptions in such situations either.

So what you can do according to the author: either separate the code that throws the exception from the one that naturally belongs to the overriding method, or define your own interface.

This is a very interesting article as it not only gives a tip on how to handle such situations, but also discusses the question about using checked exception. During my life as a Java developer I personally used to be fan of both schools. In the beginning I defined interfaces, which all methods threw a certain checked exception, no matter whether it was needed or not. Then I started hating them and went to throwing unchecked exceptions only when it was absolutely necessary (you don’t deal with input/output in 100% of your code, do you?). Of course the truth as always is somewhere in between – use checked exceptions only when something has to be dealt at development time.

OSGi and web applications

This week I recommend you two articles on nearly the same topic: how you can use OSGi when you develop web applications. So far at least my idea about OSGi was that it can be used only by some low level server side components. And that the web applications could only be built upon the OSGi infrastructure, but not use it directly. Well, the good news is that the people from Glassfish, Equinox and [hopefully] the other OSGi vendors or adopters are not so narrow-minded as I used to be :-)

The first article discusses how a Web service built and deployed on Glassfish can call a method, defined and implemented by an OSGi bundle, registered as an OSGi service. As Glassfish is also implemented using OSGi (it is based on Apache Felix), it is perfectly fine that your web module’s MANIFEST.MF file contains the necessary entries so that it imports other bundles. Basically this is all the magic needed by your web service in order to call OSGi services defined in the same container.

The second article opened my eyes even wider. As I mentioned earlier, my recent opinion was that the existing OSGi implementations only offer some basic functionality to enable the OSGi specification. What I didn’t know was that Equinox and most probably other OSGi implementations have packed some bundles that start an embedded web server. So if your bundle has a Java Servlet inside and you import the right packages, you will be able to develop a sample web application directly inside Equinox. As this still sounds very awkward to me (sorry again for the narrow-minded-ness :-)), please feel encouraged to comment on this topic.

Java script vs Java (again)

One of the people from whom I have learned very much in the area of object oriented design in Java – Misko Hevery, explains why he has become fan of JavaScript. He starts with the most popular myth from the camp of the statically typed languages fans – the lack of the compiler in the dynamically typed world makes the latter such. According to the author the fact that you can write unit tests in JavaScript makes up for the missing compiler. If you have close-to-100% code coverage of your JavaScript code, which is run (successfully) on more than regular basis, then you should not worry about syntax or other errors that might appear at runtime, but could be caught by the compiler.

After that, the author starts with the most common advantages of dynamically typed languages – you write less code to achieve the same obvious things, closures are part of the language, simplicity, duck typing. Finally the author tries to bust another myth – that writing a program in a dynamic language cannot scale to a big team of developers.

Leave a Reply


4 − = three