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? >> >> thanks >> david jencks >> >> >> > 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. thanks david jencks > > -- > > ------------------------------------------------- > Valentin Valchev · Lead Software Engineer > ProSyst Labs EOOD > 1606 Sofia, Bulgaria · 48 Vladajska Str. > Tel. +359 (0)2 952 35 81; Fax +359 (0)2 953 26 17 > http://www.prosyst.com · [email protected] > ------------------------------------------------- > stay in touch with your product. > ------------------------------------------------- > > <v_valchev.vcf>
