Re: [PATCH] Review Request - Test bug: 6948101 java/rmi/transport/pinLastArguments/PinLastArguments.java failing intermittently
On 27/06/2012 4:57 PM, Eric Wang wrote: Hi David Stuart, Thank you for the help! please review the in webrev 6948101.zip in attachment. Thanks Eric. That fix also seems fine to me. David Regards, Eric On 2012/6/27 9:14, Stuart Marks wrote: Hi Eric, Alan Bateman asked me to help you out with this since he's going to be unavailable for a couple weeks. I didn't see you on the OpenJDK census [1] so you might not have an Author role and thus the ability to post webrevs. If indeed you don't, I can post a webrev for you. I can also post a webrev for your other review (7123972) if it's still necessary. Finally, I can push the fixes for you when the reviews are complete. s'marks [1] http://openjdk.java.net/census On 6/26/12 2:56 PM, David Holmes wrote: Hi Eric, On 26/06/2012 7:26 PM, Eric Wang wrote: Please help to review the fix attached for test bug 6948101 http://monaco.us.oracle.com/detail.jsf?cr=6948101 which is same root cause as bug 7123972 http://monaco.us.oracle.com/detail.jsf?cr=7123972. The test makes wrong assumption that GC is started immediately to recycle unused objects after System.gc() called. The proposed fix is to make sure objects have been recycled by GC before checking if the weak reference is null. Again I really need to see a webrev to see the fix in context. Do you have Author role and an OpenJDK user name so you can post webrevs on cr.openjdk.java.net? I suspect this may have the same issues as the other fix and require a timeout for when the original problem is still present. Thanks, David Regards, Eric
Re: Bug 7176907 - Patches for javac warnings cleanup (text and util) from Adopt OpenJDK
Hi Kurchi, Thanks for updating this. This looks good to me. I guess Stuart will be sponsoring the patch. For his sins he's kindly offered to do so yes :-) There are a couple of other switch statements in src/share/classes/java/util/regex/Pattern.java. which are not throwing fallthrough warnings (in Netbeans at least), although there is fallthrough happening from one case to another. From what I notice, only if there is a break statement missing before the default case, does Netbeans throw some warning. Is the fallthrough warning technically supposed to be thrown only when the logic falls through to the default case then? That's my understanding with the javac compiler yes. I think it was the balance that the javac folk thought was a sensible compromise in terms of not generating too many false positive warnings. Cheers, Martijn
Re: [PATCH] Review Request - Test bug: 6948101 java/rmi/transport/pinLastArguments/PinLastArguments.java failing intermittently
Hi David, Thank you for review! Hi Stuart, Can you please help to review and post the webrev, Thanks a lot! Eric On 2012/6/27 15:32, David Holmes wrote: On 27/06/2012 4:57 PM, Eric Wang wrote: Hi David Stuart, Thank you for the help! please review the in webrev 6948101.zip in attachment. Thanks Eric. That fix also seems fine to me. David Regards, Eric On 2012/6/27 9:14, Stuart Marks wrote: Hi Eric, Alan Bateman asked me to help you out with this since he's going to be unavailable for a couple weeks. I didn't see you on the OpenJDK census [1] so you might not have an Author role and thus the ability to post webrevs. If indeed you don't, I can post a webrev for you. I can also post a webrev for your other review (7123972) if it's still necessary. Finally, I can push the fixes for you when the reviews are complete. s'marks [1] http://openjdk.java.net/census On 6/26/12 2:56 PM, David Holmes wrote: Hi Eric, On 26/06/2012 7:26 PM, Eric Wang wrote: Please help to review the fix attached for test bug 6948101 http://monaco.us.oracle.com/detail.jsf?cr=6948101 which is same root cause as bug 7123972 http://monaco.us.oracle.com/detail.jsf?cr=7123972. The test makes wrong assumption that GC is started immediately to recycle unused objects after System.gc() called. The proposed fix is to make sure objects have been recycled by GC before checking if the weak reference is null. Again I really need to see a webrev to see the fix in context. Do you have Author role and an OpenJDK user name so you can post webrevs on cr.openjdk.java.net? I suspect this may have the same issues as the other fix and require a timeout for when the original problem is still present. Thanks, David Regards, Eric
Re: Bug 7176907 - Patches for javac warnings cleanup (text and util) from Adopt OpenJDK
Hi all, We've been working on improving the workflow for our patch review system and so the new locations for the patches are at: https://raw.github.com/AdoptOpenJDK/PatchReview/master/5-submitted/javac_warnings/core_java_text.patch https://raw.github.com/AdoptOpenJDK/PatchReview/master/5-submitted/javac_warnings/core_java_util.patch Cheers, Martijn On 27 June 2012 08:58, Martijn Verburg martijnverb...@gmail.com wrote: Hi Kurchi, Thanks for updating this. This looks good to me. I guess Stuart will be sponsoring the patch. For his sins he's kindly offered to do so yes :-) There are a couple of other switch statements in src/share/classes/java/util/regex/Pattern.java. which are not throwing fallthrough warnings (in Netbeans at least), although there is fallthrough happening from one case to another. From what I notice, only if there is a break statement missing before the default case, does Netbeans throw some warning. Is the fallthrough warning technically supposed to be thrown only when the logic falls through to the default case then? That's my understanding with the javac compiler yes. I think it was the balance that the javac folk thought was a sensible compromise in terms of not generating too many false positive warnings. Cheers, Martijn
Re: RFR : 7162902 / 6893617 Umbrella port of a number of corba bug fixes from JDK 6 to jdk7u/8
Hi Sean, I think this looks good. ship it :-) Best Lance On Jun 25, 2012, at 4:26 PM, Sean Coffey wrote: Hi, I'm looking for a code review around the following corba changes. It turns out that we've a few bug fixes in corba area for jdk6 that were never forward ported to jdk7 or 8. The port is pretty much identical to what was used in JDK6. Some formatting and diamond operator changes introduced but that's about it. There were a few bug fixes to follow up on regressions around the initial fix but this umbrella port should cover all issues. The initial bugs fixes were fixed under the jets category in the bug tool and that category entered read only mode over a year ago. Hence the requirement for a new bug ID. The main bug fix is 6725987 which is an issue where references to the ORB were being kept after ORB.destroy was called. http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7162902 An accompanying CNCtx fix in JDK repo is also made to correct an issue where the java.naming.corba.orb system property wasn't used correctly. (CR 6893617) http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6893617 Corba testsuites run and no issues seen. I've also run some JCK testing and saw no issues. http://cr.openjdk.java.net/~coffeys/webrev.7162902.jdk8/ (corba) http://cr.openjdk.java.net/~coffeys/webrev.6893617.jdk8/ (jdk) The corba codebase code formatting seems to vary quite a bit. I've reformatted in a small number of areas but the whole corba repo probably warrants it's own clean up project at a later date. regards, Sean. Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 lance.ander...@oracle.com
Re: Codereview request for 7130915: File.equals does not give expected results when path contains Non-English characters on Mac OS X
I welcome this issue is getting some serious attention then. When will this be backported to 7u? -- David On 24.06.2012, at 18:58, Xueming Shen wrote: Yes, I believe the issue described in MACOSX_PORT-165 is the same issue this patch is trying to solve. Btw, it appears there are typos in the note(2), my mini keyboard obviously is too sticky:-) (2) normalize the resulting file name from macosx fs APIs from nfd-nfc before passing back to java.io.File (File.list() and canonicalize()), so we deal with nfc file name (as usual) for java.io classes/APIs. -sherman On 6/24/12 7:50 AM, David Kocher wrote: Will this address issue MACOSX_PORT-165 [1]? [1] http://java.net/jira/browse/MACOSX_PORT-165 -- David On 22.06.2012, at 19:01, Xueming Shen wrote: Hi Here is the proposed change to support Unicode nfd/nfc and case insensitive file path on MacOSX file system. 7130915: File.equals does not give expected results when path contains Non-English characters on Mac OS X 7168427: FileInputStream cannot open file where the file path contains asian characters [macosx] While these two bug reports are only against java.io, we have the same issue in javax.nio.file. Here is the webrev http://cr.openjdk.java.net/~sherman/7130915_7168427/webrev/ Here is the brief summary of the changes java.io.File: (1) removed nfc-nfd conversion in io_util.h/WITH_PLATFORM_STRING, which means we are now passing nfc/composite characters directly into macosx file system APIs without normalize them to nfd. It appears macosx fs APIs do take nfc, though it uses nfd. (2) normalize the resulting file name from macosx fs APIs from nfd-nfd before passing back to java.io.File (File.list() and canonicalize()), so we deal with nfdc file name (as usual) for java.io classes/APIs. (3) fs.compare()/hashCode() was updated to be case insensitive (4) hasCode() was updated to use the new String.hash32(). java.nio.file: (5) added a setof MacOSXFile... on top of existing BsdFile... classes. An alternative is to update those BsdFile... classes directly to address the macosx specific issues. But given there might be developers over there might work on open jdk BSD port and have dependency on these classes, it might be desirable to have another separate layer of MacOSXFile... classes. So now the default FileSystem/Provider is MacOSXFileSystemProvider and MacOSXFileSystem. (6) the main changes are in MacOSXFileSystem, in which the corresponding methods were added to handle, case insensitive and nfd=nfc normalization, including the pathmatcher. (7) compare is now are case-insensitive (8) hashCode is now murmur3_32(), this is true for all Solaris/Unix/Linux and maxosx. Though lots of files have been touched, but the line of changes are actually relatively small. The proposed change only deals with the default case-sensitiveness seting, which is case insensitive. On MaxOSX, you actually can configure the HFS+ file system or the mounted vol to be case-sensitive. A possible approach is to have some extra FileStore attributes, such as a isCaseSensitive and to use case sensitive compare/equal on such fs, but this can be dealt with separately later. Thanks, -Sherman
Re: String.subSequence and CR#6924259: Remove offset and count fields from java.lang.String
Hi Mike, Yes, all that you say below is true. CharSequence is an interface that does not define the contract of identity when implementations/subtypes of CharSequence do - each in it's own way. Much like java.util.Collection and List vs. Set. It's always dangerous for methods that return such interfaces when the implementation class of the returned instance changes so that it defines a different hidden contract. It is unfortunately also true that now there is no official way of comparing/equating/hashing a substring without copying the characters. It feels like standard Java SE API is lacking a part of functionality. Maybe this space could be filled with the addition of a new public immutable CharSequence subtype - like Rope: http://ahmadsoft.org/ropes/doc/index.html Regards, Peter On Friday, June 22, 2012 03:15:40 PM Mike Duigou wrote: I've made a test implementation of subSequence() utilizing an inner class with offset and count fields to try to understand all the parts that would be impacted. My observations thus far: - The specification of the subSequence() method is currently too specific. It says that the result is a subString(). This would no longer be true. Hopefully nobody assumed that this meant they could cast the result to String. I know, why would you if you can just call subString() instead? I've learned to assume that somebody somewhere does always does the most unexpected thing. - The CharSequences returned by subSequence would follow only the general CharSequence rules for equals()/hashCode(). Any current usages of the result of subSequence for equals() or hashing, even though it's not advised, would break. We could add equals() and hashCode() implementations to the CharSequence returned but they would probably be expensive. - In general I wonder if parsers will be satisfied with a CharSequence that only implements identity equals(). - I also worry about applications that currently do use subSequence currently and which will fail when the result is not a String instance as String.equals() will return false for all CharSequences that aren't Strings. ie. CharSequence token = line.subSequence(line, start, end); if (keyword.equals(token)) ... This would now fail. At this point I wonder if this is a feature worth pursuing. Mike On Jun 3 2012, at 13:44 , Peter Levart wrote: On Thursday, May 31, 2012 03:22:35 AM mike.dui...@oracle.com wrote: Changeset: 2c773daa825d Author:mduigou Date: 2012-05-17 10:06 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2c773daa825d 6924259: Remove offset and count fields from java.lang.String Summary: Removes the use of shared character array buffers by String along with the two fields needed to support the use of shared buffers. Wow, that's quite a change. So .substring() is not O(1) any more? Doesn't this have impact on the performance of parsers and such that rely on the performance caracteristics of the .substring() ? Have you considered then implementing .subSequence() not in terms of just delegating to .substring() but returning a special CharSequence view over the chars of the sub-sequence?
hg: jdk8/tl/jdk: 6893617: JDK 6 CNCtx always uses the default ORB
Changeset: 612e56cf284c Author:coffeys Date: 2012-06-27 21:10 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/612e56cf284c 6893617: JDK 6 CNCtx always uses the default ORB Reviewed-by: lancea ! src/share/classes/com/sun/jndi/cosnaming/CNCtx.java
hg: jdk8/tl/corba: 7162902: Umbrella port of a number of corba bug fixes from JDK 6 to jdk7u/8
Changeset: 47adb42076f1 Author:coffeys Date: 2012-06-27 21:09 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/47adb42076f1 7162902: Umbrella port of a number of corba bug fixes from JDK 6 to jdk7u/8 Reviewed-by: lancea ! src/share/classes/com/sun/corba/se/impl/encoding/CachedCodeBase.java ! src/share/classes/com/sun/corba/se/impl/interceptors/PIHandlerImpl.java ! src/share/classes/com/sun/corba/se/impl/interceptors/PINoOpHandlerImpl.java ! src/share/classes/com/sun/corba/se/impl/monitoring/MonitoringManagerFactoryImpl.java ! src/share/classes/com/sun/corba/se/impl/monitoring/MonitoringManagerImpl.java ! src/share/classes/com/sun/corba/se/impl/orb/ORBImpl.java ! src/share/classes/com/sun/corba/se/impl/orbutil/threadpool/ThreadPoolImpl.java ! src/share/classes/com/sun/corba/se/impl/orbutil/threadpool/ThreadPoolManagerImpl.java ! src/share/classes/com/sun/corba/se/impl/orbutil/threadpool/WorkQueueImpl.java ! src/share/classes/com/sun/corba/se/impl/protocol/CorbaMessageMediatorImpl.java ! src/share/classes/com/sun/corba/se/impl/transport/SelectorImpl.java ! src/share/classes/com/sun/corba/se/spi/logging/data/ORBUtil.mc ! src/share/classes/com/sun/corba/se/spi/monitoring/MonitoringManager.java ! src/share/classes/com/sun/corba/se/spi/monitoring/MonitoringManagerFactory.java ! src/share/classes/com/sun/corba/se/spi/orb/ORB.java ! src/share/classes/com/sun/corba/se/spi/orbutil/threadpool/ThreadPool.java ! src/share/classes/com/sun/corba/se/spi/orbutil/threadpool/ThreadPoolManager.java ! src/share/classes/com/sun/corba/se/spi/protocol/PIHandler.java ! src/share/classes/com/sun/corba/se/spi/protocol/RequestDispatcherRegistry.java
Re: Patch review request - Test bug 7123972 test/java/lang/annotation/loaderLeak/Main.java fails intermittently
I've posted the webrev here: http://cr.openjdk.java.net/~smarks/yiming.wang/7123972/webrev.0/ I've looked at the changes and they seem fine. It's interesting that the run times take 30-60 sec in your experience. I've run them on my system (Linux in a virtual machine) and they usually run in 10-20 sec. In any case, as you say, if the test times out it indicates there really was a failure. I'll give people a chance to look at the webrev and if there aren't any more comments in another day or so I'll push in the changeset. Thanks for developing this! s'marks On 6/26/12 11:50 PM, Eric Wang wrote: Hi David, Thank you! I run the test several times on 3 platforms (windows, solaris and linux), the average execution time is 30secs to 60secs. if the test hang 2 minutes, there should be something wrong. Hi Marks, I don't have the author role, Can you please help to review and post the webrev 7123972.zip in attachment if it is OK, Thanks a lot! Regards, Eric On 2012/6/27 14:19, David Holmes wrote: Eric, Ignore my comment about adding the timeouts. As Alan reminded me if the test would hang then jtreg will time it out after two minutes anyway. So this is good to go as far as I am concerned. Thanks, David On 27/06/2012 7:51 AM, David Holmes wrote: Thanks Eric. So to summarize: - we create a custom classloader, load a class through it and store a reference to that Class in a WeakReference - we then drop the reference to the loader At this point the only reference to the loader is from the Class loaded, which in turn is only weakly reachable. I must confess that I'm unclear why this test should be failing in its original form. The first gc() should remove the strong reference to the loader. That leaves a weak cycle: WeakRef - Class - Loader - Class. The second gc() should detect the cycle and clear the WeakRef. I guess the problem is that depending on which gc is in use the actual gc() calls may not in fact induce every possible GC action. The fix seems reasonable in that regard - keep gc'ing and finalizing till we see the loader is gone, and so the WeakReference should be cleared. The original bug would cause a ref to the Class to remain (from the annotation) and hence the WeakRef would not be cleared. However, in that case the loader would also be strongly referenced and so never become finalizable. So if this test was now run against a JDK with the original bug, the test would hang. So I think we need to add a timeout in there as well. David On 25/06/2012 6:06 PM, Eric Wang wrote: On 2012/6/21 20:16, David Holmes wrote: Hi Eric, On 21/06/2012 8:57 PM, Eric Wang wrote: Hi David, Thanks for your review, I have updated the code by following your suggestion. please see the attachment. I'm not sure whether there's a better way to guarantee object finalized by GC definitely within the given time. The proposed fix may work in most cases but may still throw InterruptException if execution is timeout (2 minutes of JTreg by default). There is no way to guarantee finalization in a specific timeframe, but if a simple test hasn't executed finalizers in 2 minutes then that in itself indicates a problem. Can you post a full webrev for this patch? I don't like seeing it out of context and am wondering exactly what we are trying to GC here. David Regards, Eric On 2012/6/21 14:32, David Holmes wrote: Hi Eric, On 21/06/2012 4:05 PM, Eric Wang wrote: I come from Java SQE team who are interested in regression test bug fix. Here is the first simple fix for bug 7123972 http://monaco.us.oracle.com/detail.jsf?cr=7123972, Can you please help to review and comment? Attachment is the patch Thanks! This bug is caused by wrong assumption that the GC is started immediately to recycle un-referenced objects after System.gc() called one or two times. The proposed solution is to make sure the un-referenced object is recycled by GC before checking if the reference is null. Your patch makes its own assumptions - specifically that finalization must eventually run. At a minimum you should add System.runFinalization() calls after the System.gc() inside the loop. Even that is no guarantee in a general sense, though it should work for hotspot. David Regards, Eric Hi Alan David, Thank you for your comments, sorry for reply this mail late as i was just back from the dragon boat holiday. I have updated the code again based on your suggestions: rename the flag variable, increase the sleep time and remove it from problem list. The attachment is the full webrev for this patch, Can you please review again? Thanks a lot! Regards, Eric
Re: Patch review request - Test bug 7123972 test/java/lang/annotation/loaderLeak/Main.java fails intermittently
Eric, Ignore my comment about adding the timeouts. As Alan reminded me if the test would hang then jtreg will time it out after two minutes anyway. So this is good to go as far as I am concerned. Thanks, David On 27/06/2012 7:51 AM, David Holmes wrote: Thanks Eric. So to summarize: - we create a custom classloader, load a class through it and store a reference to that Class in a WeakReference - we then drop the reference to the loader At this point the only reference to the loader is from the Class loaded, which in turn is only weakly reachable. I must confess that I'm unclear why this test should be failing in its original form. The first gc() should remove the strong reference to the loader. That leaves a weak cycle: WeakRef - Class - Loader - Class. The second gc() should detect the cycle and clear the WeakRef. I guess the problem is that depending on which gc is in use the actual gc() calls may not in fact induce every possible GC action. The fix seems reasonable in that regard - keep gc'ing and finalizing till we see the loader is gone, and so the WeakReference should be cleared. The original bug would cause a ref to the Class to remain (from the annotation) and hence the WeakRef would not be cleared. However, in that case the loader would also be strongly referenced and so never become finalizable. So if this test was now run against a JDK with the original bug, the test would hang. So I think we need to add a timeout in there as well. David On 25/06/2012 6:06 PM, Eric Wang wrote: On 2012/6/21 20:16, David Holmes wrote: Hi Eric, On 21/06/2012 8:57 PM, Eric Wang wrote: Hi David, Thanks for your review, I have updated the code by following your suggestion. please see the attachment. I'm not sure whether there's a better way to guarantee object finalized by GC definitely within the given time. The proposed fix may work in most cases but may still throw InterruptException if execution is timeout (2 minutes of JTreg by default). There is no way to guarantee finalization in a specific timeframe, but if a simple test hasn't executed finalizers in 2 minutes then that in itself indicates a problem. Can you post a full webrev for this patch? I don't like seeing it out of context and am wondering exactly what we are trying to GC here. David Regards, Eric On 2012/6/21 14:32, David Holmes wrote: Hi Eric, On 21/06/2012 4:05 PM, Eric Wang wrote: I come from Java SQE team who are interested in regression test bug fix. Here is the first simple fix for bug 7123972 http://monaco.us.oracle.com/detail.jsf?cr=7123972, Can you please help to review and comment? Attachment is the patch Thanks! This bug is caused by wrong assumption that the GC is started immediately to recycle un-referenced objects after System.gc() called one or two times. The proposed solution is to make sure the un-referenced object is recycled by GC before checking if the reference is null. Your patch makes its own assumptions - specifically that finalization must eventually run. At a minimum you should add System.runFinalization() calls after the System.gc() inside the loop. Even that is no guarantee in a general sense, though it should work for hotspot. David Regards, Eric Hi Alan David, Thank you for your comments, sorry for reply this mail late as i was just back from the dragon boat holiday. I have updated the code again based on your suggestions: rename the flag variable, increase the sleep time and remove it from problem list. The attachment is the full webrev for this patch, Can you please review again? Thanks a lot! Regards, Eric
Re: Fwd: Codereview request for 7130915: File.equals does not give expected results when path contains Non-English characters on Mac OS X
On 27/06/2012 04:33, Xueming Shen wrote: Alan, Webrev has been updated accordingly at http://cr.openjdk.java.net/~sherman/7130915/webrev with changes (1) added a CFStringCreateMutable(...) != null check in both io and nio native, though it is unlikely to fail here because we are passing a NULL and 0 length, like new StringBuilder() invocation, if it fails the system probably goes very wrong. Both FStringAppendCharacters and CFStringNormalize are void return type. (2) The first line of path.toCharArray in normalizeJavaPath is a typo, it is supposed to be deleted. The implementation only goes toCharArray when it needs to go native. Currently it uses 0x80 as the fast path criteria, it is possible to expose some sun.text.normalizer's internal methods to have a quick nfc check, but I'm not sure how much the performance gain would be, but might worth some investigation later. (3) Comments have been added for those override-able methods in UnixFileSystem. (4) blank lines have been removed from dispatcher.c (5) I don't think we need to do the HFS check, given we are only doing nfc/nfd stuff now, as long as it is a MacOSX, I believe its nfc/nfd layer will be there. Copyright has been re-copy/ pasted and we now only use only bugid. -Sherman I'm heading away on vacation now and only quickly scanned the updated webrev. All looks okay to me. On the calls to the CF functions then one thing is that if they fail (and this is unlikely I know) then you won't have an exception pending so may need to add code to call one of the JNU* functions to throw OOME, otherwise it might cause a NPE in the caller rather than throwing an exception as you would expect. -Alan
Re: RFR [7u6]: 7166896: DocumentBuilder.parse(String uri) is not IPv6 enabled. It throws MalformedURLException
Hi,
On Jun 26, 2012, at 11:59 PM, Joe Wang wrote:
Hi Paul,
That method was contributed by engineers from Korea and intended to handle
paths that contained international characters, so that was how it was named.
It was an extra processing added. Outside of that scenario, we'd want to skip
the process and get back to letting URL handle the input, whether the system
id contains space or '[', and etc.
Your fix will fail if there is an IPv6 encoded address for the host part and
there are non-ASCII characters present in, for example, the path part.
If the intent is to *never* percent encode ASCII characters you should change
the following (and JavaDoc) to be consistent:
2638 // for each byte
2639 for (i = 0; i len; i++) {
2640 b = bytes[i];
2641 // for non-ascii character: make it positive, then escape
2642 if (b 0) {
2643 ch = b + 256;
2644 buffer.append('%');
2645 buffer.append(gHexChs[ch 4]);
2646 buffer.append(gHexChs[ch 0xf]);
2647 }
2648 else if (b != '%' b != '#' gNeedEscaping[b]) { //---
remove this block
2649 buffer.append('%');
2650 buffer.append(gAfterEscaping1[b]);
2651 buffer.append(gAfterEscaping2[b]);
2652 }
2653 else {
2654 buffer.append((char)b);
2655 }
2656 }
Thankfully java.net.URL is much more forgiving (a polite way of saying buggy!)
than java.net.URI and accepts unencoded reserved ASCII characters as part of
the URI encoded characters.
Something does not smell right here. Arguably the system ID should be a
correctly encoded URI to begin with otherwise an error should result.
Paul.
-Joe
On 6/25/2012 9:13 AM, Paul Sandoz wrote:
Hi Joe,
What happens if there is a space character or other characters in the string
that should be encoded ?
http://greenbytes.de/tech/webdav/rfc2396.html#rfc.section.2.4.3
I suspect escapeNonUSAscii is slightly misleading, it should be really
called something like escapeCharactersInUriString.
Note that '[' and ']' are not valid URI characters outside of an IPv6
encoded address.
Paul.
On Jun 23, 2012, at 1:09 AM, Joe Wang wrote:
Hi,
This is a patch to fix the IPv6 issue.
In a previous patch to fix an issue with system id containing international
characters, an extra character escaping was added so that any URL passed to
the parser goes through method escapeNonUSAscii before it's used to
construct an URL.
However, literal IPv6 addresses are enclosed in square brackets. The
escapeNonUSAscii encoded address will become unrecognizable to URL that
would throw a java.net.MalformedURLException. An address such as
http://[fe80::la03:73ff:fead:f7b0]/note.xml is encoded as
http://%5Bfe80::la03:73ff:fead:f7b0%5D/note.xml;, resulting in
java.net.MalformedURLException: For input string: :la03:73ff:fead:f7b0%5D.
This patch skips the encoding process and returns it as is if there're no
non-ascii characters.
webrev: http://cr.openjdk.java.net/~joehw/7u6/7166896/webrev/
Please review.
Thanks,
Joe
Re: Patch review request - Test bug 7123972 test/java/lang/annotation/loaderLeak/Main.java fails intermittently
Hi David,
Thank you! I run the test several times on 3 platforms (windows, solaris
and linux), the average execution time is 30secs to 60secs. if the test
hang 2 minutes, there should be something wrong.
Hi Marks,
I don't have the author role, Can you please help to review and post the
webrev 7123972.zip in attachment if it is OK, Thanks a lot!
Regards,
Eric
On 2012/6/27 14:19, David Holmes wrote:
Eric,
Ignore my comment about adding the timeouts. As Alan reminded me if
the test would hang then jtreg will time it out after two minutes anyway.
So this is good to go as far as I am concerned.
Thanks,
David
On 27/06/2012 7:51 AM, David Holmes wrote:
Thanks Eric.
So to summarize:
- we create a custom classloader, load a class through it and store a
reference to that Class in a WeakReference
- we then drop the reference to the loader
At this point the only reference to the loader is from the Class loaded,
which in turn is only weakly reachable.
I must confess that I'm unclear why this test should be failing in its
original form. The first gc() should remove the strong reference to the
loader. That leaves a weak cycle: WeakRef - Class - Loader - Class.
The second gc() should detect the cycle and clear the WeakRef. I guess
the problem is that depending on which gc is in use the actual gc()
calls may not in fact induce every possible GC action.
The fix seems reasonable in that regard - keep gc'ing and finalizing
till we see the loader is gone, and so the WeakReference should be
cleared. The original bug would cause a ref to the Class to remain (from
the annotation) and hence the WeakRef would not be cleared. However, in
that case the loader would also be strongly referenced and so never
become finalizable. So if this test was now run against a JDK with the
original bug, the test would hang. So I think we need to add a timeout
in there as well.
David
On 25/06/2012 6:06 PM, Eric Wang wrote:
On 2012/6/21 20:16, David Holmes wrote:
Hi Eric,
On 21/06/2012 8:57 PM, Eric Wang wrote:
Hi David,
Thanks for your review, I have updated the code by following your
suggestion. please see the attachment.
I'm not sure whether there's a better way to guarantee object
finalized
by GC definitely within the given time. The proposed fix may work in
most cases but may still throw InterruptException if execution is
timeout (2 minutes of JTreg by default).
There is no way to guarantee finalization in a specific timeframe, but
if a simple test hasn't executed finalizers in 2 minutes then that in
itself indicates a problem.
Can you post a full webrev for this patch? I don't like seeing it out
of context and am wondering exactly what we are trying to GC here.
David
Regards,
Eric
On 2012/6/21 14:32, David Holmes wrote:
Hi Eric,
On 21/06/2012 4:05 PM, Eric Wang wrote:
I come from Java SQE team who are interested in regression test bug
fix.
Here is the first simple fix for bug 7123972
http://monaco.us.oracle.com/detail.jsf?cr=7123972, Can you please
help
to review and comment? Attachment is the patch Thanks!
This bug is caused by wrong assumption that the GC is started
immediately to recycle un-referenced objects after System.gc()
called
one or two times.
The proposed solution is to make sure the un-referenced object is
recycled by GC before checking if the reference is null.
Your patch makes its own assumptions - specifically that
finalization
must eventually run. At a minimum you should add
System.runFinalization() calls after the System.gc() inside the
loop.
Even that is no guarantee in a general sense, though it should work
for hotspot.
David
Regards,
Eric
Hi Alan David,
Thank you for your comments, sorry for reply this mail late as i was
just back from the dragon boat holiday.
I have updated the code again based on your suggestions: rename the
flag
variable, increase the sleep time and remove it from problem list.
The attachment is the full webrev for this patch, Can you please review
again? Thanks a lot!
Regards,
Eric
--- old/test/ProblemList.txt2012-06-25 15:41:20.466150117 +0800
+++ new/test/ProblemList.txt2012-06-25 15:41:18.998075349 +0800
@@ -122,9 +122,6 @@
# jdk_lang
-# 7123972
-java/lang/annotation/loaderLeak/Main.java generic-all
-
# 6944188
java/lang/management/ThreadMXBean/ThreadStateTest.java generic-all
--- old/test/java/lang/annotation/loaderLeak/Main.java 2012-06-25
15:41:26.005179716 +0800
+++ new/test/java/lang/annotation/loaderLeak/Main.java 2012-06-25
15:41:24.531076496 +0800
@@ -36,6 +36,8 @@
import java.io.*;
public class Main {
+static volatile boolean finalized = false;
+
public static void main(String[] args) throws Exception {
for (int i=0; i100; i++)
doTest(args.length != 0);
@@ -57,8 +59,11 @@
System.gc();
System.gc();
loader = null;
-System.gc();
-System.gc();
+while(!finalized) {
+System.gc();
Re: [PATCH] Review Request - Test bug: 6948101 java/rmi/transport/pinLastArguments/PinLastArguments.java failing intermittently
Hi David Stuart,
Thank you for the help! please review the in webrev 6948101.zip in
attachment.
Regards,
Eric
On 2012/6/27 9:14, Stuart Marks wrote:
Hi Eric,
Alan Bateman asked me to help you out with this since he's going to be
unavailable for a couple weeks.
I didn't see you on the OpenJDK census [1] so you might not have an
Author role and thus the ability to post webrevs. If indeed you don't,
I can post a webrev for you. I can also post a webrev for your other
review (7123972) if it's still necessary.
Finally, I can push the fixes for you when the reviews are complete.
s'marks
[1] http://openjdk.java.net/census
On 6/26/12 2:56 PM, David Holmes wrote:
Hi Eric,
On 26/06/2012 7:26 PM, Eric Wang wrote:
Please help to review the fix attached for test bug 6948101
http://monaco.us.oracle.com/detail.jsf?cr=6948101 which is same root
cause as bug 7123972
http://monaco.us.oracle.com/detail.jsf?cr=7123972.
The test makes wrong assumption that GC is started immediately to
recycle unused objects after System.gc() called.
The proposed fix is to make sure objects have been recycled by GC
before
checking if the weak reference is null.
Again I really need to see a webrev to see the fix in context. Do you
have
Author role and an OpenJDK user name so you can post webrevs on
cr.openjdk.java.net?
I suspect this may have the same issues as the other fix and require
a timeout
for when the original problem is still present.
Thanks,
David
Regards,
Eric
--- old/test/ProblemList.txt2012-06-26 17:02:12.934138771 +0800
+++ new/test/ProblemList.txt2012-06-26 17:02:11.494051649 +0800
@@ -271,9 +271,6 @@
# 7140992
java/rmi/server/Unreferenced/finiteGCLatency/FiniteGCLatency.java generic-all
-# 6948101
-java/rmi/transport/pinLastArguments/PinLastArguments.java generic-all
-
# 7146541
java/rmi/transport/rapidExportUnexport/RapidExportUnexport.java
linux-all
--- old/test/java/rmi/transport/pinLastArguments/PinLastArguments.java
2012-06-26 17:02:17.432074905 +0800
+++ new/test/java/rmi/transport/pinLastArguments/PinLastArguments.java
2012-06-26 17:02:15.984073307 +0800
@@ -43,7 +43,8 @@
import java.rmi.server.UnicastRemoteObject;
public class PinLastArguments {
-
+private static volatile boolean finalized = false;
+
public interface Ping extends Remote {
void ping(Object first, Object second) throws RemoteException;
}
@@ -53,6 +54,9 @@
public void ping(Object first, Object second) {
System.err.println(ping invoked: + first + , + second);
}
+protected void finalize() {
+finalized = true;
+}
}
public static void main(String[] args) throws Exception {
@@ -78,7 +82,11 @@
}
impl = null;
-System.gc();
+while(!finalized) {
+System.gc();
+System.runFinalization();
+Thread.sleep(20);
+}
if (ref.get() != null) {
throw new Error(TEST FAILED: impl not garbage collected);
Re: Fwd: Codereview request for 7130915: File.equals does not give expected results when path contains Non-English characters on Mac OS X
Thanks Alan! The webrev has been updated to throw OOME as your other nio native dispatcher does. http://cr.openjdk.java.net/~sherman/7130915/webrev. I can wait for your back from the vacation:-) -Sherman On 6/26/12 11:41 PM, Alan Bateman wrote: On 27/06/2012 04:33, Xueming Shen wrote: Alan, Webrev has been updated accordingly at http://cr.openjdk.java.net/~sherman/7130915/webrev with changes (1) added a CFStringCreateMutable(...) != null check in both io and nio native, though it is unlikely to fail here because we are passing a NULL and 0 length, like new StringBuilder() invocation, if it fails the system probably goes very wrong. Both FStringAppendCharacters and CFStringNormalize are void return type. (2) The first line of path.toCharArray in normalizeJavaPath is a typo, it is supposed to be deleted. The implementation only goes toCharArray when it needs to go native. Currently it uses 0x80 as the fast path criteria, it is possible to expose some sun.text.normalizer's internal methods to have a quick nfc check, but I'm not sure how much the performance gain would be, but might worth some investigation later. (3) Comments have been added for those override-able methods in UnixFileSystem. (4) blank lines have been removed from dispatcher.c (5) I don't think we need to do the HFS check, given we are only doing nfc/nfd stuff now, as long as it is a MacOSX, I believe its nfc/nfd layer will be there. Copyright has been re-copy/ pasted and we now only use only bugid. -Sherman I'm heading away on vacation now and only quickly scanned the updated webrev. All looks okay to me. On the calls to the CF functions then one thing is that if they fail (and this is unlikely I know) then you won't have an exception pending so may need to add code to call one of the JNU* functions to throw OOME, otherwise it might cause a NPE in the caller rather than throwing an exception as you would expect. -Alan
hg: jdk8/tl/jaxws: Added tag jdk8-b44 for changeset f6a417540ef1
Changeset: e80ac58b5ba9 Author:katleman Date: 2012-06-21 17:07 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/e80ac58b5ba9 Added tag jdk8-b44 for changeset f6a417540ef1 ! .hgtags
hg: jdk8/tl/corba: 9 new changesets
Changeset: ad3ba4b392cc Author:katleman Date: 2012-06-21 17:07 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/ad3ba4b392cc Added tag jdk8-b44 for changeset 439d9bf8e4ff ! .hgtags Changeset: 5222b7d658d4 Author:coffeys Date: 2012-03-26 14:01 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/5222b7d658d4 7143851: Improve IIOP stub and tie generation in RMIC 7149048: Changes to corba rmic stubGenerator class are not used during jdk build process Reviewed-by: mschoene, robm ! src/share/classes/sun/rmi/rmic/iiop/StubGenerator.java Changeset: e324dfb90c9e Author:mbankal Date: 2012-03-28 02:50 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/e324dfb90c9e 7079902: Refine CORBA data models Reviewed-by: coffeys ! src/share/classes/com/sun/corba/se/impl/interceptors/ClientRequestInfoImpl.java ! src/share/classes/com/sun/corba/se/impl/interceptors/ServerRequestInfoImpl.java ! src/share/classes/com/sun/corba/se/impl/javax/rmi/CORBA/Util.java ! src/share/classes/com/sun/corba/se/impl/oa/poa/POAPolicyMediatorBase_R.java ! src/share/classes/com/sun/corba/se/impl/oa/toa/TOAFactory.java ! src/share/classes/com/sun/corba/se/impl/orb/ParserTable.java ! src/share/classes/com/sun/corba/se/impl/orbutil/RepositoryId_1_3.java ! src/share/classes/com/sun/corba/se/impl/orbutil/RepositoryId_1_3_1.java ! src/share/classes/com/sun/corba/se/impl/protocol/LocalClientRequestDispatcherBase.java ! src/share/classes/com/sun/corba/se/impl/util/RepositoryId.java ! src/share/classes/com/sun/corba/se/spi/logging/CORBALogDomains.java ! src/share/classes/sun/rmi/rmic/iiop/IDLNames.java Changeset: 2846cb957582 Author:mbankal Date: 2012-03-28 02:53 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/2846cb957582 Merge Changeset: a00c5c0b1f30 Author:asaha Date: 2012-04-10 10:41 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/a00c5c0b1f30 Merge - make/tools/src/build/tools/stripproperties/StripProperties.java Changeset: 3697feea6f54 Author:asaha Date: 2012-05-08 07:27 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/3697feea6f54 Merge Changeset: 787fb5a0602f Author:asaha Date: 2012-05-21 14:50 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/787fb5a0602f Merge Changeset: 25bb958d07de Author:asaha Date: 2012-06-07 12:29 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/25bb958d07de Merge Changeset: 747dad9e9d37 Author:lana Date: 2012-06-26 10:13 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/747dad9e9d37 Merge
hg: jdk8/tl/langtools: 2 new changesets
Changeset: a39c99192184 Author:katleman Date: 2012-06-21 17:08 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/a39c99192184 Added tag jdk8-b44 for changeset 59cbead12ff4 ! .hgtags Changeset: e111e4587cca Author:lana Date: 2012-06-25 21:39 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/e111e4587cca Merge - src/share/classes/com/sun/tools/javac/parser/EndPosTable.java
hg: jdk8/tl: 4 new changesets
Changeset: 8fb4cd2f05a1 Author:mbykov Date: 2012-06-19 14:24 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/8fb4cd2f05a1 7178241: Basic script for JDK source code legal headers conformance verification Summary: A new script lic_check.sh to check license headers in JDK source code Reviewed-by: ohair, darcy Contributed-by: misha.by...@oracle.com + make/scripts/lic_check.sh Changeset: e4f81a817447 Author:katleman Date: 2012-06-20 15:22 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/e4f81a817447 Merge Changeset: 1e989139ce0d Author:katleman Date: 2012-06-21 17:07 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/1e989139ce0d Added tag jdk8-b44 for changeset e4f81a817447 ! .hgtags Changeset: 633f2378c904 Author:lana Date: 2012-06-25 21:37 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/633f2378c904 Merge
hg: jdk8/tl/hotspot: 45 new changesets
Changeset: 6e2633440960 Author:amurillo Date: 2012-06-01 15:30 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6e2633440960 7173438: new hotspot build - hs24-b14 Reviewed-by: jcoomes ! make/hotspot_version Changeset: fab99b17c1de Author:mikael Date: 2012-06-01 20:17 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/fab99b17c1de 7155453: [macosx] re-enable jbb tests in JPRT Summary: Run SPECjbb in headless mode and enable SPECjbb runs on OSX Reviewed-by: dcubed, dholmes ! make/jprt.properties Changeset: 4434fdad6b37 Author:dholmes Date: 2012-06-02 07:32 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4434fdad6b37 Merge ! make/jprt.properties Changeset: e17b61ba7bb3 Author:kamg Date: 2012-06-04 10:22 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e17b61ba7bb3 7166498: JVM crash in ClassVerifier Summary: Fixed raw pointer being used after potential safepoint/GC Reviewed-by: acorn, fparain, dholmes ! src/share/vm/classfile/verifier.cpp Changeset: a297b0e14605 Author:mgerdin Date: 2012-06-04 09:21 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a297b0e14605 7172226: HotSpot fails to build with GCC 4.7 because of stricter c++ argument dependent lookup Summary: Add using keyword to import base class functions from FreeListT to fix template name lookup in gcc 4.7 Reviewed-by: brutisso, iveresov ! src/share/vm/memory/binaryTreeDictionary.cpp ! src/share/vm/memory/binaryTreeDictionary.hpp Changeset: 37552638d24a Author:brutisso Date: 2012-06-05 22:30 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/37552638d24a 7172388: G1: _total_full_collections should not be incremented for concurrent cycles Reviewed-by: azeemj, jmasa ! src/share/vm/gc_implementation/g1/concurrentMarkThread.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/vm_operations_g1.cpp ! src/share/vm/gc_implementation/g1/vm_operations_g1.hpp Changeset: b9442ac22f59 Author:brutisso Date: 2012-06-04 13:29 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b9442ac22f59 7173460: G1: java/lang/management/MemoryMXBean/CollectionUsageThreshold.java failes with G1 Summary: The scope of TraceMemoryManagerStats in G1CollectedHeap need to cover the call to G1MonitoringSupport::update_sizes() Reviewed-by: johnc, jmasa ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp Changeset: 063451aefde8 Author:jcoomes Date: 2012-06-08 09:49 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/063451aefde8 Merge Changeset: 2fe087c3e814 Author:jiangli Date: 2012-06-06 14:33 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2fe087c3e814 7172967: Eliminate constMethod's _method backpointer to methodOop. Summary: Eliminate constMethod's _method backpointer to methodOop, and move the _constant field from methodOop to constMethod. Reviewed-by: roland, bdelsart, kamg ! agent/src/share/classes/sun/jvm/hotspot/oops/ConstMethod.java ! agent/src/share/classes/sun/jvm/hotspot/oops/Method.java ! src/cpu/sparc/vm/cppInterpreter_sparc.cpp ! src/cpu/sparc/vm/interp_masm_sparc.cpp ! src/cpu/sparc/vm/interp_masm_sparc.hpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/x86/vm/cppInterpreter_x86.cpp ! src/cpu/x86/vm/interp_masm_x86_32.hpp ! src/cpu/x86/vm/interp_masm_x86_64.hpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/os/solaris/dtrace/generateJvmOffsets.cpp ! src/os/solaris/dtrace/jhelper.d ! src/os/solaris/dtrace/libjvm_db.c ! src/share/vm/oops/constMethodKlass.cpp ! src/share/vm/oops/constMethodOop.cpp ! src/share/vm/oops/constMethodOop.hpp ! src/share/vm/oops/methodKlass.cpp ! src/share/vm/oops/methodOop.cpp ! src/share/vm/oops/methodOop.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: ab6ab9f84b2d Author:bdelsart Date: 2012-06-11 04:47 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ab6ab9f84b2d Merge Changeset: dcfcdd01af4b Author:fparain Date: 2012-06-05 06:48 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/dcfcdd01af4b 7171703: JNI DefineClass crashes client VM when first parameter is NULL Reviewed-by: acorn, kamg, sspitsyn, dholmes ! src/share/vm/prims/jni.cpp Changeset: de909f001528 Author:mikael Date: 2012-06-06 05:21 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/de909f001528 7170275: os::print_os_info needs to know about Windows 8 Summary: Recognize Windows 8 and Windows Server 2012 Reviewed-by: sla, kvn, azeemj ! src/os/windows/vm/os_windows.cpp Changeset: 40b4aaf010e4 Author:dholmes Date: 2012-06-08 02:06 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/40b4aaf010e4 7172708: 32/64 bit type issues on Windows after Mac OS X port Reviewed-by: dholmes,
hg: jdk8/tl/jdk: 36 new changesets
Changeset: 9d88f2ce6338 Author:katleman Date: 2012-06-21 17:08 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9d88f2ce6338 Added tag jdk8-b44 for changeset db471a7af031 ! .hgtags Changeset: eb50eeb2eb7d Author:prr Date: 2012-06-13 12:46 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/eb50eeb2eb7d 7027300: Unsynchronized HashMap access causes endless loop Reviewed-by: bae, jgodinez ! src/share/classes/sun/font/SunLayoutEngine.java Changeset: 5959fec806d8 Author:bae Date: 2012-06-14 11:14 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5959fec806d8 7153693: Three 2D_ImageIO tests failed due ImageFormatException on OEL 6.* Unbreakable Kernel x64 Reviewed-by: jgodinez, prr ! src/share/native/sun/awt/image/jpeg/jpegdecoder.c Changeset: 2aa89f018a2f Author:prr Date: 2012-06-14 16:34 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2aa89f018a2f 7158366: [macosx] Print-to-file dialog doesn't have an entry field for a name Reviewed-by: bae, jgodinez ! src/share/classes/sun/print/ServiceDialog.java Changeset: e42563f8ec12 Author:lana Date: 2012-06-17 22:07 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e42563f8ec12 Merge - makefiles/altclasses/Makefile - makefiles/apple/Makefile - makefiles/apple/applescript/Makefile - makefiles/com/Makefile - makefiles/com/apple/Makefile - makefiles/com/apple/osx/Makefile - makefiles/com/apple/osxui/Makefile - makefiles/com/oracle/Makefile - makefiles/com/oracle/jfr/Makefile - makefiles/com/oracle/security/ucrypto/FILES_c.gmk - makefiles/com/oracle/security/ucrypto/Makefile - makefiles/com/oracle/security/ucrypto/mapfile-vers - makefiles/com/sun/Makefile - makefiles/common/shared/Defs-utils.gmk - makefiles/java/fdlibm/FILES_c.gmk - makefiles/java/fdlibm/Makefile - makefiles/java/instrument/Makefile - makefiles/java/instrument/mapfile-vers - makefiles/java/java/Exportedfiles.gmk - makefiles/java/java/FILES_c.gmk - makefiles/java/java/FILES_java.gmk - makefiles/java/java/Makefile - makefiles/java/java/localelist.sh - makefiles/java/java/mapfile-vers - makefiles/java/java/reflect/Makefile - makefiles/java/java/reorder-i586 - makefiles/java/java/reorder-sparc - makefiles/java/java/reorder-sparcv9 - makefiles/java/java_crw_demo/Makefile - makefiles/java/java_crw_demo/mapfile-vers - makefiles/java/java_hprof_demo/Makefile - makefiles/java/java_hprof_demo/mapfile-vers - makefiles/java/jexec/Makefile - makefiles/java/jli/Makefile - makefiles/java/jli/mapfile-vers - makefiles/java/jobjc/Makefile - makefiles/java/jvm/Makefile - makefiles/java/main/Makefile - makefiles/java/main/java/Makefile - makefiles/java/main/java/mapfile-amd64 - makefiles/java/main/java/mapfile-i586 - makefiles/java/main/java/mapfile-sparc - makefiles/java/main/java/mapfile-sparcv9 - makefiles/java/main/javaw/Makefile - makefiles/java/management/Exportedfiles.gmk - makefiles/java/management/FILES_c.gmk - makefiles/java/management/Makefile - makefiles/java/management/mapfile-vers - makefiles/java/net/FILES_c.gmk - makefiles/java/net/Makefile - makefiles/java/net/mapfile-vers - makefiles/java/nio/Exportedfiles.gmk - makefiles/java/nio/FILES_c.gmk - makefiles/java/nio/FILES_java.gmk - makefiles/java/nio/Makefile - makefiles/java/nio/addNotices.sh - makefiles/java/nio/genBuffer.sh - makefiles/java/nio/genCharsetProvider.sh - makefiles/java/nio/genCoder.sh - makefiles/java/nio/genExceptions.sh - makefiles/java/nio/mapfile-bsd - makefiles/java/nio/mapfile-linux - makefiles/java/nio/mapfile-solaris - makefiles/java/nio/reorder-i586 - makefiles/java/nio/reorder-sparc - makefiles/java/nio/reorder-sparcv9 - makefiles/java/npt/Makefile - makefiles/java/npt/mapfile-vers - makefiles/java/redist/fonts/Makefile - makefiles/java/security/Makefile - makefiles/java/sun_nio/FILES_java.gmk - makefiles/java/sun_nio/Makefile - makefiles/java/util/FILES_java.gmk - makefiles/java/util/FILES_properties.gmk - makefiles/java/util/Makefile - makefiles/java/verify/Makefile - makefiles/java/verify/mapfile-vers - makefiles/java/verify/reorder-i586 - makefiles/java/verify/reorder-sparc - makefiles/java/verify/reorder-sparcv9 - makefiles/javax/Makefile - makefiles/javax/imageio/Makefile - makefiles/javax/management/Makefile - makefiles/javax/sound/FILES_c.gmk - makefiles/javax/sound/Makefile - makefiles/javax/sound/SoundDefs.gmk - makefiles/javax/sound/jsoundalsa/Makefile - makefiles/javax/sound/jsoundalsa/mapfile-vers - makefiles/javax/sound/jsoundds/Makefile - makefiles/javax/sound/mapfile-vers - makefiles/javax/sql/Makefile - makefiles/javax/swing/FILES.gmk - makefiles/javax/swing/Makefile - makefiles/javax/swing/beaninfo/FILES.gmk - makefiles/javax/swing/beaninfo/Makefile - makefiles/javax/swing/beaninfo/SwingBeans.gmk - makefiles/javax/swing/beaninfo/manifest - makefiles/javax/swing/html32dtd/Makefile - makefiles/javax/swing/plaf/FILES.gmk - makefiles/javax/swing/plaf/Makefile - makefiles/sun/Makefile -
