db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kristian Waagan <kristian.waa...@oracle.com>
Subject Re: building with JDK 7
Date Mon, 17 Oct 2011 19:44:13 GMT
On 17.10.11 21:37, Knut Anders Hatlen wrote:
> Rick Hillegas<rick.hillegas@oracle.com>  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?


View raw message