AntBuilder broken by a RC-1 -> RC-2 change: Can't find compiler

Is this a blocker for gant, or for groovy?

besides that.... is it possible, that the gant script sets a new JAVA_HOME?

I beleive this is a blocker for both Gant and Groovy. I believe this problem has arisen due to a change in Groovy over the last three or four weeks.

Gant does not alter the JAVA_HOME variable:

Of the Ant tasks used in the Gant build, only the Ant.javac task appears to be affected, the Ant.groovyc, Ant.junit tasks appears to work just fine.

hmm.. if I see it right, the gant script starts the startGroovy script, which means the error should be there. There I find only this suspicious part:

# Attempt to set JAVA_HOME if it's not already set.
if [ -z "$JAVA_HOME" ] ; then
    if $darwin ; then 
        [ -z "$JAVA_HOME" -a -d "/Library/Java/Home" ] && export JAVA_HOME="/Library/Java/Home"
        [ -z "$JAVA_HOME" -a -d "/System/Library/Frameworks/JavaVM.framework/Home" ] && export JAVA_HOME="/System/Library/Frameworks/JavaVM.framework/Home"
    else
        javaExecutable="`which javac`"
        [ -z "$javaExecutable" -o "`expr \"$javaExecutable\" : '\([^ ]*\)'`" = "no" ] && die "JAVA_HOME not set and cannot find javac to deduce location, please set JAVA_HOME."
        # readlink(1) is not available as standard on Solaris 10.
        readLink=`which readlink`
        [ `expr "$readLink" : '\([^ ]*\)'` = "no" ] && die "JAVA_HOME not set and readlink not available, please set JAVA_HOME."
        javaExecutable="`readlink -f \"$javaExecutable\"`"
        javaHome="`dirname \"$javaExecutable\"`"
        javaHome=`expr "$javaHome" : '\(.*\)/bin'`
        export JAVA_HOME="$javaHome"
    fi
fi

but If I recall correctly, then [ -z "$JAVA_HOME" ] ; is used to est for an unset variable (or zero length), which means that JAVA_HOME was not set before. Could you in your example give the output to the following program?

which javac
echo $JAVA_HOME
gant test
echo $JAVA_HOME

because I expect now, that JAVA_HOME was first not set and is then set by the startGroovy script, but to the wrong location, because.. well because I think that "which javac" finds the the jre instead of the jdk. If that is correct, then setting PATH differently would help, as well as setting JAVA_HOME before.

The problem here is that I have a JAVA_HOME set so none of the above code should get executed.

executing the Gant script with -x, I see that:

exec /usr/lib/jvm/java-6-sun-1.6.0.03/bin/java -classpath /home/users/russel/lib/Java/groovy/lib/groovy-1.1-rc-2-SNAPSHOT.jar -Dprogram.name=gant -Dgroovy.starter.conf=/home/users/russel/lib/Java/groovy/conf/groovy-starter.conf -Dgroovy.home=/home/users/russel/lib/Java/groovy -Dtools.jar=/usr/lib/jvm/java-6-sun-1.6.0.03/lib/tools.jar org.codehaus.groovy.tools.GroovyStarter --main gant.Gant --conf /home/users/russel/lib/Java/groovy/conf/groovy-starter.conf --classpath .

all of which seems entirely fine.

Thre string jre doesn't appear in the Gant source. In the Groovy source it appears in src/main/org/codehaus/groovy/tools/javac/JavacJavaCompiler.java and src/bin/startGroovy

I would be surprised if it was an Ant issue, I have been using 1.7.0 for many moons.

it might be right that you are using ant 1.7.0 for a long time now, but as you can see groovy is not setting a different JAVA_HOME here. So it might be the combination that causes a problem. Looking at the code of AntBuilder I can't find anything that could cause this problem. That leaves it to the javac task.

I suspect we must continue to doubt Groovy and that the change is a thing that has happened in Groovy.

I assume AntBuilder does not fork Ant jobs but loads the Ant jars and calls the appropriate methods. This would mean that the environment variables are not an issue, that the problem is a classpath and class loaders issues. So what can have changed in Groovy that means that tools.jar is not on the classpath for AntBuilder?

OK, this is definitely not a Gant problem The script:

new AntBuilder ( ).javac ( srcdir : '.' , destdir : '/tmp' )

causes the result:

