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
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 networking code to get
som
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 discu
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 regard
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 NetworkI
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 : http://cr.o
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 toda
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 anyth
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 mo
There is precedence for revealing the full pathname only when a security
manager is not running.
Would that be acceptable?
On 20 Jun 2014, at 13:21, Vincent Ryan wrote:
> Hello Aaron,
>
> I considered using your testcase that manually generates the necessary
> malformed JAR
> but as there wa
On 06/20/2014 03:00 PM, Alan Bateman wrote:
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
provider
Hi Joe, all,
Please approve fix for removings warnings in asm, this is merely a mini
refresh from
upstream sources, I have verified there are no more warnings in asm sources.
http://cr.openjdk.java.net/~ksrini/8044866/webrev/
Thanks
Kumar
PS: many thanks to Remi Forax for pushing these fixes
On 20/06/2014 15:02, Peter Levart wrote:
And, as Martin pointed out, it seems to be used for tests that
exercise particular responses from NameService API to test the
behaviour of JDK classes. It would be a shame for those tests to go away.
We've been talking about removing it for many years b
Hi Kumar,
Looks fine; thanks,
-Joe
On 06/20/2014 07:04 AM, Kumar Srinivasan wrote:
Hi Joe, all,
Please approve fix for removings warnings in asm, this is merely a
mini refresh from
upstream sources, I have verified there are no more warnings in asm
sources.
http://cr.openjdk.java.net/~ksr
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 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 P
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 mat
Hi Henry,
For the Cipher{Input, Output}Stream classes, the class itself was added
in 1.4 so it seems redundant to have the @since information on each
method too. In other words, is preserving the @since JCE 1.2 information
useful at this point?
Thanmks,
-Joe
On 06/20/2014 01:20 PM, Henry J
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, Output}Str
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 locks
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 AM,
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. Tha
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. Th
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
http://cr.openjdk.java.net/~henryjen/jdk9/8047723/0/webrev/src/javax/xml/parsers/DocumentBuilderFactory.java.ud
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 impl
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. Than
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 to
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 r
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 06/20/
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 t
33 matches
Mail list logo
