1. Link the library project to all relevant projects (“Project Preferences” -> “Java Build Path” -> “Projects” -> “Add…”)
2. Then, add the client-side code of the library (by adding it as a module.) Therefore, edit the gwt.xml of your application and add for example <inherits name="net.svenbuschbeck.gwt.lib.SuperLib "/> where SuperLib is the file name of the gwt.xml file in you library project and before that is the package it lies in.
3. Add the code to the project by linking a source folder. Unfortunately, this is required if you do not want to write an Ant script to compile your application. (If you prefer Ant check this out) I don’t like the idea of using such a script because if you forget to run it each time you make changes, you will end up in confusion—let’s go for the convenient, automatic way then.
   1. Add a folder to your application project; open the “advanced” section in the folder creation dialog, select “Link to alternate location” and pick the source folder (usually “src”) of your library project. (Hint: if you work within a team using a versioning system, you can create a variable for that folder and use this instead. This way, each of your colleagues can put the library project in a different folder and accommodate for that by adjusting the variable )
   2. Right click the folder, “Build Path” -> “Use as Source Folder”. Done.

Surprisingly, the GWT plugin for Eclipse does not honor the project linking, thus all the references need to be made explicit or you will end up with lots of the following: ClassNotFoundException.

com.google.gwt.core.client.JavaScriptException: (NS_ERROR_DOM_SYNTAX_ERR): An invalid or illegal string was specified;

Again, GWT tricked me into thinking I am writing Java code and made me forget about that it is going to be compiled into Javascript. And because of the latter, a division by zero does not throw an DevisionByZeroException, no, it returns NaN even for native data types (there is no differentiation between double and Double in Javascript — there is only the object-version of double, which can be of value Double.NaN).

But also GWT was not prepared to handle Double.NaN. When calling canvas.getContext().drawImage(image,x,y) and one of x and y or both were Double.NaN I got the error message shown above. If you got the same… you know what to do now: check all devisions in your code for potential devisions by zero!!

I tried to add an addAttachHandler to the RootPanel to get informed about the root panel getting detached from the DOM so that I can finalize my application. Surprisingly, that does not work in Chrome (tested Chrome and Firefox only).

But besides that this sounds like a bug to me, I found the “proper” way of doing things before the application ends:

Window.addWindowClosingHandler(new Window.ClosingHandler() {
	@Override public void onWindowClosing(ClosingEvent event) { ... }
});

In the end, I think something like Document.addUnloadHandler would be more suggestive… closing the window or reloading a page is both exiting the application by unloading the DOM — not closing the window.

...
import com.google.gwt.event.dom.client.ClickHandler;
import com.google.gwt.user.client.Event;

public class Anchor extends com.google.gwt.user.client.ui.Anchor {

	@Override public void setEnabled(boolean enabled) {
		super.setEnabled(enabled);
		if (isAttached()) {
			onDetach();
			if (enabled) {
				sinkEvents(Event.ONCLICK);
			} else {
				unsinkEvents(Event.ONCLICK);
			}
			onAttach();
		}
	}

	@Override protected void onLoad() {
		super.onLoad();
		if (isEnabled()) {
			sinkEvents(Event.ONCLICK);
		} else {
			unsinkEvents(Event.ONCLICK);
		}
	}
}

Note the onLoad method, it sets up the state when the widget gets attached to the DOM the first time. It is required because setEnabled() could have been called before the anchor got attached.

If you encountered the same issue, please vote for this bug report.

There is another fix to the “well known” issues with the ATI Radeon X1400 and Ubuntu 10.04 to 10.10 besides the one posted about one year ago (see here).
The previous fix kept the graphics card working normally but harmed the overall operating system’s stability, so here is another fix based on disabling all 3D features of the device to get rid of the flickering screen.

It’s up to you to choose what you are able to live without
a) The desktop settings panel and “Segmentation fault” errors now and then, or
b) 3D acceleration (does not harm video playback or any other basic OS functionalities)

For solution a) see this.
For b) create this file: /etc/modprobe.d/radeon-kms.conf — and add following content

options radeon modeset=0

Solution found here (in German).

Create a file in /usr/local/bin/skype and insert

#!/bin/bash
LD_PRELOAD=/usr/lib/libv4l/v4l1compat.so /usr/bin/skype