> groovy AntBuilderProblem.groovy
[javac] Compiling 17 source files to /tmp
Caught: : Unable to find a javac compiler;
com.sun.tools.javac.Main is not on the classpath.
Perhaps JAVA_HOME does not point to the JDK.
It is currently set to "/usr/lib/jvm/java-6-sun-1.6.0.03/jre"
at AntBuilderProblem.run(AntBuilderProblem.groovy:1)
at AntBuilderProblem.main(AntBuilderProblem.groovy)

OK, I have doen the experiment: I downloaded Groovy RC-1 and used that and everything is fine. Groovy RC-2 and Subversion head have the problem. This is definitely not a Gant or Ant problem per se since they were not changed. Thus something has changed between RC-1 and RC-2 which means that in effect Groovy is broken.

I think the AntBuilder code acts as a test. I will turn this into a Groovy unit test and add it in. This will of course mean that the Groovy tests will break.

new AntBuilder ( ).javac ( srcdir : '.' , destdir : '/tmp' )

the change I can think of is that the tools.jar is no longer loaded by default through Groovy. And I guess since it is not loaded through Groovy, ant tries to find it by itself and does that wrong. I still really suspect that ant is doing something wrong here. adding tools.jar would be a workaround that you could try. If it works then, then I really think it is the fault of Ant, if not, then it is something inside Groovy I guess... something I have no ideas of what it could be.

As observed by Jochen Theodorou, the thing that is causing the difference is the presence or absence of the line:

load $

in $GROOVY_HOME/conf/groovy-starter.conf. With the line AntBuilder works fine but Mac OS X won't work because Apple have merged rt.jar and tools.jar into a single classes.jar in the Mac OS X version of Java (for some incomprehensible reason). Without the line, Mac OS X is fine but AntBuilder now has a serious problem, it fails to fins any class in tools.jar.

We therefore have a dilema, Groovy is either broken on Mac OS X or has a broken AntBuilder.

I took a look at the ant source and found this line:

    private static final String JAVA_HOME = System.getProperty("java.home");

which makes me ask myself who is setting this property... running a java program on my windows machine this shows me: "C:\Programme\JavaSoft\sdk\jre" and then it is no wonder it gets a problem, because that is the JRE and not the JDK part. I confirmed this with my linux machine.. it is pointing to "/usr/lib/j2sdk1.5-sun/jre" there and that differs from my JAVA_HOME which is set to "/usr/lib/j2sdk1.5-sun"

I must say I think the ANT message is extremly misleading, because even though it is speaking of JAVA_HOME, it means the property java.home and that property is set by the VM to the JRE and not the JDK. No wonder Ant will not find the javac binary, because in that directory and its subdirectories, there is no javac command. So in my eyes ant is broken here. I guess when running ant from the command line, something in ant-utils or such will correct the path.

The question is now how we react to this. I mean it is clear, that the javac class won't be found, if it is not on the classpath, which will happen if we don't include the tools.jar. Or should the user have to do that? Russel, what do you suggest?

Jochen, well spotted!

println ( System.properties.'java.home' )

prints the path to the JRE for me as well. This is of course not surprising and exactly as it should be since this is the path to the JVM, not to the JDK.

I think it is clear that the Ant error message is completely misleading. I have added a bug report in the Ant Bugzilla (43794).

I think we have to find out what Ant does internally to allow the javac task to run, so that we know how Ant gets round this problem. Currently I am assuing they define their own class loader and it looks in all the right places, including tools.jar on all systems other than Mac OS X.

I think that maybe Groovy should check to see if it is running from a JRE or from a JDK with embedded JRE, and in the latter case add tools.jar to the classpath. This then ensures people running only on a JRE can run Groovy (but at the expense of not being able to do some things such as run the Ant javac task) whilst people using a JDK get everything and no surprises. This also gets round the Mac OS X problem since classes.jar is already on the classpath.

As said on the list, the solution seems to be for me to use a slightly different property syntax in the conf file. for example $

instead of $

or simply ?

and say that $

will handle non existing properties.

ok, I changed the conf file and the class using that file as config. $

load ${tools.jar}

, which will then throw an error. This should fix the problem since with this the tools.jar will be on the classpath per default again and then ANT should be able to find the javac class again and does not try to find the external javac compiler, which seems not to work in many configurations.

so I close this as fixed for now. Would be nice of you to test it and see if it is really fixed Russel.