On 14/08/2015 7:42 AM, Joseph D. Darcy wrote:
Hi David,
On 8/13/2015 2:30 PM, David Holmes wrote:
Joe,
This is making it hard to clean up everything at once. I'm already
delayed from pushing the fix because the "@key intermittent" change is
not in hs-rt yet.
If the test needs to be updated a
Hi Volker,
The internal reviews are complete and accepted.
The code looks fine. Please push it. I"ll be going on vacation so if
it breaks something,
someone else will need to pick up the pieces or back it out.
Many thanks for the work to refactor and cleanup the details.
Roger
On 8/12/1
Looks good to me.
Masayoshi
On 8/13/2015 10:54 PM, Aleksej Efimov wrote:
Hello,
Please review latest tzdata (2015f) integration into JDK9:
http://cr.openjdk.java.net/~aefimov/tzdata/2015f/9/00
Testing shows no TZ related failures on all platforms.
Thanks,
Aleksej
JBS: https://bugs.openjdk.
Hi David,
On 8/13/2015 2:30 PM, David Holmes wrote:
Joe,
This is making it hard to clean up everything at once. I'm already
delayed from pushing the fix because the "@key intermittent" change is
not in hs-rt yet.
If the test needs to be updated as part of the fix for JDK-8029453,
presumabl
Joe,
This is making it hard to clean up everything at once. I'm already
delayed from pushing the fix because the "@key intermittent" change is
not in hs-rt yet. If this change also goes in then I again have to wait
for it to arrive before I can reverse it. It will take a month for
everything
Hello,
Until a fix for JDK-8029453 is in place, the test TimeoutLockLoops.java
should be placed on the problem list for Linux since it fails
intermittently, but fairly frequently, on that OS:
--- a/test/ProblemList.txtThu Aug 13 09:36:14 2015 -0700
+++ b/test/ProblemList.txtThu Aug 13
looks OK. Nothing obvious stands out.
Best
Lance
On Aug 13, 2015, at 10:42 AM, Alexander Stepanov
wrote:
> Hello,
>
> Could you please review the following fix:
> http://cr.openjdk.java.net/~avstepan/8133480/webrev.00
> for
> https://bugs.openjdk.java.net/browse/JDK-8133480
>
> Just another
> On Aug 13, 2015, at 9:38 AM, Kumar Srinivasan
> wrote:
>
> 3. void JLI_InitArgProcessing(jboolean isJava, jboolean disableArgFile) {
>// No expansion for relaunch
>
>
> The launcher might re-exec itself, this might happen under certain
> circumstances on *nix, is the above logic to prev
Henry,
I am still not complete, but here are some more comments and specifics.
args.c
1.
-static int firstAppArgIndex = -1;
+#define NOT_FOUND -1;
+static int firstAppArgIndex = NOT_FOUND;
2.
// Any @argument comes in here is an argument as is.
// Expansion should had done before c
Hello,
Could you please review the following fix:
http://cr.openjdk.java.net/~avstepan/8133480/webrev.00
for
https://bugs.openjdk.java.net/browse/JDK-8133480
Just another portion of deprecated tags replaced with {@code }.
A single misprint was fixed; no other changes indicated by specdiff.
Tha
Hello,
Please review latest tzdata (2015f) integration into JDK9:
http://cr.openjdk.java.net/~aefimov/tzdata/2015f/9/00
Testing shows no TZ related failures on all platforms.
Thanks,
Aleksej
JBS: https://bugs.openjdk.java.net/browse/JDK-8133321
11 matches
Mail list logo