[
https://issues.apache.org/jira/browse/COLLECTIONS-728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16990850#comment-16990850
]
Alex Herbert commented on COLLECTIONS-728:
------------------------------------------
{quote}it would make more sense to follow the JCA pattern and have a factory
that allowed users to register provider libraries and then request by name,
flags, and optional provider.
{quote}
That would work with the same JVM. How do you register the same provider across
VMs?
An alternative is to maintain a register in Commons. Each provider is assigned
a code (e.g. a 16-bit integer). Anyone who wishes to provide reference
implementations can apply for a code from Commons. This then becomes their code
that no-one else can use. A set number of code can be reserved for use by
Commons to allocate to algorithms that the library (or core Java) provides. The
register can be in a properties file included in the jar if necessary but I
don't see the need for that. It should be public somewhere, e.g. a page on the
website which is updated each release.
This idea is akin to the use of fields in a TIFF file. Someone can register a
field with Adobe for use in their TIFF reader/writer implementation. They can
then put whatever they want in that field. A set number of fields are reserved
by the TIFF standard and are not available.
This does add a maintenance burden on Commons to respond to people who wish to
register hash functions. But how often will that occur? Maybe never. If a
personal user wishes to use the library with their own hash function they do
not have to register it. Just use an arbitrary code and they are responsible to
ensure compatibility across their own code.
The Bloom filter library then only need verify two filters are created using
the same hash function with a single integer (i.e. the code) comparison. No
name checks, no hashing of function names, etc.
You could enforce the properties isIterative and isUnsigned are for the first
two bits of the code if you so desire.
On another note, I think the performance of autoboxing requires that this
interface is specialised to a primitive:
{code:java}
ToLongBiFunction<byte[], Integer>
{code}
> BloomFilter contribution
> ------------------------
>
> Key: COLLECTIONS-728
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-728
> Project: Commons Collections
> Issue Type: Task
> Reporter: Claude Warren
> Priority: Minor
> Attachments: BF_Func.md, BloomFilter.java, BloomFilterI2.java,
> Usage.md
>
>
> Contribution of BloomFilter library comprising base implementation and gated
> collections.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
