United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-6449122 : javac process is failing on Mustang integration compile

Details
Type:
Bug
Submit Date:
2006-07-14
Status:
Resolved
Updated Date:
2010-08-06
Project Name:
JDK
Resolved Date:
2006-08-18
Component:
tools
OS:
generic
Sub-Component:
javac
CPU:
generic
Priority:
P2
Resolution:
Fixed
Affected Versions:
6
Fixed Versions:

Related Reports
Duplicate:
Relates:
Relates:
Relates:

Sub Tasks

Description
--- 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

                                    

Comments
EVALUATION

The problem is intermittent because it depends on the hashCode
of names used in the compiler.  The initial size of scopes and
the hashCode both play together to trigger this problem.
                                     
2006-08-15
EVALUATION

A short-term solution is to not call Scope.dble from Scope.enter.
This short-term solution will be used until a better solution can
be implemented (see 6460352).
                                     
2006-08-15
WORK AROUND

Reverse the order of files given on the command line.
                                     
2006-08-13
EVALUATION

I can consistently reproduce the problem using b85-b90.  However,
I'm not able to reproduce the problem with b91.

I assume this is related to 6437894 and, unless I hear to the contrary,
consider this issue closed.
                                     
2006-07-19



Hardware and Software, Engineered to Work Together