Advogato blog for aph

23 Oct 2012

Tue, 23 Oct 2012 16:35:31 GMT

We're doing an ARM64 OpenJDK port! Article at
http://www.advogato.org/article/1067.html

20 Feb 2009

Fri, 20 Feb 2009 17:04:27 GMT

I wrote an article: Shark, gcj, and HotSpot: A tale of three code generators. Article at http://www.advogato.org/article/1001.html

8 Nov 2007

Thu, 8 Nov 2007 17:25:13 GMT

Boy, do I feel stupid. As soon as I posted my blog, people pointed out to me that NetBeans 6.0 Beta 2 supports IcedTea out of the box, so all my hackery with NetBeans 5.5 was pointless.

However, NetBeans 6.0 Beta 2 doesn't work for me. It just displays a blank screen. After a little while, I've found out why. I always run all my test programs as X clients on a remote mcahine, with the server running on my desktop machine. It turns out that if you start 6.0 Beta 2 on the same machine as the X server, it displays correctly.

I suppose that NetBeans must be doing some of the same weird stuff that we've seen elsewhere, and trying to bypass part of the X protocol somehow.

8 Nov 2007

Thu, 8 Nov 2007 16:13:50 GMT

Download netbeans 5.5 from

http://www.netbeans.info/downloads/

OK, run the netbeans installer.

No Java Development Kit(JDK) was found on this system.

Oh dear.

zorro:~ $ java -version
java version "1.7.0"
IcedTea Runtime Environment (build 1.7.0-kojibuilder_27_sep_2007_14_56-b00)
IcedTea Server VM (build 11.0-b05, mixed mode)

OK, so it is there. Looks like the netbeans installer really doesn't like IcedTea.

Try with an old JDK 1.5 version.
Run the netbeans installer. Ah, that's much better!

Initializing InstallShield Wizard........
Launching InstallShield Wizard........

Right, so we have netbeans installed.

zorro:~ $ ./netbeans-5.5.1/bin/netbeans

That works fine. Okay, so let's try running that with IcedTea in --jdkhome rather than Java 1.5:

zorro:~ $ sh -x ./netbeans-5.5.1/bin/netbeans --jdkhome /usr/lib/jvm/java-1.7.0-icedtea-1.7.0.0.x86_64

Alright! That seems to work perfectly. Let's try "Hello, World"

init:
deps-jar:
compile:
run:
Exception in thread "main" java.lang.UnsupportedClassVersionError: javaapplication1/Main : Unsupported major.minor version 51.0
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:638)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:143)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:281)
at java.net.URLClassLoader.access$000(URLClassLoader.java:74)
at java.net.URLClassLoader$1.run(URLClassLoader.java:216)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:209)
at java.lang.ClassLoader.loadClass(ClassLoader.java:324)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:294)
at java.lang.ClassLoader.loadClass(ClassLoader.java:269)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:337)
Java Result: 1
BUILD SUCCESSFUL (total time: 0 seconds)

Excuse me? What is *that* all about? I'm running on a Java 1.7 VM and compiling on a Java 1.7 VM, but the class file version is wrong. Bizarre.

Let's try that from the command line, so we can see what's going on:

zorro:src $ /usr/lib/jvm/java-1.7.0-icedtea-1.7.0.0.x86_64/bin/javac javaapplication1/Main.java
zorro:src $ java javaapplication1.Main
Hello, world!

So, that works. Let's have a look at the class file version:

zorro:src $ jcf-dump javaapplication1/Main
Reading .class from ./javaapplication1/Main.class.
Magic number: 0xcafebabe, minor_version: 0, major_version: 50.

Hey, it looks like IcedTea's javac defaults to emitting .class files with the Java 1.6 major version. What happens with Java 1.7 and IcedTea's VM?

zorro:src $ /usr/lib/jvm/java-1.7.0-icedtea-1.7.0.0.x86_64/bin/javac -source 1.7 javaapplication1/Main.java
zorro:src $ /usr/lib/jvm/java-1.7.0-icedtea-1.7.0.0.x86_64/bin/java javaapplication1/Main
Exception in thread "main" java.lang.UnsupportedClassVersionError: javaapplication1/Main : Unsupported major.minor version 51.0

Ouch! So, although IcedTea is in theory Java 1.7 its VM will refuse to run .class files in the 1.7 format. Netbeans must be forcing Version 1.7.

OK, right-clock on Project/Properties, and there it is:

Source Level: 1.7

Change that to 1.6, Clean and Build Main Project:

init:
deps-jar:
compile:
run:
Hello, world!
BUILD SUCCESSFUL (total time: 0 seconds)

Alright, so that works. IcedTea is now running netbeans.

As far as I can see everything works perfectly, except for some small font rendering issues. The only real problem is that the netbeans installer won't recognized IcedTea as a valid Java VM, so you have to have Java 1.5 (an unfree VM) installed somewhere to install. Once netbeans is installed you can delete Java 1.5.

We really need to fix this; you shouldn't have to install an unfree JDK to run netbeans on IcedTea.

OK, now I'll try the NetBeans 6.0 beta.

30 Sep 2005

Fri, 30 Sep 2005 15:07:44 GMT

Umm, beaten by Dalibor on both the economic _and_ social liberal scale! I got a mere 80%/20% split. I'm not sure how Dalibor managed to beat me on the social scale. Must try to improve...

26 Sep 2005

Mon, 26 Sep 2005 10:42:06 GMT

Well, DevJam was a blast.

The idea was to talk with Debian developers about packaging components written in the Java language, and I went along as gcj maintainer. I was a little worried that the Debians wouldn't like the packaging we do with gcj in Fedora, or that they'd want to do it entirely differently. I needn't have worried, however. They were very receptive to suggestions and seem in general to be a smart and enthusiastic bunch of people.

Friday began with mjw's thing. Summary: we're 90ish percent done, but it doesn't work. Or something like that...

I can't remember what else happened on Friday.

I kicked off the proceedings on Saturday by talking about gcj and how it works on GNU/Linux systems, with particular regard to the whole precompiled database thing. Then Jeroen van Wolffelaar spoke about Debian packaging and how it works, which was very useful for me. My impression -- which might of course be incorrect -- was that Debian packaging is nicer in some ways than RPM, worse in others, and just different enough to be totally incompatible. Sigh.

We agreed, I think, to concentrate on the packages at jpackage.org. This is easy for Fedora (jpackage and Fedora are RPM based distributions) but hard for Debian. I don't know if this is going to work, but I think it's worth a try.

I'm a little worried that Fedora and Debian might be duplicating effort, particularly with regard to sanitizing packages. This sanitization is necessary because we have to be very sure that there are no unfree packages shipped by mistake. Hopefully, where one distro has sanitized a package the other will be able to use that as a base.

gbenson talked for a little while about how the rebuild-gcj-db and aot-compile-rpm scripts work, so that they can easily be used in a Debian-based system. That should work well, I think.

DevJam itself was interesting. The idea is that people turn up with computers and lock themselves in a room with a ton of food for a couple of days, hacking and talking together. There's plenty of room for people to sleep. All rather like a Scout camp, but minus the healthy outdoor activity and the singing. As a weakling I didn't do the sleeping on the floor thing, instead staying in hotel in the centre of Oldenburg. (The Hermes: very good, 60 Euros per night. Next to the railway station. Recommended.)

One thing I really got from this is how lucky I am to work on free software full time -- the attendees at DevJam were smart and enthusiastic and quite inspiring. It was an opportunity to recharge my batteries.

So, I'm glad I went and I hope to meet the Debians again. Until then, we have plenty of things to be getting on with!