groovy
  1. groovy
  2. GROOVY-2258

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

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Blocker Blocker
    • Resolution: Fixed
    • Affects Version/s: 1.1-rc-2
    • Fix Version/s: 1.1-rc-3
    • Component/s: None
    • Labels:
      None
    • Environment:
      Ubuntu 7.10 Gutsy Gibbon, java version "1.6.0_03", Groovy Head r8979
    • Number of attachments :
      0

      Description

      After a clean compile and install of Groovy and a clean compile and install of Gant then when Gant tries to process a javac Ant task, the following output is generated:

      > gant test
      [groovyc] No sources to compile
      [mkdir] Created dir: /home/Checkouts/Subversion/Gant/gant/trunk/target/test-classes
      [javac] Compiling 1 source file to /home/Checkouts/Subversion/Gant/gant/trunk/target/classes
      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"
      > echo $JAVA_HOME
      /usr/lib/jvm/java-6-sun-1.6.0.03
      >

        Activity

        Hide
        Russel Winder added a comment - - edited

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

        load $

        {tools.jar}

        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.

        Show
        Russel Winder added a comment - - edited As observed by Jochen Theodorou, the thing that is causing the difference is the presence or absence of the line: load $ {tools.jar} 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.
        Hide
        blackdrag blackdrag added a comment -

        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?

        Show
        blackdrag blackdrag added a comment - 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?
        Hide
        Russel Winder added a comment -

        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.

        Show
        Russel Winder added a comment - 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.
        Hide
        blackdrag blackdrag added a comment -

        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 $

        {x?}

        instead of $

        {x}, where the ? indicates that the property might not be set. then we can modify the tools.jar line to "load ${tools.jar?}". an alternative syntax wold be $?{x}

        or simply ?

        {x}. Or we could go the other way and say an error should be thrown if a property does not exist, but assign this a another syntax like !{x}

        and say that $

        {x}

        will handle non existing properties.

        Show
        blackdrag blackdrag added a comment - 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 $ {x?} instead of $ {x}, where the ? indicates that the property might not be set. then we can modify the tools.jar line to "load ${tools.jar?}". an alternative syntax wold be $?{x} or simply ? {x}. Or we could go the other way and say an error should be thrown if a property does not exist, but assign this a another syntax like !{x} and say that $ {x} will handle non existing properties.
        Hide
        blackdrag blackdrag added a comment -

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

        {x} now defines a not required property. If x is not defined, then the whole load instruction for this will be ignored. This means a
        load ${tools.jar}
        

        will be ignored if tools.jar is not set. To get the old version you need to use $!{x}

        , 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.

        Show
        blackdrag blackdrag added a comment - ok, I changed the conf file and the class using that file as config. $ {x} now defines a not required property. If x is not defined, then the whole load instruction for this will be ignored. This means a load ${tools.jar} will be ignored if tools.jar is not set. To get the old version you need to use $!{x} , 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.

          People

          • Assignee:
            blackdrag blackdrag
            Reporter:
            Russel Winder
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: