db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Hillegas <Richard.Hille...@Sun.COM>
Subject Re: JDK 1.4 support
Date Tue, 02 Dec 2008 15:51:22 GMT
Knut Anders Hatlen wrote:
> more good stuff...
> Right, that would solve the issue of compile-time checks without adding
> new build dependencies. Writing the stubs for JSR 169 was a much smaller
> task, though, since we only needed to strip down a small subset
> (java.sql.* and javax.sql.*) of Harmony's class library. Now we're
> talking more or less about the full class library. Before we go ahead,
> we should probably sort out these things:
>
> o Does Harmony implement all of Foundation Profile 1.1?
>
> o How can we ensure that the stubs have the exact same signatures as the
> specification, are complete, and contain no extra classes, interfaces or
> methods?
>   
Right. This is a chunk of work which I doubt that anyone is eager to do.
> The original topic of this thread, and the thread on derby-user, was to
> remove the build-dependency on JDK 1.4. Some components still need to be
> compiled against the 1.4 libraries (client driver, dynamically loaded
> nio modules, JDBC 3.0 driver), so compiling most of the engine against
> FP doesn't solve that problem, unless we either
>
>  a) drop support for J2SE 1.4, or
>
>  b) include stubs for J2SE 1.4
>   
I'm not following you. I think that we continue to claim support  for 
JDK1.4 if we

1) claim support for CDC/FP 1.1, which is a subset of JDK1.4

2) provide a JDBC3 driver
> I'd say that if we choose to implement stubs for Foundation Profile, we
> should do the same for all the class libraries we require (1.4 and 1.5)
> so that only one Java version is needed on your system in order to build
> Derby. (I fear though that this means that most of our code base will be
> class library stubs and not database code...)
>   
I guess we could do that. Seems like pulling more of the ball of yarn 
than we need to.
> What I proposed in my previous mail, might be a simpler short-term
> solution, although it doesn't address the lack of compile-time
> checking. But it would address the JDK 1.4 dependency, which is not
> addressed by creating FP stubs. We would then do something like this in
> our build scripts (perhaps in the PropertySetter ant task?):
>
>  1) set the Java 1.5 compile classpath as we do today
>
>  2) set the Java 1.4 compile classpath as we do today if Java 1.4 is
>     found, otherwise construct one that uses the 1.5 compile classpath
>
>  3) set the JSR 169 compile classpath as we do today (use
>     jsr169compile.classpath if set, otherwise construct one as
>     java14compile.classpath + stubs)
>
>   
Something along those lines sounds promising. I would be content with a 
two part solution:

I) A simple build for people who are new to the community. This builds 
everything including the JSR169, JDBC3, and JDBC4 drivers. Extra credit 
if all you need is the Derby source and a Java 5 compiler.

II) A straightforward way for derby-dev(elopers) to plug in other 
libraries to verify at compile-time that

a) the core engine doesn't spill outside the CDC/FP limits
b) the JDBC3 driver and network server don't spill outside the JDK1.4 limits

I suspect that this means we need to supply:

i) JSR169 stubs (already done)
ii) JDBC3 stubs
iii) JDBC4 stubs

Regards,
-Rick



Mime
View raw message