Bob Lang <email@hidden> wrote:
>> Let's enter the Terminal command: alias javac "/usr/bin/javac
>> -encoding"
>>
>> Now, entering "javac ProgramFile.java" gives EXACTLY the same symptoms
>> that Brandon is getting.
Only one of the symptoms, not all of them.
>Sorry, the alias command should have been: alias javac "/usr/bin/javac
>-sourcepath"
>
>As far as I can tell, this replicates the original problem. I also
>think that replacing -sourcepath by -classpath has the same effect.
If you make those aliases, the reason for failure is that the 'javac'
command is doing exactly what it should do. Each of those options (among
others) takes a following option-specific parameter, which is not a source
file.
So with this alias:
alias javac "/usr/bin/javac -sourcepath"
the following command:
javac abc.java
expands to this:
/usr/bin/javac -sourcepath abc.java
The problem with this command-line is that the -sourcepath option takes a
following parameter that is a sourcepath. If abc.java is being taken as a
sourcepath, then javac has been invoked with no source files. Similar
analysis applies to -encoding and -classpath, resulting in a vacuous or
malformed command.
There are many ways that the command line:
javac abc.java
can be turned into a malformed command line. You've given several possible
ways that 'javac' COULD be malformed or misinterpreted, but it's not at all
clear that it IS the cause of the problem.
Although you've successfully replicated one symptom with your example
aliases, they don't replicate all symptoms. For example, I don't think
your aliases would produce the additional symptom that this command sorta
works:
javac -verbose F77ToF90.java
although it fails to compile for a different reason:
inability to locate MultiFile.class.
>So, if there's a spurious alias somewhere, Brandon's problem is
>explained; hence my suggestion to check out the shell startup files and
>Terminal settings.
Or simply type this command to list all shell aliases, spurious or intentional:
alias
Once you know there's an alias for javac, you can track it down in the
shell startup files. What none of us knows, though, is which 'javac' the
original poster's javac command line is actually referring to.
If it's referring to /usr/bin/javac, and that is a proper symlink, then the
problem probably lies in the Java installation. Otherwise it could be
almost anything.
If 'javac' is being aliased by the shell, the 'alias' command will list the
aliases.
If 'javac' is referring to another command than /usr/bin/javac, the 'which'
command will tell you which one:
which javac
To find out if it's the right kind of file:
file `which javac`
I'm pretty sure the original poster either has aliases defined or has a
non-standard command environment. I infer this from the use of the 'dir'
command, which appears to be equivalent to 'ls -l', but I'm just guessing.
For reference, find 'dir' on the original post, near the heading "Example
of compile problem":
<http://lists.apple.com/archives/java-dev/2005/Apr/msg00086.html>
I also suspect something odd with permissions, since I don't understand why
Java source or class files should have the x bit set on them. This may be
insignificant, e.g. a side-effect of a file-server or simply what the user
applied to the files, but it's definitely peculiar. Peculiar things may be
clues.
Speaking of peculiar, the original post asserts that MultiFile.java was not
recompiled in the example, yet the time-stamp on MultiFile.class clearly
shows a change. So I'm a little confused about exactly what the user is
doing or expecting. Especially without knowing exactly what 'javac' or
'dir' is referring to.
On the whole, I think a mis-installed Java framework is the most plausible
cause of the problem.
My second guess would be a malformed command environment (use the 'alias'
and 'which' commands to investigate this). However, malformed aliases etc.
would not explain why FileDialog suddenly doesn't work, so there's more
afoot than bad aliases.
It'd be a little easier to decipher 'javac' problems with a very simple class:
file Nothing.java:
public class Nothing
{ }
This can then be expanded to investigate other problems, but if this simple
thing doesn't compile, there's no point in going further until the
fundamental compiling problem is solved. Once it does compile properly,
more code can be easily added, to produce other specific problems in the
simplest way possible.
-- GG
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Java-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/java-dev/email@hidden
This email sent to email@hidden