Finally, make it executable by sudo chmod a+x /usr/local/bin/skype
Use this file to start Skype from now on. Done.

But not for me. Skype refused to eat it: ERROR: ld.so: object '/usr/lib/libv4l/v4l1compat.so' from LD_PRELOAD cannot be preloaded: ignored.
Until I finally found this one here.

Just to cut a long story short, here is why: all the other solutions work for 32bit Linux only — but hey, I do not have any of my old laptop’s potential to be wasted — I am running 64bit Ubuntu (tested with version 9.10 and 10.10 64bit). And with a minor tweak, the fix will work for you, too.

Install the video4linux libraries:

 sudo apt-get install lib32v4l-0

And change /usr/local/bin/skype to

LD_PRELOAD=/usr/lib32/libv4l/v4l1compat.so /usr/bin/skype

Its just about the “32” — and one good example more of why you should put meaningful error messages in whatever software!

Thanks Eoin Murphy.

My goal was to set a cookie to expire in about one month from today like this:

Date expires = new Date(new Date().getTime() + 1000 * 60 * 60 * 24 * 30);
Cookies.setCookie("myCookie", "myData", expires);

And kept wondering why the cookie never got stored.

And finally created a simple test case like this:

Date today = new Date();
Date tomorrow = new Date(today.getTime() + 1000 * 60 * 60 * 24);
Date nextMonth = new Date(today.getTime() + 1000 * 60 * 60 * 24 * 30);

And got following dates:

today=Mon Feb 07 14:27:50 CET 2011
tomorrow=Tue Feb 08 14:27:50 CET 2011
nextMonth=Tue Jan 18 21:25:02 CET 2011

According to Java’s calculation, the cookie was expired already before even being set.

Took me a bit to understand why:
1000 * 60 * 60 * 24 * 30 = 2,592,000,000 = 0x9A7EC800
Thus, the first bit got set to one… a classical overflow causing the integer value to become negative — just try:

System.out.println(1000 * 60 * 60 * 24 * 30);

It will print out -1702967296.

Fix: Add a little L will solve the issue by forcing the compiler to calculate using the scope of long:

Date nextMonthLong = new Date(today.getTime() + 1000L * 60 * 60 * 24 * 30);

I guess I will fall for that one again sometime as the error is not obvious in my opinion — especially because getTime() returns a long and still, the compiler sticks with an int for the multiplication part.

public boolean isCollapsed() {
	return panel.isVisible();
}

public void setCollapsed() {
	panel.setVisible(false);
}

Seen it? Despite the complicated and cryptic error message, the mistake is rather simple: the setter method is missing a parameter, i.e. “public void setCollapsed(boolean collapsed) {“.

class A {}
class B extends A {}

It is just logical that casting B to A works fine:

A anObjectOfClassA = new B();

But when it comes to collections of As and Bs, a strange phenomenon appears in Java:

Collection<B> collectionOfBs = new LinkedList<B>();
Collection<A> collectionOfAs = (Collection<A>)collectionOfBs; // this line does not compile!

That is, though the collection wrapper (the java.util.Collection class) is the same and B extends A, casting a collection of objects of class B to a collection of objects of class A throws an compile-time error.

But it works using generics (the whole class for the sake of completeness and reusability):

import java.util.Collection;
import java.util.LinkedList;

public class CollectionCastingExample {

  class A {}
  class B extends A {}

  Collection<B> collectionOfBs = new LinkedList<B>();
//  Collection<A> collectionOfAs = (Collection<A>)collectionOfBs;

  Collection<A> collectionOfAs = downCastCollection(collectionOfBs, A.class);

  /**
   * Casts a collection of objects of class B where B extends A to a collection of objects of class A.
   *
   * @param <T> Base class
   * @param collection Collection of objects of a class extending T
   * @param aClass Representation of T
   * @return Collection of objects of T casted from given collection of objects of a class extending T.
   */
  @SuppressWarnings("unchecked")
  public static <T> Collection<T> downCastCollection(Collection<? extends T> collection,
      Class<T> aClass) {
    return (Collection<T>) collection;
  }
}

Despite the fact that a @SuppressWarnings("unchecked") is required, it avoids iterating over the whole collection of Bs and casting each of them from B to A plus adding them to a new collection of As.