[
https://issues.apache.org/jira/browse/DERBY-4263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kristian Waagan updated DERBY-4263:
-----------------------------------
Attachment: derby-4263-1b-jdk_detection_by_jars.diff
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.
> PropertySetter isn't able to recognize JDK without version number in path
> -------------------------------------------------------------------------
>
> Key: DERBY-4263
> URL: https://issues.apache.org/jira/browse/DERBY-4263
> Project: Derby
> Issue Type: Bug
> Components: Build tools
> Affects Versions: 10.6.0.0
> Reporter: Knut Anders Hatlen
> Priority: Minor
> Attachments: derby-4263-1a-jdk_detection_by_jars.diff,
> derby-4263-1b-jdk_detection_by_jars.diff
>
>
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
