Derby
  1. Derby
  2. DERBY-4694

Build breaks on Mac OS X due to JDK classpath issues

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 10.7.1.1
    • Fix Version/s: 10.6.2.1, 10.7.1.1
    • Component/s: Build tools
    • Labels:
      None
    • Environment:
      Mac OS X JDK 1.6

      Description

      The Derby build breaks on OS X, apparently trying to use JDK 1.5/1.6 compile classpath for JDK 1.4.

      A quick look indicates that PropertySetter is only using defaults when configuring the classpaths, and this fails when OS X creates symlinks 1.4 -> 1.6 and 1.5 -> 1.6.
      We should investigate whether the current JAR inspection logic works on OS X with Apple JDKs as well (it is currently used for Sun and IBM JDKs, as well as for other / unknown JDKs).

      Issue was reported on derby-dev (see http://db.markmail.org/thread/wqe73b27rknuezm7 ).
      See also this thread for a related issue that may affect OS X: http://markmail.org/thread/7w24qwmvgxfctndi

      1. 1.6.0allfiles.txt
        25 kB
        Kathey Marsden
      2. 1.6.0dirStructure.txt
        1 kB
        Kathey Marsden
      3. antPrintCompilerPropertiesVerbose.txt
        6 kB
        Kathey Marsden
      4. antwithlibset.txt
        13 kB
        Kathey Marsden
      5. antwithpatch_diff.txt
        3 kB
        Kathey Marsden
      6. derby-4694-1a.diff
        13 kB
        Kristian Waagan
      7. derby-4694-2a-debugging.diff
        5 kB
        Kristian Waagan
      8. derby-4694-2b-debugging_and_mac_fix.diff
        6 kB
        Kristian Waagan

        Activity

        Hide
        Kristian Waagan added a comment -

        Attaching patch 1a.

        This changes the way JDKs are located when running on OS X. Up until now the defaults were used, with the patch a search will be performed like for other operating systems.

        Please take the patch for a test-drive if you develop on OS X
        I'm interested in two cases:

        • "mature" OS X installations with JDK 1.4 and 1.5 installed
        • fresh OS X installations where JDK 1.4 and JDK 1.4 are pointing to JDK 1.6.
          For both of these it may be good to test with JAVA_HOME pointing to 1.5 [1] and 1.6 [2]. On fresh installs this shouldn't matter, but let's test it first...

        Patch ready for review.

        [1] /System/Library/Frameworks/JavaVM.framework/Versions/1.5/Home
        [2] /System/Library/Frameworks/JavaVM.framework/Versions/1.6/Home

        Show
        Kristian Waagan added a comment - Attaching patch 1a. This changes the way JDKs are located when running on OS X. Up until now the defaults were used, with the patch a search will be performed like for other operating systems. Please take the patch for a test-drive if you develop on OS X I'm interested in two cases: "mature" OS X installations with JDK 1.4 and 1.5 installed fresh OS X installations where JDK 1.4 and JDK 1.4 are pointing to JDK 1.6. For both of these it may be good to test with JAVA_HOME pointing to 1.5 [1] and 1.6 [2] . On fresh installs this shouldn't matter, but let's test it first... Patch ready for review. [1] /System/Library/Frameworks/JavaVM.framework/Versions/1.5/Home [2] /System/Library/Frameworks/JavaVM.framework/Versions/1.6/Home
        Hide
        Rick Hillegas added a comment -

        Thanks for the patch, Kristian. I have tried it out on my machine, which is what you would call a "mature" OS X installation. I have tried both experiments and have successfully built Derby (and run a heartbeat test) using both a Java 5 and a Java 6 environment. Looks good to me. Thanks.

        Show
        Rick Hillegas added a comment - Thanks for the patch, Kristian. I have tried it out on my machine, which is what you would call a "mature" OS X installation. I have tried both experiments and have successfully built Derby (and run a heartbeat test) using both a Java 5 and a Java 6 environment. Looks good to me. Thanks.
        Hide
        Kristian Waagan added a comment -

        Thanks, Rick.

        Since the build breaks anyway for those running with freshly installed OS X (of a recent version), I committed patch 1a to trunk with revision 958555.
        I'll give it some time before I backport it to 10.6 (not sure about 10.5 yet).

        Show
        Kristian Waagan added a comment - Thanks, Rick. Since the build breaks anyway for those running with freshly installed OS X (of a recent version), I committed patch 1a to trunk with revision 958555. I'll give it some time before I backport it to 10.6 (not sure about 10.5 yet).
        Hide
        Kristian Waagan added a comment -

        Attaching a patch adding extra verbose debugging. Enable with -DprintCompilerPropertiesVerbose=true

        Show
        Kristian Waagan added a comment - Attaching a patch adding extra verbose debugging. Enable with -DprintCompilerPropertiesVerbose=true
        Hide
        Kathey Marsden added a comment -

        See related discussion at: http://old.nabble.com/build-on-iMac-OS-X-10.6-ts29031016.html

        Changing the summary and environment to include Mac as I was having trouble finding this bug last night

        Show
        Kathey Marsden added a comment - See related discussion at: http://old.nabble.com/build-on-iMac-OS-X-10.6-ts29031016.html Changing the summary and environment to include Mac as I was having trouble finding this bug last night
        Hide
        Kathey Marsden added a comment -

        Unfortunately, I seem to be having some trouble applying the patch which seemed to be saved with some garbage on my machine. Probably more mac newbiness. I will work on that this evening after i get back from the office. Below are some of the ls's. I don't know what the A business is. There seem to be real files under there, not just links.

        Katherine-Marsdens-iMac:trunk kmarsden$ ls -l /System/Library/Frameworks/JavaVM.framework/Versions
        total 64
        lrwxr-xr-x 1 root wheel 5 Jun 20 08:54 1.3 -> 1.3.1
        drwxr-xr-x 3 root wheel 102 May 28 2009 1.3.1
        lrwxr-xr-x 1 root wheel 10 Jun 20 08:54 1.4 -> CurrentJDK
        lrwxr-xr-x 1 root wheel 10 Jun 20 08:54 1.4.2 -> CurrentJDK
        lrwxr-xr-x 1 root wheel 10 Jun 20 08:54 1.5 -> CurrentJDK
        lrwxr-xr-x 1 root wheel 10 Jun 20 08:54 1.5.0 -> CurrentJDK
        lrwxr-xr-x 1 root wheel 5 Jun 20 08:54 1.6 -> 1.6.0
        drwxr-xr-x 7 root wheel 238 Nov 19 2009 1.6.0
        drwxr-xr-x 8 root wheel 272 Jun 20 08:57 A
        lrwxr-xr-x 1 root wheel 1 Jun 20 08:54 Current -> A
        lrwxr-xr-x 1 root wheel 3 Jun 20 08:54 CurrentJDK -> 1.6

        Katherine-Marsdens-iMac:patches kmarsden$ ls -l /System/Library/Frameworks/JavaVM.framework/Versions/A
        total 160
        lrwxr-xr-x 1 root wheel 28 Jun 20 08:54 CodeResources -> _CodeSignature/CodeResources
        drwxr-xr-x 42 root wheel 1428 Jun 20 08:57 Commands
        drwxr-xr-x 4 root wheel 136 May 18 2009 Frameworks
        -rwxr-xr-x 1 root wheel 209888 May 6 22:20 JavaVM
        drwxr-xr-x 32 root wheel 1088 Jun 20 08:57 Resources
        drwxr-xr-x 3 root wheel 102 Jun 20 08:57 _CodeSignature

        rwxr-xr-x 1 root wheel 74 Jun 20 08:54 /usr/bin/java -> /System/Library/Frameworks/JavaVM.framework/Versions/Current/Commands/java

        Katherine-Marsdens-iMac:patches kmarsden$ ls -l /System/Library/Frameworks/JavaVM.framework/Versions/Current/Commands/java
        -rwxr-xr-x 1 root wheel 72928 Apr 23 09:15 /System/Library/Frameworks/JavaVM.framework/Versions/Current/Commands/java

        Show
        Kathey Marsden added a comment - Unfortunately, I seem to be having some trouble applying the patch which seemed to be saved with some garbage on my machine. Probably more mac newbiness. I will work on that this evening after i get back from the office. Below are some of the ls's. I don't know what the A business is. There seem to be real files under there, not just links. Katherine-Marsdens-iMac:trunk kmarsden$ ls -l /System/Library/Frameworks/JavaVM.framework/Versions total 64 lrwxr-xr-x 1 root wheel 5 Jun 20 08:54 1.3 -> 1.3.1 drwxr-xr-x 3 root wheel 102 May 28 2009 1.3.1 lrwxr-xr-x 1 root wheel 10 Jun 20 08:54 1.4 -> CurrentJDK lrwxr-xr-x 1 root wheel 10 Jun 20 08:54 1.4.2 -> CurrentJDK lrwxr-xr-x 1 root wheel 10 Jun 20 08:54 1.5 -> CurrentJDK lrwxr-xr-x 1 root wheel 10 Jun 20 08:54 1.5.0 -> CurrentJDK lrwxr-xr-x 1 root wheel 5 Jun 20 08:54 1.6 -> 1.6.0 drwxr-xr-x 7 root wheel 238 Nov 19 2009 1.6.0 drwxr-xr-x 8 root wheel 272 Jun 20 08:57 A lrwxr-xr-x 1 root wheel 1 Jun 20 08:54 Current -> A lrwxr-xr-x 1 root wheel 3 Jun 20 08:54 CurrentJDK -> 1.6 Katherine-Marsdens-iMac:patches kmarsden$ ls -l /System/Library/Frameworks/JavaVM.framework/Versions/A total 160 lrwxr-xr-x 1 root wheel 28 Jun 20 08:54 CodeResources -> _CodeSignature/CodeResources drwxr-xr-x 42 root wheel 1428 Jun 20 08:57 Commands drwxr-xr-x 4 root wheel 136 May 18 2009 Frameworks -rwxr-xr-x 1 root wheel 209888 May 6 22:20 JavaVM drwxr-xr-x 32 root wheel 1088 Jun 20 08:57 Resources drwxr-xr-x 3 root wheel 102 Jun 20 08:57 _CodeSignature rwxr-xr-x 1 root wheel 74 Jun 20 08:54 /usr/bin/java -> /System/Library/Frameworks/JavaVM.framework/Versions/Current/Commands/java Katherine-Marsdens-iMac:patches kmarsden$ ls -l /System/Library/Frameworks/JavaVM.framework/Versions/Current/Commands/java -rwxr-xr-x 1 root wheel 72928 Apr 23 09:15 /System/Library/Frameworks/JavaVM.framework/Versions/Current/Commands/java
        Hide
        Kristian Waagan added a comment -

        Hi Kathey,

        The patch was invalid, I had by mistake issued "svndiff" instead of "svn diff" to generate the patch. The former generates terminal control characters (and was piped through less...)
        Sorry for the hassle, I uploaded a new patch.

        The layout on your Mac looks like expected (but not exactly intuitive!).
        If you revert back to before patch 1a went in, your build will probably fail as it did for Brett because 1.4 and 1.5 are symlinked to 1.6.
        I do not yet understand why PropertySetter fails to pick up the JDK in 1.6.0 on your machine. It worked on my Mac Mini and on Rick's laptop, but those OS X installations were not brand new. Hopefully the verbose debugging info can tell us where things go wrong.

        Show
        Kristian Waagan added a comment - Hi Kathey, The patch was invalid, I had by mistake issued "svndiff" instead of "svn diff" to generate the patch. The former generates terminal control characters (and was piped through less...) Sorry for the hassle, I uploaded a new patch. The layout on your Mac looks like expected (but not exactly intuitive!). If you revert back to before patch 1a went in, your build will probably fail as it did for Brett because 1.4 and 1.5 are symlinked to 1.6. I do not yet understand why PropertySetter fails to pick up the JDK in 1.6.0 on your machine. It worked on my Mac Mini and on Rick's laptop, but those OS X installations were not brand new. Hopefully the verbose debugging info can tell us where things go wrong.
        Hide
        Kathey Marsden added a comment -

        Hi Kristian,

        Here is the output with the patch. I have not looked at PropertySetter before. It is interesting the directories it comes up with. Please let me know if you would like me to put some effort into debugging.

        Show
        Kathey Marsden added a comment - Hi Kristian, Here is the output with the patch. I have not looked at PropertySetter before. It is interesting the directories it comes up with. Please let me know if you would like me to put some effort into debugging.
        Hide
        Kristian Waagan added a comment -

        Hi Kathey,

        I'm a bit puzzled, the output you uploaded isn't as I expected it to be.
        Are you sure you applied patch 2a, ran with the new property -DprintCompilerPropertiesVerbose=true (note the extra 'Verbose') and uploaded the correct file?

        When enbled you should see lines with "[verbose]" in them (near the start of the line, after another tag).

        It would be very helpful if you could try again, since I don't have access to a Mac like yours.

        Thanks,

        Show
        Kristian Waagan added a comment - Hi Kathey, I'm a bit puzzled, the output you uploaded isn't as I expected it to be. Are you sure you applied patch 2a, ran with the new property -DprintCompilerPropertiesVerbose=true (note the extra 'Verbose') and uploaded the correct file? When enbled you should see lines with " [verbose] " in them (near the start of the line, after another tag). It would be very helpful if you could try again, since I don't have access to a Mac like yours. Thanks,
        Hide
        Kathey Marsden added a comment -

        Sorry Kristian, I did not have the verbose property set. This is the output with the following in my local.properties file:
        printCompilerProperties=true
        printCompilerPropertiesVerbose=true

        I did not look at the actual output but did confirm [verbose] lines are there.

        Show
        Kathey Marsden added a comment - Sorry Kristian, I did not have the verbose property set. This is the output with the following in my local.properties file: printCompilerProperties=true printCompilerPropertiesVerbose=true I did not look at the actual output but did confirm [verbose] lines are there.
        Hide
        Kristian Waagan added a comment -

        Thanks Kathey,

        Seems your JDK installation doesn't have the "Headers" directory. I have no idea why... Note that the JDK 1.6 installation is first detected through the 1.4 symlink (which is fine).
        There are basically only two options:
        a) the verification criteria are too strict (i.e. we can remove Headers from the list of required directories)
        b) your JDK installation is damaged

        I don't have a formal description of how an Apple JDK should look like, I based my list on existing installations.
        Can you post the directory structure of your JDK 1.6 installation?
        It would be nice if someone else with a recently new Mac could confirm these findings, but if we don't get any feedback I suggest we go for option (a).

        Kathey, if you set 'j16lib' (~/ant.properties or ./local.properties) explicitly, can you build Derby?

        Show
        Kristian Waagan added a comment - Thanks Kathey, Seems your JDK installation doesn't have the "Headers" directory. I have no idea why... Note that the JDK 1.6 installation is first detected through the 1.4 symlink (which is fine). There are basically only two options: a) the verification criteria are too strict (i.e. we can remove Headers from the list of required directories) b) your JDK installation is damaged I don't have a formal description of how an Apple JDK should look like, I based my list on existing installations. Can you post the directory structure of your JDK 1.6 installation? It would be nice if someone else with a recently new Mac could confirm these findings, but if we don't get any feedback I suggest we go for option (a). Kathey, if you set 'j16lib' (~/ant.properties or ./local.properties) explicitly, can you build Derby?
        Hide
        Kathey Marsden added a comment - - edited

        I am sorry Kristian, I missed your earlier comment. Here are the files in in 1.6.0. It doesn't even have an rt.jar, so definitely not what I am used to. I tried setting

        jdkdir=/System/Library/Frameworks/JavaVM.framework/Versions
        jdk16=$

        {jdkdir}

        /1.6.0
        j16lib=$

        {jdk16}

        /1.6.0/Home/Classes

        with no luck. I will try for a little bit longer before I go into the office in about 20 minutes.
        If my installation is corrupt, it must have happened in the factory as I have not mucked with it except for the ls's.

        Show
        Kathey Marsden added a comment - - edited I am sorry Kristian, I missed your earlier comment. Here are the files in in 1.6.0. It doesn't even have an rt.jar, so definitely not what I am used to. I tried setting jdkdir=/System/Library/Frameworks/JavaVM.framework/Versions jdk16=$ {jdkdir} /1.6.0 j16lib=$ {jdk16} /1.6.0/Home/Classes with no luck. I will try for a little bit longer before I go into the office in about 20 minutes. If my installation is corrupt, it must have happened in the factory as I have not mucked with it except for the ls's.
        Hide
        Kathey Marsden added a comment -

        This is my latest run with local.properties:

        printCompilerProperties=true
        printCompilerPropertiesVerbose=true
        jdkdir=/System/Library/Frameworks/JavaVM.framework/Versions
        jdk16=$

        {jdkdir}/1.6.0
        j16lib=${jdk16}/Home/lib
        j15lib=${jdkdir}

        /1.5/Home/lib
        j14lib=$

        {jdkdir}

        /1.4.2/Home/lib

        I will look some more when I get home. Sorry this has come in such small hurried spurts.

        Show
        Kathey Marsden added a comment - This is my latest run with local.properties: printCompilerProperties=true printCompilerPropertiesVerbose=true jdkdir=/System/Library/Frameworks/JavaVM.framework/Versions jdk16=$ {jdkdir}/1.6.0 j16lib=${jdk16}/Home/lib j15lib=${jdkdir} /1.5/Home/lib j14lib=$ {jdkdir} /1.4.2/Home/lib I will look some more when I get home. Sorry this has come in such small hurried spurts.
        Hide
        Kristian Waagan added a comment -

        Kathey, I think your best option is to modify PropertySetter to remove the check for the Headers directory [1]. If that makes the build succeed, than I guess we should just remove the check for that directory.

        [1] Just delete the line ' new File(f, APPLE_HEADERS_DIR),'

        Show
        Kristian Waagan added a comment - Kathey, I think your best option is to modify PropertySetter to remove the check for the Headers directory [1] . If that makes the build succeed, than I guess we should just remove the check for that directory. [1] Just delete the line ' new File(f, APPLE_HEADERS_DIR),'
        Hide
        Kathey Marsden added a comment -

        Thanks. I will try that and try to pick a time when I have more than 2 minutes to work on it to hash it out. I wonder if something will also be required to have it look for classes.jar instead of rt.jar.

        Show
        Kathey Marsden added a comment - Thanks. I will try that and try to pick a time when I have more than 2 minutes to work on it to hash it out. I wonder if something will also be required to have it look for classes.jar instead of rt.jar.
        Hide
        Kristian Waagan added a comment -

        Thanks, Kathey.

        Your concern regarding classes.jar has already been taken care of (as part of the commit on/around 28th of June), unless the script is so confused that it doesn't even understand that it's on a Mac

        Show
        Kristian Waagan added a comment - Thanks, Kathey. Your concern regarding classes.jar has already been taken care of (as part of the commit on/around 28th of June), unless the script is so confused that it doesn't even understand that it's on a Mac
        Hide
        Kathey Marsden added a comment -

        Removing the Header requirement did not help.

        I will take a look and see why classes.jar is not getting picked up. I think it knows it is a mac because from antwithlibset.txt it sets:
        setJdkProperties] Setting property java16compile.classpath to /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home/lib/deploy.jar:/System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home/lib/dt.jar:/System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home/lib/javaws.jar:/System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home/lib/jce.jar:/System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home/lib/management-agent.jar:/System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home/lib/plugin.jar:/System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home/lib/sa-jdi.jar

        but is missing classes.jar and the final fatal error is caused by the lack of it.
        Fatal Error: Unable to find package java.lang in classpath or bootclasspath

        It seems unhappy about the strange A directory
        -> '/System/Library/Frameworks/JavaVM.framework/Versions/A'
        [setJdkProperties] [verbose] rejected
        ...
        [setJdkProperties] [verbose] checking root '/System/Library/Frameworks/JavaVM.framework/Versions/A'
        [setJdkProperties] Missing JDK directory: /System/Library/Frameworks/JavaVM.framework/Versions/A/Classes

        Katherine-Marsdens-iMac:A kmarsden$ ls -l /System/Library/Frameworks/JavaVM.framework/Versions/A
        total 160
        lrwxr-xr-x 1 root wheel 28 Jun 20 08:54 CodeResources -> _CodeSignature/CodeResources
        drwxr-xr-x 42 root wheel 1428 Jun 20 08:57 Commands
        drwxr-xr-x 4 root wheel 136 May 18 2009 Frameworks
        -rwxr-xr-x 1 root wheel 209888 May 6 22:20 JavaVM
        drwxr-xr-x 32 root wheel 1088 Jun 20 08:57 Resources
        drwxr-xr-x 3 root wheel 102 Jun 20 08:57 _CodeSignature
        Katherine-Marsdens-iMac:A kmarsden$ pwd

        Do you know what Versions/A is supposed to be? Is it important to the build or can we just stick with the actual versions. It doesn't look like a JDK in there.

        Show
        Kathey Marsden added a comment - Removing the Header requirement did not help. I will take a look and see why classes.jar is not getting picked up. I think it knows it is a mac because from antwithlibset.txt it sets: setJdkProperties] Setting property java16compile.classpath to /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home/lib/deploy.jar:/System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home/lib/dt.jar:/System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home/lib/javaws.jar:/System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home/lib/jce.jar:/System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home/lib/management-agent.jar:/System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home/lib/plugin.jar:/System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home/lib/sa-jdi.jar but is missing classes.jar and the final fatal error is caused by the lack of it. Fatal Error: Unable to find package java.lang in classpath or bootclasspath It seems unhappy about the strange A directory -> '/System/Library/Frameworks/JavaVM.framework/Versions/A' [setJdkProperties] [verbose] rejected ... [setJdkProperties] [verbose] checking root '/System/Library/Frameworks/JavaVM.framework/Versions/A' [setJdkProperties] Missing JDK directory: /System/Library/Frameworks/JavaVM.framework/Versions/A/Classes Katherine-Marsdens-iMac:A kmarsden$ ls -l /System/Library/Frameworks/JavaVM.framework/Versions/A total 160 lrwxr-xr-x 1 root wheel 28 Jun 20 08:54 CodeResources -> _CodeSignature/CodeResources drwxr-xr-x 42 root wheel 1428 Jun 20 08:57 Commands drwxr-xr-x 4 root wheel 136 May 18 2009 Frameworks -rwxr-xr-x 1 root wheel 209888 May 6 22:20 JavaVM drwxr-xr-x 32 root wheel 1088 Jun 20 08:57 Resources drwxr-xr-x 3 root wheel 102 Jun 20 08:57 _CodeSignature Katherine-Marsdens-iMac:A kmarsden$ pwd Do you know what Versions/A is supposed to be? Is it important to the build or can we just stick with the actual versions. It doesn't look like a JDK in there.
        Hide
        Kathey Marsden added a comment -

        If I remove the Header directory check and remove the *lib settings in my local.properties it all builds ok. Hooray!

        I also tried changing local.properties as follows which failed with abstract method errors:

        printCompilerProperties=true
        printCompilerPropertiesVerbose=true
        jdkdir=/System/Library/Frameworks/JavaVM.framework/Versions
        jdk16=$

        {jdkdir}/1.6.0
        16lib=${jdk16}/Classes
        j15lib=${jdkdir}

        /1.5/Classes
        j14lib=$

        {jdkdir}

        /1.4.2/Classes

        e.g. [javac] /Users/kmarsden/Derby/svn/trunk/java/engine/org/apache/derby/impl/jdbc/EmbedResultSetMetaData.java:59: org.apache.derby.impl.jdbc.EmbedResultSetMetaData is not abstract and does not override abstract method isWrapperFor(java.lang.Class) in java.sql.Wrappe
        r

        I think this makes sense as if you are using the lib settings, it is an indication that you want such checking done.

        Show
        Kathey Marsden added a comment - If I remove the Header directory check and remove the *lib settings in my local.properties it all builds ok. Hooray! I also tried changing local.properties as follows which failed with abstract method errors: printCompilerProperties=true printCompilerPropertiesVerbose=true jdkdir=/System/Library/Frameworks/JavaVM.framework/Versions jdk16=$ {jdkdir}/1.6.0 16lib=${jdk16}/Classes j15lib=${jdkdir} /1.5/Classes j14lib=$ {jdkdir} /1.4.2/Classes e.g. [javac] /Users/kmarsden/Derby/svn/trunk/java/engine/org/apache/derby/impl/jdbc/EmbedResultSetMetaData.java:59: org.apache.derby.impl.jdbc.EmbedResultSetMetaData is not abstract and does not override abstract method isWrapperFor(java.lang.Class) in java.sql.Wrappe r I think this makes sense as if you are using the lib settings, it is an indication that you want such checking done.
        Hide
        Kristian Waagan added a comment - - edited

        Attached patch 2b, committed to trunk with revision 963206.

        The patch removes the check for the 'Headers' directory inside the JDK root, and changes some of the text emitted by the verbose debugging (accepted -> candidate, rejected -> duplicate).

        Show
        Kristian Waagan added a comment - - edited Attached patch 2b, committed to trunk with revision 963206. The patch removes the check for the 'Headers' directory inside the JDK root, and changes some of the text emitted by the verbose debugging (accepted -> candidate, rejected -> duplicate).
        Hide
        Kristian Waagan added a comment -

        I don't think PropertySetter was written to thoroughly verify the settings set by the user, it will only add the jar files found in the specified JDK directories.
        In your case, you are pointing the j14lib and j15lib at a JDK 1.6 installation - which is why the compiler complains about the missing isWrapperFor method.

        Show
        Kristian Waagan added a comment - I don't think PropertySetter was written to thoroughly verify the settings set by the user, it will only add the jar files found in the specified JDK directories. In your case, you are pointing the j14lib and j15lib at a JDK 1.6 installation - which is why the compiler complains about the missing isWrapperFor method.
        Hide
        Brett Wooldridge added a comment -

        It is in fact Apple (OS X) that ships with symbolic links from JDK 1.4/1.5 to JDK 1.6. For newer fresh installs (certainly Snow Leopard, maybe Leopard) this is the default.

        Show
        Brett Wooldridge added a comment - It is in fact Apple (OS X) that ships with symbolic links from JDK 1.4/1.5 to JDK 1.6. For newer fresh installs (certainly Snow Leopard, maybe Leopard) this is the default.
        Hide
        Kristian Waagan added a comment -

        I'm aware of that, the point was that the script won't try to "correct" the user if invalid values for the various JDK versions are specified. If a user on a fresh OS X install specifies the lib directories in ant.properties/local.properties, doing the intuitive thing will cause Derby to fail due to the symlinking.
        If no JDK paths are specified in the property files, the script should understand what Apple has chosen to do (effectively only using JDK 1.6).

        Brett, can you confirm the the script works in your environment as well?
        And, out of curiosity, does your JDK installation have a 'Headers' directory?

        Thanks,

        Show
        Kristian Waagan added a comment - I'm aware of that, the point was that the script won't try to "correct" the user if invalid values for the various JDK versions are specified. If a user on a fresh OS X install specifies the lib directories in ant.properties/local.properties, doing the intuitive thing will cause Derby to fail due to the symlinking. If no JDK paths are specified in the property files, the script should understand what Apple has chosen to do (effectively only using JDK 1.6). Brett, can you confirm the the script works in your environment as well? And, out of curiosity, does your JDK installation have a 'Headers' directory? Thanks,
        Hide
        Kathey Marsden added a comment -

        I wanted to mention that at long last, I reverted my changes, updated trunk and all built fine without setting any properties. Thank you Kristian! I still can't run tests with jars because of the DERBY-4739 hang, but happy to be building. I don't have time to debug DERBY-4739 thoroughly now, but Lily and I did look at it for a few minutes the other day. I will post our findings to that issue.

        Show
        Kathey Marsden added a comment - I wanted to mention that at long last, I reverted my changes, updated trunk and all built fine without setting any properties. Thank you Kristian! I still can't run tests with jars because of the DERBY-4739 hang, but happy to be building. I don't have time to debug DERBY-4739 thoroughly now, but Lily and I did look at it for a few minutes the other day. I will post our findings to that issue.
        Hide
        Kristian Waagan added a comment -

        Closing issue.

        FYI, I can also confirm the hang on Max OS X (found while testing 10.6 RC).

        Show
        Kristian Waagan added a comment - Closing issue. FYI, I can also confirm the hang on Max OS X (found while testing 10.6 RC).
        Hide
        Kristian Waagan added a comment -

        Reopening for backport to 10.6 (merge isn't clean in 10.5).

        Backported to the 10.6 branch with revision 980035.

        Show
        Kristian Waagan added a comment - Reopening for backport to 10.6 (merge isn't clean in 10.5). Backported to the 10.6 branch with revision 980035.
        Hide
        Kristian Waagan added a comment -

        Closing again...

        Show
        Kristian Waagan added a comment - Closing again...

          People

          • Assignee:
            Kristian Waagan
            Reporter:
            Kristian Waagan
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development