[
https://issues.apache.org/jira/browse/DERBY-4263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12721334#action_12721334
]
Rick Hillegas commented on DERBY-4263:
--------------------------------------
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.
> 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
>
>
> 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.
