Bug 34138 - Ant should use other compilers when Sun's Javac can not be found
Summary: Ant should use other compilers when Sun's Javac can not be found
Status: NEW
Alias: None
Product: Ant
Classification: Unclassified
Component: Core tasks (show other bugs)
Version: 1.7.0
Hardware: Other other
: P2 enhancement with 1 vote (vote)
Target Milestone: ---
Assignee: Ant Notifications List
Depends on:
Reported: 2005-03-22 22:08 UTC by Dalibor Topic
Modified: 2008-11-24 03:58 UTC (History)
0 users


Note You need to log in before you can comment on or make changes to this bug.
Description Dalibor Topic 2005-03-22 22:08:14 UTC
Hi all,

Ant gives an error message out of the box when its javac task is used, no
build.compiler is set and the runtime environment doesn't have a com.sun Javac
entry point.

That leads to people using such runtime enviroments patching build.xml files,
setting build.compiler in patched Ant shell scripts, and even writing their own
com.sun Javac wrappers (java-gcj-wrapper) and setting build.compiler to a known
good value in the VM itself (me in Kaffe a few days ago to make Tomcat4's
pristine tarball work unpatched on Kaffe from CVS head. The JSPs didn't compile
because of no Javac being found by Ant).

Before I propose a solution, is there some specific way of dealing with this
that's 'blessed' by Ant developers, beside 'Run Sun!' ? ;)

Otherwise, I'd suggest a 'test for Javac and jikes and gcj and  kjc and an
external javac in java.home' before you abort' approach.

dalibor topic
Comment 1 Steve Loughran 2005-03-23 11:22:07 UTC
well, there is the environment variable ANT_OPTS that is options to the JVM; set


and every build uses kaffe. Is there some reason why this is inadequate?

I am also thinking of having a well-known properties file that is read in
*after* all command line stuff, something like
${user.hom}/.ant/common.properties  ..things like compiler setting, or, more
importantly to me, proxy settings, could go in there.
Comment 2 Stefan Bodewig 2005-03-24 11:48:48 UTC
Test for JavaEnvUtils.getJDKExecutable("javac") would work, for JVMs that come
with an executable named javac.  But if we used that, we'd also assume that it
was command line compatible with Sun's.

Testing for jikes or gcj is more difficult, you'd have to code up OS specific
diagnostics to know the difference between "command not found" and "compilation
error".  Well, we could search for the executable in PATH (the functionality is
already there in ExecTask#resolveExecutable.

But what should be the order of preference?  Personally I'd prefer jikes over
kjc, that much ist sure.  Steve might even prefer jikes over Sun's javac 8-)

It would be rather easy to say we use gcj if we detect we are running in libgcj.
Or jvc when running in Microsoft's VM.

What would be the best fit if we know Ant is running in Kaffe?
Comment 3 Steve Loughran 2005-03-24 14:36:29 UTC
I dont think we should try and be clever and automatically do the right thing,
as that can generate bad support calls. Example: javac & jikes pull in classes
to compile on demand, kjc doesnt. If I write a build file that relys on this, it
will fail on kjc machines; the author of the build file gets a non-replicable
support call. But if the runner of the failing build file had to set some switch
to use kjc, they should know that and provide the info, maybe even a fix.

Better to make it easier for anyone to override the compiler, even if the author
of the build file neglected any way to make this easy.

And yes, jikes is my compiler of choice, 'cept for fancy Java1.5 stuff, and as
soon as jikes does templates, I move back there too.
Comment 4 Dalibor Topic 2005-03-24 19:58:52 UTC
thanks for the good, fast, catch steve! I had (conveniently :) forgotten about
the greedy/non-greedy compiler issues, that would crop up. :(

Of course, there is another (enhancement-grade) fix: let's make the Depend task
compute the dependencies that need to be rebuilt, and pass them to the compiler.

On the other hand, different versions of compilers may have different dependency
resolution algorithms (I believe I recall Jikes switched around a bit in the
early years), and that could lead to non-replicable support calls as well, if
the 'ant computed' and 'my compiler does this' dependency graphs don't match :(

So, I am still a bit uncertain how to make ant work well out of the box in the
'best' way, without causing you headache with moving entry points and similar
nonsense. Is the 'pre-set build.compiler' approach reasonable? In particular as
Kaffe is likely to switch compilers around some more in the future (possibly
back to kjc for generics, and then possibly to gcjx for more generics, and
better gcj integration).

dalibor topic
Comment 5 Steve Loughran 2005-03-24 23:36:25 UTC
TO be honest, we dont get any complaints about kaffe's non greediness, except at
bootstrap time, because we the shell scripts that boot ant arent kaffe-friendly.
you cant boot ant with kaffe, and its not something anyone is (currently)
motivated to fix.

We get a lot more complains about "ant compiled files I excluded", "javac
filesets broken", etc, etc, with compilers pulling in files that are needed, but
explicitly excluded. IMO, forced inclusion might actually be a good thing all
round, as it stops you accidentally importing app.view.* into app.model.* and so
break layering rules. 

I guess tomcat is a special issue, because it uses ant for javac, but isnt your
normal build file. other things may be similar (eg Axis).

This leads me to another thought. Could we have a new compiler adapter
"best-effort" that does the right thing, perhaps with an ordered list of
preferred tools: apt,modern javac, classic javac, jikes, kjc, ... ). So if
tomcat and axis ask for the  best-effort compiler they get whatever is around,
not just classic javac.

So we would be putting the smartness into ant, but hiding it in a compiler
adapter that could be switched in or out.
Comment 6 Thomas Fitzsimmons 2005-04-29 20:45:36 UTC
I satisfied Ant's requirements in java-gcj-compat by using the Eclipse Compiler
for Java (which is very similar in behaviour to Sun's javac) and creating a
tools.jar that contains a com.sun.tools.javac.Main wrapper around ecj. 
Unfortunately this class is not publicly-specified, so it's not really
appropriate for inclusion in free runtimes.

Long term, I'd like to see all free runtimes agree on a standard package for
in-process tools instantiation.  For example, in GNU Classpath we could create a
gnu.tools package and have all free runtime installations agree to implement
that.  Included in the specification of gnu.tools would be the behavior
charateristics that Ant expects of a Java compiler.

In the short term this would be one extra code path in ant's decision making
process.  In the long term, I would hope that all free compilers aspire to match
the capabilities of Sun's javac, and in doing so eliminate the behavioral
differences that Ant currently has to negotiate.