There’s been a couple of reality-defying
pronouncements (second
one) from Sun folks. Who believes this junk?

I liked this quote from McNealy: “Somebody’s got to be in charge,
or nobody is”. Well, yeah, that’s a strength of our approach. Of
course, it really doesn’t make much sense to talk this way. Yes, it
is usually good to have some central group driving the evolution of a
piece of software. That’s a plus. But if that control is overly
tight, it becomes a minus. On top of that, “overly tight” changes
depending on the situation — there’s no single correct answer.

So, duh, one of the strengths of free software is that it lets
people experiment to try to find out what the “objective situation”
might be at the current moment.

Generics

Right there in the generics specification is some language
explaining that you can’t refer to members of a variable whose
declared type is a type variable, unless the member comes from
Object. So much for my question and my reading skills.
Yet another goofy restriction though. Sigh. It seems to me that it
could equally well have been designed such that a type variable “looks
like” its collection of bounds, and ambiguity would be resolved with
respect to the set of inherited members. Then there would only be the
issue I raised before.

In other news, perhaps we’ll start a Classpath branch for
generics work soon.

C++

Working with C++ continues to be interesting. It is nicely
expressive, gcjx is about half the raw line count of the current
gcj. That isn’t a completely fair comparison though.

On the other hand, I continue to run into things that C++ can’t
do. For instance, you can’t have a string as a template argument.
This means strange workarounds in some places in gcjx. I still don’t
understand why you can mark a constructor as explicit but
you can’t mark a cast operator that way. It seems to me that this
would be a nice way to avoid implicit casts.

Unfortunately some C++ lessons I’ve learned a bit late. E.g., if
you want to change the representation of some container, you’re best
off introducing a typedef early on and then using it religiously
wherever you use the container. Ideally you would have one such
typedef per field, I suppose. As it is now, if I want to refactor to
a different representation, I’m in for a lot of work.

You can sort of emulate C# properties by using C++ classes with
various overloaded operators. It isn’t the same since in C++ it is
the field’s type, not the field’s enclosing class, which determines
the triggers — but it is good enough for my purposes. I have a few
of these, where the gettor method is just operator(),
supplying a function-like interface.

Why would you do something weird like this? It seems to me that
in the absence of good refactoring
tools (and other sorts of restructuring tools), your best bet is
to try to make the text of your program assume some general shape
which can be more easily manipulated. In this case, a method call is
more general than a field access.

Maybe that’s bonkers.

In a similar vein I have kept to the minimum number of global
variables. Right now there are eleven. Of course there could be just
one; ten of them are really just convenience things that I (currently)
“know” to be truly global across all compilations. My opinion is,
whenever you add a global variable or a static field, you are probably
making a mistake. Too bad g++ doesn’t have warnings to let me enforce
this.

I’ve been looking at Java generics a bit, and I found something a
bit weird. Suppose you have a class like this:

class k<T extends Throwable & Comparable> {
  int doSomething(T arg) {
    return arg.compareTo(this);
  }
}

First, note that Throwable doesn’t
implement Comparable (and in fact multiple constraints
aren’t very useful when one implements another).

What should the generated code look like? According to the
generics paper I have, no cast is required in this situation.
But that can only be correct if the verifier always allows implicit
casts to an interface type to succeed, and then requires the execution
engine to detect incorrect calls.

This seems wrong to me. Instead it seems like the compiler must
insert an explicit cast whenever a value whose type is a type variable
is implicitly cast to a type other than its erasure type.

This weekend I started work on generics in gcjx. I’ve got the
parsing finished, and a fair amount of semantic analysis. Generic
methods don’t work yet, and code generation needs a serious overhaul
to handle the new code, but things are really coming along.

I read that there will be a Open
Source Java panel at JavaOne this year. Thanks to Wes Felter for this,
and for pointing out that Sun failed to invite any actual Free Java
hackers to talk about this.

I really messed up by not going to the conference this year.
Bummer. So, on the off chance that someone attending JavaOne might
read this, I’ve come up with some questions you might want to ask and
some things to bring up.

No funny business

The aforementioned article quotes Gosling as saying, “Most of the
folks in the open-source world have a pretty simplistic view of the
landscape”. Oh, come on. Let’s name names, let’s not make
unverifiable assertions about what “most” of any group wants, etc. In
other words, let’s be really honest with each other.

So, if Gosling, or anybody, says something like this at JavaOne,
please push back strongly. An argument like this is just a way to
make it hard to refute what someone is asserting.

Forking

You’re certain to hear the forking argument from someone on the
panel. This argument goes, compatibility is one of Java’s biggest
selling points, and if Java is made open source, this property will
be lost. This argument is wrong on several counts.

