Nicolas Richeton

I learned recently that there are several ways to code accented characters in Unicode. As instance, a word like “Rivière” can be stored as :

R i v i è r e (composed characters)
or
R i v i e ` r e (combining characters)

At first, it seems to be only technical details. Most Java developers use Strings without taking much care of how it is stored internaly. Convertion problems happen sometimes but can be easily fixed in most cases.

But things are more complicated here. Java Strings can use the two forms and both are valid : Eclipse debugger displays the same value for each one. However if you try to use Object#equals on two equivalent strings which are not using the same form, the result is false.

This means that equals cannot be used to compare Strings. Other comparators supporting Unicode forms are available in the Java API, but you can choose to use them only in your code. If the comparation is done by a third party library, you have no choice than to convert the String from one form to another.

This can be done using java.text.Normalizer, but this is a Java 6 API. If you have to ensure compatibility with Java 1.4 or 5, one way is to use IBM’s ICU4J, which is available in the default Eclipse distribution as a plugin.

com.ibm.icu.text.Normalizer.compose(String str, boolean compat)
and
com.ibm.icu.text.Normalizer.decompose(String str, boolean compat)

So when do you need to use theses method ? ALWAYS !!
You never know when a library will choose to return a String in one form or the other because it is often unspecified.

This is exactly what happens with SWT : depending of the OS and the method you call you can get two Strings that are equivalent but return false when using equals.

Here is an example on OSX
* Text#getText() returns the first form
* a FileTransfer Drag and Drop returns paths in the second form.
See Bug 141282

In my opinion, a library should only use a single form and returning string of the other form should be considered as a bug. Otherwise developers have to do too many convertions all over the code to ensure that strings can be correctly compared.

I was asked in my previous blog entry how to add SWT to a project classpath in order to run a simple snippet.
This for me the quickest way to run a SWT snippet from scratch :

Start Eclipse

Create a new plugin project

Go through the plugin wizard

Do not use templates

Add SWT dependency

Create a new class

Note : If you want to run a SWT snippet you even don’t need these steps. Just copy the snippet content and paste it in the package view. This will create the java class in the right package, ready to be launched. Then jump to the “run snippet” step.

Paste the snippet

Organize imports

Run the snippet

And voila

Once you got this working, you can start working with JFace or RCP, by adding the corresponding dependency.

I spent several hours to locate a SWT problem with DND and special characters in path on OSX. The hard part was that strings were are correctly displayed by SWT and work with the file API. But if you try to compare or check equality of this string with another one, it always fails because a special char uses 2 chars instead of one. This is only an encoding problem, but not easy to find.

See Bug 141282 on Eclipse
and Bug 97 on ShareMedia bugtracker

Custom drag and drop image does not work with FileTransfer on Mac.

https://bugs.eclipse.org/bugs/show_bug.cgi?id=189292

I pointed out the bug in the code, so this should be fixed quickly.

The Open GL viewer in Sharemedia never worked correctly on Mac, because the opengl depth test was failing : objects were drawn according to the order I created them (the latest ones over the oldest ones) whereas they should have been drawn according to their position in the scene. (the closest one over the farest ones).

On win32, everything worked as expected, so I suspected a bug on my Macbook video card (Intel GMA950) or in apple drivers.

I just solved this issue this morning : SWT/LWJGL has different default values for the creation of the opengl context : a depth buffer is created on win32 and not on osx.

To fix this, create the GLData object this way :
GLData data = new GLData();
data.doubleBuffer = true;
data.depthSize = 1; // Add this line to force a depth buffer

I guess this would solve this problem too :
http://lwjgl.org/forum/index.php/topic,1858.msg11016.html#msg11016

Now I can say that the OpenGL viewer will work on mac with the next release of Sharemedia.

UPDATE : See Bug 220518