Screwing around with GJ.

C. Scott Ananian

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 (JSR-14). I've been programming with JSR-14 for about two years now, since the early 1.0 prototypes. In November Sun released version 1.3 of the prototype compiler. This page has been updated accordingly.

This page is a place to collect my various work on GJ-related things, including updated javadoc for the current 1.3 prototype compiler, SinjP, a javap tool that works on JSR-14 class files, SinjDoc, a javadoc tool that works on JSR-14 source files, a LALR(1) grammar for JSR-14 (see also Eric Blake's work), and a a list of bugs I've found in the 1.3 prototype. The current prototypes are *almost* but still-not-quite able to compile FLEX; I'll probably keep hacking on things until the GJ compiler is bug-free and usable enough to let me get Real Work Done on FLEX.

If you're interested in JSR-14, you may also be interested in JSR-201, which includes enumerations, autoboxing, for loop enhancements, and import of static members. Also proposed for Java 1.5 are JSR-133 (revisions to the java memory model and threads) and JSR-181 (a metadata facility).

I (and others) have also written a package of parameterized collections classes which greatly extend the power of the standard java.util library. This library was originally developed for the FLEX project.

SinjDoc: a Javadoc-like tool for JSR-14

This is still in active development. You can download the current version 0.3 sources; caveat emptor. API documentation (no frames version) generated by the tool is also available, as is a list of changes made since the last release.

Sign up on the SinjDoc-Announce mailing list to be notified of new releases of SinjDoc.

For a good example of what this tool can do, look at the generated documentation for the FLEX compiler infrastructure, which is generated using it.

SinjP: a Javap-like tool for JSR-14

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

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.)

Updated javadoc for standard libraries

The 1.2 prototype compiler updated the "generic"-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 didn't help that the prototype compiler used to crash hard for some of these mismatches.) So --- to ease 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.3 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.
• I also have the signature-only javadoc created for the "latest Sun stubs" (as of 10-April-2003) by my sinjdoc tool. This includes some other Java 1.5 goodies which aren't yet in the official JSR-14 prototype compiler.

Bug list for 1.3 prototype compiler

Old bug list for 1.2 prototype compiler.

Here are the bugs I know about or suspect are in the 1.3 prototype compiler. Note that these may or may not have been confirmed by the good folk at Sun, 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. There are also some additional details which are not covered by the spec.
• Incorrect GJ prototypes for:
  • java.util.Arrays/java.util.Collections (questionable)
    Since the 1.0 prototypes, the following signatures have been in java.util.Arrays classfile: prototypes):

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

    These are the signatures listed in my "bug-fixed" javadoc, although the signatures in the original javadoc were:

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

    But these signatures break binary compatibilty, because they do not type-erase to the old signatures for these methods, which take Object[]. I believe the correct signatures should be:

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

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

  • java.util.Collections
    Since 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>);
    

    I believe this bug is now fixed in Sun's internal sources.
  • java.util.HashMap
    In the 1.3 prototype (and present earlier as well), the constructor to HashMap has the signature:

    public HashMap(Map<K,V> m);
    

    The signature should be:

    public <K2 extends K, V2 extends V> HashMap(Map<K2,V2> m);
    

    I believe this bug is now fixed in Sun's internal sources.
• NullPointerException in Flow.visitTry(Flow.java:873). This bug is present in the 1.4.2beta (non-generic) java compiler as well, so it's not GJ-specific --- but it does keep me from compiling FLEX entirely with the 1.3 prototype. This is sun bug 4848018 filed against 1.4.2beta.
• Compiler forgets parameters to Comparable. This happens frequently when incrementally building a project. Including all related files on the command line fixes the problem, but its quite annoying to have to recompile an entire large application every time a single file changes. Details to reproduce in the link.
• Scoping errors. Eric Blake has written up some examples of potential scoping errors in the 1.3 prototype. I'm not entirely convinced by all of his examples, and the "bug" seems to be that the compiler accepts erroneous code rather than *emitting* erroneous code or rejecting valid code, so these will probably impact you less than the bugs mentioned above.
• Type inference failure. The type inference engine still seems to be unable to resolve valid uses of parameterized types — in this case, a method involving mutually-recursive type parameters. Details are in the link.
• Unavoidable casts in bridge methods. It is impossible to create a JSR-14 implementation of java.util.Map where the entrySet() method behaves according to the specification, which says that entrySet().add(x) should throw an UnsupportedOperationException. Instead, you will often get a ClassCastException instead.
• Cyclic inheritance problem. This is now Sun bug 4862621. This is most relevant to the current GJ developer because code that works now will become erroneous when this bug is fixed, and you can't "fix" your working code now to work in the future because the compiler will not accept the "correct" code now.
• Extra parentheses cause VerifyError at runtime. This bug was discovered by "agentsmooth" on the GJ forum, and seems to exist in every prototype from 1.0 to 1.3. Removing the extraneous parentheses in the example fixes the VerifyError problem, and thus is an acceptable workaround.
• Typo in com/sun/tools/javac/v8/code/Symbol.java:579? More details in link; it seems that there is a single-character substitution of 'u' in place of 'l' in the 1.3_ea sources. Discovered by "couraud", enlightenment by "aserdyuk" in the GJ forum.

C. Scott Ananian

cscottcscott.net