Re: RFR for JDK-8027973. javax/xml/jaxp/transform/jdk8004476/XSLTExFuncTest.java hangs (win)
On 11/21/13 4:58 AM, Patrick Zhang wrote: Hi Everyone, I am working on https://bugs.openjdk.java.net/browse/JDK-8027973. The problem is caused by wrong URL format on windows. file://c:\xxx is one invalid schema. Solution: Replace file:// with file:/// then it will work on windows and it will not impact other platforms. And remove the test from ProblemList.txt Hi Patrick, I didn't know windows needed a triple '/' - I think I learned something today ;-) May I suggest that you add the description of the problem solution (the text you wrote above) in comment in the test? It may save a lot of time to future maintainers - I think I would have had a hard time to figure that out by myself :-) best regards, -- daniel webrev: http://cr.openjdk.java.net/~pzhang/8027973/webrev/ Result on windows: http://cr.openjdk.java.net/~pzhang/8027973/XSLTExFuncTest.jtr Result on Linux: http://cr.openjdk.java.net/~pzhang/8027973/XSLTExFuncTest.linux.jtr Regards Patrick
Re: RFR for JDK-8027973. javax/xml/jaxp/transform/jdk8004476/XSLTExFuncTest.java hangs (win)
On 21/11/2013 05:20, huizhe wang wrote: Thanks for working on the issue. The fix looks good. Looks good to me too (very subtle). (A side point but should jdk be dropped from the directory name so that it is a bit more consistent with the tests in the test/javax/xml tree). -Alan
Re: RFR(2): 7174936: several String methods claim to always create new String
On 21/11/2013 04:04, Stuart Marks wrote: OK, I'll remove the String.subSequence change from this changeset and push it when I get approval. I've filed this bug: https://bugs.openjdk.java.net/browse/JDK-8028757 to cover the CharSequence.subSequence issue and potential spec change. It probably isn't that much work to do, but it probably is easier to handle it separately. Thanks, I think this is the best approach given that the subSequence issue may require clearly documenting the deviation from how it is specified in CharSequence. -Alan
Re: RFR for JDK-8027973. javax/xml/jaxp/transform/jdk8004476/XSLTExFuncTest.java hangs (win)
Hi Alan, I have renamed jdk8004476 to 8004476. And as Daniel's suggestion, add some comments to XSLTExFuncTest.java. I have updated the webrev for review. http://cr.openjdk.java.net/~pzhang/8027973/webrev/ Regards Patrick On 11/21/13 5:33 PM, Alan Bateman wrote: On 21/11/2013 05:20, huizhe wang wrote: Thanks for working on the issue. The fix looks good. Looks good to me too (very subtle). (A side point but should jdk be dropped from the directory name so that it is a bit more consistent with the tests in the test/javax/xml tree). -Alan
hg: jdk8/tl/corba: 8028215: ORB.init fails with SecurityException if properties select the JDK default ORB
Changeset: fe781b3badd6 Author:msheppar Date: 2013-11-21 11:30 + URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/fe781b3badd6 8028215: ORB.init fails with SecurityException if properties select the JDK default ORB Summary: check for default ORBImpl and ORBSingleton set via properties or System properties Reviewed-by: alanb, coffeys, mchung ! src/share/classes/org/omg/CORBA/ORB.java
Re: RFR(L) - 2nd round: 8024854: Basic changes and files to build the class library on AIX
On 20/11/2013 18:26, Volker Simonis wrote: Hi, this is the second review round for 8024854: Basic changes and files to build the class library on AIX https://bugs.openjdk.java.net/browse/JDK-8024854. The previous reviews can be found at the end of this mail in the references section. I've tried to address all the comments and suggestions from the first round and to further streamline the patch (it perfectly builds on Linux/x86_64, Linux/PPC664, AIX, Solaris/SPARC and Windows/x86_64). The biggest change compared to the first review round is the new aix/ subdirectory which I've now created under jdk/src and which contains AIX-only code. Thanks for the update and addressing all the original comments and suggestions. In particular, moving most of the AIX specific files to src/aix and including an implementation of dladdr, make a big difference and makes this much easier to review. I've skimmed through all the non-client files in the webrev and just have a few comments: NetworkLibraries.gmk - is the exclude of bsd_close.c right? It looks like it will add this to LIBNET_EXCLUDE_FILES even when building on Mac. In the old verifier code (check_code.c) then it's not clear to me that the caller wrapper is needed but in any case the change suggests to me that we should look at the malloc usages so that they better handle the size==0 case. I realize the wrappers are to avoid changing too much and it should be okay to handle this via a separate bug. In net_util.c then it's a bit ugly to be calling aix_close_init. Michael/Chris - what you would think about the JNI_OnLoad calling into a platform specific function to do platform specific initialization? The changes to java_md_solinux.c look okay to me but it makes me wonder if this should be renamed as it no longer exclusively Solaris + Linux. Port.java - one suggestion for unregisterImpl is to rename it to preUnregister and change it to protected so that it's more obvious that it supposed to be overridden. UnixNativeDispatcher.c - this looks okay (must reduced since the first round), I just wonder if the changes to *_getpwuid and *_getgrgid are really needed as this just impacts the error message. Also might be good to indent the #ifdef to be consistent with the other usages in these functions. That's mostly it. I notice that only a small number of tests have been updated. Are there more test updates to come? I'm pretty sure we have a lot more tests that may require update (searching for SunOS might give some hints). -Alan.
RFR: JDK-8023278: Reflection API methods do not throw AnnotationFormatError in case of malformed Runtime[In]VisibleTypeAnnotations attribute
Hi Please review this fix to the type annotation reflection parser. The wrong kind of exception was thrown in the case of malformed Runtime[In]VisibleTypeAnnotations . Also the parser needed to be fixed for sign issues in a handful of places. The test has tree broken classes encoded that tests a few of the error paths in the parser, I have also run the reproducer from JCK attached to the bug report and it passes. bug: https://bugs.openjdk.java.net/browse/JDK-8023278 webrev: http://cr.openjdk.java.net/~jfranck/8023278/webrev.00/ cheers /Joel
hg: jdk8/tl/jdk: 8028628: java/nio/channels/FileChannel/Size.java failed once in the same binary run
Changeset: 81708985c0a2 Author:dxu Date: 2013-11-21 14:23 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/81708985c0a2 8028628: java/nio/channels/FileChannel/Size.java failed once in the same binary run Reviewed-by: alanb, chegar, mchung, lancea ! test/java/nio/channels/FileChannel/Size.java
hg: jdk8/tl/jdk: 7065902: (file) test/java/nio/file/Files/Misc.java fails on Solaris 11 when run as root
Changeset: a74d6aa51654 Author:dxu Date: 2013-11-21 14:16 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a74d6aa51654 7065902: (file) test/java/nio/file/Files/Misc.java fails on Solaris 11 when run as root Reviewed-by: alanb ! test/java/nio/file/Files/Misc.java
Re: Map.Entry.setValue as a default method
On 11/21/2013 03:56 PM, Remi Forax wrote:
Maybe one of:
interface KoolReusablePair {
default boolean defaultEquals(Object x) { ... }
static int hashCode(KoolReusablePair self) { ... }
...
}
class KoolImpl implements KoolReusablePair {
@Override //manual opt-in:
public boolean equals(Object x) { return
KoolReusablePair.super.defaultEquals(x); }
@Override //manual opt-in:
public int hashCode() { return KoolReusablePair.hashCode(this); }
...
}
— John
The plumber in me think that a static method unlike a default method
will not pollute the itable.
...and static interface method, unlike default, will not pollute the
public API (static interface methods are not inherited).
Regards, Peter
regards,
Rémi
hg: jdk8/tl/jdk: 6703075: (process) java/lang/ProcessBuilder/Basic.java fails with fastdebug
Changeset: 89fccc5a7469 Author:martin Date: 2013-11-21 16:06 + URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/89fccc5a7469 6703075: (process) java/lang/ProcessBuilder/Basic.java fails with fastdebug Reviewed-by: alanb ! test/java/lang/ProcessBuilder/Basic.java
hg: jdk8/tl/jdk: 6402201: ProcessAttachTest.sh needs better synchronization
Changeset: 91ec3bc92793 Author:egahlin Date: 2013-11-21 13:46 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/91ec3bc92793 6402201: ProcessAttachTest.sh needs better synchronization Reviewed-by: alanb ! test/ProblemList.txt ! test/com/sun/jdi/ProcessAttachDebuggee.java ! test/com/sun/jdi/ProcessAttachTest.sh
Re: RFR(L) - 2nd round: 8024854: Basic changes and files to build the class library on AIX
Hi Alan, thanks a lot for the fast review and your valuable comments. Please find my answers inline: On Thu, Nov 21, 2013 at 1:01 PM, Alan Bateman alan.bate...@oracle.comwrote: On 20/11/2013 18:26, Volker Simonis wrote: Hi, this is the second review round for 8024854: Basic changes and files to build the class library on AIXhttps://bugs.openjdk.java.net/browse/JDK-8024854. The previous reviews can be found at the end of this mail in the references section. I've tried to address all the comments and suggestions from the first round and to further streamline the patch (it perfectly builds on Linux/x86_64, Linux/PPC664, AIX, Solaris/SPARC and Windows/x86_64). The biggest change compared to the first review round is the new aix/ subdirectory which I've now created under jdk/src and which contains AIX-only code. Thanks for the update and addressing all the original comments and suggestions. In particular, moving most of the AIX specific files to src/aix and including an implementation of dladdr, make a big difference and makes this much easier to review. I've skimmed through all the non-client files in the webrev and just have a few comments: NetworkLibraries.gmk - is the exclude of bsd_close.c right? It looks like it will add this to LIBNET_EXCLUDE_FILES even when building on Mac. You're right, that's a typo. That should have read: 48 ifneq ($(OPENJDK_TARGET_OS), aix) 49 LIBNET_EXCLUDE_FILES += aix_close.c 50 else 51 LIBNET_SRC_DIRS += $(JDK_TOPDIR)/src/aix/native/java/net/ 52 endif But actually I've just realized that it is not need at all, because 'aix_close.c' isn't in the PATH for any other OS than AIX (that could be probably called a feature of the new file layout:) So I'll simply change it to: 48 ifeq ($(OPENJDK_TARGET_OS), aix) 49 LIBNET_SRC_DIRS += $(JDK_TOPDIR)/src/aix/native/java/net/ 50 endif In the old verifier code (check_code.c) then it's not clear to me that the caller wrapper is needed but in any case the change suggests to me that we should look at the malloc usages so that they better handle the size==0 case. I realize the wrappers are to avoid changing too much and it should be okay to handle this via a separate bug. Yes, exactly. I didn't wanted to change too much code. But as the C-Standard states ( http://pubs.opengroup.org/onlinepubs/95399/functions/malloc.html) ...If size is 0, either a null pointer or a unique pointer that can be successfully passed to free() shall be returned... it is perfectly legal that malloc/calloc return a NULL pointer if called with a zero argument. This case is currently not handled (i.e. it's handled as an 'out of memory' error) in check_code.c and I agree that this should be fixed via a separate bug. In net_util.c then it's a bit ugly to be calling aix_close_init. Michael/Chris - what you would think about the JNI_OnLoad calling into a platform specific function to do platform specific initialization? What about renaming 'initLocalAddrTable()' into something like 'platformInit()' and moving the call to 'aix_close_init' to a AIX-specific version of 'platformInit()' in net_util_md.c? The changes to java_md_solinux.c look okay to me but it makes me wonder if this should be renamed as it no longer exclusively Solaris + Linux. You're right - we could rename it to something like 'java_md_unix.c'. But no matter how fancy the name would be, the file would still be in the 'src/solaris/bin' subdirectory:( So I think we'd better leave this for a later change when we completely factor out the Linux/Mac code from the 'solaris/' directory. Port.java - one suggestion for unregisterImpl is to rename it to preUnregister and change it to protected so that it's more obvious that it supposed to be overridden. Done. Also changed the comment to JavaDoc style to be more consistent with the other comments in that file. UnixNativeDispatcher.c - this looks okay (must reduced since the first round), I just wonder if the changes to *_getpwuid and *_getgrgid are really needed as this just impacts the error message. Also might be good to indent the #ifdef to be consistent with the other usages in these functions. You're right. This change was done before you fixed 7043788: (fs) PosixFileAttributes.owner() or group() throws NPE if owner/group not in passwd/group database ( http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/f91c799f7bfb). After you're fix it was automatically adapted. I've removed the special AIX handling as suggested because I think as well that another error message in the exception won't have any impact. That's mostly it. I notice that only a small number of tests have been updated. Are there more test updates to come? I'm pretty sure we have a lot more tests that may require update (searching for SunOS might give some hints). I'm currently working on it and created 8028537: PPC64: Updated jdk/test scripts to understand the AIX os and environment for it because I didn't
RFR: JDK-7065902 - (file) test/java/nio/file/Files/Misc.java fails on Solaris 11 when run as root
Hi All, Please review the simple fix towards test/java/nio/file/Files/Misc.java. It only fails when it is run by root. As Alan commented in the bug, the root has all permissions, so the test assumptions are wrong. Thanks! Bug: https://bugs.openjdk.java.net/browse/JDK-7065902 Webrev: http://cr.openjdk.java.net/~dxu/7065902/webrev/ -Dan
hg: jdk8/tl/jdk: 8028632: Update jdk/test/ProblemList.txt to reflect fix JDK-8024423
Changeset: fc9f24b9408e Author:sla Date: 2013-11-21 12:57 + URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fc9f24b9408e 8028632: Update jdk/test/ProblemList.txt to reflect fix JDK-8024423 Summary: Removed 5 testcases from the ProblemList Reviewed-by: sla Contributed-by: balchandra.vai...@oracle.com ! test/ProblemList.txt
Re: RFR: JDK-8028628 - java/nio/channels/FileChannel/Size.java failed once in the same binary run
On 11/21/2013 05:41 AM, Alan Bateman wrote: On 21/11/2013 01:09, Dan Xu wrote: Hi All, I have updated my fix based on your suggestions. I have changed to create testing files in the working directory, moved those static member variables into local method variables, and used try-with-resources to read and write the testing files. After the change, the file delete is no longer important. So I just do the clean-up with deleteOnExit() for simplicity. If the test fails, it is better to keep the test file to give more clue. Therefore, I don't put the file clean-up into finally block. Thanks! Webrev: http://cr.openjdk.java.net/~dxu/8028628/webrev01/ -Dan Just one thing about testLargeFile, I see that it additionally creates a file-mapping and it's not clear that this is needed (I don't see anything in JDK-4563125 to explain this). I suspect this can be removed. Otherwise it looks okay to me. -Alan. Hi Alan, I think the map is used to enlarge the size of the largeFile to testSize + 10. In initTestFile(), it initiates the file with size 10. My understanding is that it avoids writing large amount of data into the largeFile by using the map. Thanks! -Dan
hg: jdk8/tl/jdk: 2 new changesets
Changeset: 93826827e8b4 Author:valeriep Date: 2013-11-19 15:29 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/93826827e8b4 8026943: SQE test jce/Global/Cipher/SameBuffer failed Summary: Always use different input/output buffers when calling FeedbackCipher objects Reviewed-by: mullan ! src/share/classes/com/sun/crypto/provider/CipherBlockChaining.java ! src/share/classes/com/sun/crypto/provider/CipherCore.java ! src/share/classes/com/sun/crypto/provider/DESedeWrapCipher.java + test/com/sun/crypto/provider/Cipher/AES/TestCopySafe.java Changeset: 06d155a7c9b0 Author:valeriep Date: 2013-11-21 11:58 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/06d155a7c9b0 Merge
hg: jdk8/tl/jdk: 2 new changesets
Changeset: 2972241cf7eb Author:tyan Date: 2013-11-21 13:37 + URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2972241cf7eb 703: test/com/sun/net/httpserver/Test9a.java fails intermittently Summary: Additional stacktrace information is printed on failure Reviewed-by: alanb, dfuchs, chegar ! test/ProblemList.txt ! test/com/sun/net/httpserver/Test9a.java Changeset: ed979f9b40cd Author:tyan Date: 2013-11-21 13:42 + URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ed979f9b40cd 8022212: Intermittent test failures in java/net Reviewed-by: chegar ! test/java/net/NetworkInterface/IndexTest.java
Re: RFR: JDK-8028628 - java/nio/channels/FileChannel/Size.java failed once in the same binary run
On 21/11/2013 17:02, Dan Xu wrote: Hi Alan, I think the map is used to enlarge the size of the largeFile to testSize + 10. In initTestFile(), it initiates the file with size 10. My understanding is that it avoids writing large amount of data into the largeFile by using the map. Thanks! -Dan Okay, I guess I was really just wondering about the reliability on Windows as sometimes tests that use memory mapped files are troublesome when it comes to clean-up after the test. Also as this test hasn't run on Windows before then I wonder about how long initTestFile will take to create the 4GB file. You've probably measured already but if you need a speed up then you could change initTestFile to use a FIleChannel and create the file with the SPARSE option. Then just position to size-1 and write 1 byte. That should be faster than writing e 4 billion times. -Alan.
Re: RFR: JDK-8028628 - java/nio/channels/FileChannel/Size.java failed once in the same binary run
On 21/11/2013 01:09, Dan Xu wrote: Hi All, I have updated my fix based on your suggestions. I have changed to create testing files in the working directory, moved those static member variables into local method variables, and used try-with-resources to read and write the testing files. After the change, the file delete is no longer important. So I just do the clean-up with deleteOnExit() for simplicity. If the test fails, it is better to keep the test file to give more clue. Therefore, I don't put the file clean-up into finally block. Thanks! Webrev: http://cr.openjdk.java.net/~dxu/8028628/webrev01/ -Dan Just one thing about testLargeFile, I see that it additionally creates a file-mapping and it's not clear that this is needed (I don't see anything in JDK-4563125 to explain this). I suspect this can be removed. Otherwise it looks okay to me. -Alan.
Re: RFR: JDK-8023278: Reflection API methods do not throw AnnotationFormatError in case of malformed Runtime[In]VisibleTypeAnnotations attribute
Hi Joel, Looks fine; thanks, -Joe On 11/21/2013 11:50 AM, Joel Borggrén-Franck wrote: Hi Please review this fix to the type annotation reflection parser. The wrong kind of exception was thrown in the case of malformed Runtime[In]VisibleTypeAnnotations . Also the parser needed to be fixed for sign issues in a handful of places. The test has tree broken classes encoded that tests a few of the error paths in the parser, I have also run the reproducer from JCK attached to the bug report and it passes. bug: https://bugs.openjdk.java.net/browse/JDK-8023278 webrev: http://cr.openjdk.java.net/~jfranck/8023278/webrev.00/ cheers /Joel
Re: RFR: JDK-7065902 - (file) test/java/nio/file/Files/Misc.java fails on Solaris 11 when run as root
On 21/11/2013 19:29, Dan Xu wrote: Hi All, Please review the simple fix towards test/java/nio/file/Files/Misc.java. It only fails when it is run by root. As Alan commented in the bug, the root has all permissions, so the test assumptions are wrong. Thanks! Bug: https://bugs.openjdk.java.net/browse/JDK-7065902 Webrev: http://cr.openjdk.java.net/~dxu/7065902/webrev/ This looks okay although it's possible for users other than root to be a superuser. I think we have at least one other test that checks if /etc/passwd is writable as a crude indication as to whether the test is being run by root or not. -Alan
Re: Map.Entry.setValue as a default method
On 11/21/2013 02:08 AM, John Rose wrote:
On Nov 20, 2013, at 4:31 PM, Remi Forax fo...@univ-mlv.fr
mailto:fo...@univ-mlv.fr wrote:
But while you can declare a default hashCode and equals, it will not
work because the implementation of Object.hashCode and Object.equals
will always be preferred to the default methods by the VM, this is
how default methods are specified. Not something I'm very proud.
Next question: What's the best practice for declaring reusable code
for exactly those restricted methods (hashCode/equals, toString)?
Because of the irregularity with Object, the opt-in isn't by default,
but there should still be a convention for supplying the code as a
would-be default method.
Maybe one of:
interface KoolReusablePair {
default boolean defaultEquals(Object x) { ... }
static int hashCode(KoolReusablePair self) { ... }
...
}
class KoolImpl implements KoolReusablePair {
@Override //manual opt-in:
public boolean equals(Object x) { return
KoolReusablePair.super.defaultEquals(x); }
@Override //manual opt-in:
public int hashCode() { return KoolReusablePair.hashCode(this); }
...
}
— John
The plumber in me think that a static method unlike a default method
will not pollute the itable.
regards,
Rémi
hg: jdk8/tl/jdk: 8028215: ORB.init fails with SecurityException if properties select the JDK default ORB
Changeset: d5d4b9a63174 Author:msheppar Date: 2013-11-21 11:36 + URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d5d4b9a63174 8028215: ORB.init fails with SecurityException if properties select the JDK default ORB Summary: check for default ORBImpl and ORBSingleton set via properties or System properties Reviewed-by: alanb, coffeys, mchung + test/com/sun/corba/se/impl/orb/SetDefaultORBTest.java
Re: RFR: JDK-8028628 - java/nio/channels/FileChannel/Size.java failed once in the same binary run
Hi Alan, When looking at the FileChannel.map() method, it seems that it will not write e 4 billion times. Instead, it only extends the file size to testSize+10. It uses ftruncate() in linux and uses SetFilePointer() in Windows, which causes the file offset different on different platforms. But the performance should be good. On windows, this test runs for around 0.14 seconds in jprt machines. Thanks! -Dan On Thu 21 Nov 2013 11:51:28 AM PST, Alan Bateman wrote: On 21/11/2013 17:02, Dan Xu wrote: Hi Alan, I think the map is used to enlarge the size of the largeFile to testSize + 10. In initTestFile(), it initiates the file with size 10. My understanding is that it avoids writing large amount of data into the largeFile by using the map. Thanks! -Dan Okay, I guess I was really just wondering about the reliability on Windows as sometimes tests that use memory mapped files are troublesome when it comes to clean-up after the test. Also as this test hasn't run on Windows before then I wonder about how long initTestFile will take to create the 4GB file. You've probably measured already but if you need a speed up then you could change initTestFile to use a FIleChannel and create the file with the SPARSE option. Then just position to size-1 and write 1 byte. That should be faster than writing e 4 billion times. -Alan.
hg: jdk8/tl/nashorn: 5 new changesets
Changeset: fea9f0f9bbde Author:sundar Date: 2013-11-14 15:53 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/fea9f0f9bbde 8028161: nashorn: src/jdk/nashorn/api/scripting/ScriptEngineTest.java Reviewed-by: lagergren, hannesw ! test/src/jdk/nashorn/api/scripting/ScriptEngineTest.java Changeset: a165c0fb5be6 Author:hannesw Date: 2013-11-16 00:23 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/a165c0fb5be6 8028210: Missing conversions on array index expression Reviewed-by: attila, jlaskey, lagergren ! src/jdk/nashorn/internal/objects/NativeArguments.java ! src/jdk/nashorn/internal/objects/NativeObject.java ! src/jdk/nashorn/internal/objects/NativeString.java ! src/jdk/nashorn/internal/runtime/ScriptObject.java ! src/jdk/nashorn/internal/runtime/arrays/ArrayIndex.java + test/script/basic/JDK-8028210.js + test/script/basic/JDK-8028210.js.EXPECTED Changeset: bce2bbfb35ae Author:lagergren Date: 2013-11-18 16:35 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/bce2bbfb35ae 8028434: Line number nodes were off for while nodes and do while nodes - the line number of a loop node should be treated as the location of the test expression Reviewed-by: jlaskey, sundar ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/ir/debug/PrintVisitor.java ! src/jdk/nashorn/internal/parser/Parser.java + test/script/basic/JDK-8028434.js + test/script/basic/JDK-8028434.js.EXPECTED Changeset: b375d261e56c Author:lagergren Date: 2013-11-19 10:29 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/b375d261e56c 8028573: Line number nodes were off for while nodes and do while nodes - the line number of a loop node should be treated as the location of the test expression Reviewed-by: attila, hannesw ! test/script/basic/JDK-8028434.js Changeset: 73d741231651 Author:sundar Date: 2013-11-22 08:52 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/73d741231651 Merge
