Paul, John, thanks!
Best regards,
Vladimir Ivanov
On 12/3/14, 10:38 AM, John Rose wrote:
Reviewed.
I sympathize with Paul's gnarly comment.
Nice bit of stream-ology (rheology) in the test code.
Regarding:
On Dec 2, 2014, at 8:20 AM, Vladimir Ivanov vladimir.x.iva...@oracle.com
wrote:
On 01/12/2014 07:55, Amy Lu wrote:
Yes, the extensions part should be removed.
Please review the updated version:
http://cr.openjdk.java.net/~weijun/8066131/webrev.01
This looks okay for now and I can sponsor this for you. We might have to
come back to this test later in JDK 9.
-Alan
Hi Hendrik,
On 11/28/2014 03:40 PM, Hendrik Dev wrote:
Is it enough to read this mailing list or are other sources more
recommended and is http://hg.openjdk.java.net/jdk9/dev/jdk/ the
correct repo?
I think yes, and yes.
Joe Wang (JEP assignee) is on this list.
-Aleksey.
On 02/12/2014 22:34, Martin Buchholz wrote:
:
Martin's pet peeve: use readFully (why doesn't InputStream support
that yet?!) copy-paste from elsewhere in the jdk.
I agree, I think this should be #2 on the list to look at as part of the
I/O convenience methods thread.
-Alan
Hi,
On 12/02/2014 01:02 PM, Paul Sandoz wrote:
Please find below a patch to remove the networking code computing a
seed in ThreadLocal/SplittableRandom.
Looks good.
We thought it a good idea at the time :-) but subsequently on certain
platforms this results in very high initalization costs
Aleksey, thanks for the review.
I haven't tried -XX:SoftRefLRUPolicyMSPerMB=0, but I did extensive
testing on Octane/Nashorn with multiple low -Xmx levels + frequent Full
GCs (8060147 [1] was the result of those experiments) and stress tested
cache eviction with jdk/java/lang/invoke/LFCache
On 02/12/2014 02:39, Chris Plummer wrote:
Sorry about the long delay in getting back to this. I ran into two
separate JPRT issues that were preventing me from testing these
changes, plus I was on vacation last week. Here's an updated webrev.
I'm not sure where we left things, so I'll just say
Hi Peter,
A few questions and comments:
- Can/should this function be fit into one of the existing classes?
- Is more than one instance needed?
Seed material seems to be needed only as a one-shot so a simpler
implementation that opens,
uses and closes would leave fewer leftovers (and
The changes in 8035000 [1] changed some common rmi testlibrary classes,
RMID.java for one, and this test no longer compiles.
The test should call RMID destroy() instead of shutdown(..).
../chhegar/s/jdk/test/javax/management/remote/mandatory/connection/RMIConnector_NPETest.java:64:
error:
On 03/12/2014 14:40, Chris Hegarty wrote:
:
diff --git
a/test/javax/management/remote/mandatory/connection/RMIConnector_NPETest.java
b/test/javax/management/remote/mandatory/connection/RMIConnector_NPETest.java
---
Hi Mandy,
On Dec 2, 2014, at 11:28 PM, Mandy Chung mandy.ch...@oracle.com wrote:
On 12/2/2014 1:47 PM, Lance Andersen wrote:
The revised webrev is here
http://cr.openjdk.java.net/~lancea/8060068/webrev.03/
Looks good. Nit: line 443 and a few places in the getConnection need a
space
Hi Bernd,
On Dec 2, 2014, at 6:33 PM, Bernd Eckenfels e...@zusammenkunft.net wrote:
Hello Mandy and Lance,
(sorry, not a full quote for more focused answers, inline)
Am Tue, 02 Dec 2014 14:10:06 -0800
schrieb Mandy Chung mandy.ch...@oracle.com:
Would you be able to try this patch and
On 12/02/2014 05:34 PM, Martin Buchholz wrote:
I support Peter's initiative and am willing to help review if we have
general consensus about the direction.
Peter's implementation scheme of using Unix /dev/urandom
or the Windows Crypto API (or something else on failure) seems
like the best
On 12/03/2014 10:03 AM, Lance Andersen wrote:
Note, I also tweaked the doPriviliged block for the JDBC property
It's nice to see use of limited doPrivileged. Limited doPrivileged restricts
the permissions be accessed by the doPrivileged block. On the other hand, since
it only calls
On Dec 3, 2014, at 10:39 AM, Sean Mullan sean.mul...@oracle.com wrote:
On 12/03/2014 10:03 AM, Lance Andersen wrote:
Note, I also tweaked the doPriviliged block for the JDBC property
It's nice to see use of limited doPrivileged. Limited doPrivileged
restricts the permissions be
Hi folks,
Looking to fix a regression caused by 8042857. Basically the behaviour
in 8042857 is incorrect. This fix reverts to the previous behaviour and
attempts to beef up the tests a little around Ldap timeouts.
http://cr.openjdk.java.net/~robm/8065238/webrev.01/
The test itself looks
Nathan, thanks a lot for reporting this. Sorry no one has replied to you
earlier,
but your bug report was actually entered into the JBS (JDK Bug System):
https://bugs.openjdk.java.net/browse/JDK-8054565
So don't worry, it won't get lost.
Now about the issue itself. It's indeed a bug.
On 12/3/2014 8:18 AM, Lance Andersen wrote:
Thank you Sean. As this code path is only called 1 time, i am not
concerned that performance will be an issue. If you and Mandy prefer
me to remove it, I can, just let me know.
Yes, I agree it is narrow. The suggestion to add the limited
On Dec 3, 2014, at 11:57 AM, Mandy Chung mandy.ch...@oracle.com wrote:
On 12/3/2014 8:18 AM, Lance Andersen wrote:
Thank you Sean. As this code path is only called 1 time, i am not concerned
that performance will be an issue. If you and Mandy prefer me to remove
it, I can, just let
On Wed, Dec 3, 2014 at 7:26 AM, Doug Lea d...@cs.oswego.edu wrote:
On 12/02/2014 05:34 PM, Martin Buchholz wrote:
I support Peter's initiative and am willing to help review if we have
general consensus about the direction.
Peter's implementation scheme of using Unix /dev/urandom
or the
On 12/3/14 6:41 AM, Alan Bateman wrote:
On 03/12/2014 14:40, Chris Hegarty wrote:
diff --git
a/test/javax/management/remote/mandatory/connection/RMIConnector_NPETest.java
b/test/javax/management/remote/mandatory/connection/RMIConnector_NPETest.java
---
On 12/03/2014 12:20 PM, Martin Buchholz wrote:
I don't think such a general purpose utility belongs in
SplittableRandom or ThreadLocalRandom - those are the clients. Random
is a slightly better fit, but still not great.
Perhaps one of these could be made to be a good fit.
As of now, this
Hi all,
There seems to be a consensus that a simpler static method would be just
fine, since it will be used only to gather secure seed for other java
based PRNG implementations. UNIX file as well as Windows Crypro API
implementation are naturally exposed as open/use/close API, so I did
that
Hi Roger,
Thanks for looking at my baby steps in the JNI / Windows worlds...
Answers inline...
On 12/03/2014 03:14 PM, roger riggs wrote:
Hi Peter,
A few questions and comments:
- Can/should this function be fit into one of the existing classes?
As a static method perhaps, yes. The
Potentially in the future. It has been on a list of candidate enhancements for
quite some time.
As Aleksey just mentioned in his response, (he beat me to the punch), that work
is not in scope as part of this project.
Should also mention that the work from this project would not prohibit such
On Wed, Dec 3, 2014 at 9:38 AM, Doug Lea d...@cs.oswego.edu wrote:
On 12/03/2014 12:20 PM, Martin Buchholz wrote:
I don't think such a general purpose utility belongs in
SplittableRandom or ThreadLocalRandom - those are the clients. Random
is a slightly better fit, but still not great.
Hi Kumar,
On 12/3/14 10:58 AM, Kumar Srinivasan wrote:
Hi Chris,
Approved with some minor nits, typos which needs correction.
yes java.c follows the JDK indenting as Alan pointed out.
TooSmallStackSize.java
Copyright should be 2014,
Copy/paste error from example test I was referred to. I
On 12/3/2014 11:26 AM, Chris Plummer wrote:
Hi Kumar,
On 12/3/14 10:58 AM, Kumar Srinivasan wrote:
Hi Chris,
Approved with some minor nits, typos which needs correction.
yes java.c follows the JDK indenting as Alan pointed out.
TooSmallStackSize.java
Copyright should be 2014,
Copy/paste
On 12/03/2014 02:03 PM, Martin Buchholz wrote:
On Wed, Dec 3, 2014 at 9:38 AM, Doug Lea d...@cs.oswego.edu wrote:
... Of the two choices, housing the code in ThreadLocalRandom
seems logistically a bit easier. Then SplittableRandom could use
private static final AtomicLong defaultGen =
Hi,
This is a review for a new test which has a different
implementation for JDK 8 JDK 9
During the review of
JDK-8065552: setAccessible(true) on fields of Class may throw
a SecurityException,
it was remarked that such a test would be useful.
So here is such a test that loads all
Hi all,
Moar RMI test cleanups!
The main issue is that the timing loop that waits for rmid to start will now
check to make sure the process hasn't exited prematurely.
I've also taken the opportunity to simplify this and other timing loops in the
RMI test library and to make their
On Wed, Dec 3, 2014 at 2:15 PM, Doug Lea d...@cs.oswego.edu wrote:
No public API because systemSeed need only be implemented
inside TLR, for its initial seed. Then the others can get their seeds
using ThreadLocalRandom.current().nextLong(), unless
java.util.secureRandomSeed is set (which I
Hi Stuart,
This looks ok to me
Best,
Lance
On Dec 3, 2014, at 6:27 PM, Stuart Marks stuart.ma...@oracle.com wrote:
Hi all,
Moar RMI test cleanups!
The main issue is that the timing loop that waits for rmid to start will now
check to make sure the process hasn't exited prematurely.
Updated webrev:
http://cr.openjdk.java.net/~dholmes/8038189/webrev.jdk.v2/
Only changes are to profile-includes.txt.
Thanks,
David
On 2/12/2014 2:24 PM, David Holmes wrote:
Erik,
Many thanks for the makefile macro wizardry! I will incorporate, test
and return with an updated webreb.
David
Hi Daniel,
Once clarification please ...
On 4/12/2014 8:47 AM, Daniel Fuchs wrote:
Hi,
This is a review for a new test which has a different
implementation for JDK 8 JDK 9
During the review of
JDK-8065552: setAccessible(true) on fields of Class may throw
a SecurityException,
Hi,
Here is my suggested fix for the FilterOuputStream issue in JDK-8054565. I
have been running this fix in my applications for several weeks (by adding it
to the bootstrap classpath) and it solves my issue. The fix creates a new
member field to remember whether close has already been
Hello,
First some background, one of the JEPs targeted to JDK 9 is
JEP 212: Resolve Lint and Doclint Warnings
http://openjdk.java.net/jeps/212
In the jdk repository, only the deprecation category of lint warnings
remain. While resolving the other categories of warnings mostly involved
37 matches
Mail list logo
