On 08.07.2024 11:18, Julian Reschke wrote:
On 07.07.2024 17:12, Gary Gregory wrote:
We don't want to break binary compatibility within the 4.x release line.
Gary
...
Would we have to?
OK, so this is about the return values.
It's still unfortunate, because it makes it harder to convert
On 07.07.2024 17:12, Gary Gregory wrote:
We don't want to break binary compatibility within the 4.x release line.
Gary
...
Would we have to?
Best regards, Julian
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
you are correct. it was using some older transitive deps.. resolved. thank you
for your patience .
Sent: Sunday, July 07, 2024 at 11:12 AM
From: "Gary Gregory"
To: julian.resc...@gmx.de.invalid
Cc: "Commons Developers List"
Subject: Re: [collections] Predicate vs Pre
rn
> commons-collections3's Predicates.
>
> CC4 deprecates the custom Predicate class (good!), and these just extend
> JDK Predicates
> (
> https://commons.apache.org/proper/commons-collections/apidocs/org/apache/commons/collections4/Predicate.html
> ).
>
> However,
Absolutely true that same functionality can be achieved with a nested for-loop
or a flatMap,
however for a 10+ nesting levels - or dynamic number/order of nesting levels -
it becomes hardly manageable.
On 2024/06/26 21:02:53 Peter Burka wrote:
> I don't know if it's been proposed before, but I
/commons-collections/apidocs/org/apache/commons/collections4/Predicate.html).
However, PredicateUtils (for instance
https://commons.apache.org/proper/commons-collections/apidocs/org/apache/commons/collections4/PredicateUtils.html#anyPredicate(java.util.Collection))
still require use of commons
I don't know if it's been proposed before, but I think any implementation
would necessarily be inefficient.
I imagine such an iterator would need to produce objects of type Pair.
This would lead to a lot of allocation and could create garbage collection
pressure. The same functionality can be
G'day to all!
It seems there's no Iterator that would implement the same thing as Python's
itertools.product (quite literally a nested for loop) with some Java stream()
capabilities.
Is this intentional (as in, was considered and rejected) or a PR with such
CartesianProductIterator would be
The Apache Commons team is pleased to announce Commons Collections
4.5.0-M2, the second milestone release toward 4.5.0. Commons
Collections contains types that extend and augment the Java
Collections Framework.
This milestone release requires Java 8 and makes small changes to the
package
; We have fixed a few bugs and added enhancements since Apache Commons
> > Collections 4.5.0-M1 was released, so I would like to release Apache
> > Commons Collections 4.5.0-M2.
> >
> > Apache Commons Collections 4.5.0-M2 RC1 is available for review here:
> >https:/
+1
> On Jun 14, 2024, at 10:48 PM, Gary Gregory wrote:
>
> We have fixed a few bugs and added enhancements since Apache Commons
> Collections 4.5.0-M1 was released, so I would like to release Apache
> Commons Collections 4.5.0-M2.
>
> Apache Commons Collections 4.5.
The RC is available :)
On 2024/06/13 14:04:47 Gary Gregory wrote:
> That all sounds good to me. I'll cut a release over the next few days.
>
> Gary
>
> On Thu, Jun 13, 2024, 9:48 AM Claude Warren wrote:
>
> > Given the hectic nature of my life at the moment, I would say longer than a
> >
Feel free to write the docs in whatever format you want :-) It just
needs to build with Maven (prefereably)
Gary
On Sat, Jun 15, 2024 at 12:07 PM Phil Steitz wrote:
>
> On Sat, Jun 15, 2024 at 8:19 AM Claude Warren wrote:
>
> > Greetings,
> >
> > I see that we support xml documents for
We (well, not me) are revamping the Log4j site documentation using
AsciiDoc. Take a look there if you're curious.
Gary
On Sat, Jun 15, 2024 at 12:07 PM Phil Steitz wrote:
>
> On Sat, Jun 15, 2024 at 8:19 AM Claude Warren wrote:
>
> > Greetings,
> >
> > I see that we support xml documents for
eport is strangely wonky. RAT is fine and headers look fine
> to me, but Checkstyle is, um, confused
>
> Phil
>
> On Fri, Jun 14, 2024 at 7:49 PM Gary Gregory wrote:
>
> > We have fixed a few bugs and added enhancements since Apache Commons
> > Collections 4.5.0-M1 w
My +1
Gary
On Fri, Jun 14, 2024 at 10:48 PM Gary Gregory wrote:
>
> We have fixed a few bugs and added enhancements since Apache Commons
> Collections 4.5.0-M1 was released, so I would like to release Apache
> Commons Collections 4.5.0-M2.
>
> Apache Commons Collec
xed a few bugs and added enhancements since Apache Commons
> Collections 4.5.0-M1 was released, so I would like to release Apache
> Commons Collections 4.5.0-M2.
>
> Apache Commons Collections 4.5.0-M2 RC1 is available for review here:
>
> https://dist.apache.org/repos/dist/dev/common
On Sat, Jun 15, 2024 at 8:19 AM Claude Warren wrote:
> Greetings,
>
> I see that we support xml documents for documentation but does anyone know
> if markdown is supported? I have a number of markdown based documents that
> would work well for the Bloom filter documentation, but translating to
Greetings,
I see that we support xml documents for documentation but does anyone know
if markdown is supported? I have a number of markdown based documents that
would work well for the Bloom filter documentation, but translating to XML
will be a pain.
thanks,
Claude
We have fixed a few bugs and added enhancements since Apache Commons
Collections 4.5.0-M1 was released, so I would like to release Apache
Commons Collections 4.5.0-M2.
Apache Commons Collections 4.5.0-M2 RC1 is available for review here:
https://dist.apache.org/repos/dist/dev/commons
That all sounds good to me. I'll cut a release over the next few days.
Gary
On Thu, Jun 13, 2024, 9:48 AM Claude Warren wrote:
> Given the hectic nature of my life at the moment, I would say longer than a
> week.
> Would it make sense to do an M2 to verify the APIs and then lock down and
>
Given the hectic nature of my life at the moment, I would say longer than a
week.
Would it make sense to do an M2 to verify the APIs and then lock down and
comb through documentation with a fine tooth comb, looking for errors and
missing explanations before an M3 that has no code, just
It would be better IMO to have the updated documentation for M2 but not
critical, let me know if you think you can do it "soon" (say within a week)
or if it's just on a longer term to-do list.
TY,
Gary
On Thu, Jun 13, 2024, 3:39 AM Claude Warren wrote:
> The only changes I am considering are
The only changes I am considering are to remove any stream usage within the
code, no external changes. Additionally, there may be some new
documentation coming but that can wait until after M2.
Thanks for all your hard work on this.
Claude
On Wed, Jun 12, 2024 at 7:30 PM Gary D. Gregory wrote:
HI All, Claude W, Alex H:
I would like to cut a 4.5.0-M2 RC later this week to capture latest bloom
filter code.
Feel free to ask me to hold back if you plan further changes first.
TY!
Gary
-
To unsubscribe, e-mail:
You need to test it with some realistic data for a benchmark.
In Commons Statistics we have a case where all elements of an array are
passed to a consumer. So you have either:
int[] a = ...
IntConsumer c = ...
Arrays.stream(a).forEach(c::accept)
vs
for (final int i : a) {
c.accept(i);
}
There is/was a discussion in Cassandra Dev recently about the overhead of
Java Streaming vs simple loops/iteration. The consensus there is that
streams should not be used in the hot path. Discussion then devolved into
determining hot path or banning outright.
My question is should we remove the
Pull request https://github.com/apache/commons-collections/pull/501 addresses
this issue
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
The code in the implementation of the EnhancedDoubleHasher is based on the
wikipedia article https://en.wikipedia.org/wiki/Double_hashing.
The code that appears in the article is:
struct key; /// Opaque
/// Use other data types when needed. (Must be unsigned for guaranteed
wrapping.)
extern
Tracking this with:
https://issues.apache.org/jira/browse/COLLECTIONS-855
On Sat, 18 May 2024 at 08:26, Alex Herbert wrote:
> Thanks for highlighting this. I did not use the original paper and based
> the implementation on Wikipedia.
>
> I think the issue is that we use i in [0
Thanks for highlighting this. I did not use the original paper and based
the implementation on Wikipedia.
I think the issue is that we use i in [0, k); we can correct this by using
i in [1, k]. The order inside the loop would not change but we would have
to decrement i to use in the assignment
The code in the implementation of the EnhancedDoubleHasher is based on the
wikipedia article https://en.wikipedia.org/wiki/Double_hashing.
The code that appears in the article is:
struct key; /// Opaque
/// Use other data types when needed. (Must be unsigned for guaranteed
wrapping.)
extern
I have updated Collections-854 [1] to reflect the naming that we have been
talking about and will start on the refactoring soon. Please start
watching that ticket.
Claude
[1] https://issues.apache.org/jira/browse/COLLECTIONS-854
On Mon, May 13, 2024 at 12:33 PM Claude Warren wrote
)
>>> - Rename BitMap to BitMaps.
>>>- Rename methods:
>>> - Producer forEachX() to forEachUntil()
>>> - The semantic nomenclature:
>>> - Bitmaps are arrays of bits not a BitMaps object.
>>> - Indexes are ints
I usually update changes.xml right after I merge a PR.
Gary
On Sun, May 12, 2024, 6:12 AM Claude Warren wrote:
> --
> LinkedIn: http://www.linkedin.com/in/claudewarren
>
No. Just add it as a second commit after merge.
On Sun, 12 May 2024, 11:12 Claude Warren, wrote:
> --
> LinkedIn: http://www.linkedin.com/in/claudewarren
>
--
LinkedIn: http://www.linkedin.com/in/claudewarren
> Head commit for run:
> b99df0198e952b673e3e92c6dedd45230d35d507 / Julian Reschke <
> resc...@apache.org>
> COLLECTIONS-842: rename test class so that it get's run by default
>
> Report URL:
> https://github.com/apache/commons-collections/actions/runs/8967262090
>
> With regards,
> GitHub Actions via GitBox
>
>
semantic nomenclature:
>> - Bitmaps are arrays of bits not a BitMaps object.
>> - Indexes are ints and not an instance of a Collection object.
>> - Cells are pairs of ints representing an index and a value. They
>> are not Pair<> objects.
>>
t; - The semantic nomenclature:
> - Bitmaps are arrays of bits not a BitMaps object.
> - Indexes are ints and not an instance of a Collection object.
> - Cells are pairs of ints representing an index and a value. They
> are not Pair<> objects.
>
nts representing an index and a value. They
are not Pair<> objects.
- Producers iterate over collections of the object (Bitmap, Index,
Cell) applying a predicate to do work and stop the iteration early if
necessary. They are carriers/transporters of Bloom filter ena
llPredicate (?)
> >
> > Agreed (as suggested by Albert)
> >
> > >- The semantic nomenclature:
> > > - Bitmaps are arrays of bits not a BitMap object.
> > > - Indexes are ints and not an instance of a Collection object.
> > > -
itmaps are arrays of bits not a BitMap object.
> > - Indexes are ints and not an instance of a Collection object.
> > - Cells are pairs of ints representing an index and a value. They
> > are not Pair<> objects.
> > - Producers iterate over collect
are pairs of ints representing an index and a value. They
> are not Pair<> objects.
> - Producers iterate over collections of the object (Bitmap, Index,
> Cell) applying a predicate to do work and stop the iteration early if
> necessary. They are ca
not a BitMap object.
- Indexes are ints and not an instance of a Collection object.
- Cells are pairs of ints representing an index and a value. They
are not Pair<> objects.
- Producers iterate over collections of the object (Bitmap, Index,
Cell) applying a predicate
Thank you for your thoughtful reply. See my comments below.
On Sun, Apr 28, 2024 at 11:10 AM Alex Herbert wrote:
>
> Hi Gary,
>
> I am in favour of using nomenclature and patterns that will be familiar to
> a Java developer. But only if they match the familiar JDK use patterns. The
> Bloom
> There is no primitive specialisation
of Iterator for long
https://docs.oracle.com/javase/8/docs/api/java/util/PrimitiveIterator.OfLong.html
On Sun, Apr 28, 2024 at 10:00 AM Alex Herbert
wrote:
> Hi Gary,
>
> I am in favour of using nomenclature and patterns that will be familiar to
> a
Hi Gary,
I am in favour of using nomenclature and patterns that will be familiar to
a Java developer. But only if they match the familiar JDK use patterns. The
Bloom filter package has some atypical use patterns that have driven the
current API to where it is. I'll try and describe these below.
Hi Clause, Albert, and all,
Since the introduction of lambdas in Java 8, Java has a well-defined
terminology around the classic producer-consumer paradigm but (for
reasons unknown to me) realized in the functional interfaces *Supplier
and *Consumer. In addition, as of Java 5, we have the Iterable
Thank you for the explanation. It sounds like leaving it as is better.
Gary
On Fri, Apr 26, 2024, 2:25 AM Alex Herbert wrote:
> On Thu, 25 Apr 2024 at 21:47, Gary D. Gregory wrote:
>
> > Hi Clause, Albert, and all,
> >
> > Why not make Hasher more functional like so:
> >
> > public interface
On Thu, 25 Apr 2024 at 21:47, Gary D. Gregory wrote:
> Hi Clause, Albert, and all,
>
> Why not make Hasher more functional like so:
>
> public interface Hasher extends Function
>
> It would implement the standard `apply` instead of `indices`.
>
> WDYT?
>
> Gary
>
I do not see any problems with
Hi Clause, Albert, and all,
Why not make Hasher more functional like so:
public interface Hasher extends Function
It would implement the standard `apply` instead of `indices`.
WDYT?
Gary
-
To unsubscribe, e-mail:
After looking at the LayeredBloomFilter and the LayerManager and the way it
is intended to be used I found a couple of changes that we might want to
consider.
1) WrappedBloomFilter should not implement copy(), that should be left to
the wrapping implementation.
2) We change LayerManager to be a
On Sat, 20 Apr 2024 at 11:36, Claude Warren wrote:
> The LayerdBloomFilter has a method find() that returns an array of ints
> that are the indices into the layer array. This is easily reproducible
> using an iterator.
> There is also get() method that takes an integer argument (an index of
The LayerdBloomFilter has a method find() that returns an array of ints
that are the indices into the layer array. This is easily reproducible
using an iterator.
There is also get() method that takes an integer argument (an index of the
bloom filter) and returns the Bloom filter from the layer.
On Fri, 19 Apr 2024 at 08:26, Claude Warren wrote:
> While the Deque makes clear the idea of enqueueing and dequeueing the
> layers it does not have the method to natively traverse and extract entries
> from the middle of the queue. Nor would I expect it to. So I think the
> Deque does not
pull request to fix this problem. I could use another
> > review: https://github.com/apache/commons-collections/pull/476
> >
> >
> > On Tue, Apr 9, 2024 at 11:29 AM Claude Warren wrote:
> >
> > > Alex,
> > >
> > > I like your solution. To a
about how any custom downstream code is currently using the collection of
layers.
Alex
On Wed, 17 Apr 2024 at 10:00, Claude Warren wrote:
> I have an open pull request to fix this problem. I could use another
> review: https://github.com/apache/commons-collections/pull/476
>
>
>
I have an open pull request to fix this problem. I could use another
review: https://github.com/apache/commons-collections/pull/476
On Tue, Apr 9, 2024 at 11:29 AM Claude Warren wrote:
> Alex,
>
> I like your solution. To answer your question. We create a BloomFilter
> that has
On Tue, Apr 9, 2024 at 11:09 PM Rodion Efremov wrote:
>
> Hello,
>
> Fair enough. However, why we have CursorableLinkedList and
> NodeCachingLinkedList around when my previous benchmarking showed that they
> are inferior compated to both TreeList and IndexedLinkedList?
We have a lot of things we
pose a Deque/List that is implemented as a doubly
> linked
> > > list with a sublinear index speeding up single-element operations to
> > > (likely) O(sqrt(n)). It passes a benchmark faster than TreeList by the
> > > factor of around 5.
> > >
> &
/List that is implemented as a doubly linked
> > list with a sublinear index speeding up single-element operations to
> > (likely) O(sqrt(n)). It passes a benchmark faster than TreeList by the
> > factor of around 5.
> >
> > The data structure is hosted in GitHub:
>
itHub:
> https://github.com/coderodde/IndexedLinkedList
>
> Does it have potential to be included in Collections?
>
> Best regards,
> rodde
--
Elliotte Rusty Harold
elh...@ibiblio.org
-
To unsubscrib
://github.com/coderodde/IndexedLinkedList
Does it have potential to be included in Collections?
Best regards,
rodde
implemented
required it, but I do not have the code to hand at the moment.
Claude
On Tue, Apr 9, 2024 at 10:38 AM Alex Herbert
wrote:
> Hi Claude,
>
> Q. What is your current clean-up filter, i.e.
> the Consumer>? I assume you are using a custom one.
>
> The current collec
Hi Claude,
Q. What is your current clean-up filter, i.e.
the Consumer>? I assume you are using a custom one.
The current collections code only has 2 functional implementations. One
will remove the newest filter if it is empty, one will remove the oldest
filters until the size is below a li
Greetings,
I am attempting to use the Bloomfilter code in Kafka to manage PID
generation. The requirement is to remove pid tracking after a period of
time. This is possible with the LayeredBloomFilter but it has an edge case
problem.
The LayeredBloomFilter uses the LayerManager to manage the
The Apache Commons team is pleased to announce Apache Commons
Collections 4.5.0-M1.
The Apache Commons Collections package contains types that extend and
augment the Java Collections Framework.
This milestone release requires Java 8 and adds the package
`org.apache.commons.collections4
31, 2024, at 12:19 PM, Gary Gregory wrote:
> >
> > We have fixed a few bugs and added enhancements since Apache Commons
> > Collections 4.4 was released, so I would like to release Apache
> > Commons Collections 4.5.0-M1.
> >
> > Apache Commons Collections 4.5.
My +1
Gary
On Mon, Apr 1, 2024 at 12:24 PM Rob Tompkins wrote:
>
> +1 all looks good.
>
> > On Mar 31, 2024, at 12:19 PM, Gary Gregory wrote:
> >
> > We have fixed a few bugs and added enhancements since Apache Commons
> > Collections 4.4 was released,
+1 all looks good.
> On Mar 31, 2024, at 12:19 PM, Gary Gregory wrote:
>
> We have fixed a few bugs and added enhancements since Apache Commons
> Collections 4.4 was released, so I would like to release Apache
> Commons Collections 4.5.0-M1.
>
> Apache Commons Col
ist area, and site reports, found no issues.
Thanks!
Bruno
On Sun, 31 Mar 2024 at 18:20, Gary Gregory wrote:
> We have fixed a few bugs and added enhancements since Apache Commons
> Collections 4.4 was released, so I would like to release Apache
> Commons Collections 4.5.0-M1.
>
> Apach
My vote: +1 Release these artifact.
On Sun, Mar 31, 2024 at 6:19 PM Gary Gregory wrote:
> We have fixed a few bugs and added enhancements since Apache Commons
> Collections 4.4 was released, so I would like to release Apache
> Commons Collections 4.5.0-M1.
>
> Apache Commons Co
We have fixed a few bugs and added enhancements since Apache Commons
Collections 4.4 was released, so I would like to release Apache
Commons Collections 4.5.0-M1.
Apache Commons Collections 4.5.0-M1 RC1 is available for review here:
https://dist.apache.org/repos/dist/dev/commons/collections
+1 for M1 or beta1, thanks!
On Mon, 25 Mar 2024 at 14:12, Gary Gregory wrote:
> Hi All,
>
> 4.5.0 will contain a new package for Bloom Filters.
>
> Since this is a new package and is non-trivial, I propose we release a
> version called 4.5.0-M1 or 4.5.0-beta1 to let users try this out while
>
+1 on the M1 or beta1 release.
On Mon, Mar 25, 2024 at 2:12 PM Gary Gregory wrote:
> Hi All,
>
> 4.5.0 will contain a new package for Bloom Filters.
>
> Since this is a new package and is non-trivial, I propose we release a
> version called 4.5.0-M1 or 4.5.0-beta1 to let users try this out
r complex and it
would be nice to have some figures to show the advantages.
We should also get some closure on COLLECTIONS-842 [1] which is an
incompatibility between collections and default methods added to List in
JDK 21. I looked at this for a while but did not change anything in the
codebase. TLDR:
Hi All,
4.5.0 will contain a new package for Bloom Filters.
Since this is a new package and is non-trivial, I propose we release a
version called 4.5.0-M1 or 4.5.0-beta1 to let users try this out while
giving us the change to make breaking API changes if needed.
Gary
e compatible with JDK 21.
Extra:
Note that this incompatibility is true when targeting Java 21 as the release.
If compiling for an earlier Java release then this is possible using
JDK 21 via the javac --release flag.
Collections is a very long way from targeting Java 21 (it currently
targets Java
hese methods to java.util.List:
>>
>> default public void addFirst(E o)
>> default public void addLast(E o)
>>
>> These are source incompatible with Commons Collections AbstractLinkedList:
>>
>> public boolean addFirst(E o)
>> public boolea
First(E o)
> default public void addLast(E o)
>
> These are source incompatible with Commons Collections AbstractLinkedList:
>
> public boolean addFirst(E o)
> public boolean addLast(E o)
>
> This affects AbstractLinkedList and any list that extends it
> (Cursorable
JDK 21 has added these methods to java.util.List:
default public void addFirst(E o)
default public void addLast(E o)
These are source incompatible with Commons Collections AbstractLinkedList:
public boolean addFirst(E o)
public boolean addLast(E o)
This affects AbstractLinkedList and any list
Oh, BTW, please don't take this as a strong position against making the
code thread-safe. I am trying to understand the source of the desire for
change, and playing a bit of devil's advocate.
Gary
On Sun, Jul 2, 2023, 07:46 Gary Gregory wrote:
> The question I have is whether thread safety is
The question I have is whether thread safety is something you require here
or think is a feature people will be surprised is absent.
Sometimes extra bells and whistles make the code harder to maintain. Once
advertised as such, it may become quite hard to fix bugs or add new
features. I would
I do not think concurrent write usage is a general use case for the
filter. So this seems like a specialisation. If implementing it would
harm performance then I would be against it for the base
implementation.
For specialisation I would prefer the JDK pattern used for
Synchronized collections
I have been thinking about what it would take to make SimpleBloomFilter
thread safe. I think that the answer is to use a copy on write strategy
and a lock within all the merge methods.
However, this leaves the problem of the cardinality calculation. Currently
it is lazily performed and cached.
Java 8.
Gary
On Wed, Jun 14, 2023, 12:42 Maxim Solodovnik wrote:
> On Wed, 14 Jun 2023 at 23:32, Efremov, Rodion
> wrote:
> >
> > Hello,
> >
> > What Java version Collections 4.5 is being built for?
> >
> > Best r
Hello,
On Wed, 14 Jun 2023 at 23:32, Efremov, Rodion
wrote:
>
> Hello,
>
> What Java version Collections 4.5 is being built for?
the answer is here:
https://github.com/apache/commons-collections/blob/master/pom.xml#L532
:)
ps I believe this question is for user@ list :)
>
On Wed, 14 Jun 2023 at 23:32, Efremov, Rodion
wrote:
>
> Hello,
>
> What Java version Collections 4.5 is being built for?
>
> Best regards,
--
Best regards,
Maxim
-
To unsubscribe, e-mail: dev-unsubscr...@
Hello,
What Java version Collections 4.5 is being built for?
Best regards,
tps://issues.apache.org/jira/browse/COLLECTIONS-842>.
Best regards, Julian
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
on the JDK 21 content.
At the time of writing, 5 JEPs are already integrated in the JDK 21 mainline -
Virtual Threads, Generational ZGC, etc. – see below for more details. This
newsletter heads-up is focused on one of those JEPs; i.e., JEP 431 Sequenced
Collections, as it might induce some
I have a work around but not having to convert from binary representation
to string would be handy. But it is not critical. I am also not sure that
the API is documented all that well. Perhaps I should open a low level
ticket that we can work on after 4.5 is released.
On Sun, Apr 23, 2023 at
Claude,
Do you need the API to be made public?
Gary
On Mon, Apr 17, 2023 at 2:53 PM Gary Gregory wrote:
>
> I am guessing that only what is required to be public is as to both maximize
> our flexibility in maintenance and minimize the public API surface to support.
>
> We could make it public
I am guessing that only what is required to be public is as to both
maximize our flexibility in maintenance and minimize the public API surface
to support.
We could make it public if we are sure the API is documented and the code
isbas good as we can reasonably make it.
Gary
On Mon, Apr 17,
I was looking at the Trie and PatriciaTree class structure from version 4.5
over the weekend. I wanted to build a different implementation with slight
modifications. However, there does not seem to be a way to inherit from
AbstractPatriciaTrie as it is package protected. Was this intentional or
Thank you for the update Claude.
Gary
On Thu, Mar 23, 2023, 03:57 Claude Warren, Jr
wrote:
> Gary,
>
> The Bloom filter package is functionally complete and ready for prime
> time. As to beta, I have used it in several research projects and am
> proposing using it in an in-house project at
Gary,
The Bloom filter package is functionally complete and ready for prime
time. As to beta, I have used it in several research projects and am
proposing using it in an in-house project at work. I don't know what the
standard process is for commons, so I leave it to your discretion.
Claude
Hi All,
What is the status of the bloom filters package? Is it ready for prime
time? Should we have a beta?
Gary
We have:
org.apache.commons.collections4.bloomfilter.HasherCollection.add(Collection)
I propose that we rename it to "addAll" to follow existing Java concepts in
Collections.
Gary
-
To unsubscribe, e-mail: de
1 - 100 of 1822 matches
Mail list logo
