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
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 called
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,
i
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 Stuart,
This looks ok to me
Best,
Lance
On Dec 3, 2014, at 6:27 PM, Stuart Marks 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.
>
> I've also taken t
On Wed, Dec 3, 2014 at 2:15 PM, Doug Lea 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 didn't illustrate
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 elapsed-tim
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
On 12/03/2014 02:03 PM, Martin Buchholz wrote:
On Wed, Dec 3, 2014 at 9:38 AM, Doug Lea wrote:
... Of the two choices, housing the code in ThreadLocalRandom
seems logistically a bit easier. Then SplittableRandom could use
private static final AtomicLong defaultGen =
new AtomicLong(Thread
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 er
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 wil
On Wed, Dec 3, 2014 at 9:38 AM, Doug Lea 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.
>
>
>
> Perhaps
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,
1.
37 * stack size for the platform (as provided by the JVM error message when
a very
38 * small is used),
Hi there,
Has there been a effort jet to update the
„jdk/make/netbeans/j2se/nbproject/project.xml“ to the modularized structure
jet?
In the past it was very help full in order to find certain references within
the JDK code base.
-Patrick
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 an
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 webrev
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
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 new
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
---
a/test/javax/management/remote/mandatory/c
On Wed, Dec 3, 2014 at 7:26 AM, Doug Lea 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 Windows Cr
On Dec 3, 2014, at 11:57 AM, Mandy Chung 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 me know.
>>
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
doPr
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. Th
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 quit
On Dec 3, 2014, at 10:39 AM, Sean Mullan 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 accessed by t
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 Syst
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 opti
Hi Bernd,
On Dec 2, 2014, at 6:33 PM, Bernd Eckenfels 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 :
>
>> Would you be able to try this patch and see if the deadlocks are
>> reproduc
Hi Mandy,
On Dec 2, 2014, at 11:28 PM, Mandy Chung 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 in "for(",
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
---
a/test/javax/management/remote/mandatory/connection/RMIConnector_NPETest.jav
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: meth
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 n
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 w
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 te
On 12/01/2014 07:58 PM, Vladimir Ivanov wrote:
> http://cr.openjdk.java.net/~vlivanov/8057020/webrev.00/
> https://bugs.openjdk.java.net/browse/JDK-8057020
Looks okay, although the cache management logic gives me a headache
after the vacation. I thought I spotted a few bugs, but those were only
fa
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 cos
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 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 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
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
wrote:
In src/java.base/share/class
40 matches
Mail list logo
