Derby
  1. Derby
  2. DERBY-4263

PropertySetter isn't able to recognize JDK without version number in path

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 10.6.1.0
    • Fix Version/s: 10.6.1.0
    • Component/s: Build tools
    • Labels:
      None
    • Issue & fix info:
      Patch Available

      Description

      With empty ant.properties and JDK 6 installed in /tmp/jdk as the only JDK on the system, PropertySetter complains that it's not able to set java16compile.classpath:

      ,----

      [setJdkProperties]
      [setJdkProperties] PropertySetter environment =
      [setJdkProperties]
      [setJdkProperties] java.vendor = Sun Microsystems Inc.
      [setJdkProperties] java.home = /tmp/jdk/jre
      [setJdkProperties] java.version = 1.6.0_13
      [setJdkProperties] os.name = SunOS
      [setJdkProperties] j14lib = null
      [setJdkProperties] j15lib = null
      [setJdkProperties] j16lib = null
      [setJdkProperties]
      BUILD FAILED
      /code/derby/trunk0/build.xml:203: Don't know how to set java15compile.classpath, java16compile.classpath using this environment:
      java.vendor = Sun Microsystems Inc.
      java.home = /tmp/jdk/jre
      java.version = 1.6.0_13
      os.name = SunOS
      j14lib = null
      j15lib = null
      j16lib = null
      `----

      Since it is able to detect both that the version of the default JDK is 1.6.0_13 and where it is installed, setting java16compile.classpath should be trivial.

      If the name of the JDK directory is changed from /tmp/jdk to /tmp/jdk1.6.0, Derby is built successfully.

        Activity

        Hide
        Kristian Waagan added a comment -

        I think the only reason was to be cautious. Building Derby with an early access JDK could potentially introduce strange bugs.
        Another minor point is that in general one wouldn't want to use an early access build over a know production quality build that's accessible on the system.

        Nothing in the build system should break if we allow early access JDKs, but if it does anyway it's probably because the early access build is too far away from production quality.

        Since I'm assuming this question is raised due to the JDK 1.7 on Mac issue, I want to point out that fixing the early access build is only one of the steps required to be able to build with JDK 1.7 only (this goes for all platforms).

        Show
        Kristian Waagan added a comment - I think the only reason was to be cautious. Building Derby with an early access JDK could potentially introduce strange bugs. Another minor point is that in general one wouldn't want to use an early access build over a know production quality build that's accessible on the system. Nothing in the build system should break if we allow early access JDKs, but if it does anyway it's probably because the early access build is too far away from production quality. Since I'm assuming this question is raised due to the JDK 1.7 on Mac issue, I want to point out that fixing the early access build is only one of the steps required to be able to build with JDK 1.7 only (this goes for all platforms).
        Hide
        Rick Hillegas added a comment -

        Early access JDKs are ignored by PropertySetter due to logic added by derby-4263-1b-jdk_detection_by_jars.diff patch (committed on 2009-08-07 at subversion revision 801924). What was the motivation for ignoring early access JDKs? Put another way, what would break if we removed the logic which ignores early access JDKs? Thanks-Rick

        Show
        Rick Hillegas added a comment - Early access JDKs are ignored by PropertySetter due to logic added by derby-4263-1b-jdk_detection_by_jars.diff patch (committed on 2009-08-07 at subversion revision 801924). What was the motivation for ignoring early access JDKs? Put another way, what would break if we removed the logic which ignores early access JDKs? Thanks-Rick
        Hide
        Derby Ciu added a comment -

        Even after applying the patch 1b given here, I am getting the same"Ant Build Failed error". Is there any workaround please?

        Show
        Derby Ciu added a comment - Even after applying the patch 1b given here, I am getting the same"Ant Build Failed error". Is there any workaround please?
        Hide
        Myrna van Lunteren added a comment -

        The patch was committed and has been in the codeline for quite a while. (click on 'All' or 'Subversion Commits' in JIRA to see the commits).
        And the final problem I saw (with the MANIFEST.MF file in IBM SR5) was fixed by IBM in the 1.6 SR7 point release.
        Sounds like you are seeing a different problem.
        I suggest you run read the BUILDING.html carefully, if that gives no ideas, run ant with -DprintCompilerProperties=true (or set printCompilerProperties=true in $HOME/ant.properties or <topoftree>/local.properties) and send an email to the derby dev list (derby-dev@db.apache.org) with the output.
        JIRA is for bugs, sounds like you are only running into some setup hurdles.

        Show
        Myrna van Lunteren added a comment - The patch was committed and has been in the codeline for quite a while. (click on 'All' or 'Subversion Commits' in JIRA to see the commits). And the final problem I saw (with the MANIFEST.MF file in IBM SR5) was fixed by IBM in the 1.6 SR7 point release. Sounds like you are seeing a different problem. I suggest you run read the BUILDING.html carefully, if that gives no ideas, run ant with -DprintCompilerProperties=true (or set printCompilerProperties=true in $HOME/ant.properties or <topoftree>/local.properties) and send an email to the derby dev list (derby-dev@db.apache.org) with the output. JIRA is for bugs, sounds like you are only running into some setup hurdles.
        Hide
        Derby Ciu added a comment -

        I am facing a similar "Ant Build Failed" issue complaining that it does not know to set compiler15.classpath and compiler16.classpath using my environment. How do I apply the given patch?

        Show
        Derby Ciu added a comment - I am facing a similar "Ant Build Failed" issue complaining that it does not know to set compiler15.classpath and compiler16.classpath using my environment. How do I apply the given patch?
        Hide
        Myrna van Lunteren added a comment -

        I've logged a complaint regarding the strange 1.6 (SR5) MANIFEST.MF file; in the mean time I've got things working again, so I suggest we leave things as is for now.

        Show
        Myrna van Lunteren added a comment - I've logged a complaint regarding the strange 1.6 (SR5) MANIFEST.MF file; in the mean time I've got things working again, so I suggest we leave things as is for now.
        Hide
        Kristian Waagan added a comment -

        Thanks, Myrna.

        I'm on vacation right now, but will look more into this when I come back.
        Note that the new algorithm relies on meta data recorded in the jar files of the JDK distribution - it doesn't actually start the VM to extract it.
        We could do that, but I thought that will be more expensive than just doing a few file checks on the file system.

        My quick notes from the IBM JDKs:

        • To pick IBM, you have to run IBM (as the VM invoking ant)
        • I didn't know exactly which JAR file(s) to check for the IBM JDKs, all I found had incomplete information (i.e. no vendor)
        • Versions differ (i.e. 1.6.0 vs 6.0).

        It may be that the logic for IBM JDK 6 is simply broken, due to the missing vendor and the different version string.

        Show
        Kristian Waagan added a comment - Thanks, Myrna. I'm on vacation right now, but will look more into this when I come back. Note that the new algorithm relies on meta data recorded in the jar files of the JDK distribution - it doesn't actually start the VM to extract it. We could do that, but I thought that will be more expensive than just doing a few file checks on the file system. My quick notes from the IBM JDKs: To pick IBM, you have to run IBM (as the VM invoking ant) I didn't know exactly which JAR file(s) to check for the IBM JDKs, all I found had incomplete information (i.e. no vendor) Versions differ (i.e. 1.6.0 vs 6.0). It may be that the logic for IBM JDK 6 is simply broken, due to the missing vendor and the different version string.
        Hide
        Myrna van Lunteren added a comment -

        Well, I needed to do the cleanup to figure out what was actually happening.

        So, there is one strange thing; it is reporting this for my IBM 1.6 jvm (SR5 sdk, I've got a couple of the same installs in different directories)
        [setJdkProperties] found JDK: vendor=unknown, specVersion=unknown, implVersion=6.0, path=c:\jvms\ibm16

        While for the 1.5 ibm jvms it reports:
        [setJdkProperties] found JDK: vendor=IBM Corporation, specVersion=1.5.0, implVersion=1.5.0, path=c:\jvms\ibm15

        Note, that if I just try to run my trusty, rusty program that spits out all properties set by the jvm, it reports
        key: java.vm.vendor ;value: IBM Corporation
        key: java.vendor ;value: IBM Corporation
        key: java.specification.version ;value: 1.6
        key: java.vm.specification.version ;value: 1.0
        key: java.specification.name ;value: Java Platform API Specification

        My build was setup up without setting java16compile.classpath (to the ibm16 jars) before the change. If I physically remove the sun jdk 1.6 I have, It does pick up the ibm jvm and my build works as before...(i.e. pick up the IBM 1.6 that's there).
        If I set java16compileclasspath it also picks up the ibm16.
        The sun 1.6 is [setJdkProperties] found JDK: vendor=Sun Microsystems, Inc., specVersion=1.6, implVersion=1.6.0_01, path=c:\jvmsjdk16
        (java -version gives: java version "1.6.0_01"
        Java(TM) SE Runtime Environment (build 1.6.0_01-b06)
        Java HotSpot(TM) Client VM (build 1.6.0_01-b06, mixed mode) )

        A little debugging and it seems the propertySetter thinks my (1.6) vendor is null.
        I'll try to find some time to debug this further, figure out why.

        Show
        Myrna van Lunteren added a comment - Well, I needed to do the cleanup to figure out what was actually happening. So, there is one strange thing; it is reporting this for my IBM 1.6 jvm (SR5 sdk, I've got a couple of the same installs in different directories) [setJdkProperties] found JDK: vendor=unknown, specVersion=unknown, implVersion=6.0, path=c:\jvms\ibm16 While for the 1.5 ibm jvms it reports: [setJdkProperties] found JDK: vendor=IBM Corporation, specVersion=1.5.0, implVersion=1.5.0, path=c:\jvms\ibm15 Note, that if I just try to run my trusty, rusty program that spits out all properties set by the jvm, it reports key: java.vm.vendor ;value: IBM Corporation key: java.vendor ;value: IBM Corporation key: java.specification.version ;value: 1.6 key: java.vm.specification.version ;value: 1.0 key: java.specification.name ;value: Java Platform API Specification My build was setup up without setting java16compile.classpath (to the ibm16 jars) before the change. If I physically remove the sun jdk 1.6 I have, It does pick up the ibm jvm and my build works as before...(i.e. pick up the IBM 1.6 that's there). If I set java16compileclasspath it also picks up the ibm16. The sun 1.6 is [setJdkProperties] found JDK: vendor=Sun Microsystems, Inc., specVersion=1.6, implVersion=1.6.0_01, path=c:\jvmsjdk16 (java -version gives: java version "1.6.0_01" Java(TM) SE Runtime Environment (build 1.6.0_01-b06) Java HotSpot(TM) Client VM (build 1.6.0_01-b06, mixed mode) ) A little debugging and it seems the propertySetter thinks my (1.6) vendor is null. I'll try to find some time to debug this further, figure out why.
        Hide
        Kristian Waagan added a comment -

        Do you mind posting the list of the JVMs detected? (as printed by the build script when using printCompilerProperties=true)
        I'd like to understand why the IBM JDK that used to get picked, dosen't anymore. My only educated guess would be that the metadata extracted from the JARs is incorrect / inaccurate and that the Sun JDK you have installed has version number considered to be higher - but I'd like to verify this. Of course, I'm assuming the running JVM (used to invoke the build script) is a IBM one.

        I don't have any plans to backport this change.

        Show
        Kristian Waagan added a comment - Do you mind posting the list of the JVMs detected? (as printed by the build script when using printCompilerProperties=true) I'd like to understand why the IBM JDK that used to get picked, dosen't anymore. My only educated guess would be that the metadata extracted from the JARs is incorrect / inaccurate and that the Sun JDK you have installed has version number considered to be higher - but I'd like to verify this. Of course, I'm assuming the running JVM (used to invoke the build script) is a IBM one. I don't have any plans to backport this change.
        Hide
        Myrna van Lunteren added a comment - - edited

        The difference was that after your change, it picked a Sun 1.6 instead of an IBM 1.6 jvm.

        The environment where I saw this was using a somewhat convoluted setup, building a number of things, not just derby. Building derby not directly but using ant from the command line, but from another build file, using ant call to the 'all' target of the trunk's top level build.xml.
        Properties are not set in ant.properties but are set in this "wrapper" build file.

        I need to go and revamp that build setup - there's some cleanup that can be done / is necessary...

        So it's ok.
        However, I'd not like this change to get backported.

        Show
        Myrna van Lunteren added a comment - - edited The difference was that after your change, it picked a Sun 1.6 instead of an IBM 1.6 jvm. The environment where I saw this was using a somewhat convoluted setup, building a number of things, not just derby. Building derby not directly but using ant from the command line, but from another build file, using ant call to the 'all' target of the trunk's top level build.xml. Properties are not set in ant.properties but are set in this "wrapper" build file. I need to go and revamp that build setup - there's some cleanup that can be done / is necessary... So it's ok. However, I'd not like this change to get backported.
        Hide
        Kristian Waagan added a comment -

        Hi Myrna,

        Maybe you could run with -DprintCompilerProperties=true and post the output from the target setting the classpaths?
        If you do that with trunk first, and then again after commenting out the lines mentioned below, we could compare and see what has changed. If it's the same, I must have changed something else in the build process.

        To go back to old behavior, assuming the required JDKs are available, comment out the calls to the method 'setForMostJDKsJARInspection' (only two of the three should do, but commenting out all three doesn't hurt).
        If you pipe to less, the interesting information should be found on the first page and onwards.

        Show
        Kristian Waagan added a comment - Hi Myrna, Maybe you could run with -DprintCompilerProperties=true and post the output from the target setting the classpaths? If you do that with trunk first, and then again after commenting out the lines mentioned below, we could compare and see what has changed. If it's the same, I must have changed something else in the build process. To go back to old behavior, assuming the required JDKs are available, comment out the calls to the method 'setForMostJDKsJARInspection' (only two of the three should do, but commenting out all three doesn't hurt). If you pipe to less, the interesting information should be found on the first page and onwards.
        Hide
        Myrna van Lunteren added a comment -

        Apologies for not testing out the patch - I was on vacation when you first posted it and it escaped my attention.

        Since this change, I see 7 extra warnings in the output (with the actual path to the top of trunk replaced by <...mypath...>)
        [javac] <...mypath...>\java\client\org\apache\derby\client\am\LogicalCallableStatement40.java:42: warning: [deprecation] setUnicodeStream(int,java.io.InputStream,int) in java.sql.PreparedStatement has been deprecated
        [javac] public class LogicalCallableStatement40
        [javac] ^
        [javac] <...mypath...>\java\client\org\apache\derby\client\am\LogicalCallableStatement40.java:42: warning: [deprecation] getBigDecimal(int,int) in java.sql.CallableStatement has been deprecated
        [javac] public class LogicalCallableStatement40
        [javac] ^
        [javac] <...mypath...>\java\client\org\apache\derby\client\am\LogicalCallableStatement40.java:42: warning: [deprecation] setUnicodeStream(int,java.io.InputStream,int) in java.sql.PreparedStatement has been deprecated
        [javac] public class LogicalCallableStatement40
        [javac] ^
        [javac] <...mypath...>\java\client\org\apache\derby\client\am\LogicalPreparedStatement40.java:41: warning: [deprecation] setUnicodeStream(int,java.io.InputStream,int) in java.sql.PreparedStatement has been deprecated
        [javac] public class LogicalPreparedStatement40
        [javac] ^
        [javac] <...mypath...>\java\client\org\apache\derby\client\am\LogicalCallableStatement40.java:42: warning: [deprecation] setUnicodeStream(int,java.io.InputStream,int) in java.sql.PreparedStatement has been deprecated
        [javac] public class LogicalCallableStatement40
        [javac] ^
        [javac] <...mypath...>\java\client\org\apache\derby\client\am\LogicalCallableStatement40.java:42: warning: [deprecation] getBigDecimal(int,int) in java.sql.CallableStatement has been deprecated
        [javac] public class LogicalCallableStatement40
        [javac] ^
        [javac] <...mypath...>\java\client\org\apache\derby\client\am\LogicalCallableStatement40.java:42: warning: [deprecation] setUnicodeStream(int,java.io.InputStream,int) in java.sql.PreparedStatement has been deprecated
        [javac] public class LogicalCallableStatement40

        I assume this is ok, we knew of this, but it's odd that this pops up even though I'm always running with -Ddeprecation=off, so I thought I'd mention it.

        Show
        Myrna van Lunteren added a comment - Apologies for not testing out the patch - I was on vacation when you first posted it and it escaped my attention. Since this change, I see 7 extra warnings in the output (with the actual path to the top of trunk replaced by <...mypath...>) [javac] <...mypath...>\java\client\org\apache\derby\client\am\LogicalCallableStatement40.java:42: warning: [deprecation] setUnicodeStream(int,java.io.InputStream,int) in java.sql.PreparedStatement has been deprecated [javac] public class LogicalCallableStatement40 [javac] ^ [javac] <...mypath...>\java\client\org\apache\derby\client\am\LogicalCallableStatement40.java:42: warning: [deprecation] getBigDecimal(int,int) in java.sql.CallableStatement has been deprecated [javac] public class LogicalCallableStatement40 [javac] ^ [javac] <...mypath...>\java\client\org\apache\derby\client\am\LogicalCallableStatement40.java:42: warning: [deprecation] setUnicodeStream(int,java.io.InputStream,int) in java.sql.PreparedStatement has been deprecated [javac] public class LogicalCallableStatement40 [javac] ^ [javac] <...mypath...>\java\client\org\apache\derby\client\am\LogicalPreparedStatement40.java:41: warning: [deprecation] setUnicodeStream(int,java.io.InputStream,int) in java.sql.PreparedStatement has been deprecated [javac] public class LogicalPreparedStatement40 [javac] ^ [javac] <...mypath...>\java\client\org\apache\derby\client\am\LogicalCallableStatement40.java:42: warning: [deprecation] setUnicodeStream(int,java.io.InputStream,int) in java.sql.PreparedStatement has been deprecated [javac] public class LogicalCallableStatement40 [javac] ^ [javac] <...mypath...>\java\client\org\apache\derby\client\am\LogicalCallableStatement40.java:42: warning: [deprecation] getBigDecimal(int,int) in java.sql.CallableStatement has been deprecated [javac] public class LogicalCallableStatement40 [javac] ^ [javac] <...mypath...>\java\client\org\apache\derby\client\am\LogicalCallableStatement40.java:42: warning: [deprecation] setUnicodeStream(int,java.io.InputStream,int) in java.sql.PreparedStatement has been deprecated [javac] public class LogicalCallableStatement40 I assume this is ok, we knew of this, but it's odd that this pops up even though I'm always running with -Ddeprecation=off, so I thought I'd mention it.
        Hide
        Kristian Waagan added a comment -

        Thanks, Rick.

        Committed patch 1b to trunk with revision 801924.
        I'm marking as fixed, but there is a chance the change will trigger problems for some people (depending on the JDKs they have installed). If so, please reopen or create a new issue (linking to this one).

        I chose to commit because the change will only affect developers (or those building Derby), and problems can be worked around by settings in ant.properties.

        Show
        Kristian Waagan added a comment - Thanks, Rick. Committed patch 1b to trunk with revision 801924. I'm marking as fixed, but there is a chance the change will trigger problems for some people (depending on the JDKs they have installed). If so, please reopen or create a new issue (linking to this one). I chose to commit because the change will only affect developers (or those building Derby), and problems can be worked around by settings in ant.properties.
        Hide
        Rick Hillegas added a comment -

        Thanks for the new patch, Kristian. It addresses my previous concerns. I don't know how to answer the question you posed at the end of your last comment. It seems to me that we may have to log some experience with this approach before we form an opinion. Thanks.

        Show
        Rick Hillegas added a comment - Thanks for the new patch, Kristian. It addresses my previous concerns. I don't know how to answer the question you posed at the end of your last comment. It seems to me that we may have to log some experience with this approach before we form an opinion. Thanks.
        Hide
        Kristian Waagan added a comment -

        Patch 1b addresses Rick's comments.

        > o Class header for PropertySetter: In the third bullet, it's unclear whether version refers to the "specification version" or to the "implementation version". I think the bullet means to say that for
        each specification version (VM level), we pick the latest implementation version (release number) at that level, regardless of which vendor created the VM release.
        Right.
        Note that the algorithm for determining if a specific implementation version satisfies a given specification version is very simple: implVer.contains(specVer)

        I also added a warning message if the vendor is unknown, but we will continue and try to understand the JDK. I briefly tested it using Apache Harmony, and it printed the warning message and failed.
        For unknown JDKs, I think we have two options (assuming we require 'java', 'java' and a 'jre'-library);

        • search for all jar files under the jre-library
        • start the VM and extract the boot class path

        I tried the second approach with Apache Harmony, and it worked fine when it came to configuring the JDK. The build failed however. Is doing this too radical, and will it cause us more trouble than benefit?
        For reference, below is the code I added:

        // Last desperate attempt (require 1.5 or 1.6).
        String implVersion = getProperty("java.version");
        boolean is15 = isValidVersion(implVersion, "1.5");
        boolean is16 = isValidVersion(implVersion, "1.6");
        if (!(isSet(J15CLASSPATH) || isSet(J16CLASSPATH)) &&
        (is15 || is16))

        { // See if we can continue with just the unknown running // JDK, from which we can obtain the boot classpath. echo("WARNING: Using running unknown JDK."); String bootClassPath = getProperty("vm.boot.class.path"); setProperty(is15 ? J15CLASSPATH : J16CLASSPATH, bootClassPath); }

        Patch ready for another round of review, and testing.

        Show
        Kristian Waagan added a comment - Patch 1b addresses Rick's comments. > o Class header for PropertySetter: In the third bullet, it's unclear whether version refers to the "specification version" or to the "implementation version". I think the bullet means to say that for each specification version (VM level), we pick the latest implementation version (release number) at that level, regardless of which vendor created the VM release. Right. Note that the algorithm for determining if a specific implementation version satisfies a given specification version is very simple: implVer.contains(specVer) I also added a warning message if the vendor is unknown, but we will continue and try to understand the JDK. I briefly tested it using Apache Harmony, and it printed the warning message and failed. For unknown JDKs, I think we have two options (assuming we require 'java', 'java' and a 'jre'-library); search for all jar files under the jre-library start the VM and extract the boot class path I tried the second approach with Apache Harmony, and it worked fine when it came to configuring the JDK. The build failed however. Is doing this too radical, and will it cause us more trouble than benefit? For reference, below is the code I added: // Last desperate attempt (require 1.5 or 1.6). String implVersion = getProperty("java.version"); boolean is15 = isValidVersion(implVersion, "1.5"); boolean is16 = isValidVersion(implVersion, "1.6"); if (!(isSet(J15CLASSPATH) || isSet(J16CLASSPATH)) && (is15 || is16)) { // See if we can continue with just the unknown running // JDK, from which we can obtain the boot classpath. echo("WARNING: Using running unknown JDK."); String bootClassPath = getProperty("vm.boot.class.path"); setProperty(is15 ? J15CLASSPATH : J16CLASSPATH, bootClassPath); } Patch ready for another round of review, and testing.
        Hide
        Kristian Waagan added a comment -

        Thanks for the comments, Rick.

        I haven't forgotten this issue, but I have put it on hold for the time being. I hope I can return to it later and address your comments.
        Since the comments aren't regarding the core functionality of the patch, it is still helpful if people test the patch (and disables their settings in ant.properties while doing so) on their systems.

        Show
        Kristian Waagan added a comment - Thanks for the comments, Rick. I haven't forgotten this issue, but I have put it on hold for the time being. I hope I can return to it later and address your comments. Since the comments aren't regarding the core functionality of the patch, it is still helpful if people test the patch (and disables their settings in ant.properties while doing so) on their systems.
        Hide
        Rick Hillegas added a comment -

        Thanks for this patch, Kristian. After applying it, the build runs cleanly for me on Mac OS X using both the default Java 5 compiler and the beta Java 6 compiler. I have a couple comments on the patch:

        o Class header for PropertySetter: In the third bullet, it's unclear whether version refers to the "specification version" or to the "implementation version". I think the bullet means to say that for each specification version (VM level), we pick the latest implementation version (release number) at that level, regardless of which vendor created the VM release.

        o getJreLib() - header needs a descriptive paragraph in addition to the parameter and return value annotations

        o getJreLib() - a normalization operation (vendor.replaceAll(",", "")) is applied to two strings before comparing them. I think it would be easier to understand if the normalization operation were factored out into a common method. That will also make the code less brittle if we need to improve this normalization later on.

        You asked the following: "Note that I changed the property setter to go ahead also if the JDK vendor isn't recognized. I don't really see a reason for aborting. Does anyone disagree?" The advantage of doing it the way you propose is that the build will not fail in cases where it really can just soldier on. The advantage of the abort is that it gives the developer some diagnostic information about what the real problem is in case the build tries to soldier on but trips over an impedance mismatch during compilation. A solution which provided both benefits might be this: If the JDK vendor isn't recognized, soldier on but first print out a diagnostic message saying that the vendor isn't recognized and this may confuse the build later on.

        Show
        Rick Hillegas added a comment - Thanks for this patch, Kristian. After applying it, the build runs cleanly for me on Mac OS X using both the default Java 5 compiler and the beta Java 6 compiler. I have a couple comments on the patch: o Class header for PropertySetter: In the third bullet, it's unclear whether version refers to the "specification version" or to the "implementation version". I think the bullet means to say that for each specification version (VM level), we pick the latest implementation version (release number) at that level, regardless of which vendor created the VM release. o getJreLib() - header needs a descriptive paragraph in addition to the parameter and return value annotations o getJreLib() - a normalization operation (vendor.replaceAll(",", "")) is applied to two strings before comparing them. I think it would be easier to understand if the normalization operation were factored out into a common method. That will also make the code less brittle if we need to improve this normalization later on. You asked the following: "Note that I changed the property setter to go ahead also if the JDK vendor isn't recognized. I don't really see a reason for aborting. Does anyone disagree?" The advantage of doing it the way you propose is that the build will not fail in cases where it really can just soldier on. The advantage of the abort is that it gives the developer some diagnostic information about what the real problem is in case the build tries to soldier on but trips over an impedance mismatch during compilation. A solution which provided both benefits might be this: If the JDK vendor isn't recognized, soldier on but first print out a diagnostic message saying that the vendor isn't recognized and this may confuse the build later on.
        Hide
        Kristian Waagan added a comment -

        I have written an alternative algorithm for detecting JDKs. It is using the same basics as the existing one, but instead of looking at the directory name it looks for specific JAR files.
        The new code has been tested lightly on Solaris, Linux and Windows, and has worked with JDKs from Sun, IBM and Oracle/BEA. It doesn't work with Apache Harmony, and I haven't looked at IcedTea.
        The new algorithm will first try to pick the newest JDK from the same vendor as the running JDK, and if that fails it will pick the newest JDK from any vendor.
        If the new algorithm doesn't find the required JDKs, the old algorithm will be attempted.
        Note that I changed the property setter to go ahead also if the JDK vendor isn't recognized. I don't really see a reason for aborting. Does anyone disagree?
        The PropertySetter should behave as before for the Mac, but testing wouldn't hurt!

        There are many possible combinations, so it would be nice if people could take the new code for a test spin!

        Here's the output from running "ant -DprintCompilerProperties" (btw, using less gives you more ) on a system of mine:

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

        {compilerPropsAlreadySet}

        [echo] Before setting properties: compilerLevel16 = 1.5
        [echo] Before setting properties: jsr169compile.classpath = $

        {jsr169compile.classpath}

        [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]
        [setJdkProperties] PropertySetter environment =
        [setJdkProperties]
        [setJdkProperties] java.vendor = Sun Microsystems Inc.
        [setJdkProperties] java.home = /tmp/myjdk/jre
        [setJdkProperties] java.version = 1.5.0_16
        [setJdkProperties] os.name = SunOS
        [setJdkProperties] j14lib = null
        [setJdkProperties] j15lib = null
        [setJdkProperties] j16lib = null
        [setJdkProperties] jdkSearchPath = /tmp, /usr/jdk
        [setJdkProperties]
        [setJdkProperties] found JDK: vendor=Sun Microsystems, Inc., specVersion=1.5, implVersion=1.5.0_16, path=/tmp/myjdk
        [setJdkProperties] found JDK: vendor=Sun Microsystems, Inc., specVersion=1.6, implVersion=1.6.0_11, path=/usr/jdk/jdk1.6.0_11
        [setJdkProperties] found JDK: vendor=Sun Microsystems, Inc., specVersion=1.5, implVersion=1.5.0_17, path=/usr/jdk/jdk1.5.0_17
        [setJdkProperties] found JDK: vendor=Sun Microsystems, Inc., specVersion=1.6, implVersion=1.6.0_13, path=/usr/jdk/latest
        [setJdkProperties] found JDK: vendor=Sun Microsystems, Inc., specVersion=1.4, implVersion=1.4.2_18, path=/usr/jdk/j2sdk1.4.2_18
        [setJdkProperties] found JDK: vendor=Sun Microsystems, Inc., specVersion=1.6, implVersion=1.6.0_14, path=/usr/jdk/jdk1.6.0_14
        [setJdkProperties] found JDK: vendor=Sun Microsystems, Inc., specVersion=1.6, implVersion=1.6.0_13, path=/usr/jdk/jdk1.6.0_13
        [setJdkProperties] found JDK: vendor=Sun Microsystems, Inc., specVersion=1.5, implVersion=1.5.0_16, path=/usr/jdk/jdk1.5.0_16
        [setJdkProperties] found JDK: vendor=Sun Microsystems, Inc., specVersion=1.6, implVersion=1.7.0-ea, path=/usr/jdk/jdk1.7.0
        [setJdkProperties] found JDK: vendor=Sun Microsystems, Inc., specVersion=1.6, implVersion=1.6.0_14-ea, path=/usr/jdk/jdk1.6.0_14-ea
        [setJdkProperties] Chosen JDK for specification version 1.4 (vendor Sun Microsystems Inc.): vendor=Sun Microsystems, Inc., specVersion=1.4, implVersion=1.4.2_18, path=/usr/jdk/j2sdk1.4.2_18
        [setJdkProperties] Chosen JDK for specification version 1.5 (vendor Sun Microsystems Inc.): vendor=Sun Microsystems, Inc., specVersion=1.5, implVersion=1.5.0_17, path=/usr/jdk/jdk1.5.0_17
        [setJdkProperties] Chosen JDK for specification version 1.6 (vendor Sun Microsystems Inc.): vendor=Sun Microsystems, Inc., specVersion=1.6, implVersion=1.6.0_14, path=/usr/jdk/jdk1.6.0_14
        [setJdkProperties] Setting property java14compile.classpath to /usr/jdk/j2sdk1.4.2_18/jre/lib/charsets.jar:/usr/jdk/j2sdk1.4.2_18/jre/lib/jce.jar:/usr/jdk/j2sdk1.4.2_18/jre/lib/jsse.jar:/usr/jdk/j2sdk1.4.2_18/jre/lib/plugin.jar:/usr/jdk/j2sdk1.4.2_18/jre/lib/rt.jar:/usr/jdk/j2sdk1.4.2_18/jre/lib/sunrsasign.jar
        [setJdkProperties] Setting property java15compile.classpath to /usr/jdk/jdk1.5.0_17/jre/lib/charsets.jar:/usr/jdk/jdk1.5.0_17/jre/lib/deploy.jar:/usr/jdk/jdk1.5.0_17/jre/lib/javaws.jar:/usr/jdk/jdk1.5.0_17/jre/lib/jce.jar:/usr/jdk/jdk1.5.0_17/jre/lib/jsse.jar:/usr/jdk/jdk1.5.0_17/jre/lib/plugin.jar:/usr/jdk/jdk1.5.0_17/jre/lib/rt.jar
        [setJdkProperties] Setting property java16compile.classpath to /usr/jdk/jdk1.6.0_14/jre/lib/alt-rt.jar:/usr/jdk/jdk1.6.0_14/jre/lib/charsets.jar:/usr/jdk/jdk1.6.0_14/jre/lib/deploy.jar:/usr/jdk/jdk1.6.0_14/jre/lib/javaws.jar:/usr/jdk/jdk1.6.0_14/jre/lib/jce.jar:/usr/jdk/jdk1.6.0_14/jre/lib/jsse.jar:/usr/jdk/jdk1.6.0_14/jre/lib/management-agent.jar:/usr/jdk/jdk1.6.0_14/jre/lib/plugin.jar:/usr/jdk/jdk1.6.0_14/jre/lib/resources.jar:/usr/jdk/jdk1.6.0_14/jre/lib/rt.jar

        printCompilerProperties:
        [echo] After setting properties: compilerPropsAlreadySet = true
        [echo] After setting properties: compilerLevel16 = 1.5
        [echo] After setting properties: jsr169compile.classpath = /export/home/kw160128/derby/wdir/trunk-merge-basin/classes/stubs/jsr169:/usr/jdk/j2sdk1.4.2_18/jre/lib/charsets.jar:/usr/jdk/j2sdk1.4.2_18/jre/lib/jce.jar:/usr/jdk/j2sdk1.4.2_18/jre/lib/jsse.jar:/usr/jdk/j2sdk1.4.2_18/jre/lib/plugin.jar:/usr/jdk/j2sdk1.4.2_18/jre/lib/rt.jar:/usr/jdk/j2sdk1.4.2_18/jre/lib/sunrsasign.jar
        [echo] After setting properties: j14lib = ${j14lib}

        [echo] After setting properties: java14compile.classpath = /usr/jdk/j2sdk1.4.2_18/jre/lib/charsets.jar:/usr/jdk/j2sdk1.4.2_18/jre/lib/jce.jar:/usr/jdk/j2sdk1.4.2_18/jre/lib/jsse.jar:/usr/jdk/j2sdk1.4.2_18/jre/lib/plugin.jar:/usr/jdk/j2sdk1.4.2_18/jre/lib/rt.jar:/usr/jdk/j2sdk1.4.2_18/jre/lib/sunrsasign.jar
        [echo] After setting properties: j15lib = $

        {j15lib}

        [echo] After setting properties: java15compile.classpath = /usr/jdk/jdk1.5.0_17/jre/lib/charsets.jar:/usr/jdk/jdk1.5.0_17/jre/lib/deploy.jar:/usr/jdk/jdk1.5.0_17/jre/lib/javaws.jar:/usr/jdk/jdk1.5.0_17/jre/lib/jce.jar:/usr/jdk/jdk1.5.0_17/jre/lib/jsse.jar:/usr/jdk/jdk1.5.0_17/jre/lib/plugin.jar:/usr/jdk/jdk1.5.0_17/jre/lib/rt.jar
        [echo] After setting properties: j16lib = $

        {jdk16}

        /jre/lib
        [echo] After setting properties: java16compile.classpath = /usr/jdk/jdk1.6.0_14/jre/lib/alt-rt.jar:/usr/jdk/jdk1.6.0_14/jre/lib/charsets.jar:/usr/jdk/jdk1.6.0_14/jre/lib/deploy.jar:/usr/jdk/jdk1.6.0_14/jre/lib/javaws.jar:/usr/jdk/jdk1.6.0_14/jre/lib/jce.jar:/usr/jdk/jdk1.6.0_14/jre/lib/jsse.jar:/usr/jdk/jdk1.6.0_14/jre/lib/management-agent.jar:/usr/jdk/jdk1.6.0_14/jre/lib/plugin.jar:/usr/jdk/jdk1.6.0_14/jre/lib/resources.jar:/usr/jdk/jdk1.6.0_14/jre/lib/rt.jar

        Show
        Kristian Waagan added a comment - I have written an alternative algorithm for detecting JDKs. It is using the same basics as the existing one, but instead of looking at the directory name it looks for specific JAR files. The new code has been tested lightly on Solaris, Linux and Windows, and has worked with JDKs from Sun, IBM and Oracle/BEA. It doesn't work with Apache Harmony, and I haven't looked at IcedTea. The new algorithm will first try to pick the newest JDK from the same vendor as the running JDK, and if that fails it will pick the newest JDK from any vendor. If the new algorithm doesn't find the required JDKs, the old algorithm will be attempted. Note that I changed the property setter to go ahead also if the JDK vendor isn't recognized. I don't really see a reason for aborting. Does anyone disagree? The PropertySetter should behave as before for the Mac, but testing wouldn't hurt! There are many possible combinations, so it would be nice if people could take the new code for a test spin! Here's the output from running "ant -DprintCompilerProperties" (btw, using less gives you more ) on a system of mine: printCompilerProperties: [echo] Before setting properties: compilerPropsAlreadySet = $ {compilerPropsAlreadySet} [echo] Before setting properties: compilerLevel16 = 1.5 [echo] Before setting properties: jsr169compile.classpath = $ {jsr169compile.classpath} [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] [setJdkProperties] PropertySetter environment = [setJdkProperties] [setJdkProperties] java.vendor = Sun Microsystems Inc. [setJdkProperties] java.home = /tmp/myjdk/jre [setJdkProperties] java.version = 1.5.0_16 [setJdkProperties] os.name = SunOS [setJdkProperties] j14lib = null [setJdkProperties] j15lib = null [setJdkProperties] j16lib = null [setJdkProperties] jdkSearchPath = /tmp, /usr/jdk [setJdkProperties] [setJdkProperties] found JDK: vendor=Sun Microsystems, Inc., specVersion=1.5, implVersion=1.5.0_16, path=/tmp/myjdk [setJdkProperties] found JDK: vendor=Sun Microsystems, Inc., specVersion=1.6, implVersion=1.6.0_11, path=/usr/jdk/jdk1.6.0_11 [setJdkProperties] found JDK: vendor=Sun Microsystems, Inc., specVersion=1.5, implVersion=1.5.0_17, path=/usr/jdk/jdk1.5.0_17 [setJdkProperties] found JDK: vendor=Sun Microsystems, Inc., specVersion=1.6, implVersion=1.6.0_13, path=/usr/jdk/latest [setJdkProperties] found JDK: vendor=Sun Microsystems, Inc., specVersion=1.4, implVersion=1.4.2_18, path=/usr/jdk/j2sdk1.4.2_18 [setJdkProperties] found JDK: vendor=Sun Microsystems, Inc., specVersion=1.6, implVersion=1.6.0_14, path=/usr/jdk/jdk1.6.0_14 [setJdkProperties] found JDK: vendor=Sun Microsystems, Inc., specVersion=1.6, implVersion=1.6.0_13, path=/usr/jdk/jdk1.6.0_13 [setJdkProperties] found JDK: vendor=Sun Microsystems, Inc., specVersion=1.5, implVersion=1.5.0_16, path=/usr/jdk/jdk1.5.0_16 [setJdkProperties] found JDK: vendor=Sun Microsystems, Inc., specVersion=1.6, implVersion=1.7.0-ea, path=/usr/jdk/jdk1.7.0 [setJdkProperties] found JDK: vendor=Sun Microsystems, Inc., specVersion=1.6, implVersion=1.6.0_14-ea, path=/usr/jdk/jdk1.6.0_14-ea [setJdkProperties] Chosen JDK for specification version 1.4 (vendor Sun Microsystems Inc.): vendor=Sun Microsystems, Inc., specVersion=1.4, implVersion=1.4.2_18, path=/usr/jdk/j2sdk1.4.2_18 [setJdkProperties] Chosen JDK for specification version 1.5 (vendor Sun Microsystems Inc.): vendor=Sun Microsystems, Inc., specVersion=1.5, implVersion=1.5.0_17, path=/usr/jdk/jdk1.5.0_17 [setJdkProperties] Chosen JDK for specification version 1.6 (vendor Sun Microsystems Inc.): vendor=Sun Microsystems, Inc., specVersion=1.6, implVersion=1.6.0_14, path=/usr/jdk/jdk1.6.0_14 [setJdkProperties] Setting property java14compile.classpath to /usr/jdk/j2sdk1.4.2_18/jre/lib/charsets.jar:/usr/jdk/j2sdk1.4.2_18/jre/lib/jce.jar:/usr/jdk/j2sdk1.4.2_18/jre/lib/jsse.jar:/usr/jdk/j2sdk1.4.2_18/jre/lib/plugin.jar:/usr/jdk/j2sdk1.4.2_18/jre/lib/rt.jar:/usr/jdk/j2sdk1.4.2_18/jre/lib/sunrsasign.jar [setJdkProperties] Setting property java15compile.classpath to /usr/jdk/jdk1.5.0_17/jre/lib/charsets.jar:/usr/jdk/jdk1.5.0_17/jre/lib/deploy.jar:/usr/jdk/jdk1.5.0_17/jre/lib/javaws.jar:/usr/jdk/jdk1.5.0_17/jre/lib/jce.jar:/usr/jdk/jdk1.5.0_17/jre/lib/jsse.jar:/usr/jdk/jdk1.5.0_17/jre/lib/plugin.jar:/usr/jdk/jdk1.5.0_17/jre/lib/rt.jar [setJdkProperties] Setting property java16compile.classpath to /usr/jdk/jdk1.6.0_14/jre/lib/alt-rt.jar:/usr/jdk/jdk1.6.0_14/jre/lib/charsets.jar:/usr/jdk/jdk1.6.0_14/jre/lib/deploy.jar:/usr/jdk/jdk1.6.0_14/jre/lib/javaws.jar:/usr/jdk/jdk1.6.0_14/jre/lib/jce.jar:/usr/jdk/jdk1.6.0_14/jre/lib/jsse.jar:/usr/jdk/jdk1.6.0_14/jre/lib/management-agent.jar:/usr/jdk/jdk1.6.0_14/jre/lib/plugin.jar:/usr/jdk/jdk1.6.0_14/jre/lib/resources.jar:/usr/jdk/jdk1.6.0_14/jre/lib/rt.jar printCompilerProperties: [echo] After setting properties: compilerPropsAlreadySet = true [echo] After setting properties: compilerLevel16 = 1.5 [echo] After setting properties: jsr169compile.classpath = /export/home/kw160128/derby/wdir/trunk-merge-basin/classes/stubs/jsr169:/usr/jdk/j2sdk1.4.2_18/jre/lib/charsets.jar:/usr/jdk/j2sdk1.4.2_18/jre/lib/jce.jar:/usr/jdk/j2sdk1.4.2_18/jre/lib/jsse.jar:/usr/jdk/j2sdk1.4.2_18/jre/lib/plugin.jar:/usr/jdk/j2sdk1.4.2_18/jre/lib/rt.jar:/usr/jdk/j2sdk1.4.2_18/jre/lib/sunrsasign.jar [echo] After setting properties: j14lib = ${j14lib} [echo] After setting properties: java14compile.classpath = /usr/jdk/j2sdk1.4.2_18/jre/lib/charsets.jar:/usr/jdk/j2sdk1.4.2_18/jre/lib/jce.jar:/usr/jdk/j2sdk1.4.2_18/jre/lib/jsse.jar:/usr/jdk/j2sdk1.4.2_18/jre/lib/plugin.jar:/usr/jdk/j2sdk1.4.2_18/jre/lib/rt.jar:/usr/jdk/j2sdk1.4.2_18/jre/lib/sunrsasign.jar [echo] After setting properties: j15lib = $ {j15lib} [echo] After setting properties: java15compile.classpath = /usr/jdk/jdk1.5.0_17/jre/lib/charsets.jar:/usr/jdk/jdk1.5.0_17/jre/lib/deploy.jar:/usr/jdk/jdk1.5.0_17/jre/lib/javaws.jar:/usr/jdk/jdk1.5.0_17/jre/lib/jce.jar:/usr/jdk/jdk1.5.0_17/jre/lib/jsse.jar:/usr/jdk/jdk1.5.0_17/jre/lib/plugin.jar:/usr/jdk/jdk1.5.0_17/jre/lib/rt.jar [echo] After setting properties: j16lib = $ {jdk16} /jre/lib [echo] After setting properties: java16compile.classpath = /usr/jdk/jdk1.6.0_14/jre/lib/alt-rt.jar:/usr/jdk/jdk1.6.0_14/jre/lib/charsets.jar:/usr/jdk/jdk1.6.0_14/jre/lib/deploy.jar:/usr/jdk/jdk1.6.0_14/jre/lib/javaws.jar:/usr/jdk/jdk1.6.0_14/jre/lib/jce.jar:/usr/jdk/jdk1.6.0_14/jre/lib/jsse.jar:/usr/jdk/jdk1.6.0_14/jre/lib/management-agent.jar:/usr/jdk/jdk1.6.0_14/jre/lib/plugin.jar:/usr/jdk/jdk1.6.0_14/jre/lib/resources.jar:/usr/jdk/jdk1.6.0_14/jre/lib/rt.jar

          People

          • Assignee:
            Kristian Waagan
            Reporter:
            Knut Anders Hatlen
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development