Knut Anders Hatlen <[email protected]> writes: > Rick Hillegas <[email protected]> writes: > >> Starting on 2011-11-08, the JDK 1.4 test results began to show 2 >> errors which don't appear on other platforms. The errors are >> NoSuchMethodErrors raised by calling a BigDecimal constructor which >> appears in Java 5 but not JDK 1.4. The offending Derby test code was >> checked in on 2011-03-29 at subversion revision 1086799 as part of the >> work on DERBY-2515. I would have expected to see this error long >> before 2011-11-08. Any theories about why it popped up only last week? > > It coincides with the simplification of PropertySetter, so here's my > theory (I don't have the build scripts for the nightlies handy right > now, so I can't tell for sure): > - Before 2011-11-08, PropertySetter would find the 1.4.2 run-time > libraries and compile against them. Since there is no BigDecimal(int) > constructor in 1.4.2, the compiler promotes the int argument to a > double and produces byte code that calls BigDecimal(double). > > - After 2011-11-08, PropertySetter no longer looks for old libraries, > and instead constructs a classpath based on the Java 6 libraries, > which do contain the BigDecimal(int) constructor. So the int is not > promoted to a double, and the byte code calls BigDecimal(int), which > is not available on Java 1.4.2.
Almost... I checked the scripts used in the nightly build job, and they explicitly point j14lib to a Java 1.4.2 installation. That would explain why the class was compiled to something that worked on Java 1.4.2 before 2011-11-08. j14lib is still set by the scripts, but DERBY-5485 also replaced all occurrences of java14compile.classpath with java15compile.classpath in the build scripts, so now we'll compile this class against the Java 5 libraries even if j14lib is set. That explains why the byte code now calls the new constructor introduced in Java 5 instead of promoting the int to a double and calling the Java 1.4 constructor. -- Knut Anders
