You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openjpa.apache.org by Patrick Linskey <pl...@gmail.com> on 2007/06/05 01:22:11 UTC
[DISCUSS] use backport-concurrent instead of repackaged concurrent classes
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
Re: [DISCUSS] use backport-concurrent instead of repackaged concurrent classes
Posted by Patrick Linskey <pl...@gmail.com>.
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 <pl...@gmail.com> 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 <da...@yahoo.com> 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
Re: [DISCUSS] use backport-concurrent instead of repackaged concurrent classes
Posted by Patrick Linskey <pl...@gmail.com>.
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 <da...@yahoo.com> 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
Re: [DISCUSS] use backport-concurrent instead of repackaged concurrent classes
Posted by David Jencks <da...@yahoo.com>.
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
Re: [DISCUSS] use backport-concurrent instead of repackaged concurrent
classes
Posted by Craig L Russell <Cr...@Sun.COM>.
+1 and there is still good reason to support 1.4
Craig
On Jun 4, 2007, at 5:11 PM, Dain Sundstrom wrote:
> +1 (but I'd rather just drop 1.4 support)
>
> -dain
>
> 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
>
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: [DISCUSS] use backport-concurrent instead of repackaged concurrent classes
Posted by Dain Sundstrom <da...@iq80.com>.
+1 (but I'd rather just drop 1.4 support)
-dain
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
Re: [DISCUSS] use backport-concurrent instead of repackaged concurrent
classes
Posted by Craig L Russell <Cr...@Sun.COM>.
+1
Craig
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
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: [DISCUSS] use backport-concurrent instead of repackaged concurrent classes
Posted by Brian McCallister <br...@skife.org>.
On Jun 4, 2007, at 6:58 PM, Patrick Linskey wrote:
> To date, OpenJPA has done minimal repackaging (currently only the EDU
> classes). I'm wary of changing this policy, especially considering how
> few classes we repackage. In fact, I think that not repackaging the
> backport classes is a good thing, as it lets people easily plug in the
> faster Java 5 version without having to then re-repackage those
> classes and recompile them.
>
> Any other opinions?
It is case by case, of course. As mentioned, backport is probably not
worth repackaging. My tendency, for small libraries, is to prefer
repackaging :-)
-Brian
>
> -Patrick
>
> On 6/4/07, Brian McCallister <br...@apache.org> wrote:
>>
>> 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 <br...@apache.org> 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
>>
>>
>
>
> --
> Patrick Linskey
> 202 669 5907
Re: [DISCUSS] use backport-concurrent instead of repackaged concurrent classes
Posted by Brian McCallister <br...@apache.org>.
On Jun 4, 2007, at 7:03 PM, Craig L Russell wrote:
> [If interfaces change in an incompatible way on most minor
> releases, as in your ehcache example, I'd think twice about using
> the package at all. Not brilliant change management IMHO.]
EHCache actually kept the interface compatible, it is Hibernate that
won't allow the upgrade. That is a whole other story.
Ideally folks would change package names for major version releases,
but it doesn't usually happen in java-land, sadly.
-Brian
Re: [DISCUSS] use backport-concurrent instead of repackaged concurrent
classes
Posted by Craig L Russell <Cr...@Sun.COM>.
On Jun 4, 2007, at 6:58 PM, Patrick Linskey wrote:
> To date, OpenJPA has done minimal repackaging (currently only the EDU
> classes). I'm wary of changing this policy, especially considering how
> few classes we repackage. In fact, I think that not repackaging the
> backport classes is a good thing, as it lets people easily plug in the
> faster Java 5 version without having to then re-repackage those
> classes and recompile them.
>
> Any other opinions?
I'm also allergic to repackaging (re-namespacing). I agree that it's
inconvenient if the dependency changes its interfaces but that's
usually in a major release.
[If interfaces change in an incompatible way on most minor releases,
as in your ehcache example, I'd think twice about using the package
at all. Not brilliant change management IMHO.]
Craig
>
> -Patrick
>
> On 6/4/07, Brian McCallister <br...@apache.org> wrote:
>>
>> 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 <br...@apache.org> 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
>>
>>
>
>
> --
> Patrick Linskey
> 202 669 5907
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: [DISCUSS] use backport-concurrent instead of repackaged concurrent
classes
Posted by Craig L Russell <Cr...@Sun.COM>.
+1 for binary dependency on backport.
Craig
On Jun 6, 2007, at 9:53 AM, Patrick Linskey wrote:
> No, I'm suggesting that we pull it in as a binary prereq, and that we
> use the backport stuff instead of Doug's old stuff.
>
> -Patrick
>
> On 6/6/07, Kevin Sutter <kw...@gmail.com> wrote:
>> Let me see if I understand the proposal...
>>
>> We want to get an updated version of Doug Lea's concurrency
>> libraries into
>> OpenJPA. Not as a binary prereq like Serp or Commons
>> Collections. But,
>> rather we will bring the source into the OpenJPA svn repository
>> and build it
>> like it was ours, but we don't want to change the package names?
>>
>> I think this is asking for problems down the road. At least with
>> binary
>> prereqs, we can identify the specific version that we require and
>> deal with
>> any incompatibilities between releases. But, if we just bring the
>> source
>> into our tree without re-packaging, then we have no idea whether
>> we are
>> running with the version that we ship or some other version that
>> happens to
>> be available via the application's classpath. As OpenJPA
>> continues to be
>> incorporated into larger and larger environments, we have to be
>> concerned
>> about our prereqs (source or binary) and how they will interact
>> with the
>> rest of the environment.
>>
>> I would vote to stick with our current practice of bringing in
>> Doug Lea's
>> libraries and putting them into our own packaging scheme to avoid any
>> possible conflicts with other instances of these libraries.
>>
>> Thanks,
>> Kevin
>>
>> On 6/4/07, Brian McCallister <br...@skife.org> wrote:
>> >
>> >
>> > On Jun 4, 2007, at 6:58 PM, Patrick Linskey wrote:
>> >
>> > > In fact, I think that not repackaging the
>> > > backport classes is a good thing, as it lets people easily
>> plug in the
>> > > faster Java 5 version without having to then re-repackage those
>> > > classes and recompile them.
>> >
>> > This is a really good reason to not renamespace, actually, as it is
>> > reasonable for people to want to change between distributed
>> options.
>> >
>> > -Brian
>> >
>>
>
>
> --
> Patrick Linskey
> 202 669 5907
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: [DISCUSS] use backport-concurrent instead of repackaged concurrent classes
Posted by Kevin Sutter <kw...@gmail.com>.
Thanks for the clarification. I understood that we were going to replace
Doug's libraries with the backport stuff, but it didn't sound like we were
proposing the binary prereq approach. I also just checked on the licensing
of the backport stuff (
http://dcl.mathcs.emory.edu/util/backport-util-concurrent/index.php) and it
looks like it's covered by the Creative Commons public domain licensing, so
that's good. This sounds like an okay approach.
On 6/6/07, Patrick Linskey <pl...@gmail.com> wrote:
>
> No, I'm suggesting that we pull it in as a binary prereq, and that we
> use the backport stuff instead of Doug's old stuff.
>
> -Patrick
>
> On 6/6/07, Kevin Sutter <kw...@gmail.com> wrote:
> > Let me see if I understand the proposal...
> >
> > We want to get an updated version of Doug Lea's concurrency libraries
> into
> > OpenJPA. Not as a binary prereq like Serp or Commons Collections. But,
> > rather we will bring the source into the OpenJPA svn repository and
> build it
> > like it was ours, but we don't want to change the package names?
> >
> > I think this is asking for problems down the road. At least with binary
> > prereqs, we can identify the specific version that we require and deal
> with
> > any incompatibilities between releases. But, if we just bring the
> source
> > into our tree without re-packaging, then we have no idea whether we are
> > running with the version that we ship or some other version that happens
> to
> > be available via the application's classpath. As OpenJPA continues to
> be
> > incorporated into larger and larger environments, we have to be
> concerned
> > about our prereqs (source or binary) and how they will interact with the
> > rest of the environment.
> >
> > I would vote to stick with our current practice of bringing in Doug
> Lea's
> > libraries and putting them into our own packaging scheme to avoid any
> > possible conflicts with other instances of these libraries.
> >
> > Thanks,
> > Kevin
> >
> > On 6/4/07, Brian McCallister <br...@skife.org> wrote:
> > >
> > >
> > > On Jun 4, 2007, at 6:58 PM, Patrick Linskey wrote:
> > >
> > > > In fact, I think that not repackaging the
> > > > backport classes is a good thing, as it lets people easily plug in
> the
> > > > faster Java 5 version without having to then re-repackage those
> > > > classes and recompile them.
> > >
> > > This is a really good reason to not renamespace, actually, as it is
> > > reasonable for people to want to change between distributed options.
> > >
> > > -Brian
> > >
> >
>
>
> --
> Patrick Linskey
> 202 669 5907
>
Re: [DISCUSS] use backport-concurrent instead of repackaged concurrent classes
Posted by Patrick Linskey <pl...@gmail.com>.
No, I'm suggesting that we pull it in as a binary prereq, and that we
use the backport stuff instead of Doug's old stuff.
-Patrick
On 6/6/07, Kevin Sutter <kw...@gmail.com> wrote:
> Let me see if I understand the proposal...
>
> We want to get an updated version of Doug Lea's concurrency libraries into
> OpenJPA. Not as a binary prereq like Serp or Commons Collections. But,
> rather we will bring the source into the OpenJPA svn repository and build it
> like it was ours, but we don't want to change the package names?
>
> I think this is asking for problems down the road. At least with binary
> prereqs, we can identify the specific version that we require and deal with
> any incompatibilities between releases. But, if we just bring the source
> into our tree without re-packaging, then we have no idea whether we are
> running with the version that we ship or some other version that happens to
> be available via the application's classpath. As OpenJPA continues to be
> incorporated into larger and larger environments, we have to be concerned
> about our prereqs (source or binary) and how they will interact with the
> rest of the environment.
>
> I would vote to stick with our current practice of bringing in Doug Lea's
> libraries and putting them into our own packaging scheme to avoid any
> possible conflicts with other instances of these libraries.
>
> Thanks,
> Kevin
>
> On 6/4/07, Brian McCallister <br...@skife.org> wrote:
> >
> >
> > On Jun 4, 2007, at 6:58 PM, Patrick Linskey wrote:
> >
> > > In fact, I think that not repackaging the
> > > backport classes is a good thing, as it lets people easily plug in the
> > > faster Java 5 version without having to then re-repackage those
> > > classes and recompile them.
> >
> > This is a really good reason to not renamespace, actually, as it is
> > reasonable for people to want to change between distributed options.
> >
> > -Brian
> >
>
--
Patrick Linskey
202 669 5907
Re: [DISCUSS] use backport-concurrent instead of repackaged concurrent classes
Posted by Kevin Sutter <kw...@gmail.com>.
Let me see if I understand the proposal...
We want to get an updated version of Doug Lea's concurrency libraries into
OpenJPA. Not as a binary prereq like Serp or Commons Collections. But,
rather we will bring the source into the OpenJPA svn repository and build it
like it was ours, but we don't want to change the package names?
I think this is asking for problems down the road. At least with binary
prereqs, we can identify the specific version that we require and deal with
any incompatibilities between releases. But, if we just bring the source
into our tree without re-packaging, then we have no idea whether we are
running with the version that we ship or some other version that happens to
be available via the application's classpath. As OpenJPA continues to be
incorporated into larger and larger environments, we have to be concerned
about our prereqs (source or binary) and how they will interact with the
rest of the environment.
I would vote to stick with our current practice of bringing in Doug Lea's
libraries and putting them into our own packaging scheme to avoid any
possible conflicts with other instances of these libraries.
Thanks,
Kevin
On 6/4/07, Brian McCallister <br...@skife.org> wrote:
>
>
> On Jun 4, 2007, at 6:58 PM, Patrick Linskey wrote:
>
> > In fact, I think that not repackaging the
> > backport classes is a good thing, as it lets people easily plug in the
> > faster Java 5 version without having to then re-repackage those
> > classes and recompile them.
>
> This is a really good reason to not renamespace, actually, as it is
> reasonable for people to want to change between distributed options.
>
> -Brian
>
Re: [DISCUSS] use backport-concurrent instead of repackaged concurrent classes
Posted by Brian McCallister <br...@skife.org>.
On Jun 4, 2007, at 6:58 PM, Patrick Linskey wrote:
> In fact, I think that not repackaging the
> backport classes is a good thing, as it lets people easily plug in the
> faster Java 5 version without having to then re-repackage those
> classes and recompile them.
This is a really good reason to not renamespace, actually, as it is
reasonable for people to want to change between distributed options.
-Brian
Re: [DISCUSS] use backport-concurrent instead of repackaged concurrent classes
Posted by Patrick Linskey <pl...@gmail.com>.
To date, OpenJPA has done minimal repackaging (currently only the EDU
classes). I'm wary of changing this policy, especially considering how
few classes we repackage. In fact, I think that not repackaging the
backport classes is a good thing, as it lets people easily plug in the
faster Java 5 version without having to then re-repackage those
classes and recompile them.
Any other opinions?
-Patrick
On 6/4/07, Brian McCallister <br...@apache.org> wrote:
>
> 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 <br...@apache.org> 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
>
>
--
Patrick Linskey
202 669 5907
Re: [DISCUSS] use backport-concurrent instead of repackaged concurrent classes
Posted by Brian McCallister <br...@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 <br...@apache.org> 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
Re: [DISCUSS] use backport-concurrent instead of repackaged concurrent classes
Posted by Patrick Linskey <pl...@gmail.com>.
I'm allergic to re-namespacing... why do you think that we should do so?
-Patrick
On 6/4/07, Brian McCallister <br...@apache.org> 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
Re: [DISCUSS] use backport-concurrent instead of repackaged concurrent classes
Posted by Brian McCallister <br...@apache.org>.
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