Re: [Latka]Following references
Hi, I provided this patch a couple of weeks ago and got no reaction. So I just want to ask whether there is anybody who has an eye on patches and further development of this component. BTW: Has there ever been a release of Latka? Oli Oliver Heger wrote: Hi, as I have promised I created a patch (in bugzilla, bug ID is 25487) that adds the feature of extracting references from downloaded pages to Latka. These references can be refered to in later request tags. The basic idea is that there are three new Jelly tags - link, form and frame - that can be put in the body of a request tag. With the attributes of these tags it is possible to refer to a corresponding reference on a page that has already been downloaded. The tags alter the actual request to load the URL defined by this reference. To demonstrate I have written an alternative version of the TestCommonsWebsite.xml script that makes use of these new tags. Some remarks to the code: There is a new package o.a.c.latka.html that contains the classes for parsing HTML pages and extracting references. I could not use the URLExtractor class in the attic for this purpose because I had to obtain much more information from the page, e.g. the body of the a tags or hidden input fields in the body of a form tag. The RequestImpl class had to be slightly modified to allow sub tags of the request tag to change the URL of the actual request (creation of the HttpMethod object is now deferred). Also the ResponseImpl class now maintains an object with all references extracted from this page, which is created on demand. I hope that I have met all coding style guides. Please have a look at the code and let me know what you think. If you decide to apply the patch, I can also provide some documentation updates. Regards Oli - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Next Steps - WAS Re: [net] VMSFTPEntryParser bug?
Seems to me the HashMap --- Hashtable change could be made against HEAD. It's only NECESSARY for 1.1 compatibility but it poses no great problem for a 1.2 compatible version; it isn't as if this would impact some functionality deep in the core of the product. So after this is done, a NET_1_1_1 tag could be created and that could be the final of this branch. On the other hand, if there are other 1.1 incompatibilities we may want to fix those too, and then this might get a little problematical. Hey, Jeffrey, do you know if there's an easy way to make Maven do a JDK 1.1 compile? Or would it be easier to just tinker with the generated ant script? On the subject of the pluggable parser factory, I'm not sure I see the need, but it's easy enough to do it that way, so I will make the change. Am I correct in assuming that in your plan there would be a default implementation, with other factories being selectable instead on the basis of a property? On Wednesday 31 December 2003 10:42 pm, Daniel F. Savarese wrote: In message [EMAIL PROTECTED], steve cohen writes: I am not completely CVS-literate and setting up the branches is beyond my current level of experience but probably would be good experience for me. In my response to Jeffrey's email, I asked about whether we wanted to replace the existing NET_1_1_0 tag with a new NET_1_1_0 branch tag or leave the existing tag alone and attach a special branch tag with a different name to the NET_1_1_0 files. After we resolve that, if you want to do it, go ahead. I don't know if you can use the -F and -b options together with cvs tag, which is why I suggested the roundabout way of renaming the tag and creating a new one with the old name using -b. Subversion makes this easier. without requiring it to have far more knowledge of commons-net internals than I think is healthy. So I am developing an FTPFileEntryParserFactory and some convenience methods in FTPClient to enable Ant to be recoded decently. I followed the emails. Sounds great. I forgot to offer a comment. I was going to suggest making FTPFileEntryParserFactory either a class or an interface that has to be instantiated rather than a singleton. I think you were intending to make createFileEntryParser a static method. I suggest the use of an interface and a default factory class for the same reason we had to write SocketFactory and much later, in J2SE 1.4, Sun added its own javax.net.SocketFactory and javax.net.ServerSocketFactory. It allows generic code to be written that accepts pluggable parser factories should a user decide to implement his own factory. I'm thinking about the automatic detection code you alluded to, which could then be configurable/extensible through the insertion of parser factories. I can also make the HashMap--Hashtable change for the 1.1.1 branch. The JDK 1.1 incompatibility was DISCOVERED through failure of the unit test but the offending code is in the class being tested, not the test itself. I have Sure thing. Let's decide how to tag that branch. And it sounds like you have an itch for doing the nio stuff. It's been nagging me for a while, but I'm actually writing networking code these days based on java.nio, so I figure I should kill two birds with one stone and start rolling it into Commons Net as a proposal instead of keeping it in my private library. It's so much easier to dedicate volunteer committer hours when you're working on/using the stuff anyway. daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] Branching
Daniel, I agree with all your ideas, but it seems to me you can branch from any tagged point in the revision history so I'm not sure what the idea is behind deleting/renaming the tags. http://www.cvshome.org/docs/manual/cvs-1.11.10/cvs_5.html#SEC56 Given that, as per Steve's message, we can make 1.1 compatibilty changes on HEAD, release and tag, and branch from that point in the future when/if there are bug fixes required? It's early New Year's morning, so my head may be a bit foggy! On Wed, 31 Dec 2003 23:52:45 -0500, Daniel F. Savarese [EMAIL PROTECTED] said: I wrote: Sanity check the steps to make sure this is what we want: o rename NET_1_1_0 tag to something else, let's say FOO o tag FOO as NET_1_1_0, this time with the -b flag to make it a branch tag I left out delete the FOO tag ... If that seems like not a good thing, another option is to tag the NET_1_1_0 snapshot with NET_1_1_0_MAINTENANCE or some such tag for the 1.1 maintenance branch and leave the existing NET_1_1_0 tag alone. I forgot to indicate what I favor. Only because I haven't thought of any arguments against it, I favor the first method (change NET_1_1_0 to a 'cvs tag -b' branch tag). The second approach is safer because it doesn't run the risk of screwing up anything and I don't object to it. The only con I can think of to the second approach is that having two tags with NET_1_1_0 in them may be confusing. I don't think I've ever retroactively branched after tagging with CVS (usually, for me at least, branching is premeditated), which is why I don't have a strong preference. daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- = Jeffrey D. Brekke [EMAIL PROTECTED] Wisconsin, USA [EMAIL PROTECTED] [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Best place for CPIO io streams
Thanks for your help Phil and Noel. I will open a ticket as soon as I have the CPIO input/output stream ready and I'm satisfied with the functionality. Happy new Year. Micha - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Next Steps - WAS Re: [net] VMSFTPEntryParser bug?
On Thursday 01 January 2004 09:06 am, Jeffrey D. Brekke wrote: Maven uses the following property: maven.compiler.target which defaults to 1.1 so what I last released generated 1.1 compatible class files. http://maven.apache.org/reference/plugins/java/properties.html Example: maven -Dmaven.compiler.target=1.2 clean jar Then I don't understand why I was able to build, since HashMap is not in 1.1. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25818] - BinaryHeap.remove(Object) seems to break heap order
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25818.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25818
BinaryHeap.remove(Object) seems to break heap order
--- Additional Comments From [EMAIL PROTECTED] 2004-01-01 18:07 ---
Test case that fails:
public void testAddRemove() {
resetEmpty();
BinaryBuffer heap = (BinaryBuffer) collection;
heap.add(new Integer(0));
heap.add(new Integer(2));
heap.add(new Integer(4));
heap.add(new Integer(3));
heap.add(new Integer(8));
heap.add(new Integer(10));
heap.add(new Integer(12));
heap.add(new Integer(3));
confirmed.addAll(heap);
System.out.println(heap);
Object obj = new Integer(10);
heap.remove(obj);
confirmed.remove(obj);
System.out.println(heap);
verify();
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25818] - BinaryHeap.remove(Object) seems to break heap order
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25818. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25818 BinaryHeap.remove(Object) seems to break heap order --- Additional Comments From [EMAIL PROTECTED] 2004-01-01 18:55 --- Thanks, Stephen. I am completing final testing/review of a fix Modifing remove() to decide whether to percolate up or down, and adding percolateUp methods that take start indexes. All tests (incl the one you just suggested w/ BinaryHeap in place of BinaryBuffer) pass. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/collections/src/java/org/apache/commons/collections PriorityQueueUtils.java SynchronizedPriorityQueue.java
scolebourne2004/01/01 10:57:37
Modified:collections/src/java/org/apache/commons/collections
PriorityQueueUtils.java
SynchronizedPriorityQueue.java
Removed: collections/src/java/org/apache/commons/collections/buffer
UnmodifiablePriorityQueue.java
SynchronizedPriorityQueue.java
Log:
Move PriorityQueue decorators to PriorityQueueUtils only
(PriorityQueue interface has nothing to do with Buffer)
Revision ChangesPath
1.5 +123 -8
jakarta-commons/collections/src/java/org/apache/commons/collections/PriorityQueueUtils.java
Index: PriorityQueueUtils.java
===
RCS file:
/home/cvs/jakarta-commons/collections/src/java/org/apache/commons/collections/PriorityQueueUtils.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- PriorityQueueUtils.java 3 Dec 2003 14:39:42 - 1.4
+++ PriorityQueueUtils.java 1 Jan 2004 18:57:37 - 1.5
@@ -57,9 +57,7 @@
*/
package org.apache.commons.collections;
-import org.apache.commons.collections.buffer.BinaryHeap;
-import org.apache.commons.collections.buffer.SynchronizedPriorityQueue;
-import org.apache.commons.collections.buffer.UnmodifiablePriorityQueue;
+import java.util.NoSuchElementException;
/**
* Provides static utility methods and decorators for [EMAIL PROTECTED]
PriorityQueue}.
@@ -74,7 +72,7 @@
/**
* An empty unmodifiable priority queue.
*/
-public static final PriorityQueue EMPTY_PRIORITY_QUEUE =
UnmodifiablePriorityQueue.decorate(new BinaryHeap());
+public static final PriorityQueue EMPTY_PRIORITY_QUEUE = new
EmptyPriorityQueue();
/**
* codePriorityQueueUtils/code should not normally be instantiated.
@@ -91,7 +89,7 @@
* @throws IllegalArgumentException if the priority queue is null
*/
public static PriorityQueue synchronizedPriorityQueue(PriorityQueue
priorityQueue) {
-return SynchronizedPriorityQueue.decorate(priorityQueue);
+return new SynchronizedPriorityQueue(priorityQueue);
}
/**
@@ -102,7 +100,124 @@
* @throws IllegalArgumentException if the priority queue is null
*/
public static PriorityQueue unmodifiablePriorityQueue(PriorityQueue
priorityQueue) {
-return UnmodifiablePriorityQueue.decorate(priorityQueue);
+return new UnmodifiablePriorityQueue(priorityQueue);
}
+//---
+/**
+ * Decorator for PriorityQueue that adds synchronization.
+ */
+static class SynchronizedPriorityQueue implements PriorityQueue {
+
+/** The priority queue to decorate */
+protected final PriorityQueue priorityQueue;
+
+protected SynchronizedPriorityQueue(PriorityQueue priorityQueue) {
+if (priorityQueue == null) {
+throw new IllegalArgumentException(PriorityQueue must not be
null);
+}
+this.priorityQueue = priorityQueue;
+}
+
+public synchronized boolean isEmpty() {
+return priorityQueue.isEmpty();
+}
+
+public synchronized Object peek() {
+return priorityQueue.peek();
+}
+
+public synchronized Object pop() {
+return priorityQueue.pop();
+}
+
+public synchronized void insert(Object obj) {
+priorityQueue.insert(obj);
+}
+
+public synchronized void clear() {
+priorityQueue.clear();
+}
+
+public synchronized String toString() {
+return priorityQueue.toString();
+}
+}
+
+//---
+/**
+ * Decorator for PriorityQueue that prevents changes.
+ */
+static class UnmodifiablePriorityQueue implements PriorityQueue, Unmodifiable {
+
+/** The priority queue to decorate */
+protected final PriorityQueue priorityQueue;
+
+protected UnmodifiablePriorityQueue(PriorityQueue priorityQueue) {
+if (priorityQueue == null) {
+throw new IllegalArgumentException(PriorityQueue must not be
null);
+}
+this.priorityQueue = priorityQueue;
+}
+
+public synchronized boolean isEmpty() {
+return priorityQueue.isEmpty();
+}
+
+public synchronized Object peek() {
+return priorityQueue.peek();
+}
+
+public synchronized Object pop() {
+throw new UnsupportedOperationException();
+}
+
+public synchronized void insert(Object
cvs commit: jakarta-commons/collections/src/java/org/apache/commons/collections PriorityQueue.java
scolebourne2004/01/01 10:58:55
Modified:collections/src/java/org/apache/commons/collections
PriorityQueue.java
Log:
PriorityQueue is replaced by Buffer
Revision ChangesPath
1.9 +7 -8
jakarta-commons/collections/src/java/org/apache/commons/collections/PriorityQueue.java
Index: PriorityQueue.java
===
RCS file:
/home/cvs/jakarta-commons/collections/src/java/org/apache/commons/collections/PriorityQueue.java,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- PriorityQueue.java13 Dec 2003 23:51:28 - 1.8
+++ PriorityQueue.java1 Jan 2004 18:58:55 - 1.9
@@ -57,17 +57,16 @@
*/
package org.apache.commons.collections;
-import java.util.NoSuchElementException;
-
/**
* Defines a collection for priority queues, which can insert, peek and pop.
* p
- * This interface does not dictate whether it is min or max heap.
+ * This interface is now replaced by the codeBuffer/code interface.
+ * It remains for backwards compatability.
*
* @since Commons Collections 1.0
* @version $Revision$ $Date$
*
- * @author a href=mailto:[EMAIL PROTECTED]Peter Donald/a
+ * @author Peter Donald
*/
public interface PriorityQueue {
@@ -100,7 +99,7 @@
* @return the element at top of heap
* @throws NoSuchElementException if codeisEmpty() == true/code
*/
-Object peek() throws NoSuchElementException;
+Object peek();
/**
* Return element on top of heap and remove it.
@@ -108,6 +107,6 @@
* @return the element at top of heap
* @throws NoSuchElementException if codeisEmpty() == true/code
*/
-Object pop() throws NoSuchElementException;
+Object pop();
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/collections/src/java/org/apache/commons/collections BinaryHeap.java
scolebourne2004/01/01 11:00:20 Modified:collections/src/java/org/apache/commons/collections BinaryHeap.java Log: Undeprecate, as is only implementation of PriorityQueue Revision ChangesPath 1.16 +19 -15 jakarta-commons/collections/src/java/org/apache/commons/collections/BinaryHeap.java Index: BinaryHeap.java === RCS file: /home/cvs/jakarta-commons/collections/src/java/org/apache/commons/collections/BinaryHeap.java,v retrieving revision 1.15 retrieving revision 1.16 diff -u -r1.15 -r1.16 --- BinaryHeap.java 29 Nov 2003 18:04:57 - 1.15 +++ BinaryHeap.java 1 Jan 2004 19:00:20 - 1.16 @@ -63,36 +63,40 @@ import java.util.NoSuchElementException; /** - * Binary heap implementation of [EMAIL PROTECTED] PriorityQueue} and [EMAIL PROTECTED] Buffer}. + * Binary heap implementation of codePriorityQueue/code. + * p + * The codePriorityQueue/code interface has now been replaced for most uses + * by the codeBuffer/code interface. This class and the interface are + * retained for backwards compatability. The intended replacement is + * [EMAIL PROTECTED] org.apache.commons.collections.buffer.BinaryBuffer BinaryBuffer}. * p * The removal order of a binary heap is based on either the natural sort * order of its elements or a specified [EMAIL PROTECTED] Comparator}. The - * [EMAIL PROTECTED] #remove()} method always returns the first element as determined + * [EMAIL PROTECTED] #pop()} method always returns the first element as determined * by the sort order. (The codeisMinHeap/code flag in the constructors - * can be used to reverse the sort order, in which case [EMAIL PROTECTED] #remove()} + * can be used to reverse the sort order, in which case [EMAIL PROTECTED] #pop()} * will always remove the last element.) The removal order is * inot/i the same as the order of iteration; elements are * returned by the iterator in no particular order. * p - * The [EMAIL PROTECTED] #add(Object)} and [EMAIL PROTECTED] #remove()} operations perform - * in logarithmic time. The [EMAIL PROTECTED] #get()} operation performs in constant + * The [EMAIL PROTECTED] #insert(Object)} and [EMAIL PROTECTED] #pop()} operations perform + * in logarithmic time. The [EMAIL PROTECTED] #peek()} operation performs in constant * time. All other operations perform in linear time or worse. * p * Note that this implementation is not synchronized. Use - * [EMAIL PROTECTED] BufferUtils#synchronizedBuffer(Buffer)} to provide - * synchronized access to a codeBinaryHeap/code: + * [EMAIL PROTECTED] PriorityQueueUtils#synchronizedPriorityQueue(PriorityQueue)} + * to provide synchronized access to a codeBinaryHeap/code: * * pre - * Buffer heap = BufferUtils.synchronizedBuffer(new BinaryHeap()); + * PriorityQueue heap = PriorityQueueUtils.synchronizedPriorityQueue(new BinaryHeap()); * /pre * - * @deprecated Moved to buffer subpackage. Due to be removed in v4.0. * @since Commons Collections 1.0 * @version $Revision$ $Date$ * - * @author a href=mailto:[EMAIL PROTECTED]Peter Donald/a - * @author a href=mailto:[EMAIL PROTECTED]Ram Chidambaram/a - * @author a href=mailto:[EMAIL PROTECTED]Michael A. Smith/a + * @author Peter Donald + * @author Ram Chidambaram + * @author Michael A. Smith * @author Paul Jack * @author Stephen Colebourne */ @@ -227,7 +231,7 @@ m_comparator = comparator; } - +//--- /** * Clears all elements from queue. */ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/collections/src/java/org/apache/commons/collections/buffer BinaryBuffer.java package.html BinaryHeap.java
scolebourne2004/01/01 11:01:34
Modified:collections/src/test/org/apache/commons/collections/buffer
TestAll.java
collections/src/java/org/apache/commons/collections/buffer
package.html
Added: collections/src/test/org/apache/commons/collections/buffer
TestBinaryBuffer.java
collections/src/java/org/apache/commons/collections/buffer
BinaryBuffer.java
Removed: collections/src/test/org/apache/commons/collections/buffer
TestBinaryHeap.java
collections/src/java/org/apache/commons/collections/buffer
BinaryHeap.java
Log:
Rename BinaryHeap to BinaryBuffer
Remove PriorityQueue interface
Revision ChangesPath
1.3 +3 -3
jakarta-commons/collections/src/test/org/apache/commons/collections/buffer/TestAll.java
Index: TestAll.java
===
RCS file:
/home/cvs/jakarta-commons/collections/src/test/org/apache/commons/collections/buffer/TestAll.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- TestAll.java 29 Nov 2003 18:04:56 - 1.2
+++ TestAll.java 1 Jan 2004 19:01:34 - 1.3
@@ -83,7 +83,7 @@
public static Test suite() {
TestSuite suite = new TestSuite();
-suite.addTest(TestBinaryHeap.suite());
+suite.addTest(TestBinaryBuffer.suite());
suite.addTest(TestBlockingBuffer.suite());
suite.addTest(TestBoundedFifoBuffer.suite());
suite.addTest(TestBoundedFifoBuffer2.suite());
1.1
jakarta-commons/collections/src/test/org/apache/commons/collections/buffer/TestBinaryBuffer.java
Index: TestBinaryBuffer.java
===
/*
* $Header:
/home/cvs/jakarta-commons/collections/src/test/org/apache/commons/collections/buffer/TestBinaryBuffer.java,v
1.1 2004/01/01 19:01:34 scolebourne Exp $
*
*
* The Apache Software License, Version 1.1
*
* Copyright (c) 2001-2003 The Apache Software Foundation. All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
*
* 1. Redistributions of source code must retain the above copyright
*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 acknowledgement:
* This product includes software developed by the
*Apache Software Foundation (http://www.apache.org/).
*Alternately, this acknowledgement may appear in the software itself,
*if and wherever such third-party acknowledgements normally appear.
*
* 4. The names The Jakarta Project, Commons, 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]
*
* 5. Products derived from this software may not be called Apache
*nor may Apache appear in their names without prior written
*permission of the Apache Software Foundation.
*
* THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
* WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
* OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
* DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
* ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
* LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
* USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
* ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
* OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
* OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
*
* 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/.
*
*/
package org.apache.commons.collections.buffer;
import java.util.ArrayList;
import
Re: [collections] BinaryHeap and PriorityQueue
I have made the following changes: - PriorityQueue now disapproved (not deprecated, but the language indicates it is) - BinaryHeap in main package is not deprecated, as it is the only implementation of PQ - BinaryHeap in buffer subpackage renamed to BinaryBuffer. No longer implements PQ - PQ decorators now inner classes of PQUtils We could go further and actually deprecated PQ. But I'm a little wary of that. (And both BinaryHeap and BinaryBuffer still need their remove bug fixing :-) Stephen - Original Message - From: Stephen Colebourne [EMAIL PROTECTED] BinaryHeap is a very old collections class, originally from Avalon. It implements PriorityQueue interface. PQ is an interface that does not extend Collection, Buffer is effectively the replacement that does. They use different terms though - PQ insert/peek/pop - Buffer add/get/remove. PQ is also badly named as the interface specifies nothing about 'priority'. Currently I have moved BinaryHeap and the PriorityQueue decorators into the buffer subpackage (as they seem related). But is this right??? Possibilities: a) BinaryHeap and PQ decorators in buffer subpackage b) BinaryHeap and PQ decorators in (new) priorityqueue subpackage c) BinaryHeap left in main package where it always was, PQ decorators as hidden inner classes on PriorityQueueUtils. I think I favour (c), as I'm not a fan of the PQ interface, and this would avoid change for this dubious (but probably useful) class/interface. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-commons/collections/src/java/org/apache/commons/collections BinaryHeap.java
[EMAIL PROTECTED] wrote: scolebourne2004/01/01 11:00:20 Modified:collections/src/java/org/apache/commons/collections BinaryHeap.java Log: Undeprecate, as is only implementation of PriorityQueue What is the plan here? We don't want to maintain two implementations, do we? In particular, shall I apply the fix for PR #25818 to both classes? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/collections/src/java/org/apache/commons/collections/buffer BoundedFifoBuffer.java UnboundedFifoBuffer.java
scolebourne2004/01/01 11:24:46
Modified:collections/src/java/org/apache/commons/collections/buffer
BoundedFifoBuffer.java UnboundedFifoBuffer.java
Log:
Apply collection coding standards
Revision ChangesPath
1.4 +46 -42
jakarta-commons/collections/src/java/org/apache/commons/collections/buffer/BoundedFifoBuffer.java
Index: BoundedFifoBuffer.java
===
RCS file:
/home/cvs/jakarta-commons/collections/src/java/org/apache/commons/collections/buffer/BoundedFifoBuffer.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- BoundedFifoBuffer.java28 Dec 2003 16:36:48 - 1.3
+++ BoundedFifoBuffer.java1 Jan 2004 19:24:46 - 1.4
@@ -100,10 +100,10 @@
public class BoundedFifoBuffer extends AbstractCollection
implements Buffer, BoundedCollection {
-private final Object[] m_elements;
-private int m_start = 0;
-private int m_end = 0;
-private boolean m_full = false;
+private final Object[] elements;
+private int start = 0;
+private int end = 0;
+private boolean full = false;
private final int maxElements;
/**
@@ -125,8 +125,8 @@
if (size = 0) {
throw new IllegalArgumentException(The size must be greater than 0);
}
-m_elements = new Object[size];
-maxElements = m_elements.length;
+elements = new Object[size];
+maxElements = elements.length;
}
/**
@@ -150,12 +150,12 @@
public int size() {
int size = 0;
-if (m_end m_start) {
-size = maxElements - m_start + m_end;
-} else if (m_end == m_start) {
-size = (m_full ? maxElements : 0);
+if (end start) {
+size = maxElements - start + end;
+} else if (end == start) {
+size = (full ? maxElements : 0);
} else {
-size = m_end - m_start;
+size = end - start;
}
return size;
@@ -192,10 +192,10 @@
* Clears this buffer.
*/
public void clear() {
-m_full = false;
-m_start = 0;
-m_end = 0;
-Arrays.fill(m_elements, null);
+full = false;
+start = 0;
+end = 0;
+Arrays.fill(elements, null);
}
/**
@@ -211,18 +211,18 @@
throw new NullPointerException(Attempted to add null object to
buffer);
}
-if (m_full) {
+if (full) {
throw new BufferOverflowException(The buffer cannot hold more than +
maxElements + objects.);
}
-m_elements[m_end++] = element;
+elements[end++] = element;
-if (m_end = maxElements) {
-m_end = 0;
+if (end = maxElements) {
+end = 0;
}
-if (m_end == m_start) {
-m_full = true;
+if (end == start) {
+full = true;
}
return true;
@@ -239,7 +239,7 @@
throw new BufferUnderflowException(The buffer is already empty);
}
-return m_elements[m_start];
+return elements[start];
}
/**
@@ -253,16 +253,16 @@
throw new BufferUnderflowException(The buffer is already empty);
}
-Object element = m_elements[m_start];
+Object element = elements[start];
if (null != element) {
-m_elements[m_start++] = null;
+elements[start++] = null;
-if (m_start = maxElements) {
-m_start = 0;
+if (start = maxElements) {
+start = 0;
}
-m_full = false;
+full = false;
}
return element;
@@ -304,28 +304,32 @@
public Iterator iterator() {
return new Iterator() {
-private int index = m_start;
+private int index = start;
private int lastReturnedIndex = -1;
-private boolean isFirst = m_full;
+private boolean isFirst = full;
public boolean hasNext() {
-return isFirst || (index != m_end);
+return isFirst || (index != end);
}
public Object next() {
-if (!hasNext()) throw new NoSuchElementException();
+if (!hasNext()) {
+throw new NoSuchElementException();
+}
isFirst = false;
lastReturnedIndex = index;
index = increment(index);
-return m_elements[lastReturnedIndex];
Re: cvs commit: jakarta-commons/collections/src/java/org/apache/commons/collections BinaryHeap.java
See other thread;-) - Original Message - From: Phil Steitz [EMAIL PROTECTED] To: Jakarta Commons Developers List [EMAIL PROTECTED] Sent: Thursday, January 01, 2004 7:11 PM Subject: Re: cvs commit: jakarta-commons/collections/src/java/org/apache/commons/collections BinaryHeap.java [EMAIL PROTECTED] wrote: scolebourne2004/01/01 11:00:20 Modified:collections/src/java/org/apache/commons/collections BinaryHeap.java Log: Undeprecate, as is only implementation of PriorityQueue What is the plan here? We don't want to maintain two implementations, do we? In particular, shall I apply the fix for PR #25818 to both classes? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] BinaryHeap and PriorityQueue
Sorry to respond first to the commit message (must be all the oversight talk ;) See interspersed. Stephen Colebourne wrote: I have made the following changes: - PriorityQueue now disapproved (not deprecated, but the language indicates it is) - BinaryHeap in main package is not deprecated, as it is the only implementation of PQ - BinaryHeap in buffer subpackage renamed to BinaryBuffer. No longer implements PQ It might be better named something like PriorityBuffer since that matches the behavior. - PQ decorators now inner classes of PQUtils We could go further and actually deprecated PQ. But I'm a little wary of that. We should decide whether or not Queue implementations belong in [collections]. I am +0 on this (the + is because BinaryHeap/Buffer exists). If no, we should deprecate. See below. (And both BinaryHeap and BinaryBuffer still need their remove bug fixing :-) As noted in bug report, I have a fix ready to commit. What I don't like about the setup above is that this and all other fixes / enhancements need to be applied to both classes. Stephen - Original Message - From: Stephen Colebourne [EMAIL PROTECTED] BinaryHeap is a very old collections class, originally from Avalon. It implements PriorityQueue interface. PQ is an interface that does not extend Collection, Buffer is effectively the replacement that does. They use different terms though - PQ insert/peek/pop - Buffer add/get/remove. PQ is also badly named as the interface specifies nothing about 'priority'. Ack. Maybe should just be called Queue. As noted below, however, the only impl in [collections] is a heap-backed priority queue. Currently I have moved BinaryHeap and the PriorityQueue decorators into the buffer subpackage (as they seem related). But is this right??? Sorry to respond late on this, but it does not seem right to me. I see the BinaryHeap/Buffer impl as a array-heap-backed implementation of a priority queue. The interface is a Queue interface, which, as you point out is different from a buffer interface. Possibilities: a) BinaryHeap and PQ decorators in buffer subpackage b) BinaryHeap and PQ decorators in (new) priorityqueue subpackage c) BinaryHeap left in main package where it always was, PQ decorators as hidden inner classes on PriorityQueueUtils. I think I favour (c), as I'm not a fan of the PQ interface, and this would avoid change for this dubious (but probably useful) class/interface. Here is a logical alternative: 1) Deprecate PriorityQueue interface in favor of Queue. 2) Create a queue package and put BinaryHeap there (maybe renamed something like HeapPriorityQueue or BinaryPriorityQueue or even PriorityQueue). This would open the door for other queue implementations. I understand that this departs from the general pattern of sticking with things that extend collection, but it is more natural to me at least. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Next Steps - WAS Re: [net] VMSFTPEntryParser bug?
I believe it just produces 1.1 compatible class files. Maven just passes the setting to the ant task, which passes it to javac. Since the HashMap class is is not present under 1.1 I guess we'd just get a ClassNotFoundException. I believe that should be all we need, we shouldn't need to *compile* with the javac from 1.1, we just need to use classes that are present with 1.1 and produce 1.1 compatible classes ( byte codes ). On Thu, 01 Jan 2004 10:57:24 -0600, steve cohen [EMAIL PROTECTED] said: On Thursday 01 January 2004 09:06 am, Jeffrey D. Brekke wrote: Maven uses the following property: maven.compiler.target which defaults to 1.1 so what I last released generated 1.1 compatible class files. http://maven.apache.org/reference/plugins/java/properties.html Example: maven -Dmaven.compiler.target=1.2 clean jar Then I don't understand why I was able to build, since HashMap is not in 1.1. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- = Jeffrey D. Brekke [EMAIL PROTECTED] Wisconsin, USA [EMAIL PROTECTED] [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/net/src/java/org/apache/commons/net/ftp/parser VMSFTPEntryParser.java
scohen 2004/01/01 12:49:49
Modified:net/src/java/examples ExtendedNNTPOps.java
net/src/java/org/apache/commons/net/ftp/parser
VMSFTPEntryParser.java
Log:
refactor back to JDK 1.1 compatibility.
HashMap - Hashtable
ArrayList - [] or use StringTokenizer to avoid having to fall back to deprecated
methods in ORO.
Revision ChangesPath
1.3 +8 -5 jakarta-commons/net/src/java/examples/ExtendedNNTPOps.java
Index: ExtendedNNTPOps.java
===
RCS file: /home/cvs/jakarta-commons/net/src/java/examples/ExtendedNNTPOps.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- ExtendedNNTPOps.java 23 Sep 2003 02:53:56 - 1.2
+++ ExtendedNNTPOps.java 1 Jan 2004 20:49:48 - 1.3
@@ -58,7 +58,6 @@
import java.io.IOException;
import java.io.Reader;
import java.io.PrintWriter;
-import java.util.ArrayList;
import java.util.StringTokenizer;
import org.apache.commons.net.io.DotTerminatedMessageReader;
@@ -143,9 +142,8 @@
int highArticleNumber)
throws IOException
{
-ArrayList articles = new ArrayList();
Reader reader = null;
-
+Article[] articles = new Article[0];
reader = (DotTerminatedMessageReader)
client.retrieveArticleInfo(lowArticleNumber, highArticleNumber);
@@ -156,6 +154,11 @@
// Extract the article information
// Mandatory format (from NNTP RFC 2980) is :
// Subject\tAuthor\tDate\tID\tReference(s)\tByte Count\tLine Count
+
+int count = st.countTokens();
+articles = new Article[count];
+int index = 0;
+
while (st.hasMoreTokens()) {
StringTokenizer stt = new StringTokenizer(st.nextToken(), \t);
Article article = new Article();
@@ -165,13 +168,13 @@
article.setDate(stt.nextToken());
article.setArticleId(stt.nextToken());
article.addHeaderField(References, stt.nextToken());
-articles.add(article);
+articles[index++] = article;
}
} else {
return null;
}
-return (Article[]) articles.toArray(new Article[articles.size()]);
+return articles;
}
private String readerToString(Reader reader)
1.9 +18 -14
jakarta-commons/net/src/java/org/apache/commons/net/ftp/parser/VMSFTPEntryParser.java
Index: VMSFTPEntryParser.java
===
RCS file:
/home/cvs/jakarta-commons/net/src/java/org/apache/commons/net/ftp/parser/VMSFTPEntryParser.java,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- VMSFTPEntryParser.java30 Dec 2003 03:58:52 - 1.8
+++ VMSFTPEntryParser.java1 Jan 2004 20:49:48 - 1.9
@@ -3,7 +3,7 @@
/*
* The Apache Software License, Version 1.1
*
- * Copyright (c) 2001 The Apache Software Foundation. All rights
+ * Copyright (c) 2004 The Apache Software Foundation. All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
@@ -55,8 +55,9 @@
*/
import java.util.Calendar;
-import java.util.HashMap;
-import java.util.ArrayList;
+import java.util.Enumeration;
+import java.util.Hashtable;
+import java.util.StringTokenizer;
import java.io.BufferedReader;
import java.io.ByteArrayInputStream;
import java.io.IOException;
@@ -209,7 +210,7 @@
files = super.parseFileList(listingStream);
} else {
FTPFile[] tempFiles = super.parseFileList(listingStream);
-HashMap filesHash = new HashMap();
+Hashtable filesHash = new Hashtable();
String fileName;
for (int index = 0; index tempFiles.length; index++) {
@@ -218,8 +219,14 @@
filesHash.put(fileName, (FTPFile) tempFiles[index]);
}
}
+files = new FTPFile[filesHash.size()];
+Enumeration e = filesHash.keys();
+int index = 0;
+while (e.hasMoreElements()) {
+FTPFile ftpf = (FTPFile) filesHash.get(e.nextElement());
+files[index++] = ftpf;
+}
-files = (FTPFile[]) filesHash.values().toArray(new FTPFile[0]);
}
return files;
@@ -256,18 +263,15 @@
String owner = group(9);
String grp;
String user;
-
Re: Next Steps - WAS Re: [net] VMSFTPEntryParser bug?
Yes, in order to verify that the code doesn't use any 1.2+ code I found that
you have to also use bootclasspath={path to jdk1.1.8 classes.zip}
There were a couple of other instances:
use of ArrayLists in VMSFTPEntryParser and in ExtendedNNTPOps.java
in the examples section.
I cleaned all of these up and committed them. In the case of the ArrayList in
VMSFTPEntryParser, it did not work to change the file container to a Vector.
This code was calling a method in ORO that returned a Collection, also not
JDK1.1 compatible. Since the older ORO method that returned a Vector had
been deprecated, I looked at what it was doing, which was simply splitting a
string on a comma. This was an overkill use of ORO, easily replicated with a
StringTokenizer.
Talk about a stroll down memory lane!
On Thursday 01 January 2004 02:18 pm, Jeffrey D. Brekke wrote:
I believe it just produces 1.1 compatible class files. Maven just
passes the setting to the ant task, which passes it to javac. Since
the HashMap class is is not present under 1.1 I guess we'd just get a
ClassNotFoundException.
I believe that should be all we need, we shouldn't need to *compile*
with the javac from 1.1, we just need to use classes that are present
with 1.1 and produce 1.1 compatible classes ( byte codes ).
On Thu, 01 Jan 2004 10:57:24 -0600, steve cohen
[EMAIL PROTECTED] said:
On Thursday 01 January 2004 09:06 am, Jeffrey D. Brekke wrote:
Maven uses the following property: maven.compiler.target which
defaults to 1.1 so what I last released generated 1.1 compatible
class files.
http://maven.apache.org/reference/plugins/java/properties.html
Example: maven -Dmaven.compiler.target=1.2 clean jar
Then I don't understand why I was able to build, since HashMap is
not in 1.1.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/net/src/test/org/apache/commons/net/ftp/parser EnterpriseUnixFTPEntryParserTest.java FTPParseTestFramework.java NTFTPEntryParserTest.java OS2FTPEntryParserTest.java UnixFTPEntryParserTest.java VMSFTPEntryParserTest.java
scohen 2004/01/01 13:04:22 Modified:net/proposal/ftp2/src/java/org/apache/commons/net/ftp/ftp2 FTPClient2.java FTPFileEntryParser.java FTPFileIterator.java FTPFileList.java net/proposal/ftp2/src/java/org/apache/commons/net/ftp/ftp2/parser AIXFTPEntryParser.java EnterpriseUnixFTPEntryParser.java MatchApparatus.java NTFTPEntryParser.java OS2FTPEntryParser.java UnixFTPEntryParser.java VMSFTPEntryParser.java net/proposal/ftp2/src/test/org/apache/commons/net/ftp/ftp2/parser EnterpriseUnixFTPEntryParserTest.java FTPParseTestFramework.java NTFTPEntryParserTest.java OS2FTPEntryParserTest.java UnixFTPEntryParserTest.java VMSFTPEntryParserTest.java net/src/java/examples IOUtil.java PrintCommandListener.java chargen.java daytime.java echo.java finger.java ftp.java fwhois.java mail.java messages.java newsgroups.java post.java rdate.java rexec.java rlogin.java rshell.java server2serverFTP.java tftp.java weatherTelnet.java net/src/java/org/apache/commons/net CharGenTCPClient.java CharGenUDPClient.java DatagramSocketClient.java DatagramSocketFactory.java DaytimeTCPClient.java DaytimeUDPClient.java DefaultDatagramSocketFactory.java DefaultSocketFactory.java DiscardTCPClient.java DiscardUDPClient.java EchoTCPClient.java EchoUDPClient.java FingerClient.java MalformedServerReplyException.java ProtocolCommandEvent.java ProtocolCommandListener.java ProtocolCommandSupport.java SocketClient.java SocketFactory.java TimeTCPClient.java TimeUDPClient.java WhoisClient.java net/src/java/org/apache/commons/net/bsd RCommandClient.java RExecClient.java RLoginClient.java net/src/java/org/apache/commons/net/ftp DefaultFTPFileListParser.java FTP.java FTPClient.java FTPCommand.java FTPConnectionClosedException.java FTPFile.java FTPFileEntryParser.java FTPFileIterator.java FTPFileList.java FTPFileListParser.java FTPFileListParserImpl.java FTPReply.java net/src/java/org/apache/commons/net/ftp/parser EnterpriseUnixFTPEntryParser.java NTFTPEntryParser.java OS2FTPEntryParser.java UnixFTPEntryParser.java net/src/java/org/apache/commons/net/io CopyStreamAdapter.java CopyStreamEvent.java CopyStreamException.java CopyStreamListener.java DotTerminatedMessageReader.java DotTerminatedMessageWriter.java FromNetASCIIInputStream.java FromNetASCIIOutputStream.java SocketInputStream.java SocketOutputStream.java ToNetASCIIInputStream.java ToNetASCIIOutputStream.java Util.java net/src/java/org/apache/commons/net/nntp ArticlePointer.java NNTP.java NNTPClient.java NNTPCommand.java NNTPConnectionClosedException.java NNTPReply.java NewGroupsOrNewsQuery.java NewsgroupInfo.java SimpleNNTPHeader.java net/src/java/org/apache/commons/net/pop3 POP3.java POP3Client.java POP3Command.java POP3MessageInfo.java POP3Reply.java net/src/java/org/apache/commons/net/smtp RelayPath.java SMTP.java SMTPClient.java SMTPCommand.java SMTPConnectionClosedException.java SMTPReply.java SimpleSMTPHeader.java net/src/java/org/apache/commons/net/telnet TelnetCommand.java TelnetOption.java TelnetOutputStream.java net/src/java/org/apache/commons/net/tftp TFTP.java TFTPAckPacket.java TFTPClient.java TFTPDataPacket.java TFTPErrorPacket.java TFTPPacket.java TFTPPacketException.java TFTPReadRequestPacket.java TFTPRequestPacket.java
cvs commit: jakarta-commons/net/src/java/examples ExtendedNNTPOps.java TelnetClientExample.java
scohen 2004/01/01 13:31:21 Modified:net/src/java/examples ExtendedNNTPOps.java TelnetClientExample.java Log: more copyright date changes Revision ChangesPath 1.4 +1 -1 jakarta-commons/net/src/java/examples/ExtendedNNTPOps.java Index: ExtendedNNTPOps.java === RCS file: /home/cvs/jakarta-commons/net/src/java/examples/ExtendedNNTPOps.java,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- ExtendedNNTPOps.java 1 Jan 2004 20:49:48 - 1.3 +++ ExtendedNNTPOps.java 1 Jan 2004 21:31:21 - 1.4 @@ -1,7 +1,7 @@ /* * The Apache Software License, Version 1.1 * - * Copyright (c) 2001 The Apache Software Foundation. All rights + * Copyright (c) 2004 The Apache Software Foundation. All rights * reserved. * * Redistribution and use in source and binary forms, with or without 1.4 +1 -1 jakarta-commons/net/src/java/examples/TelnetClientExample.java Index: TelnetClientExample.java === RCS file: /home/cvs/jakarta-commons/net/src/java/examples/TelnetClientExample.java,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- TelnetClientExample.java 10 Aug 2003 09:22:25 - 1.3 +++ TelnetClientExample.java 1 Jan 2004 21:31:21 - 1.4 @@ -3,7 +3,7 @@ /* * The Apache Software License, Version 1.1 * - * Copyright (c) 2003 The Apache Software Foundation. All rights + * Copyright (c) 2004 The Apache Software Foundation. All rights * reserved. * * Redistribution and use in source and binary forms, with or without - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[net] Tag NET_1_1_1 created
This is the version with all JDK 1.1 incompatible code dumbed down to the 1.1.8 level. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] BinaryHeap and PriorityQueue
We could go further and actually deprecated PQ. But I'm a little wary of that. We should decide whether or not Queue implementations belong in [collections]. I am +0 on this (the + is because BinaryHeap/Buffer exists). If no, we should deprecate. See below. (And both BinaryHeap and BinaryBuffer still need their remove bug fixing :-) As noted in bug report, I have a fix ready to commit. What I don't like about the setup above is that this and all other fixes / enhancements need to be applied to both classes. I am happy for Buffer to exist in [collections] (although I wish the methods were peek and pop) Given a choice I would deprecate PQ altogether. Your change will need to be applied to both BinaryBuffer and BinaryHeap, unless we make BinaryHeap wrap a BinaryBuffer (maintaining the old interface). I am +1 on renaming to PriorityBuffer. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] BinaryHeap and PriorityQueue
Stephen Colebourne wrote: I am happy for Buffer to exist in [collections] (although I wish the methods were peek and pop) Yeah. Like a queue ;-). Given a choice I would deprecate PQ altogether. That would make things simpler. Your change will need to be applied to both BinaryBuffer and BinaryHeap, unless we make BinaryHeap wrap a BinaryBuffer (maintaining the old interface). For now, I am making the change to both (and both tests). I would like to consider, however either a) deprecate both PQ and BinaryHeap (rationale: we implement what are effectivley queues in the buffer package) b) change BinaryHeap to wrap a BinaryBuffer I guess I ultimately favor a). I am +1 on renaming to PriorityBuffer. I agree. Phil Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/collections/src/test/org/apache/commons/collections/buffer TestBinaryBuffer.java
psteitz 2004/01/01 15:56:51
Modified:collections/src/java/org/apache/commons/collections
BinaryHeap.java
collections/src/java/org/apache/commons/collections/buffer
BinaryBuffer.java
collections/src/test/org/apache/commons/collections
TestBinaryHeap.java
collections/src/test/org/apache/commons/collections/buffer
TestBinaryBuffer.java
Log:
Fixed BinaryHeap / BinaryBuffer remove(object) bug.
PR #25818
Reported by: Steve Phelps
Revision ChangesPath
1.17 +70 -28
jakarta-commons/collections/src/java/org/apache/commons/collections/BinaryHeap.java
Index: BinaryHeap.java
===
RCS file:
/home/cvs/jakarta-commons/collections/src/java/org/apache/commons/collections/BinaryHeap.java,v
retrieving revision 1.16
retrieving revision 1.17
diff -u -r1.16 -r1.17
--- BinaryHeap.java 1 Jan 2004 19:00:20 - 1.16
+++ BinaryHeap.java 1 Jan 2004 23:56:51 - 1.17
@@ -4,7 +4,7 @@
*
* The Apache Software License, Version 1.1
*
- * Copyright (c) 2001-2003 The Apache Software Foundation. All rights
+ * Copyright (c) 2001-2004 The Apache Software Foundation. All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
@@ -319,8 +319,9 @@
}
/**
- * Percolates element down heap from top.
- * Assume it is a maximum heap.
+ * Percolates element down heap from the position given by the index.
+ * p
+ * Assumes it is a mimimum heap.
*
* @param index the index for the element
*/
@@ -350,8 +351,9 @@
}
/**
- * Percolates element down heap from top.
- * Assume it is a maximum heap.
+ * Percolates element down heap from the position given by the index.
+ * p
+ * Assumes it is a maximum heap.
*
* @param index the index of the element
*/
@@ -381,16 +383,15 @@
}
/**
- * Percolates element up heap from bottom.
- * Assume it is a maximum heap.
+ * Percolates element up heap from the position given by the index.
+ * p
+ * Assumes it is a minimum heap.
*
- * @param element the element
+ * @param index the index of the element to be percolated up
*/
-protected void percolateUpMinHeap(final Object element) {
-int hole = ++m_size;
-
-m_elements[hole] = element;
-
+protected void percolateUpMinHeap(final int index) {
+int hole = index;
+Object element = m_elements[hole];
while (hole 1 compare(element, m_elements[hole / 2]) 0) {
// save element that is being pushed down
// as the element bubble is percolated up
@@ -398,19 +399,32 @@
m_elements[hole] = m_elements[next];
hole = next;
}
-
m_elements[hole] = element;
}
/**
- * Percolates element up heap from bottom.
- * Assume it is a maximum heap.
+ * Percolates a new element up heap from the bottom.
+ * p
+ * Assumes it is a minimum heap.
*
* @param element the element
*/
-protected void percolateUpMaxHeap(final Object element) {
-int hole = ++m_size;
+protected void percolateUpMinHeap(final Object element) {
+m_elements[++m_size] = element;
+percolateUpMinHeap(m_size);
+}
+/**
+ * Percolates element up heap from from the position given by the index.
+ * p
+ * Assume it is a maximum heap.
+ *
+ * @param element the element
+ */
+protected void percolateUpMaxHeap(final int index) {
+int hole = index;
+Object element = m_elements[hole];
+
while (hole 1 compare(element, m_elements[hole / 2]) 0) {
// save element that is being pushed down
// as the element bubble is percolated up
@@ -423,6 +437,18 @@
}
/**
+ * Percolates a new element up heap from the bottom.
+ * p
+ * Assume it is a maximum heap.
+ *
+ * @param element the element
+ */
+protected void percolateUpMaxHeap(final Object element) {
+m_elements[++m_size] = element;
+percolateUpMaxHeap(m_size);
+}
+
+/**
* Compares two objects using the comparator if specified, or the
* natural order otherwise.
*
@@ -494,18 +520,34 @@
}
public void remove() {
-if (lastReturnedIndex == -1) throw new IllegalStateException();
+if (lastReturnedIndex == -1) {
+throw new IllegalStateException();
+
cvs commit: jakarta-commons/collections project.xml
psteitz 2004/01/01 16:05:56 Modified:collections project.xml Log: Added Steve Phelps as contributor. Restored alpha sort order. Revision ChangesPath 1.22 +6 -3 jakarta-commons/collections/project.xml Index: project.xml === RCS file: /home/cvs/jakarta-commons/collections/project.xml,v retrieving revision 1.21 retrieving revision 1.22 diff -u -r1.21 -r1.22 --- project.xml 29 Dec 2003 18:52:01 - 1.21 +++ project.xml 2 Jan 2004 00:05:56 - 1.22 @@ -84,9 +84,6 @@ contributors contributor - nameJanek Bogucki/name -/contributor -contributor nameMax Rydahl Andersen/name /contributor contributor @@ -105,6 +102,9 @@ nameChristopher Berry/name /contributor contributor + nameJanek Bogucki/name +/contributor +contributor nameChuck Burdick/name /contributor contributor @@ -181,6 +181,9 @@ /contributor contributor nameKasper Nielsen/name +/contributor +contributor + nameSteve Phelps/name /contributor contributor nameIlkka Priha/name - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 25818] - BinaryHeap.remove(Object) seems to break heap order
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25818. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25818 BinaryHeap.remove(Object) seems to break heap order [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-01-02 00:35 --- Fixed in nightly builds starting 1/2/04. Modified iterator remove() to compare repositioned last element to its new parent to decide whether to percolate up or down. Added percolateUp methods with starting indexes to support this. Thanks, Steve, for reporting (and identifying the source of) this bug. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/collections LICENSE.txt
scolebourne2004/01/01 18:19:25 Modified:collections LICENSE.txt Log: New license for 2004 Revision ChangesPath 1.4 +2 -6 jakarta-commons/collections/LICENSE.txt Index: LICENSE.txt === RCS file: /home/cvs/jakarta-commons/collections/LICENSE.txt,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- LICENSE.txt 31 Aug 2003 17:30:27 - 1.3 +++ LICENSE.txt 2 Jan 2004 02:19:25 - 1.4 @@ -1,10 +1,7 @@ -/* - * $Header$ - * - * +/* * The Apache Software License, Version 1.1 * - * Copyright (c) 1999-2003 The Apache Software Foundation. All rights + * Copyright (c) 1999-2004 The Apache Software Foundation. All rights * reserved. * * Redistribution and use in source and binary forms, with or without @@ -53,5 +50,4 @@ * individuals on behalf of the Apache Software Foundation. For more * information on the Apache Software Foundation, please see * http://www.apache.org/. - * */ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[collections][lang] 2004
I am planning on running licence update scripts across [collections] and [lang]. Any objections to the all file approach? Every file will get the same copyright dates. Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections] BinaryHeap and PriorityQueue
Stephen Colebourne wrote: From: Phil Steitz [EMAIL PROTECTED] Stephen Colebourne wrote: Given a choice I would deprecate PQ altogether. That would make things simpler. If no one else comments, I'll do this. I am +1 on renaming to PriorityBuffer. Done I was also looking at the heap impl and wondering if the compare method could check for ascendingOrder, then removing the need for near duplicate methods (one for minHeap, one for maxHeap) elsewhere. Would this be a good change? That would simplify the code, but might cost something in overall performance (since compare is hot). Could be that's why the original author(s) set it up the way it is? Should be trivial. Might be worth playing with. Another solution would be to just have the constructor reverse the comparator for maxHeaps (using ComparatorUtils.reversedComparator). There the cost would be stack operations for each compare (calling through to the reversed comparator). Another (small?) consideration is backward compatability for anyone who has subclassed BinaryHeap (assuming we are not going to deprecate), since all of the percolateXxx methods are protected, not private. Phil Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections][lang] 2004
Stephen Colebourne wrote: I am planning on running licence update scripts across [collections] and [lang]. Any objections to the all file approach? Every file will get the same copyright dates. The guidlines here http://jakarta.apache.org/site/source.html say Committers should update the copyright notice on the Apache License to include the current year when they revise a source file. If it is 2002, and you revise a source file from 1999, change the copyright notice in the license to cite 1999, 2002. If the file was from 2001, we would change it to 2001-2002. And so forth. This will happen most often in the early part of a year, but maintenance of the copyright date should occur year-round, as needed. That would indicate to me that what we should be doing is updating the notices when we change files. One thing that we probably do *not* want to do is to just replace the 2003 references with 2004, since that would make the files from 2003 look like their protection began in 2004. Is there an ASF policy on this? Phil Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections][lang] 2004
Aw, phooey. I just changed the dates on all the commons-net classes. Wish I had seen these instructions beforehand. On the other hand, with one exception they all contained 2001, which, as far as I can recall, was before these classes came under the Jakarta umbrella. If memory serves, they entered the Sandbox in 2002 and Commons proper in 2003. On Thursday 01 January 2004 09:14 pm, Phil Steitz wrote: Stephen Colebourne wrote: I am planning on running licence update scripts across [collections] and [lang]. Any objections to the all file approach? Every file will get the same copyright dates. The guidlines here http://jakarta.apache.org/site/source.html say Committers should update the copyright notice on the Apache License to include the current year when they revise a source file. If it is 2002, and you revise a source file from 1999, change the copyright notice in the license to cite 1999, 2002. If the file was from 2001, we would change it to 2001-2002. And so forth. This will happen most often in the early part of a year, but maintenance of the copyright date should occur year-round, as needed. That would indicate to me that what we should be doing is updating the notices when we change files. One thing that we probably do *not* want to do is to just replace the 2003 references with 2004, since that would make the files from 2003 look like their protection began in 2004. Is there an ASF policy on this? Phil Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/net/src/test/org/apache/commons/net/telnet EchoOptionHandlerTest.java InvalidTelnetOptionExceptionTest.java SimpleOptionHandlerTest.java SuppressGAOptionHandlerTest.java TelnetClientFunctionalTest.java TelnetClientTest.java TelnetOptionHandlerTestAbstract.java TelnetOptionTest.java TelnetTestResponder.java TelnetTestSimpleServer.java TerminalTypeOptionHandlerTest.java
scohen 2004/01/01 19:39:07 Modified:net/proposal/ftp2/src/java/org/apache/commons/net/ftp/ftp2 FTPClient2.java FTPFileEntryParser.java FTPFileIterator.java FTPFileList.java net/proposal/ftp2/src/java/org/apache/commons/net/ftp/ftp2/parser AIXFTPEntryParser.java EnterpriseUnixFTPEntryParser.java MatchApparatus.java NTFTPEntryParser.java OS2FTPEntryParser.java UnixFTPEntryParser.java VMSFTPEntryParser.java net/proposal/ftp2/src/test/org/apache/commons/net/ftp/ftp2/parser EnterpriseUnixFTPEntryParserTest.java FTPParseTestFramework.java NTFTPEntryParserTest.java OS2FTPEntryParserTest.java UnixFTPEntryParserTest.java VMSFTPEntryParserTest.java net/src/java/examples ExtendedNNTPOps.java IOUtil.java PrintCommandListener.java TelnetClientExample.java chargen.java daytime.java echo.java finger.java ftp.java fwhois.java mail.java messages.java newsgroups.java post.java rdate.java rexec.java rlogin.java rshell.java server2serverFTP.java tftp.java weatherTelnet.java net/src/java/org/apache/commons/net CharGenTCPClient.java CharGenUDPClient.java DatagramSocketClient.java DatagramSocketFactory.java DaytimeTCPClient.java DaytimeUDPClient.java DefaultDatagramSocketFactory.java DefaultSocketFactory.java DiscardTCPClient.java DiscardUDPClient.java EchoTCPClient.java EchoUDPClient.java FingerClient.java MalformedServerReplyException.java ProtocolCommandEvent.java ProtocolCommandListener.java ProtocolCommandSupport.java SocketClient.java SocketFactory.java TimeTCPClient.java TimeUDPClient.java WhoisClient.java net/src/java/org/apache/commons/net/bsd RCommandClient.java RExecClient.java RLoginClient.java net/src/java/org/apache/commons/net/ftp DefaultFTPFileListParser.java FTP.java FTPClient.java FTPCommand.java FTPConnectionClosedException.java FTPFile.java FTPFileEntryParser.java FTPFileIterator.java FTPFileList.java FTPFileListParser.java FTPFileListParserImpl.java FTPReply.java net/src/java/org/apache/commons/net/ftp/parser EnterpriseUnixFTPEntryParser.java NTFTPEntryParser.java OS2FTPEntryParser.java UnixFTPEntryParser.java VMSFTPEntryParser.java net/src/java/org/apache/commons/net/io CopyStreamAdapter.java CopyStreamEvent.java CopyStreamException.java CopyStreamListener.java DotTerminatedMessageReader.java DotTerminatedMessageWriter.java FromNetASCIIInputStream.java FromNetASCIIOutputStream.java SocketInputStream.java SocketOutputStream.java ToNetASCIIInputStream.java ToNetASCIIOutputStream.java Util.java net/src/java/org/apache/commons/net/nntp ArticlePointer.java NNTP.java NNTPClient.java NNTPCommand.java NNTPConnectionClosedException.java NNTPReply.java NewGroupsOrNewsQuery.java NewsgroupInfo.java SimpleNNTPHeader.java net/src/java/org/apache/commons/net/pop3 POP3.java POP3Client.java POP3Command.java POP3MessageInfo.java POP3Reply.java net/src/java/org/apache/commons/net/smtp RelayPath.java SMTP.java SMTPClient.java SMTPCommand.java SMTPConnectionClosedException.java SMTPReply.java SimpleSMTPHeader.java net/src/java/org/apache/commons/net/telnet EchoOptionHandler.java InvalidTelnetOptionException.java SimpleOptionHandler.java SuppressGAOptionHandler.java Telnet.java TelnetClient.java TelnetCommand.java TelnetInputStream.java
Re: [collections][lang] 2004
On Thu, 1 Jan 2004, Phil Steitz wrote: Stephen Colebourne wrote: I am planning on running licence update scripts across [collections] and [lang]. Any objections to the all file approach? Every file will get the same copyright dates. The guidlines here http://jakarta.apache.org/site/source.html say Committers should update the copyright notice on the Apache License to include the current year when they revise a source file. If it is 2002, and you revise a source file from 1999, change the copyright notice in the license to cite 1999, 2002. If the file was from 2001, we would change it to 2001-2002. And so forth. This will happen most often in the early part of a year, but maintenance of the copyright date should occur year-round, as needed. That would indicate to me that what we should be doing is updating the notices when we change files. One thing that we probably do *not* want to do is to just replace the 2003 references with 2004, since that would make the files from 2003 look like their protection began in 2004. Is there an ASF policy on this? I'm not aware of an ASF policy per se, but what you quote above is correct according to (US and, I believe, UK) copyright law, and is what all of my employers, past and present, have required. -- Martin Cooper Phil Stephen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections][lang] 2004
On Thu, 1 Jan 2004, Phil Steitz wrote: notices when we change files. One thing that we probably do *not* want to do is to just replace the 2003 references with 2004, since that would make the files from 2003 look like their protection began in 2004. I assume we'd replace -2003 with -2004. So not a problem, then ([^-])2003 with \12003-2004 perhaps to add those on. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/io/src/test/org/apache/commons/io IOUtilsTestCase.java
bayard 2004/01/01 22:18:40
Modified:io/src/test/org/apache/commons/io IOUtilsTestCase.java
Log:
removed test cases that only test CopyUtils methods, as these methods now have their
own tests in the CopyUtilsTest class
Revision ChangesPath
1.7 +3 -101
jakarta-commons-sandbox/io/src/test/org/apache/commons/io/IOUtilsTestCase.java
Index: IOUtilsTestCase.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/io/src/test/org/apache/commons/io/IOUtilsTestCase.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- IOUtilsTestCase.java 30 Dec 2003 15:26:59 - 1.6
+++ IOUtilsTestCase.java 2 Jan 2004 06:18:40 - 1.7
@@ -139,54 +139,6 @@
assertTrue( Content not equal according to java.util.Arrays#equals(),
Arrays.equals( b0, b1 ) );
}
-public void testInputStreamToOutputStream()
-throws Exception
-{
-File destination = newFile( copy1.txt );
-FileInputStream fin = new FileInputStream( m_testFile );
-try {
-FileOutputStream fout = new FileOutputStream( destination );
-try {
-int count = CopyUtils.copy( fin, fout );
-assertTrue( Not all bytes were read, fin.available() == 0 );
-assertEquals( Number of bytes read should equal file size,
m_testFile.length(), count );
-fout.flush();
-
-checkFile( destination, m_testFile );
-checkWrite( fout );
-} finally {
-fout.close();
-}
-deleteFile( destination );
-} finally {
-fin.close();
-}
-}
-
-public void testInputStreamToWriter()
-throws Exception
-{
-File destination = newFile( copy2.txt );
-FileInputStream fin = new FileInputStream( m_testFile );
-try {
-FileWriter fout = new FileWriter( destination );
-try {
-CopyUtils.copy( fin, fout );
-
-assertTrue( Not all bytes were read, fin.available() == 0 );
-fout.flush();
-
-checkFile( destination, m_testFile );
-checkWrite( fout );
-} finally {
-fout.close();
-}
-deleteFile( destination );
-} finally {
- fin.close();
-}
-}
-
public void testInputStreamToString()
throws Exception
{
@@ -197,56 +149,6 @@
assertTrue( Not all bytes were read, fin.available() == 0 );
assertTrue( Wrong output size: out.length()= + out.length() +
!= + FILE_SIZE, out.length() == FILE_SIZE );
-} finally {
-fin.close();
-}
-}
-
-public void testReaderToOutputStream()
-throws Exception
-{
-File destination = newFile( copy3.txt );
-FileReader fin = new FileReader( m_testFile );
-try {
-FileOutputStream fout = new FileOutputStream( destination );
-try {
-CopyUtils.copy( fin, fout );
-//Note: this method *does* flush. It is equivalent to:
-// OutputStreamWriter _out = new OutputStreamWriter(fout);
-// CopyUtils.copy( fin, _out, 4096 ); // copy( Reader, Writer, int
);
-// _out.flush();
-// out = fout;
-
-// Note: rely on the method to flush
-checkFile( destination, m_testFile );
-checkWrite( fout );
-} finally {
-fout.close();
-}
-deleteFile( destination );
-} finally {
-fin.close();
-}
-}
-
-public void testReaderToWriter()
-throws Exception
-{
-File destination = newFile( copy4.txt );
-FileReader fin = new FileReader( m_testFile );
-try {
-FileWriter fout = new FileWriter( destination );
-try {
-int count = CopyUtils.copy( fin, fout );
-assertEquals( The number of characters returned by copy is wrong,
m_testFile.length(), count);
-
-fout.flush();
-checkFile( destination, m_testFile );
-checkWrite( fout );
-} finally {
-fout.close();
-}
-deleteFile( destination );
} finally {
fin.close();
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/io project.xml
bayard 2004/01/01 22:22:14 Modified:io project.xml Log: removed the IOUtilsTestCase unit test exclusion as it builds for me fine Revision ChangesPath 1.17 +0 -1 jakarta-commons-sandbox/io/project.xml Index: project.xml === RCS file: /home/cvs/jakarta-commons-sandbox/io/project.xml,v retrieving revision 1.16 retrieving revision 1.17 diff -u -r1.16 -r1.17 --- project.xml 29 Dec 2003 05:04:16 - 1.16 +++ project.xml 2 Jan 2004 06:22:14 - 1.17 @@ -183,7 +183,6 @@ /includes excludes exclude**/testtools/**/exclude -exclude**/IOUtilTestCase*/exclude /excludes resources - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/io/xdocs tasks.xml
bayard 2004/01/01 22:25:33 Modified:io/xdocs tasks.xml Log: unit test re-enabled Revision ChangesPath 1.13 +0 -1 jakarta-commons-sandbox/io/xdocs/tasks.xml Index: tasks.xml === RCS file: /home/cvs/jakarta-commons-sandbox/io/xdocs/tasks.xml,v retrieving revision 1.12 retrieving revision 1.13 diff -u -r1.12 -r1.13 --- tasks.xml 30 Dec 2003 17:30:53 - 1.12 +++ tasks.xml 2 Jan 2004 06:25:33 - 1.13 @@ -9,7 +9,6 @@ ul liFilenameUtils: This class is a big mess ATM. We need to clean it up./li liIOUtilsTestCase: Move copy tests over to CopyUtilsTestCase or kill them. [Hen]/li -liRe-enable test case for: IOUtilTestCase/li liWrite TestCases for: ul liEndianUtils - InputStream/OutputStream methods/li - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [collections][lang] 2004
Henri Yandell wrote: On Thu, 1 Jan 2004, Phil Steitz wrote: notices when we change files. One thing that we probably do *not* want to do is to just replace the 2003 references with 2004, since that would make the files from 2003 look like their protection began in 2004. I assume we'd replace -2003 with -2004. So not a problem, then ([^-])2003 with \12003-2004 perhaps to add those on. And 2001, 2003, etc. The problem is that I am not sure that blast updating when there is no change to the protected content is correct. I am not a lawyer, but my understanding is that the last date in the copyright notice should be the year when the content was last changed. I am -0 to doing a blast update. Phil Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/io/src/test/org/apache/commons/io EndianUtilsTest.java
bayard 2004/01/01 22:44:26
Modified:io/src/test/org/apache/commons/io EndianUtilsTest.java
Log:
Implemented tests for the unsigned methods and removed the todo comments
Revision ChangesPath
1.8 +13 -8
jakarta-commons-sandbox/io/src/test/org/apache/commons/io/EndianUtilsTest.java
Index: EndianUtilsTest.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/io/src/test/org/apache/commons/io/EndianUtilsTest.java,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- EndianUtilsTest.java 30 Dec 2003 15:26:59 - 1.7
+++ EndianUtilsTest.java 2 Jan 2004 06:44:26 - 1.8
@@ -136,6 +136,11 @@
assertEquals( 0x01, bytes[1] );
}
+public void testReadSwappedUnsignedShort() {
+byte[] bytes = new byte[] { 0x02, 0x01 };
+assertEquals( 0x0102, EndianUtils.readSwappedUnsignedShort( bytes, 0 )
);
+}
+
public void testReadSwappedInteger() {
byte[] bytes = new byte[] { 0x04, 0x03, 0x02, 0x01 };
int ln = EndianUtils.readSwappedInteger( bytes, 0 );
@@ -151,7 +156,10 @@
assertEquals( 0x01, bytes[3] );
}
-// TODO: public void testWriteUnsignedInteger
+public void testReadSwappedUnsignedInteger() {
+byte[] bytes = new byte[] { 0x04, 0x03, 0x02, 0x01 };
+assertEquals( 0x01020304L, EndianUtils.readSwappedUnsignedInteger(
bytes, 0 ) );
+}
public void testReadSwappedLong() {
byte[] bytes = new byte[] { 0x08, 0x07, 0x06, 0x05, 0x04, 0x03, 0x02, 0x01
};
@@ -211,9 +219,6 @@
/*
// TODO:
-
-// All readSwappedXxxx(byte[], int)
-// All writeSwappedXxxx(byte[], int, )
// All readSwappedXxxx(InputStream)
// All writeSwappedXxxx(OutputStream, )
*/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons-sandbox/io/src/test/org/apache/commons/io EndianUtilsTest.java
bayard 2004/01/01 22:44:54
Modified:io/src/test/org/apache/commons/io EndianUtilsTest.java
Log:
removed unnecessary line
Revision ChangesPath
1.9 +4 -5
jakarta-commons-sandbox/io/src/test/org/apache/commons/io/EndianUtilsTest.java
Index: EndianUtilsTest.java
===
RCS file:
/home/cvs/jakarta-commons-sandbox/io/src/test/org/apache/commons/io/EndianUtilsTest.java,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- EndianUtilsTest.java 2 Jan 2004 06:44:26 - 1.8
+++ EndianUtilsTest.java 2 Jan 2004 06:44:54 - 1.9
@@ -143,7 +143,6 @@
public void testReadSwappedInteger() {
byte[] bytes = new byte[] { 0x04, 0x03, 0x02, 0x01 };
-int ln = EndianUtils.readSwappedInteger( bytes, 0 );
assertEquals( 0x01020304, EndianUtils.readSwappedInteger( bytes, 0 ) );
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/codec LICENSE.txt
ggregory2004/01/01 22:52:40 Modified:codecLICENSE.txt Log: Fix license typo: Products derived from this software may not be called Apache, *Apache nor may Apache appear in their name [...] There is a double word in there. This LICENSE FILE is from the main Jakata Commons page. Revision ChangesPath 1.5 +3 -3 jakarta-commons/codec/LICENSE.txt Index: LICENSE.txt === RCS file: /home/cvs/jakarta-commons/codec/LICENSE.txt,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- LICENSE.txt 5 Oct 2003 21:45:49 - 1.4 +++ LICENSE.txt 2 Jan 2004 06:52:40 - 1.5 @@ -30,8 +30,8 @@ *from this software without prior written permission. For written *permission, please contact [EMAIL PROTECTED] * - * 5. Products derived from this software may not be called Apache, - *Apache nor may Apache appear in their name without prior + * 5. Products derived from this software may not be called Apache + *nor may Apache appear in their name without prior *written permission of the Apache Software Foundation. * * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED @@ -53,4 +53,4 @@ * information on the Apache Software Foundation, please see * http://www.apache.org/. * - */ + */ \ No newline at end of file - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-commons/codec LICENSE.txt
ggregory2004/01/01 22:53:49 Modified:codecLICENSE.txt Log: Copyright (c) 2001-2004. Revision ChangesPath 1.6 +1 -1 jakarta-commons/codec/LICENSE.txt Index: LICENSE.txt === RCS file: /home/cvs/jakarta-commons/codec/LICENSE.txt,v retrieving revision 1.5 retrieving revision 1.6 diff -u -r1.5 -r1.6 --- LICENSE.txt 2 Jan 2004 06:52:40 - 1.5 +++ LICENSE.txt 2 Jan 2004 06:53:49 - 1.6 @@ -3,7 +3,7 @@ * * The Apache Software License, Version 1.1 * - * Copyright (c) 2001-2003 The Apache Software Foundation. All rights + * Copyright (c) 2001-2004 The Apache Software Foundation. All rights * reserved. * * Redistribution and use in source and binary forms, with or without - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
