Screwing around with GJ.

I've been playing with the various prototype compilers that Sun has been releasing as part of its "Extending the Java Programming Language with Generic Types" project. In addition, I've hung around the Forum trying to remedy some deficiencies in the prototypes released so far.

This page is a place to collect my various work on GJ-related things, including updated javadoc for the current 1.2 prototype compiler, a javap tool that works on GJ class files, and a a list of bugs I've found in the 1.2 prototype. I'm working on converting FLEX to GJ, so I'll probably keep hacking on things until the GJ compiler is bug-free enough to let me get Real Work Done on FLEX.

Updated javadoc

The 1.2 prototype compiler updated the GJ-ified Collections (and other?) APIs, but did not come with updated javadoc. As a result, your existing code which extends Collections tends to mysteriously fail because your type signatures no longer match properly. It doesn't help that the prototype compiler crashes hard for some of these mismatches. So --- to each your pain, I've gone through the javadoc with the help of my javap-like tool below and manually tried to fixup the javadoc to be accurate. Note that this is accurate to what's shipping now with the 1.2 prototype; note my list below for details on what I think may be "broken" in this release and thus slated for change in future releases.

So, without further ado, here are some links to the goodies:

• A tgz archive just like you downloaded from Sun. Only, this one has my fixes applied. The legality of redistributing this might be somewhat sketchy, although (because?) there is no license information enclosed.
• A patch against the official Sun distributed files. I should be okay in redistributing this, but it'll take some work on your part to apply.
• For your convenience, I've put the updated Collections API javadoc and Reflection API javadoc here on the web, so you can just browse directly instead of downloading.

Javap-like tool for GJ

I've written a no-frills javap-like tool that a) doesn't choke on bytecode emitted by the GJ compiler, as does the standard Sun javap, and b) actually parses the GJ Signature attribute to emit the correct GJ signature for the methods in the class. This was invaluable to be in looking through the jar files supplied with the 1.2 compiler to look for what had changed. Maybe it will be helpful to you, too.

To use:

• Download Harpoon.jar which contains the code for the tool. This is actually a full FLEX distribution, which is why the download is rather porky.
• Use it like so:

  % java -cp Harpoon.jar harpoon.Main.Javap java.util.AbstractSet
  

  (with the class you are interested in replacing java.util.AbstractSet, of course.)
  [see sample output]
• Make sure the prototype compiler's collect.jar file is also on your classpath, or you're likely to get the (mostly uninteresting) prototypes of the pre-GJ Collections classes; if the output of the command above doesn't give you GJ types on AbstractSet, this is the most likely reason why.
• (Note that there are odd historical reasons why the name "Harpoon" is associated with the FLEX compiler, which explains the package and jar file names above.)

Bug list for 1.2 prototype compiler

Here are the bugs I know about or suspect are in the 1.2 prototype compiler. Note that none of these have been confirmed by the good folk at Sun yet, so some of these might actually be "features" in disguise.

• Errata in section 7 of the specification document. The ParamaterSignature and MethodTypeSignature productions are wrong.
• Incorrect GJ prototypes for:
  • java.util.Arrays/java.util.Collections (questionable)
    The old java.util.Arrays javadoc had the signatures:

    public static <T extends Comparable<T>> int binarySearch(T[] a, T key);
    public static <T extends Comparable<T>> void sort(T[] a);
    

    But their signatures in the classfile have always been (in 1.0 and 1.2 prototypes):

    public static <T> int binarySearch(T[] a, T key);
    public static <T> void sort(T[] a);
    

    My "bug-fixed" javadoc lists signatures that match the class file (i.e. without the Comparable bounds), and I'm guessing this is the "correct" signature due to array oddities --- the array could have nothing but Comparable objects in it, but the array type could safely be something bland like Object[]; thus the Comparable bound is too strict.

    One of the java.util.Collections.sort() methods has the same issue.

  • java.util.Collections
    In the 1.2 prototype, the Collections.unmodifiableCollection() method has the signature:

    public static <T> java.util.Collection unmodifiableCollection(java.util.Collection<T>);
    

    The signature should be:

    public static <T> java.util.Collection<T> unmodifiableCollection(java.util.Collection<T>);
    

  • java.util.HashMap
    Most methods and constructors in the 1.2 prototype have covariant types where appropriate. However, the HashMap constructor has been overlooked. Its signature is:

    HashMap(Map<K,V> t);
    

    By analogy to the ArrayList, HashSet, and Hashtable constructors, this signature should be:

    <A extends K, B extends V> HashMap(Map<A,B> t);
    

• There is an apparent bug in the retro-fitting compiler that causes it to emit invalid Signature attributes in the classfiles. You probably won't notice this, since nothing really uses these at the moment, except javap-like tools and the new GJ reflection capabilities (which I don't think are implemented in any available code yet). But I'm pretty sure this is a bug, and here are the details.
• Crash in javac. This happens to me when I'm trying to build classes which extend the Collections APIs but haven't yet been updated with the new type signatures for addAll(), putAll(), etc. Details in the link.

cscottcscott.net