Fwd: clean build doesn't generate package private class

Doug Felt dougfelt at google.com
Fri Mar 6 17:33:52 UTC 2009


Thanks.  That's essentially what I did, and it worked.

The only other difference is I didn't override the default environment
compiler info on the make line.

Since it is working for me now, I'm going to continue with my main task and
not explore this further at the moment.  Sometime next week I should have
time to see if I can recreate this problem.

Doug

On Fri, Mar 6, 2009 at 3:54 AM, Christopher Hegarty - Sun Microsystems
Ireland <Christopher.Hegarty at sun.com> wrote:

> Hi Doug,
>
> This is very strange. I just synced with the latest JDK7 source from TL and
> did a clean build, everything went fine, I have a Parts.class
>
> As you said, this is a clean build, right? Not a incremental.
>
> Running a few tests with javac I can see that if you compile URL.java then
> you will always compile Parts, even if the compile of URL.java has been
> triggered implicitly by a reference from another class ( and this is
> typically the case when building the JDK ).
>
> The only thing I can suggest is to resync the repository and try a full
> clean build. Failing that cd  jdk/make/java/net, make clobber, make all.
> That will rebuild URL.java which will produce Parts.class.
>
> -Chris.
>
>
> On 03/05/09 17:16, Doug Felt wrote:
>
>> resend, bounced the first time
>>
>> ---------- Forwarded message ----------
>> From: Doug Felt <dougfelt at google.com>
>> Date: Tue, Mar 3, 2009 at 1:52 PM
>> Subject: clean build doesn't generate package private class
>> To: build-dev at openjdk.java.net
>>
>>
>> I recently fetched jdk7 (after not having done so for a few months) and
>> did
>> a clean rebuild, and the VM is failing to start.  I'm building on Ubuntu
>> (2.6.27-11-generic) on i586.  Sanity passes.
>>
>> make all CC=gcc-4.1 CPP=g++-4.1
>>
>> On startup I get the following stack trace:
>>
>> Error occurred during initialization of VM
>> java.lang.NoClassDefFoundError: java/net/Parts
>>    at java.net.URL.<init>(URL.java:396)
>>    at java.net.URL.<init>(URL.java:300)
>>    at java.net.URL.<init>(URL.java:323)
>>    at sun.net.www.ParseUtil.fileToEncodedURL(ParseUtil.java:272)
>>    at sun.misc.Launcher.getFileURL(Launcher.java:442)
>>    at sun.misc.Launcher$ExtClassLoader.getExtURLs(Launcher.java:190)
>>    at sun.misc.Launcher$ExtClassLoader.<init>(Launcher.java:161)
>>    at sun.misc.Launcher$ExtClassLoader$1.run(Launcher.java:145)
>>    at sun.misc.Launcher$ExtClassLoader$1.run(Launcher.java:139)
>>    at java.security.AccessController.doPrivileged(Native Method)
>>    at
>> sun.misc.Launcher$ExtClassLoader.getExtClassLoader(Launcher.java:138)
>>    at sun.misc.Launcher.<init>(Launcher.java:71)
>>    at sun.misc.Launcher.<clinit>(Launcher.java:59)
>>    at java.lang.ClassLoader.initSystemClassLoader(ClassLoader.java:1325)
>>    at java.lang.ClassLoader.getSystemClassLoader(ClassLoader.java:1307)
>>
>> Looking in the classes directory, I see that although URL.class is
>> present,
>> Parts.class is not.  Parts.class is a package private class defined at the
>> top level in the same source file as URL.java.
>>
>> Does anyone recognize this problem?  How do I work around this?  Do I need
>> a
>> new bootstrap build, or different compiler options?
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/build-dev/attachments/20090306/bcbf0738/attachment.html>


More information about the build-dev mailing list