Am 17.02.2011 02:10, schrieb Ralph Goers:
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
This is really a good question. AFAIK other Commons components switched
to Java 1.5 only in a major release, but given the current situation
with end of support for older JDKs, it may be worth starting a new
discussion.
OTOH I would not have a major problem with switching to Java 1.5, doing
some slight API improvements by introducing generics etc., and calling
this version 2.0. (Maybe we have then again a discussion whether package
names must be changed.)
I am not very happy with the experimental branch, too. If time permits,
I would like to start something new in the sandbox from scratch to
overcome some of the problems in our current design (e.g. the tight
coupling of the reloading mechanism which causes these synchronization
problems).
Oliver
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
