RE: [Collections] [SUBMIT] Trie
Charles, You are 100% right. It depends on application. For such applications as billing in telecomunications it is enough to use object-based storage of elements (with some optimizations like converting UNICODE String to the BDC string). For text retrieving DBMS indexes primitive data structures as byte[] preferable. Like extremely fast expression-matching functionality (Application in biology or Evolutionary algorithms) At lease some kind of Trie implementation in Collections would be of great importance /Pranas -Original Message- From: Charles Burdick [mailto:[EMAIL PROTECTED]] Sent: 2002 m. gruod?io 6 d. 17:26 To: Jakarta Commons Developers List Subject: Re: [Collections] [SUBMIT] Trie As a frequent user of Commons-Collections, I can support the usefulness of a Trie implementation in Collections. Most algorithms textbooks use Trie as an advanced data structure for fast string retrieval. It is discussed in Knuth's Art of Computer Programming. http://www.amazon.com/exec/obidos/tg/detail/-/0201485419/ref=lib_rd_ss_TI73/ 102-3297886-4987356?v=glances=booksvi=readerimg=86coliid=I3GKWA6SDKHVJ5# reader-link I'm not convinced that Tries can be optimally stored as objects. Perhaps we will want a Trie interface that supports primitive char access as well as a TrieMap interface that is object-based and extends Collection. Thanks, Chuck --- Stephen Colebourne [EMAIL PROTECTED] wrote: Hi, I've taken a quick look at the code here, and that all looks fine. Unfortunately, I don't really know what I'm looking at! What I mean is that I've never heard of a 'Trie' before, and am thus wondering as to why I would use it, and is it general enough to be in [collections]. In the past we have had discussions about Tree implementations (and I have coded some before). This may be related, as the Trie appears to be a recursive structure. Perhaps, some use cases as to why a Trie is useful, especially in a general/server environment would be useful. Thanks. Stephen - Original Message - From: Rich Dougherty [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, December 02, 2002 7:36 AM Subject: [Collections] [SUBMIT] Trie Hi I've written an implementation for a trie which I'd like to contribute. I've attached a simple implementation and a test case. Here's the interface: __ 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] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [Collections] [SUBMIT] Trie
I should explain usage of Trie (specially case binary Patricia): Storage requirement - Minimal (good balance between storage and performance) Functionality - Exact match (it is usual case), Prefix Match, Some kind of flexible expressions may be used as key For a long strings even Exact match is much more efficient comparing to hashing algorithms! /Pranas P.S. Expression matching may be new topic... Useful, but extremely hard implementation. I am novice in this list. Maybe such functionality it is not part of [Collections] -Original Message- From: Rob Oxspring [mailto:[EMAIL PROTECTED]] Sent: 2002 m. gruod?io 6 d. 20:50 To: 'Jakarta Commons Developers List'; [EMAIL PROTECTED] Subject: 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
[beanutils] statics [WAS Re: [digester] collections and default for useThreadClassLoader]
On Saturday, December 7, 2002, at 06:50 AM, Costin Manolache wrote: snip 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 ? ) (now is probably a good time to raise something that's been in the air for a little while.) at the moment, beanutils is composed of static methods. the caching is also static. one effect of this is that there is only one global set of converters. another is that the cached data has to be shared globally. it might make more sense to have concrete objects. caches and other data would be stored with each instance. the current static methods would then call a static instance. users would then be free to continue to use the convenient static methods or they could create an instance and use that instead. - robert -- 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 02:13 PM, 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 - - robert -- 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 06:51 PM, Costin Manolache wrote: [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. there is a very strong argument for sharing basic reflection code. that's why people are interested in finding the best place for it. the sun reflection code (pre java 1.4 at least) is very buggy. components that rely on reflection need to have a reliable set of utilities with workarounds for these bugs. these need to be well tested and reliable since more complex introspection/introspection alternative system are going to be built on top. sharing these components means that a bug can be fixed in one place rather than five or six. bugs and workarounds found will benefit all components which use reflection. it means that users can be directed to a single canonical version. the effort which would have gone into maintaining duplicate versions can be used to create comprehensive unit tests so that we don't get so many bugs to fix. duplication means supporting different versions each with their own particular bugs. users will have to shop around for a version that has the fixes in that they need. - robert -- 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 06:53 PM, Costin Manolache wrote: 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. +1 - robert -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [beanutils] moving reflection classes out of beanutils
On Saturday, December 7, 2002, at 06:59 AM, Costin Manolache wrote: 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. the plan was to separate out just the reflection utilities leaving beanutils focused exclusively on introspection. digester (for example) would still need to use beanutils for introspection but may want to migrate to the improved reflection utilities. the critical flaw with the old MethodUtils API is that the method contracts are not written in a way that makes it clear what are bugs and what aren't. fixing this will mean changing the method symantics. the reflection methods will work better but differently. i'd say that's a good reason for making it version 2.0. components using beanutils expect that MethodUtils should work to the java language specification. users who use MethodUtils directly rely on the method descriptions. they can quite reasonable rely on a feature of the current code which deviates from the correct behaviour (as far as the other components are concerned). the flaw also makes it impossible to create comprehensive test cases. - robert -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[GUMP] Build Failure - commons-jelly
This email is autogenerated from the output from:
http://cvs.apache.org/builds/gump/2002-12-07/commons-jelly.html
Buildfile: build.xml
init:
[mkdir] Created dir: /home/rubys/jakarta/jakarta-commons-sandbox/jelly/lib
get-deps:
compile:
[mkdir] Created dir:
/home/rubys/jakarta/jakarta-commons-sandbox/jelly/target/classes
[javac] Compiling 341 source files to
/home/rubys/jakarta/jakarta-commons-sandbox/jelly/target/classes
[javac]
/home/rubys/jakarta/jakarta-commons-sandbox/jelly/src/java/org/apache/commons/jelly/tags/http/HttpTagSupport.java:68:
cannot resolve symbol
[javac] symbol : class HttpMultiClient
[javac] location: package httpclient
[javac] import org.apache.commons.httpclient.HttpMultiClient;
[javac] ^
[javac]
/home/rubys/jakarta/jakarta-commons-sandbox/jelly/src/java/org/apache/commons/jelly/tags/http/SessionTag.java:64:
cannot resolve symbol
[javac] symbol : class HttpMultiClient
[javac] location: package httpclient
[javac] import org.apache.commons.httpclient.HttpMultiClient;
[javac] ^
[javac]
/home/rubys/jakarta/jakarta-commons-sandbox/jelly/src/java/org/apache/commons/jelly/tags/http/SessionTag.java:89:
cannot resolve symbol
[javac] symbol : class HttpMultiClient
[javac] location: class org.apache.commons.jelly.tags.http.SessionTag
[javac] private HttpMultiClient _httpClient;
[javac] ^
[javac]
/home/rubys/jakarta/jakarta-commons-sandbox/jelly/src/java/org/apache/commons/jelly/tags/http/SessionTag.java:118:
cannot resolve symbol
[javac] symbol : class HttpMultiClient
[javac] location: class org.apache.commons.jelly.tags.http.SessionTag
[javac] public HttpMultiClient getHttpClient() {
[javac]^
[javac]
/home/rubys/jakarta/jakarta-commons-sandbox/jelly/src/java/org/apache/commons/jelly/tags/http/SessionTag.java:127:
cannot resolve symbol
[javac] symbol : class HttpMultiClient
[javac] location: class org.apache.commons.jelly.tags.http.SessionTag
[javac] public void setHttpClient(HttpMultiClient httpClient) {
[javac] ^
[javac]
/home/rubys/jakarta/jakarta-commons-sandbox/jelly/src/java/org/apache/commons/jelly/tags/http/HttpTagSupport.java:234:
cannot resolve symbol
[javac] symbol : class HttpMultiClient
[javac] location: class org.apache.commons.jelly.tags.http.HttpTagSupport
[javac] private HttpMultiClient getHttpClient() {
[javac] ^
[javac]
/home/rubys/jakarta/jakarta-commons-sandbox/jelly/src/java/org/apache/commons/jelly/tags/http/HttpTagSupport.java:236:
cannot resolve symbol
[javac] symbol : class HttpMultiClient
[javac] location: class org.apache.commons.jelly.tags.http.HttpTagSupport
[javac] HttpMultiClient client = null;
[javac] ^
[javac]
/home/rubys/jakarta/jakarta-commons-sandbox/jelly/src/java/org/apache/commons/jelly/tags/http/HttpTagSupport.java:241:
cannot resolve symbol
[javac] symbol : class HttpMultiClient
[javac] location: class org.apache.commons.jelly.tags.http.HttpTagSupport
[javac] client = new HttpMultiClient();
[javac] ^
[javac]
/home/rubys/jakarta/jakarta-commons-sandbox/jelly/src/java/org/apache/commons/jelly/tags/http/SessionTag.java:105:
cannot resolve symbol
[javac] symbol : class HttpMultiClient
[javac] location: class org.apache.commons.jelly.tags.http.SessionTag
[javac] _httpClient = new HttpMultiClient(getProxyHost(),
getProxyPort());
[javac] ^
[javac]
/home/rubys/jakarta/jakarta-commons-sandbox/jelly/src/java/org/apache/commons/jelly/tags/http/SessionTag.java:107:
cannot resolve symbol
[javac] symbol : class HttpMultiClient
[javac] location: class org.apache.commons.jelly.tags.http.SessionTag
[javac] _httpClient = new HttpMultiClient();
[javac] ^
[javac]
/home/rubys/jakarta/jakarta-commons-sandbox/jelly/src/java/org/apache/commons/jelly/tags/http/MethodSupportTag.java:185:
org.apache.commons.httpclient.HttpConnectionManager is abstract; cannot be
instantiated
[javac] connectionManager = new HttpConnectionManager();
[javac] ^
[javac]
/home/rubys/jakarta/jakarta-commons-sandbox/jelly/src/java/org/apache/commons/jelly/tags/http/MethodSupportTag.java:232:
cannot resolve symbol
[javac] symbol : method getConnection (java.lang.String)
[javac] location: interface org.apache.commons.httpclient.HttpConnectionManager
[javac] return getConnectionManager().getConnection( getUrl() );
[javac]
[GUMP] Build Failure - commons-email
This email is autogenerated from the output from: http://cvs.apache.org/builds/gump/2002-12-07/commons-email.html Buildfile: build-gump.xml jar: [mkdir] Created dir: /home/rubys/jakarta/jakarta-commons-sandbox/email/target/classes [javac] Compiling 7 source files to /home/rubys/jakarta/jakarta-commons-sandbox/email/target/classes [javac] /home/rubys/jakarta/jakarta-commons-sandbox/email/src/java/org/apache/commons/mail/HtmlEmail.java:66: cannot resolve symbol [javac] symbol : class GenerateUniqueId [javac] location: package util [javac] import org.apache.commons.util.GenerateUniqueId; [javac]^ [javac] /home/rubys/jakarta/jakarta-commons-sandbox/email/src/java/org/apache/commons/mail/HtmlEmail.java:208: cannot resolve symbol [javac] symbol : class GenerateUniqueId [javac] location: package util [javac] String cid = org.apache.commons.util.GenerateUniqueId.getIdentifier(); [javac] ^ [javac] 2 errors BUILD FAILED file:///home/rubys/jakarta/jakarta-commons-sandbox/email/build-gump.xml:22: Compile failed; see the compiler error output for details. Total time: 2 seconds -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15160] New: - speedup for beanutils / array getter
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=15160. 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=15160 speedup for beanutils / array getter Summary: speedup for beanutils / array getter Product: Commons Version: 1.5 Final Platform: All OS/Version: All Status: NEW Severity: Enhancement Priority: Other Component: Bean Utilities AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] At many places within the jakarta code I discovered unnecessary usage of the java collections, which *slows down things significantly*. The appended patch is a patch for BeanUtils.getArrayProperty, but it should be considered to be a generic example how to speed up things. The FastXXX approach is a good start, but *real* arrays are *WAY* faster, since the mechanisms used here are implemented native. :o) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15160] - speedup for beanutils / array getter
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=15160. 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=15160 speedup for beanutils / array getter --- Additional Comments From [EMAIL PROTECTED] 2002-12-07 17:10 --- Created an attachment (id=4075) speedup patch for BeanUtils::getArrayProperty -- 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: 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. Nothing illegal with 2 versions anyway. If there are duplicate versions, with no difference in religion between those versions, I would question the rightness. Especially if it came from the same 'group' of developers. [Not that I'm stating that Commons is a group of developers in any way] 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. So work stops on beanutils and BeanUtilsTNG is created? Why can't it be removed? I agree that such a removal should imply a large version number change, ie) BeanUtils 2.0, but what states that Commons libraries have to follow slow-release deprecation methods? This start to look like dependency spaghetti to me, and it does create problems. Yep. Reality is we are going to have N libraries with M dependencies, where N and M will only get bigger at a rate slightly faster than we can manage it. Do we need to have a common plan in Commons? Or do we do our best to ensure there are no dependencies between projects, ie) each one is stand-alone and has some kind of copying system for internal function calls [ie) we copy the jar, change the bytecode to a different package name, an obfuscated one]. 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. While this kind of view is an important one to have in the community [as detailed in a long thread on jakarta-general or apache-community] in that it helps to deal with potential forking and potential project-death, it does seem that the philosophy should be to work together until such a point as working together is not possible, and then to allow the community-healing mores to come into play. Hen -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [beanutils] moving reflection classes out of beanutils
On Saturday, December 7, 2002, at 08:57 PM, Henri Yandell wrote: On Fri, 6 Dec 2002 [EMAIL PROTECTED] wrote: ... BTW. I agree that the [lang] charter would need to be reworked to clarify the inclusion of 'reflection'. This proposal is to create a package of Java utility classes for the classes that are in java.lang's hierarchy, or are considered to be so standard as to justify existence in java.lang. java.lang.reflect :) The proposal, nice and umbrella-like as it is, refers to anything that provides Utils for the java.lang.reflect classes. yep. the reflection classes are definitely in-scope. i think that people would be less worried about lang expanding into a grand, uber-utility framework if the second part of the charter could be tightened up a little. or are considered to be so standard as to justify existence in java.lang. can be interpreted fairly broadly. AFAIK no one's objected to the scope of the released version. of the newer packages, reflect is clearly in-scope but there is some debate about whether it's the best place for those classes. whether functor is in scope is debatable. no one objected at the time but it would be possible to create a reasoned argument that they are 'standard' but not 'so standard' as to justify inclusion. (not that i'm advocating moving them out. i just think we need to think about these things.) - robert -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [beanutils] moving reflection classes out of beanutils
On Sat, 7 Dec 2002, robert burrell donkin wrote: On Saturday, December 7, 2002, at 08:57 PM, Henri Yandell wrote: java.lang.reflect :) The proposal, nice and umbrella-like as it is, refers to anything that provides Utils for the java.lang.reflect classes. yep. the reflection classes are definitely in-scope. i think that people would be less worried about lang expanding into a grand, uber-utility framework if the second part of the charter could be tightened up a little. or are considered to be so standard as to justify existence in java.lang. can be interpreted fairly broadly. I'm +1 to remove this. It's aimed to be a loophole, but now I've got a bit more of an understanding of the ASF Way, I see that the way is to define things tightly then argue through the barriers, rather than leave little backdoor legalisms. I'll suggest this in another thread to be removed. AFAIK no one's objected to the scope of the released version. of the newer packages, reflect is clearly in-scope but there is some debate about whether it's the best place for those classes. whether functor is in scope is debatable. no one objected at the time but it would be possible to create a reasoned argument that they are 'standard' but not 'so standard' as to justify inclusion. Functor has always been a big debate. That they are highly useful is not somethign I can argue with [having just spent some time on vacation making the IO FileFilter implement Predicate]. They are also not [Patterns], a name that was I think my misfortune to suggest without a real understanding. It's also blatantly obvious that they are misplaced in Collections. Probably the bigger question is how to get them out of collections and not why they're currently in the cvs tree under lang :) Hen -- 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: Craig R. McClanahan wrote: 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. Because reflection and beans are different things. Many things will want to do reflection, but won't have any interest in some form of bean API. The same holds for BeanUtils' Convertor system. Many things will want to use this, but have no interest in Beans. Having to deal with a library which is created with a context of JavaBeans means that the Convertor and Reflection APIs will be tainted by this context. 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. Yep. And ConstructorUtils/MethodUtils are outside the scope of BeanUtils in my view, even if the PROPOSAL does provide some mention of reflection/introspection utilities. 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. Agreed. It's always better to debate a piece of code when it's sitting and ready for inclusion in a particular library somewhere, especially with something like reflection where it's pretty independent of the surrounding library. So... we let Robert/Stephen/others finish up with reflect in lang while copying across modifications that occur to those areas in beanutils... then we have big argument then? :) Hen -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-commons/lang/src/test/org/apache/commons/lang StringUtilsTest.java
bayard 2002/12/07 13:50:30
Modified:lang STATUS.html
lang/src/java/org/apache/commons/lang StringUtils.java
lang/src/test/org/apache/commons/lang StringUtilsTest.java
Log:
Added the StringUtils.unescape method, UnitTest and STATUS change.
Revision ChangesPath
1.28 +3 -2 jakarta-commons/lang/STATUS.html
Index: STATUS.html
===
RCS file: /home/cvs/jakarta-commons/lang/STATUS.html,v
retrieving revision 1.27
retrieving revision 1.28
diff -u -r1.27 -r1.28
--- STATUS.html 15 Nov 2002 00:07:26 - 1.27
+++ STATUS.html 7 Dec 2002 21:50:29 - 1.28
@@ -72,6 +72,7 @@
ul
liCharRange.UNSET - will have problems if we introduce reverse ranges that go
down to \u./lI
liNull effects - the classes are not standardised in how they handle null./li
+liWhen running the TestFactoryUtils test, sometimes the CPU speed is not quick
enough and 'assertEquals((double) System.currentTimeMillis(), (double) ((Date)
created).getTime(), 0.01d);' fails. /li
/ul
/p
@@ -90,7 +91,7 @@
liDateRange/li
liCloneUtils - utility class to enable cloning via various different mechanisms.
This code exists in [pattern] at present./li
liStringUtils truncateNicely method - A substring with some extra power to choose
where to cut off. It was in Avalon and was added separately to String Taglib from a
code submission. This suggests it may have some commonality. [CODED]/li
-liStringUtils unescape method - String Taglib has shown that this method is
missing from StringUtils. It would take a String with \n in and convert it to the
Java character. unescape and escape should be symmetric. /li
+liStringUtils unescape method - String Taglib has shown that this method is
missing from StringUtils. It would take a String with \n in and convert it to the
Java character. unescape and escape should be symmetric - [DONE. Test symmetry] /li
liArrayUtils - opinion seems to be that this belongs with [lang] and not
[collections]
liGUID and other Identifier generators - these may belong in [util], some code
exists in [pattern] at the moment
liCharUtils - Utilities to work on a char[] in the same way as a String
1.28 +74 -2
jakarta-commons/lang/src/java/org/apache/commons/lang/StringUtils.java
Index: StringUtils.java
===
RCS file:
/home/cvs/jakarta-commons/lang/src/java/org/apache/commons/lang/StringUtils.java,v
retrieving revision 1.27
retrieving revision 1.28
diff -u -r1.27 -r1.28
--- StringUtils.java 27 Nov 2002 22:54:29 - 1.27
+++ StringUtils.java 7 Dec 2002 21:50:29 - 1.28
@@ -55,9 +55,10 @@
*/
import java.util.StringTokenizer;
-
import java.util.Iterator;
+import org.apache.commons.lang.exception.NestableRuntimeException;
+
/**
* pCommon codeString/code manipulation routines./p
*
@@ -952,6 +953,77 @@
break;
}
}
+}
+return buffer.toString();
+}
+
+/**
+ * Unescapes any Java literals found in the String. For example,
+ * it will turn a sequence of '\' and 'n' into a newline character,
+ * unless the '\' is preceded by another '\'.
+ */
+public static String unescape(String str) {
+int sz = str.length();
+StringBuffer buffer = new StringBuffer(sz);
+StringBuffer unicode = new StringBuffer(4);
+boolean hadSlash = false;
+boolean inUnicode = false;
+for (int i = 0; i sz; i++) {
+char ch = str.charAt(i);
+if(inUnicode) {
+// if in unicode, then we're reading unicode
+// values in somehow
+if(unicode.length() == 4) {
+// unicode now contains the four hex digits
+// which represents our unicode chacater
+try {
+int value = Integer.parseInt(unicode.toString(), 16);
+buffer.append( (char)value );
+unicode.setLength(0);
+unicode.setLength(4);
+inUnicode = false;
+hadSlash = false;
+} catch(NumberFormatException nfe) {
+throw new NestableRuntimeException(Unable to parse unicode
value: +unicode, nfe);
+}
+} else {
+unicode.append(ch);
+continue;
+}
+}
+if(hadSlash) {
+// handle an escaped value
+hadSlash = false;
+switch(ch) {
+case '\\':
cvs commit: jakarta-commons/lang default.properties project.xml
bayard 2002/12/07 13:52:19
Modified:lang default.properties project.xml
Log:
Updated version from 1.0 to 1.1-dev.
Revision ChangesPath
1.8 +2 -1 jakarta-commons/lang/default.properties
Index: default.properties
===
RCS file: /home/cvs/jakarta-commons/lang/default.properties,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- default.properties4 Oct 2002 03:23:18 - 1.7
+++ default.properties7 Dec 2002 21:52:19 - 1.8
@@ -1,3 +1,4 @@
+junit.home=/usr/local/javalib
# The pathname of the junit.jar JAR file
junit.jar = ${junit.home}/junit-3.7.jar
@@ -11,7 +12,7 @@
component.title = Core Language Utilities
# The current version number of this component
-component.version = 1.0
+component.version = 1.1-dev
# The name that is used to create the jar file
final.name = ${component.name}-${component.version}
1.8 +1 -1 jakarta-commons/lang/project.xml
Index: project.xml
===
RCS file: /home/cvs/jakarta-commons/lang/project.xml,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- project.xml 7 Nov 2002 20:06:20 - 1.7
+++ project.xml 7 Dec 2002 21:52:19 - 1.8
@@ -3,7 +3,7 @@
extend../project.xml/extend
idcommons-lang/id
nameLang/name
- currentVersion1.0/currentVersion
+ currentVersion1.1-dev/currentVersion
inceptionYear2001/inceptionYear
description
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [core] Scope, you choose!
On Sat, 7 Dec 2002, Henri Yandell wrote: One potential criteria for the zipped Commons distro would be that it must not be dependent on external jars, ie) the distro is entirely self-cohesive. Wouldn't this restrict us to include only Commons components that do not depend on things that *cannot* be redistributed? I don't personally see a problem inheriting the external dependencies of the underlying packages. I'm only interested/willing to support a single default configuration for combo: latest released versions of all jakarta-commons packages (i.e. no sandbox), combined into a single JAR, with integrated Javadocs. For the current selection of released packages, the list of external dependencies is pretty short (jdbc20ext.jar, jmx.jar, oro.jar), but will grow rapidly if/when jelly becomes a standard jakarta-commons component. Others, of course, are free to add build targets for the subsets they are interested in, or tweak the rules to enable conditional inclusion via Ant properties. Hen Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 15160] - speedup for beanutils / array getter
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=15160. 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=15160 speedup for beanutils / array getter [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2002-12-07 23:27 --- Your proposed optimization will not work when the underlying property contains an array of primitives rather than an array of objects. You would have discovered this if you'd tried the unit tests against your patched version :-). -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-commons/beanutils/src/java/org/apache/commons/beanutils/locale/converters package.html
craigmcc2002/12/07 15:34:41
Modified:beanutils/src/java/org/apache/commons/beanutils
BeanComparator.java ResultSetDynaClass.java
beanutils/src/java/org/apache/commons/beanutils/converters
package.html
beanutils/src/java/org/apache/commons/beanutils/locale
LocaleConvertUtils.java
beanutils/src/java/org/apache/commons/beanutils/locale/converters
package.html
Log:
Clean up Javadoc generation warnings under JDK 1.4. No functional changes.
Revision ChangesPath
1.3 +3 -4
jakarta-commons/beanutils/src/java/org/apache/commons/beanutils/BeanComparator.java
Index: BeanComparator.java
===
RCS file:
/home/cvs/jakarta-commons/beanutils/src/java/org/apache/commons/beanutils/BeanComparator.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- BeanComparator.java 2 Dec 2002 16:38:24 - 1.2
+++ BeanComparator.java 7 Dec 2002 23:34:40 - 1.3
@@ -70,7 +70,6 @@
* Allows you to pass the name of a method in and compare two beans.
*
* @author a hrefmailto:[EMAIL PROTECTED];Eric Pugh/a
- * @createdMay 5, 2002
*/
public class BeanComparator implements Comparator, Serializable {
1.6 +5 -5
jakarta-commons/beanutils/src/java/org/apache/commons/beanutils/ResultSetDynaClass.java
Index: ResultSetDynaClass.java
===
RCS file:
/home/cvs/jakarta-commons/beanutils/src/java/org/apache/commons/beanutils/ResultSetDynaClass.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- ResultSetDynaClass.java 13 Sep 2002 11:51:18 - 1.5
+++ ResultSetDynaClass.java 7 Dec 2002 23:34:40 - 1.6
@@ -318,7 +318,7 @@
/**
* pFactory method to create a new DynaProperty for the given index
- * into the result set metadata/p
+ * into the result set metadata./p
*
* @param metadata is the result set metadata
* @param i is the column index in the metadata
1.3 +2 -2
jakarta-commons/beanutils/src/java/org/apache/commons/beanutils/converters/package.html
Index: package.html
===
RCS file:
/home/cvs/jakarta-commons/beanutils/src/java/org/apache/commons/beanutils/converters/package.html,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- package.html 3 Sep 2002 20:41:25 - 1.2
+++ package.html 7 Dec 2002 23:34:41 - 1.3
@@ -4,9 +4,9 @@
/head
body bgcolor=white
pStandard implementations of the
-a href=../Converter.htmlConverter/a
+codeConverter/code
interface that are pre-registered with
-a href=../ConvertUtils.htmlConvertUtils/a
+codeConvertUtils/code
at startup time./p
/body
/html
1.2 +5 -5
jakarta-commons/beanutils/src/java/org/apache/commons/beanutils/locale/LocaleConvertUtils.java
Index: LocaleConvertUtils.java
===
RCS file:
/home/cvs/jakarta-commons/beanutils/src/java/org/apache/commons/beanutils/locale/LocaleConvertUtils.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- LocaleConvertUtils.java 3 Sep 2002 21:34:20 - 1.1
+++ LocaleConvertUtils.java 7 Dec 2002 23:34:41 - 1.2
@@ -393,7 +393,7 @@
* if there is no registered one, return codenull/code.
*
* @param locale The Locale
- * @return The FastHashMap instance contains the all {@LocaleConverter} types
for
+ * @return The FastHashMap instance contains the all {@link LocaleConverter}
types for
* the specified locale.
*/
protected static FastHashMap lookup(Locale locale) {
@@ -418,7 +418,7 @@
* Create all {@link LocaleConverter} types for specified locale.
*
* @param locale The Locale
- * @return The FastHashMap instance contains the all {@LocaleConverter} types
+ * @return The FastHashMap instance contains the all {@link LocaleConverter}
types
* for the specified locale.
*/
protected static FastHashMap create(Locale locale) {
1.2 +2 -2
jakarta-commons/beanutils/src/java/org/apache/commons/beanutils/locale/converters/package.html
Index: package.html
===
RCS file:
/home/cvs/jakarta-commons/beanutils/src/java/org/apache/commons/beanutils/locale/converters/package.html,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- package.html 3 Sep 2002 21:34:20
cvs commit: jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/cookie - New directory
jsdever 2002/12/07 22:02:15 jakarta-commons/httpclient/src/java/org/apache/commons/httpclient/cookie - New directory -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[modeler] removing deps ?
It would be reasonably easy to remove the deps of modeler on digester ( use DOM or SAX directly instead ) and beanutils ( we use only a a very small piece ). Our use of introspection will not be exposed to the user and we have some very specific requirements ( as mandated by the spec ), so there's little benefit of using the general purpose beanutils - quite the contrary. Modeler is a very critical piece - it needs to be in the parent loader ( if we want to control tomcat or other apps via JMX and modeler ), and it'll be critical for security. The fewer public APIs it exposes ( besides JMX ) and the fewer classes it drags into the same protection domain - the better it is. We'll not duplicate anything - the code to do what we need already exists ( in several forms ), we'll just use it ( adapted to the specific needs ). I don't think it'll be a problem with the duplicated maintainance either - the code we need has been quite stable for a long time and I think people working and using the modeler have enough experience to do maintain this code. Craig ? Remy ? Other people who are interested in modeler ? Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
