Re: [Collections] [SUBMIT] Trie
Thanks Craig. With two possible Jakarta users, we seem to have a justification for
inclusion.
So, it is now about practical issues. How does the submitted Trie cope for design and
performance. Do we need a String only Trie, a URL Trie, or does the abstracted Trie
submitted work OK?
The big question is to get the Trie interface correct. In my naive view, it would be
nice if there was no 'Trie' interface, but instead just a Map implementation and a
TrieUtils. TrieUtils would then only use the Map interface to determine the
suffix/prefix/longest cases.
However, this may not be practical. Can I ask all concerned to think about the
interface, and whether the current one is suitable for all the needs we can think of.
Stephen
public interface Trie extends Map {
// Gets all the entries that have keys which start with
// a given prefix.
public Set prefixEntrySet(Object keyPrefix);
// Get the entry with the longest key that is a prefix of
// the given value.
public Map.Entry getLongest(Object key);
}
from:Craig R. McClanahan [EMAIL PROTECTED]
FWIW, there are at least two Jakarta products that I'm involved in (Tomcat
and Struts) that have exactly the path-mapping use case that was described
for the Trie class. And, conveniently, they both already dependd on
[collections] so it would be very convenient to have Trie added here.
It will be very interesting to experiment with the relative speed of using
a Trie in these cases versus the current algorithms (which clearly need
some optimizations).
So, an inactive-committer (to collections) 1 from me for including this.
Craig McClanahan
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[jelly] Stable release?
Hello, I'm curious what is currently the most stable release of Jelly? I checked out the cvs tree and tries to build it, but it seems to break on certain dependencies. I'd like to begin experimenting with Jelly as a Mathematical Simulation tool, not neccessarily as a developer, so I'd like a pretty stable release thats going to not be too buggy. -Mark -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [jelly] Stable release?
From: Mark R. Diggory [EMAIL PROTECTED] Hello, I'm curious what is currently the most stable release of Jelly? I checked out the cvs tree and tries to build it, but it seems to break on certain dependencies. It shouldn't do. Are you using Maven to build it? What problems did you find - it should all just work. I'd like to begin experimenting with Jelly as a Mathematical Simulation tool, not neccessarily as a developer, so I'd like a pretty stable release thats going to not be too buggy. Its pretty stable - its been used in various projects such as Maven for quite some time. Though we do really need to get a release out soon so folks can depend on a formal release. Until now you could depend on a snapshot build from here... http://www.ibiblio.org/maven/commons-jelly/jars/ James --- http://radio.weblogs.com/0112098/ __ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[VOTE] moving Jelly to the commons proper
The Jelly code base has been stable for some time and it'd be good to get a stable release of Jelly out so other projects like Maven, Cactus and Latka can depend on a stable, supported release. So I'd like to propose that Jelly be moved to the commons proper where we can start work on getting things in place for an official release. I'm +1 - Cut Here - I vote as follows on moving Jelly to the Commons Proper: [ ] +1 - I support this move and am willing to help [ ] +0 - I support this move, but cannot assist [ ] -0 - I don't support this move [ ] -1 - I vote against this move (requires valid *technical* reasoning) - Cut Here - James --- http://radio.weblogs.com/0112098/ __ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [Collections] [SUBMIT] Trie
I think interface shold be corrected:
...
// Gets all the entries that have keys which start with
// a given prefix.
public Set prefixEntrySet(Object keyPrefix);
// Get the entry with the longest key that is a prefix of
// the given value.
public Map.Entry getLongest(Object key);
...
Comment:
* key may be String - It is intuitive type for the prefix definition
* key must be of type XString for which prefix definition valid like:
public interface XString {
// number of elements in the XString
int getLength();
// get element it can be character converted to the int, bit value 0 1 for
binary trie or Patricia etc.
int getElement(int i);
}
/Pranas
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: 2002 m. gruodþio 6 d. 14:09
To: [EMAIL PROTECTED]
Subject: Re: [Collections] [SUBMIT] Trie
Thanks Craig. With two possible Jakarta users, we seem to have a
justification for inclusion.
So, it is now about practical issues. How does the submitted Trie cope for
design and performance. Do we need a String only Trie, a URL Trie, or does
the abstracted Trie submitted work OK?
The big question is to get the Trie interface correct. In my naive view, it
would be nice if there was no 'Trie' interface, but instead just a Map
implementation and a TrieUtils. TrieUtils would then only use the Map
interface to determine the suffix/prefix/longest cases.
However, this may not be practical. Can I ask all concerned to think about
the interface, and whether the current one is suitable for all the needs we
can think of.
Stephen
public interface Trie extends Map {
// Gets all the entries that have keys which start with
// a given prefix.
public Set prefixEntrySet(Object keyPrefix);
// Get the entry with the longest key that is a prefix of
// the given value.
public Map.Entry getLongest(Object key);
}
from:Craig R. McClanahan [EMAIL PROTECTED]
FWIW, there are at least two Jakarta products that I'm involved in (Tomcat
and Struts) that have exactly the path-mapping use case that was described
for the Trie class. And, conveniently, they both already dependd on
[collections] so it would be very convenient to have Trie added here.
It will be very interesting to experiment with the relative speed of using
a Trie in these cases versus the current algorithms (which clearly need
some optimizations).
So, an inactive-committer (to collections) 1 from me for including this.
Craig McClanahan
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
was: [VOTE] moving Jelly to the commons proper
James Strachan wrote: The Jelly code base has been stable for some time and it'd be good to get a stable release of Jelly out so other projects like Maven, Cactus and Latka can depend on a stable, supported release. So I'd like to propose that Jelly be moved to the commons proper where we can start work on getting things in place for an official release. I'm not a commiter, just asking: Will the release contain all tag libraries? I think that it would be better to release Jelly with some tag libraries but maybe not with all of them. And release some tag libraries in the independent way. This 'big' library may be hard to maintain then 'core' distribution and set of tag libraries. (Remember problems with logging Log4J support and NPEs?) I think the same applied to Morper component, BTW. Regards Tomek Pik James -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] moving Jelly to the commons proper
+1 Mvgr, Martin On Fri, 2002-12-06 at 15:13, James Strachan wrote: The Jelly code base has been stable for some time and it'd be good to get a stable release of Jelly out so other projects like Maven, Cactus and Latka can depend on a stable, supported release. So I'd like to propose that Jelly be moved to the commons proper where we can start work on getting things in place for an official release. I'm +1 - Cut Here - I vote as follows on moving Jelly to the Commons Proper: [ ] +1 - I support this move and am willing to help [ ] +0 - I support this move, but cannot assist [ ] -0 - I don't support this move [ ] -1 - I vote against this move (requires valid *technical* reasoning) - Cut Here - James --- http://radio.weblogs.com/0112098/ __ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] moving Jelly to the commons proper
From: Tomasz Pik [EMAIL PROTECTED] James Strachan wrote: The Jelly code base has been stable for some time and it'd be good to get a stable release of Jelly out so other projects like Maven, Cactus and Latka can depend on a stable, supported release. So I'd like to propose that Jelly be moved to the commons proper where we can start work on getting things in place for an official release. I'm not a commiter, just asking: Will the release contain all tag libraries? I think that it would be better to release Jelly with some tag libraries but maybe not with all of them. And release some tag libraries in the independent way. This 'big' library may be hard to maintain then 'core' distribution and set of tag libraries. (Remember problems with logging Log4J support and NPEs?) Agreed. I think a small core of Jelly with few dependencies, then other libraries available seperately would be a great idea. Its a common complaint that 'Jelly has lots of dependencies' when really the core is pretty small and has few non-commons dependencies, its just that different libraries have dependencies on other libraries. We could still create a 'one big jar' if need be (like commons-core, or ant-optional etc) or could leave each add-on library as a seperate jar for those wishing a more fine grained control. What I'd really like is a Maven-plugin style model where new libraries and their dependencies could be loaded on demand (if need be) from a small core in a JJAR / Maven / forehead / classworlds kinda way. One of the main aims of proposing Jelly to the commons proper is so that the community can decide the best release form of Jelly. I'd appreciate any feedback on these ideas James --- http://radio.weblogs.com/0112098/ __ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] moving Jelly to the commons proper
+0 - Original Message - From: James Strachan [EMAIL PROTECTED] To: Jakarta Commons Developers [EMAIL PROTECTED] Sent: Friday, December 06, 2002 4:13 PM Subject: [VOTE] moving Jelly to the commons proper The Jelly code base has been stable for some time and it'd be good to get a stable release of Jelly out so other projects like Maven, Cactus and Latka can depend on a stable, supported release. So I'd like to propose that Jelly be moved to the commons proper where we can start work on getting things in place for an official release. I'm +1 - Cut Here - I vote as follows on moving Jelly to the Commons Proper: [ ] +1 - I support this move and am willing to help [ ] +0 - I support this move, but cannot assist [ ] -0 - I don't support this move [ ] -1 - I vote against this move (requires valid *technical* reasoning) - Cut Here - James --- http://radio.weblogs.com/0112098/ __ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [beanutils] moving reflection classes out of beanutils
from:Jeff Robertson [EMAIL PROTECTED] From: Rodney Waldhoff [mailto:[EMAIL PROTECTED]] Costin If duplication is a concern - then just use Costin beanutils ( however duplication is explicitely Costin allowed in commons AFAIK). Robert i've been convinced that beanutils is Robert not the right place for this code. Rodney And I'm convinced that lang isn't the right place either. Let's split the Rodney difference and propose commons-reflect or commons-reflection or whatever, Rodney and end this thread. Jeff As I think several people have pointed out, isn't that what clazz is Jeff supposed to be? No. [clazz] is high level pluggable introspection. Originally [reflect] was proposed for low-level reflection helpers. However this got changed to [lang] because: - the package would consist of only 4 classes - it would still need to depend on [lang] - [beanutils] would thus have to depend on [reflect] and [lang] People seem to be loathe to include anything as a dependency in commons. [lang] got chosen to reduce the number of dependecies and small projects. This issue is all about dependencies and who does what. Commons could create 20 tiny jars easily, or it could create one [core] jar. Which is the right approach It was the first question I raised on joining, and we're still arguing about it. BTW. I agree that the [lang] charter would need to be reworked to clarify the inclusion of 'reflection'. Stephen -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [Collections] [SUBMIT] Trie
Map isn't appropriate for sure. The point of a trie seems to be that you have a
flexible indexed
key for each entry-- to add all possible keys for each entry would create the overhead
that a trie
avoids.
Think about it this way: what would be the best way to implement
Object get(Object key)
Here's the contract for Map, straight from javadoc:
public interface Map
An object that maps keys to values. A map cannot contain duplicate keys; each key
can map to at
Imost/I one value.
(cheesy italics mine)
I have to say that I am a little disappointed at all the emphasis in Collections
(aimed at no one
in particular) on implementing java.util interfaces at all costs, even if the proposed
structure
isn't a good fit. It leads to performance degradation in some cases, and may actually
prohibit a
good understanding of some data structures. This silliness led to someone (don't
remember who)
telling me that a piece of code I submitted wasn't a collection because it didn't
implement some
interface that the people at Sun happened to come up with.
The java.util package is a good (well, an okay and in some individual cases bad)
starting point,
and that's all-- that goes for both interfaces and implementations.
I agree that we need to focus on the interface and implementation to make sure that
they're the
best we can come up with.
My 2.5c worth.
Jeff
--- [EMAIL PROTECTED] wrote:
Thanks Craig. With two possible Jakarta users, we seem to have a justification for
inclusion.
So, it is now about practical issues. How does the submitted Trie cope for design and
performance. Do we need a String only Trie, a URL Trie, or does the abstracted Trie
submitted
work OK?
The big question is to get the Trie interface correct. In my naive view, it would be
nice if
there was no 'Trie' interface, but instead just a Map implementation and a
TrieUtils. TrieUtils
would then only use the Map interface to determine the suffix/prefix/longest cases.
However, this may not be practical. Can I ask all concerned to think about the
interface, and
whether the current one is suitable for all the needs we can think of.
Stephen
public interface Trie extends Map {
// Gets all the entries that have keys which start with
// a given prefix.
public Set prefixEntrySet(Object keyPrefix);
// Get the entry with the longest key that is a prefix of
// the given value.
public Map.Entry getLongest(Object key);
}
from:Craig R. McClanahan [EMAIL PROTECTED]
FWIW, there are at least two Jakarta products that I'm involved in (Tomcat
and Struts) that have exactly the path-mapping use case that was described
for the Trie class. And, conveniently, they both already dependd on
[collections] so it would be very convenient to have Trie added here.
It will be very interesting to experiment with the relative speed of using
a Trie in these cases versus the current algorithms (which clearly need
some optimizations).
So, an inactive-committer (to collections) 1 from me for including this.
Craig McClanahan
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] moving Jelly to the commons proper
On Friday, December 6, 2002, at 09:13 AM, James Strachan wrote: The Jelly code base has been stable for some time and it'd be good to get a stable release of Jelly out so other projects like Maven, Cactus and Latka can depend on a stable, supported release. So I'd like to propose that Jelly be moved to the commons proper where we can start work on getting things in place for an official release. I'm +1 - Cut Here - I vote as follows on moving Jelly to the Commons Proper: [ ] +1 - I support this move and am willing to help [X] +0 - I support this move, but cannot assist [ ] -0 - I don't support this move [ ] -1 - I vote against this move (requires valid *technical* reasoning) - Cut Here - James --- http://radio.weblogs.com/0112098/ __ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- Geir Magnusson Jr 203-355-2219(w) Adeptra, Inc. 203-247-1713(m) [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] moving Jelly to the commons proper
-bob I vote as follows on moving Jelly to the Commons Proper: [x] +1 - I support this move and am willing to help [ ] +0 - I support this move, but cannot assist [ ] -0 - I don't support this move [ ] -1 - I vote against this move (requires valid *technical* reasoning) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [core] Scope, you choose!
I disagree with a number of things here: 1. The definition of core commons components, or for that matter, the very notion of a core set of commons components defined by anything except for the dependency graph. The collection of components I would consider core are different from yours, and I suspect they are both different from what some third party might consider to be core. (Indeed your core set includes components that only exist in the sandbox, so we don't yet even have formal consensus that they should exist in jakarta-commons.) The concept of defining a core set of components is flawed IMO, nor do I see what the benefit of such a categorization would be. 2. The expression Here are the tasks currently/planned for. Planned by whom? I don't recall any sort of roadmap being proposed for this, nor any vote. This is really your proposal (perhaps agreed to by some others) of what should happen, yes? 3. You write: Why are Functors in [lang] ? Because they are not specifically related/restricted to collections. Because other projects, eg. [io], [clazz] want to use them and don't want to depend on [collections]. but your answer only explains why aren't Functors in [collections]?. similarly, you write: Why is Reflection in [lang] ? Because its not specifically tied to beans. Because other projects, eg. [clazz] want to use reflection and don't want to depend on [beanutils] but your answer only explains why isn't Reflection in [beanutils]?. 4. You write: Where would you draw the scope lines? Do we just follow history? Or try to improve? I think that the approach taken here is working backwards. The right approach (IMO) and the approach endorsed by the commons charter is to articulate a component's scope and then propose it, not to partition the universe of functionality into existing (sometimes sandboxed) components. We shouldn't be draw[ing] scope lines, we should be defining cohesive components. If some components have overlapping scope, that's OK (formally). If we want to refactor the scope of one or more components to reduce this overlap, I think that's generally a Good Thing, but at minimum that represents a product change (and hence requires a formal consensus vote), and should IMO be handled in largely the same way as any component proposal. 5. You write: It all comes down to how big or small you want your jar files. And whether [beanutils] and [collections] are prepared to add [lang] (or _any_ other jar) as a dependency. It doesn't come down to that at all. JAR file size is independent of component partitioning. It comes down to: a) Are these classes likely to be used together (i.e., if I use one will I use the other)? b) Are these classes likely to be changed together (i.e., if I change one, will I change the other)? If the answer to both questions is no, then it is unlikely that the two classes belong in the same commons component. Note that this is what we really mean when we say component x doesn't want to depend on component y--we're saying that component y isn't a cohesive component--I want some if its functionality but not all of it. - Rod Stephen -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [beanutils] moving reflection classes out of beanutils
On Friday, December 6, 2002, at 04:27 PM, Rodney Waldhoff wrote: On Thu, 5 Dec 2002, robert burrell donkin wrote: On Thursday, December 5, 2002, at 08:39 PM, Morgan Delagrange wrote: --- robert burrell donkin [EMAIL PROTECTED] wrote: snip rodney hasn't been a regular contributor to beanutils either in terms of code or on the mailing lists. if he couldn't even be bothered to ask before making himself a committer He's not required to ask, only to indicate his participation. asking is a matter of politeness and means that his participation is less likely to be vetoed. a committer has responsibilities as well as rights. if i thought that a committer was just dumping code into a component and had no intention of maintaining that code, i wouldn't hesitate to veto. I really offended by this comment, Robert. The commit you refer to was not only well within my rights *and* responsibilities, clearly following both the spirit and letter of the asf, jakarta, and jakarta-commons guidelines, but also well within the bounds of politeness and courtesy. This commit was small (one class, about ~300 lines counting comments and blanks), unobtrusive (no new dependencies, configuration, extra processing or memory use was introduced), fully backwards compatible, and well within the scope of the project. The commit then review protocol is clearly appropriate (and polite) in this circumstance. If I need your explicit approval before making a small, unobtrusive, fully backwards compatible and in scope commit, then Guideline #15 (Each committer has karma to all the packages) is meaningless. i'm sorry you feel this way rodney. i'd thought i'd made it clear that these criticisms don't apply to you. i was trying (and failing) to speak in general terms. the guidelines have an inbuilt mechanism whereby components may - if they wish - prevent a new existing commons committer joining. that is, they can veto the addition of the committers name to the list of developers for the component. - robert -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [Collections] [SUBMIT] Trie
Hi Pranas,
It seems [collections] is more about to implement java.util.* interfaces,
[algorithms] subproject was proposed a few moths ago, but I am not expert.
I think we can implement
some interesting algorithms with your help (Genetic algorithms ). It can
be good
place for trie/patricia, hash functions, linier programming, math stuff,
.
I think interface shold be corrected:
...
// Gets all the entries that have keys which start with
// a given prefix.
public Set prefixEntrySet(Object keyPrefix);
// Get the entry with the longest key that is a prefix of
// the given value.
public Map.Entry getLongest(Object key);
...
Comment:
* key may be String - It is intuitive type for the prefix definition
* key must be of type XString for which prefix definition valid like:
public interface XString {
// number of elements in the XString
int getLength();
// get element it can be character converted to the int, bit value 0 1 for
binary trie or Patricia etc.
int getElement(int i);
}
/Pranas
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: 2002 m. gruodþio 6 d. 14:09
To: [EMAIL PROTECTED]
Subject: Re: [Collections] [SUBMIT] Trie
Thanks Craig. With two possible Jakarta users, we seem to have a
justification for inclusion.
So, it is now about practical issues. How does the submitted Trie cope for
design and performance. Do we need a String only Trie, a URL Trie, or does
the abstracted Trie submitted work OK?
The big question is to get the Trie interface correct. In my naive view,
it
would be nice if there was no 'Trie' interface, but instead just a Map
implementation and a TrieUtils. TrieUtils would then only use the Map
interface to determine the suffix/prefix/longest cases.
However, this may not be practical. Can I ask all concerned to think about
the interface, and whether the current one is suitable for all the needs
we
can think of.
Stephen
public interface Trie extends Map {
// Gets all the entries that have keys which start with
// a given prefix.
public Set prefixEntrySet(Object keyPrefix);
// Get the entry with the longest key that is a prefix of
// the given value.
public Map.Entry getLongest(Object key);
}
from:Craig R. McClanahan [EMAIL PROTECTED]
FWIW, there are at least two Jakarta products that I'm involved in
(Tomcat
and Struts) that have exactly the path-mapping use case that was
described
for the Trie class. And, conveniently, they both already dependd on
[collections] so it would be very convenient to have Trie added here.
It will be very interesting to experiment with the relative speed of
using
a Trie in these cases versus the current algorithms (which clearly need
some optimizations).
So, an inactive-committer (to collections) 1 from me for including
this.
Craig McClanahan
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [beanutils] moving reflection classes out of beanutils
On Fri, 6 Dec 2002 [EMAIL PROTECTED] wrote: Originally [reflect] was proposed for low-level reflection helpers. However this got changed to [lang] because: Not proposed, suggested, both in the [reflect] and [lang] case. - the package would consist of only 4 classes What's the threshold number of classes a component needs before it can be accepted as a commons component? - it would still need to depend on [lang] - [beanutils] would thus have to depend on [reflect] and [lang] Why would this be true? beanutils (which is where we moving a number of these classes from) doesn't depend on lang for example. What feature of [lang] is strictly necessary for reflection? Even if this were true, what difference does that make? [dbcp] depends upon [pool], but that doesn't justify making dbcp a part of pool. [digester] depends upon [beanutils], but that doesn't justify making digester a part of beanutils. People seem to be loathe to include anything as a dependency in commons. s/loathe to include/careful about adding This issue is all about dependencies and who does what. Commons could create 20 tiny jars easily, or it could create one [core] jar. Which is the right approach It was the first question I raised on joining, and we're still arguing about it. The charter seems pretty clear to me on this: 2. The package library is not a framework but a collection of components designed to be used independently. 3. Each package must have a clearly defined purpose, scope, and API -- Do one thing well, and keep your contracts. I'm also not sure this is really a mutually exclusive decision. If we want to create a [core] jar, we certainly could do so (e.g., http://cvs.apache.org/viewcvs/jakarta-commons/combo/). By the charter guidelines, it should be possible to distribute a single component in isolation, but that doesn't prohbit creating whatever bundles you'd like to create. - R. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [core] Scope, you choose!
My mail was meant to emphasise the different ideas/companents/packages that have been mentioned over time. In particular they are the ones that are about assisting development with the 'core' of the JDK. I would suggest that if we follow the charter, and all of its theoretically marvellous principles, then we end up with lots and lots of small jars. I further suggest that this leads to either a) duplicated code because components don't want to depend on other components for very small amounts of code or b) a complex web of dependencies, maybe even circular ones There is no simple solution here. I'm trying to point out that each solution has downsides, and to provoke some debate. My position? I agree that the charter's principles sound great and make perfect sense in theory. However, I have grave doubts about them working in practice. eg. if we create a [reflect], and that depends on [lang], then is [beanutils] prepared to add two other jars as dependencies, or will [beanutils] (as I suspect) keep their own independent copy of the code. Stephen from:Rodney Waldhoff [EMAIL PROTECTED] date:Fri, 06 Dec 2002 17:42:07 to: [EMAIL PROTECTED] subject: Re: [core] Scope, you choose! I disagree with a number of things here: 1. The definition of core commons components, or for that matter, the very notion of a core set of commons components defined by anything except for the dependency graph. The collection of components I would consider core are different from yours, and I suspect they are both different from what some third party might consider to be core. (Indeed your core set includes components that only exist in the sandbox, so we don't yet even have formal consensus that they should exist in jakarta-commons.) The concept of defining a core set of components is flawed IMO, nor do I see what the benefit of such a categorization would be. 2. The expression Here are the tasks currently/planned for. Planned by whom? I don't recall any sort of roadmap being proposed for this, nor any vote. This is really your proposal (perhaps agreed to by some others) of what should happen, yes? 3. You write: Why are Functors in [lang] ? Because they are not specifically related/restricted to collections. Because other projects, eg. [io], [clazz] want to use them and don't want to depend on [collections]. but your answer only explains why aren't Functors in [collections]?. similarly, you write: Why is Reflection in [lang] ? Because its not specifically tied to beans. Because other projects, eg. [clazz] want to use reflection and don't want to depend on [beanutils] but your answer only explains why isn't Reflection in [beanutils]?. 4. You write: Where would you draw the scope lines? Do we just follow history? Or try to improve? I think that the approach taken here is working backwards. The right approach (IMO) and the approach endorsed by the commons charter is to articulate a component's scope and then propose it, not to partition the universe of functionality into existing (sometimes sandboxed) components. We shouldn't be draw[ing] scope lines, we should be defining cohesive components. If some components have overlapping scope, that's OK (formally). If we want to refactor the scope of one or more components to reduce this overlap, I think that's generally a Good Thing, but at minimum that represents a product change (and hence requires a formal consensus vote), and should IMO be handled in largely the same way as any component proposal. 5. You write: It all comes down to how big or small you want your jar files. And whether [beanutils] and [collections] are prepared to add [lang] (or _any_ other jar) as a dependency. It doesn't come down to that at all. JAR file size is independent of component partitioning. It comes down to: a) Are these classes likely to be used together (i.e., if I use one will I use the other)? b) Are these classes likely to be changed together (i.e., if I change one, will I change the other)? If the answer to both questions is no, then it is unlikely that the two classes belong in the same commons component. Note that this is what we really mean when we say component x doesn't want to depend on component y--we're saying that component y isn't a cohesive component--I want some if its functionality but not all of it. - Rod Stephen -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [beanutils] moving reflection classes out of beanutils
On Friday, December 6, 2002, at 04:27 PM, Rodney Waldhoff wrote: snip And I'm convinced that lang isn't the right place either. Let's split the difference and propose commons-reflect or commons-reflection or whatever, and end this thread. +1 but i don't have the energy to force this through. it's very frustrating for me. i've been working for some time on creating a solid MethodUtils with a good API and a comprehensive set of unit tests. this version is taking shape in lang. i'd also like to see a new bug fix beanutils release very soon which is why i switched to fixing beanutils bugs. - robert -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [jelly] Subclassing JellyContext
Variables should automatically be available to their child contexts so I
don't think you need to create your own JellyContext for that.
Also the push/pop features can be used by just creating and using child
context - its rather like using a local block in Java. There's also the
j:scope tag which creates a child variable scope, essentially making any
variables set inside the j:scope tag
One question; where will you be using these typesafe getters and setters you
want? Will it be inside a Jelly Tag implementation? If so, you could put
these typesafe methods in an AbstractTag...
public abstract class MyAbstractTag extends TagSupport {
public Number getFoo() {
return (Number) context.getVariable(foo);
}
... etc.
James
---
http://radio.weblogs.com/0112098/
- Original Message -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, December 05, 2002 2:40 PM
Subject: RE: [jelly] Subclassing JellyContext
James, thanks for the pointer re createChildContext().
I am not clear what the scoping refactoring you refer to means exactly, even
after reading the link you sent ;-) But never mind. My scoping
requirements are to be able to have a variable value visible only to its
children. Maybe this is supported already, but I have gone ahead and
written this:
protected void pushVariable(String variableName, Object value) {
if ( context.getVariable(variableName) != null ) {
oldVariableValues.put(variableName,context.getVariable(variableName));
} else {
newVariableNames.add(variableName);
}
log.debug(Setting variable + variableName + to value +
value);
context.setVariable(variableName,value);
}
followed by
protected void popVariables() {
log.debug(Starting to pop variables);
for(Iterator i=newVariableNames.iterator();i.hasNext();) {
final String variableName = (String)i.next();
log.debug(Removing variable named + variableName);
context.removeVariable(variableName);
}
for(Iterator i=oldVariableValues.keySet().iterator();i.hasNext();) {
final String variableName = (String) i.next();
log.debug(Resetting value for variable named + variableName);
context.setVariable(variableName,oldVariableValues.get(variableName));
}
}
And these two methods are on an AbstractTag. I _would_ prefer to have the
methods on a context though.
But the real reason I want to subclass is to allow myself write typesafe and
intuitive variable setters and getters for variables that have meaning to my
application.
So instead of
context.setVariable(VariableNames.APPLICATION_MODE,fast)
I can do
((MyContext)context).setApplicationMode(fast)
and then
String applicationMode = ((MyContext)context).getApplicationMode()
Better than having to remember a bunch of names of variables and what type
they are.
-Original Message-
From: ext James Strachan [mailto:[EMAIL PROTECTED]]
Sent: 05. December 2002 16:22
To: Jakarta Commons Developers List
Subject: Re: [jelly] Subclassing JellyContext
There's a factory method, createChildContext() which you can
override to
create your own context...
public class MyContext extends JellyContext {
public MyContext(JellyContext parent) {
super(parent);
}
protected JellyContext createChildContext() {
return new MyContext(this);
}
}
Note that soon we'll be refactoring the variable scope logic
out of the
JellyContext so that you could just provide your own variable Scope
implementation to change how variables behave. Thats
typically the usual
reason folks need their own JellyContext implementation
There's more details of this here...
http://jira.werken.com/secure/ViewIssue.jspa?key=JELLY-1
James
---
http://radio.weblogs.com/0112098/
- Original Message -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, December 05, 2002 1:13 PM
Subject: [jelly] Subclassing JellyContext
Hi,
Is there any way I can override the creation of JellyContext
instances so I
can put in my own subclass?
Thanks,
Mike.
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
__
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
__
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
Re: [jelly] Stable release?
From: Mark R. Diggory [EMAIL PROTECTED] James Strachan wrote: From: Mark R. Diggory [EMAIL PROTECTED] Hello, I'm curious what is currently the most stable release of Jelly? I checked out the cvs tree and tries to build it, but it seems to break on certain dependencies. It shouldn't do. Are you using Maven to build it? What problems did you find - it should all just work. [javac] /root/CVS_ROOT/jakarta-commons-sandbox/jelly/src/java/org/apache/commons/jel ly/tags/core/NewTag.java:67: cannot resolve symbol [javac] symbol : class ConstructorUtils [javac] location: package beanutils [javac] import org.apache.commons.beanutils.ConstructorUtils; [javac] ^ [javac] /root/CVS_ROOT/jakarta-commons-sandbox/jelly/src/java/org/apache/commons/jel ly/tags/core/NewTag.java:127: cannot resolve symbol [javac] symbol : variable ConstructorUtils [javac] location: class org.apache.commons.jelly.tags.core.NewTag [javac] object = ConstructorUtils.invokeConstructor(theClass,values,types); [javac] ^ [javac] 2 errors BUILD FAILED file:/root/CVS_ROOT/jakarta-commons-sandbox/jelly/build.xml:34: Compile failed; see the compiler error output for details. This looks like you've got an old version of commons-beanutils. Wierd, Maven should have automatically reloaded this for you If you delete the jars in $MAVEN_HOME/repository/commmons-beanutils/jars and do another build it should work fine I think BTW which Maven version is this? I'd like to begin experimenting with Jelly as a Mathematical Simulation tool, not neccessarily as a developer, so I'd like a pretty stable release thats going to not be too buggy. Its pretty stable - its been used in various projects such as Maven for quite some time. Though we do really need to get a release out soon so folks can depend on a formal release. Until now you could depend on a snapshot build from here... http://www.ibiblio.org/maven/commons-jelly/jars/ This is helpfull, but there are a great number of versions (nightly builds?, beta N's, dev branchs) which is the best to use? The latest :-) For my experience working with other jakarta commons projects, its often hard to judge what the best release (formal or informal) to use is. Totally agree and understand. I definitly agree with the release thread going on now. For Jelly to be of use to the common user, there needs to be stable release points they can reley on. If their own work is based on the bleeding edge of the development branch it will create much suffering for them. This is because the HEAD branch cycles between states of stablity/unstability as development progresses. Depending on when they checkout the cvs, they could be grabbing from anywhere in cycle. Agreed. Another question, do you have a current timeline for releasing 1.0? Not right now no. If its any help, I don't expect much in the way of code changes between now and 1.0 and certainly the API should remain pretty consistent - I think its mostly gonna be documentation packaging issues. James --- http://radio.weblogs.com/0112098/ __ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [core] Scope, you choose!
Some good points. I would suggest that if we follow the charter, and all of its theoretically marvellous principles, then we end up with lots and lots of small jars. I further suggest that this leads to either a) duplicated code because components don't want to depend on other components for very small amounts of code or b) a complex web of dependencies, maybe even circular ones Lots of smallish packages is a good thing-- if packages are too large, a redesign is most probably in order. Of course, you can put as many classes into a .jar file as you wish. My vote will always be in favor of a) in a package that should be used by itself, like much of the stuff in Commons. In fact, I think that the rules for implementing utility classes (which includes everything in the Collections project, etc.) should be strongly conducive to creating classes that can be reused singly, with the exception perhaps of an interface or two, or a single abstract superclass. For instance, if a class uses only one string-handling method, the method should be copied to the class and made private. This sort of approach makes code easier to read, reduces chances of things breaking when changes are made in utility classes, allows smaller deployment footprint in most cases, etc. at the slight cost of overall size increase. To say (as has been said) that this approach is not code reuse but simply copying smacks of snobbery and is incorrect. It is a reuse policy that allows version-freeze on small portions of code. Jeff -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [beanutils] moving reflection classes out of beanutils
[EMAIL PROTECTED] wrote: from:Jeff Robertson [EMAIL PROTECTED] From: Rodney Waldhoff [mailto:[EMAIL PROTECTED]] Costin If duplication is a concern - then just use Costin beanutils ( however duplication is explicitely Costin allowed in commons AFAIK). Robert i've been convinced that beanutils is Robert not the right place for this code. Rodney And I'm convinced that lang isn't the right place either. Let's split the Rodney difference and propose commons-reflect or commons-reflection or whatever, Rodney and end this thread. Jeff As I think several people have pointed out, isn't that what clazz is Jeff supposed to be? No. [clazz] is high level pluggable introspection. Please stop this nonsense where it should be. Code will be where people write it - if someone wants to write and maintain reflection code in clazz, do so. Same for lang, beanutils, ant or tomcat. If you don't want to maintain the reflection code in beanutils - don't. You can't block a change or a feature because some other component implements it. The charter allows duplicated features, so I don't consider this a valid veto reason. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] moving Jelly to the commons proper
On Fri, 2002-12-06 at 09:13, James Strachan wrote: The Jelly code base has been stable for some time and it'd be good to get a stable release of Jelly out so other projects like Maven, Cactus and Latka can depend on a stable, supported release. So I'd like to propose that Jelly be moved to the commons proper where we can start work on getting things in place for an official release. I'm +1 - Cut Here - I vote as follows on moving Jelly to the Commons Proper: [x] +1 - I support this move and am willing to help [ ] +0 - I support this move, but cannot assist [ ] -0 - I don't support this move [ ] -1 - I vote against this move (requires valid *technical* reasoning) - Cut Here - James --- http://radio.weblogs.com/0112098/ __ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- jvz. Jason van Zyl [EMAIL PROTECTED] http://tambora.zenplex.org In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [beanutils] moving reflection classes out of beanutils
robert burrell donkin wrote: the guidelines have an inbuilt mechanism whereby components may - if they wish - prevent a new existing commons committer joining. that is, they can veto the addition of the committers name to the list of developers for the component. With a valid technical reason. Probably it can be done in a majority vote - but I certainly hope we'll not reach that point. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [Collections] [SUBMIT] Trie
-Original Message-
From: Jeff Varszegi [mailto:[EMAIL PROTECTED]]
Sent: 6 December 2002 17:15
To: Jakarta Commons Developers List
Subject: Re: [Collections] [SUBMIT] Trie
Map isn't appropriate for sure. The point of a trie seems to
be that you have a flexible indexed key for each entry-- to
add all possible keys for each entry would create the
overhead that a trie avoids.
I'm not sure I agree here. When all is said and done, a flexible index
is only useful to me if I can put(key,object) things into it and
get(key) things out of it. If I've been using a HashMap to hold some
similar and long strings (admittedly best case) then a Trie should be an
effective and efficient drop in replacement. To me, it looks like a map
and acts like a map.
Think about it this way: what would be the best way to implement
Object get(Object key)
Here's the contract for Map, straight from javadoc:
public interface Map
An object that maps keys to values. A map cannot contain duplicate
keys; each key can map to at Imost/I one value.
(cheesy italics mine)
Again, I guess I'm missing your point here... A trie either does or
does not contain leaf node corresponding to a specific key - I don't see
any deviation from the contract. It's true that a prefix can ultimately
be associated with a number of values, but that's the whole point of the
proposed prefixEntrySet(Object) method.
I do think there is room for negotiation about the exact naming and
behaviour of the methods in the interface. Returning a Set of
Map.Entrys seems to be useful, but returning a Trie would be tie closer
with the SortedMap interface. I haven't got a strong opinion here but
it would be nice to hear the pros and cons.
And regarding comments from Pranas - I can't think where /I/ would want
to use a non-string based trie, but I don't see what's gained by
restricting the interface to Strings.
thinking-out-loud
Maybe Gene sequences would be a useful nonstring example... Sure they
can be represented as Strings of A,G,C,Ts but they must be better served
using a 2 bit encoding rather than 16?
/thinking-out-loud
I have to say that I am a little disappointed at all the
emphasis in Collections (aimed at no one in particular) on
implementing java.util interfaces at all costs, even if the
proposed structure isn't a good fit. It leads to performance
degradation in some cases, and may actually prohibit a good
understanding of some data structures. This silliness led to
someone (don't remember who) telling me that a piece of code
I submitted wasn't a collection because it didn't implement
some interface that the people at Sun happened to come up with.
(Was this buffer related?) I agree that Map and Collection are not
necessarily appropriate in every case but it seems silly not to apply
them when they fit the bill. Maybe providing adapters to approptiate
'Collections' in a XxxUtil class would be a better approach in the
future when performance would otherwise be degraded?
The java.util package is a good (well, an okay and in some
individual cases bad) starting point, and that's all-- that
goes for both interfaces and implementations.
I agree that we need to focus on the interface and
implementation to make sure that they're the best we can come up with.
+1 I think this is probably the best aim. However it's pretty difficult
to work out the best interface without using it a bit. Maybe we should
commit the current code with a strong THIS IS ALPHA warning and let
people start to use the code and submit patches to get the abstraction
right? We already have a precedent in the primitives subpackage of code
that is in CVS but isn't considered ready for release so I don't see
that concerns over back compat should be an issue.
Rob
My 2.5c worth.
Jeff
--- [EMAIL PROTECTED] wrote:
Thanks Craig. With two possible Jakarta users, we seem to have a
justification for inclusion.
So, it is now about practical issues. How does the
submitted Trie cope
for design and performance. Do we need a String only Trie,
a URL Trie,
or does the abstracted Trie submitted work OK?
The big question is to get the Trie interface correct. In my naive
view, it would be nice if there was no 'Trie' interface,
but instead
just a Map implementation and a TrieUtils. TrieUtils would
then only
use the Map interface to determine the suffix/prefix/longest cases.
However, this may not be practical. Can I ask all concerned
to think
about the interface, and whether the current one is
suitable for all
the needs we can think of.
Stephen
public interface Trie extends Map {
// Gets all the entries that have keys which start with
// a given prefix.
public Set prefixEntrySet(Object keyPrefix);
// Get the entry with the longest key that is a prefix of
// the given value.
public Map.Entry getLongest(Object key);
}
from:Craig R.
Re: [beanutils] moving reflection classes out of beanutils
--- robert burrell donkin [EMAIL PROTECTED] wrote: snip/ the guidelines have an inbuilt mechanism whereby components may - if they wish - prevent a new existing commons committer joining. that is, they can veto the addition of the committers name to the list of developers for the component. - robert Are you sure about that? I don't see that anywhere: http://jakarta.apache.org/commons/charter.html AFAIK there are no restrictions on existing committers working on other existing components. If you're implying that committers can exercise their veto on the actual commit of a new developer's name to the STATUS file, that's not so. Commits can only be vetoed for valid technical reasons. I can't imagine the technical justification for you can't work on my component. Adding your name to the STATUS file is a courtesy. Nobody should be ostracized for not doing it: Version 1.8: http://cvs.apache.org/viewcvs/jakarta-commons/beanutils/STATUS.html#rev1.8 Version 1.6: http://cvs.apache.org/viewcvs/jakarta-commons/beanutils/src/java/org/apache/commons/beanutils/MethodUtils.java#rev1.6 - Morgan = Morgan Delagrange http://jakarta.apache.org/taglibs http://jakarta.apache.org/commons http://axion.tigris.org http://jakarta.apache.org/watchdog __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [Collections] [SUBMIT] Trie
To me, it looks like a map and acts like a map. You could squeeze it into a SortedMap, although that is also not something I would do. The structure is not used for sorting, is it? It's used for fast data retrieval. And returning a Set of Map.Entry objects would be just horrible, even if a trie should implement Map. The forcing of Map.Entry implementation on every implementor of the Map interface is one of the biggest mistakes in java.util, IMHO. Here you have a supposedly generic interface that presumes that every possible implementation will wrap entries in unnecessary extra objects of a particular type. I was looking at one util library on the web (think it was Trove) where the programmer jumped through hoops to implement the Map.Entry stuff just to maintain compatibility. This was an admirable mistake-- the point of his implementation was to increase performance with a purely array-based map, but he had to construct Map.Entry objects on the fly for callers of certain methods. Of course, someone dropping his class into code making extensive use of Map.Entry wouldn't see much performance improvement, if any... You're just thinking of a trie as a faster way than hashing to do map-style key lookups, aren't you? You are probably not thinking of ever looking up something by prefix. Well, I bet that just array-index checking and other overhead in Java will make it slower than hashing for direct key lookup on anything but small amounts of data. Hashing is pretty fast. Also, add/remove overhead on a medium-to-big trie is bound to be heavier than that for a medium-to-big hashtable. It will be interesting to see how the numbers play out, and when it's appropriate to use a map or a trie. I'll bet that tries pick up a lot under the server VM. Always willing to have a conversation, and your comments are thoughtful, especially re: gene sequences etc. Here's my deal: I want a Trie implementation dealing specifically with Strings (even better-- char arrays), because that's how I'll use it. It will also be nice to have one dealing with object sequences. It might also be nice to have one dealing with byte arrays. It might also be nice to have one dealing with bit sequences. If the first two can be squeezed (nicely) into one interface, great. It's not going to be fun to cast Object return values to String all the time for a structure I will probably only use with strings. I think that the performance of a Trie implementation might be greatly increased by limiting the tail sort of recursion (if we make all tree-walking methods one deep). Jeff --- Rob Oxspring [EMAIL PROTECTED] wrote: -Original Message- From: Jeff Varszegi [mailto:[EMAIL PROTECTED]] Sent: 6 December 2002 17:15 To: Jakarta Commons Developers List Subject: Re: [Collections] [SUBMIT] Trie Map isn't appropriate for sure. The point of a trie seems to be that you have a flexible indexed key for each entry-- to add all possible keys for each entry would create the overhead that a trie avoids. I'm not sure I agree here. When all is said and done, a flexible index is only useful to me if I can put(key,object) things into it and get(key) things out of it. If I've been using a HashMap to hold some similar and long strings (admittedly best case) then a Trie should be an effective and efficient drop in replacement. To me, it looks like a map and acts like a map. Think about it this way: what would be the best way to implement Object get(Object key) Here's the contract for Map, straight from javadoc: public interface Map An object that maps keys to values. A map cannot contain duplicate keys; each key can map to at Imost/I one value. (cheesy italics mine) Again, I guess I'm missing your point here... A trie either does or does not contain leaf node corresponding to a specific key - I don't see any deviation from the contract. It's true that a prefix can ultimately be associated with a number of values, but that's the whole point of the proposed prefixEntrySet(Object) method. I do think there is room for negotiation about the exact naming and behaviour of the methods in the interface. Returning a Set of Map.Entrys seems to be useful, but returning a Trie would be tie closer with the SortedMap interface. I haven't got a strong opinion here but it would be nice to hear the pros and cons. And regarding comments from Pranas - I can't think where /I/ would want to use a non-string based trie, but I don't see what's gained by restricting the interface to Strings. thinking-out-loud Maybe Gene sequences would be a useful nonstring example... Sure they can be represented as Strings of A,G,C,Ts but they must be better served using a 2 bit encoding rather than 16? /thinking-out-loud -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [collections] private member access in o.a.c.collections.iterators
I've prepared a patch for ArrayIterator, and the ArrayListIterator
class is ready to go, with associated test cases. However, there is
another issue with ArrayIterator. The ArrayIterator(Object array, int
start, int end) constructor has the following test:
if(end = start) {
throw new IllegalArgumentException(
My understanding is that this should really be changed to:
if(end start) {
The current behaviour prohibits the creation of an iterator over a
zero-length section of array, even though this is a valid thing to do.
Unless there are objections, I will also include this change in the
patch. This will also require changes to TestArrayList, so I guess I
can create a patch for this as well.
Any comments?
- Neil
--- Stephen Colebourne [EMAIL PROTECTED] wrote:
Perhaps you would like to send a patch for ArrayIterator.
http://jakarta.apache.org/site/source.html#Patches
Also, an ArrayListIterator would be very welcome for the iterators
package.
If you are writing it, perhaps you would consider submitting it
together
with the associated patch to IteratorUtils?
Thanks
Stephen
- Original Message -
From: Neil O'Toole [EMAIL PROTECTED]
I've been using the o.a.c.collections packages for a few months,
and I
want to applaud you guys for some fantastic work.
I do have a question: forgive me if this has been discussed before
(though I couldn't find it in the mail archive), but is there a
particular reason why the member variables in the
o.a.c.collections.iterators classes are private instead of being
protected? In general, why would you want to do this, as it
prevents
subclassing? A particular case: I wanted to created an
ArrayListIterator that subclasses ArrayIterator and implements the
ListIterator interface. With protected member access it is a simple
and
elegant implementation to subclass ArrayIterator.
Thoughts on the matter?
- Neil O'Toole
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [Collections] [SUBMIT] Trie
I do think there is room for negotiation about the exact naming and
behaviour of the methods in the interface. Returning a Set of
Map.Entrys seems to be useful, but returning a Trie would be tie closer
with the SortedMap interface. I haven't got a strong opinion here but
it would be nice to hear the pros and cons.
This is simple to implement and I cannot think of any
disadvantages. It sounds like a good idea to me.
And regarding comments from Pranas - I can't think where /I/ would want
to use a non-string based trie, but I don't see what's gained by
restricting the interface to Strings.
thinking-out-loud
Maybe Gene sequences would be a useful nonstring example... Sure they
can be represented as Strings of A,G,C,Ts but they must be better served
using a 2 bit encoding rather than 16?
/thinking-out-loud
Any information which is indexed by a sequence would be
appropriate. Strings, genes and numbers are examples where the
sequence is made up of a finite alphabet. Other examples which are a
sequence with an infinite alphabet are URIs and file names.
I agree that we need to focus on the interface and
implementation to make sure that they're the best we can come up with.
+1 I think this is probably the best aim. However it's pretty difficult
to work out the best interface without using it a bit. Maybe we should
commit the current code with a strong THIS IS ALPHA warning and let
people start to use the code and submit patches to get the abstraction
right? We already have a precedent in the primitives subpackage of code
that is in CVS but isn't considered ready for release so I don't see
that concerns over back compat should be an issue.
Ok, I'll jump in and level a few criticisms at the interface and
implementation I submitted. :-)
--- Trie - is it the right name? ---
I must admit, the more I've looked at this, the more uncomfortable I
am with the name. In my reading, I've only ever heard 'trie' applied
to a data structure indexed by strings. However, a trie does seem to
fit into a more general class of data structures. It looks like these
structures are called prefix trees--although I can't find a solid
definition. However, it may be a very elementary data structure:
http://proteacher.net/archive/posts/2001/09/26/21017.html
So conceptually, we have this sort of breakdown:
Prefix trees
- Prefix trees for handling strings
- Trie
- The data structure used in suffix trees
- Prefix trees for handling binary data
- Patricia trees
- Prefix trees for handling sequences of anything
- AbstractObjectArrayTrie (which should be renamed)
--- Separating the interface from the implementation ---
Perhaps the interface doesn't need to be named after the
implementation at all. There may be other data structures which
provide efficient operations on the prefix of keys, but aren't
implemented as a prefix tree.
--- Suggestion ---
Here's a rough suggestion.
/**
* A Map which provides several operations based on the
* prefix of keys.
*/
public interface PrefixMap extends Map {
public PrefixMap subPrefixMap(Object keyPrefix);
public Map.Entry getLongest(Object candidateKey);
}
There is a nice symmetry in providing a SortedPrefixMap, although
actual implementation would involve a reasonable amount of work. (But
I'll do it if there is consensus about it.)
public interface SortedPrefixMap extends PrefixMap, SortedMap {
// This would return a SortedPrefixMap. I can't override the
// return type, can I?
public PrefixMap subPrefixMap(Object keyPrefix);
}
/**
* An implementation of PrefixMap. Subclasses must provide an
* implementation for translating keys to and from object arrays
* and a mechanism for storing outgoing references.
*/
public abstract class AbstractObjectArrayPrefixTree
implements PrefixMap {
...
}
public abstract class AbstractObjectArraySortedPrefixTree
extends AbstractObjectArrayPrefixTree
implements SortedPrefixMap {
// extra SortedMap methods
// requires subclasses to return items in order with
// outgoingTransitionIterator().
...
}
/**
* Stores outgoing references in a Map, subclasses must
* still provide an implementation for translating keys to
* and from object arrays.
*/
public abstract class AbstractOutgoingTransitionPrefixMap
extends AbstractObjectArrayPrefixTree {
...
}
public abstract class AbstractOutgoingTransitionSortedPrefixMap
extends AbstractObjectArraySortedPrefixTree {
// needs to be passed in comparator
...
}
/**
* A SortedPrefixMap for strings.
*/
public class Trie implements SortedPrefixMap
extends AbstractObjectArraySortedPrefixTree {
// Future implementations may not extend this
// class. They may be more efficient, and based
// on native chars or ints.
...
}
Any comments on this? Particularly:
- The hierarchy of abstract classes. Should it be flattened? At the
moment I'm separating out
Re: [jelly] Stable release?
It doesn't appear that the beanutils is gotten by maven, its gotten in the ant build.xml script in the jelly directory. [root@osprey jelly]# ant Buildfile: build.xml init: get-deps: [get] Getting: http://www.ibiblio.org/maven/ant/jars/ant-1.5.jar [get] Getting: http://www.ibiblio.org/maven/ant/jars/ant-optional-1.5.jar [get] Getting: http://www.ibiblio.org/maven/commons-beanutils/jars/commons-beanutils-1.4-dev.jar [get] Getting: http://www.ibiblio.org/maven/commons-collections/jars/commons-collections-2.1.jar ... http://www.ibiblio.org/maven/xmlunit/jars/xmlunit-0.8.jar [get] Getting: http://www.ibiblio.org/maven/junit/jars/junit-3.8.1.jar [get] Getting: http://www.ibiblio.org/maven/ant/jars/ant-1.5.jar [get] Not modified - so not downloaded [get] Getting: http://www.ibiblio.org/maven/ant/jars/ant-optional-1.5.jar [get] Not modified - so not downloaded compile: [javac] Compiling 341 source files to /root/CVS_ROOT/jakarta-commons-sandbox/jelly/target/classes [javac] /root/CVS_ROOT/jakarta-commons-sandbox/jelly/src/java/org/apache/commons/jelly/tags/core/NewTag.java:67: cannot resolve symbol [javac] symbol : class ConstructorUtils [javac] location: package beanutils [javac] import org.apache.commons.beanutils.ConstructorUtils; [javac] ^ [javac] /root/CVS_ROOT/jakarta-commons-sandbox/jelly/src/java/org/apache/commons/jelly/tags/core/NewTag.java:127: cannot resolve symbol [javac] symbol : variable ConstructorUtils [javac] location: class org.apache.commons.jelly.tags.core.NewTag [javac] object = ConstructorUtils.invokeConstructor(theClass,values,types); [javac] ^ [javac] 2 errors BUILD FAILED file:/root/CVS_ROOT/jakarta-commons-sandbox/jelly/build.xml:34: Compile failed; see the compiler error output for details. Total time: 52 seconds [root@osprey jelly]# James Strachan wrote: From: Mark R. Diggory [EMAIL PROTECTED] James Strachan wrote: From: Mark R. Diggory [EMAIL PROTECTED] Hello, I'm curious what is currently the most stable release of Jelly? I checked out the cvs tree and tries to build it, but it seems to break on certain dependencies. It shouldn't do. Are you using Maven to build it? What problems did you find - it should all just work. [javac] /root/CVS_ROOT/jakarta-commons-sandbox/jelly/src/java/org/apache/commons/jel ly/tags/core/NewTag.java:67: cannot resolve symbol [javac] symbol : class ConstructorUtils [javac] location: package beanutils [javac] import org.apache.commons.beanutils.ConstructorUtils; [javac] ^ [javac] /root/CVS_ROOT/jakarta-commons-sandbox/jelly/src/java/org/apache/commons/jel ly/tags/core/NewTag.java:127: cannot resolve symbol [javac] symbol : variable ConstructorUtils [javac] location: class org.apache.commons.jelly.tags.core.NewTag [javac] object = ConstructorUtils.invokeConstructor(theClass,values,types); [javac] ^ [javac] 2 errors BUILD FAILED file:/root/CVS_ROOT/jakarta-commons-sandbox/jelly/build.xml:34: Compile failed; see the compiler error output for details. This looks like you've got an old version of commons-beanutils. Wierd, Maven should have automatically reloaded this for you If you delete the jars in $MAVEN_HOME/repository/commmons-beanutils/jars and do another build it should work fine I think BTW which Maven version is this? I'd like to begin experimenting with Jelly as a Mathematical Simulation tool, not neccessarily as a developer, so I'd like a pretty stable release thats going to not be too buggy. Its pretty stable - its been used in various projects such as Maven for quite some time. Though we do really need to get a release out soon so folks can depend on a formal release. Until now you could depend on a snapshot build from here... http://www.ibiblio.org/maven/commons-jelly/jars/ This is helpfull, but there are a great number of versions (nightly builds?, beta N's, dev branchs) which is the best to use? The latest :-) For my experience working with other jakarta commons projects, its often hard to judge what the best release (formal or informal) to use is. Totally agree and understand. I definitly agree with the release thread going on now. For Jelly to be of use to the common user, there needs to be stable release points they can reley on. If their own work is based on the bleeding edge of the development branch it will create much suffering for them. This is because the HEAD branch cycles between states of stablity/unstability as development progresses. Depending on when they checkout the cvs, they could be grabbing from anywhere in cycle. Agreed. Another question, do you have a current timeline for releasing 1.0? Not right now no. If its any help, I don't expect much in the way
RE: [Collections] [SUBMIT] Trie
To me, it looks like a map and acts like a map. You could squeeze it into a SortedMap, although that is also not something I would do. The structure is not used for sorting, is it? It's used for fast data retrieval. And returning a Set of Map.Entry objects would be just horrible, even if a trie should implement Map. The forcing of Map.Entry implementation on every implementor of the Map interface is one of the biggest mistakes in java.util, IMHO. Here you have a supposedly generic interface that presumes that every possible implementation will wrap entries in unnecessary extra objects of a particular type. I was looking at one util library on the web (think it was Trove) where the programmer jumped through hoops to implement the Map.Entry stuff just to maintain compatibility. This was an admirable mistake-- the point of his implementation was to increase performance with a purely array-based map, but he had to construct Map.Entry objects on the fly for callers of certain methods. Of course, someone dropping his class into code making extensive use of Map.Entry wouldn't see much performance improvement, if any... Well that's true... Do you suggest avoiding the Map interface entirely? I agree that some parts of the Map interface can be difficult to write if they don't mesh nicely with the underlying data structure. But, to me, that doesn't diminish the value of implementing the interface. The interface defines a common set of operations, but it doesn't make solid guarantees about performance characteristics. Users should choose an implementation that is efficient for the way they intend to use it. And that is something which [collections] could help with! You're just thinking of a trie as a faster way than hashing to do map-style key lookups, aren't you? You are probably not thinking of ever looking up something by prefix. Well, I bet that just array-index checking and other overhead in Java will make it slower than hashing for direct key lookup on anything but small amounts of data. Hashing is pretty fast. Also, add/remove overhead on a medium-to-big trie is bound to be heavier than that for a medium-to-big hashtable. It will be interesting to see how the numbers play out, and when it's appropriate to use a map or a trie. I'll bet that tries pick up a lot under the server VM. No, I'm using a trie (or should I say prefix tree) specifically for its prefix operations. Depending on the implementation and the data being stored, it can also have benefits of space efficiency. A prefix tree also supports reasonably efficient get(), put() and remove() operations. Certainly it is better than a linear search, almost certainly worse than a hash based map. For the prefix operations, I expect it would outstrip a hash based map. Maybe we could write a MapPrefixMapAdapter and see? Always willing to have a conversation, and your comments are thoughtful, especially re: gene sequences etc. Here's my deal: I want a Trie implementation dealing specifically with Strings (even better-- char arrays), because that's how I'll use it. It will also be nice to have one dealing with object sequences. It might also be nice to have one dealing with byte arrays. It might also be nice to have one dealing with bit sequences. Hmm, that's a lot of work to get a +1. :-) If the first two can be squeezed (nicely) into one interface, great. It's not going to be fun to cast Object return values to String all the time for a structure I will probably only use with strings. Mind you, I'm sure you don't avoid HashMaps because of the cast overhead--they're still very useful. That is perhaps a reason why not to include a trie (as opposed to a more general prefix tree) in [collections], but I'm not really sure. I think that the performance of a Trie implementation might be greatly increased by limiting the tail sort of recursion (if we make all tree-walking methods one deep). Good point Jeff. I will look into doing this. Rich -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [jelly] Stable release?
Ohhh, I got it, I was trying to run ant and not maven. I thought maven was getting started by ant. The build.xml script in the jelly directory seems to have problems. If ant is no longer used to build Jelly, wouldn't it be good to get rid of the build.xml file? thanks for tolerating my absent mindedness, Mark Mark R. Diggory wrote: It doesn't appear that the beanutils is gotten by maven, its gotten in the ant build.xml script in the jelly directory. [root@osprey jelly]# ant Buildfile: build.xml init: get-deps: [get] Getting: http://www.ibiblio.org/maven/ant/jars/ant-1.5.jar [get] Getting: http://www.ibiblio.org/maven/ant/jars/ant-optional-1.5.jar [get] Getting: http://www.ibiblio.org/maven/commons-beanutils/jars/commons-beanutils-1.4-dev.jar [get] Getting: http://www.ibiblio.org/maven/commons-collections/jars/commons-collections-2.1.jar ... http://www.ibiblio.org/maven/xmlunit/jars/xmlunit-0.8.jar [get] Getting: http://www.ibiblio.org/maven/junit/jars/junit-3.8.1.jar [get] Getting: http://www.ibiblio.org/maven/ant/jars/ant-1.5.jar [get] Not modified - so not downloaded [get] Getting: http://www.ibiblio.org/maven/ant/jars/ant-optional-1.5.jar [get] Not modified - so not downloaded compile: [javac] Compiling 341 source files to /root/CVS_ROOT/jakarta-commons-sandbox/jelly/target/classes [javac] /root/CVS_ROOT/jakarta-commons-sandbox/jelly/src/java/org/apache/commons/jelly/tags/core/NewTag.java:67: cannot resolve symbol [javac] symbol : class ConstructorUtils [javac] location: package beanutils [javac] import org.apache.commons.beanutils.ConstructorUtils; [javac] ^ [javac] /root/CVS_ROOT/jakarta-commons-sandbox/jelly/src/java/org/apache/commons/jelly/tags/core/NewTag.java:127: cannot resolve symbol [javac] symbol : variable ConstructorUtils [javac] location: class org.apache.commons.jelly.tags.core.NewTag [javac] object = ConstructorUtils.invokeConstructor(theClass,values,types); [javac] ^ [javac] 2 errors BUILD FAILED file:/root/CVS_ROOT/jakarta-commons-sandbox/jelly/build.xml:34: Compile failed; see the compiler error output for details. Total time: 52 seconds [root@osprey jelly]# James Strachan wrote: From: Mark R. Diggory [EMAIL PROTECTED] James Strachan wrote: From: Mark R. Diggory [EMAIL PROTECTED] Hello, I'm curious what is currently the most stable release of Jelly? I checked out the cvs tree and tries to build it, but it seems to break on certain dependencies. It shouldn't do. Are you using Maven to build it? What problems did you find - it should all just work. [javac] /root/CVS_ROOT/jakarta-commons-sandbox/jelly/src/java/org/apache/commons/jel ly/tags/core/NewTag.java:67: cannot resolve symbol [javac] symbol : class ConstructorUtils [javac] location: package beanutils [javac] import org.apache.commons.beanutils.ConstructorUtils; [javac] ^ [javac] /root/CVS_ROOT/jakarta-commons-sandbox/jelly/src/java/org/apache/commons/jel ly/tags/core/NewTag.java:127: cannot resolve symbol [javac] symbol : variable ConstructorUtils [javac] location: class org.apache.commons.jelly.tags.core.NewTag [javac] object = ConstructorUtils.invokeConstructor(theClass,values,types); [javac] ^ [javac] 2 errors BUILD FAILED file:/root/CVS_ROOT/jakarta-commons-sandbox/jelly/build.xml:34: Compile failed; see the compiler error output for details. This looks like you've got an old version of commons-beanutils. Wierd, Maven should have automatically reloaded this for you If you delete the jars in $MAVEN_HOME/repository/commmons-beanutils/jars and do another build it should work fine I think BTW which Maven version is this? I'd like to begin experimenting with Jelly as a Mathematical Simulation tool, not neccessarily as a developer, so I'd like a pretty stable release thats going to not be too buggy. Its pretty stable - its been used in various projects such as Maven for quite some time. Though we do really need to get a release out soon so folks can depend on a formal release. Until now you could depend on a snapshot build from here... http://www.ibiblio.org/maven/commons-jelly/jars/ This is helpfull, but there are a great number of versions (nightly builds?, beta N's, dev branchs) which is the best to use? The latest :-) For my experience working with other jakarta commons projects, its often hard to judge what the best release (formal or informal) to use is. Totally agree and understand. I definitly agree with the release thread going on now. For Jelly to be of use to the common user, there needs to be stable release points they can reley on. If their own work is based on the bleeding edge of the development branch it will create much suffering
[jelly] Running Jelly from the command line
What I'm hoping to find, and this is kinda parallel to the discussion about releasing Jelly, is that I can use Jelly as a light wieght scripting env. One that doesn't require Ant or Maven to run (but I could add them if I want). So, I'm curious , both ant and maven have command line startup via shell scripts/bat files for unix and wundows at least. Does Jelly have anything like this in mind? (I'm sure I could whip something up for myself, but if it was already there It'd be better). -Mark -- _ Mark Diggory Project Manager/Software Developer Harvard-MIT Data Center 617-496-7246 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15154] New: - SystemUtils.IS_JAVA_1_5 Javadoc is wrong
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15154. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15154 SystemUtils.IS_JAVA_1_5 Javadoc is wrong Summary: SystemUtils.IS_JAVA_1_5 Javadoc is wrong Product: Commons Version: 1.0.1 Final Platform: All URL: http://jakarta.apache.org/commons/lang/api/org/apache/co mmons/lang/SystemUtils.html#IS_JAVA_1_5 OS/Version: All Status: NEW Severity: Normal Priority: Other Component: Lang AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] http://jakarta.apache.org/commons/lang/api/org/apache/commons/lang/SystemUtils.h tml#IS_JAVA_1_5 Should talk about 1.5 not 1.3. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
test
Is anybody using this mail list? The last posts I could retrieve were from one year ago :) -- Yuri M [EMAIL PROTECTED] -- http://fastmail.fm - The professional email service -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: test
Well, yes, this list is pretty frequently used. I've received over 50 messages today alone. There's an archive at: http://archives.apache.org/eyebrowse/SummarizeList?[EMAIL PROTECTED] How are you trying to retrieve the messages? On Fri, 6 Dec 2002, Yuri M wrote: Is anybody using this mail list? The last posts I could retrieve were from one year ago :) -- Yuri M [EMAIL PROTECTED] -- http://fastmail.fm - The professional email service -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [collections] private member access in o.a.c.collections.iterators
Go for it ;-)
Stephen
- Original Message -
From: Neil O'Toole [EMAIL PROTECTED]
To: Jakarta Commons Developers List [EMAIL PROTECTED]
Sent: Friday, December 06, 2002 9:51 PM
Subject: Re: [collections] private member access in
o.a.c.collections.iterators
I've prepared a patch for ArrayIterator, and the ArrayListIterator
class is ready to go, with associated test cases. However, there is
another issue with ArrayIterator. The ArrayIterator(Object array, int
start, int end) constructor has the following test:
if(end = start) {
throw new IllegalArgumentException(
My understanding is that this should really be changed to:
if(end start) {
The current behaviour prohibits the creation of an iterator over a
zero-length section of array, even though this is a valid thing to do.
Unless there are objections, I will also include this change in the
patch. This will also require changes to TestArrayList, so I guess I
can create a patch for this as well.
Any comments?
- Neil
--- Stephen Colebourne [EMAIL PROTECTED] wrote:
Perhaps you would like to send a patch for ArrayIterator.
http://jakarta.apache.org/site/source.html#Patches
Also, an ArrayListIterator would be very welcome for the iterators
package.
If you are writing it, perhaps you would consider submitting it
together
with the associated patch to IteratorUtils?
Thanks
Stephen
- Original Message -
From: Neil O'Toole [EMAIL PROTECTED]
I've been using the o.a.c.collections packages for a few months,
and I
want to applaud you guys for some fantastic work.
I do have a question: forgive me if this has been discussed before
(though I couldn't find it in the mail archive), but is there a
particular reason why the member variables in the
o.a.c.collections.iterators classes are private instead of being
protected? In general, why would you want to do this, as it
prevents
subclassing? A particular case: I wanted to created an
ArrayListIterator that subclasses ArrayIterator and implements the
ListIterator interface. With protected member access it is a simple
and
elegant implementation to subclass ArrayIterator.
Thoughts on the matter?
- Neil O'Toole
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [core] Scope, you choose!
Jeff said: To say (as has been said) that this approach is not code reuse but simply copying smacks of snobbery and is incorrect. It is a reuse policy that allows version-freeze on small portions of code. Copied code is copied code. It means dual maintainance and incompatabilities. What I have consistently failed to understand about this debate is how commons can ask other jakarta projects to refactor out their common code when commons is unwilling to do the same job within its own borders. Stephen -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: test
Thanks, I was experimenting with the [EMAIL PROTECTED] command of the mailing list and the highest index it gave was 614 from October last year :) On Fri, 6 Dec 2002 16:35:38 -0800 (PST), Rodney Waldhoff [EMAIL PROTECTED] said: Well, yes, this list is pretty frequently used. I've received over 50 messages today alone. There's an archive at: http://archives.apache.org/eyebrowse/SummarizeList?[EMAIL PROTECTED] How are you trying to retrieve the messages? On Fri, 6 Dec 2002, Yuri M wrote: Is anybody using this mail list? The last posts I could retrieve were from one year ago :) -- Yuri M [EMAIL PROTECTED] -- http://fastmail.fm - The professional email service -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- Yuri M [EMAIL PROTECTED] -- http://fastmail.fm - A fast, anti-spam email service. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [Collections] [SUBMIT] Trie
-Original Message- From: Jeff Varszegi [mailto:[EMAIL PROTECTED]] Sent: 6 December 2002 21:22 To: Jakarta Commons Developers List Subject: RE: [Collections] [SUBMIT] Trie To me, it looks like a map and acts like a map. You could squeeze it into a SortedMap, although that is also not something I would do. The structure is not used for sorting, is it? It's used for fast data retrieval. I agree - the observation that I was making is that in some applications the Trie stucture is going to be more space efficient and still pretty fast. It seems silly, to me, to disallow this drop-in usage. Although if the performance hit is significant then dropping the interface may be sensible. And returning a Set of Map.Entry objects would be just horrible, even if a trie should implement Map. The forcing of Map.Entry implementation on every implementor of the Map interface is one of the biggest mistakes in java.util, IMHO. Here you have a supposedly generic interface that presumes that every possible implementation will wrap entries in unnecessary extra objects of a particular type. +1 - I've always found the pair of lists approach much easier to deal with than the list of pairs that Map seems to enforce. I was looking at one util library on the web (think it was Trove) where the programmer jumped through hoops to implement the Map.Entry stuff just to maintain compatibility. This was an admirable mistake-- the point of his implementation was to increase performance with a purely array-based map, but he had to construct Map.Entry objects on the fly for callers of certain methods. Of course, someone dropping his class into code making extensive use of Map.Entry wouldn't see much performance improvement, if any... But once it comes to tuning performance the choice of implementation should be based heavily on the usage. If the client code uses the Map.Entry facilities then the developer should choose an implementation that provides them well. It just happens that Tries are aimed towards data retrieval and space saving, if it doesn't suit then there is always the option of finding/writing your own Map implementation with a different bias. You're just thinking of a trie as a faster way than hashing to do map-style key lookups, aren't you? You are probably not thinking of ever looking up something by prefix. Admittedly the example above was using it this way but that doesn't really feature in my plans. I certainly plan on using the prefixEntrySet() to get the list of possible matches... And will be comparing it against the likes of sortedMap.subMap(key,key+'\0') before deciding which I use. Well, I bet that just array-index checking and other overhead in Java will make it slower than hashing for direct key lookup on anything but small amounts of data. Hashing is pretty fast. Also, add/remove overhead on a medium-to-big trie is bound to be heavier than that for a medium-to-big hashtable. It will be interesting to see how the numbers play out, and when it's appropriate to use a map or a trie. I'll bet that tries pick up a lot under the server VM. Always willing to have a conversation, and your comments are thoughtful, especially re: gene sequences etc. Here's my deal: I want a Trie implementation dealing specifically with Strings (even better-- char arrays), because that's how I'll use it. It will also be nice to have one dealing with object sequences. +1 Strings / char arrays would be priority 1 but I still think there is little gained by specifying this at the interface level. It might also be nice to have one dealing with byte arrays. It might also be nice to have one dealing with bit sequences. If the first two can be squeezed (nicely) into one interface, great. It's not going to be fun to cast Object return values to String all the time for a structure I will probably only use with strings. You're value objects would be Strings too? I plan on using Strings as keys which plays nicely with the current interface, but the values being looked up would be much richer objects. Forcing a String return type seems far too restrictive IMHO. I think that the performance of a Trie implementation might be greatly increased by limiting the tail sort of recursion (if we make all tree-walking methods one deep). On this I can't comment - I haven't investigated the implementation details yet. Partly the reason for suggesting we play with a few implementations before committing to a final definition. Rob Jeff --- Rob Oxspring [EMAIL PROTECTED] wrote: -Original Message- From: Jeff Varszegi [mailto:[EMAIL PROTECTED]] Sent: 6 December 2002 17:15 To: Jakarta Commons Developers List Subject: Re: [Collections] [SUBMIT] Trie Map isn't appropriate for sure. The point of a trie seems to be that you have a flexible indexed key for each entry-- to
RE: [Collections] [SUBMIT] Trie
-Original Message-
From: Rich Dougherty [mailto:[EMAIL PROTECTED]]
-8---
Ok, I'll jump in and level a few criticisms at the interface
and implementation I submitted. :-)
--- Trie - is it the right name? ---
I must admit, the more I've looked at this, the more
uncomfortable I am with the name. In my reading, I've only
ever heard 'trie' applied to a data structure indexed by
strings. However, a trie does seem to fit into a more general
class of data structures. It looks like these structures are
called prefix trees--although I can't find a solid
definition. However, it may be a very elementary data structure:
http://proteacher.net/archive/posts/2001/09/26/21017.html
So conceptually, we have this sort of breakdown:
Prefix trees
- Prefix trees for handling strings
- Trie
- The data structure used in suffix trees
- Prefix trees for handling binary data
- Patricia trees
- Prefix trees for handling sequences of anything
- AbstractObjectArrayTrie (which should be renamed)
--- Separating the interface from the implementation ---
Perhaps the interface doesn't need to be named after the
implementation at all. There may be other data structures
which provide efficient operations on the prefix of keys, but
aren't implemented as a prefix tree.
--- Suggestion ---
Here's a rough suggestion.
/**
* A Map which provides several operations based on the
* prefix of keys.
*/
public interface PrefixMap extends Map {
public PrefixMap subPrefixMap(Object keyPrefix);
public Map.Entry getLongest(Object candidateKey);
}
There is a nice symmetry in providing a SortedPrefixMap,
although actual implementation would involve a reasonable
amount of work. (But I'll do it if there is consensus about it.)
public interface SortedPrefixMap extends PrefixMap, SortedMap {
// This would return a SortedPrefixMap. I can't override the
// return type, can I?
public PrefixMap subPrefixMap(Object keyPrefix);
}
/**
* An implementation of PrefixMap. Subclasses must provide an
* implementation for translating keys to and from object arrays
* and a mechanism for storing outgoing references.
*/
public abstract class AbstractObjectArrayPrefixTree
implements PrefixMap {
...
}
public abstract class AbstractObjectArraySortedPrefixTree
extends AbstractObjectArrayPrefixTree
implements SortedPrefixMap {
// extra SortedMap methods
// requires subclasses to return items in order with
// outgoingTransitionIterator().
...
}
/**
* Stores outgoing references in a Map, subclasses must
* still provide an implementation for translating keys to
* and from object arrays.
*/
public abstract class AbstractOutgoingTransitionPrefixMap
extends AbstractObjectArrayPrefixTree {
...
}
public abstract class AbstractOutgoingTransitionSortedPrefixMap
extends AbstractObjectArraySortedPrefixTree {
// needs to be passed in comparator
...
}
/**
* A SortedPrefixMap for strings.
*/
public class Trie implements SortedPrefixMap
extends AbstractObjectArraySortedPrefixTree {
// Future implementations may not extend this
// class. They may be more efficient, and based
// on native chars or ints.
...
}
Any comments on this? Particularly:
- The hierarchy of abstract classes. Should it be flattened? At the
moment I'm separating out storage of the transitions. This is nice,
but perhaps it clutters the package too much?
- Stephen has mentioned some sort of TrieUtils? Perhaps this should be
called PrefixMapUtils, or go into MapUtils.
Rich
Firstly, I think the name PrefixMap is probably clearer than Trie and
should probably be adopted. My second thought is that the hierachy
seems pretty deep - more so than other collections implementations I can
think of.
I'm not sure how much benefit there is to making Sorted guarentees, code
such as the following would probably suit my needs equally well: (and I
prefer the flexibility of changing the comparator at the point of use)
List values = new ArrayList(trie.prefixTrie(prefix).values())
Collections.sort(values, myComparator)
I'm not sure I understand the benefits of separating out the transition
storage but hopefully I'll have time to play and understand better in
the morning.
Rob
--
To unsubscribe, e-mail:
mailto:commons-dev- [EMAIL PROTECTED]
For
additional commands,
e-mail: mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [beanutils] moving reflection classes out of beanutils
On Fri, 6 Dec 2002, Costin Manolache wrote: Date: Fri, 06 Dec 2002 07:41:08 -0800 From: Costin Manolache [EMAIL PROTECTED] Reply-To: Jakarta Commons Developers List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: [beanutils] moving reflection classes out of beanutils robert burrell donkin wrote: what we have is clear duplication. twice the support and twice the maintenance. Nobody asks you to support 2 versions. There is nothing wrong with duplication ( at least in commons ). You can just maintain and support the version you like. You're recommending deprecation of a released, public-facing API; Rodney is not. the (beanutils) MethodUtils API sucks. it was written in haste and now in leisure, i regret that it was written in that way. It doesn't quite matter. There are people using it ( digester, other projects), it was released - we have to live with it. We may learn a lesson about APIs and use it next time, but as long as it does what it is supposed to do and works - you can't remove it. This start to look like dependency spaghetti to me, and it does create problems. I believe that adding a dependency on [lang] or [reflect] would itself be grounds for a 2.x version number for [beanutils], even with no other changes (although there would undoubtedly be some). my position has always been that i'm not willing to maintain, support or develop two versions of the basic reflection classes. i've also been convinced that beanutils is not the right places for these canonical versions. Good. Then maintain and support the other version. in terms of beanutils, i'm not willing to support a release with code in that no one is willing to support. therefore, i'd think about vetoing any contribution if i thought that no one was willing to offer support for that code and maintain it. but you're willing to do that for ConstructorUtils (and MethodUtils if it can't be deprecated), aren't you rodney? ), it's reasonably clean. If Rodney doesn't want to support it - I can and I suppose other people will. Beanutils is used in tomcat, and if a bug happens we'll have to fix it anyway, and I think we can handle that. It's clear that ConstructorUtils and MethodUtils belong together, wherever they end up. But it seems less clear that a move would mean *deleting* MethodUtils from [beanutils]. It's straightforward to leave the existing APIs available (for backwards compatibility), but as wrappers around calls to the new functionality, probably deprecated but at least kept through a 2.x version lifecycle. That way, the actual functionality is still in one place for easy maintenance/enhancement, we can fix the method names in the new versions, and users of MethodUtils can migrate in a controlled manner, at their own leisure. Costin Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] moving Jelly to the commons proper
On Fri, 6 Dec 2002, James Strachan wrote: - Cut Here - I vote as follows on moving Jelly to the Commons Proper: [X] +1 - I support this move and am willing to help I will add this to the set of commons packages I build nightly, and to the commons-combo package (that builds a combined JAR/Javadocs for all the released jakarta-commons libraries). Although, I'm beginning to wonder if subproject/project status might be better. Jelly core looks like it's becoming a framework with lots of optional packages (and their associated dependencies) on top of it, very reminiscent of Ant ... In the mean time, a real release from Commons is appropriate. [ ] +0 - I support this move, but cannot assist [ ] -0 - I don't support this move [ ] -1 - I vote against this move (requires valid *technical* reasoning) - Cut Here - James Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [digester] collections and default for useThreadClassLoader
On Fri, 6 Dec 2002, Costin Manolache wrote: Date: Fri, 06 Dec 2002 07:45:52 -0800 From: Costin Manolache [EMAIL PROTECTED] Reply-To: Jakarta Commons Developers List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: [digester] collections and default for useThreadClassLoader In addition to the threadClassLoader: +1 on changing this default, by the way ... forgot to say that yesterday. is there any reason for digester to depend on collections ? I see that it is using FastHashmap and ArrayStack, but given that it is _parsing_ a file and does a lot of super-expensive operations, the performance gains from this use are not significant. I'd be OK with removing this dependency, especially if it could be shown that the performance difference is insignificant (on which you're probably right). The reason I'm looking into this - I have a lot of problems with tomcat in JMX mode, some jars need to get into the parent loader and that brakes a lot of stuff. Modeler depends on digester so I need it in the top loader - but this drags the whole jakarta-commons. Same for beanutils ( which is used quite extensively in digester, and may be needed in modeler as well ). In [beanutils] it looks like the only use of [collections] is for FastHashMap, which is used to cache things that can still be read with no synchronization locks. I suspect the performance impacts here would be more substantial and relevant than the [digester] direct dependencies; it probably needs more performance analysis before a decision. Costin Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [core] Scope, you choose!
On Fri, 6 Dec 2002 [EMAIL PROTECTED] wrote: Date: Fri, 6 Dec 2002 18:05:53 + (GMT) From: [EMAIL PROTECTED] Reply-To: Jakarta Commons Developers List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: [core] Scope, you choose! My mail was meant to emphasise the different ideas/companents/packages that have been mentioned over time. In particular they are the ones that are about assisting development with the 'core' of the JDK. I would suggest that if we follow the charter, and all of its theoretically marvellous principles, then we end up with lots and lots of small jars. Lots of JARs isn't necessarily bad, if your development environment makes it easy to dynamically build classpaths (like Ant does). However, there are often going to be cases where you'd really like a bunch o commons JARs all together, to make life easier. The political challenge is, who gets to define what is included in the bunch? I tried to punt on this issue with the combo project, which includes a specified released version of *all* the packages in jakarta-commons (but not the sandbox). Currently, this thing actually builds (except for Latka, but that's most likely an issue on my development platform), ending up with a JAR file of just over one megabyte. As a side benefit, it generates consolidated Javadocs for the packages that are included. The theory is that most people will want a JAR that contains the latest released version of all the JARs, so that is how the build is set up. Presumably, any time a Commons package was released, the CVS tag to pull for that package would also be updated in the combo build.xml file. However, because each of the tags is itself an Ant property, it is very easy to use this to grab exactly the combination of versions you want. It also would be straightforward to set up mechanisms where you can subset this -- right now you'd just have to comment out the things you don't want. Rather than getting into emotional discussions of core versus non-core, how about if we start with combo that includes *all* the non-sandbox packages, and work from there? Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] moving Jelly to the commons proper
On Fri, 6 Dec 2002, James Strachan wrote: - Cut Here - I vote as follows on moving Jelly to the Commons Proper: [X] +1 - I support this move and am willing to help [ ] +0 - I support this move, but cannot assist [ ] -0 - I don't support this move [ ] -1 - I vote against this move (requires valid *technical* reasoning) - Cut Here - -- Martin Cooper -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [jelly] Running Jelly from the command line
Just to stop others from replying to this email, I did locate the build:dist section of the maven.xml script and also located the commandline bat/shell scripts in the bin directory of the distribution. Thanks for the help. -Mark Mark R. Diggory wrote: What I'm hoping to find, and this is kinda parallel to the discussion about releasing Jelly, is that I can use Jelly as a light wieght scripting env. One that doesn't require Ant or Maven to run (but I could add them if I want). So, I'm curious , both ant and maven have command line startup via shell scripts/bat files for unix and wundows at least. Does Jelly have anything like this in mind? (I'm sure I could whip something up for myself, but if it was already there It'd be better). -Mark -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [core] Scope, you choose!
I think there are 2 separate issues. Having one big jar with all the commons code - or one big jar with all jakarta code - is a good idea. So is having a distribution with 20 small jars. It's a matter of taste, so having both is the best solution. The issue I'm concerned with is the spaghetti that goes between the packages, and the ability to pick one component without having to use all jakarta. And as a practical problem - modeler won't work without digester which doesn't work without collections, beanutils. And digester doesn't work well in the top loader - and who knows what else has the same problems. As you know, there are good reasons to be able to keep the root loader clean. It may be just another matter of taste - but at this moment bloat ( include everything, just in case ) wins. I think those are _very_ distinct problems, and we shouldn't mix them. I fully support one big jakarta-commons.jar, as well as a distribution that includes all the software in jakarta. Costin Craig R. McClanahan wrote: On Fri, 6 Dec 2002 [EMAIL PROTECTED] wrote: Date: Fri, 6 Dec 2002 18:05:53 + (GMT) From: [EMAIL PROTECTED] Reply-To: Jakarta Commons Developers List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: [core] Scope, you choose! My mail was meant to emphasise the different ideas/companents/packages that have been mentioned over time. In particular they are the ones that are about assisting development with the 'core' of the JDK. I would suggest that if we follow the charter, and all of its theoretically marvellous principles, then we end up with lots and lots of small jars. Lots of JARs isn't necessarily bad, if your development environment makes it easy to dynamically build classpaths (like Ant does). However, there are often going to be cases where you'd really like a bunch o commons JARs all together, to make life easier. The political challenge is, who gets to define what is included in the bunch? I tried to punt on this issue with the combo project, which includes a specified released version of *all* the packages in jakarta-commons (but not the sandbox). Currently, this thing actually builds (except for Latka, but that's most likely an issue on my development platform), ending up with a JAR file of just over one megabyte. As a side benefit, it generates consolidated Javadocs for the packages that are included. The theory is that most people will want a JAR that contains the latest released version of all the JARs, so that is how the build is set up. Presumably, any time a Commons package was released, the CVS tag to pull for that package would also be updated in the combo build.xml file. However, because each of the tags is itself an Ant property, it is very easy to use this to grab exactly the combination of versions you want. It also would be straightforward to set up mechanisms where you can subset this -- right now you'd just have to comment out the things you don't want. Rather than getting into emotional discussions of core versus non-core, how about if we start with combo that includes *all* the non-sandbox packages, and work from there? Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [core] Scope, you choose!
Stephen Colebourne wrote: Jeff said: To say (as has been said) that this approach is not code reuse but simply copying smacks of snobbery and is incorrect. It is a reuse policy that allows version-freeze on small portions of code. Copied code is copied code. It means dual maintainance and incompatabilities. There is no dual maintainance. Everyone maintains the code that he cares about and uses. What I have consistently failed to understand about this debate is how commons can ask other jakarta projects to refactor out their common code when commons is unwilling to do the same job within its own borders. Commons is not asking other projects to refactor common code just for the sake of moving code around and creating dependencies. If someone feels a piece of code would benefit from having more hands and more diverse opinions - and is willing to take the risks of more diverse opinions - then commons may be a good idea. It is not in commons charter to create a one-size-fits-all introspection library. What I fail to understand is what is the real issue of debate - if you want to create a library for reflection, do it. That doesn't mean you have to force everyone to use it or to stop people from working on other reflection libraries or to say that the other reflection code should move to your component. If a piece of code works well, is stable, fast, clean and does what it is needed - it will be used, and people will stop working on other implementations. If some other implementation does something different and people need that - then probably both will exist for a while. We must mind our own itches. That's the real issue that people don't seem to understand. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [digester] collections and default for useThreadClassLoader
Craig R. McClanahan wrote: In addition to the threadClassLoader: +1 on changing this default, by the way ... forgot to say that yesterday. Thanks. That was the major issue. Same for beanutils ( which is used quite extensively in digester, and may be needed in modeler as well ). In [beanutils] it looks like the only use of [collections] is for FastHashMap, which is used to cache things that can still be read with no synchronization locks. I suspect the performance impacts here would be more substantial and relevant than the [digester] direct dependencies; it probably needs more performance analysis before a decision. What worries me more is the dependency on the Comparator in a public API. That would make it impossible to remove beanutils-collection without one backward incompatibility ( at least at source level - at runtime it won't have any effect ). Regarding FastHashMap - most my tests on JDK1.4 show absolutely no difference. The cost for a lock that is allways unlocked is extremely small. On the other side - if beanutils is in the top loader and gets accessed concurently by many apps - we may find some strange errors if some of the locks are actually needed. I can add some code to check if FastHashMap is available and fallback. I need to look a bit more at the code in beanutils. There is also the issue of statics ( which become very visible when you move stuff to the top loader), and the issue of security - which is particularily important for beanutil and probably in collections ( i.e. - if things are cached - can an application access other application's data ? Is there any thread that may change the security context ? ) And of course - Class.forName and things like that would create yet another set of problems ( is all the code using the thread loader ? ). Pluse the difficulties to override some classes, possible linkage errors on reverse loaders, etc. ( well, I know you know all this :-) Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [beanutils] moving reflection classes out of beanutils
Craig R. McClanahan wrote: It doesn't quite matter. There are people using it ( digester, other projects), it was released - we have to live with it. We may learn a lesson about APIs and use it next time, but as long as it does what it is supposed to do and works - you can't remove it. I believe that adding a dependency on [lang] or [reflect] would itself be grounds for a 2.x version number for [beanutils], even with no other changes (although there would undoubtedly be some). I don't know. this kind of stuff. If the [reflect] package will have the same features and better API - then it may be better to mark beanutils as stable/closed and migrate modeler, digester, etc directly to [reflect]. I don't see why would we need a 2.x version. I don't think we need more than a component for this kind of stuff - or at least I would use a single component ( even beanutils ) over some reflection that is split in more components. Matter of taste, of course - but also complexity, dependencies, spaghetti. ( well, you can do all the introspection witha single class - both ant and tomcat3 are basically doing that ). It's clear that ConstructorUtils and MethodUtils belong together, wherever they end up. But it seems less clear that a move would mean *deleting* MethodUtils from [beanutils]. It's straightforward to leave the existing APIs available (for backwards compatibility), but as wrappers around calls to the new functionality, probably deprecated but at least kept through a 2.x version lifecycle. That way, the actual functionality is still in one place for easy maintenance/enhancement, we can fix the method names in the new versions, and users of MethodUtils can migrate in a controlled manner, at their own leisure. My point is that it would be better if the new package would focus on doing what it has to do - API, implementation, features. When it's ready - we can decide if it makes sense to deprecate ( freeze ) beanutils entirely, implement it as a wrapper for backward compat - or keep it if it fits a different niche. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] moving Jelly to the commons proper
I vote as follows on moving Jelly to the Commons Proper: [X] +1 - I support this move and am willing to help [ ] +0 - I support this move, but cannot assist [ ] -0 - I don't support this move [ ] -1 - I vote against this move (requires valid *technical* reasoning) -- dIon Gillard, Multitask Consulting Blog: http://www.freeroller.net/page/dion/Weblog Work: http://www.multitask.com.au -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
