RFR: 7186311: (props) Unicode is misspelled as Uniocde in JavaDoc and error message
Hi, Please help review this trivial javadoc typo fix. http://cr.openjdk.java.net/~sherman/7186311/webrev Thanks, -Sherman
Re: RFR: 7186311: (props) Unicode is misspelled as Uniocde in JavaDoc and error message
On 14/09/2013 07:49, Xueming Shen wrote: Hi, Please help review this trivial javadoc typo fix. http://cr.openjdk.java.net/~sherman/7186311/webrev Looks good. -Alan.
Re: RFR: 7186311: (props) Unicode is misspelled as Uniocde in JavaDoc and error message
I had to look at it a few times ;-) Looks fine to me. -Chris On 14 Sep 2013, at 07:49, Xueming Shen xueming.s...@oracle.com wrote: Hi, Please help review this trivial javadoc typo fix. http://cr.openjdk.java.net/~sherman/7186311/webrev Thanks, -Sherman
Re: RFR: 8920687: Deflater.setLevel does not work as expected
On 13/09/2013 20:44, Xueming Shen wrote: Hi, This is change to clarify the java doc to match the existing behavior. If there is a pending level/strategy change (via setLevel/Stragety()) when deflate(...) is invoked, the implementation goes down to zlib's deflateParams() for deflating operation, which clearly specifies its behavior in zlib.h as Dynamically update the compression level and compression strategy. The interpretation of level and strategy is as in deflateInit2. This can be used to switch between compression and straight copy of the input data, or to switch to a different kind of input data requiring a different strategy. If the compression level is changed, the input available so far is compressed with the old level (and may be flushed); the new level will take effect only at the next call of deflate(). - and its corresponding implementation does exactly that. It seems reasonable to have new strategy or level take effect after the available input has been compressed. Your proposed wording is okay but I wonder if the word current should be dropped from the existing statement in setLevel. You might also be able to get away with a single statement too, something like If changed, the new compression strategy takes effect after the input available has been compressed (or flushed). Your wording is okay too if you really need to be explicit about deflate being called. -Alan
hg: jdk8/tl/langtools: 8024207: javac crash in Flow.AssignAnalyzer.visitIdent
Changeset: 03c26c60499c Author:vromero Date: 2013-09-14 15:23 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/03c26c60499c 8024207: javac crash in Flow.AssignAnalyzer.visitIdent Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Resolve.java + test/tools/javac/T8024207/FlowCrashTest.java + test/tools/javac/T8024207/FlowCrashTest.out
hg: jdk8/tl/jdk: 2 new changesets
Changeset: 3255a4e348a1 Author:rriggs Date: 2013-09-14 13:55 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3255a4e348a1 8023639: Difference between LocalTime.now(Clock.systemDefaultZone()) and LocalTime.now() executed successively is more than 100 000 000 nanoseconds for slow machines Summary: Test timed out on a slow machine; it is not a conformance test and should be in the test subtree Reviewed-by: darcy, sherman ! test/java/time/tck/java/time/TCKLocalTime.java ! test/java/time/test/java/time/TestLocalTime.java Changeset: 35bb1c7f227c Author:rriggs Date: 2013-09-14 13:55 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/35bb1c7f227c 8023556: Update javadoc for start of Meiji era Summary: correct the javadoc in JapaneseEra.MEIJI to match the implementation Reviewed-by: darcy, sherman ! src/share/classes/java/time/chrono/JapaneseEra.java ! test/java/time/test/java/time/TestLocalTime.java
hg: jdk8/tl/langtools: 7047734: javac, the LVT is not generated correctly in several scenarios
Changeset: 4932bb04c4b8 Author:vromero Date: 2013-09-14 19:04 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/4932bb04c4b8 7047734: javac, the LVT is not generated correctly in several scenarios Reviewed-by: jjg, mcimadamore ! src/share/classes/com/sun/tools/javac/code/Lint.java ! src/share/classes/com/sun/tools/javac/comp/Flow.java ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/share/classes/com/sun/tools/javac/comp/TransTypes.java ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/share/classes/com/sun/tools/javac/jvm/Code.java ! src/share/classes/com/sun/tools/javac/jvm/Gen.java ! src/share/classes/com/sun/tools/javac/jvm/Items.java + src/share/classes/com/sun/tools/javac/jvm/LVTRanges.java ! src/share/classes/com/sun/tools/javac/tree/TreeMaker.java ! src/share/classes/com/sun/tools/javac/util/Bits.java + test/tools/javac/flow/AliveRanges.java + test/tools/javac/flow/LVTHarness.java + test/tools/javac/flow/tests/TestCaseConditional.java + test/tools/javac/flow/tests/TestCaseDoLoop.java + test/tools/javac/flow/tests/TestCaseFor.java + test/tools/javac/flow/tests/TestCaseForEach.java + test/tools/javac/flow/tests/TestCaseIf.java + test/tools/javac/flow/tests/TestCaseIfElse.java + test/tools/javac/flow/tests/TestCaseSwitch.java + test/tools/javac/flow/tests/TestCaseTry.java + test/tools/javac/flow/tests/TestCaseWhile.java
Re: RFR [8023130] (process) ProcessBuilder#inheritIO does not work on Windows
On 12.09.2013 19:21, Alan Bateman wrote: On 12/09/2013 06:59, Ivan Gerasimov wrote: Hello Alan, Martin, everyone! Some update on the issue. When trying to integrate my test into Basic.java, I found that it already contains exactly the same. I have just overlooked it before. Additional investigation showed that inheritIO() doesn't always fail on Windows. If the scenario is like following: - java application creates a child java process (no IO inheritance, redirecting IO through pipes by default), - child process creates a grandchild which inherits the child's stdin/out/err, everything works as expected. However, if the java app (started from a console) creates an immediate child that inherits its parent stdin/out/err, it fails. That's why this bug hasn't been caught by Basic.java before - because it uses the first testing scenario. And that's why I had to introduce a new shell script test - because the problem couldn't be reproduced otherwise. Would you please review the updated webrev? http://cr.openjdk.java.net/~igerasim/8023130/1/webrev/ http://cr.openjdk.java.net/%7Eigerasim/8023130/1/webrev/ Based on the previous mails then the update to ProcessImpl_md.c seems right. It's probably best to give this one some bake time in jdk8 before you backport it to jdk7u-dev. The reason is that the Process code likes to bite back when it is changed. On the tests then you probably know we don't like shell tests because they are usually slower and statistically more troublesome. Given the scenario that you are trying to test (and it's useful that you've got to the bottom of the issue) there they may not be other options here. One small concern with the shell test as it stands is that it looks like it is depend on the exact output. This makes me wonder about how it will behave with a debug or fastdebug build that might have additional output. I only changed the way the test is called. When the same test is run from Basic.java, it's also expected to receive some certain output. So I think that if it worked well from Basic.java, it should also work from the shell script. Also a minor point but it might be more readable if the body of the for statement was indented. Yes, done. Would you please review the updated webrev? http://cr.openjdk.java.net/~igerasim/8023130/2/webrev/ http://cr.openjdk.java.net/%7Eigerasim/8023130/2/webrev/ Sincerely yours, Ivan -Alan.
Re: RFR [8023130] (process) ProcessBuilder#inheritIO does not work on Windows
On 14.09.2013 22:58, Ivan Gerasimov wrote: On 12.09.2013 19:21, Alan Bateman wrote: On 12/09/2013 06:59, Ivan Gerasimov wrote: Hello Alan, Martin, everyone! Some update on the issue. When trying to integrate my test into Basic.java, I found that it already contains exactly the same. I have just overlooked it before. Additional investigation showed that inheritIO() doesn't always fail on Windows. If the scenario is like following: - java application creates a child java process (no IO inheritance, redirecting IO through pipes by default), - child process creates a grandchild which inherits the child's stdin/out/err, everything works as expected. However, if the java app (started from a console) creates an immediate child that inherits its parent stdin/out/err, it fails. That's why this bug hasn't been caught by Basic.java before - because it uses the first testing scenario. And that's why I had to introduce a new shell script test - because the problem couldn't be reproduced otherwise. Would you please review the updated webrev? http://cr.openjdk.java.net/~igerasim/8023130/1/webrev/ http://cr.openjdk.java.net/%7Eigerasim/8023130/1/webrev/ Based on the previous mails then the update to ProcessImpl_md.c seems right. It's probably best to give this one some bake time in jdk8 before you backport it to jdk7u-dev. The reason is that the Process code likes to bite back when it is changed. On the tests then you probably know we don't like shell tests because they are usually slower and statistically more troublesome. Given the scenario that you are trying to test (and it's useful that you've got to the bottom of the issue) there they may not be other options here. One small concern with the shell test as it stands is that it looks like it is depend on the exact output. This makes me wonder about how it will behave with a debug or fastdebug build that might have additional output. I only changed the way the test is called. When the same test is run from Basic.java, it's also expected to receive some certain output. So I think that if it worked well from Basic.java, it should also work from the shell script. Update: Of course I tested it with JPRT, and the tests passed well on all platforms. Though JPRT only run product versions of the tests. Sincerely, Ivan Also a minor point but it might be more readable if the body of the for statement was indented. Yes, done. Would you please review the updated webrev? http://cr.openjdk.java.net/~igerasim/8023130/2/webrev/ http://cr.openjdk.java.net/%7Eigerasim/8023130/2/webrev/ Sincerely yours, Ivan -Alan.
RFR: JDK-7123493 : (proxy) Proxy.getProxyClass doesn't scale under high load
Hi folks, Looking to backport this fix to JDK7. The backport has resulted in relatively minor changes to the original fix such as replicating the BiFunction / Supplier interfaces in a limited sense as inner classes in WeakCache. http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7123493 Original review thread: http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-April/015854.html -Rob
Re: RFR: JDK-7123493 : (proxy) Proxy.getProxyClass doesn't scale under high load
...and the actual webrev: http://cr.openjdk.java.net/~robm/7123493/webrev.01/ http://cr.openjdk.java.net/%7Erobm/7123493/webrev.01/ -Rob On 15/09/13 00:21, Rob McKenna wrote: Hi folks, Looking to backport this fix to JDK7. The backport has resulted in relatively minor changes to the original fix such as replicating the BiFunction / Supplier interfaces in a limited sense as inner classes in WeakCache. http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7123493 Original review thread: http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-April/015854.html -Rob
Re: RFR: 8022749: Convert junit tests to testng in test/java/lang/invoke
Thanks for the heads up. I noticed this just now; after refreshing my repos half of the tests fail. Where is the doc that says how to run jtreg and ant (Netbeans) now that my tests have been changed for me? — John On Aug 12, 2013, at 2:17 AM, Alan Bateman alan.bate...@oracle.com wrote: On 10/08/2013 01:25, Henry Jen wrote: Hi, Please review a webrev contributed by Mani Sarkar that converts junit tests in test/java/lang/invoke to testng. http://cr.openjdk.java.net/~henryjen/tl/8022749/0/webrev/ Cheers, Henry This looks good to me (but cc'ing mlvm-dev so that John/Christian/others that might run these tests interactively are aware of this). -Alan. ___ mlvm-dev mailing list mlvm-...@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
