felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcel Offermans <marcel.offerm...@luminis.nl>
Subject Re: Moving scr to java 6?
Date Sat, 05 May 2012 09:52:29 GMT
On May 5, 2012, at 3:58 AM, David Jencks wrote:
> On May 4, 2012, at 12:46 PM, Valentin Valchev wrote:
>> On 4.5.2012 г. 20:11 ч., David Jencks wrote:
>>> I'd like to suggest moving scr trunk to java 6.  I realize there are people still
using various jdk 1.3 with scr butI think it is getting less and less plausible to keep trunk
at that level.
>>> -- I don't think there is any plausible way to solve the concurrency problems
without using modern concurrency constructs such as ReentrantLock
>>> -- I'd like to enhance the scr commands to use regexes to provide more flexibility
with which bundles you are asking about
>>> -- consistent use of @Override would help find bugs earlier (we had one such
>>> To support 1.3 level users we could either keep a branch alive or see if retrotranslator
still works.
>>> Thoughts?
>> Maybe we can investigate the possibility to use Java 6 language
>> constructs, but stick with Java 1.3 API. This would allow us to use
>> http://retrotranslator.sourceforge.net/ on the target bundles, which
>> will make them run on older VMs.
> Retrotranslator uses the oswego concurrency library (that was the inspiration for the
java 5 concurrency features) for the concurrency constructs.  IMO it is not acceptable to
ask a java 5+ user to use this library when the jvm has better versions.  So if we want to
try to provide these bug fixes to jdk 1.3 I think we need two jars.  We could try retrotranslator
on the trunk code.  On the other hand since the concurrency problems only seem to show up
under highly multithreaded server conditions, maybe someone on jdk 1.3 doesn't need them and
maintaining a branch would be sufficient.

This discussion started with the issue that there are concurrency problems in SCR. You state,
David, that these would be hard or even impossible to solve without using modern concurrency
constructs and that therefore we need to move to Java 5, 6 or 7. Whilst I agree that the concurrency
constructs that are offered in Java 5+ make it easier to solve concurrency problems, the fundamental
way to solve them is by design and once you've done that it does not matter that much if you
use the Oswego library, the Java 5+ package, or any other implementation of such a primitive
(you probaby won't need all of them, so you can just embed one or two classes you need). Therefore,
I personally do not see the need to move to Java5+ and/or fork the implementation.

Greetings, Marcel

View raw message