Shrek 2 was about what I expected — funny but not hilarious, nice
graphics, simple storyline, and some clever subtle jokes. I enjoyed
it quite a bit, I recommend it. Elyn like it better than the
original, mostly due to less hype, I think.

Today I installed Mozilla on my girlfriend’s Windows box. What a
pleasant experience that was — congratulations Mozilla hackers.
She’s already using OpenOffice, and now she will be using free
software for email and browsing. Free software has come a long way
since those days ten years ago when a Tcl-based browser seemed like a
good idea and we were all waiting for XWord to work.

Refactoring

Today’s gcjx refactoring is like the work I had done on my
foundation: necessary, but in the end there’s just the same old dirt
showing.

Last night I spent some time making the libgcj bytecode verifier
a
bit more generic. This is still preliminary, but basically the
idea is to make it so that the verifier can be plugged into other
environments. We plan to put it in the gcj front end as well, but
other VM implementors might want to write the necessary glue code to
make it work for them — this is a bit ugly, but not really very
difficult.

Sometimes you just need a short break to reset your mind a bit.
The other day I was struggling with one particular gcjx bug. I came
back to it tonight, after a grueling day hacking the Eclipse 3 build
system, and it was suddenly trivial.

So, good news. gcjx can now once again parse all of Classpath,
only this time, it is handling inner and anonymous classes more
correctly (still not perfectly…), and it survives through code
generation:

$ find /tmp/gcjx-out -name '*.class' -print | wc -l
   2391

This weekend I finished enough of anonymous and inner class
handling to check it in. gcjx is now back to generating code. There
are some more fixes to come in this area. Recently I also added a few
warnings; usually this is really simple in the new framework.

Bryce had a nice idea, which was to replace gcjh with a new gcjx
back end. This was inspired by the gcjh Miranda
method bug, which is particularly ugly because it will require a
major infrastructural improvement to gcjh. So, I started writing the
JNI header back end, which predictably is really simple. gcjx holds
the promise of being able to write class files, header files, and an
object file all from a single compilation; strange but also
convenient.

Today I helped Anthony debug a libgcj problem over irc. I sure
wish there were an easy way to hook an irc session up to an
already-running gdb so we could interactively share the debugger.
Anyone have a cool hack for this? Preferably one that has some sense
built into it so that not just anybody can hijack the debugger…

GDirect

I spent a little time yesterday working on an easy way to create
native methods for Java. I call it “GDirect”. The idea is pretty
simple, basically have a package that creates native method
implementations on the fly, based on declarations in your code. So,
e.g., you would write something like this:

public class example {
  static {
    // Second argument is base name of shared library.
    GDirect.link (example.class, "m");
  }

  public static native double atan (double x);
}

In this example, example.atan will call the C math
library function atan, nothing more is needed.

Issues

There are a few issues with this approach. One is pointers, but
with gcj we can just represent these with RawData.
Another is structures, which I’m just punting on. A third issue is
type mismatch — if the Java int and the C
int are not the same, you need translation at runtime.
So far I’m not handling this, but it is actually pretty easy to deal
with. There are some other type-mapping issues to resolve as well,
I’ll look at those more a bit later.

Since this uses JNI under the hood, it is pretty slow. With the
upcoming binary compatibility ABI in gcj, though, we can do better
there. In some situations we can completely eliminate the need for a
runtime stub and just have direct calls to the C functions from
Java.

Opportunities

This code can be made completely portable across JVMs without much
effort. It works by creating new functions on the fly with libffi,
and it registers these functions with the JVM via the JNI
RegisterNatives call. For gcj, we’ll have some CNI
equivalent of this in the not-too-distant future, so we’ll be able to
make GDirect both portable and more efficient when running on our
implementation.

libffi’s closure API is what makes this possible. It works on
most platforms, though not all yet. I think a similar technique could
be used to make bridges in other places, e.g. interfacing Java to
Mozilla or to OOo.

Another random idea is to make it simpler to wrap libraries that
already have an object-oriented interface. One way we could do this
would be to tell GDirect about a field which holds a native pointer.
Then we would treat non-static native methods specially, looking up
the native pointer at invocation time and passing it to the underlying
C API. Combined with a simple facility to rewrite method names when
linking, this would make it very easy to create and maintain, say, a
Gtk wrapper library. For instance, something like
gtk_window_set_type_hint would become:

public class GtkWindow extends ... {
  // This would actually be in a superclass somewhere.
  private RawData nativeInfo;