First, Sun will still control the “Java” brand. So a fork won’t
be called Java, just as White
Box Linux isn’t called “Red Hat Linux”.

Second, Linux vendors won’t fork Java anyway, just like they don’t
fork Perl, Python, Eclipse, or hundreds of other things. True, there
is “forking” in the kernel, but this is explicitly encouraged by the
kernel development model. And there is some forking in gcc, but if
you look at what actually happens, all the changes are closely
coordinated with the upstream developers — and gcc’s various ABI
stability problems will not be inherited by Java, as gcc’s problems
originate upstream.

Problems? What problems?

Sun invariably says that they can’t think of what problems open
source Java would solve that aren’t already solved. Of course that’s
ridiculous. It is pretty hard for Linux vendors to ship a working JRE
on their platform if they make any sort of changes at all — the Java
vendors are just too slow. And Debian can’t ship a complete Java at
all, so lots of Java software ends up in unfree.

On top of this, non-free core software is something to be avoided
in the community. This overly-controlled approach on Sun’s part is
losing the Linux desktop to .NET. I’m curious to hear what Sun has to
say about this. Do they notice this? Do they care? Do they think
there is some other strategy to change this?

What we want

Instead of listening to various uninvolved people project their
beliefs onto Free Java developers, how about standing up and giving a
little speech about what it is we really want? This is pretty
simple, and it would be a nice community service.

• While open sourcing Sun’s implementation would be wonderful, it
  isn’t actually necessary. I do think that opening their
  implementation would help both Sun and Java, perhaps not in the short
  run but certainly in the medium-to-long term.
• We would like open access to the TCK for free implementations.
  We also believe in compatibility, and go out of our way to provide it.
  In fact, sometimes Sun makes this harder than it needs to be, see this
  thread. I’ve occasionally read statements indicating that the TCK
  is available, but it simply isn’t true.
• We would like the subsetting restrictions to be lifted a bit.
  They are basically incompatible with the open source development
  process. I’m sure we could work out some kind of viable compromise
  in this area, preserving both our ability to hack how we like and
  Sun’s desires for completeness and compatibility.

A friend of mine is working on a Senate campaign here. This
weekend I spent a little time helping him out. I imported some voter
registration data from the county into postgres and ran a few
queries. I haven’t done any database hacking before, so this was
pretty fun. Of course I ran into all the usual snags: the data was
incorrectly formatted, the version of postgres I have can’t directly
import CSV data anyway, etc.

On the flip side, all the needed tools were already just sitting
around — I installed tcllib and postgresql-tcl via up2date, and then
wrote a short import/export script. (I chose these since I already
know Tcl well enough to just type it in, but really it could have been
anything.) Tcl is slow, but for a single import, it hardly matters,
and postgres 7.5 will solve this directly anyway.

I think the fact that this was just a weekend hack is pretty
interesting. I’ve been thinking about expanding this code a bit, to
help my friend some more, say by writing a web app that talks to the
database so that we can get the information distributed more
efficiently. All the parts needed to do that are just an up2date away
— and this kind of bundling is a property of free software, and more
or less prohibited by the proprietary business model. That’s pretty
nice for us end users.

I liked this one the best of all three. I thought the visual
style was more beautiful and evocative — I wish I had seen this movie
as a kid. Also it was more suspenseful than the first two
installments. It still isn’t as good as the books, unfortunately, but
it is worth seeing.

The GCC Summit was a
big success — lots of people there, lots of interesting papers and
discussions. The “statically typed trees” talk looked like an early
favorite to me, but objects-in-C sort of turns me off; in the end my
favorites were the keynote, the loop optimizer talk, and the
autovectorization talk.

While there I hacked gcj a bit to generate more explicit code for
instanceof and checkcast. It turns out,
though, that we really need to wait for the new GVN and VRP passes for
this to make sense, so I’m just pocketing that patch for the time
being.

I got to see and meet lots of cool folks there — it was like a
year’s worth of socializing crammed into 4 days.

I think the most surprising thing I heard was that they are
planning to migrate gdb to use C++. I still have a hard time
believing that, but Andrew Cagney himself said it…

gcjx

I also did a fair amount of hacking on gcjx. In particular, I
wrote a pretty good chunk of the code to lower from the internal model
to gcc’s tree representation. For those not following closely, gcc
has undergone some huge changes in the last few years. With the merge
of the tree-ssa branch, it has now become much, much easier to write a
gcc front end. I expect it to get even simpler in the future.
Hopefully this realization will filter out to the community and we’ll
see more experimentation in this area.