On 01/05/2015 05:52 PM, Mike Duigou wrote:
Well spotted Peter. The change looks good though I wonder if it should
be:
int length = (int)((elements + elements / 20) / loadFactor) + 3;
FYI, regarding Daniel's suggestion: When similar invariant checks were
added to the HashMap deserialization me
Thanks for reviewing Daniel. I'm mark you as author. If I can get a
jdk7u Reviewer to review, I'll push this.
Will update copyright before pushing also.
regards,
Sean.
On 08/01/15 14:55, Daniel Fuchs wrote:
Hi Seán,
Thanks for taking care of that :-)
It looks good to me. You might want to se
On 2015-01-08 15:55, Erik Joelsson wrote:
Hello,
Please review this patch, which adds support for building with
different versions of Visual Studio and in particular adds support for
VS2013. In order to control which version to use, I've introduced a
new configure parameter "--with-toolchain-
Hi all,
Please find the webrev for adding an initial set of tests for RowSets. The
webrev is at http://cr.openjdk.java.net/~lancea/8068732/webrev.00/
Best,
Lance
Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering
1 Network Drive
Burlington, MA 0180
On 09/01/2015 15:27, Claes Redestad wrote:
Hi,
please review this change to remove the dependency on the line.separator
property at object construction time by instead using the
System.lineSeparator()
utility.
In itself, this change will break some applications manipulating the
line.separato
On 1/9/15 7:27 AM, Claes Redestad wrote:
Hi,
please review this change to remove the dependency on the line.separator
property at object construction time by instead using the
System.lineSeparator()
utility.
In itself, this change will break some applications manipulating the
line.separator
Hi,
Please find below a webrev for:
8068730: Increase the precision of the implementation
of java.time.Clock.systemUTC()
https://bugs.openjdk.java.net/browse/JDK-8068730
The java.time.Clock.system() method (and variants thereof) are
specified to "obtain a clock that returns the current
Hello Daniel,
this is good news. I do wonder: is there a plan to make this an
intrinsic(+vsyscall on Linux) just like System.currentTimeMillis()?
Because using it for high precision timestamps would only make sense if
it is similar lightweight.
Greetings
Bernd
Am Fri, 09 Jan 2015
17:56:28 +01
On 09/01/15 18:25, Bernd Eckenfels wrote:
Hello Daniel,
this is good news. I do wonder: is there a plan to make this an
intrinsic(+vsyscall on Linux) just like System.currentTimeMillis()?
I guess it is a possibility if there is a need, but not in this
changeset, and not by me, as I wouldn't kn
Well that is a nice surprise ;-) And I think the implementation via an
adjustment is very sensible.
In java.time.Instant, a readObject() has been added. However, I don't
believe this will ever be called because Instant has a writeReplace()
method and so is not deserialized. (There may be some secu
Hi, Bernd
The initial discussion of the change that set TREEIFY_THRESHOLD to 8 (it
was initially 16) can be read here:
http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-July/018685.html
...continuing here...
http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-August/019853.html
Hello Brent,
thank you for digging that out! It describes basically what is
documented in the javadoc as well. Having 8 colliding keys is regarded
as extremly rare when hashCode is poision distributed. From that point
of view using this threshold makes sense.
However it was not checked (at least
On 01/09/2015 02:22 PM, Bernd Eckenfels wrote:
My naive suggestion would be to delay the treeifying a bit longer if
the hash keys are not Compareable and the hash tables are large(er).
Feel free to experiment. Bear in mind that the main rationale for
treeifying HashMap and ConcurrentHashMap i
Given the prevalence of sub-optimal hashcodes, my own intuition is also
that raising the treeification threshold from 8 will be a win. But it
depends on the element type - the more expensive it is to compare elements,
the lower the optimal treeification threshold. String (or a wrapper around
Stri
On 01/09/2015 06:29 PM, Martin Buchholz wrote:
Given the prevalence of sub-optimal hashcodes, my own intuition is also that
raising the treeification threshold from 8 will be a win.
That's what I thought at first. But 8 is a better choice for String
and other Comparable keys, which account for
Hi Lance,
Looks good to me.
Are classes CachedRowSetTests and WebRowSetTests used? The Common* tests
seem to me all extends CommonCachedRowSetTests.
A minor point: would it make sense to add a rowSetType data provider
that includes listener(s)?
Some of the tests in CommonCachedRowSetTests
Hi Joe,
On Jan 9, 2015, at 8:12 PM, huizhe wang wrote:
> Hi Lance,
>
> Looks good to me.
Thank you
>
> Are classes CachedRowSetTests and WebRowSetTests used? The Common* tests seem
> to me all extends CommonCachedRowSetTests.
Yes, they are, Each type of RowSet (Cached/Web/Join/Filter) have
Hi Lance,
Thanks for the explanation. That's an interesting/smart use of the
annotation (enabled). I was guessing there might be issues in the
implementation :-)
It's good to get a baseline in and revisit later, similarly as you've
seen in the newly-migrated jaxp tests. I'm just glad I have
Again, thank you all for engaging in discussion of this very difficult
topic.
While we can't presently check intra object dependencies during
deserialization with readObject(), the examples I provide can do this.
ObjectInputValidation is sufficient for enforcing business rules,
however it ca
19 matches
Mail list logo