  static {
    GDirect.link (GtkWindow.class, "gtk", "nativeInfo",
                  GtkRewriter.getInstance ());
  }

  public native void setTypeHint (int hint);
}

Here, GtkRewriter would be a special class that would know how to
transform “GtkWindow.setTypeHint” into “gtk_window_set_type_hint”.

Tom Fitzsimmons has modified JHBuild to
build
gcj. This is pretty cool, check it out. I’m hoping to convince
him to add more packages, like GNU Crypto, to the
mix.

gcc

The tree-ssa branch was merged into
mainline today. Congratulations are in order to Diego and
everyone else who worked on this, it’s been a long time coming. Not
to be ungrateful, but now someone should write that VRP pass… 🙂

I’m still working on making anonymous, inner, and local classes
behave properly. It’s been slow going, but mostly because it is
spring and things are more social now.

Nightly builds

I finally investigated a couple nightly build problems. Now the
API comparison pages
should be working again. I still haven’t investigated the GNU Crypto
check failure or the Kawa build failure; maybe later.

At long last, a movie where the climactic scene is literally dog
versus vampire. Who writes this stuff?

I spent today reading a few threads on JavaLobby. What a sad waste of
time that was! We’ve finally found a place where the typical comment
level is even lower than on SlashDot.

As DV
points out, it sucks that some
folks don’t get it. Even, it turns out, folks who are ostensibly
in our own community.

One question that comes up from time to time is “what good is an
open Java?”. The answer to that is so obvious that we generally just
skip over it, assuming everybody has been following along the last
ten years. Apparently, they haven’t.

So, the story is, any single entity that controls access to the
source will be driven by the incentives that affect them. For
instance in the software market you often see companies moving more
toward enterprise customers, leaving the lower end to be filled by
others. The general idea here, btw, is true regardless of whether we
are talking about open or closed source — for open source the
incentives differ (and of course the consequences differ too, as we’ll
see).

What this implies is that, if you aren’t along the “incentive
path” of the gatekeeping organization, you are in trouble. This is
one reason that open source is useful — it is a way for users to
reduce their risk when adopting technologies, since they have some
ability to solve the problems they face in their “less interesting”
environment.

Another way to be screwed by non-free software is to be working on
an area that is “anti-strategic”. In this scenario, the gatekeeper
decides that supporting your situation is actively against their
interests. Then you are just completely out of luck.

Now, for Java and Linux the way this plays out is that Linux’s
higher rate of change occasionally undermines JVMs. Linux vendors
typically have a hard time shipping a solid JVM on all their supported
platforms in a timely way, especially if there have been changes in
the kernel or libc — floating stacks, SELinux, NPTL, or even more
mundane things.

Considerations like this are what drove us to actually implement
gcj-eclipse (as opposed to just dreaming about it and hacking on it in
my spare time). There simply wasn’t a way to get a working JVM on all
our target platforms on our schedule.

Contrast this with, say, any other piece of the entire operating
system. With free software, you run your own life. If you want to
build an operating system that works on S/390, or PPC64, or whatever,
you can port anything you think is important to it. It might not be
easy, etc, but at least you have the option. Case in point: for the
JVM we had to punt, but for Eclipse we put in the work to make a
64-bit port. So, there’s your value right there.

So far we haven’t really run into the “anti-strategic” scenario in
the Java-on-Linux thing, though I’ve seen various folks predict its
arrival on the assumption that Sun will turn to the IP protection
racket as their technology business slides. If that happens it will
be a nice bit of punctuation to the whole free software saga — sort
of the moral at the end explaining why tying your fate to an
organization whose needs, eventually, diverge from your own.

Dalibor
has some nice things to say on the doomsday scenario of Sun moving
into the protection racket, and some of the goofier aspects of the
SCSL and TCK licenses.

Specific Response

I read through Fleury’s comments again. I’ve debunked most of
this stuff already, I won’t bother doing it again.

gcjx

gcjx development
has been going a bit slow lately. I’m working on fixing anonymous
classes and the capture of final local variables, it is sort of slow
going.

Eclipse 3

I’ve been looking at Eclipse 3.0M8 lately. It seems pretty good
— faster, more eye candy (actually a minus for me, a plus for some I
guess), some handy new compiler knobs. Also it has a built-in code
formatting feature, which can mostly handle GNU Classpath’s style.
I’ll probably check in the style file at some point, meanwhile email
me if you want a copy.