Standard extensions masked by ant?

[Sean Kelly <ke...@ad1440.net>]

Hi folks:

I'm using Java 1.3 with Ant 1.2.

I'm building some software that uses the Java COMM API, javax.comm.
I've installed Sun's COMM API in the standard extension directory by
putting comm.jar in $JAVA_HOME/jre/lib/ext and verified that it's
there and being referenced:

% mv $JAVA_HOME/jre/lib/ext/comm.{jar,off}
% javap javax.comm.SerialPort
Class 'javax.comm.SerialPort' not found
% mv $JAVA_HOME/jre/lib/ext/comm.{off,jar}
% javap javax.comm.SerialPort
Compiled from SerialPort.java
public abstract class javax.comm.SerialPort extends javax.comm.CommPort {
...

I can hand-compile a file that uses this class OK:

% javac Serial1WireLineDriver.java
% rm Serial1WireLineDriver.class

But with ant, no:

% cat build.xml
<?xml version="1.0" encoding="UTF-8"?>
<project name="jbuttons" default="compile" basedir=".">
  <target name="compile">
    <javac srcdir="."/>
  </target>
</project>
% ant
...
    [javac] symbol  : class SerialPort
    [javac] location: pacakge comm
...

Adding the extdirs attribute to the javac tag and pointing it to
$JAVA_HOME/jre/lib/ext doesn't help.  But explicitly listing comm.jar
in the classpath attribute does work.

Why are standard extensions "suppressed" in this way?  I checked the
FAQ and gave a cursory search of the user archives and didn't find
answer.

Thanks.
--Sean

--
Sean Kelly
Independent Consultant
Java / XML / Etc.

Re: Standard extensions masked by ant?

[James Duncan Davidson <du...@x180.net>]

On 12/9/00 2:42 PM, "Sean Kelly" <ke...@ad1440.net> wrote:

> Why are standard extensions "suppressed" in this way?  I checked the
> FAQ and gave a cursory search of the user archives and didn't find
> answer.

Under JDk 1.2 -- there's no reason they should be masked as items in the
/lib/ext directory are essentially on the bootclasspath and come ahead of
any user defined classpath entries unless you are using some pretty funky
options -- or are using tools that aren't Java based and don't know about
the lib/ext concept.

.duncan

-- 
James Duncan Davidson                                        duncan@x180.net
                                                                  !try; do()

Re: Standard extensions masked by ant?

[Sean Kelly <ke...@ad1440.net>]

> Extdirs is a compiler specific thing (Looks like you are using jikes).

No, the javac that comes with J2SE 1.3.

> Some compilers completely ignore it while others use it.

It must be the way that Ant invokes the compiler through the
sun.tools.compiler interface.  There must be some other setup that
happens that allows standard extensions to be visible when running
javac directly.  I just can't figure out what it might be.

> I would *highly* suggest that you do not use ext at all. Most people
> who use it end up going through the java equivelent of
> dll-hell. Just place the library in a well known place and link to
> it. It will make it a lot easier overtime.

You mean don't use the standard extensions feature of Java?  That
means managing a long classpath either in my build.xml files or in my
environment.  Blech.

Still, thanks for your help.
--Sean

Re: Standard extensions masked by ant?

[Peter Donald <do...@apache.org>]

At 02:42  9/12/00 -0800, Sean Kelly wrote:
>% cat build.xml
><?xml version="1.0" encoding="UTF-8"?>
><project name="jbuttons" default="compile" basedir=".">
>  <target name="compile">
>    <javac srcdir="."/>
>  </target>
></project>
>% ant
>...
>    [javac] symbol  : class SerialPort
>    [javac] location: pacakge comm
>...
>
>Adding the extdirs attribute to the javac tag and pointing it to
>$JAVA_HOME/jre/lib/ext doesn't help.  But explicitly listing comm.jar
>in the classpath attribute does work.
>
>Why are standard extensions "suppressed" in this way?  I checked the
>FAQ and gave a cursory search of the user archives and didn't find
>answer.

Extdirs is a compiler specific thing (Looks like you are using jikes). Some
compilers completely ignore it while others use it. I would *highly*
suggest that you do not use ext at all. Most people who use it end up going
through the java equivelent of dll-hell. Just place the library in a well
known place and link to it. It will make it a lot easier overtime.

Cheers,

Pete

*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof."                   |
|              - John Kenneth Galbraith               |
*-----------------------------------------------------*