Bug #19331 I think this should be fixed in the cvs code base as we do detect cycles with the reflection version of the code. Of course, if two classes both implement their own toString() methods and point to each other, that is still a problem.
Gary -----Original Message----- From: Henri Yandell [mailto:[EMAIL PROTECTED] Sent: Sunday, June 22, 2003 21:02 To: Jakarta Commons Developers List Subject: Re: [lang] What's left for 2.0 2.0 time again. As far as I can tell, all we have left are: Bug #15082. Stephen has done some work here, and suggests making DurationFormatUtils package scoped for 2.0. +1 from me, anyone against it? Bug #19331 Some kind of issue with the builders. Mohan has a good reply here, is it a real problem or just a feature? Do we kill or solve? Are there any others that people think should go in? Are there any other tasks that people are working on or have open? Hen On Sun, 15 Jun 2003, Henri Yandell wrote: > > > On Wed, 4 Jun 2003, Gary Gregory wrote: > > > We have over the last couple of weeks started "what's left for 2.0" message > > threads a couple of times, do people here want a 2.0 (or a 2.0 beta first)? > > Yep. Time for another one soon. [email I mean]. I'm in favour of just > going straight to a 2.0 rather than pushing a beta out. I'm not sure that > reusable libraries as abstract as ours [and not a service like maven, > tomcat etc] gain much from a beta release. > > Apologies for some of the questions coming up and for reopening of old > emails, I've been gone for 3 weeks. > > > Should we consider: > > > > (1) IntHashMap as a non-public member of [lang] > > > > In for 2.0, or defer to discuss (2)? > > This was for Entities.java optimisation? Sounds good to go in. > > > (2) "all his other utility code" > > > > Does not affect [lang] per se but it is becoming clear that keeping [lang] > > and [collections] not inter-dependent will introduce duplication of > > functionality or odd placement of functionality (IntHashMap in lang, not > > collection). Duplicating code is something I am really not fond of. > > I think this is a clear case of a good reason for allowing duplication. > Optimisation involves lots of yucky things [and rarely anything nice]. > Duplication is a yucky thing, but the optimisation is more important. > > Hen > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
