RE: registry JRE vs. JDK with java task

[Diane Holt <ho...@yahoo.com>]

--- Conor MacNeill <co...@m64.com> wrote:
> Just to clarify. Ant requires JAVA_HOME to be set so that it can find
> tools.jar which contains the javac compiler. So while the JDK may no
> longer require it, it still needs to be set if you are using Javac in
> ant.

Unless you've hand-tweaked your Javac.java file to have addRunTime be
false :)  BTW: Any chance at all of ever having that added as an attribute
to <javac>, so I don't have to have a modified version of the source-file?
As a bargaining chip (albeit, probably not a huge one), I've also added
the Vcafe25 compiler (sj) as one that <javac> now understands, so if
anyone else is actually using that compiler and would be interested in
seeing it incorporated into the cvs source-file, maybe I can get both my
changes patched in and go back to at least being able to get that
source-file off-the-rack?

No biggee if the answer's no, since I'd still have two other modified
source-files, which I know will *never* be allowed to be patched in, since
one of them gets rid of the extra line of space in the logging output, and
the other one allows for a test-for-equality on if/unless (oh no, not that
again! :) -- just figured it couldn't hurt to ask, since one less file to
diddle is better than none less :)

Thanks,
Diane

=====
(holtdl@yahoo.com)



__________________________________________________
Do You Yahoo!?
Yahoo! Shopping - Thousands of Stores. Millions of Products.
http://shopping.yahoo.com/

Re: registry JRE vs. JDK with java task

[Stefan Bodewig <bo...@apache.org>]

Michael Krammer <kr...@spotfire.com> wrote:

> I think that a reasonable behaviour would be to skip the runtime
> system classpath and the paths defined in the "java.ext.dirs" system
> property if you specify a bootclasspath attribute.

I'd really prefer something like

addruntime=true|false   default true

This controls whether rt.jar or classes.zip will be added to the
classpath. This is usually necessary if you want to compile using
jikes and your target Java version is the same as the one that's
currently running Ant (usually true when using jikes I guess).

This is what Diane has done for her version AFAIK.

addcurrentclasspath=true|false   default true

(better name appreciated)

This controls whether the CLASSPATH used to run Ant will be passed to
the compiler. We could also make that control whether java.ext.dirs
will be consulted or not (although we might want to have a third
attribute, I'm not sure).

Usually you want this to be true, but I sometimes you want to have the
full control over the CLASSPATH javac uses, like

*) you are compiling for a Java version other than the one you are
using to run Ant (tools.jar would be on the CLASSPATH in JDK 1.2 for
example).

*) You are compiling classes that need a different version of classes
that are also used by Ant. An example would be compiling xerces where
you need DOM2 classes but you have the DOM1 classes from JAXP 1.0 on
your classpath.

Stefan

Re: registry JRE vs. JDK with java task

[Michael Krammer <kr...@spotfire.com>]

On 22 Nov 2000, Stefan Bodewig wrote:

> Add another option to not add Path.systemClasspath as well and I'll
> commit them (unless anybody else objects).

<lurking mode off>

I've had problems with the way that the Javac task handles the classpath
for Jikes. I'm running Ant 1.2 with Java 2 SDK 1.2.2, but compiling for a
JDK 1.1 target JVM (the product is an applet). I think it should be
possible to specify bootclasspath and extdirs attributes to make it work.
However, in addition to these parameters, Ant adds the runtime system
classpath as well as the runtime value of the "java.ext.dirs" system
property.

With this build target I get the classpath argument for jikes listed
below:

<property name="build.compiler" value="jikes"/>
<javac srcdir="D:\Project\src"
       bootclasspath="D:\Project\lib\classes.zip">
  <classpath>
    <pathelement location="D:\Project\lib\junit.jar"/>
  </classpath>
</javac>

D:\Project\lib\classes.zip;
D:\Programs\jre1.2.2\lib\ext\iiimp.jar;
D:\Project\lib\junit.jar;
D:\Project\src;
D:\Programs\Ant-1.2\lib\ant.jar;
D:\Programs\Ant-1.2\lib\jaxp.jar;
D:\Programs\Ant-1.2\lib\parser.jar;
D:\Programs\jdk1.2.2\lib\tools.jar;
D:\Programs\jre1.2.2\lib\rt.jar

What I do want is a classpath containing only these elements:

D:\Projects\t2\lib\classes.zip;
D:\Projects\t2\lib\junit.jar;
D:\Projects\t2\src\product;

I think that a reasonable behaviour would be to skip the runtime system
classpath and the paths defined in the "java.ext.dirs" system property if
you specify a bootclasspath attribute. Specifying a bootclasspath but no
extdirs attribute would result in an empty extdirs path. If you specify
just an extdirs attribute (but no bootclasspath), it gets added to the
list of default extdirs read from the "java.ext.dirs" property. If you
don't specify any of the bootclasspath or extdirs attributes, the current
behaviour seems appropriate.

This is the way my own hacked Javac task works right now.

What do you think?

- Michael

----------------------------------------------------------------------
Michael Krammer           ***  Stop the continental drift NOW!  ***
email: krammer@spotfire.com     web: http://www.spotfire.com
Spotfire AB, Första Långgatan 26, SE-413 28 Göteborg, Sweden

Re: registry JRE vs. JDK with java task

[Stefan Bodewig <bo...@apache.org>]

Diane Holt <ho...@yahoo.com> wrote:

> Unless you've hand-tweaked your Javac.java file to have addRunTime
> be false :) BTW: Any chance at all of ever having that added as an
> attribute to <javac>, so I don't have to have a modified version of
> the source-file?  As a bargaining chip (albeit, probably not a huge
> one), I've also added the Vcafe25 compiler (sj) as one that <javac>
> now understands, so if anyone else is actually using that compiler
> and would be interested in seeing it incorporated into the cvs
> source-file, maybe I can get both my changes patched in and go back
> to at least being able to get that source-file off-the-rack?

Add another option to not add Path.systemClasspath as well and I'll
commit them (unless anybody else objects).

Stefan