Re: [Cp-tools-discuss] Contributions: java parser; java annotation tool.

[C. Scott Ananian]

On 14 Jul 2002, Mark Wielaard wrote:

> On Sat, 2002-07-13 at 16:36, Nic Ferrier wrote:
> > 
> > I think generics are a good idea, but I'm not that bothered about
> > them till the GNU project has a compiler that supports them.
> 
> Kopi Version 2 does:
> http://www.dms.at/kopi/general/ann_2.1A.html
> 
> I haven't tried it yet but if someone has written some code that uses
> generics it would be interesting to know how well it works.

well, the FLEX project (http://flex-compiler.lcs.mit.edu) is a very large
body of source that uses generics; my attempts to test Kopi v2.1a
(downloaded from http://www.dms.at/kopi/download/kjc-2.1A-bin.jar)
were hampered as follows:
  a) the downloaded JAR file was missing the file
       gnu/getopt/MessagesBundle.properties
     which rendered it completely inoperable.  This was a minor issue,
     easily fixed.
  b) Kopi doesn't implement the grammar hack described in JSR-14 to
     workaround the lexer recognizing '>>' as the right-shift token
     in expressions such as:
        Set<Set<Foo>> s = new Set<Set<Foo>>();
     Laboriously worked around by rewriting all of these as:
        Set<Set<Foo> > s = new Set<Set<Foo> >();
  c) A (parser?) bug in Kopi v2.1a prevents using generic constructors,
     which are needed to implement the proper genericized collections
     API.  For example, a method extending java.lang.AbstractList should
     have the constructor:
       class MyList<E> extends AbstractList<E> {
        public <T extends E> MyList(Collection<T> c) {
          ...
        }
       }
     This generic constructor is not accepted by Kopi, although it is
     legal JSR-14.  I worked around this by rewriting all of my
     collections implementations to remove the generic constructor:
        public MyList(Collection<E> c) { ... }
  d) [SHOWSTOPPER] Kopi then gave the following (bogus) errors and threw
     an unchecked exception: (excerpted)

Util/Default.java:258: error:Too less type arguments for type 
"java/util/AbstractList"; required: 1 [JSR 41]
Util/Collections/AbstractHeap.java:96: error:Cannot find type 
"java/util/Map/Entry"
Util/Collections/AbstractMapEntry.java:17: error:Cannot find type "Map/Entry"
[...]
Exception in thread "main" at.dms.util.InconsistencyException: type not checked
        at at.dms.kjc.CClassNameType.getCClass(CClassNameType.java:117)
        at at.dms.kjc.CReferenceType.isAssignableTo(CReferenceType.java:275)
        at at.dms.kjc.CTypeVariable.isAssignableTo(CTypeVariable.java:157)
        at at.dms.kjc.CReferenceType.isAssignableTo(CReferenceType.java:252)
        at at.dms.kjc.CClass.checkInstantiation(CClass.java:516)
        at 
at.dms.kjc.CClassOrInterfaceType.checkType(CClassOrInterfaceType.java:117)
        at at.dms.kjc.CClassNameType.checkType(CClassNameType.java:210)
        at at.dms.kjc.JTypeDeclaration.join(JTypeDeclaration.java:196)
        at at.dms.kjc.JClassDeclaration.join(JClassDeclaration.java:127)
        at at.dms.kjc.JCompilationUnit.join(JCompilationUnit.java:174)
        at at.dms.kjc.Main.join(Main.java:376)
        at at.dms.kjc.Main.run(Main.java:160)
        at at.dms.kjc.Main.compile(Main.java:69)
        at at.dms.kjc.Main.main(Main.java:60)

  My diagnosis: kopi is having trouble locating inner classes
  (java.util.Map.Entry) whether they are referred to as:
     import java.util.Map;
     Map.Entry x = ...
   or as
     java.util.Map.Entry x = ....

  Also Kopi has trouble with "raw types" called for in JSR-14, such as
  in the following class (this is the first error message above):

    private static class PairList<A,B> extends AbstractList
        implements java.io.Serializable {
        private A left;
        private B right;
        PairList(A left, B right) {
            this.left = left; this.right = right;
        }
        public int size() { return 2; }
        public Object get(int index) {
            switch(index) {
            case 0: return this.left;
            case 1: return this.right;
            default: throw new IndexOutOfBoundsException();
            }
        }
        public Object set(int index, Object element) {
            Object prev;
            switch(index) {
            case 0: prev=this.left; this.left=(A)element; return prev;
            case 1: prev=this.right; this.right=(B)element; return prev;
            default: throw new IndexOutOfBoundsException();
            }
        }
    }

SUMMARY:  Kopi has a ways to go before it can match Sun's JSE-14 prototype
compiler or claim to compile all generic code consistent with JSE-14.
I could not get even simple classes like:

public class IteratorEnumerator<E> implements Enumeration<E> {
    private final Iterator<E> i;
    public IteratorEnumerator(Iterator<E> i) { this.i = i; }
    public boolean hasMoreElements() { return i.hasNext(); }
    public E nextElement() { return i.next(); }
}

to compile:
 $ java at.dms.kjc.Main -G --classpath . Util/IteratorEnumerator.java
 Util/IteratorEnumerator.java:15: error:Too much type arguments for type 
"java/util/Enumeration"; required: 0 [JSR 41]
But if you add Sun's latest genericized collections API:
 $ java at.dms.kjc.Main -G --classpath 
~/jsr14_adding_generics-1_2-ea/collect.jar Util/IteratorEnumerator.java
 Util/IteratorEnumerator.java:20: error:Type "java.lang.Object" cannot be 
returned as a "E" [JLS 14.16]
 Util/IteratorEnumerator.java:20: error:Method "nextElement" must return a 
value [JLS 8.4.5]
 $

But it's a good start, and undoubtedly closer to compiling generic java
than gcj is. =)
 --scott

President global action network DC strategic Kojarena Secretary MI6 
planning direct action PLO explosives Sabana Seca jihad cracking SEAL Team 6 
                         ( http://cscott.net/ )