From mike.duigou at oracle.com Mon Jan 3 20:16:02 2011 From: mike.duigou at oracle.com (Mike Duigou) Date: Mon, 3 Jan 2011 12:16:02 -0800 Subject: Review for CR 6728865 : Improved heuristics for Collections.disjoint() [updated] In-Reply-To: <4D1549C8.9000102@gmx.de> References: <4D0EA65D.5090101@oracle.com> <46C51E8C-6F3A-4F54-8070-100BFED61D1A@oracle.com> <4D100FF1.6060702@oracle.com> <4D1084E3.9050504@oracle.com> <76AFCC5F-E660-4934-9037-E9F0504A04A4@oracle.com> <4D1118EF.1080300@oracle.com> <4D1200DE.3040107@oracle.com> <4D131E2B.1080702@oracle.com> <4D13BDF3.7030000@gmx.de> <4D13CC1F.6030704@gmx.de> <4D1549C8.9000102@gmx.de> Message-ID: <2323B4FF-5BC3-43C4-9360-BB56342866F4@oracle.com> On Dec 24 2010, at 17:32 , Ulf Zibis wrote: > Trying to correct white space ... > > Am 23.12.2010 23:59, schrieb Paul Benedict: >> Ulf, a previous email by Remi said only to invoke size() if the collection is a Set. > Thanks I missed that. > My guess was, that size() should be always faster than instantiating an iterator for the final for-loop, and then seeing, that there is no element. An earlier webrev had an isEmpty() check in the "c1 is a Set" half of the branch. This optimization would pay off in some cases but cost a small amount in others. Since I don't have any strong sense of whether including it would be of actual benefit or harm I opted to take it out in later revisions. Mike From mike.duigou at oracle.com Mon Jan 3 22:15:34 2011 From: mike.duigou at oracle.com (Mike Duigou) Date: Mon, 3 Jan 2011 14:15:34 -0800 Subject: Review for CR 6728865 : Improved heuristics for Collections.disjoint() [updated] In-Reply-To: <4D13BDF3.7030000@gmx.de> References: <4D0EA65D.5090101@oracle.com> <46C51E8C-6F3A-4F54-8070-100BFED61D1A@oracle.com> <4D100FF1.6060702@oracle.com> <4D1084E3.9050504@oracle.com> <76AFCC5F-E660-4934-9037-E9F0504A04A4@oracle.com> <4D1118EF.1080300@oracle.com> <4D1200DE.3040107@oracle.com> <4D131E2B.1080702@oracle.com> <4D13BDF3.7030000@gmx.de> Message-ID: On Dec 23 2010, at 13:24 , Ulf Zibis wrote: > Am 23.12.2010 20:46, schrieb Mike Duigou: >> I have updated the webrev with the javadoc changes (identical to below) and Ulf's suggested code changes: >> >> http://cr.openjdk.java.net/~mduigou/6728865.3/webrev/ > > Thanks, I could convince you mostly. > But, IMO, the inner comments are too expatiated ("less than O(N/2)" is used 3 times). I've tried to favour clarity and simplicity of language over brevity for comments and mostly intended the comments for casual readers trying to understanding the operation of the method rather than future maintainers. This applies to the source code as well-- I've somewhat ignored "Optimizations" which make the source code smaller but no faster in execution. > Aren't the explanation comments from my last example clear enough and more fluently readable? > You use "ceiling(n/2)". Didn't you mean "ceiling O(N/2)" for consistence? The example refers to the total number of actual comparisons not it's O complexity so "ceiling(N/2)" is correct. > "//than mere Collection's,iterate on c2." > 2 spaces are missing > One space added. > "// One (or both) collections is/are empty. Nothing will match." > Shorter: > "// At least one collection is empty. Nothing will match." Done. > Javadoc: > - the term '@throws NullPointerException' is duplicated, don't know if that would work ? This is intentionally copying the style of Collection methods where two separate @throws NullPointerException clauses are also used. > - there is a habit, maybe a rule, to insert 2 spaces after '.' Only for those still using typewriters. :-) For javadoc comments the double spaces are collapsed to a single space in the HTML view and just take up precious characters in the 80 column line wrap. To my knowledge the 2 spaces after punctuation style has been abandoned. Mike From Ulf.Zibis at gmx.de Tue Jan 4 01:02:08 2011 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Tue, 04 Jan 2011 02:02:08 +0100 Subject: Review for CR 6728865 : Improved heuristics for Collections.disjoint() [updated] In-Reply-To: <2323B4FF-5BC3-43C4-9360-BB56342866F4@oracle.com> References: <4D0EA65D.5090101@oracle.com> <46C51E8C-6F3A-4F54-8070-100BFED61D1A@oracle.com> <4D100FF1.6060702@oracle.com> <4D1084E3.9050504@oracle.com> <76AFCC5F-E660-4934-9037-E9F0504A04A4@oracle.com> <4D1118EF.1080300@oracle.com> <4D1200DE.3040107@oracle.com> <4D131E2B.1080702@oracle.com> <4D13BDF3.7030000@gmx.de> <4D13CC1F.6030704@gmx.de> <4D1549C8.9000102@gmx.de> <2323B4FF-5BC3-43C4-9360-BB56342866F4@oracle.com> Message-ID: <4D227190.6030004@gmx.de> Am 03.01.2011 21:16, schrieb Mike Duigou: > On Dec 24 2010, at 17:32 , Ulf Zibis wrote: > >> Am 23.12.2010 23:59, schrieb Paul Benedict: >>> Ulf, a previous email by Remi said only to invoke size() if the collection is a Set. >> Thanks I missed that. >> My guess was, that size() should be always faster than instantiating an iterator for the final for-loop, and then seeing, that there is no element. > An earlier webrev had an isEmpty() check in the "c1 is a Set" half of the branch. This optimization would pay off in some cases but cost a small amount in others. Since I don't have any strong sense of whether including it would be of actual benefit or harm I opted to take it out in later revisions. > For the same reason you could set the empty-check at 1st place. This would result in the most simple (and fast) code (see my before post). - in all implementations, I have seen, "isEmpty()" is equivalent to "size() == 0" - "cost a small amount in others" applies rarely; the only implementation, I have seen, where "Set.size() can be expensive", is ConcurrentSkipListSet (are there others?). - swapping c1 , c2 only happens in the very rare applying cases. Anyway, isn't size() anyhow cheaper than superfluously looping contains() ? E.g. Given Set c1 with 100 elements and Set c2 with 0 elements. Then we iterate and compare over 100 elements needlessly. -Ulf From Ulf.Zibis at gmx.de Tue Jan 4 01:02:27 2011 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Tue, 04 Jan 2011 02:02:27 +0100 Subject: Review for CR 6728865 : Improved heuristics for Collections.disjoint() [updated] In-Reply-To: References: <4D0EA65D.5090101@oracle.com> <46C51E8C-6F3A-4F54-8070-100BFED61D1A@oracle.com> <4D100FF1.6060702@oracle.com> <4D1084E3.9050504@oracle.com> <76AFCC5F-E660-4934-9037-E9F0504A04A4@oracle.com> <4D1118EF.1080300@oracle.com> <4D1200DE.3040107@oracle.com> <4D131E2B.1080702@oracle.com> <4D13BDF3.7030000@gmx.de> Message-ID: <4D2271A3.3040004@gmx.de> Am 03.01.2011 23:15, schrieb Mike Duigou: > I've tried to favour clarity and simplicity of language over brevity for comments and mostly intended the comments for casual readers trying to understanding the operation of the method rather than future maintainers. OK, we are different. For me, redundancy usually reduces clarity. I would need more time to read and understand the comments, especially as a non-english native. > This applies to the source code as well-- I've somewhat ignored "Optimizations" which make the source code smaller but no faster in execution. Well, I think a single swap (single CPU instruction) is little faster, than copying to local variables, and in Hotspot optimization case reduces register pressure. Anyway, your code reorders the arguments in more cases than necessary. That's why I have constructed the decision maps to clearly see the common paths. > > The example refers to the total number of actual comparisons not it's O complexity so "ceiling(N/2)" is correct. I was in error, as I finally noted (overseen ?). But I still think, (N+1)/2 is more correct than ceiling(N/2). N=2: match can be in 1st or 2nd position, so 1.5 comparisions in avarage! N=3: match can be in 1st, 2nd or 3rd position, so 2 comparisions in avarage! N=4: match can be in 1st to 4th position, so 2.5 comparisions in avarage! >> "//than mere Collection's,iterate on c2." >> 2 spaces are missing > One space added. The 2nd one is after the comma. ;-) > >> Javadoc: >> - the term '@throws NullPointerException' is duplicated, don't know if that would work ? > This is intentionally copying the style of Collection methods where two separate @throws NullPointerException clauses are also used. Hm, where exactly did yo find this style? > Only for those still using typewriters. :-) For javadoc comments the double spaces are collapsed to a single space in the HTML view and just take up precious characters in the 80 column line wrap. To my knowledge the 2 spaces after punctuation style has been abandoned. IMO it still enhances the readability in the source code. -Ulf From forax at univ-mlv.fr Tue Jan 4 01:24:20 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Tue, 04 Jan 2011 02:24:20 +0100 Subject: Review for CR 6728865 : Improved heuristics for Collections.disjoint() [updated] In-Reply-To: <4D227190.6030004@gmx.de> References: <4D0EA65D.5090101@oracle.com> <46C51E8C-6F3A-4F54-8070-100BFED61D1A@oracle.com> <4D100FF1.6060702@oracle.com> <4D1084E3.9050504@oracle.com> <76AFCC5F-E660-4934-9037-E9F0504A04A4@oracle.com> <4D1118EF.1080300@oracle.com> <4D1200DE.3040107@oracle.com> <4D131E2B.1080702@oracle.com> <4D13BDF3.7030000@gmx.de> <4D13CC1F.6030704@gmx.de> <4D1549C8.9000102@gmx.de> <2323B4FF-5BC3-43C4-9360-BB56342866F4@oracle.com> <4D227190.6030004@gmx.de> Message-ID: <4D2276C4.3080601@univ-mlv.fr> On 01/04/2011 02:02 AM, Ulf Zibis wrote: > Am 03.01.2011 21:16, schrieb Mike Duigou: >> On Dec 24 2010, at 17:32 , Ulf Zibis wrote: >> >>> Am 23.12.2010 23:59, schrieb Paul Benedict: >>>> Ulf, a previous email by Remi said only to invoke size() if the >>>> collection is a Set. >>> Thanks I missed that. >>> My guess was, that size() should be always faster than instantiating >>> an iterator for the final for-loop, and then seeing, that there is >>> no element. >> An earlier webrev had an isEmpty() check in the "c1 is a Set" half of >> the branch. This optimization would pay off in some cases but cost a >> small amount in others. Since I don't have any strong sense of >> whether including it would be of actual benefit or harm I opted to >> take it out in later revisions. >> > For the same reason you could set the empty-check at 1st place. This > would result in the most simple (and fast) code (see my before post). > - in all implementations, I have seen, "isEmpty()" is equivalent to > "size() == 0" It's semantically equivalent by definition but the complexities aren't the same. see http://hg.openjdk.java.net/jdk7/jdk7/jdk/file/1c72adc9d5f3/src/share/classes/java/util/concurrent/ConcurrentSkipListMap.java near line 1740 or http://hg.openjdk.java.net/jdk7/jdk7/jdk/file/1c72adc9d5f3/src/share/classes/java/util/concurrent/ConcurrentLinkedQueue.java near line 400 or http://hg.openjdk.java.net/jdk7/jdk7/jdk/file/1c72adc9d5f3/src/share/classes/java/util/concurrent/ConcurrentHashMap.java near line 700. > - "cost a small amount in others" applies rarely; the only > implementation, I have seen, where "Set.size() can be expensive", is > ConcurrentSkipListSet (are there others?). By example, Collections.newSetFromMap(new ConcurrentHashMap<>). Also don't forget all Sets that map JDBC results. > - swapping c1 , c2 only happens in the very rare applying cases. > > Anyway, isn't size() anyhow cheaper than superfluously looping > contains() ? E.g. Given Set c1 with 100 elements and Set c2 with 0 > elements. Then we iterate and compare over 100 elements needlessly. > > -Ulf > > R?mi From Ulf.Zibis at gmx.de Tue Jan 4 05:06:53 2011 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Tue, 04 Jan 2011 06:06:53 +0100 Subject: Review for CR 6728865 : Improved heuristics for Collections.disjoint() [updated] In-Reply-To: <4D2276C4.3080601@univ-mlv.fr> References: <4D0EA65D.5090101@oracle.com> <46C51E8C-6F3A-4F54-8070-100BFED61D1A@oracle.com> <4D100FF1.6060702@oracle.com> <4D1084E3.9050504@oracle.com> <76AFCC5F-E660-4934-9037-E9F0504A04A4@oracle.com> <4D1118EF.1080300@oracle.com> <4D1200DE.3040107@oracle.com> <4D131E2B.1080702@oracle.com> <4D13BDF3.7030000@gmx.de> <4D13CC1F.6030704@gmx.de> <4D1549C8.9000102@gmx.de> <2323B4FF-5BC3-43C4-9360-BB56342866F4@oracle.com> <4D227190.6030004@gmx.de> <4D2276C4.3080601@univ-mlv.fr> Message-ID: <4D22AAED.5010301@gmx.de> Am 04.01.2011 02:24, schrieb R?mi Forax: > On 01/04/2011 02:02 AM, Ulf Zibis wrote: >> For the same reason you could set the empty-check at 1st place. This would result in the most >> simple (and fast) code (see my before post). >> - in all implementations, I have seen, "isEmpty()" is equivalent to "size() == 0" > > It's semantically equivalent by definition but the complexities aren't the same. > see > http://hg.openjdk.java.net/jdk7/jdk7/jdk/file/1c72adc9d5f3/src/share/classes/java/util/concurrent/ConcurrentSkipListMap.java > near line 1740 Yes, of coarse, but ... For Collections.disjoint(c1, c2), having n1 = c1.size(), n2 = c2.size() Cost at minimun: - c1.isEmpty() || c2.isEmpty() Cost at worst: - n1 iterations over c1 for computing c1.size() - if n1 != 0: n2 iterations over c2 for computing c2.size() Benefit: - if n1 == 0 or n2 == 0: instatiation of c1.iterator() or n1 * (iteration + c2.contains()) - if n1 > n2: (n1 - n2)/2 * (iteration + comparison) - if n1 <= n2: nothing Note: comparison is likely much more expensive than iteration As the optimization against the collection's sizes only makes sense if at least 1 collection is very small, it would be advantageous to have a size(int max) method, which internally should iterate at most max times instead of size times. In the meantime we could do a workaround by iterating let's say at most 5 steps on each collection to check it's size. Similar: Resultset.sizeIsLessThan(int n). BTW: containsKey() and size() could be simplified by introducing doFind(V value) similar to doGet(K key), similar for ConcurrentHashMap > or > http://hg.openjdk.java.net/jdk7/jdk7/jdk/file/1c72adc9d5f3/src/share/classes/java/util/concurrent/ConcurrentLinkedQueue.java > > near line 400 Thanks for the additional example. > or > http://hg.openjdk.java.net/jdk7/jdk7/jdk/file/1c72adc9d5f3/src/share/classes/java/util/concurrent/ConcurrentHashMap.java > > near line 700. ConcurrentHashMap is NOT a Collection! >> - "cost a small amount in others" applies rarely; the only implementation, I have seen, where >> "Set.size() can be expensive", is ConcurrentSkipListSet (are there others?). > > By example, Collections.newSetFromMap(new ConcurrentHashMap<>). As substitute for missing ConcurrentHashSet. > Also don't forget all Sets that map JDBC results. JDBC results size computation could be much faster. See: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6409445 The few collections, for which "Set.size() can be expensive" holds, are from concurrent package or wrap a JDBC result. Can't we check that? -Ulf From markus at headcrashing.eu Tue Jan 4 09:24:27 2011 From: markus at headcrashing.eu (Markus KARG) Date: Tue, 4 Jan 2011 10:24:27 +0100 Subject: Where to discuss class proposals? Message-ID: <005101cbabf1$2f750fa0$8e5f2ee0$@eu> Dear Core Library Developers, >From discussing with other coders for 25+ years, since the early days of Java, and from having contributed to several Java EE subprojects (like JAX-RS and others) in the past, and from the feedback I got to several of my blog postings on java.net, there turned out a need for some new interfaces / classes in the core libraries (namely Ordinal, Range and Sequence to handle non-integer ordinals, non-number ranges, and content-less lists defined from ranges and step sizes). I (and others, like Martin FOWLER's proposal) actually wrote such interfaces and classes, but they don't make sense unless many JRE core classes adopt them (they have to be part of the JRE, not part of the application). The question is: Where is to discuss such ideas? I tried it by positing feature requests using the Java Bug Database mechanism, but those had been unanswered since months. So even that is mentioned in OpenJDK's new members guide as the preferred way, it seemed it actually is not the way the core library team actually is living. So please tell me: Where and in what form to post ideas for the core libs to get in touch with you in shorter time than months and to actively discuss JRE needed changes lively? Or is it just to the sole grace of Oracle to decide what goes into the JRE? Or what is ACTUAL way to get things into the JRE? Obviously, the Java Bug Database is not. This is not to offend anybody, we all are in heavy stress these days, I just really want to know how to move on with this issue. Thanks Markus KARG Head Crashing Informatics http://www.headcrashing.eu http://www.java.net/blogs/mkarg -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Tue Jan 4 13:50:38 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 04 Jan 2011 13:50:38 +0000 Subject: 6993732: Remove the HPI Message-ID: <4D2325AE.7050400@oracle.com> The HPI is left over from bygone years where we had a portability layer and needed to support green and native threading models. Some of the code has not been used or maintained since the transition to HotSpot back in jdk1.3. As of jdk7-b123, the HPI library (libhpi.so/hpi.dll) isn't loaded and it's finally time to wield the axe and remove this old code. The webrev with the changes is here: http://cr.openjdk.java.net/~alanb/6993732/webrev/ Thanks, Alan. From Lance.Andersen at oracle.com Tue Jan 4 14:30:51 2011 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Tue, 4 Jan 2011 09:30:51 -0500 Subject: 6993732: Remove the HPI In-Reply-To: <4D2325AE.7050400@oracle.com> References: <4D2325AE.7050400@oracle.com> Message-ID: <968FCBB8-756D-4ABD-968F-7D65F41196EB@oracle.com> looks fine to me Alan On Jan 4, 2011, at 8:50 AM, Alan Bateman wrote: > > The HPI is left over from bygone years where we had a portability layer and needed to support green and native threading models. Some of the code has not been used or maintained since the transition to HotSpot back in jdk1.3. As of jdk7-b123, the HPI library (libhpi.so/hpi.dll) isn't loaded and it's finally time to wield the axe and remove this old code. The webrev with the changes is here: > http://cr.openjdk.java.net/~alanb/6993732/webrev/ > > Thanks, > > Alan. Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com Oracle is committed to developing practices and products that help protect the environment -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.hegarty at oracle.com Tue Jan 4 14:49:20 2011 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 04 Jan 2011 14:49:20 +0000 Subject: 6993732: Remove the HPI In-Reply-To: <4D2325AE.7050400@oracle.com> References: <4D2325AE.7050400@oracle.com> Message-ID: <4D233370.5020209@oracle.com> Looks fine. -Chris. On 04/01/2011 13:50, Alan Bateman wrote: > > The HPI is left over from bygone years where we had a portability layer > and needed to support green and native threading models. Some of the > code has not been used or maintained since the transition to HotSpot > back in jdk1.3. As of jdk7-b123, the HPI library (libhpi.so/hpi.dll) > isn't loaded and it's finally time to wield the axe and remove this old > code. The webrev with the changes is here: > http://cr.openjdk.java.net/~alanb/6993732/webrev/ > > Thanks, > > Alan. From chris.hegarty at oracle.com Tue Jan 4 15:03:30 2011 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 04 Jan 2011 15:03:30 +0000 Subject: Code Review 7000511: PrintStream, PrintWriter, Formatter leave files open when exception thrown In-Reply-To: References: <4D078824.5030307@oracle.com> Message-ID: <4D2336C2.5040108@oracle.com> On 23/12/2010 20:29, Mike Duigou wrote: > Feedback is on webrev.02 http://cr.openjdk.java.net/~chegar/7000511/webrev.02/webrev/ : > > * PrintStream > > - .flush(), close(), most println() methods synchronize on this for their entire implementation. They could just be made synchronized methods. I think there are pros and cons of doing this, maybe best left to another CR which could look into this separately? > - The javadoc for append(CharSequence,int,int) for the csq==null condition seems misleading as start and end are considered. I'm not sure what the original intent of this was, but from what I can see the javadoc appears to be clear and the implementation looks like it behaves correctly. > * Formatter > > - The zero params constructor could just call this((Apppendable) null). The advantage is that the StringBuilder is only constructed in one place. > > - The Formatter(Locale) constructor could just call this(l, (Apppendable) null). Same reason. Actually, I think it is clearer to have the StringBuilder created as is. It makes it more obvious than having to trace through another constructor. But it you feel strongly I can make the changes. -Chris. > > > On Dec 14 2010, at 07:07 , Chris Hegarty wrote: > >> Failing java.io.PrintStream, java.io.PrintWriter, java.util.Scanner, and java.util.Formatter multi-arg constructors that take a java.io.File or String filename (as well as one or more additional args) opens a FileIn/OutputStream to the given File/filename. If one of the other given args causes the constructor to fail ( null or unsupported charset for example ) the FileIn/OutputStream is never closed, and the application does not have a reference to it. You rely on the finalizer to close the stream. >> >> This is most serious on Windows because you cannot remove a file if there is an open handle to it. >> >> I also cleaned up an existing regression test that fails in samevm mode (partly) because of this. And removed another excluded test from the list since its bug was fixed some time ago. >> >> Webrev: >> http://cr.openjdk.java.net/~chegar/7000511/webrev.00/webrev/ >> >> -Chris. > From chris.hegarty at oracle.com Tue Jan 4 15:34:57 2011 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 04 Jan 2011 15:34:57 +0000 Subject: Code Review 7000511: PrintStream, PrintWriter, Formatter leave files open when exception thrown In-Reply-To: <4D09FC31.1070501@oracle.com> References: <4D078824.5030307@oracle.com> <4D07B184.7050005@oracle.com> <4D092D17.3070001@oracle.com> <4D09FC31.1070501@oracle.com> Message-ID: <4D233E21.4070804@oracle.com> On 16/12/2010 11:46, Alan Bateman wrote: > Chris Hegarty wrote: >> >> : >> Thanks for your comments Alan. I reworked the changes to include them. >> >> Updated webrev: >> http://cr.openjdk.java.net/~chegar/7000511/webrev.01/webrev/ > This looks better. A few comments: > > In PrintStream it looks like the charset will now be checked twice, once > by using isSupported and again when creating the OutputStreamWriter. As > OutputStreamWriter has a constructor that takes a Charset (and so > doesn't throw UnsupportedEncodingException) then maybe it would be > simpler to just replace verifyCharsetName with a toCharset(String) > method that does the Charset.forName and returns the Charset. If you did > that, and introduced a private constructor that takes the Charset as its > first parameter then it might be cleaner. > > Same thing in PrinterWriter and Formatter and you would avoid the Void > parameter trick that might not be clear to future maintainers. > > Minor nit is that the new private constructor in PrinterWriter might be > better placed before the public constructors that use it. Also minor > comment on Formatter is that the private static getZero method is > declared final :-) > > On Scanner there is one other constructor that has the same issue (line > 726). > > On the tests, it's nice to see multi-catch being used in > test/java/util/Formatter/Constructors.java. It might be good to add the > bugID for future archaeologists trying to understand the behavior change > where UnsupportedEncodingException is thrown instead of FNF. Thanks for the comments. Please take a look at the latest changes. http://cr.openjdk.java.net/~chegar/7000511/webrev.02/webrev/ -Chris. > > -Alan. From alan.bateman at oracle.com Tue Jan 4 18:02:02 2011 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Tue, 04 Jan 2011 18:02:02 +0000 Subject: hg: jdk7/tl/jdk: 7010192: InetAddress.isReachable hits ShouldNotReachHere with hs20-b04 (win) Message-ID: <20110104180211.907A947972@hg.openjdk.java.net> Changeset: 6f2d19ef67b1 Author: alanb Date: 2011-01-04 17:49 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/6f2d19ef67b1 7010192: InetAddress.isReachable hits ShouldNotReachHere with hs20-b04 (win) Reviewed-by: chegar ! src/windows/native/java/net/Inet4AddressImpl.c ! src/windows/native/java/net/Inet6AddressImpl.c From mandy.chung at oracle.com Tue Jan 4 18:05:34 2011 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 04 Jan 2011 10:05:34 -0800 Subject: 6993732: Remove the HPI In-Reply-To: <4D2325AE.7050400@oracle.com> References: <4D2325AE.7050400@oracle.com> Message-ID: <4D23616E.1040200@oracle.com> On 01/04/11 05:50, Alan Bateman wrote: > > The HPI is left over from bygone years where we had a portability > layer and needed to support green and native threading models. Some of > the code has not been used or maintained since the transition to > HotSpot back in jdk1.3. As of jdk7-b123, the HPI library > (libhpi.so/hpi.dll) isn't loaded and it's finally time to wield the > axe and remove this old code. The webrev with the changes is here: > http://cr.openjdk.java.net/~alanb/6993732/webrev/ > Looks good to me. Mandy From mark.reinhold at oracle.com Tue Jan 4 18:15:29 2011 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 04 Jan 2011 10:15:29 -0800 Subject: 6993732: Remove the HPI In-Reply-To: alan.bateman@oracle.com; Tue, 04 Jan 2011 13:50:38 GMT; <4D2325AE.7050400@oracle.com> Message-ID: <20110104181529.9A30CA86@eggemoggin.niobe.net> At last! Your changes look good to me. Thanks for getting this done. - Mark From mike.duigou at oracle.com Tue Jan 4 18:31:57 2011 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 4 Jan 2011 10:31:57 -0800 Subject: Code Review 7000511: PrintStream, PrintWriter, Formatter leave files open when exception thrown In-Reply-To: <4D2336C2.5040108@oracle.com> References: <4D078824.5030307@oracle.com> <4D2336C2.5040108@oracle.com> Message-ID: On Jan 4 2011, at 07:03 , Chris Hegarty wrote: > On 23/12/2010 20:29, Mike Duigou wrote: >> Feedback is on webrev.02 http://cr.openjdk.java.net/~chegar/7000511/webrev.02/webrev/ : >> >> * PrintStream >> >> - .flush(), close(), most println() methods synchronize on this for their entire implementation. They could just be made synchronized methods. > > I think there are pros and cons of doing this, maybe best left to another CR which could look into this separately? Just an observation. Yes, definitely separately, if at all. > >> - The javadoc for append(CharSequence,int,int) for the csq==null condition seems misleading as start and end are considered. > > I'm not sure what the original intent of this was, but from what I can see the javadoc appears to be clear and the implementation looks like it behaves correctly. Rereading it in a new year I'm not as bothered by it. The wording could better reflect that substitution of the string "null" for csq=null is the only special handling for csq=null. - "An invocation ..." could perhaps be improved to: This method is equivalent to calling append(CharSequence) with the subsequence of {@code csq}, or the string "null" if {@code csq} is {@code null}, defined by {@code start} and {@code end}. 
...
- @param csq : "If csq is ..." sentence to read: A {@code null} value is equivalent to passing the string "null". I feel more strongly about the later change than the former (my alternative wording doesn't seem much better to me). > >> * Formatter >> >> - The zero params constructor could just call this((Apppendable) null). The advantage is that the StringBuilder is only constructed in one place. >> >> - The Formatter(Locale) constructor could just call this(l, (Apppendable) null). Same reason. > > Actually, I think it is clearer to have the StringBuilder created as is. It makes it more obvious than having to trace through another constructor. But it you feel strongly I can make the changes. Personal preference only. (It's also easy to follow the trail with Netbeans) > > -Chris. > >> >> >> On Dec 14 2010, at 07:07 , Chris Hegarty wrote: >> >>> Failing java.io.PrintStream, java.io.PrintWriter, java.util.Scanner, and java.util.Formatter multi-arg constructors that take a java.io.File or String filename (as well as one or more additional args) opens a FileIn/OutputStream to the given File/filename. If one of the other given args causes the constructor to fail ( null or unsupported charset for example ) the FileIn/OutputStream is never closed, and the application does not have a reference to it. You rely on the finalizer to close the stream. >>> >>> This is most serious on Windows because you cannot remove a file if there is an open handle to it. >>> >>> I also cleaned up an existing regression test that fails in samevm mode (partly) because of this. And removed another excluded test from the list since its bug was fixed some time ago. >>> >>> Webrev: >>> http://cr.openjdk.java.net/~chegar/7000511/webrev.00/webrev/ >>> >>> -Chris. >> From xueming.shen at oracle.com Tue Jan 4 22:13:00 2011 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Tue, 04 Jan 2011 22:13:00 +0000 Subject: hg: jdk7/tl/jdk: 7009618: regression test failed caused by the fix for 7003462 Message-ID: <20110104221317.3D89B4797B@hg.openjdk.java.net> Changeset: 4379c762ec50 Author: sherman Date: 2011-01-04 14:17 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/4379c762ec50 7009618: regression test failed caused by the fix for 7003462 Summary: avoid caching the "ended" Inflater in ZipFile class Reviewed-by: alanb ! src/share/classes/java/util/zip/Inflater.java ! src/share/classes/java/util/zip/ZipFile.java + test/java/util/zip/ZipFile/FinalizeZipFile.java From lana.steuck at oracle.com Wed Jan 5 01:44:27 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 05 Jan 2011 01:44:27 +0000 Subject: hg: jdk7/tl: 6 new changesets Message-ID: <20110105014428.3AAD247983@hg.openjdk.java.net> Changeset: 4346ba98938b Author: ohair Date: 2010-12-21 16:44 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/rev/4346ba98938b 6360517: ALT_MSDEVTOOLS_PATH and rc.exe location, and rebase location Reviewed-by: ksrini ! Makefile ! README-builds.html Changeset: dc9eb519c6ed Author: ohair Date: 2010-12-22 12:25 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/rev/dc9eb519c6ed 7003845: README-builds document proper location of forest extension, provide alternatives Reviewed-by: robilad ! README ! README-builds.html + get_source.sh + make/scripts/hgforest.sh Changeset: 4d044e6e1080 Author: ohair Date: 2010-12-22 12:27 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/rev/4d044e6e1080 Merge ! README-builds.html Changeset: c1af03f88627 Author: ohair Date: 2010-12-23 18:41 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/rev/c1af03f88627 7008723: Remove binary plugs creation and use from openjdk Reviewed-by: mchung, andrew, aph, dholmes ! Makefile ! README-builds.html Changeset: d0eb51cc458a Author: ohair Date: 2010-12-24 11:16 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/rev/d0eb51cc458a Merge Changeset: 024a6755895b Author: ohair Date: 2010-12-28 15:52 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/rev/024a6755895b 6962318: Update copyright year Reviewed-by: xdono ! make/Defs-internal.gmk ! make/deploy-rules.gmk ! make/hotspot-rules.gmk ! make/install-rules.gmk ! make/jprt.gmk ! make/sanity-rules.gmk + make/scripts/update_copyright_year.sh From lana.steuck at oracle.com Wed Jan 5 01:44:34 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 05 Jan 2011 01:44:34 +0000 Subject: hg: jdk7/tl/corba: 6962318: Update copyright year Message-ID: <20110105014435.C846947984@hg.openjdk.java.net> Changeset: f90b3e014e83 Author: ohair Date: 2010-12-28 15:52 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/f90b3e014e83 6962318: Update copyright year Reviewed-by: xdono ! make/Makefile ! make/com/sun/corba/minclude/com_sun_corba_se_impl_io.jmk ! make/common/Defs-linux.gmk ! make/common/Defs-solaris.gmk ! make/common/Defs-windows.gmk ! make/common/Defs.gmk ! make/common/Rules.gmk ! make/common/shared/Defs-java.gmk ! make/common/shared/Defs-linux.gmk ! make/common/shared/Defs-solaris.gmk ! make/common/shared/Defs-windows.gmk ! make/common/shared/Defs.gmk ! make/org/omg/idl/Makefile ! make/sun/corba/Makefile ! make/sun/corba/core/Makefile ! make/sun/rmi/rmic/FILES.gmk ! src/share/classes/com/sun/corba/se/impl/encoding/BufferManagerWriteStream.java ! src/share/classes/com/sun/corba/se/impl/interceptors/ClientRequestInfoImpl.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/interceptors/RequestInfoImpl.java ! src/share/classes/com/sun/corba/se/impl/io/IIOPInputStream.java ! src/share/classes/com/sun/corba/se/impl/io/ObjectStreamClass.java ! src/share/classes/com/sun/corba/se/impl/orbutil/CorbaResourceUtil.java ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_pt_BR.properties ! src/share/classes/com/sun/corba/se/impl/presentation/rmi/ExceptionHandlerImpl.java ! src/share/classes/com/sun/corba/se/impl/transport/SocketOrChannelConnectionImpl.java ! src/share/classes/com/sun/corba/se/pept/transport/ConnectionCache.java ! src/share/classes/com/sun/corba/se/spi/protocol/PIHandler.java ! src/share/classes/com/sun/corba/se/spi/transport/CorbaConnection.java ! src/share/classes/com/sun/tools/corba/se/idl/constExpr/Expression.java ! src/share/classes/javax/rmi/PortableRemoteObject.java ! src/share/classes/org/omg/CORBA/ORB.java ! src/share/classes/org/omg/CORBA/SetOverrideType.java ! src/share/classes/org/omg/CORBA/TCKind.java ! src/share/classes/org/omg/CORBA/UnknownUserException.java ! src/share/classes/org/omg/CORBA/portable/ServantObject.java ! src/share/classes/org/omg/CosNaming/nameservice.idl ! src/share/classes/org/omg/PortableInterceptor/Interceptors.idl ! src/share/classes/sun/corba/Bridge.java From lana.steuck at oracle.com Wed Jan 5 01:45:14 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 05 Jan 2011 01:45:14 +0000 Subject: hg: jdk7/tl/hotspot: 7 new changesets Message-ID: <20110105014528.392D447985@hg.openjdk.java.net> Changeset: cd8189d84e92 Author: trims Date: 2010-12-22 19:20 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/cd8189d84e92 Added tag hs20-b04 for changeset 9669f9b28410 ! .hgtags Changeset: b03260081e9b Author: johnc Date: 2010-12-17 11:26 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/b03260081e9b 7006113: G1: Initialize ReferenceProcessor::_is_alive_non_header field Summary: Initialize the _is_alive_non_header field of G1's reference processor with an instance of the G1CMIsAliveClosure. This will stop adding reference objects with live referents to the discovered reference lists unnecessarily. Reviewed-by: tonyp, ysr, jwilhelm, brutisso ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp Changeset: 74ee0db180fa Author: ysr Date: 2010-12-17 23:41 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/74ee0db180fa 6807801: CMS: could save/restore fewer header words during scavenge Summary: Age bits need not enter the mark-word preservation calculus; also affected, in addition to CMS, per CR synopsis above, were ParNew (but not DefNew), ParallelScavenge and G1, albeit to a lesser degree than CMS. Reviewed-by: tonyp, johnc ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp ! src/share/vm/memory/defNewGeneration.cpp ! src/share/vm/memory/defNewGeneration.hpp ! src/share/vm/oops/markOop.inline.hpp Changeset: 7c5250dbd584 Author: tonyp Date: 2010-12-19 20:57 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/7c5250dbd584 6896624: G1: hotspot:::gc and hotspot:::mem-pool-gc probes are not fired Summary: Fire the gc-begin and gc-end probes for G1. Reviewed-by: kamg, ysr, jcoomes ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/shared/vmGCOperations.hpp Changeset: 9026f05dc736 Author: johnc Date: 2010-12-23 12:19 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/9026f05dc736 Merge Changeset: 5ef9917b908d Author: trims Date: 2010-12-24 07:59 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/5ef9917b908d 7008759: Bump the HS20 build number to 05 Summary: Update the HS20 build number to 05 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 0a8e0d4345b3 Author: trims Date: 2011-01-03 15:30 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/0a8e0d4345b3 7010068: Update all 2010 Oracle-changed OpenJDK files to have the proper copyright dates - first pass Summary: Update the copyright to be 2010 on all changed files in OpenJDK Reviewed-by: jcoomes ! agent/src/os/linux/libproc_impl.c ! agent/src/os/linux/ps_core.c ! agent/src/os/linux/ps_proc.c ! agent/src/os/linux/symtab.c ! agent/src/os/linux/symtab.h ! agent/src/share/classes/sun/jvm/hotspot/interpreter/BytecodeInvoke.java ! agent/src/share/classes/sun/jvm/hotspot/interpreter/BytecodeWithCPIndex.java ! agent/src/share/classes/sun/jvm/hotspot/interpreter/Bytecodes.java ! agent/src/share/classes/sun/jvm/hotspot/memory/CompactibleFreeListSpace.java ! agent/src/share/classes/sun/jvm/hotspot/memory/SystemDictionary.java ! agent/src/share/classes/sun/jvm/hotspot/oops/ConstantPoolCache.java ! agent/src/share/classes/sun/jvm/hotspot/oops/ConstantPoolCacheEntry.java ! agent/src/share/classes/sun/jvm/hotspot/oops/GenerateOopMap.java ! agent/src/share/classes/sun/jvm/hotspot/oops/Oop.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java ! agent/src/share/classes/sun/jvm/hotspot/tools/jcore/ByteCodeRewriter.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/soql/sa.js ! make/hotspot_distro ! make/hotspot_version ! make/jprt.gmk ! make/jprt.properties ! make/linux/makefiles/defs.make ! make/linux/makefiles/jvmti.make ! make/linux/makefiles/mapfile-vers-debug ! make/linux/makefiles/mapfile-vers-product ! make/linux/makefiles/product.make ! make/linux/makefiles/saproc.make ! make/linux/makefiles/shark.make ! make/linux/makefiles/sparcWorks.make ! make/solaris/makefiles/defs.make ! make/solaris/makefiles/fastdebug.make ! make/solaris/makefiles/jvmti.make ! make/solaris/makefiles/optimized.make ! make/solaris/makefiles/product.make ! make/solaris/makefiles/saproc.make ! make/windows/build.bat ! make/windows/get_msc_ver.sh ! make/windows/makefiles/defs.make ! make/windows/makefiles/sanity.make ! src/os/solaris/dtrace/hotspot.d ! src/os_cpu/linux_x86/vm/linux_x86_32.s ! src/os_cpu/solaris_x86/vm/solaris_x86_32.il ! src/os_cpu/solaris_x86/vm/solaris_x86_32.s ! src/os_cpu/solaris_x86/vm/solaris_x86_64.il ! test/Makefile ! test/compiler/6431242/Test.java ! test/compiler/6857159/Test6857159.java ! test/compiler/6877254/Test.java ! test/compiler/6895383/Test.java ! test/compiler/6896727/Test.java From lana.steuck at oracle.com Wed Jan 5 01:45:59 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 05 Jan 2011 01:45:59 +0000 Subject: hg: jdk7/tl/jaxp: 2 new changesets Message-ID: <20110105014559.EB2D747986@hg.openjdk.java.net> Changeset: 57ed1f3bec72 Author: ohair Date: 2010-12-28 15:52 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/57ed1f3bec72 6962318: Update copyright year Reviewed-by: xdono ! build.properties ! make/Makefile Changeset: 3a829f5ba9d2 Author: lana Date: 2011-01-04 16:28 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/3a829f5ba9d2 Merge From lana.steuck at oracle.com Wed Jan 5 01:46:05 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 05 Jan 2011 01:46:05 +0000 Subject: hg: jdk7/tl/jaxws: 2 new changesets Message-ID: <20110105014605.0B6CC47987@hg.openjdk.java.net> Changeset: 86f60e5b3975 Author: ohair Date: 2010-12-28 15:53 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/86f60e5b3975 6962318: Update copyright year Reviewed-by: xdono ! build.properties ! jaxws.properties ! make/Makefile Changeset: 466e89f7e5be Author: lana Date: 2011-01-04 16:37 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/466e89f7e5be Merge ! jaxws.properties From lana.steuck at oracle.com Wed Jan 5 01:46:47 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 05 Jan 2011 01:46:47 +0000 Subject: hg: jdk7/tl/jdk: 6 new changesets Message-ID: <20110105014752.DBAE447988@hg.openjdk.java.net> Changeset: 4e70663f0163 Author: ohair Date: 2010-12-21 18:21 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/4e70663f0163 6360517: ALT_MSDEVTOOLS_PATH and rc.exe location, and rebase location Reviewed-by: ksrini ! make/Makefile ! make/common/shared/Compiler-gcc.gmk ! make/common/shared/Compiler-msvc.gmk ! make/common/shared/Defs-solaris.gmk ! make/common/shared/Defs-versions.gmk ! make/common/shared/Defs-windows.gmk ! make/common/shared/Defs.gmk ! make/common/shared/Sanity-Settings.gmk ! make/common/shared/Sanity.gmk ! make/jdk_generic_profile.sh Changeset: 217c842d710b Author: ohair Date: 2010-12-23 18:50 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/217c842d710b 7008723: Remove binary plugs creation and use from openjdk Reviewed-by: mchung, andrew, aph, dholmes ! README ! make/Makefile ! make/com/sun/jmx/Makefile ! make/common/Defs.gmk ! make/common/Library.gmk ! make/common/Program.gmk ! make/common/Release.gmk ! make/common/Sanity.gmk - make/common/internal/BinaryPlugs.gmk ! make/common/shared/Sanity-Settings.gmk ! make/common/shared/Sanity.gmk ! make/java/redist/Makefile ! make/javax/sound/Makefile ! make/jdk_generic_profile.sh ! make/netbeans/README ! make/sun/dcpr/Makefile ! make/sun/font/t2k/Makefile ! make/sun/management/Makefile Changeset: ab960e856d18 Author: ohair Date: 2010-12-24 11:17 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/ab960e856d18 Merge - make/common/internal/BinaryPlugs.gmk ! make/common/shared/Defs-versions.gmk ! make/common/shared/Sanity.gmk Changeset: a06412e13bf7 Author: ohair Date: 2010-12-28 15:53 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/a06412e13bf7 6962318: Update copyright year Reviewed-by: xdono ! make/com/Makefile ! make/com/sun/Makefile ! make/com/sun/crypto/provider/Makefile ! make/com/sun/demo/Makefile ! make/com/sun/demo/jvmti/Makefile ! make/com/sun/java/Makefile ! make/com/sun/java/browser/Makefile ! make/com/sun/java/pack/Makefile ! make/com/sun/java/pack/prop/Makefile ! make/com/sun/jmx/Makefile ! make/com/sun/jndi/Makefile ! make/com/sun/jndi/cosnaming/Makefile ! make/com/sun/jndi/dns/Makefile ! make/com/sun/jndi/ldap/Makefile ! make/com/sun/jndi/rmi/Makefile ! make/com/sun/jndi/rmi/registry/Makefile ! make/com/sun/nio/Makefile ! make/com/sun/nio/sctp/FILES_java.gmk ! make/com/sun/nio/sctp/Makefile ! make/com/sun/nio/sctp/mapfile-vers ! make/com/sun/org/Makefile ! make/com/sun/org/apache/Makefile ! make/com/sun/org/apache/xml/Makefile ! make/com/sun/rowset/Makefile ! make/com/sun/script/Makefile ! make/com/sun/security/Makefile ! make/com/sun/security/auth/module/Makefile ! make/com/sun/servicetag/Makefile ! make/com/sun/tools/Makefile ! make/com/sun/tools/attach/Makefile ! make/com/sun/tracing/Makefile ! make/common/Cscope.gmk ! make/common/Defs-linux.gmk ! make/common/Defs-solaris.gmk ! make/common/Defs-windows.gmk ! make/common/Defs.gmk ! make/common/Demo.gmk ! make/common/Library.gmk ! make/common/Modules.gmk ! make/common/Program.gmk ! make/common/Release.gmk ! make/common/Sanity.gmk ! make/common/internal/Resources.gmk ! make/common/shared/Compiler-sun.gmk ! make/common/shared/Defs-control.gmk ! make/common/shared/Defs-java.gmk ! make/common/shared/Defs-linux.gmk ! make/common/shared/Defs-utils.gmk ! make/docs/CORE_PKGS.gmk ! make/docs/NON_CORE_PKGS.gmk ! make/java/Makefile ! make/java/awt/Makefile ! make/java/dyn/Makefile ! make/java/fdlibm/Makefile ! make/java/hpi/Makefile ! make/java/hpi/hpi_common.gmk ! make/java/hpi/native/Makefile ! make/java/hpi/windows/Makefile ! make/java/instrument/Makefile ! make/java/java/Makefile ! make/java/java/genlocales.gmk ! make/java/java_crw_demo/Makefile ! make/java/java_hprof_demo/Makefile ! make/java/jli/Makefile ! make/java/logging/Makefile ! make/java/main/Makefile ! make/java/main/java/Makefile ! make/java/main/javaw/Makefile ! make/java/management/Makefile ! make/java/net/FILES_c.gmk ! make/java/net/Makefile ! make/java/net/mapfile-vers ! make/java/nio/FILES_java.gmk ! make/java/nio/Makefile ! make/java/nio/mapfile-linux ! make/java/nio/mapfile-solaris ! make/java/npt/Makefile ! make/java/redist/Makefile ! make/java/redist/fonts/Makefile ! make/java/redist/sajdi/Makefile ! make/java/sql/Makefile ! make/java/sun_nio/Makefile ! make/java/text/base/Makefile ! make/java/util/FILES_java.gmk ! make/java/verify/Makefile ! make/java/zip/Makefile ! make/javax/Makefile ! make/javax/crypto/Makefile ! make/javax/imageio/Makefile ! make/javax/print/Makefile ! make/javax/rmi/Makefile ! make/javax/sound/Makefile ! make/javax/sound/jsoundalsa/Makefile ! make/javax/sound/jsoundds/Makefile ! make/javax/sql/Makefile ! make/javax/swing/FILES.gmk ! make/javax/swing/Makefile ! make/javax/swing/beaninfo/SwingBeans.gmk ! make/javax/swing/plaf/Makefile ! make/jpda/Makefile ! make/jpda/back/Makefile ! make/jpda/transport/Makefile ! make/jpda/transport/shmem/Makefile ! make/jpda/transport/socket/Makefile ! make/jpda/tty/Makefile ! make/jprt.gmk ! make/jprt.properties ! make/launchers/Makefile ! make/mkdemo/Makefile ! make/mkdemo/applets/Makefile ! make/mkdemo/jfc/Makefile ! make/mkdemo/jni/Makefile ! make/mkdemo/jvmti/hprof/Makefile ! make/mkdemo/management/Makefile ! make/mkdemo/nio/Makefile ! make/mkdemo/nio/zipfs/Makefile ! make/mkdemo/scripting/Makefile ! make/mksample/Makefile ! make/mksample/dtrace/Makefile ! make/mksample/jmx/Makefile ! make/mksample/jmx/jmx-scandir/Makefile ! make/mksample/nbproject/Makefile ! make/mksample/nio/Makefile ! make/mksample/nio/file/Makefile ! make/mksample/nio/multicast/Makefile ! make/mksample/nio/server/Makefile ! make/mksample/scripting/Makefile ! make/mksample/scripting/scriptpad/Makefile ! make/mksample/webservices/EbayClient/Makefile ! make/mksample/webservices/EbayServer/Makefile ! make/mksample/webservices/Makefile ! make/modules/Makefile ! make/modules/modules.config ! make/modules/optional.depconfig ! make/modules/tools/Makefile ! make/modules/tools/nbproject/project.properties ! make/modules/tools/src/com/sun/classanalyzer/Module.java ! make/netbeans/world/build.xml ! make/org/Makefile ! make/org/ietf/Makefile ! make/sun/Makefile ! make/sun/applet/Makefile ! make/sun/awt/FILES_c_unix.gmk ! make/sun/awt/FILES_c_windows.gmk ! make/sun/awt/FILES_export_unix.gmk ! make/sun/awt/FILES_export_windows.gmk ! make/sun/awt/Makefile ! make/sun/awt/mapfile-mawt-vers ! make/sun/awt/mapfile-vers ! make/sun/awt/mapfile-vers-linux ! make/sun/cmm/Makefile ! make/sun/cmm/kcms/Makefile ! make/sun/cmm/lcms/FILES_c_unix.gmk ! make/sun/cmm/lcms/FILES_c_windows.gmk ! make/sun/cmm/lcms/Makefile ! make/sun/dcpr/Makefile ! make/sun/font/FILES_c.gmk ! make/sun/font/Makefile ! make/sun/font/t2k/Makefile ! make/sun/headless/Makefile ! make/sun/headless/mapfile-vers ! make/sun/image/Makefile ! make/sun/image/generic/Makefile ! make/sun/image/vis/Makefile ! make/sun/jar/Makefile ! make/sun/javazic/Makefile ! make/sun/jawt/Makefile ! make/sun/jconsole/Makefile ! make/sun/jdbc/Makefile ! make/sun/jdga/Makefile ! make/sun/jkernel/Makefile ! make/sun/jpeg/Makefile ! make/sun/launcher/Makefile ! make/sun/management/Makefile ! make/sun/native2ascii/Makefile ! make/sun/net/FILES_java.gmk ! make/sun/net/Makefile ! make/sun/net/others/Makefile ! make/sun/net/spi/Makefile ! make/sun/net/spi/nameservice/Makefile ! make/sun/net/spi/nameservice/dns/Makefile ! make/sun/nio/Makefile ! make/sun/nio/cs/FILES_java.gmk ! make/sun/nio/cs/Makefile ! make/sun/org/Makefile ! make/sun/org/mozilla/Makefile ! make/sun/org/mozilla/javascript/Makefile ! make/sun/pisces/Makefile ! make/sun/rmi/Makefile ! make/sun/rmi/cgi/Makefile ! make/sun/rmi/oldtools/Makefile ! make/sun/rmi/registry/Makefile ! make/sun/rmi/rmi/Makefile ! make/sun/rmi/rmic/Makefile ! make/sun/rmi/rmid/Makefile ! make/sun/security/Makefile ! make/sun/security/ec/Makefile ! make/sun/security/jgss/wrapper/Makefile ! make/sun/security/krb5/Makefile ! make/sun/security/mscapi/Makefile ! make/sun/security/pkcs11/Makefile ! make/sun/security/smartcardio/Makefile ! make/sun/serialver/Makefile ! make/sun/splashscreen/Makefile ! make/sun/text/Makefile ! make/sun/tools/Makefile ! make/sun/tracing/Makefile ! make/sun/tracing/dtrace/Makefile ! make/sun/xawt/FILES_c_unix.gmk ! make/sun/xawt/FILES_export_unix.gmk ! make/sun/xawt/Makefile ! make/sun/xawt/mapfile-vers ! make/tools/Makefile ! make/tools/freetypecheck/freetypecheck.c ! make/tools/src/build/tools/charsetmapping/JIS0213.java ! make/tools/src/build/tools/charsetmapping/Main.java ! make/tools/src/build/tools/charsetmapping/SBCS.java ! make/tools/src/build/tools/charsetmapping/Utils.java ! make/tools/src/build/tools/generatecharacter/GenerateCharacter.java ! make/tools/src/build/tools/jarreorder/JarReorder.java ! make/tools/src/build/tools/javazic/RuleDay.java ! src/share/bin/main.c ! src/share/bin/parse_manifest.c ! src/share/bin/wildcard.c ! src/share/classes/com/sun/imageio/plugins/bmp/BMPImageReaderSpi.java ! src/share/classes/com/sun/imageio/plugins/bmp/BMPImageWriterSpi.java ! src/share/classes/com/sun/imageio/plugins/gif/GIFImageReaderSpi.java ! src/share/classes/com/sun/imageio/plugins/gif/GIFImageWriterSpi.java ! src/share/classes/com/sun/imageio/plugins/jpeg/JPEG.java ! src/share/classes/com/sun/imageio/plugins/png/PNGImageReaderSpi.java ! src/share/classes/com/sun/imageio/plugins/png/PNGImageWriterSpi.java ! src/share/classes/com/sun/imageio/plugins/wbmp/WBMPImageReaderSpi.java ! src/share/classes/com/sun/imageio/plugins/wbmp/WBMPImageWriterSpi.java ! src/share/classes/com/sun/imageio/spi/FileImageInputStreamSpi.java ! src/share/classes/com/sun/imageio/spi/FileImageOutputStreamSpi.java ! src/share/classes/com/sun/imageio/spi/InputStreamImageInputStreamSpi.java ! src/share/classes/com/sun/imageio/spi/OutputStreamImageOutputStreamSpi.java ! src/share/classes/com/sun/imageio/spi/RAFImageInputStreamSpi.java ! src/share/classes/com/sun/imageio/spi/RAFImageOutputStreamSpi.java ! src/share/classes/com/sun/java/swing/plaf/gtk/PangoFonts.java ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsComboBoxUI.java ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsTableHeaderUI.java ! src/share/classes/com/sun/java/util/jar/pack/AdaptiveCoding.java ! src/share/classes/com/sun/java/util/jar/pack/BandStructure.java ! src/share/classes/com/sun/java/util/jar/pack/ClassWriter.java ! src/share/classes/com/sun/java/util/jar/pack/Code.java ! src/share/classes/com/sun/java/util/jar/pack/Coding.java ! src/share/classes/com/sun/java/util/jar/pack/CodingChooser.java ! src/share/classes/com/sun/java/util/jar/pack/CodingMethod.java ! src/share/classes/com/sun/java/util/jar/pack/Fixups.java ! src/share/classes/com/sun/java/util/jar/pack/Histogram.java ! src/share/classes/com/sun/java/util/jar/pack/Instruction.java ! src/share/classes/com/sun/java/util/jar/pack/PackageReader.java ! src/share/classes/com/sun/java/util/jar/pack/PackageWriter.java ! src/share/classes/com/sun/java/util/jar/pack/PopulationCoding.java ! src/share/classes/com/sun/jndi/dns/DnsClient.java ! src/share/classes/com/sun/jndi/rmi/registry/RegistryContext.java ! src/share/classes/com/sun/media/sound/AbstractMidiDevice.java ! src/share/classes/com/sun/media/sound/AudioSynthesizerPropertyInfo.java ! src/share/classes/com/sun/media/sound/ModelByteBufferWavetable.java ! src/share/classes/com/sun/media/sound/ModelInstrument.java ! src/share/classes/com/sun/media/sound/SoftReceiver.java ! src/share/classes/com/sun/media/sound/SoftVoice.java ! src/share/classes/com/sun/net/httpserver/BasicAuthenticator.java ! src/share/classes/com/sun/net/httpserver/Filter.java ! src/share/classes/com/sun/net/httpserver/Headers.java ! src/share/classes/com/sun/net/httpserver/HttpsConfigurator.java ! src/share/classes/com/sun/net/httpserver/HttpsParameters.java ! src/share/classes/com/sun/rowset/internal/XmlReaderContentHandler.java ! src/share/classes/com/sun/security/auth/LdapPrincipal.java ! src/share/classes/com/sun/security/sasl/CramMD5Client.java ! src/share/classes/com/sun/security/sasl/CramMD5Server.java ! src/share/classes/com/sun/security/sasl/ExternalClient.java ! src/share/classes/com/sun/security/sasl/gsskerb/GssKrb5Client.java ! src/share/classes/com/sun/security/sasl/gsskerb/GssKrb5Server.java ! src/share/classes/com/sun/servicetag/Registry.java ! src/share/classes/com/sun/servicetag/SunConnection.java ! src/share/classes/com/sun/servicetag/resources/register.html ! src/share/classes/com/sun/servicetag/resources/register_ja.html ! src/share/classes/com/sun/servicetag/resources/register_zh_CN.html ! src/share/classes/com/sun/tools/example/debug/tty/TTYResources.java ! src/share/classes/java/awt/AWTEvent.java ! src/share/classes/java/awt/AlphaComposite.java ! src/share/classes/java/awt/Canvas.java ! src/share/classes/java/awt/Color.java ! src/share/classes/java/awt/Component.java ! src/share/classes/java/awt/Container.java ! src/share/classes/java/awt/Dialog.java ! src/share/classes/java/awt/EventDispatchThread.java ! src/share/classes/java/awt/EventQueue.java ! src/share/classes/java/awt/FileDialog.java ! src/share/classes/java/awt/Font.java ! src/share/classes/java/awt/Frame.java ! src/share/classes/java/awt/GraphicsEnvironment.java ! src/share/classes/java/awt/GridBagConstraints.java ! src/share/classes/java/awt/KeyboardFocusManager.java ! src/share/classes/java/awt/ScrollPane.java ! src/share/classes/java/awt/Scrollbar.java ! src/share/classes/java/awt/SequencedEvent.java ! src/share/classes/java/awt/SplashScreen.java ! src/share/classes/java/awt/Toolkit.java ! src/share/classes/java/awt/Window.java ! src/share/classes/java/awt/event/ActionEvent.java ! src/share/classes/java/awt/event/InputEvent.java ! src/share/classes/java/awt/image/IndexColorModel.java ! src/share/classes/java/awt/image/SampleModel.java ! src/share/classes/java/beans/MetaData.java ! src/share/classes/java/beans/XMLDecoder.java ! src/share/classes/java/dyn/Linkage.java ! src/share/classes/java/dyn/MethodType.java ! src/share/classes/java/dyn/package-info.java ! src/share/classes/java/io/Bits.java ! src/share/classes/java/io/BufferedInputStream.java ! src/share/classes/java/io/ByteArrayInputStream.java ! src/share/classes/java/io/ByteArrayOutputStream.java ! src/share/classes/java/io/Closeable.java ! src/share/classes/java/io/FileOutputStream.java ! src/share/classes/java/io/FilterInputStream.java ! src/share/classes/java/io/ObjectInput.java ! src/share/classes/java/io/ObjectOutput.java ! src/share/classes/java/io/PushbackInputStream.java ! src/share/classes/java/io/package.html ! src/share/classes/java/lang/AbstractStringBuilder.java ! src/share/classes/java/lang/AssertionError.java ! src/share/classes/java/lang/Deprecated.java ! src/share/classes/java/lang/Error.java ! src/share/classes/java/lang/Exception.java ! src/share/classes/java/lang/Integer.java ! src/share/classes/java/lang/Iterable.java ! src/share/classes/java/lang/Math.java ! src/share/classes/java/lang/Object.java ! src/share/classes/java/lang/ProcessBuilder.java ! src/share/classes/java/lang/Readable.java ! src/share/classes/java/lang/RuntimeException.java ! src/share/classes/java/lang/String.java ! src/share/classes/java/lang/SuppressWarnings.java ! src/share/classes/java/lang/System.java ! src/share/classes/java/lang/Thread.java ! src/share/classes/java/lang/ThreadGroup.java ! src/share/classes/java/lang/reflect/Constructor.java ! src/share/classes/java/net/AbstractPlainSocketImpl.java ! src/share/classes/java/net/DatagramSocket.java ! src/share/classes/java/net/HttpCookie.java ! src/share/classes/java/net/HttpURLConnection.java ! src/share/classes/java/net/Inet6Address.java ! src/share/classes/java/net/InetAddress.java ! src/share/classes/java/net/NetPermission.java ! src/share/classes/java/net/NetworkInterface.java ! src/share/classes/java/net/ServerSocket.java ! src/share/classes/java/net/SocketInputStream.java ! src/share/classes/java/net/SocksSocketImpl.java ! src/share/classes/java/net/URI.java ! src/share/classes/java/nio/Bits.java ! src/share/classes/java/nio/Direct-X-Buffer.java.template ! src/share/classes/java/nio/MappedByteBuffer.java ! src/share/classes/java/nio/StringCharBuffer.java ! src/share/classes/java/nio/channels/AsynchronousSocketChannel.java ! src/share/classes/java/nio/channels/FileLock.java ! src/share/classes/java/nio/channels/package-info.java ! src/share/classes/java/nio/channels/spi/AbstractInterruptibleChannel.java ! src/share/classes/java/nio/channels/spi/AbstractSelector.java ! src/share/classes/java/nio/channels/spi/AsynchronousChannelProvider.java ! src/share/classes/java/nio/charset/Charset.java ! src/share/classes/java/nio/charset/package.html ! src/share/classes/java/nio/file/DirectoryStream.java ! src/share/classes/java/nio/file/FileTreeWalker.java ! src/share/classes/java/nio/file/FileVisitOption.java ! src/share/classes/java/nio/file/FileVisitor.java ! src/share/classes/java/nio/file/Files.java ! src/share/classes/java/nio/file/Path.java ! src/share/classes/java/nio/file/SecureDirectoryStream.java ! src/share/classes/java/nio/file/SimpleFileVisitor.java ! src/share/classes/java/security/IdentityScope.java ! src/share/classes/java/security/Security.java ! src/share/classes/java/security/cert/PKIXParameters.java ! src/share/classes/java/text/CollationElementIterator.java ! src/share/classes/java/text/DateFormat.java ! src/share/classes/java/text/MessageFormat.java ! src/share/classes/java/text/NumberFormat.java ! src/share/classes/java/text/RuleBasedBreakIterator.java ! src/share/classes/java/util/AbstractCollection.java ! src/share/classes/java/util/AbstractList.java ! src/share/classes/java/util/AbstractMap.java ! src/share/classes/java/util/ArrayList.java ! src/share/classes/java/util/Arrays.java ! src/share/classes/java/util/Collection.java ! src/share/classes/java/util/Collections.java ! src/share/classes/java/util/ConcurrentModificationException.java ! src/share/classes/java/util/Currency.java ! src/share/classes/java/util/Date.java ! src/share/classes/java/util/FormattableFlags.java ! src/share/classes/java/util/Formatter.java ! src/share/classes/java/util/Hashtable.java ! src/share/classes/java/util/Iterator.java ! src/share/classes/java/util/LinkedList.java ! src/share/classes/java/util/List.java ! src/share/classes/java/util/ListResourceBundle.java ! src/share/classes/java/util/PriorityQueue.java ! src/share/classes/java/util/Properties.java ! src/share/classes/java/util/Random.java ! src/share/classes/java/util/Scanner.java ! src/share/classes/java/util/Stack.java ! src/share/classes/java/util/TreeMap.java ! src/share/classes/java/util/TreeSet.java ! src/share/classes/java/util/Vector.java ! src/share/classes/java/util/XMLUtils.java ! src/share/classes/java/util/concurrent/CopyOnWriteArrayList.java ! src/share/classes/java/util/jar/JarInputStream.java ! src/share/classes/java/util/logging/LogRecord.java ! src/share/classes/java/util/regex/Pattern.java ! src/share/classes/java/util/spi/CurrencyNameProvider.java ! src/share/classes/java/util/spi/LocaleServiceProvider.java ! src/share/classes/java/util/zip/Deflater.java ! src/share/classes/java/util/zip/ZipFile.java ! src/share/classes/javax/imageio/stream/ImageInputStream.java ! src/share/classes/javax/management/remote/JMXServiceURL.java ! src/share/classes/javax/naming/event/EventDirContext.java ! src/share/classes/javax/naming/ldap/Control.java ! src/share/classes/javax/naming/ldap/ControlFactory.java ! src/share/classes/javax/naming/ldap/ExtendedRequest.java ! src/share/classes/javax/naming/ldap/ExtendedResponse.java ! src/share/classes/javax/naming/ldap/LdapName.java ! src/share/classes/javax/naming/ldap/Rdn.java ! src/share/classes/javax/naming/ldap/UnsolicitedNotification.java ! src/share/classes/javax/naming/ldap/UnsolicitedNotificationListener.java ! src/share/classes/javax/net/SocketFactory.java ! src/share/classes/javax/net/ssl/SSLContext.java ! src/share/classes/javax/print/DocFlavor.java ! src/share/classes/javax/sound/midi/MidiDevice.java ! src/share/classes/javax/sound/midi/MidiSystem.java ! src/share/classes/javax/sound/midi/Receiver.java ! src/share/classes/javax/sound/midi/Transmitter.java ! src/share/classes/javax/sound/sampled/Line.java ! src/share/classes/javax/swing/AbstractButton.java ! src/share/classes/javax/swing/DebugGraphics.java ! src/share/classes/javax/swing/DefaultDesktopManager.java ! src/share/classes/javax/swing/GroupLayout.java ! src/share/classes/javax/swing/JColorChooser.java ! src/share/classes/javax/swing/JComponent.java ! src/share/classes/javax/swing/JDesktopPane.java ! src/share/classes/javax/swing/JEditorPane.java ! src/share/classes/javax/swing/JLayer.java ! src/share/classes/javax/swing/JList.java ! src/share/classes/javax/swing/JSplitPane.java ! src/share/classes/javax/swing/JTabbedPane.java ! src/share/classes/javax/swing/JTextField.java ! src/share/classes/javax/swing/JTree.java ! src/share/classes/javax/swing/JViewport.java ! src/share/classes/javax/swing/Popup.java ! src/share/classes/javax/swing/RepaintManager.java ! src/share/classes/javax/swing/SwingUtilities.java ! src/share/classes/javax/swing/ToolTipManager.java ! src/share/classes/javax/swing/UIDefaults.java ! src/share/classes/javax/swing/plaf/LayerUI.java ! src/share/classes/javax/swing/plaf/basic/BasicButtonListener.java ! src/share/classes/javax/swing/plaf/basic/BasicComboPopup.java ! src/share/classes/javax/swing/plaf/basic/BasicFileChooserUI.java ! src/share/classes/javax/swing/plaf/basic/BasicLookAndFeel.java ! src/share/classes/javax/swing/plaf/basic/BasicMenuUI.java ! src/share/classes/javax/swing/plaf/basic/BasicScrollBarUI.java ! src/share/classes/javax/swing/plaf/basic/BasicScrollPaneUI.java ! src/share/classes/javax/swing/plaf/basic/BasicSliderUI.java ! src/share/classes/javax/swing/plaf/basic/BasicTabbedPaneUI.java ! src/share/classes/javax/swing/plaf/basic/BasicTableHeaderUI.java ! src/share/classes/javax/swing/plaf/basic/BasicTextUI.java ! src/share/classes/javax/swing/plaf/basic/BasicViewportUI.java ! src/share/classes/javax/swing/plaf/metal/MetalComboBoxUI.java ! src/share/classes/javax/swing/plaf/metal/MetalScrollPaneUI.java ! src/share/classes/javax/swing/plaf/nimbus/NimbusStyle.java ! src/share/classes/javax/swing/plaf/synth/SynthButtonUI.java ! src/share/classes/javax/swing/plaf/synth/SynthColorChooserUI.java ! src/share/classes/javax/swing/plaf/synth/SynthComboBoxUI.java ! src/share/classes/javax/swing/plaf/synth/SynthDesktopIconUI.java ! src/share/classes/javax/swing/plaf/synth/SynthDesktopPaneUI.java ! src/share/classes/javax/swing/plaf/synth/SynthEditorPaneUI.java ! src/share/classes/javax/swing/plaf/synth/SynthInternalFrameUI.java ! src/share/classes/javax/swing/plaf/synth/SynthLabelUI.java ! src/share/classes/javax/swing/plaf/synth/SynthListUI.java ! src/share/classes/javax/swing/plaf/synth/SynthLookAndFeel.java ! src/share/classes/javax/swing/plaf/synth/SynthMenuBarUI.java ! src/share/classes/javax/swing/plaf/synth/SynthMenuItemUI.java ! src/share/classes/javax/swing/plaf/synth/SynthMenuUI.java ! src/share/classes/javax/swing/plaf/synth/SynthOptionPaneUI.java ! src/share/classes/javax/swing/plaf/synth/SynthPanelUI.java ! src/share/classes/javax/swing/plaf/synth/SynthParser.java ! src/share/classes/javax/swing/plaf/synth/SynthPopupMenuUI.java ! src/share/classes/javax/swing/plaf/synth/SynthProgressBarUI.java ! src/share/classes/javax/swing/plaf/synth/SynthRootPaneUI.java ! src/share/classes/javax/swing/plaf/synth/SynthScrollBarUI.java ! src/share/classes/javax/swing/plaf/synth/SynthScrollPaneUI.java ! src/share/classes/javax/swing/plaf/synth/SynthSeparatorUI.java ! src/share/classes/javax/swing/plaf/synth/SynthSliderUI.java ! src/share/classes/javax/swing/plaf/synth/SynthSpinnerUI.java ! src/share/classes/javax/swing/plaf/synth/SynthSplitPaneUI.java ! src/share/classes/javax/swing/plaf/synth/SynthTableHeaderUI.java ! src/share/classes/javax/swing/plaf/synth/SynthTableUI.java ! src/share/classes/javax/swing/plaf/synth/SynthTextAreaUI.java ! src/share/classes/javax/swing/plaf/synth/SynthTextFieldUI.java ! src/share/classes/javax/swing/plaf/synth/SynthTextPaneUI.java ! src/share/classes/javax/swing/plaf/synth/SynthToolBarUI.java ! src/share/classes/javax/swing/plaf/synth/SynthToolTipUI.java ! src/share/classes/javax/swing/plaf/synth/SynthTreeUI.java ! src/share/classes/javax/swing/plaf/synth/SynthViewportUI.java ! src/share/classes/javax/swing/table/DefaultTableCellRenderer.java ! src/share/classes/javax/swing/text/DefaultCaret.java ! src/share/classes/javax/swing/text/DefaultEditorKit.java ! src/share/classes/javax/swing/text/DefaultFormatter.java ! src/share/classes/javax/swing/text/DefaultHighlighter.java ! src/share/classes/javax/swing/text/DefaultStyledDocument.java ! src/share/classes/javax/swing/text/GlyphView.java ! src/share/classes/javax/swing/text/InternationalFormatter.java ! src/share/classes/javax/swing/text/JTextComponent.java ! src/share/classes/javax/swing/text/MaskFormatter.java ! src/share/classes/javax/swing/text/NumberFormatter.java ! src/share/classes/javax/swing/text/PlainDocument.java ! src/share/classes/javax/swing/text/TabSet.java ! src/share/classes/javax/swing/text/Utilities.java ! src/share/classes/javax/swing/text/WrappedPlainView.java ! src/share/classes/javax/swing/text/html/FormView.java ! src/share/classes/javax/swing/text/html/HTMLDocument.java ! src/share/classes/javax/swing/text/html/MinimalHTMLWriter.java ! src/share/classes/javax/swing/text/html/StyleSheet.java ! src/share/classes/javax/swing/text/html/parser/Parser.java ! src/share/classes/javax/swing/text/rtf/AbstractFilter.java ! src/share/classes/sun/applet/resources/MsgAppletViewer.java ! src/share/classes/sun/applet/resources/MsgAppletViewer_pt_BR.java ! src/share/classes/sun/applet/resources/MsgAppletViewer_zh_CN.java ! src/share/classes/sun/awt/AWTAccessor.java ! src/share/classes/sun/awt/EmbeddedFrame.java ! src/share/classes/sun/awt/HKSCS.java ! src/share/classes/sun/awt/PlatformFont.java ! src/share/classes/sun/awt/SunToolkit.java ! src/share/classes/sun/awt/UngrabEvent.java ! src/share/classes/sun/awt/dnd/SunDropTargetContextPeer.java ! src/share/classes/sun/awt/image/BufImgSurfaceData.java ! src/share/classes/sun/awt/image/ImageRepresentation.java ! src/share/classes/sun/awt/image/PNGImageDecoder.java ! src/share/classes/sun/dyn/AdapterMethodHandle.java ! src/share/classes/sun/dyn/BoundMethodHandle.java ! src/share/classes/sun/dyn/CallSiteImpl.java ! src/share/classes/sun/dyn/FilterGeneric.java ! src/share/classes/sun/dyn/FilterOneArgument.java ! src/share/classes/sun/dyn/FromGeneric.java ! src/share/classes/sun/dyn/Invokers.java ! src/share/classes/sun/dyn/MethodTypeImpl.java ! src/share/classes/sun/dyn/SpreadGeneric.java ! src/share/classes/sun/dyn/ToGeneric.java ! src/share/classes/sun/dyn/empty/Empty.java ! src/share/classes/sun/dyn/package-info.java ! src/share/classes/sun/dyn/util/BytecodeDescriptor.java ! src/share/classes/sun/dyn/util/BytecodeName.java ! src/share/classes/sun/dyn/util/ValueConversions.java ! src/share/classes/sun/dyn/util/VerifyAccess.java ! src/share/classes/sun/dyn/util/VerifyType.java ! src/share/classes/sun/dyn/util/Wrapper.java ! src/share/classes/sun/font/FontManagerFactory.java ! src/share/classes/sun/font/FontUtilities.java ! src/share/classes/sun/font/StrikeCache.java ! src/share/classes/sun/font/SunFontManager.java ! src/share/classes/sun/io/ByteToCharBig5.java ! src/share/classes/sun/io/ByteToCharBig5_HKSCS.java ! src/share/classes/sun/io/ByteToCharBig5_Solaris.java ! src/share/classes/sun/io/ByteToCharISO2022.java ! src/share/classes/sun/io/ByteToCharISO2022JP.java ! src/share/classes/sun/io/ByteToCharJISAutoDetect.java ! src/share/classes/sun/io/ByteToCharMS950_HKSCS.java ! src/share/classes/sun/io/ByteToCharUTF8.java ! src/share/classes/sun/io/CharToByteBig5.java ! src/share/classes/sun/io/CharToByteBig5_HKSCS.java ! src/share/classes/sun/io/CharToByteBig5_Solaris.java ! src/share/classes/sun/io/CharToByteDBCS_ASCII.java ! src/share/classes/sun/io/CharToByteDBCS_EBCDIC.java ! src/share/classes/sun/io/CharToByteMS950_HKSCS.java ! src/share/classes/sun/io/CharToBytePCK.java ! src/share/classes/sun/io/CharToByteUnicode.java ! src/share/classes/sun/io/Converters.java ! src/share/classes/sun/java2d/Disposer.java ! src/share/classes/sun/java2d/HeadlessGraphicsEnvironment.java ! src/share/classes/sun/java2d/SurfaceData.java ! src/share/classes/sun/java2d/cmm/CMSManager.java ! src/share/classes/sun/java2d/cmm/lcms/LCMS.java ! src/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java ! src/share/classes/sun/java2d/loops/DrawParallelogram.java ! src/share/classes/sun/java2d/loops/FillParallelogram.java ! src/share/classes/sun/java2d/loops/GraphicsPrimitive.java ! src/share/classes/sun/java2d/loops/RenderLoops.java ! src/share/classes/sun/java2d/pipe/BufferedPaints.java ! src/share/classes/sun/java2d/pipe/LoopPipe.java ! src/share/classes/sun/java2d/pipe/RenderBuffer.java ! src/share/classes/sun/java2d/pisces/Curve.java ! src/share/classes/sun/java2d/pisces/Dasher.java ! src/share/classes/sun/java2d/pisces/Helpers.java ! src/share/classes/sun/java2d/pisces/PiscesCache.java ! src/share/classes/sun/java2d/pisces/PiscesRenderingEngine.java ! src/share/classes/sun/java2d/pisces/Renderer.java ! src/share/classes/sun/java2d/pisces/Stroker.java ! src/share/classes/sun/java2d/pisces/TransformingPathConsumer2D.java ! src/share/classes/sun/jkernel/DownloadManager.java ! src/share/classes/sun/jvmstat/monitor/AbstractMonitor.java ! src/share/classes/sun/jvmstat/monitor/Monitor.java ! src/share/classes/sun/jvmstat/monitor/Units.java ! src/share/classes/sun/jvmstat/monitor/Variability.java ! src/share/classes/sun/jvmstat/perfdata/monitor/PerfByteArrayMonitor.java ! src/share/classes/sun/jvmstat/perfdata/monitor/PerfIntegerMonitor.java ! src/share/classes/sun/jvmstat/perfdata/monitor/PerfLongMonitor.java ! src/share/classes/sun/jvmstat/perfdata/monitor/PerfStringConstantMonitor.java ! src/share/classes/sun/jvmstat/perfdata/monitor/PerfStringMonitor.java ! src/share/classes/sun/jvmstat/perfdata/monitor/PerfStringVariableMonitor.java ! src/share/classes/sun/jvmstat/perfdata/monitor/v1_0/PerfDataBuffer.java ! src/share/classes/sun/jvmstat/perfdata/monitor/v2_0/PerfDataBuffer.java ! src/share/classes/sun/launcher/resources/launcher_de.properties ! src/share/classes/sun/launcher/resources/launcher_es.properties ! src/share/classes/sun/launcher/resources/launcher_fr.properties ! src/share/classes/sun/launcher/resources/launcher_it.properties ! src/share/classes/sun/launcher/resources/launcher_ja.properties ! src/share/classes/sun/launcher/resources/launcher_ko.properties ! src/share/classes/sun/launcher/resources/launcher_pt_BR.properties ! src/share/classes/sun/launcher/resources/launcher_sv.properties ! src/share/classes/sun/launcher/resources/launcher_zh_CN.properties ! src/share/classes/sun/launcher/resources/launcher_zh_TW.properties ! src/share/classes/sun/management/Flag.java ! src/share/classes/sun/management/resources/agent_de.properties ! src/share/classes/sun/management/resources/agent_es.properties ! src/share/classes/sun/management/resources/agent_fr.properties ! src/share/classes/sun/management/resources/agent_it.properties ! src/share/classes/sun/management/resources/agent_ja.properties ! src/share/classes/sun/management/resources/agent_ko.properties ! src/share/classes/sun/management/resources/agent_pt_BR.properties ! src/share/classes/sun/management/resources/agent_sv.properties ! src/share/classes/sun/management/resources/agent_zh_CN.properties ! src/share/classes/sun/management/resources/agent_zh_TW.properties ! src/share/classes/sun/misc/BootClassLoaderHook.java ! src/share/classes/sun/misc/Launcher.java ! src/share/classes/sun/misc/VM.java ! src/share/classes/sun/net/InetAddressCachePolicy.java ! src/share/classes/sun/net/NetworkClient.java ! src/share/classes/sun/net/ftp/impl/FtpClient.java ! src/share/classes/sun/net/httpserver/ChunkedInputStream.java ! src/share/classes/sun/net/httpserver/Event.java ! src/share/classes/sun/net/httpserver/ExchangeImpl.java ! src/share/classes/sun/net/httpserver/FixedLengthInputStream.java ! src/share/classes/sun/net/httpserver/HttpConnection.java ! src/share/classes/sun/net/httpserver/Request.java ! src/share/classes/sun/net/httpserver/SSLStreams.java ! src/share/classes/sun/net/httpserver/ServerConfig.java ! src/share/classes/sun/net/httpserver/ServerImpl.java ! src/share/classes/sun/net/www/MessageHeader.java ! src/share/classes/sun/net/www/MimeTable.java ! src/share/classes/sun/net/www/http/HttpClient.java ! src/share/classes/sun/net/www/protocol/file/FileURLConnection.java ! src/share/classes/sun/net/www/protocol/ftp/FtpURLConnection.java ! src/share/classes/sun/net/www/protocol/http/AuthenticationInfo.java ! src/share/classes/sun/net/www/protocol/http/BasicAuthentication.java ! src/share/classes/sun/nio/ch/AsynchronousSocketChannelImpl.java ! src/share/classes/sun/nio/ch/CompletedFuture.java ! src/share/classes/sun/nio/ch/DatagramChannelImpl.java ! src/share/classes/sun/nio/ch/DatagramSocketAdaptor.java ! src/share/classes/sun/nio/ch/FileChannelImpl.java ! src/share/classes/sun/nio/ch/FileDispatcher.java ! src/share/classes/sun/nio/ch/IOUtil.java ! src/share/classes/sun/nio/ch/IOVecWrapper.java ! src/share/classes/sun/nio/ch/Interruptible.java ! src/share/classes/sun/nio/ch/ServerSocketAdaptor.java ! src/share/classes/sun/nio/ch/ServerSocketChannelImpl.java ! src/share/classes/sun/nio/ch/SocketAdaptor.java ! src/share/classes/sun/nio/ch/SocketChannelImpl.java ! src/share/classes/sun/nio/ch/Util.java ! src/share/classes/sun/nio/cs/AbstractCharsetProvider.java ! src/share/classes/sun/nio/cs/UTF_32Coder.java ! src/share/classes/sun/nio/cs/UTF_8.java ! src/share/classes/sun/nio/cs/UnicodeEncoder.java ! src/share/classes/sun/nio/cs/ext/Big5_HKSCS_2001.java ! src/share/classes/sun/nio/cs/ext/Big5_Solaris.java ! src/share/classes/sun/nio/cs/ext/DoubleByte.java ! src/share/classes/sun/nio/cs/ext/EUC_JP.java ! src/share/classes/sun/nio/cs/ext/EUC_JP_LINUX.java ! src/share/classes/sun/nio/cs/ext/EUC_JP_Open.java ! src/share/classes/sun/nio/cs/ext/EUC_TW.java ! src/share/classes/sun/nio/cs/ext/ExtendedCharsets.java ! src/share/classes/sun/nio/cs/ext/GB18030.java ! src/share/classes/sun/nio/cs/ext/IBM33722.java ! src/share/classes/sun/nio/cs/ext/IBM964.java ! src/share/classes/sun/nio/cs/ext/ISO2022.java ! src/share/classes/sun/nio/cs/ext/JISAutoDetect.java ! src/share/classes/sun/nio/cs/ext/MS950_HKSCS_XP.java ! src/share/classes/sun/nio/cs/ext/PCK.java ! src/share/classes/sun/nio/cs/ext/SJIS.java ! src/share/classes/sun/nio/fs/AbstractPath.java ! src/share/classes/sun/nio/fs/AbstractWatchKey.java ! src/share/classes/sun/rmi/registry/resources/rmiregistry_pt_BR.properties ! src/share/classes/sun/rmi/rmic/BatchEnvironment.java ! src/share/classes/sun/rmi/rmic/resources/rmic.properties ! src/share/classes/sun/rmi/rmic/resources/rmic_ja.properties ! src/share/classes/sun/rmi/rmic/resources/rmic_zh_CN.properties ! src/share/classes/sun/rmi/server/resources/rmid_pt_BR.properties ! src/share/classes/sun/security/jca/Providers.java ! src/share/classes/sun/security/jgss/krb5/InitialToken.java ! src/share/classes/sun/security/pkcs11/P11ECKeyFactory.java ! src/share/classes/sun/security/pkcs11/wrapper/PKCS11Exception.java ! src/share/classes/sun/security/provider/JavaKeyStore.java ! src/share/classes/sun/security/ssl/Krb5Helper.java ! src/share/classes/sun/security/ssl/Krb5Proxy.java ! src/share/classes/sun/security/ssl/krb5/Krb5ProxyImpl.java ! src/share/classes/sun/security/tools/JarSignerResources_ja.java ! src/share/classes/sun/security/tools/JarSignerResources_zh_CN.java ! src/share/classes/sun/security/util/AuthResources_de.java ! src/share/classes/sun/security/util/AuthResources_es.java ! src/share/classes/sun/security/util/AuthResources_fr.java ! src/share/classes/sun/security/util/AuthResources_it.java ! src/share/classes/sun/security/util/AuthResources_ja.java ! src/share/classes/sun/security/util/AuthResources_ko.java ! src/share/classes/sun/security/util/AuthResources_pt_BR.java ! src/share/classes/sun/security/util/AuthResources_sv.java ! src/share/classes/sun/security/util/AuthResources_zh_CN.java ! src/share/classes/sun/security/util/AuthResources_zh_TW.java ! src/share/classes/sun/security/util/Resources_fr.java ! src/share/classes/sun/security/util/Resources_it.java ! src/share/classes/sun/security/util/Resources_pt_BR.java ! src/share/classes/sun/security/x509/X509Key.java ! src/share/classes/sun/swing/SwingUtilities2.java ! src/share/classes/sun/swing/plaf/synth/SynthFileChooserUIImpl.java ! src/share/classes/sun/swing/table/DefaultTableCellHeaderRenderer.java ! src/share/classes/sun/text/resources/FormatData_be.java ! src/share/classes/sun/text/resources/FormatData_fr.java ! src/share/classes/sun/text/resources/FormatData_fr_BE.java ! src/share/classes/sun/text/resources/FormatData_fr_CA.java ! src/share/classes/sun/text/resources/FormatData_fr_CH.java ! src/share/classes/sun/tools/jar/Main.java ! src/share/classes/sun/tools/jar/resources/jar_pt_BR.properties ! src/share/classes/sun/tools/jconsole/resources/JConsoleResources.java ! src/share/classes/sun/tools/jconsole/resources/JConsoleResources_ja.java ! src/share/classes/sun/tools/jconsole/resources/JConsoleResources_zh_CN.java ! src/share/classes/sun/tools/jstat/Arguments.java ! src/share/classes/sun/tools/jstat/ExpressionResolver.java ! src/share/classes/sun/tools/jstat/JStatLogger.java ! src/share/classes/sun/tools/jstat/Jstat.java ! src/share/classes/sun/tools/jstat/OptionFinder.java ! src/share/classes/sun/tools/jstat/OptionLister.java ! src/share/classes/sun/tools/jstat/resources/jstat_options ! src/share/classes/sun/tools/native2ascii/resources/MsgNative2ascii.java ! src/share/classes/sun/util/BuddhistCalendar.java ! src/share/classes/sun/util/calendar/ZoneInfoFile.java ! src/share/classes/sun/util/logging/PlatformLogger.java ! src/share/classes/sun/util/logging/resources/logging_pt_BR.properties ! src/share/classes/sun/util/resources/CalendarData_hu.properties ! src/share/classes/sun/util/resources/CurrencyNames_uk_UA.properties ! src/share/classes/sun/util/resources/LocaleNames.properties ! src/share/classes/sun/util/resources/LocaleNames_nl.properties ! src/share/classes/sun/util/resources/LocaleNames_zh.properties ! src/share/classes/sun/util/resources/LocaleNames_zh_TW.properties ! src/share/demo/java2d/J2DBench/src/j2dbench/J2DBench.java ! src/share/demo/java2d/J2DBench/src/j2dbench/Option.java ! src/share/demo/java2d/J2DBench/src/j2dbench/Result.java ! src/share/demo/java2d/J2DBench/src/j2dbench/report/J2DAnalyzer.java ! src/share/demo/java2d/J2DBench/src/j2dbench/tests/GraphicsTests.java ! src/share/demo/java2d/J2DBench/src/j2dbench/tests/text/TextTests.java ! src/share/demo/jvmti/hprof/sample.makefile.txt ! src/share/javavm/export/classfile_constants.h ! src/share/native/com/sun/java/util/jar/pack/bytes.cpp ! src/share/native/com/sun/java/util/jar/pack/unpack.cpp ! src/share/native/common/check_code.c ! src/share/native/common/jdk_util.c ! src/share/native/common/jni_util.c ! src/share/native/java/io/RandomAccessFile.c ! src/share/native/java/io/io_util.c ! src/share/native/java/io/io_util.h ! src/share/native/java/lang/Class.c ! src/share/native/java/lang/ClassLoader.c ! src/share/native/java/lang/System.c ! src/share/native/java/lang/fdlibm/include/fdlibm.h ! src/share/native/java/lang/java_props.h ! src/share/native/java/lang/reflect/Proxy.c ! src/share/native/java/net/net_util.c ! src/share/native/java/nio/Bits.c ! src/share/native/java/util/zip/Deflater.c ! src/share/native/java/util/zip/Inflater.c ! src/share/native/java/util/zip/ZipFile.c ! src/share/native/java/util/zip/zip_util.c ! src/share/native/java/util/zip/zip_util.h ! src/share/native/sun/awt/image/BufImgSurfaceData.c ! src/share/native/sun/awt/image/jpeg/imageioJPEG.c ! src/share/native/sun/awt/medialib/awt_ImagingLib.c ! src/share/native/sun/awt/medialib/mlib_ImageLookUp_64.c ! src/share/native/sun/awt/medialib/safe_alloc.h ! src/share/native/sun/awt/splashscreen/splashscreen_gif.c ! src/share/native/sun/awt/splashscreen/splashscreen_png.c ! src/share/native/sun/font/AccelGlyphCache.c ! src/share/native/sun/font/fontscalerdefs.h ! src/share/native/sun/font/freetypeScaler.c ! src/share/native/sun/font/sunFont.c ! src/share/native/sun/java2d/cmm/lcms/LCMS.c ! src/share/native/sun/java2d/loops/Any3Byte.c ! src/share/native/sun/java2d/loops/Any4Byte.c ! src/share/native/sun/java2d/loops/AnyByte.c ! src/share/native/sun/java2d/loops/AnyInt.c ! src/share/native/sun/java2d/loops/AnyShort.c ! src/share/native/sun/java2d/loops/DrawParallelogram.c ! src/share/native/sun/java2d/loops/FillParallelogram.c ! src/share/native/sun/java2d/loops/GraphicsPrimitiveMgr.c ! src/share/native/sun/java2d/loops/GraphicsPrimitiveMgr.h ! src/share/native/sun/java2d/loops/LoopMacros.h ! src/share/native/sun/java2d/loops/ProcessPath.c ! src/share/native/sun/java2d/opengl/OGLTextRenderer.c ! src/share/native/sun/management/Flag.c ! src/share/native/sun/misc/VM.c ! src/share/native/sun/misc/VMSupport.c ! src/share/native/sun/security/ec/ECC_JNI.cpp ! src/share/sample/nio/file/Chmod.java ! src/share/sample/nio/file/Copy.java ! src/share/sample/nio/file/WatchDir.java ! src/solaris/bin/jexec.c ! src/solaris/classes/java/io/UnixFileSystem.java ! src/solaris/classes/java/lang/ProcessImpl.java ! src/solaris/classes/java/lang/UNIXProcess.java.linux ! src/solaris/classes/java/lang/UNIXProcess.java.solaris ! src/solaris/classes/sun/awt/UNIXToolkit.java ! src/solaris/classes/sun/awt/X11/InfoWindow.java ! src/solaris/classes/sun/awt/X11/XBaseWindow.java ! src/solaris/classes/sun/awt/X11/XDecoratedPeer.java ! src/solaris/classes/sun/awt/X11/XEmbeddedFrame.java ! src/solaris/classes/sun/awt/X11/XEmbeddedFramePeer.java ! src/solaris/classes/sun/awt/X11/XFileDialogPeer.java ! src/solaris/classes/sun/awt/X11/XFramePeer.java ! src/solaris/classes/sun/awt/X11/XRobotPeer.java ! src/solaris/classes/sun/awt/X11/XTextAreaPeer.java ! src/solaris/classes/sun/awt/X11/XTrayIconPeer.java ! src/solaris/classes/sun/awt/X11/XWindow.java ! src/solaris/classes/sun/awt/X11/XWindowPeer.java ! src/solaris/classes/sun/awt/X11GraphicsDevice.java ! src/solaris/classes/sun/awt/X11GraphicsEnvironment.java ! src/solaris/classes/sun/awt/X11InputMethod.java ! src/solaris/classes/sun/awt/fontconfigs/linux.fontconfig.Fedora.properties ! src/solaris/classes/sun/awt/fontconfigs/linux.fontconfig.Ubuntu.properties ! src/solaris/classes/sun/awt/fontconfigs/solaris.fontconfig.properties ! src/solaris/classes/sun/awt/motif/MToolkit.java ! src/solaris/classes/sun/java2d/UnixSurfaceManagerFactory.java ! src/solaris/classes/sun/java2d/x11/X11SurfaceData.java ! src/solaris/classes/sun/net/NetHooks.java ! src/solaris/classes/sun/net/sdp/SdpProvider.java ! src/solaris/classes/sun/nio/ch/DevPollSelectorImpl.java ! src/solaris/classes/sun/nio/ch/EPollSelectorImpl.java ! src/solaris/classes/sun/nio/ch/FileDispatcherImpl.java ! src/solaris/classes/sun/nio/ch/InheritedChannel.java ! src/solaris/classes/sun/nio/ch/LinuxAsynchronousChannelProvider.java ! src/solaris/classes/sun/nio/ch/PipeImpl.java ! src/solaris/classes/sun/nio/ch/PollSelectorImpl.java ! src/solaris/classes/sun/nio/ch/SctpChannelImpl.java ! src/solaris/classes/sun/nio/ch/SctpMultiChannelImpl.java ! src/solaris/classes/sun/nio/ch/SctpNet.java ! src/solaris/classes/sun/nio/ch/SctpServerChannelImpl.java ! src/solaris/classes/sun/nio/ch/SolarisAsynchronousChannelProvider.java ! src/solaris/classes/sun/nio/cs/ext/COMPOUND_TEXT_Encoder.java ! src/solaris/classes/sun/nio/cs/ext/CompoundTextSupport.java ! src/solaris/classes/sun/nio/fs/LinuxFileStore.java ! src/solaris/classes/sun/nio/fs/SolarisFileStore.java ! src/solaris/classes/sun/nio/fs/UnixDirectoryStream.java ! src/solaris/classes/sun/nio/fs/UnixFileStore.java ! src/solaris/classes/sun/nio/fs/UnixPath.java ! src/solaris/classes/sun/nio/fs/UnixSecureDirectoryStream.java ! src/solaris/classes/sun/tools/attach/LinuxVirtualMachine.java ! src/solaris/classes/sun/tools/attach/SolarisVirtualMachine.java ! src/solaris/demo/jni/Poller/Poller.c ! src/solaris/native/java/io/FileOutputStream_md.c ! src/solaris/native/java/io/UnixFileSystem_md.c ! src/solaris/native/java/io/canonicalize_md.c ! src/solaris/native/java/io/io_util_md.c ! src/solaris/native/java/io/io_util_md.h ! src/solaris/native/java/lang/java_props_md.c ! src/solaris/native/java/lang/locale_str.h ! src/solaris/native/java/net/Inet4AddressImpl.c ! src/solaris/native/java/net/Inet6AddressImpl.c ! src/solaris/native/java/net/NetworkInterface.c ! src/solaris/native/java/net/PlainDatagramSocketImpl.c ! src/solaris/native/java/net/PlainSocketImpl.c ! src/solaris/native/java/net/net_util_md.c ! src/solaris/native/java/net/net_util_md.h ! src/solaris/native/java/nio/MappedByteBuffer.c ! src/solaris/native/sun/awt/awt.h ! src/solaris/native/sun/awt/awt_DrawingSurface.c ! src/solaris/native/sun/awt/awt_InputMethod.c ! src/solaris/native/sun/awt/awt_Robot.c ! src/solaris/native/sun/awt/awt_UNIXToolkit.c ! src/solaris/native/sun/awt/medialib/mlib_v_ImageLookUpS32S16Func.c ! src/solaris/native/sun/awt/medialib/mlib_v_ImageLookUpS32U16Func.c ! src/solaris/native/sun/awt/medialib/mlib_v_ImageLookUpSIS32S16Func.c ! src/solaris/native/sun/awt/medialib/mlib_v_ImageLookUpSIS32U16Func.c ! src/solaris/native/sun/awt/swing_GTKStyle.c ! src/solaris/native/sun/java2d/loops/java2d_Mlib.c ! src/solaris/native/sun/java2d/loops/vis_FuncArray.c ! src/solaris/native/sun/java2d/opengl/GLXSurfaceData.c ! src/solaris/native/sun/java2d/x11/X11SurfaceData.c ! src/solaris/native/sun/java2d/x11/X11SurfaceData.h ! src/solaris/native/sun/net/sdp/SdpSupport.c ! src/solaris/native/sun/net/spi/DefaultProxySelector.c ! src/solaris/native/sun/nio/ch/IOUtil.c ! src/solaris/native/sun/nio/ch/Net.c ! src/solaris/native/sun/nio/ch/SctpNet.c ! src/solaris/native/sun/nio/ch/SocketChannelImpl.c ! src/solaris/native/sun/nio/ch/UnixAsynchronousSocketChannelImpl.c ! src/solaris/native/sun/xawt/XlibWrapper.c ! src/solaris/native/sun/xawt/awt_Desktop.c ! src/windows/classes/java/io/Win32FileSystem.java ! src/windows/classes/java/lang/ProcessImpl.java ! src/windows/classes/sun/awt/Win32GraphicsDevice.java ! src/windows/classes/sun/awt/shell/Win32ShellFolderManager2.java ! src/windows/classes/sun/awt/windows/WComponentPeer.java ! src/windows/classes/sun/awt/windows/WEmbeddedFrame.java ! src/windows/classes/sun/awt/windows/WFileDialogPeer.java ! src/windows/classes/sun/awt/windows/WFramePeer.java ! src/windows/classes/sun/awt/windows/WInputMethod.java ! src/windows/classes/sun/awt/windows/WPrintDialogPeer.java ! src/windows/classes/sun/awt/windows/WToolkit.java ! src/windows/classes/sun/awt/windows/WWindowPeer.java ! src/windows/classes/sun/awt/windows/fontconfig.properties ! src/windows/classes/sun/java2d/d3d/D3DScreenUpdateManager.java ! src/windows/classes/sun/nio/ch/FileDispatcherImpl.java ! src/windows/classes/sun/nio/ch/WindowsAsynchronousChannelProvider.java ! src/windows/classes/sun/nio/ch/WindowsAsynchronousFileChannelImpl.java ! src/windows/classes/sun/nio/ch/WindowsSelectorImpl.java ! src/windows/classes/sun/nio/fs/WindowsChannelFactory.java ! src/windows/classes/sun/nio/fs/WindowsDirectoryStream.java ! src/windows/native/com/sun/media/sound/PLATFORM_API_WinOS_DirectSound.cpp ! src/windows/native/common/jni_util_md.c ! src/windows/native/java/io/FileOutputStream_md.c ! src/windows/native/java/io/WinNTFileSystem_md.c ! src/windows/native/java/io/io_util_md.c ! src/windows/native/java/io/io_util_md.h ! src/windows/native/java/lang/ProcessImpl_md.c ! src/windows/native/java/lang/java_props_md.c ! src/windows/native/java/net/NetworkInterface_winXP.c ! src/windows/native/java/net/TwoStacksPlainDatagramSocketImpl.c ! src/windows/native/java/net/net_util_md.h ! src/windows/native/java/nio/MappedByteBuffer.c ! src/windows/native/java/util/TimeZone_md.c ! src/windows/native/sun/font/fontpath.c ! src/windows/native/sun/java2d/d3d/D3DGraphicsDevice.cpp ! src/windows/native/sun/java2d/d3d/D3DPipelineManager.cpp ! src/windows/native/sun/java2d/d3d/D3DPipelineManager.h ! src/windows/native/sun/java2d/opengl/WGLSurfaceData.c ! src/windows/native/sun/java2d/windows/GDIWindowSurfaceData.cpp ! src/windows/native/sun/java2d/windows/GDIWindowSurfaceData.h ! src/windows/native/sun/java2d/windows/WindowsFlags.cpp ! src/windows/native/sun/jkernel/DownloadDialog.cpp ! src/windows/native/sun/jkernel/DownloadHelper.cpp ! src/windows/native/sun/jkernel/kernel.rc ! src/windows/native/sun/jkernel/kernel_pt_BR.rc ! src/windows/native/sun/jkernel/stdafx.h ! src/windows/native/sun/net/spi/DefaultProxySelector.c ! src/windows/native/sun/nio/ch/DatagramChannelImpl.c ! src/windows/native/sun/nio/ch/FileDispatcherImpl.c ! src/windows/native/sun/nio/ch/Net.c ! src/windows/native/sun/nio/ch/ServerSocketChannelImpl.c ! src/windows/native/sun/nio/ch/SocketChannelImpl.c ! src/windows/native/sun/nio/ch/SocketDispatcher.c ! src/windows/native/sun/nio/ch/WindowsAsynchronousFileChannelImpl.c ! src/windows/native/sun/nio/ch/WindowsSelectorImpl.c ! src/windows/native/sun/nio/ch/nio_util.h ! src/windows/native/sun/windows/WPrinterJob.cpp ! src/windows/native/sun/windows/awt.h ! src/windows/native/sun/windows/awt_BitmapUtil.cpp ! src/windows/native/sun/windows/awt_Choice.cpp ! src/windows/native/sun/windows/awt_Choice.h ! src/windows/native/sun/windows/awt_DataTransferer.cpp ! src/windows/native/sun/windows/awt_Desktop.cpp ! src/windows/native/sun/windows/awt_DesktopProperties.cpp ! src/windows/native/sun/windows/awt_Dialog.cpp ! src/windows/native/sun/windows/awt_DnDDS.cpp ! src/windows/native/sun/windows/awt_DrawingSurface.h ! src/windows/native/sun/windows/awt_FileDialog.cpp ! src/windows/native/sun/windows/awt_FileDialog.h ! src/windows/native/sun/windows/awt_Font.cpp ! src/windows/native/sun/windows/awt_InputMethod.cpp ! src/windows/native/sun/windows/awt_MenuItem.cpp ! src/windows/native/sun/windows/awt_PrintJob.cpp ! src/windows/native/sun/windows/awt_Robot.cpp ! src/windows/native/sun/windows/awt_TextArea.cpp ! src/windows/native/sun/windows/awt_TextComponent.h ! src/windows/native/sun/windows/awt_TextField.cpp ! src/windows/native/sun/windows/awt_TextField.h ! src/windows/native/sun/windows/awt_Toolkit.cpp ! src/windows/native/sun/windows/awt_Toolkit.h ! src/windows/native/sun/windows/awt_Win32GraphicsEnv.cpp ! src/windows/native/sun/windows/awt_Window.cpp ! src/windows/native/sun/windows/awtmsg.h ! test/com/sun/crypto/provider/KeyFactory/TestProviderLeak.java ! test/com/sun/crypto/provider/TLS/TestPremaster.java ! test/com/sun/crypto/provider/TLS/Utils.java ! test/com/sun/java/swing/plaf/gtk/Test6635110.java ! test/com/sun/jdi/PopAndInvokeTest.java ! test/com/sun/jdi/connect/spi/JdiLoadedByCustomLoader.sh ! test/com/sun/net/httpserver/Test.java ! test/com/sun/net/httpserver/Test1.java ! test/com/sun/net/httpserver/Test11.java ! test/com/sun/net/httpserver/Test12.java ! test/com/sun/net/httpserver/Test13.java ! test/com/sun/net/httpserver/Test6a.java ! test/com/sun/net/httpserver/Test7a.java ! test/com/sun/net/httpserver/Test8a.java ! test/com/sun/net/httpserver/Test9.java ! test/com/sun/net/httpserver/Test9a.java ! test/com/sun/net/httpserver/bugs/6725892/Test.java ! test/com/sun/net/httpserver/bugs/B6361557.java ! test/com/sun/net/httpserver/bugs/B6373555.java ! test/com/sun/net/httpserver/bugs/B6401598.java ! test/com/sun/nio/sctp/SctpChannel/Connect.java ! test/com/sun/nio/sctp/SctpChannel/Send.java ! test/com/sun/nio/sctp/SctpChannel/SocketOptionTests.java ! test/com/sun/nio/sctp/SctpMultiChannel/Send.java ! test/com/sun/servicetag/FindServiceTags.java ! test/com/sun/servicetag/JavaServiceTagTest1.java ! test/com/sun/servicetag/SystemRegistryTest.java ! test/com/sun/servicetag/Util.java ! test/com/sun/tools/attach/ProviderTests.sh ! test/com/sun/tracing/BasicFunctionality.java ! test/java/awt/EventDispatchThread/LoopRobustness/LoopRobustness.java ! test/java/awt/EventQueue/PushPopDeadlock2/PushPopTest.java ! test/java/awt/FileDialog/FilenameFilterTest/FilenameFilterTest.java ! test/java/awt/TextArea/UsingWithMouse/SelectionAutoscrollTest.java ! test/java/awt/TextField/ScrollSelectionTest/ScrollSelectionTest.java ! test/java/awt/event/MouseEvent/SpuriousExitEnter/SpuriousExitEnter_3.java ! test/java/awt/regtesthelpers/process/ProcessCommunicator.java ! test/java/beans/Beans/Test4080522.java ! test/java/beans/EventHandler/Test6277246.java ! test/java/beans/EventHandler/Test6277266.java ! test/java/beans/Introspector/Test6277246.java ! test/java/beans/XMLEncoder/java_awt_GridBagConstraints.java ! test/java/io/BufferedReader/BigMark.java ! test/java/io/BufferedReader/ReadLineSync.java ! test/java/io/DataInputStream/OpsAfterClose.java ! test/java/io/DataInputStream/ReadFully.java ! test/java/io/File/Basic.java ! test/java/io/File/DeleteOnExit.java ! test/java/io/File/DeleteOnExitNPE.java ! test/java/io/File/IsHidden.java ! test/java/io/File/SetAccess.java ! test/java/io/File/SetReadOnly.java ! test/java/io/FileInputStream/LeadingSlash.java ! test/java/io/InputStream/OpsAfterClose.java ! test/java/io/InputStream/ReadParams.java ! test/java/io/InputStreamReader/GrowAfterEOF.java ! test/java/io/ObjectInputStream/ResolveProxyClass.java ! test/java/io/RandomAccessFile/EOF.java ! test/java/io/RandomAccessFile/ParameterCheck.java ! test/java/io/RandomAccessFile/ReadLine.java ! test/java/io/RandomAccessFile/Seek.java ! test/java/io/RandomAccessFile/WriteBytesChars.java ! test/java/io/RandomAccessFile/WriteUTF.java ! test/java/io/RandomAccessFile/skipBytes/SkipBytes.java ! test/java/io/Reader/Skip.java ! test/java/io/Reader/SkipNegative.java ! test/java/io/Serializable/ClassCastExceptionDetail/Read.java ! test/java/io/Serializable/auditStreamSubclass/AuditStreamSubclass.java ! test/java/io/Serializable/backRefCNFException/Read.java ! test/java/io/Serializable/checkModifiers/CheckModifiers.java ! test/java/io/Serializable/classDescFlagConflict/Read.java ! test/java/io/Serializable/classDescHooks/ClassDescHooks.java ! test/java/io/Serializable/duplicateSerialFields/Test.java ! test/java/io/Serializable/enum/badResolve/Read.java ! test/java/io/Serializable/enum/constantSubclasses/Read.java ! test/java/io/Serializable/enum/missingConstant/Read.java ! test/java/io/Serializable/evolution/RenamePackage/run.sh ! test/java/io/Serializable/fieldTypeString/Read.java ! test/java/io/Serializable/illegalHandle/Test.java ! test/java/io/Serializable/longString/LongString.java ! test/java/io/Serializable/oldTests/AnnotateClass.java ! test/java/io/Serializable/oldTests/ArrayFields.java ! test/java/io/Serializable/oldTests/ArraysOfArrays.java ! test/java/io/Serializable/oldTests/BinaryTree.java ! test/java/io/Serializable/oldTests/CircularList.java ! test/java/io/Serializable/oldTests/SimpleArrays.java ! test/java/io/Serializable/oldTests/WritePrimitive.java ! test/java/io/Serializable/packageAccess/Test.java ! test/java/io/Serializable/parents/EvolvedClass.java ! test/java/io/Serializable/parents/OriginalClass.java ! test/java/io/Serializable/proxy/Basic.java ! test/java/io/Serializable/proxy/skipMissing/Read.java ! test/java/io/Serializable/proxy/skipMissing/Write.java ! test/java/io/Serializable/readObjectNoData/Read.java ! test/java/io/Serializable/serialver/classpath/run.sh ! test/java/io/Serializable/serialver/nested/run.sh ! test/java/io/Serializable/skipWriteObject/Read.java ! test/java/io/Serializable/skippedObjCNFException/Read.java ! test/java/io/Serializable/stopCustomDeserialization/Read.java ! test/java/io/Serializable/unresolvedClassDesc/Read.java ! test/java/io/Serializable/unshared/Read.java ! test/java/io/Serializable/wrongReturnTypes/Read.java ! test/java/io/StreamTokenizer/Comment.java ! test/java/io/pathNames/GeneralWin32.java ! test/java/io/readBytes/ReadBytesBounds.java ! test/java/lang/ClassLoader/UninitializedParent.java ! test/java/lang/ClassLoader/deadlock/TestCrossDelegate.sh ! test/java/lang/ClassLoader/deadlock/TestOneWayDelegate.sh ! test/java/lang/ClassLoader/defineClass/DefineClassByteBuffer.java ! test/java/lang/ClassLoader/findSystemClass/Loader.java ! test/java/lang/ProcessBuilder/Basic.java ! test/java/lang/Runtime/exec/ExecWithDir.java ! test/java/lang/String/Supplementary.java ! test/java/lang/StringBuffer/Supplementary.java ! test/java/lang/StringBuilder/Supplementary.java ! test/java/lang/StringCoding/CheckEncodings.sh ! test/java/lang/System/ExitFinalizersAndJIT.java ! test/java/lang/System/IgnoreNullSecurityManager.java ! test/java/lang/Thread/GenerifyStackTraces.java ! test/java/lang/Thread/StackTraces.java ! test/java/lang/annotation/ParameterAnnotations.java ! test/java/lang/management/ClassLoadingMXBean/LoadCounts.java ! test/java/lang/management/ManagementFactory/MXBeanProxyTest.java ! test/java/lang/management/MemoryMXBean/CollectionUsageThreshold.java ! test/java/lang/management/MemoryMXBean/CollectionUsageThresholdConcMarkSweepGC.sh ! test/java/lang/management/MemoryMXBean/LowMemoryTest.java ! test/java/lang/management/MemoryMXBean/MemoryManagement.java ! test/java/lang/management/MemoryMXBean/Pending.java ! test/java/lang/management/MemoryMXBean/ResetPeakMemoryUsage.java ! test/java/lang/management/MemoryPoolMXBean/ThresholdTest.java ! test/java/lang/management/RuntimeMXBean/UpTime.java ! test/java/lang/management/ThreadMXBean/AllThreadIds.java ! test/java/lang/management/ThreadMXBean/DisableTest.java ! test/java/lang/management/ThreadMXBean/EnableTest.java ! test/java/lang/management/ThreadMXBean/FindDeadlocks.java ! test/java/lang/management/ThreadMXBean/FindMonitorDeadlock.java ! test/java/lang/management/ThreadMXBean/Locks.java ! test/java/lang/reflect/Proxy/Boxing.java ! test/java/lang/reflect/Proxy/ClassRestrictions.java ! test/java/lang/reflect/Proxy/returnTypes/Test.java ! test/java/net/Authenticator/B4769350.java ! test/java/net/BindException/Test.java ! test/java/net/CookieHandler/CookieHandlerTest.java ! test/java/net/CookieHandler/TestHttpCookie.java ! test/java/net/DatagramSocket/DatagramTimeout.java ! test/java/net/DatagramSocket/SendSize.java ! test/java/net/Inet6Address/B6214234.java ! test/java/net/Inet6Address/B6558853.java ! test/java/net/Inet6Address/serialize/Serialize.java ! test/java/net/InetAddress/CheckJNI.java ! test/java/net/MulticastSocket/NoLoopbackPackets.java ! test/java/net/MulticastSocket/SetOutgoingIf.java ! test/java/net/ProxySelector/B6737819.java ! test/java/net/ResponseCache/B6181108.java ! test/java/net/ResponseCache/ResponseCacheTest.java ! test/java/net/ResponseCache/getResponseCode.java ! test/java/net/ServerSocket/AcceptCauseFileDescriptorLeak.java ! test/java/net/Socket/CloseAvailable.java ! test/java/net/Socket/DeadlockTest.java ! test/java/net/Socket/LingerTest.java ! test/java/net/Socket/LinkLocal.java ! test/java/net/Socket/ProxyCons.java ! test/java/net/Socket/ReadTimeout.java ! test/java/net/Socket/SetReceiveBufferSize.java ! test/java/net/Socket/SetSoLinger.java ! test/java/net/Socket/ShutdownBoth.java ! test/java/net/Socket/SoTimeout.java ! test/java/net/Socket/Timeout.java ! test/java/net/Socket/UrgentDataTest.java ! test/java/net/Socket/asyncClose/BrokenPipe.java ! test/java/net/Socket/setReuseAddress/Restart.java ! test/java/net/SocketInputStream/SocketClosedException.java ! test/java/net/SocketInputStream/SocketTimeout.java ! test/java/net/URI/Test.java ! test/java/net/URL/GetContent.java ! test/java/net/URL/TestIPv6Addresses.java ! test/java/net/URLClassLoader/ClassLoad.java ! test/java/net/URLClassLoader/HttpTest.java ! test/java/net/URLClassLoader/closetest/CloseTest.java ! test/java/net/URLConnection/B5052093.java ! test/java/net/URLConnection/DisconnectAfterEOF.java ! test/java/net/URLConnection/HandleContentTypeWithAttrs.java ! test/java/net/URLConnection/HttpContinueStackOverflow.java ! test/java/net/URLConnection/Redirect307Test.java ! test/java/net/URLConnection/RedirectLimit.java ! test/java/net/URLConnection/ResendPostBody.java ! test/java/net/URLConnection/SetIfModifiedSince.java ! test/java/net/URLConnection/TimeoutTest.java ! test/java/net/URLConnection/URLConnectionHeaders.java ! test/java/net/URLConnection/ZeroContentLength.java ! test/java/net/URLConnection/contentHandler/UserContentHandler.java ! test/java/net/ipv6tests/B6521014.java ! test/java/net/ipv6tests/TcpTest.java ! test/java/net/ipv6tests/Tests.java ! test/java/nio/Buffer/StringCharBufferSliceTest.java ! test/java/nio/BufferPoolMXBean/Basic.java ! test/java/nio/MappedByteBuffer/Basic.java ! test/java/nio/MappedByteBuffer/Force.java ! test/java/nio/MappedByteBuffer/ZeroMap.java ! test/java/nio/channels/AsyncCloseAndInterrupt.java ! test/java/nio/channels/AsynchronousChannelGroup/Basic.java ! test/java/nio/channels/AsynchronousChannelGroup/GroupOfOne.java ! test/java/nio/channels/AsynchronousChannelGroup/Identity.java ! test/java/nio/channels/AsynchronousFileChannel/Basic.java ! test/java/nio/channels/AsynchronousFileChannel/Lock.java ! test/java/nio/channels/AsynchronousServerSocketChannel/Basic.java ! test/java/nio/channels/AsynchronousSocketChannel/Basic.java ! test/java/nio/channels/AsynchronousSocketChannel/Leaky.java ! test/java/nio/channels/Channels/Basic2.java ! test/java/nio/channels/Channels/Write.java ! test/java/nio/channels/DatagramChannel/AdaptDatagramSocket.java ! test/java/nio/channels/DatagramChannel/Connect.java ! test/java/nio/channels/DatagramChannel/EmptyBuffer.java ! test/java/nio/channels/DatagramChannel/NoSender.java ! test/java/nio/channels/DatagramChannel/ReceiveISA.java ! test/java/nio/channels/DatagramChannel/SRTest.java ! test/java/nio/channels/DatagramChannel/Sender.java ! test/java/nio/channels/DatagramChannel/SocketOptionTests.java ! test/java/nio/channels/FileChannel/Args.java ! test/java/nio/channels/FileChannel/ClosedChannelTransfer.java ! test/java/nio/channels/FileChannel/ExpandingMap.java ! test/java/nio/channels/FileChannel/Lock.java ! test/java/nio/channels/FileChannel/MapOverEnd.java ! test/java/nio/channels/FileChannel/MapReadOnly.java ! test/java/nio/channels/FileChannel/MapTest.java ! test/java/nio/channels/FileChannel/Mode.java ! test/java/nio/channels/FileChannel/Position.java ! test/java/nio/channels/FileChannel/Pread.java ! test/java/nio/channels/FileChannel/Pwrite.java ! test/java/nio/channels/FileChannel/Read.java ! test/java/nio/channels/FileChannel/ReadFull.java ! test/java/nio/channels/FileChannel/ReadToLimit.java ! test/java/nio/channels/FileChannel/ReleaseOnCloseDeadlock.java ! test/java/nio/channels/FileChannel/ScatteringRead.java ! test/java/nio/channels/FileChannel/Size.java ! test/java/nio/channels/FileChannel/Transfer.java ! test/java/nio/channels/FileChannel/TransferToChannel.java ! test/java/nio/channels/FileChannel/TransferToNonWritable.java ! test/java/nio/channels/FileChannel/Transfers.java ! test/java/nio/channels/FileChannel/Truncate.java ! test/java/nio/channels/FileChannel/TryLock.java ! test/java/nio/channels/FileChannel/Write.java ! test/java/nio/channels/Pipe/NonBlocking.java ! test/java/nio/channels/Pipe/SelectPipe.java ! test/java/nio/channels/SelectionKey/AtomicAttachTest.java ! test/java/nio/channels/Selector/BasicAccept.java ! test/java/nio/channels/Selector/BasicConnect.java ! test/java/nio/channels/Selector/ByteServer.java ! test/java/nio/channels/Selector/CheckLocking.java ! test/java/nio/channels/Selector/CloseInvalidatesKeys.java ! test/java/nio/channels/Selector/CloseThenRegister.java ! test/java/nio/channels/Selector/CloseWhenKeyIdle.java ! test/java/nio/channels/Selector/Connect.java ! test/java/nio/channels/Selector/ConnectWrite.java ! test/java/nio/channels/Selector/HelperSlowToDie.java ! test/java/nio/channels/Selector/KeysReady.java ! test/java/nio/channels/Selector/LotsOfChannels.java ! test/java/nio/channels/Selector/OpRead.java ! test/java/nio/channels/Selector/ReadAfterConnect.java ! test/java/nio/channels/Selector/RegAfterPreClose.java ! test/java/nio/channels/Selector/SelectAfterRead.java ! test/java/nio/channels/Selector/SelectAndCancel.java ! test/java/nio/channels/Selector/SelectWrite.java ! test/java/nio/channels/Selector/SelectorLimit.java ! test/java/nio/channels/Selector/SelectorTest.java ! test/java/nio/channels/Selector/WakeupNow.java ! test/java/nio/channels/Selector/WakeupOverflow.java ! test/java/nio/channels/Selector/WakeupSpeed.java ! test/java/nio/channels/Selector/lots_of_updates.sh ! test/java/nio/channels/ServerSocketChannel/SocketOptionTests.java ! test/java/nio/channels/SocketChannel/AdaptSocket.java ! test/java/nio/channels/SocketChannel/BigReadWrite.java ! test/java/nio/channels/SocketChannel/Bind.java ! test/java/nio/channels/SocketChannel/Close.java ! test/java/nio/channels/SocketChannel/CloseRegisteredChannel.java ! test/java/nio/channels/SocketChannel/CloseTimeoutChannel.java ! test/java/nio/channels/SocketChannel/IsConnectable.java ! test/java/nio/channels/SocketChannel/LocalAddress.java ! test/java/nio/channels/SocketChannel/OpenLeak.java ! test/java/nio/channels/SocketChannel/SocketInheritance.java ! test/java/nio/channels/SocketChannel/SocketOptionTests.java ! test/java/nio/channels/SocketChannel/Trivial.java ! test/java/nio/channels/SocketChannel/UnboundSocketTests.java ! test/java/nio/channels/SocketChannel/VectorIO.java ! test/java/nio/channels/SocketChannel/Write.java ! test/java/nio/channels/etc/Shadow.java ! test/java/nio/channels/spi/AsynchronousChannelProvider/Provider1.java ! test/java/nio/channels/spi/AsynchronousChannelProvider/Provider2.java ! test/java/nio/channels/spi/AsynchronousChannelProvider/custom_provider.sh ! test/java/nio/channels/spi/SelectorProvider/inheritedChannel/ClosedStreams.java ! test/java/nio/channels/spi/SelectorProvider/inheritedChannel/EchoTest.java ! test/java/nio/file/DirectoryStream/Basic.java ! test/java/nio/file/DirectoryStream/SecureDS.java ! test/java/nio/file/FileStore/Basic.java ! test/java/nio/file/Files/Misc.java ! test/java/nio/file/Files/PrintFileTree.java ! test/java/nio/file/Files/SkipSiblings.java ! test/java/nio/file/Files/TerminateWalk.java ! test/java/nio/file/Files/WalkWithSecurity.java ! test/java/nio/file/Files/walk_file_tree.sh ! test/java/nio/file/Path/CheckPermissions.java ! test/java/nio/file/Path/CopyAndMove.java ! test/java/nio/file/Path/InterruptCopy.java ! test/java/nio/file/Path/Misc.java ! test/java/nio/file/Path/PathOps.java ! test/java/nio/file/Path/delete_on_close.sh ! test/java/nio/file/TestUtil.java ! test/java/security/Provider/Turkish.java ! test/java/security/Security/ClassLoaderDeadlock/ClassLoaderDeadlock.sh ! test/java/util/Collection/BiggernYours.java ! test/java/util/Collection/IteratorAtEnd.java ! test/java/util/Collection/MOAT.java ! test/java/util/Collections/RacingCollections.java ! test/java/util/Deque/ChorusLine.java ! test/java/util/Formatter/Constructors.java ! test/java/util/Locale/PrintDefaultLocale.java ! test/java/util/Locale/data/deflocale.c ! test/java/util/Locale/data/deflocale.sh ! test/java/util/PluggableLocale/ExecTest.sh ! test/java/util/ResourceBundle/Bug4168625Test.java ! test/java/util/ResourceBundle/Bug6299235Test.sh ! test/java/util/ResourceBundle/Bug6359330.java ! test/java/util/ResourceBundle/Control/ExpirationTest.sh ! test/java/util/ResourceBundle/Test4300693.java ! test/java/util/ResourceBundle/TestBug4179766.java ! test/java/util/ServiceLoader/basic.sh ! test/java/util/concurrent/BlockingQueue/Interrupt.java ! test/java/util/concurrent/ConcurrentQueues/OfferRemoveLoops.java ! test/java/util/concurrent/CopyOnWriteArrayList/EqualsRace.java ! test/java/util/concurrent/CopyOnWriteArraySet/RacingCows.java ! test/java/util/concurrent/CyclicBarrier/Basic.java ! test/java/util/concurrent/Executors/AutoShutdown.java ! test/java/util/concurrent/Executors/Throws.java ! test/java/util/concurrent/FutureTask/BlockingTaskExecutor.java ! test/java/util/concurrent/FutureTask/Customized.java ! test/java/util/concurrent/ThreadPoolExecutor/ConfigChanges.java ! test/java/util/concurrent/ThreadPoolExecutor/Custom.java ! test/java/util/concurrent/ThreadPoolExecutor/ScheduledTickleService.java ! test/java/util/concurrent/ThreadPoolExecutor/ShutdownNowExecuteRace.java ! test/java/util/concurrent/ThreadPoolExecutor/ThrowingTasks.java ! test/java/util/concurrent/atomic/VMSupportsCS8.java ! test/java/util/concurrent/locks/Lock/FlakyMutex.java ! test/java/util/concurrent/locks/Lock/TimedAcquireLeak.java ! test/java/util/concurrent/locks/ReentrantReadWriteLock/Bug6571733.java ! test/java/util/regex/RegExTest.java ! test/java/util/zip/ZipFile/ReadZip.java ! test/javax/imageio/CachePremissionsTest/CachePermissionsTest.java ! test/javax/print/attribute/ServiceDialogTest.java ! test/javax/print/attribute/SidesPageRangesTest.java ! test/javax/script/ProviderTest.sh ! test/javax/sound/midi/Gervill/AudioFloatConverter/ToFloatArray.java ! test/javax/sound/midi/Gervill/SoftAudioSynthesizer/DummySourceDataLine.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/DummySourceDataLine.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/LoadAllInstruments.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/LoadInstrument.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/LoadInstruments.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/RemapInstrument.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/UnloadAllInstruments.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/UnloadInstrument.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/UnloadInstruments.java ! test/javax/swing/AbstractButton/6711682/bug6711682.java ! test/javax/swing/JLayer/SerializationTest/SerializationTest.java ! test/javax/swing/JTextArea/Test6593649.java ! test/javax/swing/plaf/nimbus/Test6919629.java ! test/javax/swing/system/6799345/TestShutdown.java ! test/sun/java2d/DirectX/OnScreenRenderingResizeTest/OnScreenRenderingResizeTest.java ! test/sun/java2d/GdiRendering/InsetClipping.java ! test/sun/java2d/SunGraphics2D/DrawImageBilinear.java ! test/sun/java2d/SunGraphics2D/SourceClippingBlitTest/SourceClippingBlitTest.java ! test/sun/java2d/X11SurfaceData/SharedMemoryPixmapsTest/SharedMemoryPixmapsTest.java ! test/sun/java2d/pipe/MutableColorTest/MutableColorTest.java ! test/sun/jvmstat/monitor/MonitoredVm/MonitorVmStartTerminate.sh ! test/sun/jvmstat/testlibrary/utils.sh ! test/sun/management/jmxremote/bootstrap/GeneratePropertyPassword.sh ! test/sun/misc/BootClassLoaderHook/TestHook.java ! test/sun/net/ftp/FtpGetContent.java ! test/sun/net/ftp/FtpURL.java ! test/sun/net/sdp/ProbeIB.java ! test/sun/net/sdp/sanity.sh ! test/sun/net/www/http/ChunkedInputStream/ChunkedEncodingTest.java ! test/sun/net/www/http/ChunkedInputStream/ChunkedEncodingWithProgressMonitorTest.java ! test/sun/net/www/http/ChunkedOutputStream/Test.java ! test/sun/net/www/http/HttpClient/B6726695.java ! test/sun/net/www/http/HttpClient/MultiThreadTest.java ! test/sun/net/www/http/HttpClient/ProxyTest.java ! test/sun/net/www/http/KeepAliveCache/B5045306.java ! test/sun/net/www/http/KeepAliveCache/KeepAliveTimerThread.java ! test/sun/net/www/http/KeepAliveStream/KeepAliveStreamCloseWithWrongContentLength.java ! test/sun/net/www/httptest/HttpServer.java ! test/sun/net/www/protocol/http/ChunkedErrorStream.java ! test/sun/net/www/protocol/http/DigestTest.java ! test/sun/nio/ch/Basic.java ! test/sun/nio/ch/TempBuffer.java ! test/sun/nio/cs/CheckHistoricalNames.java ! test/sun/nio/cs/FindDecoderBugs.java ! test/sun/nio/cs/ReadZero.java ! test/sun/nio/cs/Test4200310.sh ! test/sun/nio/cs/Test4206507.java ! test/sun/nio/cs/TestStringCoding.java ! test/sun/nio/cs/TestX11CNS.java ! test/sun/rmi/rmic/manifestClassPath/run.sh ! test/sun/security/krb5/auto/Context.java ! test/sun/security/pkcs11/KeyGenerator/TestKeyGenerator.java ! test/sun/security/pkcs11/tls/TestPremaster.java ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/ClientModeClientAuth.java ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/B6226610.java ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/HttpsPost.java ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/Redirect.java ! test/sun/text/resources/LocaleDataTest.java ! test/sun/tools/jps/jps-Vvml_2.sh ! test/sun/tools/jps/jps-help.sh ! test/sun/tools/jps/jps-m_2.sh ! test/sun/tools/jstat/jstatHelp.sh ! test/sun/tools/jstat/jstatOptions1.sh ! test/sun/tools/jstatd/jstatdDefaults.sh ! test/sun/tools/jstatd/jstatdExternalRegistry.sh ! test/sun/tools/jstatd/jstatdPort.sh ! test/sun/tools/jstatd/jstatdServerName.sh ! test/sun/tools/jstatd/jstatdUsage1.sh ! test/sun/util/logging/PlatformLoggerTest.java ! test/sun/util/resources/TimeZone/Bug6317929.java ! test/tools/jar/JarEntryTime.java ! test/tools/jar/index/MetaInf.java ! test/tools/launcher/ChangeDataModel.sh ! test/tools/launcher/DefaultLocaleTest.sh ! test/tools/launcher/UnicodeTest.sh Changeset: 1c72adc9d5f3 Author: ohair Date: 2010-12-28 16:12 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/1c72adc9d5f3 6991482: Add global jdk makefile options to silence some VS2010 warnings Reviewed-by: prr ! make/common/Defs-windows.gmk ! make/common/shared/Defs-windows.gmk ! make/common/shared/Sanity-Settings.gmk Changeset: 58aa8eadae5f Author: lana Date: 2011-01-04 17:05 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/58aa8eadae5f Merge - make/common/internal/BinaryPlugs.gmk ! src/share/classes/com/sun/java/util/jar/pack/AdaptiveCoding.java ! src/share/classes/com/sun/java/util/jar/pack/BandStructure.java ! src/share/classes/com/sun/java/util/jar/pack/ClassWriter.java ! src/share/classes/com/sun/java/util/jar/pack/Code.java ! src/share/classes/com/sun/java/util/jar/pack/Coding.java ! src/share/classes/com/sun/java/util/jar/pack/CodingChooser.java ! src/share/classes/com/sun/java/util/jar/pack/Fixups.java ! src/share/classes/com/sun/java/util/jar/pack/Histogram.java ! src/share/classes/com/sun/java/util/jar/pack/Instruction.java ! src/share/classes/com/sun/java/util/jar/pack/PackageReader.java ! src/share/classes/com/sun/java/util/jar/pack/PackageWriter.java ! src/share/classes/com/sun/java/util/jar/pack/PopulationCoding.java ! src/share/classes/java/io/FileOutputStream.java ! src/share/classes/java/lang/ProcessBuilder.java ! src/share/classes/java/lang/String.java ! src/share/classes/java/lang/Thread.java ! src/share/classes/java/lang/reflect/Constructor.java ! src/share/classes/java/util/AbstractList.java ! src/share/classes/java/util/Arrays.java ! src/share/classes/java/util/Collections.java ! src/share/classes/java/util/Formatter.java ! src/share/classes/java/util/Hashtable.java ! src/share/classes/java/util/LinkedList.java ! src/share/classes/java/util/ListResourceBundle.java ! src/share/classes/java/util/PriorityQueue.java ! src/share/classes/java/util/Properties.java ! src/share/classes/java/util/TreeMap.java ! src/share/classes/java/util/TreeSet.java ! src/share/classes/java/util/logging/LogRecord.java ! src/share/classes/java/util/regex/Pattern.java ! src/share/classes/java/util/zip/ZipFile.java ! src/share/classes/sun/io/Converters.java ! src/share/classes/sun/tools/jstat/resources/jstat_options ! src/share/classes/sun/util/logging/PlatformLogger.java ! test/sun/security/krb5/auto/Context.java From lana.steuck at oracle.com Wed Jan 5 01:48:49 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 05 Jan 2011 01:48:49 +0000 Subject: hg: jdk7/tl/langtools: 2 new changesets Message-ID: <20110105014854.9369B47989@hg.openjdk.java.net> Changeset: 4868a36f6fd8 Author: ohair Date: 2010-12-28 15:54 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/4868a36f6fd8 6962318: Update copyright year Reviewed-by: xdono ! make/Makefile ! make/build.properties ! make/tools/CompileProperties/CompileProperties.java ! make/tools/CompileProperties/CompilePropertiesTask.java ! src/share/classes/com/sun/mirror/util/SourceOrderDeclScanner.java ! src/share/classes/com/sun/source/tree/MethodTree.java ! src/share/classes/com/sun/source/tree/Tree.java ! src/share/classes/com/sun/source/tree/TreeVisitor.java ! src/share/classes/com/sun/source/tree/TryTree.java ! src/share/classes/com/sun/source/tree/TypeParameterTree.java ! src/share/classes/com/sun/source/util/SimpleTreeVisitor.java ! src/share/classes/com/sun/source/util/TreeScanner.java ! src/share/classes/com/sun/source/util/Trees.java ! src/share/classes/com/sun/tools/apt/comp/Apt.java ! src/share/classes/com/sun/tools/apt/main/CommandLine.java ! src/share/classes/com/sun/tools/apt/main/Main.java ! src/share/classes/com/sun/tools/apt/mirror/apt/FilerImpl.java ! src/share/classes/com/sun/tools/apt/mirror/declaration/AnnotationProxyMaker.java ! src/share/classes/com/sun/tools/apt/mirror/declaration/DeclarationImpl.java ! src/share/classes/com/sun/tools/apt/mirror/type/TypeMirrorImpl.java ! src/share/classes/com/sun/tools/apt/resources/apt_ja.properties ! src/share/classes/com/sun/tools/apt/resources/apt_zh_CN.properties ! src/share/classes/com/sun/tools/classfile/ClassWriter.java ! src/share/classes/com/sun/tools/classfile/ExtendedAnnotation.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractExecutableMemberWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractMemberWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractPackageIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractTreeWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AllClassesFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeOptionalMemberWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeRequiredMemberWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ClassUseWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/ClassWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ConstantsSummaryWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ConstructorWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/DeprecatedListWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/EnumConstantWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/FieldWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/FrameOutputWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HelpWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDoclet.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlSerialFieldWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlSerialMethodWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/LinkFactoryImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/MethodWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/NestedClassWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageTreeWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageUseWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/SerializedFormWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/SingleIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/SourceToHTMLConverter.java ! src/share/classes/com/sun/tools/doclets/formats/html/SplitIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/SubWriterHolderWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/TagletWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/TreeWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlDocWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/AnnotationTypeOptionalMemberWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/AnnotationTypeRequiredMemberWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/AnnotationTypeWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/ClassWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/ConstantsSummaryWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/ConstructorWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/EnumConstantWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/FieldWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/MemberSummaryWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/MethodWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/NestedClassWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/PackageSummaryWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/SerializedFormWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AbstractBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AbstractMemberBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AnnotationTypeBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AnnotationTypeOptionalMemberBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AnnotationTypeRequiredMemberBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ClassBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ConstantsSummaryBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/ConstructorBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/EnumConstantBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/FieldBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/LayoutParser.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/MemberSummaryBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/MethodBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/PackageSummaryBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/SerializedFormBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclet.xml ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DirectoryManager.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Util.java ! src/share/classes/com/sun/tools/doclets/standard/Standard.java ! src/share/classes/com/sun/tools/javac/Launcher.java ! src/share/classes/com/sun/tools/javac/api/JavacTool.java ! src/share/classes/com/sun/tools/javac/code/Attribute.java ! src/share/classes/com/sun/tools/javac/code/Flags.java ! src/share/classes/com/sun/tools/javac/code/Kinds.java ! src/share/classes/com/sun/tools/javac/code/Lint.java ! src/share/classes/com/sun/tools/javac/code/Source.java ! src/share/classes/com/sun/tools/javac/code/Symtab.java ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/code/TypeAnnotationPosition.java ! src/share/classes/com/sun/tools/javac/code/TypeAnnotations.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Annotate.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/Enter.java ! src/share/classes/com/sun/tools/javac/comp/Flow.java ! src/share/classes/com/sun/tools/javac/comp/Infer.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/comp/TransTypes.java ! src/share/classes/com/sun/tools/javac/file/Paths.java ! src/share/classes/com/sun/tools/javac/jvm/CRTable.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.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/Target.java ! src/share/classes/com/sun/tools/javac/main/CommandLine.java ! src/share/classes/com/sun/tools/javac/main/Main.java ! src/share/classes/com/sun/tools/javac/main/OptionName.java ! src/share/classes/com/sun/tools/javac/main/RecognizedOptions.java ! src/share/classes/com/sun/tools/javac/model/AnnotationProxyMaker.java ! src/share/classes/com/sun/tools/javac/model/JavacElements.java ! src/share/classes/com/sun/tools/javac/model/JavacTypes.java ! src/share/classes/com/sun/tools/javac/nio/JavacPathFileManager.java ! src/share/classes/com/sun/tools/javac/nio/PathFileObject.java ! src/share/classes/com/sun/tools/javac/parser/Keywords.java ! src/share/classes/com/sun/tools/javac/processing/JavacFiler.java ! src/share/classes/com/sun/tools/javac/processing/JavacMessager.java ! src/share/classes/com/sun/tools/javac/processing/JavacRoundEnvironment.java ! src/share/classes/com/sun/tools/javac/processing/PrintingProcessor.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/resources/compiler_ja.properties ! src/share/classes/com/sun/tools/javac/resources/compiler_zh_CN.properties ! src/share/classes/com/sun/tools/javac/resources/javac.properties ! src/share/classes/com/sun/tools/javac/resources/javac_ja.properties ! src/share/classes/com/sun/tools/javac/resources/javac_zh_CN.properties ! src/share/classes/com/sun/tools/javac/resources/legacy.properties ! src/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/share/classes/com/sun/tools/javac/tree/Pretty.java ! src/share/classes/com/sun/tools/javac/tree/TreeCopier.java ! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java ! src/share/classes/com/sun/tools/javac/tree/TreeMaker.java ! src/share/classes/com/sun/tools/javac/tree/TreeScanner.java ! src/share/classes/com/sun/tools/javac/tree/TreeTranslator.java ! src/share/classes/com/sun/tools/javac/util/AbstractDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javac/util/AbstractLog.java ! src/share/classes/com/sun/tools/javac/util/BaseFileManager.java ! src/share/classes/com/sun/tools/javac/util/BasicDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javac/util/Bits.java ! src/share/classes/com/sun/tools/javac/util/FatalError.java ! src/share/classes/com/sun/tools/javac/util/JCDiagnostic.java ! src/share/classes/com/sun/tools/javac/util/LayoutCharacters.java ! src/share/classes/com/sun/tools/javac/util/List.java ! src/share/classes/com/sun/tools/javac/util/Log.java ! src/share/classes/com/sun/tools/javac/util/MandatoryWarningHandler.java ! src/share/classes/com/sun/tools/javac/util/Options.java ! src/share/classes/com/sun/tools/javac/util/RawDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javac/util/Warner.java ! src/share/classes/com/sun/tools/javadoc/ClassDocImpl.java ! src/share/classes/com/sun/tools/javadoc/DocEnv.java ! src/share/classes/com/sun/tools/javadoc/DocletInvoker.java ! src/share/classes/com/sun/tools/javadoc/JavadocClassReader.java ! src/share/classes/com/sun/tools/javadoc/Messager.java ! src/share/classes/com/sun/tools/javadoc/Start.java ! src/share/classes/com/sun/tools/javadoc/resources/javadoc.properties ! src/share/classes/com/sun/tools/javah/JNI.java ! src/share/classes/com/sun/tools/javah/LLNI.java ! src/share/classes/com/sun/tools/javah/Mangle.java ! src/share/classes/com/sun/tools/javah/TypeSignature.java ! src/share/classes/com/sun/tools/javah/resources/version.properties-template ! src/share/classes/com/sun/tools/javap/AnnotationWriter.java ! src/share/classes/com/sun/tools/javap/AttributeWriter.java ! src/share/classes/com/sun/tools/javap/ClassWriter.java ! src/share/classes/com/sun/tools/javap/CodeWriter.java ! src/share/classes/com/sun/tools/javap/SourceWriter.java ! src/share/classes/javax/lang/model/element/ElementKind.java ! src/share/classes/javax/lang/model/element/ElementVisitor.java ! src/share/classes/javax/lang/model/type/MirroredTypeException.java ! src/share/classes/javax/lang/model/type/MirroredTypesException.java ! src/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitor6.java ! src/share/classes/javax/lang/model/util/AbstractElementVisitor6.java ! src/share/classes/javax/lang/model/util/AbstractTypeVisitor6.java ! src/share/classes/javax/lang/model/util/ElementKindVisitor6.java ! src/share/classes/javax/lang/model/util/ElementScanner6.java ! src/share/classes/javax/lang/model/util/SimpleAnnotationValueVisitor6.java ! src/share/classes/javax/lang/model/util/SimpleElementVisitor6.java ! src/share/classes/javax/lang/model/util/SimpleTypeVisitor6.java ! src/share/classes/javax/lang/model/util/TypeKindVisitor6.java ! src/share/classes/javax/tools/ToolProvider.java ! src/share/sample/javac/processing/src/CheckNamesProcessor.java ! test/com/sun/javadoc/AccessAsciiArt/AccessAsciiArt.java ! test/com/sun/javadoc/AccessH1/AccessH1.java ! test/com/sun/javadoc/AccessSkipNav/AccessSkipNav.java ! test/com/sun/javadoc/AccessSummary/AccessSummary.java ! test/com/sun/javadoc/AuthorDD/AuthorDD.java ! test/com/sun/javadoc/JavascriptWinTitle/JavascriptWinTitle.java ! test/com/sun/javadoc/MetaTag/MetaTag.java ! test/com/sun/javadoc/ValidHtml/ValidHtml.java ! test/com/sun/javadoc/VersionNumber/VersionNumber.java ! test/com/sun/javadoc/WindowTitles/WindowTitles.java ! test/com/sun/javadoc/constantValues/TestConstantValuesDriver.java ! test/com/sun/javadoc/testClassCrossReferences/TestClassCrossReferences.java ! test/com/sun/javadoc/testClassTree/TestClassTree.java ! test/com/sun/javadoc/testConstructorIndent/TestConstructorIndent.java ! test/com/sun/javadoc/testDeprecatedDocs/TestDeprecatedDocs.java ! test/com/sun/javadoc/testDocRootInlineTag/TestDocRootInlineTag.java ! test/com/sun/javadoc/testExternalOverridenMethod/TestExternalOverridenMethod.java ! test/com/sun/javadoc/testHeadings/TestHeadings.java ! test/com/sun/javadoc/testHelpOption/TestHelpOption.java ! test/com/sun/javadoc/testHref/TestHref.java ! test/com/sun/javadoc/testHtmlDefinitionListTag/TestHtmlDefinitionListTag.java ! test/com/sun/javadoc/testHtmlStrongTag/TestHtmlStrongTag.java ! test/com/sun/javadoc/testHtmlTableTags/TestHtmlTableTags.java ! test/com/sun/javadoc/testHtmlTag/TestHtmlTag.java ! test/com/sun/javadoc/testIndex/TestIndex.java ! test/com/sun/javadoc/testInlineLinkLabel/TestInlineLinkLabel.java ! test/com/sun/javadoc/testInterface/TestInterface.java ! test/com/sun/javadoc/testJavascript/TestJavascript.java ! test/com/sun/javadoc/testLinkOption/TestLinkOption.java ! test/com/sun/javadoc/testLinkTaglet/TestLinkTaglet.java ! test/com/sun/javadoc/testLinkToSerialForm/TestLinkToSerialForm.java ! test/com/sun/javadoc/testMemberInheritence/TestMemberInheritence.java ! test/com/sun/javadoc/testMemberSummary/TestMemberSummary.java ! test/com/sun/javadoc/testNavagation/TestNavagation.java ! test/com/sun/javadoc/testNewLanguageFeatures/TestNewLanguageFeatures.java ! test/com/sun/javadoc/testOverridenMethods/TestMultiInheritence.java ! test/com/sun/javadoc/testOverridenMethods/TestOverridenMethodDocCopy.java ! test/com/sun/javadoc/testOverridenMethods/TestOverridenPrivateMethods.java ! test/com/sun/javadoc/testOverridenMethods/TestOverridenPrivateMethodsWithPackageFlag.java ! test/com/sun/javadoc/testOverridenMethods/TestOverridenPrivateMethodsWithPrivateFlag.java ! test/com/sun/javadoc/testPackagePage/TestPackagePage.java ! test/com/sun/javadoc/testParamTaglet/TestParamTaglet.java ! test/com/sun/javadoc/testPrivateClasses/TestPrivateClasses.java ! test/com/sun/javadoc/testSerializedForm/TestSerializedForm.java ! test/com/sun/javadoc/testSerializedFormDeprecationInfo/TestSerializedFormDeprecationInfo.java ! test/com/sun/javadoc/testSimpleTag/TestSimpleTag.java ! test/com/sun/javadoc/testStylesheet/TestStylesheet.java ! test/com/sun/javadoc/testSummaryHeading/TestSummaryHeading.java ! test/com/sun/javadoc/testSuperclassInSerialForm/TestSuperClassInSerialForm.java ! test/com/sun/javadoc/testTagInheritence/TestTagInheritence.java ! test/com/sun/javadoc/testTaglets/TestTaglets.java ! test/com/sun/javadoc/testTaglets/taglets/Foo.java ! test/com/sun/javadoc/testThrowsHead/TestThrowsHead.java ! test/com/sun/javadoc/testThrowsTag/TestThrowsTag.java ! test/com/sun/javadoc/testTitleInHref/TestTitleInHref.java ! test/com/sun/javadoc/testTypeParams/TestTypeParameters.java ! test/com/sun/javadoc/testUnnamedPackage/TestUnnamedPackage.java ! test/com/sun/javadoc/testValueTag/TestValueTag.java ! test/com/sun/javadoc/testWarnings/TestWarnings.java ! test/tools/javac/6341866/Anno.java ! test/tools/javac/6341866/T6341866.java ! test/tools/javac/6402516/CheckLocalElements.java ! test/tools/javac/ClassFileModifiers/ClassModifiers.java ! test/tools/javac/ClassFileModifiers/MemberModifiers.java ! test/tools/javac/EarlyAssert.java ! test/tools/javac/InterfaceAssert.java ! test/tools/javac/OverrideChecks/6738538/T6738538a.java ! test/tools/javac/OverrideChecks/6738538/T6738538b.java ! test/tools/javac/T6358024.java ! test/tools/javac/T6403466.java ! test/tools/javac/T6411379.java ! test/tools/javac/T6423583.java ! test/tools/javac/T6705935.java ! test/tools/javac/ThrowsIntersection_1.java ! test/tools/javac/ThrowsIntersection_2.java ! test/tools/javac/ThrowsIntersection_3.java ! test/tools/javac/ThrowsIntersection_4.java ! test/tools/javac/annotations/6214965/T6214965.java ! test/tools/javac/annotations/6365854/T6365854.java ! test/tools/javac/annotations/neg/Constant.java ! test/tools/javac/annotations/neg/Dep.java ! test/tools/javac/annotations/pos/TrailingComma.java ! test/tools/javac/api/6421111/T6421111.java ! test/tools/javac/api/6468404/T6468404.java ! test/tools/javac/api/6731573/T6731573.java ! test/tools/javac/api/T6392782.java ! test/tools/javac/api/T6412669.java ! test/tools/javac/api/TestOperators.java ! test/tools/javac/cast/6548436/T6548436d.java ! test/tools/javac/cast/6558559/T6558559a.java ! test/tools/javac/cast/6558559/T6558559b.java ! test/tools/javac/cast/6586091/T6586091.java ! test/tools/javac/danglingDep/DepX.java ! test/tools/javac/danglingDep/NoDepX.java ! test/tools/javac/danglingDep/Test1.java ! test/tools/javac/depOverrides/annotation/Test1.java ! test/tools/javac/depOverrides/annotation/Test2.java ! test/tools/javac/depOverrides/doccomment/Test1.java ! test/tools/javac/depOverrides/doccomment/Test2.java ! test/tools/javac/diags/examples/BadSourceFileHeader/sourcepath/p/A.java ! test/tools/javac/enum/6424358/T6424358.java ! test/tools/javac/enum/T6724345.java ! test/tools/javac/generics/Casting.java ! test/tools/javac/generics/Casting3.java ! test/tools/javac/generics/Casting4.java ! test/tools/javac/generics/InnerInterface1.java ! test/tools/javac/generics/InnerInterface2.java ! test/tools/javac/generics/Multibound1.java ! test/tools/javac/generics/MultipleInheritance.java ! test/tools/javac/generics/NameOrder.java ! test/tools/javac/generics/PermuteBound.java ! test/tools/javac/generics/PrimitiveVariant.java ! test/tools/javac/generics/T6557954.java ! test/tools/javac/generics/T6751514.java ! test/tools/javac/generics/T6869075.java ! test/tools/javac/generics/inference/6569789/T6569789.java ! test/tools/javac/generics/inference/6650759/T6650759a.java ! test/tools/javac/generics/typevars/5060485/Compatibility.java ! test/tools/javac/generics/typevars/5060485/Compatibility02.java ! test/tools/javac/generics/typevars/T6880344.java ! test/tools/javac/generics/wildcards/T6732484.java ! test/tools/javac/mandatoryWarnings/deprecated/Test.java ! test/tools/javac/mandatoryWarnings/unchecked/Test.java ! test/tools/javac/meth/InvokeMHTrans.java ! test/tools/javac/nio/compileTest/CompileTest.java ! test/tools/javac/policy/test1/Test1a.java ! test/tools/javac/policy/test2/Test.java ! test/tools/javac/processing/model/util/elements/Foo.java ! test/tools/javac/rawDiags/Note.java ! test/tools/javac/tree/TreeKindTest.java ! test/tools/javac/typeAnnotations/newlocations/BasicTest.java ! test/tools/javac/varargs/T6746184.java ! test/tools/javac/varargs/warning/Warn1.java ! test/tools/javadoc/T4994049/FileWithTabs.java ! test/tools/javadoc/T4994049/T4994049.java ! test/tools/javap/T6715251.java ! test/tools/javap/T6715753.java ! test/tools/javap/T6729471.java ! test/tools/javap/T6868539.java Changeset: e63b1f8341ce Author: lana Date: 2011-01-04 17:10 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/e63b1f8341ce Merge ! make/Makefile ! src/share/classes/com/sun/tools/javac/file/Paths.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/nio/JavacPathFileManager.java ! test/tools/javac/nio/compileTest/CompileTest.java From maurizio.cimadamore at oracle.com Wed Jan 5 10:00:53 2011 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Wed, 05 Jan 2011 10:00:53 +0000 Subject: hg: jdk7/tl/langtools: 7010194: several langtools regression failures after JSR 292 changes (b123) Message-ID: <20110105100058.2E57F479A4@hg.openjdk.java.net> Changeset: 15484cb7e5ae Author: mcimadamore Date: 2011-01-05 09:59 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/15484cb7e5ae 7010194: several langtools regression failures after JSR 292 changes (b123) Summary: Some regression tests rely on unsupported JSR 292 features Reviewed-by: jjg ! test/tools/javac/diags/examples/TypeParameterOnPolymorphicSignature.java - test/tools/javac/meth/InvokeDyn.java - test/tools/javac/meth/InvokeDynTrans.java ! test/tools/javac/meth/XlintWarn.java From forax at univ-mlv.fr Wed Jan 5 11:18:31 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Wed, 05 Jan 2011 12:18:31 +0100 Subject: hg: jdk7/tl/langtools: 7010194: several langtools regression failures after JSR 292 changes (b123) In-Reply-To: <20110105100058.2E57F479A4@hg.openjdk.java.net> References: <20110105100058.2E57F479A4@hg.openjdk.java.net> Message-ID: <4D245387.5030507@univ-mlv.fr> Hi maurizio, In my opinion, XlintWarn should also test invokeGeneric(). Moreover, it will be better to have one test by invoke*() instead of having one test for all invoke*() R?mi On 01/05/2011 11:00 AM, maurizio.cimadamore at oracle.com wrote: > Changeset: 15484cb7e5ae > Author: mcimadamore > Date: 2011-01-05 09:59 +0000 > URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/15484cb7e5ae > > 7010194: several langtools regression failures after JSR 292 changes (b123) > Summary: Some regression tests rely on unsupported JSR 292 features > Reviewed-by: jjg > > ! test/tools/javac/diags/examples/TypeParameterOnPolymorphicSignature.java > - test/tools/javac/meth/InvokeDyn.java > - test/tools/javac/meth/InvokeDynTrans.java > ! test/tools/javac/meth/XlintWarn.java > From Alan.Bateman at oracle.com Wed Jan 5 11:49:04 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 05 Jan 2011 11:49:04 +0000 Subject: Code Review 7000511: PrintStream, PrintWriter, Formatter leave files open when exception thrown In-Reply-To: <4D233E21.4070804@oracle.com> References: <4D078824.5030307@oracle.com> <4D07B184.7050005@oracle.com> <4D092D17.3070001@oracle.com> <4D09FC31.1070501@oracle.com> <4D233E21.4070804@oracle.com> Message-ID: <4D245AB0.9010500@oracle.com> Chris Hegarty wrote: > > > : > Thanks for the comments. Please take a look at the latest changes. > http://cr.openjdk.java.net/~chegar/7000511/webrev.02/webrev/ I see you've updated this to webrev.03 so I looked at that. Overall this looks much cleaner and you've addressed the issues that I pointed out. One minor comment is that the coding style is bit inconsistent with the existing code in a few places. For example in methods that throw checked exceptions you've indented the "throws XYZ" much more than the existing code and the closing brace is pushed out which looks a bit strange compared to the existing code. Also the comment in toCharset (repeated in all classes) probably should be a one-liner with //. -Alan. From maurizio.cimadamore at oracle.com Wed Jan 5 11:53:37 2011 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 05 Jan 2011 11:53:37 +0000 Subject: [Fwd: Re: hg: jdk7/tl/langtools: 7010194: several langtools regression failures after JSR 292 changes (b123)] In-Reply-To: <4D2454CC.6060409@oracle.com> References: <4D2454CC.6060409@oracle.com> Message-ID: <4D245BC1.30905@oracle.com> On 05/01/11 11:23, Alan Bateman wrote: > Hi maurizio, > In my opinion, XlintWarn should also test invokeGeneric(). > Moreover, it will be better to have one test by invoke*() instead of > having one > test for all invoke*() > > R?mi Hi Remi I agree on your comments; however note that the aim of the XlintWarn test is to check that the compiler issues warnings in relation to old-style usage of 292 target typing - since the old syntax is going away (see related cleanup CR: 6992698). In other words, the aim of this changeset is to make tests pass again (with b123) awaiting for a more precise cleanup (which is needed since InvokeDynamic and other 292 features should be removed from the JDK 7 repo). Maurizio From Alan.Bateman at oracle.com Wed Jan 5 13:36:41 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 05 Jan 2011 13:36:41 +0000 Subject: Review request for 6927486: Deadlock in legacy Hashtable writeObject() In-Reply-To: References: Message-ID: <4D2473E9.4010600@oracle.com> Neil Richards wrote: > Please find attached a changeset to address the problem reported in > bug 6927486, "Deadlock in legacy Hashtable writeObject()". > I've taken the liberty to generate a webrev from the changeset, just to make it a bit easier for folks to browse and review. http://cr.openjdk.java.net/~alanb/6927486/webrev/ I don't see any issues with the changes to j.u.Hashtable. You might have seen Stuart Mark's changes go by recently where he changed some of the existing code (including java.util) to use diamond. You might want to use this in these changes to avoid needing to re-run the tools on this code. This would also fix a style issue where you've got a space between the type parameters in a few places. In the tests you catch Exception (or IOException or ClassNotFoundException) and then re-throw a RuntimeException. You can probably remove this as jtreg will mark the test as failed if it completes with any exception. I think Mike Duigou plans to review this too and help get the changes into the tl/jdk repo. > The problem reported is similar to one found in java.util.Vector, for > which a fix is also currently under review > (http://mail.openjdk.java.net/pipermail/core-libs-dev/2010-December/005529.html). > You might want to give this one a nudge by re-sending with a GPL header on the test. As I recall it was just the test that needed to be reviewed. > PPS: > I notice the API javadoc for PropertyPermission does not give its > serialized form (and the "See Also:" section), even though it is > Serializable, which strikes me as unusual. > > I suppose it has no serializable fields of its own (over that which > BasicPermission has), but I'm sure I've seen other serializable > classes with no fields having "serialized form" entries. > > I assume it's the @serial exclude. You'll find some background in 4288648 (from 11 years ago) but it would require further digging to find all the details. -Alan From forax at univ-mlv.fr Wed Jan 5 14:01:54 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Wed, 05 Jan 2011 15:01:54 +0100 Subject: [Fwd: Re: hg: jdk7/tl/langtools: 7010194: several langtools regression failures after JSR 292 changes (b123)] In-Reply-To: <4D245BC1.30905@oracle.com> References: <4D2454CC.6060409@oracle.com> <4D245BC1.30905@oracle.com> Message-ID: <4D2479D2.7080201@univ-mlv.fr> On 01/05/2011 12:53 PM, Maurizio Cimadamore wrote: > On 05/01/11 11:23, Alan Bateman wrote: >> Hi maurizio, >> In my opinion, XlintWarn should also test invokeGeneric(). >> Moreover, it will be better to have one test by invoke*() instead of >> having one >> test for all invoke*() >> >> R?mi > Hi Remi > I agree on your comments; however note that the aim of the XlintWarn > test is to check that the compiler issues warnings in relation to > old-style usage of 292 target typing - since the old syntax is going > away (see related cleanup CR: 6992698). In other words, the aim of > this changeset is to make tests pass again (with b123) awaiting for a > more precise cleanup (which is needed since InvokeDynamic and other > 292 features should be removed from the JDK 7 repo). Not all syntaxes introduces by JSR 292 should be removed MethodHandle.invokeExact()/invokeGeneric() will stay. Otherwise, java.dyn package will not compile anymore. And in my opinion other features should forward ported into lambda workspace, but that's a different story. > > Maurizio R?mi From stuart.marks at oracle.com Wed Jan 5 19:47:31 2011 From: stuart.marks at oracle.com (Stuart Marks) Date: Wed, 05 Jan 2011 11:47:31 -0800 Subject: Review request for 6927486: Deadlock in legacy Hashtable writeObject() In-Reply-To: <4D2473E9.4010600@oracle.com> References: <4D2473E9.4010600@oracle.com> Message-ID: <4D24CAD3.4090403@oracle.com> On 1/5/11 5:36 AM, Alan Bateman wrote: > I've taken the liberty to generate a webrev from the changeset, just to make it > a bit easier for folks to browse and review. > http://cr.openjdk.java.net/~alanb/6927486/webrev/ > > I don't see any issues with the changes to j.u.Hashtable. You might have seen > Stuart Mark's changes go by recently where he changed some of the existing code > (including java.util) to use diamond. You might want to use this in these > changes to avoid needing to re-run the tools on this code. This would also fix > a style issue where you've got a space between the type parameters in a few > places. A couple things here. First, the changeset Alan refers to is 449dfb061fde, where I used a conversion tool to apply the diamond operator in a bunch of places. The tool applied diamond *everywhere* that the current JDK 7 compiler supports it. It's not clear that we actually want to use diamond everywhere that it can be used, however, we haven't completely decided this yet. In Hashtable.java, diamond is used in a bunch of similar places. I'd suggest following the style that's there and using diamond in this case, the creation of an Entry object for entryStack, e.g. entryStack = new Entry<>(0, entry.key, entry.value, entryStack); Second, it's not clear to me that there is a preferred style for putting spaces in the list of type arguments. If one looks around the code base, it's quite inconsistent. There does seem to be a moderate preference for not using spaces when the type arguments are themselves type parameters, which are typically single letters, e.g. Entry. But spaces are often used when the type arguments are concrete types that are full words, e.g. Map. But this is moot if diamond is used in this case. s'marks From chris.hegarty at oracle.com Thu Jan 6 11:07:50 2011 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 06 Jan 2011 11:07:50 +0000 Subject: Code Review 7000511: PrintStream, PrintWriter, Formatter leave files open when exception thrown In-Reply-To: <4D245AB0.9010500@oracle.com> References: <4D078824.5030307@oracle.com> <4D07B184.7050005@oracle.com> <4D092D17.3070001@oracle.com> <4D09FC31.1070501@oracle.com> <4D233E21.4070804@oracle.com> <4D245AB0.9010500@oracle.com> Message-ID: <4D25A286.7070202@oracle.com> On 01/ 5/11 11:49 AM, Alan Bateman wrote: > Chris Hegarty wrote: >> >> >> : >> Thanks for the comments. Please take a look at the latest changes. >> http://cr.openjdk.java.net/~chegar/7000511/webrev.02/webrev/ > I see you've updated this to webrev.03 so I looked at that. Overall this > looks much cleaner and you've addressed the issues that I pointed out. > > One minor comment is that the coding style is bit inconsistent with the > existing code in a few places. For example in methods that throw checked > exceptions you've indented the "throws XYZ" much more than the existing > code and the closing brace is pushed out which looks a bit strange > compared to the existing code. Also the comment in toCharset (repeated > in all classes) probably should be a one-liner with //. Yes, I should have noticed the style differences. I trusted Netbeans style! The style should be consistent. All fixed. http://cr.openjdk.java.net/~chegar/7000511/webrev.04/webrev/ Thanks, -Chris. > > -Alan. > > From Alan.Bateman at oracle.com Thu Jan 6 12:00:49 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 06 Jan 2011 12:00:49 +0000 Subject: Code Review 7000511: PrintStream, PrintWriter, Formatter leave files open when exception thrown In-Reply-To: <4D25A286.7070202@oracle.com> References: <4D078824.5030307@oracle.com> <4D07B184.7050005@oracle.com> <4D092D17.3070001@oracle.com> <4D09FC31.1070501@oracle.com> <4D233E21.4070804@oracle.com> <4D245AB0.9010500@oracle.com> <4D25A286.7070202@oracle.com> Message-ID: <4D25AEF1.60406@oracle.com> Chris Hegarty wrote: > : > Yes, I should have noticed the style differences. I trusted Netbeans > style! The style should be consistent. All fixed. > > http://cr.openjdk.java.net/~chegar/7000511/webrev.04/webrev/ Looks good to me. -Alan. From jonathan.gibbons at oracle.com Thu Jan 6 22:32:30 2011 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Thu, 06 Jan 2011 22:32:30 +0000 Subject: hg: jdk7/tl/jdk: 7010537: javah no longer depends on javadoc Message-ID: <20110106223240.2813347A12@hg.openjdk.java.net> Changeset: d56c111ec6dc Author: jjg Date: 2011-01-06 14:32 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d56c111ec6dc 7010537: javah no longer depends on javadoc Reviewed-by: ohair ! make/common/shared/Defs-java.gmk From chris.hegarty at oracle.com Fri Jan 7 13:09:19 2011 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Fri, 07 Jan 2011 13:09:19 +0000 Subject: hg: jdk7/tl/jdk: 7000511: PrintStream, PrintWriter, Formatter, Scanner leave files open when exception thrown Message-ID: <20110107130940.CD02747A5C@hg.openjdk.java.net> Changeset: b8663921f5d7 Author: chegar Date: 2011-01-07 13:08 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/b8663921f5d7 7000511: PrintStream, PrintWriter, Formatter, Scanner leave files open when exception thrown Reviewed-by: alanb, mduigou ! src/share/classes/java/io/PrintStream.java ! src/share/classes/java/io/PrintWriter.java ! src/share/classes/java/util/Formatter.java ! src/share/classes/java/util/Scanner.java ! test/ProblemList.txt + test/java/io/PrintStream/FailingConstructors.java + test/java/io/PrintWriter/FailingConstructors.java ! test/java/util/Formatter/Constructors.java + test/java/util/Formatter/FailingConstructors.java + test/java/util/Scanner/FailingConstructors.java From alan.bateman at oracle.com Fri Jan 7 15:52:13 2011 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Fri, 07 Jan 2011 15:52:13 +0000 Subject: hg: jdk7/tl/jdk: 2 new changesets Message-ID: <20110107155232.0A1D147A64@hg.openjdk.java.net> Changeset: 5124c2a50539 Author: alanb Date: 2011-01-07 15:49 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/5124c2a50539 6993732: Remove the HPI Reviewed-by: ohair, lancea, chegar, mduigou, mchung, mr ! make/common/Defs-linux.gmk ! make/common/Defs-solaris.gmk ! make/common/Defs-windows.gmk ! make/common/Defs.gmk ! make/common/Modules.gmk ! make/common/Release.gmk ! make/java/Makefile ! make/java/fdlibm/Makefile - make/java/hpi/Makefile - make/java/hpi/hpi_common.gmk - make/java/hpi/native/Makefile - make/java/hpi/native/mapfile-vers - make/java/hpi/native/reorder-i586 - make/java/hpi/native/reorder-sparc - make/java/hpi/native/reorder-sparcv9 - make/java/hpi/windows/Makefile ! make/tools/reorder/Makefile - src/share/hpi/export/bool.h - src/share/hpi/export/dll.h - src/share/hpi/export/hpi.h - src/share/hpi/include/hpi_impl.h - src/share/hpi/include/vm_calls.h - src/share/hpi/src/hpi.c - src/solaris/hpi/export/byteorder_md.h - src/solaris/hpi/export/hpi_md.h - src/solaris/hpi/export/io_md.h - src/solaris/hpi/export/path_md.h - src/solaris/hpi/export/timeval_md.h - src/solaris/hpi/include/hpi_init.h - src/solaris/hpi/include/interrupt.h - src/solaris/hpi/include/largefile.h - src/solaris/hpi/include/largefile_linux.h - src/solaris/hpi/include/largefile_solaris.h - src/solaris/hpi/native_threads/include/condvar_md.h - src/solaris/hpi/native_threads/include/monitor_md.h - src/solaris/hpi/native_threads/include/mutex_md.h - src/solaris/hpi/native_threads/include/np.h - src/solaris/hpi/native_threads/include/porting.h - src/solaris/hpi/native_threads/include/threads_md.h - src/solaris/hpi/native_threads/src/condvar_md.c - src/solaris/hpi/native_threads/src/interrupt_md.c - src/solaris/hpi/native_threads/src/monitor_md.c - src/solaris/hpi/native_threads/src/mutex_md.c - src/solaris/hpi/native_threads/src/sys_api_td.c - src/solaris/hpi/native_threads/src/threads_linux.c - src/solaris/hpi/native_threads/src/threads_md.c - src/solaris/hpi/native_threads/src/threads_solaris.c - src/solaris/hpi/src/interrupt.c - src/solaris/hpi/src/linker_md.c - src/solaris/hpi/src/memory_md.c - src/solaris/hpi/src/system_md.c - src/windows/hpi/export/byteorder_md.h - src/windows/hpi/export/hpi_md.h - src/windows/hpi/export/io_md.h - src/windows/hpi/export/path_md.h - src/windows/hpi/export/timeval_md.h - src/windows/hpi/include/monitor_md.h - src/windows/hpi/include/mutex_md.h - src/windows/hpi/include/threads_md.h - src/windows/hpi/src/linker_md.c - src/windows/hpi/src/memory_md.c - src/windows/hpi/src/monitor_md.c - src/windows/hpi/src/path_md.c - src/windows/hpi/src/socket_md.c - src/windows/hpi/src/sys_api_md.c - src/windows/hpi/src/system_md.c - src/windows/hpi/src/threads_md.c Changeset: ddaffd64796c Author: alanb Date: 2011-01-07 15:51 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/ddaffd64796c Merge From chris.hegarty at oracle.com Fri Jan 7 21:04:21 2011 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Fri, 07 Jan 2011 21:04:21 +0000 Subject: hg: jdk7/tl/jdk: 7009760: Possible stack corruption in Java_java_net_TwoStacksPlainSocketImpl_socketGetOption Message-ID: <20110107210432.28CAC47A77@hg.openjdk.java.net> Changeset: 6bf1c5958c22 Author: chegar Date: 2011-01-07 21:02 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/6bf1c5958c22 7009760: Possible stack corruption in Java_java_net_TwoStacksPlainSocketImpl_socketGetOption Summary: SOCKET_ADDRESS -> SOCKETADDRESS Reviewed-by: alanb ! src/windows/native/java/net/TwoStacksPlainSocketImpl.c From stuart.marks at oracle.com Sat Jan 8 00:18:31 2011 From: stuart.marks at oracle.com (stuart.marks at oracle.com) Date: Sat, 08 Jan 2011 00:18:31 +0000 Subject: hg: jdk7/tl/jdk: 7008728: diamond conversion of basic security, permissions, authentication Message-ID: <20110108001841.DFF9847A81@hg.openjdk.java.net> Changeset: 3dbc783a8073 Author: smarks Date: 2011-01-07 15:39 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/3dbc783a8073 7008728: diamond conversion of basic security, permissions, authentication Reviewed-by: mullan ! src/share/classes/com/sun/security/auth/PolicyFile.java ! src/share/classes/com/sun/security/auth/callback/DialogCallbackHandler.java ! src/share/classes/com/sun/security/auth/login/ConfigFile.java ! src/share/classes/com/sun/security/auth/module/JndiLoginModule.java ! src/share/classes/com/sun/security/auth/module/KeyStoreLoginModule.java ! src/share/classes/com/sun/security/auth/module/SolarisLoginModule.java ! src/share/classes/com/sun/security/auth/module/UnixLoginModule.java ! src/share/classes/java/security/AccessControlContext.java ! src/share/classes/java/security/BasicPermission.java ! src/share/classes/java/security/CodeSource.java ! src/share/classes/java/security/Permissions.java ! src/share/classes/java/security/ProtectionDomain.java ! src/share/classes/java/security/Provider.java ! src/share/classes/java/security/SecureClassLoader.java ! src/share/classes/java/security/Security.java ! src/share/classes/java/security/UnresolvedPermission.java ! src/share/classes/java/security/UnresolvedPermissionCollection.java ! src/share/classes/javax/security/auth/PrivateCredentialPermission.java ! src/share/classes/javax/security/auth/SubjectDomainCombiner.java ! src/share/classes/javax/security/auth/kerberos/DelegationPermission.java ! src/share/classes/javax/security/auth/kerberos/ServicePermission.java ! src/share/classes/sun/security/acl/AclEntryImpl.java ! src/share/classes/sun/security/acl/AclImpl.java ! src/share/classes/sun/security/acl/GroupImpl.java ! test/com/sun/security/auth/module/LdapLoginModule/CheckConfigs.java ! test/com/sun/security/auth/module/LdapLoginModule/CheckOptions.java From alan.bateman at oracle.com Mon Jan 10 09:33:25 2011 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Mon, 10 Jan 2011 09:33:25 +0000 Subject: hg: jdk7/tl/jdk: 7002957: (fc) FileChannel.transferTo fails to load libsendfile on Solaris 64-bit Message-ID: <20110110093352.360CA47AFA@hg.openjdk.java.net> Changeset: ee5bf287d0c4 Author: alanb Date: 2011-01-10 09:32 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/ee5bf287d0c4 7002957: (fc) FileChannel.transferTo fails to load libsendfile on Solaris 64-bit Reviewed-by: chegar ! make/java/nio/Makefile ! src/solaris/native/sun/nio/ch/FileChannelImpl.c From neil.richards at ngmr.net Mon Jan 10 11:02:51 2011 From: neil.richards at ngmr.net (Neil Richards) Date: Mon, 10 Jan 2011 11:02:51 +0000 Subject: Sunbug 6934356: Vector.writeObject() synchronization risks serialization deadlock In-Reply-To: References: <4D0A0D96.7050302@oracle.com> Message-ID: Based on Alan Bateman's feedback for my fix for a similar problem seen in java.util.Hashtable (http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-January/005601.html), I've revised the changeset once again to use diamond operators in the testcases, and to their main methods throw Exceptions directly (rather than catching them in the cause of a RuntimeException). Also based on Dalibor Topic's suggestion (http://mail.openjdk.java.net/pipermail/core-libs-dev/2010-December/005533.html), I'm attaching the updated changeset as a webrev zip file, for ease of review. Please review this modified changeset, and let me know if anything further is required for its acceptance. Cheers, Neil -- Unless stated above: IBM email: neil_richards at uk.ibm.com IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- A non-text attachment was scrubbed... Name: webrev.6934356.2.zip Type: application/zip Size: 116978 bytes Desc: not available URL: From neil.richards at ngmr.net Mon Jan 10 11:27:50 2011 From: neil.richards at ngmr.net (Neil Richards) Date: Mon, 10 Jan 2011 11:27:50 +0000 Subject: Review request for 6927486: Deadlock in legacy Hashtable writeObject() In-Reply-To: <4D2473E9.4010600@oracle.com> References: <4D2473E9.4010600@oracle.com> Message-ID: On 5 January 2011 13:36, Alan Bateman wrote: > I don't see any issues with the changes to j.u.Hashtable. You might have > seen Stuart Mark's changes go by recently where he changed some of the > existing code (including java.util) to use diamond. You might want to use > this in these changes to avoid needing to re-run the tools on this code. > This would also fix a style issue where you've got a space between the type > parameters in a few places. Good idea - I've updated the changeset to use the diamond operation where appropriate. Based on a crude search, I currently see (in the 'tl/jdk' repository) 1242 instances where Generic parameters are declared without a space, and 1911 instances where they are declared with a space. (This is for parameters with "real" object types, rather than "" type parameters). I guess this backs up Stuart's point, that there seems to be no consistency on which form to use. > In the tests you catch Exception (or IOException or ClassNotFoundException) > and then re-throw a RuntimeException. You can probably remove this as jtreg > will mark the test as failed if it completes with any exception. Okay. I've updated the changeset to do this too, and attached this as a webrev zip file (as per Dalibor's suggestion). Please review this modified changeset, and let me know if anything further is required for its acceptance. >> The problem reported is similar to one found in java.util.Vector, for >> which a fix is also currently under review >> >> (http://mail.openjdk.java.net/pipermail/core-libs-dev/2010-December/005529.html). >> > > You might want to give this one a nudge by re-sending with a GPL header on > the test. As I recall it was just the test that needed to be reviewed. I did post an update which added the appropriate headers here: http://mail.openjdk.java.net/pipermail/core-libs-dev/2010-December/005529.html However, I've updated this again, based on the feedback given for this item: http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-January/005612.html Thanks for all your help with this, Cheers, Neil -- Unless stated above: IBM email: neil_richards at uk.ibm.com IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- A non-text attachment was scrubbed... Name: webrev.6927486.1.zip Type: application/zip Size: 116102 bytes Desc: not available URL: From Alan.Bateman at oracle.com Mon Jan 10 11:56:14 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 10 Jan 2011 11:56:14 +0000 Subject: Sunbug 6934356: Vector.writeObject() synchronization risks serialization deadlock In-Reply-To: References: <4D0A0D96.7050302@oracle.com> Message-ID: <4D2AF3DE.5060104@oracle.com> Neil Richards wrote: > Based on Alan Bateman's feedback for my fix for a similar problem seen > in java.util.Hashtable > (http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-January/005601.html), > I've revised the changeset once again to use diamond operators in the > testcases, and to their main methods throw Exceptions directly (rather > than catching them in the cause of a RuntimeException). > > Also based on Dalibor Topic's suggestion > (http://mail.openjdk.java.net/pipermail/core-libs-dev/2010-December/005533.html), > I'm attaching the updated changeset as a webrev zip file, for ease of > review. > > Please review this modified changeset, and let me know if anything > further is required for its acceptance. > Looks okay to me. One minor comment is that you might want to update writeObject's description where it currently reads "It just calls the default writeObject method". A minor nit in the tests is that the date range should be "2010, 2011," rather than "2010-2011". -Alan. From Alan.Bateman at oracle.com Mon Jan 10 12:33:49 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 10 Jan 2011 12:33:49 +0000 Subject: Review request for 6927486: Deadlock in legacy Hashtable writeObject() In-Reply-To: References: <4D2473E9.4010600@oracle.com> Message-ID: <4D2AFCAD.2000304@oracle.com> Neil Richards wrote: > : > Okay. I've updated the changeset to do this too, and attached this as > a webrev zip file (as per Dalibor's suggestion). > > Please review this modified changeset, and let me know if anything > further is required for its acceptance. > Looks fine to me. As per the tests for the Vector serialization, you might want to check the format of the date range in the headers. I hate bringing up code style/conventions (as it only starts wars) but you might want to check the "implements Serializable" at L76 of SerializationDeadlock.java as it looks like it's not indented. Same thing with the "throws IOException" as line 82. I can't tell from the webrev if this is due to tabs or something else but I noticed it in the webrev for the Vector fix too. > : > I did post an update which added the appropriate headers here: > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2010-December/005529.html > I didn't see that one, sorry. Anyway, I think Mike is going help get these pushed. -Alan From neil.richards at ngmr.net Mon Jan 10 15:48:20 2011 From: neil.richards at ngmr.net (Neil Richards) Date: Mon, 10 Jan 2011 15:48:20 +0000 Subject: Sunbug 6934356: Vector.writeObject() synchronization risks serialization deadlock In-Reply-To: <4D2AF3DE.5060104@oracle.com> References: <4D0A0D96.7050302@oracle.com> <4D2AF3DE.5060104@oracle.com> Message-ID: On 10 January 2011 11:56, Alan Bateman wrote: > Looks okay to me. One minor comment is that you might want to update > writeObject's description where it currently reads "It just calls the > default writeObject method". A minor nit in the tests is that the date range > should be "2010, 2011," rather than "2010-2011". > > -Alan. Apologies for seeming to approach the solution asymptotically. Please find attached a further webrev zip file with modification to the writeObject's javadoc and testcases copyright date range. Please let me know if you find anything further. Cheers, Neil -- Unless stated above: IBM email: neil_richards at uk.ibm.com IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- A non-text attachment was scrubbed... Name: webrev.6934356.3.zip Type: application/zip Size: 117484 bytes Desc: not available URL: From lance.andersen at oracle.com Mon Jan 10 19:44:21 2011 From: lance.andersen at oracle.com (lance.andersen at oracle.com) Date: Mon, 10 Jan 2011 19:44:21 +0000 Subject: hg: jdk7/tl/jdk: 6544224: Remove the need of sun.reflect.misc Message-ID: <20110110194439.C6FB447B1F@hg.openjdk.java.net> Changeset: f4d755bbdabe Author: lancea Date: 2011-01-10 14:43 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f4d755bbdabe 6544224: Remove the need of sun.reflect.misc Reviewed-by: alanb ! src/share/classes/javax/sql/rowset/serial/SerialJavaObject.java From Alan.Bateman at oracle.com Mon Jan 10 21:11:16 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 10 Jan 2011 21:11:16 +0000 Subject: Sunbug 6934356: Vector.writeObject() synchronization risks serialization deadlock In-Reply-To: References: <4D0A0D96.7050302@oracle.com> <4D2AF3DE.5060104@oracle.com> Message-ID: <4D2B75F4.20309@oracle.com> Neil Richards wrote: > : > Apologies for seeming to approach the solution asymptotically. > > Please find attached a further webrev zip file with modification to > the writeObject's javadoc and testcases copyright date range. > > Please let me know if you find anything further. > The update to the javadoc looks fine to me. On the headers then we use the GPL header on tests (no Classpath Exception). -Alan From mike.duigou at oracle.com Mon Jan 10 22:07:17 2011 From: mike.duigou at oracle.com (Mike Duigou) Date: Mon, 10 Jan 2011 14:07:17 -0800 Subject: Sunbug 6934356: Vector.writeObject() synchronization risks serialization deadlock In-Reply-To: References: <4D0A0D96.7050302@oracle.com> <4D2AF3DE.5060104@oracle.com> Message-ID: Hi Neil; Thanks for the updates. I have posted both this webrev and the Hashtable counterpart on cr.openjdk.java.net: Hashtable : http://cr.openjdk.java.net/~mduigou/6927486.1/webrev/ Vector : http://cr.openjdk.java.net/~mduigou/6934356.3/webrev/ I am confused on one point about the license. The copyright line mentions IBM but then the rest of the initial license comment refers to Oracle. To me, from the file text alone, it is not be clear why Oracle would be legally entitled to offer a license to the code. I defer to more lawyerly types to determine what's correct here. The changes and testfiles otherwise look OK to me and I can push them as soon as the license question is resolved. Thanks, Mike On Jan 10 2011, at 07:48 , Neil Richards wrote: > On 10 January 2011 11:56, Alan Bateman wrote: >> Looks okay to me. One minor comment is that you might want to update >> writeObject's description where it currently reads "It just calls the >> default writeObject method". A minor nit in the tests is that the date range >> should be "2010, 2011," rather than "2010-2011". >> >> -Alan. > > Apologies for seeming to approach the solution asymptotically. > > Please find attached a further webrev zip file with modification to > the writeObject's javadoc and testcases copyright date range. > > Please let me know if you find anything further. > Cheers, > Neil > > -- > Unless stated above: > IBM email: neil_richards at uk.ibm.com > IBM United Kingdom Limited - Registered in England and Wales with number 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > From jonathan.gibbons at oracle.com Mon Jan 10 22:59:14 2011 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Mon, 10 Jan 2011 22:59:14 +0000 Subject: hg: jdk7/tl/langtools: 6992999: fully remove JSR 308 from langtools Message-ID: <20110110225918.7849547B33@hg.openjdk.java.net> Changeset: d17f37522154 Author: jjg Date: 2011-01-10 14:57 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/d17f37522154 6992999: fully remove JSR 308 from langtools Reviewed-by: mcimadamore ! src/share/classes/com/sun/source/tree/MethodTree.java ! src/share/classes/com/sun/source/tree/Tree.java ! src/share/classes/com/sun/source/tree/TreeVisitor.java ! src/share/classes/com/sun/source/tree/TypeParameterTree.java ! src/share/classes/com/sun/source/util/SimpleTreeVisitor.java ! src/share/classes/com/sun/source/util/TreeScanner.java ! src/share/classes/com/sun/tools/classfile/Attribute.java ! src/share/classes/com/sun/tools/classfile/ClassWriter.java - src/share/classes/com/sun/tools/classfile/ExtendedAnnotation.java - src/share/classes/com/sun/tools/classfile/RuntimeInvisibleTypeAnnotations_attribute.java - src/share/classes/com/sun/tools/classfile/RuntimeTypeAnnotations_attribute.java - src/share/classes/com/sun/tools/classfile/RuntimeVisibleTypeAnnotations_attribute.java ! src/share/classes/com/sun/tools/javac/code/Attribute.java ! src/share/classes/com/sun/tools/javac/code/Symbol.java - src/share/classes/com/sun/tools/javac/code/TypeAnnotations.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/Flow.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/ClassReader.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/processing/JavacProcessingEnvironment.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/share/classes/com/sun/tools/javac/tree/Pretty.java ! src/share/classes/com/sun/tools/javac/tree/TreeCopier.java ! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java ! src/share/classes/com/sun/tools/javac/tree/TreeMaker.java ! src/share/classes/com/sun/tools/javac/tree/TreeScanner.java ! src/share/classes/com/sun/tools/javac/tree/TreeTranslator.java ! src/share/classes/com/sun/tools/javap/AnnotationWriter.java ! src/share/classes/com/sun/tools/javap/AttributeWriter.java ! src/share/classes/com/sun/tools/javap/CodeWriter.java ! src/share/classes/com/sun/tools/javap/InstructionDetailWriter.java - src/share/classes/com/sun/tools/javap/TypeAnnotationWriter.java ! test/tools/javac/diags/examples.not-yet.txt From jonathan.gibbons at oracle.com Mon Jan 10 23:08:58 2011 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Mon, 10 Jan 2011 23:08:58 +0000 Subject: hg: jdk7/tl/langtools: 6396503: javac should not require assertions enabled Message-ID: <20110110230900.A161047B35@hg.openjdk.java.net> Changeset: 7c537f4298fb Author: jjg Date: 2011-01-10 15:08 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/7c537f4298fb 6396503: javac should not require assertions enabled Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/Main.java ! src/share/classes/com/sun/tools/javac/code/Attribute.java ! src/share/classes/com/sun/tools/javac/code/Scope.java ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/Flow.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/Resolve.java ! src/share/classes/com/sun/tools/javac/comp/TransTypes.java ! src/share/classes/com/sun/tools/javac/file/ZipFileIndexArchive.java ! src/share/classes/com/sun/tools/javac/jvm/CRTable.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.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/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/parser/Scanner.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! src/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java ! src/share/classes/com/sun/tools/javac/tree/TreeMaker.java ! src/share/classes/com/sun/tools/javac/tree/TreeScanner.java ! src/share/classes/com/sun/tools/javac/util/AbstractDiagnosticFormatter.java + src/share/classes/com/sun/tools/javac/util/Assert.java ! src/share/classes/com/sun/tools/javac/util/Bits.java ! src/share/classes/com/sun/tools/javac/util/Context.java ! src/share/classes/com/sun/tools/javac/util/List.java ! src/share/classes/com/sun/tools/javac/util/UnsharedNameTable.java ! src/share/classes/javax/tools/ToolProvider.java From stuart.marks at oracle.com Tue Jan 11 00:42:51 2011 From: stuart.marks at oracle.com (Stuart Marks) Date: Mon, 10 Jan 2011 16:42:51 -0800 Subject: code review request for 7011095, revert diamond changes in method args Message-ID: <4D2BA78B.7070606@oracle.com> Hi all, This is a followup to the diamond conversion I did for 6880112, reviewed here a few weeks ago [1]. That conversion applied the diamond operator in variable initializers, assignment statements, return statements, and in method arguments. For stylistic reasons we've decided that using diamond in method args isn't necessarily a good idea. The type inference for method args can be quite subtle, and since the diamond operator is supposed to improve brevity and clarity, using it in method args seems counterproductive. Given this, we've decided to pull out the usage of diamond from the places that it was added by 6880112. Here's the webrev: http://cr.openjdk.java.net/~smarks/reviews/7011095/webrev.0/ Thanks! s'marks [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2010-December/005466.html From stuart.marks at oracle.com Tue Jan 11 01:20:26 2011 From: stuart.marks at oracle.com (stuart.marks at oracle.com) Date: Tue, 11 Jan 2011 01:20:26 +0000 Subject: hg: jdk7/tl/jdk: 7005608: diamond conversion of JCA and crypto providers Message-ID: <20110111012043.BEB7A47B3A@hg.openjdk.java.net> Changeset: 2a0ff59928de Author: smarks Date: 2011-01-10 17:06 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/2a0ff59928de 7005608: diamond conversion of JCA and crypto providers Reviewed-by: wetmore ! src/share/classes/java/security/Security.java ! src/share/classes/sun/security/jca/ProviderList.java ! src/share/classes/sun/security/jca/Providers.java ! src/share/classes/sun/security/provider/PolicyFile.java ! src/share/classes/sun/security/provider/Sun.java ! src/share/classes/sun/security/provider/VerificationProvider.java ! src/share/classes/sun/security/provider/X509Factory.java ! src/share/classes/sun/security/rsa/RSACore.java ! src/share/classes/sun/security/rsa/SunRsaSign.java From brian.goetz at oracle.com Tue Jan 11 02:17:22 2011 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 10 Jan 2011 18:17:22 -0800 Subject: Sunbug 6934356: Vector.writeObject() synchronization risks serialization deadlock In-Reply-To: References: <4D0A0D96.7050302@oracle.com> <4D2AF3DE.5060104@oracle.com> Message-ID: <870F6496-C7A8-4A81-BDE1-590EEC07317C@oracle.com> While on the subject of serialization deadlocks in core libraries, Amy Williams and Mike Ernst did a paper (also became Amy's masters thesis) back when Mike was at MIT on static detection of deadlocks and they built a tools which found several deadlocks in the JDK collections. Does anyone recall any bugs from this source being fixed? On Jan 10, 2011, at 2:07 PM, Mike Duigou wrote: > Hi Neil; > > Thanks for the updates. I have posted both this webrev and the Hashtable counterpart on cr.openjdk.java.net: > > Hashtable : http://cr.openjdk.java.net/~mduigou/6927486.1/webrev/ > > Vector : http://cr.openjdk.java.net/~mduigou/6934356.3/webrev/ > > I am confused on one point about the license. The copyright line mentions IBM but then the rest of the initial license comment refers to Oracle. To me, from the file text alone, it is not be clear why Oracle would be legally entitled to offer a license to the code. I defer to more lawyerly types to determine what's correct here. > > The changes and testfiles otherwise look OK to me and I can push them as soon as the license question is resolved. > > Thanks, > > Mike > > On Jan 10 2011, at 07:48 , Neil Richards wrote: > >> On 10 January 2011 11:56, Alan Bateman wrote: >>> Looks okay to me. One minor comment is that you might want to update >>> writeObject's description where it currently reads "It just calls the >>> default writeObject method". A minor nit in the tests is that the date range >>> should be "2010, 2011," rather than "2010-2011". >>> >>> -Alan. >> >> Apologies for seeming to approach the solution asymptotically. >> >> Please find attached a further webrev zip file with modification to >> the writeObject's javadoc and testcases copyright date range. >> >> Please let me know if you find anything further. >> Cheers, >> Neil >> >> -- >> Unless stated above: >> IBM email: neil_richards at uk.ibm.com >> IBM United Kingdom Limited - Registered in England and Wales with number 741598. >> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU >> > From joe.darcy at oracle.com Tue Jan 11 03:27:31 2011 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 10 Jan 2011 19:27:31 -0800 Subject: code review request for 7011095, revert diamond changes in method args In-Reply-To: <4D2BA78B.7070606@oracle.com> References: <4D2BA78B.7070606@oracle.com> Message-ID: <4D2BCE23.7060002@oracle.com> Hi Stuart. Looks good; approved! Thanks, -Joe Stuart Marks wrote: > Hi all, > > This is a followup to the diamond conversion I did for 6880112, > reviewed here a few weeks ago [1]. > > That conversion applied the diamond operator in variable initializers, > assignment statements, return statements, and in method arguments. For > stylistic reasons we've decided that using diamond in method args > isn't necessarily a good idea. The type inference for method args can > be quite subtle, and since the diamond operator is supposed to improve > brevity and clarity, using it in method args seems counterproductive. > > Given this, we've decided to pull out the usage of diamond from the > places that it was added by 6880112. Here's the webrev: > > http://cr.openjdk.java.net/~smarks/reviews/7011095/webrev.0/ > > Thanks! > > s'marks > > > [1] > http://mail.openjdk.java.net/pipermail/core-libs-dev/2010-December/005466.html > > From Alan.Bateman at oracle.com Tue Jan 11 11:21:08 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 11 Jan 2011 11:21:08 +0000 Subject: code review request for 7011095, revert diamond changes in method args In-Reply-To: <4D2BCE23.7060002@oracle.com> References: <4D2BA78B.7070606@oracle.com> <4D2BCE23.7060002@oracle.com> Message-ID: <4D2C3D24.7010103@oracle.com> Joe Darcy wrote: > Hi Stuart. > > Looks good; approved! > > Thanks, > > -Joe Looks good to me too. -Alan. From Alan.Bateman at oracle.com Tue Jan 11 13:47:06 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 11 Jan 2011 13:47:06 +0000 Subject: Sunbug 6934356: Vector.writeObject() synchronization risks serialization deadlock In-Reply-To: <870F6496-C7A8-4A81-BDE1-590EEC07317C@oracle.com> References: <4D0A0D96.7050302@oracle.com> <4D2AF3DE.5060104@oracle.com> <870F6496-C7A8-4A81-BDE1-590EEC07317C@oracle.com> Message-ID: <4D2C5F5A.8010301@oracle.com> Brian Goetz wrote: > While on the subject of serialization deadlocks in core libraries, Amy Williams and Mike Ernst did a paper (also became Amy's masters thesis) back when Mike was at MIT on static detection of deadlocks and they built a tools which found several deadlocks in the JDK collections. Does anyone recall any bugs from this source being fixed? > > I don't have history in this area but I see her M.Sc. is online and sure enough, in section 6.1.1 "As an example, consider java.util.Hashtable. This class can be deadlocked by creating two Hashtable objects and adding each as an element of the other, i.e., by forming a cyclic relationship between the instances." and further on, "all synchronized Collections and combinations of such Collections (e.g., a Vector in a cyclic relationship with a Hashtable) can be dead- locked in a similar fashion". Looks like she was running with JDK 1.4 but I don't think legacy Hashtable or Vector have changed much since then. I see someone actually ran into this with j.u.Properties: 6582568: (coll) Concurrent Hashtable.equals deadlock -Alan. From jonathan.gibbons at oracle.com Tue Jan 11 16:07:21 2011 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Tue, 11 Jan 2011 16:07:21 +0000 Subject: hg: jdk7/tl/langtools: 6993305: starting position of a method without modifiers and with type parameters is incorrect Message-ID: <20110111160725.276BF47B74@hg.openjdk.java.net> Changeset: 17b271281525 Author: jjg Date: 2011-01-11 08:05 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/17b271281525 6993305: starting position of a method without modifiers and with type parameters is incorrect Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java + test/tools/javac/tree/T6993305.java From lance.andersen at oracle.com Tue Jan 11 17:37:12 2011 From: lance.andersen at oracle.com (lance.andersen at oracle.com) Date: Tue, 11 Jan 2011 17:37:12 +0000 Subject: hg: jdk7/tl/jdk: 7000693: java.sql.Timestamp compareTo() issues using low values Message-ID: <20110111173730.9A2D347B78@hg.openjdk.java.net> Changeset: befe813e24d2 Author: lancea Date: 2011-01-11 12:36 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/befe813e24d2 7000693: java.sql.Timestamp compareTo() issues using low values Reviewed-by: okutsu ! src/share/classes/java/sql/Timestamp.java From stuart.marks at oracle.com Tue Jan 11 22:24:24 2011 From: stuart.marks at oracle.com (stuart.marks at oracle.com) Date: Tue, 11 Jan 2011 22:24:24 +0000 Subject: hg: jdk7/tl/jdk: 7011095: revert diamond changes from 6880112 that occur in method args Message-ID: <20110111222434.61AC447B86@hg.openjdk.java.net> Changeset: 6d0217114886 Author: smarks Date: 2011-01-11 13:42 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/6d0217114886 7011095: revert diamond changes from 6880112 that occur in method args Reviewed-by: darcy, alanb ! src/share/classes/com/sun/java/util/jar/pack/BandStructure.java ! src/share/classes/java/io/ObjectStreamClass.java ! src/share/classes/java/lang/StringCoding.java ! src/share/classes/java/util/logging/Logger.java From neil.richards at ngmr.net Wed Jan 12 10:42:50 2011 From: neil.richards at ngmr.net (Neil Richards) Date: Wed, 12 Jan 2011 10:42:50 +0000 Subject: Sunbug 6934356: Vector.writeObject() synchronization risks serialization deadlock In-Reply-To: <4D2B75F4.20309@oracle.com> References: <4D0A0D96.7050302@oracle.com> <4D2AF3DE.5060104@oracle.com> <4D2B75F4.20309@oracle.com> Message-ID: On 10 January 2011 21:11, Alan Bateman wrote: > The update to the javadoc looks fine to me. On the headers then we use the > GPL header on tests (no Classpath Exception). Sorry once again - please find attached with the corrected header for GPL (without Classpath exception). I hope I'm pretty much there now - let me know if you spot anything else. Cheers, Neil -- Unless stated above: IBM email: neil_richards at uk.ibm.com IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- A non-text attachment was scrubbed... Name: webrev.6934356.4.zip Type: application/zip Size: 117040 bytes Desc: not available URL: From neil.richards at ngmr.net Wed Jan 12 11:22:04 2011 From: neil.richards at ngmr.net (Neil Richards) Date: Wed, 12 Jan 2011 11:22:04 +0000 Subject: Review request for 6927486: Deadlock in legacy Hashtable writeObject() In-Reply-To: <4D2AFCAD.2000304@oracle.com> References: <4D2473E9.4010600@oracle.com> <4D2AFCAD.2000304@oracle.com> Message-ID: On 10 January 2011 12:33, Alan Bateman wrote: > I hate bringing up code style/conventions (as it only starts wars) but you > might want to check the "implements Serializable" at L76 of > SerializationDeadlock.java as it looks like it's not indented. Same thing > with the "throws IOException" as line 82. I can't tell from the webrev if > this is due to tabs or something else but I noticed it in the webrev for the > Vector fix too. Please find attached a new and improved webrev zip file with: - Amended, consistent indentation - Use of the diamond operator were applicable - GPL headers in testcases (ie. "Classpath" exception removed) - Corrected formatting of copyright statement in testcases Hopefully it's now hot to trot (aka good to go). Please let me know if you see anything else, Thanks, Neil -- Unless stated above: IBM email: neil_richards at uk.ibm.com IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- A non-text attachment was scrubbed... Name: webrev.6927486.2.zip Type: application/zip Size: 115696 bytes Desc: not available URL: From chris.hegarty at oracle.com Wed Jan 12 14:42:07 2011 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Wed, 12 Jan 2011 14:42:07 +0000 Subject: hg: jdk7/tl/jdk: 7005424: Resync java.util.concurrent classes with Dougs CVS - Jan 2011 Message-ID: <20110112144218.4BB9A47BB3@hg.openjdk.java.net> Changeset: cb3ecb5e4ce5 Author: dl Date: 2011-01-12 14:40 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/cb3ecb5e4ce5 7005424: Resync java.util.concurrent classes with Dougs CVS - Jan 2011 Reviewed-by: dholmes, chegar, mduigou ! src/share/classes/java/util/Collections.java ! src/share/classes/java/util/LinkedList.java ! src/share/classes/java/util/concurrent/ArrayBlockingQueue.java ! src/share/classes/java/util/concurrent/ConcurrentLinkedDeque.java ! src/share/classes/java/util/concurrent/ConcurrentLinkedQueue.java ! src/share/classes/java/util/concurrent/ConcurrentSkipListMap.java ! src/share/classes/java/util/concurrent/CopyOnWriteArrayList.java ! src/share/classes/java/util/concurrent/ForkJoinPool.java ! src/share/classes/java/util/concurrent/ForkJoinTask.java ! src/share/classes/java/util/concurrent/ForkJoinWorkerThread.java ! src/share/classes/java/util/concurrent/LinkedBlockingDeque.java ! src/share/classes/java/util/concurrent/LinkedBlockingQueue.java ! src/share/classes/java/util/concurrent/LinkedTransferQueue.java ! src/share/classes/java/util/concurrent/Phaser.java ! src/share/classes/java/util/concurrent/PriorityBlockingQueue.java ! src/share/classes/java/util/concurrent/ScheduledThreadPoolExecutor.java ! src/share/classes/java/util/concurrent/SynchronousQueue.java ! src/share/classes/java/util/concurrent/ThreadPoolExecutor.java ! src/share/classes/java/util/concurrent/atomic/AtomicIntegerArray.java ! src/share/classes/java/util/concurrent/atomic/AtomicLongArray.java ! src/share/classes/java/util/concurrent/atomic/AtomicMarkableReference.java ! src/share/classes/java/util/concurrent/atomic/AtomicReferenceArray.java ! src/share/classes/java/util/concurrent/atomic/AtomicStampedReference.java ! src/share/classes/java/util/concurrent/locks/Condition.java ! test/ProblemList.txt ! test/java/util/WeakHashMap/GCDuringIteration.java ! test/java/util/concurrent/BlockingQueue/CancelledProducerConsumerLoops.java ! test/java/util/concurrent/BlockingQueue/MultipleProducersSingleConsumerLoops.java ! test/java/util/concurrent/BlockingQueue/ProducerConsumerLoops.java ! test/java/util/concurrent/BlockingQueue/SingleProducerMultipleConsumerLoops.java ! test/java/util/concurrent/ConcurrentQueues/IteratorWeakConsistency.java ! test/java/util/concurrent/Executors/AutoShutdown.java ! test/java/util/concurrent/Phaser/Basic.java + test/java/util/concurrent/Phaser/FickleRegister.java + test/java/util/concurrent/Phaser/PhaseOverflow.java + test/java/util/concurrent/Phaser/TieredArriveLoops.java ! test/java/util/concurrent/ThreadPoolExecutor/CoreThreadTimeOut.java From lvjing at linux.vnet.ibm.com Wed Jan 12 15:53:26 2011 From: lvjing at linux.vnet.ibm.com (Jing LV) Date: Wed, 12 Jan 2011 23:53:26 +0800 Subject: A HashMap bug with a Proxy value? Message-ID: <4D2DCE76.4000108@linux.vnet.ibm.com> Hello everyone, (As I am new in OpenJDK, please tell me if I post on the wrong mailing-list). I find an odd behaviour of HashMap. If we put a value which is an instance of Proxy, it would return false while checking containsValue(proxyinstance). I checked use Proxy instance as a key, it works well. I suppose this is a bug of HashMap. By reading the code closely, I find the problem was that, for Proxy instance, Proxy.equals(Proxy) may return false (there are many discussions on this already). HashMap.containsKey() will check if there is a key in the map equals and/or the same with the given key(so it bypass equals check) with getEntry() method but HashMap.containsValue() does not. So a quick fix will be: check there is a value in the map that equals and/or the same with the given value. I'd like to report this bug to bugzilla of openjdk, with my testcase and patch. Please tell me if any comments. Thanks a lot. Best wishes! Jing LV From brian.goetz at oracle.com Wed Jan 12 16:22:14 2011 From: brian.goetz at oracle.com (Brian Goetz) Date: Wed, 12 Jan 2011 11:22:14 -0500 Subject: Sunbug 6934356: Vector.writeObject() synchronization risks serialization deadlock In-Reply-To: <4D2C5F5A.8010301@oracle.com> References: <4D0A0D96.7050302@oracle.com> <4D2AF3DE.5060104@oracle.com> <870F6496-C7A8-4A81-BDE1-590EEC07317C@oracle.com> <4D2C5F5A.8010301@oracle.com> Message-ID: <4D2DD536.8090901@oracle.com> Yes, that's the one. Nothing to do with serialization, just a plain old deadlock. I believe this can happen with ordinary collections wrapped with synchronizedXxx() as well? But I don't think these admit an easy fix. On 1/11/2011 8:47 AM, Alan Bateman wrote: > Brian Goetz wrote: >> While on the subject of serialization deadlocks in core libraries, Amy >> Williams and Mike Ernst did a paper (also became Amy's masters thesis) >> back when Mike was at MIT on static detection of deadlocks and they >> built a tools which found several deadlocks in the JDK collections. >> Does anyone recall any bugs from this source being fixed? > I don't have history in this area but I see her M.Sc. is online and sure > enough, in section 6.1.1 "As an example, consider java.util.Hashtable. > This class can be deadlocked by creating two Hashtable objects and > adding each as an element of the other, i.e., by forming a cyclic > relationship between the instances." and further on, "all synchronized > Collections and combinations of such Collections (e.g., a Vector in a > cyclic relationship with a Hashtable) can be dead- locked in a similar > fashion". Looks like she was running with JDK 1.4 but I don't think > legacy Hashtable or Vector have changed much since then. I see someone > actually ran into this with j.u.Properties: > 6582568: (coll) Concurrent Hashtable.equals deadlock > > -Alan. From chris.hegarty at oracle.com Wed Jan 12 16:43:02 2011 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 12 Jan 2011 16:43:02 +0000 Subject: A HashMap bug with a Proxy value? In-Reply-To: <4D2DCE76.4000108@linux.vnet.ibm.com> References: <4D2DCE76.4000108@linux.vnet.ibm.com> Message-ID: <4D2DDA16.5070903@oracle.com> Are you referring to java.net.Proxy? Proxy.equals depends on the resolution of its address. Address resolution could change over time, depending on the caching policy. java.net.URL has a similar issue. Strangely,I would have expected containsValue and containsKey to behave in a similar fashion. I think the specification for these methods is very clear, they should use equals(). I'm not sure if containsKey is correct if it accepts key equality. -Chris On 01/12/11 03:53 PM, Jing LV wrote: > Hello everyone, > > (As I am new in OpenJDK, please tell me if I post on the wrong > mailing-list). > I find an odd behaviour of HashMap. If we put a value which is an > instance of Proxy, it would return false while checking > containsValue(proxyinstance). I checked use Proxy instance as a key, it > works well. > I suppose this is a bug of HashMap. By reading the code closely, I find > the problem was that, for Proxy instance, Proxy.equals(Proxy) may return > false (there are many discussions on this already). > HashMap.containsKey() will check if there is a key in the map equals > and/or the same with the given key(so it bypass equals check) with > getEntry() method but HashMap.containsValue() does not. So a quick fix > will be: check there is a value in the map that equals and/or the same > with the given value. > > I'd like to report this bug to bugzilla of openjdk, with my testcase and > patch. Please tell me if any comments. Thanks a lot. > > Best wishes! > Jing LV > From david.lloyd at redhat.com Wed Jan 12 16:56:11 2011 From: david.lloyd at redhat.com (David M. Lloyd) Date: Wed, 12 Jan 2011 10:56:11 -0600 Subject: A HashMap bug with a Proxy value? In-Reply-To: <4D2DDA16.5070903@oracle.com> References: <4D2DCE76.4000108@linux.vnet.ibm.com> <4D2DDA16.5070903@oracle.com> Message-ID: <4D2DDD2B.1020306@redhat.com> In my experience, the following are true: 1. Usage of any object has a hash key whose equals() result depends on external or mutable factors should never be used as a hash key for any reason. 2. Any object class for which, when given two instances "a" and "b", a == b is true but a.equals(b) is false is incorrectly implementing .equals(). 3. Any object whose equals() or hashCode() method implementation performs network activity (e.g. a DNS request) is defective by design. This includes java.net.URL as well as java.net.Proxy and any other JDK classes which have these unfortunate design errors. On 01/12/2011 10:43 AM, Chris Hegarty wrote: > Are you referring to java.net.Proxy? Proxy.equals depends on the > resolution of its address. Address resolution could change over time, > depending on the caching policy. java.net.URL has a similar issue. > > Strangely,I would have expected containsValue and containsKey to behave > in a similar fashion. I think the specification for these methods is > very clear, they should use equals(). I'm not sure if containsKey is > correct if it accepts key equality. > > -Chris > > On 01/12/11 03:53 PM, Jing LV wrote: >> Hello everyone, >> >> (As I am new in OpenJDK, please tell me if I post on the wrong >> mailing-list). >> I find an odd behaviour of HashMap. If we put a value which is an >> instance of Proxy, it would return false while checking >> containsValue(proxyinstance). I checked use Proxy instance as a key, it >> works well. >> I suppose this is a bug of HashMap. By reading the code closely, I find >> the problem was that, for Proxy instance, Proxy.equals(Proxy) may return >> false (there are many discussions on this already). >> HashMap.containsKey() will check if there is a key in the map equals >> and/or the same with the given key(so it bypass equals check) with >> getEntry() method but HashMap.containsValue() does not. So a quick fix >> will be: check there is a value in the map that equals and/or the same >> with the given value. >> >> I'd like to report this bug to bugzilla of openjdk, with my testcase and >> patch. Please tell me if any comments. Thanks a lot. >> >> Best wishes! >> Jing LV >> -- - DML From Alan.Bateman at oracle.com Wed Jan 12 16:59:10 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 12 Jan 2011 16:59:10 +0000 Subject: A HashMap bug with a Proxy value? In-Reply-To: <4D2DDA16.5070903@oracle.com> References: <4D2DCE76.4000108@linux.vnet.ibm.com> <4D2DDA16.5070903@oracle.com> Message-ID: <4D2DDDDE.4090206@oracle.com> Chris Hegarty wrote: > Are you referring to java.net.Proxy? Proxy.equals depends on the > resolution of its address. Address resolution could change over time, > depending on the caching policy. java.net.URL has a similar issue. > > Strangely,I would have expected containsValue and containsKey to behave > in a similar fashion. I think the specification for these methods is > very clear, they should use equals(). I'm not sure if containsKey is > correct if it accepts key equality. > > -Chris > I assume he is talking about java.lang.reflect.Proxy as it forwards the hashCode and equals methods to the invocation handler. -Alan From stuart.marks at oracle.com Wed Jan 12 22:08:54 2011 From: stuart.marks at oracle.com (stuart.marks at oracle.com) Date: Wed, 12 Jan 2011 22:08:54 +0000 Subject: hg: jdk7/tl/jdk: 7008713: diamond conversion of kerberos5 and security tools Message-ID: <20110112220904.CB17C47BC6@hg.openjdk.java.net> Changeset: a5a22f93e4c5 Author: smarks Date: 2011-01-12 13:52 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/a5a22f93e4c5 7008713: diamond conversion of kerberos5 and security tools Reviewed-by: weijun ! src/share/classes/sun/security/krb5/Config.java ! src/share/classes/sun/security/krb5/KdcComm.java ! src/share/classes/sun/security/krb5/PrincipalName.java ! src/share/classes/sun/security/krb5/Realm.java ! src/share/classes/sun/security/krb5/internal/Authenticator.java ! src/share/classes/sun/security/krb5/internal/AuthorizationData.java ! src/share/classes/sun/security/krb5/internal/EncAPRepPart.java ! src/share/classes/sun/security/krb5/internal/HostAddresses.java ! src/share/classes/sun/security/krb5/internal/KDCReq.java ! src/share/classes/sun/security/krb5/internal/KDCReqBody.java ! src/share/classes/sun/security/krb5/internal/KRBCred.java ! src/share/classes/sun/security/krb5/internal/KRBError.java ! src/share/classes/sun/security/krb5/internal/KrbCredInfo.java ! src/share/classes/sun/security/krb5/internal/LastReq.java ! src/share/classes/sun/security/krb5/internal/ccache/FileCredentialsCache.java ! src/share/classes/sun/security/krb5/internal/crypto/EType.java ! src/share/classes/sun/security/krb5/internal/ktab/KeyTab.java ! src/share/classes/sun/security/tools/JarSigner.java ! src/share/classes/sun/security/tools/KeyTool.java ! src/share/classes/sun/security/tools/policytool/PolicyTool.java ! test/sun/security/krb5/IPv6.java ! test/sun/security/krb5/auto/CleanState.java ! test/sun/security/krb5/auto/Context.java ! test/sun/security/krb5/auto/HttpNegotiateServer.java ! test/sun/security/krb5/auto/KDC.java ! test/sun/security/krb5/auto/LoginModuleOptions.java ! test/sun/security/krb5/tools/KtabCheck.java From keith.mcguigan at oracle.com Thu Jan 13 04:14:33 2011 From: keith.mcguigan at oracle.com (keith.mcguigan at oracle.com) Date: Thu, 13 Jan 2011 04:14:33 +0000 Subject: hg: jdk7/tl/jdk: 2 new changesets Message-ID: <20110113041515.C12E747BD8@hg.openjdk.java.net> Changeset: f5c0b3cbee2f Author: kamg Date: 2011-01-12 11:47 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f5c0b3cbee2f 6436034: Instance filter doesn't filter event if it occurs in native method Summary: Use 'GetLocalInstance' JVMTI extension if it exists Reviewed-by: coleenp, dcubed ! src/share/back/debugInit.c ! src/share/back/eventFilter.c ! src/share/instrument/JPLISAgent.c ! src/share/javavm/export/jvmti.h + test/com/sun/jdi/NativeInstanceFilter.java + test/com/sun/jdi/NativeInstanceFilterTarg.java Changeset: 295f6b861c12 Author: kamg Date: 2011-01-12 15:27 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/295f6b861c12 Merge From lvjing at linux.vnet.ibm.com Thu Jan 13 06:06:20 2011 From: lvjing at linux.vnet.ibm.com (Jing LV) Date: Thu, 13 Jan 2011 14:06:20 +0800 Subject: A HashMap bug with a Proxy value? In-Reply-To: <4D2DDDDE.4090206@oracle.com> References: <4D2DCE76.4000108@linux.vnet.ibm.com> <4D2DDA16.5070903@oracle.com> <4D2DDDDE.4090206@oracle.com> Message-ID: <4D2E965C.5080403@linux.vnet.ibm.com> Hi, Chris, David and Alan, thanks for comments. Yes I was talking about the java.lang.reflect.Proxy, and proxy.equals(proxy) will return false if equals() (in InvocationHandler) is not well overriden. There is some solution on this problem (on spec. etc. ). However but for common developers (e.g J2EE developer may use Proxy usually) may not care about that. I believe David's experience 2 2. Any object class for which, when given two instances "a" and "b", a == b is true but a.equals(b) is false is incorrectly implementing .equals(). is true. I wonder the design for Proxy and InvocationHandler can be enhanced by creating a default equals/toString/hashCode implementation for Proxy correctly, not ask developers to do it again and again whenever he uses Proxy. Anyway, this may be another story. I think for HashMap, it may be benefit to check "==" as well as equals in containsValue() (as containsKey already do) which is a quick solution to resolve such problems. Any idea? ? 2011-1-13 0:59, Alan Bateman ??: > Chris Hegarty wrote: >> Are you referring to java.net.Proxy? Proxy.equals depends on the >> resolution of its address. Address resolution could change over time, >> depending on the caching policy. java.net.URL has a similar issue. >> >> Strangely,I would have expected containsValue and containsKey to behave >> in a similar fashion. I think the specification for these methods is >> very clear, they should use equals(). I'm not sure if containsKey is >> correct if it accepts key equality. >> >> -Chris > I assume he is talking about java.lang.reflect.Proxy as it forwards > the hashCode and equals methods to the invocation handler. > > -Alan From pcj at roundroom.net Thu Jan 13 06:31:47 2011 From: pcj at roundroom.net (Peter Jones) Date: Thu, 13 Jan 2011 01:31:47 -0500 Subject: Sunbug 6934356: Vector.writeObject() synchronization risks serialization deadlock In-Reply-To: References: <4D0A0D96.7050302@oracle.com> <4D2AF3DE.5060104@oracle.com> <4D2B75F4.20309@oracle.com> Message-ID: <61A4144A-0302-466D-A676-586EC6D6AB62@roundroom.net> Hello, Sorry for chiming in late here, but I was wondering-- has the performance impact of this change been measured? Many years ago, the performance impact vs. the apparent severity of the bug at the time held back this fix (using PutField). Of course, both sides of that consideration may have changed since then. FWIW, the code change looks correct to me. A style nit: I would drop the "= null" initializer on line 1060-- it is a value that should never be read, so let the compiler enforce that (and then you could declare "data" final as well). Cheers, -- Peter P.S. There is a serialization micro-benchmark framework under test/java/rmi/reliability/benchmark On Jan 12, 2011, at 5:42 AM, Neil Richards wrote: > On 10 January 2011 21:11, Alan Bateman wrote: >> The update to the javadoc looks fine to me. On the headers then we use the >> GPL header on tests (no Classpath Exception). > > Sorry once again - please find attached with the corrected header for > GPL (without Classpath exception). > > I hope I'm pretty much there now - let me know if you spot anything else. > Cheers, > Neil > > -- > Unless stated above: > IBM email: neil_richards at uk.ibm.com > IBM United Kingdom Limited - Registered in England and Wales with number 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > From Alan.Bateman at oracle.com Thu Jan 13 10:34:57 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 13 Jan 2011 10:34:57 +0000 Subject: A HashMap bug with a Proxy value? In-Reply-To: <4D2DDA16.5070903@oracle.com> References: <4D2DCE76.4000108@linux.vnet.ibm.com> <4D2DDA16.5070903@oracle.com> Message-ID: <4D2ED551.4070505@oracle.com> Chris Hegarty wrote: > Are you referring to java.net.Proxy? Proxy.equals depends on the > resolution of its address. Address resolution could change over time, > depending on the caching policy. java.net.URL has a similar issue. > > Just on this, are there issues with java.net.Proxy that should be added to the javadoc? URL is a well known pariah but I didn't know about java.net.Proxy. It looks like its equals depends on the equality of socket addresses but that shouldn't involve lookups, right? -Alan. From chris.hegarty at oracle.com Thu Jan 13 10:44:15 2011 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 13 Jan 2011 10:44:15 +0000 Subject: A HashMap bug with a Proxy value? In-Reply-To: <4D2ED551.4070505@oracle.com> References: <4D2DCE76.4000108@linux.vnet.ibm.com> <4D2DDA16.5070903@oracle.com> <4D2ED551.4070505@oracle.com> Message-ID: <4D2ED77F.7030806@oracle.com> On 01/13/11 10:34 AM, Alan Bateman wrote: > Chris Hegarty wrote: >> Are you referring to java.net.Proxy? Proxy.equals depends on the >> resolution of its address. Address resolution could change over time, >> depending on the caching policy. java.net.URL has a similar issue. >> > Just on this, are there issues with java.net.Proxy that should be added > to the javadoc? URL is a well known pariah but I didn't know about > java.net.Proxy. It looks like its equals depends on the equality of > socket addresses but that shouldn't involve lookups, right? I think I may have jumped the gun here. I was thinking that unresolved InetSocketAddresses would need to be resolved, but this doesn't appear to be the case. -Chris. > > -Alan. From michael.x.mcmahon at oracle.com Thu Jan 13 11:04:15 2011 From: michael.x.mcmahon at oracle.com (michael.x.mcmahon at oracle.com) Date: Thu, 13 Jan 2011 11:04:15 +0000 Subject: hg: jdk7/tl/jdk: 2 new changesets Message-ID: <20110113110446.11CD447BE8@hg.openjdk.java.net> Changeset: 538f913777cf Author: michaelm Date: 2011-01-13 11:01 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/538f913777cf 6896088: URLClassLoader.close() apparently not working for JAR URLs on Windows Reviewed-by: chegar ! src/share/classes/sun/misc/URLClassPath.java + test/java/net/URLClassLoader/B6896088.java Changeset: 9f265d55c1c4 Author: michaelm Date: 2011-01-13 11:02 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/9f265d55c1c4 Merge From chris.hegarty at oracle.com Thu Jan 13 13:30:26 2011 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Thu, 13 Jan 2011 13:30:26 +0000 Subject: hg: jdk7/tl/jdk: 6964547: Impossible to set useV4 in SocksSocketImpl Message-ID: <20110113133042.D42E447BF0@hg.openjdk.java.net> Changeset: 694951adefec Author: chegar Date: 2011-01-13 13:24 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/694951adefec 6964547: Impossible to set useV4 in SocksSocketImpl Summary: Add socksProxyVersion property Reviewed-by: alanb, michaelm ! make/sun/net/FILES_java.gmk ! src/share/classes/java/io/PrintStream.java ! src/share/classes/java/net/SocksSocketImpl.java ! src/share/classes/java/net/doc-files/net-properties.html + src/share/classes/sun/net/SocksProxy.java ! src/share/classes/sun/net/spi/DefaultProxySelector.java + test/java/net/Socks/SocksProxyVersion.java From michael.x.mcmahon at oracle.com Thu Jan 13 14:42:22 2011 From: michael.x.mcmahon at oracle.com (michael.x.mcmahon at oracle.com) Date: Thu, 13 Jan 2011 14:42:22 +0000 Subject: hg: jdk7/tl/jdk: 3 new changesets Message-ID: <20110113144251.51A3C47BF3@hg.openjdk.java.net> Changeset: 38729ba6eb4f Author: michaelm Date: 2011-01-12 15:05 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/38729ba6eb4f 6829919: URLClassLoader.close() doesn't close resource file if getResourceAsStream(...) was called before Reviewed-by: chegar ! src/share/classes/java/net/URLClassLoader.java ! test/java/net/URLClassLoader/closetest/CloseTest.java + test/java/net/URLClassLoader/closetest/Common.java + test/java/net/URLClassLoader/closetest/GetResourceAsStream.java + test/java/net/URLClassLoader/closetest/build2.sh Changeset: ed390b2e5ca4 Author: michaelm Date: 2011-01-13 11:10 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/ed390b2e5ca4 Merge Changeset: 067b5f603fc8 Author: michaelm Date: 2011-01-13 14:41 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/067b5f603fc8 Merge From michael.x.mcmahon at oracle.com Thu Jan 13 16:37:49 2011 From: michael.x.mcmahon at oracle.com (michael.x.mcmahon at oracle.com) Date: Thu, 13 Jan 2011 16:37:49 +0000 Subject: hg: jdk7/tl/jdk: 7003398: NetworkInterface equals() and hashCode() behaviors depend on permissions granted Message-ID: <20110113163759.376EC47BF8@hg.openjdk.java.net> Changeset: 3215b22cd90e Author: michaelm Date: 2011-01-13 16:33 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/3215b22cd90e 7003398: NetworkInterface equals() and hashCode() behaviors depend on permissions granted Reviewed-by: chegar, alanb ! src/share/classes/java/net/NetworkInterface.java + test/java/net/NetworkInterface/Equals.java From jason_mehrens at hotmail.com Thu Jan 13 17:46:35 2011 From: jason_mehrens at hotmail.com (Jason Mehrens) Date: Thu, 13 Jan 2011 11:46:35 -0600 Subject: A HashMap bug with a Proxy value? In-Reply-To: <4D2E965C.5080403@linux.vnet.ibm.com> References: <4D2DCE76.4000108@linux.vnet.ibm.com>,<4D2DDA16.5070903@oracle.com> <4D2DDDDE.4090206@oracle.com>,<4D2E965C.5080403@linux.vnet.ibm.com> Message-ID: > I wonder the design for Proxy and InvocationHandler can be > enhanced by creating a default equals/toString/hashCode implementation > for Proxy correctly, not ask developers to do it again and again > whenever he uses Proxy. Anyway, this may be another story. See: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4652876 The ProxyGenerator could safely add byte codes to equals/compareTo/compare that: 1. Handle the null case per contract: false, NPE, call handler. 2. Proxy == Argument: true, 0, 0 3. Proxy.getClass() == Argument.getClass() && Proxy.h == Proxy.getClass().cast(argument).h: true,0,0 The problem is short circuit operations nor return value overrides are not allowed per the Proxy contract: "A method invocation on a proxy instance through one of its proxy interfaces will be dispatched to the invoke method of the instance's invocation handler...the result that it returns will be returned as the result of the method invocation on the proxy instance." I think for most equality checks, short circuit would be for the most part safe since most Collections all ready do such checks but, it requires a change to the Proxy contract which presents a compatibility problem. > I think for HashMap, it may be benefit to check "==" as well as equals > in containsValue() (as containsKey already do) which is a quick solution > to resolve such problems. Seems like the identity check would be a win: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6486197 Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonathan.gibbons at oracle.com Thu Jan 13 19:48:42 2011 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Thu, 13 Jan 2011 19:48:42 +0000 Subject: hg: jdk7/tl/langtools: 6430241: Hard to disable symbol file feature through API Message-ID: <20110113194846.097C147C06@hg.openjdk.java.net> Changeset: d33d8c381aa1 Author: jjg Date: 2011-01-13 11:48 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/d33d8c381aa1 6430241: Hard to disable symbol file feature through API Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/file/JavacFileManager.java ! src/share/classes/com/sun/tools/javac/file/Paths.java + test/tools/javac/api/T6430241.java From brian.goetz at oracle.com Thu Jan 13 20:06:54 2011 From: brian.goetz at oracle.com (Brian Goetz) Date: Thu, 13 Jan 2011 15:06:54 -0500 Subject: Objects.nonNull() Message-ID: <4D2F5B5E.1040904@oracle.com> I relatively recently discovered the existence of the new java.util.Objects class, a repository of useful methods that people end up rewriting endlessly for each project in classes named Util and such. Most of the methods have to do with centralizing null handling (such as Objects.hashCode(), which returns 0 if the object reference is zero.) I have one concern about naming, and that is of the nonNull(Object) methods: /** * Checks that the specified object reference is not {@code null}. This * method is designed primarily for doing parameter validation in methods * and constructors, as demonstrated below: * 
      * public Foo(Bar bar) {
      *     this.bar = Objects.nonNull(bar);
      * }
      *
* * @param obj the object reference to check for nullity * @param the type of the reference * @return {@code obj} if not {@code null} * @throws NullPointerException if {@code obj} is {@code null} */ public static T nonNull(T obj) { if (obj == null) throw new NullPointerException(); return obj; } Most of the other methods in this class are of the form "do the right thing if the object is null (or an array)", but this one is "throw an exception if the object is null." The intent is clear -- it is for simplifying fail-fast behavior by checking for nullity early -- but the name is wrong. This is bad for two reasons: (a) it is confusing and (b) it forecloses on using the name nonNull() for what most people expect it to do -- which is provide a reasonable default. I propose to change these to be called checkNonNull(), so their null-checking behavior is obvious to readers of code, and to leave room to LATER provide methods like public static T nonNull(T[] obj) { return (obj == null) ? (T[]) ZERO_LENGTH_ARRAY : obj; } and public static T nonNull(String obj) { return (obj == null) ? "" : obj; } etc. It is late but since this class was added in 7, we have a small window to not have to deal with this forever. Now taking objections. Going once... From david.lloyd at redhat.com Thu Jan 13 20:21:02 2011 From: david.lloyd at redhat.com (David M. Lloyd) Date: Thu, 13 Jan 2011 14:21:02 -0600 Subject: Objects.nonNull() In-Reply-To: <4D2F5B5E.1040904@oracle.com> References: <4D2F5B5E.1040904@oracle.com> Message-ID: <4D2F5EAE.9010302@redhat.com> On 01/13/2011 02:06 PM, Brian Goetz wrote: > I propose to change these to be called checkNonNull(), so their > null-checking behavior is obvious to readers of code I agree with this, but... > and to leave room > to LATER provide methods like > > public static T nonNull(T[] obj) { > return (obj == null) ? (T[]) ZERO_LENGTH_ARRAY : obj; > } I assume you meant: public static T[] nonNull(T[] obj) { ... This probably won't fly because ZERO_LENGTH_ARRAY can only be an Object[], so this method would have to return Object[] else you'll get CCEs. > and > public static T nonNull(String obj) { > return (obj == null) ? "" : obj; > } > etc. I don't know, this doesn't feel right to me. It would probably make more sense to have a: public static T defaulted(T test, T defVal) { return test == null ? defVal : test; } This would cover both of the above cases and more. -- - DML From mark.reinhold at oracle.com Thu Jan 13 20:33:58 2011 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 13 Jan 2011 12:33:58 -0800 Subject: Objects.nonNull() In-Reply-To: brian.goetz@oracle.com; Thu, 13 Jan 2011 15:06:54 EST; <4D2F5B5E.1040904@oracle.com> Message-ID: <20110113203358.93B662999@eggemoggin.niobe.net> > Date: Thu, 13 Jan 2011 15:06:54 -0500 > From: brian.goetz at oracle.com > ... > > I propose to change these to be called checkNonNull(), so their null-checking > behavior is obvious to readers of code, ... An even better name would be ensureNonNull(), which captures the notion that if the method returns then the condition is ensured. Just a "check" leaves open the possibility of some less drastic behavior, such as merely returning a boolean. (For what it's worth, the ensureFoo() pattern is already used elsewhere.) - Mark From tom.hawtin at oracle.com Thu Jan 13 21:12:26 2011 From: tom.hawtin at oracle.com (Tom Hawtin) Date: Thu, 13 Jan 2011 21:12:26 +0000 Subject: Objects.nonNull() In-Reply-To: <4D2F5B5E.1040904@oracle.com> References: <4D2F5B5E.1040904@oracle.com> Message-ID: <4D2F6ABA.4060101@oracle.com> On 13/01/2011 20:06, Brian Goetz wrote: > Most of the other methods in this class are of the form "do the right > thing if the object is null (or an array)", but this one is "throw an > exception if the object is null." The intent is clear -- it is for > simplifying fail-fast behavior by checking for nullity early -- but the > name is wrong. This is bad for two reasons: (a) it is confusing and (b) > it forecloses on using the name nonNull() for what most people expect it > to do -- which is provide a reasonable default. I think this is completely the wrong way around. On encountering a null the right thing is to throw an NPE. Don't make Sir C.A.R. Hoare's billion-dollar mistake worse. Perhaps the carpet-sweeping methods should be renamed, or put into an appropriately named class. Tom From pbenedict at apache.org Thu Jan 13 22:09:57 2011 From: pbenedict at apache.org (Paul Benedict) Date: Thu, 13 Jan 2011 16:09:57 -0600 Subject: Objects.nonNull() In-Reply-To: <4D2F6ABA.4060101@oracle.com> References: <4D2F5B5E.1040904@oracle.com> <4D2F6ABA.4060101@oracle.com> Message-ID: Maybe you have a nonNull() that throws NPE, and a nonNullSafe() ? On Thu, Jan 13, 2011 at 3:12 PM, Tom Hawtin wrote: > On 13/01/2011 20:06, Brian Goetz wrote: > > Most of the other methods in this class are of the form "do the right >> thing if the object is null (or an array)", but this one is "throw an >> exception if the object is null." The intent is clear -- it is for >> simplifying fail-fast behavior by checking for nullity early -- but the >> name is wrong. This is bad for two reasons: (a) it is confusing and (b) >> it forecloses on using the name nonNull() for what most people expect it >> to do -- which is provide a reasonable default. >> > > I think this is completely the wrong way around. On encountering a null the > right thing is to throw an NPE. Don't make Sir C.A.R. Hoare's billion-dollar > mistake worse. > > Perhaps the carpet-sweeping methods should be renamed, or put into an > appropriately named class. > > Tom > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.goetz at oracle.com Thu Jan 13 22:11:37 2011 From: brian.goetz at oracle.com (Brian Goetz) Date: Thu, 13 Jan 2011 17:11:37 -0500 Subject: Objects.nonNull() In-Reply-To: <4D2F6ABA.4060101@oracle.com> References: <4D2F5B5E.1040904@oracle.com> <4D2F6ABA.4060101@oracle.com> Message-ID: <4D2F7899.6010605@oracle.com> I disagree with Tom here. We have *already* made the billion dollar mistake, and we can't eliminate that headache (but we can provide easier access to aspirin.) Java developers are *constantly* writing methods like the suggested carpet-sweeping nonNull() to work around this (and some of the Objects methods already do this, like hashCode()). If I had to guess how many times this exact method had been written across all the Java code in the world, I would be quite surprised if its common logarithm were less than 4. Rising out of the rathole, it seems there is no objection to renaming nonNull() to checkNonNull or ensureNonNull(). I believe this is clearer, and this preserves the opportunity to dive further down the carpet-sweeping rathole later. One last question for Mark on the ensureXxx() convention: methods like ensureXxx() sometimes mean "make this true" (like ensureCapacity() in collections implementations) rather than "barf if it is not true." I'm willing to go either way (both checkNonNull and ensureNonNull better match the actual behavior of the method than plain nonNull) but we might as well pick the right convention. On 1/13/2011 4:12 PM, Tom Hawtin wrote: > On 13/01/2011 20:06, Brian Goetz wrote: > >> Most of the other methods in this class are of the form "do the right >> thing if the object is null (or an array)", but this one is "throw an >> exception if the object is null." The intent is clear -- it is for >> simplifying fail-fast behavior by checking for nullity early -- but the >> name is wrong. This is bad for two reasons: (a) it is confusing and (b) >> it forecloses on using the name nonNull() for what most people expect it >> to do -- which is provide a reasonable default. > > I think this is completely the wrong way around. On encountering a null > the right thing is to throw an NPE. Don't make Sir C.A.R. Hoare's > billion-dollar mistake worse. > > Perhaps the carpet-sweeping methods should be renamed, or put into an > appropriately named class. > > Tom From mike.duigou at oracle.com Thu Jan 13 22:31:49 2011 From: mike.duigou at oracle.com (Mike Duigou) Date: Thu, 13 Jan 2011 14:31:49 -0800 Subject: Sunbug 6934356: Vector.writeObject() synchronization risks serialization deadlock In-Reply-To: <61A4144A-0302-466D-A676-586EC6D6AB62@roundroom.net> References: <4D0A0D96.7050302@oracle.com> <4D2AF3DE.5060104@oracle.com> <4D2B75F4.20309@oracle.com> <61A4144A-0302-466D-A676-586EC6D6AB62@roundroom.net> Message-ID: I know that on the Oracle side we did internally discuss the potential performance impact. The main performance concern seems to be the extra GC work from creating the array of values (or the entry stack in the case of Hashtable). We decided though that for most collections the small size and short lifetime of the extra objects would mean that they would never escape the eden generation and would be quickly and efficiently GCed. We don't expect that this change will result in only insignificant (it's not "free") performance degradation whether considered from a microbenchmark perspective or from an overall system performance perspective. Alternative opinions, analysis and insights are, of course, welcome. Mike On Jan 12 2011, at 22:31 , Peter Jones wrote: > Hello, > > Sorry for chiming in late here, but I was wondering-- has the performance impact of this change been measured? Many years ago, the performance impact vs. the apparent severity of the bug at the time held back this fix (using PutField). Of course, both sides of that consideration may have changed since then. > > FWIW, the code change looks correct to me. A style nit: I would drop the "= null" initializer on line 1060-- it is a value that should never be read, so let the compiler enforce that (and then you could declare "data" final as well). > > Cheers, > -- Peter > > P.S. There is a serialization micro-benchmark framework under test/java/rmi/reliability/benchmark > > > On Jan 12, 2011, at 5:42 AM, Neil Richards wrote: > >> On 10 January 2011 21:11, Alan Bateman wrote: >>> The update to the javadoc looks fine to me. On the headers then we use the >>> GPL header on tests (no Classpath Exception). >> >> Sorry once again - please find attached with the corrected header for >> GPL (without Classpath exception). >> >> I hope I'm pretty much there now - let me know if you spot anything else. >> Cheers, >> Neil >> >> -- >> Unless stated above: >> IBM email: neil_richards at uk.ibm.com >> IBM United Kingdom Limited - Registered in England and Wales with number 741598. >> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU >> > From forax at univ-mlv.fr Thu Jan 13 22:31:03 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Thu, 13 Jan 2011 23:31:03 +0100 Subject: Objects.nonNull() In-Reply-To: <4D2F7899.6010605@oracle.com> References: <4D2F5B5E.1040904@oracle.com> <4D2F6ABA.4060101@oracle.com> <4D2F7899.6010605@oracle.com> Message-ID: <4D2F7D27.9040506@univ-mlv.fr> On 01/13/2011 11:11 PM, Brian Goetz wrote: > > I disagree with Tom here. We have *already* made the billion dollar > mistake, and we can't eliminate that headache (but we can provide > easier access to aspirin.) Java developers are *constantly* writing > methods like the suggested carpet-sweeping nonNull() to work around > this (and some of the Objects methods already do this, like > hashCode()). If I had to guess how many times this exact method had > been written across all the Java code in the world, I would be quite > surprised if its common logarithm were less than 4. > I disagree. Propagating null is rare if your API doesn't allow to take null as argument. The only place where you need to propagate null is when you output something like in Swing or in the presentation tier of a webapp. Otherwise propagating null is a mistake because it adds layers between the bug and it's appearance. > > Rising out of the rathole, it seems there is no objection to renaming > nonNull() to checkNonNull or ensureNonNull(). I believe this is > clearer, and this preserves the opportunity to dive further down the > carpet-sweeping rathole later. > > One last question for Mark on the ensureXxx() convention: methods like > ensureXxx() sometimes mean "make this true" (like ensureCapacity() in > collections implementations) rather than "barf if it is not true." > I'm willing to go either way (both checkNonNull and ensureNonNull > better match the actual behavior of the method than plain nonNull) but > we might as well pick the right convention. I think I prefer throwIfNull() which is explicit. R?mi > > On 1/13/2011 4:12 PM, Tom Hawtin wrote: >> On 13/01/2011 20:06, Brian Goetz wrote: >> >>> Most of the other methods in this class are of the form "do the right >>> thing if the object is null (or an array)", but this one is "throw an >>> exception if the object is null." The intent is clear -- it is for >>> simplifying fail-fast behavior by checking for nullity early -- but the >>> name is wrong. This is bad for two reasons: (a) it is confusing and (b) >>> it forecloses on using the name nonNull() for what most people >>> expect it >>> to do -- which is provide a reasonable default. >> >> I think this is completely the wrong way around. On encountering a null >> the right thing is to throw an NPE. Don't make Sir C.A.R. Hoare's >> billion-dollar mistake worse. >> >> Perhaps the carpet-sweeping methods should be renamed, or put into an >> appropriately named class. >> >> Tom From brian.goetz at oracle.com Thu Jan 13 22:38:59 2011 From: brian.goetz at oracle.com (Brian Goetz) Date: Thu, 13 Jan 2011 17:38:59 -0500 Subject: Objects.nonNull() In-Reply-To: <4D2F5EAE.9010302@redhat.com> References: <4D2F5B5E.1040904@oracle.com> <4D2F5EAE.9010302@redhat.com> Message-ID: <4D2F7F03.80108@oracle.com> >> and >> public static T nonNull(String obj) { >> return (obj == null) ? "" : obj; >> } >> etc. > > I don't know, this doesn't feel right to me. It would probably make more > sense to have a: > > public static T defaulted(T test, T defVal) { > return test == null ? defVal : test; > } > > This would cover both of the above cases and more. Right, my exposition suffered from my desire to keep it short and not get ratholed on the details of the carpet-sweeping methods (which was unsuccessful.) The above is (clearly) the general case, but in the code bases I've seen this in, its nearly always paired with specific versions for String (default "") and arrays (default empty array.) People use these to simplify cases like if (foo != null) for (Foo f : foo) { ... } to for (Foo f : nonNull(foo)) { ... } It is an extremely common pattern; I've seen it in nearly every nontrivial code base I've worked with. Frequently multiple times in the same code base :( Summarizing, the fail-fast and the carpet-sweeping behavior are both valid and common use cases. The current naming is not only confusing but basically forecloses on ever offering the carpet-sweeping behavior, which, despite objections from some, is something people do all the time. From Ulf.Zibis at gmx.de Thu Jan 13 22:40:05 2011 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Thu, 13 Jan 2011 23:40:05 +0100 Subject: Objects.nonNull() In-Reply-To: <4D2F7D27.9040506@univ-mlv.fr> References: <4D2F5B5E.1040904@oracle.com> <4D2F6ABA.4060101@oracle.com> <4D2F7899.6010605@oracle.com> <4D2F7D27.9040506@univ-mlv.fr> Message-ID: <4D2F7F45.5050209@gmx.de> Am 13.01.2011 23:31, schrieb R?mi Forax: > > I think I prefer throwIfNull() which is explicit. > +1 -Ulf From david.lloyd at redhat.com Thu Jan 13 22:41:49 2011 From: david.lloyd at redhat.com (David M. Lloyd) Date: Thu, 13 Jan 2011 16:41:49 -0600 Subject: Objects.nonNull() In-Reply-To: <4D2F7D27.9040506@univ-mlv.fr> References: <4D2F5B5E.1040904@oracle.com> <4D2F6ABA.4060101@oracle.com> <4D2F7899.6010605@oracle.com> <4D2F7D27.9040506@univ-mlv.fr> Message-ID: <4D2F7FAD.7030403@redhat.com> On 01/13/2011 04:31 PM, R?mi Forax wrote: > On 01/13/2011 11:11 PM, Brian Goetz wrote: >> >> I disagree with Tom here. We have *already* made the billion dollar >> mistake, and we can't eliminate that headache (but we can provide >> easier access to aspirin.) Java developers are *constantly* writing >> methods like the suggested carpet-sweeping nonNull() to work around >> this (and some of the Objects methods already do this, like >> hashCode()). If I had to guess how many times this exact method had >> been written across all the Java code in the world, I would be quite >> surprised if its common logarithm were less than 4. >> > > I disagree. > Propagating null is rare if your API doesn't allow to take null as > argument. > The only place where you need to propagate null is when you output > something like in Swing or > in the presentation tier of a webapp. > Otherwise propagating null is a mistake because it adds layers between > the bug and it's appearance. I disagree with your disagreement. :) A null value very commonly means "not found". Consider such examples as Map.get(). Trying to pretend like null doesn't exist is silly, and trying to pretend that people don't write such methods and count on this functionality is equally silly. If you don't think people should be using null, say so on your blog; don't enforce your opinion on others through core API changes. I for one like null; I think it is damned handy. And I think propagating it is just fine so long as it is documented as a part of the contract of the method. That's an education issue, not a language issue. -- - DML From mark.reinhold at oracle.com Thu Jan 13 22:55:22 2011 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 13 Jan 2011 14:55:22 -0800 Subject: Objects.nonNull() In-Reply-To: brian.goetz@oracle.com; Thu, 13 Jan 2011 17:11:37 EST; <4D2F7899.6010605@oracle.com> Message-ID: <20110113225522.359612999@eggemoggin.niobe.net> > Date: Thu, 13 Jan 2011 17:11:37 -0500 > From: brian.goetz at oracle.com > ... > > One last question for Mark on the ensureXxx() convention: methods like > ensureXxx() sometimes mean "make this true" (like ensureCapacity() in > collections implementations) rather than "barf if it is not true." Right. Actually there are no public, exception-throwing ensureFoo(x) methods, so I withdraw my suggestion. (There are a bunch of private ones.) > I'm willing > to go either way (both checkNonNull and ensureNonNull better match the actual > behavior of the method than plain nonNull) but we might as well pick the right > convention. R?mi's throwIfNull(x) suggestion does capture the precise meaning, though it begs the question of what, exactly, will be thrown. - Mark From David.Holmes at oracle.com Thu Jan 13 23:04:27 2011 From: David.Holmes at oracle.com (David Holmes) Date: Fri, 14 Jan 2011 09:04:27 +1000 Subject: Objects.nonNull() In-Reply-To: <4D2F7D27.9040506@univ-mlv.fr> References: <4D2F5B5E.1040904@oracle.com> <4D2F6ABA.4060101@oracle.com> <4D2F7899.6010605@oracle.com> <4D2F7D27.9040506@univ-mlv.fr> Message-ID: <4D2F84FB.3020806@oracle.com> R?mi Forax said the following on 01/14/11 08:31: > I think I prefer throwIfNull() which is explicit. +1 As to what gets thrown, none of these suggestions make that obvious from their name so I would not be concerned about that. Every Java programmer is very early introduced to NullPointerException. David Holmes > > R?mi > >> >> On 1/13/2011 4:12 PM, Tom Hawtin wrote: >>> On 13/01/2011 20:06, Brian Goetz wrote: >>> >>>> Most of the other methods in this class are of the form "do the right >>>> thing if the object is null (or an array)", but this one is "throw an >>>> exception if the object is null." The intent is clear -- it is for >>>> simplifying fail-fast behavior by checking for nullity early -- but the >>>> name is wrong. This is bad for two reasons: (a) it is confusing and (b) >>>> it forecloses on using the name nonNull() for what most people >>>> expect it >>>> to do -- which is provide a reasonable default. >>> >>> I think this is completely the wrong way around. On encountering a null >>> the right thing is to throw an NPE. Don't make Sir C.A.R. Hoare's >>> billion-dollar mistake worse. >>> >>> Perhaps the carpet-sweeping methods should be renamed, or put into an >>> appropriately named class. >>> >>> Tom > From brian.goetz at oracle.com Thu Jan 13 23:15:30 2011 From: brian.goetz at oracle.com (Brian Goetz) Date: Thu, 13 Jan 2011 18:15:30 -0500 Subject: Objects.nonNull() In-Reply-To: <20110113225522.359612999@eggemoggin.niobe.net> References: <20110113225522.359612999@eggemoggin.niobe.net> Message-ID: <4D2F8792.3070202@oracle.com> >> to go either way (both checkNonNull and ensureNonNull better match the actual >> behavior of the method than plain nonNull) but we might as well pick the right >> convention. > > R?mi's throwIfNull(x) suggestion does capture the precise meaning, > though it begs the question of what, exactly, will be thrown. In either case the Javadoc specifies a @throws clause that will guide readers to the answer on this. Between checkNonNull() and throwIfNull(), I lean towards the former. In any case the answer should be driven by what is more obvious to the reader. So let's look at some typical code: public Moo fooWrapper(String x, String y) { return foo(throwIfNull(x), throwIfNull(y)); } vs public Moo fooWrapper(String x, String y) { return foo(checkNonNull(x), checkNonNull(y)); } Since throwing should be the exceptional path, it feels to me that having throw in the name sets slightly the wrong expectations. (It's sort of like the old MASH episode where one of them is defusing a bomb while the other reads the instructions over the phone: "cut the red wire" (snip) "but first..." (panic ensues).) Its the difference between "proceed if ok" and "blow up if not ok"; both mean the same thing but if OK is the common case, the former seems the more appropriate phrasing. From David.Holmes at oracle.com Thu Jan 13 23:36:42 2011 From: David.Holmes at oracle.com (David Holmes) Date: Fri, 14 Jan 2011 09:36:42 +1000 Subject: Objects.nonNull() In-Reply-To: <4D2F8792.3070202@oracle.com> References: <20110113225522.359612999@eggemoggin.niobe.net> <4D2F8792.3070202@oracle.com> Message-ID: <4D2F8C8A.4040108@oracle.com> Brian Goetz said the following on 01/14/11 09:15: >>> to go either way (both checkNonNull and ensureNonNull better >>> match the actual behavior of the method than plain nonNull) but >>> we might as well pick the right convention. >> >> R?mi's throwIfNull(x) suggestion does capture the precise meaning, >> though it begs the question of what, exactly, will be thrown. > > In either case the Javadoc specifies a @throws clause that will guide > readers to the answer on this. > > Between checkNonNull() and throwIfNull(), I lean towards the former. In > any case the answer should be driven by what is more obvious to the > reader. So let's look at some typical code: > > public Moo fooWrapper(String x, String y) { > return foo(throwIfNull(x), throwIfNull(y)); > } > > vs > > public Moo fooWrapper(String x, String y) { > return foo(checkNonNull(x), checkNonNull(y)); > } > > Since throwing should be the exceptional path, it feels to me that > having throw in the name sets slightly the wrong expectations. (It's > sort of like the old MASH episode where one of them is defusing a bomb > while the other reads the instructions over the phone: "cut the red > wire" (snip) "but first..." (panic ensues).) Its the difference between > "proceed if ok" and "blow up if not ok"; both mean the same thing but if > OK is the common case, the former seems the more appropriate phrasing. But the argument was that nonNull (which Josh added by the way) and checkNonNull, don't make it clear as to what happens if it is indeed null. Whether the expected case or not, throwIfNull makes it very clear. I must confess that my +1 for throwIfNull was made before I realized that this method returns the reference - in which case throwIfNull doesn't tell you anything about what happens if it isn't null (the same argument against the original naming). David From forax at univ-mlv.fr Thu Jan 13 23:53:40 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Fri, 14 Jan 2011 00:53:40 +0100 Subject: Objects.nonNull() In-Reply-To: <4D2F7FAD.7030403@redhat.com> References: <4D2F5B5E.1040904@oracle.com> <4D2F6ABA.4060101@oracle.com> <4D2F7899.6010605@oracle.com> <4D2F7D27.9040506@univ-mlv.fr> <4D2F7FAD.7030403@redhat.com> Message-ID: <4D2F9084.9010103@univ-mlv.fr> On 01/13/2011 11:41 PM, David M. Lloyd wrote: > On 01/13/2011 04:31 PM, R?mi Forax wrote: >> On 01/13/2011 11:11 PM, Brian Goetz wrote: >>> >>> I disagree with Tom here. We have *already* made the billion dollar >>> mistake, and we can't eliminate that headache (but we can provide >>> easier access to aspirin.) Java developers are *constantly* writing >>> methods like the suggested carpet-sweeping nonNull() to work around >>> this (and some of the Objects methods already do this, like >>> hashCode()). If I had to guess how many times this exact method had >>> been written across all the Java code in the world, I would be quite >>> surprised if its common logarithm were less than 4. >>> >> >> I disagree. >> Propagating null is rare if your API doesn't allow to take null as >> argument. >> The only place where you need to propagate null is when you output >> something like in Swing or >> in the presentation tier of a webapp. >> Otherwise propagating null is a mistake because it adds layers between >> the bug and it's appearance. > > I disagree with your disagreement. :) > > A null value very commonly means "not found". Consider such examples > as Map.get(). Trying to pretend like null doesn't exist is silly, and > trying to pretend that people don't write such methods and count on > this functionality is equally silly. If you don't think people should > be using null, say so on your blog; don't enforce your opinion on > others through core API changes. I was not clear. I don't pretend that null doesn't exist. Carpet sweeping is not a good idea. As you said, null is used as return value. I have no problem with that. I just pretend that the developer has to put an "if" here and not call a kind of black magic function that will only work with 10 lines examples. > > I for one like null; I think it is damned handy. And I think > propagating it is just fine so long as it is documented as a part of > the contract of the method. That's an education issue, not a language > issue. By documentation, do you mean you use @Nullable and a null typecheker. In that case I agree with you, otherwise it's rare to see the documentation of a field saying that it can be null. So when you modify something you have to follow the reference backward from usage sites. I hate to do that. R?mi From Ulf.Zibis at gmx.de Thu Jan 13 23:57:02 2011 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Fri, 14 Jan 2011 00:57:02 +0100 Subject: Objects.nonNull() In-Reply-To: <4D2F7F03.80108@oracle.com> References: <4D2F5B5E.1040904@oracle.com> <4D2F5EAE.9010302@redhat.com> <4D2F7F03.80108@oracle.com> Message-ID: <4D2F914E.80706@gmx.de> Am 13.01.2011 23:38, schrieb Brian Goetz: > > People use these to simplify cases like > > if (foo != null) > for (Foo f : foo) { ... } > > to > > for (Foo f : nonNull(foo)) { ... } To be honest, I don't understand the real value of nonNull(). If the argument is null, NPE would be thrown anyway. Do I miss something? -Ulf From david.lloyd at redhat.com Thu Jan 13 23:58:36 2011 From: david.lloyd at redhat.com (David M. Lloyd) Date: Thu, 13 Jan 2011 17:58:36 -0600 Subject: Objects.nonNull() In-Reply-To: <4D2F8C8A.4040108@oracle.com> References: <20110113225522.359612999@eggemoggin.niobe.net> <4D2F8792.3070202@oracle.com> <4D2F8C8A.4040108@oracle.com> Message-ID: <4D2F91AC.7030207@redhat.com> On 01/13/2011 05:36 PM, David Holmes wrote: > Brian Goetz said the following on 01/14/11 09:15: >>>> to go either way (both checkNonNull and ensureNonNull better >>>> match the actual behavior of the method than plain nonNull) but >>>> we might as well pick the right convention. >>> >>> R?mi's throwIfNull(x) suggestion does capture the precise meaning, >>> though it begs the question of what, exactly, will be thrown. >> >> In either case the Javadoc specifies a @throws clause that will guide >> readers to the answer on this. >> >> Between checkNonNull() and throwIfNull(), I lean towards the former. >> In any case the answer should be driven by what is more obvious to the >> reader. So let's look at some typical code: >> >> public Moo fooWrapper(String x, String y) { >> return foo(throwIfNull(x), throwIfNull(y)); >> } >> >> vs >> >> public Moo fooWrapper(String x, String y) { >> return foo(checkNonNull(x), checkNonNull(y)); >> } >> >> Since throwing should be the exceptional path, it feels to me that >> having throw in the name sets slightly the wrong expectations. (It's >> sort of like the old MASH episode where one of them is defusing a bomb >> while the other reads the instructions over the phone: "cut the red >> wire" (snip) "but first..." (panic ensues).) Its the difference >> between "proceed if ok" and "blow up if not ok"; both mean the same >> thing but if OK is the common case, the former seems the more >> appropriate phrasing. > > But the argument was that nonNull (which Josh added by the way) and > checkNonNull, don't make it clear as to what happens if it is indeed > null. Whether the expected case or not, throwIfNull makes it very clear. It's plenty clear IMO if the method is declared as: public static T nonNull(T arg) throws NullPointerException and is documented as such. Which it is, btw. For another angle, compare to Class.cast(). It doesn't say that it throws ClassCastException (i.e. throwIfWrongType), it just says what the result is (the cast object). Granted it helps that "cast" is also a verb. Maybe if 'notNull' is not clear enough, 'nullChecked' is more appropriate; it talks about the result of the method rather that the exceptional case. T foo = clazz.cast(nullChecked(bar)); reads pretty well. -- - DML From brian.goetz at oracle.com Fri Jan 14 00:06:24 2011 From: brian.goetz at oracle.com (Brian Goetz) Date: Thu, 13 Jan 2011 19:06:24 -0500 Subject: Objects.nonNull() In-Reply-To: <4D2F914E.80706@gmx.de> References: <4D2F5B5E.1040904@oracle.com> <4D2F5EAE.9010302@redhat.com> <4D2F7F03.80108@oracle.com> <4D2F914E.80706@gmx.de> Message-ID: <4D2F9380.500@oracle.com> For clarification only (we're not suggesting adding these NOW, but instead preserving the option): People constantly write methods like public String nonNull(String s) { return s != null ? s : "" } and other versions (including the more general version that takes a default, and versions for arrays) because they are getting values from possibly null-dispensing sources (such as maps or other key-value stores). They find locutions like (s != null && s.length() > 0) to be excessively verbose in these cases. So they write utility methods that translate null to some benign default (empty string, empty array), and proceed on their way. People do this all the time; what they want is for the null check to recede into the background so the program logic is more apparent. People hate the fact that if the array/collection is null, foreach throws NPE; they'd mostly rather not have to deal explicitly with the null case. Providing a something that reads more smoothly (like checkNonNull(x)) will make them happier. On 1/13/2011 6:57 PM, Ulf Zibis wrote: > Am 13.01.2011 23:38, schrieb Brian Goetz: >> >> People use these to simplify cases like >> >> if (foo != null) >> for (Foo f : foo) { ... } >> >> to >> >> for (Foo f : nonNull(foo)) { ... } > > To be honest, I don't understand the real value of nonNull(). > If the argument is null, NPE would be thrown anyway. > Do I miss something? > > -Ulf > From mark.reinhold at oracle.com Fri Jan 14 00:20:28 2011 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 13 Jan 2011 16:20:28 -0800 Subject: Objects.nonNull() In-Reply-To: brian.goetz@oracle.com; Thu, 13 Jan 2011 18:15:30 EST; <4D2F8792.3070202@oracle.com> Message-ID: <20110114002028.9C4C02999@eggemoggin.niobe.net> > Date: Thu, 13 Jan 2011 18:15:30 -0500 > From: brian.goetz at oracle.com > ... > > Between checkNonNull() and throwIfNull(), I lean towards the former. In any > case the answer should be driven by what is more obvious to the reader. Agreed. > So > let's look at some typical code: > > public Moo fooWrapper(String x, String y) { > return foo(throwIfNull(x), throwIfNull(y)); > } > > vs > > public Moo fooWrapper(String x, String y) { > return foo(checkNonNull(x), checkNonNull(y)); > } > > Since throwing should be the exceptional path, it feels to me that having throw > in the name sets slightly the wrong expectations. ... Agreed. I'm still troubled by the "check" prefix, though. It implies that the named condition will be tested but it doesn't clearly relate the result of that test to the method's exception-throwing behavior. Here's an idea: Why not treat this as a (degenerate) kind of conversion operation? Call it asNonNull(x) -- it (trivially) converts its argument to a non-null value, and if it can't then it throws an NPE. public Moo fooWrapper(String x, String y) { return foo(asNonNull(x), asNonNull(y)); } Of all the names we've considered, this looks the most natural to me. - Mark From forax at univ-mlv.fr Fri Jan 14 00:27:38 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Fri, 14 Jan 2011 01:27:38 +0100 Subject: Objects.nonNull() In-Reply-To: <20110114002028.9C4C02999@eggemoggin.niobe.net> References: <20110114002028.9C4C02999@eggemoggin.niobe.net> Message-ID: <4D2F987A.5070209@univ-mlv.fr> On 01/14/2011 01:20 AM, mark.reinhold at oracle.com wrote: >> Date: Thu, 13 Jan 2011 18:15:30 -0500 >> From: brian.goetz at oracle.com >> ... >> >> Between checkNonNull() and throwIfNull(), I lean towards the former. In any >> case the answer should be driven by what is more obvious to the reader. > Agreed. > >> So >> let's look at some typical code: >> >> public Moo fooWrapper(String x, String y) { >> return foo(throwIfNull(x), throwIfNull(y)); >> } >> >> vs >> >> public Moo fooWrapper(String x, String y) { >> return foo(checkNonNull(x), checkNonNull(y)); >> } >> >> Since throwing should be the exceptional path, it feels to me that having throw >> in the name sets slightly the wrong expectations. ... > Agreed. > > I'm still troubled by the "check" prefix, though. It implies that the > named condition will be tested but it doesn't clearly relate the result > of that test to the method's exception-throwing behavior. > > Here's an idea: Why not treat this as a (degenerate) kind of conversion > operation? Call it asNonNull(x) -- it (trivially) converts its argument > to a non-null value, and if it can't then it throws an NPE. > > public Moo fooWrapper(String x, String y) { > return foo(asNonNull(x), asNonNull(y)); > } > > Of all the names we've considered, this looks the most natural to me. > > - Mark 'as' is used in C# or in Groovy to transform a value to another type. There is also assertNonNull or claimNonNull. R?mi From schlosna at gmail.com Fri Jan 14 00:39:27 2011 From: schlosna at gmail.com (David Schlosnagle) Date: Thu, 13 Jan 2011 19:39:27 -0500 Subject: Objects.nonNull() In-Reply-To: <4D2F9380.500@oracle.com> References: <4D2F5B5E.1040904@oracle.com> <4D2F5EAE.9010302@redhat.com> <4D2F7F03.80108@oracle.com> <4D2F914E.80706@gmx.de> <4D2F9380.500@oracle.com> Message-ID: On Thu, Jan 13, 2011 at 7:06 PM, Brian Goetz wrote: > For clarification only (we're not suggesting adding these NOW, but instead > preserving the option): > > People constantly write methods like > > ?public String nonNull(String s) { return s != null ? s : "" } > > and other versions (including the more general version that takes a default, > and versions for arrays) because they are getting values from possibly > null-dispensing sources (such as maps or other key-value stores). ?They find > locutions like > > ?(s != null && s.length() > 0) > > to be excessively verbose in these cases. ?So they write utility methods > that translate null to some benign default (empty string, empty array), and > proceed on their way. ?People do this all the time; what they want is for > the null check to recede into the background so the program logic is more > apparent. > > People hate the fact that if the array/collection is null, foreach throws > NPE; they'd mostly rather not have to deal explicitly with the null case. > ?Providing a something that reads more smoothly (like checkNonNull(x)) will > make them happier. The class documentation for java.lang.Objects currently states "This class consists of static utility methods for operating on objects. These utilities include null-safe or null-tolerant methods for computing the hash code of an object, returning a string for an object, and comparing two objects." [1] which to me seems to indicate that it should provide null-safe or null-tolerant versions of the methods on java.lang.Object where there is a sensible response (what would Objects.getClass(null) return?). The obvious APIs for comparison are Guava's Objects [2] and Apache Commons Lang's ObjectUtils [3]. It seems to me that the java.lang.Objects#nonNull [1] method which throws NullPointerException for a null argument belongs more in a preconditions [4] or validation [5] API. As for null-safe or null-tolerant handling of common types with defaults, almost every Java project I've ever seen has written or uses another library method to convert null string to blank, null to empty arrays or collections, etc. You have to ask yourself if providing utility methods to handle these null returning APIs is worth the cost of putting in java.lang, and how far do you go? - Dave References: [1] http://download.java.net/jdk7/docs/api/java/util/Objects.html [2] http://guava-libraries.googlecode.com/svn/trunk/javadoc/com/google/common/base/Objects.html [3] http://commons.apache.org/lang/api-3.0-beta/org/apache/commons/lang3/ObjectUtils.html [4] http://guava-libraries.googlecode.com/svn/trunk/javadoc/com/google/common/base/Preconditions.html [5] http://commons.apache.org/lang/api-3.0-beta/org/apache/commons/lang3/Validate.html From brian.goetz at oracle.com Fri Jan 14 00:52:27 2011 From: brian.goetz at oracle.com (Brian Goetz) Date: Thu, 13 Jan 2011 19:52:27 -0500 Subject: Objects.nonNull() In-Reply-To: <20110114002028.9C4C02999@eggemoggin.niobe.net> References: <20110114002028.9C4C02999@eggemoggin.niobe.net> Message-ID: <4D2F9E4B.8030504@oracle.com> > I'm still troubled by the "check" prefix, though. It implies that the > named condition will be tested but it doesn't clearly relate the result > of that test to the method's exception-throwing behavior. > > Here's an idea: Why not treat this as a (degenerate) kind of conversion > operation? Call it asNonNull(x) -- it (trivially) converts its argument > to a non-null value, and if it can't then it throws an NPE. > > public Moo fooWrapper(String x, String y) { > return foo(asNonNull(x), asNonNull(y)); > } > > Of all the names we've considered, this looks the most natural to me. I would like to leave room in the namespace to support both of these use cases: - I expect non-null, and if I'm wrong, fail - I expect non-null, and if I'm wrong, sweep it under the rug The motivation for this change is that we're currently grabbing nonNull(x) for one of them, using a name that is more suitable to the other. asNonNull(x) sounds like the latter to me, since asXxx suggests a conversion. I'm totally fine with that as the name for the carpet-sweeping version. Note that these are the only methods in Objects that throw anything -- the rest of the methods in Object are more of the carpet-sweeping variety. So the name should definitely reflect that these are assertions/checks/verifications/preconditions. Someone suggested assertNonNull(x), and while that sort of captures the intent, people expect assertXxx methods to throw AssertionError, and it still may surprise the user on what it does in the common case. I suppose ifNonNull() is a possible choice, though it begs the question "where is the else clause"? Unfortunately brevity is somewhat important here because people will use this inline, such as in the fooWrapper case, which suggest that something is going to be left unspecified no matter how we slice. I'm still liking checkNonNull, mostly because I haven't seen something better yet. (But nearly all the options are better than the status quo.) From ben_manes at yahoo.com Fri Jan 14 02:25:05 2011 From: ben_manes at yahoo.com (Ben Manes) Date: Thu, 13 Jan 2011 18:25:05 -0800 (PST) Subject: Objects.nonNull() In-Reply-To: <4D2F9E4B.8030504@oracle.com> References: <20110114002028.9C4C02999@eggemoggin.niobe.net> <4D2F9E4B.8030504@oracle.com> Message-ID: <666944.95706.qm@web38805.mail.mud.yahoo.com> Should these checks even be part of java.lang? It promotes creeping in many different assertion utility methods throughout the libraries. I personally prefer the more flexible Hamcrest style, e.g. assertThat(foo, is(not(nullValue()))), which allows extensibility through matchers. However, I wouldn't expect either style to be part of the core language. ________________________________ From: Brian Goetz To: mark.reinhold at oracle.com Cc: core-libs-dev at openjdk.java.net Sent: Thu, January 13, 2011 4:52:27 PM Subject: Re: Objects.nonNull() > I'm still troubled by the "check" prefix, though. It implies that the > named condition will be tested but it doesn't clearly relate the result > of that test to the method's exception-throwing behavior. > > Here's an idea: Why not treat this as a (degenerate) kind of conversion > operation? Call it asNonNull(x) -- it (trivially) converts its argument > to a non-null value, and if it can't then it throws an NPE. > > public Moo fooWrapper(String x, String y) { > return foo(asNonNull(x), asNonNull(y)); > } > > Of all the names we've considered, this looks the most natural to me. I would like to leave room in the namespace to support both of these use cases: - I expect non-null, and if I'm wrong, fail - I expect non-null, and if I'm wrong, sweep it under the rug The motivation for this change is that we're currently grabbing nonNull(x) for one of them, using a name that is more suitable to the other. asNonNull(x) sounds like the latter to me, since asXxx suggests a conversion. I'm totally fine with that as the name for the carpet-sweeping version. Note that these are the only methods in Objects that throw anything -- the rest of the methods in Object are more of the carpet-sweeping variety. So the name should definitely reflect that these are assertions/checks/verifications/preconditions. Someone suggested assertNonNull(x), and while that sort of captures the intent, people expect assertXxx methods to throw AssertionError, and it still may surprise the user on what it does in the common case. I suppose ifNonNull() is a possible choice, though it begs the question "where is the else clause"? Unfortunately brevity is somewhat important here because people will use this inline, such as in the fooWrapper case, which suggest that something is going to be left unspecified no matter how we slice. I'm still liking checkNonNull, mostly because I haven't seen something better yet. (But nearly all the options are better than the status quo.) -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.goetz at oracle.com Fri Jan 14 02:55:04 2011 From: brian.goetz at oracle.com (Brian Goetz) Date: Thu, 13 Jan 2011 21:55:04 -0500 Subject: Objects.nonNull() In-Reply-To: <666944.95706.qm@web38805.mail.mud.yahoo.com> References: <20110114002028.9C4C02999@eggemoggin.niobe.net> <4D2F9E4B.8030504@oracle.com> <666944.95706.qm@web38805.mail.mud.yahoo.com> Message-ID: <4D2FBB08.5020805@oracle.com> They are not, they are java.util. On 1/13/2011 9:25 PM, Ben Manes wrote: > Should these checks even be part of java.lang? It promotes creeping in > many different assertion utility methods throughout the libraries. I > personally prefer the more flexible Hamcrest style, e.g. assertThat(foo, > is(not(nullValue()))), which allows extensibility through matchers. > However, I wouldn't expect either style to be part of the core language. > > ------------------------------------------------------------------------ > *From:* Brian Goetz > *To:* mark.reinhold at oracle.com > *Cc:* core-libs-dev at openjdk.java.net > *Sent:* Thu, January 13, 2011 4:52:27 PM > *Subject:* Re: Objects.nonNull() > > > I'm still troubled by the "check" prefix, though. It implies that the > > named condition will be tested but it doesn't clearly relate the result > > of that test to the method's exception-throwing behavior. > > > > Here's an idea: Why not treat this as a (degenerate) kind of conversion > > operation? Call it asNonNull(x) -- it (trivially) converts its argument > > to a non-null value, and if it can't then it throws an NPE. > > > > public Moo fooWrapper(String x, String y) { > > return foo(asNonNull(x), asNonNull(y)); > > } > > > > Of all the names we've considered, this looks the most natural to me. > > I would like to leave room in the namespace to support both of these use > cases: > - I expect non-null, and if I'm wrong, fail > - I expect non-null, and if I'm wrong, sweep it under the rug > > The motivation for this change is that we're currently grabbing > nonNull(x) for one of them, using a name that is more suitable to the other. > > asNonNull(x) sounds like the latter to me, since asXxx suggests a > conversion. I'm totally fine with that as the name for the > carpet-sweeping version. > > Note that these are the only methods in Objects that throw anything -- > the rest of the methods in Object are more of the carpet-sweeping > variety. So the name should definitely reflect that these are > assertions/checks/verifications/preconditions. > > Someone suggested assertNonNull(x), and while that sort of captures the > intent, people expect assertXxx methods to throw AssertionError, and it > still may surprise the user on what it does in the common case. > > I suppose ifNonNull() is a possible choice, though it begs the question > "where is the else clause"? > > Unfortunately brevity is somewhat important here because people will use > this inline, such as in the fooWrapper case, which suggest that > something is going to be left unspecified no matter how we slice. > > I'm still liking checkNonNull, mostly because I haven't seen something > better yet. (But nearly all the options are better than the status quo.) > > From tom.hawtin at oracle.com Fri Jan 14 03:13:24 2011 From: tom.hawtin at oracle.com (Tom Hawtin) Date: Fri, 14 Jan 2011 03:13:24 +0000 Subject: Objects.nonNull() In-Reply-To: <4D2F7899.6010605@oracle.com> References: <4D2F5B5E.1040904@oracle.com> <4D2F6ABA.4060101@oracle.com> <4D2F7899.6010605@oracle.com> Message-ID: <4D2FBF54.4020901@oracle.com> On 13/01/2011 22:11, Brian Goetz wrote: > > I disagree with Tom here. We have *already* made the billion dollar > mistake, and we can't eliminate that headache (but we can provide easier > access to aspirin.) Java developers are *constantly* writing methods > like the suggested carpet-sweeping nonNull() to work around this (and > some of the Objects methods already do this, like hashCode()). If I had > to guess how many times this exact method had been written across all > the Java code in the world, I would be quite surprised if its common > logarithm were less than 4. If you come across developers abusing null to represent empty, the appropriate thing to do is point them in the direction of Items 38 and 43. Java used to offer [some] technical leadership. The two categories of methods in Objects kind of demonstrates the dumping ground nature of utilities classes. Perhaps the class should be split, and given actually meaningful names. IMO, the name nonNull is perfect in the extremely common context. this.donkey = nonNull(donkey); It's a statement about the expression. Method names don't generally say what they are going to do if passed illegal values. You could imagine other constraints expressed similarly. Tom From mike.duigou at oracle.com Fri Jan 14 04:33:04 2011 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Fri, 14 Jan 2011 04:33:04 +0000 Subject: hg: jdk7/tl/jdk: 6728865: Provide a better heuristics for Collections.disjoint method Message-ID: <20110114043327.CB14047C34@hg.openjdk.java.net> Changeset: 29f2e311cce7 Author: mduigou Date: 2011-01-13 20:32 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/29f2e311cce7 6728865: Provide a better heuristics for Collections.disjoint method Reviewed-by: alanb, dholmes, chegar, forax ! src/share/classes/java/util/Collections.java From brian.goetz at oracle.com Fri Jan 14 05:23:01 2011 From: brian.goetz at oracle.com (Brian Goetz) Date: Fri, 14 Jan 2011 00:23:01 -0500 Subject: Objects.nonNull() In-Reply-To: <20110114002028.9C4C02999@eggemoggin.niobe.net> References: <20110114002028.9C4C02999@eggemoggin.niobe.net> Message-ID: <4D2FDDB5.5000603@oracle.com> Thinking some more: - The name nonNull() is just confusing. It could reasonably mean one of several things, and we've seen this in people's reactions: some don't like it for the throwing behavior because its not clear that it has a strong checking behavior, others don't like it for the defaulting behavior because the find the defaulting behavior unnatural. This suggests it is just too vague to make anyone happy. - I'm still enamored of checkNonNull() for the throwing version but am still open to better names. - If we add carpet-sweeping versions later, asNonNull() or makeNonNull() both seem better than nonNull(). - We just stay away from the not-specific-enough name nonNull() here. On 1/13/2011 7:20 PM, mark.reinhold at oracle.com wrote: >> Date: Thu, 13 Jan 2011 18:15:30 -0500 >> From: brian.goetz at oracle.com > >> ... >> >> Between checkNonNull() and throwIfNull(), I lean towards the former. In any >> case the answer should be driven by what is more obvious to the reader. > > Agreed. > >> So >> let's look at some typical code: >> >> public Moo fooWrapper(String x, String y) { >> return foo(throwIfNull(x), throwIfNull(y)); >> } >> >> vs >> >> public Moo fooWrapper(String x, String y) { >> return foo(checkNonNull(x), checkNonNull(y)); >> } >> >> Since throwing should be the exceptional path, it feels to me that having throw >> in the name sets slightly the wrong expectations. ... > > Agreed. > > I'm still troubled by the "check" prefix, though. It implies that the > named condition will be tested but it doesn't clearly relate the result > of that test to the method's exception-throwing behavior. > > Here's an idea: Why not treat this as a (degenerate) kind of conversion > operation? Call it asNonNull(x) -- it (trivially) converts its argument > to a non-null value, and if it can't then it throws an NPE. > > public Moo fooWrapper(String x, String y) { > return foo(asNonNull(x), asNonNull(y)); > } > > Of all the names we've considered, this looks the most natural to me. > > - Mark From bhavesh.patel at sun.com Fri Jan 14 05:31:47 2011 From: bhavesh.patel at sun.com (bhavesh.patel at sun.com) Date: Fri, 14 Jan 2011 05:31:47 +0000 Subject: hg: jdk7/tl/langtools: 7010528: javadoc performance regression Message-ID: <20110114053151.1E31C47C37@hg.openjdk.java.net> Changeset: a466f00c5cd2 Author: bpatel Date: 2011-01-13 21:28 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/a466f00c5cd2 7010528: javadoc performance regression Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlTree.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/Content.java From pcj at roundroom.net Fri Jan 14 05:52:57 2011 From: pcj at roundroom.net (Peter Jones) Date: Fri, 14 Jan 2011 00:52:57 -0500 Subject: Sunbug 6934356: Vector.writeObject() synchronization risks serialization deadlock In-Reply-To: References: <4D0A0D96.7050302@oracle.com> <4D2AF3DE.5060104@oracle.com> <4D2B75F4.20309@oracle.com> <61A4144A-0302-466D-A676-586EC6D6AB62@roundroom.net> Message-ID: <55CEEFF2-5A74-40D9-B82D-558ED326D8E3@roundroom.net> I believe that the past performance concern was about the change from using ObjectOutputStream.defaultWriteObject to using OOS.putFields/writeFields, which adds some overhead-- although if you need to use them, you need to use them. (This wouldn't apply to the Hashtable fix, which looks fine to me.) Cheers, -- Peter On Jan 13, 2011, at 5:31 PM, Mike Duigou wrote: > I know that on the Oracle side we did internally discuss the potential performance impact. The main performance concern seems to be the extra GC work from creating the array of values (or the entry stack in the case of Hashtable). We decided though that for most collections the small size and short lifetime of the extra objects would mean that they would never escape the eden generation and would be quickly and efficiently GCed. We don't expect that this change will result in only insignificant (it's not "free") performance degradation whether considered from a microbenchmark perspective or from an overall system performance perspective. > > Alternative opinions, analysis and insights are, of course, welcome. > > Mike > > On Jan 12 2011, at 22:31 , Peter Jones wrote: > >> Hello, >> >> Sorry for chiming in late here, but I was wondering-- has the performance impact of this change been measured? Many years ago, the performance impact vs. the apparent severity of the bug at the time held back this fix (using PutField). Of course, both sides of that consideration may have changed since then. >> >> FWIW, the code change looks correct to me. A style nit: I would drop the "= null" initializer on line 1060-- it is a value that should never be read, so let the compiler enforce that (and then you could declare "data" final as well). >> >> Cheers, >> -- Peter >> >> P.S. There is a serialization micro-benchmark framework under test/java/rmi/reliability/benchmark >> >> >> On Jan 12, 2011, at 5:42 AM, Neil Richards wrote: >> >>> On 10 January 2011 21:11, Alan Bateman wrote: >>>> The update to the javadoc looks fine to me. On the headers then we use the >>>> GPL header on tests (no Classpath Exception). >>> >>> Sorry once again - please find attached with the corrected header for >>> GPL (without Classpath exception). >>> >>> I hope I'm pretty much there now - let me know if you spot anything else. >>> Cheers, >>> Neil >>> >>> -- >>> Unless stated above: >>> IBM email: neil_richards at uk.ibm.com >>> IBM United Kingdom Limited - Registered in England and Wales with number 741598. >>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU >>> >> > From joe.darcy at oracle.com Fri Jan 14 06:22:37 2011 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Fri, 14 Jan 2011 06:22:37 +0000 Subject: hg: jdk7/tl/jdk: 7012279: Project Coin: Clarify AutoCloseable and Throwable javadoc Message-ID: <20110114062253.F175A47C3A@hg.openjdk.java.net> Changeset: 59e352561146 Author: darcy Date: 2011-01-13 22:21 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/59e352561146 7012279: Project Coin: Clarify AutoCloseable and Throwable javadoc Reviewed-by: jjb ! src/share/classes/java/lang/AutoCloseable.java ! src/share/classes/java/lang/Throwable.java From Alan.Bateman at oracle.com Fri Jan 14 09:17:01 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 14 Jan 2011 09:17:01 +0000 Subject: Objects.nonNull() In-Reply-To: <4D2F7D27.9040506@univ-mlv.fr> References: <4D2F5B5E.1040904@oracle.com> <4D2F6ABA.4060101@oracle.com> <4D2F7899.6010605@oracle.com> <4D2F7D27.9040506@univ-mlv.fr> Message-ID: <4D30148D.9050901@oracle.com> Along the lines of R?mi's first suggestion, then another possible candidate is failIfNull(x). -Alan. From maurizio.cimadamore at oracle.com Fri Jan 14 09:50:32 2011 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Fri, 14 Jan 2011 09:50:32 +0000 Subject: hg: jdk7/tl/langtools: 3 new changesets Message-ID: <20110114095039.0B6DC47C43@hg.openjdk.java.net> Changeset: 2d5aff89aaa3 Author: mcimadamore Date: 2011-01-14 09:45 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/2d5aff89aaa3 6992698: JSR 292: remove support for transient syntax in polymorphic signature calls Summary: special syntax to denote indy return type through type parameters should be removed (and cast shall be used instead) Reviewed-by: jjg, jrose ! src/share/classes/com/sun/tools/javac/code/Symtab.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Flow.java ! src/share/classes/com/sun/tools/javac/comp/Infer.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.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/main/Main.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/util/Names.java - test/tools/javac/diags/examples/TypeParameterOnPolymorphicSignature.java - test/tools/javac/meth/InvokeDynTrans.out - test/tools/javac/meth/InvokeMHTrans.java - test/tools/javac/meth/InvokeMHTrans.out ! test/tools/javac/meth/TestCP.java ! test/tools/javac/meth/XlintWarn.java Changeset: c8d312dd17bc Author: mcimadamore Date: 2011-01-14 09:45 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/c8d312dd17bc 7007432: Test generic types well-formedness Summary: add a new kind of check (well-formedness of generic type w.r.t. declared bounds) in the type-harness Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Check.java + test/tools/javac/types/GenericTypeWellFormednessTest.java ! test/tools/javac/types/TypeHarness.java Changeset: 712be35e40b5 Author: mcimadamore Date: 2011-01-14 09:46 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/712be35e40b5 6949040: java.dyn package must be compiled with -target 7 or better Summary: issue error (rather than warning) when @PolymorphicSignature is found and target < 7 Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! test/tools/javac/diags/examples.not-yet.txt From scolebourne at joda.org Fri Jan 14 11:30:59 2011 From: scolebourne at joda.org (Stephen Colebourne) Date: Fri, 14 Jan 2011 11:30:59 +0000 Subject: Objects.nonNull() In-Reply-To: <4D2FDDB5.5000603@oracle.com> References: <20110114002028.9C4C02999@eggemoggin.niobe.net> <4D2FDDB5.5000603@oracle.com> Message-ID: There are a number of strands to this thread 1) Null useful or not. There are arguments on both sides here, and developers are divided. Personally, I use null every single day to use not known or not required, such as in a search request: /** * The set of exchange object identifiers, null to not limit by exchange object identifiers. * Note that an empty set will return no exchanges. */ private List _exchangeIds; /** * The exchange keys to match, null to not match on exchange keys. */ private IdentifierSearch _exchangeKeys; /** * The exchange name, wildcards allowed, null to not match on name. */ private String _name; For me, null is incredibly useful. I understand those that want it removed, or push against it - I just disagree. (Thats why I want better null-handling syntax features). BTW, I believe but can't prove that far more people in the real world make use of null than avoid it. 2) Other utilities These are prior art that users are familiar with, just as much as the JDK. Google Guava - Objects: public static T firstNonNull(T first, T second) Google Guava - Preconditions: public static T checkNotNull(T reference) Commons Lang - ObjectUtils: public static Object defaultIfNull(Object object, Object defaultValue) Commons Lang - StringUtils: public static boolean isEmpty(String str) public static boolean isNotEmpty(String str) public static boolean isBlank(String str) public static boolean isNotBlank(String str) public static String trimToNull(String str) public static String trimToEmpty(String str) public static String defaultString(String str) public static String defaultString(String str, String defaultStr) public static String defaultIfEmpty(String str, String defaultStr) 3) Prior discussions When this was first raised I argued for the addition of a Validate (Commons Lang)/Preconditions (Google Guava)/Assert (JUnit) class alongside and separate from Objects. The "notNull" method would make much more sense there with its given name. Validate.notNull(foo) 4) Fluency The Objects.notNull code is designed for writing fluent code that asserts the non-null status of the value. public void process(String foo) { if (nonNull(foo).length() > 3) { ... } } This is a style/taste thing. Personally I prefer: public void process(String foo) { Validate.notNull(foo); if (foo.length() > 3) { ... } } I believe that the latter (my choice) is more in the spirit of the Java core libraries. (And I've used the latter style for many years with great success, whereas I wouldn't touch the assert keyword with a bargepole) It is critical to understand that the basis of the method as written is the fluency. Therefore "checkNotNull" simply isn't as readable: if (checkNotNull(foo).length() > 3) The suggestion of "nullChecked" is more fluent: if (nullCheked(foo).length() > 3) However, I still argue that this kind of fluency is not appropriate for such a core JDK class when compared to the Validate/Preconditions alternative. 5) Now *** If you are time-pressured, I'd recommend removing this method from v7. *** A "defaultIfNull" method would be much more useful in this class: public static Object defaultIfNull(Object object, Object defaultValue) { return object != null ? object : defaultValue; } andf much more in keeping (I wouldn't ever want to see the above method just called "notNull". Stephen On 14 January 2011 05:23, Brian Goetz wrote: > Thinking some more: > > ?- The name nonNull() is just confusing. ?It could reasonably mean one of > several things, and we've seen this in people's reactions: some don't like > it for the throwing behavior because its not clear that it has a strong > checking behavior, others don't like it for the defaulting behavior because > the find the defaulting behavior unnatural. ?This suggests it is just too > vague to make anyone happy. > ?- I'm still enamored of checkNonNull() for the throwing version but am > still open to better names. > ?- If we add carpet-sweeping versions later, asNonNull() or makeNonNull() > both seem better than nonNull(). > ?- We just stay away from the not-specific-enough name nonNull() here. > > > > On 1/13/2011 7:20 PM, mark.reinhold at oracle.com wrote: >>> >>> Date: Thu, 13 Jan 2011 18:15:30 -0500 >>> From: brian.goetz at oracle.com >> >>> ... >>> >>> Between checkNonNull() and throwIfNull(), I lean towards the former. ?In >>> any >>> case the answer should be driven by what is more obvious to the reader. >> >> Agreed. >> >>> >>> ?So >>> let's look at some typical code: >>> >>> ? public Moo fooWrapper(String x, String y) { >>> ? ? ? return foo(throwIfNull(x), throwIfNull(y)); >>> ? } >>> >>> vs >>> >>> ? public Moo fooWrapper(String x, String y) { >>> ? ? ? return foo(checkNonNull(x), checkNonNull(y)); >>> ? } >>> >>> Since throwing should be the exceptional path, it feels to me that having >>> throw >>> in the name sets slightly the wrong expectations. ?... >> >> Agreed. >> >> I'm still troubled by the "check" prefix, though. ?It implies that the >> named condition will be tested but it doesn't clearly relate the result >> of that test to the method's exception-throwing behavior. >> >> Here's an idea: Why not treat this as a (degenerate) kind of conversion >> operation? ?Call it asNonNull(x) -- it (trivially) converts its argument >> to a non-null value, and if it can't then it throws an NPE. >> >> ? public Moo fooWrapper(String x, String y) { >> ? ? ? return foo(asNonNull(x), asNonNull(y)); >> ? } >> >> Of all the names we've considered, this looks the most natural to me. >> >> - Mark > From scolebourne at joda.org Fri Jan 14 11:37:59 2011 From: scolebourne at joda.org (Stephen Colebourne) Date: Fri, 14 Jan 2011 11:37:59 +0000 Subject: Objects.nonNull() In-Reply-To: References: <20110114002028.9C4C02999@eggemoggin.niobe.net> <4D2FDDB5.5000603@oracle.com> Message-ID: And I found the original thread, for reference: http://www.mail-archive.com/core-libs-dev at openjdk.java.net/msg02950.html Stephen On 14 January 2011 11:30, Stephen Colebourne wrote: > There are a number of strands to this thread > > 1) Null useful or not. > There are arguments on both sides here, and developers are divided. > Personally, I use null every single day to use not known or not > required, such as in a search request: > > ?/** > ? * The set of exchange object identifiers, null to not limit by > exchange object identifiers. > ? * Note that an empty set will return no exchanges. > ? */ > ?private List _exchangeIds; > ?/** > ? * The exchange keys to match, null to not match on exchange keys. > ? */ > ?private IdentifierSearch _exchangeKeys; > ?/** > ? * The exchange name, wildcards allowed, null to not match on name. > ? */ > ?private String _name; > > For me, null is incredibly useful. I understand those that want it > removed, or push against it - I just disagree. (Thats why I want > better null-handling syntax features). BTW, I believe but can't prove > that far more people in the real world make use of null than avoid it. > > 2) Other utilities > These are prior art that users are familiar with, just as much as the JDK. > Google Guava - Objects: > ?public static T firstNonNull(T first, T second) > > Google Guava - Preconditions: > ?public static T checkNotNull(T reference) > > Commons Lang - ObjectUtils: > ?public static Object defaultIfNull(Object object, Object defaultValue) > > Commons Lang - StringUtils: > ?public static boolean isEmpty(String str) > ?public static boolean isNotEmpty(String str) > ?public static boolean isBlank(String str) > ?public static boolean isNotBlank(String str) > ?public static String trimToNull(String str) > ?public static String trimToEmpty(String str) > ?public static String defaultString(String str) > ?public static String defaultString(String str, String defaultStr) > ?public static String defaultIfEmpty(String str, String defaultStr) > > 3) Prior discussions > When this was first raised I argued for the addition of a Validate > (Commons Lang)/Preconditions (Google Guava)/Assert (JUnit) class > alongside and separate from Objects. The "notNull" method would make > much more sense there with its given name. > > ?Validate.notNull(foo) > > 4) Fluency > The Objects.notNull code is designed for writing fluent code that > asserts the non-null status of the value. > > public void process(String foo) { > ?if (nonNull(foo).length() > 3) { ... } > } > > This is a style/taste thing. Personally I prefer: > > public void process(String foo) { > ?Validate.notNull(foo); > ?if (foo.length() > 3) { ... } > } > > I believe that the latter (my choice) is more in the spirit of the > Java core libraries. (And I've used the latter style for many years > with great success, whereas I wouldn't touch the assert keyword with a > bargepole) > > It is critical to understand that the basis of the method as written > is the fluency. Therefore "checkNotNull" simply isn't as readable: > > ?if (checkNotNull(foo).length() > 3) > > The suggestion of "nullChecked" is more fluent: > > ?if (nullCheked(foo).length() > 3) > > However, I still argue that this kind of fluency is not appropriate > for such a core JDK class when compared to the Validate/Preconditions > alternative. > > 5) Now > *** If you are time-pressured, I'd recommend removing this method from v7. *** > > A "defaultIfNull" method would be much more useful in this class: > ? ?public static Object defaultIfNull(Object object, Object defaultValue) { > ? ? ? ?return object != null ? object : defaultValue; > ? ?} > andf much more in keeping (I wouldn't ever want to see the above > method just called "notNull". > > Stephen > > > On 14 January 2011 05:23, Brian Goetz wrote: >> Thinking some more: >> >> ?- The name nonNull() is just confusing. ?It could reasonably mean one of >> several things, and we've seen this in people's reactions: some don't like >> it for the throwing behavior because its not clear that it has a strong >> checking behavior, others don't like it for the defaulting behavior because >> the find the defaulting behavior unnatural. ?This suggests it is just too >> vague to make anyone happy. >> ?- I'm still enamored of checkNonNull() for the throwing version but am >> still open to better names. >> ?- If we add carpet-sweeping versions later, asNonNull() or makeNonNull() >> both seem better than nonNull(). >> ?- We just stay away from the not-specific-enough name nonNull() here. >> >> >> >> On 1/13/2011 7:20 PM, mark.reinhold at oracle.com wrote: >>>> >>>> Date: Thu, 13 Jan 2011 18:15:30 -0500 >>>> From: brian.goetz at oracle.com >>> >>>> ... >>>> >>>> Between checkNonNull() and throwIfNull(), I lean towards the former. ?In >>>> any >>>> case the answer should be driven by what is more obvious to the reader. >>> >>> Agreed. >>> >>>> >>>> ?So >>>> let's look at some typical code: >>>> >>>> ? public Moo fooWrapper(String x, String y) { >>>> ? ? ? return foo(throwIfNull(x), throwIfNull(y)); >>>> ? } >>>> >>>> vs >>>> >>>> ? public Moo fooWrapper(String x, String y) { >>>> ? ? ? return foo(checkNonNull(x), checkNonNull(y)); >>>> ? } >>>> >>>> Since throwing should be the exceptional path, it feels to me that having >>>> throw >>>> in the name sets slightly the wrong expectations. ?... >>> >>> Agreed. >>> >>> I'm still troubled by the "check" prefix, though. ?It implies that the >>> named condition will be tested but it doesn't clearly relate the result >>> of that test to the method's exception-throwing behavior. >>> >>> Here's an idea: Why not treat this as a (degenerate) kind of conversion >>> operation? ?Call it asNonNull(x) -- it (trivially) converts its argument >>> to a non-null value, and if it can't then it throws an NPE. >>> >>> ? public Moo fooWrapper(String x, String y) { >>> ? ? ? return foo(asNonNull(x), asNonNull(y)); >>> ? } >>> >>> Of all the names we've considered, this looks the most natural to me. >>> >>> - Mark >> > From Ulf.Zibis at gmx.de Fri Jan 14 12:56:21 2011 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Fri, 14 Jan 2011 13:56:21 +0100 Subject: Objects.nonNull() In-Reply-To: <4D30148D.9050901@oracle.com> References: <4D2F5B5E.1040904@oracle.com> <4D2F6ABA.4060101@oracle.com> <4D2F7899.6010605@oracle.com> <4D2F7D27.9040506@univ-mlv.fr> <4D30148D.9050901@oracle.com> Message-ID: <4D3047F5.20608@gmx.de> Am 14.01.2011 10:17, schrieb Alan Bateman: > > Along the lines of R?mi's first suggestion, then another possible candidate is failIfNull(x). > +1 Yes, this sounds better to me than throwIfNull(x). The purpose of this method, if I understand right, is to pull out from behind the potential failing to a well defined place in the stacktrace, so more specific it could be named failHereIfNull(x), but I more like the short form. In 2nd place I like checkForNull(x). The nonNull(x) is ambiguous, and could be misunderstood as transform-to-a-non-null-value. -Ulf From Ulf.Zibis at gmx.de Fri Jan 14 13:32:41 2011 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Fri, 14 Jan 2011 14:32:41 +0100 Subject: Objects.nonNull() In-Reply-To: References: <20110114002028.9C4C02999@eggemoggin.niobe.net> <4D2FDDB5.5000603@oracle.com> Message-ID: <4D305079.8040009@gmx.de> Am 14.01.2011 12:30, schrieb Stephen Colebourne: > 2) Other utilities > These are prior art that users are familiar with, just as much as the JDK. > Google Guava - Objects: > public static T firstNonNull(T first, T second) why not? : public static T firstNonNull(T... values) > Commons Lang - ObjectUtils: > public static Object defaultIfNull(Object object, Object defaultValue) Additionally we should define some common constants for performance reasons: String.EMPTY = ""; Integer.EMPTY_ARRAY = new int[0]; ... > public void process(String foo) { > Validate.notNull(foo); > if (foo.length()> 3) { ... } > } Why not? : Validate.notNull(foo, runnable) I think, in case of an expected null value, the developer has a specific idea, how to handle it. A good candidate for closures! Just throwing an exception should be reserved for _un_expected cases. Don't forget, that we still have: assert foo != null; > The suggestion of "nullChecked" is more fluent: > > if (nullCheked(foo).length()> 3) +1 Another alternative to failIfNull(x) which I like, because it clearly describes the default operation of the method. -Ulf From jonathan.gibbons at oracle.com Fri Jan 14 19:45:48 2011 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Fri, 14 Jan 2011 19:45:48 +0000 Subject: hg: jdk7/tl/langtools: 6419926: JSR 199: FileObject.toUri() generates URI without schema (Solaris) Message-ID: <20110114194551.A7AFC47C62@hg.openjdk.java.net> Changeset: 7c7c1787fbbe Author: jjg Date: 2011-01-14 11:45 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/7c7c1787fbbe 6419926: JSR 199: FileObject.toUri() generates URI without schema (Solaris) Reviewed-by: mcimadamore + test/tools/javac/api/T6419926.java From jonathan.gibbons at oracle.com Fri Jan 14 19:56:21 2011 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Fri, 14 Jan 2011 19:56:21 +0000 Subject: hg: jdk7/tl/langtools: 6571165: Minor doc bugs in JavaCompiler.java Message-ID: <20110114195623.B939147C63@hg.openjdk.java.net> Changeset: 0a509c765657 Author: jjg Date: 2011-01-14 11:55 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/0a509c765657 6571165: Minor doc bugs in JavaCompiler.java Reviewed-by: mcimadamore ! src/share/classes/javax/tools/JavaCompiler.java From tom.hawtin at oracle.com Fri Jan 14 20:18:59 2011 From: tom.hawtin at oracle.com (Tom Hawtin) Date: Fri, 14 Jan 2011 20:18:59 +0000 Subject: Objects.nonNull() In-Reply-To: References: <20110114002028.9C4C02999@eggemoggin.niobe.net> <4D2FDDB5.5000603@oracle.com> Message-ID: <4D30AFB3.8010201@oracle.com> On 14/01/2011 11:30, Stephen Colebourne wrote: > These are prior art that users are familiar with, just as much as the JDK. There is actually prior art in JSRs. JSR 305: Annotations for Software Defect Detection Used @Nonnull. In normal circumstances, we would expect this annotation and the method to be next to each other together. (Note the lowercase. This agrees with most of the JDK, although as ever NIO does something different. The capitalisation is a mistake in Josh Bloch's contribution.) JSR 303: Bean Validation Uses @NotNull > > 4) Fluency > The Objects.notNull code is designed for writing fluent code that > asserts the non-null status of the value. > > public void process(String foo) { > if (nonNull(foo).length()> 3) { ... } > } > > This is a style/taste thing. Personally I prefer: > > public void process(String foo) { > Validate.notNull(foo); > if (foo.length()> 3) { ... } > } I don't think many people would be tempted to write the first example. > 5) Now > *** If you are time-pressured, I'd recommend removing this method from v7. *** Agreed. Better to let projects do their own thing rather than inflict yet another broken method that can never be changed. Tom From kumar.x.srinivasan at oracle.com Fri Jan 14 21:59:59 2011 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Fri, 14 Jan 2011 21:59:59 +0000 Subject: hg: jdk7/tl/langtools: 7011272: langtools build.xml should provide a patch target Message-ID: <20110114220003.1D22747C6B@hg.openjdk.java.net> Changeset: 19f9b6548c70 Author: ksrini Date: 2011-01-14 13:59 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/19f9b6548c70 7011272: langtools build.xml should provide a patch target Reviewed-by: jonathan, jjh ! make/build.xml From chris.hegarty at oracle.com Fri Jan 14 22:35:55 2011 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Fri, 14 Jan 2011 22:35:55 +0000 Subject: hg: jdk7/tl/jdk: 7010903: impl. of http.maxConnections is different from the description in JavaSE document Message-ID: <20110114223617.9332B47C76@hg.openjdk.java.net> Changeset: 983364897f72 Author: chegar Date: 2011-01-14 22:34 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/983364897f72 7010903: impl. of http.maxConnections is different from the description in JavaSE document Reviewed-by: alanb, michaelm ! src/share/classes/sun/net/www/http/KeepAliveCache.java From stuart.marks at oracle.com Sat Jan 15 00:52:22 2011 From: stuart.marks at oracle.com (stuart.marks at oracle.com) Date: Sat, 15 Jan 2011 00:52:22 +0000 Subject: hg: jdk7/tl/jdk: 7012003: diamond conversion for ssl Message-ID: <20110115005251.95E5947C8C@hg.openjdk.java.net> Changeset: d61d9bf190f5 Author: smarks Date: 2011-01-14 15:31 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d61d9bf190f5 7012003: diamond conversion for ssl Reviewed-by: wetmore ! src/share/classes/sun/security/ssl/CipherSuite.java ! src/share/classes/sun/security/ssl/CipherSuiteList.java ! src/share/classes/sun/security/ssl/ClientHandshaker.java ! src/share/classes/sun/security/ssl/DefaultSSLContextImpl.java ! src/share/classes/sun/security/ssl/HandshakeMessage.java ! src/share/classes/sun/security/ssl/Handshaker.java ! src/share/classes/sun/security/ssl/HelloExtensions.java ! src/share/classes/sun/security/ssl/ProtocolList.java ! src/share/classes/sun/security/ssl/SSLAlgorithmConstraints.java ! src/share/classes/sun/security/ssl/SSLSessionImpl.java ! src/share/classes/sun/security/ssl/SignatureAndHashAlgorithm.java ! src/share/classes/sun/security/ssl/SunX509KeyManagerImpl.java ! src/share/classes/sun/security/ssl/TrustManagerFactoryImpl.java ! src/share/classes/sun/security/ssl/X509KeyManagerImpl.java ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/CookieHandlerTest.java From schlosna at gmail.com Sun Jan 16 23:42:50 2011 From: schlosna at gmail.com (David Schlosnagle) Date: Sun, 16 Jan 2011 18:42:50 -0500 Subject: 6407460: provide Collections helper methods for new interfaces in JDK 1.6 Message-ID: Hello core-lib-devs, The recent discussions around Objects.nonNull prompted me to create a patch (attached) to add the methods below to java.util.Collections for consistency with existing methods. According to the Annotated Outline of Collections Framework [1] [2], the unmodifiable methods for some of the newer Collection types (Queue, Deque, NavigableSet, NavigableMap) seem to be missing, and the empty methods for many new and old interfaces (SortedSet, NavigableSet, Queue, Deque, SortedMap, NavigableMap) that would also be nice to have. In some of my projects, I could really benefit from having these additional Collections.empty* and Collections.unmodifiable* helper methods to simplify my code. In many cases these are places where internally a null collection is used to allow for lazy initialization, but the externally exposed APIs would always return an empty or unmodifiable collection via a simple toUnmodifiable utility method (where to include those in the JDK is probably a whole separate argument). Previously the interfaces exposed in my APIs were often List, Map, or Set, but more recently I've also been using SortedMap and SortedSet where applicable, so I've felt a little pain for not having all of the expected methods in Collections. There are of course libraries such as Guava that also provide the majority of these (and much more), but I think it would be nice to have this in the JDK. There seems to have been some discussion and bug IDs related to some of these methods over the past few years [3] [4] [5] [6], but I'm curious if this is something that would be considered for adding to the Java API, and if so would it be for JDK 1.7 or 1.8 seeing as how Mark indicated 1.7 was feature complete? I look forward to everyone's feedback. + public static SortedSet emptySortedSet() + public static NavigableSet emptyNavigableSet() + public static Queue emptyQueue() + public static Deque emptyDeque() + public static SortedMap emptySortedMap() + public static NavigableMap emptyNavigableMap() + public static NavigableSet unmodifiableNavigableSet(NavigableSet s) + public static Iterator unmodifiableIterator(Iterator it) + public static ListIterator unmodifiableListIterator(ListIterator it) + public static Queue unmodifiableQueue(Queue q) + public static Deque unmodifiableDeque(Deque q) + public static NavigableMap unmodifiableNavigableMap(NavigableMap m) Here's a little summary of what versions of the JDK contain the various empty and unmodifiable methods, and which are covered by this patch: Interface empty* unmodifiable* ---------------------- ------ ------------- Collection n/a 1.2+ Set 1.5+ 1.2+ List 1.5+ 1.2+ Queue patch patch Deque patch patch Map 1.5+ 1.2+ SortedSet patch 1.2+ SortedMap patch 1.2+ NavigableSet patch patch NavigableMap patch patch BlockingQueue ? ? TransferQueue ? ? BlockingDeque ? ? ConcurrentMap ? ? ConcurrentNavigableMap ? ? Iterator 1.7+ patch ListIterator 1.7+ patch I've updated a few of the jtreg tests as initial sanity checks, but if this patch were to be considered I'd want to expand those a bit more. I haven't yet addressed the missing synchronized (Queue, Deque, NavigableSet, NavigableMap), checked (Queue, Deque, NavigableSet, NavigableMap), singleton (SortedSet, NavigableSet, Queue, Deque, SortedMap, NavigableMap) methods. Also, I haven't created analogous methods for any of the java.util.concurrent interfaces as I'm not sure that these methods necessarily make sense for those types. - Dave P.S. I submitted a signed OCA to sun_ca at sun.com earlier today, but I'm assuming it will take a while to be added to https://sca.dev.java.net/CA_signatories.htm since it is a holiday weekend here in the USA. References: [1]: http://download.oracle.com/javase/6/docs/technotes/guides/collections/reference.html [2]: http://download.java.net/jdk7/docs/technotes/guides/collections/reference.html [3]: 4834905: Support read-only Iterator, i.e., without remove(): http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4834905 [4]: 5030930: JDK1.5 The method Collections.unmodifiableQueue(Queue) is missing: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5030930 [5]: 6407460: (coll) provide Collections helper methods for new interfaces in JDK 1.6: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6407460 [6]: How about Collections.emptySorted[Set|Map] ?: http://markmail.org/message/6u23eysno2mt6ia4 -------------- next part -------------- A non-text attachment was scrubbed... Name: 6407460.patch Type: application/octet-stream Size: 50928 bytes Desc: not available URL: From mark.reinhold at oracle.com Mon Jan 17 05:06:39 2011 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Sun, 16 Jan 2011 21:06:39 -0800 Subject: Objects.nonNull() In-Reply-To: brian.goetz@oracle.com; Thu, 13 Jan 2011 19:52:27 EST; <4D2F9E4B.8030504@oracle.com> Message-ID: <20110117050639.AE357AAB@eggemoggin.niobe.net> > Date: Thu, 13 Jan 2011 19:52:27 -0500 > From: brian.goetz at oracle.com > Mark Reinhold wrote: >> I'm still troubled by the "check" prefix, though. It implies that the >> named condition will be tested but it doesn't clearly relate the result >> of that test to the method's exception-throwing behavior. >> >> Here's an idea: Why not treat this as a (degenerate) kind of conversion >> operation? Call it asNonNull(x) -- it (trivially) converts its argument >> to a non-null value, and if it can't then it throws an NPE. >> >> public Moo fooWrapper(String x, String y) { >> return foo(asNonNull(x), asNonNull(y)); >> } >> >> Of all the names we've considered, this looks the most natural to me. > > I would like to leave room in the namespace to support both of these use cases: > - I expect non-null, and if I'm wrong, fail > - I expect non-null, and if I'm wrong, sweep it under the rug > > The motivation for this change is that we're currently grabbing nonNull(x) for > one of them, using a name that is more suitable to the other. > > asNonNull(x) sounds like the latter to me, since asXxx suggests a conversion. > I'm totally fine with that as the name for the carpet-sweeping version. Okay, got it -- I'd lost track of that side of the conversation. > Note that these are the only methods in Objects that throw anything -- > the rest of the methods in Object are more of the carpet-sweeping variety. So > the name should definitely reflect that these are > assertions/checks/verifications/preconditions. Yes. > Someone suggested assertNonNull(x), and while that sort of captures the intent, > people expect assertXxx methods to throw AssertionError, and it still may > surprise the user on what it does in the common case. Correct. > I suppose ifNonNull() is a possible choice, though it begs the question "where > is the else clause"? > > Unfortunately brevity is somewhat important here because people will use this > inline, such as in the fooWrapper case, which suggest that something is going > to be left unspecified no matter how we slice. > > I'm still liking checkNonNull, mostly because I haven't seen something better > yet. (But nearly all the options are better than the status quo.) I still don't like checkNonNull. It checks whether its argument is non-null, but then what does it do? Throw an exception if it is non-null? Throw an exception if it isn't? Do something else? My aversion to checkNonNull naming pattern comes from experience. Long, long ago in a code base far, far away I wrote a big set of unit tests using this pattern. Coming back to it months later I had to read the code very closely and keep reminding myself that the checkFoo procedures were ensuring the Foo condition rather ensuring nonFoo. So I hereby retract my earlier retraction and re-propose the ensureFoo pattern. We already have various ensureCapacity(int n) methods around, as previously noted, but ensure is such a broadly useful name that we shouldn't limit it only to those cases. Those existing methods would presumably throw exceptions if they can't ensure their postconditions anyway, so an ensureNonNull method is not really so different. Stepping back a bit ... I do think we need to consider, as a couple of people have suggested, whether this method really belongs in java.util.Objects. The other methods in Objects are closely related to the standard Object methods of compare, equals, hashCode, and toString. An ensureNonNull method and similar methods are not. I could imagine wanting to statically import one category of convenience methods but not the other. This argues for putting ensureNonNull and its relatives in a different class, say java.util.Ensure or java.util.Validate. That, in turn, is something that could wait until 8. - Mark From brian.goetz at oracle.com Mon Jan 17 05:26:05 2011 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 17 Jan 2011 00:26:05 -0500 Subject: Objects.nonNull() In-Reply-To: <20110117050639.AE357AAB@eggemoggin.niobe.net> References: <20110117050639.AE357AAB@eggemoggin.niobe.net> Message-ID: <4D33D2ED.2050503@oracle.com> > I still don't like checkNonNull. It checks whether its argument is > non-null, but then what does it do? Throw an exception if it is > non-null? Throw an exception if it isn't? Do something else? > > My aversion to checkNonNull naming pattern comes from experience. Long, > long ago in a code base far, far away I wrote a big set of unit tests > using this pattern. Coming back to it months later I had to read the > code very closely and keep reminding myself that the checkFoo procedures > were ensuring the Foo condition rather ensuring nonFoo. I see your point now. Perhaps you'd prefer requireNonNull() for the throwing version? public void fooWrapper(String s, String t) { foo(requireNonNull(s), requireNonNull(t)); } I get your point about maybe we should just remove this, but I do think that a method that acts on all object references ignorant of the reference type, fits within the mission of juO. From ariel at weisberg.ws Mon Jan 17 06:15:27 2011 From: ariel at weisberg.ws (Ariel Weisberg) Date: Mon, 17 Jan 2011 01:15:27 -0500 Subject: Objects.nonNull() In-Reply-To: <20110117050639.AE357AAB@eggemoggin.niobe.net> References: <20110117050639.AE357AAB@eggemoggin.niobe.net> Message-ID: <1295244927.770.1415651437@webmail.messagingengine.com> Hi all, As a user the first name that came to mind was expect. Expect doesn't imply a specific error signaling pattern, but it does imply that it is an error if the condition is not as expected. Expect is only one letter less than throwIf, but it doesn't include a capital letter. expectNonNull: If the value is null do X where X is some error signaling pattern that I would have to look up or be familiar with as a Java user. assertNonNull: Throws AssertionError on null input if assertions are enabled ensureNonNull: If the value is null return a non-null value checkNonNull: Return false if the argument is null and true otherwise I would be surprised if a method named assert didn't throw AssertionError, or if a method named check did not return a boolean. I would expect an ensure method to perform some corrective action if the named condition isn't met. I do prefer asNonNull over ensureNonNull because it is shorter and implies that a reference is returned. expectNonNull does not do a good job of implying that a reference is returned, and neither does ensureNonNull, but it is clear when read in the context of code. java.util.[Expect | Ensure | Assert | Check] does sound attractive. My 2 cents as a user -Ariel On Sun, 16 Jan 2011 21:06 -0800, mark.reinhold at oracle.com wrote: > > Date: Thu, 13 Jan 2011 19:52:27 -0500 > > From: brian.goetz at oracle.com > > > Mark Reinhold wrote: > >> I'm still troubled by the "check" prefix, though. It implies that the > >> named condition will be tested but it doesn't clearly relate the result > >> of that test to the method's exception-throwing behavior. > >> > >> Here's an idea: Why not treat this as a (degenerate) kind of conversion > >> operation? Call it asNonNull(x) -- it (trivially) converts its argument > >> to a non-null value, and if it can't then it throws an NPE. > >> > >> public Moo fooWrapper(String x, String y) { > >> return foo(asNonNull(x), asNonNull(y)); > >> } > >> > >> Of all the names we've considered, this looks the most natural to me. > > > > I would like to leave room in the namespace to support both of these use cases: > > - I expect non-null, and if I'm wrong, fail > > - I expect non-null, and if I'm wrong, sweep it under the rug > > > > The motivation for this change is that we're currently grabbing nonNull(x) for > > one of them, using a name that is more suitable to the other. > > > > asNonNull(x) sounds like the latter to me, since asXxx suggests a conversion. > > I'm totally fine with that as the name for the carpet-sweeping version. > > Okay, got it -- I'd lost track of that side of the conversation. > > > Note that these are the only methods in Objects that throw anything -- > > the rest of the methods in Object are more of the carpet-sweeping variety. So > > the name should definitely reflect that these are > > assertions/checks/verifications/preconditions. > > Yes. > > > Someone suggested assertNonNull(x), and while that sort of captures the intent, > > people expect assertXxx methods to throw AssertionError, and it still may > > surprise the user on what it does in the common case. > > Correct. > > > I suppose ifNonNull() is a possible choice, though it begs the question "where > > is the else clause"? > > > > Unfortunately brevity is somewhat important here because people will use this > > inline, such as in the fooWrapper case, which suggest that something is going > > to be left unspecified no matter how we slice. > > > > I'm still liking checkNonNull, mostly because I haven't seen something better > > yet. (But nearly all the options are better than the status quo.) > > I still don't like checkNonNull. It checks whether its argument is > non-null, but then what does it do? Throw an exception if it is > non-null? Throw an exception if it isn't? Do something else? > > My aversion to checkNonNull naming pattern comes from experience. Long, > long ago in a code base far, far away I wrote a big set of unit tests > using this pattern. Coming back to it months later I had to read the > code very closely and keep reminding myself that the checkFoo procedures > were ensuring the Foo condition rather ensuring nonFoo. > > So I hereby retract my earlier retraction and re-propose the ensureFoo > pattern. We already have various ensureCapacity(int n) methods around, > as previously noted, but ensure is such a broadly useful name that we > shouldn't limit it only to those cases. Those existing methods would > presumably throw exceptions if they can't ensure their postconditions > anyway, so an ensureNonNull method is not really so different. > > Stepping back a bit ... > > I do think we need to consider, as a couple of people have suggested, > whether this method really belongs in java.util.Objects. > > The other methods in Objects are closely related to the standard Object > methods of compare, equals, hashCode, and toString. An ensureNonNull > method and similar methods are not. I could imagine wanting to > statically import one category of convenience methods but not the other. > This argues for putting ensureNonNull and its relatives in a different > class, say java.util.Ensure or java.util.Validate. That, in turn, is > something that could wait until 8. > > - Mark > From sundararajan.a at sun.com Mon Jan 17 07:59:49 2011 From: sundararajan.a at sun.com (sundararajan.a at sun.com) Date: Mon, 17 Jan 2011 07:59:49 +0000 Subject: hg: jdk7/tl/jdk: 6508943: small typo in the documentation; ... Message-ID: <20110117080018.EEC5747DCD@hg.openjdk.java.net> Changeset: 507627325c81 Author: sundar Date: 2011-01-17 13:29 +0530 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/507627325c81 6508943: small typo in the documentation 6759414: javascript engine can not write to StringWriter 6869617: RhinoScriptEngine bug : ScriptException cause not set (with fix) 7012701: Add a test to check that Rhino's RegExp parser accepts unescaped '[' Reviewed-by: alanb, jjh ! src/share/classes/com/sun/script/javascript/RhinoScriptEngine.java ! src/share/classes/javax/script/CompiledScript.java + test/javax/script/CauseExceptionTest.java + test/javax/script/StringWriterPrintTest.java + test/javax/script/UnescapedBracketRegExTest.java From scolebourne at joda.org Mon Jan 17 08:53:23 2011 From: scolebourne at joda.org (Stephen Colebourne) Date: Mon, 17 Jan 2011 08:53:23 +0000 Subject: Objects.nonNull() In-Reply-To: <4D33D2ED.2050503@oracle.com> References: <20110117050639.AE357AAB@eggemoggin.niobe.net> <4D33D2ED.2050503@oracle.com> Message-ID: On 17 January 2011 05:26, Brian Goetz wrote: >> My aversion to checkNonNull naming pattern comes from experience. ?Long, >> long ago in a code base far, far away I wrote a big set of unit tests >> using this pattern. ?Coming back to it months later I had to read the >> code very closely and keep reminding myself that the checkFoo procedures >> were ensuring the Foo condition rather ensuring nonFoo. I generally use the 'check' prefix for methods that return a boolean. > I see your point now. ?Perhaps you'd prefer requireNonNull() for the > throwing version? > > ?public void fooWrapper(String s, String t) { > ? ? foo(requireNonNull(s), requireNonNull(t)); > ?} Both 'require' and 'ensure' are possible, with 'require' being slightly better in the fluent pattern. However... > I get your point about maybe we should just remove this, but I do think that > a method that acts on all object references ignorant of the reference type, > fits within the mission of juO. You should definitely remove this now!! Its too late in the release cycle to be adding a risky method like this one (which to my eyes is unsuited to the style of the core JDK) whatever you call it. Especially when many of us really want a Validate/Preconditions/Assert/ArgChecker class, not this method (I have used Validate/Preconditions/Assert/ArgChecker to check every public methods arguments in large codebases for the last 10 years - its a vital class!) Stephen From kumar.x.srinivasan at oracle.com Tue Jan 18 16:38:47 2011 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Tue, 18 Jan 2011 16:38:47 +0000 Subject: hg: jdk7/tl/langtools: 6982999: tools must support -target 7 bytecodes Message-ID: <20110118163851.AD27447EA9@hg.openjdk.java.net> Changeset: 5cf6c432ef2f Author: ksrini Date: 2011-01-18 08:37 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/5cf6c432ef2f 6982999: tools must support -target 7 bytecodes Reviewed-by: jjg, jrose ! src/share/classes/com/sun/tools/classfile/Attribute.java + src/share/classes/com/sun/tools/classfile/BootstrapMethods_attribute.java ! src/share/classes/com/sun/tools/classfile/ClassTranslator.java ! src/share/classes/com/sun/tools/classfile/ClassWriter.java ! src/share/classes/com/sun/tools/classfile/ConstantPool.java ! src/share/classes/com/sun/tools/classfile/Dependencies.java ! src/share/classes/com/sun/tools/javac/jvm/ClassFile.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javap/AttributeWriter.java ! src/share/classes/com/sun/tools/javap/ConstantWriter.java From forax at univ-mlv.fr Tue Jan 18 18:00:06 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Tue, 18 Jan 2011 19:00:06 +0100 Subject: hg: jdk7/tl/langtools: 6982999: tools must support -target 7 bytecodes In-Reply-To: <20110118163851.AD27447EA9@hg.openjdk.java.net> References: <20110118163851.AD27447EA9@hg.openjdk.java.net> Message-ID: <4D35D526.5070208@univ-mlv.fr> Nice, thank you, Kumar. R?mi On 01/18/2011 05:38 PM, kumar.x.srinivasan at oracle.com wrote: > Changeset: 5cf6c432ef2f > Author: ksrini > Date: 2011-01-18 08:37 -0800 > URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/5cf6c432ef2f > > 6982999: tools must support -target 7 bytecodes > Reviewed-by: jjg, jrose > > ! src/share/classes/com/sun/tools/classfile/Attribute.java > + src/share/classes/com/sun/tools/classfile/BootstrapMethods_attribute.java > ! src/share/classes/com/sun/tools/classfile/ClassTranslator.java > ! src/share/classes/com/sun/tools/classfile/ClassWriter.java > ! src/share/classes/com/sun/tools/classfile/ConstantPool.java > ! src/share/classes/com/sun/tools/classfile/Dependencies.java > ! src/share/classes/com/sun/tools/javac/jvm/ClassFile.java > ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java > ! src/share/classes/com/sun/tools/javap/AttributeWriter.java > ! src/share/classes/com/sun/tools/javap/ConstantWriter.java > From lvjing at linux.vnet.ibm.com Wed Jan 19 09:06:09 2011 From: lvjing at linux.vnet.ibm.com (Jing LV) Date: Wed, 19 Jan 2011 17:06:09 +0800 Subject: A HashMap bug with a Proxy value? In-Reply-To: References: <4D2DCE76.4000108@linux.vnet.ibm.com>, <4D2DDA16.5070903@oracle.com> <4D2DDDDE.4090206@oracle.com>, <4D2E965C.5080403@linux.vnet.ibm.com> Message-ID: <4D36A981.5030802@linux.vnet.ibm.com> Hi, Thanks for information. I've raised a new bug on openjdk bug system (https://bugs.openjdk.java.net/show_bug.cgi?id=100165) with testcase and patch. ? 2011-1-14 1:46, Jason Mehrens ??: > > > I wonder the design for Proxy and InvocationHandler can be > > enhanced by creating a default equals/toString/hashCode implementation > > for Proxy correctly, not ask developers to do it again and again > > whenever he uses Proxy. Anyway, this may be another story. > > See: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4652876 > > The ProxyGenerator could safely add byte codes to > equals/compareTo/compare that: > 1. Handle the null case per contract: false, NPE, call handler. > 2. Proxy == Argument: true, 0, 0 > 3. Proxy.getClass() == Argument.getClass() && Proxy.h == > Proxy.getClass().cast(argument).h: true,0,0 > > The problem is short circuit operations nor return value overrides are > not allowed per the Proxy contract: "A method invocation on a proxy > instance through one of its proxy interfaces will be dispatched to the > invoke method of the instance's invocation handler...the result that > it returns will be returned as the result of the method invocation on > the proxy instance." > > I think for most equality checks, short circuit would be for the > most part safe since most Collections all ready do such checks but, it > requires a change to the Proxy contract which presents a compatibility > problem. > > > > I think for HashMap, it may be benefit to check "==" as well as equals > > in containsValue() (as containsKey already do) which is a quick > solution > > to resolve such problems. > > Seems like the identity check would be a win: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6486197 > > Jason > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lana.steuck at oracle.com Thu Jan 20 04:56:03 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Thu, 20 Jan 2011 04:56:03 +0000 Subject: hg: jdk7/tl: 2 new changesets Message-ID: <20110120045603.ED7C547F97@hg.openjdk.java.net> Changeset: 5c4df7e99277 Author: cl Date: 2011-01-06 20:10 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/rev/5c4df7e99277 Added tag jdk7-b124 for changeset 024a6755895b ! .hgtags Changeset: b566d4909056 Author: cl Date: 2011-01-13 16:43 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/rev/b566d4909056 Added tag jdk7-b125 for changeset 5c4df7e99277 ! .hgtags From lana.steuck at oracle.com Thu Jan 20 04:56:09 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Thu, 20 Jan 2011 04:56:09 +0000 Subject: hg: jdk7/tl/corba: 2 new changesets Message-ID: <20110120045610.2F37A47F98@hg.openjdk.java.net> Changeset: 1ce58c72b789 Author: cl Date: 2011-01-06 20:10 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/1ce58c72b789 Added tag jdk7-b124 for changeset f90b3e014e83 ! .hgtags Changeset: d7532bcd3742 Author: cl Date: 2011-01-13 16:43 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/d7532bcd3742 Added tag jdk7-b125 for changeset 1ce58c72b789 ! .hgtags From lana.steuck at oracle.com Thu Jan 20 05:01:37 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Thu, 20 Jan 2011 05:01:37 +0000 Subject: hg: jdk7/tl/hotspot: 43 new changesets Message-ID: <20110120050253.8275447F9B@hg.openjdk.java.net> Changeset: 09d92cbb793b Author: cl Date: 2011-01-06 20:10 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/09d92cbb793b Added tag jdk7-b124 for changeset 0a8e0d4345b3 ! .hgtags Changeset: f6a707dbaddb Author: trims Date: 2011-01-07 19:09 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/f6a707dbaddb Added tag hs20-b05 for changeset 0a8e0d4345b3 ! .hgtags Changeset: 9fc3ffb1e0b1 Author: trims Date: 2011-01-07 22:42 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/9fc3ffb1e0b1 7011125: Bump the HS20 build number to 06 Summary: Update the HS20 build number to 06 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 6da3527317ff Author: kevinw Date: 2010-12-17 12:14 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/6da3527317ff 7003487: clhsdbproc stacktrace fails on x64 Reviewed-by: phh ! agent/src/share/classes/sun/jvm/hotspot/ui/classbrowser/HTMLGenerator.java Changeset: 02895c6a2f82 Author: bobv Date: 2010-12-20 14:30 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/02895c6a2f82 7007769: VM crashes with SIGBUS writing PerfData if tmp space is full Summary: Fill perfdata file with zeros to verify available disk space Reviewed-by: coleenp, kamg ! src/os/linux/vm/perfMemory_linux.cpp Changeset: e58d06a8037e Author: dholmes Date: 2010-12-21 23:39 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/e58d06a8037e 7008444: Remove unnecessary include of stdint.h in java_md.c Summary: Remove unnecessary include of stdint.h in java_md.c Reviewed-by: brutisso, kvn ! src/os/posix/launcher/java_md.c Changeset: 1e637defdda6 Author: zgu Date: 2010-12-22 11:24 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/1e637defdda6 6961186: Better VM handling of unexpected exceptions from application native code Summary: Trap uncaught C++ exception on Windows and Solaris and generate hs_err report. Reviewed-by: coleenp, bobv, dholmes ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp Changeset: c19157304e08 Author: zgu Date: 2010-12-22 11:52 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/c19157304e08 Merge ! src/os/windows/vm/os_windows.cpp Changeset: 3da13a976363 Author: coleenp Date: 2010-12-22 12:24 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/3da13a976363 Merge ! agent/src/share/classes/sun/jvm/hotspot/ui/classbrowser/HTMLGenerator.java Changeset: 07c62ff47437 Author: coleenp Date: 2010-12-22 16:52 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/07c62ff47437 Merge Changeset: d6cd0d55d0b5 Author: dcubed Date: 2010-12-23 07:58 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/d6cd0d55d0b5 6987812: 2/3 SAJDI: "gHotSpotVMTypes was not initialized properly in the remote process" Summary: Change ExportDirectoryTableImpl to return the 'Export RVA' field without modification. Read 'Base Of Data' field in optional header when PE32 format COFF file is read. Refine search for dbgeng.dll and dbghelp.dll. Other cleanups. Reviewed-by: swamyv, poonam ! agent/src/share/classes/sun/jvm/hotspot/HotSpotTypeDataBase.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/win32/coff/COFFFileParser.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/win32/coff/DumpExports.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/win32/coff/TestParser.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/windbg/WindbgDebuggerLocal.java Changeset: e0c969b97f66 Author: zgu Date: 2010-12-27 09:30 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/e0c969b97f66 6975480: VS2010 says _STATIC_CPPLIB is deprecated, may need to change this usage Summary: Disabled the warning message during compiling. Reviewed-by: coleenp, dholmes ! make/windows/makefiles/compile.make Changeset: dbf8dcf069d1 Author: zgu Date: 2010-12-27 09:56 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/dbf8dcf069d1 Merge ! make/windows/makefiles/compile.make Changeset: 06e4b9c9db76 Author: coleenp Date: 2010-12-28 09:54 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/06e4b9c9db76 Merge Changeset: 7737fa7ec2b5 Author: twisti Date: 2010-12-14 12:44 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/7737fa7ec2b5 7006044: materialize cheap non-oop pointers on 64-bit SPARC Summary: After 6961690 we load non-oop pointers for the constant table which could easily be materialized in a few instructions. Reviewed-by: never, kvn ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/sparc.ad Changeset: 781072b12368 Author: never Date: 2010-12-14 23:17 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/781072b12368 6765546: Wrong sscanf used to parse CompilerOracle command >= 32 characters could lead to crash Reviewed-by: kvn, iveresov ! src/share/vm/compiler/compilerOracle.cpp Changeset: 4042471b7419 Author: iveresov Date: 2010-12-16 01:46 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/4042471b7419 Merge Changeset: cccd1b172b85 Author: never Date: 2010-12-16 12:47 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/cccd1b172b85 6839888: Array overrun in vm adlc Reviewed-by: kvn, iveresov ! src/share/vm/adlc/dict2.cpp Changeset: c04052fd6ae1 Author: kvn Date: 2010-12-16 14:15 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/c04052fd6ae1 7006505: Use kstat info to identify SPARC processor Summary: read Solaris kstat data to get more precise CPU information Reviewed-by: iveresov, never, twisti, dholmes ! make/solaris/makefiles/buildtree.make ! make/solaris/makefiles/vm.make ! src/cpu/sparc/vm/sparc.ad ! src/cpu/sparc/vm/vm_version_sparc.cpp ! src/cpu/sparc/vm/vm_version_sparc.hpp ! src/os/solaris/vm/os_solaris.cpp ! src/os_cpu/solaris_sparc/vm/vm_version_solaris_sparc.cpp ! src/share/vm/memory/universe.cpp Changeset: 7223744c2784 Author: never Date: 2010-12-17 15:55 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/7223744c2784 6579789: Internal error "c1_LinearScan.cpp:1429 Error: assert(false,"")" in debuggee with fastdebug VM Reviewed-by: kvn, iveresov ! src/share/vm/c1/c1_LinearScan.cpp ! src/share/vm/c1/c1_LinearScan.hpp + test/compiler/6579789/Test6579789.java Changeset: 52d615436cef Author: never Date: 2010-12-18 06:40 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/52d615436cef Merge Changeset: 7d9caaedafce Author: twisti Date: 2010-12-18 01:15 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/7d9caaedafce 6990933: assert(sender_cb) failed: sanity in frame::sender_for_interpreter_frame Reviewed-by: never ! src/share/vm/code/nmethod.cpp Changeset: 1fb0500f550e Author: twisti Date: 2010-12-18 08:38 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/1fb0500f550e Merge Changeset: ef3c5db0b3ae Author: twisti Date: 2010-12-21 04:37 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/ef3c5db0b3ae 7008165: Garbage in ClassFormatError message Summary: When bootstrap_method_ref in BootstrapMethods attribute points to a wrong CP entry (non-MethodHandle), JVM throws ClassFormatError with a message, where method index and class file name is garbage. Reviewed-by: iveresov ! src/share/vm/classfile/classFileParser.cpp Changeset: a21ff35351ec Author: kvn Date: 2010-12-21 13:56 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/a21ff35351ec 7003130: assert(iterations start) failed: need enough space to divide up Summary: Codebuffer can overflow on test with large number of calls Reviewed-by: dholmes, collins ! src/share/vm/c1/c1_Compilation.cpp ! src/share/vm/c1/c1_Compilation.hpp Changeset: 4537d449ba57 Author: bobv Date: 2011-01-07 15:57 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/4537d449ba57 Merge Changeset: b1a2afa37ec4 Author: phh Date: 2011-01-07 10:42 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/b1a2afa37ec4 7003271: Hotspot should track cumulative Java heap bytes allocated on a per-thread basis Summary: Track allocated bytes in Thread's, update on TLAB retirement and direct allocation in Eden and tenured, add JNI methods for ThreadMXBean. Reviewed-by: coleenp, kvn, dholmes, ysr ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/c1_MacroAssembler_sparc.cpp ! src/cpu/sparc/vm/c1_MacroAssembler_sparc.hpp ! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/c1_MacroAssembler_x86.cpp ! src/cpu/x86/vm/c1_Runtime1_x86.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/solaris/vm/thread_solaris.inline.hpp ! src/share/vm/gc_interface/collectedHeap.inline.hpp ! src/share/vm/memory/threadLocalAllocBuffer.cpp ! src/share/vm/memory/threadLocalAllocBuffer.hpp ! src/share/vm/opto/macro.cpp ! src/share/vm/prims/jvmti.xml ! src/share/vm/prims/jvmtiEnv.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/services/jmm.h ! src/share/vm/services/management.cpp ! src/share/vm/services/threadService.cpp ! src/share/vm/services/threadService.hpp Changeset: 55d7d18ccff9 Author: dcubed Date: 2011-01-07 13:59 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/55d7d18ccff9 Merge Changeset: 84f36150fcc3 Author: dcubed Date: 2011-01-07 15:54 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/84f36150fcc3 Merge ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/os/solaris/vm/os_solaris.cpp Changeset: e24ab3fa6aaf Author: trims Date: 2011-01-07 22:56 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/e24ab3fa6aaf Merge ! make/jprt.properties Changeset: 4c851c931d00 Author: cl Date: 2011-01-13 16:43 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/4c851c931d00 Added tag jdk7-b125 for changeset e24ab3fa6aaf ! .hgtags From lana.steuck at oracle.com Thu Jan 20 05:04:14 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Thu, 20 Jan 2011 05:04:14 +0000 Subject: hg: jdk7/tl/jaxp: 4 new changesets Message-ID: <20110120050414.DC4E747F9C@hg.openjdk.java.net> Changeset: 6c9bdee0cc3a Author: cl Date: 2011-01-06 20:10 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/6c9bdee0cc3a Added tag jdk7-b124 for changeset 57ed1f3bec72 ! .hgtags Changeset: 116b935148bc Author: cl Date: 2011-01-13 16:43 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/116b935148bc Added tag jdk7-b125 for changeset 6c9bdee0cc3a ! .hgtags Changeset: 64c84c62ec2a Author: lana Date: 2011-01-13 14:55 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/64c84c62ec2a Merge Changeset: 2fde639439c1 Author: lana Date: 2011-01-14 13:48 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/2fde639439c1 Merge From lana.steuck at oracle.com Thu Jan 20 05:04:19 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Thu, 20 Jan 2011 05:04:19 +0000 Subject: hg: jdk7/tl/jaxws: 4 new changesets Message-ID: <20110120050419.D9C8C47F9D@hg.openjdk.java.net> Changeset: d72eea121c3b Author: cl Date: 2011-01-06 20:10 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/d72eea121c3b Added tag jdk7-b124 for changeset 86f60e5b3975 ! .hgtags Changeset: e8fc02b4c889 Author: cl Date: 2011-01-13 16:43 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/e8fc02b4c889 Added tag jdk7-b125 for changeset d72eea121c3b ! .hgtags Changeset: dba69d6345d9 Author: lana Date: 2011-01-13 14:55 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/dba69d6345d9 Merge Changeset: 6d772c5119d5 Author: lana Date: 2011-01-14 13:48 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/6d772c5119d5 Merge From lana.steuck at oracle.com Thu Jan 20 05:07:52 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Thu, 20 Jan 2011 05:07:52 +0000 Subject: hg: jdk7/tl/jdk: 56 new changesets Message-ID: <20110120051721.A712847FA2@hg.openjdk.java.net> Changeset: 0a56bdd709d0 Author: cl Date: 2011-01-06 20:10 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/0a56bdd709d0 Added tag jdk7-b124 for changeset 1c72adc9d5f3 ! .hgtags Changeset: 3972926bc8f1 Author: cl Date: 2011-01-13 16:44 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/3972926bc8f1 Added tag jdk7-b125 for changeset 0a56bdd709d0 ! .hgtags Changeset: 4d6f9aaa2600 Author: flar Date: 2010-12-14 13:25 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/4d6f9aaa2600 6766342: Improve performance of Ductus rasterizer Reviewed-by: jgodinez, prr ! make/sun/awt/make.depend ! make/sun/awt/mapfile-vers ! make/sun/awt/mapfile-vers-linux ! src/share/classes/sun/dc/DuctusRenderingEngine.java ! src/share/classes/sun/java2d/SurfaceData.java ! src/share/classes/sun/java2d/loops/CompositeType.java ! src/share/classes/sun/java2d/loops/MaskFill.java ! src/share/classes/sun/java2d/pipe/AAShapePipe.java ! src/share/classes/sun/java2d/pipe/AlphaColorPipe.java ! src/share/classes/sun/java2d/pipe/RenderingEngine.java ! src/share/classes/sun/java2d/pisces/PiscesRenderingEngine.java ! src/share/native/sun/java2d/loops/DrawParallelogram.c ! src/share/native/sun/java2d/loops/FillParallelogram.c ! src/share/native/sun/java2d/loops/MaskFill.c + src/share/native/sun/java2d/loops/ParallelogramUtils.h ! src/solaris/native/sun/java2d/loops/vis_IntArgbPre_Mask.c ! src/solaris/native/sun/java2d/loops/vis_SrcMaskFill.c + test/java/awt/Graphics2D/RenderClipTest/6766342.tests + test/java/awt/Graphics2D/RenderClipTest/RenderClipTest.java Changeset: 9d0eebb55003 Author: bae Date: 2010-12-15 19:47 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/9d0eebb55003 6782574: AffineTransformOp.filter(BufferedImage, BufferedImage) fails with InternalError Reviewed-by: igor, prr ! src/share/classes/java/awt/image/SinglePixelPackedSampleModel.java ! src/share/native/sun/awt/image/awt_parseImage.c + test/java/awt/image/IncorrectSampleMaskTest.java Changeset: 6a219e5ccfd7 Author: bae Date: 2010-12-17 13:18 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/6a219e5ccfd7 7006948: FindBugs warning in IndexColorModel class Reviewed-by: igor, prr ! src/share/classes/java/awt/image/IndexColorModel.java Changeset: 33a0f66771d5 Author: jgodinez Date: 2010-12-17 09:39 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/33a0f66771d5 6635462: D3D: REGRESSION: XOR rendering is extremly slow Reviewed-by: igor, prr ! src/share/classes/javax/swing/DefaultDesktopManager.java ! src/windows/classes/sun/awt/windows/WComponentPeer.java ! src/windows/classes/sun/java2d/d3d/D3DSurfaceData.java Changeset: 0125062d65b6 Author: bae Date: 2010-12-20 10:38 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/0125062d65b6 6736178: java.awt.image.SampleModel constructor unexpectedly throws IllegalArgumentException Reviewed-by: jgodinez, prr ! src/share/classes/java/awt/image/SampleModel.java Changeset: b0f9760f3103 Author: prr Date: 2010-12-22 13:32 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/b0f9760f3103 7007299: FileFontStrike appears not to be threadsafe? Reviewed-by: igor, jgodinez ! src/share/classes/sun/font/FileFontStrike.java Changeset: 1513ccf103a9 Author: prr Date: 2010-12-22 13:49 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/1513ccf103a9 6996867: Garbage rendering of LCD text with SRC composite mode Reviewed-by: igor, jgodinez ! src/share/classes/sun/java2d/SurfaceData.java + test/java/awt/Graphics2D/DrawString/LCDTextSrcEa.java Changeset: 78d0a8d449fd Author: bae Date: 2010-12-23 14:27 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/78d0a8d449fd 7002627: JNI Critical Arrays should be released with the original (unmodified) pointer Reviewed-by: jgodinez, prr ! src/share/native/sun/java2d/pipe/BufferedMaskBlit.c Changeset: cb3c0ffb27bb Author: lana Date: 2010-12-23 00:03 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/cb3c0ffb27bb Merge - src/share/classes/java/dyn/BootstrapMethod.java - src/share/classes/java/dyn/LinkagePermission.java - src/share/classes/java/dyn/MethodHandleProvider.java - src/share/classes/sun/dyn/JavaMethodHandle.java - src/share/demo/nio/zipfs/META-INF/services/java.nio.file.spi.FileSystemProvider - src/share/demo/nio/zipfs/com/sun/nio/zipfs/JarFileSystemProvider.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipCoder.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipConstants.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipDirectoryStream.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileAttributeView.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileAttributes.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileStore.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileSystem.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileSystemProvider.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipInfo.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipPath.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipUtils.java - test/java/dyn/JavaDocExamples.java Changeset: 155d91257957 Author: lana Date: 2010-12-23 08:47 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/155d91257957 Merge Changeset: 7fff69f28bf4 Author: jgodinez Date: 2010-12-23 10:38 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/7fff69f28bf4 6913300: Missing serialVersionUID in javax.print.attribute.standard.DialogTypeSelection Reviewed-by: igor, prr ! src/share/classes/javax/print/attribute/standard/DialogTypeSelection.java Changeset: b22c74e20a1b Author: jgodinez Date: 2010-12-23 11:01 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/b22c74e20a1b 6949749: regression cases need to be updated by removing "System.exit(0)" Reviewed-by: igor, prr ! test/java/awt/PrintJob/Text/StringWidth.java Changeset: 417acb7e8fa1 Author: prr Date: 2010-12-23 15:28 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/417acb7e8fa1 6891551: Font rasterisation uses more heap than needed for some strikes. Reviewed-by: jgodinez ! src/share/classes/sun/font/FileFontStrike.java Changeset: 4e47e55dd717 Author: prr Date: 2010-12-23 21:58 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/4e47e55dd717 6927458: font system should cache transient strikes with weak references. Reviewed-by: igor, jgodinez ! src/share/classes/sun/font/Font2D.java Changeset: 99c540ac926c Author: bae Date: 2010-12-24 14:05 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/99c540ac926c 6983028: java/awt/FontClass/FontPrivilege.java Reviewed-by: prr ! test/java/awt/FontClass/FontPrivilege.java Changeset: 14033e1600ac Author: prr Date: 2010-12-24 09:31 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/14033e1600ac 6997210: Solaris 11 has no development support for DGA: Cannot build JDK Reviewed-by: bae, ohair ! make/sun/Makefile Changeset: 70bfa0af3969 Author: bae Date: 2010-12-30 11:33 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/70bfa0af3969 7003434: test/closed/java/awt/FullScreen/DisplayChangeVITest/DisplayChangeVITest.java fails with ClassCastExc Reviewed-by: jgodinez, prr ! src/windows/classes/sun/java2d/opengl/WGLVolatileSurfaceManager.java Changeset: 9320dcfb5398 Author: lana Date: 2011-01-05 11:21 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/9320dcfb5398 Merge - make/common/internal/BinaryPlugs.gmk ! make/sun/Makefile ! make/sun/awt/mapfile-vers ! make/sun/awt/mapfile-vers-linux ! src/share/classes/java/awt/image/IndexColorModel.java ! src/share/classes/java/awt/image/SampleModel.java ! src/share/classes/javax/swing/DefaultDesktopManager.java ! src/share/classes/sun/java2d/SurfaceData.java ! src/share/classes/sun/java2d/pisces/PiscesRenderingEngine.java ! src/share/native/sun/java2d/loops/DrawParallelogram.c ! src/share/native/sun/java2d/loops/FillParallelogram.c ! src/windows/classes/sun/awt/windows/WComponentPeer.java Changeset: 3db5ac2b4c62 Author: andrew Date: 2010-12-14 13:51 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/3db5ac2b4c62 6444769: java/awt/Insets/WindowWithWarningTest/WindowWithWarningTest.html fails Summary: Remove unneeded test Reviewed-by: anthony - test/java/awt/Insets/WindowWithWarningTest/WindowWithWarningTest.html - test/java/awt/Insets/WindowWithWarningTest/WindowWithWarningTest.java Changeset: b9706aff91a3 Author: lana Date: 2010-12-15 11:49 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/b9706aff91a3 Merge - src/share/classes/sun/net/httpserver/SelectorCache.java Changeset: 4a0970a420d5 Author: anthony Date: 2010-12-16 21:48 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/4a0970a420d5 6993803: Request to update SplashScreen specification 6984255: Request for java.awt.SplashScreen spec update: mention possibility of having custom "-splash" option 6992416: [Spec clarification request] Is color deviation for splash screen image allowed? 6992833: [Spec clarification request] point (0,0) in SplashScreen.createGraphics() 6993071: java.awt.SplashScreen should mention that no unnecessary distortions to the image are allowed 6993113: [Spec clarification request] getSplashScreen(): null or HeadlessException? 6996439: [Spec clarification request] Is any delay with splashscreen appearance allowed? Summary: Update SplashScreen specification Reviewed-by: art ! src/share/classes/java/awt/SplashScreen.java Changeset: 8dbb797793b0 Author: anthony Date: 2010-12-22 17:37 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/8dbb797793b0 6998323: Unexpected color change after invoking SplashScreen.update() Summary: Fix the blendRGB() function Reviewed-by: art, dcherepanov ! src/share/native/sun/awt/splashscreen/splashscreen_gfx_impl.h Changeset: 15c45fdd572c Author: lana Date: 2010-12-23 10:20 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/15c45fdd572c Merge - src/share/classes/java/dyn/BootstrapMethod.java - src/share/classes/java/dyn/LinkagePermission.java - src/share/classes/java/dyn/MethodHandleProvider.java - src/share/classes/sun/dyn/JavaMethodHandle.java - src/share/demo/nio/zipfs/META-INF/services/java.nio.file.spi.FileSystemProvider - src/share/demo/nio/zipfs/com/sun/nio/zipfs/JarFileSystemProvider.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipCoder.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipConstants.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipDirectoryStream.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileAttributeView.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileAttributes.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileStore.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileSystem.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileSystemProvider.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipInfo.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipPath.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipUtils.java - src/share/native/sun/font/layout/HebrewLigatureData.cpp - src/share/native/sun/font/layout/HebrewShaping.cpp - src/share/native/sun/font/layout/HebrewShaping.h - test/java/dyn/JavaDocExamples.java Changeset: 6e4d9f4466f6 Author: dcherepanov Date: 2010-12-27 18:37 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/6e4d9f4466f6 4887645: Remove "awt.threadgroup" system property Reviewed-by: art, anthony ! src/share/classes/sun/awt/SunToolkit.java Changeset: a0a4f73b3d1d Author: dcherepanov Date: 2010-12-27 18:42 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/a0a4f73b3d1d 6957765: Test Bug - javax/swing/SwingWorker/6480289/bug6480289.java failed on 1.7.0b94 but passed on previous Reviewed-by: art, alexp - test/javax/swing/SwingWorker/6480289/bug6480289.java Changeset: 33d4e0de0424 Author: dcherepanov Date: 2010-12-27 18:43 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/33d4e0de0424 6866808: nsk/stress/jck12a/jck12a014 crashes with SIGSEGV at [libjvm.so+0xc5b10] Reviewed-by: art ! src/solaris/native/sun/xawt/XToolkit.c Changeset: c90a0da7649e Author: dcherepanov Date: 2010-12-27 18:45 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c90a0da7649e 6921598: PrinterDialog hidden behind other frames Reviewed-by: art ! src/windows/native/sun/windows/awt_Dialog.cpp ! src/windows/native/sun/windows/awt_Dialog.h Changeset: 39e9d5613145 Author: dav Date: 2010-12-28 17:13 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/39e9d5613145 6999766: Changes to correct c/c++ language issues for use of parfait Reviewed-by: uta, amenkov ! src/windows/native/sun/windows/Devices.h ! src/windows/native/sun/windows/awt.h ! src/windows/native/sun/windows/awt_Debug.cpp ! src/windows/native/sun/windows/awt_Debug.h ! src/windows/native/sun/windows/awt_DesktopProperties.cpp ! src/windows/native/sun/windows/awt_TextArea.h ! src/windows/native/sun/windows/awt_Toolkit.h Changeset: 8b05f9b91765 Author: dav Date: 2010-12-29 15:13 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/8b05f9b91765 7008106: com/sun/awt/Translucency/WindowOpacity.java test fails just against jdk7 b122 Reviewed-by: dcherepanov ! test/com/sun/awt/Translucency/WindowOpacity.java Changeset: 78364959fc73 Author: dav Date: 2010-12-29 17:36 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/78364959fc73 6963357: After clicking the "Load" button,the case FileDialogUserFilterTest.html crashes in jdk7 b98. Reviewed-by: dcherepanov ! src/solaris/native/sun/awt/sun_awt_X11_GtkFileDialogPeer.c Changeset: aa03f76d0e80 Author: lana Date: 2011-01-05 15:54 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/aa03f76d0e80 Merge - make/common/internal/BinaryPlugs.gmk ! src/share/classes/java/awt/SplashScreen.java ! src/share/classes/sun/awt/SunToolkit.java ! src/windows/native/sun/windows/awt.h ! src/windows/native/sun/windows/awt_DesktopProperties.cpp ! src/windows/native/sun/windows/awt_Dialog.cpp ! src/windows/native/sun/windows/awt_Toolkit.h Changeset: bde32b5becf1 Author: lana Date: 2011-01-06 18:01 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/bde32b5becf1 Merge - test/java/awt/Insets/WindowWithWarningTest/WindowWithWarningTest.html - test/java/awt/Insets/WindowWithWarningTest/WindowWithWarningTest.java - test/javax/swing/SwingWorker/6480289/bug6480289.java Changeset: ec02d02d3409 Author: okutsu Date: 2010-12-15 11:38 +0900 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/ec02d02d3409 6990037: font warnings in the build, missing fonts Reviewed-by: peytoia ! make/sun/awt/Makefile ! src/share/classes/sun/awt/FontConfiguration.java Changeset: cd7b5fb40005 Author: okutsu Date: 2010-12-17 16:56 +0900 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/cd7b5fb40005 7007583: (tz) Windows-only: update tzmappings for KB2443685 Reviewed-by: peytoia ! src/windows/lib/tzmappings Changeset: 7c7e4a0330bc Author: okutsu Date: 2010-12-17 17:13 +0900 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/7c7e4a0330bc 6644493: [Fmt-Da] SimpleDateFormat parsing RFC822 time offset is slow Reviewed-by: peytoia ! src/share/classes/java/text/SimpleDateFormat.java ! test/java/text/Format/DateFormat/ISO8601ZoneTest.java Changeset: f710204034fd Author: okutsu Date: 2010-12-17 18:06 +0900 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f710204034fd 6983207: API: MessageFormat quote handling discrepancy Reviewed-by: peytoia ! src/share/classes/java/text/MessageFormat.java Changeset: 89d065844fb6 Author: okutsu Date: 2010-12-21 10:58 +0900 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/89d065844fb6 6943959: NumericShaper API doc doesn't describe ARABIC/EASTERN_ARABIC precedence Reviewed-by: peytoia ! src/share/classes/java/awt/font/NumericShaper.java Changeset: 8da79c7d137e Author: okutsu Date: 2010-12-21 11:20 +0900 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/8da79c7d137e 7007905: javazic produces wrong line numbers Reviewed-by: peytoia ! make/tools/src/build/tools/javazic/Zoneinfo.java Changeset: 55d9205735e1 Author: naoto Date: 2010-12-21 16:14 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/55d9205735e1 4940539: Constructor of java.util.Locale should handle ISO 639-2 Language Codes Reviewed-by: okutsu ! src/share/classes/java/util/Locale.java ! test/java/util/Locale/LocaleTest.java Changeset: 403a88eeac15 Author: lana Date: 2010-12-22 16:57 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/403a88eeac15 Merge - src/share/classes/java/dyn/BootstrapMethod.java - src/share/classes/java/dyn/LinkagePermission.java - src/share/classes/java/dyn/MethodHandleProvider.java - src/share/classes/sun/dyn/JavaMethodHandle.java - src/share/demo/nio/zipfs/META-INF/services/java.nio.file.spi.FileSystemProvider - src/share/demo/nio/zipfs/com/sun/nio/zipfs/JarFileSystemProvider.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipCoder.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipConstants.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipDirectoryStream.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileAttributeView.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileAttributes.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileStore.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileSystem.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileSystemProvider.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipInfo.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipPath.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipUtils.java - src/share/native/sun/font/layout/HebrewLigatureData.cpp - src/share/native/sun/font/layout/HebrewShaping.cpp - src/share/native/sun/font/layout/HebrewShaping.h - test/java/dyn/JavaDocExamples.java Changeset: c8b383fd8adf Author: rupashka Date: 2010-12-23 17:39 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c8b383fd8adf 6973773: JCK manual case JSliderTests.html#JSlider fails in jdk7 b100 Reviewed-by: alexp ! src/share/classes/javax/swing/JSlider.java Changeset: 69b2e5838eee Author: rupashka Date: 2010-12-23 18:25 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/69b2e5838eee 7007708: TEST: javax/swing/JScrollBar/6542335/bug6542335.java failes agaisnt jdk7 on solaris/linux Reviewed-by: alexp ! test/javax/swing/JScrollBar/6542335/bug6542335.java Changeset: 94e0438c74c3 Author: okutsu Date: 2010-12-27 14:13 +0900 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/94e0438c74c3 7003643: [Fmt-Me] MessageFormat.toPattern produces wrong quoted string and subformat modifiers 7008195: [Fmt-Me] Improve MessageFormat.applyPattern performance Reviewed-by: naoto, peytoia ! src/share/classes/java/text/MessageFormat.java + test/java/text/Format/MessageFormat/Bug7003643.java ! test/java/util/PluggableLocale/DateFormatProviderTest.java ! test/java/util/PluggableLocale/DateFormatProviderTest.sh ! test/java/util/PluggableLocale/NumberFormatProviderTest.java ! test/java/util/PluggableLocale/NumberFormatProviderTest.sh ! test/java/util/PluggableLocale/fooprovider.jar ! test/java/util/PluggableLocale/providersrc/DateFormatProviderImpl.java + test/java/util/PluggableLocale/providersrc/FooDateFormat.java + test/java/util/PluggableLocale/providersrc/FooNumberFormat.java ! test/java/util/PluggableLocale/providersrc/Makefile ! test/java/util/PluggableLocale/providersrc/NumberFormatProviderImpl.java Changeset: c06d4327c0f2 Author: rupashka Date: 2010-12-27 15:28 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c06d4327c0f2 6959584: closed/javax/swing/JFileChooser/4847375/bug4847375.java : compilation failed Reviewed-by: alexp + test/javax/swing/JFileChooser/4847375/bug4847375.java Changeset: 72f1247e9ff5 Author: rupashka Date: 2010-12-27 17:41 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/72f1247e9ff5 6532833: PIT: Metal LAF - The right side border is not shown for the Spinner after the removing the buttons Reviewed-by: alexp ! src/share/classes/javax/swing/plaf/basic/BasicSpinnerUI.java + test/javax/swing/JSpinner/6532833/bug6532833.java Changeset: 2c3c88a389b0 Author: amenkov Date: 2010-12-28 16:37 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/2c3c88a389b0 6842956: Assertion error in javax_sound on 64-bit RHEL 5.3 with 32-bit JDK Reviewed-by: bae ! src/solaris/native/com/sun/media/sound/PLATFORM_API_LinuxOS_ALSA_MidiIn.c Changeset: ac1e3f99a69e Author: amenkov Date: 2010-12-29 16:26 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/ac1e3f99a69e 7006997: A typo in MidiSystem.getTransmitter() implementation code Reviewed-by: dav ! src/share/classes/javax/sound/midi/MidiSystem.java Changeset: be27227ff554 Author: amenkov Date: 2010-12-30 14:57 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/be27227ff554 6989702: sound native code compiler warnings Reviewed-by: bae ! src/solaris/native/com/sun/media/sound/PLATFORM_API_LinuxOS_ALSA_CommonUtils.c ! src/solaris/native/com/sun/media/sound/PLATFORM_API_LinuxOS_ALSA_MidiUtils.c ! src/solaris/native/com/sun/media/sound/PLATFORM_API_LinuxOS_ALSA_PCM.c ! src/solaris/native/com/sun/media/sound/PLATFORM_API_LinuxOS_ALSA_PCMUtils.h ! src/solaris/native/com/sun/media/sound/PLATFORM_API_LinuxOS_ALSA_Ports.c Changeset: 349b67ae3e08 Author: lana Date: 2011-01-04 23:41 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/349b67ae3e08 Merge - make/common/internal/BinaryPlugs.gmk ! make/sun/awt/Makefile ! src/share/classes/java/text/MessageFormat.java ! src/share/classes/javax/sound/midi/MidiSystem.java Changeset: fff6fd437f4a Author: lana Date: 2011-01-06 18:03 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/fff6fd437f4a Merge Changeset: c4ec4f80f44e Author: lana Date: 2011-01-06 18:05 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c4ec4f80f44e Merge - test/javax/script/E4XErrorTest.java - test/sun/security/krb5/auto/basic.sh Changeset: 1513e13fae08 Author: lana Date: 2011-01-13 15:03 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/1513e13fae08 Merge - test/java/awt/Insets/WindowWithWarningTest/WindowWithWarningTest.html - test/java/awt/Insets/WindowWithWarningTest/WindowWithWarningTest.java - test/javax/script/E4XErrorTest.java - test/javax/swing/SwingWorker/6480289/bug6480289.java - test/sun/security/krb5/auto/basic.sh Changeset: 8361ef97a0f9 Author: lana Date: 2011-01-14 13:48 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/8361ef97a0f9 Merge Changeset: 9596a600758c Author: lana Date: 2011-01-19 19:00 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/9596a600758c Merge - test/java/awt/Insets/WindowWithWarningTest/WindowWithWarningTest.html - test/java/awt/Insets/WindowWithWarningTest/WindowWithWarningTest.java - test/javax/swing/SwingWorker/6480289/bug6480289.java From lana.steuck at oracle.com Thu Jan 20 05:20:47 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Thu, 20 Jan 2011 05:20:47 +0000 Subject: hg: jdk7/tl/langtools: 5 new changesets Message-ID: <20110120052056.A882D47FA3@hg.openjdk.java.net> Changeset: 4b0560c72b52 Author: cl Date: 2011-01-06 20:10 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/4b0560c72b52 Added tag jdk7-b124 for changeset 4868a36f6fd8 ! .hgtags Changeset: 62bdb6767734 Author: cl Date: 2011-01-13 16:44 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/62bdb6767734 Added tag jdk7-b125 for changeset 4b0560c72b52 ! .hgtags Changeset: 20fec1b88bc1 Author: lana Date: 2011-01-13 15:05 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/20fec1b88bc1 Merge - test/tools/javac/meth/InvokeDyn.java - test/tools/javac/meth/InvokeDynTrans.java Changeset: 438a8ad60f7a Author: lana Date: 2011-01-14 13:48 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/438a8ad60f7a Merge Changeset: b6f95173e769 Author: lana Date: 2011-01-19 19:01 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/b6f95173e769 Merge From chris.hegarty at oracle.com Thu Jan 20 13:30:56 2011 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 20 Jan 2011 13:30:56 +0000 Subject: Code Review 7011857: java/util/concurrent/Phaser/FickleRegister.java fails on solaris-sparc Message-ID: <4D383910.6090309@oracle.com> Alan, FickleRegister.java can be removed from the ProblemList since it now passes, as a result of the changes for CR 7009231. diff -r 983364897f72 test/ProblemList.txt --- a/test/ProblemList.txt Fri Jan 14 22:34:31 2011 +0000 +++ b/test/ProblemList.txt Thu Jan 20 13:25:02 2011 +0000 @@ -734,8 +734,5 @@ java/util/concurrent/locks/Lock/TimedAcq # Fails on solaris-sparc -server (Set not equal to copy. 1) java/util/EnumSet/EnumSetBash.java solaris-sparc -# Fails on solaris-sparc, see 7011857 -java/util/concurrent/Phaser/FickleRegister.java solaris-sparc - Thanks, -Chris From Alan.Bateman at oracle.com Thu Jan 20 13:41:25 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 20 Jan 2011 13:41:25 +0000 Subject: Code Review 7011857: java/util/concurrent/Phaser/FickleRegister.java fails on solaris-sparc In-Reply-To: <4D383910.6090309@oracle.com> References: <4D383910.6090309@oracle.com> Message-ID: <4D383B85.9090404@oracle.com> Chris Hegarty wrote: > Alan, > > FickleRegister.java can be removed from the ProblemList since it now > passes, as a result of the changes for CR 7009231. > > diff -r 983364897f72 test/ProblemList.txt > --- a/test/ProblemList.txt Fri Jan 14 22:34:31 2011 +0000 > +++ b/test/ProblemList.txt Thu Jan 20 13:25:02 2011 +0000 > @@ -734,8 +734,5 @@ java/util/concurrent/locks/Lock/TimedAcq > # Fails on solaris-sparc -server (Set not equal to copy. 1) > java/util/EnumSet/EnumSetBash.java solaris-sparc > > -# Fails on solaris-sparc, see 7011857 > -java/util/concurrent/Phaser/FickleRegister.java solaris-sparc > - > > Thanks, > -Chris Looks good to me. -Alan. From chris.hegarty at oracle.com Thu Jan 20 15:24:44 2011 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Thu, 20 Jan 2011 15:24:44 +0000 Subject: hg: jdk7/tl/jdk: 7011857: java/util/concurrent/Phaser/FickleRegister.java fails on solaris-sparc Message-ID: <20110120152454.076F747FBD@hg.openjdk.java.net> Changeset: e64b1f11cd0b Author: chegar Date: 2011-01-20 15:23 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e64b1f11cd0b 7011857: java/util/concurrent/Phaser/FickleRegister.java fails on solaris-sparc Summary: Remove from ProblemList, failure resolved by 7009231 Reviewed-by: alanb ! test/ProblemList.txt From iaroslavski at mail.ru Thu Jan 20 18:09:19 2011 From: iaroslavski at mail.ru (Vladimir Iaroslavski) Date: Thu, 20 Jan 2011 21:09:19 +0300 Subject: Dual-Pivot Quicksort improvements for highly structured (nearly sorted) arrays and data with small periods Message-ID: Hello, Here is improvement for sorting primitives: http://cr.openjdk.java.net/~alanb/7013585/webrev Highly structured (nearly sorted) data like 1,2,3,..,k,1,2,3,..,k,... or 1,2,3,...,n/2,n/2,...,3,2,1 etc. is sorted very effectively by merge sort. The main idea of this optimization is to check if given array is nearly sorted and apply modified and improved merge sort on it. Otherwise, Dual-Pivot Quicksort is applied. Note that the check doesn't decrease the performance of sorting. Other optimization is related to random or repeated data with small period, m <= 10. This type of data is sorted faster by Quicksort with one pivot but with DNF (Dutch National Flag) partition. Therefore, sorting is switched to DNF even calculated pivots are different. The boost of performance with new optimizations is: random data: new: 135, old: 154, ratio: 87.6% ascending: new: 3, old: 45, ratio: 6.6% descending: new: 5, old: 48, ratio: 10.4% organ pipes: new: 20, old: 80, ratio: 25% period(m), m <= 10: new: 10, old: 15, ratio: 66.6% random(m), m <= 10: new: 11, old: 16, ratio: 68.7% equal: new: 2.5, old: 3, new: 83.3% On test suite suggested by Jon Bentley we see the following performance: client VM: old 56%, new 43% server VM: old 46%, new 29% Thank you, Vladimir From mandy.chung at oracle.com Thu Jan 20 23:21:18 2011 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 20 Jan 2011 15:21:18 -0800 Subject: Code review request: 6912013 "Remove the temporary launcher fix to add modules in the bootclasspath" Message-ID: <4D38C36E.9040402@oracle.com> Kumar, Can you review a launcher fix for: 6912013: Remove the temporary launcher fix to add modules in the bootclasspath Webrev at: http://cr.openjdk.java.net/~mchung/6912013/webrev.00/ I also include some cleanup done in the jigsaw repository in this changeset that will make the future merge easier. Thanks Mandy From kumar.x.srinivasan at oracle.COM Fri Jan 21 00:25:25 2011 From: kumar.x.srinivasan at oracle.COM (Kumar Srinivasan) Date: Thu, 20 Jan 2011 16:25:25 -0800 Subject: Code review request: 6912013 "Remove the temporary launcher fix to add modules in the bootclasspath" In-Reply-To: <4D38C36E.9040402@oracle.com> References: <4D38C36E.9040402@oracle.com> Message-ID: <4D38D275.9020509@oracle.COM> Approved Kumar > Kumar, > > Can you review a launcher fix for: > 6912013: Remove the temporary launcher fix to add modules in the > bootclasspath > > Webrev at: > http://cr.openjdk.java.net/~mchung/6912013/webrev.00/ > > I also include some cleanup done in the jigsaw repository in this > changeset that will make the future merge easier. > > Thanks > Mandy From mandy.chung at oracle.com Fri Jan 21 06:27:06 2011 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Fri, 21 Jan 2011 06:27:06 +0000 Subject: hg: jdk7/tl: 7013739: jdk_rmi target is missing in the top repo's test/Makefile Message-ID: <20110121062706.6940A47018@hg.openjdk.java.net> Changeset: f722c246ce71 Author: mchung Date: 2011-01-20 22:16 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/rev/f722c246ce71 7013739: jdk_rmi target is missing in the top repo's test/Makefile Reviewed-by: ohair, igor ! test/Makefile From mandy.chung at oracle.com Fri Jan 21 06:27:46 2011 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Fri, 21 Jan 2011 06:27:46 +0000 Subject: hg: jdk7/tl/jdk: 7013739: jdk_rmi target is missing in the top repo's test/Makefile Message-ID: <20110121062807.21C8047019@hg.openjdk.java.net> Changeset: cc195c981ae2 Author: mchung Date: 2011-01-20 22:17 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/cc195c981ae2 7013739: jdk_rmi target is missing in the top repo's test/Makefile Reviewed-by: ohair, igor ! test/ProblemList.txt From chris.hegarty at oracle.com Fri Jan 21 17:05:10 2011 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Fri, 21 Jan 2011 17:05:10 +0000 Subject: hg: jdk7/tl/jdk: 2 new changesets Message-ID: <20110121170529.A448447034@hg.openjdk.java.net> Changeset: 2a8d1a0a2418 Author: chegar Date: 2011-01-21 17:02 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/2a8d1a0a2418 7012768: InetAddress lookupTable leaks/deadlocks when using unsupported name service spi Reviewed-by: alanb, michaelm ! src/share/classes/java/net/InetAddress.java - test/java/net/InetAddress/B4762344.java - test/java/net/InetAddress/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor - test/java/net/InetAddress/Simple1NameServiceDescriptor.java - test/java/net/InetAddress/Simple2NameServiceDescriptor.java - test/java/net/InetAddress/SimpleNameService.java - test/sun/net/InetAddress/nameservice/B6442088.java - test/sun/net/InetAddress/nameservice/CacheTest.java - test/sun/net/InetAddress/nameservice/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor - test/sun/net/InetAddress/nameservice/SimpleNameService.java - test/sun/net/InetAddress/nameservice/SimpleNameServiceDescriptor.java + test/sun/net/InetAddress/nameservice/chaining/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor + test/sun/net/InetAddress/nameservice/chaining/Providers.java + test/sun/net/InetAddress/nameservice/chaining/Simple1NameServiceDescriptor.java + test/sun/net/InetAddress/nameservice/chaining/Simple2NameServiceDescriptor.java + test/sun/net/InetAddress/nameservice/chaining/SimpleNameService.java + test/sun/net/InetAddress/nameservice/deadlock/Hang.java + test/sun/net/InetAddress/nameservice/deadlock/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor + test/sun/net/InetAddress/nameservice/deadlock/ThrowingNameService.java + test/sun/net/InetAddress/nameservice/deadlock/ThrowingNameServiceDescriptor.java + test/sun/net/InetAddress/nameservice/simple/CacheTest.java + test/sun/net/InetAddress/nameservice/simple/DefaultCaching.java + test/sun/net/InetAddress/nameservice/simple/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor + test/sun/net/InetAddress/nameservice/simple/SimpleNameService.java + test/sun/net/InetAddress/nameservice/simple/SimpleNameServiceDescriptor.java Changeset: 6a7b8406a1b9 Author: chegar Date: 2011-01-21 17:04 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/6a7b8406a1b9 Merge From mandy.chung at oracle.com Fri Jan 21 17:47:11 2011 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Fri, 21 Jan 2011 17:47:11 +0000 Subject: hg: jdk7/tl/jdk: 2 new changesets Message-ID: <20110121174730.8E70547037@hg.openjdk.java.net> Changeset: f26d1a7fe4d2 Author: mchung Date: 2011-01-21 09:43 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f26d1a7fe4d2 6912013: Remove the temporary launcher fix to add modules in the bootclasspath Reviewed-by: ksrini ! src/share/bin/java.c ! src/share/bin/java.h ! src/share/classes/sun/launcher/LauncherHelper.java Changeset: 9c18818e7a5f Author: mchung Date: 2011-01-21 09:45 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/9c18818e7a5f Merge - test/java/net/InetAddress/B4762344.java - test/java/net/InetAddress/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor - test/java/net/InetAddress/Simple1NameServiceDescriptor.java - test/java/net/InetAddress/Simple2NameServiceDescriptor.java - test/java/net/InetAddress/SimpleNameService.java - test/sun/net/InetAddress/nameservice/B6442088.java - test/sun/net/InetAddress/nameservice/CacheTest.java - test/sun/net/InetAddress/nameservice/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor - test/sun/net/InetAddress/nameservice/SimpleNameService.java - test/sun/net/InetAddress/nameservice/SimpleNameServiceDescriptor.java From mike.duigou at oracle.com Fri Jan 21 21:29:36 2011 From: mike.duigou at oracle.com (Mike Duigou) Date: Fri, 21 Jan 2011 13:29:36 -0800 Subject: patch : Provide better link for skip list description (CR 6495521) Message-ID: I've posted a patch for review that updates the link to "skip list" to point to the wikipedia description rather than to Bill Pugh's home page (which makes no mention of skip lists). http://cr.openjdk.java.net/~mduigou/6495521/webrev.0/webrev/ The link now points to . The only alternative link that might be viable is however I think it would be best to stick with an http link. I've also added target="_top" so that the page is not opened within the frame but instead within the whole tab/window. This appears to be somewhat consistent with other uses of target attribute, where it is used, though there are "_blank" values used as well. Comments and alternatives welcome. Mike From dl at cs.oswego.edu Sat Jan 22 01:09:37 2011 From: dl at cs.oswego.edu (Doug Lea) Date: Fri, 21 Jan 2011 20:09:37 -0500 Subject: patch : Provide better link for skip list description (CR 6495521) In-Reply-To: References: Message-ID: <4D3A2E51.7090607@cs.oswego.edu> On 01/21/11 16:29, Mike Duigou wrote: > I've posted a patch for review that updates the link to "skip list" to point > to the wikipedia description rather than to Bill Pugh's home page (which > makes no mention of skip lists). > > http://cr.openjdk.java.net/~mduigou/6495521/webrev.0/webrev/ > Thanks. Bill's page used to link to his skip list work but wikipedia is a safer choice anyway. -Doug From zhengyu.gu at oracle.com Sat Jan 22 01:09:10 2011 From: zhengyu.gu at oracle.com (zhengyu.gu at oracle.com) Date: Sat, 22 Jan 2011 01:09:10 +0000 Subject: hg: jdk7/tl/jdk: 2 new changesets Message-ID: <20110122010930.1992047056@hg.openjdk.java.net> Changeset: 2381e810330b Author: zgu Date: 2011-01-20 10:45 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/2381e810330b 6983248: net/net001 and net/net003 fail on WinXP with JDK7-B108 Summary: Using closesocket to close socket handler to avoid invalid C runtime parameter exception. Reviewed-by: alanb, phh, dcubed, dsamersoff, coleenp, acorn ! src/windows/demo/jvmti/hprof/hprof_md.c Changeset: d03e47de3a89 Author: zgu Date: 2011-01-21 11:38 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d03e47de3a89 Merge From brucechapman at paradise.net.nz Sat Jan 22 07:35:20 2011 From: brucechapman at paradise.net.nz (Bruce Chapman) Date: Sat, 22 Jan 2011 20:35:20 +1300 Subject: Objects.nonNull() In-Reply-To: References: <20110114002028.9C4C02999@eggemoggin.niobe.net> <4D2FDDB5.5000603@oracle.com> Message-ID: <4D3A88B8.1010001@paradise.net.nz> On 15/01/2011 12:30 a.m., Stephen Colebourne wrote: snip > 5) Now > *** If you are time-pressured, I'd recommend removing this method from v7. *** > > A "defaultIfNull" method would be much more useful in this class: > public static Object defaultIfNull(Object object, Object defaultValue) { > return object != null ? object : defaultValue; > } More useful as a generic method T defaultIfNull(T object, T default) { return object != null ? object : defaultValue; } - snip- > Stephen > > -snip- From paul.hohensee at oracle.com Sat Jan 22 18:11:53 2011 From: paul.hohensee at oracle.com (paul.hohensee at oracle.com) Date: Sat, 22 Jan 2011 18:11:53 +0000 Subject: hg: jdk7/tl/jdk: 4 new changesets Message-ID: <20110122181232.2BEE34707D@hg.openjdk.java.net> Changeset: c73c178159d8 Author: phh Date: 2011-01-20 19:34 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c73c178159d8 6173675: M&M: approximate memory allocation rate/amount per thread Summary: Subclass com.sun.management.ThreadMXBean from java.lang.management.ThreadMXBean, add getAllocatedBytes() and friends to c.s.m.ThreadMXBean and have sun.management.ThreadImpl implement c.s.m.ThreadMXBean rather than j.l.m.ThreadMXBean. Reviewed-by: mchung, alanb, dholmes, emcmanus ! make/java/management/mapfile-vers + src/share/classes/com/sun/management/ThreadMXBean.java ! src/share/classes/sun/management/ThreadImpl.java ! src/share/classes/sun/management/VMManagement.java ! src/share/classes/sun/management/VMManagementImpl.java ! src/share/javavm/export/jmm.h ! src/share/native/sun/management/ThreadImpl.c ! src/share/native/sun/management/VMManagementImpl.c + test/com/sun/management/ThreadMXBean/ThreadAllocatedMemory.java + test/com/sun/management/ThreadMXBean/ThreadAllocatedMemoryArray.java + test/com/sun/management/ThreadMXBean/ThreadCpuTimeArray.java Changeset: 64ef2f52d781 Author: phh Date: 2011-01-21 07:29 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/64ef2f52d781 7013682: two test checking cpuTime filed java/lang/management/ThreadMXBean Summary: Typo in 6173675 fix dropped getThreadCpuTime(long) result on the floor. Reviewed-by: mchung, dholmes ! src/share/classes/sun/management/ThreadImpl.java Changeset: cd13b2114f2e Author: phh Date: 2011-01-22 08:42 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/cd13b2114f2e Merge ! src/share/classes/sun/management/ThreadImpl.java Changeset: d1365fdfb3ea Author: phh Date: 2011-01-22 08:43 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d1365fdfb3ea Merge - test/java/net/InetAddress/B4762344.java - test/java/net/InetAddress/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor - test/java/net/InetAddress/Simple1NameServiceDescriptor.java - test/java/net/InetAddress/Simple2NameServiceDescriptor.java - test/java/net/InetAddress/SimpleNameService.java - test/sun/net/InetAddress/nameservice/B6442088.java - test/sun/net/InetAddress/nameservice/CacheTest.java - test/sun/net/InetAddress/nameservice/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor - test/sun/net/InetAddress/nameservice/SimpleNameService.java - test/sun/net/InetAddress/nameservice/SimpleNameServiceDescriptor.java From maurizio.cimadamore at oracle.com Mon Jan 24 16:00:33 2011 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Mon, 24 Jan 2011 16:00:33 +0000 Subject: hg: jdk7/tl/langtools: 5 new changesets Message-ID: <20110124160044.AC846470EB@hg.openjdk.java.net> Changeset: 19c900c703c6 Author: mcimadamore Date: 2011-01-24 15:44 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/19c900c703c6 6943278: spurious error message for inference and type-variable with erroneous bound Summary: type-inference should ignore erroneous bounds Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/Infer.java + test/tools/javac/generics/inference/6943278/T6943278.java + test/tools/javac/generics/inference/6943278/T6943278.out Changeset: ce6175cfe11e Author: mcimadamore Date: 2011-01-24 15:44 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/ce6175cfe11e 6968793: issues with diagnostics Summary: several diagnostic improvements Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! test/tools/javac/6304921/T6304921.out ! test/tools/javac/6330920/T6330920.out ! test/tools/javac/6717241/T6717241a.out ! test/tools/javac/6717241/T6717241b.out ! test/tools/javac/6857948/T6857948.out ! test/tools/javac/6863465/T6863465c.out ! test/tools/javac/6863465/T6863465d.out ! test/tools/javac/T6247324.out ! test/tools/javac/TryWithResources/ResourceOutsideTry.out ! test/tools/javac/diags/examples.not-yet.txt ! test/tools/javac/diags/examples/CantResolve.java ! test/tools/javac/diags/examples/CantResolveArgsParams.java ! test/tools/javac/diags/examples/CantResolveLocation.java ! test/tools/javac/diags/examples/CantResolveLocationArgs.java ! test/tools/javac/diags/examples/CantResolveLocationArgsParams.java - test/tools/javac/diags/examples/EnumConstRequired.java ! test/tools/javac/diags/examples/ForeachNotApplicable.java ! test/tools/javac/diags/examples/KindnameClass.java ! test/tools/javac/diags/examples/KindnameMethod.java ! test/tools/javac/diags/examples/KindnameVariable.java + test/tools/javac/diags/examples/Location.java + test/tools/javac/diags/examples/Location1.java ! test/tools/javac/diags/examples/OperatorCantBeApplied.java + test/tools/javac/diags/examples/OperatorCantBeApplied1.java ! test/tools/javac/diags/examples/StaticImportOnlyClassesAndInterfaces/StaticImportOnlyClassesAndInterfaces.java ! test/tools/javac/failover/FailOver01.out ! test/tools/javac/failover/FailOver02.out ! test/tools/javac/failover/FailOver04.out ! test/tools/javac/generics/6711619/T6711619a.out ! test/tools/javac/generics/diamond/neg/Neg01.out ! test/tools/javac/generics/diamond/neg/Neg02.out ! test/tools/javac/generics/diamond/neg/Neg03.out ! test/tools/javac/generics/diamond/neg/Neg04.out ! test/tools/javac/generics/diamond/neg/Neg11.out ! test/tools/javac/generics/inference/6943278/T6943278.out ! test/tools/javac/generics/typevars/5060485/Compatibility.out ! test/tools/javac/generics/typevars/5060485/Compatibility02.out + test/tools/javac/generics/typevars/6968793/T6968793.java + test/tools/javac/generics/typevars/6968793/T6968793.out ! test/tools/javac/policy/test1/byfile.ABD.out ! test/tools/javac/policy/test1/bytodo.ABD.out ! test/tools/javac/policy/test1/simple.ABD.out Changeset: 02e6e7dd1a64 Author: mcimadamore Date: 2011-01-24 15:45 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/02e6e7dd1a64 6510286: Wording of javac error for inner classes Summary: 'inner classes cannot have static declarations' message needs to be reworked Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! test/tools/javac/InnerNamedConstant_2.out Changeset: 812c6251ea78 Author: mcimadamore Date: 2011-01-24 15:45 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/812c6251ea78 6569633: Varargs: parser error when varargs element type is an array Summary: explicit error message when old-style array syntax is mixed with varargs Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties + test/tools/javac/diags/examples/VarargsAndOldArraySyntax.java + test/tools/javac/varargs/6569633/T6569633.java + test/tools/javac/varargs/6569633/T6569633.out Changeset: 57e3b9bc7fb8 Author: mcimadamore Date: 2011-01-24 15:45 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/57e3b9bc7fb8 7013865: varargs: javac crashes during overload resolution with generic varargs Summary: fixed regression with varargs overload resolution that leads javac to crash Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Infer.java + test/tools/javac/varargs/T7013865.java From xueming.shen at oracle.com Mon Jan 24 19:51:58 2011 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Mon, 24 Jan 2011 19:51:58 +0000 Subject: hg: jdk7/tl/jdk: 7006576: (zipfs) Path.exists() always returns false on dirs when zip/JAR file built without dirs; ... Message-ID: <20110124195208.2CBC5470F4@hg.openjdk.java.net> Changeset: 4cc447291326 Author: sherman Date: 2011-01-24 11:47 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/4cc447291326 7006576: (zipfs) Path.exists() always returns false on dirs when zip/JAR file built without dirs 7009092: (zipfs) ZipPath.isSameFile() should always return true if this Path and the given Path are equal. 7009085: (zipfs) ZipPath.normalize("/./.") returns null. 7009102: (zipfs) ZipPath.toRealPath() should always return absolute path. Summary: zip filesystem provider update Reviewed-by: alanb ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileSystem.java ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipPath.java ! test/demo/zipfs/PathOps.java ! test/demo/zipfs/ZipFSTester.java ! test/demo/zipfs/basic.sh From jonathan.gibbons at oracle.com Tue Jan 25 00:18:02 2011 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Tue, 25 Jan 2011 00:18:02 +0000 Subject: hg: jdk7/tl/langtools: 6963934: JCCompilationUnit.getImports does not report all imports Message-ID: <20110125001804.98E73470FF@hg.openjdk.java.net> Changeset: 73ab0b128918 Author: jjg Date: 2011-01-24 16:17 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/73ab0b128918 6963934: JCCompilationUnit.getImports does not report all imports Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/tree/JCTree.java + test/tools/javac/tree/T6963934.java From jonathan.gibbons at oracle.com Tue Jan 25 00:34:45 2011 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Tue, 25 Jan 2011 00:34:45 +0000 Subject: hg: jdk7/tl/langtools: 6581775: Fix the white space problem in javac shell tests Message-ID: <20110125003447.2287F47100@hg.openjdk.java.net> Changeset: 22a040cbf0e0 Author: jjg Date: 2011-01-24 16:34 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/22a040cbf0e0 6581775: Fix the white space problem in javac shell tests Reviewed-by: mcimadamore ! test/tools/javac/ClassPathTest/ClassPathTest.sh ! test/tools/javac/ExtDirs/ExtDirs.sh ! test/tools/javac/Paths/Help.sh ! test/tools/javac/javazip/Test.sh ! test/tools/javac/versions/check.sh From jonathan.gibbons at oracle.com Tue Jan 25 00:39:15 2011 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Tue, 25 Jan 2011 00:39:15 +0000 Subject: hg: jdk7/tl/langtools: 6988106: javac report 'java.lang.IllegalMonitorStateException' Message-ID: <20110125003917.C4ED947102@hg.openjdk.java.net> Changeset: a8437c34fdc7 Author: jjg Date: 2011-01-24 16:38 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/a8437c34fdc7 6988106: javac report 'java.lang.IllegalMonitorStateException' Reviewed-by: ksrini ! src/share/classes/com/sun/tools/javac/file/CacheFSInfo.java ! src/share/classes/com/sun/tools/javac/file/JavacFileManager.java ! src/share/classes/com/sun/tools/javac/file/ZipFileIndex.java + src/share/classes/com/sun/tools/javac/file/ZipFileIndexCache.java ! test/tools/javac/T6725036.java From joe.darcy at oracle.com Tue Jan 25 04:05:01 2011 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Tue, 25 Jan 2011 04:05:01 +0000 Subject: hg: jdk7/tl/jdk: 7006578: Project Coin: Retrofit JDK libraries with @SafeVarargs Message-ID: <20110125040510.DB26047113@hg.openjdk.java.net> Changeset: dbfc1e419cb2 Author: darcy Date: 2011-01-24 20:04 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/dbfc1e419cb2 7006578: Project Coin: Retrofit JDK libraries with @SafeVarargs Reviewed-by: mduigou, alexp ! src/share/classes/java/util/Arrays.java ! src/share/classes/java/util/Collections.java ! src/share/classes/java/util/EnumSet.java ! src/share/classes/javax/swing/SwingWorker.java ! src/share/classes/sun/swing/AccumulativeRunnable.java From neil.richards at ngmr.net Tue Jan 25 14:28:36 2011 From: neil.richards at ngmr.net (Neil Richards) Date: Tue, 25 Jan 2011 14:28:36 +0000 Subject: Making java.util.Iterator.remove() for the iterators for EnumSet more resilient Message-ID: The Javadoc for java.util.Iterator.remove() states that the behaviour of the method is "unspecified" if the underlying collection has been modified. Ideally, Iterator.remove() would be resilient - which is to say, it would not modify the underlying collection if the element to be removed has already been removed from the collection. In the general case, I can see the rationale behind the Javadoc defining things the way they are - it would be overly onerous to require resilient behaviour on iterators for all types of collection. However, in the specific case of the iterators for java.util.EnumSet, I believe it is simple to implement them such that their remove() method does behave in the resilient manner described above. Given that it's basicaly as easy for these to behave resiliently as for them not to, I believe to would be beneficial to change them to be resilient in this fashion. To that end, please find attached a zip file containing a webrev which modifies the Iterators for EnumSet (specifically java.util.RegularEnumSet.EnumSetIterator and java.util.JumboEnumSet.EnumSetIterator) so that they are resilient, together with a couple of testcases to demonstrate the enhancement. I have searched the Java Bug Database, but have not found a bug (or RFE) relating to this item. Therefore, I'm unsure if I should raise an RFE for it there or in the OpenJDK bugzilla. As always, any comments, queries or guidance on any of the above gratefully received. - Neil -- Unless stated above: IBM email: neil_richards at uk.ibm.com IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- A non-text attachment was scrubbed... Name: webrev.EnumSetIterators.00.zip Type: application/zip Size: 92460 bytes Desc: not available URL: From lvjing at linux.vnet.ibm.com Tue Jan 25 14:45:35 2011 From: lvjing at linux.vnet.ibm.com (Jing LV) Date: Tue, 25 Jan 2011 22:45:35 +0800 Subject: BufferedWriter.write does not throw exception if it is already closed. Message-ID: <4D3EE20F.5040108@linux.vnet.ibm.com> Hello, I find a problem in java.io.BufferedWriter. It is stated in the java spec of its close() method: "... Once the stream has been closed, further write() or flush() invocations will cause an IOException to be thrown." However if a BufferedWriter is created with a delegated writer, then it seems to "forget" to throw IOException when it's closed, even if the delegated writer wants to. Here is a simple example: private int bufferSize = 1024; public void test() throws Exception { FailOnFlushWriter delegate = new FailOnFlushWriter(); Writer o = new BufferedWriter(delegate, bufferSize); try { // any of these is permitted to flush o.close(); assertTrue(delegate.flushed); fail("flush exception ignored"); } catch (IOException expected) { assertEquals("Flush failed" , expected.getMessage()); } try { o.write("Hello World"); fail("expected already closed exception"); // failed here } catch (IOException expected) { } } private static class FailOnFlushWriter extends Writer { boolean flushed = false; boolean closed = false; @Override public void write(char[] buf, int offset, int count) throws IOException { if (closed) { throw new IOException("Already closed"); } } @Override public void close() throws IOException { closed = true; flush(); } @Override public void flush() throws IOException { if (!flushed) { flushed = true; throw new IOException("Flush failed"); } } } If you run the testcases and it fails at once. By checking the code it seems the BufferedWriter store the contents and do no real operation (as its buffer size is 1024) and ignore the closed states - changing the buffersize to be smaller like 10 would make the testcase passed . I believe it would be a confusion for the user. Anyway, it would be easy to fix. Any comments? From lvjing at linux.vnet.ibm.com Tue Jan 25 15:15:52 2011 From: lvjing at linux.vnet.ibm.com (Jing LV) Date: Tue, 25 Jan 2011 23:15:52 +0800 Subject: BufferedOutputStream does not throw exception after it's closed Message-ID: <4D3EE928.1030701@linux.vnet.ibm.com> Hello, Find a similar problem with the one in the last mail(BufferedWriter), this time is BufferedOutputStream, and it has a delegated output stream and behave the same with BufferedWriter, I believe the two problems are just the same - it needs to check the open status before store the contents even if it does not need to flush. A similar testcase can be: private int bufferSize = 1024; public void test() throws Exception { OutputStream out = new BufferedOutputStream(new ClosableByteArrayOutputStream(), bufferSize); out.close(); try { out.write(new byte[] { 7, 3, 4, 5 }); fail("expected already closed exception"); } catch (IOException expected) { } } private static class ClosableByteArrayOutputStream extends OutputStream { private final ByteArrayOutputStream bytesOut = new ByteArrayOutputStream(); private boolean closed = false; @Override public void close() throws IOException { closed = true; } @Override public void write(int oneByte) throws IOException { if (closed) { throw new IOException(); } bytesOut.write(oneByte); } } Any comments? I'd like to raise this problem on the bug-tracker system. From forax at univ-mlv.fr Tue Jan 25 15:28:55 2011 From: forax at univ-mlv.fr (=?GB2312?B?UqimbWkgRm9yYXg=?=) Date: Tue, 25 Jan 2011 16:28:55 +0100 Subject: BufferedOutputStream does not throw exception after it's closed In-Reply-To: <4D3EE928.1030701@linux.vnet.ibm.com> References: <4D3EE928.1030701@linux.vnet.ibm.com> Message-ID: <4D3EEC37.5050004@univ-mlv.fr> On 01/25/2011 04:15 PM, Jing LV wrote: > Hello, Hi, you should report it as a bug even if I think that too many programs rely on that semantics so the spec should be updated instead of the implementation. > Find a similar problem with the one in the last mail(BufferedWriter), > this time is BufferedOutputStream, and it has a delegated output stream > and behave the same with BufferedWriter, I believe the two problems are > just the same - it needs to check the open status before store the > contents even if it does not need to flush. A similar testcase can be: > private int bufferSize = 1024; > public void test() throws Exception { > OutputStream out = new BufferedOutputStream(new > ClosableByteArrayOutputStream(), bufferSize); > out.close(); > > try { > out.write(new byte[] { 7, 3, 4, 5 }); > fail("expected already closed exception"); > } catch (IOException expected) { > } > } > > private static class ClosableByteArrayOutputStream extends OutputStream { > private final ByteArrayOutputStream bytesOut = new ByteArrayOutputStream(); > > private boolean closed = false; > @Override > public void close() throws IOException { > closed = true; > } > > @Override > public void write(int oneByte) throws IOException { > if (closed) { > throw new IOException(); > } > bytesOut.write(oneByte); > } > } > > Any comments? I'd like to raise this problem on the bug-tracker system. R?mi From Alan.Bateman at oracle.com Tue Jan 25 16:19:04 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 25 Jan 2011 16:19:04 +0000 Subject: BufferedWriter.write does not throw exception if it is already closed. In-Reply-To: <4D3EE20F.5040108@linux.vnet.ibm.com> References: <4D3EE20F.5040108@linux.vnet.ibm.com> Message-ID: <4D3EF7F8.70407@oracle.com> Jing LV wrote: > Hello, > > I find a problem in java.io.BufferedWriter. It is stated in the java > spec of its close() method: > "... Once the stream has been closed, further write() or flush() > invocations will cause an IOException to be thrown." > However if a BufferedWriter is created with a delegated writer, then it > seems to "forget" to throw IOException when it's closed, even if the > delegated writer wants to. Here is a simple example: > It's possible we have a spec issue in that BufferedWriter (and others) don't specify what their state is in event that flushing or closing the underlying Writer fails (the test is assuming that it is closed even though the close method failed). -Alan. From sean.mullan at oracle.com Tue Jan 25 16:23:55 2011 From: sean.mullan at oracle.com (sean.mullan at oracle.com) Date: Tue, 25 Jan 2011 16:23:55 +0000 Subject: hg: jdk7/tl/jdk: 4 new changesets Message-ID: <20110125162433.AC82447130@hg.openjdk.java.net> Changeset: ae38d1374e31 Author: mullan Date: 2011-01-24 14:56 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/ae38d1374e31 5001004: Required Security Algorithms need to be defined Reviewed-by: wetmore ! src/share/classes/java/security/AlgorithmParameterGenerator.java ! src/share/classes/java/security/AlgorithmParameters.java ! src/share/classes/java/security/KeyFactory.java ! src/share/classes/java/security/KeyPairGenerator.java ! src/share/classes/java/security/KeyStore.java ! src/share/classes/java/security/MessageDigest.java ! src/share/classes/java/security/Policy.java ! src/share/classes/java/security/SecureRandom.java ! src/share/classes/java/security/Security.java ! src/share/classes/java/security/Signature.java ! src/share/classes/java/security/cert/CertPath.java ! src/share/classes/java/security/cert/CertPathBuilder.java ! src/share/classes/java/security/cert/CertPathValidator.java ! src/share/classes/java/security/cert/CertStore.java ! src/share/classes/java/security/cert/Certificate.java ! src/share/classes/java/security/cert/CertificateFactory.java ! src/share/classes/java/security/cert/CertificateFactorySpi.java ! src/share/classes/java/security/cert/package.html ! src/share/classes/java/security/package.html ! src/share/classes/javax/crypto/Cipher.java ! src/share/classes/javax/crypto/ExemptionMechanism.java ! src/share/classes/javax/crypto/KeyAgreement.java ! src/share/classes/javax/crypto/KeyGenerator.java ! src/share/classes/javax/crypto/Mac.java ! src/share/classes/javax/crypto/SecretKeyFactory.java ! src/share/classes/javax/crypto/package.html ! src/share/classes/javax/net/ssl/SSLContext.java ! src/share/classes/javax/net/ssl/package.html ! src/share/classes/javax/security/auth/login/Configuration.java ! src/share/classes/javax/security/auth/login/package.html Changeset: b33e9b15835e Author: mullan Date: 2011-01-24 15:08 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/b33e9b15835e Merge - make/common/internal/BinaryPlugs.gmk - make/java/hpi/Makefile - make/java/hpi/hpi_common.gmk - make/java/hpi/native/Makefile - make/java/hpi/native/mapfile-vers - make/java/hpi/native/reorder-i586 - make/java/hpi/native/reorder-sparc - make/java/hpi/native/reorder-sparcv9 - make/java/hpi/windows/Makefile - src/share/classes/java/dyn/JavaMethodHandle.java - src/share/classes/java/dyn/LinkagePermission.java - src/share/classes/java/nio/channels/AsynchronousDatagramChannel.java ! src/share/classes/java/security/Security.java ! src/share/classes/javax/net/ssl/SSLContext.java - src/share/classes/sun/java2d/pisces/LineSink.java - src/share/classes/sun/net/httpserver/SelectorCache.java - src/share/classes/sun/nio/ch/SimpleAsynchronousDatagramChannelImpl.java - src/share/classes/sun/security/krb5/KrbKdcReq.java - src/share/classes/sun/security/krb5/internal/TCPClient.java - src/share/classes/sun/security/krb5/internal/UDPClient.java - src/share/demo/nio/zipfs/META-INF/services/java.nio.file.spi.FileSystemProvider - src/share/demo/nio/zipfs/com/sun/nio/zipfs/JarFileSystemProvider.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipCoder.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipConstants.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipDirectoryStream.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileAttributeView.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileAttributes.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileStore.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileSystem.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipFileSystemProvider.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipInfo.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipPath.java - src/share/demo/nio/zipfs/com/sun/nio/zipfs/ZipUtils.java - src/share/hpi/export/bool.h - src/share/hpi/export/dll.h - src/share/hpi/export/hpi.h - src/share/hpi/include/hpi_impl.h - src/share/hpi/include/vm_calls.h - src/share/hpi/src/hpi.c - src/share/native/sun/font/layout/HebrewLigatureData.cpp - src/share/native/sun/font/layout/HebrewShaping.cpp - src/share/native/sun/font/layout/HebrewShaping.h - src/solaris/classes/sun/net/www/protocol/http/NTLMAuthentication.java - src/solaris/hpi/export/byteorder_md.h - src/solaris/hpi/export/hpi_md.h - src/solaris/hpi/export/io_md.h - src/solaris/hpi/export/path_md.h - src/solaris/hpi/export/timeval_md.h - src/solaris/hpi/include/hpi_init.h - src/solaris/hpi/include/interrupt.h - src/solaris/hpi/include/largefile.h - src/solaris/hpi/include/largefile_linux.h - src/solaris/hpi/include/largefile_solaris.h - src/solaris/hpi/native_threads/include/condvar_md.h - src/solaris/hpi/native_threads/include/monitor_md.h - src/solaris/hpi/native_threads/include/mutex_md.h - src/solaris/hpi/native_threads/include/np.h - src/solaris/hpi/native_threads/include/porting.h - src/solaris/hpi/native_threads/include/threads_md.h - src/solaris/hpi/native_threads/src/condvar_md.c - src/solaris/hpi/native_threads/src/interrupt_md.c - src/solaris/hpi/native_threads/src/monitor_md.c - src/solaris/hpi/native_threads/src/mutex_md.c - src/solaris/hpi/native_threads/src/sys_api_td.c - src/solaris/hpi/native_threads/src/threads_linux.c - src/solaris/hpi/native_threads/src/threads_md.c - src/solaris/hpi/native_threads/src/threads_solaris.c - src/solaris/hpi/src/interrupt.c - src/solaris/hpi/src/linker_md.c - src/solaris/hpi/src/memory_md.c - src/solaris/hpi/src/system_md.c - src/windows/hpi/export/byteorder_md.h - src/windows/hpi/export/hpi_md.h - src/windows/hpi/export/io_md.h - src/windows/hpi/export/path_md.h - src/windows/hpi/export/timeval_md.h - src/windows/hpi/include/monitor_md.h - src/windows/hpi/include/mutex_md.h - src/windows/hpi/include/threads_md.h - src/windows/hpi/src/linker_md.c - src/windows/hpi/src/memory_md.c - src/windows/hpi/src/monitor_md.c - src/windows/hpi/src/path_md.c - src/windows/hpi/src/socket_md.c - src/windows/hpi/src/sys_api_md.c - src/windows/hpi/src/system_md.c - src/windows/hpi/src/threads_md.c - test/java/awt/Insets/WindowWithWarningTest/WindowWithWarningTest.html - test/java/awt/Insets/WindowWithWarningTest/WindowWithWarningTest.java - test/java/net/InetAddress/B4762344.java - test/java/net/InetAddress/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor - test/java/net/InetAddress/Simple1NameServiceDescriptor.java - test/java/net/InetAddress/Simple2NameServiceDescriptor.java - test/java/net/InetAddress/SimpleNameService.java - test/java/nio/channels/AsynchronousDatagramChannel/Basic.java - test/javax/script/E4XErrorTest.java - test/javax/swing/SwingWorker/6480289/bug6480289.java - test/sun/net/InetAddress/nameservice/B6442088.java - test/sun/net/InetAddress/nameservice/CacheTest.java - test/sun/net/InetAddress/nameservice/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor - test/sun/net/InetAddress/nameservice/SimpleNameService.java - test/sun/net/InetAddress/nameservice/SimpleNameServiceDescriptor.java - test/sun/security/krb5/auto/basic.sh Changeset: 6ac9383640c6 Author: mullan Date: 2011-01-24 15:46 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/6ac9383640c6 Merge Changeset: 6e7bed89ce84 Author: mullan Date: 2011-01-25 08:41 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/6e7bed89ce84 Merge From mike.duigou at oracle.com Tue Jan 25 19:24:32 2011 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 25 Jan 2011 11:24:32 -0800 Subject: Making java.util.Iterator.remove() for the iterators for EnumSet more resilient In-Reply-To: References: Message-ID: Hi Neil; This sounds like an excellent suggestion and the changes look good to me. I have created an RFE change request (CR# 7014637) and posted the webrev at cr.openjdk.java.net: http://cr.openjdk.java.net/~mduigou/7014637/webrev.00/webrev/ Mike On Jan 25 2011, at 06:28 , Neil Richards wrote: > The Javadoc for java.util.Iterator.remove() states that the behaviour > of the method is "unspecified" if the underlying collection has been > modified. > > Ideally, Iterator.remove() would be resilient - which is to say, it > would not modify the underlying collection if the element to be > removed has already been removed from the collection. > > In the general case, I can see the rationale behind the Javadoc > defining things the way they are - it would be overly onerous to > require resilient behaviour on iterators for all types of collection. > > However, in the specific case of the iterators for java.util.EnumSet, > I believe it is simple to implement them such that their remove() > method does behave in the resilient manner described above. > > Given that it's basicaly as easy for these to behave resiliently as > for them not to, I believe to would be beneficial to change them to be > resilient in this fashion. > > To that end, please find attached a zip file containing a webrev which > modifies the Iterators for EnumSet (specifically > java.util.RegularEnumSet.EnumSetIterator and > java.util.JumboEnumSet.EnumSetIterator) so that they are resilient, > together with a couple of testcases to demonstrate the enhancement. > > I have searched the Java Bug Database, but have not found a bug (or > RFE) relating to this item. > Therefore, I'm unsure if I should raise an RFE for it there or in the > OpenJDK bugzilla. > > As always, any comments, queries or guidance on any of the above > gratefully received. > > - Neil From brian.goetz at oracle.com Tue Jan 25 20:24:26 2011 From: brian.goetz at oracle.com (Brian Goetz) Date: Tue, 25 Jan 2011 15:24:26 -0500 Subject: Code review: 7012540 (java.util.Objects.nonNull() incorrectly named) Message-ID: <4D3F317A.2060607@oracle.com> There is a webrev for CR 7012540 (java.util.Objects.nonNull() incorrectly named) at: http://cr.openjdk.java.net/~briangoetz/7012540/webrev/ Code review would be appreciated. Text of CR: The class java.util.Objects is new for JDK 7. Its mission is to provide "null-safe or null-tolerant versions of common operations on objects." The methods nonNull(x) have the behavior of throwing NPE if their argument is null, and returning their argument if non-null. It is very common in Java source bases for a method named nonNull(x) to have the behavior of coercing their argument to null; that is, it is generally associated with a null-tolerant rather than a null-safe behavior. These methods should be renamed to something that makes its checking/verification behavior clear, while preserving the convenient self-return property so that it can be used in cases like: public void fooWrapper(String s, String t) { foo(checkNonNull(s), checkNonNull(t)); } Additional notes: After much discussion on core-libs-dev, the name requireNonNull() seemed the least objectionable. From pbenedict at apache.org Tue Jan 25 20:33:13 2011 From: pbenedict at apache.org (Paul Benedict) Date: Tue, 25 Jan 2011 14:33:13 -0600 Subject: Code review: 7012540 (java.util.Objects.nonNull() incorrectly named) In-Reply-To: <4D3F317A.2060607@oracle.com> References: <4D3F317A.2060607@oracle.com> Message-ID: The other good benefit from this rename is that "requireNonNull" is much more expressive when used as a static import. On Tue, Jan 25, 2011 at 2:24 PM, Brian Goetz wrote: > There is a webrev for CR 7012540 (java.util.Objects.nonNull() incorrectly > named) at: > > http://cr.openjdk.java.net/~briangoetz/7012540/webrev/ > > Code review would be appreciated. > > Text of CR: > > The class java.util.Objects is new for JDK 7. Its mission is to provide > "null-safe or null-tolerant versions of common operations on objects." > > The methods nonNull(x) have the behavior of throwing NPE if their argument > is null, and returning their argument if non-null. It is very common in > Java source bases for a method named nonNull(x) to have the behavior of > coercing their argument to null; that is, it is generally associated with a > null-tolerant rather than a null-safe behavior. > > These methods should be renamed to something that makes its > checking/verification behavior clear, while preserving the convenient > self-return property so that it can be used in cases like: > > public void fooWrapper(String s, String t) { > foo(checkNonNull(s), checkNonNull(t)); > } > > > Additional notes: After much discussion on core-libs-dev, the name > requireNonNull() seemed the least objectionable. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe.darcy at oracle.com Tue Jan 25 23:06:48 2011 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 25 Jan 2011 15:06:48 -0800 Subject: Code review: 7012540 (java.util.Objects.nonNull() incorrectly named) In-Reply-To: <4D3F317A.2060607@oracle.com> References: <4D3F317A.2060607@oracle.com> Message-ID: <4D3F5788.8040009@oracle.com> Looks good; approved, -Joe Brian Goetz wrote: > There is a webrev for CR 7012540 (java.util.Objects.nonNull() > incorrectly named) at: > > http://cr.openjdk.java.net/~briangoetz/7012540/webrev/ > > Code review would be appreciated. > > Text of CR: > > The class java.util.Objects is new for JDK 7. Its mission is to > provide "null-safe or null-tolerant versions of common operations on > objects." > > The methods nonNull(x) have the behavior of throwing NPE if their > argument is null, and returning their argument if non-null. It is > very common in Java source bases for a method named nonNull(x) to have > the behavior of coercing their argument to null; that is, it is > generally associated with a null-tolerant rather than a null-safe > behavior. > > These methods should be renamed to something that makes its > checking/verification behavior clear, while preserving the convenient > self-return property so that it can be used in cases like: > > public void fooWrapper(String s, String t) { > foo(checkNonNull(s), checkNonNull(t)); > } > > > Additional notes: After much discussion on core-libs-dev, the name > requireNonNull() seemed the least objectionable. > From mark.reinhold at oracle.com Tue Jan 25 23:15:31 2011 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 25 Jan 2011 15:15:31 -0800 Subject: Code review: 7012540 (java.util.Objects.nonNull() incorrectly named) In-Reply-To: brian.goetz@oracle.com; Tue, 25 Jan 2011 15:24:26 EST; <4D3F317A.2060607@oracle.com> Message-ID: <20110125231531.A78E712DF@eggemoggin.niobe.net> > Date: Tue, 25 Jan 2011 15:24:26 -0500 > From: brian.goetz at oracle.com > ... > > These methods should be renamed to something that makes its > checking/verification behavior clear, while preserving the convenient > self-return property so that it can be used in cases like: > > public void fooWrapper(String s, String t) { > foo(checkNonNull(s), checkNonNull(t)); > } > > > Additional notes: After much discussion on core-libs-dev, the name > requireNonNull() seemed the least objectionable. I think requireNonNull(x) is confusing. For those familiar with the "requires/ensures/modifies" triad of verbs as a compact way of identifying the preconditions, postconditions, and side effects of a method or procedure in a comment, a specification, or a more formal design-by-contract framework, "requires" is just wrong. When analyzing the invocation of foo in your example, the non-nullity of s and t are preconditions of foo and therefore postconditions of the check method. Naming the check method "requireNonNull" suggests that the check method itself has a precondition that its argument be non-null, when in fact it's the check method's postcondition which ensures that property. Since postconditions are labeled "ensures" in the "r/e/m" triad, this method should be named "ensureNonNull". - Mark From brian.goetz at oracle.com Tue Jan 25 23:33:47 2011 From: brian.goetz at oracle.com (Brian Goetz) Date: Tue, 25 Jan 2011 18:33:47 -0500 Subject: Code review: 7012540 (java.util.Objects.nonNull() incorrectly named) In-Reply-To: <20110125231531.A78E712DF@eggemoggin.niobe.net> References: <20110125231531.A78E712DF@eggemoggin.niobe.net> Message-ID: <4D3F5DDB.7070209@oracle.com> >> Additional notes: After much discussion on core-libs-dev, the name >> requireNonNull() seemed the least objectionable. > > I think requireNonNull(x) is confusing. Remember there's two versions of someModifierNonNull being discussed; the one currently in Objects is the precondition-enforcing variety, not the postcondition-ensuring variety. Are we talking about the same thing? > For those familiar with the "requires/ensures/modifies" triad of verbs as > a compact way of identifying the preconditions, postconditions, and side > effects of a method or procedure in a comment, a specification, or a more > formal design-by-contract framework, "requires" is just wrong. > > When analyzing the invocation of foo in your example, the non-nullity of > s and t are preconditions of foo and therefore postconditions of the > check method. Naming the check method "requireNonNull" suggests that > the check method itself has a precondition that its argument be non-null, > when in fact it's the check method's postcondition which ensures that > property. > > Since postconditions are labeled "ensures" in the "r/e/m" triad, this > method should be named "ensureNonNull". Right, there's precedent for "ensureXxx" methods to actually change the state of things to ensure the postcondition, such as ensureCapacity() methods in the collection implementations. Given that a part of the motivation for this change was to leave room in the namespace for both the precondition-enforcing variety (barf on null) and the postcondition-ensuring variety, aka the carpet-sweeping variety ("if it is null, make it non-null") ensureNonNull sounds a lot more like the the carpet-sweeping version than the version being discussed (barf on null). The r/e/m framework seems to support require for the throwing version (as implemented by this patch): for the throwing version, non-nullity is a precondition of the check method (if the condition is not met, error), whereas for the carpet-sweeping version, it is a postcondition of the check method (if the check method can come up with a reasonable default value). (It happens to be a postcondition of both, but the significant behavior and use of the throwing version currently in Objects is to enforce an error when the precondition is not met.) Therefore: requireNonNull(x) -> throw if x == null ensureNonNull(x) -> convert x to a non-null value if null seems like the right taxonomy. From joe.darcy at oracle.com Wed Jan 26 01:03:21 2011 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Wed, 26 Jan 2011 01:03:21 +0000 Subject: hg: jdk7/tl/langtools: 7013420: Project Coin: remove general expression support from try-with-resources statement Message-ID: <20110126010324.AF3FA4714A@hg.openjdk.java.net> Changeset: 7f8794f9cc14 Author: darcy Date: 2011-01-25 17:02 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/7f8794f9cc14 7013420: Project Coin: remove general expression support from try-with-resources statement Reviewed-by: mcimadamore, jjg ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! test/tools/javac/TryWithResources/BadTwrSyntax.out ! test/tools/javac/TryWithResources/DuplicateResource.java + test/tools/javac/TryWithResources/ExplicitFinal.java ! test/tools/javac/TryWithResources/ImplicitFinal.java ! test/tools/javac/TryWithResources/ImplicitFinal.out ! test/tools/javac/TryWithResources/TwrFlow.java ! test/tools/javac/TryWithResources/TwrFlow.out - test/tools/javac/TryWithResources/TwrInference.java - test/tools/javac/TryWithResources/TwrIntersection.java - test/tools/javac/TryWithResources/TwrIntersection02.java - test/tools/javac/TryWithResources/TwrIntersection02.out ! test/tools/javac/TryWithResources/TwrMultiCatch.java ! test/tools/javac/TryWithResources/TwrOnNonResource.java ! test/tools/javac/TryWithResources/TwrOnNonResource.out + test/tools/javac/diags/examples/TryResourceTrailingSemi.java From jjb at google.com Wed Jan 26 01:57:22 2011 From: jjb at google.com (Joshua Bloch) Date: Tue, 25 Jan 2011 17:57:22 -0800 Subject: Making java.util.Iterator.remove() for the iterators for EnumSet more resilient In-Reply-To: References: Message-ID: Mike et. al., I have serious reservations about this. It would be the first time (to my knowledge) that we deliberately swept a concurrent modification under the rug. If we go to the effort of detecting it (which you're doing), the least we should do is to report it. Also, this file (and most of java.util and java.lang) does not use braces on single-line if/for/while/do statements. Combining these points, this: 143 if (oldElements != elements[lastReturnedIndex]) { 144 size--; 145 } Should be: 143 if (oldElements != elements[lastReturnedIndex]) 144 size--; 145 else 146 throw new ConcurrentModificationException(); But I have some doubts as to whether this is worth doing. There was a much more serious case where we failed to throw a CME that we should have thrown, and the CCC (an internal review body within Sun, and now Oracle) ruledthat it represented an unacceptable compatibility violation. If we're going to make this change to EnumSet, then we must reopen 4902078and fix that too. Josh P.S. There is a much more serious problem with EnumMap that we might want to fix. It is demonstrated by this program: *public class Size {* * private enum Sex { MALE, FEMALE }* ** * public static void main(String[] args) {* * printSize(new HashMap());* * printSize(new EnumMap(Sex.class));* * }* ** * private static void printSize(Map map) {* * map.put(Sex.MALE, Sex.FEMALE);* * map.put(Sex.FEMALE, Sex.MALE);* * map.put(Sex.MALE, Sex.MALE);* * map.put(Sex.FEMALE, Sex.FEMALE);* * Set> set =* * new HashSet>(map.entrySet());* * System.out.println(set.size());* * }* *}* * * Predict the behavior of this program. Then run it and see what happens. Only two Map implementations display this disturbing behavior: EnumMap and IdentityHashMap. I'm less disturbed by IdentityHashMap, as it's such an esoteric implementation. But I could easily imagine someone getting hurt by the behavior demonstrated by the example above. Fixing it would decrease the performance of iterating over entrySets of EnumMaps, but I think it would probably be worthwhile. I violated the principle of least astonishment here, and engaged in premature optimization. Mea culpa, twice. Josh On Tue, Jan 25, 2011 at 11:24 AM, Mike Duigou wrote: > Hi Neil; > > This sounds like an excellent suggestion and the changes look good to me. I > have created an RFE change request (CR# 7014637) and posted the webrev at > cr.openjdk.java.net: > > http://cr.openjdk.java.net/~mduigou/7014637/webrev.00/webrev/ > > Mike > > On Jan 25 2011, at 06:28 , Neil Richards wrote: > > > The Javadoc for java.util.Iterator.remove() states that the behaviour > > of the method is "unspecified" if the underlying collection has been > > modified. > > > > Ideally, Iterator.remove() would be resilient - which is to say, it > > would not modify the underlying collection if the element to be > > removed has already been removed from the collection. > > > > In the general case, I can see the rationale behind the Javadoc > > defining things the way they are - it would be overly onerous to > > require resilient behaviour on iterators for all types of collection. > > > > However, in the specific case of the iterators for java.util.EnumSet, > > I believe it is simple to implement them such that their remove() > > method does behave in the resilient manner described above. > > > > Given that it's basicaly as easy for these to behave resiliently as > > for them not to, I believe to would be beneficial to change them to be > > resilient in this fashion. > > > > To that end, please find attached a zip file containing a webrev which > > modifies the Iterators for EnumSet (specifically > > java.util.RegularEnumSet.EnumSetIterator and > > java.util.JumboEnumSet.EnumSetIterator) so that they are resilient, > > together with a couple of testcases to demonstrate the enhancement. > > > > I have searched the Java Bug Database, but have not found a bug (or > > RFE) relating to this item. > > Therefore, I'm unsure if I should raise an RFE for it there or in the > > OpenJDK bugzilla. > > > > As always, any comments, queries or guidance on any of the above > > gratefully received. > > > > - Neil > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike.duigou at oracle.com Wed Jan 26 04:31:55 2011 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 25 Jan 2011 20:31:55 -0800 Subject: Code review: 7012540 (java.util.Objects.nonNull() incorrectly named) In-Reply-To: <4D3F317A.2060607@oracle.com> References: <4D3F317A.2060607@oracle.com> Message-ID: <3B79C33F-31CF-4A2E-9C7B-DF600FEA4558@oracle.com> requireNonNull() seems to be the best compromise. The changes look good to me. Mike On Jan 25 2011, at 12:24 , Brian Goetz wrote: > There is a webrev for CR 7012540 (java.util.Objects.nonNull() incorrectly named) at: > > http://cr.openjdk.java.net/~briangoetz/7012540/webrev/ > > Code review would be appreciated. > > Text of CR: > > The class java.util.Objects is new for JDK 7. Its mission is to provide "null-safe or null-tolerant versions of common operations on objects." > > The methods nonNull(x) have the behavior of throwing NPE if their argument is null, and returning their argument if non-null. It is very common in Java source bases for a method named nonNull(x) to have the behavior of coercing their argument to null; that is, it is generally associated with a null-tolerant rather than a null-safe behavior. > > These methods should be renamed to something that makes its checking/verification behavior clear, while preserving the convenient self-return property so that it can be used in cases like: > > public void fooWrapper(String s, String t) { > foo(checkNonNull(s), checkNonNull(t)); > } > > > Additional notes: After much discussion on core-libs-dev, the name requireNonNull() seemed the least objectionable. > From Ulf.Zibis at gmx.de Wed Jan 26 12:31:05 2011 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Wed, 26 Jan 2011 13:31:05 +0100 Subject: Code review: 7012540 (java.util.Objects.nonNull() incorrectly named) In-Reply-To: <4D3F5DDB.7070209@oracle.com> References: <20110125231531.A78E712DF@eggemoggin.niobe.net> <4D3F5DDB.7070209@oracle.com> Message-ID: <4D401409.9000508@gmx.de> Am 26.01.2011 00:33, schrieb Brian Goetz: > >> Since postconditions are labeled "ensures" in the "r/e/m" triad, this >> method should be named "ensureNonNull". > > Right, there's precedent for "ensureXxx" methods to actually change the state of things to ensure > the postcondition, such as ensureCapacity() methods in the collection implementations. Given that > a part of the motivation for this change was to leave room in the namespace for both the > precondition-enforcing variety (barf on null) and the postcondition-ensuring variety, aka the > carpet-sweeping variety ("if it is null, make it non-null") ensureNonNull sounds a lot more like > the the carpet-sweeping version than the version being discussed (barf on null). +1 The funtionality is: Check the argument for non-nullity AND return it if the condition holds, otherwise fail by throwing NPE. "notNullChecked(x)" IMO perfectly describes this behaviour. As a short cut, "nullChecked(x)" seems clearly enough to me. It does not block a future ensureNonNull(x) -> convert x to a non-null value if null. "requireXxx" lacks the fact, that is doesn't specify the positive-case return behaviour. It's more suitable for a void method/operator as "assert" already does. -Ulf From Ulf.Zibis at gmx.de Wed Jan 26 13:21:48 2011 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Wed, 26 Jan 2011 14:21:48 +0100 Subject: Code review: 7012540 (java.util.Objects.nonNull() incorrectly named) In-Reply-To: <4D401409.9000508@gmx.de> References: <20110125231531.A78E712DF@eggemoggin.niobe.net> <4D3F5DDB.7070209@oracle.com> <4D401409.9000508@gmx.de> Message-ID: <4D401FEC.1070503@gmx.de> Am 26.01.2011 13:31, schrieb Ulf Zibis: > > The funtionality is: > Check the argument for non-nullity AND return it if the condition holds, otherwise fail by > throwing NPE. > IIRC, Object.nonNull(x) was introduced to preserve the developer from repetitively coding: if (x == null) { throw new NullPointerException(); } But isn't this not only half the rent? The 2nd part of the repetition is: try { ... } catch (NullPointerException npe) { doAlternatively(); } I think, in case of an expected null value, the developer has a specific idea, how to handle it. Just throwing an exception should be reserved for _un_expected cases. So something like "nullChecked(x, runnable)" could serve the full rent. Fairly this should be delayed to closures. -Ulf From jeffhain at rocketmail.com Wed Jan 26 15:37:59 2011 From: jeffhain at rocketmail.com (Jeff Hain) Date: Wed, 26 Jan 2011 15:37:59 +0000 (GMT) Subject: Code review: 7012540 (java.util.Objects.nonNull() incorrectly named) Message-ID: <30568.92255.qm@web29220.mail.ird.yahoo.com> Hello. As Ulf said, I think "requireNonNull" could be the name of a method that just checks that the specified reference is not null, and would not return anything (even though we could rather use "checkNonNull" in that case, and make it return true if non null). Though, "notNullChecked" or "nonNullChecked" might seem to suppose that the non-nullity of the specified value has already being checked. A more appropriate name would be "checkNonNullAndReturnIt", but it's too verbose. I'm considering "beingNonNull" as an alternative, for "beingNonNull(x)" contains the idea that?it is still "x", i.e. that it normally returns "x", and that it supposes "x" to be non null, i.e. that it checks it. Also, the passive form "being" contains the idea that we don't change anything to the value. An alternative to this alternative would be "notBeingNull", which would be more on pair with methods like "beingPrime"/"notBeingPrime" ("beingNonPrime" looking weird to me). Though, verbs in passive form in methods names might look strange to a lot of people. Regards, Jeff. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pbenedict at apache.org Wed Jan 26 15:44:05 2011 From: pbenedict at apache.org (Paul Benedict) Date: Wed, 26 Jan 2011 09:44:05 -0600 Subject: Code review: 7012540 (java.util.Objects.nonNull() incorrectly named) In-Reply-To: <30568.92255.qm@web29220.mail.ird.yahoo.com> References: <30568.92255.qm@web29220.mail.ird.yahoo.com> Message-ID: Alternatively, we could use the "as" prefix already established in the JDK -- since this function is a kind of conversion. asNonNull(Object o, Object fallbackObj) Paul On Wed, Jan 26, 2011 at 9:37 AM, Jeff Hain wrote: > Hello. > > As Ulf said, I think "requireNonNull" could be the name of a method that > just > checks that the specified reference is not null, and would not return > anything > (even though we could rather use "checkNonNull" in that case, and make it > return true if non null). > > Though, "notNullChecked" or "nonNullChecked" might seem to suppose > that the non-nullity of the specified value has already being checked. > > A more appropriate name would be "checkNonNullAndReturnIt", but it's too > verbose. > > I'm considering "beingNonNull" as an alternative, for "beingNonNull(x)" > contains > the idea that it is still "x", i.e. that it normally returns "x", and that > it supposes "x" > to be non null, i.e. that it checks it. > Also, the passive form "being" contains the idea that we don't change > anything to > the value. > > An alternative to this alternative would be "notBeingNull", which would be > more on > pair with methods like "beingPrime"/"notBeingPrime" ("beingNonPrime" > looking > weird to me). > > Though, verbs in passive form in methods names might look strange to a lot > of people. > > Regards, > > Jeff. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.goetz at oracle.com Wed Jan 26 15:48:12 2011 From: brian.goetz at oracle.com (Brian Goetz) Date: Wed, 26 Jan 2011 10:48:12 -0500 Subject: Code review: 7012540 (java.util.Objects.nonNull() incorrectly named) In-Reply-To: References: <30568.92255.qm@web29220.mail.ird.yahoo.com> Message-ID: <4D40423C.90305@oracle.com> This ground has been already covered. "as", "to", etc, are fine for conversions -- but by definition this is a conversion will never succeed. At the same time, we need to leave room in the namespace for a conversion operation that *will* succeed. (If we didn't need both, this whole conversation would be moot!) as/to/make are all fine for the "carpet-sweeping" version of this method, but that's not what's being discussed. On 1/26/2011 10:44 AM, Paul Benedict wrote: > Alternatively, we could use the "as" prefix already established in the > JDK -- since this function is a kind of conversion. > > asNonNull(Object o, Object fallbackObj) > > Paul > > On Wed, Jan 26, 2011 at 9:37 AM, Jeff Hain > wrote: > > Hello. > As Ulf said, I think "requireNonNull" could be the name of a method > that just > checks that the specified reference is not null, and would not > return anything > (even though we could rather use "checkNonNull" in that case, and > make it > return true if non null). > Though, "notNullChecked" or "nonNullChecked" might seem to suppose > that the non-nullity of the specified value has already being checked. > A more appropriate name would be "checkNonNullAndReturnIt", but it's > too verbose. > I'm considering "beingNonNull" as an alternative, for > "beingNonNull(x)" contains > the idea that it is still "x", i.e. that it normally returns "x", > and that it supposes "x" > to be non null, i.e. that it checks it. > Also, the passive form "being" contains the idea that we don't > change anything to > the value. > An alternative to this alternative would be "notBeingNull", which > would be more on > pair with methods like "beingPrime"/"notBeingPrime" ("beingNonPrime" > looking > weird to me). > Though, verbs in passive form in methods names might look strange to > a lot of people. > Regards, > Jeff. > > From pbenedict at apache.org Wed Jan 26 16:00:24 2011 From: pbenedict at apache.org (Paul Benedict) Date: Wed, 26 Jan 2011 10:00:24 -0600 Subject: Code review: 7012540 (java.util.Objects.nonNull() incorrectly named) In-Reply-To: <4D40423C.90305@oracle.com> References: <30568.92255.qm@web29220.mail.ird.yahoo.com> <4D40423C.90305@oracle.com> Message-ID: Brian, My implementation of asNonNull() is as follows: return (o != null) ? o : fallbackObj. That is a conversion that can succeed. However, the conversation clearly has shown we need this (1) a null-safe conversion method and (2) and a NPE-throwing check method. I was only referring to the #1 and that's why I think "as" works here. For the latter, I prefer "check" or "validate" to throw NPE when null is an error. Paul On Wed, Jan 26, 2011 at 9:48 AM, Brian Goetz wrote: > This ground has been already covered. "as", "to", etc, are fine for > conversions -- but by definition this is a conversion will never succeed. > At the same time, we need to leave room in the namespace for a conversion > operation that *will* succeed. (If we didn't need both, this whole > conversation would be moot!) as/to/make are all fine for the > "carpet-sweeping" version of this method, but that's not what's being > discussed. > > > On 1/26/2011 10:44 AM, Paul Benedict wrote: > >> Alternatively, we could use the "as" prefix already established in the >> JDK -- since this function is a kind of conversion. >> >> asNonNull(Object o, Object fallbackObj) >> >> Paul >> >> On Wed, Jan 26, 2011 at 9:37 AM, Jeff Hain > > wrote: >> >> Hello. >> As Ulf said, I think "requireNonNull" could be the name of a method >> that just >> checks that the specified reference is not null, and would not >> return anything >> (even though we could rather use "checkNonNull" in that case, and >> make it >> return true if non null). >> Though, "notNullChecked" or "nonNullChecked" might seem to suppose >> that the non-nullity of the specified value has already being checked. >> A more appropriate name would be "checkNonNullAndReturnIt", but it's >> too verbose. >> I'm considering "beingNonNull" as an alternative, for >> "beingNonNull(x)" contains >> the idea that it is still "x", i.e. that it normally returns "x", >> and that it supposes "x" >> to be non null, i.e. that it checks it. >> Also, the passive form "being" contains the idea that we don't >> change anything to >> the value. >> An alternative to this alternative would be "notBeingNull", which >> would be more on >> pair with methods like "beingPrime"/"notBeingPrime" ("beingNonPrime" >> looking >> weird to me). >> Though, verbs in passive form in methods names might look strange to >> a lot of people. >> Regards, >> Jeff. >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From schlosna at gmail.com Wed Jan 26 16:01:43 2011 From: schlosna at gmail.com (David Schlosnagle) Date: Wed, 26 Jan 2011 11:01:43 -0500 Subject: Code review: 7012540 (java.util.Objects.nonNull() incorrectly named) In-Reply-To: <4D3F5DDB.7070209@oracle.com> References: <20110125231531.A78E712DF@eggemoggin.niobe.net> <4D3F5DDB.7070209@oracle.com> Message-ID: On Tue, Jan 25, 2011 at 6:33 PM, Brian Goetz wrote: >>> Additional notes: After much discussion on core-libs-dev, the name >>> requireNonNull() seemed the least objectionable. >> >> I think requireNonNull(x) is confusing. > > Remember there's two versions of someModifierNonNull being discussed; the > one currently in Objects is the precondition-enforcing variety, not the > postcondition-ensuring variety. ?Are we talking about the same thing? > >> For those familiar with the "requires/ensures/modifies" triad of verbs as >> a compact way of identifying the preconditions, postconditions, and side >> effects of a method or procedure in a comment, a specification, or a more >> formal design-by-contract framework, "requires" is just wrong. >> >> When analyzing the invocation of foo in your example, the non-nullity of >> s and t are preconditions of foo and therefore postconditions of the >> check method. ?Naming the check method "requireNonNull" suggests that >> the check method itself has a precondition that its argument be non-null, >> when in fact it's the check method's postcondition which ensures that >> property. >> >> Since postconditions are labeled "ensures" in the "r/e/m" triad, this >> method should be named "ensureNonNull". > > Right, there's precedent for "ensureXxx" methods to actually change the > state of things to ensure the postcondition, such as ensureCapacity() > methods in the collection implementations. ?Given that a part of the > motivation for this change was to leave room in the namespace for both the > precondition-enforcing variety (barf on null) and the postcondition-ensuring > variety, aka the carpet-sweeping variety ("if it is null, make it non-null") > ensureNonNull sounds a lot more like the the carpet-sweeping version than > the version being discussed (barf on null). > > The r/e/m framework seems to support require for the throwing version (as > implemented by this patch): for the throwing version, non-nullity is a > precondition of the check method (if the condition is not met, error), > whereas for the carpet-sweeping version, it is a postcondition of the check > method (if the check method can come up with a reasonable default value). > ?(It happens to be a postcondition of both, but the significant behavior and > use of the throwing version currently in Objects is to enforce an error when > the precondition is not met.) ?Therefore: > > ?requireNonNull(x) -> throw if x == null > ?ensureNonNull(x) ?-> convert x to a non-null value if null > > seems like the right taxonomy. > If you're still open to other possible names for the requireNonNull method, based on some of the evaluation comments on the highest rated RFE [1] would you prefer assumeNonNull that throws NullPointerException when the assumption is violated, otherwise returns the specified object reference? I honestly don't have a strong opinion between either requireNonNull or assumeNonNull, but I think it is at least a small step toward a more comprehensive preconditions API. As I mentioned before, I'd love to see something along the lines of Guava's Preconditions or Apache commons-lang's Validate APIs as part of the JDK, but that is probably best left to JDK 8 to better flesh out. [1]: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4449383 - Dave From brian.goetz at oracle.com Wed Jan 26 16:40:38 2011 From: brian.goetz at oracle.com (Brian Goetz) Date: Wed, 26 Jan 2011 11:40:38 -0500 Subject: Code review: 7012540 (java.util.Objects.nonNull() incorrectly named) In-Reply-To: References: <20110125231531.A78E712DF@eggemoggin.niobe.net> <4D3F5DDB.7070209@oracle.com> Message-ID: <4D404E86.5070501@oracle.com> The only reason we're even having this discussion now -- as we're well past freeze for 7 -- is to prevent the current situation from getting carved into stone, where we have a nonNull() precondition-enforcing method in Objects. While the correct name for the postcondition-producing version is tangentially relevant to that, the short-term goal -- which we keep drifting from -- is renaming the precondition-enforcing version so as to *also allow room for* a postcondition-producing version later. Anything more than this is going to get rejected on a "sorry, it's too late" basis. (Its amusing that the goal here was to eliminate a name that was confusing because it could apply equally well to two equally valid use cases, and this is in fact so confusing that even we cannot be consistent about which version we're discussing....) On 1/26/2011 11:01 AM, David Schlosnagle wrote: > On Tue, Jan 25, 2011 at 6:33 PM, Brian Goetz wrote: >>>> Additional notes: After much discussion on core-libs-dev, the name >>>> requireNonNull() seemed the least objectionable. >>> >>> I think requireNonNull(x) is confusing. >> >> Remember there's two versions of someModifierNonNull being discussed; the >> one currently in Objects is the precondition-enforcing variety, not the >> postcondition-ensuring variety. Are we talking about the same thing? >> >>> For those familiar with the "requires/ensures/modifies" triad of verbs as >>> a compact way of identifying the preconditions, postconditions, and side >>> effects of a method or procedure in a comment, a specification, or a more >>> formal design-by-contract framework, "requires" is just wrong. >>> >>> When analyzing the invocation of foo in your example, the non-nullity of >>> s and t are preconditions of foo and therefore postconditions of the >>> check method. Naming the check method "requireNonNull" suggests that >>> the check method itself has a precondition that its argument be non-null, >>> when in fact it's the check method's postcondition which ensures that >>> property. >>> >>> Since postconditions are labeled "ensures" in the "r/e/m" triad, this >>> method should be named "ensureNonNull". >> >> Right, there's precedent for "ensureXxx" methods to actually change the >> state of things to ensure the postcondition, such as ensureCapacity() >> methods in the collection implementations. Given that a part of the >> motivation for this change was to leave room in the namespace for both the >> precondition-enforcing variety (barf on null) and the postcondition-ensuring >> variety, aka the carpet-sweeping variety ("if it is null, make it non-null") >> ensureNonNull sounds a lot more like the the carpet-sweeping version than >> the version being discussed (barf on null). >> >> The r/e/m framework seems to support require for the throwing version (as >> implemented by this patch): for the throwing version, non-nullity is a >> precondition of the check method (if the condition is not met, error), >> whereas for the carpet-sweeping version, it is a postcondition of the check >> method (if the check method can come up with a reasonable default value). >> (It happens to be a postcondition of both, but the significant behavior and >> use of the throwing version currently in Objects is to enforce an error when >> the precondition is not met.) Therefore: >> >> requireNonNull(x) -> throw if x == null >> ensureNonNull(x) -> convert x to a non-null value if null >> >> seems like the right taxonomy. >> > > If you're still open to other possible names for the requireNonNull > method, based on some of the evaluation comments on the highest rated > RFE [1] would you prefer assumeNonNull that throws > NullPointerException when the assumption is violated, otherwise > returns the specified object reference? I honestly don't have a strong > opinion between either requireNonNull or assumeNonNull, but I think it > is at least a small step toward a more comprehensive preconditions > API. As I mentioned before, I'd love to see something along the lines > of Guava's Preconditions or Apache commons-lang's Validate APIs as > part of the JDK, but that is probably best left to JDK 8 to better > flesh out. > > [1]: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4449383 > > - Dave From alan.bateman at oracle.com Wed Jan 26 18:02:32 2011 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Wed, 26 Jan 2011 18:02:32 +0000 Subject: hg: jdk7/tl/jdk: 7012663: javadoc warning in javax.swing.JComponent and javax.swing.plaf.synth.SynthTextPaneUI Message-ID: <20110126180241.F2FF947171@hg.openjdk.java.net> Changeset: bf1b937076db Author: alanb Date: 2011-01-26 18:01 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/bf1b937076db 7012663: javadoc warning in javax.swing.JComponent and javax.swing.plaf.synth.SynthTextPaneUI Reviewed-by: alexp ! src/share/classes/javax/swing/JComponent.java ! src/share/classes/javax/swing/plaf/synth/SynthTextPaneUI.java From jonathan.gibbons at oracle.com Wed Jan 26 19:20:54 2011 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Wed, 26 Jan 2011 19:20:54 +0000 Subject: hg: jdk7/tl/langtools: 6554097: "final" confuses @SuppressWarnings Message-ID: <20110126192056.29B2B47174@hg.openjdk.java.net> Changeset: df371fd16386 Author: jjg Date: 2011-01-26 11:20 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/df371fd16386 6554097: "final" confuses @SuppressWarnings Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java + test/tools/javac/T6554097.java + test/tools/javac/T6554097.out From joe.darcy at oracle.com Wed Jan 26 20:32:39 2011 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Wed, 26 Jan 2011 20:32:39 +0000 Subject: hg: jdk7/tl/jdk: 7013420: Project Coin: remove general expression support from try-with-resources statement Message-ID: <20110126203249.7183C47178@hg.openjdk.java.net> Changeset: abab55565eda Author: darcy Date: 2011-01-26 12:32 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/abab55565eda 7013420: Project Coin: remove general expression support from try-with-resources statement Reviewed-by: alanb ! test/java/nio/channels/FileChannel/Truncate.java From jonathan.gibbons at oracle.com Wed Jan 26 21:46:00 2011 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Wed, 26 Jan 2011 21:46:00 +0000 Subject: hg: jdk7/tl/langtools: 7013272: Automatically generate info about how compiler resource keys are used Message-ID: <20110126214602.DFCAD4717E@hg.openjdk.java.net> Changeset: 3da26790ccb7 Author: jjg Date: 2011-01-26 13:45 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/3da26790ccb7 7013272: Automatically generate info about how compiler resource keys are used Reviewed-by: mcimadamore ! make/build.xml ! src/share/classes/com/sun/tools/javac/code/Printer.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties + test/tools/javac/diags/ArgTypeCompilerFactory.java ! test/tools/javac/diags/Example.java + test/tools/javac/diags/MessageFile.java + test/tools/javac/diags/MessageInfo.java ! test/tools/javac/diags/RunExamples.java From jjb at google.com Wed Jan 26 23:44:05 2011 From: jjb at google.com (Joshua Bloch) Date: Wed, 26 Jan 2011 15:44:05 -0800 Subject: Code review: 7012540 (java.util.Objects.nonNull() incorrectly named) In-Reply-To: <4D404E86.5070501@oracle.com> References: <20110125231531.A78E712DF@eggemoggin.niobe.net> <4D3F5DDB.7070209@oracle.com> <4D404E86.5070501@oracle.com> Message-ID: I like the name *nonNull*. All other things being equal, shorter is better. I've used the name *nonNull* for a few years, and it's feels right. To my mind, *requireNonNull* does a worse job of suggesting that the method returns its argument. Josh On Wed, Jan 26, 2011 at 8:40 AM, Brian Goetz wrote: > The only reason we're even having this discussion now -- as we're well past > freeze for 7 -- is to prevent the current situation from getting carved into > stone, where we have a nonNull() precondition-enforcing method in Objects. > While the correct name for the postcondition-producing version is > tangentially relevant to that, the short-term goal -- which we keep drifting > from -- is renaming the precondition-enforcing version so as to *also allow > room for* a postcondition-producing version later. > > Anything more than this is going to get rejected on a "sorry, it's too > late" basis. > > (Its amusing that the goal here was to eliminate a name that was confusing > because it could apply equally well to two equally valid use cases, and this > is in fact so confusing that even we cannot be consistent about which > version we're discussing....) > > > On 1/26/2011 11:01 AM, David Schlosnagle wrote: > >> On Tue, Jan 25, 2011 at 6:33 PM, Brian Goetz >> wrote: >> >>> Additional notes: After much discussion on core-libs-dev, the name >>>>> requireNonNull() seemed the least objectionable. >>>>> >>>> >>>> I think requireNonNull(x) is confusing. >>>> >>> >>> Remember there's two versions of someModifierNonNull being discussed; the >>> one currently in Objects is the precondition-enforcing variety, not the >>> postcondition-ensuring variety. Are we talking about the same thing? >>> >>> For those familiar with the "requires/ensures/modifies" triad of verbs >>>> as >>>> a compact way of identifying the preconditions, postconditions, and side >>>> effects of a method or procedure in a comment, a specification, or a >>>> more >>>> formal design-by-contract framework, "requires" is just wrong. >>>> >>>> When analyzing the invocation of foo in your example, the non-nullity of >>>> s and t are preconditions of foo and therefore postconditions of the >>>> check method. Naming the check method "requireNonNull" suggests that >>>> the check method itself has a precondition that its argument be >>>> non-null, >>>> when in fact it's the check method's postcondition which ensures that >>>> property. >>>> >>>> Since postconditions are labeled "ensures" in the "r/e/m" triad, this >>>> method should be named "ensureNonNull". >>>> >>> >>> Right, there's precedent for "ensureXxx" methods to actually change the >>> state of things to ensure the postcondition, such as ensureCapacity() >>> methods in the collection implementations. Given that a part of the >>> motivation for this change was to leave room in the namespace for both >>> the >>> precondition-enforcing variety (barf on null) and the >>> postcondition-ensuring >>> variety, aka the carpet-sweeping variety ("if it is null, make it >>> non-null") >>> ensureNonNull sounds a lot more like the the carpet-sweeping version than >>> the version being discussed (barf on null). >>> >>> The r/e/m framework seems to support require for the throwing version (as >>> implemented by this patch): for the throwing version, non-nullity is a >>> precondition of the check method (if the condition is not met, error), >>> whereas for the carpet-sweeping version, it is a postcondition of the >>> check >>> method (if the check method can come up with a reasonable default value). >>> (It happens to be a postcondition of both, but the significant behavior >>> and >>> use of the throwing version currently in Objects is to enforce an error >>> when >>> the precondition is not met.) Therefore: >>> >>> requireNonNull(x) -> throw if x == null >>> ensureNonNull(x) -> convert x to a non-null value if null >>> >>> seems like the right taxonomy. >>> >>> >> If you're still open to other possible names for the requireNonNull >> method, based on some of the evaluation comments on the highest rated >> RFE [1] would you prefer assumeNonNull that throws >> NullPointerException when the assumption is violated, otherwise >> returns the specified object reference? I honestly don't have a strong >> opinion between either requireNonNull or assumeNonNull, but I think it >> is at least a small step toward a more comprehensive preconditions >> API. As I mentioned before, I'd love to see something along the lines >> of Guava's Preconditions or Apache commons-lang's Validate APIs as >> part of the JDK, but that is probably best left to JDK 8 to better >> flesh out. >> >> [1]: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4449383 >> >> - Dave >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From crazybob at crazybob.org Thu Jan 27 01:20:14 2011 From: crazybob at crazybob.org (Bob Lee) Date: Wed, 26 Jan 2011 17:20:14 -0800 Subject: Code review: 7012540 (java.util.Objects.nonNull() incorrectly named) In-Reply-To: References: <20110125231531.A78E712DF@eggemoggin.niobe.net> <4D3F5DDB.7070209@oracle.com> <4D404E86.5070501@oracle.com> Message-ID: On Wed, Jan 26, 2011 at 3:44 PM, Joshua Bloch wrote: > I like the name *nonNull*. All other things being equal, shorter is > better. I've used the name *nonNull* for a few years, and it's feels > right. To my mind, *requireNonNull* does a worse job of suggesting that > the method returns its argument. +1 for nonNull. While it's implemented as a method, I think of it more as a keyword-like modifier, in which case an adjective works better than a verb phrase. Bob -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.reinhold at oracle.com Thu Jan 27 05:05:29 2011 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 26 Jan 2011 21:05:29 -0800 Subject: Code review: 7012540 (java.util.Objects.nonNull() incorrectly named) In-Reply-To: brian.goetz@oracle.com; Tue, 25 Jan 2011 18:33:47 EST; <4D3F5DDB.7070209@oracle.com> Message-ID: <20110127050529.913241754@eggemoggin.niobe.net> Executive summary: requireNonNull is the preferred name. > Date: Tue, 25 Jan 2011 18:33:47 -0500 > From: brian.goetz at oracle.com > mark.reinhold at oracle.com wrote: >> I think requireNonNull(x) is confusing. > > Remember there's two versions of someModifierNonNull being discussed; the one > currently in Objects is the precondition-enforcing variety, not the > postcondition-ensuring variety. Are we talking about the same thing? Yes, i.e., the former. >> For those familiar with the "requires/ensures/modifies" triad of verbs as >> a compact way of identifying the preconditions, postconditions, and side >> effects of a method or procedure in a comment, a specification, or a more >> formal design-by-contract framework, "requires" is just wrong. >> >> When analyzing the invocation of foo in your example, the non-nullity of >> s and t are preconditions of foo and therefore postconditions of the >> check method. Naming the check method "requireNonNull" suggests that >> the check method itself has a precondition that its argument be non-null, >> when in fact it's the check method's postcondition which ensures that >> property. >> >> Since postconditions are labeled "ensures" in the "r/e/m" triad, this >> method should be named "ensureNonNull". > > Right, there's precedent for "ensureXxx" methods to actually change the state > of things to ensure the postcondition, such as ensureCapacity() methods in the > collection implementations. Given that a part of the motivation for this > change was to leave room in the namespace for both the precondition-enforcing > variety (barf on null) and the postcondition-ensuring variety, aka the > carpet-sweeping variety ("if it is null, make it non-null") ensureNonNull > sounds a lot more like the the carpet-sweeping version than the version being > discussed (barf on null). I was actually arguing that the barfing version should be named ensureNonNull. (Wow, am I actually writing about barfing methods?) > The r/e/m framework seems to support require for the throwing version (as > implemented by this patch): for the throwing version, non-nullity is a > precondition of the check method (if the condition is not met, error), whereas > for the carpet-sweeping version, it is a postcondition of the check method (if > the check method can come up with a reasonable default value). (It happens to > be a postcondition of both, but the significant behavior and use of the > throwing version currently in Objects is to enforce an error when the > precondition is not met.) Therefore: > > requireNonNull(x) -> throw if x == null > ensureNonNull(x) -> convert x to a non-null value if null > > seems like the right taxonomy. It depends on your perspective. In a nested method invocation, the postconditions of the inner method must relate to the preconditions of the outer method. That is, for the expression foo(bar(x)) to be correct then the postconditions of the bar method must imply the preconditions of foo method. Now suppose that bar is intended to be the barf-on-null method. If we consider how to name bar on its own, outside of its intended usage as in this example, then it's natural (for me, anyway) to conclude that "ensuresNonNull" is the right name. What's important about bar is its postcondition, namely that its return value (x) is not null. Naming it "requireNonNull" seems backwards on this view, because "requires" is always about preconditions, and it's definitely not a precondition of this method that its argument not be null. If, by contrast, we consider how to name bar in the context of the above example then it's easy to see that "requireNonNull" is the better name, because what's important in the overall expression is satisfying foo's precondition that its argument not be null, and so foo(requireNonNull(x)) reads very fluently. A little utility method like this will never (well, hardly ever) be used in isolation, so I agree now that it makes sense to prefer the second form, i.e., requireNonNull. I'm not sure I agree that the corresponding carpet-sweeping method is best named ensureNonNull; treating that as a conversion, i.e., asNonNull, may be a better choice. That, however, is a discussion for another release. - Mark From scolebourne at joda.org Thu Jan 27 08:38:23 2011 From: scolebourne at joda.org (Stephen Colebourne) Date: Thu, 27 Jan 2011 08:38:23 +0000 Subject: Code review: 7012540 (java.util.Objects.nonNull() incorrectly named) In-Reply-To: <20110127050529.913241754@eggemoggin.niobe.net> References: <4D3F5DDB.7070209@oracle.com> <20110127050529.913241754@eggemoggin.niobe.net> Message-ID: As I said before, removing this method is the best option now. Get it right in v8. Stephen On 27 January 2011 05:05, wrote: > Executive summary: requireNonNull is the preferred name. > >> Date: Tue, 25 Jan 2011 18:33:47 -0500 >> From: brian.goetz at oracle.com > >> mark.reinhold at oracle.com wrote: >>> I think requireNonNull(x) is confusing. >> >> Remember there's two versions of someModifierNonNull being discussed; the one >> currently in Objects is the precondition-enforcing variety, not the >> postcondition-ensuring variety. ?Are we talking about the same thing? > > Yes, i.e., the former. > >>> For those familiar with the "requires/ensures/modifies" triad of verbs as >>> a compact way of identifying the preconditions, postconditions, and side >>> effects of a method or procedure in a comment, a specification, or a more >>> formal design-by-contract framework, "requires" is just wrong. >>> >>> When analyzing the invocation of foo in your example, the non-nullity of >>> s and t are preconditions of foo and therefore postconditions of the >>> check method. ?Naming the check method "requireNonNull" suggests that >>> the check method itself has a precondition that its argument be non-null, >>> when in fact it's the check method's postcondition which ensures that >>> property. >>> >>> Since postconditions are labeled "ensures" in the "r/e/m" triad, this >>> method should be named "ensureNonNull". >> >> Right, there's precedent for "ensureXxx" methods to actually change the state >> of things to ensure the postcondition, such as ensureCapacity() methods in the >> collection implementations. ?Given that a part of the motivation for this >> change was to leave room in the namespace for both the precondition-enforcing >> variety (barf on null) and the postcondition-ensuring variety, aka the >> carpet-sweeping variety ("if it is null, make it non-null") ensureNonNull >> sounds a lot more like the the carpet-sweeping version than the version being >> discussed (barf on null). > > I was actually arguing that the barfing version should be named > ensureNonNull. > > (Wow, am I actually writing about barfing methods?) > >> The r/e/m framework seems to support require for the throwing version (as >> implemented by this patch): for the throwing version, non-nullity is a >> precondition of the check method (if the condition is not met, error), whereas >> for the carpet-sweeping version, it is a postcondition of the check method (if >> the check method can come up with a reasonable default value). ?(It happens to >> be a postcondition of both, but the significant behavior and use of the >> throwing version currently in Objects is to enforce an error when the >> precondition is not met.) ?Therefore: >> >> ? requireNonNull(x) -> throw if x == null >> ? ensureNonNull(x) ?-> convert x to a non-null value if null >> >> seems like the right taxonomy. > > It depends on your perspective. > > In a nested method invocation, the postconditions of the inner method > must relate to the preconditions of the outer method. ?That is, for the > expression > > ? ?foo(bar(x)) > > to be correct then the postconditions of the bar method must imply the > preconditions of foo method. > > Now suppose that bar is intended to be the barf-on-null method. > > If we consider how to name bar on its own, outside of its intended usage > as in this example, then it's natural (for me, anyway) to conclude that > "ensuresNonNull" is the right name. ?What's important about bar is its > postcondition, namely that its return value (x) is not null. ?Naming it > "requireNonNull" seems backwards on this view, because "requires" is > always about preconditions, and it's definitely not a precondition of > this method that its argument not be null. > > If, by contrast, we consider how to name bar in the context of the above > example then it's easy to see that "requireNonNull" is the better name, > because what's important in the overall expression is satisfying foo's > precondition that its argument not be null, and so > > ? ?foo(requireNonNull(x)) > > reads very fluently. > > A little utility method like this will never (well, hardly ever) be used > in isolation, so I agree now that it makes sense to prefer the second > form, i.e., requireNonNull. > > I'm not sure I agree that the corresponding carpet-sweeping method is > best named ensureNonNull; treating that as a conversion, i.e., asNonNull, > may be a better choice. ?That, however, is a discussion for another > release. > > - Mark > From forax at univ-mlv.fr Thu Jan 27 08:43:35 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Thu, 27 Jan 2011 09:43:35 +0100 Subject: Code review: 7012540 (java.util.Objects.nonNull() incorrectly named) In-Reply-To: References: <4D3F5DDB.7070209@oracle.com> <20110127050529.913241754@eggemoggin.niobe.net> Message-ID: <4D413037.5040801@univ-mlv.fr> On 01/27/2011 09:38 AM, Stephen Colebourne wrote: > As I said before, removing this method is the best option now. Get it > right in v8. > Stephen I think we can't. This method is already used at many place in the JDK. About the name, I propose: iUsedToUseGetClassHereButNodobyWasAbleToUnderstand() R?mi > > On 27 January 2011 05:05, wrote: >> Executive summary: requireNonNull is the preferred name. >> >>> Date: Tue, 25 Jan 2011 18:33:47 -0500 >>> From: brian.goetz at oracle.com >>> mark.reinhold at oracle.com wrote: >>>> I think requireNonNull(x) is confusing. >>> Remember there's two versions of someModifierNonNull being discussed; the one >>> currently in Objects is the precondition-enforcing variety, not the >>> postcondition-ensuring variety. Are we talking about the same thing? >> Yes, i.e., the former. >> >>>> For those familiar with the "requires/ensures/modifies" triad of verbs as >>>> a compact way of identifying the preconditions, postconditions, and side >>>> effects of a method or procedure in a comment, a specification, or a more >>>> formal design-by-contract framework, "requires" is just wrong. >>>> >>>> When analyzing the invocation of foo in your example, the non-nullity of >>>> s and t are preconditions of foo and therefore postconditions of the >>>> check method. Naming the check method "requireNonNull" suggests that >>>> the check method itself has a precondition that its argument be non-null, >>>> when in fact it's the check method's postcondition which ensures that >>>> property. >>>> >>>> Since postconditions are labeled "ensures" in the "r/e/m" triad, this >>>> method should be named "ensureNonNull". >>> Right, there's precedent for "ensureXxx" methods to actually change the state >>> of things to ensure the postcondition, such as ensureCapacity() methods in the >>> collection implementations. Given that a part of the motivation for this >>> change was to leave room in the namespace for both the precondition-enforcing >>> variety (barf on null) and the postcondition-ensuring variety, aka the >>> carpet-sweeping variety ("if it is null, make it non-null") ensureNonNull >>> sounds a lot more like the the carpet-sweeping version than the version being >>> discussed (barf on null). >> I was actually arguing that the barfing version should be named >> ensureNonNull. >> >> (Wow, am I actually writing about barfing methods?) >> >>> The r/e/m framework seems to support require for the throwing version (as >>> implemented by this patch): for the throwing version, non-nullity is a >>> precondition of the check method (if the condition is not met, error), whereas >>> for the carpet-sweeping version, it is a postcondition of the check method (if >>> the check method can come up with a reasonable default value). (It happens to >>> be a postcondition of both, but the significant behavior and use of the >>> throwing version currently in Objects is to enforce an error when the >>> precondition is not met.) Therefore: >>> >>> requireNonNull(x) -> throw if x == null >>> ensureNonNull(x) -> convert x to a non-null value if null >>> >>> seems like the right taxonomy. >> It depends on your perspective. >> >> In a nested method invocation, the postconditions of the inner method >> must relate to the preconditions of the outer method. That is, for the >> expression >> >> foo(bar(x)) >> >> to be correct then the postconditions of the bar method must imply the >> preconditions of foo method. >> >> Now suppose that bar is intended to be the barf-on-null method. >> >> If we consider how to name bar on its own, outside of its intended usage >> as in this example, then it's natural (for me, anyway) to conclude that >> "ensuresNonNull" is the right name. What's important about bar is its >> postcondition, namely that its return value (x) is not null. Naming it >> "requireNonNull" seems backwards on this view, because "requires" is >> always about preconditions, and it's definitely not a precondition of >> this method that its argument not be null. >> >> If, by contrast, we consider how to name bar in the context of the above >> example then it's easy to see that "requireNonNull" is the better name, >> because what's important in the overall expression is satisfying foo's >> precondition that its argument not be null, and so >> >> foo(requireNonNull(x)) >> >> reads very fluently. >> >> A little utility method like this will never (well, hardly ever) be used >> in isolation, so I agree now that it makes sense to prefer the second >> form, i.e., requireNonNull. >> >> I'm not sure I agree that the corresponding carpet-sweeping method is >> best named ensureNonNull; treating that as a conversion, i.e., asNonNull, >> may be a better choice. That, however, is a discussion for another >> release. >> >> - Mark >> From neil.richards at ngmr.net Thu Jan 27 11:44:20 2011 From: neil.richards at ngmr.net (Neil Richards) Date: Thu, 27 Jan 2011 11:44:20 +0000 Subject: Making java.util.Iterator.remove() for the iterators for EnumSet more resilient In-Reply-To: References: Message-ID: On 26 January 2011 01:57, Joshua Bloch wrote: > I have serious reservations about this. It would be the first time (to my > knowledge) that we deliberately swept a concurrent modification under the > rug. ?If we go to the effort of detecting it (which you're doing), the least > we should do is to report it. I see that the current API Javadoc for EnumSet currently says this about the behaviour of its iterator: " The iterator returned by the iterator method traverses the elements in their natural order (the order in which the enum constants are declared). The returned iterator is weakly consistent: it will never throw ConcurrentModificationException and it may or may not show the effects of any modifications to the set that occur while the iteration is in progress. " The change I suggest improves the resilience of the behaviour of the EnumSet implementations within the confines of the behaviour mandated by the existing API Javadoc. The additional modification that you suggest would necessitate a change in the documented behaviour here, albeit to something more akin to other Iterator implementations. I can see validity in the argument on both sides of this, but, given the way things are currently documented in the API and the ability (with the change) for the EnumSet Iterator impls to handle things in naturally graceful manner (ie. without corrupting the set), I think I still lean towards abiding by the constraints of the current documentation and so not throwing a ConcurrentModificationException. (I could probably be swayed if the consensus lay the other way, however.) > Also, this file (and most of java.util and > java.lang) does not use braces on single-line if/for/while/do statements. In using braces for single-line if statements, I was following the Java Coding Conventions, section 7.4 (http://www.oracle.com/technetwork/java/codeconventions-142311.html#449), in which it says: " Note: if statements always use braces {}. Avoid the following error-prone form: if (condition) //AVOID! THIS OMITS THE BRACES {}! statement; " Was I wrong to have done this? Are there any more pertinent (and/or recent(!)) coding conventions for OpenJDK ? > There was a much > more serious case where we failed to throw a CME that we should have thrown, > and the CCC (an internal review body within Sun, and now Oracle) ruled that > it represented an unacceptable compatibility violation. > If we're going to make this change to EnumSet, then we must reopen?4902078 > and fix that too. Thanks for the pointer - it seems to be an interesting problem, and one which I have not hitherto contemplated or explored. Being generally an advocate of the philosophy of "making the word a better place, fixing one bug at a time", I don't see a solution to 4902078 as being *inextricably* linked with the one I'm trying to address in EnumSet here - though they're obviously in the same area of SDK function. > P.S. ?There is a much more serious problem with EnumMap that we might want > to fix. I believe that the problem to which you refer is reported in 6312706, "(coll) Map entrySet iterators should return different entries on each call to next()". In the comments for that report, it suggests that the mischievous behaviour can also be seen in the entry set iterator for ConcurrentHashMap (in addition to those for IdentityHashMap and EnumMap). It's been my intention to work on this problem, to try and brew up an suitably agreeable solution, which I'll raise in a separate thread (once I have it (!)). - Neil PS: Thanks, Mike, for creating the RFE and posting the webrev. -- Unless stated above: IBM email: neil_richards at uk.ibm.com IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From brian.goetz at oracle.com Thu Jan 27 14:31:27 2011 From: brian.goetz at oracle.com (Brian Goetz) Date: Thu, 27 Jan 2011 09:31:27 -0500 Subject: Code review: 7012540 (java.util.Objects.nonNull() incorrectly named) In-Reply-To: <4D413037.5040801@univ-mlv.fr> References: <4D3F5DDB.7070209@oracle.com> <20110127050529.913241754@eggemoggin.niobe.net> <4D413037.5040801@univ-mlv.fr> Message-ID: <4D4181BF.7050703@oracle.com> > About the name, I propose: > iUsedToUseGetClassHereButNodobyWasAbleToUnderstand() But there are two methods we want to rename this to, and we can't use this name twice. I propose we generate random method names instead. From jason_mehrens at hotmail.com Thu Jan 27 16:04:11 2011 From: jason_mehrens at hotmail.com (Jason Mehrens) Date: Thu, 27 Jan 2011 10:04:11 -0600 Subject: Code review: 7012540 (java.util.Objects.nonNull() incorrectly named) In-Reply-To: <4D4181BF.7050703@oracle.com> References: <4D3F5DDB.7070209@oracle.com> <20110127050529.913241754@eggemoggin.niobe.net> , <4D413037.5040801@univ-mlv.fr>, <4D4181BF.7050703@oracle.com> Message-ID: > > About the name, I propose: > > iUsedToUseGetClassHereButNodobyWasAbleToUnderstand() > > But there are two methods we want to rename this to, and we can't use > this name twice. I propose we generate random method names instead. You don't want to violate trademarks either. How about 'vetoNull' derived from the java.beans API. Not that it is a great name but, it is short, the meaning of veto in that context is used to deal with unacceptable values by throwing, and the beans API is already well established. Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.goetz at oracle.com Thu Jan 27 17:27:20 2011 From: brian.goetz at oracle.com (Brian Goetz) Date: Thu, 27 Jan 2011 12:27:20 -0500 Subject: 6407460: provide Collections helper methods for new interfaces in JDK 1.6 In-Reply-To: References: Message-ID: <4D41AAF8.2050301@oracle.com> Overall these look like good additions. I haven't reviewed the code in detail but a quick sanity check suggests that this is a good direction. There's definitely some more work needed on the testing (for example, testing that the contents of x and unmodifiable(x) are identical, testing that the unmodifiable collection reflects changes in the underlying mutable collection, testing the sortedSet/navigableSet methods for empty{Sorted,Navigable}Set, etc). As to the concurrent collection interfaces, I don't think they're strictly needed, but they do make sense. The methods added by ConcurrentMap over Map are all mutative, so immutableMap(concurrentMap) should produce the desired behavior but not necessarily the desired contract. On 1/16/2011 6:42 PM, David Schlosnagle wrote: > Hello core-lib-devs, > > The recent discussions around Objects.nonNull prompted me to create a > patch (attached) to add the methods below to java.util.Collections for > consistency with existing methods. According to the Annotated Outline > of Collections Framework [1] [2], the unmodifiable methods > for some of the newer Collection types (Queue, Deque, NavigableSet, > NavigableMap) seem to be missing, and the empty methods for > many new and old interfaces (SortedSet, NavigableSet, Queue, Deque, > SortedMap, NavigableMap) that would also be nice to have. > > In some of my projects, I could really benefit from having these > additional Collections.empty* and Collections.unmodifiable* helper > methods to simplify my code. In many cases these are places where > internally a null collection is used to allow for lazy initialization, > but the externally exposed APIs would always return an empty or > unmodifiable collection via a simple toUnmodifiable utility method > (where to include those in the JDK is probably a whole separate > argument). Previously the interfaces exposed in my APIs were often > List, Map, or Set, but more recently I've also been using SortedMap > and SortedSet where applicable, so I've felt a little pain for not > having all of the expected methods in Collections. There are of course > libraries such as Guava that also provide the majority of these (and > much more), but I think it would be nice to have this in the JDK. > > There seems to have been some discussion and bug IDs related to some > of these methods over the past few years [3] [4] [5] [6], but I'm > curious if this is something that would be considered for adding to > the Java API, and if so would it be for JDK 1.7 or 1.8 seeing as how > Mark indicated 1.7 was feature complete? I look forward to everyone's > feedback. > > + public static SortedSet emptySortedSet() > + public static NavigableSet emptyNavigableSet() > + public static Queue emptyQueue() > + public static Deque emptyDeque() > + public static SortedMap emptySortedMap() > + public static NavigableMap emptyNavigableMap() > + public static NavigableSet > unmodifiableNavigableSet(NavigableSet s) > + public static Iterator unmodifiableIterator(Iterator extends E> it) > + public static ListIterator > unmodifiableListIterator(ListIterator it) > + public static Queue unmodifiableQueue(Queue q) > + public static Deque unmodifiableDeque(Deque q) > + public static NavigableMap > unmodifiableNavigableMap(NavigableMap m) > > Here's a little summary of what versions of the JDK contain the > various empty and unmodifiable methods, and which are covered by this > patch: > > Interface empty* unmodifiable* > ---------------------- ------ ------------- > Collection n/a 1.2+ > Set 1.5+ 1.2+ > List 1.5+ 1.2+ > Queue patch patch > Deque patch patch > Map 1.5+ 1.2+ > SortedSet patch 1.2+ > SortedMap patch 1.2+ > NavigableSet patch patch > NavigableMap patch patch > BlockingQueue ? ? > TransferQueue ? ? > BlockingDeque ? ? > ConcurrentMap ? ? > ConcurrentNavigableMap ? ? > Iterator 1.7+ patch > ListIterator 1.7+ patch > > I've updated a few of the jtreg tests as initial sanity checks, but if > this patch were to be considered I'd want to expand those a bit more. > I haven't yet addressed the missing synchronized (Queue, > Deque, NavigableSet, NavigableMap), checked (Queue, Deque, > NavigableSet, NavigableMap), singleton (SortedSet, > NavigableSet, Queue, Deque, SortedMap, NavigableMap) methods. Also, I > haven't created analogous methods for any of the java.util.concurrent > interfaces as I'm not sure that these methods necessarily make sense > for those types. > > - Dave > > P.S. I submitted a signed OCA to sun_ca at sun.com earlier today, but I'm > assuming it will take a while to be added to > https://sca.dev.java.net/CA_signatories.htm since it is a holiday > weekend here in the USA. > > References: > [1]: http://download.oracle.com/javase/6/docs/technotes/guides/collections/reference.html > [2]: http://download.java.net/jdk7/docs/technotes/guides/collections/reference.html > [3]: 4834905: Support read-only Iterator, i.e., without remove(): > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4834905 > [4]: 5030930: JDK1.5 The method Collections.unmodifiableQueue(Queue extends T>) is missing: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5030930 > [5]: 6407460: (coll) provide Collections helper methods for new > interfaces in JDK 1.6: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6407460 > [6]: How about Collections.emptySorted[Set|Map] ?: > http://markmail.org/message/6u23eysno2mt6ia4 From forax at univ-mlv.fr Thu Jan 27 17:44:21 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Thu, 27 Jan 2011 18:44:21 +0100 Subject: 6407460: provide Collections helper methods for new interfaces in JDK 1.6 In-Reply-To: <4D41AAF8.2050301@oracle.com> References: <4D41AAF8.2050301@oracle.com> Message-ID: <4D41AEF5.3060200@univ-mlv.fr> Hi David, On 01/27/2011 06:27 PM, Brian Goetz wrote: > Overall these look like good additions. I haven't reviewed the code > in detail but a quick sanity check suggests that this is a good > direction. There's definitely some more work needed on the testing > (for example, testing that the contents of x and unmodifiable(x) are > identical, testing that the unmodifiable collection reflects changes > in the underlying mutable collection, testing the > sortedSet/navigableSet methods for empty{Sorted,Navigable}Set, etc). > > As to the concurrent collection interfaces, I don't think they're > strictly needed, but they do make sense. The methods added by > ConcurrentMap over Map are all mutative, so > immutableMap(concurrentMap) should produce the desired behavior but > not necessarily the desired contract. I think you can reduce the number of empty* methods given that Deque inherits form Queue and NavigableMap inherits from SortedMap. Also you forget some wildcards in unmodifiableDeque and unmodifiableNavigableMap. R?mi > > On 1/16/2011 6:42 PM, David Schlosnagle wrote: >> Hello core-lib-devs, >> >> The recent discussions around Objects.nonNull prompted me to create a >> patch (attached) to add the methods below to java.util.Collections for >> consistency with existing methods. According to the Annotated Outline >> of Collections Framework [1] [2], the unmodifiable methods >> for some of the newer Collection types (Queue, Deque, NavigableSet, >> NavigableMap) seem to be missing, and the empty methods for >> many new and old interfaces (SortedSet, NavigableSet, Queue, Deque, >> SortedMap, NavigableMap) that would also be nice to have. >> >> In some of my projects, I could really benefit from having these >> additional Collections.empty* and Collections.unmodifiable* helper >> methods to simplify my code. In many cases these are places where >> internally a null collection is used to allow for lazy initialization, >> but the externally exposed APIs would always return an empty or >> unmodifiable collection via a simple toUnmodifiable utility method >> (where to include those in the JDK is probably a whole separate >> argument). Previously the interfaces exposed in my APIs were often >> List, Map, or Set, but more recently I've also been using SortedMap >> and SortedSet where applicable, so I've felt a little pain for not >> having all of the expected methods in Collections. There are of course >> libraries such as Guava that also provide the majority of these (and >> much more), but I think it would be nice to have this in the JDK. >> >> There seems to have been some discussion and bug IDs related to some >> of these methods over the past few years [3] [4] [5] [6], but I'm >> curious if this is something that would be considered for adding to >> the Java API, and if so would it be for JDK 1.7 or 1.8 seeing as how >> Mark indicated 1.7 was feature complete? I look forward to everyone's >> feedback. >> >> + public static SortedSet emptySortedSet() >> + public static NavigableSet emptyNavigableSet() >> + public static Queue emptyQueue() >> + public static Deque emptyDeque() >> + public static SortedMap emptySortedMap() >> + public static NavigableMap emptyNavigableMap() >> + public static NavigableSet >> unmodifiableNavigableSet(NavigableSet s) >> + public static Iterator unmodifiableIterator(Iterator> extends E> it) >> + public static ListIterator >> unmodifiableListIterator(ListIterator it) >> + public static Queue unmodifiableQueue(Queue> E> q) >> + public static Deque unmodifiableDeque(Deque q) >> + public static NavigableMap >> unmodifiableNavigableMap(NavigableMap m) >> >> Here's a little summary of what versions of the JDK contain the >> various empty and unmodifiable methods, and which are covered by this >> patch: >> >> Interface empty* unmodifiable* >> ---------------------- ------ ------------- >> Collection n/a 1.2+ >> Set 1.5+ 1.2+ >> List 1.5+ 1.2+ >> Queue patch patch >> Deque patch patch >> Map 1.5+ 1.2+ >> SortedSet patch 1.2+ >> SortedMap patch 1.2+ >> NavigableSet patch patch >> NavigableMap patch patch >> BlockingQueue ? ? >> TransferQueue ? ? >> BlockingDeque ? ? >> ConcurrentMap ? ? >> ConcurrentNavigableMap ? ? >> Iterator 1.7+ patch >> ListIterator 1.7+ patch >> >> I've updated a few of the jtreg tests as initial sanity checks, but if >> this patch were to be considered I'd want to expand those a bit more. >> I haven't yet addressed the missing synchronized (Queue, >> Deque, NavigableSet, NavigableMap), checked (Queue, Deque, >> NavigableSet, NavigableMap), singleton (SortedSet, >> NavigableSet, Queue, Deque, SortedMap, NavigableMap) methods. Also, I >> haven't created analogous methods for any of the java.util.concurrent >> interfaces as I'm not sure that these methods necessarily make sense >> for those types. >> >> - Dave >> >> P.S. I submitted a signed OCA to sun_ca at sun.com earlier today, but I'm >> assuming it will take a while to be added to >> https://sca.dev.java.net/CA_signatories.htm since it is a holiday >> weekend here in the USA. >> >> References: >> [1]: >> http://download.oracle.com/javase/6/docs/technotes/guides/collections/reference.html >> [2]: >> http://download.java.net/jdk7/docs/technotes/guides/collections/reference.html >> [3]: 4834905: Support read-only Iterator, i.e., without remove(): >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4834905 >> [4]: 5030930: JDK1.5 The method Collections.unmodifiableQueue(Queue> extends T>) is missing: >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5030930 >> [5]: 6407460: (coll) provide Collections helper methods for new >> interfaces in JDK 1.6: >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6407460 >> [6]: How about Collections.emptySorted[Set|Map] ?: >> http://markmail.org/message/6u23eysno2mt6ia4 From David.Holmes at oracle.com Fri Jan 28 04:58:22 2011 From: David.Holmes at oracle.com (David Holmes) Date: Fri, 28 Jan 2011 14:58:22 +1000 Subject: Code review: 7012540 (java.util.Objects.nonNull() incorrectly named) In-Reply-To: <4D413037.5040801@univ-mlv.fr> References: <4D3F5DDB.7070209@oracle.com> <20110127050529.913241754@eggemoggin.niobe.net> <4D413037.5040801@univ-mlv.fr> Message-ID: <4D424CEE.1060409@oracle.com> R?mi Forax said the following on 01/27/11 18:43: > On 01/27/2011 09:38 AM, Stephen Colebourne wrote: >> As I said before, removing this method is the best option now. Get it >> right in v8. >> Stephen > > I think we can't. > This method is already used at many place in the JDK. I think we can. Those usages will have to be modified anyway. If it is really the wrong decision to add this now, and if we really can't get some consensus on the best name for the exception throwing method, then we should remove it. I'm not saying we're in that position, just that if we were there's no reason we could not undo this. I think the utility and significance of this method is vastly over-estimated, and certainly not worth the level of activity it has caused. David Holmes > About the name, I propose: > iUsedToUseGetClassHereButNodobyWasAbleToUnderstand() > > R?mi > >> >> On 27 January 2011 05:05, wrote: >>> Executive summary: requireNonNull is the preferred name. >>> >>>> Date: Tue, 25 Jan 2011 18:33:47 -0500 >>>> From: brian.goetz at oracle.com >>>> mark.reinhold at oracle.com wrote: >>>>> I think requireNonNull(x) is confusing. >>>> Remember there's two versions of someModifierNonNull being >>>> discussed; the one >>>> currently in Objects is the precondition-enforcing variety, not the >>>> postcondition-ensuring variety. Are we talking about the same thing? >>> Yes, i.e., the former. >>> >>>>> For those familiar with the "requires/ensures/modifies" triad of >>>>> verbs as >>>>> a compact way of identifying the preconditions, postconditions, and >>>>> side >>>>> effects of a method or procedure in a comment, a specification, or >>>>> a more >>>>> formal design-by-contract framework, "requires" is just wrong. >>>>> >>>>> When analyzing the invocation of foo in your example, the >>>>> non-nullity of >>>>> s and t are preconditions of foo and therefore postconditions of the >>>>> check method. Naming the check method "requireNonNull" suggests that >>>>> the check method itself has a precondition that its argument be >>>>> non-null, >>>>> when in fact it's the check method's postcondition which ensures that >>>>> property. >>>>> >>>>> Since postconditions are labeled "ensures" in the "r/e/m" triad, this >>>>> method should be named "ensureNonNull". >>>> Right, there's precedent for "ensureXxx" methods to actually change >>>> the state >>>> of things to ensure the postcondition, such as ensureCapacity() >>>> methods in the >>>> collection implementations. Given that a part of the motivation for >>>> this >>>> change was to leave room in the namespace for both the >>>> precondition-enforcing >>>> variety (barf on null) and the postcondition-ensuring variety, aka the >>>> carpet-sweeping variety ("if it is null, make it non-null") >>>> ensureNonNull >>>> sounds a lot more like the the carpet-sweeping version than the >>>> version being >>>> discussed (barf on null). >>> I was actually arguing that the barfing version should be named >>> ensureNonNull. >>> >>> (Wow, am I actually writing about barfing methods?) >>> >>>> The r/e/m framework seems to support require for the throwing >>>> version (as >>>> implemented by this patch): for the throwing version, non-nullity is a >>>> precondition of the check method (if the condition is not met, >>>> error), whereas >>>> for the carpet-sweeping version, it is a postcondition of the check >>>> method (if >>>> the check method can come up with a reasonable default value). (It >>>> happens to >>>> be a postcondition of both, but the significant behavior and use of the >>>> throwing version currently in Objects is to enforce an error when the >>>> precondition is not met.) Therefore: >>>> >>>> requireNonNull(x) -> throw if x == null >>>> ensureNonNull(x) -> convert x to a non-null value if null >>>> >>>> seems like the right taxonomy. >>> It depends on your perspective. >>> >>> In a nested method invocation, the postconditions of the inner method >>> must relate to the preconditions of the outer method. That is, for the >>> expression >>> >>> foo(bar(x)) >>> >>> to be correct then the postconditions of the bar method must imply the >>> preconditions of foo method. >>> >>> Now suppose that bar is intended to be the barf-on-null method. >>> >>> If we consider how to name bar on its own, outside of its intended usage >>> as in this example, then it's natural (for me, anyway) to conclude that >>> "ensuresNonNull" is the right name. What's important about bar is its >>> postcondition, namely that its return value (x) is not null. Naming it >>> "requireNonNull" seems backwards on this view, because "requires" is >>> always about preconditions, and it's definitely not a precondition of >>> this method that its argument not be null. >>> >>> If, by contrast, we consider how to name bar in the context of the above >>> example then it's easy to see that "requireNonNull" is the better name, >>> because what's important in the overall expression is satisfying foo's >>> precondition that its argument not be null, and so >>> >>> foo(requireNonNull(x)) >>> >>> reads very fluently. >>> >>> A little utility method like this will never (well, hardly ever) be used >>> in isolation, so I agree now that it makes sense to prefer the second >>> form, i.e., requireNonNull. >>> >>> I'm not sure I agree that the corresponding carpet-sweeping method is >>> best named ensureNonNull; treating that as a conversion, i.e., >>> asNonNull, >>> may be a better choice. That, however, is a discussion for another >>> release. >>> >>> - Mark >>> > From lvjing at linux.vnet.ibm.com Fri Jan 28 05:25:41 2011 From: lvjing at linux.vnet.ibm.com (Jing LV) Date: Fri, 28 Jan 2011 13:25:41 +0800 Subject: BufferedWriter.write does not throw exception if it is already closed. In-Reply-To: <4D3EF7F8.70407@oracle.com> References: <4D3EE20F.5040108@linux.vnet.ibm.com> <4D3EF7F8.70407@oracle.com> Message-ID: <4D425355.2070409@linux.vnet.ibm.com> ? 2011-1-26 0:19, Alan Bateman ??: > Jing LV wrote: >> Hello, >> >> I find a problem in java.io.BufferedWriter. It is stated in the java >> spec of its close() method: >> "... Once the stream has been closed, further write() or flush() >> invocations will cause an IOException to be thrown." >> However if a BufferedWriter is created with a delegated writer, then it >> seems to "forget" to throw IOException when it's closed, even if the >> delegated writer wants to. Here is a simple example: > It's possible we have a spec issue in that BufferedWriter (and others) > don't specify what their state is in event that flushing or closing > the underlying Writer fails (the test is assuming that it is closed > even though the close method failed). > > -Alan. Hi Alan, (Sorry for late reply that it seems my mail-box has some trouble that I cannot send my mail yesterday). I agreed with you that the document may be changed. However as you see another problem is that the write method is unstable, it may or may not throw the exception, only depends on its buffer size, I think we'd better at least fix this unpredictable behaviour? From schlosna at gmail.com Fri Jan 28 06:07:39 2011 From: schlosna at gmail.com (David Schlosnagle) Date: Fri, 28 Jan 2011 01:07:39 -0500 Subject: 6407460: provide Collections helper methods for new interfaces in JDK 1.6 In-Reply-To: <4D41AEF5.3060200@univ-mlv.fr> References: <4D41AAF8.2050301@oracle.com> <4D41AEF5.3060200@univ-mlv.fr> Message-ID: Thanks for the feedback Brian and R?mi. I'm assuming this would go into JDK 8 at the earliest, so there seems to be some time to build out the test cases and other related missing methods. Are JUnit tests acceptable (I see only a couple in jdk/test/java/dyn/) or would you prefer the standalone tests that seem to be the majority? As I was incorporating some of the comments tonight, I noticed a possible improvement to Collections.UnmodifiableList#subList to handle cases where the underlying List's subList method returns a proper RandomAccess List implementation and by using the unmodifiableList method to wrap it appropriately. Similar changes could be made for SynchronizedList and CheckedList. Should this be handled as a separate bug? public List subList(int fromIndex, int toIndex) { - return new UnmodifiableList(list.subList(fromIndex, toIndex)); + return unmodifiableList(list.subList(fromIndex, toIndex)); } On another note, does anyone know what the typical turnaround time is from submitting a signed SCA/OCA to being listed on https://sca.dev.java.net/CA_signatories.htm? I see the list was last updated on 2011/01/18, but the SCA java.net project now seems to be locked in preparation for migrating to the new java.net system. Thanks, Dave On Thu, Jan 27, 2011 at 12:44 PM, R?mi Forax wrote: > On 01/27/2011 06:27 PM, Brian Goetz wrote: >> >> Overall these look like good additions. ?I haven't reviewed the code in >> detail but a quick sanity check suggests that this is a good direction. >> ?There's definitely some more work needed on the testing (for example, >> testing that the contents of x and unmodifiable(x) are identical, testing >> that the unmodifiable collection reflects changes in the underlying mutable >> collection, testing the sortedSet/navigableSet methods for >> empty{Sorted,Navigable}Set, etc). >> >> As to the concurrent collection interfaces, I don't think they're strictly >> needed, but they do make sense. ?The methods added by ConcurrentMap over Map >> are all mutative, so immutableMap(concurrentMap) should produce the desired >> behavior but not necessarily the desired contract. > > I think you can reduce the number of empty* methods given that > Deque inherits form Queue and NavigableMap inherits from SortedMap. > > Also you forget some wildcards in unmodifiableDeque and > unmodifiableNavigableMap. From jim.holmlund at sun.com Fri Jan 28 08:10:52 2011 From: jim.holmlund at sun.com (jim.holmlund at sun.com) Date: Fri, 28 Jan 2011 08:10:52 +0000 Subject: hg: jdk7/tl/langtools: 7015482: jtreg test tools/javac/diags/MessageInfo.java fails when test/ dir is not in langtools repo Message-ID: <20110128081054.75DCA47210@hg.openjdk.java.net> Changeset: 92ab09ed59fd Author: jjh Date: 2011-01-28 00:09 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/92ab09ed59fd 7015482: jtreg test tools/javac/diags/MessageInfo.java fails when test/ dir is not in langtools repo Summary: Don't fail if the needed file isn't present, if running under jtreg. Reviewed-by: jjg ! test/tools/javac/diags/MessageInfo.java From Alan.Bateman at oracle.com Fri Jan 28 09:57:31 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 28 Jan 2011 09:57:31 +0000 Subject: Dual-Pivot Quicksort improvements for highly structured (nearly sorted) arrays and data with small periods In-Reply-To: References: Message-ID: <4D42930B.7030600@oracle.com> Does anyone have this on their radar to review? If not, I'll put it on my list. -Alan. Vladimir Iaroslavski wrote: > Hello, > > Here is improvement for sorting primitives: > http://cr.openjdk.java.net/~alanb/7013585/webrev > > Highly structured (nearly sorted) data like > 1,2,3,..,k,1,2,3,..,k,... or > 1,2,3,...,n/2,n/2,...,3,2,1 etc. > is sorted very effectively by merge sort. > > The main idea of this optimization is to check > if given array is nearly sorted and apply modified > and improved merge sort on it. Otherwise, Dual-Pivot > Quicksort is applied. > > Note that the check doesn't decrease the performance of sorting. > > Other optimization is related to random or repeated data > with small period, m <= 10. This type of data is sorted > faster by Quicksort with one pivot but with DNF (Dutch > National Flag) partition. Therefore, sorting is switched > to DNF even calculated pivots are different. > > The boost of performance with new optimizations is: > > random data: new: 135, old: 154, ratio: 87.6% > ascending: new: 3, old: 45, ratio: 6.6% > descending: new: 5, old: 48, ratio: 10.4% > organ pipes: new: 20, old: 80, ratio: 25% > period(m), m <= 10: new: 10, old: 15, ratio: 66.6% > random(m), m <= 10: new: 11, old: 16, ratio: 68.7% > equal: new: 2.5, old: 3, new: 83.3% > > On test suite suggested by Jon Bentley we see > the following performance: > > client VM: old 56%, new 43% > server VM: old 46%, new 29% > > Thank you, > Vladimir > From Alan.Bateman at oracle.com Fri Jan 28 10:55:05 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 28 Jan 2011 10:55:05 +0000 Subject: BufferedWriter.write does not throw exception if it is already closed. In-Reply-To: <4D425355.2070409@linux.vnet.ibm.com> References: <4D3EE20F.5040108@linux.vnet.ibm.com> <4D3EF7F8.70407@oracle.com> <4D425355.2070409@linux.vnet.ibm.com> Message-ID: <4D42A089.7010007@oracle.com> Jing LV wrote: > Hi Alan, > > (Sorry for late reply that it seems my mail-box has some trouble that > I cannot send my mail yesterday). I agreed with you that the document > may be changed. However as you see another problem is that the write > method is unstable, it may or may not throw the exception, only > depends on its buffer size, I think we'd better at least fix this > unpredictable behaviour? > I think this is part of the same issue. BufferedWriter#close is failing because the underlying Writer's close is failing. This leaves the BufferedWriter "open" and the underlying Writer "closed". If you continue writing then the BufferedWriter may continue to buffer characters but if it has to flush to the underlying Writer then it will fail. This is clearly undesirable and it may be best to clarify the spec so that stream will be considered to be closed even if the close fails (as the current behavior is long standing behavior we would just need to think through any implications/side-effects). We can easily the implementation too, and in addition the suppressed exception support gives us the opportunity to fix a few other issues in these classes. I'll create a bug for this today. -Alan. From maurizio.cimadamore at oracle.com Fri Jan 28 12:19:17 2011 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Fri, 28 Jan 2011 12:19:17 +0000 Subject: hg: jdk7/tl/langtools: 3 new changesets Message-ID: <20110128121926.12B594721C@hg.openjdk.java.net> Changeset: 2088e674f0e0 Author: mcimadamore Date: 2011-01-28 12:01 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/2088e674f0e0 6910550: javac 1.5.0_17 fails with incorrect error message Summary: multiple clashing members declared in same class should be added to the class' scope in order to avoid downstream spurious diagnostics Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Flags.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java + test/tools/javac/generics/6910550/T6910550a.java + test/tools/javac/generics/6910550/T6910550a.out + test/tools/javac/generics/6910550/T6910550b.java + test/tools/javac/generics/6910550/T6910550b.out + test/tools/javac/generics/6910550/T6910550c.java + test/tools/javac/generics/6910550/T6910550c.out + test/tools/javac/generics/6910550/T6910550d.java + test/tools/javac/generics/6910550/T6910550d.out + test/tools/javac/generics/6910550/T6910550e.java + test/tools/javac/generics/6910550/T6910550e.out Changeset: 5a43b245aed1 Author: mcimadamore Date: 2011-01-28 12:03 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/5a43b245aed1 6313164: javac generates code that fails byte code verification for the varargs feature Summary: method applicability check should fail if formal varargs element type is not accessible Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/Infer.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! test/tools/javac/diags/examples.not-yet.txt + test/tools/javac/diags/examples/InaccessibleVarargsType/InaccessibleVarargsType.java + test/tools/javac/diags/examples/InaccessibleVarargsType/p1/A.java + test/tools/javac/diags/examples/InaccessibleVarargsType/p1/B.java ! test/tools/javac/generics/inference/6638712/T6638712c.out ! test/tools/javac/generics/inference/6638712/T6638712d.out + test/tools/javac/varargs/6313164/T6313164.java + test/tools/javac/varargs/6313164/T6313164.out + test/tools/javac/varargs/6313164/p1/A.java + test/tools/javac/varargs/6313164/p1/B.java + test/tools/javac/varargs/6313164/p1/C.java Changeset: 17bafae67e9d Author: mcimadamore Date: 2011-01-28 12:06 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/17bafae67e9d 6838943: inference: javac is not handling type-variable substitution properly Summary: free type-variables are being replaced with type-variables bound to forall type leading to unsoundness Reviewed-by: jjg, dlsmith ! src/share/classes/com/sun/tools/javac/code/Types.java + test/tools/javac/generics/inference/6838943/T6838943.java + test/tools/javac/generics/inference/6838943/T6838943.out From alan.bateman at oracle.com Fri Jan 28 12:28:58 2011 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Fri, 28 Jan 2011 12:28:58 +0000 Subject: hg: jdk7/tl/jdk: 2 new changesets Message-ID: <20110128122932.A2C7F4721E@hg.openjdk.java.net> Changeset: 236e3f2d0a6b Author: alanb Date: 2011-01-28 09:28 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/236e3f2d0a6b 7006126: (fs) Updates to file system API (1/2011) Reviewed-by: chegar, sherman ! make/java/java/FILES_java.gmk ! make/java/nio/FILES_java.gmk ! make/mkdemo/Makefile ! src/share/classes/java/io/BufferedReader.java ! src/share/classes/java/io/BufferedWriter.java ! src/share/classes/java/io/File.java ! src/share/classes/java/io/FileInputStream.java ! src/share/classes/java/io/FileOutputStream.java ! src/share/classes/java/io/FilePermission.java ! src/share/classes/java/io/SerialCallbackContext.java - src/share/classes/java/io/TempFileHelper.java ! src/share/classes/java/nio/channels/FileChannel.java ! src/share/classes/java/nio/channels/SeekableByteChannel.java ! src/share/classes/java/nio/file/AccessMode.java + src/share/classes/java/nio/file/CopyMoveHelper.java ! src/share/classes/java/nio/file/CopyOption.java ! src/share/classes/java/nio/file/DirectoryStream.java - src/share/classes/java/nio/file/FileRef.java ! src/share/classes/java/nio/file/FileStore.java ! src/share/classes/java/nio/file/FileSystem.java ! src/share/classes/java/nio/file/FileSystems.java ! src/share/classes/java/nio/file/FileTreeWalker.java ! src/share/classes/java/nio/file/FileVisitor.java ! src/share/classes/java/nio/file/Files.java ! src/share/classes/java/nio/file/LinkOption.java ! src/share/classes/java/nio/file/LinkPermission.java ! src/share/classes/java/nio/file/OpenOption.java ! src/share/classes/java/nio/file/Path.java ! src/share/classes/java/nio/file/PathMatcher.java ! src/share/classes/java/nio/file/Paths.java ! src/share/classes/java/nio/file/SecureDirectoryStream.java + src/share/classes/java/nio/file/TempFileHelper.java ! src/share/classes/java/nio/file/WatchEvent.java ! src/share/classes/java/nio/file/WatchKey.java ! src/share/classes/java/nio/file/WatchService.java ! src/share/classes/java/nio/file/attribute/AclEntry.java ! src/share/classes/java/nio/file/attribute/AclFileAttributeView.java - src/share/classes/java/nio/file/attribute/Attributes.java ! src/share/classes/java/nio/file/attribute/BasicFileAttributeView.java ! src/share/classes/java/nio/file/attribute/BasicFileAttributes.java ! src/share/classes/java/nio/file/attribute/DosFileAttributeView.java ! src/share/classes/java/nio/file/attribute/DosFileAttributes.java ! src/share/classes/java/nio/file/attribute/FileAttribute.java ! src/share/classes/java/nio/file/attribute/FileAttributeView.java ! src/share/classes/java/nio/file/attribute/FileOwnerAttributeView.java - src/share/classes/java/nio/file/attribute/FileStoreSpaceAttributeView.java - src/share/classes/java/nio/file/attribute/FileStoreSpaceAttributes.java ! src/share/classes/java/nio/file/attribute/FileTime.java ! src/share/classes/java/nio/file/attribute/PosixFileAttributeView.java ! src/share/classes/java/nio/file/attribute/PosixFileAttributes.java ! src/share/classes/java/nio/file/attribute/PosixFilePermission.java ! src/share/classes/java/nio/file/attribute/PosixFilePermissions.java ! src/share/classes/java/nio/file/attribute/UserDefinedFileAttributeView.java ! src/share/classes/java/nio/file/attribute/package-info.java ! src/share/classes/java/nio/file/package-info.java ! src/share/classes/java/nio/file/spi/FileSystemProvider.java ! src/share/classes/java/nio/file/spi/FileTypeDetector.java ! src/share/classes/java/util/Scanner.java ! src/share/classes/sun/nio/fs/AbstractAclFileAttributeView.java ! src/share/classes/sun/nio/fs/AbstractBasicFileAttributeView.java + src/share/classes/sun/nio/fs/AbstractFileSystemProvider.java ! src/share/classes/sun/nio/fs/AbstractFileTypeDetector.java ! src/share/classes/sun/nio/fs/AbstractPath.java ! src/share/classes/sun/nio/fs/AbstractPoller.java ! src/share/classes/sun/nio/fs/AbstractUserDefinedFileAttributeView.java ! src/share/classes/sun/nio/fs/AbstractWatchKey.java ! src/share/classes/sun/nio/fs/AbstractWatchService.java ! src/share/classes/sun/nio/fs/DynamicFileAttributeView.java ! src/share/classes/sun/nio/fs/FileOwnerAttributeViewImpl.java ! src/share/classes/sun/nio/fs/PollingWatchService.java ! src/share/classes/sun/security/provider/SeedGenerator.java ! src/share/classes/sun/tools/jar/Main.java ! src/share/sample/nio/file/AclEdit.java ! src/share/sample/nio/file/Chmod.java ! src/share/sample/nio/file/Copy.java ! src/share/sample/nio/file/DiskUsage.java ! src/share/sample/nio/file/FileType.java ! src/share/sample/nio/file/WatchDir.java ! src/share/sample/nio/file/Xdd.java ! src/solaris/classes/sun/nio/fs/GnomeFileTypeDetector.java ! src/solaris/classes/sun/nio/fs/LinuxDosFileAttributeView.java ! src/solaris/classes/sun/nio/fs/LinuxFileSystem.java ! src/solaris/classes/sun/nio/fs/LinuxFileSystemProvider.java ! src/solaris/classes/sun/nio/fs/LinuxUserDefinedFileAttributeView.java ! src/solaris/classes/sun/nio/fs/LinuxWatchService.java ! src/solaris/classes/sun/nio/fs/SolarisAclFileAttributeView.java ! src/solaris/classes/sun/nio/fs/SolarisFileSystem.java ! src/solaris/classes/sun/nio/fs/SolarisFileSystemProvider.java ! src/solaris/classes/sun/nio/fs/SolarisUserDefinedFileAttributeView.java ! src/solaris/classes/sun/nio/fs/SolarisWatchService.java ! src/solaris/classes/sun/nio/fs/UnixCopyFile.java ! src/solaris/classes/sun/nio/fs/UnixFileAttributeViews.java ! src/solaris/classes/sun/nio/fs/UnixFileAttributes.java ! src/solaris/classes/sun/nio/fs/UnixFileStore.java ! src/solaris/classes/sun/nio/fs/UnixFileSystem.java ! src/solaris/classes/sun/nio/fs/UnixFileSystemProvider.java ! src/solaris/classes/sun/nio/fs/UnixPath.java ! src/solaris/classes/sun/nio/fs/UnixSecureDirectoryStream.java ! src/windows/classes/sun/nio/fs/RegistryFileTypeDetector.java ! src/windows/classes/sun/nio/fs/WindowsFileAttributeViews.java ! src/windows/classes/sun/nio/fs/WindowsFileCopy.java ! src/windows/classes/sun/nio/fs/WindowsFileStore.java ! src/windows/classes/sun/nio/fs/WindowsFileSystem.java ! src/windows/classes/sun/nio/fs/WindowsFileSystemProvider.java ! src/windows/classes/sun/nio/fs/WindowsPath.java ! src/windows/classes/sun/nio/fs/WindowsPathParser.java ! src/windows/classes/sun/nio/fs/WindowsSecurityDescriptor.java ! src/windows/classes/sun/nio/fs/WindowsUserDefinedFileAttributeView.java ! src/windows/classes/sun/nio/fs/WindowsWatchService.java ! test/demo/zipfs/basic.sh ! test/java/io/File/IsHidden.java ! test/java/io/File/SetAccess.java ! test/java/io/File/SymLinks.java ! test/java/io/FileInputStream/LargeFileAvailable.java ! test/java/nio/channels/FileChannel/AtomicAppend.java ! test/java/nio/channels/FileChannel/Transfer.java ! test/java/nio/file/DirectoryStream/Basic.java ! test/java/nio/file/DirectoryStream/DriveLetter.java ! test/java/nio/file/DirectoryStream/SecureDS.java ! test/java/nio/file/FileStore/Basic.java + test/java/nio/file/Files/BytesAndLines.java + test/java/nio/file/Files/CheckPermissions.java - test/java/nio/file/Files/ContentType.java + test/java/nio/file/Files/CopyAndMove.java - test/java/nio/file/Files/CreateFileTree.java + test/java/nio/file/Files/DeleteOnClose.java + test/java/nio/file/Files/FileAttributes.java - test/java/nio/file/Files/ForceLoad.java + test/java/nio/file/Files/InterruptCopy.java + test/java/nio/file/Files/Links.java - test/java/nio/file/Files/META-INF/services/java.nio.file.spi.FileTypeDetector - test/java/nio/file/Files/MaxDepth.java ! test/java/nio/file/Files/Misc.java + test/java/nio/file/Files/PassThroughFileSystem.java - test/java/nio/file/Files/PrintFileTree.java + test/java/nio/file/Files/SBC.java - test/java/nio/file/Files/SimpleFileTypeDetector.java - test/java/nio/file/Files/SkipSiblings.java + test/java/nio/file/Files/TemporaryFiles.java - test/java/nio/file/Files/TerminateWalk.java - test/java/nio/file/Files/WalkWithSecurity.java + test/java/nio/file/Files/delete_on_close.sh - test/java/nio/file/Files/denyAll.policy - test/java/nio/file/Files/grantAll.policy - test/java/nio/file/Files/grantTopOnly.policy + test/java/nio/file/Files/probeContentType/Basic.java + test/java/nio/file/Files/probeContentType/ForceLoad.java + test/java/nio/file/Files/probeContentType/META-INF/services/java.nio.file.spi.FileTypeDetector + test/java/nio/file/Files/probeContentType/SimpleFileTypeDetector.java + test/java/nio/file/Files/walkFileTree/CreateFileTree.java + test/java/nio/file/Files/walkFileTree/MaxDepth.java + test/java/nio/file/Files/walkFileTree/Nulls.java + test/java/nio/file/Files/walkFileTree/PrintFileTree.java + test/java/nio/file/Files/walkFileTree/SkipSiblings.java + test/java/nio/file/Files/walkFileTree/TerminateWalk.java + test/java/nio/file/Files/walkFileTree/WalkWithSecurity.java + test/java/nio/file/Files/walkFileTree/denyAll.policy + test/java/nio/file/Files/walkFileTree/grantAll.policy + test/java/nio/file/Files/walkFileTree/grantTopOnly.policy + test/java/nio/file/Files/walkFileTree/walk_file_tree.sh - test/java/nio/file/Files/walk_file_tree.sh - test/java/nio/file/Path/CheckPermissions.java - test/java/nio/file/Path/CopyAndMove.java - test/java/nio/file/Path/DeleteOnClose.java - test/java/nio/file/Path/FileAttributes.java - test/java/nio/file/Path/InterruptCopy.java - test/java/nio/file/Path/Links.java ! test/java/nio/file/Path/Misc.java - test/java/nio/file/Path/PassThroughFileSystem.java ! test/java/nio/file/Path/PathOps.java - test/java/nio/file/Path/SBC.java - test/java/nio/file/Path/TemporaryFiles.java - test/java/nio/file/Path/delete_on_close.sh ! test/java/nio/file/TestUtil.java ! test/java/nio/file/WatchService/Basic.java ! test/java/nio/file/WatchService/FileTreeModifier.java ! test/java/nio/file/WatchService/LotsOfEvents.java ! test/java/nio/file/WatchService/SensitivityModifier.java ! test/java/nio/file/attribute/AclFileAttributeView/Basic.java ! test/java/nio/file/attribute/BasicFileAttributeView/Basic.java ! test/java/nio/file/attribute/DosFileAttributeView/Basic.java - test/java/nio/file/attribute/FileStoreAttributeView/Basic.java ! test/java/nio/file/attribute/FileTime/Basic.java ! test/java/nio/file/attribute/PosixFileAttributeView/Basic.java ! test/java/nio/file/attribute/UserDefinedFileAttributeView/Basic.java ! test/java/nio/file/spi/SetDefaultProvider.java ! test/java/nio/file/spi/TestProvider.java Changeset: 60d347deb54d Author: alanb Date: 2011-01-28 09:31 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/60d347deb54d Merge - src/share/classes/java/io/TempFileHelper.java - src/share/classes/java/nio/file/FileRef.java - src/share/classes/java/nio/file/attribute/Attributes.java - src/share/classes/java/nio/file/attribute/FileStoreSpaceAttributeView.java - src/share/classes/java/nio/file/attribute/FileStoreSpaceAttributes.java ! test/demo/zipfs/basic.sh - test/java/nio/file/Files/ContentType.java - test/java/nio/file/Files/CreateFileTree.java - test/java/nio/file/Files/ForceLoad.java - test/java/nio/file/Files/META-INF/services/java.nio.file.spi.FileTypeDetector - test/java/nio/file/Files/MaxDepth.java - test/java/nio/file/Files/PrintFileTree.java - test/java/nio/file/Files/SimpleFileTypeDetector.java - test/java/nio/file/Files/SkipSiblings.java - test/java/nio/file/Files/TerminateWalk.java - test/java/nio/file/Files/WalkWithSecurity.java - test/java/nio/file/Files/denyAll.policy - test/java/nio/file/Files/grantAll.policy - test/java/nio/file/Files/grantTopOnly.policy - test/java/nio/file/Files/walk_file_tree.sh - test/java/nio/file/Path/CheckPermissions.java - test/java/nio/file/Path/CopyAndMove.java - test/java/nio/file/Path/DeleteOnClose.java - test/java/nio/file/Path/FileAttributes.java - test/java/nio/file/Path/InterruptCopy.java - test/java/nio/file/Path/Links.java - test/java/nio/file/Path/PassThroughFileSystem.java - test/java/nio/file/Path/SBC.java - test/java/nio/file/Path/TemporaryFiles.java - test/java/nio/file/Path/delete_on_close.sh - test/java/nio/file/attribute/FileStoreAttributeView/Basic.java From alan.bateman at oracle.com Fri Jan 28 12:38:03 2011 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Fri, 28 Jan 2011 12:38:03 +0000 Subject: hg: jdk7/tl/langtools: 2 new changesets Message-ID: <20110128123809.712844721F@hg.openjdk.java.net> Changeset: babf86a1ac92 Author: alanb Date: 2011-01-28 09:25 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/babf86a1ac92 7006126: (fs) Updates to file system API (1/2011) Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/nio/JavacPathFileManager.java ! src/share/classes/com/sun/tools/javac/nio/PathFileObject.java ! test/tools/javac/nio/compileTest/CompileTest.java Changeset: df3394337b04 Author: alanb Date: 2011-01-28 12:36 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/df3394337b04 Merge From Ulf.Zibis at gmx.de Fri Jan 28 13:40:56 2011 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Fri, 28 Jan 2011 14:40:56 +0100 Subject: Code review: 7012540 (java.util.Objects.nonNull() incorrectly named) In-Reply-To: <4D424CEE.1060409@oracle.com> References: <4D3F5DDB.7070209@oracle.com> <20110127050529.913241754@eggemoggin.niobe.net> <4D413037.5040801@univ-mlv.fr> <4D424CEE.1060409@oracle.com> Message-ID: <4D42C768.2010608@gmx.de> Am 28.01.2011 05:58, schrieb David Holmes: > R?mi Forax said the following on 01/27/11 18:43: >> On 01/27/2011 09:38 AM, Stephen Colebourne wrote: >>> As I said before, removing this method is the best option now. Get it >>> right in v8. >>> Stephen >> >> I think we can't. >> This method is already used at many place in the JDK. > > I think we can. Those usages will have to be modified anyway. If it is really the wrong decision > to add this now, and if we really can't get some consensus on the best name for the exception > throwing method, then we should remove it. > > I'm not saying we're in that position, just that if we were there's no reason we could not undo this. > > I think the utility and significance of this method is vastly over-estimated, and certainly not > worth the level of activity it has caused. > +1 If I understand right, please correct me, the motivation of this method was to force a better exception with shorter stacktrace in fail case, for easier to find the error's reason. So this method is a kind of debug helper, which in real world doesn't help the program flow. but returns better error messages for support. In any case the software should be revised, so that the not-allowed nullity of an argument (1) can't occur or (2) invokes a well defined handling instead throwing a meaningless RuntimeException. Can I see an example, where "assert x != null" wont help? IMHO, we better introduce a debug helper class, which could contain things like "assertNotNull(x)". Another idea is a language change: Make "assert" to return the LHS argument. -Ulf From alan.bateman at oracle.com Fri Jan 28 13:26:57 2011 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Fri, 28 Jan 2011 13:26:57 +0000 Subject: hg: jdk7/tl/jdk: 7015410: test/java/net/Socks/SocksProxyVersion.java needs to be updated due to 7013420 Message-ID: <20110128132714.47E3B47223@hg.openjdk.java.net> Changeset: dea360853f8b Author: alanb Date: 2011-01-28 13:26 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/dea360853f8b 7015410: test/java/net/Socks/SocksProxyVersion.java needs to be updated due to 7013420 Reviewed-by: chegar ! test/java/net/Socks/SocksProxyVersion.java From david.lloyd at redhat.com Fri Jan 28 14:47:34 2011 From: david.lloyd at redhat.com (David M. Lloyd) Date: Fri, 28 Jan 2011 08:47:34 -0600 Subject: Code review: 7012540 (java.util.Objects.nonNull() incorrectly named) In-Reply-To: <4D424CEE.1060409@oracle.com> References: <4D3F5DDB.7070209@oracle.com> <20110127050529.913241754@eggemoggin.niobe.net> <4D413037.5040801@univ-mlv.fr> <4D424CEE.1060409@oracle.com> Message-ID: <4D42D706.8040909@redhat.com> On 01/27/2011 10:58 PM, David Holmes wrote: > R?mi Forax said the following on 01/27/11 18:43: >> On 01/27/2011 09:38 AM, Stephen Colebourne wrote: >>> As I said before, removing this method is the best option now. Get it >>> right in v8. >>> Stephen >> >> I think we can't. >> This method is already used at many place in the JDK. > > I think we can. Those usages will have to be modified anyway. If it is > really the wrong decision to add this now, and if we really can't get > some consensus on the best name for the exception throwing method, then > we should remove it. > > I'm not saying we're in that position, just that if we were there's no > reason we could not undo this. > > I think the utility and significance of this method is vastly > over-estimated, and certainly not worth the level of activity it has > caused. Everyone likes a good bike-shed-painting session. -- - DML From lvjing at linux.vnet.ibm.com Fri Jan 28 14:50:51 2011 From: lvjing at linux.vnet.ibm.com (Jing LV) Date: Fri, 28 Jan 2011 22:50:51 +0800 Subject: BufferedWriter.write does not throw exception if it is already closed. In-Reply-To: <4D42A089.7010007@oracle.com> References: <4D3EE20F.5040108@linux.vnet.ibm.com> <4D3EF7F8.70407@oracle.com> <4D425355.2070409@linux.vnet.ibm.com> <4D42A089.7010007@oracle.com> Message-ID: <4D42D7CB.8050006@linux.vnet.ibm.com> Thanks for reply Alan, sorry didn't see this mail before I raise an issue on https://bugs.openjdk.java.net/show_bug.cgi?id=100169 (my mail server seems some problem these days) Consider it is using underlying writer, one thing I need to mention is that in the testcase I post in the first mail, it was trying to throw an exception[1] in its write method when it's closed already. I am ok with the documentation modification myself, however I wonder it may confuse customer if he found his own writer has no problem at all? [1] @Override public void write(char[] buf, int offset, int count) throws IOException { if (closed) { throw new IOException("Already closed"); } } ? 2011-1-28 18:55, Alan Bateman ??: > Jing LV wrote: >> Hi Alan, >> >> (Sorry for late reply that it seems my mail-box has some trouble that >> I cannot send my mail yesterday). I agreed with you that the document >> may be changed. However as you see another problem is that the write >> method is unstable, it may or may not throw the exception, only >> depends on its buffer size, I think we'd better at least fix this >> unpredictable behaviour? >> > I think this is part of the same issue. BufferedWriter#close is > failing because the underlying Writer's close is failing. This leaves > the BufferedWriter "open" and the underlying Writer "closed". If you > continue writing then the BufferedWriter may continue to buffer > characters but if it has to flush to the underlying Writer then it > will fail. This is clearly undesirable and it may be best to clarify > the spec so that stream will be considered to be closed even if the > close fails (as the current behavior is long standing behavior we > would just need to think through any implications/side-effects). We > can easily the implementation too, and in addition the suppressed > exception support gives us the opportunity to fix a few other issues > in these classes. I'll create a bug for this today. > > -Alan. From Alan.Bateman at oracle.com Fri Jan 28 15:44:06 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 28 Jan 2011 15:44:06 +0000 Subject: BufferedWriter.write does not throw exception if it is already closed. In-Reply-To: <4D42D7CB.8050006@linux.vnet.ibm.com> References: <4D3EE20F.5040108@linux.vnet.ibm.com> <4D3EF7F8.70407@oracle.com> <4D425355.2070409@linux.vnet.ibm.com> <4D42A089.7010007@oracle.com> <4D42D7CB.8050006@linux.vnet.ibm.com> Message-ID: <4D42E446.8000909@oracle.com> Jing LV wrote: > Thanks for reply Alan, sorry didn't see this mail before I raise an > issue on https://bugs.openjdk.java.net/show_bug.cgi?id=100169 (my mail > server seems some problem these days) > > Consider it is using underlying writer, one thing I need to mention is > that in the testcase I post in the first mail, it was trying to throw > an exception[1] in its write method when it's closed already. I am ok > with the documentation modification myself, however I wonder it may > confuse customer if he found his own writer has no problem at all? > > [1] > @Override > public void write(char[] buf, int offset, int count) throws > IOException { > if (closed) { > throw new IOException("Already closed"); > } > } I'll add S=7015589 to that bugzilla bug so that it links to the links to the "Sun" bug that I created after the previous mail. I don't think I fully understand what you are saying in the above but let me just repeat that I think we should look at clarifying close so that the BufferedWriter is considered closed even if the close method fails with an IOException. That would mean that a subsequence attempt to write to the closed stream (irrespective of whether close completed with or without an exception) would fail consistently rather than being dependent on the buffer size. See attached as an initial patch to see how it would work. I was just mentioning that we can fix a few other issues while we are there - for example the exception from the underlying writer's close supplants the exception from the flush. -Alan diff --git a/src/share/classes/java/io/BufferedReader.java b/src/share/classes/java/io/BufferedReader.java --- a/src/share/classes/java/io/BufferedReader.java +++ b/src/share/classes/java/io/BufferedReader.java @@ -514,9 +514,12 @@ public class BufferedReader extends Read synchronized (lock) { if (in == null) return; - in.close(); - in = null; - cb = null; + try { + in.close(); + } finally { + in = null; + cb = null; + } } } } diff --git a/src/share/classes/java/io/BufferedWriter.java b/src/share/classes/java/io/BufferedWriter.java --- a/src/share/classes/java/io/BufferedWriter.java +++ b/src/share/classes/java/io/BufferedWriter.java @@ -260,10 +260,9 @@ public class BufferedWriter extends Writ if (out == null) { return; } - try { + try (Writer w = out) { flushBuffer(); } finally { - out.close(); out = null; cb = null; } diff --git a/src/share/classes/java/io/FilterOutputStream.java b/src/share/classes/java/io/FilterOutputStream.java --- a/src/share/classes/java/io/FilterOutputStream.java +++ b/src/share/classes/java/io/FilterOutputStream.java @@ -153,10 +153,8 @@ class FilterOutputStream extends OutputS * @see java.io.FilterOutputStream#out */ public void close() throws IOException { - try { - flush(); - } catch (IOException ignored) { + try (OutputStream ostream = out) { + flush(); } - out.close(); } } From joe.darcy at oracle.com Sat Jan 29 00:54:39 2011 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Sat, 29 Jan 2011 00:54:39 +0000 Subject: hg: jdk7/tl/langtools: 7015530: Reiterate API specializations in javax.lang.model.elment subinterfaces Message-ID: <20110129005443.4B84347245@hg.openjdk.java.net> Changeset: 7a75a1803c7a Author: darcy Date: 2011-01-28 16:54 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/7a75a1803c7a 7015530: Reiterate API specializations in javax.lang.model.elment subinterfaces Reviewed-by: jjg ! src/share/classes/javax/lang/model/element/Element.java ! src/share/classes/javax/lang/model/element/ExecutableElement.java ! src/share/classes/javax/lang/model/element/PackageElement.java ! src/share/classes/javax/lang/model/element/TypeElement.java ! src/share/classes/javax/lang/model/element/TypeParameterElement.java ! src/share/classes/javax/lang/model/element/VariableElement.java From joe.darcy at oracle.com Sat Jan 29 01:10:05 2011 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Sat, 29 Jan 2011 01:10:05 +0000 Subject: hg: jdk7/tl/jdk: 7015156: Remove JSR 308 changes from core libraries Message-ID: <20110129011030.15EA847247@hg.openjdk.java.net> Changeset: d21a1ce074a7 Author: darcy Date: 2011-01-28 17:09 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d21a1ce074a7 7015156: Remove JSR 308 changes from core libraries Reviewed-by: mduigou ! src/share/classes/java/lang/SuppressWarnings.java ! src/share/classes/java/lang/annotation/ElementType.java From matthias at mernst.org Sat Jan 29 11:13:25 2011 From: matthias at mernst.org (Matthias Ernst) Date: Sat, 29 Jan 2011 12:13:25 +0100 Subject: Code review: 7012540 (java.util.Objects.nonNull() incorrectly named) In-Reply-To: References: <20110125231531.A78E712DF@eggemoggin.niobe.net> <4D3F5DDB.7070209@oracle.com> <4D404E86.5070501@oracle.com> Message-ID: On Thu, Jan 27, 2011 at 2:20 AM, Bob Lee wrote: > On Wed, Jan 26, 2011 at 3:44 PM, Joshua Bloch wrote: >> >> I like the name?nonNull. ?All other things being equal, shorter is better. >> ?I've used the name?nonNull for a few years, and it's feels right. To my >> mind, requireNonNull?does a worse job of suggesting that the method returns >> its argument. > > +1 for nonNull. While it's implemented as a method, I think of it more as a > keyword-like modifier, in which case an adjective works better than a verb > phrase. > Bob Couldn't agree more. I'm surprised no one has brought up the analogy to type casts yet. nonNull(o) is the equivalent of (String)o. It is a static assertion that the static type system is too weak to express and that may fail at runtime; programmers familiar with the Java language do not expect (String)o to perform a value conversion either. -- Matthias nonNullOrBust.