Rick Hillegas <[EMAIL PROTECTED]> writes: > Bryan Pendleton wrote: >>> 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 >> >> Perhaps we are trying to force the build to do too much? >> >> Would it be easier to verify this via testing, than at build time? >> >> For example: >> - to verify that we are compatible with JDK 1.4, we should test >> under 1.4 >> - to verify that we are compatible with JDBC 3.0, we should test >> under JDBC 3.0 >> - to verify that we work in a CDC/FP environment, we should >> test in a CDC/FP environment >> >> I have no idea whether this actually makes things simpler or >> harder, just wanted to toss this out there to see if it was useful. >> >> thanks, >> >> bryan > I don't think this would be a step backward for CDC/FP support. We > rely on test-time checks for our claims about small device > support. For our JDK1.4 claims, I think that we already provide > support for plugging in the JDK1.4 libraries so that we verify that > support at compile-time. The incremental work here would be a little > tweaking to make the build use the small device libraries (rather than > the JDK1.4 libraries) when building the core engine and network > server. I'm guessing that this is just a little tweaking but the devil > could be in the details.
Another point is that we can't guarantee by testing alone that no JDK 5 methods have been used, thereby breaking the JDK 1.4 support, unless we have 100% test coverage. Compile-time checks would also discover problems in code paths that are not exercised by the tests. -- Knut Anders
