--- javac process is failing ---

 Compilation of valid Java code is failing with Mustang RE bld env, (JPRT)
 but not in other environments.  This failure is on valid Java code and
 the failure is always at the same location.


 ./../../src/share/classes/com/sun/xml/bind/v2/model/impl/ClassInfoImpl.java:1077: can
not find symbol
 symbol  : class T
 location: class com.sun.xml.bind.v2.model.impl.ClassInfoImpl<T,C,F,M>
        for( ClassInfoImpl<T,C,F,M> c=getBaseClass(); c!=null; c=c.getBaseClass() )
                           ^
 ./../../src/share/classes/com/sun/xml/bind/v2/model/impl/ClassInfoImpl.java:1106: can
not find symbol
 symbol  : class T
 location: class com.sun.xml.bind.v2.model.impl.ClassInfoImpl<T,C,F,M>
        for( PropertyInfoImpl<T,C,F,M> p : properties ) {
                              ^
 ./../../src/share/classes/com/sun/xml/bind/v2/model/impl/ClassInfoImpl.java:1134: can
not find symbol
 symbol  : class T
 location: class com.sun.xml.bind.v2.model.impl.ClassInfoImpl<T,C,F,M>
        T fClass = reader().getClassValue(t, "factoryClass");
        ^


--------------------------------------------------------
>> Kelly O'Hair

The failure can be reproduced on any Linux or Solaris system with:

   mkdir /tmp/junk
   cd /tmp/junk
   cp ~ohair/zipper.j2se.zip .
   unzip -q zipper.j2se.zip
   rm zipper.j2se.zip
   cd make
   gnumake


I'm suspecting that the javac process is running out of thread stack space,
or resources, or memory???  But the first error seen appears to complain
about the source for class com.sun.xml.bind.v2.model.impl.ClassInfoImpl.

If you do a second 'gnumake' after the first one fails, it will likely
succeed, perhaps because fewer classes are being compiled the second
time around???



--------------------------------------------------------
>> Jonathan Gibbons

Kelly notes that "the first error seen appears to complain about the source for class
com.sun.xml.bind.v2.model.impl.ClassInfoImpl." and I note that this class is in rt.jar
.

As such, I'm thinking you are somehow being tripped up by the new javac feature that
prevents access to undocumented com.sun internal classes in rt.jar. This is a recent
feature intented to protect us from Joe Public creating dependencies on our internal
classes.


--------------------------------------------------------
>> Kelly O'Hair

If this new feature causes failures like we are seeing, then something is
wrong with it. This build failure doesn't happen all the time, which
would mean that this new feature isn't predictable, making it somewhat
unreliable for building.

Is it possible that there are race conditions in javac, and the classes
are generated in somewhat unpredictable order? The same classes it's
checking against?



--------------------------------------------------------
>> Jonathan Gibbons

Kelly,

The guess may be off base because this seems to be occurring while
building J2SE -- i.e. before ct.sym is created.

I'm running the commands you suggested.  I got what was maybe the issue
you saw, although I maybe misread/misunderstood your message at first.
I'm seeing compilation errors relating to one of the generic type
parameters (T) of the class, as in this example