commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <ralph.go...@dslextreme.com>
Subject Re: [configuration] Compilation under Java 1.4
Date Thu, 17 Feb 2011 07:27:45 GMT
As I see it, the problem with the experimental branch is that we haven't yet "flipped" the
configuration so that everything is based on a HierarchicalConfiguration nor have we gotten
rid of the attribute splitting stuff. The reloading is mostly a problem with how CombinedConfiguration
works - having the combination point into the trees of the various configurations makes reloading
a nightmare.

As for 2.0 - I first need to finish the VFS release so we can release 1.7.  I'm not happy
with the way I have to generate release notes but I haven't had time to create a plugin to
do it correctly, primarily because the changes plugin wasn't designed to allow another plugin
to make use of its functionality.

Ralph

On Feb 16, 2011, at 11:04 PM, Oliver Heger wrote:

> 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.heger@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-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>> 
>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message