Return-Path: Delivered-To: apmail-openjpa-dev-archive@www.apache.org Received: (qmail 55914 invoked from network); 5 Jun 2007 01:55:46 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 5 Jun 2007 01:55:46 -0000 Received: (qmail 76872 invoked by uid 500); 5 Jun 2007 01:55:49 -0000 Delivered-To: apmail-openjpa-dev-archive@openjpa.apache.org Received: (qmail 76833 invoked by uid 500); 5 Jun 2007 01:55:49 -0000 Mailing-List: contact dev-help@openjpa.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@openjpa.apache.org Delivered-To: mailing list dev@openjpa.apache.org Received: (qmail 76823 invoked by uid 99); 5 Jun 2007 01:55:49 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 04 Jun 2007 18:55:49 -0700 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: local policy includes SPF record at spf.trusted-forwarder.org) Received: from [207.106.133.20] (HELO sceptre.pobox.com) (207.106.133.20) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 04 Jun 2007 18:55:44 -0700 Received: from sceptre (localhost.localdomain [127.0.0.1]) by sceptre.pobox.com (Postfix) with ESMTP id 6F3742F0 for ; Mon, 4 Jun 2007 21:55:44 -0400 (EDT) Received: from [10.0.1.2] (c-69-181-83-36.hsd1.ca.comcast.net [69.181.83.36]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by sceptre.sasl.smtp.pobox.com (Postfix) with ESMTP id 38E5855B23 for ; Mon, 4 Jun 2007 21:55:44 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <7262f25e0706041839i6db068bl70179655f2ea4d8a@mail.gmail.com> References: <7262f25e0706041622n54583ff9v19989dae4a8d5f49@mail.gmail.com> <0898E65B-AD8D-44DA-BE47-97C2205A4BE1@apache.org> <7262f25e0706041839i6db068bl70179655f2ea4d8a@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Brian McCallister Subject: Re: [DISCUSS] use backport-concurrent instead of repackaged concurrent classes Date: Mon, 4 Jun 2007 18:55:06 -0700 To: dev@openjpa.apache.org X-Mailer: Apple Mail (2.752.3) X-Virus-Checked: Checked by ClamAV on apache.org On Jun 4, 2007, at 6:39 PM, Patrick Linskey wrote: > I'm allergic to re-namespacing... why do you think that we should > do so? Avoiding collisions. The majority case is that people don't care about the extra 327k but they care a lot about not hitting conflicts with libraries. Dug Lea's libraries are not a great example of this, but Hibernate *is* a good example -- it relies on EHCache by default, going from 3.0 to 3.1 to 3.2 is a major non-backwards compatible change, and you cannot use EHCache 1.2 with 3.0, so you are trapped unable to upgrade dependencies. Weblogic and ANTLR (a couple versions back) is another great example. Basically, if you are a library (which OpenJPA is) you want to minimize the degree to which you place constraints on the runtime environment of your users. I can easily imagine someone using a home- rolled build of the concurrent backport which was subtly incompatible. Yes, your user could renamespace then, but it is better if they *never have the issue* -Brian > > -Patrick > > On 6/4/07, Brian McCallister wrote: >> I would suggest using backports and repackaging -- though I have >> trouble imaging the interfaces on backports changing. I, personally, >> am of the opinion that if at all possible, small dependencies should >> be re-namespaced and bundled. >> >> -Brian >> >> 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