Re: [collection] PMD of Collections
On Thu, 7 Nov 2002, Henri Yandell wrote:
Looking at the PMD report of Commons Collections, I've fixed the blatant
errors [see:
http://pmd.sourceforge.net/reports/jakartacommons_jakarta-commons.html]
It still leaves a lot in the Tests which are basically:
try {
Object obj = someTest();
} catch(ExpectedException ee) {
...
}
It thinks these should be:
try {
someTest();
} catch(...
So. Does anyone mind if I go through and remove all the variable naming?
Is it doing any real service [all it shows is return type, rtfjdoc]?
One benefit to this is that if the signature changes (i.e. the return
type), then the assignment won't compile. In a way, reminding the
developer that changing the return type breaks things. Without the
assignment, there is no typecheck.
But really, I don't think that's much of an argument because there
really should be some other test that's implicitly checking the return
type when it tests that the method returns an expected result. So I'm
fine with removing the unused variables.
regards,
michael
--
Michael A. Smith
[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
Re: cvs commit: jakarta-commons-sandbox/daemon/src/native/unix/nativesignals.c
[hmmm... thought I posted this already, but haven't seen the post, nor
have I gotten the BCC to myself. try 2]
On 31 Oct 2002 [EMAIL PROTECTED] wrote:
jfclere 2002/10/31 03:32:05
Modified:daemon/src/native/nt/executables/vdmoniadm resource.h
daemon/src/native/nt/executables/vdmonisvc resource.h
daemon/src/native/nt/moni vdmoniadm.c vdmonisvc.c
daemon/src/native/nt/service instmain.c
daemon/src/native/nt/signals kills.c
daemon/src/native/nt/supcalls_nt vdenv.c
daemon/src/native/unix/native signals.c
Log:
Arrange licence stuff and C++ comments.
Revision ChangesPath
1.2 +61 -6
jakarta-commons-sandbox/daemon/src/native/nt/executables/vdmoniadm/resource.h
Index: resource.h
===
RCS file:
/home/cvs/jakarta-commons-sandbox/daemon/src/native/nt/executables/vdmoniadm/resource.h,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- resource.h 18 Feb 2002 21:15:40 - 1.1
+++ resource.h 31 Oct 2002 11:32:04 - 1.2
@@ -1,7 +1,62 @@
-//{{NO_DEPENDENCIES}}
-// Microsoft Developer Studio generated include file.
-// Used by vdmoniadm.rc
-//
+/* = *
+ * *
+ * The Apache Software License, Version 1.1 *
+ * *
+ * Copyright (c) 1999-2002 The Apache Software Foundation. *
+ * All rights reserved.*
+ * *
+ * = *
+ * *
+ * Redistribution and use in source and binary forms, with or without modi- *
+ * fication, are permitted provided that the following conditions are met: *
+ * *
+ * 1. Redistributions of source code must retain the above copyright notice *
+ *notice, this list of conditions and the following disclaimer. *
+ * *
+ * 2. Redistributions in binary form must reproduce the above copyright *
+ *notice, this list of conditions and the following disclaimer in the *
+ *documentation and/or other materials provided with the distribution. *
+ * *
+ * 3. The end-user documentation included with the redistribution, if any, *
+ *must include the following acknowlegement: *
+ * *
+ * This product includes software developed by the Apache Software *
+ *Foundation http://www.apache.org/. *
+ * *
+ *Alternately, this acknowlegement may appear in the software itself, if *
+ *and wherever such third-party acknowlegements normally appear. *
+ * *
+ * 4. The names The Jakarta Project, WebApp, and Apache Software *
+ *Foundation must not be used to endorse or promote products derived *
+ *from this software without prior written permission. For written *
+ *permission, please contact [EMAIL PROTECTED].*
WebApp? That doesn't match with what's specified in
http://cvs.apache.org/viewcvs/jakarta-commons-sandbox/daemon/LICENSE
or
http://cvs.apache.org/viewcvs/jakarta-commons-sandbox/daemon/LICENSE.txt
same for all the other files modified in this commit.
regards,
michael
--
Michael A. Smith
[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
Re: cvs commit: jakarta-commons-sandbox/jelly/src/test/org/apache/commons/jelly/jetty/docRoottest1.txt
/jelly/tags/jetty/SecurityHandlerTag.java Index: SecurityHandlerTag.java === /* * $Header: /home/cvs/jakarta-commons/latka/src/java/org/apache/commons/latka/jelly/SecurityHandlerTag.java,v 1.3 2002/07/14 12:38:22 dion Exp $ * $Revision: 1.3 $ * $Date: 2002/07/14 12:38:22 $ * * * * The Apache Software License, Version 1.1 * * Copyright (c) 1999-2001 The Apache Software Foundation. All rights * reserved. 2002? [snip] ok, I'm bored with this. check the copyright dates in all those other files as well. :) michael -- Michael A. Smith [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
Re: moving to a top-level project (was: [Ant nudge STATUS] Betterthanwe thought...)
On Tue, 29 Oct 2002, Geir Magnusson Jr. wrote: On 10/29/02 12:15 AM, Michael A. Smith [EMAIL PROTECTED] wrote: Geir Magnusson Jr. wrote: On 10/28/02 8:23 AM, Greg Stein [EMAIL PROTECTED] wrote: On Sun, Oct 27, 2002 at 04:08:02PM -0500, Michael A. Smith wrote: ... So, to clarify, committers on jakarta-commons voted for creating a management body of the code within the jakarta-commons cvs repository. Costin calls this the commons PMC, although the distinction should be made that this is not a board-recognized PMC. And to prevent confusion, I would highly suggest that the jakarta-commons committers find and use a different name than pmc. Otherwise, there will always be a to clarify when talking about it :-) Sorry - I missed something. What did we vote on? I saw some discussion, but I didn't see a vote for anything... I must have missed it. Search for subject Proposal: httpd-like PMC organisation First in thread was [EMAIL PROTECTED] (Message-ID: ap4a0j$lf5$[EMAIL PROTECTED]) Your response in the thread can be found at [EMAIL PROTECTED] (Message-id: [EMAIL PROTECTED]) regards, michael And that was considered a *vote*?? It was discussion on a proposal in which many of the respondents replied with a vote (i.e. +1). Thus, those respondants voted on the proposal. Whether you call that a vote or not, I don't particularly care, as I never said there was a vote. Just said that people voted. Sorry if the terminology is a bit misleading. regards, michael -- Michael A. Smith [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
Re: moving to a top-level project (was: [Ant nudge STATUS] Betterthanwe thought...)
Greg Stein wrote: [ damn, I hate reply-to... it totally horks cross-posting... adding commons-dev back... ] reply-to-all leaves commons-dev in there, at least for me. If reply-to wasn't set, you'd still have to use reply-to-all. :) On Mon, Oct 28, 2002 at 08:57:57AM -0500, Michael A. Smith wrote: Greg Stein wrote: On Sun, Oct 27, 2002 at 04:08:02PM -0500, Michael A. Smith wrote: ... So, to clarify, committers on jakarta-commons voted for creating a management body of the code within the jakarta-commons cvs repository. Costin calls this the commons PMC, although the distinction should be made that this is not a board-recognized PMC. And to prevent confusion, I would highly suggest that the jakarta-commons committers find and use a different name than pmc. Otherwise, there will always be a to clarify when talking about it :-) Cheers, -g yeah, I know. I've tried to only refer to a management body or oversight board or other generic terms to describe it rather than overloading the PMC term and confusing everyone. Hopefully Costin will start doing the same. :) Somebody used the term SPMC (SubProject Management Committee). That certainly helps to distinguish it. yup. I'd agree with that. :) [Since the time I wrote my note above] I just went and read the thread on commons-dev that Costin started. It looks like the end result was well, let's defer this for now. Unless I missed something, this means that it doesn't really matter what the name is... you guys aren't doing it :-) yeah, I was going to mention that. Don't know why it didn't make it into my mail. I do want to point out one item that Costin wrote near the end of the thread: I don't know - if it is too complicated we'll need a simpler solution. I hope we all realise that nobody can track all the code commits and all the code in general, and sooner or later an error can happen. It is interesting to point out that if the commons-dev group has a hard time monitoring all the activity, then how could the nine members of the Jakarta PMC monitor all of Jakarta? Eesh... :-) I'd say that is one of the motivators for spinning out projects from Jakarta -- provide each with a PMC that is highly focused on just that project and provide it with the legal umbrella/protection of the ASF. Isn't that what this reorg thing is partially about? :) Of course, I'm fearing the day that some J-C components may choose to move to A-C. My commit review load is going to skyrocket :-( :) (but that can also be a signal that something ought to move to top-level; something like the commons httpclient might be a good candidate for spinning out of J-C and Jakarta altogether... *shrug*) I've tried to encourage extremely active commons components, like httpclient (our most active) and jelly (which is still in the sandbox), to move themselves to a higher level, but since I'm not active on those particular compmonents, I haven't been too vocal about it. When I say higher level, I'm referring to the Jakarta subproject level (rather than a commons component), but that's only because I'm not sure I understood the option of promoting to a new top level apache project. Cheers, -g regards, michael -- Michael A. Smith [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
Re: moving to a top-level project (was: [Ant nudge STATUS] Betterthanwe thought...)
Geir Magnusson Jr. wrote: On 10/28/02 8:23 AM, Greg Stein [EMAIL PROTECTED] wrote: On Sun, Oct 27, 2002 at 04:08:02PM -0500, Michael A. Smith wrote: ... So, to clarify, committers on jakarta-commons voted for creating a management body of the code within the jakarta-commons cvs repository. Costin calls this the commons PMC, although the distinction should be made that this is not a board-recognized PMC. And to prevent confusion, I would highly suggest that the jakarta-commons committers find and use a different name than pmc. Otherwise, there will always be a to clarify when talking about it :-) Sorry - I missed something. What did we vote on? I saw some discussion, but I didn't see a vote for anything... I must have missed it. Search for subject Proposal: httpd-like PMC organisation First in thread was [EMAIL PROTECTED] (Message-ID: ap4a0j$lf5$[EMAIL PROTECTED]) Your response in the thread can be found at [EMAIL PROTECTED] (Message-id: [EMAIL PROTECTED]) regards, michael -- Michael A. Smith [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
Re: [collections] project.xml and versionning Was: cvs commit: jakarta-commons/collectionsproject.xml
done. regards, michael Martin van den Bemt wrote: Make it 2.2-dev and change it to 3.0 if the changes ask for a new major release number. So +1 ;) Shall I change it ? Mvgr, Martin On Sat, 2002-10-26 at 23:45, Henri Yandell wrote: Yeah, project.xml is important to update. I don't think it goes into the collections-src release, so it's only important to make sure the one in cvs outputs the right version number. Seems we're mainly looking at 2 questions: 1) Should the project.xml represent the next builder. ie) 2.2 or 3.0. 2) Should it include a -dev. I'm +1 on both. I say we call it 2.2-dev. Or 2.2-SNAPSHOT if we want that functionality by default. We also probably need to consider upgrading the release-howto on the website to mention that project.xml needs upgrading, for collections and for other projects. Hen On Sat, 26 Oct 2002, Steve Downey wrote: The difference, to me at least, is that project.xml is machine readable. That version number can end up in all sorts of places. My concern is distinguishing a genuine release from a development or nightly build. In theory that's pretty easy, but in practice, someone always forgets. A nightly release is promoted into QA in order to test a fix for a bug, and then no one remembers when and where it came from. And then we go through a cycle of the gee it works for me game. Right now 'maven dist' builds 'commons-collections-2.1.jar', and packages it into 'commons-collections-2.1.tar.gz' and so forth. On Saturday 26 October 2002 02:24 pm, Henri Yandell wrote: only one was me sticking ClassMap in, which needs me to do some doccing on it to explain it further, and possibly modify its lookup algorithm. The STATUS.html [I think it's that] has a 'Next Release' bit that I left as '?' when doing the last release. Figuring out what the next release is will involve updating that :) Hen On 26 Oct 2002, Martin van den Bemt wrote: If you know what the next release is going to be named ;) Mvgr, Martin On Sat, 2002-10-26 at 18:39, Steve Downey wrote: Shouldn't it be 2.2, or 2.1-dev, or 2.2-dev? Whatever it is, the result of building it now isn't the 2.1 release. [OK, so it might be. I don't think there have been any checkins since release] On Saturday 26 October 2002 07:04 am, [EMAIL PROTECTED] wrote: mvdb2002/10/26 04:04:46 Modified:collections project.xml Log: Updated the version in project.xml. Thanx Moritz Petersen for pointing us to that. Revision ChangesPath 1.6 +1 -1 jakarta-commons/collections/project.xml Index: project.xml === RCS file: /home/cvs/jakarta-commons/collections/project.xml,v retrieving revision 1.5 retrieving revision 1.6 diff -u -r1.5 -r1.6 --- project.xml 14 Sep 2002 02:17:18 - 1.5 +++ project.xml 26 Oct 2002 11:04:46 - 1.6 @@ -4,7 +4,7 @@ extend../project.xml/extend nameCollections/name idcommons-collections/id - currentVersion2.0/currentVersion + currentVersion2.1/currentVersion inceptionYear2002/inceptionYear gumpRepositoryIdjakarta/gumpRepositoryId shortDescriptionCommons Collections/shortDescription -- Michael A. Smith [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
Re: [collections] collections depends on lang? (RE: cvs commit: jakarta-commons/collections/src/java/org/apache/commons/collectionsClassMap.java)
Ok, so I went back to write my little proposal (which I'm not even going to mention now). In order to make sure my proposal was well informed and thus a higher chance of being adopted, I went back to take a look at previous discussions about commons-core, dependencies between commons components, and other related topics. While very depressing[*], this exercise was very informative, and is keeping me from making an ill-advised proposal. Even with the release of a commons-core or a commons-combo or whatever, the issue of interdependencies isn't going to go away. Classes and functionality need to be put into the most appropriate classes, and only when said functionality is absolutely necessary. My current thoughts are that maybe this ClassMap shouldn't even be there. While it does provide some interesting functionality that I know would be useful for the conversion stuff (as was the original example that Hen described), the semantics of the super interface/class is way under defined. And even just adding documentation isn't going to solve that, as different people may want different semantics. I'm beginning to think that if someone wants such a functionality they could have their project depend on both lang and collections and implement the semantics they want on their own. In other words, I think that ClassMap might be a little bit outside the scope of the collections component, even if it *is* a map. btw, an eventual dependency on lang and/or pattern might be acceptable, but as Rodney pointed out, ClassMap isn't the best justification for doing that at this point. regards, michael [*] If you're curious, search archives in June for messages with the subject of architecture, and messages in August with subject of cross dependecy[sic] and pattern charter (case insensitive). That was right before the start of the nearly two-week long debate on public constructors. Fun, fun, fun. Michael A. Smith wrote: Agreed. Care must be taken when adding dependencies, especially to collections and lang. I have an alternative suggestion, but want to write it up as a more formal proposal. Hopefully I'll get that done by the end of the weekend. regards, michael On Fri, 25 Oct 2002, Waldhoff, Rodney wrote: Personally, I'd prefer not to have collections depend upon lang (currently it doesn't depend upon anything else, correct?), at least not if ClassMap is the best justification we have for it. A lot of other packages use Collections, so adding a new dependency to Collections is adding a new dependency to a lot of modules. We should be very careful and deliberate about that. Much of the code for getting all the superclasses and superinterfaces of a class is coded in the upcoming [lang] reflection code. Maybe the next collections release should depend on [lang]? Stephen -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org -- Michael A. Smith [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
Re: what's the right way to deal with unlicensed code in sandbox?
Martin van den Bemt wrote: Hmm I didn't actually know where I was getting into ;) All the java code looks ok, but the native doesn't.. I think some of the current maintainers of daemon are better candidates to this change and also handle the necessary waivers for the siemens code in there.. Siemens code? Unless by waivers you mean a signed document on file with the ASF, I'm getting scared. Especially after messages on the reorg list from Roy last night. See [EMAIL PROTECTED] for the two messages I'm referring to. regards, michael -- Michael A. Smith [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
Re: cvs commit: jakarta-commons-sandbox/vfs/src/java/org/apache/commons/vfs/utilMessages.java
[EMAIL PROTECTED] wrote:
adammurdoch2002/10/23 06:09:10
Modified:vfs/src/java/org/apache/commons/vfs/provider/jar
JarFileObject.java JarFileSystem.java
vfs/src/java/org/apache/commons/vfs/provider
DefaultFileContent.java
vfs/src/java/org/apache/commons/vfs/util Messages.java
Log:
Fix checkstyle complaints.
Revision ChangesPath
1.4 +9 -5 jakarta-commons-sandbox/vfs/src/java/org/apache/commons/vfs/provider/jar/JarFileObject.java
Index: JarFileObject.java
===
RCS file: /home/cvs/jakarta-commons-sandbox/vfs/src/java/org/apache/commons/vfs/provider/jar/JarFileObject.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- JarFileObject.java 23 Oct 2002 11:59:41 - 1.3
+++ JarFileObject.java 23 Oct 2002 13:09:10 - 1.4
@@ -78,10 +78,10 @@
{
private Attributes attributes;
-public JarFileObject( FileName name,
- ZipEntry entry,
- ZipFile zipFile,
- JarFileSystem fs )
+public JarFileObject( final FileName name,
+ final ZipEntry entry,
+ final ZipFile zipFile,
+ final JarFileSystem fs )
{
super( name, entry, zipFile, fs );
}
checkstyle was complaining about that?
[snip]
Index: Messages.java
===
RCS file: /home/cvs/jakarta-commons-sandbox/vfs/src/java/org/apache/commons/vfs/util/Messages.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- Messages.java 23 Oct 2002 11:59:42 - 1.3
+++ Messages.java 23 Oct 2002 13:09:10 - 1.4
@@ -70,7 +70,7 @@
public class Messages
{
/** Map from message code to MessageFormat object for the message. */
-private static final Map messages = new HashMap();
+private static Map messages = new HashMap();
private static ResourceBundle resources;
private Messages()
checkstyle was complaining about that?
regards,
michael
--
Michael A. Smith
[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
RE: cvs commit: jakarta-commons-sandbox/vfs/src/java/org/apache/commons/vfs/utilMessages.java
On Wed, 23 Oct 2002, Adam Murdoch wrote:
-public JarFileObject( FileName name,
- ZipEntry entry,
- ZipFile zipFile,
- JarFileSystem fs )
+public JarFileObject( final FileName name,
+ final ZipEntry entry,
+ final ZipFile zipFile,
+ final JarFileSystem fs )
{
super( name, entry, zipFile, fs );
}
checkstyle was complaining about that?
Uh, no. I added the finals out of habit.
ok. just wondering. :)
@@ -70,7 +70,7 @@
public class Messages
{
/** Map from message code to MessageFormat object for
the message. */
-private static final Map messages = new HashMap();
+private static Map messages = new HashMap();
private static ResourceBundle resources;
private Messages()
checkstyle was complaining about that?
Yep. It wanted
private static final Map MESSAGES = new HashMap();
I prefered to get rid of the final.
ah... makes sense (even though you already had what you say it wanted
-- it probably wanted private final static or final private static or
something in a different order). :)
regards,
michael
--
Michael A. Smith
[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
Re: cvs commit: jakarta-commons-sandbox/jelly/src/java/org/apache/commons/jelly/tags/werkzUseGoalsTag.java WerkzTagLibrary.java
Since I'm being anal about copyright dates today... On 23 Oct 2002 [EMAIL PROTECTED] wrote: jstrachan2002/10/23 08:39:40 Modified:jelly/src/test/org/apache/commons/jelly/werkz example.jelly jelly/src/java/org/apache/commons/jelly/tags/werkz WerkzTagLibrary.java Added: jelly/src/java/org/apache/commons/jelly/tags/werkz UseGoalsTag.java [snip] 1.1 jakarta-commons-sandbox/jelly/src/java/org/apache/commons/jelly/tags/werkz/UseGoalsTag.java Index: UseGoalsTag.java === /* * * * * The Apache Software License, Version 1.1 * * Copyright (c) 1999 The Apache Software Foundation. All rights * reserved. We're in 2002 now. :) regards, michael -- Michael A. Smith [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
Re: monitoring the sandbox [WAS Re: License and copyright issues]
Steve Downey wrote: What about an automatic sunset on sandbox code? 3 months after initial commit it's either voted in as a project somewhere, or removed? 3 months of inactivity maybe, not 3 months from initial commit. Some code bases may require a long time to generate the necessary community, but as long as its active, I don't see a requirement to promote or remove. michael -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
Re: [Lang] Validate! [was: Assertions?]
Stephen Colebourne wrote: From: Ola Berg [EMAIL PROTECTED] From: Stephen Colebourne [EMAIL PROTECTED] I have a class like this at both work (called Assert) and in the Joda project (called Validate). Me to (but they are called Assert). Why can't you, Stephen, check some of this in (into lang sandbox?) so that we can have a go at it? Well at least in part because I no longer know if I can check code in from another project (Joda) to [lang] without going through lawyers. Joda uses an Apache style licence, so there should be no issue, but I just don't know anymore ;-) ask the jakarta PMC. Since they're the once offically charged with ensuring license compliance for jakarta projects (i.e. the board has given them that authority), then they should provide the correct answer. Anyway, the class is hardly tough to write from scratch. (Mine doesn't have the fancy array/list checking methods) or just rewrite it. what a strange manifestation of the NIH attitude. :) michael -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
Re: cvs commit: jakarta-commons-sandbox/periodicity/src/plugins-build/database/src/java/org/apache/commons/periodicity/databasePeriodicityDriverService.java DriverMetaDataService.java
[EMAIL PROTECTED] wrote: prickett2002/10/22 17:08:54 Modified:periodicity/src/plugins-build/database project.xml periodicity/src/plugins-build/database/src/java/org/apache/commons/periodicity/database DriverMetaDataService.java Added: periodicity/src/plugins-build/database/src/java/org/apache/commons/periodicity/database PeriodicityDriverService.java Log: Added a first cut of the Periodicity Driver Service Added a dependency on commons-configuration package version 1.0-dev Changed DriverMetaDataService to extend Service [snip] 1.1 jakarta-commons-sandbox/periodicity/src/plugins-build/database/src/java/org/apache/commons/periodicity/database/PeriodicityDriverService.java Index: PeriodicityDriverService.java === package org.apache.commons.periodicity.database; /* * $Header: /home/cvs/jakarta-commons-sandbox/periodicity/src/plugins-build/database/src/java/org/apache/commons/periodicity/database/PeriodicityDriverService.java,v 1.1 2002/10/23 00:08:54 prickett Exp $ * $Revision: 1.1 $ * $Date: 2002/10/23 00:08:54 $ * * * * The Apache Software License, Version 1.1 * * Copyright (c) 1999-2001 The Apache Software Foundation. All rights * reserved. shouldn't this be (c) 2002? It's a first cut, so I doubt it existed from 1999 to 2001. regards, michael -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
Re: cvs commit: jakarta-commons-sandbox/periodicity/src/plugins-build/database/src/test/org/apache/commons/periodicity/databaseTestDriverService.java
[EMAIL PROTECTED] wrote: prickett2002/10/22 19:25:24 Added: periodicity/src/plugins-build/database/src/test/org/apache/commons/periodicity/database TestDriverService.java Log: Added a Test Driver Meta Data Service class for unit testing purposes. Revision ChangesPath 1.1 jakarta-commons-sandbox/periodicity/src/plugins-build/database/src/test/org/apache/commons/periodicity/database/TestDriverService.java Index: TestDriverService.java === package org.apache.commons.periodicity.database; /* * $Header: /home/cvs/jakarta-commons-sandbox/periodicity/src/plugins-build/database/src/test/org/apache/commons/periodicity/database/TestDriverService.java,v 1.1 2002/10/23 02:25:24 prickett Exp $ * $Revision: 1.1 $ * $Date: 2002/10/23 02:25:24 $ * * * * The Apache Software License, Version 1.1 * * Copyright (c) 1999-2001 The Apache Software Foundation. All rights * reserved. Same thing with this one. This should probably be (c) 2002. regards, michael -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
Re: cvs commit: jakarta-commons-sandbox/periodicity/src/plugins-build/database/src/test/org/apache/commons/periodicity/databaseDriverServiceConfigNullTest.java
[EMAIL PROTECTED] wrote: prickett2002/10/22 19:47:16 Added: periodicity/src/plugins-build/database/src/test/org/apache/commons/periodicity/database DriverServiceConfigNullTest.java Log: Added a test to test the behavior for a null configuration. Revision ChangesPath 1.1 jakarta-commons-sandbox/periodicity/src/plugins-build/database/src/test/org/apache/commons/periodicity/database/DriverServiceConfigNullTest.java Index: DriverServiceConfigNullTest.java === package org.apache.commons.periodicity.database; /* * $Header: /home/cvs/jakarta-commons-sandbox/periodicity/src/plugins-build/database/src/test/org/apache/commons/periodicity/database/DriverServiceConfigNullTest.java,v 1.1 2002/10/23 02:47:15 prickett Exp $ * $Revision: 1.1 $ * $Date: 2002/10/23 02:47:15 $ * * * * The Apache Software License, Version 1.1 * * Copyright (c) 1999-2001 The Apache Software Foundation. All rights * reserved. And this one. This should probably be (c) 2002. regards, michael -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
Re: cvs commit: jakarta-commons-sandbox/jelly/src/test/org/apache/commons/jelly/test/xmlTestXMLParserCache.java
[EMAIL PROTECTED] wrote: morgand 2002/10/22 14:57:47 Added: jelly/src/test/org/apache/commons/jelly/test/xml TestXMLParserCache.java Log: some sanity checks for XMLParser cache Revision ChangesPath 1.1 jakarta-commons-sandbox/jelly/src/test/org/apache/commons/jelly/test/xml/TestXMLParserCache.java Index: TestXMLParserCache.java === /* * $Header: /home/cvs/jakarta-commons-sandbox/jelly/src/test/org/apache/commons/jelly/test/xml/TestXMLParserCache.java,v 1.1 2002/10/22 21:57:47 morgand Exp $ * $Revision: 1.1 $ * $Date: 2002/10/22 21:57:47 $ * * * * The Apache Software License, Version 1.1 * * Copyright (c) 1999-2002 The Apache Software Foundation. All rights * reserved. probably isn't as bad as not including 2002 when things actually change in 2002, but did this stuff really start in 1999? It could have I suppose... regards, michael -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
Re: Proposal: httpd-like PMC organisation
+1 on the proposal to add a commons oversight board. We don't need to name it PMC (the charter doesn't give this oversight board a name, it just makes the analogy to the jakarta PMC). Oh, and I've already volunteered. michael p.s. Did anyone else see a 6 hour delay between the time it looks like Costin sent this and actually receiving it? Costin Manolache wrote: We already have a line in our charter about having a jakarta-commons specific PMC. Right now it is modeled after jakarta, with 3 members. I would like to propose changing this number to include more people - I think the right solution is more closer to what httpd and apr projects are doing, where the PMC is composed of most active commiters. My proposal is to modify the charter so that a jakarta-commons PMC is composed of all active commiters. This will be volunteer-based, in the sense that any active commiter who wants to become part of the PMC will announce his willingness to participate. Questions: - should we vote on the volunteering offer ? What is httpd doing ? - Should we impose a 2-3 month wait period for new commiters ? ) - should the pmc have a separate mail list ? ( I personally don't think so - but that's how other pmcs are organised ) The commons PMC members will split the task of monitoring the files. All decisions will continue to be taken by majority vote of all jakarta-commons commiters. Not that this is not a proposal to form a top-level project - just to better organise ourself. Jakarta-commons is IMO at the core of jakarta - with the most diverse set of commiters from almost all jakarta projects. Any major issue will be forwarded to the Jakarta PMC. -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
Re: cvs commit: jakarta-commons-sandbox/periodicity/src/plugins-build/database/src/test/org/apache/commons/periodicity/databaseDriverServiceConfigEmptyTest.java DriverServiceDbFileNonExistTest.java
[EMAIL PROTECTED] wrote: prickett2002/10/22 20:56:41 Added: periodicity/src/plugins-build/database/src/test/org/apache/commons/periodicity/database DriverServiceConfigEmptyTest.java DriverServiceDbFileNonExistTest.java Log: Added a Junit test to test what happens with an empty configuration file Added a JUnit test to test what happens with a non-existent configuration file. Revision ChangesPath 1.1 jakarta-commons-sandbox/periodicity/src/plugins-build/database/src/test/org/apache/commons/periodicity/database/DriverServiceConfigEmptyTest.java Index: DriverServiceConfigEmptyTest.java === package org.apache.commons.periodicity.database; /* * $Header: /home/cvs/jakarta-commons-sandbox/periodicity/src/plugins-build/database/src/test/org/apache/commons/periodicity/database/DriverServiceConfigEmptyTest.java,v 1.1 2002/10/23 03:56:41 prickett Exp $ * $Revision: 1.1 $ * $Date: 2002/10/23 03:56:41 $ * * * * The Apache Software License, Version 1.1 * * Copyright (c) 1999-2001 The Apache Software Foundation. All rights um. Same thing. We're in the year 2002 now. regards, michael -- Michael A. Smith [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
Re: [collections] ClassMap and others
Henri Yandell wrote: I just pushed a ClassMap class in. Uses inheritence in the get, so you can do: map.put(Number.class, new NumberConverter()); Converter c = (Converter)map.get(Float.class); assuming a Converter class. I like, but I see some issues with the implementation with regards to interfaces. I just commented on your cvs commit (did that before I saw this message). It doesn't do anything fancy with Integer.TYPE. ie) claiming that that extends Number.class etc. Any views? these would be special cases, right? dunno... I'll think about it though. Clearing out my collections package... Other things: I still need to add an isSorted to CollectionUtils, will go ahead and do that at some point. Making myself hold back until I have a unit-test is almost like hard work :) I'm not sure that an isSorted will work for CollectionUtils. Collection implementations have no restrictions on maintaining iterator order from one iterator to the next, so while the first time you call isSorted it may return true, the second time it may not. In fact, the Collections.iterator() documentation explicitly states that: There are no guarantees concerning the order in which the elements are returned (unless this collection is an instance of some class that provides a guarantee). Now, if you add that to ListUtils and perform on lists, then that seems reasonable. I have a SortedIterator class. Basic usage being: .. Iterator iterator = ... SortedIterator si = new SortedIterator(iterator, new SomeComparator() ); .. Then it reads that iterator out in sorted order. Obviously has to suck it into memory internally. Anyone think this is of use? This same thing can be accomplished using the three-step: List l = IteratorUtils.toList(iterator); Collections.sort(list, new SomeComparator()); Iterator sorted = list.iterator(); to get the desired effect. Why? Because the implementation cannot do magic and turn an interator into a sorted iterator without reading the entire iterator, storing each element into a temporary store, then sorting it. Leaving it up to the user to do this three-step process (create List to store all elements, sort list, get iterator) ensures that a developer understands the memory implications (i.e. that the entire iterator is read into a list). In other words, I don't see this as adding much functionality. but, maybe that's just me. :) OrderedSet - Basically a List which doesn't allow duplicates. ok. LimitedList - A List which maintains a fixed max length. usefulness? Maybe an LRUList? SortedLimitedList - A List which uses a Comparator to maintain a sorted max length. Useful to do a quick sort to find the first N elements of a list of length L. Insertion Sort huh? ProxySet/List. Any reason not to have these? [or even ProxyCollection]? not that I can think of. typed.* a Map/List/Set wrapper which enforces the Type of the value or key. So you'd do: .. List list = new TypedList(Integer.class) .. and it will throw an Exception if u pass the wrong thing in. isn't this just a ListUtils.predicatedList(p) with a predicate, p, that checks for the right class? maybe provide the predicate to construct such a thing? That's all that leaps out as mature for now. Apologies if I'm repeating myself with any of these, am attempting to clean out my collections package so I can force myself to use Commons Collections more. Will slowly add things as I get time and unit tests together. cool. Or at least the ones that aren't blown apart. ;) michael -- Michael A. Smith [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
Re: Licensing Issues
Jeff Prickett wrote: Michael, The licensing details will be worked out soon. hrm. what's this mean? A good portion of the Periodicity code base dates back to 2000. Some of the UML diagrams date back to 1999. However, you are right the code just checked in is totally new and as such should hold (c) 2002. cool. :) As far as this being my own original contribution. It is. There are no conflicts as far as outside copyrights. Thanks for reaffirming that. I was just being anal about the dates though. :) michael -- Michael A. Smith [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
Re: License and copyright issues
The closest I can identify is jxpath which contains this at the end of the license in each source file[1]: * This software consists of voluntary contributions made by many * individuals on behalf of the Apache Software Foundation and was * originally based on software copyright (c) 2001, Plotnix, Inc, * http://www.plotnix.com/. * For more information on the Apache Software Foundation, please see * http://www.apache.org/. Where typical apache code contains only: * This software consists of voluntary contributions made by many * individuals on behalf of the Apache Software Foundation. For more * information on the Apache Software Foundation, please see * http://www.apache.org/. However, I can't imagine this would be the source of the problem since this project has been in CVS for over a year now (Aug 23, 2001), not 4 months, as Roy specifies. I should also note that it has had active participation by an Apache member (craigmcc), and on the plotnix website, there is the statement: JXPath was initially developed by Dmitri Plotnikov at PLOTNIX and then contributed to the Apache Jakarta project. The new home of JXPath is Jakarta Commons[2] And Dmitri Plotnikov is a committer here, actively developing JXPath. Thus, I'm not sure this is the problem that Roy was referring to. That's why I asked Roy (and Ken Coar) on the reorg list to specify the problem[3]. I have yet to hear back. Any other ideas what the problem may be? regards, michael [1] For example, http://cvs.apache.org/viewcvs/jakarta-commons/jxpath/src/java/org/apache/commons/jxpath/AbstractFactory.java?rev=1.4content-type=text/vnd.viewcvs-markup [2] http://www.plotnix.com [3] [EMAIL PROTECTED] Costin Manolache wrote: The following was posted by Roy Fielding: Just look at the commons cvs -- there is code present that was taken from another open source project, the license removed, and replaced with the committer's own copyright alongside that of the ASF. That isn't just contrary to our guidelines; it is immoral! And, it has been there for four months without anyone so much as lifting a finger (not to mention deleting the module, which is what I would have done). If that isn't cause to terminate an entire project, I don't know what is. This is a very serious accusation, and it seems other people are aware of this issue - yet neither jakarta-commons nor jakarta PMC have been informed ( at least to my knowledge ). We may have too much traffic - or maybe people don't know about [EMAIL PROTECTED], or maybe those who claim 'we don't care' are right. As you should know, it is our duty to review the code that is checked in and make sure it respect some basic rules. I think it is essential for us to find the code and find out how this happened and how it can be prevented in the future. Nothing is perfect - and it is possible that people don't understand the rules or just didn't think. I can't find many excuses for whoever noticed and who knew about that and failed to notify the community or the PMC - and I include Roy here. But that doesn't change the fact that we have a serious and major problem - I think it is our fault in the first place as commons commiters for letting such a thing happen. Since I still can't find out what code he is reffering to - I would like to ask for your support in identifying it ( and fixing the problem, of course ), and then to discuss and try to find out solutions to avoid this in future. Costin -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
RE: License and copyright issues
On Mon, 21 Oct 2002, Henri Yandell wrote: On Mon, 21 Oct 2002, Martin Cooper wrote: I found a few things not yet mentioned: 1) In codec\Metaphone.java, Copyright 1997, William B. Brogden, which is clearly a problem. Sorry, my fault. I can and will remove this, and will go back in my records for the email in which he gave me the acceptance to take the code. [I think he said it was public domain.] Will provide more info in a bit. I do not believe we can attach a copyright and/or license to any public domain code without getting into murky water. Actually, I don't believe *anyone* can attach a copyright to public domain code without getting into murky water. Actually, I don't even think that's murky. The way I've understood discussion on reorg@apache, when we need answers on whether things like this will cause problems, we send them to [EMAIL PROTECTED] So, if you want to keep the code (it's sandbox code in a not-very-active component), dig up your documentation on where the code originated and any circumstances surrounding it, and attach it to an email to [EMAIL PROTECTED] where you can ask whether its ok. It'd probably be nice to include an executive summary so that the board can decipher what you're talking about a bit quicker. regards, michael -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
Re: License and copyright issues
I found another possibility (checked in around 3 months, 10 days ago, much closer to Roy's 4 month statement). Unfortunately, my archive of the CVS commits doesn't go back all the way, but I did comment on it at the time it was committed, and I have a copy of the message I sent, along with the response I got from the person that committed the code. Since I am not a member, nor on the PMC, I let the issue drop, figuring that a member or someone from the PMC would take it up with the board or whomever if it was really necessary. See attached messages. regards, michael ---BeginMessage--- On 10 Jul 2002 [EMAIL PROTECTED] wrote: patrickl2002/07/09 22:27:52 Added: daemon/src/bin launch-ant.bat launch-ant.sh launcher.properties launcher.xml daemon/src/java LauncherBootstrap.java daemon/src/java/org/apache/commons/launcher ChildMain.java LaunchFilter.java LaunchTask.java LaunchTask_en.properties Launcher.java LauncherClassLoader.java LauncherException.java Launcher_en.properties ParentListener.java StreamConnector.java Log: Initial commit of the Java Launcher tool. This tool, originally developed by Sun Microsystems, Inc. for use in its Java Web Services Developer Pack 1.0 product, is being donated to the Apache Software Foundation. This initial commit consists of working code and working Windows and Unix samples. Documentation for the XML file syntax is still a pending item. Obtained from: Sun Microsystems, Inc. This sounds like it requires some kind of legal agreement with Sun. Was that properly obtained by the Apache board? just curious. it seems as though many of us committers are left in the dark when it comes to legal agreements that are made or in the process of being made. The apache board doesn't even seem to be posting their meeting minutes anymore (I doubt its been 6 months since their last meeting): http://www.apache.org/foundation/board/calendar.html regards, michael -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org ---End Message--- ---BeginMessage--- Michael, Actually, donated by Sun Microsystems, Inc. is really an overstatement. More correctly, this code was developed by me personally while I was on unpaid leave from Sun. Also, the current iteration that was committed to this project was a completely new rewrite from the Launcher code that I developed for Sun's Java Web Services Developer Pack. So, as far as legal issues go, I would say that we are OK. The reason I put it in this project was that there is a desire to include a Launcher in the Tomcat 5.0 proposal that is currently be voted on in the tomcat-dev mailing list. Hope that helps, Patrick Michael A. Smith wrote: On 10 Jul 2002 [EMAIL PROTECTED] wrote: patrickl2002/07/09 22:27:52 Added: daemon/src/bin launch-ant.bat launch-ant.sh launcher.properties launcher.xml daemon/src/java LauncherBootstrap.java daemon/src/java/org/apache/commons/launcher ChildMain.java LaunchFilter.java LaunchTask.java LaunchTask_en.properties Launcher.java LauncherClassLoader.java LauncherException.java Launcher_en.properties ParentListener.java StreamConnector.java Log: Initial commit of the Java Launcher tool. This tool, originally developed by Sun Microsystems, Inc. for use in its Java Web Services Developer Pack 1.0 product, is being donated to the Apache Software Foundation. This initial commit consists of working code and working Windows and Unix samples. Documentation for the XML file syntax is still a pending item. Obtained from: Sun Microsystems, Inc. This sounds like it requires some kind of legal agreement with Sun. Was that properly obtained by the Apache board? just curious. it seems as though many of us committers are left in the dark when it comes to legal agreements that are made or in the process of being made. The apache board doesn't even seem to be posting their meeting minutes anymore (I doubt its been 6 months since their last meeting): http://www.apache.org/foundation/board/calendar.html regards, michael -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org -- Patrick Luby Email: [EMAIL PROTECTED] Sun Microsystems Phone: 408-276-7471 901 San Antonio Road, USCA14-303 Palo Alto, CA 94303-4900 -- To unsubscribe, e-mail
Re: What should we do about sandbox ? RE: License and copyright issues
Costin Manolache wrote: Martin Cooper wrote: I found a few things not yet mentioned: 1) In codec\Metaphone.java, Copyright 1997, William B. Brogden, which is clearly a problem. 2) In scaffold, numerous instances of Copyright (c) 2002 Synthis Corporation., also clearly a problem. Acording to jakarta-commons rules, the sandbox is just a CVS repository where experiments may happen. I see it similar with commiters using their homes or public_html pages on jakarta - or with the commiters cvs repository. The sandbox is open to any jakarta commiter. The question is: do we have to police it and monitor all forms of activities that happen on apache servers ? Because as far as I can see, there is no difference between a file placed by a jakarta commiters on his public_html or home and the files in commons-sandbox. We made it very clear that sandbox code can't be released, and the fact that it is accessible using public cvs and viewcvs is similar with the public_html files. These were my thoughts exactly, and partly why I only noticed the potential issue (probably non-issue) with jxpath, and not those in codec and scaffold. I was only looking in jakarta-commons, not jakarta-commons-sandbox. I would propose to ask the sandbox to be removed from viewcvs and the eventually discuss what to do about the public cvs. As a way to protect ourself. I wouldn't mind if this is voted down :-) Certainly a possibility, but that kinda kills the ability to create a community which is the whole point to the sandbox. What do you think about this issue ? Any other proposed solutions ? Shouldn't we bring this question up with the jakarta PMC? Since this is really a legal question, I would think the board, via the PMC, should have the say on how this should be handled. michael -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
Re: [collections] Re: Fw: Testing of a release
Stephen Colebourne wrote: Michael, sorry to be formal, but does this mean the -1 is removed? If so, then we have enough votes, and the release will occur. Stephen yes, my -1 is removed, and I'll now give a +1. I still do have the concern over which JDK is used to build the binary distribution and whether that's an issue or not. I wouldn't want the binary distribution to be unusable in 1.2.2 because it's using a new class file format (I also can't remember whether that changed from 1.2.2 to 1.3 or from 1.3 to 1.4). I'm not even sure how to confirm that. I quickly tried a 1.2.2 version of javap on one of the classes compiled in 1.4, and that seemed to work fine, so maybe I'm just crazy. Or maybe jdk 1.3 and 1.4 default to using target=1.2. Whatever. Not a big enough concern for me to hold up the release any longer. :) btw, thanks for putting up with me. :) michael - Original Message - From: Michael A. Smith [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Sent: Sunday, October 20, 2002 7:46 AM Subject: Re: Fw: Testing of a release [moving back to commons-dev since others may be interested in this] Henri Yandell wrote: Where do we stand on the collections release? Michael, at what point are you willing to remove your -1? Stephen (I was never meant to be a manager ... ;-) It's no different than being a librarian I reckon :) Just the books talk back. And being a librarian is something that any ape can do. I believe things look much better now. A 2.1 build using current CVS should be fine as long as Hen's latest manifest gets included (which I guess *is* current CVS), and xdocs/index.xml gets updated with the latest release (see below). The RC2 fails on - General #2 - the filename of the rc2 ends with rc1 Ack. There are times when I think that being professional at 3am is just stupid. That was me messing up the 'mv' command. Amazing isn't it. Fixed it online. :) Source #4 - the xdocs source file still references 2.0 Yeah, from Daniel's RC-ing in Lang I've not been following the distribution stage of the build. ie) announce, make a website etc. I think the latest collections release mentioned in the xdocs source is ok to leave as 2.0 for the release candidates, but should definately be fixed for the actual 2.1 release build. Source #5 - result is different, but I'm not sure why Possibly platform. Will retry. In fact will retry now before we send now that I've sent a nice rant to the reorg people :) Okay. There is a size difference it seems. Building from the zip, on the same machine, I get slightly smaller zip and tar.gz's than I did for the rc2. However, If I unzip both, do ls -l on each file, then print the file-size and the name of the file into a file. Then I do a diff on those two files, I get no differences. So that suggests that each entry of the two created zips [I only tested the created zips] has the same entries. I'll repeat with a cksum later on, but at first glance it seems to me that the difference is not due to the contents. I don't know how much of a difference you're seeing. For the source distribution, a full recursive diff didn't yield any differences for me, but I wouldn't have expected any since the source dist just pulls from CVS. As for the binary distribution, I would expect there to be some differences because the .jar file contains timestamps which probably are different (which, due to compression, may yield different file sizes). Additionally, the javadoc generated html files contain timestamps which will be different, and thus possibly compress differently. But, that would be all the differences I would expect you (Hen) to see since you built the distribution in the first place. On the other hand, its possible for anyone else to see many more differences, unless the exact same platform/JDK version is used. I don't know what version you (Hen) used to build the binary distribution, but I built using 1.2.2 since its the lowest version we support (this using a class file format that should be usable by all JRE's we support). The binary distribution I built from the source distribution differs greatly from the binary distribution you put out. Each class file is different, probably because of differences in the compiler producing slightly different bytecode (hopefully, the class file format is the same!). Additionally, I see differences in the generated html like the following (probably due to a difference in javadoc between the two versions): TD BGCOLOR=#FF CLASS=NavBarCell1A HREF=../../../../../index-all.htmlFONT CLASS=NavBarFont1BIndex/ B/FONT/Anbsp;/TD --- TD BGCOLOR=#FF CLASS=NavBarCell1A HREF=../../../../../index-all.htmlFONT ID=NavBarFont1BIndex/B /FONT/Anbsp;/TD [sorry for the line wrapping] Note the difference between CLASS=NavBarFont1 and ID=NavBarFont1 This difference in JDKs also manifests itself in other ways. For example
Re: Fw: Testing of a release
[moving back to commons-dev since others may be interested in this] Henri Yandell wrote: Where do we stand on the collections release? Michael, at what point are you willing to remove your -1? Stephen (I was never meant to be a manager ... ;-) It's no different than being a librarian I reckon :) Just the books talk back. And being a librarian is something that any ape can do. I believe things look much better now. A 2.1 build using current CVS should be fine as long as Hen's latest manifest gets included (which I guess *is* current CVS), and xdocs/index.xml gets updated with the latest release (see below). The RC2 fails on - General #2 - the filename of the rc2 ends with rc1 Ack. There are times when I think that being professional at 3am is just stupid. That was me messing up the 'mv' command. Amazing isn't it. Fixed it online. :) Source #4 - the xdocs source file still references 2.0 Yeah, from Daniel's RC-ing in Lang I've not been following the distribution stage of the build. ie) announce, make a website etc. I think the latest collections release mentioned in the xdocs source is ok to leave as 2.0 for the release candidates, but should definately be fixed for the actual 2.1 release build. Source #5 - result is different, but I'm not sure why Possibly platform. Will retry. In fact will retry now before we send now that I've sent a nice rant to the reorg people :) Okay. There is a size difference it seems. Building from the zip, on the same machine, I get slightly smaller zip and tar.gz's than I did for the rc2. However, If I unzip both, do ls -l on each file, then print the file-size and the name of the file into a file. Then I do a diff on those two files, I get no differences. So that suggests that each entry of the two created zips [I only tested the created zips] has the same entries. I'll repeat with a cksum later on, but at first glance it seems to me that the difference is not due to the contents. I don't know how much of a difference you're seeing. For the source distribution, a full recursive diff didn't yield any differences for me, but I wouldn't have expected any since the source dist just pulls from CVS. As for the binary distribution, I would expect there to be some differences because the .jar file contains timestamps which probably are different (which, due to compression, may yield different file sizes). Additionally, the javadoc generated html files contain timestamps which will be different, and thus possibly compress differently. But, that would be all the differences I would expect you (Hen) to see since you built the distribution in the first place. On the other hand, its possible for anyone else to see many more differences, unless the exact same platform/JDK version is used. I don't know what version you (Hen) used to build the binary distribution, but I built using 1.2.2 since its the lowest version we support (this using a class file format that should be usable by all JRE's we support). The binary distribution I built from the source distribution differs greatly from the binary distribution you put out. Each class file is different, probably because of differences in the compiler producing slightly different bytecode (hopefully, the class file format is the same!). Additionally, I see differences in the generated html like the following (probably due to a difference in javadoc between the two versions): TD BGCOLOR=#FF CLASS=NavBarCell1A HREF=../../../../../index-all.htmlFONT CLASS=NavBarFont1BIndex/ B/FONT/Anbsp;/TD --- TD BGCOLOR=#FF CLASS=NavBarCell1A HREF=../../../../../index-all.htmlFONT ID=NavBarFont1BIndex/B /FONT/Anbsp;/TD [sorry for the line wrapping] Note the difference between CLASS=NavBarFont1 and ID=NavBarFont1 This difference in JDKs also manifests itself in other ways. For example: $ diff /tmp/collections2.1/packaged/tar/commons-collections-2.1/META-INF/MANIFEST.MF /tmp/collections2.1/built/tar/commons-collections-2.1/META-INF/MANIFEST.MF 2,4d1 Extension-Name: org.apache.commons.collections Specification-Vendor: Apache Software Foundation Created-By: Ant 1.4.1 5a3 Created-By: Ant 1.4.1 6a5,6 Extension-Name: org.apache.commons.collections Specification-Vendor: Apache Software Foundation Again, probably due to a compiler difference whereby the manifest entries are ordered in a different way probably based on different environments (either differing Ant versions, or the jar tool, or something else). Speaking of which, have we specified which compiler version the binary distributions should be built with? I would assume 1.2 since that's the lowest version we support, thus ensuring the binary distributions are built with the correct class file format, but 1.3 using the -target 1.2 should work as well. This should probably be documentated in the release procedures though. Binary #4 - manifest contains spec version 1.0, not 2.1 Will
Re: cvs commit: jakarta-commons/collections/xdocs index.xml
I think the point of the hard coded version was so that people that download the distribution will be linked to the proper STATUS file... michael [EMAIL PROTECTED] wrote: bayard 2002/10/20 19:02:22 Modified:collections/xdocs index.xml Log: Updated web page with a 2.1 link and removed the hard-coded 1.13 from the STATUS. Revision ChangesPath 1.2 +4 -1 jakarta-commons/collections/xdocs/index.xml Index: index.xml === RCS file: /home/cvs/jakarta-commons/collections/xdocs/index.xml,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- index.xml 25 Jul 2002 02:36:45 - 1.1 +++ index.xml 21 Oct 2002 02:02:22 - 1.2 @@ -36,7 +36,7 @@ section name=Documentation p -An alphabetical list of the package can be found in the a href=http://cvs.apache.org/viewcvs/~checkout~/jakarta-commons/collections/STATUS.html?rev=1.13;collections +An alphabetical list of the package can be found in the a href=http://cvs.apache.org/viewcvs/~checkout~/jakarta-commons/collections/STATUS.html;collections status document/a. /p @@ -47,6 +47,9 @@ section name=Releases ul +lia +href=http://jakarta.apache.org/builds/jakarta-commons/release/commons-collections/v2.1/;Version +2.1/a/li lia href=http://jakarta.apache.org/builds/jakarta-commons/release/commons-collections/v2.0/;Version 2.0/a/li -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
Re: [collections] bug in CollectionUtils.cardinality method
We're in the release process so this cannot be fixed at the moment, so
please file a bug in Bugzilla so we don't lose track of this:
http://issues.apache.org/bugzilla/enter_bug.cgi?product=Commons
regards,
michael
Sergey Yevtushenko wrote:
There is a bug in cardinality method, which shows, when obj parameter is
null;
It leads to NullPointerException.
In order to reveal it, add line
assertEquals(0, CollectionUtils.cardinality(null, _b));
to testCardinality in TestCollectionUtils.
One variant of correct implementation is following:
public static int cardinality(Object obj, final Collection col) {
int count = 0;
Iterator it = col.iterator();
if(null==obj){
while(it.hasNext()){
Object elt = it.next();
if(null==elt){
count++;
}
}
}else{
while(it.hasNext()) {
Object elt = it.next();
if(obj.equals(elt)) {
count++;
}
}
}
return count;
}
Kind regards.
Sergey Yevtushenko
--
To unsubscribe, e-mail:
mailto:commons-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail:
mailto:commons-dev-help;jakarta.apache.org
--
To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
Re: [collections] suggestion for change in MultiHasMap
We're in the release process so this cannot be fixed at the moment, so
please file a bug in Bugzilla so we don't lose track of this:
http://issues.apache.org/bugzilla/enter_bug.cgi?product=Commons
regards,
michael
Sergey Yevtushenko wrote:
Current implementation of MultiHashMap has one problem with notion of
equality.
Namely, when for some key some value is added, and then removed from
MultiMap, and this value was only one value, that was put for this key
than multimap wouldn't be equal to with same values of key/value pairs,
in which this new value was not added.
This can be demonstrated by following test (can be added to
TestMultiHashMap.testMapEquals):
public void testMapEquals() {
MultiHashMap one = new MultiHashMap();
Integer value = new Integer(1);
one.put(One, value);
one.remove(One, value);
MultiHashMap two = new MultiHashMap();
assertEquals(two, one);
}
Suggested fix for this problem is the following change in code of
MultiHashMap.remove(Object key, Object value).
public Object remove( Object key, Object item )
{
ArrayList valuesForKey = (ArrayList) super.get( key );
if ( valuesForKey == null )
return null;
valuesForKey.remove( item );
//start of change
if(valuesForKey.isEmpty()){
remove(key);
}
//end of change
return item;
}
Best Regards.
Sergey Yevtushenko
--
To unsubscribe, e-mail:
mailto:commons-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail:
mailto:commons-dev-help;jakarta.apache.org
--
To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
jakarta-commons - apache-commons
All: As previously mentioned on this list, there is ongoing apache-wide discussions aimed at reorganizing the apache software foundation. These discussions are taking place on the [EMAIL PROTECTED] mailing list[1]. Also mentioned here briefly, is that the apache board recently voted to create an apache commons project (at the same level of jakarta). This project is still currently in the process of being formed in terms of structure. There is light discussion about this on the [EMAIL PROTECTED] mailing list[2]. Recently, on the reorg list, Costin Manolache, made the following proposal: Ok, let's take this - I assume Java will be one of the languages in the new commons. Why not move the current jakarta-commons as the java-language sub-project of the apache-commons. As for flamewar - as long as we can keep our ties with jakarta ( and now build ties to xml ) - I suspect most people will be happy. Actually, a much better idea would be to join the xml-commons with jakarta-commons and form the self-managed java side of apache-commons. With all commiters forming the PMC. There are quite a few people in xml.apache.org who are interested in participating in jakarta-commons ( and some are actually doing so ). Of course, the first step would be to ask the question on jakarta-commons and xml-commons and eventually put it to a vote. That's the only way to know - and avoids any flamewar. Consider this as a proposal. I should reiterate here that apache commons has not fully formed, so at this point there is no definition on how it is setup or how it works. The first few projects in apache commons will probably have a hand in shaping it to some degree. So, as mentioned in his proposal, I'm sending the question to jakarta-commons. What do committers here think? Is this something we would want to consider? regards, michael [1] You can subscribe to the mailing list by sending a mail to [EMAIL PROTECTED] [2] You can subscribe to the mailing list by sending a mail to [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
RE: [apache-commons] Apache Commons info?
On Thu, 17 Oct 2002, Scott Sanders wrote: [EMAIL PROTECTED] Is there another one? well, I'm subscribed to that message and there has been zero traffic. Meanwhile, based on the commit messages on http://cvs.apache.org/viewcvs/commons/STATUS there seems to be discussion happening somewhere. regards, michael -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
Re: [VOTE] Release 2.1 of commons collections
Henri Yandell wrote: 2. In the binary distribution (both .zip and .tar.gz), the commons-collections.jar contains a Manifest.mf that lists: Specification-Version: 1.0 Implementation-Version: 2.0 Imp Version done. Spec Version not done. Any suggestions on what it should be? 2.0? 2.1? Following the format of Collections 1, I think it would be 1.0. I think it should be 2.1. The API has changed since 2.0, so there's a new specification even though the changes were backwards compatible. If someone reimplements the collections 2.1 API, and specify specification-version 2.0 and implementation-version 6643 (some random build number), how would a user know that the implementation contains the 2.1 classes (e.g. iterators)? Hence, I think the spec number should be changed when the API changes. If we release a 2.1.1 bug-fix-only release, then the spec would stay at 2.1 since the API specification doesn't change. 3. In the .zip distributions (both source and binary), the text files do not have windows line endings. I'm not sure whether that's such a big deal, but you'd think that windows users that open the LICENSE.txt file in notepad will want to be able to read it. Same goes for all the source files and such. Recommend running ant's FixCRLF task on all .txt, .html, .xml, and .java files when the .zip distributions are created. Need to test that to make sure it doesn't introduce ^Ms on non-Windows I guess. Not done yet. yeah, this one is a bit semi-controversial, even to myself. I'd drop my -1 even if this wasn't fixed. [needs rechecking: 4. Unpacking the source distribution and executing ant dist does not generate the exact same binary distribution as what are up on the website. For the most part, this is probably due to #1, but once that's fixed, this should be done againt to make sure things are ok. In addition, the distributions that are generated from the ant dist result in files with base name of commons-collections-2.0 instead of commons-collections-2.1. This is due to the component.version specified as 2.0 in the build.xml instead of 2.1. Note. I get files with 2.1, then rename them to 2.1_rc2 for the rc. Apart from cvs tags which have to be different, I want all other things to say 2.1. agreed. They just shouldn't be 2.0. :) I don't think I'll have time to recheck the rc2 packaging until Sat evening, but if someone else can check for the issues I mentioned, that'd be great. regards, michael -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
Re: [jelly] whats required before moving to a commons proper (wasRe: [Latka][Proposal] Make Jelly a required dependency?)
James Strachan wrote: Firstly thanks to all the great feedback lately on Jelly, its really helped alot. There's still a few things that need to be sorted out before we can get close to a real release of Jelly (much more documentation and the dependency/distribution issues being highest priority). Before this recent discussion my thoughts were that these things could get sorted out while within, say, the commons-proper. Thats to say that I didn't think these kind of issues were a prerequisite for moving into commons proper but are prerequisites for a full release from the commons. My thinking was that moving to the commons proper might help us focus on getting things ready for a release and so forth. Though Ceki and Rodney would rather this happen in the sandbox first before it is proposed to move. So I guess the movement to the commons proper is like a half-release, halfway between being a sandbox component and being a released commons proper component. Now I'm wondering, how long should I wait before proposing Jelly for the commons proper? Or to put that another way; what needs to be done before Jelly could be moved to commons proper. Should things only move to commons proper when they are just about ready to release? I'd actually quite like Jelly to be under some pressure to get a 1.0 release out; though obviously I don't want us to rush things and cut corners. Any more thoughts on all this? My opinion: Get it ready for full 1.0 release. Then propose it for a top level Jakarta sub-project rather than a commons component. While Jelly certainly does seem like it fits within the commons charter, the community I perceive to follow it seems to have grown quickly and to a point where it is strong enough to stand on its own, rather than as a component within commons. If generaljakarta do not accept Jelly as a jakarta sub-project, then you can always come back to commons and request a move to commons proper. regards, michael -- To unsubscribe, e-mail: mailto:commons-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:commons-dev-help;jakarta.apache.org
Re: [VOTE] Promote NET to commons proper was Release Plans
-1. I think there should be more initial committers before it gets moved to commons proper. One of the reasons for the sandbox is to allow a component to build a community, I don't think the component has a large enough development community yet. regards, michael Waldhoff, Rodney wrote: The [VOTE] request should really contain a link to the proposal, e.g., http://jakarta.apache.org/commons/sandbox/net/proposal.html -Original Message- From: Juozas Baliuka [mailto:[EMAIL PROTECTED]] Sent: Monday, September 16, 2002 1:48 PM To: Jakarta Commons Developers List Subject: [VOTE] Promote NET to commons proper was Release Plans +1 - Original Message - From: Brekke, Jeff [EMAIL PROTECTED] To: 'Jakarta Commons Developers List' [EMAIL PROTECTED] Sent: Monday, September 16, 2002 8:15 PM Subject: RE: [NET] Release Plans No I think we should promote and work on those tasks post release. Not exactly sure how to start this process, just blast the list with an email? Someone up for it? = Jeffrey D. Brekke Quad/Graphics [EMAIL PROTECTED] http://www.qg.com -Original Message- From: Juozas Baliuka [mailto:[EMAIL PROTECTED]] Sent: Monday, September 16, 2002 1:04 PM To: Jakarta Commons Developers List Subject: Re: [NET] Release Plans Do you plan to compete some tasks in sandbox or can we start to vote for promotion ? OK, I've cobbled together the proposal xdoc from the original NetComponents description and other commons proposal docs. I've updated the task list and regen'd the site. = Jeffrey D. Brekke Quad/Graphics [EMAIL PROTECTED] http://www.qg.com -Original Message- From: Steve Downey [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 11, 2002 2:05 PM To: Jakarta Commons Developers List Subject: Re: [NET] Release Plans My understaning is that it should have a PROPOSAL.html, and that is what is voted on for the project to become a commons project. It's really mostly a cut and paste from one of the other, accepted, PROPOSALs in commons. I just checked the charter: # New packages may be proposed to the Jakarta Commons mailing list. To be accepted, a package proposal must receive a positive super-majority vote of the subproject committers. Proposals are to identify the rationale for the package, its scope, its interaction with other packages and products, the Commons resources, if any, to be created, the initial source from which the package is to be created, and the initial set of committers. 1. The whole number of positive votes needed for a super majority is calculated by dividing the total number of active subproject committers by four, multiplying by three, and rounding to the nearest whole number (= .5 rounds up). I don't know how many active commiters there are now. -- 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] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] Promote NET to commons proper was Release Plans
It's not now that I'm worried about. It's 3 months from now when that active user community is submitting tons and tons of bugs/feature requests, and the development community cannot keep up because of external time pressures. That's better managed with more committers. In any case, I'm only one vote. It's a majority decision, not a concensus. michael Juozas Baliuka wrote: It is true developer community is not very large, but I think user community is not so small, and I know they are waiting for release (I know two of them personaly). I can add myself to initial committers list, but I do not think it needs more committers at this time. -1. I think there should be more initial committers before it gets moved to commons proper. One of the reasons for the sandbox is to allow a component to build a community, I don't think the component has a large enough development community yet. regards, michael Waldhoff, Rodney wrote: The [VOTE] request should really contain a link to the proposal, e.g., http://jakarta.apache.org/commons/sandbox/net/proposal.html -Original Message- From: Juozas Baliuka [mailto:[EMAIL PROTECTED]] Sent: Monday, September 16, 2002 1:48 PM To: Jakarta Commons Developers List Subject: [VOTE] Promote NET to commons proper was Release Plans +1 - Original Message - From: Brekke, Jeff [EMAIL PROTECTED] To: 'Jakarta Commons Developers List' [EMAIL PROTECTED] Sent: Monday, September 16, 2002 8:15 PM Subject: RE: [NET] Release Plans No I think we should promote and work on those tasks post release. Not exactly sure how to start this process, just blast the list with an email? Someone up for it? = Jeffrey D. Brekke Quad/Graphics [EMAIL PROTECTED] http://www.qg.com -Original Message- From: Juozas Baliuka [mailto:[EMAIL PROTECTED]] Sent: Monday, September 16, 2002 1:04 PM To: Jakarta Commons Developers List Subject: Re: [NET] Release Plans Do you plan to compete some tasks in sandbox or can we start to vote for promotion ? OK, I've cobbled together the proposal xdoc from the original NetComponents description and other commons proposal docs. I've updated the task list and regen'd the site. = Jeffrey D. Brekke Quad/Graphics [EMAIL PROTECTED] http://www.qg.com -Original Message- From: Steve Downey [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 11, 2002 2:05 PM To: Jakarta Commons Developers List Subject: Re: [NET] Release Plans My understaning is that it should have a PROPOSAL.html, and that is what is voted on for the project to become a commons project. It's really mostly a cut and paste from one of the other, accepted, PROPOSALs in commons. I just checked the charter: # New packages may be proposed to the Jakarta Commons mailing list. To be accepted, a package proposal must receive a positive super-majority vote of the subproject committers. Proposals are to identify the rationale for the package, its scope, its interaction with other packages and products, the Commons resources, if any, to be created, the initial source from which the package is to be created, and the initial set of committers. 1. The whole number of positive votes needed for a super majority is calculated by dividing the total number of active subproject committers by four, multiplying by three, and rounding to the nearest whole number (= .5 rounds up). I don't know how many active commiters there are now. -- 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] -- 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] Promote NET to commons proper was Release Plans
On Tue, 17 Sep 2002, Martin Cooper wrote: I'm -0 because I'm not currently involved with [net]. If I was, I'd be -1. But I'd really hate to see us lower the barrier for Commons Proper components. Promotion to commons proper affects the entire commons, not just [net], so it shouldn't matter whether you are involved with [net] or not. michael -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [Collections] Naming conventions
On Sat, 15 Jun 2002, Stephen Colebourne wrote: I thought part of the aim of the Utils was to avoid having top level classes, even if they are package scoped. yeah, in a way. They coule also be looked at as convenience methods where you only need to import one class name to get all of the functionality rather than importing each that you need. The problem as I see it is that someone new to the package will come along and see maybe 60+ classes in the collections package. However, over half could be package scoped with no way to tell. (I reckon most people would scan the class names first, either as java files or javadoc.) By defining them as static nested classes (package scoped) we avoid the visibility issue. Joshua Bloch's book described it as reducing the 'conceptual size' of the API. I wouldn't want all 60+ classes in the collections package, even when package private. To start, I believe adding them as inner classes or non-public outer classes in the xUtils.java file would be a good starting point (hence they aren't exposed in javadoc or as .java files). Then, if a compelling need arises, we can make them public classes, but in a separate package (e.g. org.apache.commons.collections.decorators). regards, michael -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [Collections] Naming conventions
On Thu, 13 Jun 2002, Stephen Colebourne wrote:
What you describe does indeed compile, but isn't the proposal. The following
demonstrates (I hope) why they need to be package scoped.
public class CollectionUtils {
public static Collection predicatedCollection(Collection coll) {
return new PredicatedCollection(coll);
}
static class PredicatedCollection {
}
}
public class ListUtils {
public static List predicatedList(List list) {
return new PredicatedList(list);
}
static class PredicatedList extends PredicatedCollection {
}
}
got it... I thought I was missing something. :) didn't realize you were
referring to cross-xxxUtils inheritance. Yes, that would need to be
package private. I'm not sure that is such a big deal though.
I haven't fully digested this thread yet, but I'm inclined to agree with
you.
It is quite a lot to digest, but given the number of ideas that are floating
about, we do seem to need it. There could be some work for the committers to
manage the patches etc. for any renaming however!
yup... believe me, I know... I'm still trying to manage the patches
Paul sent in for the new testing framework... :)
michael
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [Collections] Naming conventions
On Thu, 13 Jun 2002, Jonathan Carlson wrote: I personally like the Lists, Sets, Collections, etc naming, too. We could put pass-through methods to java.util.Collections on the commons.Collections class. That way we can have our cake and eat it too. too implies that Stephen was infavor of Lists, Sets naming, but in that same email: After a little thought, I think I favour adding Utils to all of the above. ;) The only people that would have to use the whole path name would be those who import java.util.*. And I, personally, think that is a sloppy convention anyways because it makes it very difficult on new Java developers trying to learn a system, in addition to Sun's suggestions against it. This next idea would be a last resort, but we could come up with an automatic java.util import generator for those java.util classes used in the class. It would be relatively easy to do with regular expressions and the BeanShell. Too much work for users. I will -1 an org.apache.commons.collections.Collections class. regards, michael -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [Collections] Naming conventions
On Thu, 13 Jun 2002, Jack, Paul wrote: I'm even okay with the wrapper classes being package-protected OUTER classes defined in the same source file. Having package-protected classes still gives us a lot of leeway with organizing things, as technically users shouldn't be using package-protected methods and classes. we could even make them public classes and allow users to extend them on their own (using the XXXUtils.whatever methods as convenience methods) After a little thought, I think I favour adding Utils to all of the above. Results in no clashes with Java, and just involves adding methods to ListUtils, CollectionUtils and MapUtils. One other consideration is that ListUtils is deprecated. We could always un-deprecate it, of course. I'd want to manually deprecate each method currently in the class though, but that doesn't seem like a big deal. nope... not a big deal. Since you said it though, why would you still want to deprecate each method? It seems like summing two lists and returning a List might still be beneficial rather than using a collection method that returns a Collection. A user shouldn't assume that the returned collection from CollectionUtils is really a List (even if it is at the moment). Maybe Rodney (if he's even listening and remembers) can provide some insight as to why he deprecated it a year ago. But otherwise, I think having: BagUtils CollectionUtils ComparatorUtils IteratorUtils ListUtils MapUtils PredicateUtils SetUtils TransformerUtils TreeUtils is all good. I'd like FactoryUtils to be SimpleObjectFactoryUtils, which is a very long name but more consistent with the others. FactoryUtils could still be used. Then, if later we add another type of factory (I have *no* idea what though), we can keep all the factory methods in FactoryUtils. And actually, we could rename SimpleObjectFactory to just plain Factory. I tried looking back at the discussion to understand why it wasn't. Here's a review. Originally, Factory was proposed and had some support: http://nagoya.apache.org/eyebrowse/ReadMsg?[EMAIL PROTECTED]msgNo=7348 Then, Stephen brought up an interesting point about how different people define a factory in different ways (e.g. by having the factory method take a parameter), but this still used the Factory name: http://nagoya.apache.org/eyebrowse/ReadMsg?[EMAIL PROTECTED]msgNo=7366 It wasn't until Aaron Bates, the person that proposed the Lazy collections in the first place, put his code up on the web: http://nagoya.apache.org/eyebrowse/ReadMsg?[EMAIL PROTECTED]msgId=338897 And, of course, She/He who does the work, wins But that doesn't mean we can't do more work and rename it. I didn't really see any arguments against naming it Factory rather than SimpleObjectFactory On method names, I agree with your implicit use of yyyedXxx, eg. filteredMap or predicatedSet This is all sounding dangerously close to consensus! I think this is probably the only civilized conversation on naming conventions I've ever had... :) :) regards, michael -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [CLI] multiple args
On Fri, 14 Jun 2002, bob mcwhirter wrote: I want to allow multiple -D options, and have them anywhere in the command-line. Right now, that's interp'd as maven -D maven.username=werken -D maven:deploy-site Which is wrong. Workaround is reordering the command-line: maven maven:deploy-site -D maven.username=werken Seems like an arbitrary restriction. Any thoughts on how to hack in multiple-instances-single-arg options without adding yet-another-boolean-parameter to all of the signatures? How about an end-of-list marker: maven -D macen.username=werken -- maven:deploy-site regards, michael -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: I need karma
While you're granting karma, can you give me karma to the sandbox? I've wanted to apply people's patches to sandbox code and I've had a few myself, so I asked once before but it never happened. thanks, michael On 12 Jun 2002, Jason van Zyl wrote: On Wed, 2002-06-12 at 18:19, bob mcwhirter wrote: Crap. Likewise, I probably need commons karma for CLI since it exited the sandbox. Done. -bob On Wed, 12 Jun 2002, Jon Scott Stevens wrote: I need karma for the betwixt project now that it has moved over to commons from sandbox. -- 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] Naming conventions [was ComparableComparator -nulls OK]
On Wed, 12 Jun 2002, Stephen Colebourne wrote: If we do this right, some of the current top level classes (eg.iterators) could be deprecated and become merged into a factory style class, to the benefit of the interface size. Well thats my input (sorry for the long email!). We could really do with an agreement on this ;-) Note all these changes can be made as none affect released classes. I was a bit unsure that such a reorganization would not affect released classes, mainly because I had forgotten what was in the 2.0 release and what has been added since then. To help figure that out, I went through all the classes and added @since tags for all the released classes. I didn't have enough minutes this evening to figure out what the compability impact really would be though. Btw, no apologies needed for the long email. You've expressed a lot of great ideas; ones which I hope we will be able to implement so users will have an easier time using the code that we provide. regards, michael -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [Collections] ReadOnly Collection decorators
On Mon, 10 Jun 2002, Jonathan Carlson wrote: I'd really like to see some ReadOnly Collection decorators for all of the Collection and Iterator interfaces and subinterfaces. When I return a collection or iterator from a framework I don't want to trust that no one will modify those collections if they represent something internal. Using these have protected me from even my own carelessness at least once. I have written a few already that I could share (Set, List, Map, Iterator etc) but they don't subclass the commons collections Proxy* classes (see my previous note on the naming of these), which they probably should do if they are to be included. Thoughts anyone? Most of these already exist in the JDK: java.util.Collections.unmodifiableCollection(Collection) java.util.Collections.unmodifiableList(List) java.util.Collections.unmodifiableMap(Map) java.util.Collections.unmodifiableSet(Set) java.util.Collections.unmodifiableSortedMap(SortedMap) java.util.Collections.unmodifiableSortedSet(SortedSet) the only thing missing would be an unmodifiable bag, sorted bag, and iterator. regards, michael -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH][Collections] New testing framework, patch #1
Sorry its taken so long to review your patches. Now that I've had the chance, I wish I was able to take a look sooner. On Thu, 30 May 2002, Jack, Paul wrote: Okay, so the goal was to be able to modularize the tests in such a way that objects that return a collection or map could have those return values tested using TestMap, TestCollection etc. right. How I decided to handle that was to create a new implementation of junit.framework.Test, that allows you to specify bulk test methods in addition to the usual simple test methods: I'm agreeing with your intent here (i.e. the addition of the bulk test methods), however I disagree with reimplementing Test. My main objection is that you are reimplementing parts of JUnit and missing some of the functionality that it provided. Namely, the ability to extract the testing hierarchy. While the hierarchy isn't readily visible when run using the textui (the junit test runner that's run automatically as part of the commons build), it is useful to have when using JUnit's swing UI. I'd really like to be able to see a hierarchy that looks something like this: TestAll TestArrayIterator ... TestSequencedHashMap testMapGet ... testYoungest testYoungestReplaceNullWithValue entrySet testSize testFoo testBar keySet testSize testFoo testBar ... TestFastArrayList testSearch testNewArrayList subList testFoo testBar You've put a lot of work into getting these tests up and running, and it has exposed some problems with existing implementations, so your work isn't without merit. In fact, I'm inclined to commit it, I would just rather see something that utilizes JUnit's TestSuite (by subclass probably since it doesn't support bulkTest) so that a proper test hierarchy can be built. Therefore, I'm going to hold off a little bit to see if any other collections committers care to comment on the above. regards, michael -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [COLLECTIONS/BEANUTILS] Is there a comparator that can dynamicallypick a method to call on a bean?
On Fri, 7 Jun 2002, Henri Yandell wrote: Sorry Eric, I'm not sure you got my question. BeanComparator = good, +1. I think it'd be great to commit a BeanComparator. The ASC/DESC bit is unnecessary I think due to ReverseComparator. This is an opinion though, I don't believe in ASC/DESC in Comparators. So I was just -1 on the Polarity part of your BeanComparator :) Morgan or Michael may want to veto that though :) Neither of us can veto your veto. We can try to twist your arm, but in this case, I have no reason to: I agree with you. The reverse comparator can provide the complementary ascending or descending behavior. regards, michael -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [VOTE] move Betwixt into commons proper (was Re: Betwixt MethodUpdaters)
+1 on moving Betwixt into commons proper. On Wed, 5 Jun 2002, James Strachan wrote: - Original Message - From: Jason van Zyl [EMAIL PROTECTED] It now looks like the bugs have been squashed so how about we propose to move Betwixt up to the commons proper and do a release? Sounds good with me. Lets do it in 2 stages, move to commons proper first, then leave it a couple of days to check that noone can find any more bugs, then lets call another vote to release it. So here's the first vote, to move betwixt to commons proper. Already there's 4 developers and several projects using betwixt so I think it passes all the conditions. http://jakarta.apache.org/commons/sandbox/betwixt/developer-list.html I'm +1 James _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] Re: Betwixt MethodUpdaters, James Strachan Re: Betwixt MethodUpdaters, Jason van Zyl [VOTE] move Betwixt into commons proper (was Re: Betwixt MethodUpdaters), James Strachan Re: [VOTE] move Betwixt into commons proper (was Re: Betwixt MethodUpdaters), Geir Magnusson Jr. Re: [VOTE] move Betwixt into commons proper (was Re: Betwixt MethodUpdaters), Michael A. Smith Re: [VOTE] move Betwixt into commons proper (was Re: Betwixt MethodUpdaters), Jon Scott Stevens RE: [VOTE] move Betwixt into commons proper (was Re: Betwixt MethodUpdaters), Vincent Massol Re: [VOTE] move Betwixt into commons proper (was Re: Betwixt MethodUpdaters), Craig R. McClanahan Re: [VOTE] move Betwixt into commons proper (was Re: Betwixt MethodUpdaters), robert burrell donkin -- Chronological -- -- Thread -- [EMAIL PROTECTED]"> Reply via email to [VOTE] move Betwixt into commons proper (was Re: Betwixt MethodUpdaters), James Strachan Re: [VOTE] move Betwixt into commons proper (was Re: Betwixt MethodUpdaters), Geir Magnusson Jr. Re: [VOTE] move Betwixt into commons proper (was Re: Betwixt MethodUpdaters), Michael A. Smith Re: [VOTE] move Betwixt into commons proper (was Re: Betwixt MethodUpdaters), Jon Scott Stevens RE: [VOTE] move Betwixt into commons proper (was Re: Betwixt MethodUpdaters), Vincent Massol Re: [VOTE] move Betwixt into commons proper (was Re: Betwixt MethodUpdaters), Craig R. McClanahan Re: [VOTE] move Betwixt into commons proper (was Re: Betwixt MethodUpdaters), robert burrell donkin -- Chronological -- -- Thread -- [EMAIL PROTECTED]"> Reply via email to Re: [VOTE] move Betwixt into commons proper (was Re: Betwixt MethodUpdaters), Geir Magnusson Jr. Re: [VOTE] move Betwixt into commons proper (was Re: Betwixt MethodUpdaters), Michael A. Smith Re: [VOTE] move Betwixt into commons proper (was Re: Betwixt MethodUpdaters), Jon Scott Stevens Re: [VOTE] move Betwixt into commons proper (was Re: Betwixt MethodUpdaters), dion Re: [VOTE] move Betwixt into commons proper (was Re: Betwixt MethodUpdaters), Ivelin Ivanov Re: [VOTE] move Betwixt into commons proper (was Re: Betwixt MethodUpdaters), James Strachan [Betwixt] what's the plan?, robert burrell donkin Re: [Betwixt] what's the plan?, James Strachan Re: [Betwixt] what's the plan?, Martin van den Bemt Re: [Betwixt] what's the plan?, James Strachan Re: [Betwixt] what's the plan?, robert burrell donkin Re: [VOTE] move Betwixt into commons proper (was Re: Betwixt MethodUpdaters), Ivelin Ivanov -- Chronological -- -- Thread -- [EMAIL PROTECTED]"> Reply via email to <!-- google_ad_client = "pub-7266757337600734"; google_alternate_ad_url = "http://www.mail-archive.com/blank.png"; google_ad_width = 160; google_ad_height = 600; google_ad_format = "160x600_as"; google_ad_channel = "3243237953"; google_color_border = "CE9689"; google_color_bg = ["FF","ECE5DF"]; google_color_link = "006792"; google_color_url = "006792"; google_color_text = "00"; //--> Re: [VOTE] move Betwixt into commons proper (was Re: Betwixt MethodUpdaters) Geir Magnusson Jr. Re: [VOTE] move Betwixt into commons proper (was Re: Betwixt MethodUpdaters) Michael A. Smith Re: [VOTE] move Betwixt into commons proper (was Re: Betwixt MethodUpdaters) Jon Scott Stevens Re: [VOTE] move Betwixt into commons proper (was Re: Betwixt MethodUpdaters) dion Re: [VOTE] move Betwixt into commons proper (was Re: Betwixt MethodUpdaters) James Strachan [Betwixt] what's the plan? robert
RE: [PATCH][Collections] further testing code for Maps
On Wed, 29 May 2002, Jack, Paul wrote: Will do -- But what should I do about any new source files I need to include? Right now I'll plan on attaching the cvs diff as one text file, and including any new source files as a separate attachment. There's some hack you can do to get the new file added as part of the patch, but I can't remember what it was. Unless you can figure it out (maybe someone else on the list knows -- anyone?), attaching the new file(s) along with the patch to existing files would be fine. Also, would it be easier for you to deal with a series of smaller incremental patches, or should I just submit one big colossal patch when I've finished? Smaller incremental self-contained patches are usually easier. regards michael -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH][Collections] further testing code for Maps
On Fri, 24 May 2002, Jack, Paul wrote: I completed all the TODO and XXX items in TestMap. Some of the Map implementations (notably MultiHashMap) intentionally violate the Map contract, so I overrode some of the new methods in concrete TestMap subclasses. This 3-day weekend is now coming to a close, and I haven't gotten nearly as much accomplished as I would have hoped. I have, however, gotten a chance to review the patch to the testing code. In a second or two, I'll be committing your patch with the following modifications: - Wrapped some long lines to fit within 80 columns. - Added javadoc documentation to the new methods. - In testEntrySetContainsAll(), moved the containsAll check inside the loop to check after each expected item is added to the collection argument. - In testEntrySetRemove2(), changed the notAKey and notAValue to a real key and real value as returned from getKeys and getValues, but executed the test on an empty map. Otherwise, a type specific map that may be added in the future may throw a class cast or other exception because the key and/or value are not of the appropriate type. Similar changes were made elsewhere for the same reasoning as described below. - In testMapGet, I made sure the value is still being returned correctly when the value in a mapping is null rather than just ignoring mappings to null values. - Uncommented the toString() method you added, but changed it to be valid for all maps (i.e. do as much checking as possible considering the format of the string returned from toString is not defined.) - In testMapPut, changed your hardcoded key (1) and value (One) to be those returned from getSampleKeys and getSampleValues. For the second put, I used the values from getNewSampleValues. - In testMapPutAll, changed hardcoded values to those from getSampleKeys and getSampleValues. - In testMapRemove, changed hardcoded values to those from getSampleKeys. - I didn't take much for testMapValues because the values within a collection are not necessarily sortable. Instead, I rewrote it to compare the collections in a different way. This change allowed a test of the BeanMap.values() method rather than overriding it to not test anything. - In TestDoubleOrderedMap, clarified the documentation of the overridden test. - In TestMultiHashMap, added TODO for reimplementing the tests to ensure the values are appropriate collections rather than just ignoring the tests altogether. There is still some work to be done in that keySet() and values() collection views are inadequately tested. definately. The testing approach in TestMap doesn't extend well. That is, if another collection returns a map, there's no easy way to use the same testing code to test the returned map. In other words, if we use the same approach in TestMap for TestList and TestSet, etc., then that testing code can't be reused to test the collection views of Map. Long term, I'd want to see a much more flexible mechanism for testing collections that can be reused to test small-collection views of larger collections. If only there where 48 hours in a day. Thanks, Paul, for taking the time to fill in these extra test methods! regards, michael -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH][Collections] further testing code for Maps
On Fri, 24 May 2002, Jack, Paul wrote: I completed all the TODO and XXX items in TestMap. Some of the Map implementations (notably MultiHashMap) intentionally violate the Map contract, so I overrode some of the new methods in concrete TestMap subclasses. very cool! More tests are definately a good thing. I'm hoping to have time this weekend, and I've put this at the top of my list. regards, michael -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [PATCH][Collections] SequencedHashMap: equals, hashCode, toString
On Fri, 24 May 2002, Jack, Paul wrote: Extending AbstractMap is not the right way to add an equals, hashcode and toString method. I just committed real implementations for the methods. Was there something wrong with AbstractMap's implementations, or did you just want to keep SequencedHashMap's superclass as Object? I'm just wondering if there's something my unit tests aren't catching... Just wanted to keep the superclass as Object. I suppose it doesn't make that much of a difference really, so my statement on it being not the right way is probably a bit harsh. Sorry about that. :) regards michael -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH][Collections] SequencedHashMap: equals, hashCode, toString
On Thu, 23 May 2002, Jack, Paul wrote:
Index: SequencedHashMap.java
===
RCS file:
/home/cvspublic/jakarta-commons/collections/src/java/org/apache/commons/coll
ections/SequencedHashMap.java,v
retrieving revision 1.9
diff -r1.9 SequencedHashMap.java
100c100
public class SequencedHashMap implements Map, Cloneable, Externalizable {
---
public class SequencedHashMap extends AbstractMap implements Map,
Cloneable, Externalizable {
Extending AbstractMap is not the right way to add an equals, hashcode and
toString method. I just committed real implementations for the methods.
regards,
michael
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [ committer vote ] - for an extra committer...
On Fri, 24 May 2002, Arron Bates wrote: Already a committer on the Struts project, wodering if the committers of the commons would allow an extra hand for the project?... Submitted a few patches commons for BeanUtils, and now would like to contribute some handy collection wrappers. Anyways, find myself wandering back into commons realm to get some things done, and figure an extra hand to watch the flock wouldn't be a bad thing. +1 PS: How bad do I need to sell myself for this?... well... ...yesterday, circa 12:45pm, I happily became a legend in my own lunch-time... huh? michael -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: PATCH : org.apache.commons.collections.SoftRefHashMap
On Tue, 21 May 2002, christopher marshall wrote:
It doesn't seem as if anyone has submitted this patch into the CVS
repository for testing... Is this any way to encourage new participants?
we're all volunteers here. I can only speak for myself, but I've been
extremely busy and haven't had much time for anything lately. However,
here's a quick review of your mail:
Please let me know if this is OK as I haven't submitted code before.
patches are preferred. See the bottom section of this document:
http://jakarta.apache.org/site/source.html
see also:
http://jakarta.apache.org/site/getinvolved.html
Patches fix the SoftRefHashMap so that the entrySet() and values()
methods are backed by the underlying map and the keys whose referent-values
have been cleared will be automatically (and performant-ly) purged upon
writes to the map. I have deprecated the purge() method and
re-implemented
it to call processQueue(), which is a more performant way of purging the
Map as it goes straight to the cleared values without iterating through the
whole Map.
Having the entrySet and values collections backed by the map is probably a
good thing. As for the purge stuff, I don't know what your motivation is
here. performant isn't in my trusty on-line dictionaries:
http://www.dictionary.com/search?q=performant
http://www.m-w.com/cgi-bin/dictionary?performant
Are you saying it has better performance? That's probably good as well.
The Map also has the new method getIfAbsentPut(Object key, ObjectFactory
fac) which takes a new paramter of type
org.apache.common.collections.ObjectFactory (an Interface). It aids the use
of this map as a cache (see below).
In my opinion, this is not appropriate to add to the SoftRefHashMap. If
you want such functionality, add it in a subclass
I feel that the idea to extend the class with createReference()
overimplemented is a bad one, and have removed the functionality. Among
other things, it is difficult to see how this would be implemented here
without unnecessary complications - considering the functionality is
questionable (to extend SoftRefHashMap to actually be a WeakRefHashMap?) I
think that this is justified.
well, I don't. You're removing functionality and if you just removed the
method, you're breaking backwards compatibility. what unnecessary
complications are you talking about? Just a possible misleading super
class? How else is this functionality questionable?
The idea of Object factory is so that the Map can be used effectively as a
Cache; suppose that a User wishes to store (expensively retrieved) database
entries in the Map which must always be retrieved (whether the referent
value has since been GC-ed or not). The user code looks like
//
public UserObject apiGetUser(final String userId) {
return (UserObject) map.getIfAbsentPut(userId, new ObjectFactory() {
public Object create() {
//expensive database access to return the
//required Object
Object user = expensiveDBAccess( userId );
return user;
}
});
}
//
The ObjectFactory.create() will only be invoked (and the expensive
operation
executed) should the value have been cleared from the Map (ie. GC-d). The
factory method will be invoked and the Object stored in the map for the
key.
this isn't necessary. The SoftRefHashMap can do this without
modification.
UserObject obj = (UserObject)map.get(userId);
if(obj == null) {
obj = expensiveDBAccess(userId);
map.put(userId, obj);
}
The only thing you might gain from the object factory thing is to remove
possible code duplication if you're doing these map.get things in various
places in your code. But in that case, I'd recommend you create a
separate object that stores your user information and handles this under
the covers. For example:
public class UserCache {
private SoftRefHashMap map = new SoftRefHashMap();
public UserObject getUserObject(String userId) {
UserObject obj = (UserObject)map.get(userId);
if(obj == null) {
obj = expensiveDBAccess(userId);
map.put(userId, obj);
}
}
}
or as a direct subclass:
public class UserCache extends SoftRefHashMap {
public Object get(Object key) {
Object o = super.get(key);
if(o == null) {
o = expensiceDBAccess(key);
map.put(key, o);
}
}
}
regards,
michael
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Are FastArrayList/FastHashMap broken (unthreadsafe)
On Fri, 17 May 2002, christopher marshall wrote: I have just been looking through the source code to the classes org.apache.commons.collections.FastHashMap and org.apache.commons.collections.FastArrayList - these classes seem totally broken to me because they are designed for use within a multi-threaded environment but are not threadsafe within the definition of the Java memory model. They're not *totally* broken. Just not really thread safe in highly optimized runtimes. I accept that presumably these classes have been pored over by minds superior to my own, but here is my reasoning: Firstly, the internal fast boolean is not volatile, hence 2 separate Threads may be of a different opinion as to whether the Map/List is running in fast mode or not (If a primitive variable is non-volatile, the JVM is entirely free to read the value from Thread-local memory). This is a known issue. Even with the volatile keyword, it's not thread safe. See: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7924 Secondly, even if 2 threads agree that the Map/List is running in fast mode, the Java memory model doesn't guarantee that non-synchronized changes will be visible across multiple Threads (because synchronization acts as a main-memory barrier). Since access to the Map/List via the get() method is not synchronized in fast mode, but will be to the put()/add() methods, it isn't clear that a Thread performing just reads will see changes an arbitrary amount of time after they have actually happened. If you don't think the fix for bug 7924 will solve this issue, then file a separate bug for it. P.S. Apologies if this is directed at the wrong mailing list - this is my first contribution. This is the right place... regards, michael -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: SoftRefHashMap isn't a pure implementation of Map - I'd like tocontribute one
On Fri, 17 May 2002, christopher marshall wrote: Again you may have to excuse my naivety. The org.apache.common.collections.SoftRefHashMap is not a pure implementation of the java.util.Map interface, because the collections returned by the values() and entrySet() methods are not backed by the underlying Map. I also believe that the SoftRefHashMap is flawed as keys will not be automatically be reclaimed when their value-referents are cleared - the user has to manually invoke the purge() method. I have written an implementation of Map (SoftValueHashMap) which is a pure implementation of the java.util.Map interface and which purges itw own keys automatically. Also it has a getIfAbsentPut(Object key, ObjectFactory fac) method, which is very useful for cache-ing purposes (it is unlikely that a Cache will want to return null just because an underlying value has been de-referenced etc). I think we'd much rather have the existing SoftRefHashMap patched to be correct. I wish to contribute this code to Apache Commons Collections and have been looking on the Apache site to see how this is done by a new developer. Unforunately I can't find the information. Could someone please tell me the etiquette to be followed (presumably I email my source code to an Admitter who puts it in the nightly-release CVS repository. other than fixing the above mentioned problems, how different is it? Could you just patch the existing version? Anyway, the correct procedure is to submit it here (preferrably as a patch with the subject prefixed with [PATCH]). See also: http://jakarta.apache.org/site/getinvolved.html http://jakarta.apache.org/site/source.html regards, michael -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Are FastArrayList/FastHashMap broken (unthreadsafe)
On Fri, 17 May 2002, Jack, Paul wrote: I have just been looking through the source code to the classes org.apache.commons.collections.FastHashMap and org.apache.commons.collections.FastArrayList - these classes seem totally broken to me because they are designed for use within a multi-threaded environment but are not threadsafe within the definition of the Java memory model. They're not *totally* broken. Just not really thread safe in highly optimized runtimes. Insofar as Java code is supposed to be cross-platform, the fact that the code isn't really thread safe in highly optimized runtimes really does mean it's totally broken. not totally broken because there are certain use-cases where this probably isn't an issue. For example, not ever modifying the collection once it is in fast mode. Furthermore, the code won't work in non-highly optimized runtimes either. The instructions that clone the internal collection and the instructions that store the reference to the clone can be done or percieved out-of-order because of optimizing compilers or processor pipelines. A thread invoking a read operation might raise all sorts of unexpected RuntimeExceptions because the clone() of a write operation hasn't finished yet. In theory this could happen even on single-processor JIT environments (though to be fair I've only ever tested the code on single-processor 386-based chips, where everything seems to work just fine). We've already had this discussion: http://marc.theaimsgroup.com/?l=jakarta-commons-devm=101838955101424w=2 and (although in a different context), I've already pointed out the reordering corruption possibility: http://marc.theaimsgroup.com/?l=jakarta-commons-devm=101901975914794w=2 ... If you don't think the fix for bug 7924 will solve this issue, then file a separate bug for it. It's a separate issue, and there should be a separate bug. However, there is no way to fix the bug: The Fast collection classes cannot behave as advertised and be cross-platform, given the current Java Memory Model. So are you saying your patch won't work? http://marc.theaimsgroup.com/?l=jakarta-commons-devm=101953795432669w=2 :) That patch is still on my radar. I just haven't had the chance to do anything with it yet. I've been swamped with too many other things. regards, michael -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [OT] RangeIterator
On Mon, 13 May 2002, Oliver Fischer wrote: some days ago I posted my RangeIterator after a short discussion. Unfortunately I didn't get any positiv or negativ response on it. Did someone look at it? Oliver, This message from Paul Jack and the included quoted message from James Strachan summarize the conclusions from the discussion (at least from my viewpoint): http://www.mail-archive.com/commons-dev@jakarta.apache.org/msg06457.html In other words, I don't think the RangeIterator provides enough new functionality over the existing FilterIterator to warrant its addition. regards, michael -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [GUMP] Build Failure - commons-util
Jon, Can you please fix gump's commons-util build? You broke it. If not, I'm going to back out your change to build.xml. thanks, michael On Wed, 1 May 2002, Michael A. Smith wrote: On 1 May 2002, Ted Husted wrote: This email is autogenerated from the output from: http://jakarta.apache.org/builds/gump/2002-05-01/commons-util.html Buildfile: build.xml BUILD FAILED Target `dist' does not exist in this project. Total time: 4 seconds Gump was last able to build commons-util on 4/29: http://jakarta.apache.org/builds/gump/2002-04-29/commons-util.html On April 30th, Jon maven'ized commons-util: http://cvs.apache.org/viewcvs.cgi/jakarta-commons-sandbox/util/build.xml Jon, would you please fix either the build file or gump's build descriptor so that gump can build commons-util? thanks, michael -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [GUMP] Build Failure - commons-util
On 1 May 2002, Ted Husted wrote: This email is autogenerated from the output from: http://jakarta.apache.org/builds/gump/2002-05-01/commons-util.html Buildfile: build.xml BUILD FAILED Target `dist' does not exist in this project. Total time: 4 seconds Gump was last able to build commons-util on 4/29: http://jakarta.apache.org/builds/gump/2002-04-29/commons-util.html On April 30th, Jon maven'ized commons-util: http://cvs.apache.org/viewcvs.cgi/jakarta-commons-sandbox/util/build.xml Jon, would you please fix either the build file or gump's build descriptor so that gump can build commons-util? thanks, michael -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Checkstyle and RuntimeExceptions
On Tue, 30 Apr 2002, Steve Cohen wrote: In Joshua Bloch's Effective Java he makes a point of stating that writers of Javadoc comments should be ESPECIALLY interested in documenting runtime exceptions that are NOT listed in the throws clause (as in fact, they're not required to be). Makes good sense to me, since you're not required to list these, how else are you going to warn users of your class that such may be thrown? However, the default settings of CheckStyle, at least those in use in the commons/sandbox/net project, seem to militate against doing this. Document a runtime exception that may be thrown without putting it in the throws clause and you'll get one of these errors: Unused @throws tag for 'IllegalArgumentException'. Is this setting really the way we want it to be? This is a bug in checkstyle. I filed a bug report at the beginning of April: http://sourceforge.net/tracker/index.php?func=detailaid=540382group_id=29721atid=397078 regards, michael -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [patch] typo in commons-deamon's doc
On Thu, 25 Apr 2002, Anton Brazhnyk wrote: there is a typo in jakarta-commons-sandbox\daemon\src\docs\daemon.html I just tried committing this patch (thanks Anton!), but I can't because I have insufficient karma. Can someone with the appropriate admin abilities add me as a committer in the commons sandbox? thanks, michael -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [SUBMIT] OptimizedFastArrayList
On Tue, 16 Apr 2002, Jack, Paul wrote: Attached is a new List implementation inspired by but faster than FastArrayList. From the javadoc: Is there any external behavior difference between FastArrayList and your OptimizedFastArrayList (other than performance)? If so, can you explicitly specify the differences and why? If not, is there a reason not to just replace the existing FastArrayList with the faster implementation? Read access to this list is not synchronized, but write access is. To pull this trick off, the state of the list is cloned during a write, the changes are applied to the clone, and then the clone replaces the list's state. Read operations use a local reference to the old state, and are not adversely affected by a write. This is similar to org.apache.commons.collections.FastArrayList. is it me, or does this behavior suffer from the double checked locking problem? While this isn't the exact same scenario (i.e. the double checking of a variable one in and one outside a synchronized block), I believe the situation is the same: it is possible that a non-synchronized read can see the cloned object before that cloned object is fully created. For more information on the double checked locking, see this excellent writeup: http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html Other writeups: http://www.javaworld.com/javaworld/jw-02-2001/jw-0209-double.html http://www.javaworld.com/javaworld/jw-05-2001/jw-0525-double.html The JSR for fixing the Java memory model: http://jcp.org/jsr/detail/133.jsp [Paul, I don't mean to pick on you about this. The existing Fast* classes suffer from the exact same problem] However, since the list is backed by a dynamic array, *many of the algorithms that alter the list already require that the state be cloned*. For instance, to remove an element, a new array must be allocated, and the elements from the old array (minus the removed object) must be copied to the new array. FastArrayList essentially performed the cloning twice: It first clones the entire list, and then performs the costly remove() operation on the copy. This implementation is optimized such that a new array is only allocated once. Assuming no monitor contention, this class should perform similarly to java.util.ArrayList, except for the add(Object) and set(int, Object) methods, which now perform in linear time. Actually, if the ArrayList implementeds were smart, they aren't cloning the array each time, they are just adding the element in an existing, but empty, slot in the array. That is, the underlying array is possibly larger than ArrayList.size(). An add(Object) only needs to duplicate the array if the existing array is full. An add(int, Object) may need to move elements, but shouldn't need to clone the entire array. The actual cloning of the array (to grow or shrink the size) can have an amortized constant time operation if the the array is doubled when a grow is required (and if you add in the shirnking, which I don't think the JDK impl does, you would halve the size of the array when it is 1/4 full). In your version, you may even be able to get rid of the single clone using a similar technique. For example, if you are adding to the end (add(Object)), if the array already has room for one more element, you could just increase the size and create a new State rather than a new State *and* a new array. When removing the last element, use the same array, but create a new State with the smaller size. I'm not sure if that really buys much though, as it requires excess memory for the empty array elements that are only used if an add operation occurs sometime in the future. Considering that the underlying ArrayList impl uses that memory anyway, I'm not sure this is that big of a deal when considered as a replacement of FastArrayList. regards, michael -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Insert error
On Mon, 15 Apr 2002, bahaa azami housni wrote: I try to Insert in an access table and I receive this error: what can I do ? The Jakarta Commons mailing list is not the appropriate place to post such a question. Please read: http://jakarta.apache.org/site/mail.html (especially the section entitled Join the lists that are appropriate for your discussion.) I doubt there are any Jakarta mailing lists that are appropriate for a generic JDBC/SQL question such as yours. regards, michael -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: FastArrayList, FastHashMap, FastTreeMap not thread safe
On Tue, 9 Apr 2002, Jack, Paul wrote: List and Map objects can return views on their contents that can be modified. For instance, elements can be removed from an ArrayList via its iterator(). Elements can be removed from a map via its keySet() or its values() collection. A TreeMap can also return a submap that can be modified. Generally, changes on a view of a collection are reflected in the original and vice-versa. The problem is, with FastArrayList or FastHashMap, in fast mode, if somebody tries to modify a collection view (say, a keySet() of a FastHashMap) they will never enter the FastHashMap's monitor. The state of the FastHashMap can become corrupted if more than one thread attempts to modify its keySet(); and threads attempting a fast get(Object) on a FastHashMap while another thread modifies its keySet() may get faulty data back. Can you file this as a bug? That way we can be sure to track it. http://nagoya.apache.org/bugzilla/ I'd recommend using the unmodifiable methods of the java.util.Collections class to make the collection views immutable. This would solve the problem, but technically violate the contract of java.util.Map and java.util.List (which specify that views on a map or list must support all operations the original map or list supported). Unfortunately, making it unmodifiable is a non-baskwards compatible change. There may be users out there that are relying on the returned views being modifiable. It shouldn't be too difficult to synchronize properly in the returned views -- just requires some time to actually work on it. regards, michael -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [logging] Need interface...
I'm trying to stay out of this debate, but I just can't let this go by:
On Wed, 3 Apr 2002 [EMAIL PROTECTED] wrote:
I'm thinking as:
class MyClass implements LogUser {
// default logger
private static Logger logger = Log.getLogger(MyClass.class);
public void setLogger( Log log ) {
// should really fail-fast if a null logger is provided rather
// than have logging statements fail at some unknown point in
// the future.
if(log == null) throw new NullPointerException(null log);
logger=log;
}
...
if( logger.isDebugEnabled() ) logger.debug(Something );
}
yeah, I know it was just pseudo-code. :)
regards,
michael
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [logging] Need interface...
On Wed, 3 Apr 2002 [EMAIL PROTECTED] wrote:
Again - I have doubts about how this will work for apps with multiple
loggers, but the idea of supporting both push and pull is valid.
One method of supporting multiple loggers is to specify a LogFactory
rather than a log. The component can then call the specified factory to
retrieve a log instance to its liking. And if the container wants the
component to use one and only one logger, it can provide a LogFactory to
the component that will always return the same Log instance.
E.g.
public interface LogUser {
void setCommonsLogFactory(LogFactory factory);
}
regards,
michael
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: PROPOSAL: new 'wrapper' commons component
On Wed, 3 Apr 2002, Scott Sanders wrote: Could we replace daemon with this if this is the case. Daemon is slightly more descriptive than wrapper IMHO. +1 either way. I'm agreeing with Scott here. If Remy (one of the three people listed as an initial committer to daemon) says wrapper has more features and he's giving his +1, then we should just replace the daemon component with wrapper (I like the daemon name better anyway). No vote is necessary to modify replace the sandbox daemon with wrapper. If you want to skip the sandbox and go directly to commons component, I'd be okay with that (+1) if it was renamed. Wrapper is a bit too generic for me. michael Scott -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 02, 2002 11:39 PM To: Jakarta Commons Developers List Subject: Re: PROPOSAL: new 'wrapper' commons component Hi, I would like to propose a new common component, based on code used in tomcat, avalon and other java servers to work as NT services and unix daemons. The initial code is based on the wrapper project at sourceforge, and will replace ( and be merged with ) the other components that duplicate the same functionality ( daemon, jk_nt_service, etc). Attached is the proposal, please send your votes. +1. 'wrapper' has more advanced features than all the other service wrappers currently used @Jakarta (or elsewhere). Remy -- 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] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Latka Questions
On Thu, 21 Mar 2002, James CE Johnson wrote: I've been looking at latka as a testing framework for our application and have some specific questions that I can't find the answers to. Would this be the best place to ask? yup. regards, michael -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [Collections] non-compatible changes
On Thu, 21 Mar 2002, Morgan Delagrange wrote: 3. BeanMap.values() is modifiable, but modifications are not reflected in the BeanMap. Probably should return an unmodifiable collection. 4. BeanMap.keySet() is modifiable. Modifications to it (i.e. removes) will be reflected in the BeanMap, but that's probably not a good idea. Probably should return an unmodifiable collection. I'm -1 to these changes. There may be clients to BeanMap that expect this behaviour, and I'm uncomfortable with changing it in the eleventh hour of the release. I think that, for now, we should just document the behavior in the Javadocs. So, you'd rather leave the behavior such that changes to keySet() are reflected in the map, entrySet() is unmodifiable, and changes to values() are not reflected in the map? Having three different behaviors for these just seems wrong to me as well. 5. DoubleOrderedMap requires its keys and elements to be comparable. I don't think the external API relies on Comparable (just the internal API), so I don't think this must be fixed before a 2.0 release, but I didn't look quite that closely to know for sure. 6. The following classes have protected members and/or methods, but the ability to subclass without corrupting the internal state of the parent class is suspect: BeanMap, FastArrayList, FastHashMap, FastTreeMap. Fixing these would probably involve making some fields private. -1. We should minimize changes that affect Serialization, and in this case it doesn't seem worth the price. I don't know how either of these have effects on Serialization. DoubleOrderedMap isn't serializable, and even if it was, it doesn't have any Comparable fields that would be serialized (all the Comparable references are casts in order to do a comparison). As for changing protected members to private or otherwise adjusting to ensure subclasses can't corrupt internal structures, that doesn't change serialization either. If anything, it just requires the addition of a serialVersionUID to say yes, this class really does have the same fields. regards, michael -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [Collections] Release status?
On Wed, 20 Mar 2002, Morgan Delagrange wrote: Hi Michael et al. I've lost track. Is there anything else pending, or can I retag and create a new Release Candidate? Well, I've fixed all the things on my todo list that can't be made in a 2.0.1 release, but I also haven't finished reviewing the collections code for other places that may need fixing up. I was hoping to finish reviewing tonight. Ok to wait until tomorrow? regards, michael -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [Collections] Release status?
On Wed, 20 Mar 2002, Morgan Delagrange wrote: Sure, we can wait until tomorrow. Just be sure to get it all on the table at once, so we don't spread out the discussion unnecessarily. Yeah, that's what I meant to do before, but I somehow managed to forget what I sat down to do and ended up just fixing BinaryHeap et al. Might have something to do with the food poisoning I was still recovering from at the time... regards, michael -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[Collections] non-compatible changes
On Wed, 20 Mar 2002, Morgan Delagrange wrote: Sure, we can wait until tomorrow. Just be sure to get it all on the table at once, so we don't spread out the discussion unnecessarily. Okay, I've finished my (somewhat hurried and tiring) review for possible non-backwards compatible changes. I'm willing to do the necessary work for all of these. Here's the list of issues and improvements I have found in collections which require non-backwards compatible changes (and thus probably should go in before a 2.0 release if they are to go in at all): 1. AbstractBag seems to be more of a default map based implementation and differs in design from the AbstractSet, AbstractMap classes which do not make assumptions about how they might be implemented. To be consistent with JDK AbstractX collections, this should just be providing default implementations that could be used regardless of underlying storage mechanism. For example, the add(Object) method would call the abstract add(Object,int) method passing the object and 1. I think iterator() would need to be the only other abstract method. There's a few ways to fix this. First, reimplement so that only the minimal interfaces need to be implemented, thus matching the style of the JDK AbstractX collections. Second rename to DefaultMapBag or similar so that there isn't a difference in style. Third, a combination of both. The minimum necessary for a 2.0 release is just the rename. If you're confused about what I mean here, I can probably put together a patch this weekend for the third option (a new AbstractBag and a DefaultMapBag). 2. ArrayEnumeration is not fail-fast when a (Object[])null value is passed to the constructor. 3. BeanMap.values() is modifiable, but modifications are not reflected in the BeanMap. Probably should return an unmodifiable collection. 4. BeanMap.keySet() is modifiable. Modifications to it (i.e. removes) will be reflected in the BeanMap, but that's probably not a good idea. Probably should return an unmodifiable collection. 5. DoubleOrderedMap requires its keys and elements to be comparable. I don't think the external API relies on Comparable (just the internal API), so I don't think this must be fixed before a 2.0 release, but I didn't look quite that closely to know for sure. 6. The following classes have protected members and/or methods, but the ability to subclass without corrupting the internal state of the parent class is suspect: BeanMap, FastArrayList, FastHashMap, FastTreeMap. Fixing these would probably involve making some fields private. My brain power started dying, so I didn't really review the following classes (unfortunate since these are pretty sophisticated classes): CollectionUtils, CursorableLinkedList, ExtendedProperties, SoftRefHashMap There's also a lot of places where I disagree with the implementation of things, but I think it'd probably be too much for me to complain about all of them as well (e.g. MapUtils.getXXX() methods should throw exceptions or return null for things that aren't XXX rather than massaging them into XXX or using System.out.println) One other note: package.html probably should be updated before 2.0 release. tired, michael -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Can't build Collections
My bad. I didn't build clean before checking in the changes to PriorityQueue.java. I'll fix this right away... michael On Mon, 18 Mar 2002, Martin Cooper wrote: Attempting to build jakarta-collections tonight results in the following: build-java: [mkdir] Created dir: C:\src\jakarta\jakarta-commons\collections\dist\classes [javac] Compiling 43 source files to C:\src\jakarta\jakarta-commons\collecti ons\dist\classes [javac] C:\src\jakarta\jakarta-commons\collections\src\java\org\apache\commo ns\collections\SynchronizedPriorityQueue.java:72: org.apache.commons.collections .SynchronizedPriorityQueue should be declared abstract; it does not define inser t(java.lang.Object) in org.apache.commons.collections.SynchronizedPriorityQueue [javac] public final class SynchronizedPriorityQueue [javac] ^ [javac] C:\src\jakarta\jakarta-commons\collections\src\java\org\apache\commo ns\collections\SynchronizedPriorityQueue.java:118: incompatible types [javac] found : java.lang.Object [javac] required: java.lang.Comparable [javac] return m_priorityQueue.peek(); [javac]^ [javac] C:\src\jakarta\jakarta-commons\collections\src\java\org\apache\commo ns\collections\SynchronizedPriorityQueue.java:129: incompatible types [javac] found : java.lang.Object [javac] required: java.lang.Comparable [javac] return m_priorityQueue.pop(); [javac] ^ [javac] 3 errors Could someone fix this, please, or tell me what I'm doing wrong? Thanks. -- Martin Cooper -- 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] ReverseComparator
On Tue, 19 Mar 2002, Christoph Reck wrote: In sorting reverse is a common terminology, the comparator is used to sort. Ascending/Descending would be another term but is to much point of view dependant. Just my EUR0.02... I agree that reverse is common terminology when sorting, but I disagree that sorting is intrinsicly what a comparator does. While sorting is probably the most common use-case for comparators, the comparator itself does not do any sorting. It compares objects and returns a negative, zero value, or positive result. It doesn't rearrange, reverse, order, or sort. It just compares two objects. This particular comparator inverses the result of the compare to be a positive, zero value, or negative result (respectively). I use inverse here in its mathematical sense of inverting the result, since that's all this comparator is doing. I'm not going to argue this anymore though. I've changed my position -- why is this class even included in commons when the JDK provides a reverse/inverse comparator already? @see Collections.reverseOrder() regards, michael Michael A. Smith wrote: [snip] Additionally, I think that InverseComparator is a more appropriate name, as inverse has a more direct meaning (to me at least). Inverse has the mathematical meaning of the opposite sign which is exactly what this comparator does. Reverse, on the other hand, implies switching the order of something, the comparator isn't really switching the order (although a collection using the comparator may be reversed if it uses the inverse comparator). Thoughts? [snip] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [collections] ReverseComparator
On Tue, 19 Mar 2002, Michael A. Smith wrote: I'm not going to argue this anymore though. I've changed my position -- why is this class even included in commons when the JDK provides a reverse/inverse comparator already? @see Collections.reverseOrder() I just answered my own question. Collections.reverseOrder() inverts/reverses the natural ordering, but does not invert/reverse the ordering of an arbitrary comparator like the collections version does. That's a good reason to keep the commons version around. michael -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [COLLECTIONS] [VOTE] Release Collections 2.0
On Mon, 18 Mar 2002, James Strachan wrote:
- Original Message -
From: Morgan Delagrange [EMAIL PROTECTED]
yeah, I think I did mean ArrayIterator. The simple way of doing this
would be to use Array.getLength(array). That does the checking for you.
It also lets you calculate the length once (in the constructor) so that
multiple calls to hasNext does not require the overhead of
Array.getLength(...).
OK, sounds reasonable. FWIW, it may make sense to optimize this class
someday, so we don't perform unnecessary reflection on Object[] arrays.
Though I didn't think you could cast all arrays to Object[] so I'd prefer to
keep the reflection based implementation - I've certainly written code
before that needs it. e.g.
int[] foo = {1,2,3};
Object[] bar = (Object[]) foo;
The above is invalid.
I think what Morgan was referring to was possibly optimizing when this
*is* possible. E.g. have a second constructor that takes an Object[].
That way, if the object past in *is* castable as Object[], then a
non-reflection based impl could be used. I'm not sure how the two impls
could be mixed though, so I'm not sure how much of an optimization it
really is.
I think we both recognize that taking an int[] should be allowed.
regards,
michael
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [collections] ReverseComparator
On Tue, 19 Mar 2002, Morgan Delagrange wrote: I disagree. a no-arg constructor and dynamic instantiation of the comparator may be useful without a get/setComparator mechanism. For example, consider an application that allows you to specify a comparator in a configuration file while it will use for a particular application specific task. The config fail may just ask for the comparator class name, and the app can instantiate an instance of the comparator to use. I don't dispute that the new no-op constructor is an improvement. :) But if we're going to fix it, let's fix it right...I'm not sure we've gone far enough yet. Right now, the only use for that no-arg constructor is to provide functionality identical to Collections.reverseOrder(). That doesn't seem very useful at all. If you want to support bean-like construction, then let's add getter and setter methods; if not, then let's dump the no-arg constructor entirely. This middle ground seems inadequate. I'd just pick one, but I don't want to tick anybody off. Having the no-arg be equivalent to Collections.reverseOrder is still useful -- there's no easy way to specify the comparator returned from Collections.reverseOrder() as a configuration option in, say, an digestor based configuration file: field name=name comparator=org.apache.commons.collections.comparators.ComparableComparator field name=date comparator=org.apache.commons.collections.comparators.ReverseComparator That's the big advantage that makes me want to keep the no-arg even though equivalant functionality exists in Collections.reverseOrder. Here's my case for just removing the no-arg comparator. 1) Bean-like construction of a Comparator seems unimportant as a feature. 2) If only the constructor can set the comparator that's reversed, it's not possible to do something naughty like changing a comparator after it has already been assigned to a SortedXXX. 1) its important for the use-case above. 2) having a no-arg doesn't imply the comparator can be changed after assigned to a SortedXXX. It seems like both of these arguments *do* apply against adding a setComparator method though: it seems unimportant as a feature to be able to change the underlying comparator (rather than just creating a new one), and changing the functionality of the comparator after its assigned to a SortedXXX is a Bad Thing. I should also mention that a no-arg constructor does not imply that the comparator is a bean and needs to have get/set methods for all its attributes. And even if it does, I would still argue that the comparator is would not be a read/write attribute. I'd be ok with a get method if that makes things more bean-like. If folks really want no-arg, then let's at least add a setter method. For me, that option is a distant second, but livable. I will -1 adding a setComparator method. I think its too dangerous to allow the comparator to change behavior after it has been constructed. get/setComparator methods are really only useful for altering the underlying comparator once the reverse/inverse comparator has been constructed. I think this is bad because the underlying comparator is part of the functionality, and providing modification of it thus changes the functionality of the reverse/inverse comparator. That doesn't seem like an appropriate attribute modification. Definitely agree. I'd prefer to not have getter/setter methods. ok, so we agree. :) Since there's been a bit of discussion on the issue, and I haven't really heard any objections to my diff (fixing the comparator with respect to the comparator contract), I'm going to check that in. I'm also going to check in the argument swap rather than multiplication. We can continue discussion on the rename and whether or not to have a no-arg constructor. -0 for a no-arg constructor. This is weird actually. That no-arg has been in there since the class was added in February, and probably before that while the class existed in the util sandbox. Status-quo in this case is to leave the no-arg constructor. My changes were merely to fix the no-arg so that it conforms to the Comparator contract. Makes for some interesting apache style voting. :) -1 for the name change, only because it has the same connotation as and shares terminology with Collections.reverseOrder(). Might as well be consistent. If the term seems awkward, then a more specific definition in the Javadoc should suffice. Fine by me. After removing the multiplicationg in favor of just reversing the elements, it now seems just as appropriate to calling it a ReverseComparator as it does to call it an InverseComparator. ;) regards, michael -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [COLLECTIONS] [VOTE] Release Collections 2.0
On Mon, 18 Mar 2002, Morgan Delagrange wrote: For example, ArrayEnumeration takes an Object as a parameter, but does not provide checking on that to ensure that it is actually an Array. The checking would eventually be provided when the hasNext or next methods are called (in the form of an IllegalArgumentException), but I feel this should really be thrown from the constructor and and the setArray methods. That is, a more fail-fast behavior. Dang nabbit, now you've made me think. ArrayEnumeration actually takes Object[] as its parameter, I think you're thinking of ArrayIterator. But you are right, it would be nice if ArrayIterator was fail-fast. Unfortunately I can't think of a way to do it that's not really hokey. ArrayIterator can take an array of primitives, and there is no specific operation I know of to determine if an Object is an array of primatives. :P yeah, I think I did mean ArrayIterator. The simple way of doing this would be to use Array.getLength(array). That does the checking for you. It also lets you calculate the length once (in the constructor) so that multiple calls to hasNext does not require the overhead of Array.getLength(...). ArrayIterator takes primitives and ArrayEnumeration doesn't. :P Should we fix ArrayEnumeration? Or maybe we should deprecate the class and encourage users to wrap ArrayIterator with IteratorEnumeration instead. I think the latter would be my vote. We shouldn't really need to have any Enumeration classes around, since they can always be wrapped. There's probably an argument for keeping it around, but it's not an argument that I'm going to make. I'm with you on deprecating ArrayEnumeration. Another thing on I'd like to see is full generalization of some of the collections. For example, the BinaryHeap is currently restricted to Comparable objects. While you can't really have a heap without the ability to compare the objects, that doesn't mean the objects themselves have to be comparable. It should be allowable to specify a Comparator and use that to compare objects that don't implement Comparable. Such a change would alter the signatures of a couple of methods and would be an non-backwards compatible change. That only sounds like more constructors, right? You could probably do that in a minor release, especially considering BinaryHeap is neither Serializable nor subclass-able. Nope. peek() and pop() return Comparables and some of the protected methods take a Comparable as an argument. Changing these from Comparable to Object would be an API change because the method signatures would change. If you can hold off on the release for a few days, I can fix the above mentioned problems. Should be fairly simple to do. regards, michael -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [COLLECTIONS] [VOTE] Release Collections 2.0
On Tue, 19 Mar 2002, Tim Vernum wrote: yeah, I think I did mean ArrayIterator. The simple way of doing this would be to use Array.getLength(array). That does the checking for you. Doesn't obj.getClass().isArray() work? Yup, but we need to calculate the length of the array anyway to properly implement hasNext. See my commit that should be arriving momentarily. michael -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [collections] PriorityQueue
On Mon, 18 Mar 2002, otisg wrote: Take a look at this: http://marc.theaimsgroup.com/?l=lucene-devm=101356466003978w=2 http://marc.theaimsgroup.com/?l=lucene-devm=101484185405376w=2 (PrioerityQueue is mentioned further down in this second message) I'm not sure the relevance. Most of the discussion is centered around Lucene's implementation of a PriorityQueue, not the one in commons. The commons PriorityQueue seemed only mentioned in the contxt of the possibility of evaluating commons' version. Was there ever follow up with an actual evaluation of the Commons version? I tried searching for more follow ups, but didn't find anything particular to the commons version. in any case, I'm going to commit my changes. If anyone has an objection, just -1 my commit, and I'll back out the changes. regards, michael Otis ___ Get your own FREE email account at iVillage.com! http://webmail.ivillage.com -Original Message- From: Michael A. Smith Sent: 3/18/2002 11:51:00 PM To: [EMAIL PROTECTED] Subject: [collections] PriorityQueue In order to update BinaryHeap to take generic Objects rather than requiring Comparable objects, I will need to make an equivalent update to PriortyQueue. Any objections? regards, michael -- To unsubscribe, e-mail: For additional commands, e-mail: -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[collections] ReverseComparator
I just noticed that ReverseComparator has a no-arg constructor which
essentially returns -1 for all comparisons. This is the same as if a
null comparator is passed to the single-arg constructor. Doing so breaks
the contract for a comparator [sgn(compare(x, y)) == -sgn(compare(y, x))].
I think this should be changed to use the object's natural ordering if no
comparator has been specified. More specifically, see my diff below.
Aside: Is there any compelling reason to use -1*comparator.compare(o1,o2)
instead of comparator.compare(o2,o1)? It seems this way eliminates the
multiplication step and should have the same result.
Additionally, I think that InverseComparator is a more appropriate name,
as inverse has a more direct meaning (to me at least). Inverse has the
mathematical meaning of the opposite sign which is exactly what this
comparator does. Reverse, on the other hand, implies switching the order
of something, the comparator isn't really switching the order (although a
collection using the comparator may be reversed if it uses the inverse
comparator).
Thoughts?
regards,
Michael
Index: src/java/org/apache/commons/collections/comparators/ReverseComparator.java
===
RCS file:
/home/cvs/jakarta-commons/collections/src/java/org/apache/commons/collections/comparators/ReverseComparator.java,v
retrieving revision 1.5
diff -u -r1.5 ReverseComparator.java
--- src/java/org/apache/commons/collections/comparators/ReverseComparator.java 1 Mar
2002 19:18:49 - 1.5
+++ src/java/org/apache/commons/collections/comparators/ReverseComparator.java 19 Mar
+2002 05:09:43 -
@@ -75,6 +75,7 @@
* the reverse(List) method of java.util.Collection.
*/
public ReverseComparator() {
+this(null);
}
/**
@@ -82,15 +83,15 @@
* of the passed in comparator.
*/
public ReverseComparator(Comparator comparator) {
-this.comparator = comparator;
+if(comparator != null) {
+this.comparator = comparator;
+} else {
+this.comparator = ComparableComparator.getInstance();
+}
}
public int compare(Object o1, Object o2) {
-if(comparator == null) {
-return -1;
-} else {
-return -1*comparator.compare(o1,o2);
-}
+return -1*comparator.compare(o1,o2);
}
}
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [COLLECTIONS] [VOTE] Release Collections 2.0
On Fri, 15 Mar 2002, Morgan Delagrange wrote: The release candidate is ready and sitting on the server: http://jakarta.apache.org/builds/jakarta-commons/release/commons-collections /v2.0/ Please state your vote for this candidate. Also, please let me know if you discover errors in the distribution. -0 on the release. I don't want to hold it up, but I feel there are still some issues that could be resolved before we actually release a 2.0. As I mentioned earlier, documentation definately needs to be improved, but that could be added in a 2.0.1 without too much problems. Another thing that I think could be improved is argument checking. For example, ArrayEnumeration takes an Object as a parameter, but does not provide checking on that to ensure that it is actually an Array. The checking would eventually be provided when the hasNext or next methods are called (in the form of an IllegalArgumentException), but I feel this should really be thrown from the constructor and and the setArray methods. That is, a more fail-fast behavior. Changing such argument checking may be construed as an incompatible change, so that may not be able to be fixed in a 2.0.1 or a 2.1. Another thing on I'd like to see is full generalization of some of the collections. For example, the BinaryHeap is currently restricted to Comparable objects. While you can't really have a heap without the ability to compare the objects, that doesn't mean the objects themselves have to be comparable. It should be allowable to specify a Comparator and use that to compare objects that don't implement Comparable. Such a change would alter the signatures of a couple of methods and would be an non-backwards compatible change. regards, michael -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [COLLECTIONS] Collections 2.0 Release Candidate this week
On Thu, 14 Mar 2002, Morgan Delagrange wrote: I don't think any of the remaining submissions for Collections are ready for release yet, so I plan to prepare a Release Candidate and call a release vote within the next few days. I still think the BeanMap documentation is weak, but I'm not going to hold up the release because of that. I may spend some time trying to ferret out some of the undocumented bug fixes. Documentation can always be added in a 2.0.1 release. I've got a lot of documentation items on my todo list, but I don't know when I'll be able to get to them (I'm out of town this weekend). [snip] PENDING COLLECTIONS --- DirtyFlagMap: Per the email sent by James House (http://marc.theaimsgroup.com/?l=jakarta-commons-devm=101406634514652w=2). Will be reviewed by Michael Smith I briefly reviewed this a while ago, and I can't remember why I never posted my thoughts on it. What I found was that the dirty flag will not be set if a modification is made via entrySet(), keySet(), or values(). In my mind, this is a fairly large bug. Additionally, I'm not convinced on the usefulness of it. With those two items, I think we should hold off on including this class for now. regards, michael -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [collections] One test failed
On Wed, 13 Mar 2002, Lev Assinovsky wrote: Hi Michael! May be it's interesting for you? I made cvs update (for collections) and run ant (jdk 1.4). Yup. I mentioned this yesterday afternoon, just didn't have a chance last night to get to them. I've seen this as well, and is actually a bad test. The test is iterating over the results and expecting a certain order, however hash based collections usually do not guaruntee a particular ordering. In this case, the hashing behavior between JDK 1.3 and JDK 1.4 is different so the iterator is returning the elements in a different order (thus the test fails). In other words, the test is assuming that the Bag.iterator() method returns the elements in some particular order. For the HashBag, this ordering is based on a hashtable, which does not guaruntee any particular order. The hashing behavior changed between jdk 1.3 and 1.4, so the order changed for 1.4 (and broke the test under 1.4). The Bag interface does not specify that iterator() should return its elements in any particular order. Since the test assumes an order, this is is a bug in the test, not in the code itself. regards, michael Here are the results: test: [java] . [java] . [java] . [java] . [java] . [java] . [java] . [java] . [java] . [java] . [java] . [java] . [java] . [java] .FF [java] . [java] . [java] . [java] . [java] ... [java] Time: 13.029 [java] There were 2 failures: [java] 1) testIterator(org.apache.commons.collections.TestHashBag)junit.framework.AssertionFailedError: First should be 'A' expected:A but was:B [java] at org.apache.commons.collections.TestBag.testIterator(Unknown Source) [java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [java] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:42) [java] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:28) [java] 2) testIteratorFail(org.apache.commons.collections.TestHashBag)junit.framework.AssertionFailedErr or: First should be 'A' expected:A but was:B [java] at org.apache.commons.collections.TestBag.testIteratorFail(Unknown Source) [java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [java] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:42) [java] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:28) [java] [java] FAILURES!!! [java] Tests run: 749, Failures: 2, Errors: 0 [java] Regards, -- Lev AssinovskyPeterlink Web ProgrammerSt. Petersburg, Russia Tel/Fax: +7 812 3275343 197022 ul.Chapigina 7Á E-mail: [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] doc's build problem
On Wed, 13 Mar 2002, Lev Assinovsky wrote: Hello! I found that when run ant dist: [javadoc] Constructing Javadoc information... [javadoc] Standard Doclet version 1.4.0 The messages you are seeing are just warnings. They should be fixed, but they shouldn't prevent you from being able to generate javadoc information. regards, michael [javadoc] [javadoc] Building tree for all the packages and classes... [javadoc] Building index for all the packages and classes... [javadoc] /tmp/buildtemp_200203131311/org/apache/commons/collections/LRUMap.java:134: warning - Tag @see: missing #: removeLRU() [javadoc] /tmp/buildtemp_200203131311/org/apache/commons/collections/LRUMap.java:134: warning - Tag @see: can't find removeLRU() in org.apache.commons.collections.LRUMap [javadoc] /tmp/buildtemp_200203131311/org/apache/commons/collections/DefaultMapEntry.java:71: warning - Tag @link: reference not found: Map.Entry Map.Entry [javadoc] /tmp/buildtemp_200203131311/org/apache/commons/collections/DefaultMapEntry.java:87: warning - Tag @link: reference not found: Map.Entry#equals(Object) [javadoc] /tmp/buildtemp_200203131311/org/apache/commons/collections/DefaultMapEntry.java:104: warning - Tag @link: reference not found: Map.Entry#hashCode() [javadoc] Building index for all classes... [javadoc] /tmp/buildtemp_200203131311/org/apache/commons/collections/DefaultMapEntry.java:71: warning - Tag @link: reference not found: Map.Entry Map.Entry [javadoc] /tmp/buildtemp_200203131311/org/apache/commons/collections/AbstractBag.java:84: warning - Tag @link: can't find setMap(Map) in org.apache.commons.collections.AbstractBag [javadoc] /tmp/buildtemp_200203131311/org/apache/commons/collections/AbstractBag.java:84: warning - Tag @link: can't find setMap(Map) in org.apache.commons.collections.AbstractBag [javadoc] /tmp/buildtemp_200203131311/org/apache/commons/collections/AbstractBag.java:84: warning - Tag @link: can't find setMap(Map) in org.apache.commons.collections.AbstractBag [javadoc] /tmp/buildtemp_200203131311/org/apache/commons/collections/ArrayIterator.java:74: warning - @ is an unknown tag. [javadoc] /tmp/buildtemp_200203131311/org/apache/commons/collections/DefaultMapEntry.java:71: warning - Tag @link: reference not found: Map.Entry Map.Entry [javadoc] /tmp/buildtemp_200203131311/org/apache/commons/collections/DefaultMapEntry.java:87: warning - Tag @link: reference not found: Map.Entry#equals(Object) [javadoc] /tmp/buildtemp_200203131311/org/apache/commons/collections/DefaultMapEntry.java:104: warning - Tag @link: reference not found: Map.Entry#hashCode() [javadoc] /tmp/buildtemp_200203131311/org/apache/commons/collections/DefaultMapEntry.java:87: warning - Tag @link: reference not found: Map.Entry#equals(Object) [javadoc] /tmp/buildtemp_200203131311/org/apache/commons/collections/DefaultMapEntry.java:104: warning - Tag @link: reference not found: Map.Entry#hashCode() [javadoc] Generating /hdc2/archive/Jakarta/jakarta-commons/collections/dist/docs/api/stylesheet.css... -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [collections] Tests failed with jdk1.4 and 1.3.1
On Tue, 12 Mar 2002, Lev Assinovsky wrote: [java] There were 5 failures: that's weird, there are only 4 failures listed. [java] 1) testEntrySetContainsProperMappings(org.apache.commons.collections.TestBeanMap)junit.framework.AssertionFailedEr ror: entrySet().contains(Object) must return true when map contains the mapping expected:true but was:false [java] at org.apache.commons.collections.TestMap.testEntrySetContainsProperMappings(Unknown Source) [java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [java] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:42) [java] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:28) [java] 2) testEntrySetIterator(org.apache.commons.collections.TestBeanMap)junit.framework.AssertionFailedError: Objects r eturned from entrySet().iterator() must be instances of Map.Entry. [java] at org.apache.commons.collections.TestMap.testEntrySetIterator(Unknown Source) [java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [java] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:42) [java] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:28) [java] 3) testEntrySetIteratorRemove(org.apache.commons.collections.TestBeanMap)junit.framework.AssertionFailedError: ite rator should throw UnsupportedOperationException if remove is not allowed from the entrySet().iterator() [java] at org.apache.commons.collections.TestMap.testEntrySetIteratorRemove(Unknown Source) [java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [java] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:42) [java] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:28) These first three are the same for jdk 1.3, and are known problems. I've been trying to get to them, but have been swamped with other stuff and haven't had the chance yet. [java] 4) testIterator(org.apache.commons.collections.TestHashBag)junit.framework.AssertionFailedError: First should be ' A' expected:A but was:B [java] at org.apache.commons.collections.TestBag.testIterator(Unknown Source) [java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [java] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:42) [java] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:28) I've seen this as well, and is actually a bad test. The test is iterating over the results and expecting a certain order, however hash based collections usually do not guaruntee a particular ordering. In this case, the hashing behavior between JDK 1.3 and JDK 1.4 is different so the iterator is returning the elements in a different order (thus the test fails). [java] [java] FAILURES!!! [java] Tests run: 748, Failures: 5, Errors: 1 there's that 5 again, but I only saw 4 listed... [snip] Actually my intention was to use dbcp, that's why I got nightly The above test failures shouldn't effect dbcp. regards, michael -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [collections] Tests failed with jdk1.4 and 1.3.1
On Tue, 12 Mar 2002, Lev Assinovsky wrote: Thanks, Michael! But what about that exception [java] 1) testContainsValue(org.apache.commons.collections.TestBeanMap) [java] java.lang.ClassCastException: java.lang.String What is that? Haven't had a change to look extensively yet, but I'm guessing something in either the test or in BeanMap is assuming all the values are the same type, and they aren't. Does it affect DBCP? DBCP does not use BeanMap as far as I know. regards, michael -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-commons/collections/src/java/org/apache/commons/collectionsAbstractBag.java Bag.java Closure.java DefaultMapEntry.java HashBag.javaIteratorEnumeration.java MapUtils.java MultiHas
On 13 Mar 2002 [EMAIL PROTECTED] wrote: Log: Removed bad line-endings (multiple ^Ms). [snip] Revision ChangesPath 1.5 +338 -338 jakarta-commons/collections/src/java/org/apache/commons/collections/AbstractBag.java I find it interesting that cvs says the entire file changes (+338 -338), yet if you look at the colored diff using viewcvs, it says No changes http://cvs.apache.org/viewcvs/jakarta-commons/collections/src/java/org/apache/commons/collections/AbstractBag.java.diff?r1=1.4r2=1.5diff_format=h regards, michael -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [COLLECTIONS] Comparator observations
On Thu, 28 Feb 2002, Morgan Delagrange wrote: First, I'm not sure all of these Comparators are generic enough to include in Collections. ComparableComparator and ReverseComparator seem to be right on. NumericStringComparator, PackageNameComparator, and UrlComparator seem too specific for Collections though. I'm just curious, but why do you feel they are too specific? If someone whants to create a TreeSet (or FastTreeSet, or pretty much any ordered set), which contains URLs, a URL comparator might be useful. And it doesn't seem to make as much sense to have the URL comparator in a net component. It seems that if a Collection or Comparator would seem out of place in the JDK, it's not a good candidate for Collections. PackageNameComparator and UrlComparator in particular seem out of place. Most comparators are highly specific, and comparators are also very easy to write. Consequently, we should be wary of which Comparators we include. Bay, would you object to removing NumericStringComparator, PackageNameComparator and UrlComparator? these comparators (by name only) seem generic enough. They don't depend on anything other than what's already in the JDK (String, URL). I would agree that they would be out of place if the comparator was comparing things that are not in the JDK though. More specifically, a comparator that depends on something other than stuff in the JDK is probably too specific and would be out of place. I'm just not sure that theese comparators are. I'm not sure that easy to write is a great argument for excluding them. If it was, we wouldn't include things like ProxyIterator, SingletonIterator, or even IteratorEnumeraation. Having the ability to reuse code rather than just redo it (even if it is simple) is one of the tenets of the commons project. Second, none of the Comparators are Serializable. Shouldn't they be, so that their corresponding Collections will be serializable? that's probably a good idea. :) michael -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [collections][patch] Remove redundant public modifiers frominterface methods
On Thu, 28 Feb 2002, Christopher Elkins wrote: I've always liked the public modifier, but I guess it is completely redundant. I'll try to change my ways in the future. Yeah, there's nothing technically _wrong_ it. (The JLS doesn't explicitly say as such.) However, it tends to pollute the build output (in Jikes, anyway) and potentially masks warnings that are actually important. :-) Actually, while the JLS doesn't say its wrong (otherwise the compiler wouldn't accept it), it is highly discouraged. To quote the relevent section of the java language specification (section 9.4): It is permitted, but strongly discouraged as a matter of style, to redundantly specify the public modifier for interface methods. This is actually true for the abstract modifier as well (at a previous employer, all interfaces had public abstract): For compatibility with older versions of the Java platform, it is permitted but discouraged, as a matter of style, to redundantly specify the abstract modifier for methods declared in interfaces. reference: http://java.sun.com/docs/books/jls/second_edition/html/interfaces.doc.html#78651 regards, michael -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [COLLECTIONS] Comparator observations
On Thu, 28 Feb 2002, Morgan Delagrange wrote: I'm just curious, but why do you feel they are too specific? If someone whants to create a TreeSet (or FastTreeSet, or pretty much any ordered set), which contains URLs, a URL comparator might be useful. Why would you want an ordered list of URLs? For display purposes? Or to guarantee that you are not referring to the same file? If that's the case, that's already addressed by URLStreamHandler.equals() which returns true if the two urls are considered equal, ie. they refer to the same fragment in the same file. If this Comparator is trying to overcome deficiencies in URLStreamHandler, that should be documented in the class. Even if it were the case, I don't believe a Comparator is the right place to address it. Usually, if it makes sense to ascribe order to an Object, that Object implements Comparable. In this particular case, the UrlComparator sorts by host, then path, then protocol, then port. But why that and not protocol, host, path, port? Or why not protocol, host, port, path? URLs don't really have an implicit order, so the UrlComparator is guaranteed to be somewhat arbitrary. Point well taken. My objection is mainly their arbitrary ordering. They try to sort Objects that don't have undeniable order. That's why I'd rather see us focus on Comparators that reverse other comparators (ReverseComparator), or comparators that can be used to implement SortedSets or SortedMaps (ComparableComparator). Other possibilities might be classes that let you chain Comparators together, or Comparators that truly address oversights in the JDK. Comparators like the Soundex Comparator also make sense, because Soundex has an implicit ordering (but Soundex is also very specific, and it's more appropriate where it is in Codec.) I'd rather not see us try to ascribe an arbitrary ordering to Objets like URLs and package names. Again, point taken. Soundex should definately go with the soundex stuff. It is specific to that codec. But surely there's quite a distinction in scope between these classes that deal with iteration in general and a class that only sorts URLs? my iteration example was referring to simplicity of implementation, not applicability to collections. :) regards, michael -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [Commons] Testing sub-components
On Tue, 26 Feb 2002, Morgan Delagrange wrote: Actually, I think the names below, which I drew from the current Collections test classes, are slightly misleading. I think there should be a TestObject test case, which tests the methods of Object. For most other tasks, we probably want a library of custom asserts, rather than actual test cases. That seems to be the only reasonable course, since interfaces can be combined in any number of ways. I've been thinking about the library of custom asserts a bit as well, but have yet to reach a design/impl that I'm happy with. My primary motivation was primarily for being able to use the same tests for testing the entrySet(), keySet(), and values() that are used for testing Maps, and Collections. This is almost the same thing as you imply about being able to test interfaces. michael -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: commons dbcp or pool problems
On Fri, 22 Feb 2002, Glenn Nielsen wrote: I have been using Tomcat 4.1-dev and its new DBCP DataSource Factory which uses commons-dbcp, which then uses other commons components like commons-pool. Everything works fine, then all of a sudden GenericPool can no longer get a db connection from the pool. All attempts to get a connection from the pool fail. The only way to fix the problem is to stop and restart Tomcat. In case you ask, the db is running fine, and an application which uses Torque to manage db connections continues to work. Only the commons-dbcp exhibits the failure. This has happen twice in the last 24 hours, both times were about 10 - 12 hours after Tomcat started up. The first run was during the day with higher traffic, the second was overnight with lower traffic. During each run the DBCP has handled many thousands of connection requests. Here is a snippet from the exception: 2002-02-22 08:47:53 StandardWrapperValve[jsp]: Servlet.service() for servlet jsp threw exception java.util.NoSuchElementException: Timeout waiting for idle object at org.apache.commons.pool.impl.GenericObjectPool.borrowObject(Unknown Source) at org.apache.commons.dbcp.PoolingDataSource.getConnection(Unknown Source) at org.apache.taglibs.dbtags.connection.ConnectionTag.doEndTag(ConnectionTag.java:214) at org.apache.jsp.pastnumsearch$jsp._jspService(pastnumsearch$jsp.java:116) Without knowing any details about the pool component (yet -- I plan on giving it a good look eventually), I suspect that you may have a pool leak. Somewhere you're borrowing from the pool and not returning it to the pool. Possibly the return of an object is not in a finally block and an rare exception causes it to lose one object. Then again, I haven't looked at the pool component, so I don't know whether this would be tye symptom for that problem or not. Take what I say with a grain of salt. Although it might be a good place to start looking. regards, michael I am using the following commons components. commons-collections V1.0 release from July 14, 2001. commons-pool nightly from Feb 1, 2002. commons-dbcp nightly from Feb 1, 2002. Does anyone know of any bugs or changes in any of these which may be causing the general failure of pooling the dbcp connections? Thanks, Glenn -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | -- -- 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: Util Dispersion
On Fri, 22 Feb 2002 [EMAIL PROTECTED] wrote: What is the reasoning for not moving lru.* into Collections and/or merging with LRUMap? Mainly that I was unsure if the consensus was for that. Anyone against this being transfered? And anyone up for the merging? I would be okay with it being moved to collections, provided that it adds functionality that isn't already available in the LRUMap. If possible, it'd be nice to just have their functionality merged rather than adding additional classes. Aaron, since you committed it, can you evaluate to see what features the lru.* stuff has that the LRUMap in collections doesn't? regards, michael -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Commons Util 1.0 release candidate 1
On Thu, 21 Feb 2002 [EMAIL PROTECTED] wrote: Any -1's on a servlet subproject/subpackage for these three? Not from me. Would a servlet component be the appropriate component location for the servlet filters? Or is that still going to be a separate component? regards, michael On Thu, 21 Feb 2002, Waldhoff, Rodney wrote: src/java/org/apache/commons/util/http/BrowserDetector.java src/java/org/apache/commons/util/http/HttpUtils.java src/java/org/apache/commons/util/http/RequestUtils.java There's been suggestion for a 'servlet' package. These might go in there That sounds like a better idea still, since even if HttpUtils/RequestUtils can make their way into HttpClient, BrowserDetector would still be orphaned. -Original Message- From: Waldhoff, Rodney To: 'Jakarta Commons Developers List ' Sent: 2/21/02 10:48 AM Subject: RE: Commons Util 1.0 release candidate 1 Bay wrote: This leaves a few other classes to decide where they should go. 2) http. I imagine this would either go into io or into HttpClient. io seems most likely as HttpClient has a different goal. IO sounds OK, but we may want to revisit that. I'd like to see us factor out some of the HTTP parsing/generating bits in HTTP Client so that they're usable independent of the wire-level protocol (driven by some experiences using an in-process Tomcat engine), in which case RequestUtils and HttpUtils might be clean fit. (I'm gonna send out a note on this and some related HTTP Client (3.x?) ideas, probably next week.) (I'm actually a little confused by the purpose of RequestUtils: shouldn't header matching just be a matter of case-insensitive comparision? Can someone point to where/why RequestUtils is used?) 3) 'util' like classes. Soundex Soundex is used by Strings(StringUtil) so it's tempting to send it with it into Lang. Soundex seems like an String encoding to me, so why not in the codec component? - Rod -- 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: cvs commit: jakarta-commons/collections/src/test/org/apache/commons/collectionsTestMap.java TestSequencedHashMap.java
On Thu, 21 Feb 2002, Michael A. Smith wrote: I'll get what I have committed once I get home from work and get some food in my stomach. grr... ran into cvs/patch problems, then ran into some runtime issues. You should see the commit message shortly. :) regards, michael -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: cvs commit: jakarta-commons/collections/src/test/org/apache/commons/collectionsTestSequencedHashMap.java
On 22 Feb 2002 [EMAIL PROTECTED] wrote: morgand 02/02/21 22:25:10 Modified:collections/src/test/org/apache/commons/collections TestSequencedHashMap.java Log: more specific in-memory serialization tests for SequencedHashMap [snip] +assertEquals(Both maps have the same first key, + map.getFirstKey(),getSampleKeys()[0]); +assertEquals(Both maps have the same first key, + map2.getFirstKey(),getSampleKeys()[0]); +assertEquals(Both maps have the same last key, + map.getLastKey(),getSampleKeys()[0]); +assertEquals(Both maps have the same last key, + map2.getLastKey(),getSampleKeys()[0]); shouldn't that be getSampleKeys()[getSampleKeys().length - 1] for the last ones? right now the both maps have the same last key tests are failing and they probably shouldn't. michael -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
