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 recently) >>> >>> 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
