Derby
  1. Derby
  2. DERBY-5469

Make it possible to build Derby if you are on Mac OS X and your JDK is JDK 7

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 10.9.1.0
    • Component/s: Build tools
    • Labels:
      None
    1. derby-5469-01-ae-add17andJavadoc.diff
      28 kB
      Rick Hillegas
    2. derby-5469-01-af-dontSetUprevVariables.diff
      33 kB
      Rick Hillegas
    3. derby-5469-01-ag-cleanedUp.diff
      36 kB
      Rick Hillegas
    4. derby-5469-01-ah-cleanedUp.diff
      36 kB
      Rick Hillegas

      Issue Links

        Activity

        Hide
        Rick Hillegas added a comment -

        Since the build now works on the Mac OS X preview for JDK 7, I am resolving this issue.

        Show
        Rick Hillegas added a comment - Since the build now works on the Mac OS X preview for JDK 7, I am resolving this issue.
        Hide
        Rick Hillegas added a comment -

        Attaching derby-5469-01-ah-cleanedUp.diff. This adds java17compileclasspath to the class header comment. Otherwise this is identical to the previous patch. Since the patch seems to work in many environments (thanks for the testing, everyone), I have committed it at subversion revision 1189174.

        I intend to open a new issue to simplify PropertySetter. I believe that work will make further wordsmithing of this patch unnecessary.

        Show
        Rick Hillegas added a comment - Attaching derby-5469-01-ah-cleanedUp.diff. This adds java17compileclasspath to the class header comment. Otherwise this is identical to the previous patch. Since the patch seems to work in many environments (thanks for the testing, everyone), I have committed it at subversion revision 1189174. I intend to open a new issue to simplify PropertySetter. I believe that work will make further wordsmithing of this patch unnecessary.
        Hide
        Knut Anders Hatlen added a comment -

        I got a chance to test the build time with JDK 6 vs JDK 7 on Ubuntu too, and in my experiments there was a significant difference: 5 min 20 sec vs 8 min 50 sec when I ran "ant -q all". If I modified all the build.xml files and specified source and target level 1.5 (or 1.6 or 1.7) instead of 1.4, it improved to 5 min 50 sec. So it definitely looks like there's something that's slower when compiling code targeted for 1.4 with JDK 7.

        Show
        Knut Anders Hatlen added a comment - I got a chance to test the build time with JDK 6 vs JDK 7 on Ubuntu too, and in my experiments there was a significant difference: 5 min 20 sec vs 8 min 50 sec when I ran "ant -q all". If I modified all the build.xml files and specified source and target level 1.5 (or 1.6 or 1.7) instead of 1.4, it improved to 5 min 50 sec. So it definitely looks like there's something that's slower when compiling code targeted for 1.4 with JDK 7.
        Hide
        Kathey Marsden added a comment -

        I tried the build with the patch on IBM 1.6 with my setup on Windows with the local.properties below:

        jdk14=C:/cygwin/ibmsvn/ntsoftware/ibm142
        j14lib=$

        {jdk14}

        /jre/lib
        jdk15=C:/cygwin/ibmsvn/ntsoftware/ibm15
        j15lib=$

        {jdk15}

        /jre/lib
        jdk16=C:/cygwin/ibmsvn/ntsoftware/ibm16
        j16lib=$

        {jdk16}

        /jre/lib
        sane=true
        sanity=true

        and with a similar local.properties tp the one I posted before (just paths changed) on Linux, and the IBM 1.6 build seems to be working fine. I will log a bug for the IBM 1.7 manifest issue which also seems to be an issue on Windows.

        So I think the patch does not regress anything for IBM 1.6. I think for IBM 1.7, it would be sufficient to file an issue to get the build working with IBM JDK 1.7.

        As an aside, for some time I could build on Windows without a local.properties or ant.properties. About a month ago I noticed that was no longer the case. I am not sure if something changed on my machine or with the build that caused that problem.

        Show
        Kathey Marsden added a comment - I tried the build with the patch on IBM 1.6 with my setup on Windows with the local.properties below: jdk14=C:/cygwin/ibmsvn/ntsoftware/ibm142 j14lib=$ {jdk14} /jre/lib jdk15=C:/cygwin/ibmsvn/ntsoftware/ibm15 j15lib=$ {jdk15} /jre/lib jdk16=C:/cygwin/ibmsvn/ntsoftware/ibm16 j16lib=$ {jdk16} /jre/lib sane=true sanity=true and with a similar local.properties tp the one I posted before (just paths changed) on Linux, and the IBM 1.6 build seems to be working fine. I will log a bug for the IBM 1.7 manifest issue which also seems to be an issue on Windows. So I think the patch does not regress anything for IBM 1.6. I think for IBM 1.7, it would be sufficient to file an issue to get the build working with IBM JDK 1.7. As an aside, for some time I could build on Windows without a local.properties or ant.properties. About a month ago I noticed that was no longer the case. I am not sure if something changed on my machine or with the build that caused that problem.
        Hide
        Knut Anders Hatlen added a comment -

        I agree that PropertySetter is starting to get too complex. In my opinion, it would be sufficient if PropertySetter were able to detect which Java version Ant is running (which can be done by inspecting system properties, no need to parse rt.jar) and set up the various compile classpaths based on that Java instance. This would still allow easy building of Derby, which was the goal when PropertySetter was introduced. If someone wants a more exotic setup (like pointing java14compile.classpath to actual Java 1.4 runtime libraries), they should be able to override the compile classpaths with properties the same way as today, but PropertySetter doesn't need to do that automatically.

        Although it might be possible to make PropertySetter detect all old Java versions from all vendors on all platforms, and to keep it updated, I'd much rather spend my time writing database code than maintaining PropertySetter...

        Show
        Knut Anders Hatlen added a comment - I agree that PropertySetter is starting to get too complex. In my opinion, it would be sufficient if PropertySetter were able to detect which Java version Ant is running (which can be done by inspecting system properties, no need to parse rt.jar) and set up the various compile classpaths based on that Java instance. This would still allow easy building of Derby, which was the goal when PropertySetter was introduced. If someone wants a more exotic setup (like pointing java14compile.classpath to actual Java 1.4 runtime libraries), they should be able to override the compile classpaths with properties the same way as today, but PropertySetter doesn't need to do that automatically. Although it might be possible to make PropertySetter detect all old Java versions from all vendors on all platforms, and to keep it updated, I'd much rather spend my time writing database code than maintaining PropertySetter...
        Hide
        Kristian Waagan added a comment -

        Kathey wrote:


        I wonder, is their a reason we use the manifest entries instead of the system properties [1] to determine this information?


        Yes, spawning a process for each of the candidate VMs to extract the system properties is taking much longer. This will surely annoy some developers.

        Both the mechanisms we are using to determine the version ("encoded" in the directory name, and inspecting JAR files manifest) have weaknesses. As Rick suggests, we should consider a simplified build process and leave the more complex configurations to be manually configured by those who want/have to run with them.

        I believe the reason why the PropertySetter was created was to allow casual developers and newcomers to Derby to get started quickly. Today the minimal requirement for a build is probably one JDK, and that should be the VM used to invoke ant.

        Show
        Kristian Waagan added a comment - Kathey wrote: I wonder, is their a reason we use the manifest entries instead of the system properties [1] to determine this information? Yes, spawning a process for each of the candidate VMs to extract the system properties is taking much longer. This will surely annoy some developers. Both the mechanisms we are using to determine the version ("encoded" in the directory name, and inspecting JAR files manifest) have weaknesses. As Rick suggests, we should consider a simplified build process and leave the more complex configurations to be manually configured by those who want/have to run with them. I believe the reason why the PropertySetter was created was to allow casual developers and newcomers to Derby to get started quickly. Today the minimal requirement for a build is probably one JDK, and that should be the VM used to invoke ant.
        Hide
        Rick Hillegas added a comment -

        Thanks, Kathey. The PropertySetter task does look at system properties. However, where it's falling down is in the part of its processing where it looks around the directory system to find other JDKs. It does this so that it can find libraries for lower versions of the JDK. In particular, it wants to find a 1.4 JDK if it can so that it can use those libraries when compiling the bulk of Derby code. Being able to use those libraries means that the compiler can object if someone tries to call a Java 6 method in code which is supposed to run on small devices.

        It's a very tricky piece of logic and I am beginning to fear that the number of special cases may be expanding faster than we can keep up with them.

        Standard attributes in the jar manifest are documented here: http://download.oracle.com/javase/1.4.2/docs/guide/jar/jar.html#Manifest%20Specification

        Thanks,
        -Rick

        Show
        Rick Hillegas added a comment - Thanks, Kathey. The PropertySetter task does look at system properties. However, where it's falling down is in the part of its processing where it looks around the directory system to find other JDKs. It does this so that it can find libraries for lower versions of the JDK. In particular, it wants to find a 1.4 JDK if it can so that it can use those libraries when compiling the bulk of Derby code. Being able to use those libraries means that the compiler can object if someone tries to call a Java 6 method in code which is supposed to run on small devices. It's a very tricky piece of logic and I am beginning to fear that the number of special cases may be expanding faster than we can keep up with them. Standard attributes in the jar manifest are documented here: http://download.oracle.com/javase/1.4.2/docs/guide/jar/jar.html#Manifest%20Specification Thanks, -Rick
        Hide
        Kathey Marsden added a comment -

        Thanks Rick,

        I will report it. I wonder, is their a reason we use the manifest entries instead of the system properties [1] to determine this information?

        Are the values in the manifest a documented standard or convention?

        [1] http://download.oracle.com/javase/6/docs/api/java/lang/System.html#getProperties()

        Show
        Kathey Marsden added a comment - Thanks Rick, I will report it. I wonder, is their a reason we use the manifest entries instead of the system properties [1] to determine this information? Are the values in the manifest a documented standard or convention? [1] http://download.oracle.com/javase/6/docs/api/java/lang/System.html#getProperties( )
        Hide
        Rick Hillegas added a comment -

        Thanks, Kathey. I believe I have made some headway in understanding how the IBM JDK 7 for Linux is confusing the Derby build. The PropertySetter task is looking inside the rt.jar of the IBM JDK 7 in order to read the jar manifest and figure out what kind of JDK this is. Unfortunately, the manifest for that jar file looks wrong. Here it is:

        Manifest-Version: 1.0
        Ant-Version: Apache Ant 1.7.1
        Created-By: 2.4 (IBM Corporation)
        Build-Level: $HeadURL$@$Rev$,2011-08-27 07:16:30.694
        Implementation-Version: 6.0

        The manifest says that the JDK is Java 6 rather than Java 7 and the manifest is missing the Implementation-Vendor and Specification-Version attributes. For comparison, here is the manifest from the rt.jar for IBM JDK 6 for Linux:

        Manifest-Version: 1.0
        Ant-Version: Apache Ant 1.6.5
        Created-By: 2.3 (IBM Corporation)
        Specification-Title: Java Platform API Specification
        Implementation-Title: Java Runtime Environment
        Specification-Version: 1.6.0
        Specification-Vendor: Sun Microsystems, Inc.
        Implementation-Version: 1.6.0
        Implementation-Vendor: IBM Corporation

        It is possible that the same problem may be found in the jar files for IBM JDK 7 for other platforms. For the time being, this may prevent us from using those JDKs to build Derby.

        Could someone at IBM bring this to the attention of the IBM JDK team? Thanks.

        Show
        Rick Hillegas added a comment - Thanks, Kathey. I believe I have made some headway in understanding how the IBM JDK 7 for Linux is confusing the Derby build. The PropertySetter task is looking inside the rt.jar of the IBM JDK 7 in order to read the jar manifest and figure out what kind of JDK this is. Unfortunately, the manifest for that jar file looks wrong. Here it is: Manifest-Version: 1.0 Ant-Version: Apache Ant 1.7.1 Created-By: 2.4 (IBM Corporation) Build-Level: $HeadURL$@$Rev$,2011-08-27 07:16:30.694 Implementation-Version: 6.0 The manifest says that the JDK is Java 6 rather than Java 7 and the manifest is missing the Implementation-Vendor and Specification-Version attributes. For comparison, here is the manifest from the rt.jar for IBM JDK 6 for Linux: Manifest-Version: 1.0 Ant-Version: Apache Ant 1.6.5 Created-By: 2.3 (IBM Corporation) Specification-Title: Java Platform API Specification Implementation-Title: Java Runtime Environment Specification-Version: 1.6.0 Specification-Vendor: Sun Microsystems, Inc. Implementation-Version: 1.6.0 Implementation-Vendor: IBM Corporation It is possible that the same problem may be found in the jar files for IBM JDK 7 for other platforms. For the time being, this may prevent us from using those JDKs to build Derby. Could someone at IBM bring this to the attention of the IBM JDK team? Thanks.
        Hide
        Kathey Marsden added a comment -

        I know there are nightly builds on linux with JDK 1.6, but I think with
        the following local.properties:

        j16lib=/local1/cloudtst/dev/src/ibm16/jre/lib
        j15lib=/local1/cloudtst/dev/src/ibm15/jre/lib
        j14lib=/local1/cloudtst/dev/src/ibm142/jre/lib
        jdk16=/local1/cloudtst/dev/src/ibm16
        java14compile.classpath=$

        {j14lib}/core.jar;${j14lib}

        /server.jar;$

        {j14lib}/xml.jar;${j14lib}

        /ibmjcefw.jar;$

        {j14lib}

        /security.jar
        java15compile.classpath=$

        {j15lib}/core.jar;${j15lib}

        /server.jar;$

        {j15lib}/xml.jar;${j15lib}

        /ibmjcefw.jar;$

        {j15lib}/security.jar;${j15lib}

        /vm.jar
        java16compile.classpath=$

        {j16lib}/sql.jar;${j16lib}

        /xml.jar;$

        {j16lib}/ibmjcefw.jar;${j16lib}

        /rt.jar;$

        {j16lib}/vm.jar;${j16lib}

        /security.jar;$

        {j16lib}/
        java.util.jar;${j16lib}

        /jndi.jar;$

        {j16lib}/logging.jar;${j16lib}

        /jlm.jar;$

        {j16lib}

        /annotation.jar
        junit=/local1/cloudtst/dev/src/junit/junit.jar
        proceed=true
        sane=false

        I have built on linux in the past with JDK 1.6 as well, but have always
        set the various compile.classpath properties.

        Show
        Kathey Marsden added a comment - I know there are nightly builds on linux with JDK 1.6, but I think with the following local.properties: j16lib=/local1/cloudtst/dev/src/ibm16/jre/lib j15lib=/local1/cloudtst/dev/src/ibm15/jre/lib j14lib=/local1/cloudtst/dev/src/ibm142/jre/lib jdk16=/local1/cloudtst/dev/src/ibm16 java14compile.classpath=$ {j14lib}/core.jar;${j14lib} /server.jar;$ {j14lib}/xml.jar;${j14lib} /ibmjcefw.jar;$ {j14lib} /security.jar java15compile.classpath=$ {j15lib}/core.jar;${j15lib} /server.jar;$ {j15lib}/xml.jar;${j15lib} /ibmjcefw.jar;$ {j15lib}/security.jar;${j15lib} /vm.jar java16compile.classpath=$ {j16lib}/sql.jar;${j16lib} /xml.jar;$ {j16lib}/ibmjcefw.jar;${j16lib} /rt.jar;$ {j16lib}/vm.jar;${j16lib} /security.jar;$ {j16lib}/ java.util.jar;${j16lib} /jndi.jar;$ {j16lib}/logging.jar;${j16lib} /jlm.jar;$ {j16lib} /annotation.jar junit=/local1/cloudtst/dev/src/junit/junit.jar proceed=true sane=false I have built on linux in the past with JDK 1.6 as well, but have always set the various compile.classpath properties.
        Hide
        Rick Hillegas added a comment -

        When I back out the patch and remove the IBM JDK 7 from my Ubuntu appliance (leaving only the IBM JDK 6), the build fails early on. The build is unable to find a JDK to build against. Might be an environmental problem in my Linux appliance. Might be that we have never tested the build against IBM JDKs on Linux. In any event, I think that fixing the build in this environment falls outside the scope of this JIRA.

        Have we tested the build against IBM JDKs on Linux?

        Thanks,
        -Rick

        Show
        Rick Hillegas added a comment - When I back out the patch and remove the IBM JDK 7 from my Ubuntu appliance (leaving only the IBM JDK 6), the build fails early on. The build is unable to find a JDK to build against. Might be an environmental problem in my Linux appliance. Might be that we have never tested the build against IBM JDKs on Linux. In any event, I think that fixing the build in this environment falls outside the scope of this JIRA. Have we tested the build against IBM JDKs on Linux? Thanks, -Rick
        Hide
        Rick Hillegas added a comment -

        I have downloaded an IBM JDK 7 for Linux. The build does not work with it. Stand by...

        Show
        Rick Hillegas added a comment - I have downloaded an IBM JDK 7 for Linux. The build does not work with it. Stand by...
        Hide
        Rick Hillegas added a comment -

        Thanks for the review, Kristian. I have added a comment about setting java17compile.classpath. That will turn up in the next rev of the patch.

        The seeds are used by the setForMostJDKsJARInspection() and setForMostJDKs() methods. Could you suggest some more extensive header comments for those methods? I can add those to the next rev. More extensive comments for those methods will help us wordsmith the names and comments on the JDKVersion methods. Thanks.

        Show
        Rick Hillegas added a comment - Thanks for the review, Kristian. I have added a comment about setting java17compile.classpath. That will turn up in the next rev of the patch. The seeds are used by the setForMostJDKsJARInspection() and setForMostJDKs() methods. Could you suggest some more extensive header comments for those methods? I can add those to the next rev. More extensive comments for those methods will help us wordsmith the names and comments on the JDKVersion methods. Thanks.
        Hide
        Kristian Waagan added a comment -

        Thanks for the updated patch, Rick.

        Unfortunately, the comments for the names/seeds are now inaccurate, as the values aren't used as directory name seeds by the setForXXXJARInspection methods. The way I understand it, the seed is used as a directory name seed with the directory-based algorithm, and as a specification version seed with the JAR-inspection-based algorithm. This is only relevant for the variables '_oracleDirectoryNameSeed' and '_ibmDirectoryNameSeed'. '_ibmDirectoryNameSeedWithoutPeriod' is only used by the directory-based algorithm and is correct as it stands.
        Not sure what to suggest, besides from either making these two names less specific again or creating two methods with different names returning the same value...

        Maybe it's not so important either, I'll let you decide.

        There's no comment about the tool setting 'java17compile.classpath'. Is that correct, or just an omission?

        Show
        Kristian Waagan added a comment - Thanks for the updated patch, Rick. Unfortunately, the comments for the names/seeds are now inaccurate, as the values aren't used as directory name seeds by the setForXXXJARInspection methods. The way I understand it, the seed is used as a directory name seed with the directory-based algorithm, and as a specification version seed with the JAR-inspection-based algorithm. This is only relevant for the variables '_oracleDirectoryNameSeed' and '_ibmDirectoryNameSeed'. '_ibmDirectoryNameSeedWithoutPeriod' is only used by the directory-based algorithm and is correct as it stands. Not sure what to suggest, besides from either making these two names less specific again or creating two methods with different names returning the same value... Maybe it's not so important either, I'll let you decide. There's no comment about the tool setting 'java17compile.classpath'. Is that correct, or just an omission?
        Hide
        Rick Hillegas added a comment -

        My virtualized Ubuntu appliance seems to be working again. I have tested the patch on Ubuntu using Oracle JDKs, and the patch seems to do the right thing there too. I did not notice a big difference between the build times on JDK 6 and JDK 7 on Ubuntu. Using the JDK 6 compiler the build took 2 minutes and 21 seconds. It took just 9 seconds longer using the JDK 7 compiler.

        Show
        Rick Hillegas added a comment - My virtualized Ubuntu appliance seems to be working again. I have tested the patch on Ubuntu using Oracle JDKs, and the patch seems to do the right thing there too. I did not notice a big difference between the build times on JDK 6 and JDK 7 on Ubuntu. Using the JDK 6 compiler the build took 2 minutes and 21 seconds. It took just 9 seconds longer using the JDK 7 compiler.
        Hide
        Rick Hillegas added a comment -

        Attaching derby-5469-01-ag-cleanedUp.diff. This patch removes some unused cruft. It also renames and adds comments to fields and methods in JDKVersion.

        Touches the same files as the previous patch.

        Show
        Rick Hillegas added a comment - Attaching derby-5469-01-ag-cleanedUp.diff. This patch removes some unused cruft. It also renames and adds comments to fields and methods in JDKVersion. Touches the same files as the previous patch.
        Hide
        Rick Hillegas added a comment -

        Thanks for test-driving the patch, Dag, Knut, and Kristian. Some responses to Kristian's comments:

        o 141: JAVA_5 is unused.
        o 578: currentJDK is unused

        Thanks, I will remove these.

        o 1302: printProperty is unused (used for debugging?)
        o 1525: requireProperty is unused

        These two methods are also unused without my patch. I think that requireProperty() is cruft which I can remove. The printProperty() method may be useful for debugging purposes so I propose to leave it alone.

        I agree that the state and methods of JDKVersion need better names and comments. I will attempt to address this issue in the next rev of the patch. Thanks.

        Show
        Rick Hillegas added a comment - Thanks for test-driving the patch, Dag, Knut, and Kristian. Some responses to Kristian's comments: o 141: JAVA_5 is unused. o 578: currentJDK is unused Thanks, I will remove these. o 1302: printProperty is unused (used for debugging?) o 1525: requireProperty is unused These two methods are also unused without my patch. I think that requireProperty() is cruft which I can remove. The printProperty() method may be useful for debugging purposes so I propose to leave it alone. I agree that the state and methods of JDKVersion need better names and comments. I will attempt to address this issue in the next rev of the patch. Thanks.
        Hide
        Kristian Waagan added a comment -

        I tested the patch on Windows Vista, and it works fine for me. Note that ant uses JAVA_HOME to decide which version of Java is used to invoke ant, so one has to either unset it or point it at the Java version one wants to use.

        Javadocs built with both JDK 6 and 7.

        A few comments on the changes in PropertySetter:
        o 141: JAVA_5 is unused.
        o 578: currentJDK is unused
        o 1302: printProperty is unused (used for debugging?)
        o 1525: requireProperty is unused

        It would maybe be good to comment on the structure and methods of JDKVersion.
        The variables 'baseJavaVersion', 'oracleName', 'ibmBaseName', and 'ibmLatestName' are not immediately self-explaining to me. For instance, why are both 'baseJavaVersion' and 'oracleName' needed? What's the difference between 'ibmBaseName' and 'ibmLatestName'? It's also not clear to me if name is another word for version, or if name is something else. Is 'baseJavaVersion' the specification version of the JDK/JRE?

        Show
        Kristian Waagan added a comment - I tested the patch on Windows Vista, and it works fine for me. Note that ant uses JAVA_HOME to decide which version of Java is used to invoke ant, so one has to either unset it or point it at the Java version one wants to use. Javadocs built with both JDK 6 and 7. A few comments on the changes in PropertySetter: o 141: JAVA_5 is unused. o 578: currentJDK is unused o 1302: printProperty is unused (used for debugging?) o 1525: requireProperty is unused It would maybe be good to comment on the structure and methods of JDKVersion. The variables 'baseJavaVersion', 'oracleName', 'ibmBaseName', and 'ibmLatestName' are not immediately self-explaining to me. For instance, why are both 'baseJavaVersion' and 'oracleName' needed? What's the difference between 'ibmBaseName' and 'ibmLatestName'? It's also not clear to me if name is another word for version, or if name is something else. Is 'baseJavaVersion' the specification version of the JDK/JRE?
        Hide
        Knut Anders Hatlen added a comment -

        I see similar differences on Solaris. "ant -q all" takes ~40 s when JAVA_HOME points to JDK 6, and ~65 s when it points to JDK 7. I also see this when running without the patch, so I don't think there's a problem with the patch.

        Another observation: If I remove the source="..." and target="..." attributes from all the javac targets in the build files, the JDK 7 build runs as fast as the JDK 6 build. Perhaps javac in JDK 7 is less optimized for compiling classes with source and target level 1.4.

        Show
        Knut Anders Hatlen added a comment - I see similar differences on Solaris. "ant -q all" takes ~40 s when JAVA_HOME points to JDK 6, and ~65 s when it points to JDK 7. I also see this when running without the patch, so I don't think there's a problem with the patch. Another observation: If I remove the source="..." and target="..." attributes from all the javac targets in the build files, the JDK 7 build runs as fast as the JDK 6 build. Perhaps javac in JDK 7 is less optimized for compiling classes with source and target level 1.4.
        Hide
        Dag H. Wanvik added a comment -

        I built ok on Windows Vista/Cygwin with JDK 5,6, and 7. For some reason, the JDK 7 build is much slower than the JDK 6 build: ca 5 vs ca 3 m (two attempts at each, interleaved). No clue why yet.

        Show
        Dag H. Wanvik added a comment - I built ok on Windows Vista/Cygwin with JDK 5,6, and 7. For some reason, the JDK 7 build is much slower than the JDK 6 build: ca 5 vs ca 3 m (two attempts at each, interleaved). No clue why yet.
        Hide
        Knut Anders Hatlen added a comment -

        That's right. I tested the patch on Solaris.

        Show
        Knut Anders Hatlen added a comment - That's right. I tested the patch on Solaris.
        Hide
        Rick Hillegas added a comment -

        Thanks, Knut. I think you were testing on Solaris?

        Still need a volunteer to test-drive the patch on Windows. I may be able to cover Ubuntu soon--am recovering my virtual machines now. Thanks.

        Show
        Rick Hillegas added a comment - Thanks, Knut. I think you were testing on Solaris? Still need a volunteer to test-drive the patch on Windows. I may be able to cover Ubuntu soon--am recovering my virtual machines now. Thanks.
        Hide
        Knut Anders Hatlen added a comment -

        Thanks, Rick. The results look good now. With the 01-af patch, I see this when all JDK versions are found by PropertySetter:

        • Building with Java 5, java17compile.classpath is based on Java 5 + JDBC 4 stubs
        • Building with Java 6, java17compile.classpath is based on Java 6
        • Building with Java 7, java17compile.classpath is based on Java 7
        Show
        Knut Anders Hatlen added a comment - Thanks, Rick. The results look good now. With the 01-af patch, I see this when all JDK versions are found by PropertySetter: Building with Java 5, java17compile.classpath is based on Java 5 + JDBC 4 stubs Building with Java 6, java17compile.classpath is based on Java 6 Building with Java 7, java17compile.classpath is based on Java 7
        Hide
        Rick Hillegas added a comment -

        Attaching derby-5469-01-af-dontSetUprevVariables.diff. This improves the previous version of the patch by not setting the java$

        {version}compile.classpath variable for ${version}

        greater than the compiler version. This patch flunks the build if the user has set java$

        {version}compile.classpath or j${version}

        lib while trying to run with a compiler whose rev level is less than $

        {version}

        .

        Knut, could you test-drive the new version of the patch and verify whether it fixes the problem you saw?

        Touches the same files as the previous rev of the patch.

        Show
        Rick Hillegas added a comment - Attaching derby-5469-01-af-dontSetUprevVariables.diff. This improves the previous version of the patch by not setting the java$ {version}compile.classpath variable for ${version} greater than the compiler version. This patch flunks the build if the user has set java$ {version}compile.classpath or j${version} lib while trying to run with a compiler whose rev level is less than $ {version} . Knut, could you test-drive the new version of the patch and verify whether it fixes the problem you saw? Touches the same files as the previous rev of the patch.
        Hide
        Knut Anders Hatlen added a comment -

        That sounds right. Note that since we support building with JDK 5, even the code that's only ever supposed to run on Java 6 and newer is restricted to the Java 5 subset of the language and libraries (unless we use reflection).

        Show
        Knut Anders Hatlen added a comment - That sounds right. Note that since we support building with JDK 5, even the code that's only ever supposed to run on Java 6 and newer is restricted to the Java 5 subset of the language and libraries (unless we use reflection).
        Hide
        Rick Hillegas added a comment -

        Thanks for pointing that out, Knut. Does the following make sense:

        1) The compiler must support generics (this we already enforce).

        2) The java$

        {version}compiler.classpath and j{version}

        lib variables should not be set (either by the user or by PropertySetter) if $

        {version}

        is greater than the compiler version.

        Thanks,
        -Rick

        Show
        Rick Hillegas added a comment - Thanks for pointing that out, Knut. Does the following make sense: 1) The compiler must support generics (this we already enforce). 2) The java$ {version}compiler.classpath and j{version} lib variables should not be set (either by the user or by PropertySetter) if $ {version} is greater than the compiler version. Thanks, -Rick
        Hide
        Knut Anders Hatlen added a comment -

        java16compile.classpath is based on JDK 5 without the patch too (which is the correct behaviour, since the JDK 5 compiler might not understand classes in a newer format). What I meant to point out, was that if we start using java17compile.classpath to build parts of the code, and we still want to support building with JDK 5 or JDK 6, we need to add logic to construct java17compile.classpath from the lower version JDKs. But that logic isn't needed for now, so I think the patch is fine.

        Show
        Knut Anders Hatlen added a comment - java16compile.classpath is based on JDK 5 without the patch too (which is the correct behaviour, since the JDK 5 compiler might not understand classes in a newer format). What I meant to point out, was that if we start using java17compile.classpath to build parts of the code, and we still want to support building with JDK 5 or JDK 6, we need to add logic to construct java17compile.classpath from the lower version JDKs. But that logic isn't needed for now, so I think the patch is fine.
        Hide
        Rick Hillegas added a comment -

        Thanks, Knut. Hm, that's odd. Without the patch, if you build with JDK 5 (and both JDK 6 and JDK 7 are present), what is java16compile.classpath based on? Thanks.

        Show
        Rick Hillegas added a comment - Thanks, Knut. Hm, that's odd. Without the patch, if you build with JDK 5 (and both JDK 6 and JDK 7 are present), what is java16compile.classpath based on? Thanks.
        Hide
        Rick Hillegas added a comment -

        Tests passed cleanly for me on Java 6 running against Derby jars built using the open jdk 7 mac os x preview.

        Show
        Rick Hillegas added a comment - Tests passed cleanly for me on Java 6 running against Derby jars built using the open jdk 7 mac os x preview.
        Hide
        Knut Anders Hatlen added a comment -

        The patch seems to do the right thing in my environment.

        One small anomaly:

        When building with JDK 5, and both JDK 6 and JDK 7 are found by PropertySetter, java16compile.classpath will be based on JDK 5, whereas java17compile.classpath will be based on JDK 7. But since we don't use java17compile.classpath when compiling yet, that's not a problem for now.

        Show
        Knut Anders Hatlen added a comment - The patch seems to do the right thing in my environment. One small anomaly: When building with JDK 5, and both JDK 6 and JDK 7 are found by PropertySetter, java16compile.classpath will be based on JDK 5, whereas java17compile.classpath will be based on JDK 7. But since we don't use java17compile.classpath when compiling yet, that's not a problem for now.
        Hide
        Rick Hillegas added a comment - - edited

        Attaching derby-5469-01-ae-add17andJavadoc.diff. This patch makes it possible for me to build Derby and the javadoc using the open jdk 7 preview for mac os x. I am running regression tests against Derby jars built by this jdk in order to verify that the resulting jar files run correctly on Java 6.

        I would appreciate it if other developers could test-drive this patch on Windows, Solaris, and Linux. I'm hoping that the patch allows us to use jdk 7 on those platforms too, but some more tuning may be necessary. I would appreciate it if the following tests could be run:

        a) Build Derby on JDK 6

        b) Build javadoc on JDK 6

        c) Build Derby on JDK 7

        d) Build javadoc on JDK 7

        This patch makes the following changes to PropertySetter:

        P1) Refactors the code to make it more table-driven and eliminate duplicated code. These changes center around the addition of a new inner class, JDKVersion. That class encapsulates the information needed to set the classpath variable for a JDK level.

        P2) Adds JDK 7 to the table of JDKVersions.

        P3) Comments out the check which rejected early access releases. We may want to uncomment this later on. For the moment, however, I see more value than harm in allowing testing against early access JDKs.

        P4) Adds additional logic to handle the inspection of open jdk 7 on mac os x.

        P5) Expands the list of VMs which are sufficient to build Derby. Previously, you had to have JDK 5 or JDK 6. Now JDK 7 is sufficient to build Derby.

        The patch makes the following changes to the master build script:

        B1) Adds a new java17compile.classpath variable. This variable will be set by PropertySetter if that task finds a valid jdk 7 installation on the machine.

        B2) If java16compile.classpath is not set, then set it to be java15compile.classpath along with the JDBC4 stubs, as was done previously. However, if java15compile.classpath is also not set, then java16compile.classpath is set to be java17compile.classpath.

        B3) If java17compile.classpath is not set, then it is forced to be java16compile.classpath. Note that java17compile.classpath is not currently used by the build--but someday it may be.

        B4) Increases the memory given to the javadoc tasks. Java 7 changed the javadoc format. The Java 7 javadoc program needs more memory--at least on mac os x it does.

        Touches the following files:

        M java/build/org/apache/derbyPreBuild/PropertySetter.java
        M build.xml

        Show
        Rick Hillegas added a comment - - edited Attaching derby-5469-01-ae-add17andJavadoc.diff. This patch makes it possible for me to build Derby and the javadoc using the open jdk 7 preview for mac os x. I am running regression tests against Derby jars built by this jdk in order to verify that the resulting jar files run correctly on Java 6. I would appreciate it if other developers could test-drive this patch on Windows, Solaris, and Linux. I'm hoping that the patch allows us to use jdk 7 on those platforms too, but some more tuning may be necessary. I would appreciate it if the following tests could be run: a) Build Derby on JDK 6 b) Build javadoc on JDK 6 c) Build Derby on JDK 7 d) Build javadoc on JDK 7 This patch makes the following changes to PropertySetter: P1) Refactors the code to make it more table-driven and eliminate duplicated code. These changes center around the addition of a new inner class, JDKVersion. That class encapsulates the information needed to set the classpath variable for a JDK level. P2) Adds JDK 7 to the table of JDKVersions. P3) Comments out the check which rejected early access releases. We may want to uncomment this later on. For the moment, however, I see more value than harm in allowing testing against early access JDKs. P4) Adds additional logic to handle the inspection of open jdk 7 on mac os x. P5) Expands the list of VMs which are sufficient to build Derby. Previously, you had to have JDK 5 or JDK 6. Now JDK 7 is sufficient to build Derby. The patch makes the following changes to the master build script: B1) Adds a new java17compile.classpath variable. This variable will be set by PropertySetter if that task finds a valid jdk 7 installation on the machine. B2) If java16compile.classpath is not set, then set it to be java15compile.classpath along with the JDBC4 stubs, as was done previously. However, if java15compile.classpath is also not set, then java16compile.classpath is set to be java17compile.classpath. B3) If java17compile.classpath is not set, then it is forced to be java16compile.classpath. Note that java17compile.classpath is not currently used by the build--but someday it may be. B4) Increases the memory given to the javadoc tasks. Java 7 changed the javadoc format. The Java 7 javadoc program needs more memory--at least on mac os x it does. Touches the following files: M java/build/org/apache/derbyPreBuild/PropertySetter.java M build.xml
        Hide
        Rick Hillegas added a comment -

        Here is the build output with the printCompiler properties set, running from a shell window in which JAVA_HOME points at the jdk 7 preview:

        printCompilerProperties:
        [echo] Before setting properties: compilerPropsAlreadySet = $

        {compilerPropsAlreadySet}

        [echo] Before setting properties: compilerLevel16 = 1.6
        [echo] Before setting properties: jsr169compile.classpath = /Users/rh161140/sw/phoneME/phoneme_advanced_mr2/lib/btclasses.zip:/Users/rh161140/sw/phoneME/phoneme_advanced_mr2/lib/basis.jar:/Users/rh161140/sw/jsr169Support/jdbc.jar
        [echo] Before setting properties: j14lib = $

        {j14lib}

        [echo] Before setting properties: java14compile.classpath = $

        {java14compile.classpath}

        [echo] Before setting properties: j15lib = $

        {j15lib}

        [echo] Before setting properties: java15compile.classpath = $

        {java15compile.classpath}

        [echo] Before setting properties: j16lib = $

        {j16lib}

        [echo] Before setting properties: java16compile.classpath = $

        {java16compile.classpath}

        [setJdkProperties] [verbose] jdkParent derived from '/Library/Java/JavaVirtualMachines/JDK 1.7.0 Developer Preview.jdk/Contents/Home/jre': '/Library/Java/JavaVirtualMachines/JDK 1.7.0 Developer Preview.jdk/Contents'
        [setJdkProperties]
        [setJdkProperties] PropertySetter environment =
        [setJdkProperties]
        [setJdkProperties] java.vendor = Oracle Corporation
        [setJdkProperties] java.home = /Library/Java/JavaVirtualMachines/JDK 1.7.0 Developer Preview.jdk/Contents/Home/jre
        [setJdkProperties] java.version = 1.7.0-ea
        [setJdkProperties] os.name = Mac OS X
        [setJdkProperties] j14lib = null
        [setJdkProperties] j15lib = null
        [setJdkProperties] j16lib = null
        [setJdkProperties] jdkSearchPath = /Library/Java/JavaVirtualMachines/JDK 1.7.0 Developer Preview.jdk/Contents
        [setJdkProperties]
        [setJdkProperties]
        [setJdkProperties]
        [setJdkProperties] [verbose] jdkParent derived from '/Library/Java/JavaVirtualMachines/JDK 1.7.0 Developer Preview.jdk/Contents/Home/jre': '/Library/Java/JavaVirtualMachines/JDK 1.7.0 Developer Preview.jdk/Contents'
        [setJdkProperties]
        [setJdkProperties] Locating Apple JDKs:
        [setJdkProperties] [verbose] locating JDKs in '/Library/Java/JavaVirtualMachines/JDK 1.7.0 Developer Preview.jdk/Contents'
        [setJdkProperties] [verbose] candidate '/Library/Java/JavaVirtualMachines/JDK 1.7.0 Developer Preview.jdk/Contents/Home' -> '/Library/Java/JavaVirtualMachines/JDK 1.7.0 Developer Preview.jdk/Contents/Home'
        [setJdkProperties] [verbose] candidate '/Library/Java/JavaVirtualMachines/JDK 1.7.0 Developer Preview.jdk/Contents/MacOS' -> '/Library/Java/JavaVirtualMachines/JDK 1.7.0 Developer Preview.jdk/Contents/MacOS'
        [setJdkProperties] [verbose] checking root '/Library/Java/JavaVirtualMachines/JDK 1.7.0 Developer Preview.jdk/Contents/Home'
        [setJdkProperties] Missing JDK directory: /Library/Java/JavaVirtualMachines/JDK 1.7.0 Developer Preview.jdk/Contents/Home/Classes
        [setJdkProperties] [verbose] checking root '/Library/Java/JavaVirtualMachines/JDK 1.7.0 Developer Preview.jdk/Contents/MacOS'
        [setJdkProperties] Missing JDK directory: /Library/Java/JavaVirtualMachines/JDK 1.7.0 Developer Preview.jdk/Contents/MacOS/Classes
        [setJdkProperties] [verbose] located 0 JDKs in total
        [setJdkProperties]
        [setJdkProperties] Selecting JDK candidates:
        [setJdkProperties] No candidate JDKs (version '1.4')
        [setJdkProperties] No candidate JDKs (version '1.5')
        [setJdkProperties] No candidate JDKs (version '1.6')
        [setJdkProperties] [verbose] jdkParent derived from '/Library/Java/JavaVirtualMachines/JDK 1.7.0 Developer Preview.jdk/Contents/Home/jre': '/Library/Java/JavaVirtualMachines/JDK 1.7.0 Developer Preview.jdk/Contents'

        BUILD FAILED
        /Users/rh161140/derby/mainline/trunk/build.xml:278: Don't know how to set java15compile.classpath, java16compile.classpath using this environment:

        java.vendor = Oracle Corporation
        java.home = /Library/Java/JavaVirtualMachines/JDK 1.7.0 Developer Preview.jdk/Contents/Home/jre
        java.version = 1.7.0-ea
        os.name = Mac OS X
        j14lib = null
        j15lib = null
        j16lib = null
        jdkSearchPath = /Library/Java/JavaVirtualMachines/JDK 1.7.0 Developer Preview.jdk/Contents

        Please consult BUILDING.html for instructions on how to set the compiler-classpath properties.

        Show
        Rick Hillegas added a comment - Here is the build output with the printCompiler properties set, running from a shell window in which JAVA_HOME points at the jdk 7 preview: printCompilerProperties: [echo] Before setting properties: compilerPropsAlreadySet = $ {compilerPropsAlreadySet} [echo] Before setting properties: compilerLevel16 = 1.6 [echo] Before setting properties: jsr169compile.classpath = /Users/rh161140/sw/phoneME/phoneme_advanced_mr2/lib/btclasses.zip:/Users/rh161140/sw/phoneME/phoneme_advanced_mr2/lib/basis.jar:/Users/rh161140/sw/jsr169Support/jdbc.jar [echo] Before setting properties: j14lib = $ {j14lib} [echo] Before setting properties: java14compile.classpath = $ {java14compile.classpath} [echo] Before setting properties: j15lib = $ {j15lib} [echo] Before setting properties: java15compile.classpath = $ {java15compile.classpath} [echo] Before setting properties: j16lib = $ {j16lib} [echo] Before setting properties: java16compile.classpath = $ {java16compile.classpath} [setJdkProperties] [verbose] jdkParent derived from '/Library/Java/JavaVirtualMachines/JDK 1.7.0 Developer Preview.jdk/Contents/Home/jre': '/Library/Java/JavaVirtualMachines/JDK 1.7.0 Developer Preview.jdk/Contents' [setJdkProperties] [setJdkProperties] PropertySetter environment = [setJdkProperties] [setJdkProperties] java.vendor = Oracle Corporation [setJdkProperties] java.home = /Library/Java/JavaVirtualMachines/JDK 1.7.0 Developer Preview.jdk/Contents/Home/jre [setJdkProperties] java.version = 1.7.0-ea [setJdkProperties] os.name = Mac OS X [setJdkProperties] j14lib = null [setJdkProperties] j15lib = null [setJdkProperties] j16lib = null [setJdkProperties] jdkSearchPath = /Library/Java/JavaVirtualMachines/JDK 1.7.0 Developer Preview.jdk/Contents [setJdkProperties] [setJdkProperties] [setJdkProperties] [setJdkProperties] [verbose] jdkParent derived from '/Library/Java/JavaVirtualMachines/JDK 1.7.0 Developer Preview.jdk/Contents/Home/jre': '/Library/Java/JavaVirtualMachines/JDK 1.7.0 Developer Preview.jdk/Contents' [setJdkProperties] [setJdkProperties] Locating Apple JDKs: [setJdkProperties] [verbose] locating JDKs in '/Library/Java/JavaVirtualMachines/JDK 1.7.0 Developer Preview.jdk/Contents' [setJdkProperties] [verbose] candidate '/Library/Java/JavaVirtualMachines/JDK 1.7.0 Developer Preview.jdk/Contents/Home' -> '/Library/Java/JavaVirtualMachines/JDK 1.7.0 Developer Preview.jdk/Contents/Home' [setJdkProperties] [verbose] candidate '/Library/Java/JavaVirtualMachines/JDK 1.7.0 Developer Preview.jdk/Contents/MacOS' -> '/Library/Java/JavaVirtualMachines/JDK 1.7.0 Developer Preview.jdk/Contents/MacOS' [setJdkProperties] [verbose] checking root '/Library/Java/JavaVirtualMachines/JDK 1.7.0 Developer Preview.jdk/Contents/Home' [setJdkProperties] Missing JDK directory: /Library/Java/JavaVirtualMachines/JDK 1.7.0 Developer Preview.jdk/Contents/Home/Classes [setJdkProperties] [verbose] checking root '/Library/Java/JavaVirtualMachines/JDK 1.7.0 Developer Preview.jdk/Contents/MacOS' [setJdkProperties] Missing JDK directory: /Library/Java/JavaVirtualMachines/JDK 1.7.0 Developer Preview.jdk/Contents/MacOS/Classes [setJdkProperties] [verbose] located 0 JDKs in total [setJdkProperties] [setJdkProperties] Selecting JDK candidates: [setJdkProperties] No candidate JDKs (version '1.4') [setJdkProperties] No candidate JDKs (version '1.5') [setJdkProperties] No candidate JDKs (version '1.6') [setJdkProperties] [verbose] jdkParent derived from '/Library/Java/JavaVirtualMachines/JDK 1.7.0 Developer Preview.jdk/Contents/Home/jre': '/Library/Java/JavaVirtualMachines/JDK 1.7.0 Developer Preview.jdk/Contents' BUILD FAILED /Users/rh161140/derby/mainline/trunk/build.xml:278: Don't know how to set java15compile.classpath, java16compile.classpath using this environment: java.vendor = Oracle Corporation java.home = /Library/Java/JavaVirtualMachines/JDK 1.7.0 Developer Preview.jdk/Contents/Home/jre java.version = 1.7.0-ea os.name = Mac OS X j14lib = null j15lib = null j16lib = null jdkSearchPath = /Library/Java/JavaVirtualMachines/JDK 1.7.0 Developer Preview.jdk/Contents Please consult BUILDING.html for instructions on how to set the compiler-classpath properties.
        Hide
        Rick Hillegas added a comment -

        Hi Kristian,

        Here are the build diagnostics when I set printCompilerPropertiesVerbose=true and don't set the -quiet flag:

        printCompilerProperties:
        [echo] Before setting properties: compilerPropsAlreadySet = $

        {compilerPropsAlreadySet}

        [echo] Before setting properties: compilerLevel16 = 1.6
        [echo] Before setting properties: jsr169compile.classpath = /Users/rh161140/sw/phoneME/phoneme_advanced_mr2/lib/btclasses.zip:/Users/rh161140/sw/phoneME/phoneme_advanced_mr2/lib/basis.jar:/Users/rh161140/sw/jsr169Support/jdbc.jar
        [echo] Before setting properties: j14lib = $

        {j14lib}
        [echo] Before setting properties: java14compile.classpath = ${java14compile.classpath}
        [echo] Before setting properties: j15lib = ${j15lib}
        [echo] Before setting properties: java15compile.classpath = ${java15compile.classpath}
        [echo] Before setting properties: j16lib = ${j16lib}
        [echo] Before setting properties: java16compile.classpath = ${java16compile.classpath}
        [setJdkProperties] [verbose] jdkParent derived from '/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home': '/System/Library/Java/JavaVirtualMachines/1.6.0.jdk'
        [setJdkProperties]
        [setJdkProperties] PropertySetter environment =
        [setJdkProperties]
        [setJdkProperties] java.vendor = Apple Inc.
        [setJdkProperties] java.home = /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home
        [setJdkProperties] java.version = 1.6.0_26
        [setJdkProperties] os.name = Mac OS X
        [setJdkProperties] j14lib = null
        [setJdkProperties] j15lib = null
        [setJdkProperties] j16lib = null
        [setJdkProperties] jdkSearchPath = /System/Library/Java/JavaVirtualMachines/1.6.0.jdk
        [setJdkProperties]
        [setJdkProperties]
        [setJdkProperties]
        [setJdkProperties] [verbose] jdkParent derived from '/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home': '/System/Library/Java/JavaVirtualMachines/1.6.0.jdk'
        [setJdkProperties]
        [setJdkProperties] Locating Apple JDKs:
        [setJdkProperties] [verbose] locating JDKs in '/System/Library/Java/JavaVirtualMachines/1.6.0.jdk'
        [setJdkProperties] [verbose] candidate '/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents' -> '/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents'
        [setJdkProperties] [verbose] checking root '/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents'
        [setJdkProperties] found JDK: vendor=Apple Computer, Inc., specVersion=1.6, implVersion=1.6.0_26, path=/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents
        [setJdkProperties] [verbose] located 1 JDKs in total
        [setJdkProperties]
        [setJdkProperties] Selecting JDK candidates:
        [setJdkProperties] INFO: No valid JDK with specification version '1.4' found
        [setJdkProperties] INFO: No valid JDK with specification version '1.5' found
        [setJdkProperties] Candidate JDK for specification version 1.6 (vendor Apple Inc.): vendor=Apple Computer, Inc., specVersion=1.6, implVersion=1.6.0_26, path=/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents
        [setJdkProperties] Setting property java16compile.classpath to /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/alt-rt.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/alt-string.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/charsets.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/classes.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/dt.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/jce.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/jconsole.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/jsse.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/management-agent.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/ui.jar

        printCompilerProperties:
        [echo] After setting properties: compilerPropsAlreadySet = true
        [echo] After setting properties: compilerLevel16 = 1.6
        [echo] After setting properties: jsr169compile.classpath = /Users/rh161140/sw/phoneME/phoneme_advanced_mr2/lib/btclasses.zip:/Users/rh161140/sw/phoneME/phoneme_advanced_mr2/lib/basis.jar:/Users/rh161140/sw/jsr169Support/jdbc.jar
        [echo] After setting properties: j14lib = ${j14lib}

        [echo] After setting properties: java14compile.classpath = /Users/rh161140/derby/mainline/trunk/classes/stubs/jdbc3:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/alt-rt.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/alt-string.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/charsets.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/classes.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/dt.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/jce.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/jconsole.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/jsse.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/management-agent.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/ui.jar
        [echo] After setting properties: j15lib = $

        {j15lib}

        [echo] After setting properties: java15compile.classpath = /Users/rh161140/derby/mainline/trunk/classes/stubs/jdbc3:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/alt-rt.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/alt-string.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/charsets.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/classes.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/dt.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/jce.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/jconsole.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/jsse.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/management-agent.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/ui.jar
        [echo] After setting properties: j16lib = $

        {jdk16}

        /jre/lib
        [echo] After setting properties: java16compile.classpath = /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/alt-rt.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/alt-string.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/charsets.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/classes.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/dt.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/jce.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/jconsole.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/jsse.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/management-agent.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/ui.jar

        Thanks,
        -Rick

        Show
        Rick Hillegas added a comment - Hi Kristian, Here are the build diagnostics when I set printCompilerPropertiesVerbose=true and don't set the -quiet flag: printCompilerProperties: [echo] Before setting properties: compilerPropsAlreadySet = $ {compilerPropsAlreadySet} [echo] Before setting properties: compilerLevel16 = 1.6 [echo] Before setting properties: jsr169compile.classpath = /Users/rh161140/sw/phoneME/phoneme_advanced_mr2/lib/btclasses.zip:/Users/rh161140/sw/phoneME/phoneme_advanced_mr2/lib/basis.jar:/Users/rh161140/sw/jsr169Support/jdbc.jar [echo] Before setting properties: j14lib = $ {j14lib} [echo] Before setting properties: java14compile.classpath = ${java14compile.classpath} [echo] Before setting properties: j15lib = ${j15lib} [echo] Before setting properties: java15compile.classpath = ${java15compile.classpath} [echo] Before setting properties: j16lib = ${j16lib} [echo] Before setting properties: java16compile.classpath = ${java16compile.classpath} [setJdkProperties] [verbose] jdkParent derived from '/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home': '/System/Library/Java/JavaVirtualMachines/1.6.0.jdk' [setJdkProperties] [setJdkProperties] PropertySetter environment = [setJdkProperties] [setJdkProperties] java.vendor = Apple Inc. [setJdkProperties] java.home = /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home [setJdkProperties] java.version = 1.6.0_26 [setJdkProperties] os.name = Mac OS X [setJdkProperties] j14lib = null [setJdkProperties] j15lib = null [setJdkProperties] j16lib = null [setJdkProperties] jdkSearchPath = /System/Library/Java/JavaVirtualMachines/1.6.0.jdk [setJdkProperties] [setJdkProperties] [setJdkProperties] [setJdkProperties] [verbose] jdkParent derived from '/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home': '/System/Library/Java/JavaVirtualMachines/1.6.0.jdk' [setJdkProperties] [setJdkProperties] Locating Apple JDKs: [setJdkProperties] [verbose] locating JDKs in '/System/Library/Java/JavaVirtualMachines/1.6.0.jdk' [setJdkProperties] [verbose] candidate '/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents' -> '/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents' [setJdkProperties] [verbose] checking root '/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents' [setJdkProperties] found JDK: vendor=Apple Computer, Inc., specVersion=1.6, implVersion=1.6.0_26, path=/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents [setJdkProperties] [verbose] located 1 JDKs in total [setJdkProperties] [setJdkProperties] Selecting JDK candidates: [setJdkProperties] INFO: No valid JDK with specification version '1.4' found [setJdkProperties] INFO: No valid JDK with specification version '1.5' found [setJdkProperties] Candidate JDK for specification version 1.6 (vendor Apple Inc.): vendor=Apple Computer, Inc., specVersion=1.6, implVersion=1.6.0_26, path=/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents [setJdkProperties] Setting property java16compile.classpath to /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/alt-rt.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/alt-string.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/charsets.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/classes.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/dt.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/jce.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/jconsole.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/jsse.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/management-agent.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/ui.jar printCompilerProperties: [echo] After setting properties: compilerPropsAlreadySet = true [echo] After setting properties: compilerLevel16 = 1.6 [echo] After setting properties: jsr169compile.classpath = /Users/rh161140/sw/phoneME/phoneme_advanced_mr2/lib/btclasses.zip:/Users/rh161140/sw/phoneME/phoneme_advanced_mr2/lib/basis.jar:/Users/rh161140/sw/jsr169Support/jdbc.jar [echo] After setting properties: j14lib = ${j14lib} [echo] After setting properties: java14compile.classpath = /Users/rh161140/derby/mainline/trunk/classes/stubs/jdbc3:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/alt-rt.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/alt-string.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/charsets.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/classes.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/dt.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/jce.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/jconsole.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/jsse.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/management-agent.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/ui.jar [echo] After setting properties: j15lib = $ {j15lib} [echo] After setting properties: java15compile.classpath = /Users/rh161140/derby/mainline/trunk/classes/stubs/jdbc3:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/alt-rt.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/alt-string.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/charsets.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/classes.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/dt.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/jce.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/jconsole.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/jsse.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/management-agent.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/ui.jar [echo] After setting properties: j16lib = $ {jdk16} /jre/lib [echo] After setting properties: java16compile.classpath = /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/alt-rt.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/alt-string.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/charsets.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/classes.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/dt.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/jce.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/jconsole.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/jsse.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/management-agent.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/ui.jar Thanks, -Rick
        Hide
        Kristian Waagan added a comment -

        Thanks, Rick.

        Do you think you can run with -DprintCompilerPropertiesVerbose=true as well? Note 'Verbose' at the end of that property name. I'm interested in the output that says stuff about candidate JDKs and about selecting a JDK for each level.

        Show
        Kristian Waagan added a comment - Thanks, Rick. Do you think you can run with -DprintCompilerPropertiesVerbose=true as well? Note 'Verbose' at the end of that property name. I'm interested in the output that says stuff about candidate JDKs and about selecting a JDK for each level.
        Hide
        Rick Hillegas added a comment -

        Hi Kristian,

        Up until recently, I was on a machine running Mac OS X 10.5. On that machine I had separate JDKs for 1.3, 1.4, 1.5, and a beta version of 1.6. A couple weeks ago I upgraded to Mac OS X 10.6. This clobbered the old JDKs and left me in the situation which you describe: I only had JDK 1.6; the older JDKs were just symlinks to JDK 1.6. Over the past several years, Apple has been getting out of the business of making JDKs. It seems that Apple didn't have the resources to make sure that older JDKs still ran on new revs of Mac OS X. Apple has donated its JDK implementation to the Open JDK effort and an open source community is now responsible for producing future revs of the JDK for Mac OS X.

        My machine stopped booting this weekend (it goes into the shop this afternoon). Now I'm using a new machine which runs Mac OS X 10.7. Here the situation is similar to Mac OS X 10.6: the machine came installed with just JDK 1.6; JDKs 1.4 and 1.5 are just symlinks to JDK 1.6. Here's the result of running "ls -l" on the directory of JDK versions:

        lrwxr-xr-x 1 root wheel 10 Oct 16 18:30 1.4 -> CurrentJDK
        lrwxr-xr-x 1 root wheel 10 Oct 16 18:30 1.4.2 -> CurrentJDK
        lrwxr-xr-x 1 root wheel 10 Oct 16 18:30 1.5 -> CurrentJDK
        lrwxr-xr-x 1 root wheel 10 Oct 16 18:30 1.5.0 -> CurrentJDK
        lrwxr-xr-x 1 root wheel 10 Oct 16 18:30 1.6 -> CurrentJDK
        lrwxr-xr-x 1 root wheel 10 Oct 16 18:30 1.6.0 -> CurrentJDK
        drwxr-xr-x 8 root wheel 272 Oct 16 18:30 A
        lrwxr-xr-x 1 root wheel 1 Oct 16 18:30 Current -> A
        lrwxr-xr-x 1 root wheel 59 Oct 16 18:30 CurrentJDK -> /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents

        I have also installed the preview release of Open JDK 1.7. That lives in another directory tree.

        I don't know what the situation is going to be now that the Apple port is being driven by Open JDK. I will see if I can get some information. Here is the result of starting a build under JDK 1.6 with printCompilerProperties set to true:

        [echo] Before setting properties: compilerPropsAlreadySet = $

        {compilerPropsAlreadySet}

        [echo] Before setting properties: compilerLevel16 = 1.6
        [echo] Before setting properties: jsr169compile.classpath = /Users/rh161140/sw/phoneME/phoneme_advanced_mr2/lib/btclasses.zip:/Users/rh161140/sw/phoneME/phoneme_advanced_mr2/lib/basis.jar:/Users/rh161140/sw/jsr169Support/jdbc.jar
        [echo] Before setting properties: j14lib = $

        {j14lib}
        [echo] Before setting properties: java14compile.classpath = ${java14compile.classpath}
        [echo] Before setting properties: j15lib = ${j15lib}
        [echo] Before setting properties: java15compile.classpath = ${java15compile.classpath}
        [echo] Before setting properties: j16lib = ${j16lib}
        [echo] Before setting properties: java16compile.classpath = ${java16compile.classpath}
        [echo] After setting properties: compilerPropsAlreadySet = true
        [echo] After setting properties: compilerLevel16 = 1.6
        [echo] After setting properties: jsr169compile.classpath = /Users/rh161140/sw/phoneME/phoneme_advanced_mr2/lib/btclasses.zip:/Users/rh161140/sw/phoneME/phoneme_advanced_mr2/lib/basis.jar:/Users/rh161140/sw/jsr169Support/jdbc.jar
        [echo] After setting properties: j14lib = ${j14lib}

        [echo] After setting properties: java14compile.classpath = /Users/rh161140/derby/mainline/trunk/classes/stubs/jdbc3:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/alt-rt.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/alt-string.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/charsets.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/classes.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/dt.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/jce.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/jconsole.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/jsse.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/management-agent.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/ui.jar
        [echo] After setting properties: j15lib = $

        {j15lib}

        [echo] After setting properties: java15compile.classpath = /Users/rh161140/derby/mainline/trunk/classes/stubs/jdbc3:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/alt-rt.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/alt-string.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/charsets.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/classes.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/dt.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/jce.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/jconsole.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/jsse.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/management-agent.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/ui.jar
        [echo] After setting properties: j16lib = $

        {jdk16}

        /jre/lib
        [echo] After setting properties: java16compile.classpath = /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/alt-rt.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/alt-string.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/charsets.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/classes.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/dt.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/jce.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/jconsole.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/jsse.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/management-agent.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/ui.jar

        Thanks,
        -Rick

        Show
        Rick Hillegas added a comment - Hi Kristian, Up until recently, I was on a machine running Mac OS X 10.5. On that machine I had separate JDKs for 1.3, 1.4, 1.5, and a beta version of 1.6. A couple weeks ago I upgraded to Mac OS X 10.6. This clobbered the old JDKs and left me in the situation which you describe: I only had JDK 1.6; the older JDKs were just symlinks to JDK 1.6. Over the past several years, Apple has been getting out of the business of making JDKs. It seems that Apple didn't have the resources to make sure that older JDKs still ran on new revs of Mac OS X. Apple has donated its JDK implementation to the Open JDK effort and an open source community is now responsible for producing future revs of the JDK for Mac OS X. My machine stopped booting this weekend (it goes into the shop this afternoon). Now I'm using a new machine which runs Mac OS X 10.7. Here the situation is similar to Mac OS X 10.6: the machine came installed with just JDK 1.6; JDKs 1.4 and 1.5 are just symlinks to JDK 1.6. Here's the result of running "ls -l" on the directory of JDK versions: lrwxr-xr-x 1 root wheel 10 Oct 16 18:30 1.4 -> CurrentJDK lrwxr-xr-x 1 root wheel 10 Oct 16 18:30 1.4.2 -> CurrentJDK lrwxr-xr-x 1 root wheel 10 Oct 16 18:30 1.5 -> CurrentJDK lrwxr-xr-x 1 root wheel 10 Oct 16 18:30 1.5.0 -> CurrentJDK lrwxr-xr-x 1 root wheel 10 Oct 16 18:30 1.6 -> CurrentJDK lrwxr-xr-x 1 root wheel 10 Oct 16 18:30 1.6.0 -> CurrentJDK drwxr-xr-x 8 root wheel 272 Oct 16 18:30 A lrwxr-xr-x 1 root wheel 1 Oct 16 18:30 Current -> A lrwxr-xr-x 1 root wheel 59 Oct 16 18:30 CurrentJDK -> /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents I have also installed the preview release of Open JDK 1.7. That lives in another directory tree. I don't know what the situation is going to be now that the Apple port is being driven by Open JDK. I will see if I can get some information. Here is the result of starting a build under JDK 1.6 with printCompilerProperties set to true: [echo] Before setting properties: compilerPropsAlreadySet = $ {compilerPropsAlreadySet} [echo] Before setting properties: compilerLevel16 = 1.6 [echo] Before setting properties: jsr169compile.classpath = /Users/rh161140/sw/phoneME/phoneme_advanced_mr2/lib/btclasses.zip:/Users/rh161140/sw/phoneME/phoneme_advanced_mr2/lib/basis.jar:/Users/rh161140/sw/jsr169Support/jdbc.jar [echo] Before setting properties: j14lib = $ {j14lib} [echo] Before setting properties: java14compile.classpath = ${java14compile.classpath} [echo] Before setting properties: j15lib = ${j15lib} [echo] Before setting properties: java15compile.classpath = ${java15compile.classpath} [echo] Before setting properties: j16lib = ${j16lib} [echo] Before setting properties: java16compile.classpath = ${java16compile.classpath} [echo] After setting properties: compilerPropsAlreadySet = true [echo] After setting properties: compilerLevel16 = 1.6 [echo] After setting properties: jsr169compile.classpath = /Users/rh161140/sw/phoneME/phoneme_advanced_mr2/lib/btclasses.zip:/Users/rh161140/sw/phoneME/phoneme_advanced_mr2/lib/basis.jar:/Users/rh161140/sw/jsr169Support/jdbc.jar [echo] After setting properties: j14lib = ${j14lib} [echo] After setting properties: java14compile.classpath = /Users/rh161140/derby/mainline/trunk/classes/stubs/jdbc3:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/alt-rt.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/alt-string.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/charsets.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/classes.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/dt.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/jce.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/jconsole.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/jsse.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/management-agent.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/ui.jar [echo] After setting properties: j15lib = $ {j15lib} [echo] After setting properties: java15compile.classpath = /Users/rh161140/derby/mainline/trunk/classes/stubs/jdbc3:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/alt-rt.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/alt-string.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/charsets.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/classes.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/dt.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/jce.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/jconsole.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/jsse.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/management-agent.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/ui.jar [echo] After setting properties: j16lib = $ {jdk16} /jre/lib [echo] After setting properties: java16compile.classpath = /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/alt-rt.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/alt-string.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/charsets.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/classes.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/dt.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/jce.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/jconsole.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/jsse.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/management-agent.jar:/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Classes/ui.jar Thanks, -Rick
        Hide
        Kristian Waagan added a comment -

        Apple pulled some tricks regarding the various JDK versions installed on Mac OS X, where older versions simply pointed at the latest version.
        Is that the case with the JDK 1.7 preview too?
        Can someone build with "ant -DprintCompilerPropertiesVerbose=true" and post the relevant output?

        Show
        Kristian Waagan added a comment - Apple pulled some tricks regarding the various JDK versions installed on Mac OS X, where older versions simply pointed at the latest version. Is that the case with the JDK 1.7 preview too? Can someone build with "ant -DprintCompilerPropertiesVerbose=true" and post the relevant output?

          People

          • Assignee:
            Rick Hillegas
            Reporter:
            Rick Hillegas
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development