[
https://issues.apache.org/jira/browse/NET-115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12487624
]
Rich Stupek commented on NET-115:
-
I think the bug is that the stream is not flushed before being closed. You&#x
alone validation
framework by applications, since it allows for more flexibility when
analyzing ValidatorResult instances.
Thanks!
Rich
-Original Message-
From: Ted Husted [mailto:[EMAIL PROTECTED]
Sent: Sunday, June 06, 2004 7:39 AM
To: Jakarta Commons Developers List
Su
hasher.keysEqual(key1, key2);
}
...
}
Rich
--
Rich Dougherty
http://www.rd.gen.nz/
pgp0.pgp
Description: PGP signature
in practice because most JVM implementations
always show the same value, even in different threads. However, the
possibility exists that the Fast* classes won't work as expected in some
JVMs.
I'm not very will connected to the net right now, so I haven't been able to
verify this, bu
n the first call, but return null for all
successive calls. Thus it could only be used as an Iterator once, which
doesn't seem very useful to me.
Rich
--
Rich Dougherty
http://www.rd.gen.nz/
pgp0.pgp
Description: PGP signature
in the past (as I've discovered different options). I may be off
on a few details, but hopefully this should be enough to get you on your
way.
Rich
---
1. When you check the project out from the CVS repository view choose
something like "Check out as..." instead of "Check out
I don't fully understand the String.intern() method. I understand the
purpose, but to be able to call String.intern(), don't you need to
create a new instance of a String to then check if it has already been
created? (The same thought that Rich D had about his Interner class).
I th
amount of object creation.
Still, it can be handy since it allows you to perform comparisons based
on reference.
interner.intern(new Integer(x)) == interner.intern(new Integer(x))
And if you had enough objects that were equal(), it could still save you
memory.
Rich
pgp0.pgp
Descri
va.time, etc. I think that
decision was a good one, but that doesn't necessarily make it a good
design. :-)
Rich
signature.asc
Description: This is a digitally signed message part
, but I think it
is would be fine if it is planned carefully. For example, code in the
old position could be deprecated for version 3 and removed in version 4.
Rich
signature.asc
Description: This is a digitally signed message part
() {
> +return "ComparableComparator".hashCode();
> +}
You could make that a little bit clearer by making it a constant. ie
private static final HASH_CODE = "ComparableComparator".hashCode();
And it'll improve performance. ;-)
Rich
signature.asc
Description: This is a digitally signed message part
ld be merged with this
class or whether it should stand on its own.
Rich
signature.asc
Description: This is a digitally signed message part
e a copy of your working directory.
Rich
signature.asc
Description: This is a digitally signed message part
Here's a repost of a patch which will fix this. Note that the
reimplementation of java.util.LinkedList is necessary so we can override
node creation and deletion without using Sun's code.
Rich
--- Begin Message ---
(I'm reposting this, since I sent the original over eight hours ag
In other words we should probably get both to extend
LinkedList, or just leave both as normal Lists.
Rich
signature.asc
Description: This is a digitally signed message part
"2.2". This also required changes to several other test
cases which overrode the method.
BTW, what is the best way to submit a patch which includes new files? I used
'diff' with the -N option, is there a way using 'cvs diff'?
Rich
linkedlist-reimp.patch.gz
a
nice class to use for future adaptions to LinkedList. The
standard LinkedList is pretty much opaque to subclasses. This is good
for a public API, but it makes it pretty difficult to
extend. CommonsLinkedList might be useful to keep around as a package
visible class.
Rich
--
To unsubscribe, e-mai
sion. This allows version strings like
"2.1" or "2.2". This also required changes to several other test
cases which overrode the method.
Rich
linkedlist-reimp.patch.gz
Description: application/gzip
linkedlist-reimp-data.tar.gz
Description: application/gzip
--
To unsubscr
> Rich, can you declare either:
>
> a) declare that the implementation was not copied
> b) supply a reimplementation if it was
>
> Otherwise I will be forced (legally) to remove the code from CVS (which
> I don't really want to do ;-), don't you just love licencing
I was just
checking it past the list.
My (layperson) understanding says that we should check it out carefully.
Despite the fact that a linked list is a common data structure and despite
the fact that we've got a license to use the API, I don't think we're
allowed to redistribute
ot filter the values at
all. To me, all these approaches seem a lot clearer.
Rich
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
ill be immutable, whereas "readable" only
suggests that subclasses will be able to read its value.
Rich
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
issue a readInt call (to
> retreive the int compatibility version) before continuing
> deserialization.
I don't think the class was included in the last release, so hopefully
there are no compatibility issues.
Rich
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For a
difiable iterator implementation
hiding in CollectionUtils... oops. We don't need two class that do the
same thing so here's a patch to remove the old implementation.
Rich
duplicate-unmodifiableitr.patch
Description: Binary data
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTE
y're still very useful. That is perhaps a reason why not
to include a trie (as opposed to a more general prefix tree) in
[collections], but I'm not really sure.
> I think that the performance of a Trie implementation might be
> greatly increased by limiting the tail sort of recursion (if we make
> all tree-walking methods one deep).
Good point Jeff. I will look into doing this.
Rich
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
ierarchy of abstract classes. Should it be flattened? At the
moment I'm separating out storage of the transitions. This is nice,
but perhaps it clutters the package too much?
- Stephen has mentioned some sort of TrieUtils? Perhaps this should be
called PrefixMapUtils, or go into MapUtils.
Rich
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
x27;ve submitted could be
used i a suffix tree. Here are two links that show the relationship:
http://www.csse.monash.edu.au/~lloyd/tildeAlgDS/Tree/Suffix/
http://www.cs.mcgill.ca/~cs251/OldCourses/1997/topic7/
Rich
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Hi
This patch adds two methods to IteratorUtils which return unmodifiable
views of iterators. One wraps an Iterator, the other a ListIterator.
These methods are analogues to the methods for collections in the
java.util.Collections class.
Rich
unmodifiable-iterators.patch.gz
Description
ta structure. I couldn't find an implementation with a
suitable license anywhere, so I wrote my own. I found an
implementation in a servlet container written by someone at HP (open
source, with heavy restrictions) and one in LimeWire (GPL, not LGPL or
Apache). Also many implementations were too
there was any interest in getting an upload package in the jakarta
domain. There was talk of this when the filters project was first
mentioned, but nothing since. If you would like I can just send you the
upload filter.
Rich Catlett
Richard Frazer wrote:
> Just curious what the status o
Jason Hunter who I believe is part of the ASF has a whole api available
at servlets.com (I think). It's code from the oreilly book on servlets.
I don't know if it's a possibility, but maybe he could be persuaded to
change the liscense and put it under the apache umbrella
31 matches
Mail list logo
