Many thanks for your efforts, Darren!
=20
Good that you caught that Commons Collections issue with 0 as initial =
capacity. This is a notable difference to the JDK 1.4 collection =
implementations, which simply use 1 as minimal capacity in such a case.
=20
Renaming test classes to allow for easier exclusion is OK too. I'd just =
like to avoid Jdk14* naming in public classes in Spring itself - classes =
like JdkRegexpMethodPointcut will work on JDK >=3D 1.4, so Jdk14*-style =
naming would look somewhat dated pretty soon.
=20
Juergen
=20
________________________________
Von: spr...@li... im Auftrag =
von Darren Davison
Gesendet: So 21.11.2004 12:13
An: spr...@li...
Betreff: [Springframework-developer] JDK 1.3 compatibility (again)
After a recent mail about Spring issues in JDK 1.3, I did a little more
testing on my own machines, and the SF CF machines. It's quite =
important
to me as we're one of the laggard companies that still uses it via
WebSphere 5.0.x!
I ran the entire test suite (built obviously with a 1.4 JDK) on 1.3 and =
was
actually pretty pleased with the results. There were 6 failures and 24
errors. Here's a brief breakdown for those interested;
Of the 24 errors..
* 9 are due to references to java.sql.Savepoint in the test cases,
* 7 are due to running tests explicitly designed for JDK 1.4 (for =
example
Jdk14ControlFlowTests and JdkRegexpMethodPointcutTests) which can be
excluded with test.excludes=3D... I renamed =
JdkRegexpMethodPointcutTests to
Jdk14RegexpMethodPointcutTests if that's ok? Makes it easier to exclude
tests by naming patterns.
* 2 are in a large test class and reference java.util.prefs - these =
tests
have been amended to simply return if JDK 1.3 is detected.
Of the remaining 6, 2 are caused by the new
org.springframework.core.CollectionFactory since it doesn't check the
initialCapacity parameter before creating a Commons Collection instance =
on
JDK 1.3. Commons Collections cannot have an initial capacity of 0. =
I've
changed the code in this class and added corresponding tests Juergen. =
Just
committed if you want to check.
The remaining 4 errors probably need looking at on a case by case basis =
to
see if they would cause usage issues or if they are just test code =
issues=20
- I haven't had time to check these yet.
The 6 failures are all in ResourceBundleMessageSourceTests and are =
mildly
concerning as I think this would cause a usage failure if anyone =
depended
on this functionality. It seems (without going into it closely) that =
all
the failures occur when a resource bundle is referenced with a Locale =
that
specifies a country, language AND a variant in its constructor. It =
seems
that the variant is ignored and the resource bundle corresponding to the
country and language only is used instead.
I'll post more later. Got to go sort out my son's birthday party now.
--
Darren Davison
Public Key: #DD356B0D
|
