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
