Hi Doug,
On 06/19/2014 02:02 PM, Doug Lea wrote:
On 06/19/2014 04:48 AM, Peter Levart wrote:
Or, even better, why not just using the next value from the seeder
sequence
for the initial value of secondary seed and avoid interaction with
TLR's main
seed/probe:
Thanks! Or better, just use
On 06/19/2014 08:04 PM, Martin Buchholz wrote:
On Thu, Jun 19, 2014 at 1:22 AM, Alan Bateman alan.bate...@oracle.com
wrote:
On 19/06/2014 05:25, Martin Buchholz wrote:
ThreadLocalRandom's clinit method creates an intermediate broken state of
ThreadLocalRandom and then proceeds to run some
On 20/06/2014 09:42, Patrick Zhang wrote:
Hi Team,
8035490 is one task used to track xml code colocation from sqe repo
into jaxp repo.
As one initial change set, it includes below materials:
1. TEST.ROOT to declare test code location.
2. ProblemList.txt to exclude 6 tests which have been
Hi Joe,
Thanks for the detailed explanation.
It really helps reviewing the fix!
This looks reasonable to me. One minor nit is that you
could turn:
769 BigInteger maxintAsBigInteger = BigInteger.valueOf((long)
Integer.MAX_VALUE);
into a static final constant in the class.
best
On 06/20/2014 11:10 AM, Peter Levart wrote:
Perhaps a more lazy initialization of NetworkInterface class that does
not trigger initialization of NS providers could help. We just need to
invoke two methods on NetworkInterface:
- static NetworkInterface.getNetworkInterfaces()
- instance
Neil,
Thanks for quick implementation.
java.c:
Did not check return values of malloc(), I wonder if source code
analyzers will complain.
-Zhengyu
On 6/19/2014 8:29 PM, Neil Toda wrote:
Launcher support for modified Native Memory Tracking mechanism in JVM
in JDK9.
Webrev :
Hello Aaron,
I considered using your testcase that manually generates the necessary
malformed JAR
but as there was a suitable signed JAR already in the test suite I decided to
re-use that.
I think it makes sense to re-work the test as a Java program. Unfortunately
I’ll be on vacation
from
I'm in favor of Peters approach ( I would need to do a more detailed
review though ).
Looking up name service providers during initialization of InetAddress
has been the cause of several issues in the past.
I agree with Stanimir's point about TCCL, but I don't think we should
try to do
On 20/06/2014 12:20, Peter Levart wrote:
Hi,
A patch that solves this is a patch to InetAddress. We can't suppress
initialization of InetAddress as part of NetworkInterface
initialization, but we can suppress initialization of NameService
providers as part of InetAddress initialization by
Hi,
Please review a trivial webrev to add JDK version to @since in a format
as Mark suggested[1].
http://cr.openjdk.java.net/~henryjen/jdk9/8047721/0/webrev/
[1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2014-June/000806.html
Appened is the diff as in the webrev.
Cheers,
Henry
diff
Henry,
I think JCE1.2 should get the space to be JCE 1.2 so it matches other
secondary versions like JNDI 1.1 (last part of your patch). Or, you could
make that another cleanup in itself.
Cheers,
Paul
You are absolutely right, I should have fixed it as I did for the rest.
Updated webrev can be found at
http://cr.openjdk.java.net/~henryjen/jdk9/8047721/1/webrev/
Cheers,
Henry
On 06/20/2014 01:01 PM, Paul Benedict wrote:
Henry,
I think JCE1.2 should get the space to be JCE 1.2 so it
I assume the reason to have those @since JCE tag is somehow we want to
distinguish those APIs from the rest, thus I chose to preserve them.
If we agree it's not worth to keep, I can remove them.
Cheers,
Henry
On 06/20/2014 01:25 PM, Joe Darcy wrote:
Hi Henry,
For the Cipher{Input,
Daniel, Jim,
In JDK8 the FileHandler file locking was changed to use FileChannel.open with
CREATE_NEW. If the file exists (locked or not) the FileHandler will rotate due
to safety concerns about writing to the same log file. The FileHandler has an
upper bound of 100 as the number of file
Thanks for the review. FYI. I'm going to push this change to
jdk9/client as this depends on the deploy change that is not integrated
(just anxious to get this out of my queue rather than waiting it to show
up in jdk9/dev).
Mandy
On 6/18/14 11:32 AM, Joe Darcy wrote:
On 06/18/2014 11:27
Hi,
Please review a trivial webrev for jdk9/corba that do the same @since
tag normalization as in jdk9/jdk.
http://cr.openjdk.java.net/~henryjen/jdk9/8047722/0/webrev/
Cheers,
Henry
Hi,
Please review a trivial webrev for jdk9/jaxp that do the same @since tag
normalization as in jdk9/jdk.
http://cr.openjdk.java.net/~henryjen/jdk9/8047723/0/webrev/
I am not sure if there is another mailing list thatis more appropriate
for this, if so, please direct me to the right ml.
Hi,
Please review a trivial webrev for jdk9/jaxws that do the same @since
tag normalization as in jdk9/jdk.
http://cr.openjdk.java.net/~henryjen/jdk9/8047724/0/webrev/
I am not sure if there is another mailing list thatis more appropriate
for this, if so, please direct me to the right ml.
Hi Henry,
Is it possible to add to the @since tool/script to remove repository
revision notes? They appear in the API document as if they reflect
meaningful version. An example in
Memory allocation in the launcher should use one of the JLI_MemAlloc
wrappers, if possible.
-Joe
On 06/20/2014 09:50 AM, Neil Toda wrote:
They should complain. Thanks Zhengyu. I'll make sure these are
non-null.
-neil
On 6/20/2014 5:01 AM, Zhengyu Gu wrote:
Neil,
Thanks for quick
Thanks Joe. It would have checked for NULL for me.
I'll use the JLI wrapper.
-neil
On 6/20/2014 4:04 PM, Joe Darcy wrote:
Memory allocation in the launcher should use one of the JLI_MemAlloc
wrappers, if possible.
-Joe
On 06/20/2014 09:50 AM, Neil Toda wrote:
They should complain.
Neil,
Generally looks good, yes JLI_* functions must be used, I missed that one.
Are you going to post another iteration ?
Kumar
On 6/20/2014 4:27 PM, Neil Toda wrote:
Thanks Joe. It would have checked for NULL for me.
I'll use the JLI wrapper.
-neil
On 6/20/2014 4:04 PM, Joe Darcy wrote:
Thanks Kumar for your other finds. I'll spin another webrev this
evening and post
it with the fixes to address everyone's points.
Thanks.
-neil
On 6/20/2014 4:45 PM, Kumar Srinivasan wrote:
Neil,
Generally looks good, yes JLI_* functions must be used, I missed that
one.
Are you going
Looks like it's pretty easy to do a find and replace in files in jaxp
folder. If this is desired, we can do it in a separate webrev to be
clear on changeset history?
Cheers,
Henry
On 06/20/2014 03:36 PM, huizhe wang wrote:
Hi Henry,
Is it possible to add to the @since tool/script to remove
On 6/20/2014 5:24 PM, Henry Jen wrote:
Looks like it's pretty easy to do a find and replace in files in jaxp
folder. If this is desired, we can do it in a separate webrev to be
clear on changeset history?
Sounds good. Then, your webrev is fine with me.
Cheers,
Joe
Cheers,
Henry
On
Thanks Daniel, Lance.
On 6/20/2014 3:02 AM, Daniel Fuchs wrote:
Hi Joe,
Thanks for the detailed explanation.
It really helps reviewing the fix!
Glad to know it helps. I thought this part of spec could be unfamiliar
to people.
This looks reasonable to me. One minor nit is that you
could
26 matches
Mail list logo
