Thanks. But I have a larger issue. We have been doing performance testing and the synchronization in AbstractFileConfiguration, DynamicCombinedConfiguration, and MultiFileHierarchicalConfiguration are showing up as predominant hot spots. These would be easy to fix if I could use java.util.concurrent but, of course, that would require an upgrade to Java 5. The experimental branch has a minimum version of Java 5 but it is nowhere near ready for a release. I'm wondering when the right time to upgrade would be? 1.8?
Ralph On Feb 16, 2011, at 1:48 PM, Jörg Schaible wrote: > Hi Oliver, > > Oliver Heger wrote: > >> Am 16.02.2011 22:05, schrieb Rahul Akolkar: >>> On Wed, Feb 16, 2011 at 3:45 PM, Oliver Heger >>> <oliver.he...@oliver-heger.de> wrote: >>>> Am 15.02.2011 21:23, schrieb Oliver Heger: >>>>> >>>>> Am 10.02.2011 13:09, schrieb sebb: >>>>>> >>> <snip/> >>>>>> >>>>>> FYI: >>>>>> >>>>>> Note that the Commons Parent POM was changed some while ago to add >>>>>> profiles java-1.4, java-1.3 etc. which change the Java version used >>>>>> for compile and test without needing to change the JVM used to run >>>>>> Maven itself. >>>>>> >>>>>> See >>>>>> >>>>>> http://commons.apache.org/commons-parent- > pom.html#Testing_with_different_Java_versions >>>>>> >>>>> >>>>> Thanks for the pointer. I will try to exclude the affected classes if >>>>> the profile for Java 1.4 is active. >>>>> >>>> >>>> Just an update: I have added a profile which excludes the problematic >>>> classes when building under JDK 1.4. With the current version of the pom >>>> it is possible to run the following command successfully: >>>> >>>> mvn clean package -Pjava-1.4 >>>> >>>> However, what does not work is the following: If you first build without >>>> the profile (using Java 1.5+), you cannot simply run >>>> >>>> mvn test -Pjava-1.4 >>>> >>>> (i.e. simply running tests without compiling). Test execution is aborted >>>> immediately with a bad class version error, although I excluded the >>>> classes in the configuration of the surefire plug-in. No idea why this >>>> is the case. >>>> >>> <snap/> >>> >>> The sources are already compiled using the higher JDK by then (and mvn >>> test won't clean that compile run). >>> >>> -Rahul >>> >> Yes, but I hoped that the excluded classes would not be loaded at all, >> so it would not be a problem that they have been compiled on a higher >> JDK. But obviously surefire works in a different way. > > You did not exclude the .class files and forgot the anonymous classes ... > ;-) > > Fixed, tests succeed. > > - Jörg > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
