for the remove(), add(), and subtract() methods I agree that void is not
correct and it should be boolean and be the same as the value you would get
from calling isValid().
You are correct the getCounts() should return an iterator of some type on
int[], I don't know why I thought long[]. I am hap
> On 1 Mar 2020, at 15:39, Claude Warren wrote:
>
> I think the CountingBloomFilter interface needs to extend BloomFilter.
I said that but did not write it, sorry.
>
> I think I am confused.
>
> I would expect CountingBloomFilter to have
>
> interface CountingBloomFilter extends BloomFilte
Until it exists .class were only in / so algorithm was often "scan
everything which is ending with a .class". mjar broke these algorithms :(.
That said, major bump does not solve the fact you will break people, or do
you plan to maintain all versions in parallel just for that?
jpms classifier reall
So spring and other scanners scan classes under /META-INF/versions/...
i was unaware of that.
So probably need a major version bump then, so it indicates a major
change, so that consumers treat it as such and test it.
On Sun, 1 Mar 2020 at 17:11, Romain Manni-Bucau wrote:
>
> Le dim. 1 mars 2020
Le dim. 1 mars 2020 à 18:00, John Patrick a écrit :
> Romain, The 4 commons projects I'm referring to already have
> Automatic-Module-Name in the Manifest, if that is what you mean by
> "explicit module name in the manifest".
>
> I've been playing around with jdk 1.8, 9, 10, 11, 12, 13 and 14, fo
Romain, The 4 commons projects I'm referring to already have
Automatic-Module-Name in the Manifest, if that is what you mean by
"explicit module name in the manifest".
I've been playing around with jdk 1.8, 9, 10, 11, 12, 13 and 14, for
about 18 months and not seen the issue you described about ne
I think the CountingBloomFilter interface needs to extend BloomFilter.
I think I am confused.
I would expect CountingBloomFilter to have
interface CountingBloomFilter extends BloomFilter {
// these 2 methods are the reverse of merge()
void remove( BloomFilter );
void remove( Hasher )
> On 1 Mar 2020, at 09:28, Claude Warren wrote:
>
> The idea of a backing array is fine and the only problem I see with it is
> in very large filters (on the order of 10^8 bits and larger) but document
> the size calculation and let the developer worry about it.
Let us look at the use case whe
I used Jabel, and Maven profiles to generate jvm8 and also jvm11 jars in
the Java::Geci project.
I also wrote a document about what, why, and how I did it:
https://javax0.wordpress.com/2019/11/06/supporting-java-8/
It may help.
Peter
On Sun, 1 Mar 2020 at 12:38, Romain Manni-Bucau
wrote:
>
Hi John,
Didnt check on java 11 ga but in early versions module-info was required to
be at the root of the jar even if overriden for some version (
http://openjdk.java.net/jeps/238) so it ends up in the fact that some java
8 apps will be broken by this addition and that only doing it in a mjar
wil
I'm wanting to correctly use Collections and Lang as Java Modules.
Looking at the dependencies, I'll need to tackle all four projects.
I'm planning on doing the following as if I'm touching the projects I
might as well help out;
1) spring clean .gitignore, each project has different list, some
do
The idea of a backing array is fine and the only problem I see with it is
in very large filters (on the order of 10^8 bits and larger) but document
the size calculation and let the developer worry about it.
As for the merge question. merge is a standard bloom filter operation. It
is well defined
12 matches
Mail list logo
