This behavior can have unfortunate side effects in applications. Especially remote applications that work path based and interact with different operating systems can run into problems here.

I came across this when I tried to access a subversion repository that contained file names with German umlauts from my Mac. I am running subversion 1.6.5 and when I check out a file with an umlaut in its name, executing “svn stat” will list the file twice, once as missing (with an ‘!’) and once as unversioned (with a ‘?’). A search in the collabnet discussion forums finally confirmed that this is a know issue. The following links provide some documentation:
http://www.opensimwiki.net/index.php/SVN
http://svn.apache.org/repos/asf/subversion/trunk/notes/unicode-composition-for-filenames

However, the subversion issues are just one specific bug. For application developers it is important to know that Unicode equivalence is a term to keep in mind. The wikipedia article (http://en.wikipedia.org/wiki/Unicode_equivalence) mentions a bug in the samba protocol due to different representations of Unicode characters.

So, next time you come across an issue that involves a Mac and umlauts, Unicode equivalence might be the term to look for.

Is a serialVerionUID required on abstract classes?

My first thought: No way! If the serialVersionUID is used by the serialization mechanism to check whether some serialized data is compatible with a serializable class, abstract classes (that will never be instantiated, and thus, never be serialized directly) don’t need one! The problem is that the entire inheritance tree is checked when a class is de-serialized — and that includes abstract base classes. A simple example illustrates the problem:

If we have an abstract base class …

import java.io.Serializable;

public abstract class Base
implements Serializable {}

… and a sub-class that declares a serialVersionUID …

public class Sub extends Base {
    private static final long serialVersionUID =
      -7913545780181427623L;
}

… and we create an instance of the sub-class and serialize it to a file …

...
Sub sub1 = new Sub();
try {
    FileOutputStream fout = new FileOutputStream("sub.dat");
    ObjectOutputStream oos = new ObjectOutputStream(fout);
    oos.writeObject(sub1);
    oos.close();
} catch (Exception e) {
    e.printStackTrace();
}

… and then we change the base class by e.g. adding an int field …

import java.io.Serializable;

public abstract class Base
implements Serializable {
    int a = 0;
}

… and try to de-serialize the sub-class …

Sub sub2 = null;
// Load the file and de-serialize the object
try {
    FileInputStream fin = new FileInputStream("sub.dat");
    ObjectInputStream ois = new ObjectInputStream(fin);
    sub2 = (Sub) ois.readObject();
    ois.close();
} catch (Exception e) {
    e.printStackTrace();
}

… we’ll get a “java.io.InvalidClassException”.

If we do the same thing, but define a serialVersionUID in the abstract base class, the exception would not occur. The reason for this is, that if a serialVersionUID is not explicitly declared, the JVM will calculate a default one, “based on various aspects of the class” [1]. This is a great mechanism, at first glance it even seems to be better than creating the id manually — if the class changes, these changes are automatically reflected in the generated id. But, this mechanism can differ based on the VM If you would run this example on one VM and then try to de-serialize the same “sub.dat” file with a different VM, without modifying the base class, it is possible that you would get an “InvalidClassException”, simply because the VM uses a different mechanism to calculate the default serialVersionUID. This is why it is recommended to manually declare the serialVersionUID.

However, this also means that, if we change a serializable class and thereby make it incompatible with previously serialized instances, we have to update the serialVersionUID!

Now if we think about software maintenance and data integrity, there should be a way to migrate existing serialized data to new versions of the serializable class. I’d be interested to know if there is an official recommendation for this, but didn’t investigate further yet.

It would also be interesting to see how OR-mapping frameworks fit into the picture. There is an interesting thread on using Serializable and what to do with the serialVersionUID in the hibernate JIRA: http://opensource.atlassian.com/projects/hibernate/browse/HBX-964

I’d be interested to know what others think about this, so please feel free to comment!

[1] http://java.sun.com/javase/6/docs/api/java/io/Serializable.html

org.springframework.beans.factory.BeanCurrentlyInCreationException:
Error creating bean with name 'repositoryService': Requested bean
is currently in creation: Is there an unresolvable circular
reference?

The problem is that rather than having to declare all of jBPM’s services in your application context — like it used to be up to jBPM 4.2 —, the new spring integration provides access to them through the Process Engine. All you need in your application context is this:

<bean id="springHelper">
  <property name="jbpmCfg" value="PATH TO YOUR jbpm.cfg.xml">
</property>
</bean>
<bean id="processEngine" factory-bean="springHelper"
factory-method="createProcessEngine" />

Now you can inject the processEngine into your classes and retrieve jBPM’s services like this:

processEngine.getExecutionService() …
processEngine.getRepositoryService() …
…

Eclipse error message: "Cannot complete the request. This installation has not been configured properly for software updates!"

To fix this, you need to go to “Preferences > General > Capabilities” and check “Classic Update”. Afterwards you should be able to select “Help > Software Updates > Find and Install…”.

I wasn’t able to find much on the internet, but this post on an Ubuntu forum finally brought the solution.

Technology is responsible for bringing us back from a Read Only (RO) culture to a Read-Write (RW) one…Human beings have been RW during most of our history. But for some time we stopped creating things and started consuming them instead.

So I decided to switch to read-write mode, post this here, and maybe give you some food for thought for the weekend…

org.springframework.beans.factory.BeanCreationException: Error
creating bean with name 'XY' defined in class path resource
[applicationContext.xml]: Instantiation of bean failed; nested
exception is org.springframework.beans.
BeanInstantiationException: Could not instantiate bean class
[XY]: Constructor threw exception; nested exception is
java.lang.LinkageError: You are trying to run JAXB 2.0 runtime
(from jar:file:/.../WEB-INF/lib/jaxb-impl-2.1.8.jar!/com/sun/
xml/bind/v2/model/impl/ModelBuilder.class)but you have old
JAXB 1.0 runtime earlier in the classpath (at jar:file:
/.../WEB-INF/lib/jaxb-impl-1.0.4.jar!/com/sun/xml/bind/
WhiteSpaceProcessor.class) Please remove the JAXB 1.0
runtime for 2.0 runtime to work correctly.

Well, I have, several times… and the task of having to figure out which library causes this dependency conflict seemed unresolvable pretty scary at first! Luckily, there is the m2eclipse plug-in with its excellent dependency graph. So if you are using Eclipse, whether you are actually using m2eclipse to manage your project or not, just the dependency graph makes it worth having a look at it. I still run my maven tasks on the command line, but have m2eclipse installed, just to be able to use the graph.

After identifying which library is causing the dependency conflict, all you have to do is to add an “exclude” node to that dependency in your pom.xml. In the above case, this snipped did the trick:

<dependency>
    <groupId>...</groupId>
    <artifactId>...</artifactId>
    <version>...</version>
    <exclusions>
        <exclusion>
            <artifactId>jaxb-impl</artifactId>
            <groupId>javax.xml</groupId>
        </exclusion>
        ...
    </exclusions>
</dependency>

/System/Library/Frameworks/JavaVM.framework/Versions/

directory all point to “CurrentJDK”, which points to “1.6″. The thing is that Snow Leopard ships with a 32 bit version and a 64 bit version of the VM (Virtual Machine), 64 bit being the default one. The Java Preferences app shows this nicely:

And that is the big news about it, since a 32 bit version of java 6 didn’t previously exist for OS X.

Now I’ve previously had to tweak Eclipse to use the 1.5 VM (see “Java Versions on Mac OS X“), and now it just works. I’m assuming that this is because of the “mixed mode”:

$ java -version
java version "1.6.0_15"
Java(TM) SE Runtime Environment (build 1.6.0_15-b03-219)
Java HotSpot(TM) 64-Bit Server VM (build 14.1-b02-90, mixed mode)

…so the VM would automatically detect if an application should be executed in 64 or 32 bit mode and then start the correct VM. I still need to investigate how this actually works. Anyway, the good news is that java and eclipse seems to be working better with Snow Leopard. I’ll write more on this as I continue working with it, for now here is an interesting post on the topic:

http://blog.zvikico.com/2009/09/eclipse-java-and-snow-leopard.html

$sudo lsof -Pi | grep -i "listen"

FAQ: ftp://lsof.itap.purdue.edu/pub/tools/unix/lsof/FAQ
Man page: ftp://lsof.itap.purdue.edu/pub/tools/unix/lsof/lsof_man

$ mvn --version
Maven version: 2.0.9
Java version: 1.6.0_07
OS name: "mac os x" version: "10.5.6" arch: "x86_64" Family: "mac"

In this case, maven 2.0.9 is running, so we’ll see how to switch to maven 2.0.6. First we need to know where the maven executable, or in this case, the symbolic link to the executable is located:

$ which mvn
/usr/bin/mvn

Next, we’ll use ls to check where the symbolic link is pointing:

$ ls -l /usr/bin/mvn
lrwxr-xr-x  1 root  wheel  24 Apr 24 14:26 /usr/bin/mvn -> /usr/share/maven/bin/mvn

Finally, if you have different maven versions installed, you can switch between them by overwriting the symbolic link:

$ sudo ln -fhsv /usr/share/maven-2.0.6/bin/mvn /usr/bin/mvn

After providing your password, the symbolic link should now be pointing to the maven 2.0.6 executable. To doublecheck, type

$ mvn --version

The output should be something like this

Maven version: 2.0.6