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