[Live-demo] OpenJDK Only for LiveDVD 5.5?

[Even Rouault]

Le dimanche 01 janvier 2012 19:03:33, Andrea Aime a écrit :
> On Sun, Jan 1, 2012 at 6:55 PM, Andrea Aime <andrea.aime at geo-
solutions.it>wrote:
> > The brief facts:
> >> * Sun Java is not allowed to be packaged into future distributions (like
> >> ubuntu, debian, or OSGeo-Live). Instead, users are expected to download
> >> SunJava from Sun.
> >> * SunJava 7 will be based upon OpenJDK.
> >> * OpenJDK is reportedly much better than previous OpenJDK versions.
> 
> Hmmm.... I wanted to run a benchmark to substantiate this claim but there
> are no OpenJDK 7 binaries available
> for my aging Ubuntu 10.04 (which I'll upgrade only when the new LTS shows
> up).
> 
> Also, on Windows there are no OpenJDK builds so in the end we need to
> target Oracle JDK anyways (besides
> the obvious business reasons), this means a OpenJDK support will have to
> come in parallel (aka "more work")

Not sure how/if it can help for geoserver/geotools, but I can give you some of 
my experience with OpenJDK6 and Windows. I have ported a quite big Java app 
from Sun Java 1.4.2 -> Sun Java 1.6.0 -> OpenJDK 1.6.0 and it is now in 
production in our client.

It is true that there are no Windows OpenJDK builds easily found. I finally 
build mine. The hardest part was to gather all the requirements (cygwin, 
directx headers, freetype, GNU make, etc...), plus some undocumented issues 
that I finally identified as being due to my use of a non-English version of 
MSVC. But overall I found that the build instructions worked well if you 
follow them closely. Lately, I've updated to the build b23 and found that the 
building process was a bit easier than during my first experience that dated 
back to more than 1 year 1/2.

As far as the port of the app is concerned, most problems found were due to an 
inadequate use of some bits of the Java API where the Sun Java 1.4.2/1.6 
implementation were permissive, but the OpenJDK one not. When looking at the 
docs, we realized that we were relying on unspecified behaviour. The most 
problematic was due to an inadequate use of threading with AWT (use of AWT 
from another thread than the AWT event dispatch thread).

The other most problematic part I can recall was related to font rendering. 
The font engine of the windows openjdk build uses freetype whereas the 
commercial version uses a closed-source engine. This required adjusting font 
sizes in GUIs and setting some anti-aliasing hints.

I'm not sure if the changes we did would have been necessary if we had 
targetted JDK7/OpenJDK7 directly instead of OpenJDK6, but at the time they 
were done it wasn't yet released.

Best regards,

Even