Strange behavior of javac

Max (Weijun) Wang Weijun.Wang at Sun.COM
Wed Sep 24 07:42:26 PDT 2008


Thanks for the suggestion. After some investigation it turns out I was  
not running the correct javac.

$ which javac
/Users/octo/java/bsd-java-build/bin/javac
$ alias javac
-bash: alias: javac: not found
$ javac -version
javac 1.5.0_13
...
$ /Users/octo/java/bsd-java-build/bin/javac -version
javac 1.7.0-internal

This is still quite strange.

Thanks
Max

On Sep 24, 2008, at 9:30 PM, Maurizio Cimadamore wrote:

> Max (Weijun) Wang wrote:
>>> *"Note:   The directory specified by -d  is not automatically  
>>> added to your user class path."
>>
>> I don't mean to use -d for -cp.
>>
>> Please note that I'm not using an installed JDK, but a newly built  
>> jdk (with class files in /classes instead of rt.jar), so $JM/ 
>> classes should be already at the top of bootclasspath.
> Ok, now I got what you mean. Have you tried printing all the search  
> path being used by your javac? You can do that by adding the '- 
> verbose' option. At the very beginning of your output you should  
> have an entry for $JM/classes; if you don't have that entry that  
> means that $JM/classes is not used as a search path for classes (in  
> that case it could be a simple problem due to the way in which javac  
> is launched, e.g. bootclasspath is not specified properly).
>
> Maurizio
>>
>>  $ javap x.A
>>  Compiled from "A.java"
>>  public class x.A extends java.lang.Object {
>>      public x.A();
>>  }
>>
>>  $ javac -d $JM/classes B.java
>>  B.java:1: cannot find symbol
>>  symbol: class A
>>  package x; public class B extends A {}
>>                                  ^
>>  1 error
>>
>> May this is a class loader issue?
>>
>> Max
>>
>> On Sep 24, 2008, at 8:16 PM, Maurizio Cimadamore wrote:
>>
>>> Hi Max
>>> If you read this document:
>>>
>>> http://java.sun.com/javase/6/docs/technotes/tools/solaris/javac.html
>>>
>>> You'll find the following line:*
>>>
>>> *"Note:   The directory specified by -d  is not automatically  
>>> added to your user class path."
>>>
>>> Which seems to suggest that the standard behavior is not to add  
>>> the destination directory to the classpath; as a consequence your  
>>> second compilation must fail, as javac cannot find any class/ 
>>> sources under ./x/
>>>
>>> It seems like your Linux box with the latest openjdk build is not  
>>> behaving as expected - as it ends up in adding the destination  
>>> directory to your classpath. But I might be wrong.
>>>
>>> FYI, under Ubuntu 8.04 your commands fail using both openjdk-6 and  
>>> 1.6.0_06 compilers.
>>>
>>> Jon, any ideas?
>>> Maurizio
>>>
>>> Max (Weijun) Wang wrote:
>>>> Hi All
>>>>
>>>> I just built a bsd-port openjdk, the last of the following  
>>>> commands fails.
>>>>
>>>> cd /tmp
>>>> echo 'package x; public class A {}' > A.java
>>>> javac -d $JM/classes A.java
>>>> echo 'package x; public class B extends A {}' > B.java
>>>> javac -d $JM/classes B.java
>>>>
>>>> B.java:1: cannot find symbol
>>>> symbol: class A
>>>> package x; public class B extends A {}
>>>>                                 ^
>>>> 1 error
>>>>
>>>> (Here $JM is the newly built jdk, javac is the compiler in $JM/bin)
>>>>
>>>> As I understand, the second javac call should be able to load  
>>>> class A from $JM/classes/x/A.class. This is true on my Linux box  
>>>> with the latest openjdk build.
>>>>
>>>> Any ideas?
>>>>
>>>> Thanks
>>>> Max
>>>>
>>>
>>
>




More information about the compiler-dev mailing list