On 17.10.11 21:37, Knut Anders Hatlen wrote:
Rick Hillegas<[email protected]> writes:
It seems that at least one other person has managed to trick the Derby
build into working under JDK 7:
https://issues.apache.org/jira/browse/DERBY-5310. I find that I can
build Derby under the openjdk 7 preview for mac os x as long as I
force the j16lib property to point into the jre library of my Java 7
installation. That is, I have to trick the build into thinking that
JDK 7 is really JDK 6.
I didn't have to trick it into anything, but that was because I also had
JDK 6 installed, and PropertySetter had no problem detecting it and
based j16lib on JDK 6. That is, it used the compiler from JDK 7 and the
libraries from JDK 6.
It doesn't appear to me that any support for JDK 7 has been added to
PropertySetter. That's the ant task which sets up the Derby build
environment. Is this a fair summary of how we expect the Derby build
to work under JDK 7:
1) Out-of-the-box the build will fail because the build does not
consider Java 7 installations.
If JDK 7 is the only JDK you have installed, yes. (Or if PropertySetter
cannot find your JDK 6 installation.)
2) In order to build under JDK7 you have to trick the build into
thinking that your Java 7 installation is really Java 6 (e.g., by
forcing the value of j16lib).
Yes, if you only have JDK 7, we should build a java17compile.classpath,
and then construct java16compile.classpath based on JDK 7 and JDBC 4.0
stubs. Something like this:
${out.jdbc4.dir}:${java17compile.classpath}
Do we really need the stubs in this case?
I thought they were added to be able to build JDBC 4.0 support with a
JDK 1.5 compiler.
Are there any advantages of including the stubs anyway, even if they are
not strictly required?
PropertySetter lacks that piece of logic right now.
That last piece has to be done in build.xml, but it is correct that
PropertySetter doesn't even consider JDK 1.7 as a candidate JDK.
I guess we may also want to ditch the compile classpath variable for JDK
1.4 now?
--
Kristian
