Incidentally, one benefit of using the backport classes is that there is a special Java 5 version of them available, which is optimized to use the new Java 5 language features for better performance. So, that could end up being all we need to do to resolve all these issues in the long run.
-Patrick On 6/4/07, Patrick Linskey <[EMAIL PROTECTED]> wrote:
Last time we discussed this, we decided that JDK1.4 support was still a goal. I have never used retrotranslator, so have no opinions about its utility. However, if the question is begged, I'd like to separate it from this issue -- the switch to the backport APIs is easy (it's available in maven), and would let me check in some related scalability-related work that I've been itching to get integrated into the mainline. I expect that the discussion on JDK1.4 support is somewhat more involved. -Patrick On 6/4/07, David Jencks <[EMAIL PROTECTED]> wrote: > This begs the question of what the need to support jdk 1.4 is, and > whether the jdk 1.4 use case is small enough so it can be handled > with retrotranslator so the actual code and use the real jdk 1.5 > concurrent library. > > thanks > david jencks > > On Jun 4, 2007, at 4:22 PM, Patrick Linskey wrote: > > > Hi, > > > > In the process of doing some concurrency-related work on OpenJPA, I've > > run across the need for a ReentrantReadWriteLock, akin to what is in > > Java 5's java.util.concurrent package, Emory University's > > edu.emory.mathcs.backport package, and Doug Lea's EDU.oswego.cs.dl > > package. > > > > Currently, OpenJPA has repackaged copies of some of the code from > > EDU.oswego.cs.dl, but not everything. I'd like to get rid of the > > repackaged copies, and move to the versions in > > edu.emory.mathcs.backport. According to Doug Lea's website, the > > backport classes are preferable to the EDU.oswego.cs.dl classes at > > this point. > > > > This change is independent of future changes to allow for pluggability > > of the concurrent implementation, and only impacts those classes that > > we are already directly repackaging. > > > > Thoughts? > > > > -Patrick > > > > -- > > Patrick Linskey > > 202 669 5907 > > -- Patrick Linskey 202 669 5907
-- Patrick Linskey 202 669 5907
