|
From: <jue...@we...> - 2004-11-21 12:25:16
|
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 |