Hi all,
It’s been another couple of years since DbUtils had a release[1], and some good
changes are ready to ship. Since the 1.7 release, we’ve had 90+ commit from
Commons committers and GitHub PRs. Some features, a threading fix, and lots of
attention to builds and quality across all platforms
Hi.
Le dim. 29 déc. 2019 à 23:25, Alex Herbert a écrit :
>
> I’ve dropped the static equals methods and reciprocal and pushed the updated
> class with MathJax.
>
> I put MathJax in whenever possible. This may be a bit too much. The rendered
> javadoc looks good but the javadoc rendered by my ID
OK.
If you are going to make the behaviour change for the string methods then the
javadoc should be updated. It currently states:
"The string is converted to bytes using the default encoding.”
So perhaps switch this to:
“Before 1.14 the string was converted using default encoding. Since 1.14 t
> On 29 Dec 2019, at 18:39, Gary Gregory wrote:
>
> It depends on the platform you are using, which is the bug. What is most
> important WRT compatibility is the API signature's binary compatibility
> which would be maintained.
>
> As the code is now, a result value is effectively meaningless
I’ve dropped the static equals methods and reciprocal and pushed the updated
class with MathJax.
I put MathJax in whenever possible. This may be a bit too much. The rendered
javadoc looks good but the javadoc rendered by my IDE without MathJax support
can be very unreadable.
Have a look at th
It depends on the platform you are using, which is the bug. What is most
important WRT compatibility is the API signature's binary compatibility
which would be maintained.
As the code is now, a result value is effectively meaningless without
knowing the "file.encoding" at the time the value was ge
Hi all
I've started to look into
https://issues.apache.org/jira/browse/COMPRESS-498 which (correctly)
points out that Compress 1.18 has changed the OSGi coordinates over the
previous versions.
The symbolic name is defined inside the parent POM. In Parent 46 this
has been
org.apache.commons.
Changing the getBytes() call will change the operation vs the previous
release. That would be a major release change would it not?
On Sun, Dec 29, 2019 at 4:20 PM Gary Gregory wrote:
> On Sun, Dec 29, 2019 at 10:58 AM Gary Gregory
> wrote:
>
> > The two murmur hash classes call String#getBytes
It is currently a sub-class. There was a suggestion to move it outside of
the BloomFilter interface.
On Sun, Dec 29, 2019 at 3:47 PM Gilles Sadowski
wrote:
> Le dim. 29 déc. 2019 à 15:30, Claude Warren a écrit :
> >
> > If the Shape class (BloomFilter.Shape) is extracted from the BloomFilter
>
On Sun, Dec 29, 2019 at 10:58 AM Gary Gregory
wrote:
> The two murmur hash classes call String#getBytes() instead of
> String#getBytes(Charset|String).
>
> This means you can get different results depending on where in the world
> you run the code or by changing the "file.encoding" system propert
The two murmur hash classes call String#getBytes() instead of
String#getBytes(Charset|String).
This means you can get different results depending on where in the world
you run the code or by changing the "file.encoding" system property. I
can't imagine that's the intention here.
Why not use UTF-8
Le dim. 29 déc. 2019 à 15:30, Claude Warren a écrit :
>
> If the Shape class (BloomFilter.Shape) is extracted from the BloomFilter
> interface and made a stand-alone class would the name change or is the fact
> that it is in the o.a.c.c.bloomfilter package enough?
>
> I prefer the name Shape to Bl
If the Shape class (BloomFilter.Shape) is extracted from the BloomFilter
interface and made a stand-alone class would the name change or is the fact
that it is in the o.a.c.c.bloomfilter package enough?
I prefer the name Shape to BloomFilterShape.
Claude
On Sat, Dec 28, 2019 at 9:06 AM Claude Wa
The Apache Commons VFS team is pleased to announce the release of Apache
Commons VFS Project 2.5.0.
Apache Commons VFS is a Virtual File System library.
New features and bug fix release.
Changes in this version include:
New features:
o VFS-734: Add functional interface
org.apache.commons.vfs2.
On Sun, Dec 29, 2019 at 4:20 AM Alex Herbert
wrote:
> On Sun, 29 Dec 2019, 01:14 Gary Gregory, wrote:
>
> > It looks like public methods have been removed
> > from org.apache.commons.codec.digest.MurmurHash3$IncrementalHash32, These
> > need to go back in to maintain binary compatibility. Then w
One possible reason to use T[0] is because that's how the new (since
Java 11) toArray method does it. From java.util.Collection, OpenJDK
version 13:
default T[] toArray(IntFunction generator) {
return toArray(generator.apply(0));
}
This method has, as of yet, not been overridd
On Sun, 29 Dec 2019, 01:14 Gary Gregory, wrote:
> It looks like public methods have been removed
> from org.apache.commons.codec.digest.MurmurHash3$IncrementalHash32, These
> need to go back in to maintain binary compatibility. Then we can have a
> release candidate.
>
To fix the broken hash imp
17 matches
Mail list logo
