Derby
  1. Derby
  2. DERBY-5485

Simplify PropertySetter so that it is less brittle and easier to maintain.

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 10.9.1.0
    • Fix Version/s: 10.9.1.0
    • Component/s: Build tools
    • Labels:
      None
    • Urgency:
      Normal
    • Issue & fix info:
      Patch Available

      Description

      The PropertySetter task sets up classpath variables so that the build can take advantage of JVM-specific class libraries. Using those libraries makes it possible for the compiler to flag code which is supposed to run on less capable platforms but which calls methods from later JVMs. This is a very tricky problem and we seem to have reached consensus that it requires too much effort to make PropertySetter run correctly in all of the build environments which Derby developers use. I will attach a proposal for how to simplify PropertySetter so that it requires less effort to maintain.

      1. derby-5485-02-aa-fixBigDecimalInstantiators.diff
        2 kB
        Rick Hillegas
      2. derby-5485-01-ah-changeJDBClevel.diff
        104 kB
        Rick Hillegas
      3. derby-5485-01-ag-changeJDBClevel.diff
        104 kB
        Rick Hillegas
      4. derby-5485-01-af-simplifyPlusJavadoc.diff
        104 kB
        Rick Hillegas

        Issue Links

          Activity

          Hide
          Rick Hillegas added a comment -

          Note that this issue is marked fixed in 10.9.1. Porting this fix to the 10.8 branch would probably be tricky because the 10.9 build changed in order to remove support for Java 1.4.

          Show
          Rick Hillegas added a comment - Note that this issue is marked fixed in 10.9.1. Porting this fix to the 10.8 branch would probably be tricky because the 10.9 build changed in order to remove support for Java 1.4.
          Hide
          Rick Hillegas added a comment -

          Thanks, Kristian. I am done working on this issue and have resolved it.

          Show
          Rick Hillegas added a comment - Thanks, Kristian. I am done working on this issue and have resolved it.
          Hide
          Kristian Waagan added a comment -

          Has the work on this issue been completed?

          Show
          Kristian Waagan added a comment - Has the work on this issue been completed?
          Hide
          Rick Hillegas added a comment -

          Attaching derby-5485-02-aa-fixBigDecimalInstantiators.diff. This fixes org.apache.derbyTesting.functionTests.tests.jdbcapi.ProcedureTest so that it runs on JDK 1.4 again. The previous patch broke that test because the compiler was resolving BigDecimal instantiations to an initializer which was introduced in Java 5. This patch changes those instantiations so that they are resolved to an initializer which appears in JDK 1.4. For further information on this problem, see the following derby-dev email thread: http://old.nabble.com/need-theories-about-errors-seen-in-the-jdk-1.4-test-runs-td32842864.html#a32842864

          I have successfully run the patched test on Java 6 and JDK 1.4. Committed at subversion revision 1202276.

          Touches the following file:

          M java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/ProcedureTest.java

          Show
          Rick Hillegas added a comment - Attaching derby-5485-02-aa-fixBigDecimalInstantiators.diff. This fixes org.apache.derbyTesting.functionTests.tests.jdbcapi.ProcedureTest so that it runs on JDK 1.4 again. The previous patch broke that test because the compiler was resolving BigDecimal instantiations to an initializer which was introduced in Java 5. This patch changes those instantiations so that they are resolved to an initializer which appears in JDK 1.4. For further information on this problem, see the following derby-dev email thread: http://old.nabble.com/need-theories-about-errors-seen-in-the-jdk-1.4-test-runs-td32842864.html#a32842864 I have successfully run the patched test on Java 6 and JDK 1.4. Committed at subversion revision 1202276. Touches the following file: M java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/ProcedureTest.java
          Hide
          Rick Hillegas added a comment -

          Attaching derby-5485-01-ah-changeJDBClevel.diff. This is the previous patch merged with the changes from derby-5496-01-ab-identify14classes.diff which were checked in earlier today.

          Thanks again to everyone who test-drove this patch. Committed at subversion revision 1199248.

          Show
          Rick Hillegas added a comment - Attaching derby-5485-01-ah-changeJDBClevel.diff. This is the previous patch merged with the changes from derby-5496-01-ab-identify14classes.diff which were checked in earlier today. Thanks again to everyone who test-drove this patch. Committed at subversion revision 1199248.
          Hide
          Rick Hillegas added a comment -

          Thanks for test-driving the patch, Kathey and Dag.

          Show
          Rick Hillegas added a comment - Thanks for test-driving the patch, Kathey and Dag.
          Hide
          Dag H. Wanvik added a comment -

          I teste drove this patch on Windows Vista / Cygwin / Norwegian locale, with JDK 1.7, JDK 1.6 and JDK 1.5 to build sane jars after clobber. My ant.properties was minimal, see below. No issues seen: verified by running sysinfo.

          ant.properties:
          ---------------------
          proceed=false
          deprecation=off
          printCompilerProperties=true

          Show
          Dag H. Wanvik added a comment - I teste drove this patch on Windows Vista / Cygwin / Norwegian locale, with JDK 1.7, JDK 1.6 and JDK 1.5 to build sane jars after clobber. My ant.properties was minimal, see below. No issues seen: verified by running sysinfo. ant.properties: --------------------- proceed=false deprecation=off printCompilerProperties=true
          Hide
          Kathey Marsden added a comment -

          I did not review, but did try out building with the derby-5485-01-ag-changeJDBClevel.diff patch and ran a single test. I was able to build fine with both my previously posted local.properties and no local.properties file. Thanks Rick!

          Show
          Kathey Marsden added a comment - I did not review, but did try out building with the derby-5485-01-ag-changeJDBClevel.diff patch and ran a single test. I was able to build fine with both my previously posted local.properties and no local.properties file. Thanks Rick!
          Hide
          Rick Hillegas added a comment -

          Thanks for test-driving the patch, Knut. Attaching derby-5485-01-ag-changeJDBClevel.diff, which changes the JDBC level for Java 6 from 4.1 to 4.0 in BUILDING.html. I go back and forth on this one: the Java 6 JDBC implementation for Derby does contain the extra 4.1 methods but, of course, they can only be accessed through reflection; you are probably right that we will cause less confusion by claiming the lower rev level. Thanks.

          Show
          Rick Hillegas added a comment - Thanks for test-driving the patch, Knut. Attaching derby-5485-01-ag-changeJDBClevel.diff, which changes the JDBC level for Java 6 from 4.1 to 4.0 in BUILDING.html. I go back and forth on this one: the Java 6 JDBC implementation for Derby does contain the extra 4.1 methods but, of course, they can only be accessed through reflection; you are probably right that we will cause less confusion by claiming the lower rev level. Thanks.
          Hide
          Knut Anders Hatlen added a comment -

          I successfully built Derby with Java 1.5, 1.6 and 1.7 on Solaris after applying the patch.

          There's a small typo in BUILDING.html under Advanced Build:

          > Derby is supposed to run in all of the following environments:
          > (...)
          > Java 6 JDBC 4.1

          It should say JDBC 4.0 here, I think.

          Show
          Knut Anders Hatlen added a comment - I successfully built Derby with Java 1.5, 1.6 and 1.7 on Solaris after applying the patch. There's a small typo in BUILDING.html under Advanced Build: > Derby is supposed to run in all of the following environments: > (...) > Java 6 JDBC 4.1 It should say JDBC 4.0 here, I think.
          Hide
          Rick Hillegas added a comment -

          Attaching derby-5485-01-af-simplifyPlusJavadoc.diff. This patch simplifies PropertySetter as described above. PropertySetter still achieves goals (1) and (2) but abandons goal (3).

          I have successfully compiled the Derby code and built the javadoc in the following environments:

          o Oracle JDK 6 and 7 on Mac OS X

          o Oracle JDK 6 and 7 on Ubuntu

          o IBM JDK 6 and 7 on Ubuntu

          I would appreciate test-drives from people who build on the following platforms. Thanks!

          o Oracle JDKs on Solaris

          o Oracle JDKs on Windows

          o IBM JDKs on Windows

          The patch involves a wholesale revamping of PropertySetter:

          a) Support for JDK 1.4 is removed because 10.9 does not support that platform.

          b) PropertySetter still tries to set the java$

          {version}compile.classpath properties from the j${version}

          lib properties where $

          {version} is 15, 16, and 17.

          c) PropertySetter also tries to set java${version}

          compile.classpath where $

          {version} is the version of the currently executing JVM. This is done by wiring together all of the jar files in the directories which contain the jars which contain java.lang.String and java.util.Vector.

          d) However, PropertySetter does NOT try to set java${version}

          compile.classpath if j$

          {version}lib is not set and if ${version}

          is not the version of the currently executing JVM.

          In addition, this patch changes the master build script as follows:

          e) References to j14lib and java14compile.classpath are removed. If not set, the jsr169compile.classpath is set based on java15compile.classpath rather than java14compile.classpath.

          f) java16compile.classpath is removed from the classpath of the derbydocs target so that the javadoc build will work with IBM JDK 7.

          In addition, this patch removes all other references to java14compile.classpath in the other subordinate build scripts. I did not also change the source and target rev levels of the affected targets. Those targets still require source and target to be 14 rather than 15. Changing the source and target rev levels results in many "unchecked exception" warnings. These can probably be suppressed but the right solution might be to actually fix the Derby code. That effort falls outside the scope of this JIRA. Until the source and target rev levels are changed, we will not be able to use Java 5 language features in the code compiled by the affected targets.

          Touches the following files:

          ----------------

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

          Revamps this task as described above.

          ----------------

          M java/tools/org/apache/derby/impl/tools/build.xml
          M java/storeless/build.xml
          M java/demo/toursdb/build.xml
          M java/demo/build.xml
          M java/engine/org/apache/derby/impl/jdbc/build.xml
          M java/engine/org/apache/derby/impl/services/build.xml
          M java/engine/org/apache/derby/impl/io/build.xml
          M java/engine/org/apache/derby/impl/store/build.xml
          M java/engine/org/apache/derby/osgi/build.xml
          M java/engine/org/apache/derby/iapi/jdbc/build.xml
          M java/engine/org/apache/derby/iapi/services/crypto/build.xml
          M java/engine/org/apache/derby/iapi/types/build.xml
          M java/engine/org/apache/derby/iapi/store/build.xml
          M java/engine/org/apache/derby/iapi/reference/build.xml
          M java/engine/org/apache/derby/jdbc/build.xml
          M java/engine/org/apache/derby/vti/build.xml
          M java/shared/build.xml
          M java/drda/org/apache/derby/impl/drda/build.xml
          M java/drda/org/apache/derby/drda/build.xml
          M java/testing/org/apache/derbyTesting/unitTests/build.xml
          M java/testing/org/apache/derbyTesting/system/nstest/build.xml
          M java/testing/org/apache/derbyTesting/system/optimizer/build.xml
          M java/testing/org/apache/derbyTesting/system/oe/build.xml
          M java/testing/org/apache/derbyTesting/system/mailjdbc/build.xml
          M java/testing/org/apache/derbyTesting/system/sttest/build.xml
          M java/testing/org/apache/derbyTesting/functionTests/tests/i18n/build.xml
          M java/testing/org/apache/derbyTesting/functionTests/tests/lang/build.xml
          M java/testing/org/apache/derbyTesting/functionTests/tests/largedata/build.xml
          M java/testing/org/apache/derbyTesting/functionTests/tests/replicationTests/build.xml
          M java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/build.xml
          M java/testing/org/apache/derbyTesting/functionTests/tests/perf/build.xml
          M java/testing/org/apache/derbyTesting/functionTests/tests/store/build.xml
          M java/testing/org/apache/derbyTesting/functionTests/tests/tools/build.xml
          M java/testing/org/apache/derbyTesting/functionTests/tests/memory/build.xml
          M java/testing/org/apache/derbyTesting/functionTests/tests/upgradeTests/build.xml
          M java/testing/org/apache/derbyTesting/functionTests/tests/junitTests/compatibility/build.xml
          M java/testing/org/apache/derbyTesting/functionTests/tests/derbynet/build.xml
          M java/testing/org/apache/derbyTesting/functionTests/tests/memorydb/build.xml
          M java/testing/org/apache/derbyTesting/functionTests/harness/build.xml
          M java/testing/org/apache/derbyTesting/functionTests/util/build.xml
          M java/testing/org/apache/derbyTesting/junit/build.xml
          M java/testing/org/apache/derbyTesting/perf/build.xml
          M java/client/build.xml
          M build.xml

          Removes java14compile.classpath references as described above.

          ----------------

          M BUILDING.html

          Removes references to JDK 1.4 from this summary document.

          Show
          Rick Hillegas added a comment - Attaching derby-5485-01-af-simplifyPlusJavadoc.diff. This patch simplifies PropertySetter as described above. PropertySetter still achieves goals (1) and (2) but abandons goal (3). I have successfully compiled the Derby code and built the javadoc in the following environments: o Oracle JDK 6 and 7 on Mac OS X o Oracle JDK 6 and 7 on Ubuntu o IBM JDK 6 and 7 on Ubuntu I would appreciate test-drives from people who build on the following platforms. Thanks! o Oracle JDKs on Solaris o Oracle JDKs on Windows o IBM JDKs on Windows The patch involves a wholesale revamping of PropertySetter: a) Support for JDK 1.4 is removed because 10.9 does not support that platform. b) PropertySetter still tries to set the java$ {version}compile.classpath properties from the j${version} lib properties where $ {version} is 15, 16, and 17. c) PropertySetter also tries to set java${version} compile.classpath where $ {version} is the version of the currently executing JVM. This is done by wiring together all of the jar files in the directories which contain the jars which contain java.lang.String and java.util.Vector. d) However, PropertySetter does NOT try to set java${version} compile.classpath if j$ {version}lib is not set and if ${version} is not the version of the currently executing JVM. In addition, this patch changes the master build script as follows: e) References to j14lib and java14compile.classpath are removed. If not set, the jsr169compile.classpath is set based on java15compile.classpath rather than java14compile.classpath. f) java16compile.classpath is removed from the classpath of the derbydocs target so that the javadoc build will work with IBM JDK 7. In addition, this patch removes all other references to java14compile.classpath in the other subordinate build scripts. I did not also change the source and target rev levels of the affected targets. Those targets still require source and target to be 14 rather than 15. Changing the source and target rev levels results in many "unchecked exception" warnings. These can probably be suppressed but the right solution might be to actually fix the Derby code. That effort falls outside the scope of this JIRA. Until the source and target rev levels are changed, we will not be able to use Java 5 language features in the code compiled by the affected targets. Touches the following files: ---------------- M java/build/org/apache/derbyPreBuild/PropertySetter.java Revamps this task as described above. ---------------- M java/tools/org/apache/derby/impl/tools/build.xml M java/storeless/build.xml M java/demo/toursdb/build.xml M java/demo/build.xml M java/engine/org/apache/derby/impl/jdbc/build.xml M java/engine/org/apache/derby/impl/services/build.xml M java/engine/org/apache/derby/impl/io/build.xml M java/engine/org/apache/derby/impl/store/build.xml M java/engine/org/apache/derby/osgi/build.xml M java/engine/org/apache/derby/iapi/jdbc/build.xml M java/engine/org/apache/derby/iapi/services/crypto/build.xml M java/engine/org/apache/derby/iapi/types/build.xml M java/engine/org/apache/derby/iapi/store/build.xml M java/engine/org/apache/derby/iapi/reference/build.xml M java/engine/org/apache/derby/jdbc/build.xml M java/engine/org/apache/derby/vti/build.xml M java/shared/build.xml M java/drda/org/apache/derby/impl/drda/build.xml M java/drda/org/apache/derby/drda/build.xml M java/testing/org/apache/derbyTesting/unitTests/build.xml M java/testing/org/apache/derbyTesting/system/nstest/build.xml M java/testing/org/apache/derbyTesting/system/optimizer/build.xml M java/testing/org/apache/derbyTesting/system/oe/build.xml M java/testing/org/apache/derbyTesting/system/mailjdbc/build.xml M java/testing/org/apache/derbyTesting/system/sttest/build.xml M java/testing/org/apache/derbyTesting/functionTests/tests/i18n/build.xml M java/testing/org/apache/derbyTesting/functionTests/tests/lang/build.xml M java/testing/org/apache/derbyTesting/functionTests/tests/largedata/build.xml M java/testing/org/apache/derbyTesting/functionTests/tests/replicationTests/build.xml M java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/build.xml M java/testing/org/apache/derbyTesting/functionTests/tests/perf/build.xml M java/testing/org/apache/derbyTesting/functionTests/tests/store/build.xml M java/testing/org/apache/derbyTesting/functionTests/tests/tools/build.xml M java/testing/org/apache/derbyTesting/functionTests/tests/memory/build.xml M java/testing/org/apache/derbyTesting/functionTests/tests/upgradeTests/build.xml M java/testing/org/apache/derbyTesting/functionTests/tests/junitTests/compatibility/build.xml M java/testing/org/apache/derbyTesting/functionTests/tests/derbynet/build.xml M java/testing/org/apache/derbyTesting/functionTests/tests/memorydb/build.xml M java/testing/org/apache/derbyTesting/functionTests/harness/build.xml M java/testing/org/apache/derbyTesting/functionTests/util/build.xml M java/testing/org/apache/derbyTesting/junit/build.xml M java/testing/org/apache/derbyTesting/perf/build.xml M java/client/build.xml M build.xml Removes java14compile.classpath references as described above. ---------------- M BUILDING.html Removes references to JDK 1.4 from this summary document.
          Hide
          Rick Hillegas added a comment -

          The javadoc problem with IBM JDK 7 goes away if I remove $

          {java16compile.classpath}

          from the classpath specification for the derbydocs target. When I remove that extra bit of classpath, the generated javadoc still looks correct to me.

          Show
          Rick Hillegas added a comment - The javadoc problem with IBM JDK 7 goes away if I remove $ {java16compile.classpath} from the classpath specification for the derbydocs target. When I remove that extra bit of classpath, the generated javadoc still looks correct to me.
          Hide
          Rick Hillegas added a comment -

          I am working on a candidate patch. With this patch I can build Derby successfully in the following environments:

          o Oracle JDK 6 and 7 on Mac OS X

          o Oracle JDK 6 and 7 on Ubuntu

          o IBM JDK 6 and 7 on Ubuntu

          The patch tries to set the compile classpath by wiring together all of the jars in a system directory or directories. For all of the platforms above except for IBM JDK 7, it was sufficient to find the directory which contains the jar file which contains java.lang.String. However, this was not good enough for IBM JDK 7. For that platform, I also had to add the jars in the directory which contains the jar file which contains java.util.Vector. It appears that the IBM JDK 7 splits the system classes across jar files in more than one directory--unlike all of the other JDKs above.

          I am also unable to build the Derby javadoc using IBM JDK 7. I see the following error. This may be a problem in how I am constructing the classpath.

          [javadoc] /mac-home/ubuntu-home/sw-ubuntu/java/ibm/ibm-java-sdk-7.0-0.0-i386/jre/lib/jlm.src.jar(com/ibm/lang/management/MemoryMXBeanImpl.java):53: error: cannot access MemoryMXBean
          [javadoc] MemoryMXBean, NotificationEmitter {
          [javadoc] ^
          [javadoc] bad source file: /mac-home/ubuntu-home/sw-ubuntu/java/ibm/ibm-java-sdk-7.0-0.0-i386/jre/lib/jlm.src.jar(com/ibm/lang/management/MemoryMXBean.java)
          [javadoc] file does not contain class com.ibm.lang.management.MemoryMXBean
          [javadoc] Please remove or make sure it appears in the correct subdirectory of the sourcepath.
          [javadoc] /mac-home/ubuntu-home/sw-ubuntu/java/ibm/ibm-java-sdk-7.0-0.0-i386/jre/lib/jlm.src.jar(com/ibm/lang/management/OperatingSystemMXBeanImpl.java):29: error: cannot access OperatingSystemMXBean
          [javadoc] implements OperatingSystemMXBean, NotificationEmitter {
          [javadoc] ^
          [javadoc] bad source file: /mac-home/ubuntu-home/sw-ubuntu/java/ibm/ibm-java-sdk-7.0-0.0-i386/jre/lib/jlm.src.jar(com/ibm/lang/management/OperatingSystemMXBean.java)
          [javadoc] file does not contain class com.ibm.lang.management.OperatingSystemMXBean
          [javadoc] Please remove or make sure it appears in the correct subdirectory of the sourcepath.

          Show
          Rick Hillegas added a comment - I am working on a candidate patch. With this patch I can build Derby successfully in the following environments: o Oracle JDK 6 and 7 on Mac OS X o Oracle JDK 6 and 7 on Ubuntu o IBM JDK 6 and 7 on Ubuntu The patch tries to set the compile classpath by wiring together all of the jars in a system directory or directories. For all of the platforms above except for IBM JDK 7, it was sufficient to find the directory which contains the jar file which contains java.lang.String. However, this was not good enough for IBM JDK 7. For that platform, I also had to add the jars in the directory which contains the jar file which contains java.util.Vector. It appears that the IBM JDK 7 splits the system classes across jar files in more than one directory--unlike all of the other JDKs above. I am also unable to build the Derby javadoc using IBM JDK 7. I see the following error. This may be a problem in how I am constructing the classpath. [javadoc] /mac-home/ubuntu-home/sw-ubuntu/java/ibm/ibm-java-sdk-7.0-0.0-i386/jre/lib/jlm.src.jar(com/ibm/lang/management/MemoryMXBeanImpl.java):53: error: cannot access MemoryMXBean [javadoc] MemoryMXBean, NotificationEmitter { [javadoc] ^ [javadoc] bad source file: /mac-home/ubuntu-home/sw-ubuntu/java/ibm/ibm-java-sdk-7.0-0.0-i386/jre/lib/jlm.src.jar(com/ibm/lang/management/MemoryMXBean.java) [javadoc] file does not contain class com.ibm.lang.management.MemoryMXBean [javadoc] Please remove or make sure it appears in the correct subdirectory of the sourcepath. [javadoc] /mac-home/ubuntu-home/sw-ubuntu/java/ibm/ibm-java-sdk-7.0-0.0-i386/jre/lib/jlm.src.jar(com/ibm/lang/management/OperatingSystemMXBeanImpl.java):29: error: cannot access OperatingSystemMXBean [javadoc] implements OperatingSystemMXBean, NotificationEmitter { [javadoc] ^ [javadoc] bad source file: /mac-home/ubuntu-home/sw-ubuntu/java/ibm/ibm-java-sdk-7.0-0.0-i386/jre/lib/jlm.src.jar(com/ibm/lang/management/OperatingSystemMXBean.java) [javadoc] file does not contain class com.ibm.lang.management.OperatingSystemMXBean [javadoc] Please remove or make sure it appears in the correct subdirectory of the sourcepath.
          Hide
          Rick Hillegas added a comment -

          The PropertySetter task sets the following properties for the master build script. These are the properties which point at the JDK-specific jar files:

          java14compile.classpath
          java15compile.classpath
          java16compile.classpath
          java17compile.classpath

          PropertySetter attempts to do the following:

          1) Make it possible to build Derby out-of-the-box without setting any ant properties. The build is supposed to work on all machines which Derby developers use provided that the developer uses a modern JDK that supports generics (viz., Java 5, 6, or 7).

          2) Set the JDK-specific classpath properties (see above) from the corresponding library properties if the user has set them. Setting the JDK-specific classpath properties makes it possible for the Derby build to object if references to later JVMs are made by code which is supposed to run on earlier JVMs. The library properties are:

          j14lib
          j15lib
          j16lib
          j17lib

          3) If the library properties are not set, still try to set the JDK-specific classpath properties by finding a corresponding JDK on the user's machine.

          The hard-to-maintain complexity of PropertySetter largely involves goal (3).

          This JIRA proposes to rewrite PropertySetter so that it still achieves goals (1) and (2) but abandons goal (3).

          Show
          Rick Hillegas added a comment - The PropertySetter task sets the following properties for the master build script. These are the properties which point at the JDK-specific jar files: java14compile.classpath java15compile.classpath java16compile.classpath java17compile.classpath PropertySetter attempts to do the following: 1) Make it possible to build Derby out-of-the-box without setting any ant properties. The build is supposed to work on all machines which Derby developers use provided that the developer uses a modern JDK that supports generics (viz., Java 5, 6, or 7). 2) Set the JDK-specific classpath properties (see above) from the corresponding library properties if the user has set them. Setting the JDK-specific classpath properties makes it possible for the Derby build to object if references to later JVMs are made by code which is supposed to run on earlier JVMs. The library properties are: j14lib j15lib j16lib j17lib 3) If the library properties are not set, still try to set the JDK-specific classpath properties by finding a corresponding JDK on the user's machine. The hard-to-maintain complexity of PropertySetter largely involves goal (3). This JIRA proposes to rewrite PropertySetter so that it still achieves goals (1) and (2) but abandons goal (3).

            People

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

              Dates

              • Created:
                Updated:
                Resolved:

                Development