Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@apache.org Received: (qmail 93318 invoked from network); 27 Nov 2001 05:08:35 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 27 Nov 2001 05:08:35 -0000 Received: (qmail 10715 invoked by uid 97); 27 Nov 2001 05:08:44 -0000 Delivered-To: qmlist-jakarta-archive-commons-dev@jakarta.apache.org Received: (qmail 10697 invoked by uid 97); 27 Nov 2001 05:08:42 -0000 Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Jakarta Commons Developers List" Reply-To: "Jakarta Commons Developers List" Delivered-To: mailing list commons-dev@jakarta.apache.org Received: (qmail 10686 invoked from network); 27 Nov 2001 05:08:42 -0000 Message-ID: From: Elli Albek To: Jakarta Commons Developers Subject: RE: Fast collections thread safe? Date: Mon, 26 Nov 2001 21:05:20 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N One more iteration. Check out the link, I think we have exactly the same problem with fast collections. The new clone of the collection might be flushed to shared memory after its reference is. So other threads will see the object reference to the new collection, but the memory space for that object will be corrupt. So even though the pointer to the object is there, trying to use the object can have unexpected results. As weird as it sounds, I have seen these thing happen on multi CPU machines (that was a long time ago, JDK 1.1.7, but I am under the impression that the problem still exists). the article: http://www.javaworld.com/javaworld/jw-05-2001/jw-0525-double.html E -----Original Message----- From: Jan Sorensen [mailto:sorensenjan@yahoo.com] Sent: Thursday, September 27, 2001 5:09 AM To: Jakarta Commons Developers Subject: RE: Fast collections thread safe? I realized that you can actually call the clone method through reflection, something like: Class c = object.getClass(); Method m = c.getDeclaredMethod("clone", null); // Should search of the super chain copy = m.invoke(obj, null); The getDeclaredMethod will get the clone method, and if the method is public invoke will successful execute it. In case object does not have a public clone, an exception will be thrown. For use in the fast collections, I think all the relevant collection implementation class provide a public clone, so I think it would work. -- Jan Sorensen --- Jan Sorensen wrote: > Date: Wed, 26 Sep 2001 23:44:48 -0700 (PDT) > From: Jan Sorensen > Subject: RE: Fast collections thread safe? > To: Jakarta Commons Developers > > > I agree 100% with you, it doesn't make sense when > the > interfaces doesn't provide a clone. Didn't think > about > that. > > -- > Jan Sorensen > > --- Elli Albek wrote: > > The problem with that is that you will need to > clone > > the wrapped > > collections, and the java.util package interfaces > to > > not support cloning. > > The implementing classes do support cloning. > > If we assume that the wrappers work directly on > the > > class and not the > > interface, then providing a wrapper API or an > actual > > class implementation > > API (as it is today) does not make any difference. > > > > Example: > > We cannot do something like > > Map FastCollections.fastMap(Map m) > > because Map does not support cloning. > > > > We will have to do something like: > > HashMap FastCollections.fastMap(HashMap m) > > > > and this is not much different than doing > > > > new FastHashMap(); > > > > My 2 cents > > > > E > > > > > > -----Original Message----- > > From: Jan Sorensen [mailto:sorensenjan@yahoo.com] > > Sent: Wednesday, September 26, 2001 12:00 AM > > To: Jakarta Commons Developers > > Subject: RE: Fast collections thread safe? > > > > > > Wouldn't it make sense to implemnt the fast > > collections as a kind of wrapper classes, similar > to > > Collections.synchronizedXxxxx. We could then > > implemnt > > FastMap, FastList, FastSet, FastCollection etc, > and > > get a "fast" version of all the collection > > interfaces. > > > > -- > > Jan Sorensen > > aragost > > > > > > --- "Craig R. McClanahan" > > wrote: > > > > > > > > > On Tue, 25 Sep 2001, Elli Albek wrote: > > > > > > > [snip] > > > > By the way, the FastArrayList is subclassing > > > ArrayList but not using > > > > anything of it. > > > > I tried: > > > > public class FastArrayList extends > > > java.util.AbstractList { > > > > > > > > and: > > > > public class FastArrayList implements > > > java.util.List{ > > > > > > > > And they both compile. > > > > > > > > > > The reasoning for this subclassing was as > follows: > > > > > Even though the > > > Collections APIs tell people they should pass > List > > > as a method parameter > > > (instead of ArrayList), some people persist in > > > passing ArrayList instead. > > > If they did that, FastArrayList would not be a > > > plug-compatible > > > replacement. > > > > > > The argument is a little weak, and I'd be OK for > > > changing it -- if we > > > hadn't released it as is in Collections 1.0. > > > Unfortunately, changing it > > > now would be backwards incompatible for anyone > who > > > relied on the above > > > reasoning. > > > > > > > E > > > > > > > > > > Craig > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: > > > commons-dev-unsubscribe@jakarta.apache.org > > > For additional commands, e-mail: > > > commons-dev-help@jakarta.apache.org > > > > > > > > > __________________________________________________ > > Do You Yahoo!? > > Get email alerts & NEW webcam video instant > > messaging with Yahoo! Messenger. > > http://im.yahoo.com > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: > > commons-dev-unsubscribe@jakarta.apache.org > > For additional commands, e-mail: > > commons-dev-help@jakarta.apache.org > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: > > commons-dev-unsubscribe@jakarta.apache.org > > For additional commands, e-mail: > > commons-dev-help@jakarta.apache.org > > > > > __________________________________________________ > Do You Yahoo!? > Listen to your Yahoo! Mail messages from any phone. > http://phone.yahoo.com > __________________________________________________ Do You Yahoo!? Listen to your Yahoo! Mail messages from any phone. http://phone.yahoo.com --------------------------------------------------------------------- To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: commons-dev-help@jakarta.apache.org -- To unsubscribe, e-mail: For additional commands, e-mail: