From jeffhain at rocketmail.com Fri Jun 1 00:19:56 2012 From: jeffhain at rocketmail.com (Jeff Hain) Date: Fri, 1 Jun 2012 01:19:56 +0100 (BST) Subject: review request: 4244896: (process) Provide System.getPid(), System.killProcess(String pid) In-Reply-To: <4FC7A0F6.7000402@oracle.com> References: <4F861847.5080308@oracle.com> <4F869AD6.7010903@oracle.com>, <4F8D849E.8090607@oracle.com> <4F8F56E0.6020009@oracle.com> <4F8FF15E.9080408@oracle.com> <4FAC0F5F.3090508@oracle.com> <4FC788CB.9070900@oracle.com> <4FC7A0F6.7000402@oracle.com> Message-ID: <1338509996.95534.YahooMailNeo@web132101.mail.ird.yahoo.com> Hi. > 185???? public boolean waitFor(long timeout, TimeUnit unit) > 186???????? throws InterruptedException { > 187???????? long now = System.nanoTime(); > 188???????? > 189???????? long end = now + > 190???????????? (timeout <= 0 ? 0 : TimeUnit.NANOSECONDS.convert(timeout, unit)); > 191???????? > 192???????? if (end <= 0) // overflow > 193???????????? end = Long.MAX_VALUE; > 194 > 195???????? long rem = end - now; > 196???????? do { > 197???????????? try { > 198???????????????? exitValue(); > 199???????????????? return true; > 200???????????? } catch(IllegalThreadStateException ex) { > 201???????????????? if(rem > 0) > 202???????????????????? Thread.sleep( > 203???????????????????????? Math.min(TimeUnit.NANOSECONDS.toMillis(rem) + 1, 100)); > 204???????????? } > 205???????????? rem = end - System.nanoTime(); > 206???????? } while(rem > 0); > 207???????? return false; > 208???? } If System.nanoTime() is close to wrapping, this code would consider overflow even for a not-so-large timeout, and the wait could stop earlier than expected. (Also "now" should rather be called "startTime" or so (since at some point it's no longer current time).) One could do as in ScheduledThreadPoolExecutor, and use an offset on System.nanoTime(). Or, just remove lines 192-194 : it's not really a problem if "end" wraps, since it should unwrap when doing "end - System.nanoTime()" (supposing we don't spend centuries in the method). Or, only work with delta (also supposing we don't wait for centuries), never explicitly considering an "end" value, like this: public boolean waitFor(long timeout, TimeUnit unit) ??? throws InterruptedException { ??? final long startNS = System.nanoTime(); ??? ??? final long timeoutNS = (timeout <= 0 ? 0 : unit.toNanos(timeout)); ??? ??? long remNS = timeoutNS; ??? do { ??????? try { ??????????? exitValue(); ??????????? return true; ??????? } catch(IllegalThreadStateException ex) { ??????????? if(remNS > 0) ??????????????? Thread.sleep( ??????????????????? Math.min(TimeUnit.NANOSECONDS.toMillis(remNS) + 1, 100)); ??????? } ??????? remNS = timeoutNS - (System.nanoTime() - startNS); ??? } while(remNS > 0); ??? return false; } -Jeff From david.holmes at oracle.com Fri Jun 1 00:41:20 2012 From: david.holmes at oracle.com (David Holmes) Date: Fri, 01 Jun 2012 10:41:20 +1000 Subject: review request: 4244896: (process) Provide System.getPid(), System.killProcess(String pid) In-Reply-To: <4FC788CB.9070900@oracle.com> References: <4F861847.5080308@oracle.com> <4F869AD6.7010903@oracle.com>, <4F8D849E.8090607@oracle.com> <4F8F56E0.6020009@oracle.com> <4F8FF15E.9080408@oracle.com> <4FAC0F5F.3090508@oracle.com> <4FC788CB.9070900@oracle.com> Message-ID: <4FC80FB0.3050701@oracle.com> Hi Rob, This looks good to me. I'm glad to see that destroyForcibly mandates that Process instances from ProcessBuilder.start and Runtime.exec must do a forcible destroy. That addresses my concern about documenting the actual implementations. Two minor comments: Process.java: 236 * {@link ProcessBuilder#start} and {@link Runtime#exec} are of type that "are of type" -> "are of a type ..." ProcessKillTest.sh: BIT_FLAG is now unused. Thanks, David On 1/06/2012 1:05 AM, Rob McKenna wrote: > Latest version including work on the spec language: > > http://cr.openjdk.java.net/~robm/4244896/webrev.04/ > > > -Rob > > On 10/05/12 19:56, Rob McKenna wrote: >> Hi folks, >> >> The latest version is at: >> >> http://cr.openjdk.java.net/~robm/4244896/webrev.03/ >> >> >> Feedback greatly appreciated. >> >> -Rob >> >> On 19/04/12 12:05, Alan Bateman wrote: >>> On 19/04/2012 01:05, David Holmes wrote: >>>> On 18/04/2012 11:44 PM, Jason Mehrens wrote: >>>>> >>>>> Rob, >>>>> >>>>> It looks like waitFor is calling Object.wait(long) without owning >>>>> this objects monitor. If I pass Long.MAX_VALUE to waitFor, >>>>> shouldn't waitFor return if the early if the process ends? >>>> >>>> Also waitFor doesn't call wait() under the guard of a looping >>>> predicate so it will suffer from lost signals and potentially >>>> spurious wakeups. I also don't see anything calling notify[All] to >>>> indicate the process has now terminated. It would appear that >>>> wait(timeout) is being used as a sleep mechanism and that is wrong >>>> on a number of levels. >>> I assume waitFor(timout) will require 3 distinct implementations, one >>> for Solaris/Linux/Mac, another for Windows, and a default >>> implementations for Process implementations that exist outside of the >>> JDK. >>> >>> It's likely the Solaris/Linux/Mac implementation will involve two >>> threads, one to block in waitpid and the other to interrupt it via a >>> signal if the timeout elapses before the child terminates. The >>> Windows implementation should be trivial because it can be a timed wait. >>> >>> I assume the default implementation (which is what is being discussed >>> here) will need to loop calling exitValue until the timeout elapses >>> or the child terminates. Not very efficient but at least it won't be >>> used when when creating Processes via Runtime.exec or ProcessBuilder. >>> >>> I think the question we need to consider is whether waitFor(timeout) >>> is really needed. If it's something that it pushed out for another >>> day then it brings up the question as to whether to include isAlive >>> now or not (as waitFor without timeout gives us an isAlive equivalent >>> too). >>> >>> -Alan. >>> >>> >>> >>> From david.holmes at oracle.com Fri Jun 1 01:06:04 2012 From: david.holmes at oracle.com (David Holmes) Date: Fri, 01 Jun 2012 11:06:04 +1000 Subject: review request: 4244896: (process) Provide System.getPid(), System.killProcess(String pid) In-Reply-To: <1338509996.95534.YahooMailNeo@web132101.mail.ird.yahoo.com> References: <4F861847.5080308@oracle.com> <4F869AD6.7010903@oracle.com>, <4F8D849E.8090607@oracle.com> <4F8F56E0.6020009@oracle.com> <4F8FF15E.9080408@oracle.com> <4FAC0F5F.3090508@oracle.com> <4FC788CB.9070900@oracle.com> <4FC7A0F6.7000402@oracle.com> <1338509996.95534.YahooMailNeo@web132101.mail.ird.yahoo.com> Message-ID: <4FC8157C.5080900@oracle.com> Jeff, On 1/06/2012 10:19 AM, Jeff Hain wrote: > Hi. >> 185 public boolean waitFor(long timeout, TimeUnit unit) >> 186 throws InterruptedException { >> 187 long now = System.nanoTime(); >> 188 >> 189 long end = now + >> 190 (timeout<= 0 ? 0 : TimeUnit.NANOSECONDS.convert(timeout, unit)); >> 191 >> 192 if (end<= 0) // overflow >> 193 end = Long.MAX_VALUE; >> 194 >> 195 long rem = end - now; >> 196 do { >> 197 try { >> 198 exitValue(); >> 199 return true; >> 200 } catch(IllegalThreadStateException ex) { >> 201 if(rem> 0) >> 202 Thread.sleep( >> 203 Math.min(TimeUnit.NANOSECONDS.toMillis(rem) + 1, 100)); >> 204 } >> 205 rem = end - System.nanoTime(); >> 206 } while(rem> 0); >> 207 return false; >> 208 } > > > If System.nanoTime() is close to wrapping, this code would consider overflow even for a not-so-large timeout, If System.nanoTime is close to wrapping then we have all sorts of problems to worry about. But you are right. The way to handle this with no overflow issues is to track the elapsed time (System.nanoTime() - start) which will always give a positive result when less than 2^63 nanoseconds elapse. That then gets subtracted from the requested timeout to give the rem value. > and the wait could stop earlier than expected. > (Also "now" should rather be called "startTime" or so (since at some point it's no longer current time).) > > One could do as in ScheduledThreadPoolExecutor, and use an offset on System.nanoTime(). Aside: I don't see that in latest version of STPE. Cheers, David ----- > Or, just remove lines 192-194 : it's not really a problem if "end" wraps, since it should unwrap > when doing "end - System.nanoTime()" (supposing we don't spend centuries in the method). > > Or, only work with delta (also supposing we don't wait for centuries), never explicitly considering > an "end" value, like this: > > public boolean waitFor(long timeout, TimeUnit unit) > throws InterruptedException { > final long startNS = System.nanoTime(); > > final long timeoutNS = (timeout<= 0 ? 0 : unit.toNanos(timeout)); > > long remNS = timeoutNS; > do { > try { > exitValue(); > return true; > } catch(IllegalThreadStateException ex) { > if(remNS> 0) > Thread.sleep( > Math.min(TimeUnit.NANOSECONDS.toMillis(remNS) + 1, 100)); > } > remNS = timeoutNS - (System.nanoTime() - startNS); > } while(remNS> 0); > return false; > } > > -Jeff From mike.duigou at oracle.com Fri Jun 1 07:15:57 2012 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Fri, 01 Jun 2012 07:15:57 +0000 Subject: hg: jdk8/tl/jdk: 7173432: Handle null key at HashMap resize Message-ID: <20120601071616.B7FEA4767A@hg.openjdk.java.net> Changeset: 7baa22e6a6b3 Author: mduigou Date: 2012-06-01 00:05 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7baa22e6a6b3 7173432: Handle null key at HashMap resize Summary: If the key to be inserted into a HashMap is null and the table needs to be resized as part of the insertion then addEntry will try to recalculate the hash of a null key. This will fail with an NPE. Reviewed-by: darcy ! src/share/classes/java/util/HashMap.java + test/java/util/HashMap/NullKeyAtResize.java From Alan.Bateman at oracle.com Fri Jun 1 07:46:15 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 01 Jun 2012 08:46:15 +0100 Subject: review request: 4244896: (process) Provide System.getPid(), System.killProcess(String pid) In-Reply-To: <4FC7A0F6.7000402@oracle.com> References: <4F861847.5080308@oracle.com> <4F869AD6.7010903@oracle.com>, <4F8D849E.8090607@oracle.com> <4F8F56E0.6020009@oracle.com> <4F8FF15E.9080408@oracle.com> <4FAC0F5F.3090508@oracle.com> <4FC788CB.9070900@oracle.com> <4FC7A0F6.7000402@oracle.com> Message-ID: <4FC87347.2020606@oracle.com> On 31/05/2012 17:48, Rob McKenna wrote: > That link should be: > > http://cr.openjdk.java.net/~robm/4244896/webrev.04/ > > -Rob I'm happy the spec has come good too. One small suggestion is to tweak this line: "{@code Process} objects returned by {@link ProcessBuilder#start} and {@link Runtime#exec} are of type that overrides this method and so invoking this method will forcibly terminatethe process. " to "Invoking this method on {@code Process} objects returned by {@link ProcessBuilder#start} and {@link Runtime#exec} will forcibly terminate the process". Alsoin this sentence: "... is called, however this method may be chained to {@code waitFor()} if needed." may be clearer if you put "This method may be ..." as a separate sentence. Otherwise I think it reads well.I hope to review the implementation and test soon. -Alan From kasperni at gmail.com Fri Jun 1 09:29:16 2012 From: kasperni at gmail.com (Kasper Nielsen) Date: Fri, 1 Jun 2012 11:29:16 +0200 Subject: HashMap bug for large sizes Message-ID: Hi, I don't know if this has been discussed before. But I was looking at the HashMap implementation today and noticed that there are some issues with very large sized hashmaps with more then Integer.MAX_VALUE elements. 1. The Map contract says that "If the map contains more than Integer.MAX_VALUE elements, returns Integer.MAX_VALUE." The current implementation will just wrap around and return negative numbers when you add elements (size++). 2. If the size of a HashMap has wrapped around and returns negative size you cannot deserialize it. Because of this loop in readObject for (int i=0; i References: Message-ID: <4FC8C564.7000104@cs.oswego.edu> On 06/01/12 05:29, Kasper Nielsen wrote: > Hi, > > I don't know if this has been discussed before. But I was looking at > the HashMap implementation today and noticed that there are some > issues with very large sized hashmaps with more then Integer.MAX_VALUE > elements. I think this arose on this list (or possibly some side-exchanges) three years ago when discussing possible HashMap improvements. It seems impossible to fix this without breaking serialization compatibility, so people seemed resigned to let the limitations remain until there was some change forcing incompatibility anyway. At the least though, an implementation note could be added to the javadocs. I think several other java.util classes also have this problem, but none of the java.util.concurrent ones do. So as a workaround, people can use ConcurrentHashMap even if they aren't using it concurrently. -Doug > > 1. > The Map contract says that "If the map contains more than > Integer.MAX_VALUE elements, returns Integer.MAX_VALUE." The current > implementation will just wrap around and return negative > numbers when you add elements (size++). > > 2. > If the size of a HashMap has wrapped around and returns negative size > you cannot deserialize it. Because of this loop in readObject > for (int i=0; i K key = (K) s.readObject(); > V value = (V) s.readObject(); > putForCreate(key, value); > } > > If someone wants to play around with the size limits of HashMap I > suggest taking the source code of HashMap and change the type of the > size field from an int to a short, in which case you can test this > with less the xx GB of heap. > > There are probably other map implementations in the JDK with the same issues. > > Cheers > Kasper > From eamonn at mcmanus.net Fri Jun 1 19:12:05 2012 From: eamonn at mcmanus.net (Eamonn McManus) Date: Fri, 1 Jun 2012 12:12:05 -0700 Subject: HashMap bug for large sizes In-Reply-To: <4FC8C564.7000104@cs.oswego.edu> References: <4FC8C564.7000104@cs.oswego.edu> Message-ID: It seems to me that since the serialization of HashMaps with more than Integer.MAX_VALUE entries produces an output that cannot be deserialized, nobody can be using it, and we are free to change it. For example we could say that if the read size is -1 then the next item in the stream is a long that is the true size, and arrange for that to be true in writeObject when there are more than Integer.MAX_VALUE entries. Whether there really are people who have HashMaps with billions of entries that they want to serialize with Java serialization is another question. ?amonn On 1 June 2012 06:36, Doug Lea
wrote: > > On 06/01/12 05:29, Kasper Nielsen wrote: >> >> Hi, >> >> I don't know if this has been discussed before. But I was looking at >> the HashMap implementation today and noticed that there are some >> issues with very large sized hashmaps with more then Integer.MAX_VALUE >> elements. > > > I think this arose on this list (or possibly some side-exchanges) > three years ago when discussing possible HashMap improvements. It > seems impossible to fix this without breaking serialization > compatibility, so people seemed resigned to let the limitations > remain until there was some change forcing incompatibility anyway. > At the least though, an implementation note could be added to > the javadocs. I think several other java.util classes also have > this problem, but none of the java.util.concurrent ones do. > So as a workaround, people can use ConcurrentHashMap even if > they aren't using it concurrently. > > -Doug > > >> >> 1. >> The Map contract says that "If the map contains more than >> Integer.MAX_VALUE elements, returns Integer.MAX_VALUE." The current >> implementation will just wrap around and return negative >> numbers when you add elements (size++). >> >> 2. >> If the size of a HashMap has wrapped around and returns negative size >> you cannot deserialize it. Because of this loop in readObject >> for (int i=0; i> ? ?K key = (K) s.readObject(); >> ? ?V value = (V) s.readObject(); >> ? ?putForCreate(key, value); >> } >> >> If someone wants to play around with the size limits of HashMap I >> suggest taking the source code of HashMap and change the type of the >> size field from an int to a short, in which case you can test this >> with less the xx GB of heap. >> >> There are probably other map implementations in the JDK with the same issues. >> >> Cheers >> ? Kasper >> > From kasperni at gmail.com Fri Jun 1 19:28:22 2012 From: kasperni at gmail.com (Kasper Nielsen) Date: Fri, 01 Jun 2012 21:28:22 +0200 Subject: HashMap bug for large sizes In-Reply-To: References: <4FC8C564.7000104@cs.oswego.edu> Message-ID: <4FC917D6.7040301@gmail.com> On 01-06-2012 21:12, Eamonn McManus wrote: > It seems to me that since the serialization of HashMaps with more than > Integer.MAX_VALUE entries produces an output that cannot be > deserialized, nobody can be using it, and we are free to change it. > For example we could say that if the read size is -1 then the next > item in the stream is a long that is the true size, and arrange for > that to be true in writeObject when there are more than > Integer.MAX_VALUE entries. Yeah, I thought of something along the lines of: long mapSize; s.writeInt(mapSize> Integer.MAX_VALUE ? Integer.MAX_VALUE : (int) mapSize ); for (int i=0;i=Integer.MAX_VALUE) { s.writeLong(size);//write the real size for (long i=Integer.MAX_VALUE;i Whether there really are people who have HashMaps with billions of > entries that they want to serialize with Java serialization is another > question. But it is not just serializing a HashMap that does not work. HashMap.size() and HashMap.clear() isn't working as well. - Kasper From eamonn at mcmanus.net Fri Jun 1 20:05:04 2012 From: eamonn at mcmanus.net (Eamonn McManus) Date: Fri, 1 Jun 2012 13:05:04 -0700 Subject: HashMap bug for large sizes In-Reply-To: <4FC917D6.7040301@gmail.com> References: <4FC8C564.7000104@cs.oswego.edu> <4FC917D6.7040301@gmail.com> Message-ID: > But it is not just serializing a HashMap that does not work. HashMap.size() > and HashMap.clear() isn't working as well. I don't see what's wrong with HashMap.clear(), but HashMap.size() is clearly buggy and should be fixed. There's also a performance problem in that accesses start becoming linear once there are more than 1 << 30 entries, but fixing that is substantially harder than just fixing size(), and ConcurrentHashMap already provides a better alternative for such huge maps. ?amonn On 1 June 2012 12:28, Kasper Nielsen wrote: > On 01-06-2012 21:12, Eamonn McManus wrote: >> >> It seems to me that since the serialization of HashMaps with more than >> Integer.MAX_VALUE entries produces an output that cannot be >> deserialized, nobody can be using it, and we are free to change it. >> For example we could say that if the read size is -1 then the next >> item in the stream is a long that is the true size, and arrange for >> that to be true in writeObject when there are more than >> Integer.MAX_VALUE entries. > > Yeah, > I thought of something along the lines of: > > long mapSize; > s.writeInt(mapSize> Integer.MAX_VALUE ? Integer.MAX_VALUE : (int) mapSize ); > for (int i=0;i > if (mapSize>=Integer.MAX_VALUE) { > ?s.writeLong(size);//write the real size > ?for (long i=Integer.MAX_VALUE;i } > > } > >> Whether there really are people who have HashMaps with billions of >> entries that they want to serialize with Java serialization is another >> question. > > > But it is not just serializing a HashMap that does not work. HashMap.size() > and HashMap.clear() isn't working as well. > > - Kasper From kasperni at gmail.com Fri Jun 1 20:59:51 2012 From: kasperni at gmail.com (Kasper Nielsen) Date: Fri, 01 Jun 2012 22:59:51 +0200 Subject: HashMap bug for large sizes In-Reply-To: References: <4FC8C564.7000104@cs.oswego.edu> <4FC917D6.7040301@gmail.com> Message-ID: <4FC92D47.8060303@gmail.com> On 01-06-2012 22:05, Eamonn McManus wrote: >> But it is not just serializing a HashMap that does not work. HashMap.size() >> and HashMap.clear() isn't working as well. > I don't see what's wrong with HashMap.clear(), My mistake, was looking at the HashMap implementation for Harmony. > but HashMap.size() is > clearly buggy and should be fixed. There's also a performance problem > in that accesses start becoming linear once there are more than 1<< > 30 entries, but fixing that is substantially harder than just fixing > size(), and ConcurrentHashMap already provides a better alternative > for such huge maps. Yes, introducing an extra level of indirection a.la. CHM segments for those few usecases is definitely not worth it. - Kasper From david.holmes at oracle.com Sat Jun 2 03:55:10 2012 From: david.holmes at oracle.com (David Holmes) Date: Sat, 02 Jun 2012 13:55:10 +1000 Subject: HashMap bug for large sizes In-Reply-To: <4FC8C564.7000104@cs.oswego.edu> References: <4FC8C564.7000104@cs.oswego.edu> Message-ID: <4FC98E9E.3090701@oracle.com> On 1/06/2012 11:36 PM, Doug Lea wrote: > On 06/01/12 05:29, Kasper Nielsen wrote: >> >> I don't know if this has been discussed before. But I was looking at >> the HashMap implementation today and noticed that there are some >> issues with very large sized hashmaps with more then Integer.MAX_VALUE >> elements. > > I think this arose on this list (or possibly some side-exchanges) > three years ago when discussing possible HashMap improvements. It Yes - see: http://mail.openjdk.java.net/pipermail/core-libs-dev/2009-June/001859.html as part of the "Faster Hashmap" discussion. Also 6998187 was filed for this in November 2010, but it fell into a crack in the bug system. I just pulled it back out. David ----- > seems impossible to fix this without breaking serialization > compatibility, so people seemed resigned to let the limitations > remain until there was some change forcing incompatibility anyway. > At the least though, an implementation note could be added to > the javadocs. I think several other java.util classes also have > this problem, but none of the java.util.concurrent ones do. > So as a workaround, people can use ConcurrentHashMap even if > they aren't using it concurrently. > > -Doug > >> >> 1. >> The Map contract says that "If the map contains more than >> Integer.MAX_VALUE elements, returns Integer.MAX_VALUE." The current >> implementation will just wrap around and return negative >> numbers when you add elements (size++). >> >> 2. >> If the size of a HashMap has wrapped around and returns negative size >> you cannot deserialize it. Because of this loop in readObject >> for (int i=0; i> K key = (K) s.readObject(); >> V value = (V) s.readObject(); >> putForCreate(key, value); >> } >> >> If someone wants to play around with the size limits of HashMap I >> suggest taking the source code of HashMap and change the type of the >> size field from an int to a short, in which case you can test this >> with less the xx GB of heap. >> >> There are probably other map implementations in the JDK with the same >> issues. >> >> Cheers >> Kasper >> > From david.holmes at oracle.com Sat Jun 2 22:15:18 2012 From: david.holmes at oracle.com (David Holmes) Date: Sun, 03 Jun 2012 08:15:18 +1000 Subject: [doc]Small modification on the WeakHashMap doc In-Reply-To: <4FC32AE9.2060703@linux.vnet.ibm.com> References: <4FA22B25.2090201@linux.vnet.ibm.com> <4FA73BDE.1040309@linux.vnet.ibm.com> <4FA74547.7040901@oracle.com> <4FC32AE9.2060703@linux.vnet.ibm.com> Message-ID: <4FCA9076.1020308@oracle.com> Hi Charles, I have no problem with this clarification in the implementation notes being added. I've checked with Joe and it does not require CCC approval. David ----- On 28/05/2012 5:36 PM, Charles Lee wrote: > > Hi devs, > > I'd like to propose a new minor change for the WeakHashMap doc, which I > got it from David :-) > > Would anyone got some time to take a look this fix[1]? > > 1. http://cr.openjdk.java.net/~littlee/7166055/webrev.01/ > > > On 05/07/2012 11:45 AM, David Holmes wrote: >> Hi Charles, >> >> On 7/05/2012 1:05 PM, Charles Lee wrote: >>> Does anyone interested in this issue? >> >> Interest and time are two different things :) >> >> A shorter form would be: >> >> "If the values in the map do not rely on the map holding strong >> references to them, then one way to deal with this is ... >> >> David >> >>> On 05/03/2012 02:52 PM, Charles Lee wrote: >>>> Hi guys, >>>> >>>> In the Implementation notes of WeakHashMap[1], says: >>>> >>>> /One way to deal with this is to wrap values themselves within >>>> WeakReferences before inserting, as in: m.put(key, new >>>> WeakReference(value)), and then unwrapping upon each get./ >>>> >>>> However, it is not concise and a little misleading. Because the value >>>> in the WeakReference can be GC'd if there are no strong reference to >>>> it. This behaviour surprises some customers. >>>> How about add a statement like [2]: >>>> >>>> /However, as the use of WeakReference in this manner will not prevent >>>> value objects from being GC'd, this approach is only useful when >>>> entries in the map are not relied upon for keeping the underlying >>>> value objects "live"./ >>>> >>>> >>>> >>>> >>>> [1]: >>>> http://docs.oracle.com/javase/7/docs/api/java/util/WeakHashMap.html >>>> [2]: http://cr.openjdk.java.net/~littlee/7166055/webrev.00/ >>>> >>>> >>> >>> >> > > > -- > Yours Charles > From mike.duigou at oracle.com Sun Jun 3 21:35:52 2012 From: mike.duigou at oracle.com (Mike Duigou) Date: Sun, 3 Jun 2012 14:35:52 -0700 Subject: hg: jdk8/tl/jdk: 6924259: Remove offset and count fields from java.lang.String In-Reply-To: <1359801.KFxJhQHyve@cube> References: <20120531032252.A69774763C@hg.openjdk.java.net> <1359801.KFxJhQHyve@cube> Message-ID: [I trimmed the distribution list] On Jun 3 2012, at 13:44 , Peter Levart wrote: > On Thursday, May 31, 2012 03:22:35 AM mike.duigou at oracle.com wrote: >> Changeset: 2c773daa825d >> Author: mduigou >> Date: 2012-05-17 10:06 -0700 >> URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2c773daa825d >> >> 6924259: Remove offset and count fields from java.lang.String >> Summary: Removes the use of shared character array buffers by String along >> with the two fields needed to support the use of shared buffers. > > Wow, that's quite a change. Indeed. It was a long time in development. It is a change which is expected to be overall beneficial though and in the general case a positive win. > So .substring() is not O(1) any more? No. Though with object allocation it probably was only ever roughly O(1) anyway. > Doesn't this have impact on the performance of parsers and such that rely on > the performance caracteristics of the .substring() ? It does have an impact. We've seen as much as a couple of percent on some benchmarks. Parsers which use substring for extraction are definitely impacted by this change. > Have you considered then implementing .subSequence() not in terms of just > delegating to .substring() but returning a special CharSequence view over the > chars of the sub-sequence? It does look that String.subSequence() returning a special view rather than a substring would be a good optimization and probably a very good compromise for parser developers. Please create an issue and if you have the time and expertise a patch would speed things along (though unfortunately almost certainly too late for inclusion in 7u6). Mike > Regards, Peter > >> Reviewed-by: alanb, mduigou, forax, briangoetz >> Contributed-by: brian.doherty at oracle.com >> >> ! src/share/classes/java/lang/Integer.java >> ! src/share/classes/java/lang/Long.java >> ! src/share/classes/java/lang/String.java >> ! src/share/classes/java/lang/StringCoding.java From littlee at linux.vnet.ibm.com Mon Jun 4 01:55:32 2012 From: littlee at linux.vnet.ibm.com (Charles Lee) Date: Mon, 04 Jun 2012 09:55:32 +0800 Subject: [doc]Small modification on the WeakHashMap doc In-Reply-To: <4FCA9076.1020308@oracle.com> References: <4FA22B25.2090201@linux.vnet.ibm.com> <4FA73BDE.1040309@linux.vnet.ibm.com> <4FA74547.7040901@oracle.com> <4FC32AE9.2060703@linux.vnet.ibm.com> <4FCA9076.1020308@oracle.com> Message-ID: <4FCC1594.3010502@linux.vnet.ibm.com> Thanks David. Do I need another review? On 06/03/2012 06:15 AM, David Holmes wrote: > Hi Charles, > > I have no problem with this clarification in the implementation notes > being added. I've checked with Joe and it does not require CCC approval. > > David > ----- > > On 28/05/2012 5:36 PM, Charles Lee wrote: >> >> Hi devs, >> >> I'd like to propose a new minor change for the WeakHashMap doc, which I >> got it from David :-) >> >> Would anyone got some time to take a look this fix[1]? >> >> 1. http://cr.openjdk.java.net/~littlee/7166055/webrev.01/ >> >> >> On 05/07/2012 11:45 AM, David Holmes wrote: >>> Hi Charles, >>> >>> On 7/05/2012 1:05 PM, Charles Lee wrote: >>>> Does anyone interested in this issue? >>> >>> Interest and time are two different things :) >>> >>> A shorter form would be: >>> >>> "If the values in the map do not rely on the map holding strong >>> references to them, then one way to deal with this is ... >>> >>> David >>> >>>> On 05/03/2012 02:52 PM, Charles Lee wrote: >>>>> Hi guys, >>>>> >>>>> In the Implementation notes of WeakHashMap[1], says: >>>>> >>>>> /One way to deal with this is to wrap values themselves within >>>>> WeakReferences before inserting, as in: m.put(key, new >>>>> WeakReference(value)), and then unwrapping upon each get./ >>>>> >>>>> However, it is not concise and a little misleading. Because the value >>>>> in the WeakReference can be GC'd if there are no strong reference to >>>>> it. This behaviour surprises some customers. >>>>> How about add a statement like [2]: >>>>> >>>>> /However, as the use of WeakReference in this manner will not prevent >>>>> value objects from being GC'd, this approach is only useful when >>>>> entries in the map are not relied upon for keeping the underlying >>>>> value objects "live"./ >>>>> >>>>> >>>>> >>>>> >>>>> [1]: >>>>> http://docs.oracle.com/javase/7/docs/api/java/util/WeakHashMap.html >>>>> [2]: http://cr.openjdk.java.net/~littlee/7166055/webrev.00/ >>>>> >>>>> >>>> >>>> >>> >> >> >> -- >> Yours Charles >> > -- Yours Charles From david.holmes at oracle.com Mon Jun 4 03:05:12 2012 From: david.holmes at oracle.com (David Holmes) Date: Mon, 04 Jun 2012 13:05:12 +1000 Subject: [doc]Small modification on the WeakHashMap doc In-Reply-To: <4FCC1594.3010502@linux.vnet.ibm.com> References: <4FA22B25.2090201@linux.vnet.ibm.com> <4FA73BDE.1040309@linux.vnet.ibm.com> <4FA74547.7040901@oracle.com> <4FC32AE9.2060703@linux.vnet.ibm.com> <4FCA9076.1020308@oracle.com> <4FCC1594.3010502@linux.vnet.ibm.com> Message-ID: <4FCC25E8.3000505@oracle.com> On 4/06/2012 11:55 AM, Charles Lee wrote: > Thanks David. Do I need another review? Yes. Someone from TL - Mike or Alan most likely. David > On 06/03/2012 06:15 AM, David Holmes wrote: >> Hi Charles, >> >> I have no problem with this clarification in the implementation notes >> being added. I've checked with Joe and it does not require CCC approval. >> >> David >> ----- >> >> On 28/05/2012 5:36 PM, Charles Lee wrote: >>> >>> Hi devs, >>> >>> I'd like to propose a new minor change for the WeakHashMap doc, which I >>> got it from David :-) >>> >>> Would anyone got some time to take a look this fix[1]? >>> >>> 1. http://cr.openjdk.java.net/~littlee/7166055/webrev.01/ >>> >>> >>> On 05/07/2012 11:45 AM, David Holmes wrote: >>>> Hi Charles, >>>> >>>> On 7/05/2012 1:05 PM, Charles Lee wrote: >>>>> Does anyone interested in this issue? >>>> >>>> Interest and time are two different things :) >>>> >>>> A shorter form would be: >>>> >>>> "If the values in the map do not rely on the map holding strong >>>> references to them, then one way to deal with this is ... >>>> >>>> David >>>> >>>>> On 05/03/2012 02:52 PM, Charles Lee wrote: >>>>>> Hi guys, >>>>>> >>>>>> In the Implementation notes of WeakHashMap[1], says: >>>>>> >>>>>> /One way to deal with this is to wrap values themselves within >>>>>> WeakReferences before inserting, as in: m.put(key, new >>>>>> WeakReference(value)), and then unwrapping upon each get./ >>>>>> >>>>>> However, it is not concise and a little misleading. Because the value >>>>>> in the WeakReference can be GC'd if there are no strong reference to >>>>>> it. This behaviour surprises some customers. >>>>>> How about add a statement like [2]: >>>>>> >>>>>> /However, as the use of WeakReference in this manner will not prevent >>>>>> value objects from being GC'd, this approach is only useful when >>>>>> entries in the map are not relied upon for keeping the underlying >>>>>> value objects "live"./ >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> [1]: >>>>>> http://docs.oracle.com/javase/7/docs/api/java/util/WeakHashMap.html >>>>>> [2]: http://cr.openjdk.java.net/~littlee/7166055/webrev.00/ >>>>>> >>>>>> >>>>> >>>>> >>>> >>> >>> >>> -- >>> Yours Charles >>> >> > > From mike.duigou at oracle.com Mon Jun 4 03:33:09 2012 From: mike.duigou at oracle.com (Mike Duigou) Date: Sun, 3 Jun 2012 20:33:09 -0700 Subject: [doc]Small modification on the WeakHashMap doc In-Reply-To: <4FCC25E8.3000505@oracle.com> References: <4FA22B25.2090201@linux.vnet.ibm.com> <4FA73BDE.1040309@linux.vnet.ibm.com> <4FA74547.7040901@oracle.com> <4FC32AE9.2060703@linux.vnet.ibm.com> <4FCA9076.1020308@oracle.com> <4FCC1594.3010502@linux.vnet.ibm.com> <4FCC25E8.3000505@oracle.com> Message-ID: The change looks good to me. On Jun 3 2012, at 20:05 , David Holmes wrote: > On 4/06/2012 11:55 AM, Charles Lee wrote: >> Thanks David. Do I need another review? > > Yes. Someone from TL - Mike or Alan most likely. > > David > >> On 06/03/2012 06:15 AM, David Holmes wrote: >>> Hi Charles, >>> >>> I have no problem with this clarification in the implementation notes >>> being added. I've checked with Joe and it does not require CCC approval. >>> >>> David >>> ----- >>> >>> On 28/05/2012 5:36 PM, Charles Lee wrote: >>>> >>>> Hi devs, >>>> >>>> I'd like to propose a new minor change for the WeakHashMap doc, which I >>>> got it from David :-) >>>> >>>> Would anyone got some time to take a look this fix[1]? >>>> >>>> 1. http://cr.openjdk.java.net/~littlee/7166055/webrev.01/ >>>> >>>> >>>> On 05/07/2012 11:45 AM, David Holmes wrote: >>>>> Hi Charles, >>>>> >>>>> On 7/05/2012 1:05 PM, Charles Lee wrote: >>>>>> Does anyone interested in this issue? >>>>> >>>>> Interest and time are two different things :) >>>>> >>>>> A shorter form would be: >>>>> >>>>> "If the values in the map do not rely on the map holding strong >>>>> references to them, then one way to deal with this is ... >>>>> >>>>> David >>>>> >>>>>> On 05/03/2012 02:52 PM, Charles Lee wrote: >>>>>>> Hi guys, >>>>>>> >>>>>>> In the Implementation notes of WeakHashMap[1], says: >>>>>>> >>>>>>> /One way to deal with this is to wrap values themselves within >>>>>>> WeakReferences before inserting, as in: m.put(key, new >>>>>>> WeakReference(value)), and then unwrapping upon each get./ >>>>>>> >>>>>>> However, it is not concise and a little misleading. Because the value >>>>>>> in the WeakReference can be GC'd if there are no strong reference to >>>>>>> it. This behaviour surprises some customers. >>>>>>> How about add a statement like [2]: >>>>>>> >>>>>>> /However, as the use of WeakReference in this manner will not prevent >>>>>>> value objects from being GC'd, this approach is only useful when >>>>>>> entries in the map are not relied upon for keeping the underlying >>>>>>> value objects "live"./ >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> [1]: >>>>>>> http://docs.oracle.com/javase/7/docs/api/java/util/WeakHashMap.html >>>>>>> [2]: http://cr.openjdk.java.net/~littlee/7166055/webrev.00/ >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>>> -- >>>> Yours Charles >>>> >>> >> >> From mike.duigou at oracle.com Mon Jun 4 06:08:46 2012 From: mike.duigou at oracle.com (Mike Duigou) Date: Sun, 3 Jun 2012 23:08:46 -0700 Subject: Request for Reviews 7173918&7173919: Small follow-ons to alternative hashing Message-ID: <0F20DE59-F151-453C-8CFE-83EBC92E7655@oracle.com> Two small issues related to the larger alternative string hashing changes (CR#7126277) from last week. One issue is for JDK 7 and the other is for JDK 8. Both are quite small. For the JDK 7 issue, as documented in the review request, the default threshold for the alternative hashing in that patch was set to the minimum to unconditionally enable the feature. This was done to make compatibility testing easier. Developers are strongly encouraged to test their applications with the 7u6b13 build to ensure that their applications do not later encounter problems. For the release version of 7u6 the default threshold will be set to 512. This patch sets that default and marks one field final. http://cr.openjdk.java.net/~mduigou/7173918/0/webrev/ The JDK8 issue is number of small performance enhancements suggested by Ulf Zibis and Remi Forax. These changes are being considered now while this issue remains fresh in the maintainer and reviewer's minds. http://cr.openjdk.java.net/~mduigou/7173919/0/webrev/ Thanks, Mike From forax at univ-mlv.fr Mon Jun 4 07:43:51 2012 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Mon, 04 Jun 2012 09:43:51 +0200 Subject: Request for Reviews 7173918&7173919: Small follow-ons to alternative hashing In-Reply-To: <0F20DE59-F151-453C-8CFE-83EBC92E7655@oracle.com> References: <0F20DE59-F151-453C-8CFE-83EBC92E7655@oracle.com> Message-ID: <4FCC6737.7020806@univ-mlv.fr> Hi Mike, jdk8 patch looks good to me. R?mi On 06/04/2012 08:08 AM, Mike Duigou wrote: > Two small issues related to the larger alternative string hashing changes (CR#7126277) from last week. One issue is for JDK 7 and the other is for JDK 8. Both are quite small. > > For the JDK 7 issue, as documented in the review request, the default threshold for the alternative hashing in that patch was set to the minimum to unconditionally enable the feature. This was done to make compatibility testing easier. Developers are strongly encouraged to test their applications with the 7u6b13 build to ensure that their applications do not later encounter problems. For the release version of 7u6 the default threshold will be set to 512. This patch sets that default and marks one field final. > > http://cr.openjdk.java.net/~mduigou/7173918/0/webrev/ > > The JDK8 issue is number of small performance enhancements suggested by Ulf Zibis and Remi Forax. These changes are being considered now while this issue remains fresh in the maintainer and reviewer's minds. > > http://cr.openjdk.java.net/~mduigou/7173919/0/webrev/ > > Thanks, > > Mike From david.holmes at oracle.com Mon Jun 4 07:46:13 2012 From: david.holmes at oracle.com (David Holmes) Date: Mon, 04 Jun 2012 17:46:13 +1000 Subject: Request for Reviews 7173918&7173919: Small follow-ons to alternative hashing In-Reply-To: <0F20DE59-F151-453C-8CFE-83EBC92E7655@oracle.com> References: <0F20DE59-F151-453C-8CFE-83EBC92E7655@oracle.com> Message-ID: <4FCC67C5.4040107@oracle.com> Both sets of changes look fine to me. David On 4/06/2012 4:08 PM, Mike Duigou wrote: > Two small issues related to the larger alternative string hashing changes (CR#7126277) from last week. One issue is for JDK 7 and the other is for JDK 8. Both are quite small. > > For the JDK 7 issue, as documented in the review request, the default threshold for the alternative hashing in that patch was set to the minimum to unconditionally enable the feature. This was done to make compatibility testing easier. Developers are strongly encouraged to test their applications with the 7u6b13 build to ensure that their applications do not later encounter problems. For the release version of 7u6 the default threshold will be set to 512. This patch sets that default and marks one field final. > > http://cr.openjdk.java.net/~mduigou/7173918/0/webrev/ > > The JDK8 issue is number of small performance enhancements suggested by Ulf Zibis and Remi Forax. These changes are being considered now while this issue remains fresh in the maintainer and reviewer's minds. > > http://cr.openjdk.java.net/~mduigou/7173919/0/webrev/ > > Thanks, > > Mike From littlee at linux.vnet.ibm.com Mon Jun 4 08:34:58 2012 From: littlee at linux.vnet.ibm.com (littlee at linux.vnet.ibm.com) Date: Mon, 04 Jun 2012 08:34:58 +0000 Subject: hg: jdk8/tl/jdk: 7166055: Javadoc for WeakHashMap contains misleading advice Message-ID: <20120604083518.2D7BD476CA@hg.openjdk.java.net> Changeset: 237e27c7ddc3 Author: littlee Date: 2012-06-04 16:30 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/237e27c7ddc3 7166055: Javadoc for WeakHashMap contains misleading advice Reviewed-by: dholmes, mduigou ! src/share/classes/java/util/WeakHashMap.java From weijun.wang at oracle.com Mon Jun 4 10:07:15 2012 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Mon, 04 Jun 2012 10:07:15 +0000 Subject: hg: jdk8/tl/jdk: 7173036: test/com/sun/jdi/ConnectedVMs.java does not run as expected Message-ID: <20120604100738.40B6E476D1@hg.openjdk.java.net> Changeset: a5bb0343f135 Author: weijun Date: 2012-06-04 18:06 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a5bb0343f135 7173036: test/com/sun/jdi/ConnectedVMs.java does not run as expected Reviewed-by: alanb ! test/com/sun/jdi/ConnectedVMs.java From Ulf.Zibis at gmx.de Mon Jun 4 11:01:05 2012 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Mon, 04 Jun 2012 13:01:05 +0200 Subject: hg: jdk8/tl/jdk: 7126277: Alternative String hashing implementation In-Reply-To: <20120531051930.AA11E47640@hg.openjdk.java.net> References: <20120531051930.AA11E47640@hg.openjdk.java.net> Message-ID: <4FCC9571.9030802@gmx.de> Hi Mike, Am 31.05.2012 07:19, schrieb mike.duigou at oracle.com: > Changeset: 43bd5ee0205e > Author: mduigou > Date: 2012-05-30 22:18 -0700 > URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/43bd5ee0205e > > 7126277: Alternative String hashing implementation > Summary: ... when the capacity of the hash table has ever grown beyond 512 entries. I can't see this in the JDK8 code. So at least the changeset comment seems wrong. -Ulf From littlee at linux.vnet.ibm.com Mon Jun 4 08:38:42 2012 From: littlee at linux.vnet.ibm.com (Charles Lee) Date: Mon, 04 Jun 2012 16:38:42 +0800 Subject: [doc]Small modification on the WeakHashMap doc In-Reply-To: References: <4FA22B25.2090201@linux.vnet.ibm.com> <4FA73BDE.1040309@linux.vnet.ibm.com> <4FA74547.7040901@oracle.com> <4FC32AE9.2060703@linux.vnet.ibm.com> <4FCA9076.1020308@oracle.com> <4FCC1594.3010502@linux.vnet.ibm.com> <4FCC25E8.3000505@oracle.com> Message-ID: <4FCC7412.6010207@linux.vnet.ibm.com> Thanks David. Thanks Mike. The patch has been committed. On 06/04/2012 11:33 AM, Mike Duigou wrote: > The change looks good to me. > On Jun 3 2012, at 20:05 , David Holmes wrote: > >> On 4/06/2012 11:55 AM, Charles Lee wrote: >>> Thanks David. Do I need another review? >> Yes. Someone from TL - Mike or Alan most likely. >> >> David >> >>> On 06/03/2012 06:15 AM, David Holmes wrote: >>>> Hi Charles, >>>> >>>> I have no problem with this clarification in the implementation notes >>>> being added. I've checked with Joe and it does not require CCC approval. >>>> >>>> David >>>> ----- >>>> >>>> On 28/05/2012 5:36 PM, Charles Lee wrote: >>>>> Hi devs, >>>>> >>>>> I'd like to propose a new minor change for the WeakHashMap doc, which I >>>>> got it from David :-) >>>>> >>>>> Would anyone got some time to take a look this fix[1]? >>>>> >>>>> 1. http://cr.openjdk.java.net/~littlee/7166055/webrev.01/ >>>>> >>>>> >>>>> On 05/07/2012 11:45 AM, David Holmes wrote: >>>>>> Hi Charles, >>>>>> >>>>>> On 7/05/2012 1:05 PM, Charles Lee wrote: >>>>>>> Does anyone interested in this issue? >>>>>> Interest and time are two different things :) >>>>>> >>>>>> A shorter form would be: >>>>>> >>>>>> "If the values in the map do not rely on the map holding strong >>>>>> references to them, then one way to deal with this is ... >>>>>> >>>>>> David >>>>>> >>>>>>> On 05/03/2012 02:52 PM, Charles Lee wrote: >>>>>>>> Hi guys, >>>>>>>> >>>>>>>> In the Implementation notes of WeakHashMap[1], says: >>>>>>>> >>>>>>>> /One way to deal with this is to wrap values themselves within >>>>>>>> WeakReferences before inserting, as in: m.put(key, new >>>>>>>> WeakReference(value)), and then unwrapping upon each get./ >>>>>>>> >>>>>>>> However, it is not concise and a little misleading. Because the value >>>>>>>> in the WeakReference can be GC'd if there are no strong reference to >>>>>>>> it. This behaviour surprises some customers. >>>>>>>> How about add a statement like [2]: >>>>>>>> >>>>>>>> /However, as the use of WeakReference in this manner will not prevent >>>>>>>> value objects from being GC'd, this approach is only useful when >>>>>>>> entries in the map are not relied upon for keeping the underlying >>>>>>>> value objects "live"./ >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> [1]: >>>>>>>> http://docs.oracle.com/javase/7/docs/api/java/util/WeakHashMap.html >>>>>>>> [2]: http://cr.openjdk.java.net/~littlee/7166055/webrev.00/ >>>>>>>> >>>>>>>> >>>>>>> >>>>> >>>>> -- >>>>> Yours Charles >>>>> >>> -- Yours Charles From forax at univ-mlv.fr Mon Jun 4 12:41:14 2012 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Mon, 04 Jun 2012 14:41:14 +0200 Subject: hg: jdk8/tl/jdk: 6924259: Remove offset and count fields from java.lang.String In-Reply-To: References: <20120531032252.A69774763C@hg.openjdk.java.net> <1359801.KFxJhQHyve@cube> Message-ID: <4FCCACEA.8020500@univ-mlv.fr> On 06/03/2012 11:35 PM, Mike Duigou wrote: > [I trimmed the distribution list] > > On Jun 3 2012, at 13:44 , Peter Levart wrote: > >> On Thursday, May 31, 2012 03:22:35 AM mike.duigou at oracle.com wrote: >>> Changeset: 2c773daa825d >>> Author: mduigou >>> Date: 2012-05-17 10:06 -0700 >>> URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2c773daa825d >>> >>> 6924259: Remove offset and count fields from java.lang.String >>> Summary: Removes the use of shared character array buffers by String along >>> with the two fields needed to support the use of shared buffers. >> Wow, that's quite a change. > Indeed. It was a long time in development. It is a change which is expected to be overall beneficial though and in the general case a positive win. > >> So .substring() is not O(1) any more? > No. Though with object allocation it probably was only ever roughly O(1) anyway. Allocation fast path just bump a pointer, so it's O(1). There are two advantages of the new code. The String object and the array of chars are now co-located in memory (at least for small/medium strings) so cpu caches are happy. This fix a longstanding memory leak issue see http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4513622 that why some parsers already doesn't use the substring() trick. BTW Mike, you can now close this bug. > >> Doesn't this have impact on the performance of parsers and such that rely on >> the performance caracteristics of the .substring() ? > It does have an impact. We've seen as much as a couple of percent on some benchmarks. Parsers which use substring for extraction are definitely impacted by this change. > >> Have you considered then implementing .subSequence() not in terms of just >> delegating to .substring() but returning a special CharSequence view over the >> chars of the sub-sequence? > It does look that String.subSequence() returning a special view rather than a substring would be a good optimization and probably a very good compromise for parser developers. Please create an issue and if you have the time and expertise a patch would speed things along (though unfortunately almost certainly too late for inclusion in 7u6). Given that Integer.parseInt() or Double.parseDouble() takes a String and not a CharSequence, yes you can create a CharSequence view but the only way to use it is to call toString() on it. > > Mike cheers, R?mi From Ulf.Zibis at gmx.de Mon Jun 4 12:39:11 2012 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Mon, 04 Jun 2012 14:39:11 +0200 Subject: Request for Reviews 7173918&7173919: Small follow-ons to alternative hashing In-Reply-To: <0F20DE59-F151-453C-8CFE-83EBC92E7655@oracle.com> References: <0F20DE59-F151-453C-8CFE-83EBC92E7655@oracle.com> Message-ID: <4FCCAC6F.5090109@gmx.de> Am 04.06.2012 08:08, schrieb Mike Duigou: > Two small issues related to the larger alternative string hashing changes (CR#7126277) from last week. One issue is for JDK 7 and the other is for JDK 8. Both are quite small. > > For the JDK 7 issue, as documented in the review request, the default threshold for the alternative hashing in that patch was set to the minimum to unconditionally enable the feature. This was done to make compatibility testing easier. Developers are strongly encouraged to test their applications with the 7u6b13 build to ensure that their applications do not later encounter problems. For the release version of 7u6 the default threshold will be set to 512. This patch sets that default and marks one field final. > > http://cr.openjdk.java.net/~mduigou/7173918/0/webrev/ *** WeakHashMap 353 int hash(Object k) { 354 355 int h; 356 if (useAltHashing) { 357 h = hashSeed; 358 if (k instanceof String) { 359 return h ^ sun.misc.Hashing.stringHash32((String) k); 360 } else { 361 h ^= k.hashCode(); 362 } 363 } else { 364 h = k.hashCode(); 365 } ==> shorter form + better chance for inlining + less less jumps, which are always kinda expensive: 353 int hash(Object k) { 354 355 int h; 356 if (useAltHashing) { 357 h = hashSeed; 358 if (k instanceof String) { 359 return h ^ sun.misc.Hashing.stringHash32((String)k); ==> Remove the space after the cast. 360 } 361 362 h ^= k.hashCode(); *** HashMap doesn't use "(h = hashSeed) ^ ..." for the String case, why? *** Hashtable has completely different design, why? : - doesn't use instanceof operator - doesn't use "(h = hashSeed) ^ ..." for general objects ==> You again have inserted a spaces after casts. > > The JDK8 issue is number of small performance enhancements suggested by Ulf Zibis and Remi Forax. These changes are being considered now while this issue remains fresh in the maintainer and reviewer's minds. > > http://cr.openjdk.java.net/~mduigou/7173919/0/webrev/ 291 if (k instanceof String) { 292 return ((String) k).hash32(); ==> You again have inserted a space after the cast. 293 } ==> Please add a blank line here as in the other map classes. Otherwise it would look, that the following line has some context to the before line. ==> Additionally I would add a comment here, why the legacy behaviour on general objects is changed in that way. ==> Maybe it would be more readable/logical to move this line just after line 298. 294 int h = hashSeed ^ k.hashCode(); 295 296 // This function ensures that hashCodes that differ only by 297 // constant multiples at each bit position have a bounded 298 // number of collisions (approximately 8 at default load factor). 299 h ^= (h >>> 20) ^ (h >>> 12); 300 return h ^ (h >>> 7) ^ (h >>> 4); Anyway I still would prefer to move the hash(Object) method to AbstractHashMap. Additionally while being here, we could review, why ConcurrentHashMap has a different algorithm. -Ulf From edvard.wendelin at oracle.com Mon Jun 4 14:01:27 2012 From: edvard.wendelin at oracle.com (Edvard Wendelin) Date: Mon, 4 Jun 2012 16:01:27 +0200 Subject: Request for Review(XS): 7156963 Incorrect copyright header in java/io/SerialCallbackContext Message-ID: <0FBC0B92-B3EA-4A62-9355-F5FE1E25A5D1@oracle.com> Please review. In addition to fixing the copyright I also fixed the incorrect indentation of the rest of the file (which is kind of hard to tell from the webrev). Bug: 7156963 CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7156963 Synopsis: Incorrect copyright header in java/io/SerialCallbackContext Webrev: http://cr.openjdk.java.net/~ewendeli/7156963/webrev.01/ Testing: Verified that the JDK compiles properly. Thanks, Edvard From dbelfer at gmail.com Mon Jun 4 15:33:26 2012 From: dbelfer at gmail.com (Diego Belfer) Date: Mon, 4 Jun 2012 12:33:26 -0300 Subject: [PATCH] 7164256 : EnumMap.clone doesn't clear the entrySet field, keeping a reference to the original Map In-Reply-To: References: <4FC3D9F3.4040602@oracle.com> Message-ID: Hi Alan, I've already sent the signed OCA. Will you sponsor the patch ? Best, Diego On Mon, May 28, 2012 at 11:37 PM, Diego Belfer wrote: > Hi Alan, > > Thanks for your reply. I am attaching a new patch and it contains the test > case now. > > I have read the contents of the link you sent me and I believe the OCA > signature is the only thing that is pending. I will send a signed copy of > the OCA tomorrow so my change can be applied to the repository once it gets > approved. > > Let me know if I'm missing something. > > Best, > Diego > > > > # HG changeset patch > # User muralx > # Date 1338257674 10800 > # Node ID f61b94fd7aca738353177fcf3cc3972ddf36cf36 > > # Parent 9b8c96f96a0f9a5801b55530a387fefbe50482a3 > PATCH 7164256 : EnumMap.clone does not clear the instance field entrySet > > diff --git a/src/share/classes/java/util/EnumMap.java > b/src/share/classes/java/util/EnumMap.java > --- a/src/share/classes/java/util/EnumMap.java > +++ b/src/share/classes/java/util/EnumMap.java > @@ -721,6 +721,7 @@ > throw new AssertionError(); > } > result.vals = result.vals.clone(); > + result.entrySet = null; > return result; > } > > diff --git a/test/java/util/EnumMap/ProperEntrySetOnClone.java > b/test/java/util/EnumMap/ProperEntrySetOnClone.java > new file mode 100644 > --- /dev/null > +++ b/test/java/util/EnumMap/ProperEntrySetOnClone.java > @@ -0,0 +1,58 @@ > +/* > + * Copyright (c) 2012, Oracle and/or its affiliates. All rights reserved. > + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > + * > + * This code is free software; you can redistribute it and/or modify it > + * under the terms of the GNU General Public License version 2 only, as > + * published by the Free Software Foundation. > + * > + * This code is distributed in the hope that it will be useful, but > WITHOUT > + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or > + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License > + * version 2 for more details (a copy is included in the LICENSE file that > + * accompanied this code). > + * > + * You should have received a copy of the GNU General Public License > version > + * 2 along with this work; if not, write to the Free Software Foundation, > + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. > + * > + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA > + * or visit www.oracle.com if you need additional information or have any > + * questions. > + */ > + > +/* > + * @test > + * @bug 7164256 > + * @summary EnumMap.entrySet() returns an entrySet referencing to the > cloned instance > + * @author Diego Belfer > + */ > + > +import java.util.EnumMap; > + > +public class ProperEntrySetOnClone { > + public enum Test { > + ONE, TWO > + } > + > + public static void main(String[] args) { > + EnumMap map1 = new EnumMap String>(Test.class); > + map1.put(Test.ONE, "1"); > + map1.put(Test.TWO, "2"); > + > + // We need to force creation of the map1.entrySet > + int size = map1.entrySet().size(); > + if (size != 2) { > + throw new RuntimeException( > + "Invalid size in original map. Expected: 2 was: " + > size); > + } > + > + EnumMap map2 = map1.clone(); > + map2.remove(Test.ONE); > + size = map2.entrySet().size(); > + if (size != 1) { > + throw new RuntimeException( > + "Invalid size in cloned instance. Expected: 1 was: " > + size); > + } > + } > +} > > > > On Mon, May 28, 2012 at 5:02 PM, Alan Bateman wrote: > >> On 28/05/2012 20:31, Diego Belfer wrote: >> >>> Hi, >>> >>> The patch seems to have been removed by the mailer. I am adding it >>> inline. >>> >>> Best, >>> Diego Belfer >>> [muralx] >>> >>> Thanks for the bug report and patch. I think mailman is configured to >> drop certain types of attachments which would explain why it was missing >> from your first mail. >> >> As you are contributing a fix then I would suggesting going through this >> page first: >> >> http://openjdk.java.net/**contribute/ >> >> This explains how to be a contributor. Also note in section 3 that a unit >> or regression tests should be included where practical. I realize this will >> be more work than the fix itself but that is often the case. You can find >> some examples of tests for this area in jdk/test/java/util/EnumMap. >> >> -Alan. >> >> > From Ulf.Zibis at gmx.de Mon Jun 4 15:39:43 2012 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Mon, 04 Jun 2012 17:39:43 +0200 Subject: hg: jdk8/tl/jdk: 6924259: Remove offset and count fields from java.lang.String In-Reply-To: <20120531032252.A69774763C@hg.openjdk.java.net> References: <20120531032252.A69774763C@hg.openjdk.java.net> Message-ID: <4FCCD6BF.3080300@gmx.de> In getBytes() you do not need: int n = srcEnd; int i = srcBegin; You could already use srcEnd srcBegin @@ -1015,16 +968,16 @@ public final class String return true; } if (anObject instanceof String) { - String anotherString = (String)anObject; - int n = count; - if (n == anotherString.count) { + String anotherString = (String) anObject; + int n = value.length; + if (n == anotherString.value.length) { char v1[] = value; char v2[] = anotherString.value; - int i = offset; - int j = anotherString.offset; + int i = 0; while (n-- != 0) { - if (v1[i++] != v2[j++]) - return false; + if (v1[i] != v2[i]) + return false; + i++; } return true; } Why not simply? : if (anObject instanceof String) { String anotherString = (String) anObject; int n = value.length; if (n == anotherString.value.length) { char v1[] = value; char v2[] = anotherString.value; while (n-- != 0) { if (v1[n] != v2[n]) return false; } return true; } This additionally has the advantage, that mostly the difference would be found quicker, as strings of same length often would differ at the end e.g.: VeryLongText_1 VeryLongText_2 Same for other equals and compare methods. BTW: You again have inserted a space after casts. ;-) -Ulf Am 31.05.2012 05:22, schrieb mike.duigou at oracle.com: > Changeset: 2c773daa825d > Author: mduigou > Date: 2012-05-17 10:06 -0700 > URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2c773daa825d > > 6924259: Remove offset and count fields from java.lang.String > Summary: Removes the use of shared character array buffers by String along with the two fields needed to support the use of shared buffers. > Reviewed-by: alanb, mduigou, forax, briangoetz > Contributed-by: brian.doherty at oracle.com > > ! src/share/classes/java/lang/Integer.java > ! src/share/classes/java/lang/Long.java > ! src/share/classes/java/lang/String.java > ! src/share/classes/java/lang/StringCoding.java > > From joe.darcy at oracle.com Mon Jun 4 18:38:31 2012 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 04 Jun 2012 11:38:31 -0700 Subject: Request for Review(XS): 7156963 Incorrect copyright header in java/io/SerialCallbackContext In-Reply-To: <0FBC0B92-B3EA-4A62-9355-F5FE1E25A5D1@oracle.com> References: <0FBC0B92-B3EA-4A62-9355-F5FE1E25A5D1@oracle.com> Message-ID: <4FCD00A7.4040007@oracle.com> Looks fine, -Joe On 6/4/2012 7:01 AM, Edvard Wendelin wrote: > Please review. In addition to fixing the copyright I also fixed the incorrect indentation of the rest of the file (which is kind of hard to tell from the webrev). > > Bug: 7156963 > > CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7156963 > Synopsis: Incorrect copyright header in java/io/SerialCallbackContext > > Webrev: http://cr.openjdk.java.net/~ewendeli/7156963/webrev.01/ > > Testing: Verified that the JDK compiles properly. > > Thanks, > Edvard From david.holmes at oracle.com Mon Jun 4 23:04:53 2012 From: david.holmes at oracle.com (David Holmes) Date: Tue, 05 Jun 2012 09:04:53 +1000 Subject: Request for Reviews 7173918&7173919: Small follow-ons to alternative hashing In-Reply-To: <4FCCAC6F.5090109@gmx.de> References: <0F20DE59-F151-453C-8CFE-83EBC92E7655@oracle.com> <4FCCAC6F.5090109@gmx.de> Message-ID: <4FCD3F15.9050405@oracle.com> Ulf, As I understand Mike's email, the JDK7 code is not being modified (at this stage at least) to apply the optimizations that have been applied to the JDK8 code. The JDK 7 changes are only to set the default value to 512 (plus that one final field change) David On 4/06/2012 10:39 PM, Ulf Zibis wrote: > Am 04.06.2012 08:08, schrieb Mike Duigou: >> Two small issues related to the larger alternative string hashing >> changes (CR#7126277) from last week. One issue is for JDK 7 and the >> other is for JDK 8. Both are quite small. >> >> For the JDK 7 issue, as documented in the review request, the default >> threshold for the alternative hashing in that patch was set to the >> minimum to unconditionally enable the feature. This was done to make >> compatibility testing easier. Developers are strongly encouraged to >> test their applications with the 7u6b13 build to ensure that their >> applications do not later encounter problems. For the release version >> of 7u6 the default threshold will be set to 512. This patch sets that >> default and marks one field final. >> >> http://cr.openjdk.java.net/~mduigou/7173918/0/webrev/ > *** WeakHashMap > > 353 int hash(Object k) { > 354 > 355 int h; > 356 if (useAltHashing) { > 357 h = hashSeed; > 358 if (k instanceof String) { > 359 return h ^ sun.misc.Hashing.stringHash32((String) k); > 360 } else { > 361 h ^= k.hashCode(); > 362 } > 363 } else { > 364 h = k.hashCode(); > 365 } > > ==> shorter form + better chance for inlining + less less jumps, which > are always kinda expensive: > > 353 int hash(Object k) { > 354 > 355 int h; > 356 if (useAltHashing) { > 357 h = hashSeed; > 358 if (k instanceof String) { > 359 return h ^ sun.misc.Hashing.stringHash32((String)k); > ==> Remove the space after the cast. > 360 } > 361 > 362 h ^= k.hashCode(); > > *** HashMap > doesn't use "(h = hashSeed) ^ ..." for the String case, why? > > *** Hashtable > has completely different design, why? : > - doesn't use instanceof operator > - doesn't use "(h = hashSeed) ^ ..." for general objects > > ==> You again have inserted a spaces after casts. > >> >> The JDK8 issue is number of small performance enhancements suggested >> by Ulf Zibis and Remi Forax. These changes are being considered now >> while this issue remains fresh in the maintainer and reviewer's minds. >> >> http://cr.openjdk.java.net/~mduigou/7173919/0/webrev/ > > 291 if (k instanceof String) { > 292 return ((String) k).hash32(); > ==> You again have inserted a space after the cast. > 293 } > ==> Please add a blank line here as in the other map classes. Otherwise > it would look, that the following line has some context to the before line. > ==> Additionally I would add a comment here, why the legacy behaviour on > general objects is changed in that way. > ==> Maybe it would be more readable/logical to move this line just after > line 298. > 294 int h = hashSeed ^ k.hashCode(); > 295 > 296 // This function ensures that hashCodes that differ only by > 297 // constant multiples at each bit position have a bounded > 298 // number of collisions (approximately 8 at default load factor). > 299 h ^= (h >>> 20) ^ (h >>> 12); > 300 return h ^ (h >>> 7) ^ (h >>> 4); > > Anyway I still would prefer to move the hash(Object) method to > AbstractHashMap. > Additionally while being here, we could review, why ConcurrentHashMap > has a different algorithm. > > -Ulf > > From weijun.wang at oracle.com Tue Jun 5 00:25:37 2012 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 05 Jun 2012 08:25:37 +0800 Subject: Request for Review(XS): 7156963 Incorrect copyright header in java/io/SerialCallbackContext In-Reply-To: <4FCD00A7.4040007@oracle.com> References: <0FBC0B92-B3EA-4A62-9355-F5FE1E25A5D1@oracle.com> <4FCD00A7.4040007@oracle.com> Message-ID: <4FCD5201.8000804@oracle.com> It seems the whole copyright header is one-char shifted to right. -Max On 06/05/2012 02:38 AM, Joe Darcy wrote: > Looks fine, > > -Joe > > On 6/4/2012 7:01 AM, Edvard Wendelin wrote: >> Please review. In addition to fixing the copyright I also fixed the >> incorrect indentation of the rest of the file (which is kind of hard >> to tell from the webrev). >> >> Bug: 7156963 >> >> CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7156963 >> Synopsis: Incorrect copyright header in java/io/SerialCallbackContext >> >> Webrev: http://cr.openjdk.java.net/~ewendeli/7156963/webrev.01/ >> >> Testing: Verified that the JDK compiles properly. >> >> Thanks, >> Edvard From littlee at linux.vnet.ibm.com Tue Jun 5 02:17:19 2012 From: littlee at linux.vnet.ibm.com (littlee at linux.vnet.ibm.com) Date: Tue, 05 Jun 2012 02:17:19 +0000 Subject: hg: jdk8/tl/jdk: 7173044: MemoryMonitor hangs if getMax method in MemoryUsage object returns -1 Message-ID: <20120605021729.8B384476EF@hg.openjdk.java.net> Changeset: 4573662cb28c Author: zhouyx Date: 2012-06-05 10:16 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4573662cb28c 7173044: MemoryMonitor hangs if getMax method in MemoryUsage object returns -1 Reviewed-by: dholmes, sspitsyn ! src/share/demo/management/MemoryMonitor/MemoryMonitor.java From weijun.wang at oracle.com Tue Jun 5 09:12:20 2012 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Tue, 05 Jun 2012 09:12:20 +0000 Subject: hg: jdk8/tl/jdk: 7172701: KDC tests cleanup Message-ID: <20120605091426.A138A476F5@hg.openjdk.java.net> Changeset: 0678af55d3db Author: weijun Date: 2012-06-05 17:11 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0678af55d3db 7172701: KDC tests cleanup Reviewed-by: xuelei ! test/sun/security/krb5/auto/KDC.java ! test/sun/security/krb5/auto/OkAsDelegate.java ! test/sun/security/krb5/auto/OkAsDelegateXRealm.java - test/sun/security/krb5/auto/ok-as-delegate-xrealm.sh - test/sun/security/krb5/auto/ok-as-delegate.sh From forax at univ-mlv.fr Tue Jun 5 10:00:36 2012 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Tue, 05 Jun 2012 12:00:36 +0200 Subject: non-blocking channel Infinite loop in java.util.Scanner Message-ID: <4FCDD8C4.9070106@univ-mlv.fr> One of my student find a bug in the implementation of Scanner, that allows you to use a non blocking channel as input of a Scanner. The Scanner uses Channels.newReader() to create a Reader from a channel which itself create a StreamDecoder. In that case, StreamDecoder.impReader() goes into an infinite loop because impReader() calls readBytes() that does nothing if channel.read() returns zero. The javadoc of Channels.newReader() clearly states that it should throw a IllegalBlockingModeException but there is no code that checks that. I think a way to solve the problem is to insert a code that check the blocking state in Channels.newWriter(). if (ch instanceof SelectableChannel) { SelectableChannel sc = (SelectableChannel)ch; if (!sc.isBlocking()) throw new IllegalBlockingModeException(); } } and to document the exception in the constructor of Scanner that takes a channel. If someone provide me a bug id, it will provide a patch :) cheers, R?mi PS: The code below is a simple test to reproduce the infinite loop. ---------------------------------------------------- import java.io.IOException; import java.net.InetSocketAddress; import java.nio.ByteBuffer; import java.nio.channels.ServerSocketChannel; import java.nio.channels.SocketChannel; import java.util.Scanner; public class Main { public static void main(String[] args) throws IOException { ServerSocketChannel serverSocketChannel = ServerSocketChannel.open(); serverSocketChannel.bind(new InetSocketAddress(2332)); new Thread(new Runnable() { @Override public void run() { try { SocketChannel channel = SocketChannel.open(new InetSocketAddress("localhost", 2332)); do { channel.write(ByteBuffer.wrap(new byte[] {'A'})); Thread.sleep(1000); } while(true); } catch (IOException | InterruptedException e) { throw new AssertionError(e); } } }).start(); SocketChannel socketChannel = serverSocketChannel.accept(); socketChannel.configureBlocking(false); Scanner scanner = new Scanner(socketChannel); while(scanner.hasNextLine()) { System.out.println(scanner.nextLine()); } } } From Alan.Bateman at oracle.com Tue Jun 5 10:40:05 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 05 Jun 2012 11:40:05 +0100 Subject: non-blocking channel Infinite loop in java.util.Scanner In-Reply-To: <4FCDD8C4.9070106@univ-mlv.fr> References: <4FCDD8C4.9070106@univ-mlv.fr> Message-ID: <4FCDE205.3030808@oracle.com> On 05/06/2012 11:00, R?mi Forax wrote: > One of my student find a bug in the implementation of Scanner, > that allows you to use a non blocking channel as input of a Scanner. > > The Scanner uses Channels.newReader() to create a Reader > from a channel which itself create a StreamDecoder. > > In that case, StreamDecoder.impReader() goes into an infinite loop > because impReader() calls readBytes() that does nothing > if channel.read() returns zero. > > The javadoc of Channels.newReader() clearly states that > it should throw a IllegalBlockingModeException but > there is no code that checks that. > > I think a way to solve the problem is to insert a code > that check the blocking state in Channels.newWriter(). > > if (ch instanceof SelectableChannel) { > SelectableChannel sc = (SelectableChannel)ch; > if (!sc.isBlocking()) > throw new IllegalBlockingModeException(); > } > } This could be fixed in Channels.newReader or in StreamDecoder, the former would be consistent with Channels.newWriter. I guess you know this already, but you will need to synchronize on the selectable channel's blockingLock to ensure that the blocking mode doesn't change. I've created a bug for this: 7174305: (ch) Channels.newReader doesn't throw IllegalBlockingMode if channel is configured non-blocking -Alan. From chris.hegarty at oracle.com Tue Jun 5 11:27:17 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 05 Jun 2012 12:27:17 +0100 Subject: [PATCH] 7164256 : EnumMap.clone doesn't clear the entrySet field, keeping a reference to the original Map In-Reply-To: References: <4FC3D9F3.4040602@oracle.com> Message-ID: <4FCDED15.4040303@oracle.com> On 04/06/12 16:33, Diego Belfer wrote: > Hi Alan, > > I've already sent the signed OCA. Will you sponsor the patch ? I don't yet see you listed on the OCA Signatories List [1]. It may just take a little time to process your agreement. -Chris. [1] http://www.oracle.com/technetwork/community/oca-486395.html > > Best, > Diego > > On Mon, May 28, 2012 at 11:37 PM, Diego Belfer wrote: > >> Hi Alan, >> >> Thanks for your reply. I am attaching a new patch and it contains the test >> case now. >> >> I have read the contents of the link you sent me and I believe the OCA >> signature is the only thing that is pending. I will send a signed copy of >> the OCA tomorrow so my change can be applied to the repository once it gets >> approved. >> >> Let me know if I'm missing something. >> >> Best, >> Diego >> >> >> >> # HG changeset patch >> # User muralx >> # Date 1338257674 10800 >> # Node ID f61b94fd7aca738353177fcf3cc3972ddf36cf36 >> >> # Parent 9b8c96f96a0f9a5801b55530a387fefbe50482a3 >> PATCH 7164256 : EnumMap.clone does not clear the instance field entrySet >> >> diff --git a/src/share/classes/java/util/EnumMap.java >> b/src/share/classes/java/util/EnumMap.java >> --- a/src/share/classes/java/util/EnumMap.java >> +++ b/src/share/classes/java/util/EnumMap.java >> @@ -721,6 +721,7 @@ >> throw new AssertionError(); >> } >> result.vals = result.vals.clone(); >> + result.entrySet = null; >> return result; >> } >> >> diff --git a/test/java/util/EnumMap/ProperEntrySetOnClone.java >> b/test/java/util/EnumMap/ProperEntrySetOnClone.java >> new file mode 100644 >> --- /dev/null >> +++ b/test/java/util/EnumMap/ProperEntrySetOnClone.java >> @@ -0,0 +1,58 @@ >> +/* >> + * Copyright (c) 2012, Oracle and/or its affiliates. All rights reserved. >> + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >> + * >> + * This code is free software; you can redistribute it and/or modify it >> + * under the terms of the GNU General Public License version 2 only, as >> + * published by the Free Software Foundation. >> + * >> + * This code is distributed in the hope that it will be useful, but >> WITHOUT >> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or >> + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License >> + * version 2 for more details (a copy is included in the LICENSE file that >> + * accompanied this code). >> + * >> + * You should have received a copy of the GNU General Public License >> version >> + * 2 along with this work; if not, write to the Free Software Foundation, >> + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. >> + * >> + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA >> + * or visit www.oracle.com if you need additional information or have any >> + * questions. >> + */ >> + >> +/* >> + * @test >> + * @bug 7164256 >> + * @summary EnumMap.entrySet() returns an entrySet referencing to the >> cloned instance >> + * @author Diego Belfer >> + */ >> + >> +import java.util.EnumMap; >> + >> +public class ProperEntrySetOnClone { >> + public enum Test { >> + ONE, TWO >> + } >> + >> + public static void main(String[] args) { >> + EnumMap map1 = new EnumMap> String>(Test.class); >> + map1.put(Test.ONE, "1"); >> + map1.put(Test.TWO, "2"); >> + >> + // We need to force creation of the map1.entrySet >> + int size = map1.entrySet().size(); >> + if (size != 2) { >> + throw new RuntimeException( >> + "Invalid size in original map. Expected: 2 was: " + >> size); >> + } >> + >> + EnumMap map2 = map1.clone(); >> + map2.remove(Test.ONE); >> + size = map2.entrySet().size(); >> + if (size != 1) { >> + throw new RuntimeException( >> + "Invalid size in cloned instance. Expected: 1 was: " >> + size); >> + } >> + } >> +} >> >> >> >> On Mon, May 28, 2012 at 5:02 PM, Alan Batemanwrote: >> >>> On 28/05/2012 20:31, Diego Belfer wrote: >>> >>>> Hi, >>>> >>>> The patch seems to have been removed by the mailer. I am adding it >>>> inline. >>>> >>>> Best, >>>> Diego Belfer >>>> [muralx] >>>> >>>> Thanks for the bug report and patch. I think mailman is configured to >>> drop certain types of attachments which would explain why it was missing >>> from your first mail. >>> >>> As you are contributing a fix then I would suggesting going through this >>> page first: >>> >>> http://openjdk.java.net/**contribute/ >>> >>> This explains how to be a contributor. Also note in section 3 that a unit >>> or regression tests should be included where practical. I realize this will >>> be more work than the fix itself but that is often the case. You can find >>> some examples of tests for this area in jdk/test/java/util/EnumMap. >>> >>> -Alan. >>> >>> >> From alan.bateman at oracle.com Tue Jun 5 12:56:05 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Tue, 05 Jun 2012 12:56:05 +0000 Subject: hg: jdk8/tl/jdk: 7173515: (se) Selector.open fails with OOME on Solaris when unlimited file descriptors Message-ID: <20120605125622.6EC16476FF@hg.openjdk.java.net> Changeset: 5ea56641276c Author: alanb Date: 2012-06-05 12:47 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5ea56641276c 7173515: (se) Selector.open fails with OOME on Solaris when unlimited file descriptors Reviewed-by: coffeys, chegar - src/share/classes/sun/nio/ch/DevPollSelectorProvider.java ! src/solaris/classes/sun/nio/ch/DevPollArrayWrapper.java + src/solaris/classes/sun/nio/ch/DevPollSelectorProvider.java From Lance.Andersen at oracle.com Tue Jun 5 14:15:36 2012 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Tue, 5 Jun 2012 10:15:36 -0400 Subject: Fwd: Review request for 7145913 CachedRowSetSwriter.insertNewRow() throws SQLException References: <7A0C9C7C-48E4-422A-9A42-1DAF5263C47C@oracle.com> Message-ID: <8C9D0585-5619-44CC-8770-83AD51505801@oracle.com> Still looking for reviewer Best Lance Begin forwarded message: > From: Lance Andersen - Oracle > Date: May 31, 2012 6:16:16 PM EDT > Cc: core-libs-dev core-libs-dev > Subject: Re: Review request for 7145913 CachedRowSetSwriter.insertNewRow() throws SQLException > > Here is the revision using the try with resources as David suggested > > http://cr.openjdk.java.net/~lancea/7145913/webrev.01/ > > Best > Lance > On May 31, 2012, at 3:10 PM, David Schlosnagle wrote: > >> On Thu, May 31, 2012 at 1:50 PM, Lance Andersen - Oracle >> wrote: >>> Hi, >>> >>> Looking for a reviewer for 7145913. This addresses an issue with where a SQLException could be thrown when writing a row back with an auto-incremented column on some databases. >>> >>> Webrev is http://cr.openjdk.java.net/~lancea/7145913/webrev.00/. RowSet TCK, sqe tests and unit tests all pass with this fix. >> >> Hi Lance, >> >> I had a few quick comments: >> >> * Do you need the multiple calls to CachedResultSet.getObject for the primary >> key, or would it be worthwhile to store the result in a local variable? >> >> * This seems to be pre-existing before your changes, but the PreparedStatement >> pstmtSel and ResultSet rs, rs2 used within the insertNewRow method are never >> closed, which could lead to resource leaks. >> >> * Minor nit, the indentation in this file seems off, especially for the method >> JavaDoc. >> >> I've included a minor cleanup below of the insertNewRow method using >> try-with-resources. >> >> Thanks, >> Dave >> >> >> /** >> * Inserts a row that has been inserted into the given >> * CachedRowSet object into the data source from which >> * the rowset is derived, returning false if the insertion >> * was successful. >> * >> * @param crs the CachedRowSet object that has had a >> row inserted >> * and to whose underlying data source the row will be inserted >> * @param pstmt the PreparedStatement object that will be used >> * to execute the insertion >> * @return false to indicate that the insertion was successful; >> * true otherwise >> * @throws SQLException if a database access error occurs >> */ >> private boolean insertNewRow(CachedRowSet crs, >> PreparedStatement pstmt, CachedRowSetImpl crsRes) throws SQLException { >> >> boolean returnVal = false; >> >> try (PreparedStatement pstmtSel = con.prepareStatement(selectCmd, >> ResultSet.TYPE_SCROLL_SENSITIVE, >> ResultSet.CONCUR_READ_ONLY); >> ResultSet rs = pstmtSel.executeQuery(); >> ResultSet rs2 = con.getMetaData().getPrimaryKeys(null, null, >> crs.getTableName()) >> ) { >> >> ResultSetMetaData rsmd = crs.getMetaData(); >> int icolCount = rsmd.getColumnCount(); >> String[] primaryKeys = new String[icolCount]; >> int k = 0; >> while (rs2.next()) { >> primaryKeys[k] = rs2.getString("COLUMN_NAME"); >> k++; >> } >> >> if (rs.next()) { >> for (String pkName : primaryKeys) { >> if (!isPKNameValid(pkName, rsmd)) { >> >> /* We came here as one of the the primary keys >> * of the table is not present in the cached >> * rowset object, it should be an autoincrement column >> * and not included while creating CachedRowSet >> * Object, proceed to check for other primary keys >> */ >> continue; >> } >> >> Object crsPK = crs.getObject(pkName); >> if (crsPK == null) { >> /* >> * It is possible that the PK is null on some databases >> * and will be filled in at insert time (MySQL >> for example) >> */ >> break; >> } >> >> String rsPK = rs.getObject(pkName).toString(); >> if (crsPK.toString().equals(rsPK)) { >> returnVal = true; >> this.crsResolve.moveToInsertRow(); >> for (int i = 1; i <= icolCount; i++) { >> String colname = >> (rs.getMetaData()).getColumnName(i); >> if (colname.equals(pkName)) >> this.crsResolve.updateObject(i,rsPK); >> else >> this.crsResolve.updateNull(i); >> } >> this.crsResolve.insertRow(); >> this.crsResolve.moveToCurrentRow(); >> } >> } >> } >> >> if (returnVal) { >> return returnVal; >> } >> >> try { >> int i; >> for (i = 1; i <= icolCount; i++) { >> Object obj = crs.getObject(i); >> if (obj != null) { >> pstmt.setObject(i, obj); >> } else { >> pstmt.setNull(i,crs.getMetaData().getColumnType(i)); >> } >> } >> >> i = pstmt.executeUpdate(); >> return false; >> >> } catch (SQLException ex) { >> /* >> * Cursor will come here if executeUpdate fails. >> * There can be many reasons why the insertion failed, >> * one can be violation of primary key. >> * Hence we cannot exactly identify why the insertion failed >> * Present the current row as a null row to the user. >> **/ >> this.crsResolve.moveToInsertRow(); >> >> for (int i = 1; i <= icolCount; i++) { >> this.crsResolve.updateNull(i); >> } >> >> this.crsResolve.insertRow(); >> this.crsResolve.moveToCurrentRow(); >> >> return true; >> } >> } >> } > > > 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 > 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 From Lance.Andersen at oracle.com Tue Jun 5 14:16:09 2012 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Tue, 5 Jun 2012 10:16:09 -0400 Subject: Fwd: Review request for CR 171917 CachedRowSetImpl.populate does not handle map properly References: <73689F85-1321-4642-9F0B-75598029AD00@oracle.com> Message-ID: <5BC5D784-BCBD-4C2B-8874-6128DBABB8BE@oracle.com> Looking for a reviewer here as well still Best Lance Begin forwarded message: > From: Lance Andersen - Oracle > Date: May 26, 2012 9:33:40 AM EDT > Cc: core-libs-dev core-libs-dev > Subject: Re: Review request for CR 171917 CachedRowSetImpl.populate does not handle map properly > > Here is the revised change with David's suggestion. All tests continue to pass > > > new-host-4:rowset lanceandersen$ !hg > hg diff CachedRowSetImpl.java > diff -r 4580652d9828 src/share/classes/com/sun/rowset/CachedRowSetImpl.java > --- a/src/share/classes/com/sun/rowset/CachedRowSetImpl.java Fri May 04 16:00:47 2012 -0400 > +++ b/src/share/classes/com/sun/rowset/CachedRowSetImpl.java Sat May 26 08:43:15 2012 -0400 > @@ -659,7 +659,7 @@ > * us work with drivers that do not support > * getObject with a map in fairly sensible way > */ > - if (map == null) { > + if (map == null || map.isEmpty()) { > obj = data.getObject(i); > } else { > obj = data.getObject(i, map); > > > Best > Lance > On May 25, 2012, at 7:35 PM, David Schlosnagle wrote: > >> On Fri, May 25, 2012 at 3:50 PM, Lance Andersen - Oracle >> wrote: >>> The populate() method needs to check for a size of 0 for the map in case a webrowset xml file has an empty map tag, which would result in calling setobject specifying a map and not all databases/drivers support this. >>> >>> simple 1 line change: >>> >>> hg diff CachedRowSetImpl.java >>> diff -r 4580652d9828 src/share/classes/com/sun/rowset/CachedRowSetImpl.java >>> --- a/src/share/classes/com/sun/rowset/CachedRowSetImpl.java Fri May 04 16:00:47 2012 -0400 >>> +++ b/src/share/classes/com/sun/rowset/CachedRowSetImpl.java Fri May 25 15:45:29 2012 -0400 >>> @@ -659,7 +659,7 @@ >>> * us work with drivers that do not support >>> * getObject with a map in fairly sensible way >>> */ >>> - if (map == null) { >>> + if (map == null || map.size() == 0) { >> >> Lance, >> >> Is there any reason not to use Map.isEmpty() which would be useful if >> the Map has an expensive size() method? >> >> - if (map == null) { >> + if (map == null || map.isEmpty()) { >> >> Thanks, >> Dave > > > 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 > 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 From Lance.Andersen at oracle.com Tue Jun 5 14:17:19 2012 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Tue, 5 Jun 2012 10:17:19 -0400 Subject: Review request CR 7171918 XmlReaderContentHandler.endElement does not handle a Delete Tag properly In-Reply-To: <8967800E-31D0-41C2-A320-9EA35685E0EE@oracle.com> References: <8967800E-31D0-41C2-A320-9EA35685E0EE@oracle.com> Message-ID: <73AAADDD-3106-46B3-80A5-621C40AB1344@oracle.com> Also looking for a reviewer still here. As with the other changes, all SQE, Junit and JCK tests pass Best Lance On May 25, 2012, at 3:56 PM, Lance Andersen - Oracle wrote: > Attached is the fix for 7171918. If a WebRowSet is written to disk that contains a row marked for deletion and then read back into a WebRowSet, it was not marked again as a deleted row. > > Here is the fix to endElement() to address this. > > hg diff XmlReaderContentHandler.java > diff -r 4580652d9828 src/share/classes/com/sun/rowset/internal/XmlReaderContentHandler.java > --- a/src/share/classes/com/sun/rowset/internal/XmlReaderContentHandler.java Fri May 04 16:00:47 2012 -0400 > +++ b/src/share/classes/com/sun/rowset/internal/XmlReaderContentHandler.java Fri May 25 15:52:21 2012 -0400 > @@ -764,6 +764,7 @@ > rs.next(); > rs.setOriginalRow(); > applyUpdates(); > + rs.deleteRow(); > } catch (SQLException ex) { > throw new SAXException(MessageFormat.format(resBundle.handleGetObject("xmlrch.errdel").toString() , ex.getMessage())); > > > Best, > Lance > > > 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 > 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 From kelly.ohair at oracle.com Tue Jun 5 15:01:07 2012 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Tue, 5 Jun 2012 08:01:07 -0700 Subject: Failing jdk testcase: java/lang/Math/WorstCaseTests.java Message-ID: <299AAC76-60DD-40BC-8346-75A114CC37A5@oracle.com> I am seeing this testcase fail on Windows 32&64bit and 32bit Linux&Solaris X86 java/lang/Math/WorstCaseTests.java Does anyone know anything about this? -kto -------------------------------------------------- TEST: java/lang/Math/WorstCaseTests.java JDK under test: (/tmp/jprt/P1/020333.khazra/testproduct/linux_i586_2.6-product) java version "1.8.0-internal" Java(TM) SE Runtime Environment (build 1.8.0-internal-201206050203.khazra.jdk-b00) Java HotSpot(TM) Client VM (build 24.0-b12, mixed mode, sharing) ACTION: build -- Passed. All files up to date REASON: User specified action: run build Tests TIME: 0.001 seconds messages: command: build Tests reason: User specified action: run build Tests elapsed time (seconds): 0.001 ACTION: build -- Passed. Build successful REASON: User specified action: run build WorstCaseTests TIME: 0.091 seconds messages: command: build WorstCaseTests reason: User specified action: run build WorstCaseTests elapsed time (seconds): 0.091 ACTION: compile -- Passed. Compilation successful REASON: .class file out of date or does not exist TIME: 0.091 seconds messages: command: compile /tmp/jprt/P1/020333.khazra/s/test/java/lang/Math/WorstCaseTests.java reason: .class file out of date or does not exist elapsed time (seconds): 0.091 ACTION: build -- Passed. All files up to date REASON: Named class compiled on demand TIME: 0.0 seconds messages: command: build WorstCaseTests reason: Named class compiled on demand elapsed time (seconds): 0.0 ACTION: main -- Failed. Execution failed: `main' threw exception: java.lang.RuntimeException REASON: User specified action: run main WorstCaseTests TIME: 0.046 seconds messages: command: main WorstCaseTests reason: User specified action: run main WorstCaseTests elapsed time (seconds): 0.046 STDERR: Failure for Math.exp: For input -15.273162747858944 (-0x1.e8bdbfcd9144ep3) got 2.327821619714312E-7 (0x1.f3e558cf4de5dp-23); outside of range [2.3278216197143096E-7 (0x1.f3e558cf4de54p-23), 2.3278216197143099E-7 (0x1.f3e558cf4de55p-23)] Failure for Math.exp: For input -5.77934084246919 (-0x1.71e0b869b5e79p2) got 0.0030907520294119885 (0x1.951c6dc5d24dfp-9); outside of range [0.0030907520294119898 (0x1.951c6dc5d24e2p-9), 0.00309075202941199 (0x1.951c6dc5d24e3p-9)] Failure for Math.exp: For input -1.797728508222747 (-0x1.cc37ef7de7501p0) got 0.16567479005430436 (0x1.534d4de870712p-3); outside of range [0.16567479005430438 (0x1.534d4de870713p-3), 0.1656747900543044 (0x1.534d4de870714p-3)] Failure for Math.exp: For input 1.8367220480063033 (0x1.d6336a88077aap0) got 6.27593230200363 (0x1.91a8dff540ff6p2); outside of range [6.275932302003631 (0x1.91a8dff540ff7p2), 6.275932302003632 (0x1.91a8dff540ff8p2)] Failure for Math.exp: For input 11.715807839696332 (0x1.76e7e5d7b6eacp3) got 122492.83772374172 (0x1.de7cd6751029cp16); outside of range [122492.83772374169 (0x1.de7cd6751029ap16), 122492.8377237417 (0x1.de7cd6751029bp16)] Failure for Math.exp: For input 13.278663800537615 (0x1.a8ead058bc6b8p3) got 584588.6991355021 (0x1.1d71965f516aap19); outside of range [584588.6991355025 (0x1.1d71965f516adp19), 584588.6991355026 (0x1.1d71965f516aep19)] Failure for Math.exp: For input 17.83500450381271 (0x1.1d5c2daebe367p4) got 5.567292518201272E7 (0x1.a8c02e974c316p25); outside of range [5.567292518201271E7 (0x1.a8c02e974c314p25), 5.5672925182012714E7 (0x1.a8c02e974c315p25)] Failure for Math.exp: For input 28.26876911181362 (0x1.c44ce0d716a1ap4) got 1.8922148019756777E12 (0x1.b890ca8637ad8p40); outside of range [1.89221480197568E12 (0x1.b890ca8637ae1p40), 1.8922148019756802E12 (0x1.b890ca8637ae2p40)] Testing worst cases incurred 8 failures. java.lang.RuntimeException at WorstCaseTests.main(WorstCaseTests.java:77) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:474) at com.sun.javatest.regtest.MainAction$SameVMRunnable.run(MainAction.java:698) at java.lang.Thread.run(Thread.java:722) JavaTest Message: Test threw exception: java.lang.RuntimeException JavaTest Message: shutting down test TEST RESULT: Failed. Execution failed: `main' threw exception: java.lang.RuntimeException -------------------------------------------------- From ariel at weisberg.ws Tue Jun 5 15:38:04 2012 From: ariel at weisberg.ws (Ariel Weisberg) Date: Tue, 05 Jun 2012 11:38:04 -0400 Subject: JNI UTF-8 encoding bug with some characters Message-ID: <1338910684.32374.140661085271673.2D0E1735@webmail.messagingengine.com> Hi all, Not sure what list this should go to. I found an issue with JNI's GetStringUTFChars which is supposed to return a Java string in UTF-8 encoding. There is an attached test case. I tested on Ubuntu 12.04 (Linux aweisberg-desktop 2.6.32-41-generic #89-Ubuntu SMP Fri Apr 27 22:18:56 UTC 2012 x86_64 GNU/Linux) and CentOS 5 (Linux volt3b 2.6.18-308.4.1.el5 #1 SMP Tue Apr 17 17:08:00 EDT 2012 x86_64 x86_64 x86_64 GNU/Linux) with JDK 6 update 32 and JDK 7 update 4. For the following string "???x?xx?yy?" I find that the first character is encoded correctly, but the second character (http://www.fileformat.info/info/unicode/char/1f032/index.htm) comes out with an invalid code point. The result of String.getBytes("UTF-8") is c3a2f09f80b278e4b8807878c3a97979d4b1 and this matches the output I get from defining the string as a constant in C++. The result of GetStringUTFChars is c3a2eda0bcedb0b278e4b8. See this test case (https://s3.amazonaws.com/com.voltdb.aweisberg/utf8_encoding_bug.tgz) for a reproducer and how I displayed the values. Thanks, Ariel From ariel at weisberg.ws Tue Jun 5 16:06:10 2012 From: ariel at weisberg.ws (Ariel Weisberg) Date: Tue, 05 Jun 2012 12:06:10 -0400 Subject: JNI UTF-8 encoding bug with some characters In-Reply-To: <1338910684.32374.140661085271673.2D0E1735@webmail.messagingengine.com> References: <1338910684.32374.140661085271673.2D0E1735@webmail.messagingengine.com> Message-ID: <1338912370.6413.140661085283809.53D7F96C@webmail.messagingengine.com> Hi, Here is a link to an updated test case that simplifies the string being tested to just the problem character, and fixes a bug in determining the length of the array returned by GetStringUTFChars. https://s3.amazonaws.com/com.voltdb.aweisberg/utf8_encoding_bug2.tgz Thanks, Ariel On Tue, Jun 5, 2012, at 11:38 AM, Ariel Weisberg wrote: > Hi all, > > Not sure what list this should go to. > > I found an issue with JNI's GetStringUTFChars which is supposed to > return a Java string in UTF-8 encoding. There is an attached test case. > I tested on Ubuntu 12.04 (Linux aweisberg-desktop 2.6.32-41-generic > #89-Ubuntu SMP Fri Apr 27 22:18:56 UTC 2012 x86_64 GNU/Linux) and CentOS > 5 (Linux volt3b 2.6.18-308.4.1.el5 #1 SMP Tue Apr 17 17:08:00 EDT 2012 > x86_64 x86_64 x86_64 GNU/Linux) with JDK 6 update 32 and JDK 7 update 4. > > For the following string "???x?xx?yy?" I find that the first character is > encoded correctly, but the second character > (http://www.fileformat.info/info/unicode/char/1f032/index.htm) comes out > with an invalid code point. > > The result of String.getBytes("UTF-8") is > c3a2f09f80b278e4b8807878c3a97979d4b1 and this matches the output I get > from defining the string as a constant in C++. > > The result of GetStringUTFChars is c3a2eda0bcedb0b278e4b8. > > See this test case > (https://s3.amazonaws.com/com.voltdb.aweisberg/utf8_encoding_bug.tgz) > for a reproducer and how I displayed the values. > > Thanks, > Ariel From joe.darcy at oracle.com Tue Jun 5 17:07:27 2012 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 05 Jun 2012 10:07:27 -0700 Subject: Failing jdk testcase: java/lang/Math/WorstCaseTests.java In-Reply-To: <299AAC76-60DD-40BC-8346-75A114CC37A5@oracle.com> References: <299AAC76-60DD-40BC-8346-75A114CC37A5@oracle.com> Message-ID: <4FCE3CCF.8040409@oracle.com> Hi Kelly, There has been some HotSpot work recently to modify the intrinsifications of pow and exp; perhaps this failure is related to 7169934 "pow(x, y) on x64 computes incorrect result when x<0 and y is an odd integer"? -Joe On 6/5/2012 8:01 AM, Kelly O'Hair wrote: > I am seeing this testcase fail on Windows 32&64bit and 32bit Linux&Solaris X86 > java/lang/Math/WorstCaseTests.java > Does anyone know anything about this? > > -kto > > -------------------------------------------------- > TEST: java/lang/Math/WorstCaseTests.java > JDK under test: (/tmp/jprt/P1/020333.khazra/testproduct/linux_i586_2.6-product) > java version "1.8.0-internal" > Java(TM) SE Runtime Environment (build 1.8.0-internal-201206050203.khazra.jdk-b00) > Java HotSpot(TM) Client VM (build 24.0-b12, mixed mode, sharing) > > ACTION: build -- Passed. All files up to date > REASON: User specified action: run build Tests > TIME: 0.001 seconds > messages: > command: build Tests > reason: User specified action: run build Tests > elapsed time (seconds): 0.001 > > ACTION: build -- Passed. Build successful > REASON: User specified action: run build WorstCaseTests > TIME: 0.091 seconds > messages: > command: build WorstCaseTests > reason: User specified action: run build WorstCaseTests > elapsed time (seconds): 0.091 > > ACTION: compile -- Passed. Compilation successful > REASON: .class file out of date or does not exist > TIME: 0.091 seconds > messages: > command: compile /tmp/jprt/P1/020333.khazra/s/test/java/lang/Math/WorstCaseTests.java > reason: .class file out of date or does not exist > elapsed time (seconds): 0.091 > > ACTION: build -- Passed. All files up to date > REASON: Named class compiled on demand > TIME: 0.0 seconds > messages: > command: build WorstCaseTests > reason: Named class compiled on demand > elapsed time (seconds): 0.0 > > ACTION: main -- Failed. Execution failed: `main' threw exception: java.lang.RuntimeException > REASON: User specified action: run main WorstCaseTests > TIME: 0.046 seconds > messages: > command: main WorstCaseTests > reason: User specified action: run main WorstCaseTests > elapsed time (seconds): 0.046 > STDERR: > Failure for Math.exp: > For input -15.273162747858944 (-0x1.e8bdbfcd9144ep3) > got 2.327821619714312E-7 (0x1.f3e558cf4de5dp-23); > outside of range > [2.3278216197143096E-7 (0x1.f3e558cf4de54p-23), 2.3278216197143099E-7 (0x1.f3e558cf4de55p-23)] > Failure for Math.exp: > For input -5.77934084246919 (-0x1.71e0b869b5e79p2) > got 0.0030907520294119885 (0x1.951c6dc5d24dfp-9); > outside of range > [0.0030907520294119898 (0x1.951c6dc5d24e2p-9), 0.00309075202941199 (0x1.951c6dc5d24e3p-9)] > Failure for Math.exp: > For input -1.797728508222747 (-0x1.cc37ef7de7501p0) > got 0.16567479005430436 (0x1.534d4de870712p-3); > outside of range > [0.16567479005430438 (0x1.534d4de870713p-3), 0.1656747900543044 (0x1.534d4de870714p-3)] > Failure for Math.exp: > For input 1.8367220480063033 (0x1.d6336a88077aap0) > got 6.27593230200363 (0x1.91a8dff540ff6p2); > outside of range > [6.275932302003631 (0x1.91a8dff540ff7p2), 6.275932302003632 (0x1.91a8dff540ff8p2)] > Failure for Math.exp: > For input 11.715807839696332 (0x1.76e7e5d7b6eacp3) > got 122492.83772374172 (0x1.de7cd6751029cp16); > outside of range > [122492.83772374169 (0x1.de7cd6751029ap16), 122492.8377237417 (0x1.de7cd6751029bp16)] > Failure for Math.exp: > For input 13.278663800537615 (0x1.a8ead058bc6b8p3) > got 584588.6991355021 (0x1.1d71965f516aap19); > outside of range > [584588.6991355025 (0x1.1d71965f516adp19), 584588.6991355026 (0x1.1d71965f516aep19)] > Failure for Math.exp: > For input 17.83500450381271 (0x1.1d5c2daebe367p4) > got 5.567292518201272E7 (0x1.a8c02e974c316p25); > outside of range > [5.567292518201271E7 (0x1.a8c02e974c314p25), 5.5672925182012714E7 (0x1.a8c02e974c315p25)] > Failure for Math.exp: > For input 28.26876911181362 (0x1.c44ce0d716a1ap4) > got 1.8922148019756777E12 (0x1.b890ca8637ad8p40); > outside of range > [1.89221480197568E12 (0x1.b890ca8637ae1p40), 1.8922148019756802E12 (0x1.b890ca8637ae2p40)] > Testing worst cases incurred 8 failures. > java.lang.RuntimeException > at WorstCaseTests.main(WorstCaseTests.java:77) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:474) > at com.sun.javatest.regtest.MainAction$SameVMRunnable.run(MainAction.java:698) > at java.lang.Thread.run(Thread.java:722) > > JavaTest Message: Test threw exception: java.lang.RuntimeException > JavaTest Message: shutting down test > > > TEST RESULT: Failed. Execution failed: `main' threw exception: java.lang.RuntimeException > -------------------------------------------------- > > From Alan.Bateman at oracle.com Tue Jun 5 17:10:29 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 05 Jun 2012 18:10:29 +0100 Subject: Failing jdk testcase: java/lang/Math/WorstCaseTests.java In-Reply-To: <299AAC76-60DD-40BC-8346-75A114CC37A5@oracle.com> References: <299AAC76-60DD-40BC-8346-75A114CC37A5@oracle.com> Message-ID: <4FCE3D85.5000500@oracle.com> cc'ing Rroland Westrelin, as this may be caused by some of the changes in hs24-b12. Note that jdk8/tl is only sync with b11 and that probably explains why we aren't seeing them here. -Alan On 05/06/2012 16:01, Kelly O'Hair wrote: > I am seeing this testcase fail on Windows 32&64bit and 32bit Linux&Solaris X86 > java/lang/Math/WorstCaseTests.java > Does anyone know anything about this? > > -kto > > -------------------------------------------------- > TEST: java/lang/Math/WorstCaseTests.java > JDK under test: (/tmp/jprt/P1/020333.khazra/testproduct/linux_i586_2.6-product) > java version "1.8.0-internal" > Java(TM) SE Runtime Environment (build 1.8.0-internal-201206050203.khazra.jdk-b00) > Java HotSpot(TM) Client VM (build 24.0-b12, mixed mode, sharing) > > ACTION: build -- Passed. All files up to date > REASON: User specified action: run build Tests > TIME: 0.001 seconds > messages: > command: build Tests > reason: User specified action: run build Tests > elapsed time (seconds): 0.001 > > ACTION: build -- Passed. Build successful > REASON: User specified action: run build WorstCaseTests > TIME: 0.091 seconds > messages: > command: build WorstCaseTests > reason: User specified action: run build WorstCaseTests > elapsed time (seconds): 0.091 > > ACTION: compile -- Passed. Compilation successful > REASON: .class file out of date or does not exist > TIME: 0.091 seconds > messages: > command: compile /tmp/jprt/P1/020333.khazra/s/test/java/lang/Math/WorstCaseTests.java > reason: .class file out of date or does not exist > elapsed time (seconds): 0.091 > > ACTION: build -- Passed. All files up to date > REASON: Named class compiled on demand > TIME: 0.0 seconds > messages: > command: build WorstCaseTests > reason: Named class compiled on demand > elapsed time (seconds): 0.0 > > ACTION: main -- Failed. Execution failed: `main' threw exception: java.lang.RuntimeException > REASON: User specified action: run main WorstCaseTests > TIME: 0.046 seconds > messages: > command: main WorstCaseTests > reason: User specified action: run main WorstCaseTests > elapsed time (seconds): 0.046 > STDERR: > Failure for Math.exp: > For input -15.273162747858944 (-0x1.e8bdbfcd9144ep3) > got 2.327821619714312E-7 (0x1.f3e558cf4de5dp-23); > outside of range > [2.3278216197143096E-7 (0x1.f3e558cf4de54p-23), 2.3278216197143099E-7 (0x1.f3e558cf4de55p-23)] > Failure for Math.exp: > For input -5.77934084246919 (-0x1.71e0b869b5e79p2) > got 0.0030907520294119885 (0x1.951c6dc5d24dfp-9); > outside of range > [0.0030907520294119898 (0x1.951c6dc5d24e2p-9), 0.00309075202941199 (0x1.951c6dc5d24e3p-9)] > Failure for Math.exp: > For input -1.797728508222747 (-0x1.cc37ef7de7501p0) > got 0.16567479005430436 (0x1.534d4de870712p-3); > outside of range > [0.16567479005430438 (0x1.534d4de870713p-3), 0.1656747900543044 (0x1.534d4de870714p-3)] > Failure for Math.exp: > For input 1.8367220480063033 (0x1.d6336a88077aap0) > got 6.27593230200363 (0x1.91a8dff540ff6p2); > outside of range > [6.275932302003631 (0x1.91a8dff540ff7p2), 6.275932302003632 (0x1.91a8dff540ff8p2)] > Failure for Math.exp: > For input 11.715807839696332 (0x1.76e7e5d7b6eacp3) > got 122492.83772374172 (0x1.de7cd6751029cp16); > outside of range > [122492.83772374169 (0x1.de7cd6751029ap16), 122492.8377237417 (0x1.de7cd6751029bp16)] > Failure for Math.exp: > For input 13.278663800537615 (0x1.a8ead058bc6b8p3) > got 584588.6991355021 (0x1.1d71965f516aap19); > outside of range > [584588.6991355025 (0x1.1d71965f516adp19), 584588.6991355026 (0x1.1d71965f516aep19)] > Failure for Math.exp: > For input 17.83500450381271 (0x1.1d5c2daebe367p4) > got 5.567292518201272E7 (0x1.a8c02e974c316p25); > outside of range > [5.567292518201271E7 (0x1.a8c02e974c314p25), 5.5672925182012714E7 (0x1.a8c02e974c315p25)] > Failure for Math.exp: > For input 28.26876911181362 (0x1.c44ce0d716a1ap4) > got 1.8922148019756777E12 (0x1.b890ca8637ad8p40); > outside of range > [1.89221480197568E12 (0x1.b890ca8637ae1p40), 1.8922148019756802E12 (0x1.b890ca8637ae2p40)] > Testing worst cases incurred 8 failures. > java.lang.RuntimeException > at WorstCaseTests.main(WorstCaseTests.java:77) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:474) > at com.sun.javatest.regtest.MainAction$SameVMRunnable.run(MainAction.java:698) > at java.lang.Thread.run(Thread.java:722) > > JavaTest Message: Test threw exception: java.lang.RuntimeException > JavaTest Message: shutting down test > > > TEST RESULT: Failed. Execution failed: `main' threw exception: java.lang.RuntimeException > -------------------------------------------------- > > From xueming.shen at oracle.com Tue Jun 5 17:49:47 2012 From: xueming.shen at oracle.com (Xueming Shen) Date: Tue, 05 Jun 2012 10:49:47 -0700 Subject: JNI UTF-8 encoding bug with some characters In-Reply-To: <1338912370.6413.140661085283809.53D7F96C@webmail.messagingengine.com> References: <1338910684.32374.140661085271673.2D0E1735@webmail.messagingengine.com> <1338912370.6413.140661085283809.53D7F96C@webmail.messagingengine.com> Message-ID: <4FCE46BB.8090403@oracle.com> Hi Ariel, The Java UTF-8 charset (sun.nio.cs.UTF_8) is updated back to jdk7 to follow Unicode Corrigendum [1] (CR#4486841) and is furthered updated in JDK8 (#7096080) to fully conform with the Standard. As the result, the Java UTF-8 charset now only encodes and decodes supplementary character into 4 bytes utf-8 byte sequence. However, we did not do the same thing for vm's jni-utf-8 implementation, which still encode/decodes the supplementary into 6 bytes (pair of surrogates, 3 bytes each). This was the decision we made back then with the assumption that the jni-utf-8 is mainly for "internal" information exchange (you are not supposed to use the result to exchange the information with an "external" system), as long as it provides a round-trip conversion, should be not an issue. The character you are using here is a supplementary character, this is why you are seeing the difference here. -Sherman [1] http://www.unicode.org/versions/corrigendum1.html On 06/05/2012 09:06 AM, Ariel Weisberg wrote: > Hi, > > Here is a link to an updated test case that simplifies the string being > tested to just the problem character, and fixes a bug in determining the > length of the array returned by GetStringUTFChars. > > https://s3.amazonaws.com/com.voltdb.aweisberg/utf8_encoding_bug2.tgz > > Thanks, > Ariel > > On Tue, Jun 5, 2012, at 11:38 AM, Ariel Weisberg wrote: >> Hi all, >> >> Not sure what list this should go to. >> >> I found an issue with JNI's GetStringUTFChars which is supposed to >> return a Java string in UTF-8 encoding. There is an attached test case. >> I tested on Ubuntu 12.04 (Linux aweisberg-desktop 2.6.32-41-generic >> #89-Ubuntu SMP Fri Apr 27 22:18:56 UTC 2012 x86_64 GNU/Linux) and CentOS >> 5 (Linux volt3b 2.6.18-308.4.1.el5 #1 SMP Tue Apr 17 17:08:00 EDT 2012 >> x86_64 x86_64 x86_64 GNU/Linux) with JDK 6 update 32 and JDK 7 update 4. >> >> For the following string "???x?xx?yy?" I find that the first character is >> encoded correctly, but the second character >> (http://www.fileformat.info/info/unicode/char/1f032/index.htm) comes out >> with an invalid code point. >> >> The result of String.getBytes("UTF-8") is >> c3a2f09f80b278e4b8807878c3a97979d4b1 and this matches the output I get >> from defining the string as a constant in C++. >> >> The result of GetStringUTFChars is c3a2eda0bcedb0b278e4b8. >> >> See this test case >> (https://s3.amazonaws.com/com.voltdb.aweisberg/utf8_encoding_bug.tgz) >> for a reproducer and how I displayed the values. >> >> Thanks, >> Ariel From ariel at weisberg.ws Tue Jun 5 18:12:29 2012 From: ariel at weisberg.ws (Ariel Weisberg) Date: Tue, 05 Jun 2012 14:12:29 -0400 Subject: JNI UTF-8 encoding bug with some characters In-Reply-To: <4FCE46BB.8090403@oracle.com> References: <1338910684.32374.140661085271673.2D0E1735@webmail.messagingengine.com> <1338912370.6413.140661085283809.53D7F96C@webmail.messagingengine.com> <4FCE46BB.8090403@oracle.com> Message-ID: <1338919949.32316.140661085340985.467ADD14@webmail.messagingengine.com> Hi, Thanks I will do the conversion in Java then. Ariel On Tue, Jun 5, 2012, at 10:49 AM, Xueming Shen wrote: > Hi Ariel, > > The Java UTF-8 charset (sun.nio.cs.UTF_8) is updated back to jdk7 to > follow Unicode > Corrigendum [1] (CR#4486841) and is furthered updated in JDK8 (#7096080) > to > fully conform with the Standard. As the result, the Java UTF-8 charset > now > only encodes and decodes supplementary character into 4 bytes utf-8 byte > sequence. However, we did not do the same thing for vm's jni-utf-8 > implementation, which still encode/decodes the supplementary into 6 bytes > (pair of surrogates, 3 bytes each). This was the decision we made back > then > with the assumption that the jni-utf-8 is mainly for "internal" > information > exchange (you are not supposed to use the result to exchange the > information > with an "external" system), as long as it provides a round-trip > conversion, > should be not an issue. The character you are using here is a > supplementary > character, this is why you are seeing the difference here. > > -Sherman > > [1] http://www.unicode.org/versions/corrigendum1.html > > On 06/05/2012 09:06 AM, Ariel Weisberg wrote: > > Hi, > > > > Here is a link to an updated test case that simplifies the string being > > tested to just the problem character, and fixes a bug in determining the > > length of the array returned by GetStringUTFChars. > > > > https://s3.amazonaws.com/com.voltdb.aweisberg/utf8_encoding_bug2.tgz > > > > Thanks, > > Ariel > > > > On Tue, Jun 5, 2012, at 11:38 AM, Ariel Weisberg wrote: > >> Hi all, > >> > >> Not sure what list this should go to. > >> > >> I found an issue with JNI's GetStringUTFChars which is supposed to > >> return a Java string in UTF-8 encoding. There is an attached test case. > >> I tested on Ubuntu 12.04 (Linux aweisberg-desktop 2.6.32-41-generic > >> #89-Ubuntu SMP Fri Apr 27 22:18:56 UTC 2012 x86_64 GNU/Linux) and CentOS > >> 5 (Linux volt3b 2.6.18-308.4.1.el5 #1 SMP Tue Apr 17 17:08:00 EDT 2012 > >> x86_64 x86_64 x86_64 GNU/Linux) with JDK 6 update 32 and JDK 7 update 4. > >> > >> For the following string "???x?xx?yy?" I find that the first character is > >> encoded correctly, but the second character > >> (http://www.fileformat.info/info/unicode/char/1f032/index.htm) comes out > >> with an invalid code point. > >> > >> The result of String.getBytes("UTF-8") is > >> c3a2f09f80b278e4b8807878c3a97979d4b1 and this matches the output I get > >> from defining the string as a constant in C++. > >> > >> The result of GetStringUTFChars is c3a2eda0bcedb0b278e4b8. > >> > >> See this test case > >> (https://s3.amazonaws.com/com.voltdb.aweisberg/utf8_encoding_bug.tgz) > >> for a reproducer and how I displayed the values. > >> > >> Thanks, > >> Ariel > From kurchi.subhra.hazra at oracle.com Tue Jun 5 18:36:38 2012 From: kurchi.subhra.hazra at oracle.com (Kurchi Hazra) Date: Tue, 05 Jun 2012 11:36:38 -0700 Subject: Code Review Request: 7173645: (props) System.getProperty("os.name") should return "Windows Server 2012" for Windows Server 2012 Message-ID: <4FCE51B6.5070806@oracle.com> Hi, This is a minor change in java_props_md.c to return "Windows Server 2012" as the "os.name" when running on Windows Server 2012. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7173645 (To appear soon) Webrev: http://cr.openjdk.java.net/~khazra/7173645/webrev.00/ Thanks, Kurchi From xueming.shen at oracle.com Tue Jun 5 19:01:43 2012 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Tue, 05 Jun 2012 19:01:43 +0000 Subject: hg: jdk8/tl/jdk: 6183404: Many eudc characters are incorrectly mapped in MS936 and GBK converter Message-ID: <20120605190152.B7FAC47707@hg.openjdk.java.net> Changeset: d1f52390275b Author: sherman Date: 2012-06-05 12:11 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d1f52390275b 6183404: Many eudc characters are incorrectly mapped in MS936 and GBK converter Summary: updated MS936 and GBK mappings Reviewed-by: alanb ! make/tools/CharsetMapping/GBK.map ! make/tools/CharsetMapping/MS936.map From Alan.Bateman at oracle.com Tue Jun 5 19:17:19 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 05 Jun 2012 20:17:19 +0100 Subject: Code Review Request: 7173645: (props) System.getProperty("os.name") should return "Windows Server 2012" for Windows Server 2012 In-Reply-To: <4FCE51B6.5070806@oracle.com> References: <4FCE51B6.5070806@oracle.com> Message-ID: <4FCE5B3F.6040602@oracle.com> On 05/06/2012 19:36, Kurchi Hazra wrote: > Hi, > > This is a minor change in java_props_md.c to return "Windows Server > 2012" as > the "os.name" when running on Windows Server 2012. > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7173645 (To > appear soon) > Webrev: http://cr.openjdk.java.net/~khazra/7173645/webrev.00/ > > Thanks, > Kurchi > Looks okay to me. -Alan From Alan.Bateman at oracle.com Tue Jun 5 20:53:22 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 05 Jun 2012 21:53:22 +0100 Subject: Failing jdk testcase: java/lang/Math/WorstCaseTests.java In-Reply-To: <97B13958-535E-40BF-AB4B-3922D7EE5DA1@oracle.com> References: <299AAC76-60DD-40BC-8346-75A114CC37A5@oracle.com> <4FCE3D85.5000500@oracle.com> <97B13958-535E-40BF-AB4B-3922D7EE5DA1@oracle.com> Message-ID: <4FCE71C2.1080603@oracle.com> On 05/06/2012 21:04, Roland Westrelin wrote: >> cc'ing Rroland Westrelin, as this may be caused by some of the changes in hs24-b12. Note that jdk8/tl is only sync with b11 and that probably explains why we aren't seeing them here. > Yes, a change we made to speed up pow/exp calculation by relying on x86 fpu instructions broke this test. Is there an existing CR for this failure already? Otherwise I'll file it. > > Roland. I've created: 7174532: jdk/test/java/lang/Math/WorstCaseTests.java failing on x86 -Alan. From forax at univ-mlv.fr Tue Jun 5 23:12:16 2012 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Wed, 06 Jun 2012 01:12:16 +0200 Subject: non-blocking channel Infinite loop in java.util.Scanner In-Reply-To: <4FCDE205.3030808@oracle.com> References: <4FCDD8C4.9070106@univ-mlv.fr> <4FCDE205.3030808@oracle.com> Message-ID: <4FCE9250.3010105@univ-mlv.fr> On 06/05/2012 12:40 PM, Alan Bateman wrote: > On 05/06/2012 11:00, R?mi Forax wrote: >> One of my student find a bug in the implementation of Scanner, >> that allows you to use a non blocking channel as input of a Scanner. >> >> The Scanner uses Channels.newReader() to create a Reader >> from a channel which itself create a StreamDecoder. >> >> In that case, StreamDecoder.impReader() goes into an infinite loop >> because impReader() calls readBytes() that does nothing >> if channel.read() returns zero. >> >> The javadoc of Channels.newReader() clearly states that >> it should throw a IllegalBlockingModeException but >> there is no code that checks that. >> >> I think a way to solve the problem is to insert a code >> that check the blocking state in Channels.newWriter(). >> >> if (ch instanceof SelectableChannel) { >> SelectableChannel sc = (SelectableChannel)ch; >> if (!sc.isBlocking()) >> throw new IllegalBlockingModeException(); >> } >> } > This could be fixed in Channels.newReader or in StreamDecoder, the > former would be consistent with Channels.newWriter. I guess you know > this already, but you will need to synchronize on the selectable > channel's blockingLock to ensure that the blocking mode doesn't change. > > I've created a bug for this: > > 7174305: (ch) Channels.newReader doesn't throw IllegalBlockingMode if > channel is configured non-blocking > > -Alan. Thanks Alan, I can't ensure that the blocking mode will not change by synchronizing on the channel's blockingLock because I will have to take the lock before creating the reader and releasing it when the reader is closed. An easier solution is to throw an IllegalBlockingModeException if the channel.read() returns 0, in that case I think I don't have to even check the configured mode (the question is what to do if the configured mode is changed by another thread between the call to read() and the call to isBlocking()). and BTW isBlocking() already takes the lock, may be the doc of isBlocking() should more clear about that. R?mi From lana.steuck at oracle.com Wed Jun 6 00:47:35 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 06 Jun 2012 00:47:35 +0000 Subject: hg: jdk8/tl: Added tag jdk8-b41 for changeset 1a8c7c530f8a Message-ID: <20120606004735.E728B47717@hg.openjdk.java.net> Changeset: 1ce5dc164166 Author: cl Date: 2012-06-01 14:11 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/1ce5dc164166 Added tag jdk8-b41 for changeset 1a8c7c530f8a ! .hgtags From lana.steuck at oracle.com Wed Jun 6 00:47:37 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 06 Jun 2012 00:47:37 +0000 Subject: hg: jdk8/tl/corba: Added tag jdk8-b41 for changeset 113f0d5f0a08 Message-ID: <20120606004739.23F6047718@hg.openjdk.java.net> Changeset: 79cc42c9c71b Author: cl Date: 2012-06-01 14:12 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/79cc42c9c71b Added tag jdk8-b41 for changeset 113f0d5f0a08 ! .hgtags From lana.steuck at oracle.com Wed Jun 6 00:47:38 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 06 Jun 2012 00:47:38 +0000 Subject: hg: jdk8/tl/jaxp: Added tag jdk8-b41 for changeset 6f5c0e17415d Message-ID: <20120606004747.285DD47719@hg.openjdk.java.net> Changeset: 39ee03c16021 Author: cl Date: 2012-06-01 14:12 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/39ee03c16021 Added tag jdk8-b41 for changeset 6f5c0e17415d ! .hgtags From lana.steuck at oracle.com Wed Jun 6 00:47:45 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 06 Jun 2012 00:47:45 +0000 Subject: hg: jdk8/tl/jaxws: Added tag jdk8-b41 for changeset f2072b164b05 Message-ID: <20120606004748.9DC154771A@hg.openjdk.java.net> Changeset: 1f20f37818a9 Author: cl Date: 2012-06-01 14:12 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/1f20f37818a9 Added tag jdk8-b41 for changeset f2072b164b05 ! .hgtags From lana.steuck at oracle.com Wed Jun 6 00:47:39 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 06 Jun 2012 00:47:39 +0000 Subject: hg: jdk8/tl/langtools: 2 new changesets Message-ID: <20120606004750.11AA04771B@hg.openjdk.java.net> Changeset: 02c5a3575539 Author: cl Date: 2012-06-01 14:12 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/02c5a3575539 Added tag jdk8-b41 for changeset 179fa85aeefa ! .hgtags Changeset: 252f8b7473e1 Author: lana Date: 2012-06-05 17:40 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/252f8b7473e1 Merge From lana.steuck at oracle.com Wed Jun 6 00:47:52 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 06 Jun 2012 00:47:52 +0000 Subject: hg: jdk8/tl/hotspot: 23 new changesets Message-ID: <20120606004840.C4D914771C@hg.openjdk.java.net> Changeset: 03d61caacd1e Author: amurillo Date: 2012-05-18 14:57 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/03d61caacd1e 7170006: new hotspot build - hs24-b12 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 0251d217257f Author: sla Date: 2012-05-08 20:28 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/0251d217257f 7162726: Wrong filter predicate of visible locals in SA JSJavaFrame Reviewed-by: sla, dcubed Contributed-by: Krystal Mok ! agent/src/share/classes/sun/jvm/hotspot/utilities/soql/JSJavaFrame.java Changeset: 7f410b6ea66c Author: dholmes Date: 2012-05-09 00:28 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7f410b6ea66c 7167406: (Zero) Fix for InvokeDynamic needed Reviewed-by: chrisphi, dholmes Contributed-by: Andrew Dinn ! src/cpu/zero/vm/cppInterpreter_zero.cpp Changeset: d506b2cf2ad0 Author: dholmes Date: 2012-05-09 04:32 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d506b2cf2ad0 Merge Changeset: 78d2ae5ab35b Author: nloodin Date: 2012-05-09 16:24 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/78d2ae5ab35b 7163117: Agent can't connect to process on Mac OSX Reviewed-by: dholmes, coleenp, sla, minqi, kvn ! agent/src/share/classes/sun/jvm/hotspot/HotSpotAgent.java ! agent/src/share/classes/sun/jvm/hotspot/bugspot/BugSpotAgent.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/BsdCDebugger.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/bsd/BsdThreadContextFactory.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/proc/ProcDebuggerLocal.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/remote/RemoteDebuggerClient.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/Threads.java ! agent/src/share/classes/sun/jvm/hotspot/ui/classbrowser/HTMLGenerator.java Changeset: 037973617842 Author: kevinw Date: 2012-05-11 17:24 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/037973617842 7157734: hotspot test scripts not testing 64-bit JVM under JPRT/JTREG. Reviewed-by: kvn ! test/compiler/6894807/Test6894807.sh ! test/gc/6941923/test6941923.sh ! test/runtime/6626217/Test6626217.sh ! test/runtime/6878713/Test6878713.sh ! test/runtime/6929067/Test6929067.sh ! test/runtime/7020373/Test7020373.sh ! test/runtime/7051189/Xchecksig.sh ! test/runtime/7158988/TestFieldMonitor.sh Changeset: 2f4819f92dc7 Author: zgu Date: 2012-05-10 18:19 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2f4819f92dc7 Merge - src/share/vm/gc_implementation/concurrentMarkSweep/binaryTreeDictionary.cpp - src/share/vm/gc_implementation/concurrentMarkSweep/binaryTreeDictionary.hpp - src/share/vm/gc_implementation/concurrentMarkSweep/freeBlockDictionary.cpp - src/share/vm/gc_implementation/concurrentMarkSweep/freeBlockDictionary.hpp - src/share/vm/gc_implementation/concurrentMarkSweep/freeList.cpp - src/share/vm/gc_implementation/concurrentMarkSweep/freeList.hpp Changeset: b4f7c4315c36 Author: zgu Date: 2012-05-12 06:50 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b4f7c4315c36 Merge Changeset: 7d4e6dabc6bf Author: dcubed Date: 2012-05-15 10:52 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7d4e6dabc6bf 7165060: dtrace tests fail with FDS debug info files Summary: Work around 'gobjcopy --add-gnu-debuglink' failure by adding a temporary tool that adds the '.gnu_debuglink' section and nothing more. Reviewed-by: sspitsyn, acorn + make/solaris/makefiles/add_gnu_debuglink.make ! make/solaris/makefiles/vm.make + src/os/solaris/add_gnu_debuglink/add_gnu_debuglink.c Changeset: 80b9cc90b643 Author: dcubed Date: 2012-05-15 11:27 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/80b9cc90b643 Merge ! make/solaris/makefiles/defs.make ! make/solaris/makefiles/vm.make Changeset: 9793f47cdebc Author: dcubed Date: 2012-05-15 15:16 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9793f47cdebc 7169102: 7165060 merge lost changes to make/windows/makefiles/defs.make Reviewed-by: sspitsyn, acorn ! make/windows/makefiles/defs.make Changeset: 7432b9db36ff Author: nloodin Date: 2012-05-10 15:44 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7432b9db36ff 7165755: OS Information much longer on linux than other platforms Reviewed-by: sla, dholmes ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/linux/vm/os_linux.hpp ! src/os/posix/vm/os_posix.cpp + src/os/posix/vm/os_posix.hpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/solaris/vm/os_solaris.hpp ! src/os/windows/vm/os_windows.cpp ! src/os/windows/vm/os_windows.hpp ! src/share/vm/runtime/os.hpp Changeset: 198dcc84088c Author: dcubed Date: 2012-05-16 12:47 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/198dcc84088c 7169409: enabling ZIP_DEBUGINFO_FILES causes unexpected test failures on Windows X86 Summary: Disable ZIP_DEBUGINFO_FILES by default on Windows. Reviewed-by: acorn ! make/windows/makefiles/defs.make Changeset: 4b37c0dafe3a Author: dcubed Date: 2012-05-18 09:15 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4b37c0dafe3a 7170010: conditional "ZIP_DEBUGINFO_FILES ?= 0" setting is not reliable on Windows Summary: Always disable ZIP_DEBUGINFO_FILES on Windows. Reviewed-by: acorn ! make/windows/makefiles/defs.make Changeset: cee14a6fc5ac Author: zgu Date: 2012-05-22 20:29 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/cee14a6fc5ac Merge Changeset: 6759698e3140 Author: roland Date: 2012-05-15 10:10 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6759698e3140 7133857: exp() and pow() should use the x87 ISA on x86 Summary: use x87 instructions to implement exp() and pow() in interpreter/c1/c2. Reviewed-by: kvn, never, twisti ! src/cpu/sparc/vm/c1_LIRGenerator_sparc.cpp ! src/cpu/sparc/vm/interpreter_sparc.cpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp ! src/cpu/x86/vm/c1_LinearScan_x86.cpp ! src/cpu/x86/vm/interpreter_x86_32.cpp ! src/cpu/x86/vm/interpreter_x86_64.cpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_LIR.cpp ! src/share/vm/c1/c1_LIR.hpp ! src/share/vm/c1/c1_LIRAssembler.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/c1/c1_LinearScan.cpp ! src/share/vm/interpreter/abstractInterpreter.hpp ! src/share/vm/interpreter/interpreter.cpp ! src/share/vm/interpreter/templateInterpreter.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/subnode.cpp Changeset: 4073d9478a90 Author: roland Date: 2012-05-18 15:50 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4073d9478a90 7167254: Crash on OSX in Enumerator.nextElement() with compressed oops Summary: null checks in "compressed oops with base" mode may trigger a SIGBUS rather than a SIGSEGV. Reviewed-by: dsamersoff, dcubed, rbackman, kvn ! src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp Changeset: cdd249497b34 Author: twisti Date: 2012-05-18 12:20 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/cdd249497b34 7170053: crash in C2 when using -XX:+CountCompiledCalls Reviewed-by: kvn, twisti Contributed-by: Krystal Mok ! src/share/vm/opto/doCall.cpp Changeset: e2961d14584b Author: roland Date: 2012-05-21 09:46 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e2961d14584b 7169934: pow(x,y) or x64 computes incorrect result when x<0 and y is an odd integer Summary: bad test for parity of y in pow(x,y) (c1, interpreter) Reviewed-by: kvn, twisti ! src/cpu/x86/vm/assembler_x86.cpp Changeset: 7089278210e2 Author: kvn Date: 2012-05-24 18:39 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7089278210e2 Merge Changeset: 785573170238 Author: amurillo Date: 2012-05-25 14:45 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/785573170238 Merge Changeset: 37add4fa0296 Author: amurillo Date: 2012-05-25 14:45 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/37add4fa0296 Added tag hs24-b12 for changeset 785573170238 ! .hgtags Changeset: 2040997cba56 Author: cl Date: 2012-06-01 14:12 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2040997cba56 Added tag jdk8-b41 for changeset 37add4fa0296 ! .hgtags From lana.steuck at oracle.com Wed Jun 6 00:47:50 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 06 Jun 2012 00:47:50 +0000 Subject: hg: jdk8/tl/jdk: 5 new changesets Message-ID: <20120606004848.2D3E44771D@hg.openjdk.java.net> Changeset: edb02bee325e Author: ihse Date: 2012-05-25 18:55 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/edb02bee325e 7172014: Remove empty and unused javah include files Reviewed-by: ohair, erikj ! src/share/native/sun/awt/image/cvutils/img_dcm.h ! src/share/native/sun/awt/image/cvutils/img_dcm8.h ! src/share/native/sun/java2d/pipe/SpanClipRenderer.c ! src/solaris/native/sun/awt/initIDs.c Changeset: 8b4dd321b8a2 Author: dholmes Date: 2012-05-30 00:37 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8b4dd321b8a2 7171653: 32-bit cross-compile on 64-bit build host generates 64-bit data for awt/X11 leading to crash Reviewed-by: ohair, anthony ! make/sun/xawt/Makefile ! makefiles/sun/xawt/Makefile Changeset: 4eac56f073ea Author: katleman Date: 2012-05-30 15:59 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4eac56f073ea Merge Changeset: cf5c1f6fbc5b Author: cl Date: 2012-06-01 14:12 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cf5c1f6fbc5b Added tag jdk8-b41 for changeset 4eac56f073ea ! .hgtags Changeset: 91d05db156d3 Author: lana Date: 2012-06-05 17:40 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/91d05db156d3 Merge From david.holmes at oracle.com Wed Jun 6 01:35:55 2012 From: david.holmes at oracle.com (David Holmes) Date: Wed, 06 Jun 2012 11:35:55 +1000 Subject: Code Review Request: 7173645: (props) System.getProperty("os.name") should return "Windows Server 2012" for Windows Server 2012 In-Reply-To: <4FCE51B6.5070806@oracle.com> References: <4FCE51B6.5070806@oracle.com> Message-ID: <4FCEB3FB.6030806@oracle.com> Looks good to me. Pity we can't get a version string from the OS for this. David On 6/06/2012 4:36 AM, Kurchi Hazra wrote: > Hi, > > This is a minor change in java_props_md.c to return "Windows Server > 2012" as > the "os.name" when running on Windows Server 2012. > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7173645 (To > appear soon) > Webrev: http://cr.openjdk.java.net/~khazra/7173645/webrev.00/ > > Thanks, > Kurchi > > From weijun.wang at oracle.com Wed Jun 6 02:06:24 2012 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Wed, 06 Jun 2012 02:06:24 +0000 Subject: hg: jdk8/tl/jdk: 7174351: test/sun/security/tools/keytool/standard.sh failed after new Hashtable Message-ID: <20120606020635.35E2A4772F@hg.openjdk.java.net> Changeset: b6eb10d6932f Author: weijun Date: 2012-06-06 10:05 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b6eb10d6932f 7174351: test/sun/security/tools/keytool/standard.sh failed after new Hashtable Reviewed-by: xuelei ! test/sun/security/tools/keytool/KeyToolTest.java From huizhe.wang at oracle.com Wed Jun 6 03:23:54 2012 From: huizhe.wang at oracle.com (Joe Wang) Date: Tue, 05 Jun 2012 20:23:54 -0700 Subject: [7u6] RFR (JAXP) : 7151118: Regressions on 7u4 b11 comp. 7u4 b06 on specjvm2008.xml.transform subbenchmark Message-ID: <4FCECD4A.1000704@oracle.com> I tested through all of the Xalan updates and found XalanJ-2271 to be the culprit. It [1] was intended to improve performance in webserver environment while resolving unescaped chars in attributes. Unfortunately, it actually resulted in a 5% drop in specjvm2008. I tried to improve the patch, by for example not making mutable copies of the CharInfo objects and etc., but none could get all of the performance loss back. Since it was a proactive update, meaning no one requested it, instead of spending too much time on this issue, I decided to roll the entire patch back. Below is the webrev [2]. [1] https://issues.apache.org/jira/browse/XALANJ-2271 [2] http://cr.openjdk.java.net/~joehw/7u6/cr7151118/webrev/ All unit/sqe/tck tests passed. Please review. Thanks, Joe From chris.hegarty at oracle.com Wed Jun 6 07:41:40 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 06 Jun 2012 08:41:40 +0100 Subject: Code Review Request: 7173645: (props) System.getProperty("os.name") should return "Windows Server 2012" for Windows Server 2012 In-Reply-To: <4FCE51B6.5070806@oracle.com> References: <4FCE51B6.5070806@oracle.com> Message-ID: <4FCF09B4.4060400@oracle.com> Looks fine. -Chris. On 05/06/2012 19:36, Kurchi Hazra wrote: > Hi, > > This is a minor change in java_props_md.c to return "Windows Server > 2012" as > the "os.name" when running on Windows Server 2012. > > Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7173645 (To > appear soon) > Webrev: http://cr.openjdk.java.net/~khazra/7173645/webrev.00/ > > Thanks, > Kurchi > > From Alan.Bateman at oracle.com Wed Jun 6 10:08:00 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 06 Jun 2012 11:08:00 +0100 Subject: non-blocking channel Infinite loop in java.util.Scanner In-Reply-To: <4FCE9250.3010105@univ-mlv.fr> References: <4FCDD8C4.9070106@univ-mlv.fr> <4FCDE205.3030808@oracle.com> <4FCE9250.3010105@univ-mlv.fr> Message-ID: <4FCF2C00.8030905@oracle.com> On 06/06/2012 00:12, R?mi Forax wrote: > > Thanks Alan, > > I can't ensure that the blocking mode will not change by synchronizing on > the channel's blockingLock because I will have to take the lock > before creating the reader and releasing it when the reader is closed. Looking at now, it would need to be done in StreamDecoder.readBytes. > > An easier solution is to throw an IllegalBlockingModeException > if the channel.read() returns 0, in that case I think I don't have to > even check the configured mode > (the question is what to do if the configured mode is changed by > another thread between the call to read() > and the call to isBlocking()). It's possible that read may return bytes immediately when configured non-blocking so it means you will need to check the blocking mode to ensure that the expected IllegalBlockingModeException is thrown. I guess you could also check for 0 to avoid grabbing the blocking lock. -Alan. From Alan.Bateman at oracle.com Wed Jun 6 12:28:39 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 06 Jun 2012 13:28:39 +0100 Subject: [PATCH] 7164256 : EnumMap.clone doesn't clear the entrySet field, keeping a reference to the original Map In-Reply-To: References: <4FC3D9F3.4040602@oracle.com> Message-ID: <4FCF4CF7.5090602@oracle.com> This looks good to me and I'm happy to sponsor this. Does anyone else want to review this? -Alan On 29/05/2012 03:37, Diego Belfer wrote: > : > > # HG changeset patch > # User muralx > # Date 1338257674 10800 > # Node ID f61b94fd7aca738353177fcf3cc3972ddf36cf36 > # Parent 9b8c96f96a0f9a5801b55530a387fefbe50482a3 > PATCH 7164256 : EnumMap.clone does not clear the instance field entrySet > > diff --git a/src/share/classes/java/util/EnumMap.java > b/src/share/classes/java/util/EnumMap.java > --- a/src/share/classes/java/util/EnumMap.java > +++ b/src/share/classes/java/util/EnumMap.java > @@ -721,6 +721,7 @@ > throw new AssertionError(); > } > result.vals = result.vals.clone(); > + result.entrySet = null; > return result; > } > > diff --git a/test/java/util/EnumMap/ProperEntrySetOnClone.java > b/test/java/util/EnumMap/ProperEntrySetOnClone.java > new file mode 100644 > --- /dev/null > +++ b/test/java/util/EnumMap/ProperEntrySetOnClone.java > @@ -0,0 +1,58 @@ > +/* > + * Copyright (c) 2012, Oracle and/or its affiliates. All rights reserved. > + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > + * > + * This code is free software; you can redistribute it and/or modify it > + * under the terms of the GNU General Public License version 2 only, as > + * published by the Free Software Foundation. > + * > + * This code is distributed in the hope that it will be useful, but > WITHOUT > + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or > + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License > + * version 2 for more details (a copy is included in the LICENSE file > that > + * accompanied this code). > + * > + * You should have received a copy of the GNU General Public License > version > + * 2 along with this work; if not, write to the Free Software Foundation, > + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. > + * > + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA > 94065 USA > + * or visit www.oracle.com if you need > additional information or have any > + * questions. > + */ > + > +/* > + * @test > + * @bug 7164256 > + * @summary EnumMap.entrySet() returns an entrySet referencing to the > cloned instance > + * @author Diego Belfer > + */ > + > +import java.util.EnumMap; > + > +public class ProperEntrySetOnClone { > + public enum Test { > + ONE, TWO > + } > + > + public static void main(String[] args) { > + EnumMap map1 = new EnumMap String>(Test.class); > + map1.put(Test.ONE, "1"); > + map1.put(Test.TWO, "2"); > + > + // We need to force creation of the map1.entrySet > + int size = map1.entrySet().size(); > + if (size != 2) { > + throw new RuntimeException( > + "Invalid size in original map. Expected: 2 was: " > + size); > + } > + > + EnumMap map2 = map1.clone(); > + map2.remove(Test.ONE); > + size = map2.entrySet().size(); > + if (size != 1) { > + throw new RuntimeException( > + "Invalid size in cloned instance. Expected: 1 > was: " + size); > + } > + } > +} > From chris.hegarty at oracle.com Wed Jun 6 12:35:16 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 06 Jun 2012 13:35:16 +0100 Subject: [PATCH] 7164256 : EnumMap.clone doesn't clear the entrySet field, keeping a reference to the original Map In-Reply-To: <4FCF4CF7.5090602@oracle.com> References: <4FC3D9F3.4040602@oracle.com> <4FCF4CF7.5090602@oracle.com> Message-ID: <4FCF4E84.6020209@oracle.com> On 06/06/2012 13:28, Alan Bateman wrote: > > This looks good to me and I'm happy to sponsor this. Does anyone else > want to review this? The changes look fine to me too. -Chris. > > -Alan > > > On 29/05/2012 03:37, Diego Belfer wrote: >> : >> >> # HG changeset patch >> # User muralx >> # Date 1338257674 10800 >> # Node ID f61b94fd7aca738353177fcf3cc3972ddf36cf36 >> # Parent 9b8c96f96a0f9a5801b55530a387fefbe50482a3 >> PATCH 7164256 : EnumMap.clone does not clear the instance field entrySet >> >> diff --git a/src/share/classes/java/util/EnumMap.java >> b/src/share/classes/java/util/EnumMap.java >> --- a/src/share/classes/java/util/EnumMap.java >> +++ b/src/share/classes/java/util/EnumMap.java >> @@ -721,6 +721,7 @@ >> throw new AssertionError(); >> } >> result.vals = result.vals.clone(); >> + result.entrySet = null; >> return result; >> } >> >> diff --git a/test/java/util/EnumMap/ProperEntrySetOnClone.java >> b/test/java/util/EnumMap/ProperEntrySetOnClone.java >> new file mode 100644 >> --- /dev/null >> +++ b/test/java/util/EnumMap/ProperEntrySetOnClone.java >> @@ -0,0 +1,58 @@ >> +/* >> + * Copyright (c) 2012, Oracle and/or its affiliates. All rights >> reserved. >> + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >> + * >> + * This code is free software; you can redistribute it and/or modify it >> + * under the terms of the GNU General Public License version 2 only, as >> + * published by the Free Software Foundation. >> + * >> + * This code is distributed in the hope that it will be useful, but >> WITHOUT >> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or >> + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License >> + * version 2 for more details (a copy is included in the LICENSE file >> that >> + * accompanied this code). >> + * >> + * You should have received a copy of the GNU General Public License >> version >> + * 2 along with this work; if not, write to the Free Software >> Foundation, >> + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. >> + * >> + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA >> 94065 USA >> + * or visit www.oracle.com if you need >> additional information or have any >> + * questions. >> + */ >> + >> +/* >> + * @test >> + * @bug 7164256 >> + * @summary EnumMap.entrySet() returns an entrySet referencing to the >> cloned instance >> + * @author Diego Belfer >> + */ >> + >> +import java.util.EnumMap; >> + >> +public class ProperEntrySetOnClone { >> + public enum Test { >> + ONE, TWO >> + } >> + >> + public static void main(String[] args) { >> + EnumMap map1 = new EnumMap(Test.class); >> + map1.put(Test.ONE, "1"); >> + map1.put(Test.TWO, "2"); >> + >> + // We need to force creation of the map1.entrySet >> + int size = map1.entrySet().size(); >> + if (size != 2) { >> + throw new RuntimeException( >> + "Invalid size in original map. Expected: 2 was: " + size); >> + } >> + >> + EnumMap map2 = map1.clone(); >> + map2.remove(Test.ONE); >> + size = map2.entrySet().size(); >> + if (size != 1) { >> + throw new RuntimeException( >> + "Invalid size in cloned instance. Expected: 1 was: " + size); >> + } >> + } >> +} >> > From forax at univ-mlv.fr Wed Jun 6 14:47:32 2012 From: forax at univ-mlv.fr (=?utf-8?B?UmVtaSBGb3JheA==?=) Date: Wed, 06 Jun 2012 16:47:32 +0200 Subject: =?utf-8?B?UmU6IFtQQVRDSF0gNzE2NDI1NiA6IEVudW1NYXAuY2xvbmUgZG9lc24ndCBjbGVhciB0aGUgZW50cnlTZXQgZmllbGQsCWtlZXBpbmcgYSByZWZlcmVuY2UgdG8gdGhlIG9yaWdpbmFsIE1hcA==?= Message-ID: <201206061447.q56El8Ub020929@monge.univ-mlv.fr> Yes, looks good to me too. Cheers, R?mi ----- Reply message ----- From: "Chris Hegarty" To: "Alan Bateman" Cc: Subject: [PATCH] 7164256 : EnumMap.clone doesn't clear the entrySet field, keeping a reference to the original Map Date: Wed, Jun 6, 2012 14:35 On 06/06/2012 13:28, Alan Bateman wrote: > > This looks good to me and I'm happy to sponsor this. Does anyone else > want to review this? The changes look fine to me too. -Chris. > > -Alan > > > On 29/05/2012 03:37, Diego Belfer wrote: >> : >> >> # HG changeset patch >> # User muralx >> # Date 1338257674 10800 >> # Node ID f61b94fd7aca738353177fcf3cc3972ddf36cf36 >> # Parent 9b8c96f96a0f9a5801b55530a387fefbe50482a3 >> PATCH 7164256 : EnumMap.clone does not clear the instance field entrySet >> >> diff --git a/src/share/classes/java/util/EnumMap.java >> b/src/share/classes/java/util/EnumMap.java >> --- a/src/share/classes/java/util/EnumMap.java >> +++ b/src/share/classes/java/util/EnumMap.java >> @@ -721,6 +721,7 @@ >> throw new AssertionError(); >> } >> result.vals = result.vals.clone(); >> + result.entrySet = null; >> return result; >> } >> >> diff --git a/test/java/util/EnumMap/ProperEntrySetOnClone.java >> b/test/java/util/EnumMap/ProperEntrySetOnClone.java >> new file mode 100644 >> --- /dev/null >> +++ b/test/java/util/EnumMap/ProperEntrySetOnClone.java >> @@ -0,0 +1,58 @@ >> +/* >> + * Copyright (c) 2012, Oracle and/or its affiliates. All rights >> reserved. >> + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >> + * >> + * This code is free software; you can redistribute it and/or modify it >> + * under the terms of the GNU General Public License version 2 only, as >> + * published by the Free Software Foundation. >> + * >> + * This code is distributed in the hope that it will be useful, but >> WITHOUT >> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or >> + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License >> + * version 2 for more details (a copy is included in the LICENSE file >> that >> + * accompanied this code). >> + * >> + * You should have received a copy of the GNU General Public License >> version >> + * 2 along with this work; if not, write to the Free Software >> Foundation, >> + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. >> + * >> + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA >> 94065 USA >> + * or visit www.oracle.com if you need >> additional information or have any >> + * questions. >> + */ >> + >> +/* >> + * @test >> + * @bug 7164256 >> + * @summary EnumMap.entrySet() returns an entrySet referencing to the >> cloned instance >> + * @author Diego Belfer >> + */ >> + >> +import java.util.EnumMap; >> + >> +public class ProperEntrySetOnClone { >> + public enum Test { >> + ONE, TWO >> + } >> + >> + public static void main(String[] args) { >> + EnumMap map1 = new EnumMap(Test.class); >> + map1.put(Test.ONE, "1"); >> + map1.put(Test.TWO, "2"); >> + >> + // We need to force creation of the map1.entrySet >> + int size = map1.entrySet().size(); >> + if (size != 2) { >> + throw new RuntimeException( >> + "Invalid size in original map. Expected: 2 was: " + size); >> + } >> + >> + EnumMap map2 = map1.clone(); >> + map2.remove(Test.ONE); >> + size = map2.entrySet().size(); >> + if (size != 1) { >> + throw new RuntimeException( >> + "Invalid size in cloned instance. Expected: 1 was: " + size); >> + } >> + } >> +} >> > From dl at cs.oswego.edu Wed Jun 6 16:22:19 2012 From: dl at cs.oswego.edu (Doug Lea) Date: Wed, 06 Jun 2012 12:22:19 -0400 Subject: An Alternative Hashing Alternative Message-ID: <4FCF83BB.9070808@cs.oswego.edu> I just posted the following to the concurrency-interest list. I'll send a follow-up on tie-ins to core-lib issues next. ... Finally acting on an old idea, I committed an update to ConcurrentHashMap (currently only the one in our jdk8 preview package, as jsr166e.ConcurrentHashMap8) that much more gracefully handles maps that are huge or have many keys with colliding hash codes. Internally, it uses tree-map-like structures to maintain bins containing more nodes than would be expected under ideal random key distributions over ideal numbers of bins. Among other things, this provides graceful (O log(N)) degradation when there are more than about a billion elements (which run out of 32bit hash resolution and array bound limits). However, the map can only do so if keys are Comparable, which is true of most keys in practice -- Strings, Longs, etc. Without relying on Comparable, we can't otherwise magically find any other means to further resolve and organize keys after running out of bits, so performance for non-Comparable keys is unaffected/unimproved. This also provides a mechanism for coping with hostile usages in which many keys (Strings in particular) are somehow constructed to have the same hashCode, which can lead to algorithmic denial of service attacks (because of linear-time bin searches) if code using the map don't screen external inputs. The overflow-tree-based strategy here is an alternative approach to adding secondary randomly-seeded hash code methods ("hash32") to class String, as has been committed recently to OpenJDK. But ConcurrentHashMap8 doesn't doesn't rely on this. The use of overflow-bins also allowed a few other minor speedups in more typical usages. A few more small improvements are still left unfinished for now. (I'll be traveling and/or otherwise committed for most of the next few weeks.) Links: jsr166e.jar: http://gee.cs.oswego.edu/dl/jsr166/dist/jsr166e.jar source: http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/jsr166e/ConcurrentHashMapV8.java?view=log Please give this a try and let me know about experiences. -Doug From crazybob at crazybob.org Wed Jun 6 16:39:15 2012 From: crazybob at crazybob.org (Bob Lee) Date: Wed, 6 Jun 2012 09:39:15 -0700 Subject: An Alternative Hashing Alternative In-Reply-To: <4FCF83BB.9070808@cs.oswego.edu> References: <4FCF83BB.9070808@cs.oswego.edu> Message-ID: Whoa! This is awesome. Bob On Wed, Jun 6, 2012 at 9:22 AM, Doug Lea
wrote: > > I just posted the following to the concurrency-interest list. > I'll send a follow-up on tie-ins to core-lib issues next. > > ... > > > Finally acting on an old idea, I committed an update to > ConcurrentHashMap (currently only the one in our jdk8 preview > package, as jsr166e.ConcurrentHashMap8) that much more gracefully > handles maps that are huge or have many keys with colliding > hash codes. Internally, it uses tree-map-like structures to > maintain bins containing more nodes than would be expected > under ideal random key distributions over ideal numbers of bins. > > Among other things, this provides graceful (O log(N)) degradation when > there are more than about a billion elements (which run out of 32bit > hash resolution and array bound limits). However, the map can only > do so if keys are Comparable, which is true of most keys in > practice -- Strings, Longs, etc. Without relying on Comparable, > we can't otherwise magically find any other means to further > resolve and organize keys after running out of bits, so performance > for non-Comparable keys is unaffected/unimproved. > > This also provides a mechanism for coping with hostile usages in > which many keys (Strings in particular) are somehow constructed to > have the same hashCode, which can lead to algorithmic denial > of service attacks (because of linear-time bin searches) if > code using the map don't screen external inputs. The overflow-tree-based > strategy here is an alternative approach to adding secondary > randomly-seeded hash code methods ("hash32") to class String, > as has been committed recently to OpenJDK. But ConcurrentHashMap8 > doesn't doesn't rely on this. > > The use of overflow-bins also allowed a few other minor speedups > in more typical usages. A few more small improvements are still > left unfinished for now. (I'll be traveling and/or otherwise > committed for most of the next few weeks.) > > Links: > jsr166e.jar: http://gee.cs.oswego.edu/dl/**jsr166/dist/jsr166e.jar > source: http://gee.cs.oswego.edu/cgi-**bin/viewcvs.cgi/jsr166/src/** > jsr166e/ConcurrentHashMapV8.**java?view=log > > Please give this a try and let me know about experiences. > > -Doug > > -- Bob Square is hiring! From dl at cs.oswego.edu Wed Jun 6 16:51:10 2012 From: dl at cs.oswego.edu (Doug Lea) Date: Wed, 06 Jun 2012 12:51:10 -0400 Subject: An Alternative Hashing Alternative In-Reply-To: <4FCF83BB.9070808@cs.oswego.edu> References: <4FCF83BB.9070808@cs.oswego.edu> Message-ID: <4FCF8A7E.5030000@cs.oswego.edu> On 06/06/12 12:22, Doug Lea wrote: > > I just posted the following to the concurrency-interest list. I'll send a > follow-up on tie-ins to core-lib issues next. The main issue is whether adding generic overflow-handling techniques to hash table classes (as used here for ConcurrentHashMap, but variations are applicable with a lot of effort to others) are a better solution than special-casing a better String hash method (i.e., the hash32 changes). My current sense is that they are: * They also address the huge-map problem (although not as well as would be the case if we had 64bit arrays and hash codes, but that is not happening anytime soon). * They work for types other than String (although still only for Comparables), and improve performance when hashes are merely poorly distributed, not hostilely identical. * They avoid the need for a cascading series of related OpenJDK updates. * Normal-case (non-hostile etc) throughput is better. On the other hand: Worst-case throughput using this approach for hostile Strings cannot be quite as good as using better, randomly-seeded hash functions. However, so long as the worst case is no worse than other ways to hostilely annoy busy servers etc, it is not clear to me that the hash32 approach is worthwhile. I don't have any factual basis for concluding this though, since I don't have full test setup for VU#903934. If anyone else does, I'd be interested in hearing about results. One more semi-related follow-up while I am at it: On 06/01/12 16:05, Eamonn McManus wrote: > There's also a performance problem in that accesses start becoming linear > once there are more than 1<< 30 entries, but fixing that is substantially > harder than just fixing size(), and ConcurrentHashMap already provides a > better alternative for such huge maps. > Well, it does now in CHMV8. But before, even though it used segmented arrays, there are still only 32bits of hash code, so keys still collided. -Doug From alan.bateman at oracle.com Wed Jun 6 17:02:14 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Wed, 06 Jun 2012 17:02:14 +0000 Subject: hg: jdk8/tl/jdk: 7172826: (se) Selector based on the Solaris event port mechanism Message-ID: <20120606170234.9E65A4774E@hg.openjdk.java.net> Changeset: 119c9a306a3d Author: alanb Date: 2012-06-06 17:59 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/119c9a306a3d 7172826: (se) Selector based on the Solaris event port mechanism Reviewed-by: coffeys, chegar ! make/java/nio/Makefile ! make/java/nio/mapfile-linux ! make/java/nio/mapfile-solaris ! src/share/classes/sun/nio/ch/IOUtil.java ! src/solaris/classes/sun/nio/ch/DevPollArrayWrapper.java ! src/solaris/classes/sun/nio/ch/EPollArrayWrapper.java + src/solaris/classes/sun/nio/ch/EventPortSelectorImpl.java + src/solaris/classes/sun/nio/ch/EventPortSelectorProvider.java + src/solaris/classes/sun/nio/ch/EventPortWrapper.java ! src/solaris/classes/sun/nio/ch/SolarisEventPort.java ! src/solaris/native/sun/nio/ch/DevPollArrayWrapper.c ! src/solaris/native/sun/nio/ch/EPollArrayWrapper.c ! src/solaris/native/sun/nio/ch/IOUtil.c ! src/solaris/native/sun/nio/ch/SolarisEventPort.c ! test/java/nio/channels/Selector/lots_of_updates.sh ! test/java/nio/channels/SocketChannel/Open.sh ! test/sun/nio/ch/SelProvider.java From forax at univ-mlv.fr Wed Jun 6 17:09:36 2012 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Wed, 06 Jun 2012 19:09:36 +0200 Subject: An Alternative Hashing Alternative In-Reply-To: <4FCF8A7E.5030000@cs.oswego.edu> References: <4FCF83BB.9070808@cs.oswego.edu> <4FCF8A7E.5030000@cs.oswego.edu> Message-ID: <4FCF8ED0.7000602@univ-mlv.fr> I haven't read the whole code (I need a blackboard :) I wonder if it's not better to use unsafe.tryMonitorEnter() instead of a lock bit. Also the class depends on LongAdder, is it a requirement or an AtomicLongUpdater can be used ? cheers, R?mi On 06/06/2012 06:51 PM, Doug Lea wrote: > On 06/06/12 12:22, Doug Lea wrote: >> >> I just posted the following to the concurrency-interest list. I'll >> send a >> follow-up on tie-ins to core-lib issues next. > > The main issue is whether adding generic overflow-handling techniques > to hash table classes (as used here for ConcurrentHashMap, but > variations are applicable with a lot of effort to others) > are a better solution than special-casing a better String hash method > (i.e., the hash32 changes). My current sense is that they are: > > * They also address the huge-map problem (although not as well > as would be the case if we had 64bit arrays and hash codes, but that > is not happening anytime soon). > > * They work for types other than String (although still only for > Comparables), and improve performance when hashes are merely > poorly distributed, not hostilely identical. > > * They avoid the need for a cascading series of related OpenJDK > updates. > > * Normal-case (non-hostile etc) throughput is better. > > On the other hand: Worst-case throughput using this approach > for hostile Strings cannot be quite as good as using better, > randomly-seeded hash functions. However, so long as the worst > case is no worse than other ways to hostilely annoy busy servers > etc, it is not clear to me that the hash32 approach is worthwhile. > I don't have any factual basis for concluding this though, since > I don't have full test setup for VU#903934. If anyone else does, > I'd be interested in hearing about results. > > One more semi-related follow-up while I am at it: > > On 06/01/12 16:05, Eamonn McManus wrote: >> There's also a performance problem in that accesses start becoming >> linear >> once there are more than 1<< 30 entries, but fixing that is >> substantially >> harder than just fixing size(), and ConcurrentHashMap already provides a >> better alternative for such huge maps. >> > > Well, it does now in CHMV8. But before, even though it used segmented > arrays, there are still only 32bits of hash code, so keys still > collided. > > -Doug > From dl at cs.oswego.edu Wed Jun 6 17:23:07 2012 From: dl at cs.oswego.edu (Doug Lea) Date: Wed, 06 Jun 2012 13:23:07 -0400 Subject: An Alternative Hashing Alternative In-Reply-To: <4FCF8ED0.7000602@univ-mlv.fr> References: <4FCF83BB.9070808@cs.oswego.edu> <4FCF8A7E.5030000@cs.oswego.edu> <4FCF8ED0.7000602@univ-mlv.fr> Message-ID: <4FCF91FB.3090308@cs.oswego.edu> On 06/06/12 13:09, R?mi Forax wrote: > I haven't read the whole code (I need a blackboard :) (The mostly-non-blocking retries here lead to a lot of code sprawl. Macros would help :-) > I wonder if it's not better to use unsafe.tryMonitorEnter() > instead of a lock bit. I need a lock with a form of tryLock, so while I do use built-in monitors and/or AQS for actual locking, I need to preface use with lock bit in regular non-tree-bins. > > Also the class depends on LongAdder, is it a requirement or an AtomicLongUpdater > can be used ? If this ever makes it as far as contemplating JDK7 ports, a minimal form of LongAdder could be pulled in as a static inner class. -Doug From mike.duigou at oracle.com Wed Jun 6 18:28:37 2012 From: mike.duigou at oracle.com (Mike Duigou) Date: Wed, 6 Jun 2012 11:28:37 -0700 Subject: [PATCH] 7164256 : EnumMap.clone doesn't clear the entrySet field, keeping a reference to the original Map In-Reply-To: <201206061447.q56El8Ub020929@monge.univ-mlv.fr> References: <201206061447.q56El8Ub020929@monge.univ-mlv.fr> Message-ID: Looks good to me as well. Mike On Jun 6 2012, at 07:47 , Remi Forax wrote: > Yes, looks good to me too. > > Cheers, > R?mi > > ----- Reply message ----- > From: "Chris Hegarty" > To: "Alan Bateman" > Cc: > Subject: [PATCH] 7164256 : EnumMap.clone doesn't clear the entrySet field, keeping a reference to the original Map > Date: Wed, Jun 6, 2012 14:35 > > > On 06/06/2012 13:28, Alan Bateman wrote: >> >> This looks good to me and I'm happy to sponsor this. Does anyone else >> want to review this? > > The changes look fine to me too. > > -Chris. > >> >> -Alan >> >> >> On 29/05/2012 03:37, Diego Belfer wrote: >>> : >>> >>> # HG changeset patch >>> # User muralx >>> # Date 1338257674 10800 >>> # Node ID f61b94fd7aca738353177fcf3cc3972ddf36cf36 >>> # Parent 9b8c96f96a0f9a5801b55530a387fefbe50482a3 >>> PATCH 7164256 : EnumMap.clone does not clear the instance field entrySet >>> >>> diff --git a/src/share/classes/java/util/EnumMap.java >>> b/src/share/classes/java/util/EnumMap.java >>> --- a/src/share/classes/java/util/EnumMap.java >>> +++ b/src/share/classes/java/util/EnumMap.java >>> @@ -721,6 +721,7 @@ >>> throw new AssertionError(); >>> } >>> result.vals = result.vals.clone(); >>> + result.entrySet = null; >>> return result; >>> } >>> >>> diff --git a/test/java/util/EnumMap/ProperEntrySetOnClone.java >>> b/test/java/util/EnumMap/ProperEntrySetOnClone.java >>> new file mode 100644 >>> --- /dev/null >>> +++ b/test/java/util/EnumMap/ProperEntrySetOnClone.java >>> @@ -0,0 +1,58 @@ >>> +/* >>> + * Copyright (c) 2012, Oracle and/or its affiliates. All rights >>> reserved. >>> + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >>> + * >>> + * This code is free software; you can redistribute it and/or modify it >>> + * under the terms of the GNU General Public License version 2 only, as >>> + * published by the Free Software Foundation. >>> + * >>> + * This code is distributed in the hope that it will be useful, but >>> WITHOUT >>> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or >>> + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License >>> + * version 2 for more details (a copy is included in the LICENSE file >>> that >>> + * accompanied this code). >>> + * >>> + * You should have received a copy of the GNU General Public License >>> version >>> + * 2 along with this work; if not, write to the Free Software >>> Foundation, >>> + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. >>> + * >>> + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA >>> 94065 USA >>> + * or visit www.oracle.com if you need >>> additional information or have any >>> + * questions. >>> + */ >>> + >>> +/* >>> + * @test >>> + * @bug 7164256 >>> + * @summary EnumMap.entrySet() returns an entrySet referencing to the >>> cloned instance >>> + * @author Diego Belfer >>> + */ >>> + >>> +import java.util.EnumMap; >>> + >>> +public class ProperEntrySetOnClone { >>> + public enum Test { >>> + ONE, TWO >>> + } >>> + >>> + public static void main(String[] args) { >>> + EnumMap map1 = new EnumMap(Test.class); >>> + map1.put(Test.ONE, "1"); >>> + map1.put(Test.TWO, "2"); >>> + >>> + // We need to force creation of the map1.entrySet >>> + int size = map1.entrySet().size(); >>> + if (size != 2) { >>> + throw new RuntimeException( >>> + "Invalid size in original map. Expected: 2 was: " + size); >>> + } >>> + >>> + EnumMap map2 = map1.clone(); >>> + map2.remove(Test.ONE); >>> + size = map2.entrySet().size(); >>> + if (size != 1) { >>> + throw new RuntimeException( >>> + "Invalid size in cloned instance. Expected: 1 was: " + size); >>> + } >>> + } >>> +} >>> >> From kurchi.subhra.hazra at oracle.com Wed Jun 6 18:37:53 2012 From: kurchi.subhra.hazra at oracle.com (kurchi.subhra.hazra at oracle.com) Date: Wed, 06 Jun 2012 18:37:53 +0000 Subject: hg: jdk8/tl/jdk: 7173645: (props) System.getProperty("os.name") should return "Windows Server 2012" for Windows Server 2012 Message-ID: <20120606183809.8E28647757@hg.openjdk.java.net> Changeset: af313ded4ffb Author: khazra Date: 2012-06-06 11:37 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/af313ded4ffb 7173645: (props) System.getProperty("os.name") should return "Windows Server 2012" for Windows Server 2012 Summary: Enable Windows Server 2012 to be recognized as "os.name" Reviewed-by: alanb, dholmes, chegar ! src/windows/native/java/lang/java_props_md.c From forax at univ-mlv.fr Wed Jun 6 19:03:38 2012 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Wed, 06 Jun 2012 21:03:38 +0200 Subject: An Alternative Hashing Alternative In-Reply-To: <4FCF91FB.3090308@cs.oswego.edu> References: <4FCF83BB.9070808@cs.oswego.edu> <4FCF8A7E.5030000@cs.oswego.edu> <4FCF8ED0.7000602@univ-mlv.fr> <4FCF91FB.3090308@cs.oswego.edu> Message-ID: <4FCFA98A.6040609@univ-mlv.fr> On 06/06/2012 07:23 PM, Doug Lea wrote: > On 06/06/12 13:09, R?mi Forax wrote: >> I haven't read the whole code (I need a blackboard :) > > (The mostly-non-blocking retries here lead to a lot of code sprawl. > Macros would help :-) > >> I wonder if it's not better to use unsafe.tryMonitorEnter() >> instead of a lock bit. > > I need a lock with a form of tryLock, so while I do use built-in > monitors and/or AQS for actual locking, I need to preface use with > lock bit > in regular non-tree-bins. tryMonitorEnter is the equivalent of tryLock for synchronized block (monitorEnter/monitorExit). > >> >> Also the class depends on LongAdder, is it a requirement or an >> AtomicLongUpdater >> can be used ? > > If this ever makes it as far as contemplating JDK7 ports, a minimal > form of LongAdder could be pulled in as a static inner class. > > -Doug > R?mi From dl at cs.oswego.edu Wed Jun 6 19:09:31 2012 From: dl at cs.oswego.edu (Doug Lea) Date: Wed, 06 Jun 2012 15:09:31 -0400 Subject: An Alternative Hashing Alternative In-Reply-To: <4FCFA98A.6040609@univ-mlv.fr> References: <4FCF83BB.9070808@cs.oswego.edu> <4FCF8A7E.5030000@cs.oswego.edu> <4FCF8ED0.7000602@univ-mlv.fr> <4FCF91FB.3090308@cs.oswego.edu> <4FCFA98A.6040609@univ-mlv.fr> Message-ID: <4FCFAAEB.1040203@cs.oswego.edu> On 06/06/12 15:03, R?mi Forax wrote: > tryMonitorEnter is the equivalent of tryLock for synchronized block > (monitorEnter/monitorExit). Sorry; yes. This method exists, but seems to be designed to only be used in unusual situations. So the performance is dreadful on JVMs I've tried it on. Working on this method to try to make it perform well enough to use in performance-sensitive code might make a good project for someone. -Doug From forax at univ-mlv.fr Wed Jun 6 20:31:46 2012 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Wed, 06 Jun 2012 22:31:46 +0200 Subject: An Alternative Hashing Alternative In-Reply-To: <4FCFAAEB.1040203@cs.oswego.edu> References: <4FCF83BB.9070808@cs.oswego.edu> <4FCF8A7E.5030000@cs.oswego.edu> <4FCF8ED0.7000602@univ-mlv.fr> <4FCF91FB.3090308@cs.oswego.edu> <4FCFA98A.6040609@univ-mlv.fr> <4FCFAAEB.1040203@cs.oswego.edu> Message-ID: <4FCFBE32.8020701@univ-mlv.fr> On 06/06/2012 09:09 PM, Doug Lea wrote: > On 06/06/12 15:03, R?mi Forax wrote: >> tryMonitorEnter is the equivalent of tryLock for synchronized block >> (monitorEnter/monitorExit). > > Sorry; yes. This method exists, but seems to be designed to only be used > in unusual situations. So the performance is dreadful on JVMs I've > tried it on. Working on this method to try to make it perform well > enough to use in performance-sensitive code might make a good > project for someone. > > -Doug > I've just checked Hotspot sources, monitorEnter/MonitorExit and tryMonitorEnter have no corresponding intrinsic. That's why you can't use them in ConcurrentHashMap. R?mi From xuelei.fan at oracle.com Thu Jun 7 01:19:55 2012 From: xuelei.fan at oracle.com (xuelei.fan at oracle.com) Date: Thu, 07 Jun 2012 01:19:55 +0000 Subject: hg: jdk8/tl/jdk: 7174244: NPE in Krb5ProxyImpl.getServerKeys() Message-ID: <20120607012013.E527D47769@hg.openjdk.java.net> Changeset: f8e72d7ff37d Author: xuelei Date: 2012-06-06 18:18 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f8e72d7ff37d 7174244: NPE in Krb5ProxyImpl.getServerKeys() Reviewed-by: weijun ! src/share/classes/sun/security/ssl/SSLContextImpl.java ! src/share/classes/sun/security/ssl/ServerHandshaker.java ! src/share/classes/sun/security/ssl/krb5/Krb5ProxyImpl.java + test/sun/security/ssl/sanity/ciphersuites/CipherSuitesInOrder.java From xuelei.fan at oracle.com Thu Jun 7 01:39:58 2012 From: xuelei.fan at oracle.com (xuelei.fan at oracle.com) Date: Thu, 07 Jun 2012 01:39:58 +0000 Subject: hg: jdk8/tl/jdk: 7172149: ArrayIndexOutOfBoundsException from Signature.verify Message-ID: <20120607014008.2343D4776D@hg.openjdk.java.net> Changeset: 713b10821c3d Author: xuelei Date: 2012-06-06 18:39 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/713b10821c3d 7172149: ArrayIndexOutOfBoundsException from Signature.verify Summary: take care of integer addition overflow Reviewed-by: xuelei, wetmore Contributed-by: Jonathan Lu ! src/share/classes/java/security/Signature.java + test/java/security/Signature/VerifyRangeCheckOverflow.java From daniel.daugherty at oracle.com Thu Jun 7 02:12:29 2012 From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com) Date: Thu, 07 Jun 2012 02:12:29 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20120607021250.60BF84776F@hg.openjdk.java.net> Changeset: 181175887d24 Author: jonas Date: 2012-06-06 13:16 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/181175887d24 7174861: all/OPT jdk build on Solaris with FDS enabled sets wrong options Summary: Use CFLAGS_COMMON instead of CC_OPT and CXXFLAGS_COMMON instead of CXX_OPT for setting FDS options. FDS should also set OPTIMIZATION_LEVEL. Reviewed-by: ihse, dholmes, ohair, dcubed ! make/common/Defs-solaris.gmk Changeset: 7543b6db3026 Author: dcubed Date: 2012-06-06 19:11 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7543b6db3026 Merge From mike.duigou at oracle.com Thu Jun 7 07:56:05 2012 From: mike.duigou at oracle.com (Mike Duigou) Date: Thu, 7 Jun 2012 00:56:05 -0700 Subject: Review Request 7174736 : JCK test api/java_util/HashMap/index_EntrySet failing Message-ID: <1F2B6122-A75C-4B9D-A834-33E6E907A738@oracle.com> Hello all; Alan Bateman tracked down a regression introduced by the Alternative HashMap changes which was caught by the JCK tests. The fix is a one liner: diff --git a/src/share/classes/java/util/HashMap.java b/src/share/classes/java/util/HashMap.java --- a/src/share/classes/java/util/HashMap.java +++ b/src/share/classes/java/util/HashMap.java @@ -611,7 +611,7 @@ public class HashMap Map.Entry entry = (Map.Entry) o; Object key = entry.getKey(); - int hash = (key == null) ? 0 : hash(key.hashCode()); + int hash = (key == null) ? 0 : hash(key); int i = indexFor(hash, table.length); @SuppressWarnings("unchecked") Entry prev = (Entry)table[i]; Which is unfortunately similar to another error discovered during pre-commit review. Barring complaints, I will push this change on Thursday. Mike From Alan.Bateman at oracle.com Thu Jun 7 08:14:59 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 07 Jun 2012 09:14:59 +0100 Subject: 7175011: ProblemList.txt updates (6/2012) Message-ID: <4FD06303.7010100@oracle.com> We have two test failures that look like they will take a while to get resolved in jdk8/tl. One of them is the FPU precision issue that Kelly brought up a few days ago. The other is a jconsole test that was missed by some recent refactoring in that area. I'd like to put these tests on the ProblemList.txt so that they are excluded from execution until they are fixed. Attached are the diffs. -Alan. diff --git a/test/ProblemList.txt b/test/ProblemList.txt --- a/test/ProblemList.txt +++ b/test/ProblemList.txt @@ -150,6 +150,9 @@ sun/management/jmxremote/startstop/JMXSt ############################################################################ # jdk_math + +# 7174532 +java/lang/Math/WorstCaseTests.java generic-all ############################################################################ @@ -374,6 +377,9 @@ com/sun/jdi/ProcessAttachTest.sh # Filed 6979016 sun/tools/jconsole/ResourceCheckTest.sh generic-all +# 7172176 +sun/tools/jconsole/ImmutableResourceTest.sh generic-all + # 7132203 sun/jvmstat/monitor/MonitoredVm/CR6672135.java generic-all From chris.hegarty at oracle.com Thu Jun 7 08:54:53 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 07 Jun 2012 09:54:53 +0100 Subject: 7175011: ProblemList.txt updates (6/2012) In-Reply-To: <4FD06303.7010100@oracle.com> References: <4FD06303.7010100@oracle.com> Message-ID: <4FD06C5D.3030001@oracle.com> Thanks Alan, for doing this. -Chris. On 07/06/2012 09:14, Alan Bateman wrote: > > We have two test failures that look like they will take a while to get > resolved in jdk8/tl. One of them is the FPU precision issue that Kelly > brought up a few days ago. The other is a jconsole test that was missed > by some recent refactoring in that area. I'd like to put these tests on > the ProblemList.txt so that they are excluded from execution until they > are fixed. Attached are the diffs. > > -Alan. > > > diff --git a/test/ProblemList.txt b/test/ProblemList.txt > --- a/test/ProblemList.txt > +++ b/test/ProblemList.txt > @@ -150,6 +150,9 @@ sun/management/jmxremote/startstop/JMXSt > ############################################################################ > > > # jdk_math > + > +# 7174532 > +java/lang/Math/WorstCaseTests.java generic-all > > ############################################################################ > > > @@ -374,6 +377,9 @@ com/sun/jdi/ProcessAttachTest.sh > # Filed 6979016 > sun/tools/jconsole/ResourceCheckTest.sh generic-all > > +# 7172176 > +sun/tools/jconsole/ImmutableResourceTest.sh generic-all > + > # 7132203 > sun/jvmstat/monitor/MonitoredVm/CR6672135.java generic-all > From alan.bateman at oracle.com Thu Jun 7 09:33:50 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 07 Jun 2012 09:33:50 +0000 Subject: hg: jdk8/tl/jdk: 7175011: ProblemList.txt updates (6/2012) Message-ID: <20120607093429.CEFF847779@hg.openjdk.java.net> Changeset: 636f9486fde7 Author: alanb Date: 2012-06-07 10:31 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/636f9486fde7 7175011: ProblemList.txt updates (6/2012) Reviewed-by: mduigou, chegar ! test/ProblemList.txt From alan.bateman at oracle.com Thu Jun 7 11:32:45 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 07 Jun 2012 11:32:45 +0000 Subject: hg: jdk8/tl/jdk: 7164256: EnumMap clone doesn't clear the entrySet keeping a reference to the original Map Message-ID: <20120607113304.B3A8347781@hg.openjdk.java.net> Changeset: 757a5129fad7 Author: alanb Date: 2012-06-07 12:31 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/757a5129fad7 7164256: EnumMap clone doesn't clear the entrySet keeping a reference to the original Map Reviewed-by: alanb, chegar, forax, mduigou Contributed-by: dbelfer at gmail.com ! src/share/classes/java/util/EnumMap.java + test/java/util/EnumMap/ProperEntrySetOnClone.java From Alan.Bateman at oracle.com Thu Jun 7 11:41:30 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 07 Jun 2012 12:41:30 +0100 Subject: [PATCH] 7164256 : EnumMap.clone doesn't clear the entrySet field, keeping a reference to the original Map In-Reply-To: References: <4FC3D9F3.4040602@oracle.com> Message-ID: <4FD0936A.9090301@oracle.com> On 04/06/2012 16:33, Diego Belfer wrote: > Hi Alan, > > I've already sent the signed OCA. Will you sponsor the patch ? It's pushed now, see: http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-June/010443.html Thanks for the contribution. -Alan. From nils.loodin at oracle.com Thu Jun 7 13:42:41 2012 From: nils.loodin at oracle.com (nils.loodin at oracle.com) Date: Thu, 07 Jun 2012 13:42:41 +0000 Subject: hg: jdk8/tl/jdk: 7163471: Licensee source bundle failed around 7u4 Message-ID: <20120607134251.711684778D@hg.openjdk.java.net> Changeset: c89018e3f3b6 Author: nloodin Date: 2012-06-05 13:43 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c89018e3f3b6 7163471: Licensee source bundle failed around 7u4 Reviewed-by: dholmes, sla, brutisso, erikj ! make/com/oracle/Makefile From Alan.Bateman at oracle.com Thu Jun 7 14:18:45 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 07 Jun 2012 15:18:45 +0100 Subject: 7174723: java/lang/ProcessBuilder/Basic.java failing [win] Message-ID: <4FD0B845.1070508@oracle.com> Mike, ProcessBuilder/Basic.java has been failing on Windows since the hash work went into jdk8/tl. This test is 11500 tests in one and the removeMappings fix fixes some of the failures. I looked into remaining issues today and it's another assumption on iteration order. A child process prints out the map of its environment variables and the parent assumes the order that they come back. I've changed the test so that the child process sorts them and adjusted the order that the parent expects. This means the test is passing again on all platforms. Attached is the patch. Assuming you are okay with then then we can push it after you push the fix for 7174736. -Alan diff --git a/test/java/lang/ProcessBuilder/Basic.java b/test/java/lang/ProcessBuilder/Basic.java --- a/test/java/lang/ProcessBuilder/Basic.java +++ b/test/java/lang/ProcessBuilder/Basic.java @@ -248,6 +248,7 @@ public class Basic { private static String getenvAsString(Map environment) { StringBuilder sb = new StringBuilder(); + environment = new TreeMap<>(environment); for (Map.Entry e : environment.entrySet()) // Ignore magic environment variables added by the launcher if (! e.getKey().equals("NLSPATH") && @@ -1625,7 +1626,7 @@ public class Basic { childArgs.add("System.getenv()"); String[] cmdp = childArgs.toArray(new String[childArgs.size()]); String[] envp; - String[] envpWin = {"=ExitValue=3", "=C:=\\", "SystemRoot="+systemRoot}; + String[] envpWin = {"=C:=\\", "=ExitValue=3", "SystemRoot="+systemRoot}; String[] envpOth = {"=ExitValue=3", "=C:=\\"}; if (Windows.is()) { envp = envpWin; @@ -1633,7 +1634,7 @@ public class Basic { envp = envpOth; } Process p = Runtime.getRuntime().exec(cmdp, envp); - String expected = Windows.is() ? "=C:=\\,SystemRoot="+systemRoot+",=ExitValue=3," : "=C:=\\,"; + String expected = Windows.is() ? "=C:=\\,=ExitValue=3,SystemRoot="+systemRoot+"," : "=C:=\\,"; String commandOutput = commandOutput(p); if (MacOSX.is()) { commandOutput = removeMacExpectedVars(commandOutput); @@ -1690,7 +1691,7 @@ public class Basic { commandOutput = removeMacExpectedVars(commandOutput); } check(commandOutput.equals(Windows.is() - ? "SystemRoot="+systemRoot+",LC_ALL=C," + ? "LC_ALL=C,SystemRoot="+systemRoot+"," : "LC_ALL=C,"), "Incorrect handling of envstrings containing NULs"); } catch (Throwable t) { unexpected(t); } From weijun.wang at oracle.com Thu Jun 7 14:34:17 2012 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Thu, 07 Jun 2012 14:34:17 +0000 Subject: hg: jdk8/tl/jdk: 7175041: HttpTimestamper should accept https URI Message-ID: <20120607143428.E6F0947794@hg.openjdk.java.net> Changeset: 9b814b887240 Author: weijun Date: 2012-06-07 22:33 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9b814b887240 7175041: HttpTimestamper should accept https URI Reviewed-by: mullan ! src/share/classes/sun/security/timestamp/HttpTimestamper.java From Lance.Andersen at oracle.com Thu Jun 7 16:36:35 2012 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Thu, 7 Jun 2012 12:36:35 -0400 Subject: [7u6] RFR (JAXP) : 7151118: Regressions on 7u4 b11 comp. 7u4 b06 on specjvm2008.xml.transform subbenchmark In-Reply-To: <4FCECD4A.1000704@oracle.com> References: <4FCECD4A.1000704@oracle.com> Message-ID: I am ok with it based on a once-over and the fact you are passing all of the tests Best Lance On Jun 5, 2012, at 11:23 PM, Joe Wang wrote: > I tested through all of the Xalan updates and found XalanJ-2271 to be the culprit. It [1] was intended to improve performance in webserver environment while resolving unescaped chars in attributes. Unfortunately, it actually resulted in a 5% drop in specjvm2008. I tried to improve the patch, by for example not making mutable copies of the CharInfo objects and etc., but none could get all of the performance loss back. > > Since it was a proactive update, meaning no one requested it, instead of spending too much time on this issue, I decided to roll the entire patch back. Below is the webrev [2]. > > [1] https://issues.apache.org/jira/browse/XALANJ-2271 > [2] http://cr.openjdk.java.net/~joehw/7u6/cr7151118/webrev/ > > All unit/sqe/tck tests passed. > > Please review. > > Thanks, > Joe > 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 From dbelfer at gmail.com Thu Jun 7 17:14:31 2012 From: dbelfer at gmail.com (Diego Belfer) Date: Thu, 7 Jun 2012 14:14:31 -0300 Subject: [PATCH] 7164256 : EnumMap.clone doesn't clear the entrySet field, keeping a reference to the original Map In-Reply-To: <4FD0936A.9090301@oracle.com> References: <4FC3D9F3.4040602@oracle.com> <4FD0936A.9090301@oracle.com> Message-ID: Hi Alan, Thanks to you. I will look for another issue I can solve. Is there any other tool for looking for open issues? The bugs database ( bugs.sun.com) does not have an advance search which allows to look for open issue and/or filtering by categories. Best, Diego On Thu, Jun 7, 2012 at 8:41 AM, Alan Bateman wrote: > On 04/06/2012 16:33, Diego Belfer wrote: > >> Hi Alan, >> >> I've already sent the signed OCA. Will you sponsor the patch ? >> > It's pushed now, see: > > http://mail.openjdk.java.net/**pipermail/core-libs-dev/2012-** > June/010443.html > > Thanks for the contribution. > > -Alan. > > From alan.bateman at oracle.com Thu Jun 7 17:43:04 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 07 Jun 2012 17:43:04 +0000 Subject: hg: jdk8/tl/jdk: 7174723: TEST_BUG: java/lang/ProcessBuilder/Basic.java failing [win] Message-ID: <20120607174323.6635E477A2@hg.openjdk.java.net> Changeset: 23f8be788c77 Author: alanb Date: 2012-06-07 18:42 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/23f8be788c77 7174723: TEST_BUG: java/lang/ProcessBuilder/Basic.java failing [win] Reviewed-by: mduigou ! test/java/lang/ProcessBuilder/Basic.java From forax at univ-mlv.fr Thu Jun 7 17:57:19 2012 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Thu, 07 Jun 2012 19:57:19 +0200 Subject: [PATCH] 7164256 : EnumMap.clone doesn't clear the entrySet field, keeping a reference to the original Map In-Reply-To: References: <4FC3D9F3.4040602@oracle.com> <4FD0936A.9090301@oracle.com> Message-ID: <4FD0EB7F.80104@univ-mlv.fr> On 06/07/2012 07:14 PM, Diego Belfer wrote: > Hi Alan, > > Thanks to you. I will look for another issue I can solve. > > Is there any other tool for looking for open issues? The bugs database ( > bugs.sun.com) does not have an advance search which allows to look for open > issue and/or filtering by categories. > > Best, > Diego I think you can try this one: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6901992 and you will be a hero a lot of people :) R?mi From dbelfer at gmail.com Thu Jun 7 18:24:05 2012 From: dbelfer at gmail.com (Diego Belfer) Date: Thu, 7 Jun 2012 15:24:05 -0300 Subject: [PATCH] 7164256 : EnumMap.clone doesn't clear the entrySet field, keeping a reference to the original Map In-Reply-To: <4FD0EB7F.80104@univ-mlv.fr> References: <4FC3D9F3.4040602@oracle.com> <4FD0936A.9090301@oracle.com> <4FD0EB7F.80104@univ-mlv.fr> Message-ID: I will give it a try. Thanks, muralx On Thu, Jun 7, 2012 at 2:57 PM, R?mi Forax wrote: > On 06/07/2012 07:14 PM, Diego Belfer wrote: > >> Hi Alan, >> >> Thanks to you. I will look for another issue I can solve. >> >> Is there any other tool for looking for open issues? The bugs database ( >> bugs.sun.com) does not have an advance search which allows to look for >> open >> issue and/or filtering by categories. >> >> Best, >> Diego >> > > I think you can try this one: > http://bugs.sun.com/**bugdatabase/view_bug.do?bug_**id=6901992 > and you will be a hero a lot of people :) > > R?mi > > From mike.duigou at oracle.com Thu Jun 7 18:40:15 2012 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Thu, 07 Jun 2012 18:40:15 +0000 Subject: hg: jdk8/tl/jdk: 7174736: JCK test api/java_util/HashMap/index_EntrySet failing Message-ID: <20120607184025.AF352477AD@hg.openjdk.java.net> Changeset: fc0e508b713f Author: mduigou Date: 2012-06-07 01:01 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fc0e508b713f 7174736: JCK test api/java_util/HashMap/index_EntrySet failing Summary: Corrects a problem with HashMap.removeEntry() that caused a JCK test to fail Reviewed-by: mduigou Contributed-by: alan.bateman at oracle.com ! src/share/classes/java/util/HashMap.java From lance.andersen at oracle.com Thu Jun 7 18:47:25 2012 From: lance.andersen at oracle.com (Lance Andersen - Oracle) Date: Thu, 7 Jun 2012 14:47:25 -0400 Subject: review request 7172551 Message-ID: <2EFD8707-1603-4CCD-A431-2325D2EF044B@oracle.com> Hi all, Another review request (to go with the others that are outstanding). This is change is for jigsaw, where we are removing the native code used by DriverManager. The webrev can be found at: http://cr.openjdk.java.net/~lancea/7172551/webrev.00 Best, Lance 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 From dawid.weiss at gmail.com Thu Jun 7 20:07:07 2012 From: dawid.weiss at gmail.com (Dawid Weiss) Date: Thu, 7 Jun 2012 22:07:07 +0200 Subject: Empty regexp replaceall and surrogate pairs results in corrupted utf16. Message-ID: Hi, I'm a committer to the Apache Lucene project. We have randomized tests and one seed hit the following (simplified) scenario: String s1 = "AB\uD840\uDC00C"; String s2 = s1.replaceAll("", "X"); the input contains an extended unicode character (any surrogate pair will do). The pattern is an empty string (in fact, it was randomized as "]|" but it's the same problem so I omit the details). The problem is that after applying this pattern, replaceAll inserts X in between the surrogate pair characters and this results in invalid UTF-16: AB??C XAXBX?X?XCX I believe this is a bug in the regexp implementation (sorry, don't have a patch for it) but I'd like to confirm it's not something known. Pointers appreciated. Dawid From rednaxelafx at gmail.com Thu Jun 7 20:10:45 2012 From: rednaxelafx at gmail.com (Krystal Mok) Date: Fri, 8 Jun 2012 04:10:45 +0800 Subject: typo in comments of JVM_SupportsCX8 in jvm.h Message-ID: Hi all, As discussed on hotspot-compiler-dev [1], I came across a typo in the exported jvm.h in the jdk workspace while working on 7174218. The fix is simple [2], and sync up with the changes in 7174218: diff -r 7def50698e78 src/share/javavm/export/jvm.h --- a/src/share/javavm/export/jvm.h Thu May 24 16:15:58 2012 -0700 +++ b/src/share/javavm/export/jvm.h Wed Jun 06 01:15:50 2012 +0800 @@ -595,7 +595,7 @@ JVM_AssertionStatusDirectives(JNIEnv *env, jclass unused); /* - * java.util.concurrent.AtomicLong + * java.util.concurrent.atomic.AtomicLong */ JNIEXPORT jboolean JNICALL JVM_SupportsCX8(void); Could someone review and sponsor this fix, please? Regards, Kris Mok [1]: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2012-June/007798.html [2]: https://gist.github.com/2876357#file_remove_atomic_long_cs_impl_jdk.patch From chris.hegarty at oracle.com Thu Jun 7 20:18:49 2012 From: chris.hegarty at oracle.com (chris hegarty) Date: Thu, 07 Jun 2012 21:18:49 +0100 Subject: review request 7172551 In-Reply-To: <2EFD8707-1603-4CCD-A431-2325D2EF044B@oracle.com> References: <2EFD8707-1603-4CCD-A431-2325D2EF044B@oracle.com> Message-ID: <4FD10CA9.8070700@oracle.com> Looks fine to me. -Chris. On 07/06/2012 19:47, Lance Andersen - Oracle wrote: > Hi all, > > Another review request (to go with the others that are outstanding). > > This is change is for jigsaw, where we are removing the native code used by DriverManager. The webrev can be found at: > > http://cr.openjdk.java.net/~lancea/7172551/webrev.00 > > Best, > Lance > > 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 > From Alan.Bateman at oracle.com Thu Jun 7 20:30:34 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 07 Jun 2012 21:30:34 +0100 Subject: review request 7172551 In-Reply-To: <2EFD8707-1603-4CCD-A431-2325D2EF044B@oracle.com> References: <2EFD8707-1603-4CCD-A431-2325D2EF044B@oracle.com> Message-ID: <4FD10F6A.5030506@oracle.com> On 07/06/2012 19:47, Lance Andersen - Oracle wrote: > Hi all, > > Another review request (to go with the others that are outstanding). > > This is change is for jigsaw, where we are removing the native code used by DriverManager. The webrev can be found at: > > http://cr.openjdk.java.net/~lancea/7172551/webrev.00 > Thanks Lance, this looks good to me and will allow us to remove a workaround that we have in the jigsaw forest. -Alan. From chris.hegarty at oracle.com Thu Jun 7 20:39:41 2012 From: chris.hegarty at oracle.com (chris hegarty) Date: Thu, 07 Jun 2012 21:39:41 +0100 Subject: typo in comments of JVM_SupportsCX8 in jvm.h In-Reply-To: References: Message-ID: <4FD1118D.1090108@oracle.com> Looks fine Kris (given the same change is being made to hotspot/src/share/vm/prims/jvm.h) I can sponsor this for you. We can use the same bug number seeing as these are two separate repositories. -Chris. On 07/06/2012 21:10, Krystal Mok wrote: > Hi all, > > As discussed on hotspot-compiler-dev [1], I came across a typo in the > exported jvm.h in the jdk workspace while working on 7174218. > The fix is simple [2], and sync up with the changes in 7174218: > > diff -r 7def50698e78 src/share/javavm/export/jvm.h > --- a/src/share/javavm/export/jvm.h Thu May 24 16:15:58 2012 -0700 > +++ b/src/share/javavm/export/jvm.h Wed Jun 06 01:15:50 2012 +0800 > @@ -595,7 +595,7 @@ > JVM_AssertionStatusDirectives(JNIEnv *env, jclass unused); > > /* > - * java.util.concurrent.AtomicLong > + * java.util.concurrent.atomic.AtomicLong > */ > JNIEXPORT jboolean JNICALL > JVM_SupportsCX8(void); > > Could someone review and sponsor this fix, please? > > Regards, > Kris Mok > > [1]: > http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2012-June/007798.html > [2]: > https://gist.github.com/2876357#file_remove_atomic_long_cs_impl_jdk.patch From joe.darcy at oracle.com Thu Jun 7 20:39:59 2012 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 07 Jun 2012 13:39:59 -0700 Subject: review request 7172551 In-Reply-To: <2EFD8707-1603-4CCD-A431-2325D2EF044B@oracle.com> References: <2EFD8707-1603-4CCD-A431-2325D2EF044B@oracle.com> Message-ID: <4FD1119F.6040008@oracle.com> Generally looks fine, but I recommend some adjustments: I'd like to see some "()" on this line! 470 ClassLoader cl = cc != null ? cc.getClassLoader() : null; I prefer to update the copyright year as part of making the code changes. -Joe On 6/7/2012 11:47 AM, Lance Andersen - Oracle wrote: > Hi all, > > Another review request (to go with the others that are outstanding). > > This is change is for jigsaw, where we are removing the native code used by DriverManager. The webrev can be found at: > > http://cr.openjdk.java.net/~lancea/7172551/webrev.00 > > Best, > Lance > > 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 > From rednaxelafx at gmail.com Thu Jun 7 20:47:30 2012 From: rednaxelafx at gmail.com (Krystal Mok) Date: Fri, 8 Jun 2012 04:47:30 +0800 Subject: typo in comments of JVM_SupportsCX8 in jvm.h In-Reply-To: <4FD1118D.1090108@oracle.com> References: <4FD1118D.1090108@oracle.com> Message-ID: On Fri, Jun 8, 2012 at 4:39 AM, chris hegarty wrote: > Looks fine Kris (given the same change is being made to > hotspot/src/share/vm/prims/**jvm.h) > > Yes. jvm.h in both the hotspot and jdk workspaces had incorrect comments on JVM_SupportsCX8 before this change, but they were different because they were out of sync. > I can sponsor this for you. We can use the same bug number seeing as these > are two separate repositories. > > Great. Thank you, Chris! - Kris > -Chris. > > From mandy.chung at oracle.com Thu Jun 7 20:49:13 2012 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 07 Jun 2012 13:49:13 -0700 Subject: review request 7172551 In-Reply-To: <2EFD8707-1603-4CCD-A431-2325D2EF044B@oracle.com> References: <2EFD8707-1603-4CCD-A431-2325D2EF044B@oracle.com> Message-ID: <4FD113C9.1010005@oracle.com> Looks good. It's a good clean up. Mandy On 6/7/2012 11:47 AM, Lance Andersen - Oracle wrote: > Hi all, > > Another review request (to go with the others that are outstanding). > > This is change is for jigsaw, where we are removing the native code used by DriverManager. The webrev can be found at: > > http://cr.openjdk.java.net/~lancea/7172551/webrev.00 > > Best, > Lance > > 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 > From huizhe.wang at oracle.com Thu Jun 7 21:10:03 2012 From: huizhe.wang at oracle.com (huizhe.wang at oracle.com) Date: Thu, 07 Jun 2012 21:10:03 +0000 Subject: hg: jdk8/tl/jaxp: 7151118: Regressions on 7u4 b11 comp. 7u4 b06 on specjvm2008.xml.transform subbenchmark Message-ID: <20120607211007.E1A99477BA@hg.openjdk.java.net> Changeset: 633700642caf Author: joehw Date: 2012-06-07 13:47 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/633700642caf 7151118: Regressions on 7u4 b11 comp. 7u4 b06 on specjvm2008.xml.transform subbenchmark Summary: roll back XalanJ-2271 that caused the regression Reviewed-by: lancea ! src/com/sun/org/apache/xml/internal/serializer/CharInfo.java ! src/com/sun/org/apache/xml/internal/serializer/ToHTMLStream.java ! src/com/sun/org/apache/xml/internal/serializer/ToStream.java ! src/com/sun/org/apache/xml/internal/serializer/ToXMLStream.java From Lance.Andersen at oracle.com Thu Jun 7 21:13:55 2012 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Thu, 7 Jun 2012 17:13:55 -0400 Subject: review request 7172551 In-Reply-To: <4FD113C9.1010005@oracle.com> References: <2EFD8707-1603-4CCD-A431-2325D2EF044B@oracle.com> <4FD113C9.1010005@oracle.com> Message-ID: Thanks Chris, Alan, Joe, Mandy. Joe I will update the copyright but will not plan on a webrev for that.. I thought line 470 was readable ClassLoader cl = cc != null ? cc.getClassLoader() : null; I would prefer to get this back for now vs. make that change as part of an additional cleanup i have planned to DriverManager. as if I do this now, I would want to do another full build and run of all of the tests. I know Alan would like this back for jigsaw sooner rather than later. I think I can streamline this code some more but would like to get this back (as well as my other week old review requests ;-) ). Are you Ok with just the copyright change for now? Best Lance On Jun 7, 2012, at 4:49 PM, Mandy Chung wrote: > Looks good. It's a good clean up. > > Mandy > > On 6/7/2012 11:47 AM, Lance Andersen - Oracle wrote: >> Hi all, >> >> Another review request (to go with the others that are outstanding). >> >> This is change is for jigsaw, where we are removing the native code used by DriverManager. The webrev can be found at: >> >> http://cr.openjdk.java.net/~lancea/7172551/webrev.00 >> >> Best, >> Lance >> >> 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 >> 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 From joe.darcy at oracle.com Thu Jun 7 22:03:46 2012 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 07 Jun 2012 15:03:46 -0700 Subject: review request 7172551 In-Reply-To: References: <2EFD8707-1603-4CCD-A431-2325D2EF044B@oracle.com> <4FD113C9.1010005@oracle.com> Message-ID: <4FD12542.6040706@oracle.com> Hi Lance, On 6/7/2012 2:13 PM, Lance Andersen - Oracle wrote: > Thanks Chris, Alan, Joe, Mandy. > > Joe I will update the copyright but will not plan on a webrev for that.. Sure. > I thought line 470 was readable > > ClassLoader cl = cc != null ? cc.getClassLoader() : null; I would have written this as ClassLoader cl = (cc != null) ? cc.getClassLoader() : null; The other reviewers accepted the old version so I'll leave it to your discretion about whether to change it or not. Cheers, -Joe > > I would prefer to get this back for now vs. make that change as part of an additional cleanup i have planned to DriverManager. > > as if I do this now, I would want to do another full build and run of all of the tests. I know Alan would like this back for jigsaw sooner rather than later. > > I think I can streamline this code some more but would like to get this back (as well as my other week old review requests ;-) ). > > Are you Ok with just the copyright change for now? > > > Best > Lance > > On Jun 7, 2012, at 4:49 PM, Mandy Chung wrote: > >> Looks good. It's a good clean up. >> >> Mandy >> >> On 6/7/2012 11:47 AM, Lance Andersen - Oracle wrote: >>> Hi all, >>> >>> Another review request (to go with the others that are outstanding). >>> >>> This is change is for jigsaw, where we are removing the native code used by DriverManager. The webrev can be found at: >>> >>> http://cr.openjdk.java.net/~lancea/7172551/webrev.00 >>> >>> Best, >>> Lance >>> >>> 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 >>> > > 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 > From huizhe.wang at oracle.com Thu Jun 7 22:27:50 2012 From: huizhe.wang at oracle.com (Joe Wang) Date: Thu, 07 Jun 2012 15:27:50 -0700 Subject: [7u6] RFR (JAXP) : 7157608: One feature is not recognized. Message-ID: <4FD12AE6.8060505@oracle.com> The feature is: http://apache.org/xml/features/standard-uri-conformant True: Requires that a URI has to be provided where a URI is expected. False: Some invalid URI's are accepted as valid values when a URI is expected. Examples include: using platform dependent file separator in place of '/'; using Windows/DOS path names like "c:\blah" and "\\host\dir\blah"; using invalid URI characters (space, for example). I'm not sure why it was left out during jdk6 development. The implementation code was in the RI except the part that add the feature to the recognized list. It does appear to me a useful feature in cases such as when a file with the path generated in the Windows environment is provided to the parser. Since the impl code is in, fixing the issue is basically adding the feature to the recognized list as listed below: webrev: http://cr.openjdk.java.net/~joehw/7u6/7157608/webrev/ copied here: diff --git a/src/com/sun/org/apache/xerces/internal/impl/XMLEntityManager.java b/src/com/sun/org/apache/xerces/internal/impl/XMLEntityManager.java --- a/src/com/sun/org/apache/xerces/internal/impl/XMLEntityManager.java +++ b/src/com/sun/org/apache/xerces/internal/impl/XMLEntityManager.java @@ -182,7 +182,8 @@ protected static final String PARSER_SET EXTERNAL_GENERAL_ENTITIES, EXTERNAL_PARAMETER_ENTITIES, ALLOW_JAVA_ENCODINGS, - WARN_ON_DUPLICATE_ENTITYDEF + WARN_ON_DUPLICATE_ENTITYDEF, + STANDARD_URI_CONFORMANT }; /** Feature defaults. */ @@ -192,6 +193,7 @@ protected static final String PARSER_SET Boolean.TRUE, Boolean.TRUE, Boolean.FALSE, + Boolean.FALSE }; Thanks, Joe From Lance.Andersen at oracle.com Thu Jun 7 22:35:40 2012 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Thu, 7 Jun 2012 18:35:40 -0400 Subject: review request 7172551 In-Reply-To: <4FD12542.6040706@oracle.com> References: <2EFD8707-1603-4CCD-A431-2325D2EF044B@oracle.com> <4FD113C9.1010005@oracle.com> <4FD12542.6040706@oracle.com> Message-ID: Hi Joe, Thank you for the note. Here is the diff ace2 51 =>hg diff DriverManager.java diff -r fc0e508b713f src/share/classes/java/sql/DriverManager.java --- a/src/share/classes/java/sql/DriverManager.java Thu Jun 07 01:01:09 2012 -0700 +++ b/src/share/classes/java/sql/DriverManager.java Thu Jun 07 20:09:05 2012 -0400 @@ -1,5 +1,5 @@ /* - * Copyright (c) 1996, 2011, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 1996, 2012, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -30,6 +30,7 @@ import java.security.AccessController; import java.security.PrivilegedAction; import java.util.concurrent.CopyOnWriteArrayList; +import sun.reflect.Reflection; /** @@ -461,6 +462,15 @@ } //------------------------------------------------------------------------ + + // Internal method used to get the caller's class loader. + // Replaces the call to the native method + private static ClassLoader getCallerClassLoader() { + Class cc = Reflection.getCallerClass(3); + ClassLoader cl = (cc != null) ? cc.getClassLoader() : null; + return cl; + } + // Indicates whether the class object that would be created if the code calling // DriverManager is accessible. @@ -604,8 +614,6 @@ throw new SQLException("No suitable driver found for "+ url, "08001"); } - /* Returns the caller's class loader, or null if none */ - private static native ClassLoader getCallerClassLoader(); } ace2 52 => Best Lance On Jun 7, 2012, at 6:03 PM, Joe Darcy wrote: > Hi Lance, > > On 6/7/2012 2:13 PM, Lance Andersen - Oracle wrote: >> Thanks Chris, Alan, Joe, Mandy. >> >> Joe I will update the copyright but will not plan on a webrev for that.. > > Sure. > >> I thought line 470 was readable >> >> ClassLoader cl = cc != null ? cc.getClassLoader() : null; > > I would have written this as > > > ClassLoader cl = (cc != null) ? cc.getClassLoader() : null; > > The other reviewers accepted the old version so I'll leave it to your discretion about whether to change it or not. > > Cheers, > > -Joe > >> >> I would prefer to get this back for now vs. make that change as part of an additional cleanup i have planned to DriverManager. >> >> as if I do this now, I would want to do another full build and run of all of the tests. I know Alan would like this back for jigsaw sooner rather than later. >> >> I think I can streamline this code some more but would like to get this back (as well as my other week old review requests ;-) ). >> >> Are you Ok with just the copyright change for now? >> >> >> Best >> Lance >> >> On Jun 7, 2012, at 4:49 PM, Mandy Chung wrote: >> >>> Looks good. It's a good clean up. >>> >>> Mandy >>> >>> On 6/7/2012 11:47 AM, Lance Andersen - Oracle wrote: >>>> Hi all, >>>> >>>> Another review request (to go with the others that are outstanding). >>>> >>>> This is change is for jigsaw, where we are removing the native code used by DriverManager. The webrev can be found at: >>>> >>>> http://cr.openjdk.java.net/~lancea/7172551/webrev.00 >>>> >>>> Best, >>>> Lance >>>> >>>> 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 >>>> >> >> 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 >> 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 From xueming.shen at oracle.com Thu Jun 7 22:46:30 2012 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 07 Jun 2012 15:46:30 -0700 Subject: Empty regexp replaceall and surrogate pairs results in corrupted utf16. In-Reply-To: References: Message-ID: <4FD12F46.5060505@oracle.com> Personally I don't think it is a bug. A j.l.String represents a sequence of UTF-16 chars. While a pair of surrogates represents a supplementary character, a single surrogate itself is still a "legal" independent entity inside a String object and length of a String is still defined as the total number of char unit and an index value between a high surrogate and a low surrogate is still a legal index value that can be used to access the char at that particular position. Using an empty String "" as a regex for the replaceAll() takes the advantage of the special meaning of "", in which it is interpreted as it can match any possible zero-width position of the target String, it does not imply anything regarding "character" or "characters" around it, so I would not interpret it as a zero-with character boundary, therefor a "position" in between a pair surrogates is still a good "found" for replacing. -Sherman On 6/7/2012 1:07 PM, Dawid Weiss wrote: > Hi, I'm a committer to the Apache Lucene project. We have randomized > tests and one seed hit the following (simplified) scenario: > > String s1 = "AB\uD840\uDC00C"; > String s2 = s1.replaceAll("", "X"); > > the input contains an extended unicode character (any surrogate pair > will do). The pattern is an empty string (in fact, it was randomized > as "]|" but it's the same problem so I omit the details). The problem > is that after applying this pattern, replaceAll inserts X in between > the surrogate pair characters and this results in invalid UTF-16: > > AB??C > XAXBX?X?XCX > > I believe this is a bug in the regexp implementation (sorry, don't > have a patch for it) but I'd like to confirm it's not something known. > Pointers appreciated. > > Dawid From Ulf.Zibis at gmx.de Fri Jun 8 00:36:47 2012 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Fri, 08 Jun 2012 02:36:47 +0200 Subject: review request 7172551 In-Reply-To: <4FD12542.6040706@oracle.com> References: <2EFD8707-1603-4CCD-A431-2325D2EF044B@oracle.com> <4FD113C9.1010005@oracle.com> <4FD12542.6040706@oracle.com> Message-ID: <4FD1491F.5070900@gmx.de> Am 08.06.2012 00:03, schrieb Joe Darcy: > I would have written this as > > ClassLoader cl = (cc != null) ? cc.getClassLoader() : null; Alternative: return (cc != null) ? cc.getClassLoader() : null; -Ulf From david.holmes at oracle.com Fri Jun 8 01:51:10 2012 From: david.holmes at oracle.com (David Holmes) Date: Fri, 08 Jun 2012 11:51:10 +1000 Subject: typo in comments of JVM_SupportsCX8 in jvm.h In-Reply-To: <4FD1118D.1090108@oracle.com> References: <4FD1118D.1090108@oracle.com> Message-ID: <4FD15A8E.2070906@oracle.com> On 8/06/2012 6:39 AM, chris hegarty wrote: > Looks fine Kris (given the same change is being made to > hotspot/src/share/vm/prims/jvm.h) > > I can sponsor this for you. We can use the same bug number seeing as > these are two separate repositories. Bzzzt! No you can't! In theory you can use one CR to cover a combined change across multiple repos (eg open and closed). But you can't use one CR to cover a change in two different components: hotspot and jdk. One has to be filed against jvm->hotspot->whatever, the other against java->java->whatever. David ---- > -Chris. > > On 07/06/2012 21:10, Krystal Mok wrote: >> Hi all, >> >> As discussed on hotspot-compiler-dev [1], I came across a typo in the >> exported jvm.h in the jdk workspace while working on 7174218. >> The fix is simple [2], and sync up with the changes in 7174218: >> >> diff -r 7def50698e78 src/share/javavm/export/jvm.h >> --- a/src/share/javavm/export/jvm.h Thu May 24 16:15:58 2012 -0700 >> +++ b/src/share/javavm/export/jvm.h Wed Jun 06 01:15:50 2012 +0800 >> @@ -595,7 +595,7 @@ >> JVM_AssertionStatusDirectives(JNIEnv *env, jclass unused); >> >> /* >> - * java.util.concurrent.AtomicLong >> + * java.util.concurrent.atomic.AtomicLong >> */ >> JNIEXPORT jboolean JNICALL >> JVM_SupportsCX8(void); >> >> Could someone review and sponsor this fix, please? >> >> Regards, >> Kris Mok >> >> [1]: >> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2012-June/007798.html >> >> [2]: >> https://gist.github.com/2876357#file_remove_atomic_long_cs_impl_jdk.patch From paul.sandoz at oracle.com Fri Jun 8 08:41:39 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 8 Jun 2012 10:41:39 +0200 Subject: [7u6] RFR (JAXP) : 7157608: One feature is not recognized. In-Reply-To: <4FD12AE6.8060505@oracle.com> References: <4FD12AE6.8060505@oracle.com> Message-ID: <9B5D87A7-7183-4A8D-93BB-C656CA32D5DF@oracle.com> Hi Joe, Looks OK to me. Paul. On Jun 8, 2012, at 12:27 AM, Joe Wang wrote: > The feature is: http://apache.org/xml/features/standard-uri-conformant > > True: Requires that a URI has to be provided where a URI is expected. > False: Some invalid URI's are accepted as valid values when a URI is expected. Examples include: using platform dependent file separator in place of '/'; using Windows/DOS path names like "c:\blah" and "\\host\dir\blah"; using invalid URI characters (space, for example). > > > I'm not sure why it was left out during jdk6 development. The implementation code was in the RI except the part that add the feature to the recognized list. It does appear to me a useful feature in cases such as when a file with the path generated in the Windows environment is provided to the parser. > > Since the impl code is in, fixing the issue is basically adding the feature to the recognized list as listed below: > webrev: http://cr.openjdk.java.net/~joehw/7u6/7157608/webrev/ > copied here: > > diff --git a/src/com/sun/org/apache/xerces/internal/impl/XMLEntityManager.java b/src/com/sun/org/apache/xerces/internal/impl/XMLEntityManager.java > --- a/src/com/sun/org/apache/xerces/internal/impl/XMLEntityManager.java > +++ b/src/com/sun/org/apache/xerces/internal/impl/XMLEntityManager.java > @@ -182,7 +182,8 @@ protected static final String PARSER_SET > EXTERNAL_GENERAL_ENTITIES, > EXTERNAL_PARAMETER_ENTITIES, > ALLOW_JAVA_ENCODINGS, > - WARN_ON_DUPLICATE_ENTITYDEF > + WARN_ON_DUPLICATE_ENTITYDEF, > + STANDARD_URI_CONFORMANT > }; > > /** Feature defaults. */ > @@ -192,6 +193,7 @@ protected static final String PARSER_SET > Boolean.TRUE, > Boolean.TRUE, > Boolean.FALSE, > + Boolean.FALSE > }; > > > Thanks, > Joe From chris.hegarty at oracle.com Fri Jun 8 08:44:06 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 08 Jun 2012 09:44:06 +0100 Subject: typo in comments of JVM_SupportsCX8 in jvm.h In-Reply-To: <4FD15A8E.2070906@oracle.com> References: <4FD1118D.1090108@oracle.com> <4FD15A8E.2070906@oracle.com> Message-ID: <4FD1BB56.8000404@oracle.com> On 08/06/12 02:51, David Holmes wrote: > On 8/06/2012 6:39 AM, chris hegarty wrote: >> Looks fine Kris (given the same change is being made to >> hotspot/src/share/vm/prims/jvm.h) >> >> I can sponsor this for you. We can use the same bug number seeing as >> these are two separate repositories. > > Bzzzt! No you can't! > > In theory you can use one CR to cover a combined change across multiple > repos (eg open and closed). > > But you can't use one CR to cover a change in two different components: > hotspot and jdk. One has to be filed against jvm->hotspot->whatever, the > other against java->java->whatever. you're right. I was thinking of a similar case across the langtools and jdk repos. CR 7175413: Typo in comments of JVM_SupportsCX8 in jvm.h -Chris. > > David > ---- > >> -Chris. >> >> On 07/06/2012 21:10, Krystal Mok wrote: >>> Hi all, >>> >>> As discussed on hotspot-compiler-dev [1], I came across a typo in the >>> exported jvm.h in the jdk workspace while working on 7174218. >>> The fix is simple [2], and sync up with the changes in 7174218: >>> >>> diff -r 7def50698e78 src/share/javavm/export/jvm.h >>> --- a/src/share/javavm/export/jvm.h Thu May 24 16:15:58 2012 -0700 >>> +++ b/src/share/javavm/export/jvm.h Wed Jun 06 01:15:50 2012 +0800 >>> @@ -595,7 +595,7 @@ >>> JVM_AssertionStatusDirectives(JNIEnv *env, jclass unused); >>> >>> /* >>> - * java.util.concurrent.AtomicLong >>> + * java.util.concurrent.atomic.AtomicLong >>> */ >>> JNIEXPORT jboolean JNICALL >>> JVM_SupportsCX8(void); >>> >>> Could someone review and sponsor this fix, please? >>> >>> Regards, >>> Kris Mok >>> >>> [1]: >>> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2012-June/007798.html >>> >>> >>> [2]: >>> https://gist.github.com/2876357#file_remove_atomic_long_cs_impl_jdk.patch >>> From chris.hegarty at oracle.com Fri Jun 8 08:56:19 2012 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Fri, 08 Jun 2012 08:56:19 +0000 Subject: hg: jdk8/tl/jdk: 7175413: Typo in comments of JVM_SupportsCX8 in jvm.h Message-ID: <20120608085645.75039477EB@hg.openjdk.java.net> Changeset: abe465d6a9b8 Author: chegar Date: 2012-06-08 09:55 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/abe465d6a9b8 7175413: Typo in comments of JVM_SupportsCX8 in jvm.h Reviewed-by: chegar Contributed-by: Krystal Mok ! src/share/javavm/export/jvm.h From dawid.weiss at gmail.com Fri Jun 8 11:14:04 2012 From: dawid.weiss at gmail.com (Dawid Weiss) Date: Fri, 8 Jun 2012 13:14:04 +0200 Subject: Empty regexp replaceall and surrogate pairs results in corrupted utf16. In-Reply-To: <4FD12F46.5060505@oracle.com> References: <4FD12F46.5060505@oracle.com> Message-ID: I guess a lot depends on the point of view. From historical point of view (where a char[] and a String are basically unsigned values) that pattern should simply process every value (index) and work like you say. But from a practical point of view I think it is a bug -- it corrupts the string, transforming legal unicode into invalid values. I checked with Python (3) and the behavior there is the expected one (it work at the unicode codepoint level rather than surrogate level). Where is the behavior of "" that you mention defined? I admit I couldn't find any reference to this in the documentation: > Using an empty String "" as a regex for the replaceAll() takes the > advantage of the special meaning of "", in which it is interpreted as > it can match any possible zero-width position of the target String I'm not saying you're wrong (and that pattern is definitely not common so it's probably academic discussion) but I'd like some concrete reference as to how an empty pattern should behave. To me consistency with the rest of the Pattern specification would be that it operates at "zero width position between unicode characters" not between any char[] value, even an incorrect one or in the middle of a surrogate. Dawid On Fri, Jun 8, 2012 at 12:46 AM, Xueming Shen wrote: > Personally I don't think it is a bug. A j.l.String represents a sequence of > UTF-16 chars. While > a pair of surrogates represents a supplementary character, a single > surrogate itself is still > a "legal" independent entity inside a String object and length of a String > is still defined as > the total number of char unit and an index value between a high surrogate > and a low > surrogate is still a legal index value that can be used to access the char > at that particular > position. Using an empty String "" as a regex for the replaceAll() takes the > advantage of the > special meaning of "", in which it is interpreted as it can match any > possible zero-width > position of the target String, it does ?not imply anything regarding > "character" ?or > "characters" around it, so I would not interpret it as a zero-with character > boundary, > therefor a "position" in between a pair surrogates is still a good "found" > for replacing. > > -Sherman > > > On 6/7/2012 1:07 PM, Dawid Weiss wrote: >> >> Hi, I'm a committer to the Apache Lucene project. We have randomized >> tests and one seed hit the following (simplified) scenario: >> >> ? ?String s1 = "AB\uD840\uDC00C"; >> ? ?String s2 = s1.replaceAll("", "X"); >> >> the input contains an extended unicode character (any surrogate pair >> will do). The pattern is an empty string (in fact, it was randomized >> as "]|" but it's the same problem so I omit the details). The problem >> is that after applying this pattern, replaceAll inserts X in between >> the surrogate pair characters and this results in invalid UTF-16: >> >> AB??C >> XAXBX?X?XCX >> >> I believe this is a bug in the regexp implementation (sorry, don't >> have a patch for it) but I'd like to confirm it's not something known. >> Pointers appreciated. >> >> Dawid From edvard.wendelin at oracle.com Fri Jun 8 11:41:52 2012 From: edvard.wendelin at oracle.com (Edvard Wendelin) Date: Fri, 08 Jun 2012 13:41:52 +0200 Subject: Request for Review(XS): 7156963 Incorrect copyright header in java/io/SerialCallbackContext In-Reply-To: <4FCD5201.8000804@oracle.com> References: <0FBC0B92-B3EA-4A62-9355-F5FE1E25A5D1@oracle.com> <4FCD00A7.4040007@oracle.com> <4FCD5201.8000804@oracle.com> Message-ID: <4FD1E500.5050706@oracle.com> Correct! Thanks for pointing that out. Don't know how it ended up getting one extra space on each line. Updated webrev on http://cr.openjdk.java.net/~ewendeli/7156963/webrev.02/ Thanks, Edvard On 06/05/2012 02:25 AM, Weijun Wang wrote: > It seems the whole copyright header is one-char shifted to right. > > -Max > > On 06/05/2012 02:38 AM, Joe Darcy wrote: >> Looks fine, >> >> -Joe >> >> On 6/4/2012 7:01 AM, Edvard Wendelin wrote: >>> Please review. In addition to fixing the copyright I also fixed the >>> incorrect indentation of the rest of the file (which is kind of hard >>> to tell from the webrev). >>> >>> Bug: 7156963 >>> >>> CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7156963 >>> Synopsis: Incorrect copyright header in java/io/SerialCallbackContext >>> >>> Webrev: http://cr.openjdk.java.net/~ewendeli/7156963/webrev.01/ >>> >>> Testing: Verified that the JDK compiles properly. >>> >>> Thanks, >>> Edvard From lance.andersen at oracle.com Fri Jun 8 11:58:08 2012 From: lance.andersen at oracle.com (lance.andersen at oracle.com) Date: Fri, 08 Jun 2012 11:58:08 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20120608115837.99AC5477F2@hg.openjdk.java.net> Changeset: 8305ddc88a5a Author: lancea Date: 2012-06-07 20:11 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8305ddc88a5a 7172551: Remove Native calls from DriverManager for jigsaw Reviewed-by: alanb, chegar, darcy, mchung ! make/java/java/FILES_c.gmk ! make/java/java/mapfile-vers ! makefiles/java/java/FILES_c.gmk ! makefiles/java/java/mapfile-vers ! src/share/classes/java/sql/DriverManager.java - src/share/native/java/sql/DriverManager.c Changeset: 7cb7bfae9d3a Author: lancea Date: 2012-06-08 09:22 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7cb7bfae9d3a Merge From Ulf.Zibis at gmx.de Fri Jun 8 12:16:39 2012 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Fri, 08 Jun 2012 14:16:39 +0200 Subject: Empty regexp replaceall and surrogate pairs results in corrupted utf16. In-Reply-To: References: <4FD12F46.5060505@oracle.com> Message-ID: <4FD1ED27.4070701@gmx.de> I tend to agree Dawid. Especially the comparison with Python behaviour is demonstrative. Is there any spec weather the Java Regex API has a general contract with 16-bit chars or Unicode codepoints? Thinking about the search pattern e.g. "[AB\uD840\uDC00C]"; what does it actually search for, the isolated occurence of each char, or the occurence of the codepoint "\uD840\uDC00" ? Last, but not least, we should think about, which would be the common use case, an which would be more easy to work around. (I think, the current view on isolated chars is more easy to work around: StringBuilder sb = new StringBuilder(s1.length + 1).append('X'); for (char c : s1.getChars()) sb.append(c).append('X'); String s2 = sb.toString(); ) Additionally I like to discuss: "any possible zero-width position of the target String" If String length is l, maybe it's arguable, that position l is no valid position in the String. From the use case point of view, I think "P e t e r" as result of "Peter".replaceAll("", " ") is the most useful. -Ulf Am 08.06.2012 13:14, schrieb Dawid Weiss: > I guess a lot depends on the point of view. From historical point of > view (where a char[] and a String are basically unsigned values) that > pattern should simply process every value (index) and work like you > say. But from a practical point of view I think it is a bug -- it > corrupts the string, transforming legal unicode into invalid values. > > I checked with Python (3) and the behavior there is the expected one > (it work at the unicode codepoint level rather than surrogate level). > > Where is the behavior of "" that you mention defined? I admit I > couldn't find any reference to this in the documentation: > >> Using an empty String "" as a regex for the replaceAll() takes the >> advantage of the special meaning of "", in which it is interpreted as >> it can match any possible zero-width position of the target String > I'm not saying you're wrong (and that pattern is definitely not common > so it's probably academic discussion) but I'd like some concrete > reference as to how an empty pattern should behave. To me consistency > with the rest of the Pattern specification would be that it operates > at "zero width position between unicode characters" not between any > char[] value, even an incorrect one or in the middle of a surrogate. > > Dawid > > On Fri, Jun 8, 2012 at 12:46 AM, Xueming Shen wrote: >> Personally I don't think it is a bug. A j.l.String represents a sequence of >> UTF-16 chars. While >> a pair of surrogates represents a supplementary character, a single >> surrogate itself is still >> a "legal" independent entity inside a String object and length of a String >> is still defined as >> the total number of char unit and an index value between a high surrogate >> and a low >> surrogate is still a legal index value that can be used to access the char >> at that particular >> position. Using an empty String "" as a regex for the replaceAll() takes the >> advantage of the >> special meaning of "", in which it is interpreted as it can match any >> possible zero-width >> position of the target String, it does not imply anything regarding >> "character" or >> "characters" around it, so I would not interpret it as a zero-with character >> boundary, >> therefor a "position" in between a pair surrogates is still a good "found" >> for replacing. >> >> -Sherman >> >> >> On 6/7/2012 1:07 PM, Dawid Weiss wrote: >>> Hi, I'm a committer to the Apache Lucene project. We have randomized >>> tests and one seed hit the following (simplified) scenario: >>> >>> String s1 = "AB\uD840\uDC00C"; >>> String s2 = s1.replaceAll("", "X"); >>> >>> the input contains an extended unicode character (any surrogate pair >>> will do). The pattern is an empty string (in fact, it was randomized >>> as "]|" but it's the same problem so I omit the details). The problem >>> is that after applying this pattern, replaceAll inserts X in between >>> the surrogate pair characters and this results in invalid UTF-16: >>> >>> AB??C >>> XAXBX?X?XCX >>> >>> I believe this is a bug in the regexp implementation (sorry, don't >>> have a patch for it) but I'd like to confirm it's not something known. >>> Pointers appreciated. >>> >>> Dawid From Ulf.Zibis at gmx.de Fri Jun 8 12:24:51 2012 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Fri, 08 Jun 2012 14:24:51 +0200 Subject: Empty regexp replaceall and surrogate pairs results in corrupted utf16. In-Reply-To: <4FD1ED27.4070701@gmx.de> References: <4FD12F46.5060505@oracle.com> <4FD1ED27.4070701@gmx.de> Message-ID: <4FD1EF13.2040808@gmx.de> Oops, correction: StringBuilder sb = new StringBuilder(s1.length * 2 + 1); for (char c : s1.getChars()) sb.append('X').append(c); String s2 = sb.append('X').toString(); Am 08.06.2012 14:16, schrieb Ulf Zibis: > I tend to agree Dawid. > Especially the comparison with Python behaviour is demonstrative. > > Is there any spec weather the Java Regex API has a general contract with 16-bit chars or Unicode > codepoints? > > Thinking about the search pattern e.g. "[AB\uD840\uDC00C]"; what does it actually search for, the > isolated occurence of each char, or the occurence of the codepoint "\uD840\uDC00" ? > > Last, but not least, we should think about, which would be the common use case, an which would be > more easy to work around. > (I think, the current view on isolated chars is more easy to work around: > StringBuilder sb = new StringBuilder(s1.length + 1).append('X'); > for (char c : s1.getChars()) > sb.append(c).append('X'); > String s2 = sb.toString(); > ) > > Additionally I like to discuss: "any possible zero-width position of the target String" > If String length is l, maybe it's arguable, that position l is no valid position in the String. > > From the use case point of view, I think "P e t e r" as result of "Peter".replaceAll("", " ") is > the most useful. > > -Ulf > > > Am 08.06.2012 13:14, schrieb Dawid Weiss: >> I guess a lot depends on the point of view. From historical point of >> view (where a char[] and a String are basically unsigned values) that >> pattern should simply process every value (index) and work like you >> say. But from a practical point of view I think it is a bug -- it >> corrupts the string, transforming legal unicode into invalid values. >> >> I checked with Python (3) and the behavior there is the expected one >> (it work at the unicode codepoint level rather than surrogate level). >> >> Where is the behavior of "" that you mention defined? I admit I >> couldn't find any reference to this in the documentation: >> >>> Using an empty String "" as a regex for the replaceAll() takes the >>> advantage of the special meaning of "", in which it is interpreted as >>> it can match any possible zero-width position of the target String >> I'm not saying you're wrong (and that pattern is definitely not common >> so it's probably academic discussion) but I'd like some concrete >> reference as to how an empty pattern should behave. To me consistency >> with the rest of the Pattern specification would be that it operates >> at "zero width position between unicode characters" not between any >> char[] value, even an incorrect one or in the middle of a surrogate. >> >> Dawid >> >> On Fri, Jun 8, 2012 at 12:46 AM, Xueming Shen wrote: >>> Personally I don't think it is a bug. A j.l.String represents a sequence of >>> UTF-16 chars. While >>> a pair of surrogates represents a supplementary character, a single >>> surrogate itself is still >>> a "legal" independent entity inside a String object and length of a String >>> is still defined as >>> the total number of char unit and an index value between a high surrogate >>> and a low >>> surrogate is still a legal index value that can be used to access the char >>> at that particular >>> position. Using an empty String "" as a regex for the replaceAll() takes the >>> advantage of the >>> special meaning of "", in which it is interpreted as it can match any >>> possible zero-width >>> position of the target String, it does not imply anything regarding >>> "character" or >>> "characters" around it, so I would not interpret it as a zero-with character >>> boundary, >>> therefor a "position" in between a pair surrogates is still a good "found" >>> for replacing. >>> >>> -Sherman >>> >>> >>> On 6/7/2012 1:07 PM, Dawid Weiss wrote: >>>> Hi, I'm a committer to the Apache Lucene project. We have randomized >>>> tests and one seed hit the following (simplified) scenario: >>>> >>>> String s1 = "AB\uD840\uDC00C"; >>>> String s2 = s1.replaceAll("", "X"); >>>> >>>> the input contains an extended unicode character (any surrogate pair >>>> will do). The pattern is an empty string (in fact, it was randomized >>>> as "]|" but it's the same problem so I omit the details). The problem >>>> is that after applying this pattern, replaceAll inserts X in between >>>> the surrogate pair characters and this results in invalid UTF-16: >>>> >>>> AB??C >>>> XAXBX?X?XCX >>>> >>>> I believe this is a bug in the regexp implementation (sorry, don't >>>> have a patch for it) but I'd like to confirm it's not something known. >>>> Pointers appreciated. >>>> >>>> Dawid > From staffan.larsen at oracle.com Fri Jun 8 12:40:28 2012 From: staffan.larsen at oracle.com (staffan.larsen at oracle.com) Date: Fri, 08 Jun 2012 12:40:28 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20120608124049.2B5F6477F3@hg.openjdk.java.net> Changeset: 82c41d3065e2 Author: sla Date: 2012-06-07 15:28 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/82c41d3065e2 7165257: Add JFR tests to the JDK code base Reviewed-by: ohair, dholmes, nloodin, mgronlun ! make/jprt.properties ! test/Makefile Changeset: 961807959c5f Author: sla Date: 2012-06-08 05:39 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/961807959c5f Merge From staffan.larsen at oracle.com Fri Jun 8 12:50:46 2012 From: staffan.larsen at oracle.com (staffan.larsen at oracle.com) Date: Fri, 08 Jun 2012 12:50:46 +0000 Subject: hg: jdk8/tl: 7165257: Add JFR tests to the JDK code base Message-ID: <20120608125046.9BA42477F4@hg.openjdk.java.net> Changeset: df998cd4d51d Author: sla Date: 2012-06-07 15:28 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/rev/df998cd4d51d 7165257: Add JFR tests to the JDK code base Reviewed-by: ohair, dholmes, nloodin, mgronlun ! make/jprt.properties From rob.mckenna at oracle.com Fri Jun 8 17:22:23 2012 From: rob.mckenna at oracle.com (rob.mckenna at oracle.com) Date: Fri, 08 Jun 2012 17:22:23 +0000 Subject: hg: jdk8/tl/jdk: 7161881: (dc) DatagramChannel.bind(null) fails if IPv4 socket and running with preferIPv6Addresses=true Message-ID: <20120608172242.708E247807@hg.openjdk.java.net> Changeset: a7895dc61088 Author: robm Date: 2012-06-08 18:23 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a7895dc61088 7161881: (dc) DatagramChannel.bind(null) fails if IPv4 socket and running with preferIPv6Addresses=true Reviewed-by: alanb, chegar ! src/share/classes/sun/nio/ch/DatagramChannelImpl.java + test/java/nio/channels/DatagramChannel/BindNull.java From xueming.shen at oracle.com Fri Jun 8 18:01:43 2012 From: xueming.shen at oracle.com (Xueming Shen) Date: Fri, 08 Jun 2012 11:01:43 -0700 Subject: Empty regexp replaceall and surrogate pairs results in corrupted utf16. In-Reply-To: References: <4FD12F46.5060505@oracle.com> Message-ID: <4FD23E07.8020203@oracle.com> If we can re-design everything (not the lib, but the language) allover again from the very beginning , and if we all put an i18n engr's hat on:-) it might be nature to have a 32-bit char instead of the 16-bit (OK, it's totally a difference story if from performance point of view), and then we would not have this kind of trouble at all. The reality is that String is still UTF16 and char based, Unicode supplementary code point support is an add-on, so the default index based iteration is char based. You will have to use those codePointXYZ() to do code point based access. If you consider the replaceAll() is to replace all targeted sub-string, and this sub-string happens to be an empty string in this case, as long as String.substring(i, i+1) works for the index "i" which is in between of two paired surrogates, it is hard to argue that you should not replace that "sub-string" with the replacement. Another "excuse" to back my "not a bug" argument is that as the API doc suggests the String.replaceAll() is simply a wrapper of j.u.regex.Matcher, both Pattern and Matcher class all explicitly documents that they work on "CharSequence", which is pure char based and "does not" know code point (for now, with the new defender method, it might be possible to evolute the CharSequence, if desirable, but that would be a totally different discussion). When I say "work on CharSequence", I'm not saying the Pattern does/should not work on code point, actually the implementation "transfers" all the String based pattern into a code point based pattern before interpreting it, but all code/point (mainly for supplementary) support works on the assumption that you have a "constructor". An empty string pattern really does not have any indication on "character". No, I don't think we have any concrete reference as to how an empty string regex should be interpreted. By its nature, it should be the match of every possible zero-width position in the target CharSequence, which is char based upon the API. It might be desired to document this somewhere in the Pattern class. -Sherman On 06/08/2012 04:14 AM, Dawid Weiss wrote: > I guess a lot depends on the point of view. From historical point of > view (where a char[] and a String are basically unsigned values) that > pattern should simply process every value (index) and work like you > say. But from a practical point of view I think it is a bug -- it > corrupts the string, transforming legal unicode into invalid values. > > I checked with Python (3) and the behavior there is the expected one > (it work at the unicode codepoint level rather than surrogate level). > > Where is the behavior of "" that you mention defined? I admit I > couldn't find any reference to this in the documentation: > >> Using an empty String "" as a regex for the replaceAll() takes the >> advantage of the special meaning of "", in which it is interpreted as >> it can match any possible zero-width position of the target String > I'm not saying you're wrong (and that pattern is definitely not common > so it's probably academic discussion) but I'd like some concrete > reference as to how an empty pattern should behave. To me consistency > with the rest of the Pattern specification would be that it operates > at "zero width position between unicode characters" not between any > char[] value, even an incorrect one or in the middle of a surrogate. > > Dawid > > On Fri, Jun 8, 2012 at 12:46 AM, Xueming Shen wrote: >> Personally I don't think it is a bug. A j.l.String represents a sequence of >> UTF-16 chars. While >> a pair of surrogates represents a supplementary character, a single >> surrogate itself is still >> a "legal" independent entity inside a String object and length of a String >> is still defined as >> the total number of char unit and an index value between a high surrogate >> and a low >> surrogate is still a legal index value that can be used to access the char >> at that particular >> position. Using an empty String "" as a regex for the replaceAll() takes the >> advantage of the >> special meaning of "", in which it is interpreted as it can match any >> possible zero-width >> position of the target String, it does not imply anything regarding >> "character" or >> "characters" around it, so I would not interpret it as a zero-with character >> boundary, >> therefor a "position" in between a pair surrogates is still a good "found" >> for replacing. >> >> -Sherman >> >> >> On 6/7/2012 1:07 PM, Dawid Weiss wrote: >>> Hi, I'm a committer to the Apache Lucene project. We have randomized >>> tests and one seed hit the following (simplified) scenario: >>> >>> String s1 = "AB\uD840\uDC00C"; >>> String s2 = s1.replaceAll("", "X"); >>> >>> the input contains an extended unicode character (any surrogate pair >>> will do). The pattern is an empty string (in fact, it was randomized >>> as "]|" but it's the same problem so I omit the details). The problem >>> is that after applying this pattern, replaceAll inserts X in between >>> the surrogate pair characters and this results in invalid UTF-16: >>> >>> AB??C >>> XAXBX?X?XCX >>> >>> I believe this is a bug in the regexp implementation (sorry, don't >>> have a patch for it) but I'd like to confirm it's not something known. >>> Pointers appreciated. >>> >>> Dawid From xueming.shen at oracle.com Fri Jun 8 18:36:57 2012 From: xueming.shen at oracle.com (Xueming Shen) Date: Fri, 08 Jun 2012 11:36:57 -0700 Subject: Empty regexp replaceall and surrogate pairs results in corrupted utf16. In-Reply-To: <4FD1ED27.4070701@gmx.de> References: <4FD12F46.5060505@oracle.com> <4FD1ED27.4070701@gmx.de> Message-ID: <4FD24649.4070908@oracle.com> On 06/08/2012 05:16 AM, Ulf Zibis wrote: > > > Is there any spec weather the Java Regex API has a general contract > with 16-bit chars or Unicode codepoints? The regex spec says Pattern and Matcher work ON character sequence with the reference to CharSequence interface, but the pattern itself does support Unicode character via various regex constructors and flags. An empty String pattern is really a corner case here, it does not say anything about "character", the current implementation interprets it as each, every stop when you iterate through the target CharSequence. It might not be desirable for some use scenario, but not not-reasonable. > > Additionally I like to discuss: "any possible zero-width position of > the target String" > If String length is l, maybe it's arguable, that position l is no > valid position in the String. > If you considering those "boundary matcher" regex constructs, it might be reasonable to consider this "invalid position" as a valid when using regex. I think must of other regex engines do the same thing, for example, the perl. $mystring="Peter"; $mystring =~ s// /g; printf "[%s]\n", $mystring; [ P e t e r ] But I have to say you might have a point here:-) -Sherman > From the use case point of view, I think "P e t e r" as result of > "Peter".replaceAll("", " ") is the most useful. From huizhe.wang at oracle.com Fri Jun 8 18:26:29 2012 From: huizhe.wang at oracle.com (huizhe.wang at oracle.com) Date: Fri, 08 Jun 2012 18:26:29 +0000 Subject: hg: jdk8/tl/jaxp: 7157608: One feature is not recognized. Message-ID: <20120608182633.AD38747809@hg.openjdk.java.net> Changeset: 238d2d0249af Author: joehw Date: 2012-06-08 11:28 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/238d2d0249af 7157608: One feature is not recognized. Summary: adding feature standard-uri-conformant into the recognized list Reviewed-by: psandoz ! src/com/sun/org/apache/xerces/internal/impl/XMLEntityManager.java From Ulf.Zibis at gmx.de Fri Jun 8 19:07:09 2012 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Fri, 08 Jun 2012 21:07:09 +0200 Subject: Empty regexp replaceall and surrogate pairs results in corrupted utf16. In-Reply-To: <4FD24649.4070908@oracle.com> References: <4FD12F46.5060505@oracle.com> <4FD1ED27.4070701@gmx.de> <4FD24649.4070908@oracle.com> Message-ID: <4FD24D5D.3090101@gmx.de> Thanks Sherman! Am 08.06.2012 20:36, schrieb Xueming Shen: > On 06/08/2012 05:16 AM, Ulf Zibis wrote: >> >> >> Is there any spec weather the Java Regex API has a general contract with 16-bit chars or Unicode >> codepoints? > > The regex spec says Pattern and Matcher work ON character sequence with the reference to > CharSequence interface, but the pattern itself does support Unicode character via various > regex constructors and flags. In other words, if there is a surrogate pair in the pattern, the CharSequence is seen as sequence of Unicode code points, right? "\uD840\uDC00\uD840\uDC01\uD840\uDC02".replaceAll("[AB\uD840\uDC01C]", "?") ==> "\uD840\uDC00?\uD840\uDC02" // only 1 replacement for \uD840\uDC01 "12\uD840\uDC02".replaceAll("[^0-9]", "?") ==> "12??" // 2 replacements for \uD840\uDC02 "\uD840\uDC00\uD840\uDC01\uD840\uDC02".replaceAll("[^uD840\uDC00-\uD840\uDC01]", "?") ==> "\uD840\uDC00\uD840\uDC01?" // only 1 replacement for \uD840\uDC02 > An empty String pattern is really a corner case here, it does > not say anything about "character" So it should be specified in the javadoc, and I'm with Dawid to implement it as in Python. -Ulf From huizhe.wang at oracle.com Fri Jun 8 21:42:22 2012 From: huizhe.wang at oracle.com (Joe Wang) Date: Fri, 08 Jun 2012 14:42:22 -0700 Subject: Fwd: Review request for CR 171917 CachedRowSetImpl.populate does not handle map properly In-Reply-To: <5BC5D784-BCBD-4C2B-8874-6128DBABB8BE@oracle.com> References: <73689F85-1321-4642-9F0B-75598029AD00@oracle.com> <5BC5D784-BCBD-4C2B-8874-6128DBABB8BE@oracle.com> Message-ID: <4FD271BE.5080408@oracle.com> Lance, It looks fine to me. Best, Joe On 6/5/2012 7:16 AM, Lance Andersen - Oracle wrote: > Looking for a reviewer here as well still > > Best > Lance > > Begin forwarded message: > >> From: Lance Andersen - Oracle >> Date: May 26, 2012 9:33:40 AM EDT >> Cc: core-libs-dev core-libs-dev >> Subject: Re: Review request for CR 171917 CachedRowSetImpl.populate does not handle map properly >> >> Here is the revised change with David's suggestion. All tests continue to pass >> >> >> new-host-4:rowset lanceandersen$ !hg >> hg diff CachedRowSetImpl.java >> diff -r 4580652d9828 src/share/classes/com/sun/rowset/CachedRowSetImpl.java >> --- a/src/share/classes/com/sun/rowset/CachedRowSetImpl.java Fri May 04 16:00:47 2012 -0400 >> +++ b/src/share/classes/com/sun/rowset/CachedRowSetImpl.java Sat May 26 08:43:15 2012 -0400 >> @@ -659,7 +659,7 @@ >> * us work with drivers that do not support >> * getObject with a map in fairly sensible way >> */ >> - if (map == null) { >> + if (map == null || map.isEmpty()) { >> obj = data.getObject(i); >> } else { >> obj = data.getObject(i, map); >> >> >> Best >> Lance >> On May 25, 2012, at 7:35 PM, David Schlosnagle wrote: >> >>> On Fri, May 25, 2012 at 3:50 PM, Lance Andersen - Oracle >>> wrote: >>>> The populate() method needs to check for a size of 0 for the map in case a webrowset xml file has an empty map tag, which would result in calling setobject specifying a map and not all databases/drivers support this. >>>> >>>> simple 1 line change: >>>> >>>> hg diff CachedRowSetImpl.java >>>> diff -r 4580652d9828 src/share/classes/com/sun/rowset/CachedRowSetImpl.java >>>> --- a/src/share/classes/com/sun/rowset/CachedRowSetImpl.java Fri May 04 16:00:47 2012 -0400 >>>> +++ b/src/share/classes/com/sun/rowset/CachedRowSetImpl.java Fri May 25 15:45:29 2012 -0400 >>>> @@ -659,7 +659,7 @@ >>>> * us work with drivers that do not support >>>> * getObject with a map in fairly sensible way >>>> */ >>>> - if (map == null) { >>>> + if (map == null || map.size() == 0) { >>> Lance, >>> >>> Is there any reason not to use Map.isEmpty() which would be useful if >>> the Map has an expensive size() method? >>> >>> - if (map == null) { >>> + if (map == null || map.isEmpty()) { >>> >>> Thanks, >>> Dave >> >> 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 >> > > 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 > From xueming.shen at oracle.com Fri Jun 8 22:35:27 2012 From: xueming.shen at oracle.com (Xueming Shen) Date: Fri, 08 Jun 2012 15:35:27 -0700 Subject: Empty regexp replaceall and surrogate pairs results in corrupted utf16. In-Reply-To: <4FD24D5D.3090101@gmx.de> References: <4FD12F46.5060505@oracle.com> <4FD1ED27.4070701@gmx.de> <4FD24649.4070908@oracle.com> <4FD24D5D.3090101@gmx.de> Message-ID: <4FD27E2F.4020707@oracle.com> On 06/08/2012 12:07 PM, Ulf Zibis wrote: > Thanks Sherman! > > Am 08.06.2012 20:36, schrieb Xueming Shen: >> On 06/08/2012 05:16 AM, Ulf Zibis wrote: >>> >>> >>> Is there any spec weather the Java Regex API has a general contract >>> with 16-bit chars or Unicode codepoints? >> >> The regex spec says Pattern and Matcher work ON character sequence >> with the reference to >> CharSequence interface, but the pattern itself does support Unicode >> character via various >> regex constructors and flags. > In other words, if there is a surrogate pair in the pattern, the > CharSequence is seen as sequence of Unicode code points, right? No exactly what I meant. The engine currently works as if the pattern is to match a "character" or "slice of characters" that has supplementary character embedded, engine will try to interpret the target char sequence as a sequence of Unicode code point. If the pattern is not to match a "character" or match a slice of characters that does not have supplementary character embedded, the engine will try to interpret the char sequence as a sequence of char unit. For example Matcher m = Pattern.compile("[^a]").matcher("\uD840\uDC00\uD840\uDC01\uD840\uDC02"); while (m.find()) { System.out.printf("<%d, %d>%n", m.start(), m.end()); } The output is <0, 2> <2, 4> <4, 6> The target string is iterated code point by code point, but Matcher m = Pattern.compile("(?=[^a])").matcher("\uD840\uDC00\uD840\uDC01\uD840\uDC02"); while (m.find()) { System.out.printf("<%d, %d>%n", m.start(), m.end()); } The output is <0, 0> <1, 1> <2, 2> <3, 3> <4, 4> <5, 5> And the empty string pattern belongs to the latter case. No, I'm not saying because the implementation works this way, therefor this is not a bug:-) Actually I'm starting to agree that we might not want to stop in the middle of a pair of surrogates, even in non-character case. But it might have some performance impact somewhere (if you iterate the CharSequence by code point). -Sherman > "\uD840\uDC00\uD840\uDC01\uD840\uDC02".replaceAll("[AB\uD840\uDC01C]", > "?") > ==> "\uD840\uDC00?\uD840\uDC02" // only 1 replacement for > \uD840\uDC01 > "12\uD840\uDC02".replaceAll("[^0-9]", "?") > ==> "12??" // 2 replacements for \uD840\uDC02 > "\uD840\uDC00\uD840\uDC01\uD840\uDC02".replaceAll("[^uD840\uDC00-\uD840\uDC01]", > "?") > ==> "\uD840\uDC00\uD840\uDC01?" // only 1 replacement for > \uD840\uDC02 > > >> An empty String pattern is really a corner case here, it does >> not say anything about "character" > So it should be specified in the javadoc, and I'm with Dawid to > implement it as in Python. > > -Ulf > From alan.bateman at oracle.com Sun Jun 10 09:33:58 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Sun, 10 Jun 2012 09:33:58 +0000 Subject: hg: jdk8/tl/jdk: 7175775: Disable SA options in jinfo/Basic.java test until SA updated for new hash and String count/offset Message-ID: <20120610093426.2D63847829@hg.openjdk.java.net> Changeset: fc575c78f5d3 Author: alanb Date: 2012-06-10 10:29 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fc575c78f5d3 7175775: Disable SA options in jinfo/Basic.java test until SA updated for new hash and String count/offset Reviewed-by: minqi ! test/sun/tools/jinfo/Basic.sh From dbelfer at gmail.com Sun Jun 10 23:12:04 2012 From: dbelfer at gmail.com (Diego Belfer) Date: Sun, 10 Jun 2012 20:12:04 -0300 Subject: 6901992 : Possible InvalidJarIndexException due to bug in sun.misc.JarIndex.merge() Message-ID: Hi, I am working on the bug 6901992. I have already fixed the merge method and I have created a test case for it too. Nevertheless, I was unable to reproduce the bug as a whole (using the ClassLoader mechanism) and get the InvalidJarIndexException, since the only way I might think of triggering the error is using an invalid index (INDEX.LIST), which does not make sense. I am triying to reproduce the bug using the URLClassLoader but maybe there is a different usage pattern implemented in the com.sun.deploy.cache classes. Where I can find the source files of that package? In addition, I could not find documentation or specification about how the classloader should process the INDEX.LST. For instance, it was a surprise for me that a jar listed in the INDEX.LIST was included by the classloader without an explicit listing in the classpath. Is there any specification for this? Thanks, Diego From lance.andersen at oracle.com Mon Jun 11 11:11:34 2012 From: lance.andersen at oracle.com (lance.andersen at oracle.com) Date: Mon, 11 Jun 2012 11:11:34 +0000 Subject: hg: jdk8/tl/jdk: 7171917: CachedRowSetImpl.populate does not handle map properly Message-ID: <20120611111155.62A8E47850@hg.openjdk.java.net> Changeset: 46ff1b63b0c3 Author: lancea Date: 2012-06-11 07:10 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/46ff1b63b0c3 7171917: CachedRowSetImpl.populate does not handle map properly Reviewed-by: joehw ! src/share/classes/com/sun/rowset/CachedRowSetImpl.java From tom.hawtin at oracle.com Mon Jun 11 12:44:16 2012 From: tom.hawtin at oracle.com (Tom Hawtin) Date: Mon, 11 Jun 2012 13:44:16 +0100 Subject: review request 7172551 In-Reply-To: <4FD1119F.6040008@oracle.com> References: <2EFD8707-1603-4CCD-A431-2325D2EF044B@oracle.com> <4FD1119F.6040008@oracle.com> Message-ID: <4FD5E820.4060704@oracle.com> On 07/06/2012 21:39, Joe Darcy wrote: > I'd like to see some "()" on this line! > > 470 ClassLoader cl = cc != null ? cc.getClassLoader() : null; It's `a==b ? c : d` is such an incredibly common idiom in Java, and generally unambiguous, that parentheses are unhelpful noise. Emphasising precedence with spacing is good. And I personally have a strong dislike of the double negative. 470 ClassLoader cl = cc==null ? null : cc.getClassLoader(); Tom From staffan.larsen at oracle.com Mon Jun 11 18:52:21 2012 From: staffan.larsen at oracle.com (staffan.larsen at oracle.com) Date: Mon, 11 Jun 2012 18:52:21 +0000 Subject: hg: jdk8/tl: 7175802: Missing jdk_jfr in top-level make file Message-ID: <20120611185221.CD62F4786A@hg.openjdk.java.net> Changeset: 1af3996aa431 Author: sla Date: 2012-06-11 20:52 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/rev/1af3996aa431 7175802: Missing jdk_jfr in top-level make file Reviewed-by: alanb ! test/Makefile From huizhe.wang at oracle.com Mon Jun 11 19:08:17 2012 From: huizhe.wang at oracle.com (Joe Wang) Date: Mon, 11 Jun 2012 12:08:17 -0700 Subject: [7u6] RFR (JAXP) : 7157610: NullPointerException occurs when parsing XML doc Message-ID: <4FD64221.3050609@oracle.com> As reported in 7157610, when setFeature("http://apache.org/xml/features/disallow-doctype-decl", true) is set on SAXParserFactory object, XMLReader object or DocumentBuilderFactory object, NullPointerException will be thrown when parsing XML document that has DOCTYPE declaration. The cause of the issue was that when StAX was added, the above feature was reused for a StAX feature, SupportDTD. However, in the StAX spec, the requirement was not always consistent with that of feature 'disallow-doctype-decl'. The patch is to recover what was the original disallow-doctype-decl, reporting error when disallow-doctype-decl is true, and change everything else that was added for SupportDTD to be governed by a new flag 'fSupportDTD'. Here's the webrev: http://cr.openjdk.java.net/~joehw/7u6/7157610/webrev/ All of unit/sqe/tck tests passed. Please review. Thanks, Joe From Lance.Andersen at oracle.com Mon Jun 11 19:33:00 2012 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Mon, 11 Jun 2012 15:33:00 -0400 Subject: [7u6] RFR (JAXP) : 7157610: NullPointerException occurs when parsing XML doc In-Reply-To: <4FD64221.3050609@oracle.com> References: <4FD64221.3050609@oracle.com> Message-ID: <52B18667-B385-4946-9EBF-AE76FD2BDFBA@oracle.com> Looks OK joe. Do you still need the comment //return fSupportDTD? next() : dtdEvent; in XMLDocumentScannerImpl? If not you might consider removing it. Best Lance On Jun 11, 2012, at 3:08 PM, Joe Wang wrote: > As reported in 7157610, when setFeature("http://apache.org/xml/features/disallow-doctype-decl", true) is set on SAXParserFactory object, XMLReader object or DocumentBuilderFactory object, NullPointerException will be thrown when parsing XML document that has DOCTYPE declaration. > > The cause of the issue was that when StAX was added, the above feature was reused for a StAX feature, SupportDTD. However, in the StAX spec, the requirement was not always consistent with that of feature 'disallow-doctype-decl'. > > The patch is to recover what was the original disallow-doctype-decl, reporting error when disallow-doctype-decl is true, and change everything else that was added for SupportDTD to be governed by a new flag 'fSupportDTD'. > > Here's the webrev: > http://cr.openjdk.java.net/~joehw/7u6/7157610/webrev/ > > All of unit/sqe/tck tests passed. > > Please review. > > Thanks, > Joe > 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 From dbelfer at gmail.com Mon Jun 11 19:47:03 2012 From: dbelfer at gmail.com (Diego Belfer) Date: Mon, 11 Jun 2012 16:47:03 -0300 Subject: PATCH [6901992] : Possible InvalidJarIndexException due to bug in sun.misc.JarIndex.merge() Message-ID: Hi, Here is a patch that fixes the merge method of the JarIndex. This bug was reported as the cause of the bug 6901992. Although, I was not able to reproduce the BUG itself (InvalidJarIndexException), I did verified that the method had a bug, and resources/classes where not found in a jarIndex with merged contents. If you think it is possible to commit this fix without actually reproducing the original bug report, please consider this patch for review. Thanks, Diego Belfer [muralx] # HG changeset patch # User muralx # Date 1339374533 10800 # Node ID 5468e0a8af8a9638c930a14a0134d378754b3c97 # Parent fc575c78f5d314fd8ccbdc86c8b2d7631d736960 [PATCH] 6901992 - Possible InvalidJarIndexException due to bug in sun.misc.JarIndex.merge() diff --git a/src/share/classes/sun/misc/JarIndex.java b/src/share/classes/sun/misc/JarIndex.java --- a/src/share/classes/sun/misc/JarIndex.java +++ b/src/share/classes/sun/misc/JarIndex.java @@ -201,23 +201,20 @@ packageName = fileName; } - // add the mapping to indexMap - addToList(packageName, jarName, indexMap); - - // add the mapping to jarMap - addToList(jarName, packageName, jarMap); + addMapping(packageName, jarName); } /** * Same as add(String,String) except that it doesn't strip off from the - * last index of '/'. It just adds the filename. + * last index of '/'. It just adds the jarItem (filename or package) + * as it is received. */ - private void addExplicit(String fileName, String jarName) { + private void addMapping(String jarItem, String jarName) { // add the mapping to indexMap - addToList(fileName, jarName, indexMap); + addToList(jarItem, jarName, indexMap); // add the mapping to jarMap - addToList(jarName, fileName, jarMap); + addToList(jarName, jarItem, jarMap); } /** @@ -248,18 +245,14 @@ fileName.equals(JarFile.MANIFEST_NAME)) continue; - if (!metaInfFilenames) { + if (!metaInfFilenames || !fileName.startsWith("META-INF/")) { add(fileName, currentJar); - } else { - if (!fileName.startsWith("META-INF/")) { - add(fileName, currentJar); - } else if (!entry.isDirectory()) { + } else if (!entry.isDirectory()) { // Add files under META-INF explicitly so that certain // services, like ServiceLoader, etc, can be located // with greater accuracy. Directories can be skipped // since each file will be added explicitly. - addExplicit(fileName, currentJar); - } + addMapping(fileName, currentJar); } } @@ -324,8 +317,7 @@ jars.add(currentJar); } else { String name = line; - addToList(name, currentJar, indexMap); - addToList(currentJar, name, jarMap); + addMapping(name, currentJar); } } @@ -354,7 +346,7 @@ if (path != null) { jarName = path.concat(jarName); } - toIndex.add(packageName, jarName); + toIndex.addMapping(packageName, jarName); } } } diff --git a/test/sun/misc/JarIndex/JarIndexMergeTest.java b/test/sun/misc/JarIndex/JarIndexMergeTest.java new file mode 100644 --- /dev/null +++ b/test/sun/misc/JarIndex/JarIndexMergeTest.java @@ -0,0 +1,74 @@ +/* + * Copyright (c) 2012, Oracle and/or its affiliates. All rights reserved. + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. + * + * This code is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License version 2 only, as + * published by the Free Software Foundation. + * + * This code is distributed in the hope that it will be useful, but WITHOUT + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License + * version 2 for more details (a copy is included in the LICENSE file that + * accompanied this code). + * + * You should have received a copy of the GNU General Public License version + * 2 along with this work; if not, write to the Free Software Foundation, + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. + * + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA + * or visit www.oracle.com if you need additional information or have any + * questions. + */ + +/* + * @test + * @bug 6901992 + * @summary Possible InvalidJarIndexException due to bug in sun.misc.JarIndex.merge() + * @author Diego Belfer + */ + +import java.io.File; +import java.util.LinkedList; + +import sun.misc.JarIndex; + + at SuppressWarnings("restriction") +public class JarIndexMergeTest { + static final String slash = File.separator; + static final String testSrc = System.getProperty("test.src"); + static final String testSrcDir = testSrc != null ? testSrc : "."; + + public static void main(String[] args) throws Exception { + + JarIndex jarIndexMissing = new JarIndex( + new String[] { testSrcDir + slash + "jarIndexMerge" + slash + "missing.jar" }); + LinkedList jarLists = jarIndexMissing + .get("fail/subdir/resourceToSearch.properties"); + if (jarLists != null && jarLists.size() > 0) { + throw new RuntimeException( + "Unexpected result: missing.jar should not contain the required file"); + } + + String containerJarName = testSrcDir + slash +"jarIndexMerge" + slash + "container.jar"; + JarIndex jarIndexContainer = new JarIndex( + new String[] { containerJarName }); + jarLists = jarIndexContainer + .get("fail/subdir/resourceToSearch.properties"); + if (jarLists == null || jarLists.size() == 0) { + throw new RuntimeException( + "Unexpected result: container.jar should contain the required file"); + } + + // We merge the index into the jarIndexMissing + jarIndexContainer.merge(jarIndexMissing, null); + + jarLists = jarIndexMissing + .get("fail/subdir/resourceToSearch.properties"); + if (jarLists == null || jarLists.size() == 0 || !containerJarName.equals(jarLists.get(0))) { + throw new RuntimeException( + "Unexpected result: the merged index should contain the required file"); + } + } + +} diff --git a/test/sun/misc/JarIndex/jarIndexMerge/container.jar b/test/sun/misc/JarIndex/jarIndexMerge/container.jar new file mode 100644 index 0000000000000000000000000000000000000000..9cf5b457aa50cd067390dfa6ce60409c0059ed82 GIT binary patch literal 1370 zc$}4!%}T>S6h?2-RxlL7ZFl0LyOgxzTHK0I&=-j56hng(X3`gN?b at wwbni-Z=_~jm zPTIyhKX(%S!Vm)Axpx*P^NU_Tf;va5&oj_6P-mIu#bo|lNvz7SsmS%sA{Q;qvDFkz z^0mm=HNRr1$Zq3O at RErtXA*}zEX*N?>IlxO29B3`!La^h)%)tGb=s|-t;YVYQ88I* zwGXRypx4T5HErpRoNiX6Ql7+{7jo}^<7PJZ+Hto;yW300j%2$d>DuAprVST_5%?W4 zvoi`2$|=k-*oOJZu|ZzKKa9hnlyjJSAPq#EauD+djgd%DPGY{nFcdM$QA`xL#`@Wj z!Jay-X)w;A9LC(yb7t-w%4y7F;2MrBn_~jf_lO z47j5X6+j~rp#@u1B7iajYQ*BUiXTOvH at cgR@M at Mu(OiM488zaGHE1IagN!i^!j=>e w;1vV*gh6a at NHJnbD8%~09aA%E!Xeh61{?;#6A~*MNEs&(dNMIE>|_M-0Qru!D*ylh -------------- next part -------------- # HG changeset patch # User muralx # Date 1339374533 10800 # Node ID 5468e0a8af8a9638c930a14a0134d378754b3c97 # Parent fc575c78f5d314fd8ccbdc86c8b2d7631d736960 [PATCH] 6901992 - Possible InvalidJarIndexException due to bug in sun.misc.JarIndex.merge() diff --git a/src/share/classes/sun/misc/JarIndex.java b/src/share/classes/sun/misc/JarIndex.java --- a/src/share/classes/sun/misc/JarIndex.java +++ b/src/share/classes/sun/misc/JarIndex.java @@ -201,23 +201,20 @@ packageName = fileName; } - // add the mapping to indexMap - addToList(packageName, jarName, indexMap); - - // add the mapping to jarMap - addToList(jarName, packageName, jarMap); + addMapping(packageName, jarName); } /** * Same as add(String,String) except that it doesn't strip off from the - * last index of '/'. It just adds the filename. + * last index of '/'. It just adds the jarItem (filename or package) + * as it is received. */ - private void addExplicit(String fileName, String jarName) { + private void addMapping(String jarItem, String jarName) { // add the mapping to indexMap - addToList(fileName, jarName, indexMap); + addToList(jarItem, jarName, indexMap); // add the mapping to jarMap - addToList(jarName, fileName, jarMap); + addToList(jarName, jarItem, jarMap); } /** @@ -248,18 +245,14 @@ fileName.equals(JarFile.MANIFEST_NAME)) continue; - if (!metaInfFilenames) { + if (!metaInfFilenames || !fileName.startsWith("META-INF/")) { add(fileName, currentJar); - } else { - if (!fileName.startsWith("META-INF/")) { - add(fileName, currentJar); - } else if (!entry.isDirectory()) { + } else if (!entry.isDirectory()) { // Add files under META-INF explicitly so that certain // services, like ServiceLoader, etc, can be located // with greater accuracy. Directories can be skipped // since each file will be added explicitly. - addExplicit(fileName, currentJar); - } + addMapping(fileName, currentJar); } } @@ -324,8 +317,7 @@ jars.add(currentJar); } else { String name = line; - addToList(name, currentJar, indexMap); - addToList(currentJar, name, jarMap); + addMapping(name, currentJar); } } @@ -354,7 +346,7 @@ if (path != null) { jarName = path.concat(jarName); } - toIndex.add(packageName, jarName); + toIndex.addMapping(packageName, jarName); } } } diff --git a/test/sun/misc/JarIndex/JarIndexMergeTest.java b/test/sun/misc/JarIndex/JarIndexMergeTest.java new file mode 100644 --- /dev/null +++ b/test/sun/misc/JarIndex/JarIndexMergeTest.java @@ -0,0 +1,74 @@ +/* + * Copyright (c) 2012, Oracle and/or its affiliates. All rights reserved. + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. + * + * This code is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License version 2 only, as + * published by the Free Software Foundation. + * + * This code is distributed in the hope that it will be useful, but WITHOUT + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License + * version 2 for more details (a copy is included in the LICENSE file that + * accompanied this code). + * + * You should have received a copy of the GNU General Public License version + * 2 along with this work; if not, write to the Free Software Foundation, + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. + * + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA + * or visit www.oracle.com if you need additional information or have any + * questions. + */ + +/* + * @test + * @bug 6901992 + * @summary Possible InvalidJarIndexException due to bug in sun.misc.JarIndex.merge() + * @author Diego Belfer + */ + +import java.io.File; +import java.util.LinkedList; + +import sun.misc.JarIndex; + + at SuppressWarnings("restriction") +public class JarIndexMergeTest { + static final String slash = File.separator; + static final String testSrc = System.getProperty("test.src"); + static final String testSrcDir = testSrc != null ? testSrc : "."; + + public static void main(String[] args) throws Exception { + + JarIndex jarIndexMissing = new JarIndex( + new String[] { testSrcDir + slash + "jarIndexMerge" + slash + "missing.jar" }); + LinkedList jarLists = jarIndexMissing + .get("fail/subdir/resourceToSearch.properties"); + if (jarLists != null && jarLists.size() > 0) { + throw new RuntimeException( + "Unexpected result: missing.jar should not contain the required file"); + } + + String containerJarName = testSrcDir + slash +"jarIndexMerge" + slash + "container.jar"; + JarIndex jarIndexContainer = new JarIndex( + new String[] { containerJarName }); + jarLists = jarIndexContainer + .get("fail/subdir/resourceToSearch.properties"); + if (jarLists == null || jarLists.size() == 0) { + throw new RuntimeException( + "Unexpected result: container.jar should contain the required file"); + } + + // We merge the index into the jarIndexMissing + jarIndexContainer.merge(jarIndexMissing, null); + + jarLists = jarIndexMissing + .get("fail/subdir/resourceToSearch.properties"); + if (jarLists == null || jarLists.size() == 0 || !containerJarName.equals(jarLists.get(0))) { + throw new RuntimeException( + "Unexpected result: the merged index should contain the required file"); + } + } + +} diff --git a/test/sun/misc/JarIndex/jarIndexMerge/container.jar b/test/sun/misc/JarIndex/jarIndexMerge/container.jar new file mode 100644 index 0000000000000000000000000000000000000000..9cf5b457aa50cd067390dfa6ce60409c0059ed82 GIT binary patch literal 1370 zc$}4!%}T>S6h?2-RxlL7ZFl0LyOgxzTHK0I&=-j56hng(X3`gN?b at wwbni-Z=_~jm zPTIyhKX(%S!Vm)Axpx*P^NU_Tf;va5&oj_6P-mIu#bo|lNvz7SsmS%sA{Q;qvDFkz z^0mm=HNRr1$Zq3O at RErtXA*}zEX*N?>IlxO29B3`!La^h)%)tGb=s|-t;YVYQ88I* zwGXRypx4T5HErpRoNiX6Ql7+{7jo}^<7PJZ+Hto;yW300j%2$d>DuAprVST_5%?W4 zvoi`2$|=k-*oOJZu|ZzKKa9hnlyjJSAPq#EauD+djgd%DPGY{nFcdM$QA`xL#`@Wj z!Jay-X)w;A9LC(yb7t-w%4y7F;2MrBn_~jf_lO z47j5X6+j~rp#@u1B7iajYQ*BUiXTOvH at cgR@M at Mu(OiM488zaGHE1IagN!i^!j=>e w;1vV*gh6a at NHJnbD8%~09aA%E!Xeh61{?;#6A~*MNEs&(dNMIE>|_M-0Qru!D*ylh From huizhe.wang at oracle.com Mon Jun 11 20:23:58 2012 From: huizhe.wang at oracle.com (Joe Wang) Date: Mon, 11 Jun 2012 13:23:58 -0700 Subject: [7u6] RFR (JAXP) : 7157610: NullPointerException occurs when parsing XML doc In-Reply-To: <52B18667-B385-4946-9EBF-AE76FD2BDFBA@oracle.com> References: <4FD64221.3050609@oracle.com> <52B18667-B385-4946-9EBF-AE76FD2BDFBA@oracle.com> Message-ID: <4FD653DE.5060107@oracle.com> Thanks Lance. That comment was there forever, removed now :) New webrev: http://cr.openjdk.java.net/~joehw/7u6/7157610/webrev/ -Joe On 6/11/2012 12:33 PM, Lance Andersen - Oracle wrote: > Looks OK joe. > > Do you still need the comment > > //return fSupportDTD? next() : dtdEvent; > > in XMLDocumentScannerImpl? If not you might consider removing it. > > Best > Lance > > On Jun 11, 2012, at 3:08 PM, Joe Wang wrote: > >> As reported in 7157610, when >> setFeature("http://apache.org/xml/features/disallow-doctype-decl", >> true) is set on SAXParserFactory object, XMLReader object or >> DocumentBuilderFactory object, NullPointerException will be thrown >> when parsing XML document that has DOCTYPE declaration. >> >> The cause of the issue was that when StAX was added, the above >> feature was reused for a StAX feature, SupportDTD. However, in the >> StAX spec, the requirement was not always consistent with that of >> feature 'disallow-doctype-decl'. >> >> The patch is to recover what was the original disallow-doctype-decl, >> reporting error when disallow-doctype-decl is true, and change >> everything else that was added for SupportDTD to be governed by a new >> flag 'fSupportDTD'. >> >> Here's the webrev: >> http://cr.openjdk.java.net/~joehw/7u6/7157610/webrev/ >> >> >> All of unit/sqe/tck tests passed. >> >> Please review. >> >> Thanks, >> Joe >> > > > 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 > From Lance.Andersen at oracle.com Mon Jun 11 20:27:42 2012 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Mon, 11 Jun 2012 16:27:42 -0400 Subject: [7u6] RFR (JAXP) : 7157610: NullPointerException occurs when parsing XML doc In-Reply-To: <4FD653DE.5060107@oracle.com> References: <4FD64221.3050609@oracle.com> <52B18667-B385-4946-9EBF-AE76FD2BDFBA@oracle.com> <4FD653DE.5060107@oracle.com> Message-ID: Hi Joe, No need to see it with just the change of the comment removed... good to go by me :-) Best Lance On Jun 11, 2012, at 4:23 PM, Joe Wang wrote: > Thanks Lance. > > That comment was there forever, removed now :) > > New webrev: > http://cr.openjdk.java.net/~joehw/7u6/7157610/webrev/ > > -Joe > > > On 6/11/2012 12:33 PM, Lance Andersen - Oracle wrote: >> >> Looks OK joe. >> >> Do you still need the comment >> >> //return fSupportDTD? next() : dtdEvent; >> >> in XMLDocumentScannerImpl? If not you might consider removing it. >> >> Best >> Lance >> >> On Jun 11, 2012, at 3:08 PM, Joe Wang wrote: >> >>> As reported in 7157610, when setFeature("http://apache.org/xml/features/disallow-doctype-decl", true) is set on SAXParserFactory object, XMLReader object or DocumentBuilderFactory object, NullPointerException will be thrown when parsing XML document that has DOCTYPE declaration. >>> >>> The cause of the issue was that when StAX was added, the above feature was reused for a StAX feature, SupportDTD. However, in the StAX spec, the requirement was not always consistent with that of feature 'disallow-doctype-decl'. >>> >>> The patch is to recover what was the original disallow-doctype-decl, reporting error when disallow-doctype-decl is true, and change everything else that was added for SupportDTD to be governed by a new flag 'fSupportDTD'. >>> >>> Here's the webrev: >>> http://cr.openjdk.java.net/~joehw/7u6/7157610/webrev/ >>> >>> All of unit/sqe/tck tests passed. >>> >>> Please review. >>> >>> Thanks, >>> Joe >>> >> >> >> 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 >> 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 From jim.gish at oracle.com Mon Jun 11 21:59:03 2012 From: jim.gish at oracle.com (Jim Gish) Date: Mon, 11 Jun 2012 17:59:03 -0400 Subject: specification for null handling in String, StringBuilder, etc. Message-ID: <4FD66A27.6050501@oracle.com> While triaging outstanding String bugs, I was looking at 4247235, "(spec str) StringBuffer.insert(int, char[]) specification is inconsistent" Although the description is out of date w.r.t. the current code, I did find what I would consider weaknesses (maybe even holes) in the specs relative to this issue. It appears that the common practice is to spec checked exceptions but not unchecked exceptions (which I understand). For example, in the case mentioned the spec indicates that StringIndexOutOfBoundsException is thrown if the offset is invalid, and is silent about the consequences of the char[] being null. In the latter case, it throws NullPointerException, but the str == null is not checked, rather it simply tries to access str.length and fails if str is null. My personal feeling is that pre-conditions should be explicitly checked for and be spec'd. One might argue that the spec is complete, because it says that "The overall effect is exactly as if the second argument were converted to a string by String.valueOf( char[] ),..." If you look at the class javadoc for String there is a statement that "Unless otherwise noted, passing a null argument to a constructor or method in this class will cause a || |NullPointerException| to be thrown." However, if the user simply looks at the javadoc for String.valueOf( char[] ) nothing is said about null handling there. The user would have to have read the class javadoc to catch the reference to NullPointerException. Seems like an unreasonably indirect chain to have to follow, when all we'd have to say is that the original insert method throws NPE if the char[] is null. I suggest we improve the readability here (and in related places) and tell the user straight off the effect of passing null. Cheers Jim Gish From huizhe.wang at oracle.com Mon Jun 11 22:45:07 2012 From: huizhe.wang at oracle.com (huizhe.wang at oracle.com) Date: Mon, 11 Jun 2012 22:45:07 +0000 Subject: hg: jdk8/tl/jaxp: 7157610: NullPointerException occurs when parsing XML doc Message-ID: <20120611224512.56C1547882@hg.openjdk.java.net> Changeset: f328914a04ea Author: joehw Date: 2012-06-11 15:47 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/f328914a04ea 7157610: NullPointerException occurs when parsing XML doc Summary: recovers what was the original disallow-doctype-decl, reporting error when disallow-doctype-decl is true, and change everything else that was added for SupportDTD to be governed by a new flag 'fSupportDTD'. Reviewed-by: lancea ! src/com/sun/org/apache/xerces/internal/impl/XMLDocumentFragmentScannerImpl.java ! src/com/sun/org/apache/xerces/internal/impl/XMLDocumentScannerImpl.java From kelly.ohair at oracle.com Mon Jun 11 22:55:34 2012 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Mon, 11 Jun 2012 15:55:34 -0700 Subject: review request 7172551 In-Reply-To: <4FD5E820.4060704@oracle.com> References: <2EFD8707-1603-4CCD-A431-2325D2EF044B@oracle.com> <4FD1119F.6040008@oracle.com> <4FD5E820.4060704@oracle.com> Message-ID: <9B7EFB68-40AB-4F07-949F-AA410730BCD5@oracle.com> On Jun 11, 2012, at 5:44 AM, Tom Hawtin wrote: > > > On 07/06/2012 21:39, Joe Darcy wrote: >> I'd like to see some "()" on this line! >> >> 470 ClassLoader cl = cc != null ? cc.getClassLoader() : null; > > It's `a==b ? c : d` is such an incredibly common idiom in Java, and generally unambiguous, that parentheses are unhelpful noise. Emphasising precedence with spacing is good. And I personally have a strong dislike of the double negative. Just my 2 cents on this... I agree with you on the double negative. But I like parens, and spaces are not a substitute all the time. Parens can serve to clarify, and I find them more helpful than not, paren use would have to be pretty excessive for me to complain about them. Spaces can come and go if you use things like NetBeans format options and how you have the spacing options defined. -kto > > 470 ClassLoader cl = cc==null ? null : cc.getClassLoader(); > > Tom From kumar.x.srinivasan at oracle.com Mon Jun 11 22:58:30 2012 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Mon, 11 Jun 2012 22:58:30 +0000 Subject: hg: jdk8/tl/langtools: 7160072: (javac) JavacParserTests needs cleanup Message-ID: <20120611225835.28BF247883@hg.openjdk.java.net> Changeset: 9cafabb5e576 Author: ksrini Date: 2012-06-11 15:33 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/9cafabb5e576 7160072: (javac) JavacParserTests needs cleanup Reviewed-by: jjg ! test/tools/javac/parser/JavacParserTest.java From huizhe.wang at oracle.com Mon Jun 11 23:23:46 2012 From: huizhe.wang at oracle.com (Joe Wang) Date: Mon, 11 Jun 2012 16:23:46 -0700 Subject: [7u6] RFR (JAXP) : 7144423: StAX EventReader swallows the cause of error Message-ID: <4FD67E02.3070904@oracle.com> Hi, This is patch to make sure the cause of the error is properly reported. It has been in jaxp since Feb. webrev: http://cr.openjdk.java.net/~joehw/7u6/7143711/webrev/ Please review. Thanks, Joe From peter.levart at gmail.com Sun Jun 3 20:44:38 2012 From: peter.levart at gmail.com (Peter Levart) Date: Sun, 03 Jun 2012 22:44:38 +0200 Subject: hg: jdk8/tl/jdk: 6924259: Remove offset and count fields from java.lang.String In-Reply-To: <20120531032252.A69774763C@hg.openjdk.java.net> References: <20120531032252.A69774763C@hg.openjdk.java.net> Message-ID: <1359801.KFxJhQHyve@cube> On Thursday, May 31, 2012 03:22:35 AM mike.duigou at oracle.com wrote: > Changeset: 2c773daa825d > Author: mduigou > Date: 2012-05-17 10:06 -0700 > URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2c773daa825d > > 6924259: Remove offset and count fields from java.lang.String > Summary: Removes the use of shared character array buffers by String along > with the two fields needed to support the use of shared buffers. Wow, that's quite a change. So .substring() is not O(1) any more? Doesn't this have impact on the performance of parsers and such that rely on the performance caracteristics of the .substring() ? Have you considered then implementing .subSequence() not in terms of just delegating to .substring() but returning a special CharSequence view over the chars of the sub-sequence? Regards, Peter > Reviewed-by: alanb, mduigou, forax, briangoetz > Contributed-by: brian.doherty at oracle.com > > ! src/share/classes/java/lang/Integer.java > ! src/share/classes/java/lang/Long.java > ! src/share/classes/java/lang/String.java > ! src/share/classes/java/lang/StringCoding.java From roland.westrelin at oracle.com Tue Jun 5 20:04:30 2012 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Tue, 5 Jun 2012 22:04:30 +0200 Subject: Failing jdk testcase: java/lang/Math/WorstCaseTests.java In-Reply-To: <4FCE3D85.5000500@oracle.com> References: <299AAC76-60DD-40BC-8346-75A114CC37A5@oracle.com> <4FCE3D85.5000500@oracle.com> Message-ID: <97B13958-535E-40BF-AB4B-3922D7EE5DA1@oracle.com> > cc'ing Rroland Westrelin, as this may be caused by some of the changes in hs24-b12. Note that jdk8/tl is only sync with b11 and that probably explains why we aren't seeing them here. Yes, a change we made to speed up pow/exp calculation by relying on x86 fpu instructions broke this test. Is there an existing CR for this failure already? Otherwise I'll file it. Roland. From david.holmes at oracle.com Tue Jun 12 05:40:48 2012 From: david.holmes at oracle.com (David Holmes) Date: Tue, 12 Jun 2012 15:40:48 +1000 Subject: specification for null handling in String, StringBuilder, etc. In-Reply-To: <4FD66A27.6050501@oracle.com> References: <4FD66A27.6050501@oracle.com> Message-ID: <4FD6D660.7010704@oracle.com> Hi Jim, On 12/06/2012 7:59 AM, Jim Gish wrote: > While triaging outstanding String bugs, I was looking at 4247235, "(spec > str) StringBuffer.insert(int, char[]) specification is inconsistent" > > Although the description is out of date w.r.t. the current code, I did > find what I would consider weaknesses (maybe even holes) in the specs > relative to this issue. > > It appears that the common practice is to spec checked exceptions but > not unchecked exceptions (which I understand). For example, in the case > mentioned the spec indicates that StringIndexOutOfBoundsException is > thrown if the offset is invalid, and is silent about the consequences of > the char[] being null. In the latter case, it throws > NullPointerException, but the str == null is not checked, rather it > simply tries to access str.length and fails if str is null. > > My personal feeling is that pre-conditions should be explicitly checked > for and be spec'd. This is very, very common in the core libraries. Rather than document every single method where a null parameter triggers NPE they are often covered (directly or indirectly) by blanket statements of the form "unless otherwise stated ...". I'm strongly of the opinion that people should be reading the complete specification for any type they use, not just individual methods. So I don't have a problem with not documenting this on each method - there are likely to be far more significant misunderstandings of behaviour if you don't read all the docs. But I understand others will see this from the other side. Also note that the handling of unchecked exceptions by JavaDoc complicates things because overriding implementations need to re-state that they throw the NPE (or whatever it may be), using @inheritDoc, even if there is no change from the superclass or interface specification of the method. David ----- > One might argue that the spec is complete, because it says that "The > overall effect is exactly as if the second argument were converted to a > string by String.valueOf( char[] ),..." If you look at the class javadoc > for String there is a statement that "Unless otherwise noted, passing a > null argument to a constructor or method in this class will cause a || > |NullPointerException| > to be thrown." However, if the user simply looks at the javadoc for > String.valueOf( char[] ) nothing is said about null handling there. The > user would have to have read the class javadoc to catch the reference to > NullPointerException. Seems like an unreasonably indirect chain to have > to follow, when all we'd have to say is that the original insert method > throws NPE if the char[] is null. > > I suggest we improve the readability here (and in related places) and > tell the user straight off the effect of passing null. > > Cheers > Jim Gish > > From forax at univ-mlv.fr Tue Jun 12 06:54:12 2012 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Tue, 12 Jun 2012 08:54:12 +0200 Subject: specification for null handling in String, StringBuilder, etc. In-Reply-To: <4FD6D660.7010704@oracle.com> References: <4FD66A27.6050501@oracle.com> <4FD6D660.7010704@oracle.com> Message-ID: <4FD6E794.9090404@univ-mlv.fr> On 06/12/2012 07:40 AM, David Holmes wrote: > Hi Jim, > > On 12/06/2012 7:59 AM, Jim Gish wrote: >> While triaging outstanding String bugs, I was looking at 4247235, "(spec >> str) StringBuffer.insert(int, char[]) specification is inconsistent" >> >> Although the description is out of date w.r.t. the current code, I did >> find what I would consider weaknesses (maybe even holes) in the specs >> relative to this issue. >> >> It appears that the common practice is to spec checked exceptions but >> not unchecked exceptions (which I understand). For example, in the case >> mentioned the spec indicates that StringIndexOutOfBoundsException is >> thrown if the offset is invalid, and is silent about the consequences of >> the char[] being null. In the latter case, it throws >> NullPointerException, but the str == null is not checked, rather it >> simply tries to access str.length and fails if str is null. >> >> My personal feeling is that pre-conditions should be explicitly checked >> for and be spec'd. > > This is very, very common in the core libraries. Rather than document > every single method where a null parameter triggers NPE they are often > covered (directly or indirectly) by blanket statements of the form > "unless otherwise stated ...". > > I'm strongly of the opinion that people should be reading the complete > specification for any type they use, not just individual methods. So I > don't have a problem with not documenting this on each method - there > are likely to be far more significant misunderstandings of behaviour > if you don't read all the docs. But I understand others will see this > from the other side. > > Also note that the handling of unchecked exceptions by JavaDoc > complicates things because overriding implementations need to re-state > that they throw the NPE (or whatever it may be), using @inheritDoc, > even if there is no change from the superclass or interface > specification of the method. > > David And I see no problem to check NPE with a str.length if there is a comment saying something like 'implicit NPE check'. R?mi > ----- > > >> One might argue that the spec is complete, because it says that "The >> overall effect is exactly as if the second argument were converted to a >> string by String.valueOf( char[] ),..." If you look at the class javadoc >> for String there is a statement that "Unless otherwise noted, passing a >> null argument to a constructor or method in this class will cause a || >> |NullPointerException| >> >> to be thrown." However, if the user simply looks at the javadoc for >> String.valueOf( char[] ) nothing is said about null handling there. The >> user would have to have read the class javadoc to catch the reference to >> NullPointerException. Seems like an unreasonably indirect chain to have >> to follow, when all we'd have to say is that the original insert method >> throws NPE if the char[] is null. >> >> I suggest we improve the readability here (and in related places) and >> tell the user straight off the effect of passing null. >> >> Cheers >> Jim Gish >> >> From paul.sandoz at oracle.com Tue Jun 12 07:35:37 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 12 Jun 2012 09:35:37 +0200 Subject: [7u6] RFR (JAXP) : 7144423: StAX EventReader swallows the cause of error In-Reply-To: <4FD67E02.3070904@oracle.com> References: <4FD67E02.3070904@oracle.com> Message-ID: <5B029769-84B5-4865-9706-F9142414F4AF@oracle.com> On Jun 12, 2012, at 1:23 AM, Joe Wang wrote: > Hi, > > This is patch to make sure the cause of the error is properly reported. It has been in jaxp since Feb. > > webrev: http://cr.openjdk.java.net/~joehw/7u6/7143711/webrev/ > > Please review. > Looks OK to me. Paul. From scolebourne at joda.org Tue Jun 12 09:53:46 2012 From: scolebourne at joda.org (Stephen Colebourne) Date: Tue, 12 Jun 2012 10:53:46 +0100 Subject: specification for null handling in String, StringBuilder, etc. In-Reply-To: <4FD6E794.9090404@univ-mlv.fr> References: <4FD66A27.6050501@oracle.com> <4FD6D660.7010704@oracle.com> <4FD6E794.9090404@univ-mlv.fr> Message-ID: > On 06/12/2012 07:40 AM, David Holmes wrote: >> On 12/06/2012 7:59 AM, Jim Gish wrote: >>> My personal feeling is that pre-conditions should be explicitly checked >>> for and be spec'd. >> >> This is very, very common in the core libraries. Rather than document >> every single method where a null parameter triggers NPE they are often >> covered (directly or indirectly) by blanket statements of the form "unless >> otherwise stated ...". >> >> I'm strongly of the opinion that people should be reading the complete >> specification for any type they use, not just individual methods. So I don't >> have a problem with not documenting this on each method - there are likely >> to be far more significant misunderstandings of behaviour if you don't read >> all the docs. But I understand others will see this from the other side. >> >> Also note that the handling of unchecked exceptions by JavaDoc complicates >> things because overriding implementations need to re-state that they throw >> the NPE (or whatever it may be), using @inheritDoc, even if there is no >> change from the superclass or interface specification of the method. In JSR-310 and my other projects (OpenGamma, Joda-*) I explicitly document null handling in a fairly non-invasive way, eg https://github.com/ThreeTen/threeten/blob/master/src/main/java/javax/time/ZonedDateTime.java#L276 * @param foo the foo thing, not null * @param bar the bar thing, null treated as a default bar * @param baz the baz thing, may be null * @return the foo-bar-baz result, not null */ public static FooBarBaz of(Foo foo, Bar bar, Baz baz) { The rule I use is to add a clause to the end of the @param that defines the null behaviour: - ", not null" - this parameter does not accept null, null will throw NPE or be undefined - ", may be null" - this parameter does accept null - ", null ..." - explain what null does Similar explanations for @return: - ", not null" - this method will never return null - ", may be null" - this method may return null - ", null ..." - explain when null returned, eg. ", null if not found" This approach works well as a common pattern that developers can understand without further reading or learning. It provides much more data on null-handling, and in the location that the developer actually wants it. I would love to see this approach more generally in the JDK (and I suspect you might be able to get JUG hackathons to support adding the text in to core Java classes) Stephen From Lance.Andersen at oracle.com Tue Jun 12 12:48:04 2012 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Tue, 12 Jun 2012 08:48:04 -0400 Subject: [7u6] RFR (JAXP) : 7144423: StAX EventReader swallows the cause of error In-Reply-To: <4FD67E02.3070904@oracle.com> References: <4FD67E02.3070904@oracle.com> Message-ID: looks fine best lance On Jun 11, 2012, at 7:23 PM, Joe Wang wrote: > Hi, > > This is patch to make sure the cause of the error is properly reported. It has been in jaxp since Feb. > > webrev: http://cr.openjdk.java.net/~joehw/7u6/7143711/webrev/ > > Please review. > > Thanks, > Joe 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 From Alan.Bateman at oracle.com Tue Jun 12 13:04:41 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 12 Jun 2012 14:04:41 +0100 Subject: specification for null handling in String, StringBuilder, etc. In-Reply-To: <4FD6D660.7010704@oracle.com> References: <4FD66A27.6050501@oracle.com> <4FD6D660.7010704@oracle.com> Message-ID: <4FD73E69.6050703@oracle.com> On 12/06/2012 06:40, David Holmes wrote: > > This is very, very common in the core libraries. Rather than document > every single method where a null parameter triggers NPE they are often > covered (directly or indirectly) by blanket statements of the form > "unless otherwise stated ...". Right, @throws NullPointerException can be considered clutter so it's common to see a blanket statement in the class or package description. In the case of String it already has: *

Unless otherwise noted, passing a null argument to a constructor * or method in this class will cause a {@link NullPointerException} to be * thrown. This was added via 4703640 a long time ago. Clearly a blanket statement like this doesn't make sense in all cases as there will be APIs that define many methods that allow null. -Alan From schlosna at gmail.com Tue Jun 12 14:56:27 2012 From: schlosna at gmail.com (David Schlosnagle) Date: Tue, 12 Jun 2012 10:56:27 -0400 Subject: specification for null handling in String, StringBuilder, etc. In-Reply-To: <4FD73E69.6050703@oracle.com> References: <4FD66A27.6050501@oracle.com> <4FD6D660.7010704@oracle.com> <4FD73E69.6050703@oracle.com> Message-ID: On Tue, Jun 12, 2012 at 9:04 AM, Alan Bateman wrote: > On 12/06/2012 06:40, David Holmes wrote: >> >> >> This is very, very common in the core libraries. Rather than document >> every single method where a null parameter triggers NPE they are often >> covered (directly or indirectly) by blanket statements of the form "unless >> otherwise stated ...". > > Right, @throws NullPointerException can be considered clutter so it's common > to see a blanket statement in the class or package description. In the case > of String it already has: > > ?*

Unless otherwise noted, passing a null argument to a > constructor > ?* or method in this class will cause a {@link NullPointerException} to be > ?* thrown. > > This was added via 4703640 a long time ago. > > Clearly a blanket statement like this doesn't make sense in all cases as > there will be APIs that define many methods that allow null. > > -Alan Sounds like a job for JSR-305 annotations if/when those are ever approved. Thanks, Dave From jim.gish at oracle.com Tue Jun 12 15:31:42 2012 From: jim.gish at oracle.com (Jim Gish) Date: Tue, 12 Jun 2012 11:31:42 -0400 Subject: specification for null handling in String, StringBuilder, etc. In-Reply-To: <4FD6D660.7010704@oracle.com> References: <4FD66A27.6050501@oracle.com> <4FD6D660.7010704@oracle.com> Message-ID: <4FD760DE.4070509@oracle.com> On 06/12/2012 01:40 AM, David Holmes wrote: > Hi Jim, > > On 12/06/2012 7:59 AM, Jim Gish wrote: >> While triaging outstanding String bugs, I was looking at 4247235, "(spec >> str) StringBuffer.insert(int, char[]) specification is inconsistent" >> >> Although the description is out of date w.r.t. the current code, I did >> find what I would consider weaknesses (maybe even holes) in the specs >> relative to this issue. >> >> It appears that the common practice is to spec checked exceptions but >> not unchecked exceptions (which I understand). For example, in the case >> mentioned the spec indicates that StringIndexOutOfBoundsException is >> thrown if the offset is invalid, and is silent about the consequences of >> the char[] being null. In the latter case, it throws >> NullPointerException, but the str == null is not checked, rather it >> simply tries to access str.length and fails if str is null. >> >> My personal feeling is that pre-conditions should be explicitly checked >> for and be spec'd. > > This is very, very common in the core libraries. Rather than document > every single method where a null parameter triggers NPE they are often > covered (directly or indirectly) by blanket statements of the form > "unless otherwise stated ...". For String -- that's fine in that it is covered, but for StringBuilder and StringBuffer, it's not. In fact, the constructors indicate an NPE will be thrown for null args, as do some of the methods (e.g. getchars, indexOf,..l). However, the insert method for char[] are silent. I don't like the inconsistency. Furthermore, I don't think the user should have to go read the blanket statement for String (or some other /different /class), when all we have to say is that either "str - a non-null character array" or "Throws NPE - if the str is null" (as was suggested by Stephen). I recommend we go with documenting the parameters are required to be non-null -- more of a complete contract specification -- for now and transition to @NotNull if/when JSR 305 is approved. Jim > > I'm strongly of the opinion that people should be reading the complete > specification for any type they use, not just individual methods. So I > don't have a problem with not documenting this on each method - there > are likely to be far more significant misunderstandings of behaviour > if you don't read all the docs. But I understand others will see this > from the other side. > > Also note that the handling of unchecked exceptions by JavaDoc > complicates things because overriding implementations need to re-state > that they throw the NPE (or whatever it may be), using @inheritDoc, > even if there is no change from the superclass or interface > specification of the method. > > David > ----- > > >> One might argue that the spec is complete, because it says that "The >> overall effect is exactly as if the second argument were converted to a >> string by String.valueOf( char[] ),..." If you look at the class javadoc >> for String there is a statement that "Unless otherwise noted, passing a >> null argument to a constructor or method in this class will cause a || >> |NullPointerException| >> >> to be thrown." However, if the user simply looks at the javadoc for >> String.valueOf( char[] ) nothing is said about null handling there. The >> user would have to have read the class javadoc to catch the reference to >> NullPointerException. Seems like an unreasonably indirect chain to have >> to follow, when all we'd have to say is that the original insert method >> throws NPE if the char[] is null. >> >> I suggest we improve the readability here (and in related places) and >> tell the user straight off the effect of passing null. >> >> Cheers >> Jim Gish >> >> From joe.darcy at oracle.com Tue Jun 12 15:33:38 2012 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 12 Jun 2012 08:33:38 -0700 Subject: specification for null handling in String, StringBuilder, etc. In-Reply-To: <4FD73E69.6050703@oracle.com> References: <4FD66A27.6050501@oracle.com> <4FD6D660.7010704@oracle.com> <4FD73E69.6050703@oracle.com> Message-ID: <4FD76152.4050501@oracle.com> On 6/12/2012 6:04 AM, Alan Bateman wrote: > On 12/06/2012 06:40, David Holmes wrote: >> >> This is very, very common in the core libraries. Rather than document >> every single method where a null parameter triggers NPE they are >> often covered (directly or indirectly) by blanket statements of the >> form "unless otherwise stated ...". > Right, @throws NullPointerException can be considered clutter so it's > common to see a blanket statement in the class or package description. > In the case of String it already has: > > *

Unless otherwise noted, passing a null argument to a > constructor > * or method in this class will cause a {@link NullPointerException} > to be > * thrown. > > This was added via 4703640 a long time ago. > > Clearly a blanket statement like this doesn't make sense in all cases > as there will be APIs that define many methods that allow null. > > -Alan Yes, in most cases lots of explicit "@throws NullPointerException if foo is null" is noise and should be avoided as a documentation pattern. No one should be that surprised if a method nulls a NPE after having a null passed to it! My preferred long-term solution here would be to use annotations to documentation the null-handling behavior, including class-level defaults, which would then allow tools to check null-handling of callers. -Joe From huizhe.wang at oracle.com Tue Jun 12 15:58:19 2012 From: huizhe.wang at oracle.com (Joe Wang) Date: Tue, 12 Jun 2012 08:58:19 -0700 Subject: [7u6] RFR (JAXP) : 7144423: StAX EventReader swallows the cause of error In-Reply-To: References: <4FD67E02.3070904@oracle.com> Message-ID: <4FD7671B.6050405@oracle.com> Thanks Lance, Paul! Joe On 6/12/2012 5:48 AM, Lance Andersen - Oracle wrote: > looks fine > > best > lance > On Jun 11, 2012, at 7:23 PM, Joe Wang wrote: > >> Hi, >> >> This is patch to make sure the cause of the error is properly >> reported. It has been in jaxp since Feb. >> >> webrev: http://cr.openjdk.java.net/~joehw/7u6/7143711/webrev/ >> >> >> Please review. >> >> Thanks, >> Joe > > > 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 > From huizhe.wang at oracle.com Tue Jun 12 17:22:25 2012 From: huizhe.wang at oracle.com (huizhe.wang at oracle.com) Date: Tue, 12 Jun 2012 17:22:25 +0000 Subject: hg: jdk8/tl/jaxp: 7144423: StAX EventReader swallows the cause of error Message-ID: <20120612172232.1AE994789F@hg.openjdk.java.net> Changeset: 0c7f86d9ff8b Author: joehw Date: 2012-06-12 10:23 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/0c7f86d9ff8b 7144423: StAX EventReader swallows the cause of error Summary: make sure the cause of the error is properly reported Reviewed-by: lancea, psandoz ! src/com/sun/xml/internal/stream/XMLEventReaderImpl.java From jim.gish at oracle.com Tue Jun 12 19:41:21 2012 From: jim.gish at oracle.com (Jim Gish) Date: Tue, 12 Jun 2012 15:41:21 -0400 Subject: hashing and Bug 6932858 Message-ID: <4FD79B61.8050408@oracle.com> I'm triaging all outstanding String bugs/RFEs. In light of Mike's recent changes to hashing, I'm seeking opinions on what should be done with bug # 6932858 -- "(str) Tune hashCode() of String". Although we can't change the specification for String.hashCode(), we would certainly be willing to consider optimizations. We would like to close 6932858 as WONTFIX because it includes deviations from the spec but don't want to lose any optimizations." Thanks, Jim From Lance.Andersen at oracle.com Tue Jun 12 20:20:29 2012 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Tue, 12 Jun 2012 16:20:29 -0400 Subject: Fwd: Review request for 7145913 CachedRowSetSwriter.insertNewRow() throws SQLException References: <8C9D0585-5619-44CC-8770-83AD51505801@oracle.com> Message-ID: Still looking to push this change back but need a reviewer... All JCK, TCK, SQE and unit tests pass thank you in advance Best Lance Begin forwarded message: > From: Lance Andersen - Oracle > Date: June 5, 2012 10:15:36 AM EDT > To: core-libs-dev core-libs-dev > Subject: Fwd: Review request for 7145913 CachedRowSetSwriter.insertNewRow() throws SQLException > > Still looking for reviewer > > Best > Lance > > Begin forwarded message: > >> From: Lance Andersen - Oracle >> Date: May 31, 2012 6:16:16 PM EDT >> Cc: core-libs-dev core-libs-dev >> Subject: Re: Review request for 7145913 CachedRowSetSwriter.insertNewRow() throws SQLException >> >> Here is the revision using the try with resources as David suggested >> >> http://cr.openjdk.java.net/~lancea/7145913/webrev.01/ >> >> Best >> Lance >> On May 31, 2012, at 3:10 PM, David Schlosnagle wrote: > 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 From Lance.Andersen at oracle.com Tue Jun 12 20:21:45 2012 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Tue, 12 Jun 2012 16:21:45 -0400 Subject: Fwd: Review request CR 7171918 XmlReaderContentHandler.endElement does not handle a Delete Tag properly References: <8967800E-31D0-41C2-A320-9EA35685E0EE@oracle.com> Message-ID: Still looking for a reviewer on this. All SQE, unit tests, JCK and TCK tests pass. Best Lance Begin forwarded message: > From: Lance Andersen - Oracle > Date: May 25, 2012 3:56:41 PM EDT > To: core-libs-dev core-libs-dev > Subject: Review request CR 7171918 XmlReaderContentHandler.endElement does not handle a Delete Tag properly > > Attached is the fix for 7171918. If a WebRowSet is written to disk that contains a row marked for deletion and then read back into a WebRowSet, it was not marked again as a deleted row. > > Here is the fix to endElement() to address this. > > hg diff XmlReaderContentHandler.java > diff -r 4580652d9828 src/share/classes/com/sun/rowset/internal/XmlReaderContentHandler.java > --- a/src/share/classes/com/sun/rowset/internal/XmlReaderContentHandler.java Fri May 04 16:00:47 2012 -0400 > +++ b/src/share/classes/com/sun/rowset/internal/XmlReaderContentHandler.java Fri May 25 15:52:21 2012 -0400 > @@ -764,6 +764,7 @@ > rs.next(); > rs.setOriginalRow(); > applyUpdates(); > + rs.deleteRow(); > } catch (SQLException ex) { > throw new SAXException(MessageFormat.format(resBundle.handleGetObject("xmlrch.errdel").toString() , ex.getMessage())); > > > Best, > Lance > > > 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 > 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 From huizhe.wang at oracle.com Tue Jun 12 21:11:07 2012 From: huizhe.wang at oracle.com (Joe Wang) Date: Tue, 12 Jun 2012 14:11:07 -0700 Subject: Fwd: Review request CR 7171918 XmlReaderContentHandler.endElement does not handle a Delete Tag properly In-Reply-To: References: <8967800E-31D0-41C2-A320-9EA35685E0EE@oracle.com> Message-ID: <4FD7B06B.5040705@oracle.com> Looks good to me, Lance. Best, Joe On 6/12/2012 1:21 PM, Lance Andersen - Oracle wrote: > Still looking for a reviewer on this. > > All SQE, unit tests, JCK and TCK tests pass. > > > Best > Lance > > Begin forwarded message: > >> From: Lance Andersen - Oracle >> Date: May 25, 2012 3:56:41 PM EDT >> To: core-libs-dev core-libs-dev >> Subject: Review request CR 7171918 XmlReaderContentHandler.endElement does not handle a Delete Tag properly >> >> Attached is the fix for 7171918. If a WebRowSet is written to disk that contains a row marked for deletion and then read back into a WebRowSet, it was not marked again as a deleted row. >> >> Here is the fix to endElement() to address this. >> >> hg diff XmlReaderContentHandler.java >> diff -r 4580652d9828 src/share/classes/com/sun/rowset/internal/XmlReaderContentHandler.java >> --- a/src/share/classes/com/sun/rowset/internal/XmlReaderContentHandler.java Fri May 04 16:00:47 2012 -0400 >> +++ b/src/share/classes/com/sun/rowset/internal/XmlReaderContentHandler.java Fri May 25 15:52:21 2012 -0400 >> @@ -764,6 +764,7 @@ >> rs.next(); >> rs.setOriginalRow(); >> applyUpdates(); >> + rs.deleteRow(); >> } catch (SQLException ex) { >> throw new SAXException(MessageFormat.format(resBundle.handleGetObject("xmlrch.errdel").toString() , ex.getMessage())); >> >> >> Best, >> Lance >> >> >> 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 >> > > 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 > From lance.andersen at oracle.com Tue Jun 12 21:32:31 2012 From: lance.andersen at oracle.com (lance.andersen at oracle.com) Date: Tue, 12 Jun 2012 21:32:31 +0000 Subject: hg: jdk8/tl/jdk: 7171918: XmlReaderContentHandler.endElement does not handle a Delete Tag properly Message-ID: <20120612213302.411C3478AA@hg.openjdk.java.net> Changeset: 6b6a73e8c036 Author: lancea Date: 2012-06-12 17:32 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6b6a73e8c036 7171918: XmlReaderContentHandler.endElement does not handle a Delete Tag properly Reviewed-by: joehw ! src/share/classes/com/sun/rowset/internal/XmlReaderContentHandler.java From dbelfer at gmail.com Wed Jun 13 05:11:23 2012 From: dbelfer at gmail.com (Diego Belfer) Date: Wed, 13 Jun 2012 02:11:23 -0300 Subject: PATCH [6901992] : Possible InvalidJarIndexException due to bug in sun.misc.JarIndex.merge() In-Reply-To: References: Message-ID: Hi, I have finally reproduced the InvalidJarIndexException bug as reported in the ticket. I mentioned in a previous email, that the only way I'd found for getting the error was to use an invalid index file (INDEX.LIST), which did not have any sense. That's because I was using jars containing "directory entries" (I was unaware that jar files may not include them) After reviewing the URLClasspath$JarLoader class and the validIndex method, I notice it is possible to get the exception for a Jar file which does not include directory entries. In order to trigger the issue, the Jar must be referenced by an intermediary INDEX.LIST and the intermediary Jar index should have been merged to its parent index. Although, jar tool includes directory entries in the generated jar files, Eclipse default option for exporting jars does not include them (AFAIK), so this might be quite common. I have created a new PATCH which includes an additional test case which uses the URLClassLoader to trigger the InvalidIndexException. The patch is attached, please consider it for review. Best, Diego Belfer [muralx] On Mon, Jun 11, 2012 at 4:47 PM, Diego Belfer wrote: > Hi, > > Here is a patch that fixes the merge method of the JarIndex. This bug was > reported as the cause of the bug 6901992. Although, I was not able to > reproduce the BUG itself (InvalidJarIndexException), I did verified that > the method had a bug, and resources/classes where not found in a jarIndex > with merged contents. > > If you think it is possible to commit this fix without actually > reproducing the original bug report, please consider this patch for review. > > Thanks, > Diego Belfer [muralx] > > -------------- next part -------------- # HG changeset patch # User muralx # Date 1339560937 10800 # Node ID 26467341e7232b981f96ecdf80d3b6cd649e61f1 # Parent fc575c78f5d314fd8ccbdc86c8b2d7631d736960 [PATCH] 6901992 - Possible InvalidJarIndexException due to bug in sun.misc.JarIndex.merge() diff --git a/src/share/classes/sun/misc/JarIndex.java b/src/share/classes/sun/misc/JarIndex.java --- a/src/share/classes/sun/misc/JarIndex.java +++ b/src/share/classes/sun/misc/JarIndex.java @@ -201,23 +201,20 @@ packageName = fileName; } - // add the mapping to indexMap - addToList(packageName, jarName, indexMap); - - // add the mapping to jarMap - addToList(jarName, packageName, jarMap); + addMapping(packageName, jarName); } /** * Same as add(String,String) except that it doesn't strip off from the - * last index of '/'. It just adds the filename. + * last index of '/'. It just adds the jarItem (filename or package) + * as it is received. */ - private void addExplicit(String fileName, String jarName) { + private void addMapping(String jarItem, String jarName) { // add the mapping to indexMap - addToList(fileName, jarName, indexMap); + addToList(jarItem, jarName, indexMap); // add the mapping to jarMap - addToList(jarName, fileName, jarMap); + addToList(jarName, jarItem, jarMap); } /** @@ -248,18 +245,14 @@ fileName.equals(JarFile.MANIFEST_NAME)) continue; - if (!metaInfFilenames) { + if (!metaInfFilenames || !fileName.startsWith("META-INF/")) { add(fileName, currentJar); - } else { - if (!fileName.startsWith("META-INF/")) { - add(fileName, currentJar); - } else if (!entry.isDirectory()) { + } else if (!entry.isDirectory()) { // Add files under META-INF explicitly so that certain // services, like ServiceLoader, etc, can be located // with greater accuracy. Directories can be skipped // since each file will be added explicitly. - addExplicit(fileName, currentJar); - } + addMapping(fileName, currentJar); } } @@ -324,8 +317,7 @@ jars.add(currentJar); } else { String name = line; - addToList(name, currentJar, indexMap); - addToList(currentJar, name, jarMap); + addMapping(name, currentJar); } } @@ -354,7 +346,7 @@ if (path != null) { jarName = path.concat(jarName); } - toIndex.add(packageName, jarName); + toIndex.addMapping(packageName, jarName); } } } diff --git a/test/sun/misc/JarIndex/JarIndexMergeForClassLoaderTest.java b/test/sun/misc/JarIndex/JarIndexMergeForClassLoaderTest.java new file mode 100644 --- /dev/null +++ b/test/sun/misc/JarIndex/JarIndexMergeForClassLoaderTest.java @@ -0,0 +1,61 @@ +/* + * Copyright (c) 2012, Oracle and/or its affiliates. All rights reserved. + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. + * + * This code is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License version 2 only, as + * published by the Free Software Foundation. + * + * This code is distributed in the hope that it will be useful, but WITHOUT + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License + * version 2 for more details (a copy is included in the LICENSE file that + * accompanied this code). + * + * You should have received a copy of the GNU General Public License version + * 2 along with this work; if not, write to the Free Software Foundation, + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. + * + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA + * or visit www.oracle.com if you need additional information or have any + * questions. + */ + +/* + * @test + * @bug 6901992 + * @summary Possible InvalidJarIndexException due to bug in sun.misc.JarIndex.merge() + * @author Diego Belfer + */ + +import java.io.File; +import java.net.URL; +import java.net.URLClassLoader; + +public class JarIndexMergeForClassLoaderTest { + static final String slash = File.separator; + static final String testSrc = System.getProperty("test.src"); + static final String testSrcDir = testSrc != null ? testSrc : "."; + + public static void main(String[] args) throws Exception { + String file = testSrcDir + slash + "jarIndexMerge" + slash + + "level1.jar"; + URL url = new File(file).toURI().toURL(); + + URLClassLoader classLoader = new URLClassLoader(new URL[] { url }); + + // We preload level2.jar using a package available in it + if (classLoader.getResource("sub/test/pck2/x.x") != null) { + throw new RuntimeException("Null expected for getResource"); + } + // Now we have no-dir-entries index in the classloader, we check if it + // works as expected + if (classLoader.getResource("com/resource.file") != null) { + throw new RuntimeException("Null expected for getResource"); + } + if (classLoader.getResource("com/test/resource.file") == null) { + throw new RuntimeException("Expected resource URL"); + } + } +} + diff --git a/test/sun/misc/JarIndex/JarIndexMergeTest.java b/test/sun/misc/JarIndex/JarIndexMergeTest.java new file mode 100644 --- /dev/null +++ b/test/sun/misc/JarIndex/JarIndexMergeTest.java @@ -0,0 +1,74 @@ +/* + * Copyright (c) 2012, Oracle and/or its affiliates. All rights reserved. + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. + * + * This code is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License version 2 only, as + * published by the Free Software Foundation. + * + * This code is distributed in the hope that it will be useful, but WITHOUT + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License + * version 2 for more details (a copy is included in the LICENSE file that + * accompanied this code). + * + * You should have received a copy of the GNU General Public License version + * 2 along with this work; if not, write to the Free Software Foundation, + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. + * + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA + * or visit www.oracle.com if you need additional information or have any + * questions. + */ + +/* + * @test + * @bug 6901992 + * @summary Possible InvalidJarIndexException due to bug in sun.misc.JarIndex.merge() + * @author Diego Belfer + */ + +import java.io.File; +import java.util.LinkedList; + +import sun.misc.JarIndex; + + at SuppressWarnings("restriction") +public class JarIndexMergeTest { + static final String slash = File.separator; + static final String testSrc = System.getProperty("test.src"); + static final String testSrcDir = testSrc != null ? testSrc : "."; + + public static void main(String[] args) throws Exception { + + JarIndex jarIndexMissing = new JarIndex( + new String[] { testSrcDir + slash + "jarIndexMerge" + slash + "missing.jar" }); + LinkedList jarLists = jarIndexMissing + .get("fail/subdir/resourceToSearch.properties"); + if (jarLists != null && jarLists.size() > 0) { + throw new RuntimeException( + "Unexpected result: missing.jar should not contain the required file"); + } + + String containerJarName = testSrcDir + slash +"jarIndexMerge" + slash + "container.jar"; + JarIndex jarIndexContainer = new JarIndex( + new String[] { containerJarName }); + jarLists = jarIndexContainer + .get("fail/subdir/resourceToSearch.properties"); + if (jarLists == null || jarLists.size() == 0) { + throw new RuntimeException( + "Unexpected result: container.jar should contain the required file"); + } + + // We merge the index into the jarIndexMissing + jarIndexContainer.merge(jarIndexMissing, null); + + jarLists = jarIndexMissing + .get("fail/subdir/resourceToSearch.properties"); + if (jarLists == null || jarLists.size() == 0 || !containerJarName.equals(jarLists.get(0))) { + throw new RuntimeException( + "Unexpected result: the merged index should contain the required file"); + } + } + +} diff --git a/test/sun/misc/JarIndex/jarIndexMerge/container.jar b/test/sun/misc/JarIndex/jarIndexMerge/container.jar new file mode 100644 index 0000000000000000000000000000000000000000..303f44f36498380ed59aa734530da52ae7bf2c0a GIT binary patch literal 362 zc$^FHW at h1H00G79Qw|JBfE9?-5;Jr31K>&w(UkDOloXdHrDPW2QK^omvM9AUzqBYh zH6%YcHL)l;L$9DHzaX`!Br~-*z?+eYivhQrPyy712rby$hycnMF2=1>9Yv=vDL!Cj P18HFf!b3oM64(F$sMkDM diff --git a/test/sun/misc/JarIndex/jarIndexMerge/level1.jar b/test/sun/misc/JarIndex/jarIndexMerge/level1.jar new file mode 100644 index 0000000000000000000000000000000000000000..5fd50b111399e525a11b4ed48d643509156b27e0 GIT binary patch literal 627 zc$^FHW at Zs#-~htq3}+n}kbp1)3xls~h at -BjpPRm?pNngRo{wj6$iGtz44=JpKArLQ zTzi4nTUYDcne&^246YbIcy!8B*ZZvDmD652kF at lBnG*j_y7EZK!g;@f+t#O?Lb06%h>J^;^bsmHpsC=5swhb|kVoBj`Yea53QaGXm7XLja)z tTNog~0 at M&eXu}pJ2yh%r2;tT%g`)Q}fe>S51F2#KLL){725m+V4*(#*bsGQx diff --git a/test/sun/misc/JarIndex/jarIndexMerge/level2.jar b/test/sun/misc/JarIndex/jarIndexMerge/level2.jar new file mode 100644 index 0000000000000000000000000000000000000000..563b5d1230b8dfea1e2d4fe9706a7d7471083b63 GIT binary patch literal 645 zc$^FHW at Zs#-~hta3}+n}kbp1)3xls~h at -BjpPRm?pNngRo{wj6$iGtz44=JpKArLQ zTzi4nTUYDcne&^246YbIcy!8B*ZZvDrPE$IkF at lBnG*j_y7EZK!g;@fz8O4Z@1~qWaSsa+7ndgK zBUFf{qN?D8swhbTN~ zWPl?uL56TK;Px{DOn`>~LI<`mK!8oCA%fc?J``;?v4jwAy;3N8SsC$%7%LlC6%ZN$ JRoXIwcmSi>e7^ty diff --git a/test/sun/misc/JarIndex/jarIndexMerge/missing.jar b/test/sun/misc/JarIndex/jarIndexMerge/missing.jar new file mode 100644 index 0000000000000000000000000000000000000000..2fa7239cda88c54666f1047a4862d56dc26b23ab GIT binary patch literal 316 zc$^FHW at h1H0D<=@ryLlN04op|mnIqN2f&qRr=lw1f+;CUEiS>MP6$O^QEIVXT4qja vfHxx(7Xxm~Q32E`2rbwgg8<5CPQ$HF2t}Va4yUrRfn=G1a5a#w2CD at CHj62z diff --git a/test/sun/misc/JarIndex/jarIndexMerge/nodir-entries.jar b/test/sun/misc/JarIndex/jarIndexMerge/nodir-entries.jar new file mode 100644 index 0000000000000000000000000000000000000000..136162d60b08ed176c1d855f8ca97ec5778d7bb7 GIT binary patch literal 327 zc$^FHW at Zs#;Nak3&|*02z<>lq7+4s5T|*poJ^kGDeI5Ng-CTo1^nBg^onm14?0e?4 zkGHPgMP6 at Rt#fD2Zw at lJV*KFgqo+&^0p9E!o9da~Ndt|L1mXa=1>(EUpjaRV#L4-& z`X#BwCHh6F#rdU0$*Fp2nK`M References: <475A155E-4B22-4A51-B2DC-ACF034F048D0@oracle.com> <7A0C9C7C-48E4-422A-9A42-1DAF5263C47C@oracle.com> Message-ID: <7E415BCD-E57A-474D-8B35-80EB2EAAF00E@oracle.com> Hi Lance, It looks OK to me, however i don't know much about JDBC. Much cleaner than before. Very minor point, you can shoot me for being pedantic!: from line 894 you can do the following since the return value from pstmt.executeUpdate() is never used: 894 try { 895 // int i; 896 for (int i = 1; i <= icolCount; i++) { 897 Object obj = crs.getObject(i); 898 if (obj != null) { 899 pstmt.setObject(i, obj); 900 } else { 901 pstmt.setNull(i,crs.getMetaData().getColumnType(i)); 902 } 903 } 904 905 pstmt.executeUpdate(); 906 return false; 907 908 } catch (SQLException ex) { Paul. On Jun 1, 2012, at 12:16 AM, Lance Andersen - Oracle wrote: > Here is the revision using the try with resources as David suggested > > http://cr.openjdk.java.net/~lancea/7145913/webrev.01/ > > Best > Lance > On May 31, 2012, at 3:10 PM, David Schlosnagle wrote: > >> On Thu, May 31, 2012 at 1:50 PM, Lance Andersen - Oracle >> wrote: >>> Hi, >>> >>> Looking for a reviewer for 7145913. This addresses an issue with where a SQLException could be thrown when writing a row back with an auto-incremented column on some databases. >>> >>> Webrev is http://cr.openjdk.java.net/~lancea/7145913/webrev.00/. RowSet TCK, sqe tests and unit tests all pass with this fix. >> >> Hi Lance, >> >> I had a few quick comments: >> >> * Do you need the multiple calls to CachedResultSet.getObject for the primary >> key, or would it be worthwhile to store the result in a local variable? >> >> * This seems to be pre-existing before your changes, but the PreparedStatement >> pstmtSel and ResultSet rs, rs2 used within the insertNewRow method are never >> closed, which could lead to resource leaks. >> >> * Minor nit, the indentation in this file seems off, especially for the method >> JavaDoc. >> >> I've included a minor cleanup below of the insertNewRow method using >> try-with-resources. >> >> Thanks, >> Dave >> >> >> /** >> * Inserts a row that has been inserted into the given >> * CachedRowSet object into the data source from which >> * the rowset is derived, returning false if the insertion >> * was successful. >> * >> * @param crs the CachedRowSet object that has had a >> row inserted >> * and to whose underlying data source the row will be inserted >> * @param pstmt the PreparedStatement object that will be used >> * to execute the insertion >> * @return false to indicate that the insertion was successful; >> * true otherwise >> * @throws SQLException if a database access error occurs >> */ >> private boolean insertNewRow(CachedRowSet crs, >> PreparedStatement pstmt, CachedRowSetImpl crsRes) throws SQLException { >> >> boolean returnVal = false; >> >> try (PreparedStatement pstmtSel = con.prepareStatement(selectCmd, >> ResultSet.TYPE_SCROLL_SENSITIVE, >> ResultSet.CONCUR_READ_ONLY); >> ResultSet rs = pstmtSel.executeQuery(); >> ResultSet rs2 = con.getMetaData().getPrimaryKeys(null, null, >> crs.getTableName()) >> ) { >> >> ResultSetMetaData rsmd = crs.getMetaData(); >> int icolCount = rsmd.getColumnCount(); >> String[] primaryKeys = new String[icolCount]; >> int k = 0; >> while (rs2.next()) { >> primaryKeys[k] = rs2.getString("COLUMN_NAME"); >> k++; >> } >> >> if (rs.next()) { >> for (String pkName : primaryKeys) { >> if (!isPKNameValid(pkName, rsmd)) { >> >> /* We came here as one of the the primary keys >> * of the table is not present in the cached >> * rowset object, it should be an autoincrement column >> * and not included while creating CachedRowSet >> * Object, proceed to check for other primary keys >> */ >> continue; >> } >> >> Object crsPK = crs.getObject(pkName); >> if (crsPK == null) { >> /* >> * It is possible that the PK is null on some databases >> * and will be filled in at insert time (MySQL >> for example) >> */ >> break; >> } >> >> String rsPK = rs.getObject(pkName).toString(); >> if (crsPK.toString().equals(rsPK)) { >> returnVal = true; >> this.crsResolve.moveToInsertRow(); >> for (int i = 1; i <= icolCount; i++) { >> String colname = >> (rs.getMetaData()).getColumnName(i); >> if (colname.equals(pkName)) >> this.crsResolve.updateObject(i,rsPK); >> else >> this.crsResolve.updateNull(i); >> } >> this.crsResolve.insertRow(); >> this.crsResolve.moveToCurrentRow(); >> } >> } >> } >> >> if (returnVal) { >> return returnVal; >> } >> >> try { >> int i; >> for (i = 1; i <= icolCount; i++) { >> Object obj = crs.getObject(i); >> if (obj != null) { >> pstmt.setObject(i, obj); >> } else { >> pstmt.setNull(i,crs.getMetaData().getColumnType(i)); >> } >> } >> >> i = pstmt.executeUpdate(); >> return false; >> >> } catch (SQLException ex) { >> /* >> * Cursor will come here if executeUpdate fails. >> * There can be many reasons why the insertion failed, >> * one can be violation of primary key. >> * Hence we cannot exactly identify why the insertion failed >> * Present the current row as a null row to the user. >> **/ >> this.crsResolve.moveToInsertRow(); >> >> for (int i = 1; i <= icolCount; i++) { >> this.crsResolve.updateNull(i); >> } >> >> this.crsResolve.insertRow(); >> this.crsResolve.moveToCurrentRow(); >> >> return true; >> } >> } >> } > > > 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 > From paul.sandoz at oracle.com Wed Jun 13 07:54:04 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 13 Jun 2012 09:54:04 +0200 Subject: Review request CR 7171918 XmlReaderContentHandler.endElement does not handle a Delete Tag properly In-Reply-To: <4FD7B06B.5040705@oracle.com> References: <8967800E-31D0-41C2-A320-9EA35685E0EE@oracle.com> <4FD7B06B.5040705@oracle.com> Message-ID: On Jun 12, 2012, at 11:11 PM, Joe Wang wrote: > Looks good to me, Lance. > +1 Paul. From kelly.ohair at oracle.com Wed Jun 13 10:50:43 2012 From: kelly.ohair at oracle.com (kelly.ohair at oracle.com) Date: Wed, 13 Jun 2012 10:50:43 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20120613105123.957E3478CF@hg.openjdk.java.net> Changeset: 9fd127ff51d5 Author: ohair Date: 2012-06-12 13:54 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9fd127ff51d5 7176138: Fixes for missing close() calls and possible null pointer reference instead of fatal error Reviewed-by: dcubed ! src/share/demo/jvmti/hprof/hprof_table.c ! src/solaris/demo/jvmti/hprof/hprof_md.c Changeset: 7b93a2a9cd15 Author: ohair Date: 2012-06-12 15:16 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7b93a2a9cd15 Merge From Lance.Andersen at oracle.com Wed Jun 13 11:04:22 2012 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Wed, 13 Jun 2012 07:04:22 -0400 Subject: Review request for 7145913 CachedRowSetSwriter.insertNewRow() throws SQLException In-Reply-To: <7E415BCD-E57A-474D-8B35-80EB2EAAF00E@oracle.com> References: <475A155E-4B22-4A51-B2DC-ACF034F048D0@oracle.com> <7A0C9C7C-48E4-422A-9A42-1DAF5263C47C@oracle.com> <7E415BCD-E57A-474D-8B35-80EB2EAAF00E@oracle.com> Message-ID: <3FBCA042-32A8-46D5-8C46-5BFC267F88A3@oracle.com> Hi Paul, Thank you for taking the time to review the code. I made the change you suggested below http://cr.openjdk.java.net/~lancea/7145913/webrev.02 Let me know if you are good with the change and I will get this puppy put back. Best Lance On Jun 13, 2012, at 3:53 AM, Paul Sandoz wrote: > Hi Lance, > > It looks OK to me, however i don't know much about JDBC. Much cleaner than before. > > Very minor point, you can shoot me for being pedantic!: from line 894 you can do the following since the return value from pstmt.executeUpdate() is never used: > > 894 try { > 895 // int i; > 896 for (int i = 1; i <= icolCount; i++) { > 897 Object obj = crs.getObject(i); > 898 if (obj != null) { > 899 pstmt.setObject(i, obj); > 900 } else { > 901 pstmt.setNull(i,crs.getMetaData().getColumnType(i)); > 902 } > 903 } > 904 > 905 pstmt.executeUpdate(); > 906 return false; > 907 > 908 } catch (SQLException ex) { > Paul. > > On Jun 1, 2012, at 12:16 AM, Lance Andersen - Oracle wrote: > >> Here is the revision using the try with resources as David suggested >> >> http://cr.openjdk.java.net/~lancea/7145913/webrev.01/ >> >> Best >> Lance >> On May 31, 2012, at 3:10 PM, David Schlosnagle wrote: >> >>> On Thu, May 31, 2012 at 1:50 PM, Lance Andersen - Oracle >>> wrote: >>>> Hi, >>>> >>>> Looking for a reviewer for 7145913. This addresses an issue with where a SQLException could be thrown when writing a row back with an auto-incremented column on some databases. >>>> >>>> Webrev is http://cr.openjdk.java.net/~lancea/7145913/webrev.00/. RowSet TCK, sqe tests and unit tests all pass with this fix. >>> >>> Hi Lance, >>> >>> I had a few quick comments: >>> >>> * Do you need the multiple calls to CachedResultSet.getObject for the primary >>> key, or would it be worthwhile to store the result in a local variable? >>> >>> * This seems to be pre-existing before your changes, but the PreparedStatement >>> pstmtSel and ResultSet rs, rs2 used within the insertNewRow method are never >>> closed, which could lead to resource leaks. >>> >>> * Minor nit, the indentation in this file seems off, especially for the method >>> JavaDoc. >>> >>> I've included a minor cleanup below of the insertNewRow method using >>> try-with-resources. >>> >>> Thanks, >>> Dave >>> >>> >>> /** >>> * Inserts a row that has been inserted into the given >>> * CachedRowSet object into the data source from which >>> * the rowset is derived, returning false if the insertion >>> * was successful. >>> * >>> * @param crs the CachedRowSet object that has had a >>> row inserted >>> * and to whose underlying data source the row will be inserted >>> * @param pstmt the PreparedStatement object that will be used >>> * to execute the insertion >>> * @return false to indicate that the insertion was successful; >>> * true otherwise >>> * @throws SQLException if a database access error occurs >>> */ >>> private boolean insertNewRow(CachedRowSet crs, >>> PreparedStatement pstmt, CachedRowSetImpl crsRes) throws SQLException { >>> >>> boolean returnVal = false; >>> >>> try (PreparedStatement pstmtSel = con.prepareStatement(selectCmd, >>> ResultSet.TYPE_SCROLL_SENSITIVE, >>> ResultSet.CONCUR_READ_ONLY); >>> ResultSet rs = pstmtSel.executeQuery(); >>> ResultSet rs2 = con.getMetaData().getPrimaryKeys(null, null, >>> crs.getTableName()) >>> ) { >>> >>> ResultSetMetaData rsmd = crs.getMetaData(); >>> int icolCount = rsmd.getColumnCount(); >>> String[] primaryKeys = new String[icolCount]; >>> int k = 0; >>> while (rs2.next()) { >>> primaryKeys[k] = rs2.getString("COLUMN_NAME"); >>> k++; >>> } >>> >>> if (rs.next()) { >>> for (String pkName : primaryKeys) { >>> if (!isPKNameValid(pkName, rsmd)) { >>> >>> /* We came here as one of the the primary keys >>> * of the table is not present in the cached >>> * rowset object, it should be an autoincrement column >>> * and not included while creating CachedRowSet >>> * Object, proceed to check for other primary keys >>> */ >>> continue; >>> } >>> >>> Object crsPK = crs.getObject(pkName); >>> if (crsPK == null) { >>> /* >>> * It is possible that the PK is null on some databases >>> * and will be filled in at insert time (MySQL >>> for example) >>> */ >>> break; >>> } >>> >>> String rsPK = rs.getObject(pkName).toString(); >>> if (crsPK.toString().equals(rsPK)) { >>> returnVal = true; >>> this.crsResolve.moveToInsertRow(); >>> for (int i = 1; i <= icolCount; i++) { >>> String colname = >>> (rs.getMetaData()).getColumnName(i); >>> if (colname.equals(pkName)) >>> this.crsResolve.updateObject(i,rsPK); >>> else >>> this.crsResolve.updateNull(i); >>> } >>> this.crsResolve.insertRow(); >>> this.crsResolve.moveToCurrentRow(); >>> } >>> } >>> } >>> >>> if (returnVal) { >>> return returnVal; >>> } >>> >>> try { >>> int i; >>> for (i = 1; i <= icolCount; i++) { >>> Object obj = crs.getObject(i); >>> if (obj != null) { >>> pstmt.setObject(i, obj); >>> } else { >>> pstmt.setNull(i,crs.getMetaData().getColumnType(i)); >>> } >>> } >>> >>> i = pstmt.executeUpdate(); >>> return false; >>> >>> } catch (SQLException ex) { >>> /* >>> * Cursor will come here if executeUpdate fails. >>> * There can be many reasons why the insertion failed, >>> * one can be violation of primary key. >>> * Hence we cannot exactly identify why the insertion failed >>> * Present the current row as a null row to the user. >>> **/ >>> this.crsResolve.moveToInsertRow(); >>> >>> for (int i = 1; i <= icolCount; i++) { >>> this.crsResolve.updateNull(i); >>> } >>> >>> this.crsResolve.insertRow(); >>> this.crsResolve.moveToCurrentRow(); >>> >>> return true; >>> } >>> } >>> } >> >> >> 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 >> > 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 From paul.sandoz at oracle.com Wed Jun 13 11:09:47 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 13 Jun 2012 13:09:47 +0200 Subject: Review request for 7145913 CachedRowSetSwriter.insertNewRow() throws SQLException In-Reply-To: <3FBCA042-32A8-46D5-8C46-5BFC267F88A3@oracle.com> References: <475A155E-4B22-4A51-B2DC-ACF034F048D0@oracle.com> <7A0C9C7C-48E4-422A-9A42-1DAF5263C47C@oracle.com> <7E415BCD-E57A-474D-8B35-80EB2EAAF00E@oracle.com> <3FBCA042-32A8-46D5-8C46-5BFC267F88A3@oracle.com> Message-ID: <8D925D56-B3C7-4881-BCB6-B78EB8BEFFC5@oracle.com> On Jun 13, 2012, at 1:04 PM, Lance Andersen - Oracle wrote: > Hi Paul, > > Thank you for taking the time to review the code. > > > I made the change you suggested below > > http://cr.openjdk.java.net/~lancea/7145913/webrev.02 > > Let me know if you are good with the change and I will get this puppy put back. > Looks good! Paul. From weijun.wang at oracle.com Wed Jun 13 11:23:58 2012 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Wed, 13 Jun 2012 11:23:58 +0000 Subject: hg: jdk8/tl/jdk: 7176574: sun/security/krb5/auto/TcpTimeout.java failed with solaris-i586 Message-ID: <20120613112408.CE616478D0@hg.openjdk.java.net> Changeset: 4435f8b20d08 Author: weijun Date: 2012-06-13 19:23 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4435f8b20d08 7176574: sun/security/krb5/auto/TcpTimeout.java failed with solaris-i586 Reviewed-by: chegar ! test/sun/security/krb5/auto/TcpTimeout.java From chris.hegarty at oracle.com Wed Jun 13 15:05:55 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 13 Jun 2012 16:05:55 +0100 Subject: PATCH [6901992] : Possible InvalidJarIndexException due to bug in sun.misc.JarIndex.merge() In-Reply-To: References: Message-ID: <4FD8AC53.7040204@oracle.com> Hi Diego, Thanks for picking up this bug. I think your changes look fine. Mainly cleanup except for add -> addExplicit/addMapping in merge, right? BTW the cleanup makes this more readable. Unfortunately, the tests you created require checking in a binary jar file. This is a real no no for the OpenJDK, we really need to create these jars on the fly. I did similar for test/sun/misc/JarIndex/metaInfFilenames/, but I really wish I generated the source files for these tests rather than checking in so many pointless files. I can look at helping with writing suitable tests for this. > That's because I was using jars containing "directory entries" > (I was unaware that jar files may not include them) Strangely I added the comment "Remove directories from jar files being indexed." to the workaround section of the bug. You seem to be seeing the opposite, right? -Chris. On 13/06/2012 06:11, Diego Belfer wrote: > Hi, > > I have finally reproduced the InvalidJarIndexException bug as reported in > the ticket. I mentioned in a previous email, that the only way I'd found > for getting the error was to use an invalid index file (INDEX.LIST), which > did not have any sense. That's because I was using jars containing > "directory entries" (I was unaware that jar files may not include them) > > After reviewing the URLClasspath$JarLoader class and the validIndex method, > I notice it is possible to get the exception for a Jar file which does not > include directory entries. In order to trigger the issue, the Jar must be > referenced by an intermediary INDEX.LIST and the intermediary Jar index > should have been merged to its parent index. Although, jar tool includes > directory entries in the generated jar files, Eclipse default option for > exporting jars does not include them (AFAIK), so this might be quite common. > > I have created a new PATCH which includes an additional test case which > uses the URLClassLoader to trigger the InvalidIndexException. > > The patch is attached, please consider it for review. > > Best, > Diego Belfer [muralx] > > > > On Mon, Jun 11, 2012 at 4:47 PM, Diego Belfer wrote: > >> Hi, >> >> Here is a patch that fixes the merge method of the JarIndex. This bug was >> reported as the cause of the bug 6901992. Although, I was not able to >> reproduce the BUG itself (InvalidJarIndexException), I did verified that >> the method had a bug, and resources/classes where not found in a jarIndex >> with merged contents. >> >> If you think it is possible to commit this fix without actually >> reproducing the original bug report, please consider this patch for review. >> >> Thanks, >> Diego Belfer [muralx] >> >> From huizhe.wang at oracle.com Wed Jun 13 16:18:10 2012 From: huizhe.wang at oracle.com (Joe Wang) Date: Wed, 13 Jun 2012 09:18:10 -0700 Subject: Review request for 7145913 CachedRowSetSwriter.insertNewRow() throws SQLException In-Reply-To: <8D925D56-B3C7-4881-BCB6-B78EB8BEFFC5@oracle.com> References: <475A155E-4B22-4A51-B2DC-ACF034F048D0@oracle.com> <7A0C9C7C-48E4-422A-9A42-1DAF5263C47C@oracle.com> <7E415BCD-E57A-474D-8B35-80EB2EAAF00E@oracle.com> <3FBCA042-32A8-46D5-8C46-5BFC267F88A3@oracle.com> <8D925D56-B3C7-4881-BCB6-B78EB8BEFFC5@oracle.com> Message-ID: <4FD8BD42.3020106@oracle.com> Hi Lance, The changes look good to me. Joe On 6/13/2012 4:09 AM, Paul Sandoz wrote: > On Jun 13, 2012, at 1:04 PM, Lance Andersen - Oracle wrote: >> Hi Paul, >> >> Thank you for taking the time to review the code. >> >> >> I made the change you suggested below >> >> http://cr.openjdk.java.net/~lancea/7145913/webrev.02 >> >> Let me know if you are good with the change and I will get this puppy put back. >> > Looks good! > > Paul. From forax at univ-mlv.fr Wed Jun 13 16:49:48 2012 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Wed, 13 Jun 2012 18:49:48 +0200 Subject: Review request for 7145913 CachedRowSetSwriter.insertNewRow() throws SQLException In-Reply-To: <4FD8BD42.3020106@oracle.com> References: <475A155E-4B22-4A51-B2DC-ACF034F048D0@oracle.com> <7A0C9C7C-48E4-422A-9A42-1DAF5263C47C@oracle.com> <7E415BCD-E57A-474D-8B35-80EB2EAAF00E@oracle.com> <3FBCA042-32A8-46D5-8C46-5BFC267F88A3@oracle.com> <8D925D56-B3C7-4881-BCB6-B78EB8BEFFC5@oracle.com> <4FD8BD42.3020106@oracle.com> Message-ID: <4FD8C4AC.3010305@univ-mlv.fr> On 06/13/2012 06:18 PM, Joe Wang wrote: > Hi Lance, > > The changes look good to me. > > Joe Hi Lance, just a minor comment, in isPKNameValid, you don't need the boolean isValid because you can return true instead of using break and return false at the end. cheers, R?mi > > On 6/13/2012 4:09 AM, Paul Sandoz wrote: >> On Jun 13, 2012, at 1:04 PM, Lance Andersen - Oracle wrote: >>> Hi Paul, >>> >>> Thank you for taking the time to review the code. >>> >>> >>> I made the change you suggested below >>> >>> http://cr.openjdk.java.net/~lancea/7145913/webrev.02 >>> >>> Let me know if you are good with the change and I will get this >>> puppy put back. >>> >> Looks good! >> >> Paul. From Lance.Andersen at oracle.com Wed Jun 13 17:01:48 2012 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Wed, 13 Jun 2012 13:01:48 -0400 Subject: Review request for 7145913 CachedRowSetSwriter.insertNewRow() throws SQLException In-Reply-To: <4FD8C4AC.3010305@univ-mlv.fr> References: <475A155E-4B22-4A51-B2DC-ACF034F048D0@oracle.com> <7A0C9C7C-48E4-422A-9A42-1DAF5263C47C@oracle.com> <7E415BCD-E57A-474D-8B35-80EB2EAAF00E@oracle.com> <3FBCA042-32A8-46D5-8C46-5BFC267F88A3@oracle.com> <8D925D56-B3C7-4881-BCB6-B78EB8BEFFC5@oracle.com> <4FD8BD42.3020106@oracle.com> <4FD8C4AC.3010305@univ-mlv.fr> Message-ID: <85D57A5E-833D-46B1-A13E-D278D1DA5A06@oracle.com> Hi Remi, Thank you for the suggestion. Over the years, I have gotten different views on whether to have multiple return points vs just one. Is there a specific style preference that should be used going forward? At this time, I would prefer to not make another change and if the consensus going forward is that multiple return points is OK, I will make the change in my next push of this code. Best Lance On Jun 13, 2012, at 12:49 PM, R?mi Forax wrote: > On 06/13/2012 06:18 PM, Joe Wang wrote: >> Hi Lance, >> >> The changes look good to me. >> >> Joe > > Hi Lance, > just a minor comment, in isPKNameValid, you don't need the boolean isValid because > you can return true instead of using break and return false at the end. > > cheers, > R?mi > >> >> On 6/13/2012 4:09 AM, Paul Sandoz wrote: >>> On Jun 13, 2012, at 1:04 PM, Lance Andersen - Oracle wrote: >>>> Hi Paul, >>>> >>>> Thank you for taking the time to review the code. >>>> >>>> >>>> I made the change you suggested below >>>> >>>> http://cr.openjdk.java.net/~lancea/7145913/webrev.02 >>>> >>>> Let me know if you are good with the change and I will get this puppy put back. >>>> >>> Looks good! >>> >>> Paul. > > 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 From forax at univ-mlv.fr Wed Jun 13 17:18:57 2012 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Wed, 13 Jun 2012 19:18:57 +0200 Subject: Review request for 7145913 CachedRowSetSwriter.insertNewRow() throws SQLException In-Reply-To: <85D57A5E-833D-46B1-A13E-D278D1DA5A06@oracle.com> References: <475A155E-4B22-4A51-B2DC-ACF034F048D0@oracle.com> <7A0C9C7C-48E4-422A-9A42-1DAF5263C47C@oracle.com> <7E415BCD-E57A-474D-8B35-80EB2EAAF00E@oracle.com> <3FBCA042-32A8-46D5-8C46-5BFC267F88A3@oracle.com> <8D925D56-B3C7-4881-BCB6-B78EB8BEFFC5@oracle.com> <4FD8BD42.3020106@oracle.com> <4FD8C4AC.3010305@univ-mlv.fr> <85D57A5E-833D-46B1-A13E-D278D1DA5A06@oracle.com> Message-ID: <4FD8CB81.9030303@univ-mlv.fr> On 06/13/2012 07:01 PM, Lance Andersen - Oracle wrote: > Hi Remi, > > Thank you for the suggestion. Over the years, I have gotten different > views on whether to have multiple return points vs just one. > > Is there a specific style preference that should be used going > forward? At this time, I would prefer to not make another change > and if the consensus going forward is that multiple return points is > OK, I will make the change in my next push of this code. > > Best > Lance I don't want to start another endless debate between single/multiple return points. It's just that most of the code of the JDK, at least after java 2, is written using the multiple return points style. rgds, R?mi > On Jun 13, 2012, at 12:49 PM, R?mi Forax wrote: > >> On 06/13/2012 06:18 PM, Joe Wang wrote: >>> Hi Lance, >>> >>> The changes look good to me. >>> >>> Joe >> >> Hi Lance, >> just a minor comment, in isPKNameValid, you don't need the boolean >> isValid because >> you can return true instead of using break and return false at the end. >> >> cheers, >> R?mi >> >>> >>> On 6/13/2012 4:09 AM, Paul Sandoz wrote: >>>> On Jun 13, 2012, at 1:04 PM, Lance Andersen - Oracle wrote: >>>>> Hi Paul, >>>>> >>>>> Thank you for taking the time to review the code. >>>>> >>>>> >>>>> I made the change you suggested below >>>>> >>>>> http://cr.openjdk.java.net/~lancea/7145913/webrev.02 >>>>> >>>>> >>>>> Let me know if you are good with the change and I will get this >>>>> puppy put back. >>>>> >>>> Looks good! >>>> >>>> Paul. >> >> > > > 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 > From dbelfer at gmail.com Wed Jun 13 19:36:10 2012 From: dbelfer at gmail.com (Diego Belfer) Date: Wed, 13 Jun 2012 16:36:10 -0300 Subject: PATCH [6901992] : Possible InvalidJarIndexException due to bug in sun.misc.JarIndex.merge() In-Reply-To: <4FD8AC53.7040204@oracle.com> References: <4FD8AC53.7040204@oracle.com> Message-ID: Hi Chris, That's right. The only non-cleanup change is the one in the merge. Regarding the test case, I will re-write them in order to generate the jars on fly. I'd scanned the jdk/test folder and found a few jars, that's why I included them. I have seen your test case, I will use it as a sample. I had not seen your comment in the bug report. Maybe there are other cases which trigger the InvalidJarIndexException, but, as far as I could see, the validIndex method checks that at least one entry of the jar matches the target path found in the index. If directory entries are not present in the jar, stripped paths generated during the merge and used by the index will return jars which may not contain entries for them, triggering the exception. When all directory entries are present, if a jar contains an entry for "xxx/yyy/resource.file", it will contain entries for "xxx", "xxx/yyy" and "xxx/yyy/resource.file". Best, Diego On Wed, Jun 13, 2012 at 12:05 PM, Chris Hegarty wrote: > Hi Diego, > > Thanks for picking up this bug. > > I think your changes look fine. Mainly cleanup except for add -> > addExplicit/addMapping in merge, right? BTW the cleanup makes this more > readable. > > Unfortunately, the tests you created require checking in a binary jar > file. This is a real no no for the OpenJDK, we really need to create these > jars on the fly. I did similar for test/sun/misc/JarIndex/**metaInfFilenames/, > but I really wish I generated the source files for these tests rather than > checking in so many pointless files. > > I can look at helping with writing suitable tests for this. > > > > That's because I was using jars containing "directory entries" > > (I was unaware that jar files may not include them) > > Strangely I added the comment "Remove directories from jar files being > indexed." to the workaround section of the bug. You seem to be seeing the > opposite, right? > > -Chris. > > > > On 13/06/2012 06:11, Diego Belfer wrote: > >> Hi, >> >> I have finally reproduced the InvalidJarIndexException bug as reported in >> the ticket. I mentioned in a previous email, that the only way I'd found >> for getting the error was to use an invalid index file (INDEX.LIST), which >> did not have any sense. That's because I was using jars containing >> "directory entries" (I was unaware that jar files may not include them) >> >> After reviewing the URLClasspath$JarLoader class and the validIndex >> method, >> I notice it is possible to get the exception for a Jar file which does not >> include directory entries. In order to trigger the issue, the Jar must be >> referenced by an intermediary INDEX.LIST and the intermediary Jar index >> should have been merged to its parent index. Although, jar tool includes >> directory entries in the generated jar files, Eclipse default option for >> exporting jars does not include them (AFAIK), so this might be quite >> common. >> >> I have created a new PATCH which includes an additional test case which >> uses the URLClassLoader to trigger the InvalidIndexException. >> >> The patch is attached, please consider it for review. >> >> Best, >> Diego Belfer [muralx] >> >> >> >> On Mon, Jun 11, 2012 at 4:47 PM, Diego Belfer wrote: >> >> Hi, >>> >>> Here is a patch that fixes the merge method of the JarIndex. This bug was >>> reported as the cause of the bug 6901992. Although, I was not able to >>> reproduce the BUG itself (InvalidJarIndexException), I did verified that >>> the method had a bug, and resources/classes where not found in a jarIndex >>> with merged contents. >>> >>> If you think it is possible to commit this fix without actually >>> reproducing the original bug report, please consider this patch for >>> review. >>> >>> Thanks, >>> Diego Belfer [muralx] >>> >>> >>> From chris.hegarty at oracle.com Wed Jun 13 21:46:10 2012 From: chris.hegarty at oracle.com (chris hegarty) Date: Wed, 13 Jun 2012 22:46:10 +0100 Subject: PATCH [6901992] : Possible InvalidJarIndexException due to bug in sun.misc.JarIndex.merge() In-Reply-To: References: <4FD8AC53.7040204@oracle.com> Message-ID: <4FD90A22.20608@oracle.com> Diego, I'm thinking that some of the trivial source files, to compile and built into the jars, could be simply created and written by the test itself, rather than checking them all in. If this makes it cleaner. I really don't like all the file in test/sun/misc/JarIndex/metaInfFilenames, but at least it is quite understandable. -Chris. On 13/06/2012 20:36, Diego Belfer wrote: > Hi Chris, > > That's right. The only non-cleanup change is the one in the merge. > > Regarding the test case, I will re-write them in order to generate the > jars on fly. I'd scanned the jdk/test folder and found a few jars, > that's why I included them. I have seen your test case, I will use it > as a sample. > > I had not seen your comment in the bug report. Maybe there are other > cases which trigger the InvalidJarIndexException, but, as far as I could > see, the validIndex method checks that at least one entry of the jar > matches the target path found in the index. If directory entries are not > present in the jar, stripped paths generated during the merge and used > by the index will return jars which may not contain entries for them, > triggering the exception. > When all directory entries are present, if a jar contains an entry for > "xxx/yyy/resource.file", it will contain entries for "xxx", "xxx/yyy" > and "xxx/yyy/resource.file". > > > Best, > Diego > > > On Wed, Jun 13, 2012 at 12:05 PM, Chris Hegarty > > wrote: > > Hi Diego, > > Thanks for picking up this bug. > > I think your changes look fine. Mainly cleanup except for add -> > addExplicit/addMapping in merge, right? BTW the cleanup makes this > more readable. > > Unfortunately, the tests you created require checking in a binary > jar file. This is a real no no for the OpenJDK, we really need to > create these jars on the fly. I did similar for > test/sun/misc/JarIndex/__metaInfFilenames/, but I really wish I > generated the source files for these tests rather than checking in > so many pointless files. > > I can look at helping with writing suitable tests for this. > > > > That's because I was using jars containing "directory entries" > > (I was unaware that jar files may not include them) > > Strangely I added the comment "Remove directories from jar files > being indexed." to the workaround section of the bug. You seem to be > seeing the opposite, right? > > -Chris. > > > > On 13/06/2012 06:11, Diego Belfer wrote: > > Hi, > > I have finally reproduced the InvalidJarIndexException bug as > reported in > the ticket. I mentioned in a previous email, that the only way > I'd found > for getting the error was to use an invalid index file > (INDEX.LIST), which > did not have any sense. That's because I was using jars containing > "directory entries" (I was unaware that jar files may not > include them) > > After reviewing the URLClasspath$JarLoader class and the > validIndex method, > I notice it is possible to get the exception for a Jar file > which does not > include directory entries. In order to trigger the issue, the > Jar must be > referenced by an intermediary INDEX.LIST and the intermediary > Jar index > should have been merged to its parent index. Although, jar tool > includes > directory entries in the generated jar files, Eclipse default > option for > exporting jars does not include them (AFAIK), so this might be > quite common. > > I have created a new PATCH which includes an additional test > case which > uses the URLClassLoader to trigger the InvalidIndexException. > > The patch is attached, please consider it for review. > > Best, > Diego Belfer [muralx] > > > > On Mon, Jun 11, 2012 at 4:47 PM, Diego Belfer > wrote: > > Hi, > > Here is a patch that fixes the merge method of the JarIndex. > This bug was > reported as the cause of the bug 6901992. Although, I was > not able to > reproduce the BUG itself (InvalidJarIndexException), I did > verified that > the method had a bug, and resources/classes where not found > in a jarIndex > with merged contents. > > If you think it is possible to commit this fix without actually > reproducing the original bug report, please consider this > patch for review. > > Thanks, > Diego Belfer [muralx] > > > From Ulf.Zibis at gmx.de Wed Jun 13 22:03:38 2012 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Thu, 14 Jun 2012 00:03:38 +0200 Subject: Review request for 7145913 CachedRowSetSwriter.insertNewRow() throws SQLException In-Reply-To: <3FBCA042-32A8-46D5-8C46-5BFC267F88A3@oracle.com> References: <475A155E-4B22-4A51-B2DC-ACF034F048D0@oracle.com> <7A0C9C7C-48E4-422A-9A42-1DAF5263C47C@oracle.com> <7E415BCD-E57A-474D-8B35-80EB2EAAF00E@oracle.com> <3FBCA042-32A8-46D5-8C46-5BFC267F88A3@oracle.com> Message-ID: <4FD90E3A.2040600@gmx.de> Am 13.06.2012 13:04, schrieb Lance Andersen - Oracle: > Hi Paul, > > Thank you for taking the time to review the code. > > > I made the change you suggested below > > http://cr.openjdk.java.net/~lancea/7145913/webrev.02 Typos: 912 * Hence we cannot exactly identify why the insertion failed 913 * Present the current row as a null row to the user. Please add a ',', use lowercase 'p' and maybe rename user to caller 912 * Hence we cannot exactly identify why the insertion failed, 913 * present the current row as a null row to the caller. In isPKNameValid(...) you could reuse icolCount from line 843. Another additional thought: Isn't it likely, that the internal imlementation of ResultSetMetaData methods decrements the column index like following: public String getColumnClassName(int column) { return columns[column - 1].className; In this case, iterating over the range of 0..cols-1 could be a small performance gain after JIT optimization: 1469 for(int i = 0; i< cols; i++) { 1470 String colName = rsmd.getColumnClassName(i + 1); If not, the offset could be anyway treated by single opcode using complex addressing. Same for iterating over ResultSet collumns. -Ulf From dbelfer at gmail.com Wed Jun 13 22:12:45 2012 From: dbelfer at gmail.com (Diego Belfer) Date: Wed, 13 Jun 2012 19:12:45 -0300 Subject: PATCH [6901992] : Possible InvalidJarIndexException due to bug in sun.misc.JarIndex.merge() In-Reply-To: <4FD90A22.20608@oracle.com> References: <4FD8AC53.7040204@oracle.com> <4FD90A22.20608@oracle.com> Message-ID: Chris, I was thinking of something similar. I will create the jars and their contents using Java code. There is no need of creating real class files, using a few resource files and some directories will be enough. Best, Diego On Wed, Jun 13, 2012 at 6:46 PM, chris hegarty wrote: > Diego, > > I'm thinking that some of the trivial source files, to compile and built > into the jars, could be simply created and written by the test itself, > rather than checking them all in. If this makes it cleaner. I really don't > like all the file in test/sun/misc/JarIndex/**metaInfFilenames, but at > least it is quite understandable. > > -Chris. > > > On 13/06/2012 20:36, Diego Belfer wrote: > >> Hi Chris, >> >> That's right. The only non-cleanup change is the one in the merge. >> >> Regarding the test case, I will re-write them in order to generate the >> jars on fly. I'd scanned the jdk/test folder and found a few jars, >> that's why I included them. I have seen your test case, I will use it >> as a sample. >> >> I had not seen your comment in the bug report. Maybe there are other >> cases which trigger the InvalidJarIndexException, but, as far as I could >> see, the validIndex method checks that at least one entry of the jar >> matches the target path found in the index. If directory entries are not >> present in the jar, stripped paths generated during the merge and used >> by the index will return jars which may not contain entries for them, >> triggering the exception. >> When all directory entries are present, if a jar contains an entry for >> "xxx/yyy/resource.file", it will contain entries for "xxx", "xxx/yyy" >> and "xxx/yyy/resource.file". >> >> >> Best, >> Diego >> >> >> On Wed, Jun 13, 2012 at 12:05 PM, Chris Hegarty >> >> >> wrote: >> >> Hi Diego, >> >> Thanks for picking up this bug. >> >> I think your changes look fine. Mainly cleanup except for add -> >> addExplicit/addMapping in merge, right? BTW the cleanup makes this >> more readable. >> >> Unfortunately, the tests you created require checking in a binary >> jar file. This is a real no no for the OpenJDK, we really need to >> create these jars on the fly. I did similar for >> test/sun/misc/JarIndex/__**metaInfFilenames/, but I really wish I >> >> generated the source files for these tests rather than checking in >> so many pointless files. >> >> I can look at helping with writing suitable tests for this. >> >> >> > That's because I was using jars containing "directory entries" >> > (I was unaware that jar files may not include them) >> >> Strangely I added the comment "Remove directories from jar files >> being indexed." to the workaround section of the bug. You seem to be >> seeing the opposite, right? >> >> -Chris. >> >> >> >> On 13/06/2012 06:11, Diego Belfer wrote: >> >> Hi, >> >> I have finally reproduced the InvalidJarIndexException bug as >> reported in >> the ticket. I mentioned in a previous email, that the only way >> I'd found >> for getting the error was to use an invalid index file >> (INDEX.LIST), which >> did not have any sense. That's because I was using jars containing >> "directory entries" (I was unaware that jar files may not >> include them) >> >> After reviewing the URLClasspath$JarLoader class and the >> validIndex method, >> I notice it is possible to get the exception for a Jar file >> which does not >> include directory entries. In order to trigger the issue, the >> Jar must be >> referenced by an intermediary INDEX.LIST and the intermediary >> Jar index >> should have been merged to its parent index. Although, jar tool >> includes >> directory entries in the generated jar files, Eclipse default >> option for >> exporting jars does not include them (AFAIK), so this might be >> quite common. >> >> I have created a new PATCH which includes an additional test >> case which >> uses the URLClassLoader to trigger the InvalidIndexException. >> >> The patch is attached, please consider it for review. >> >> Best, >> Diego Belfer [muralx] >> >> >> >> On Mon, Jun 11, 2012 at 4:47 PM, Diego Belfer> > wrote: >> >> >> Hi, >> >> Here is a patch that fixes the merge method of the JarIndex. >> This bug was >> reported as the cause of the bug 6901992. Although, I was >> not able to >> reproduce the BUG itself (InvalidJarIndexException), I did >> verified that >> the method had a bug, and resources/classes where not found >> in a jarIndex >> with merged contents. >> >> If you think it is possible to commit this fix without actually >> reproducing the original bug report, please consider this >> patch for review. >> >> Thanks, >> Diego Belfer [muralx] >> >> >> >> From dbelfer at gmail.com Thu Jun 14 02:20:02 2012 From: dbelfer at gmail.com (Diego Belfer) Date: Wed, 13 Jun 2012 23:20:02 -0300 Subject: PATCH [6901992] : Possible InvalidJarIndexException due to bug in sun.misc.JarIndex.merge() In-Reply-To: References: <4FD8AC53.7040204@oracle.com> <4FD90A22.20608@oracle.com> Message-ID: Hi Chris, There is no way to generate a jar without directory entries using the jar tool; there is no option for that. What do you think is the best way to handle this ? I don't want to re-implement the logic for creating a jar using the JarOutputStream class. Do you think it is possible to add a new option to the Jar tool Main class to exclude directory entries? The option does not need to be exposed by the command line tool to final users if this an issue, although I think it may be useful for them too. Best, Diego On Wed, Jun 13, 2012 at 7:12 PM, Diego Belfer wrote: > Chris, > > I was thinking of something similar. I will create the jars and their > contents using Java code. There is no need of creating real class files, > using a few resource files and some directories will be enough. > > Best, > Diego > > > On Wed, Jun 13, 2012 at 6:46 PM, chris hegarty wrote: > >> Diego, >> >> I'm thinking that some of the trivial source files, to compile and built >> into the jars, could be simply created and written by the test itself, >> rather than checking them all in. If this makes it cleaner. I really don't >> like all the file in test/sun/misc/JarIndex/**metaInfFilenames, but at >> least it is quite understandable. >> >> -Chris. >> >> >> On 13/06/2012 20:36, Diego Belfer wrote: >> >>> Hi Chris, >>> >>> That's right. The only non-cleanup change is the one in the merge. >>> >>> Regarding the test case, I will re-write them in order to generate the >>> jars on fly. I'd scanned the jdk/test folder and found a few jars, >>> that's why I included them. I have seen your test case, I will use it >>> as a sample. >>> >>> I had not seen your comment in the bug report. Maybe there are other >>> cases which trigger the InvalidJarIndexException, but, as far as I could >>> see, the validIndex method checks that at least one entry of the jar >>> matches the target path found in the index. If directory entries are not >>> present in the jar, stripped paths generated during the merge and used >>> by the index will return jars which may not contain entries for them, >>> triggering the exception. >>> When all directory entries are present, if a jar contains an entry for >>> "xxx/yyy/resource.file", it will contain entries for "xxx", "xxx/yyy" >>> and "xxx/yyy/resource.file". >>> >>> >>> Best, >>> Diego >>> >>> >>> On Wed, Jun 13, 2012 at 12:05 PM, Chris Hegarty >>> >> >>> wrote: >>> >>> Hi Diego, >>> >>> Thanks for picking up this bug. >>> >>> I think your changes look fine. Mainly cleanup except for add -> >>> addExplicit/addMapping in merge, right? BTW the cleanup makes this >>> more readable. >>> >>> Unfortunately, the tests you created require checking in a binary >>> jar file. This is a real no no for the OpenJDK, we really need to >>> create these jars on the fly. I did similar for >>> test/sun/misc/JarIndex/__**metaInfFilenames/, but I really wish I >>> >>> generated the source files for these tests rather than checking in >>> so many pointless files. >>> >>> I can look at helping with writing suitable tests for this. >>> >>> >>> > That's because I was using jars containing "directory entries" >>> > (I was unaware that jar files may not include them) >>> >>> Strangely I added the comment "Remove directories from jar files >>> being indexed." to the workaround section of the bug. You seem to be >>> seeing the opposite, right? >>> >>> -Chris. >>> >>> >>> >>> On 13/06/2012 06:11, Diego Belfer wrote: >>> >>> Hi, >>> >>> I have finally reproduced the InvalidJarIndexException bug as >>> reported in >>> the ticket. I mentioned in a previous email, that the only way >>> I'd found >>> for getting the error was to use an invalid index file >>> (INDEX.LIST), which >>> did not have any sense. That's because I was using jars containing >>> "directory entries" (I was unaware that jar files may not >>> include them) >>> >>> After reviewing the URLClasspath$JarLoader class and the >>> validIndex method, >>> I notice it is possible to get the exception for a Jar file >>> which does not >>> include directory entries. In order to trigger the issue, the >>> Jar must be >>> referenced by an intermediary INDEX.LIST and the intermediary >>> Jar index >>> should have been merged to its parent index. Although, jar tool >>> includes >>> directory entries in the generated jar files, Eclipse default >>> option for >>> exporting jars does not include them (AFAIK), so this might be >>> quite common. >>> >>> I have created a new PATCH which includes an additional test >>> case which >>> uses the URLClassLoader to trigger the InvalidIndexException. >>> >>> The patch is attached, please consider it for review. >>> >>> Best, >>> Diego Belfer [muralx] >>> >>> >>> >>> On Mon, Jun 11, 2012 at 4:47 PM, Diego Belfer>> > wrote: >>> >>> >>> Hi, >>> >>> Here is a patch that fixes the merge method of the JarIndex. >>> This bug was >>> reported as the cause of the bug 6901992. Although, I was >>> not able to >>> reproduce the BUG itself (InvalidJarIndexException), I did >>> verified that >>> the method had a bug, and resources/classes where not found >>> in a jarIndex >>> with merged contents. >>> >>> If you think it is possible to commit this fix without >>> actually >>> reproducing the original bug report, please consider this >>> patch for review. >>> >>> Thanks, >>> Diego Belfer [muralx] >>> >>> >>> >>> > From chris.hegarty at oracle.com Thu Jun 14 10:32:29 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 14 Jun 2012 11:32:29 +0100 Subject: PATCH [6901992] : Possible InvalidJarIndexException due to bug in sun.misc.JarIndex.merge() In-Reply-To: References: <4FD8AC53.7040204@oracle.com> <4FD90A22.20608@oracle.com> Message-ID: <4FD9BDBD.7050004@oracle.com> Diego, It's not too difficult to create jars on the fly using the Jar API. Here is a small example that I think would work nice in this case. Files created ( and paths are relative to the jtreg scratch, or working dir if running outside of jtreg ). Do you think you could use similar to create the jars for your test? createJar("a.jar", jarAList); createJar("b.jar", jarBList); ....... static void createJar(String jarName, Map contents) throws Exception { try (FileOutputStream aJar = new FileOutputStream(jarName); JarOutputStream jos = new JarOutputStream(aJar)) { Set> entries = contents.entrySet(); for (Entry entry : entries) writeJarEntry(jos, entry.getKey(), entry.getValue().getBytes("ASCII")); } } static void writeJarEntry(JarOutputStream jos, String name, byte[] data) throws Exception { JarEntry entry = new JarEntry(name); jos.putNextEntry(entry); jos.write(data); } static final Map jarAList = new HashMap<>(); static final Map jarBList = new HashMap<>(); static { jarAList.put("com/foo/resource1.txt", "some random data"); jarAList.put("com/bar/resource2.txt", "some more random data!"); jarAList.put("com/baz/resource3.txt", "even more random data!!!"); jarBList.put("x/y/resourceA.dat", "Hello there"); jarBList.put("x/y/resourceB.dat", "Goodbye"); jarBList.put("x/y/resourceC.dat", "Hello\nfrom\nb\ndot\njar"); } Thanks, -Chris. On 14/06/2012 03:20, Diego Belfer wrote: > Hi Chris, > > There is no way to generate a jar without directory entries using the > jar tool; there is no option for that. What do you think is the best way > to handle this ? > I don't want to re-implement the logic for creating a jar using the > JarOutputStream class. > > Do you think it is possible to add a new option to the Jar tool Main > class to exclude directory entries? The option does not need to be > exposed by the command line tool to final users if this an issue, > although I think it may be useful for them too. > > Best, > Diego > > > On Wed, Jun 13, 2012 at 7:12 PM, Diego Belfer > wrote: > > Chris, > > I was thinking of something similar. I will create the jars and > their contents using Java code. There is no need of creating real > class files, using a few resource files and some directories will be > enough. > > Best, > Diego > > > On Wed, Jun 13, 2012 at 6:46 PM, chris hegarty > > wrote: > > Diego, > > I'm thinking that some of the trivial source files, to compile > and built into the jars, could be simply created and written by > the test itself, rather than checking them all in. If this makes > it cleaner. I really don't like all the file in > test/sun/misc/JarIndex/__metaInfFilenames, but at least it is > quite understandable. > > -Chris. > > > On 13/06/2012 20:36, Diego Belfer wrote: > > Hi Chris, > > That's right. The only non-cleanup change is the one in the > merge. > > Regarding the test case, I will re-write them in order to > generate the > jars on fly. I'd scanned the jdk/test folder and found a few > jars, > that's why I included them. I have seen your test case, I > will use it > as a sample. > > I had not seen your comment in the bug report. Maybe there > are other > cases which trigger the InvalidJarIndexException, but, as > far as I could > see, the validIndex method checks that at least one entry of > the jar > matches the target path found in the index. If directory > entries are not > present in the jar, stripped paths generated during the > merge and used > by the index will return jars which may not contain entries > for them, > triggering the exception. > When all directory entries are present, if a jar contains an > entry for > "xxx/yyy/resource.file", it will contain entries for "xxx", > "xxx/yyy" > and "xxx/yyy/resource.file". > > > Best, > Diego > > > On Wed, Jun 13, 2012 at 12:05 PM, Chris Hegarty > > >> wrote: > > Hi Diego, > > Thanks for picking up this bug. > > I think your changes look fine. Mainly cleanup except > for add -> > addExplicit/addMapping in merge, right? BTW the cleanup > makes this > more readable. > > Unfortunately, the tests you created require checking in > a binary > jar file. This is a real no no for the OpenJDK, we > really need to > create these jars on the fly. I did similar for > test/sun/misc/JarIndex/____metaInfFilenames/, but I > really wish I > > generated the source files for these tests rather than > checking in > so many pointless files. > > I can look at helping with writing suitable tests for this. > > > > That's because I was using jars containing "directory > entries" > > (I was unaware that jar files may not include them) > > Strangely I added the comment "Remove directories from > jar files > being indexed." to the workaround section of the bug. > You seem to be > seeing the opposite, right? > > -Chris. > > > > On 13/06/2012 06:11, Diego Belfer wrote: > > Hi, > > I have finally reproduced the > InvalidJarIndexException bug as > reported in > the ticket. I mentioned in a previous email, that > the only way > I'd found > for getting the error was to use an invalid index file > (INDEX.LIST), which > did not have any sense. That's because I was using > jars containing > "directory entries" (I was unaware that jar files may not > include them) > > After reviewing the URLClasspath$JarLoader class and the > validIndex method, > I notice it is possible to get the exception for a > Jar file > which does not > include directory entries. In order to trigger the > issue, the > Jar must be > referenced by an intermediary INDEX.LIST and the > intermediary > Jar index > should have been merged to its parent index. > Although, jar tool > includes > directory entries in the generated jar files, > Eclipse default > option for > exporting jars does not include them (AFAIK), so > this might be > quite common. > > I have created a new PATCH which includes an > additional test > case which > uses the URLClassLoader to trigger the > InvalidIndexException. > > The patch is attached, please consider it for review. > > Best, > Diego Belfer [muralx] > > > > On Mon, Jun 11, 2012 at 4:47 PM, Diego > Belfer > >> wrote: > > > Hi, > > Here is a patch that fixes the merge method of > the JarIndex. > This bug was > reported as the cause of the bug 6901992. > Although, I was > not able to > reproduce the BUG itself > (InvalidJarIndexException), I did > verified that > the method had a bug, and resources/classes > where not found > in a jarIndex > with merged contents. > > If you think it is possible to commit this fix > without actually > reproducing the original bug report, please > consider this > patch for review. > > Thanks, > Diego Belfer [muralx] > > > > > From alan.bateman at oracle.com Thu Jun 14 11:14:40 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 14 Jun 2012 11:14:40 +0000 Subject: hg: jdk8/tl/jdk: 7176630: (sc) SocketChannel.write does not write more than 128k when channel configured blocking [win] Message-ID: <20120614111520.036B247908@hg.openjdk.java.net> Changeset: 4f99d146fce0 Author: alanb Date: 2012-06-14 12:13 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4f99d146fce0 7176630: (sc) SocketChannel.write does not write more than 128k when channel configured blocking [win] Reviewed-by: khazra, chegar ! src/windows/native/sun/nio/ch/SocketDispatcher.c + test/java/nio/channels/SocketChannel/ShortWrite.java From mike.duigou at oracle.com Thu Jun 14 15:27:16 2012 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Thu, 14 Jun 2012 15:27:16 +0000 Subject: hg: jdk8/tl/jdk: 7173919: Minor optimization of hashing methods Message-ID: <20120614152728.0BDA84790C@hg.openjdk.java.net> Changeset: 505455116320 Author: mduigou Date: 2012-06-13 16:48 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/505455116320 7173919: Minor optimization of hashing methods Summary: several minor optimizations to hashing methods used by hash map classes Reviewed-by: dholmes ! src/share/classes/java/util/HashMap.java ! src/share/classes/java/util/Hashtable.java ! src/share/classes/java/util/WeakHashMap.java ! src/share/classes/java/util/concurrent/ConcurrentHashMap.java From Ulf.Zibis at gmx.de Thu Jun 14 16:29:36 2012 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Thu, 14 Jun 2012 18:29:36 +0200 Subject: hg: jdk8/tl/jdk: 7173919: Minor optimization of hashing methods In-Reply-To: <20120614152728.0BDA84790C@hg.openjdk.java.net> References: <20120614152728.0BDA84790C@hg.openjdk.java.net> Message-ID: <4FDA1170.4090504@gmx.de> Hi Mike, I like the 1-liner ... :-) int h = hashSeed ^ k.hashCode(); ... but I'm still missing a little comment, what this xor with a hashSeed serves for. Such as brief, as the next following 3 lines about preventing from collisions. WeakHashMap.hash(Object) could be private too, instead final. And last... you have reinserted/left the space after the cast in some occurences. ;-) -Ulf Am 14.06.2012 17:27, schrieb mike.duigou at oracle.com: > Changeset: 505455116320 > Author: mduigou > Date: 2012-06-13 16:48 -0700 > URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/505455116320 > > 7173919: Minor optimization of hashing methods > Summary: several minor optimizations to hashing methods used by hash map classes > Reviewed-by: dholmes > > ! src/share/classes/java/util/HashMap.java > ! src/share/classes/java/util/Hashtable.java > ! src/share/classes/java/util/WeakHashMap.java > ! src/share/classes/java/util/concurrent/ConcurrentHashMap.java > > From lance.andersen at oracle.com Thu Jun 14 19:05:53 2012 From: lance.andersen at oracle.com (lance.andersen at oracle.com) Date: Thu, 14 Jun 2012 19:05:53 +0000 Subject: hg: jdk8/tl/jdk: 7145913: CachedRowSetSwriter.insertNewRow() throws SQLException Message-ID: <20120614190618.B196347917@hg.openjdk.java.net> Changeset: 28588ace1fb9 Author: lancea Date: 2012-06-14 15:05 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/28588ace1fb9 7145913: CachedRowSetSwriter.insertNewRow() throws SQLException Reviewed-by: joehw, naoto, psandoz, forax ! src/share/classes/com/sun/rowset/internal/CachedRowSetWriter.java From Lance.Andersen at oracle.com Thu Jun 14 19:10:30 2012 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Thu, 14 Jun 2012 15:10:30 -0400 Subject: Review request for 7145913 CachedRowSetSwriter.insertNewRow() throws SQLException In-Reply-To: <4FD90E3A.2040600@gmx.de> References: <475A155E-4B22-4A51-B2DC-ACF034F048D0@oracle.com> <7A0C9C7C-48E4-422A-9A42-1DAF5263C47C@oracle.com> <7E415BCD-E57A-474D-8B35-80EB2EAAF00E@oracle.com> <3FBCA042-32A8-46D5-8C46-5BFC267F88A3@oracle.com> <4FD90E3A.2040600@gmx.de> Message-ID: <9F0523A6-DC90-401B-9CFA-38B8E3FAC47E@oracle.com> Thanks for the comments On Jun 13, 2012, at 6:03 PM, Ulf Zibis wrote: > > Am 13.06.2012 13:04, schrieb Lance Andersen - Oracle: >> Hi Paul, >> >> Thank you for taking the time to review the code. >> >> >> I made the change you suggested below >> >> http://cr.openjdk.java.net/~lancea/7145913/webrev.02 > Typos: > 912 * Hence we cannot exactly identify why the insertion failed > 913 * Present the current row as a null row to the user. > Please add a ',', use lowercase 'p' and maybe rename user to caller > 912 * Hence we cannot exactly identify why the insertion failed, > 913 * present the current row as a null row to the caller. > I made this change > In isPKNameValid(...) you could reuse icolCount from line 843. > > Another additional thought: > Isn't it likely, that the internal imlementation of ResultSetMetaData methods decrements the column index like following: > public String getColumnClassName(int column) { > return columns[column - 1].className; > In this case, iterating over the range of 0..cols-1 could be a small performance gain after JIT optimization: > 1469 for(int i = 0; i< cols; i++) { > 1470 String colName = rsmd.getColumnClassName(i + 1); > If not, the offset could be anyway treated by single opcode using complex addressing. > > Same for iterating over ResultSet collumns. I will review this for future updates, but for now, I did not make this change Best Lance > > -Ulf > 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 From mike.duigou at oracle.com Thu Jun 14 19:40:04 2012 From: mike.duigou at oracle.com (Mike Duigou) Date: Thu, 14 Jun 2012 12:40:04 -0700 Subject: Request for Review 7175758 : Improvements to Collisions.java regression test Message-ID: Hello all; This review is for test changes only. CR#7174736 (http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fc0e508b713f) corrected a problem uncovered by a JCK test. A regression test was not included in that changeset. This patch adds a regression test for the root cause of CR#7174736 as well as additional tests on Map iterators and the Iterator.remove() functionality. http://cr.openjdk.java.net/~mduigou/7175758/0/webrev/ The reduction in "ITEMS" is to ensure that the test runs in reasonable time. 10000 keys caused the test to run for too long (especially with these additional tests). Mike From Lance.Andersen at oracle.com Thu Jun 14 19:54:20 2012 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Thu, 14 Jun 2012 15:54:20 -0400 Subject: Request for Review 7175758 : Improvements to Collisions.java regression test In-Reply-To: References: Message-ID: Looks good Mike Best Lance On Jun 14, 2012, at 3:40 PM, Mike Duigou wrote: > Hello all; > > This review is for test changes only. CR#7174736 (http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fc0e508b713f) corrected a problem uncovered by a JCK test. A regression test was not included in that changeset. This patch adds a regression test for the root cause of CR#7174736 as well as additional tests on Map iterators and the Iterator.remove() functionality. > > http://cr.openjdk.java.net/~mduigou/7175758/0/webrev/ > > The reduction in "ITEMS" is to ensure that the test runs in reasonable time. 10000 keys caused the test to run for too long (especially with these additional tests). > > Mike 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 From mike.duigou at oracle.com Thu Jun 14 20:26:40 2012 From: mike.duigou at oracle.com (Mike Duigou) Date: Thu, 14 Jun 2012 13:26:40 -0700 Subject: hg: jdk8/tl/jdk: 7173919: Minor optimization of hashing methods In-Reply-To: <4FDA1170.4090504@gmx.de> References: <20120614152728.0BDA84790C@hg.openjdk.java.net> <4FDA1170.4090504@gmx.de> Message-ID: <6AB74EE9-60A6-4B66-8248-BA04487DC8BA@oracle.com> On Jun 14 2012, at 09:29 , Ulf Zibis wrote: > Hi Mike, > > I like the 1-liner ... :-) > int h = hashSeed ^ k.hashCode(); > > ... but I'm still missing a little comment, what this xor with a hashSeed serves for. Such as brief, as the next following 3 lines about preventing from collisions. The hashSeed randomizes table order to reduce the value of partial collisions--only full collisions will predictably collide. The comment I think you are looking for is on hashSeed itself. /** * A randomizing value associated with this instance that is applied to * hash code of keys to make hash collisions harder to find. */ > > WeakHashMap.hash(Object) could be private too, instead final. OK. I will probably make it private method though I hate opening an issue just for one keyword. > > And last... you have reinserted/left the space after the cast in some occurences. ;-) Netbeans did actually. I don't do my own source formatting. Mike > > -Ulf > > Am 14.06.2012 17:27, schrieb mike.duigou at oracle.com: >> Changeset: 505455116320 >> Author: mduigou >> Date: 2012-06-13 16:48 -0700 >> URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/505455116320 >> >> 7173919: Minor optimization of hashing methods >> Summary: several minor optimizations to hashing methods used by hash map classes >> Reviewed-by: dholmes >> >> ! src/share/classes/java/util/HashMap.java >> ! src/share/classes/java/util/Hashtable.java >> ! src/share/classes/java/util/WeakHashMap.java >> ! src/share/classes/java/util/concurrent/ConcurrentHashMap.java >> >> > > From Ulf.Zibis at gmx.de Thu Jun 14 20:51:34 2012 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Thu, 14 Jun 2012 22:51:34 +0200 Subject: hg: jdk8/tl/jdk: 7173919: Minor optimization of hashing methods In-Reply-To: <6AB74EE9-60A6-4B66-8248-BA04487DC8BA@oracle.com> References: <20120614152728.0BDA84790C@hg.openjdk.java.net> <4FDA1170.4090504@gmx.de> <6AB74EE9-60A6-4B66-8248-BA04487DC8BA@oracle.com> Message-ID: <4FDA4ED6.2000003@gmx.de> Am 14.06.2012 22:26, schrieb Mike Duigou: > On Jun 14 2012, at 09:29 , Ulf Zibis wrote: > >> Hi Mike, >> >> I like the 1-liner ... :-) >> int h = hashSeed ^ k.hashCode(); >> >> ... but I'm still missing a little comment, what this xor with a hashSeed serves for. Such as brief, as the next following 3 lines about preventing from collisions. > The hashSeed randomizes table order to reduce the value of partial collisions--only full collisions will predictably collide. The comment I think you are looking for is on hashSeed itself. > > /** > * A randomizing value associated with this instance that is applied to > * hash code of keys to make hash collisions harder to find. > */ Oops, sorry, I oversaw that. I'm ok with. Anyway, I still don't understand the trick behind. Is there a good explanation in the web? >> WeakHashMap.hash(Object) could be private too, instead final. > OK. I will probably make it private method though I hate opening an issue just for one keyword. 8-) If there is no performance impact, it could stay as it is from my side, I was just wondering about the inconsistency. >> And last... you have reinserted/left the space after the cast in some occurences. ;-) > Netbeans did actually. I don't do my own source formatting. Wasn't you one of those, who argued against the space some days ago? But it's easy to adapt it in Netbeans forever: Tools->Options->Editor->Formatting->Java->Spaces->Other->After Type Cast -Ulf From jonathan.gibbons at oracle.com Thu Jun 14 23:00:29 2012 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 14 Jun 2012 16:00:29 -0700 Subject: hg: jdk8/tl/jdk: 6924259: Remove offset and count fields from java.lang.String In-Reply-To: References: <20120531032252.A69774763C@hg.openjdk.java.net> <1359801.KFxJhQHyve@cube> Message-ID: <4FDA6D0D.4080502@oracle.com> For the record, javadoc uses substring very heavily, and might be impacted by this change. -- Jon On 06/03/2012 02:35 PM, Mike Duigou wrote: > [I trimmed the distribution list] > > On Jun 3 2012, at 13:44 , Peter Levart wrote: > >> On Thursday, May 31, 2012 03:22:35 AM mike.duigou at oracle.com wrote: >>> Changeset: 2c773daa825d >>> Author: mduigou >>> Date: 2012-05-17 10:06 -0700 >>> URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2c773daa825d >>> >>> 6924259: Remove offset and count fields from java.lang.String >>> Summary: Removes the use of shared character array buffers by String along >>> with the two fields needed to support the use of shared buffers. >> Wow, that's quite a change. > Indeed. It was a long time in development. It is a change which is expected to be overall beneficial though and in the general case a positive win. > >> So .substring() is not O(1) any more? > No. Though with object allocation it probably was only ever roughly O(1) anyway. > >> Doesn't this have impact on the performance of parsers and such that rely on >> the performance caracteristics of the .substring() ? > It does have an impact. We've seen as much as a couple of percent on some benchmarks. Parsers which use substring for extraction are definitely impacted by this change. > >> Have you considered then implementing .subSequence() not in terms of just >> delegating to .substring() but returning a special CharSequence view over the >> chars of the sub-sequence? > It does look that String.subSequence() returning a special view rather than a substring would be a good optimization and probably a very good compromise for parser developers. Please create an issue and if you have the time and expertise a patch would speed things along (though unfortunately almost certainly too late for inclusion in 7u6). > > Mike > >> Regards, Peter >> >>> Reviewed-by: alanb, mduigou, forax, briangoetz >>> Contributed-by: brian.doherty at oracle.com >>> >>> ! src/share/classes/java/lang/Integer.java >>> ! src/share/classes/java/lang/Long.java >>> ! src/share/classes/java/lang/String.java >>> ! src/share/classes/java/lang/StringCoding.java From sean.coffey at oracle.com Fri Jun 15 13:14:24 2012 From: sean.coffey at oracle.com (sean.coffey at oracle.com) Date: Fri, 15 Jun 2012 13:14:24 +0000 Subject: hg: jdk8/tl/jdk: 7156963: Incorrect copyright header in java/io/SerialCallbackContext Message-ID: <20120615131455.5BFD04795D@hg.openjdk.java.net> Changeset: 00c9d6cce3ec Author: coffeys Date: 2012-06-15 14:16 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/00c9d6cce3ec 7156963: Incorrect copyright header in java/io/SerialCallbackContext Reviewed-by: weijun, coffeys Contributed-by: edvard.wendelin at oracle.com ! src/share/classes/java/io/SerialCallbackContext.java From sean.mullan at oracle.com Fri Jun 15 13:16:33 2012 From: sean.mullan at oracle.com (sean.mullan at oracle.com) Date: Fri, 15 Jun 2012 13:16:33 +0000 Subject: hg: jdk8/tl/jdk: 3 new changesets Message-ID: <20120615131706.2B31E4795E@hg.openjdk.java.net> Changeset: 8deec0d1fc6f Author: mullan Date: 2012-06-15 08:43 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8deec0d1fc6f 7176326: CertPath/CertPathBuilderTest failures after webrev 6854712_6637288_7126011 Reviewed-by: xuelei ! src/share/classes/sun/security/provider/certpath/BasicChecker.java + test/java/security/cert/CertPathBuilder/zeroLengthPath/ZeroLengthPath.java Changeset: 0e382512610f Author: mullan Date: 2012-06-15 08:47 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0e382512610f Merge Changeset: e01b47409e37 Author: mullan Date: 2012-06-15 09:16 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e01b47409e37 Merge From alan.bateman at oracle.com Fri Jun 15 16:20:55 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Fri, 15 Jun 2012 16:20:55 +0000 Subject: hg: jdk8/tl/jdk: 7176485: (bf) Allow temporary buffer cache to grow to IOV_MAX Message-ID: <20120615162128.55ECF47962@hg.openjdk.java.net> Changeset: 23394d686f74 Author: alanb Date: 2012-06-15 17:16 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/23394d686f74 7176485: (bf) Allow temporary buffer cache to grow to IOV_MAX Reviewed-by: chegar, coffeys ! make/java/nio/mapfile-linux ! make/java/nio/mapfile-solaris ! src/share/classes/sun/nio/ch/IOUtil.java ! src/share/classes/sun/nio/ch/Util.java ! src/solaris/native/sun/nio/ch/FileDispatcherImpl.c ! src/solaris/native/sun/nio/ch/IOUtil.c ! src/windows/native/sun/nio/ch/IOUtil.c ! src/windows/native/sun/nio/ch/SocketDispatcher.c ! src/windows/native/sun/nio/ch/nio_util.h From mike.duigou at oracle.com Fri Jun 15 21:32:53 2012 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Fri, 15 Jun 2012 21:32:53 +0000 Subject: hg: jdk8/tl/jdk: 7175758: Improve unit test of Map iterators and Iterator.remove() Message-ID: <20120615213315.042A24796C@hg.openjdk.java.net> Changeset: e60cedd3a4aa Author: mduigou Date: 2012-06-15 13:01 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e60cedd3a4aa 7175758: Improve unit test of Map iterators and Iterator.remove() Summary: Adds additional tests of Map iterators and Iterator.remove() Reviewed-by: lancea ! test/java/util/Map/Collisions.java From bradford.wetmore at oracle.com Sat Jun 16 00:43:02 2012 From: bradford.wetmore at oracle.com (bradford.wetmore at oracle.com) Date: Sat, 16 Jun 2012 00:43:02 +0000 Subject: hg: jdk8/tl/jdk: 7177556: Put TestProviderLeak.java on the ProblemList until test can be reworked Message-ID: <20120616004321.8A7C447972@hg.openjdk.java.net> Changeset: 8e5635ded425 Author: wetmore Date: 2012-06-15 17:42 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8e5635ded425 7177556: Put TestProviderLeak.java on the ProblemList until test can be reworked Reviewed-by: khazra ! test/ProblemList.txt From dbelfer at gmail.com Sat Jun 16 04:20:51 2012 From: dbelfer at gmail.com (Diego Belfer) Date: Sat, 16 Jun 2012 01:20:51 -0300 Subject: PATCH [6901992] : Possible InvalidJarIndexException due to bug in sun.misc.JarIndex.merge() In-Reply-To: <4FD9BDBD.7050004@oracle.com> References: <4FD8AC53.7040204@oracle.com> <4FD90A22.20608@oracle.com> <4FD9BDBD.7050004@oracle.com> Message-ID: Hi Chris, Here is a new patch containing new version of the tests. The new versions generate a the Jar on the fly as we discussed. Let me know if there is anything else you think should be improved. Best, Diego On Thu, Jun 14, 2012 at 7:32 AM, Chris Hegarty wrote: > Diego, > > It's not too difficult to create jars on the fly using the Jar API. Here > is a small example that I think would work nice in this case. Files created > ( and paths are relative to the jtreg scratch, or working dir if running > outside of jtreg ). > > Do you think you could use similar to create the jars for your test? > > createJar("a.jar", jarAList); > createJar("b.jar", jarBList); > ....... > > static void createJar(String jarName, Map contents) > throws Exception > { > try (FileOutputStream aJar = new FileOutputStream(jarName); > JarOutputStream jos = new JarOutputStream(aJar)) { > Set> entries = contents.entrySet(); > for (Entry entry : entries) > writeJarEntry(jos, entry.getKey(), > entry.getValue().getBytes("**ASCII")); > } > } > > static void writeJarEntry(JarOutputStream jos, String name, byte[] data) > throws Exception > { > JarEntry entry = new JarEntry(name); > jos.putNextEntry(entry); > jos.write(data); > } > > static final Map jarAList = new HashMap<>(); > static final Map jarBList = new HashMap<>(); > static { > jarAList.put("com/foo/**resource1.txt", "some random data"); > jarAList.put("com/bar/**resource2.txt", "some more random data!"); > jarAList.put("com/baz/**resource3.txt", "even more random > data!!!"); > jarBList.put("x/y/resourceA.**dat", "Hello there"); > jarBList.put("x/y/resourceB.**dat", "Goodbye"); > jarBList.put("x/y/resourceC.**dat", "Hello\nfrom\nb\ndot\njar"); > } > > Thanks, > -Chris. > > > On 14/06/2012 03:20, Diego Belfer wrote: > >> Hi Chris, >> >> There is no way to generate a jar without directory entries using the >> jar tool; there is no option for that. What do you think is the best way >> to handle this ? >> I don't want to re-implement the logic for creating a jar using the >> JarOutputStream class. >> >> Do you think it is possible to add a new option to the Jar tool Main >> class to exclude directory entries? The option does not need to be >> exposed by the command line tool to final users if this an issue, >> although I think it may be useful for them too. >> >> Best, >> Diego >> >> >> On Wed, Jun 13, 2012 at 7:12 PM, Diego Belfer > > wrote: >> >> Chris, >> >> I was thinking of something similar. I will create the jars and >> their contents using Java code. There is no need of creating real >> class files, using a few resource files and some directories will be >> enough. >> >> Best, >> Diego >> >> >> On Wed, Jun 13, 2012 at 6:46 PM, chris hegarty >> >> >> wrote: >> >> Diego, >> >> I'm thinking that some of the trivial source files, to compile >> and built into the jars, could be simply created and written by >> the test itself, rather than checking them all in. If this makes >> it cleaner. I really don't like all the file in >> test/sun/misc/JarIndex/__**metaInfFilenames, but at least it is >> >> quite understandable. >> >> -Chris. >> >> >> On 13/06/2012 20:36, Diego Belfer wrote: >> >> Hi Chris, >> >> That's right. The only non-cleanup change is the one in the >> merge. >> >> Regarding the test case, I will re-write them in order to >> generate the >> jars on fly. I'd scanned the jdk/test folder and found a few >> jars, >> that's why I included them. I have seen your test case, I >> will use it >> as a sample. >> >> I had not seen your comment in the bug report. Maybe there >> are other >> cases which trigger the InvalidJarIndexException, but, as >> far as I could >> see, the validIndex method checks that at least one entry of >> the jar >> matches the target path found in the index. If directory >> entries are not >> present in the jar, stripped paths generated during the >> merge and used >> by the index will return jars which may not contain entries >> for them, >> triggering the exception. >> When all directory entries are present, if a jar contains an >> entry for >> "xxx/yyy/resource.file", it will contain entries for "xxx", >> "xxx/yyy" >> and "xxx/yyy/resource.file". >> >> >> Best, >> Diego >> >> >> On Wed, Jun 13, 2012 at 12:05 PM, Chris Hegarty >> >> > >> > >> >>> >> wrote: >> >> Hi Diego, >> >> Thanks for picking up this bug. >> >> I think your changes look fine. Mainly cleanup except >> for add -> >> addExplicit/addMapping in merge, right? BTW the cleanup >> makes this >> more readable. >> >> Unfortunately, the tests you created require checking in >> a binary >> jar file. This is a real no no for the OpenJDK, we >> really need to >> create these jars on the fly. I did similar for >> test/sun/misc/JarIndex/____**metaInfFilenames/, but I >> >> really wish I >> >> generated the source files for these tests rather than >> checking in >> so many pointless files. >> >> I can look at helping with writing suitable tests for this. >> >> >> > That's because I was using jars containing "directory >> entries" >> > (I was unaware that jar files may not include them) >> >> Strangely I added the comment "Remove directories from >> jar files >> being indexed." to the workaround section of the bug. >> You seem to be >> seeing the opposite, right? >> >> -Chris. >> >> >> >> On 13/06/2012 06:11, Diego Belfer wrote: >> >> Hi, >> >> I have finally reproduced the >> InvalidJarIndexException bug as >> reported in >> the ticket. I mentioned in a previous email, that >> the only way >> I'd found >> for getting the error was to use an invalid index file >> (INDEX.LIST), which >> did not have any sense. That's because I was using >> jars containing >> "directory entries" (I was unaware that jar files may not >> include them) >> >> After reviewing the URLClasspath$JarLoader class and >> the >> validIndex method, >> I notice it is possible to get the exception for a >> Jar file >> which does not >> include directory entries. In order to trigger the >> issue, the >> Jar must be >> referenced by an intermediary INDEX.LIST and the >> intermediary >> Jar index >> should have been merged to its parent index. >> Although, jar tool >> includes >> directory entries in the generated jar files, >> Eclipse default >> option for >> exporting jars does not include them (AFAIK), so >> this might be >> quite common. >> >> I have created a new PATCH which includes an >> additional test >> case which >> uses the URLClassLoader to trigger the >> InvalidIndexException. >> >> The patch is attached, please consider it for review. >> >> Best, >> Diego Belfer [muralx] >> >> >> >> On Mon, Jun 11, 2012 at 4:47 PM, Diego >> Belfer >> >> wrote: >> >> >> >> Hi, >> >> Here is a patch that fixes the merge method of >> the JarIndex. >> This bug was >> reported as the cause of the bug 6901992. >> Although, I was >> not able to >> reproduce the BUG itself >> (InvalidJarIndexException), I did >> verified that >> the method had a bug, and resources/classes >> where not found >> in a jarIndex >> with merged contents. >> >> If you think it is possible to commit this fix >> without actually >> reproducing the original bug report, please >> consider this >> patch for review. >> >> Thanks, >> Diego Belfer [muralx] >> >> >> >> >> >> -------------- next part -------------- # HG changeset patch # User muralx # Date 1339820030 10800 # Node ID 7b531b09855a099fe0e9ea06ed7f77772cb62ed0 # Parent fc575c78f5d314fd8ccbdc86c8b2d7631d736960 [PATCH] 6901992 - Possible InvalidJarIndexException due to bug in sun.misc.JarIndex.merge() diff --git a/.hgignore b/.hgignore --- a/.hgignore +++ b/.hgignore @@ -5,3 +5,4 @@ ^make/netbeans/.*/dist/ ^.hgtip .DS_Store +\.class$ diff --git a/src/share/classes/sun/misc/JarIndex.java b/src/share/classes/sun/misc/JarIndex.java --- a/src/share/classes/sun/misc/JarIndex.java +++ b/src/share/classes/sun/misc/JarIndex.java @@ -201,23 +201,20 @@ packageName = fileName; } - // add the mapping to indexMap - addToList(packageName, jarName, indexMap); - - // add the mapping to jarMap - addToList(jarName, packageName, jarMap); + addMapping(packageName, jarName); } /** * Same as add(String,String) except that it doesn't strip off from the - * last index of '/'. It just adds the filename. + * last index of '/'. It just adds the jarItem (filename or package) + * as it is received. */ - private void addExplicit(String fileName, String jarName) { + private void addMapping(String jarItem, String jarName) { // add the mapping to indexMap - addToList(fileName, jarName, indexMap); + addToList(jarItem, jarName, indexMap); // add the mapping to jarMap - addToList(jarName, fileName, jarMap); + addToList(jarName, jarItem, jarMap); } /** @@ -248,18 +245,14 @@ fileName.equals(JarFile.MANIFEST_NAME)) continue; - if (!metaInfFilenames) { + if (!metaInfFilenames || !fileName.startsWith("META-INF/")) { add(fileName, currentJar); - } else { - if (!fileName.startsWith("META-INF/")) { - add(fileName, currentJar); - } else if (!entry.isDirectory()) { + } else if (!entry.isDirectory()) { // Add files under META-INF explicitly so that certain // services, like ServiceLoader, etc, can be located // with greater accuracy. Directories can be skipped // since each file will be added explicitly. - addExplicit(fileName, currentJar); - } + addMapping(fileName, currentJar); } } @@ -324,8 +317,7 @@ jars.add(currentJar); } else { String name = line; - addToList(name, currentJar, indexMap); - addToList(currentJar, name, jarMap); + addMapping(name, currentJar); } } @@ -354,7 +346,7 @@ if (path != null) { jarName = path.concat(jarName); } - toIndex.add(packageName, jarName); + toIndex.addMapping(packageName, jarName); } } } diff --git a/test/sun/misc/JarIndex/JarIndexMergeForClassLoaderTest.java b/test/sun/misc/JarIndex/JarIndexMergeForClassLoaderTest.java new file mode 100644 --- /dev/null +++ b/test/sun/misc/JarIndex/JarIndexMergeForClassLoaderTest.java @@ -0,0 +1,224 @@ +/* + * Copyright (c) 2012, Oracle and/or its affiliates. All rights reserved. + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. + * + * This code is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License version 2 only, as + * published by the Free Software Foundation. + * + * This code is distributed in the hope that it will be useful, but WITHOUT + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License + * version 2 for more details (a copy is included in the LICENSE file that + * accompanied this code). + * + * You should have received a copy of the GNU General Public License version + * 2 along with this work; if not, write to the Free Software Foundation, + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. + * + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA + * or visit www.oracle.com if you need additional information or have any + * questions. + */ + +/* + * @test + * @bug 6901992 + * @summary Possible InvalidJarIndexException due to bug in sun.misc.JarIndex.merge() + * Test URLClassLoader usage of the merge method when using indexes + * @author Diego Belfer + */ +import java.io.BufferedReader; +import java.io.File; +import java.io.FileNotFoundException; +import java.io.FileOutputStream; +import java.io.IOException; +import java.io.InputStream; +import java.io.InputStreamReader; +import java.net.URL; +import java.net.URLClassLoader; +import java.util.jar.JarEntry; +import java.util.jar.JarOutputStream; + + +public class JarIndexMergeForClassLoaderTest { + static String slash = File.separator; + static String testClasses = System.getProperty("test.classes"); + static String testClassesDir = testClasses != null ? testClasses : "."; + static String jar; + static boolean debug = true; + static File tmpFolder = new File(testClassesDir); + + static { + String javaHome = System.getProperty("java.home"); + if (javaHome.endsWith("jre")) { + int index = javaHome.lastIndexOf(slash); + if (index != -1) + javaHome = javaHome.substring(0, index); + } + + jar = javaHome + slash + "bin" + slash + "jar"; + } + + public static void main(String[] args) throws Exception { + // Create the jars file + File jar1 = buildJar1(); + File jar2 = buildJar2(); + File jar3 = buildJar3(); + + // Index jar files in two levels: jar1 -> jar2 -> jar3 + createIndex(jar2.getName(), jar3.getName()); + createIndex(jar1.getName(), jar2.getName()); + + // Get root jar of the URLClassLoader + URL url = jar1.toURI().toURL(); + + URLClassLoader classLoader = new URLClassLoader(new URL[] { url }); + + assertResource(classLoader, "com/jar1/resource.file", "jar1"); + assertResource(classLoader, "com/test/resource1.file", "resource1"); + assertResource(classLoader, "com/jar2/resource.file", "jar2"); + assertResource(classLoader, "com/test/resource2.file", "resource2"); + assertResource(classLoader, "com/test/resource3.file", "resource3"); + + /* + * The following two asserts failed before the fix of the bug 6901992 + */ + // Check that an existing file is found using the merged index + assertResource(classLoader, "com/missing/jar3/resource.file", "jar3"); + // Check that a non existent file in directory which does not contain + // any file is not found and it does not throw InvalidJarIndexException + assertResource(classLoader, "com/missing/nofile", null); + } + + private static File buildJar3() throws FileNotFoundException, IOException { + JarBuilder jar3Builder = new JarBuilder(tmpFolder, "jar3.jar"); + jar3Builder.addResourceFile("com/test/resource3.file", "resource3"); + jar3Builder.addResourceFile("com/missing/jar3/resource.file", "jar3"); + return jar3Builder.build(); + } + + private static File buildJar2() throws FileNotFoundException, IOException { + JarBuilder jar2Builder = new JarBuilder(tmpFolder, "jar2.jar"); + jar2Builder.addResourceFile("com/jar2/resource.file", "jar2"); + jar2Builder.addResourceFile("com/test/resource2.file", "resource2"); + return jar2Builder.build(); + } + + private static File buildJar1() throws FileNotFoundException, IOException { + JarBuilder jar1Builder = new JarBuilder(tmpFolder, "jar1.jar"); + jar1Builder.addResourceFile("com/jar1/resource.file", "jar1"); + jar1Builder.addResourceFile("com/test/resource1.file", "resource1"); + return jar1Builder.build(); + } + + /* create the index */ + static void createIndex(String parentJar, String childJar) { + // ProcessBuilder is used so that the current directory can be set + // to the directory that directly contains the jars. + debug("Running jar to create the index for: " + parentJar + " and " + + childJar); + ProcessBuilder pb = new ProcessBuilder(jar, "-i", parentJar, childJar); + + pb.directory(tmpFolder); + // pd.inheritIO(); + try { + Process p = pb.start(); + if (p.waitFor() != 0) + throw new RuntimeException("jar indexing failed"); + + if (debug && p != null) { + debugStream(p.getInputStream()); + debugStream(p.getErrorStream()); + } + } catch (InterruptedException ie) { + throw new RuntimeException(ie); + } catch (IOException e) { + throw new RuntimeException(e); + } + } + + private static void debugStream(InputStream is) throws IOException { + BufferedReader reader = new BufferedReader(new InputStreamReader(is)); + String line; + while ((line = reader.readLine()) != null) { + debug(line); + } + reader.close(); + } + + private static void assertResource(URLClassLoader classLoader, String file, + String expectedContent) throws IOException { + InputStream fileStream = classLoader.getResourceAsStream(file); + + if (fileStream == null && expectedContent == null) { + return; + } + if (fileStream == null && expectedContent != null) { + throw new RuntimeException( + buildMessage(file, expectedContent, null)); + } + try { + String actualContent = readAsString(fileStream); + + if (fileStream != null && expectedContent == null) { + throw new RuntimeException(buildMessage(file, null, + actualContent)); + } + if (!expectedContent.equals(actualContent)) { + throw new RuntimeException(buildMessage(file, expectedContent, + actualContent)); + } + } finally { + fileStream.close(); + } + } + + private static String buildMessage(String file, String expectedContent, + String actualContent) { + return "Expected: " + expectedContent + " for: " + file + " was: " + + actualContent; + } + + private static String readAsString(InputStream fileStream) + throws IOException { + byte[] buffer = new byte[1000]; + int count = fileStream.read(buffer); + return new String(buffer, 0, count, "ASCII"); + } + + static void debug(Object message) { + if (debug) { + System.out.println(message); + } + } + + + /* + * Helper class for building jar files + */ + public static class JarBuilder { + private JarOutputStream os; + private File jarFile; + + public JarBuilder(File tmpFolder, String jarName) + throws FileNotFoundException, IOException { + this.jarFile = new File(tmpFolder, jarName); + this.os = new JarOutputStream(new FileOutputStream(jarFile)); + } + + public void addResourceFile(String pathFromRoot, String content) + throws IOException { + JarEntry entry = new JarEntry(pathFromRoot); + os.putNextEntry(entry); + os.write(content.getBytes("ASCII")); + os.closeEntry(); + } + + public File build() throws IOException { + os.close(); + return jarFile; + } + } +} + diff --git a/test/sun/misc/JarIndex/JarIndexMergeTest.java b/test/sun/misc/JarIndex/JarIndexMergeTest.java new file mode 100644 --- /dev/null +++ b/test/sun/misc/JarIndex/JarIndexMergeTest.java @@ -0,0 +1,114 @@ +/* + * Copyright (c) 2012, Oracle and/or its affiliates. All rights reserved. + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. + * + * This code is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License version 2 only, as + * published by the Free Software Foundation. + * + * This code is distributed in the hope that it will be useful, but WITHOUT + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License + * version 2 for more details (a copy is included in the LICENSE file that + * accompanied this code). + * + * You should have received a copy of the GNU General Public License version + * 2 along with this work; if not, write to the Free Software Foundation, + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. + * + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA + * or visit www.oracle.com if you need additional information or have any + * questions. + */ + +/* + * @test + * @bug 6901992 + * @summary Possible InvalidJarIndexException due to bug in sun.misc.JarIndex.merge() + * @author Diego Belfer + */ + +import java.io.File; +import java.io.FileNotFoundException; +import java.io.FileOutputStream; +import java.io.IOException; +import java.util.LinkedList; +import java.util.jar.JarEntry; +import java.util.jar.JarOutputStream; + +import sun.misc.JarIndex; + +public class JarIndexMergeTest { + static String slash = File.separator; + static String testClasses = System.getProperty("test.classes"); + static String testClassesDir = testClasses != null ? testClasses : "."; + static File tmpFolder = new File(testClassesDir); + + public static void main(String[] args) throws Exception { + + File jar1 = buildJar1(); + File jar2 = buildJar2(); + + JarIndex jarIndex1 = new JarIndex(new String[] { jar1.getAbsolutePath() }); + JarIndex jarIndex2 = new JarIndex(new String[] { jar2.getAbsolutePath() }); + + jarIndex1.merge(jarIndex2, null); + + assertFileResolved(jarIndex2, "com/test1/resource1.file", + jar1.getAbsolutePath()); + assertFileResolved(jarIndex2, "com/test2/resource2.file", + jar2.getAbsolutePath()); + } + + static void assertFileResolved(JarIndex jarIndex2, String file, + String jarName) { + + LinkedList jarLists = jarIndex2.get(file); + if (jarLists == null || jarLists.size() == 0 + || !jarName.equals(jarLists.get(0))) { + throw new RuntimeException( + "Unexpected result: the merged index must resolve file: " + + file); + } + } + + private static File buildJar1() throws FileNotFoundException, IOException { + JarBuilder jar1Builder = new JarBuilder(tmpFolder, "jar1-merge.jar"); + jar1Builder.addResourceFile("com/test1/resource1.file", "resource1"); + return jar1Builder.build(); + } + + private static File buildJar2() throws FileNotFoundException, IOException { + JarBuilder jar2Builder = new JarBuilder(tmpFolder, "jar2-merge.jar"); + jar2Builder.addResourceFile("com/test2/resource2.file", "resource2"); + return jar2Builder.build(); + } + + /* + * Helper class for building jar files + */ + public static class JarBuilder { + private JarOutputStream os; + private File jarFile; + + public JarBuilder(File tmpFolder, String jarName) + throws FileNotFoundException, IOException { + this.jarFile = new File(tmpFolder, jarName); + this.os = new JarOutputStream(new FileOutputStream(jarFile)); + } + + public void addResourceFile(String pathFromRoot, String content) + throws IOException { + JarEntry entry = new JarEntry(pathFromRoot); + os.putNextEntry(entry); + os.write(content.getBytes("ASCII")); + os.closeEntry(); + } + + public File build() throws IOException { + os.close(); + return jarFile; + } + } +} + From wasserman.louis at gmail.com Sun Jun 17 18:31:57 2012 From: wasserman.louis at gmail.com (Louis Wasserman) Date: Sun, 17 Jun 2012 14:31:57 -0400 Subject: Float.parseFloat rounding bug Message-ID: Hello, I had a patch for this Sun bug , and was hoping it could get reviewed. The simplest failing test case is probably public class Foo { public static void main(String[] args) { System.out.println(144115196665790480f <= 144115196665790481f); } } which quite surprisingly prints false. What can I do to make this happen? (I'm interested because once Float.parseFloat is correct, this improvement to BigInteger.floatValue() and doubleValue()will pass tests, whereas right now the tests expect the *wrong* behavior.) Louis Wasserman wasserman.louis at gmail.com http://profiles.google.com/wasserman.louis From lana.steuck at oracle.com Mon Jun 18 06:38:48 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Mon, 18 Jun 2012 06:38:48 +0000 Subject: hg: jdk8/tl: 8 new changesets Message-ID: <20120618063849.546B147997@hg.openjdk.java.net> Changeset: dac58047c19f Author: cl Date: 2012-06-07 12:10 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/dac58047c19f Added tag jdk8-b42 for changeset 1ce5dc164166 ! .hgtags Changeset: 6aea9b1a3840 Author: lana Date: 2012-06-08 12:01 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/6aea9b1a3840 Merge Changeset: efd26e051e50 Author: erikj Date: 2012-06-07 20:25 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/efd26e051e50 7170079: Adjustments to build-infra makefiles Reviewed-by: ohair, ohrstrom, ihse, jonas Contributed-by: jonas , erikj , ihse , tgranat , ykantser ! README-builds.html ! common/autoconf/autogen.sh ! common/autoconf/builddeps.m4 ! common/autoconf/configure ! common/autoconf/configure.ac ! common/autoconf/help.m4 ! common/autoconf/platform.m4 ! common/autoconf/spec.gmk.in ! common/bin/compareimage.sh ! common/bin/diffexec.sh ! common/bin/diffjarzip.sh ! common/bin/difflib.sh ! common/bin/logger.sh ! common/makefiles/JavaCompilation.gmk ! common/makefiles/MakeBase.gmk ! common/makefiles/Makefile ! common/makefiles/NativeCompilation.gmk Changeset: dd596160b323 Author: ohair Date: 2012-06-08 17:25 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/dd596160b323 7170091: Fix missing wait between repo cloning in hgforest.sh Reviewed-by: strarup ! make/scripts/hgforest.sh Changeset: c61921f9b965 Author: ohair Date: 2012-06-08 17:28 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/c61921f9b965 Merge Changeset: 661c9aae602b Author: katleman Date: 2012-06-13 16:53 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/661c9aae602b Merge Changeset: 02c6c67c1bb7 Author: katleman Date: 2012-06-14 13:13 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/02c6c67c1bb7 Added tag jdk8-b43 for changeset 661c9aae602b ! .hgtags Changeset: 67e1fb3b2b33 Author: lana Date: 2012-06-17 21:27 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/67e1fb3b2b33 Merge From lana.steuck at oracle.com Mon Jun 18 06:38:48 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Mon, 18 Jun 2012 06:38:48 +0000 Subject: hg: jdk8/tl/corba: 5 new changesets Message-ID: <20120618063856.1480747998@hg.openjdk.java.net> Changeset: 4def0723b0b0 Author: cl Date: 2012-06-07 12:10 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/4def0723b0b0 Added tag jdk8-b42 for changeset 79cc42c9c71b ! .hgtags Changeset: 0c0b50c7b76a Author: erikj Date: 2012-06-07 20:30 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/0c0b50c7b76a 7170079: Adjustments to build-infra makefiles Reviewed-by: ohair, ohrstrom, ihse, jonas Contributed-by: jonas , erikj , ihse , tgranat , ykantser ! makefiles/Makefile Changeset: a1f721fbe5d0 Author: ohair Date: 2012-06-13 09:43 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/a1f721fbe5d0 7176691: prtconf: devinfo facility not available in corba building Reviewed-by: tbell ! make/common/shared/Platform.gmk Changeset: cd879aff5d3c Author: katleman Date: 2012-06-13 16:53 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/cd879aff5d3c Merge Changeset: 439d9bf8e4ff Author: katleman Date: 2012-06-14 13:14 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/439d9bf8e4ff Added tag jdk8-b43 for changeset cd879aff5d3c ! .hgtags From lana.steuck at oracle.com Mon Jun 18 06:38:48 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Mon, 18 Jun 2012 06:38:48 +0000 Subject: hg: jdk8/tl/jaxws: 4 new changesets Message-ID: <20120618063904.F1B6547999@hg.openjdk.java.net> Changeset: 35e0f6001816 Author: cl Date: 2012-06-07 12:10 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/35e0f6001816 Added tag jdk8-b42 for changeset 1f20f37818a9 ! .hgtags Changeset: 001351a98bd5 Author: erikj Date: 2012-06-07 20:30 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/001351a98bd5 7170079: Adjustments to build-infra makefiles Reviewed-by: ohair, ohrstrom, ihse, jonas Contributed-by: jonas , erikj , ihse , tgranat , ykantser ! makefiles/Makefile Changeset: f00c12994562 Author: katleman Date: 2012-06-13 16:53 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/f00c12994562 Merge Changeset: f6a417540ef1 Author: katleman Date: 2012-06-14 13:14 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/f6a417540ef1 Added tag jdk8-b43 for changeset f00c12994562 ! .hgtags From lana.steuck at oracle.com Mon Jun 18 06:38:48 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Mon, 18 Jun 2012 06:38:48 +0000 Subject: hg: jdk8/tl/langtools: 6 new changesets Message-ID: <20120618063911.B47954799A@hg.openjdk.java.net> Changeset: 8280c4f9f619 Author: cl Date: 2012-06-07 12:10 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/8280c4f9f619 Added tag jdk8-b42 for changeset 02c5a3575539 ! .hgtags Changeset: e3d0a8fe4318 Author: lana Date: 2012-06-08 12:45 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/e3d0a8fe4318 Merge - test/tools/javac/diags/examples/FullInstSig.java - test/tools/javac/diags/examples/InvalidInferredTypes.java - test/tools/javac/diags/examples/UndeterminedType1.java Changeset: ac29cc95b5c5 Author: erikj Date: 2012-06-07 20:30 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/ac29cc95b5c5 7170079: Adjustments to build-infra makefiles Reviewed-by: ohair, ohrstrom, ihse, jonas Contributed-by: jonas , erikj , ihse , tgranat , ykantser ! makefiles/Makefile Changeset: f8c64d835b28 Author: katleman Date: 2012-06-13 16:58 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/f8c64d835b28 Merge Changeset: 59cbead12ff4 Author: katleman Date: 2012-06-14 13:14 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/59cbead12ff4 Added tag jdk8-b43 for changeset f8c64d835b28 ! .hgtags Changeset: e534aa747b22 Author: lana Date: 2012-06-17 21:37 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/e534aa747b22 Merge From lana.steuck at oracle.com Mon Jun 18 06:38:48 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Mon, 18 Jun 2012 06:38:48 +0000 Subject: hg: jdk8/tl/jaxp: 6 new changesets Message-ID: <20120618063913.A63274799B@hg.openjdk.java.net> Changeset: c73aaf2b0d14 Author: cl Date: 2012-06-07 12:10 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/c73aaf2b0d14 Added tag jdk8-b42 for changeset 39ee03c16021 ! .hgtags Changeset: b94fad1cb830 Author: lana Date: 2012-06-08 12:01 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/b94fad1cb830 Merge Changeset: 83a38059327b Author: erikj Date: 2012-06-07 20:30 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/83a38059327b 7170079: Adjustments to build-infra makefiles Reviewed-by: ohair, ohrstrom, ihse, jonas Contributed-by: jonas , erikj , ihse , tgranat , ykantser ! makefiles/Makefile Changeset: eff4ece9c8bc Author: katleman Date: 2012-06-13 16:53 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/eff4ece9c8bc Merge Changeset: 0b3f3a4ce139 Author: katleman Date: 2012-06-14 13:14 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/0b3f3a4ce139 Added tag jdk8-b43 for changeset eff4ece9c8bc ! .hgtags Changeset: a079926a6d81 Author: lana Date: 2012-06-17 21:29 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/a079926a6d81 Merge From lana.steuck at oracle.com Mon Jun 18 06:38:49 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Mon, 18 Jun 2012 06:38:49 +0000 Subject: hg: jdk8/tl/hotspot: 23 new changesets Message-ID: <20120618063946.92FD44799C@hg.openjdk.java.net> Changeset: c80d42d78a01 Author: amurillo Date: 2012-05-25 14:56 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c80d42d78a01 7171853: new hotspot build - hs24-b13 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 960a442eae91 Author: rbackman Date: 2012-05-22 10:11 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/960a442eae91 7161732: Improve handling of thread_id in OSThread Reviewed-by: dholmes, kamg ! src/os/bsd/vm/osThread_bsd.hpp ! src/os/linux/vm/osThread_linux.hpp ! src/os/solaris/vm/osThread_solaris.hpp ! src/os/windows/vm/osThread_windows.hpp ! src/os_cpu/bsd_x86/vm/vmStructs_bsd_x86.hpp ! src/os_cpu/linux_sparc/vm/vmStructs_linux_sparc.hpp ! src/os_cpu/linux_x86/vm/vmStructs_linux_x86.hpp ! src/os_cpu/solaris_sparc/vm/vmStructs_solaris_sparc.hpp ! src/os_cpu/solaris_x86/vm/vmStructs_solaris_x86.hpp ! src/os_cpu/windows_x86/vm/vmStructs_windows_x86.hpp ! src/share/vm/runtime/osThread.hpp Changeset: df84b4a3ebcb Author: rbackman Date: 2012-05-24 13:37 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/df84b4a3ebcb 7171422: Change 7161732 breaks SA on Windows Reviewed-by: dholmes, sla ! src/os_cpu/windows_x86/vm/vmStructs_windows_x86.hpp Changeset: 9c1709c4c80c Author: dcubed Date: 2012-05-24 12:03 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9c1709c4c80c 7165598: enable FDS on Solaris X64 when 7165593 is fixed Summary: Work around 'gobjcopy' failure on Solaris X64 by adding a temporary tool that removes the SHF_ALLOC flag from "empty" section headers. Reviewed-by: sspitsyn, acorn ! make/solaris/makefiles/defs.make ! make/solaris/makefiles/dtrace.make + make/solaris/makefiles/fix_empty_sec_hdr_flags.make ! make/solaris/makefiles/jsig.make ! make/solaris/makefiles/saproc.make ! make/solaris/makefiles/vm.make + src/os/solaris/fix_empty_sec_hdr_flags/fix_empty_sec_hdr_flags.c Changeset: fb8f9ab27c14 Author: dcubed Date: 2012-05-24 12:57 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/fb8f9ab27c14 Merge ! make/solaris/makefiles/defs.make ! make/solaris/makefiles/vm.make ! make/windows/makefiles/defs.make Changeset: cd3a8ab0352b Author: zgu Date: 2012-05-24 20:04 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/cd3a8ab0352b Merge Changeset: 17be2328b50b Author: zgu Date: 2012-05-26 06:07 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/17be2328b50b Merge Changeset: 5be76dc5304d Author: zgu Date: 2012-05-29 20:06 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5be76dc5304d Merge Changeset: 71afdabfd05b Author: jiangli Date: 2012-05-21 14:10 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/71afdabfd05b 7168280: Eliminate the generic signature index slot from field array for field without generic signature. Summary: Only allocate the generic signature index slot in the field array for field with generic signature attribute. Reviewed-by: coleenp, dlong ! agent/src/share/classes/sun/jvm/hotspot/oops/AccessFlags.java ! agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/ClassConstants.java ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/oops/fieldInfo.hpp ! src/share/vm/oops/fieldStreams.hpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/runtime/fieldDescriptor.cpp ! src/share/vm/runtime/fieldDescriptor.hpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/utilities/accessFlags.hpp Changeset: 48df98e03639 Author: dholmes Date: 2012-05-23 20:09 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/48df98e03639 7170197: Update JPRT default build targets to support embedded builds Reviewed-by: jcoomes, kvn ! make/jprt.properties Changeset: 4e64a590066e Author: jprovino Date: 2012-05-26 08:49 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4e64a590066e Merge Changeset: dd45f26b4282 Author: dholmes Date: 2012-05-30 17:45 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/dd45f26b4282 Merge Changeset: c92a79900986 Author: brutisso Date: 2012-05-17 21:53 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c92a79900986 7169062: CMS: Assertion failed with -XX:+ObjectAlignmentInBytes=64 Summary: Removed the assert in CompactibleFreeListSpace::check_free_list_consistency() since it was too strict. Simplified CompactibleFreeListSpace::set_cms_values() to reducde the need for asserts. Reviewed-by: jcoomes, stefank ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp Changeset: 9a344d88dc22 Author: mnunez Date: 2012-05-21 14:59 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9a344d88dc22 7168848: Add test to check that humongous object allocation path also checks the heap occupancy. Summary: Added test that checks humongous object allocation path also check the heap occupancy and initiate a marking cycle when / if needed. Reviewed-by: brutisso, jwilhelm + test/gc/7168848/HumongousAlloc.java Changeset: 1d478c993020 Author: johnc Date: 2012-05-29 10:18 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1d478c993020 7143858: G1: Back to back young GCs with the second GC having a minimally sized eden Summary: Before the last thread to leave a JNI critical region was able to schedule a GCLocker Initiated GC, another thread was attempting an allocation and saw that the GCLocker region was no longer active and successfully scheduled a GC. Stall allocating threads until the GCLocker Initiated GC is performed and then retry the allocation. Reviewed-by: brutisso, huntch ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp Changeset: 5c8bd7c16119 Author: brutisso Date: 2012-05-25 22:35 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5c8bd7c16119 7171936: LOG_G incorrectly defined in globalDefinitions.hpp Summary: Removed LOG_G and LOG_K. Moved LOG_M to where it is being used. Reviewed-by: twisti, johnc ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp ! src/share/vm/utilities/globalDefinitions.hpp Changeset: c52a6a39546c Author: johnc Date: 2012-05-30 10:26 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c52a6a39546c 7158682: G1: Handle leak when running nsk.sysdict tests Summary: Place HandleMarks in the code that allocates handles for the pending list lock so that the handles are freed and multiple, unsuccessful, attempts to schedule a GC do not cause an OOM. Reviewed-by: brutisso ! src/share/vm/oops/instanceRefKlass.cpp Changeset: bbc900c2482a Author: brutisso Date: 2012-05-31 21:10 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/bbc900c2482a 7172279: G1: Clean up TraceGen0Time and TraceGen1Time data gathering Summary: Simplify code, remove unused code, remove ExitAfterGCNum Reviewed-by: huntch, johnc ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/utilities/numberSeq.cpp ! src/share/vm/utilities/numberSeq.hpp Changeset: 7121cd2c58b5 Author: jcoomes Date: 2012-06-01 10:29 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7121cd2c58b5 Merge Changeset: bd568544be7f Author: amurillo Date: 2012-06-01 15:24 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/bd568544be7f Merge Changeset: 55954061c6e8 Author: amurillo Date: 2012-06-01 15:24 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/55954061c6e8 Added tag hs24-b13 for changeset bd568544be7f ! .hgtags Changeset: e77b8e0ed1f8 Author: cl Date: 2012-06-07 12:10 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e77b8e0ed1f8 Added tag jdk8-b42 for changeset 55954061c6e8 ! .hgtags Changeset: b38fb5f31e31 Author: katleman Date: 2012-06-14 13:14 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b38fb5f31e31 Added tag jdk8-b43 for changeset e77b8e0ed1f8 ! .hgtags From lana.steuck at oracle.com Mon Jun 18 06:40:45 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Mon, 18 Jun 2012 06:40:45 +0000 Subject: hg: jdk8/tl/jdk: 42 new changesets Message-ID: <20120618064815.9D8E2479A2@hg.openjdk.java.net> Changeset: 8e8fb6500a87 Author: cl Date: 2012-06-07 12:10 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8e8fb6500a87 Added tag jdk8-b42 for changeset cf5c1f6fbc5b ! .hgtags Changeset: a2d12ca36eb3 Author: bae Date: 2012-05-25 12:56 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a2d12ca36eb3 7146550: [macosx] DnD test failure in createCompatibleWritableRaster() Reviewed-by: kizune, serb ! src/macosx/classes/sun/lwawt/macosx/CDragSourceContextPeer.java ! src/macosx/classes/sun/lwawt/macosx/CImage.java ! src/macosx/native/sun/awt/CDragSource.h ! src/macosx/native/sun/awt/CDragSource.m ! src/macosx/native/sun/awt/CDragSourceContextPeer.m ! test/java/awt/dnd/ImageDecoratedDnDNegative/ImageDecoratedDnDNegative.java Changeset: 23b82fb671d4 Author: lana Date: 2012-05-25 19:34 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/23b82fb671d4 Merge Changeset: c892ca15ca52 Author: andrew Date: 2012-05-30 16:17 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c892ca15ca52 7171223: Building ExtensionSubtables.cpp should use -fno-strict-aliasing Summary: GCC 4.4+ have stricter aliasing requirements which produces a new warning from this code Reviewed-by: prr, ohair ! make/sun/font/Makefile Changeset: d988ed9d40bc Author: bae Date: 2012-05-31 12:15 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d988ed9d40bc 7120895: FontConfiguration should not use thread contextClassLoader Reviewed-by: igor, prr ! src/share/classes/sun/awt/FontConfiguration.java Changeset: baf734760bd6 Author: lana Date: 2012-06-05 17:56 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/baf734760bd6 Merge Changeset: c499fd3f1695 Author: erikj Date: 2012-06-07 18:05 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c499fd3f1695 7170969: Add @GenerateNativeHeader to classes whose fields need to be exported for JNI Reviewed-by: ohair, ohrstrom, ihse ! make/sun/awt/make.depend ! src/macosx/classes/apple/laf/JRSUIConstants.java ! src/macosx/classes/com/apple/eawt/FullScreenHandler.java ! src/macosx/classes/com/apple/eawt/event/GestureHandler.java ! src/macosx/classes/sun/java2d/OSXSurfaceData.java ! src/macosx/classes/sun/lwawt/LWLabelPeer.java ! src/macosx/classes/sun/lwawt/LWTextFieldPeer.java ! src/macosx/classes/sun/lwawt/macosx/CocoaConstants.java ! src/share/classes/java/awt/Adjustable.java ! src/share/classes/java/awt/BasicStroke.java ! src/share/classes/java/awt/Choice.java ! src/share/classes/java/awt/DisplayMode.java ! src/share/classes/java/awt/Image.java ! src/share/classes/java/awt/List.java ! src/share/classes/java/awt/PopupMenu.java ! src/share/classes/java/awt/SystemColor.java ! src/share/classes/java/awt/TextComponent.java ! src/share/classes/java/awt/Transparency.java ! src/share/classes/java/awt/color/ColorSpace.java ! src/share/classes/java/awt/color/ICC_Profile.java ! src/share/classes/java/awt/datatransfer/Clipboard.java ! src/share/classes/java/awt/datatransfer/StringSelection.java ! src/share/classes/java/awt/dnd/DnDConstants.java ! src/share/classes/java/awt/event/ActionEvent.java ! src/share/classes/java/awt/event/AdjustmentEvent.java ! src/share/classes/java/awt/event/ComponentEvent.java ! src/share/classes/java/awt/event/InputMethodEvent.java ! src/share/classes/java/awt/event/MouseWheelEvent.java ! src/share/classes/java/awt/geom/PathIterator.java ! src/share/classes/java/awt/image/AffineTransformOp.java ! src/share/classes/java/awt/image/ConvolveOp.java ! src/share/classes/java/awt/image/DataBuffer.java ! src/share/classes/java/awt/image/DirectColorModel.java ! src/share/classes/java/awt/image/ImageConsumer.java ! src/share/classes/java/awt/image/ImageObserver.java ! src/share/classes/java/awt/peer/ComponentPeer.java ! src/share/classes/java/awt/print/PageFormat.java ! src/share/classes/java/awt/print/Pageable.java ! src/share/classes/java/awt/print/Printable.java ! src/share/classes/sun/awt/CharsetString.java ! src/share/classes/sun/awt/EmbeddedFrame.java ! src/share/classes/sun/awt/SunHints.java ! src/share/classes/sun/awt/dnd/SunDragSourceContextPeer.java ! src/share/classes/sun/awt/image/BufImgSurfaceData.java ! src/share/classes/sun/java2d/SunGraphics2D.java ! src/share/classes/sun/java2d/opengl/OGLBlitLoops.java ! src/share/classes/sun/java2d/opengl/OGLContext.java ! src/share/classes/sun/java2d/pipe/BufferedContext.java ! src/share/classes/sun/java2d/pipe/BufferedOpCodes.java ! src/share/classes/sun/java2d/pipe/BufferedPaints.java ! src/share/classes/sun/java2d/pipe/BufferedTextPipe.java ! src/share/classes/sun/java2d/pipe/RegionIterator.java ! src/share/classes/sun/java2d/pipe/RenderBuffer.java ! src/share/classes/sun/java2d/pipe/hw/AccelDeviceEventNotifier.java ! src/share/classes/sun/java2d/pipe/hw/AccelSurface.java ! src/share/classes/sun/java2d/pipe/hw/ContextCapabilities.java ! src/share/classes/sun/nio/ch/DatagramChannelImpl.java ! src/share/classes/sun/nio/ch/IOStatus.java ! src/share/classes/sun/security/pkcs11/Secmod.java ! src/share/classes/sun/security/pkcs11/wrapper/PKCS11.java ! src/solaris/classes/sun/awt/X11/XComponentPeer.java ! src/windows/classes/sun/java2d/d3d/D3DBlitLoops.java ! src/windows/classes/sun/java2d/d3d/D3DContext.java ! src/windows/classes/sun/java2d/d3d/D3DPaints.java ! src/windows/native/java/net/TwoStacksPlainSocketImpl.c ! src/windows/native/sun/windows/awt_DataTransferer.cpp ! src/windows/native/sun/windows/awt_MenuItem.h Changeset: 563582096868 Author: ohair Date: 2012-06-07 18:08 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/563582096868 Merge - src/macosx/bin/amd64/jvm.cfg ! src/macosx/classes/sun/lwawt/LWTextFieldPeer.java ! src/share/classes/sun/nio/ch/DatagramChannelImpl.java - src/share/classes/sun/security/action/LoadLibraryAction.java - test/tools/pack200/dyn.jar - test/tools/pack200/pack200-verifier/src/xmlkit/ClassSyntax.java - test/tools/pack200/pack200-verifier/src/xmlkit/ClassWriter.java - test/tools/pack200/pack200-verifier/src/xmlkit/InstructionAssembler.java - test/tools/pack200/pack200-verifier/src/xmlkit/InstructionSyntax.java Changeset: 992068b99493 Author: lana Date: 2012-06-08 11:58 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/992068b99493 Merge Changeset: 5ff4693406ad Author: dcherepanov Date: 2012-05-22 12:35 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5ff4693406ad 7160293: [macosx] FileDialog appears on secondary display Reviewed-by: art, bae ! src/macosx/classes/sun/awt/CGraphicsEnvironment.java ! src/macosx/classes/sun/lwawt/LWWindowPeer.java ! src/macosx/classes/sun/lwawt/PlatformWindow.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformEmbeddedFrame.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java ! src/macosx/native/sun/awt/AWTWindow.m Changeset: cac4daf60283 Author: zhouyx Date: 2012-05-23 12:37 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cac4daf60283 7170996: IME composition window does not disappear when file dialog is closed : Japanese WinXP Reviewed-by: art, bagiras ! src/windows/native/sun/windows/awt_Component.cpp Changeset: bb3ada9822e4 Author: kizune Date: 2012-05-24 15:11 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bb3ada9822e4 7144064: [macosx] "Could not find class" error in JTree's ctor when called in headless mode Reviewed-by: art, leonidr ! src/solaris/native/java/lang/java_props_md.c Changeset: cd00d68e06ac Author: neugens Date: 2012-05-25 14:16 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cd00d68e06ac 6800513: GTK-LaF renders menus incompletely Reviewed-by: rupashka ! src/share/classes/javax/swing/JPopupMenu.java Changeset: 4b2b963f8774 Author: ant Date: 2012-05-25 20:57 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4b2b963f8774 7171776: one more setGlobalCurrentFocusCycleRoot call requires doPrivileged Reviewed-by: art ! src/share/classes/java/awt/KeyboardFocusManager.java Changeset: bcdb6e5f31cc Author: lana Date: 2012-05-25 13:39 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bcdb6e5f31cc Merge Changeset: 3c9adc88956d Author: luchsh Date: 2012-05-30 10:58 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3c9adc88956d 7170655: Frame size does not follow font size change with XToolkit Reviewed-by: serb, art ! src/solaris/classes/sun/awt/X11/XLabelPeer.java + test/java/awt/Frame/ResizeAfterSetFont/ResizeAfterSetFont.java Changeset: 14f9e9060370 Author: alexsch Date: 2012-05-30 14:46 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/14f9e9060370 7146131: [macosx] When click the show optionpane button,it display partly of dialog and hung until timeout Reviewed-by: rupashka ! src/macosx/classes/com/apple/laf/AquaInternalFrameUI.java Changeset: e6de02da6870 Author: alexsch Date: 2012-05-30 14:58 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e6de02da6870 7141296: [macosx] Mouse Wheel Turn closes combobox popup Reviewed-by: rupashka ! src/macosx/classes/com/apple/laf/AquaScrollPaneUI.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformResponder.java Changeset: 8800a98316b2 Author: neugens Date: 2012-05-30 18:15 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8800a98316b2 7171806: Missing test for bug ID 6800513 fix Reviewed-by: rupashka + test/javax/swing/JPopupMenu/6800513/bug6800513.java Changeset: 06a0302856eb Author: leonidr Date: 2012-05-31 20:18 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/06a0302856eb 7150089: [macosx] Default for a custom cursor created from non-existent image is not transparent Reviewed-by: anthony, kizune ! src/macosx/classes/sun/lwawt/macosx/CCustomCursor.java Changeset: fd27852f3ea5 Author: denis Date: 2012-06-01 17:08 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fd27852f3ea5 7112115: Component.getLocationOnScreen() work incorrectly if create window in point (0, 0) on oel Reviewed-by: serb, art + test/javax/swing/JSpinner/5012888/bug5012888.java Changeset: 0526ba7f723b Author: alexsch Date: 2012-06-04 14:11 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0526ba7f723b 7161766: [macosx] javax/swing/JPopupMenu/6694823/bug6694823.java failed on Mac OS X Reviewed-by: rupashka ! test/javax/swing/JPopupMenu/6694823/bug6694823.java Changeset: 79df0a4a6573 Author: omajid Date: 2012-06-04 16:39 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/79df0a4a6573 7043963: AWT workaround missing for Mutter. Reviewed-by: art, anthony Contributed-by: Denis Lila ! src/solaris/classes/sun/awt/X11/XDecoratedPeer.java ! src/solaris/classes/sun/awt/X11/XWM.java + test/java/awt/WMSpecificTests/Mutter/MutterMaximizeTest.java ! test/java/awt/regtesthelpers/Util.java Changeset: fc64530a1571 Author: anthony Date: 2012-06-05 15:20 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fc64530a1571 7172722: Latest jdk7u from OSX broke universal build Summary: Add a data memeber for a new property Reviewed-by: serb, swingler ! src/macosx/native/sun/awt/AWTWindow.h Changeset: 5880da7a3628 Author: dcherepanov Date: 2012-06-05 19:48 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5880da7a3628 7123957: Switch of Gnome theme ends up deadlocked in GTKEngine.native_switch_theme Reviewed-by: art, anthony ! src/solaris/native/sun/awt/swing_GTKEngine.c Changeset: 8c6fef8404ea Author: lana Date: 2012-06-05 18:05 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8c6fef8404ea Merge Changeset: c6075e29ce94 Author: alexsch Date: 2012-06-06 11:54 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c6075e29ce94 7169285: [macosx] Test api/javax_swing/JPopupMenu/descriptions.html#setgetXXX doesn't take Mac main menu Reviewed-by: rupashka ! src/share/classes/javax/swing/JPopupMenu.java Changeset: 6694d9e99716 Author: littlee Date: 2012-06-07 10:22 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6694d9e99716 7174233: Openjdk is missing some key maps on the Japanese keyboards Reviewed-by: anthony, naoto ! src/solaris/classes/sun/awt/X11/XKeysym.java ! src/solaris/native/sun/xawt/XWindow.c Changeset: 77c92e809c25 Author: alexsch Date: 2012-06-07 18:24 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/77c92e809c25 7152952: [macosx] List rows overlap with enlarged font Reviewed-by: art, rupashka ! src/macosx/classes/sun/lwawt/LWListPeer.java Changeset: f1063002c843 Author: kizune Date: 2012-06-07 20:04 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f1063002c843 7124247: [macosx] Implement GraphicsDevice.setDisplayMode() Reviewed-by: anthony, swingler ! src/macosx/classes/sun/awt/CGraphicsDevice.java ! src/macosx/native/sun/awt/CGraphicsDevice.m Changeset: 05ac5622a2ec Author: kizune Date: 2012-06-07 20:06 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/05ac5622a2ec Merge Changeset: 4acd0211f48b Author: rupashka Date: 2012-06-07 21:49 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4acd0211f48b 7156657: Version 7 doesn't support translucent popup menus against a translucent window Reviewed-by: art, alexsch ! src/share/classes/javax/swing/PopupFactory.java ! src/share/demo/jfc/TransparentRuler/transparentruler/Ruler.java + test/javax/swing/JPopupMenu/7156657/bug7156657.java Changeset: a1d825c477bc Author: alexsch Date: 2012-06-08 14:15 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a1d825c477bc 7092551: Double-click in TextField sets caret to the beginning Reviewed-by: bagiras, serb ! src/windows/native/sun/windows/awt_TextArea.cpp ! src/windows/native/sun/windows/awt_TextArea.h ! src/windows/native/sun/windows/awt_TextComponent.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 Changeset: 34ac493d6bea Author: kizune Date: 2012-06-08 22:21 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/34ac493d6bea 7175566: [macosx] Glich in fix for CR7124247 caused MacOS crash during PIT testing Reviewed-by: anthony, dcherepanov ! src/macosx/native/sun/awt/CGraphicsDevice.m Changeset: 3d7be3ac3a99 Author: lana Date: 2012-06-08 12:00 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3d7be3ac3a99 Merge Changeset: cd195e5d2c07 Author: lana Date: 2012-06-08 12:44 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cd195e5d2c07 Merge ! src/share/classes/sun/nio/ch/DatagramChannelImpl.java - src/share/classes/sun/nio/ch/DevPollSelectorProvider.java - src/share/classes/sun/security/provider/certpath/CrlRevocationChecker.java - src/share/classes/sun/security/provider/certpath/OCSPChecker.java - 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/native/java/sql/DriverManager.c - test/sun/security/krb5/auto/ok-as-delegate-xrealm.sh - test/sun/security/krb5/auto/ok-as-delegate.sh Changeset: 898ce0cf7476 Author: ohair Date: 2012-06-07 20:40 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/898ce0cf7476 Merge ! src/macosx/classes/sun/lwawt/LWTextFieldPeer.java ! src/share/classes/sun/nio/ch/DatagramChannelImpl.java Changeset: 1953cf522107 Author: erikj Date: 2012-06-07 20:40 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1953cf522107 7170079: Adjustments to build-infra makefiles Reviewed-by: ohair, ohrstrom, ihse, jonas Contributed-by: jonas , erikj , ihse , tgranat , ykantser ! makefiles/CompileDemos.gmk ! makefiles/CompileJavaClasses.gmk ! makefiles/CompileLaunchers.gmk ! makefiles/CompileNativeLibraries.gmk ! makefiles/CopyFiles.gmk ! makefiles/CopyIntoClasses.gmk ! makefiles/CopySamples.gmk + makefiles/CreateJars.gmk ! makefiles/GendataBreakIterator.gmk + makefiles/GendataFontConfig.gmk + makefiles/GendataHtml32dtd.gmk + makefiles/GendataTimeZone.gmk ! makefiles/GenerateClasses.gmk ! makefiles/GenerateData.gmk ! makefiles/GenerateJavaSources.gmk + makefiles/GensrcBuffer.gmk ! makefiles/GensrcCharacterData.gmk + makefiles/GensrcCharsetCoder.gmk + makefiles/GensrcCharsetMapping.gmk + makefiles/GensrcExceptions.gmk + makefiles/GensrcIcons.gmk ! makefiles/GensrcJDWP.gmk ! makefiles/GensrcLocaleDataMetaInfo.gmk ! makefiles/GensrcMisc.gmk ! makefiles/GensrcProperties.gmk + makefiles/GensrcSwing.gmk + makefiles/GensrcX11Wrappers.gmk ! makefiles/Images.gmk ! makefiles/LegacyMakefiles.gmk ! makefiles/Makefile + makefiles/OldImages.gmk ! makefiles/Setup.gmk ! makefiles/Tools.gmk - makefiles/altclasses/Makefile - makefiles/apple/Makefile - makefiles/apple/applescript/Makefile - makefiles/com/Makefile - makefiles/com/apple/Makefile - makefiles/com/apple/osx/Makefile - makefiles/com/apple/osxui/Makefile - makefiles/com/oracle/Makefile - makefiles/com/oracle/jfr/Makefile - makefiles/com/oracle/security/ucrypto/FILES_c.gmk - makefiles/com/oracle/security/ucrypto/Makefile - makefiles/com/oracle/security/ucrypto/mapfile-vers - makefiles/com/sun/Makefile ! makefiles/common/Defs-macosx.gmk ! makefiles/common/Release-macosx.gmk ! makefiles/common/Release.gmk - makefiles/common/shared/Defs-utils.gmk ! makefiles/common/shared/Defs.gmk ! makefiles/docs/CORE_PKGS.gmk ! makefiles/java/Makefile - makefiles/java/fdlibm/FILES_c.gmk - makefiles/java/fdlibm/Makefile - makefiles/java/instrument/Makefile - makefiles/java/instrument/mapfile-vers - makefiles/java/java/Exportedfiles.gmk - makefiles/java/java/FILES_c.gmk - makefiles/java/java/FILES_java.gmk - makefiles/java/java/Makefile - makefiles/java/java/localelist.sh - makefiles/java/java/mapfile-vers - makefiles/java/java/reflect/Makefile - makefiles/java/java/reorder-i586 - makefiles/java/java/reorder-sparc - makefiles/java/java/reorder-sparcv9 - makefiles/java/java_crw_demo/Makefile - makefiles/java/java_crw_demo/mapfile-vers - makefiles/java/java_hprof_demo/Makefile - makefiles/java/java_hprof_demo/mapfile-vers - makefiles/java/jexec/Makefile - makefiles/java/jli/Makefile - makefiles/java/jli/mapfile-vers - makefiles/java/jobjc/Makefile - makefiles/java/jvm/Makefile - makefiles/java/main/Makefile - makefiles/java/main/java/Makefile - makefiles/java/main/java/mapfile-amd64 - makefiles/java/main/java/mapfile-i586 - makefiles/java/main/java/mapfile-sparc - makefiles/java/main/java/mapfile-sparcv9 - makefiles/java/main/javaw/Makefile - makefiles/java/management/Exportedfiles.gmk - makefiles/java/management/FILES_c.gmk - makefiles/java/management/Makefile - makefiles/java/management/mapfile-vers - makefiles/java/net/FILES_c.gmk - makefiles/java/net/Makefile - makefiles/java/net/mapfile-vers - makefiles/java/nio/Exportedfiles.gmk - makefiles/java/nio/FILES_c.gmk - makefiles/java/nio/FILES_java.gmk - makefiles/java/nio/Makefile - makefiles/java/nio/addNotices.sh - makefiles/java/nio/genBuffer.sh - makefiles/java/nio/genCharsetProvider.sh - makefiles/java/nio/genCoder.sh - makefiles/java/nio/genExceptions.sh - makefiles/java/nio/mapfile-bsd - makefiles/java/nio/mapfile-linux - makefiles/java/nio/mapfile-solaris - makefiles/java/nio/reorder-i586 - makefiles/java/nio/reorder-sparc - makefiles/java/nio/reorder-sparcv9 - makefiles/java/npt/Makefile - makefiles/java/npt/mapfile-vers ! makefiles/java/redist/Makefile - makefiles/java/redist/fonts/Makefile - makefiles/java/security/Makefile - makefiles/java/sun_nio/FILES_java.gmk - makefiles/java/sun_nio/Makefile - makefiles/java/util/FILES_java.gmk - makefiles/java/util/FILES_properties.gmk - makefiles/java/util/Makefile - makefiles/java/verify/Makefile - makefiles/java/verify/mapfile-vers - makefiles/java/verify/reorder-i586 - makefiles/java/verify/reorder-sparc - makefiles/java/verify/reorder-sparcv9 - makefiles/javax/Makefile - makefiles/javax/imageio/Makefile - makefiles/javax/management/Makefile - makefiles/javax/sound/FILES_c.gmk - makefiles/javax/sound/Makefile - makefiles/javax/sound/SoundDefs.gmk - makefiles/javax/sound/jsoundalsa/Makefile - makefiles/javax/sound/jsoundalsa/mapfile-vers - makefiles/javax/sound/jsoundds/Makefile - makefiles/javax/sound/mapfile-vers - makefiles/javax/sql/Makefile - makefiles/javax/swing/FILES.gmk - makefiles/javax/swing/Makefile - makefiles/javax/swing/beaninfo/FILES.gmk - makefiles/javax/swing/beaninfo/Makefile - makefiles/javax/swing/beaninfo/SwingBeans.gmk - makefiles/javax/swing/beaninfo/manifest - makefiles/javax/swing/html32dtd/Makefile - makefiles/javax/swing/plaf/FILES.gmk - makefiles/javax/swing/plaf/Makefile + makefiles/mapfiles/libawt/mapfile-mawt-vers + makefiles/mapfiles/libawt/mapfile-vers + makefiles/mapfiles/libawt/mapfile-vers-linux + makefiles/mapfiles/libawt_headless/mapfile-vers + makefiles/mapfiles/libawt_headless/reorder-i586 + makefiles/mapfiles/libawt_headless/reorder-sparc + makefiles/mapfiles/libawt_headless/reorder-sparcv9 + makefiles/mapfiles/libawt_xawt/mapfile-vers + makefiles/mapfiles/libdcpr/mapfile-vers + makefiles/mapfiles/libhprof/mapfile-vers + makefiles/mapfiles/libinstrument/mapfile-vers + makefiles/mapfiles/libj2gss/mapfile-vers + makefiles/mapfiles/libj2pcsc/mapfile-vers + makefiles/mapfiles/libj2pkcs11/mapfile-vers + makefiles/mapfiles/libj2ucrypto/mapfile-vers + makefiles/mapfiles/libjava/mapfile-vers + makefiles/mapfiles/libjava/reorder-i586 + makefiles/mapfiles/libjava/reorder-sparc + makefiles/mapfiles/libjava/reorder-sparcv9 + makefiles/mapfiles/libjava_crw_demo/mapfile-vers + makefiles/mapfiles/libjdga/mapfile-vers + makefiles/mapfiles/libjfr/mapfile-vers + makefiles/mapfiles/libjli/mapfile-vers ! makefiles/mapfiles/libjpeg/reorder-i586 ! makefiles/mapfiles/libjpeg/reorder-sparc ! makefiles/mapfiles/libjpeg/reorder-sparcv9 + makefiles/mapfiles/libjsound/mapfile-vers + makefiles/mapfiles/libjsoundalsa/mapfile-vers + makefiles/mapfiles/libkcms/mapfile-vers + makefiles/mapfiles/libmanagement/mapfile-vers + makefiles/mapfiles/libmlib_image/mapfile-vers + makefiles/mapfiles/libnet/mapfile-vers + makefiles/mapfiles/libnio/mapfile-bsd + makefiles/mapfiles/libnio/mapfile-linux + makefiles/mapfiles/libnio/mapfile-solaris + makefiles/mapfiles/libnio/reorder-i586 + makefiles/mapfiles/libnio/reorder-sparc + makefiles/mapfiles/libnio/reorder-sparcv9 + makefiles/mapfiles/libnpt/mapfile-vers + makefiles/mapfiles/libsplashscreen/mapfile-vers + makefiles/mapfiles/libsunec/mapfile-vers ! makefiles/mapfiles/libverify/reorder-i586 ! makefiles/mapfiles/libverify/reorder-sparc ! makefiles/mapfiles/libverify/reorder-sparcv9 ! makefiles/mapfiles/libzip/reorder-i586 ! makefiles/mapfiles/libzip/reorder-sparc ! makefiles/mapfiles/libzip/reorder-sparcv9 + makefiles/scripts/addNotices.sh + makefiles/scripts/genCharsetProvider.sh + makefiles/scripts/genExceptions.sh + makefiles/scripts/localelist.sh - makefiles/sun/Makefile - makefiles/sun/awt/CondenseRules.awk - makefiles/sun/awt/Depend.mak - makefiles/sun/awt/Depend.sed - makefiles/sun/awt/FILES_c_macosx.gmk - makefiles/sun/awt/FILES_c_unix.gmk - makefiles/sun/awt/FILES_c_windows.gmk - makefiles/sun/awt/FILES_export_macosx.gmk - makefiles/sun/awt/FILES_export_unix.gmk - makefiles/sun/awt/FILES_export_windows.gmk - makefiles/sun/awt/Makefile - makefiles/sun/awt/README - makefiles/sun/awt/make.depend - makefiles/sun/awt/mapfile-mawt-vers - makefiles/sun/awt/mapfile-vers - makefiles/sun/awt/mapfile-vers-linux - makefiles/sun/awt/mawt.gmk - makefiles/sun/cmm/Makefile - makefiles/sun/cmm/kcms/FILES_c_unix.gmk - makefiles/sun/cmm/kcms/FILES_c_windows.gmk - makefiles/sun/cmm/kcms/Makefile - makefiles/sun/cmm/kcms/mapfile-vers - makefiles/sun/dcpr/FILES_c.gmk - makefiles/sun/dcpr/Makefile - makefiles/sun/dcpr/mapfile-vers - makefiles/sun/headless/Makefile - makefiles/sun/headless/mapfile-vers - makefiles/sun/headless/reorder-i586 - makefiles/sun/headless/reorder-sparc - makefiles/sun/headless/reorder-sparcv9 - makefiles/sun/image/Makefile - makefiles/sun/image/generic/FILES_c.gmk - makefiles/sun/image/generic/Makefile - makefiles/sun/image/generic/mapfile-vers - makefiles/sun/image/vis/FILES_c.gmk - makefiles/sun/image/vis/Makefile - makefiles/sun/javazic/Makefile - makefiles/sun/jdbc/Makefile - makefiles/sun/jdga/Makefile - makefiles/sun/jdga/mapfile-vers - makefiles/sun/lwawt/FILES_c_macosx.gmk - makefiles/sun/lwawt/FILES_export_macosx.gmk - makefiles/sun/lwawt/Makefile - makefiles/sun/nio/Makefile - makefiles/sun/nio/cs/FILES_java.gmk - makefiles/sun/nio/cs/Makefile - makefiles/sun/org/Makefile - makefiles/sun/org/mozilla/Makefile - makefiles/sun/org/mozilla/javascript/Makefile - makefiles/sun/osxapp/Makefile - makefiles/sun/security/Makefile - makefiles/sun/security/ec/FILES_c.gmk - makefiles/sun/security/ec/mapfile-vers - makefiles/sun/security/jgss/Makefile - makefiles/sun/security/jgss/wrapper/FILES_c.gmk - makefiles/sun/security/jgss/wrapper/Makefile - makefiles/sun/security/jgss/wrapper/mapfile-vers - makefiles/sun/security/krb5/FILES_c_windows.gmk - makefiles/sun/security/krb5/Makefile - makefiles/sun/security/mscapi/FILES_cpp.gmk - makefiles/sun/security/mscapi/Makefile - makefiles/sun/security/other/Makefile - makefiles/sun/security/smartcardio/FILES_c.gmk - makefiles/sun/security/smartcardio/Makefile - makefiles/sun/security/smartcardio/mapfile-vers - makefiles/sun/security/tools/Makefile - makefiles/sun/security/util/Makefile - makefiles/sun/splashscreen/FILES_c.gmk - makefiles/sun/splashscreen/Makefile - makefiles/sun/splashscreen/mapfile-vers - makefiles/sun/xawt/FILES_c_unix.gmk - makefiles/sun/xawt/FILES_export_unix.gmk - makefiles/sun/xawt/Makefile - makefiles/sun/xawt/mapfile-vers Changeset: e00f450a3c5f Author: erikj Date: 2012-06-11 09:30 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e00f450a3c5f 7175966: Fix windows build issues for build-infra project Reviewed-by: ohair ! makefiles/CompileJavaClasses.gmk ! makefiles/java/redist/sajdi/Makefile Changeset: b3246687c369 Author: katleman Date: 2012-06-13 16:57 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b3246687c369 Merge - makefiles/altclasses/Makefile - makefiles/apple/Makefile - makefiles/apple/applescript/Makefile - makefiles/com/Makefile - makefiles/com/apple/Makefile - makefiles/com/apple/osx/Makefile - makefiles/com/apple/osxui/Makefile - makefiles/com/oracle/Makefile - makefiles/com/oracle/jfr/Makefile - makefiles/com/oracle/security/ucrypto/FILES_c.gmk - makefiles/com/oracle/security/ucrypto/Makefile - makefiles/com/oracle/security/ucrypto/mapfile-vers - makefiles/com/sun/Makefile - makefiles/common/shared/Defs-utils.gmk - makefiles/java/fdlibm/FILES_c.gmk - makefiles/java/fdlibm/Makefile - makefiles/java/instrument/Makefile - makefiles/java/instrument/mapfile-vers - makefiles/java/java/Exportedfiles.gmk - makefiles/java/java/FILES_c.gmk - makefiles/java/java/FILES_java.gmk - makefiles/java/java/Makefile - makefiles/java/java/localelist.sh - makefiles/java/java/mapfile-vers - makefiles/java/java/reflect/Makefile - makefiles/java/java/reorder-i586 - makefiles/java/java/reorder-sparc - makefiles/java/java/reorder-sparcv9 - makefiles/java/java_crw_demo/Makefile - makefiles/java/java_crw_demo/mapfile-vers - makefiles/java/java_hprof_demo/Makefile - makefiles/java/java_hprof_demo/mapfile-vers - makefiles/java/jexec/Makefile - makefiles/java/jli/Makefile - makefiles/java/jli/mapfile-vers - makefiles/java/jobjc/Makefile - makefiles/java/jvm/Makefile - makefiles/java/main/Makefile - makefiles/java/main/java/Makefile - makefiles/java/main/java/mapfile-amd64 - makefiles/java/main/java/mapfile-i586 - makefiles/java/main/java/mapfile-sparc - makefiles/java/main/java/mapfile-sparcv9 - makefiles/java/main/javaw/Makefile - makefiles/java/management/Exportedfiles.gmk - makefiles/java/management/FILES_c.gmk - makefiles/java/management/Makefile - makefiles/java/management/mapfile-vers - makefiles/java/net/FILES_c.gmk - makefiles/java/net/Makefile - makefiles/java/net/mapfile-vers - makefiles/java/nio/Exportedfiles.gmk - makefiles/java/nio/FILES_c.gmk - makefiles/java/nio/FILES_java.gmk - makefiles/java/nio/Makefile - makefiles/java/nio/addNotices.sh - makefiles/java/nio/genBuffer.sh - makefiles/java/nio/genCharsetProvider.sh - makefiles/java/nio/genCoder.sh - makefiles/java/nio/genExceptions.sh - makefiles/java/nio/mapfile-bsd - makefiles/java/nio/mapfile-linux - makefiles/java/nio/mapfile-solaris - makefiles/java/nio/reorder-i586 - makefiles/java/nio/reorder-sparc - makefiles/java/nio/reorder-sparcv9 - makefiles/java/npt/Makefile - makefiles/java/npt/mapfile-vers - makefiles/java/redist/fonts/Makefile - makefiles/java/security/Makefile - makefiles/java/sun_nio/FILES_java.gmk - makefiles/java/sun_nio/Makefile - makefiles/java/util/FILES_java.gmk - makefiles/java/util/FILES_properties.gmk - makefiles/java/util/Makefile - makefiles/java/verify/Makefile - makefiles/java/verify/mapfile-vers - makefiles/java/verify/reorder-i586 - makefiles/java/verify/reorder-sparc - makefiles/java/verify/reorder-sparcv9 - makefiles/javax/Makefile - makefiles/javax/imageio/Makefile - makefiles/javax/management/Makefile - makefiles/javax/sound/FILES_c.gmk - makefiles/javax/sound/Makefile - makefiles/javax/sound/SoundDefs.gmk - makefiles/javax/sound/jsoundalsa/Makefile - makefiles/javax/sound/jsoundalsa/mapfile-vers - makefiles/javax/sound/jsoundds/Makefile - makefiles/javax/sound/mapfile-vers - makefiles/javax/sql/Makefile - makefiles/javax/swing/FILES.gmk - makefiles/javax/swing/Makefile - makefiles/javax/swing/beaninfo/FILES.gmk - makefiles/javax/swing/beaninfo/Makefile - makefiles/javax/swing/beaninfo/SwingBeans.gmk - makefiles/javax/swing/beaninfo/manifest - makefiles/javax/swing/html32dtd/Makefile - makefiles/javax/swing/plaf/FILES.gmk - makefiles/javax/swing/plaf/Makefile - makefiles/sun/Makefile - makefiles/sun/awt/CondenseRules.awk - makefiles/sun/awt/Depend.mak - makefiles/sun/awt/Depend.sed - makefiles/sun/awt/FILES_c_macosx.gmk - makefiles/sun/awt/FILES_c_unix.gmk - makefiles/sun/awt/FILES_c_windows.gmk - makefiles/sun/awt/FILES_export_macosx.gmk - makefiles/sun/awt/FILES_export_unix.gmk - makefiles/sun/awt/FILES_export_windows.gmk - makefiles/sun/awt/Makefile - makefiles/sun/awt/README - makefiles/sun/awt/make.depend - makefiles/sun/awt/mapfile-mawt-vers - makefiles/sun/awt/mapfile-vers - makefiles/sun/awt/mapfile-vers-linux - makefiles/sun/awt/mawt.gmk - makefiles/sun/cmm/Makefile - makefiles/sun/cmm/kcms/FILES_c_unix.gmk - makefiles/sun/cmm/kcms/FILES_c_windows.gmk - makefiles/sun/cmm/kcms/Makefile - makefiles/sun/cmm/kcms/mapfile-vers - makefiles/sun/dcpr/FILES_c.gmk - makefiles/sun/dcpr/Makefile - makefiles/sun/dcpr/mapfile-vers - makefiles/sun/headless/Makefile - makefiles/sun/headless/mapfile-vers - makefiles/sun/headless/reorder-i586 - makefiles/sun/headless/reorder-sparc - makefiles/sun/headless/reorder-sparcv9 - makefiles/sun/image/Makefile - makefiles/sun/image/generic/FILES_c.gmk - makefiles/sun/image/generic/Makefile - makefiles/sun/image/generic/mapfile-vers - makefiles/sun/image/vis/FILES_c.gmk - makefiles/sun/image/vis/Makefile - makefiles/sun/javazic/Makefile - makefiles/sun/jdbc/Makefile - makefiles/sun/jdga/Makefile - makefiles/sun/jdga/mapfile-vers - makefiles/sun/lwawt/FILES_c_macosx.gmk - makefiles/sun/lwawt/FILES_export_macosx.gmk - makefiles/sun/lwawt/Makefile - makefiles/sun/nio/Makefile - makefiles/sun/nio/cs/FILES_java.gmk - makefiles/sun/nio/cs/Makefile - makefiles/sun/org/Makefile - makefiles/sun/org/mozilla/Makefile - makefiles/sun/org/mozilla/javascript/Makefile - makefiles/sun/osxapp/Makefile - makefiles/sun/security/Makefile - makefiles/sun/security/ec/FILES_c.gmk - makefiles/sun/security/ec/mapfile-vers - makefiles/sun/security/jgss/Makefile - makefiles/sun/security/jgss/wrapper/FILES_c.gmk - makefiles/sun/security/jgss/wrapper/Makefile - makefiles/sun/security/jgss/wrapper/mapfile-vers - makefiles/sun/security/krb5/FILES_c_windows.gmk - makefiles/sun/security/krb5/Makefile - makefiles/sun/security/mscapi/FILES_cpp.gmk - makefiles/sun/security/mscapi/Makefile - makefiles/sun/security/other/Makefile - makefiles/sun/security/smartcardio/FILES_c.gmk - makefiles/sun/security/smartcardio/Makefile - makefiles/sun/security/smartcardio/mapfile-vers - makefiles/sun/security/tools/Makefile - makefiles/sun/security/util/Makefile - makefiles/sun/splashscreen/FILES_c.gmk - makefiles/sun/splashscreen/Makefile - makefiles/sun/splashscreen/mapfile-vers - makefiles/sun/xawt/FILES_c_unix.gmk - makefiles/sun/xawt/FILES_export_unix.gmk - makefiles/sun/xawt/Makefile - makefiles/sun/xawt/mapfile-vers Changeset: db471a7af031 Author: katleman Date: 2012-06-14 13:14 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/db471a7af031 Added tag jdk8-b43 for changeset b3246687c369 ! .hgtags Changeset: 6b40703aad55 Author: lana Date: 2012-06-17 21:34 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6b40703aad55 Merge - makefiles/altclasses/Makefile - makefiles/apple/Makefile - makefiles/apple/applescript/Makefile - makefiles/com/Makefile - makefiles/com/apple/Makefile - makefiles/com/apple/osx/Makefile - makefiles/com/apple/osxui/Makefile - makefiles/com/oracle/Makefile - makefiles/com/oracle/jfr/Makefile - makefiles/com/oracle/security/ucrypto/FILES_c.gmk - makefiles/com/oracle/security/ucrypto/Makefile - makefiles/com/oracle/security/ucrypto/mapfile-vers - makefiles/com/sun/Makefile - makefiles/common/shared/Defs-utils.gmk - makefiles/java/fdlibm/FILES_c.gmk - makefiles/java/fdlibm/Makefile - makefiles/java/instrument/Makefile - makefiles/java/instrument/mapfile-vers - makefiles/java/java/Exportedfiles.gmk - makefiles/java/java/FILES_c.gmk - makefiles/java/java/FILES_java.gmk - makefiles/java/java/Makefile - makefiles/java/java/localelist.sh - makefiles/java/java/mapfile-vers - makefiles/java/java/reflect/Makefile - makefiles/java/java/reorder-i586 - makefiles/java/java/reorder-sparc - makefiles/java/java/reorder-sparcv9 - makefiles/java/java_crw_demo/Makefile - makefiles/java/java_crw_demo/mapfile-vers - makefiles/java/java_hprof_demo/Makefile - makefiles/java/java_hprof_demo/mapfile-vers - makefiles/java/jexec/Makefile - makefiles/java/jli/Makefile - makefiles/java/jli/mapfile-vers - makefiles/java/jobjc/Makefile - makefiles/java/jvm/Makefile - makefiles/java/main/Makefile - makefiles/java/main/java/Makefile - makefiles/java/main/java/mapfile-amd64 - makefiles/java/main/java/mapfile-i586 - makefiles/java/main/java/mapfile-sparc - makefiles/java/main/java/mapfile-sparcv9 - makefiles/java/main/javaw/Makefile - makefiles/java/management/Exportedfiles.gmk - makefiles/java/management/FILES_c.gmk - makefiles/java/management/Makefile - makefiles/java/management/mapfile-vers - makefiles/java/net/FILES_c.gmk - makefiles/java/net/Makefile - makefiles/java/net/mapfile-vers - makefiles/java/nio/Exportedfiles.gmk - makefiles/java/nio/FILES_c.gmk - makefiles/java/nio/FILES_java.gmk - makefiles/java/nio/Makefile - makefiles/java/nio/addNotices.sh - makefiles/java/nio/genBuffer.sh - makefiles/java/nio/genCharsetProvider.sh - makefiles/java/nio/genCoder.sh - makefiles/java/nio/genExceptions.sh - makefiles/java/nio/mapfile-bsd - makefiles/java/nio/mapfile-linux - makefiles/java/nio/mapfile-solaris - makefiles/java/nio/reorder-i586 - makefiles/java/nio/reorder-sparc - makefiles/java/nio/reorder-sparcv9 - makefiles/java/npt/Makefile - makefiles/java/npt/mapfile-vers - makefiles/java/redist/fonts/Makefile - makefiles/java/security/Makefile - makefiles/java/sun_nio/FILES_java.gmk - makefiles/java/sun_nio/Makefile - makefiles/java/util/FILES_java.gmk - makefiles/java/util/FILES_properties.gmk - makefiles/java/util/Makefile - makefiles/java/verify/Makefile - makefiles/java/verify/mapfile-vers - makefiles/java/verify/reorder-i586 - makefiles/java/verify/reorder-sparc - makefiles/java/verify/reorder-sparcv9 - makefiles/javax/Makefile - makefiles/javax/imageio/Makefile - makefiles/javax/management/Makefile - makefiles/javax/sound/FILES_c.gmk - makefiles/javax/sound/Makefile - makefiles/javax/sound/SoundDefs.gmk - makefiles/javax/sound/jsoundalsa/Makefile - makefiles/javax/sound/jsoundalsa/mapfile-vers - makefiles/javax/sound/jsoundds/Makefile - makefiles/javax/sound/mapfile-vers - makefiles/javax/sql/Makefile - makefiles/javax/swing/FILES.gmk - makefiles/javax/swing/Makefile - makefiles/javax/swing/beaninfo/FILES.gmk - makefiles/javax/swing/beaninfo/Makefile - makefiles/javax/swing/beaninfo/SwingBeans.gmk - makefiles/javax/swing/beaninfo/manifest - makefiles/javax/swing/html32dtd/Makefile - makefiles/javax/swing/plaf/FILES.gmk - makefiles/javax/swing/plaf/Makefile - makefiles/sun/Makefile - makefiles/sun/awt/CondenseRules.awk - makefiles/sun/awt/Depend.mak - makefiles/sun/awt/Depend.sed - makefiles/sun/awt/FILES_c_macosx.gmk - makefiles/sun/awt/FILES_c_unix.gmk - makefiles/sun/awt/FILES_c_windows.gmk - makefiles/sun/awt/FILES_export_macosx.gmk - makefiles/sun/awt/FILES_export_unix.gmk - makefiles/sun/awt/FILES_export_windows.gmk - makefiles/sun/awt/Makefile - makefiles/sun/awt/README - makefiles/sun/awt/make.depend - makefiles/sun/awt/mapfile-mawt-vers - makefiles/sun/awt/mapfile-vers - makefiles/sun/awt/mapfile-vers-linux - makefiles/sun/awt/mawt.gmk - makefiles/sun/cmm/Makefile - makefiles/sun/cmm/kcms/FILES_c_unix.gmk - makefiles/sun/cmm/kcms/FILES_c_windows.gmk - makefiles/sun/cmm/kcms/Makefile - makefiles/sun/cmm/kcms/mapfile-vers - makefiles/sun/dcpr/FILES_c.gmk - makefiles/sun/dcpr/Makefile - makefiles/sun/dcpr/mapfile-vers - makefiles/sun/headless/Makefile - makefiles/sun/headless/mapfile-vers - makefiles/sun/headless/reorder-i586 - makefiles/sun/headless/reorder-sparc - makefiles/sun/headless/reorder-sparcv9 - makefiles/sun/image/Makefile - makefiles/sun/image/generic/FILES_c.gmk - makefiles/sun/image/generic/Makefile - makefiles/sun/image/generic/mapfile-vers - makefiles/sun/image/vis/FILES_c.gmk - makefiles/sun/image/vis/Makefile - makefiles/sun/javazic/Makefile - makefiles/sun/jdbc/Makefile - makefiles/sun/jdga/Makefile - makefiles/sun/jdga/mapfile-vers - makefiles/sun/lwawt/FILES_c_macosx.gmk - makefiles/sun/lwawt/FILES_export_macosx.gmk - makefiles/sun/lwawt/Makefile - makefiles/sun/nio/Makefile - makefiles/sun/nio/cs/FILES_java.gmk - makefiles/sun/nio/cs/Makefile - makefiles/sun/org/Makefile - makefiles/sun/org/mozilla/Makefile - makefiles/sun/org/mozilla/javascript/Makefile - makefiles/sun/osxapp/Makefile - makefiles/sun/security/Makefile - makefiles/sun/security/ec/FILES_c.gmk - makefiles/sun/security/ec/mapfile-vers - makefiles/sun/security/jgss/Makefile - makefiles/sun/security/jgss/wrapper/FILES_c.gmk - makefiles/sun/security/jgss/wrapper/Makefile - makefiles/sun/security/jgss/wrapper/mapfile-vers - makefiles/sun/security/krb5/FILES_c_windows.gmk - makefiles/sun/security/krb5/Makefile - makefiles/sun/security/mscapi/FILES_cpp.gmk - makefiles/sun/security/mscapi/Makefile - makefiles/sun/security/other/Makefile - makefiles/sun/security/smartcardio/FILES_c.gmk - makefiles/sun/security/smartcardio/Makefile - makefiles/sun/security/smartcardio/mapfile-vers - makefiles/sun/security/tools/Makefile - makefiles/sun/security/util/Makefile - makefiles/sun/splashscreen/FILES_c.gmk - makefiles/sun/splashscreen/Makefile - makefiles/sun/splashscreen/mapfile-vers - makefiles/sun/xawt/FILES_c_unix.gmk - makefiles/sun/xawt/FILES_export_unix.gmk - makefiles/sun/xawt/Makefile - makefiles/sun/xawt/mapfile-vers From alan.bateman at oracle.com Mon Jun 18 10:21:34 2012 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Mon, 18 Jun 2012 10:21:34 +0000 Subject: hg: jdk8/tl/jdk: 7177617: TEST_BUG: java/nio/channels/AsyncCloseAndInterrupt.java failing (win) Message-ID: <20120618102158.DF6BC479B0@hg.openjdk.java.net> Changeset: 689129c71ccd Author: alanb Date: 2012-06-18 11:19 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/689129c71ccd 7177617: TEST_BUG: java/nio/channels/AsyncCloseAndInterrupt.java failing (win) Reviewed-by: chegar, coffeys ! test/java/nio/channels/AsyncCloseAndInterrupt.java ! test/java/nio/channels/SocketChannel/AdaptSocket.java + test/java/nio/channels/SocketChannel/CloseDuringWrite.java ! test/java/nio/channels/TestUtil.java From mark.reinhold at oracle.com Mon Jun 18 21:12:14 2012 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 18 Jun 2012 14:12:14 -0700 (PDT) Subject: JEP 155: Concurrency updates (jsr166e) Message-ID: <20120618211214.AF6D513EE@eggemoggin.niobe.net> Posted: http://openjdk.java.net/jeps/155 - Mark From david.lloyd at redhat.com Mon Jun 18 21:34:59 2012 From: david.lloyd at redhat.com (David M. Lloyd) Date: Mon, 18 Jun 2012 16:34:59 -0500 Subject: JEP 155: Concurrency updates (jsr166e) In-Reply-To: <20120618211214.AF6D513EE@eggemoggin.niobe.net> References: <20120618211214.AF6D513EE@eggemoggin.niobe.net> Message-ID: <4FDF9F03.40605@redhat.com> On 06/18/2012 04:12 PM, mark.reinhold at oracle.com wrote: > Posted: http://openjdk.java.net/jeps/155 > > - Mark Might Doug's two-field atomic operations support idea possibly be a part of this (i.e. make it in time for Java 8)? -- - DML From dl at cs.oswego.edu Mon Jun 18 23:27:31 2012 From: dl at cs.oswego.edu (Doug Lea) Date: Mon, 18 Jun 2012 19:27:31 -0400 Subject: JEP 155: Concurrency updates (jsr166e) In-Reply-To: <4FDF9F03.40605@redhat.com> References: <20120618211214.AF6D513EE@eggemoggin.niobe.net> <4FDF9F03.40605@redhat.com> Message-ID: <4FDFB963.1010109@cs.oswego.edu> On 06/18/12 17:34, David M. Lloyd wrote: > On 06/18/2012 04:12 PM, mark.reinhold at oracle.com wrote: >> Posted: http://openjdk.java.net/jeps/155 >> >> - Mark > > Might Doug's two-field atomic operations support idea possibly be a part of this > (i.e. make it in time for Java 8)? > I think it is unlikely for JDK8. Doing this (basically 2CAS and maybe 3CAS, 4CAS) well enough to release would require more JVM intrinsics to handle the cases mappable to instructions on recent/upcoming processros. We can (slowly) emulate on others, but I don't think there will be a long enough time window to coordinate for JDK8. Stay tuned though for some variants of locks etc that make some STM-ish usages easier. These ought to make it in time (and so are alluded to in JEP). -Doug From masayoshi.okutsu at oracle.com Tue Jun 19 07:32:31 2012 From: masayoshi.okutsu at oracle.com (masayoshi.okutsu at oracle.com) Date: Tue, 19 Jun 2012 07:32:31 +0000 Subject: hg: jdk8/tl/jdk: 6380549: (rb) ResourceBundle.Control global binding support Message-ID: <20120619073244.61B58479E4@hg.openjdk.java.net> Changeset: 4419c8f0b2f2 Author: okutsu Date: 2012-06-19 16:21 +0900 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4419c8f0b2f2 6380549: (rb) ResourceBundle.Control global binding support Reviewed-by: naoto ! make/java/java/FILES_java.gmk ! src/share/classes/java/util/ResourceBundle.java + src/share/classes/java/util/spi/ResourceBundleControlProvider.java + test/java/util/spi/ResourceBundleControlProvider/UserDefaultControlTest.java + test/java/util/spi/ResourceBundleControlProvider/UserDefaultControlTest.sh + test/java/util/spi/ResourceBundleControlProvider/providersrc/Makefile + test/java/util/spi/ResourceBundleControlProvider/providersrc/UserControlProvider.java + test/java/util/spi/ResourceBundleControlProvider/providersrc/UserXMLControl.java + test/java/util/spi/ResourceBundleControlProvider/providersrc/XmlRB.xml + test/java/util/spi/ResourceBundleControlProvider/providersrc/XmlRB_ja.xml + test/java/util/spi/ResourceBundleControlProvider/providersrc/java.util.spi.ResourceBundleControlProvider + test/java/util/spi/ResourceBundleControlProvider/rbcontrolprovider.jar From chris.hegarty at oracle.com Tue Jun 19 09:21:47 2012 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Tue, 19 Jun 2012 09:21:47 +0000 Subject: hg: jdk8/tl/jdk: 6901992: InvalidJarIndexException due to bug in sun.misc.JarIndex.merge() Message-ID: <20120619092249.4B557479EA@hg.openjdk.java.net> Changeset: efc2791d7c5d Author: chegar Date: 2012-06-19 10:20 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/efc2791d7c5d 6901992: InvalidJarIndexException due to bug in sun.misc.JarIndex.merge() Reviewed-by: chegar Contributed-by: dbelfer at gmail.com ! src/share/classes/sun/misc/JarIndex.java + test/sun/misc/JarIndex/JarIndexMergeForClassLoaderTest.java + test/sun/misc/JarIndex/JarIndexMergeTest.java From chris.hegarty at oracle.com Tue Jun 19 10:15:30 2012 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 19 Jun 2012 11:15:30 +0100 Subject: PATCH [6901992] : Possible InvalidJarIndexException due to bug in sun.misc.JarIndex.merge() In-Reply-To: References: <4FD8AC53.7040204@oracle.com> <4FD90A22.20608@oracle.com> <4FD9BDBD.7050004@oracle.com> Message-ID: <4FE05142.1040900@oracle.com> To close the loop on this, here is a link to the changeset: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/efc2791d7c5d Thanks for this valuable contribution Diego. -Chris On 16/06/12 05:20, Diego Belfer wrote: > Hi Chris, > > Here is a new patch containing new version of the tests. The new > versions generate a the Jar on the fly as we discussed. > > Let me know if there is anything else you think should be improved. > > Best, > Diego > > On Thu, Jun 14, 2012 at 7:32 AM, Chris Hegarty > wrote: > > Diego, > > It's not too difficult to create jars on the fly using the Jar API. > Here is a small example that I think would work nice in this case. > Files created ( and paths are relative to the jtreg scratch, or > working dir if running outside of jtreg ). > > Do you think you could use similar to create the jars for your test? > > createJar("a.jar", jarAList); > createJar("b.jar", jarBList); > ....... > > static void createJar(String jarName, Map contents) > throws Exception > { > try (FileOutputStream aJar = new FileOutputStream(jarName); > JarOutputStream jos = new JarOutputStream(aJar)) { > Set> entries = contents.entrySet(); > for (Entry entry : entries) > writeJarEntry(jos, entry.getKey(), > entry.getValue().getBytes("__ASCII")); > } > } > > static void writeJarEntry(JarOutputStream jos, String name, > byte[] data) > throws Exception > { > JarEntry entry = new JarEntry(name); > jos.putNextEntry(entry); > jos.write(data); > } > > static final Map jarAList = new HashMap<>(); > static final Map jarBList = new HashMap<>(); > static { > jarAList.put("com/foo/__resource1.txt", "some random data"); > jarAList.put("com/bar/__resource2.txt", "some more random > data!"); > jarAList.put("com/baz/__resource3.txt", "even more random > data!!!"); > jarBList.put("x/y/resourceA.__dat", "Hello there"); > jarBList.put("x/y/resourceB.__dat", "Goodbye"); > jarBList.put("x/y/resourceC.__dat", "Hello\nfrom\nb\ndot\njar"); > } > > Thanks, > -Chris. > > > On 14/06/2012 03:20, Diego Belfer wrote: > > Hi Chris, > > There is no way to generate a jar without directory entries > using the > jar tool; there is no option for that. What do you think is the > best way > to handle this ? > I don't want to re-implement the logic for creating a jar using the > JarOutputStream class. > > Do you think it is possible to add a new option to the Jar tool Main > class to exclude directory entries? The option does not need to be > exposed by the command line tool to final users if this an issue, > although I think it may be useful for them too. > > Best, > Diego > > > On Wed, Jun 13, 2012 at 7:12 PM, Diego Belfer > >> wrote: > > Chris, > > I was thinking of something similar. I will create the jars and > their contents using Java code. There is no need of creating > real > class files, using a few resource files and some directories > will be > enough. > > Best, > Diego > > > On Wed, Jun 13, 2012 at 6:46 PM, chris hegarty > > >> wrote: > > Diego, > > I'm thinking that some of the trivial source files, to > compile > and built into the jars, could be simply created and > written by > the test itself, rather than checking them all in. If > this makes > it cleaner. I really don't like all the file in > test/sun/misc/JarIndex/____metaInfFilenames, but at > least it is > > quite understandable. > > -Chris. > > > On 13/06/2012 20:36, Diego Belfer wrote: > > Hi Chris, > > That's right. The only non-cleanup change is the one > in the > merge. > > Regarding the test case, I will re-write them in > order to > generate the > jars on fly. I'd scanned the jdk/test folder and > found a few > jars, > that's why I included them. I have seen your test > case, I > will use it > as a sample. > > I had not seen your comment in the bug report. Maybe > there > are other > cases which trigger the InvalidJarIndexException, > but, as > far as I could > see, the validIndex method checks that at least one > entry of > the jar > matches the target path found in the index. If directory > entries are not > present in the jar, stripped paths generated during the > merge and used > by the index will return jars which may not contain > entries > for them, > triggering the exception. > When all directory entries are present, if a jar > contains an > entry for > "xxx/yyy/resource.file", it will contain entries for "xxx", > "xxx/yyy" > and "xxx/yyy/resource.file". > > > Best, > Diego > > > On Wed, Jun 13, 2012 at 12:05 PM, Chris Hegarty > > > > ____com > > >>> wrote: > > Hi Diego, > > Thanks for picking up this bug. > > I think your changes look fine. Mainly cleanup > except > for add -> > addExplicit/addMapping in merge, right? BTW the > cleanup > makes this > more readable. > > Unfortunately, the tests you created require > checking in > a binary > jar file. This is a real no no for the OpenJDK, we > really need to > create these jars on the fly. I did similar for > test/sun/misc/JarIndex/______metaInfFilenames/, > but I > > really wish I > > generated the source files for these tests > rather than > checking in > so many pointless files. > > I can look at helping with writing suitable > tests for this. > > > > That's because I was using jars containing "directory > entries" > > (I was unaware that jar files may not include them) > > Strangely I added the comment "Remove > directories from > jar files > being indexed." to the workaround section of the > bug. > You seem to be > seeing the opposite, right? > > -Chris. > > > > On 13/06/2012 06:11, Diego Belfer wrote: > > Hi, > > I have finally reproduced the > InvalidJarIndexException bug as > reported in > the ticket. I mentioned in a previous email, > that > the only way > I'd found > for getting the error was to use an invalid > index file > (INDEX.LIST), which > did not have any sense. That's because I was > using > jars containing > "directory entries" (I was unaware that jar files may not > include them) > > After reviewing the URLClasspath$JarLoader > class and the > validIndex method, > I notice it is possible to get the exception > for a > Jar file > which does not > include directory entries. In order to > trigger the > issue, the > Jar must be > referenced by an intermediary INDEX.LIST and the > intermediary > Jar index > should have been merged to its parent index. > Although, jar tool > includes > directory entries in the generated jar files, > Eclipse default > option for > exporting jars does not include them (AFAIK), so > this might be > quite common. > > I have created a new PATCH which includes an > additional test > case which > uses the URLClassLoader to trigger the > InvalidIndexException. > > The patch is attached, please consider it > for review. > > Best, > Diego Belfer [muralx] > > > > On Mon, Jun 11, 2012 at 4:47 PM, Diego > Belfer > > > > >>> wrote: > > > > Hi, > > Here is a patch that fixes the merge > method of > the JarIndex. > This bug was > reported as the cause of the bug 6901992. > Although, I was > not able to > reproduce the BUG itself > (InvalidJarIndexException), I did > verified that > the method had a bug, and resources/classes > where not found > in a jarIndex > with merged contents. > > If you think it is possible to commit > this fix > without actually > reproducing the original bug report, please > consider this > patch for review. > > Thanks, > Diego Belfer [muralx] > > > > > > From maurizio.cimadamore at oracle.com Tue Jun 19 12:27:14 2012 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Tue, 19 Jun 2012 12:27:14 +0000 Subject: hg: jdk8/tl/langtools: 7177701: error: Filling jar message during javax/imageio/metadata/IIOMetadataFormatImpl compilation Message-ID: <20120619122716.D48CE479ED@hg.openjdk.java.net> Changeset: 34e254ffd0e7 Author: mcimadamore Date: 2012-06-19 13:25 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/34e254ffd0e7 7177701: error: Filling jar message during javax/imageio/metadata/IIOMetadataFormatImpl compilation Summary: Recent JDK hash changes affected order in which files are returned from JavacFileManager.list() Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/file/ZipFileIndex.java From dbelfer at gmail.com Tue Jun 19 21:20:06 2012 From: dbelfer at gmail.com (Diego Belfer) Date: Tue, 19 Jun 2012 18:20:06 -0300 Subject: PATCH [6901992] : Possible InvalidJarIndexException due to bug in sun.misc.JarIndex.merge() In-Reply-To: <4FE05142.1040900@oracle.com> References: <4FD8AC53.7040204@oracle.com> <4FD90A22.20608@oracle.com> <4FD9BDBD.7050004@oracle.com> <4FE05142.1040900@oracle.com> Message-ID: Thanks for sponsoring the patch.. Best, Diego On Tue, Jun 19, 2012 at 7:15 AM, Chris Hegarty wrote: > To close the loop on this, here is a link to the changeset: > > http://hg.openjdk.java.net/**jdk8/tl/jdk/rev/efc2791d7c5d > > Thanks for this valuable contribution Diego. > > -Chris > > > On 16/06/12 05:20, Diego Belfer wrote: > >> Hi Chris, >> >> Here is a new patch containing new version of the tests. The new >> versions generate a the Jar on the fly as we discussed. >> >> Let me know if there is anything else you think should be improved. >> >> Best, >> Diego >> >> On Thu, Jun 14, 2012 at 7:32 AM, Chris Hegarty > >> wrote: >> >> Diego, >> >> It's not too difficult to create jars on the fly using the Jar API. >> Here is a small example that I think would work nice in this case. >> Files created ( and paths are relative to the jtreg scratch, or >> working dir if running outside of jtreg ). >> >> Do you think you could use similar to create the jars for your test? >> >> createJar("a.jar", jarAList); >> createJar("b.jar", jarBList); >> ....... >> >> static void createJar(String jarName, Map contents) >> throws Exception >> { >> try (FileOutputStream aJar = new FileOutputStream(jarName); >> JarOutputStream jos = new JarOutputStream(aJar)) { >> Set> entries = contents.entrySet(); >> for (Entry entry : entries) >> writeJarEntry(jos, entry.getKey(), >> entry.getValue().getBytes("__**ASCII")); >> >> } >> } >> >> static void writeJarEntry(JarOutputStream jos, String name, >> byte[] data) >> throws Exception >> { >> JarEntry entry = new JarEntry(name); >> jos.putNextEntry(entry); >> jos.write(data); >> } >> >> static final Map jarAList = new HashMap<>(); >> static final Map jarBList = new HashMap<>(); >> static { >> jarAList.put("com/foo/__**resource1.txt", "some random data"); >> jarAList.put("com/bar/__**resource2.txt", "some more random >> data!"); >> jarAList.put("com/baz/__**resource3.txt", "even more random >> data!!!"); >> jarBList.put("x/y/resourceA.__**dat", "Hello there"); >> jarBList.put("x/y/resourceB.__**dat", "Goodbye"); >> jarBList.put("x/y/resourceC.__**dat", >> "Hello\nfrom\nb\ndot\njar"); >> >> } >> >> Thanks, >> -Chris. >> >> >> On 14/06/2012 03:20, Diego Belfer wrote: >> >> Hi Chris, >> >> There is no way to generate a jar without directory entries >> using the >> jar tool; there is no option for that. What do you think is the >> best way >> to handle this ? >> I don't want to re-implement the logic for creating a jar using the >> JarOutputStream class. >> >> Do you think it is possible to add a new option to the Jar tool >> Main >> class to exclude directory entries? The option does not need to be >> exposed by the command line tool to final users if this an issue, >> although I think it may be useful for them too. >> >> Best, >> Diego >> >> >> On Wed, Jun 13, 2012 at 7:12 PM, Diego Belfer > >> >> wrote: >> >> Chris, >> >> I was thinking of something similar. I will create the jars and >> their contents using Java code. There is no need of creating >> real >> class files, using a few resource files and some directories >> will be >> enough. >> >> Best, >> Diego >> >> >> On Wed, Jun 13, 2012 at 6:46 PM, chris hegarty >> >> > >> > >>> >> wrote: >> >> Diego, >> >> I'm thinking that some of the trivial source files, to >> compile >> and built into the jars, could be simply created and >> written by >> the test itself, rather than checking them all in. If >> this makes >> it cleaner. I really don't like all the file in >> test/sun/misc/JarIndex/____**metaInfFilenames, but at >> >> least it is >> >> quite understandable. >> >> -Chris. >> >> >> On 13/06/2012 20:36, Diego Belfer wrote: >> >> Hi Chris, >> >> That's right. The only non-cleanup change is the one >> in the >> merge. >> >> Regarding the test case, I will re-write them in >> order to >> generate the >> jars on fly. I'd scanned the jdk/test folder and >> found a few >> jars, >> that's why I included them. I have seen your test >> case, I >> will use it >> as a sample. >> >> I had not seen your comment in the bug report. Maybe >> there >> are other >> cases which trigger the InvalidJarIndexException, >> but, as >> far as I could >> see, the validIndex method checks that at least one >> entry of >> the jar >> matches the target path found in the index. If >> directory >> entries are not >> present in the jar, stripped paths generated during the >> merge and used >> by the index will return jars which may not contain >> entries >> for them, >> triggering the exception. >> When all directory entries are present, if a jar >> contains an >> entry for >> "xxx/yyy/resource.file", it will contain entries for "xxx", >> "xxx/yyy" >> and "xxx/yyy/resource.file". >> >> >> Best, >> Diego >> >> >> On Wed, Jun 13, 2012 at 12:05 PM, Chris Hegarty >> >> > >> > >> >> ** >> ____com >> >> >> > >>>> >> wrote: >> >> Hi Diego, >> >> Thanks for picking up this bug. >> >> I think your changes look fine. Mainly cleanup >> except >> for add -> >> addExplicit/addMapping in merge, right? BTW the >> cleanup >> makes this >> more readable. >> >> Unfortunately, the tests you created require >> checking in >> a binary >> jar file. This is a real no no for the OpenJDK, we >> really need to >> create these jars on the fly. I did similar for >> test/sun/misc/JarIndex/______**metaInfFilenames/, >> >> but I >> >> really wish I >> >> generated the source files for these tests >> rather than >> checking in >> so many pointless files. >> >> I can look at helping with writing suitable >> tests for this. >> >> >> > That's because I was using jars containing "directory >> entries" >> > (I was unaware that jar files may not include them) >> >> Strangely I added the comment "Remove >> directories from >> jar files >> being indexed." to the workaround section of the >> bug. >> You seem to be >> seeing the opposite, right? >> >> -Chris. >> >> >> >> On 13/06/2012 06:11, Diego Belfer wrote: >> >> Hi, >> >> I have finally reproduced the >> InvalidJarIndexException bug as >> reported in >> the ticket. I mentioned in a previous email, >> that >> the only way >> I'd found >> for getting the error was to use an invalid >> index file >> (INDEX.LIST), which >> did not have any sense. That's because I was >> using >> jars containing >> "directory entries" (I was unaware that jar files may not >> include them) >> >> After reviewing the URLClasspath$JarLoader >> class and the >> validIndex method, >> I notice it is possible to get the exception >> for a >> Jar file >> which does not >> include directory entries. In order to >> trigger the >> issue, the >> Jar must be >> referenced by an intermediary INDEX.LIST and >> the >> intermediary >> Jar index >> should have been merged to its parent index. >> Although, jar tool >> includes >> directory entries in the generated jar files, >> Eclipse default >> option for >> exporting jars does not include them (AFAIK), >> so >> this might be >> quite common. >> >> I have created a new PATCH which includes an >> additional test >> case which >> uses the URLClassLoader to trigger the >> InvalidIndexException. >> >> The patch is attached, please consider it >> for review. >> >> Best, >> Diego Belfer [muralx] >> >> >> >> On Mon, Jun 11, 2012 at 4:47 PM, Diego >> Belfer >> > >> >> >>> wrote: >> >> >> >> Hi, >> >> Here is a patch that fixes the merge >> method of >> the JarIndex. >> This bug was >> reported as the cause of the bug 6901992. >> Although, I was >> not able to >> reproduce the BUG itself >> (InvalidJarIndexException), I did >> verified that >> the method had a bug, and resources/classes >> where not found >> in a jarIndex >> with merged contents. >> >> If you think it is possible to commit >> this fix >> without actually >> reproducing the original bug report, please >> consider this >> patch for review. >> >> Thanks, >> Diego Belfer [muralx] >> >> >> >> >> >> >> From xuelei.fan at oracle.com Wed Jun 20 00:29:18 2012 From: xuelei.fan at oracle.com (xuelei.fan at oracle.com) Date: Wed, 20 Jun 2012 00:29:18 +0000 Subject: hg: jdk8/tl/jdk: 7166487: checkSequenceNumber method never called within readRecord of SSLEngineImpl Message-ID: <20120620002935.1B2C147A0D@hg.openjdk.java.net> Changeset: cdcbd22cfb9d Author: xuelei Date: 2012-06-19 17:28 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cdcbd22cfb9d 7166487: checkSequenceNumber method never called within readRecord of SSLEngineImpl Reviewed-by: weijun ! src/share/classes/sun/security/ssl/SSLEngineImpl.java From david.holmes at oracle.com Wed Jun 20 01:14:26 2012 From: david.holmes at oracle.com (David Holmes) Date: Wed, 20 Jun 2012 11:14:26 +1000 Subject: hg: jdk8/tl/langtools: 7177701: error: Filling jar message during javax/imageio/metadata/IIOMetadataFormatImpl compilation In-Reply-To: <20120619122716.D48CE479ED@hg.openjdk.java.net> References: <20120619122716.D48CE479ED@hg.openjdk.java.net> Message-ID: <4FE123F2.9040403@oracle.com> Hi Maurizio, On 19/06/2012 10:27 PM, maurizio.cimadamore at oracle.com wrote: > Changeset: 34e254ffd0e7 > Author: mcimadamore > Date: 2012-06-19 13:25 +0100 > URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/34e254ffd0e7 > > 7177701: error: Filling jar message during javax/imageio/metadata/IIOMetadataFormatImpl compilation > Summary: Recent JDK hash changes affected order in which files are returned from JavacFileManager.list() > Reviewed-by: jjg > > ! src/share/classes/com/sun/tools/javac/file/ZipFileIndex.java That change seems fragile to say the least. Somewhere some piece of code depends on the iteration order of the collection. The recent changes meant that HashSet's returned order changed and broke things. So you change to a LinkedHashSet which somehow restores the old order (or at least reorders it yet again but in a way that doesn't cause a problem). David From joe.darcy at oracle.com Wed Jun 20 01:28:40 2012 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 19 Jun 2012 18:28:40 -0700 Subject: hg: jdk8/tl/langtools: 7177701: error: Filling jar message during javax/imageio/metadata/IIOMetadataFormatImpl compilation In-Reply-To: <4FE123F2.9040403@oracle.com> References: <20120619122716.D48CE479ED@hg.openjdk.java.net> <4FE123F2.9040403@oracle.com> Message-ID: <4FE12748.1030703@oracle.com> Hi David, On 6/19/2012 6:14 PM, David Holmes wrote: > Hi Maurizio, > > On 19/06/2012 10:27 PM, maurizio.cimadamore at oracle.com wrote: >> Changeset: 34e254ffd0e7 >> Author: mcimadamore >> Date: 2012-06-19 13:25 +0100 >> URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/34e254ffd0e7 >> >> 7177701: error: Filling jar message during >> javax/imageio/metadata/IIOMetadataFormatImpl compilation >> Summary: Recent JDK hash changes affected order in which files are >> returned from JavacFileManager.list() >> Reviewed-by: jjg >> >> ! src/share/classes/com/sun/tools/javac/file/ZipFileIndex.java > > That change seems fragile to say the least. Somewhere some piece of > code depends on the iteration order of the collection. The recent > changes meant that HashSet's returned order changed and broke things. > So you change to a LinkedHashSet which somehow restores the old order > (or at least reorders it yet again but in a way that doesn't cause a > problem). > > David LinkedHashSet is specified to preserve insertion order in iteration: "This implementation [of LinkedHashSet] differs from HashSet in that it maintains a doubly-linked list running through all of its entries. This linked list defines the iteration ordering, which is the order in which elements were inserted into the set (insertion-order)." Therefore, LinkedHashSet is just the right class to use when predictable iteration order matters :-) -Joe From david.holmes at oracle.com Wed Jun 20 02:09:41 2012 From: david.holmes at oracle.com (David Holmes) Date: Wed, 20 Jun 2012 12:09:41 +1000 Subject: hg: jdk8/tl/langtools: 7177701: error: Filling jar message during javax/imageio/metadata/IIOMetadataFormatImpl compilation In-Reply-To: <4FE12748.1030703@oracle.com> References: <20120619122716.D48CE479ED@hg.openjdk.java.net> <4FE123F2.9040403@oracle.com> <4FE12748.1030703@oracle.com> Message-ID: <4FE130E5.8080902@oracle.com> Hi Joe, On 20/06/2012 11:28 AM, Joe Darcy wrote: > On 6/19/2012 6:14 PM, David Holmes wrote: >> On 19/06/2012 10:27 PM, maurizio.cimadamore at oracle.com wrote: >>> Changeset: 34e254ffd0e7 >>> Author: mcimadamore >>> Date: 2012-06-19 13:25 +0100 >>> URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/34e254ffd0e7 >>> >>> 7177701: error: Filling jar message during >>> javax/imageio/metadata/IIOMetadataFormatImpl compilation >>> Summary: Recent JDK hash changes affected order in which files are >>> returned from JavacFileManager.list() >>> Reviewed-by: jjg >>> >>> ! src/share/classes/com/sun/tools/javac/file/ZipFileIndex.java >> >> That change seems fragile to say the least. Somewhere some piece of >> code depends on the iteration order of the collection. The recent >> changes meant that HashSet's returned order changed and broke things. >> So you change to a LinkedHashSet which somehow restores the old order >> (or at least reorders it yet again but in a way that doesn't cause a >> problem). >> >> David > > LinkedHashSet is specified to preserve insertion order in iteration: > "This implementation [of LinkedHashSet] differs from HashSet in that it > maintains a doubly-linked list running through all of its entries. This > linked list defines the iteration ordering, which is the order in which > elements were inserted into the set (insertion-order)." > > Therefore, LinkedHashSet is just the right class to use when predictable > iteration order matters :-) So is there an assumption that traversal is in insertion order? Or is it just that insertion order happens to work? David > -Joe From martijnverburg at gmail.com Wed Jun 20 08:50:03 2012 From: martijnverburg at gmail.com (Martijn Verburg) Date: Wed, 20 Jun 2012 09:50:03 +0100 Subject: Bug 7176907 - Patches for javac warnings cleanup (text and util) from Adopt OpenJDK Message-ID: Hi Stuart, As requested - attached are 2 patch files, one covering util, the other text. I'm aware some fixes did go in recently, so if these patches are out of date and need re-spinning, then please let me know. Cheers, Martijn (on behalf of Adopt OpenJDK) From martijnverburg at gmail.com Wed Jun 20 11:51:04 2012 From: martijnverburg at gmail.com (Martijn Verburg) Date: Wed, 20 Jun 2012 12:51:04 +0100 Subject: Bug 7176907 - Patches for javac warnings cleanup (text and util) from Adopt OpenJDK In-Reply-To: References: Message-ID: Hi all, Apologies, I didn't check that attachments were stripped. The patches can be found at: https://raw.github.com/AdoptOpenJDK/PatchReview/master/submitted/core_java_text.patch https://raw.github.com/AdoptOpenJDK/PatchReview/master/submitted/core_java_util.patch Cheers, Martijn On 20 June 2012 09:50, Martijn Verburg wrote: > Hi Stuart, > > As requested - attached are 2 patch files, one covering util, the other text. > > I'm aware some fixes did go in recently, so if these patches are out > of date and need re-spinning, then please let me know. > > Cheers, > Martijn (on behalf of Adopt OpenJDK) From forax at univ-mlv.fr Wed Jun 20 14:08:28 2012 From: forax at univ-mlv.fr (=?UTF-8?B?UsOpbWkgRm9yYXg=?=) Date: Wed, 20 Jun 2012 16:08:28 +0200 Subject: Bug 7176907 - Patches for javac warnings cleanup (text and util) from Adopt OpenJDK In-Reply-To: References: Message-ID: <4FE1D95C.3030108@univ-mlv.fr> On 06/20/2012 01:51 PM, Martijn Verburg wrote: > Hi all, > > Apologies, I didn't check that attachments were stripped. The patches > can be found at: > > https://raw.github.com/AdoptOpenJDK/PatchReview/master/submitted/core_java_text.patch > https://raw.github.com/AdoptOpenJDK/PatchReview/master/submitted/core_java_util.patch > > Cheers, > Martijn Hi Martijn, the two patches looks good. A minor nit, why is there a space between the '(' and the readUByte() in readUShort. R?mi > > On 20 June 2012 09:50, Martijn Verburg wrote: >> Hi Stuart, >> >> As requested - attached are 2 patch files, one covering util, the other text. >> >> I'm aware some fixes did go in recently, so if these patches are out >> of date and need re-spinning, then please let me know. >> >> Cheers, >> Martijn (on behalf of Adopt OpenJDK) From martijnverburg at gmail.com Wed Jun 20 14:30:36 2012 From: martijnverburg at gmail.com (Martijn Verburg) Date: Wed, 20 Jun 2012 15:30:36 +0100 Subject: Bug 7176907 - Patches for javac warnings cleanup (text and util) from Adopt OpenJDK In-Reply-To: <4FE1D95C.3030108@univ-mlv.fr> References: <4FE1D95C.3030108@univ-mlv.fr> Message-ID: Hi Remi, On 20 June 2012 15:08, R?mi Forax wrote: > On 06/20/2012 01:51 PM, Martijn Verburg wrote: >> >> Hi all, >> >> Apologies, I didn't check that attachments were stripped. ?The patches >> can be found at: >> >> >> https://raw.github.com/AdoptOpenJDK/PatchReview/master/submitted/core_java_text.patch >> >> https://raw.github.com/AdoptOpenJDK/PatchReview/master/submitted/core_java_util.patch >> >> Cheers, >> Martijn > > > Hi Martijn, > the two patches looks good. > > A minor nit, why is there a space between the '(' and the readUByte() in > readUShort. Thanks for the quick review! No reason on the whitespace, I've fixed that now. Quick question. Is there a checkstyle or jcheck that we should be applying to any corelib patches going forwards? Cheers, Martijn From kurchi.subhra.hazra at oracle.com Wed Jun 20 16:07:53 2012 From: kurchi.subhra.hazra at oracle.com (Kurchi Subhra Hazra) Date: Wed, 20 Jun 2012 09:07:53 -0700 Subject: Bug 7176907 - Patches for javac warnings cleanup (text and util) from Adopt OpenJDK In-Reply-To: References: <4FE1D95C.3030108@univ-mlv.fr> Message-ID: <4FE1F559.5070802@oracle.com> Hi, I was just going through the patches, there are some more fallthrough cases in src/share/classes/java/util/regex/Pattern.java.(for example in line 2247). Are these not generating warnings? - Kurchi On 6/20/12 7:30 AM, Martijn Verburg wrote: >>> Hi all, >>> >>> Apologies, I didn't check that attachments were stripped. The patches >>> can be found at: >>> >>> >>> https://raw.github.com/AdoptOpenJDK/PatchReview/master/submitted/core_java_text.patch >>> >>> https://raw.github.com/AdoptOpenJDK/PatchReview/master/submitted/core_java_util.patch >>> >>> Cheers, >>> Martijn >> >> Hi Martijn, >> the two patches looks good. >> >> A minor nit, why is there a space between the '(' and the readUByte() in >> readUShort. > Thanks for the quick review! No reason on the whitespace, I've fixed that now. > > Quick question. Is there a checkstyle or jcheck that we should be > applying to any corelib patches going forwards? > > Cheers, > Martijn From martijnverburg at gmail.com Wed Jun 20 16:18:48 2012 From: martijnverburg at gmail.com (Martijn Verburg) Date: Wed, 20 Jun 2012 17:18:48 +0100 Subject: Bug 7176907 - Patches for javac warnings cleanup (text and util) from Adopt OpenJDK In-Reply-To: <4FE1F559.5070802@oracle.com> References: <4FE1D95C.3030108@univ-mlv.fr> <4FE1F559.5070802@oracle.com> Message-ID: We'll look into it, hopefully have an answer for you shortly - M On 20 June 2012 17:07, Kurchi Subhra Hazra wrote: > Hi, > > ? I was just going through the patches, there are some more fallthrough > cases in > src/share/classes/java/util/regex/Pattern.java.(for example in line 2247). > Are these not generating warnings? > > - Kurchi > > > On 6/20/12 7:30 AM, Martijn Verburg wrote: > > Hi all, > > Apologies, I didn't check that attachments were stripped. ?The patches > can be found at: > > > https://raw.github.com/AdoptOpenJDK/PatchReview/master/submitted/core_java_text.patch > > https://raw.github.com/AdoptOpenJDK/PatchReview/master/submitted/core_java_util.patch > > Cheers, > Martijn > > Hi Martijn, > the two patches looks good. > > A minor nit, why is there a space between the '(' and the readUByte() in > readUShort. > > Thanks for the quick review! No reason on the whitespace, I've fixed that > now. > > Quick question. Is there a checkstyle or jcheck that we should be > applying to any corelib patches going forwards? > > Cheers, > Martijn > > From jonathan.gibbons at oracle.com Wed Jun 20 20:37:07 2012 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Wed, 20 Jun 2012 20:37:07 +0000 Subject: hg: jdk8/tl/langtools: 7174143: encapsulate doc comment table Message-ID: <20120620203711.34B2747A3E@hg.openjdk.java.net> Changeset: 5c0b3faeb0b0 Author: jjg Date: 2012-06-20 13:23 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/5c0b3faeb0b0 7174143: encapsulate doc comment table Reviewed-by: ksrini, mcimadamore ! src/share/classes/com/sun/tools/javac/api/JavacTrees.java ! src/share/classes/com/sun/tools/javac/comp/Enter.java ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! src/share/classes/com/sun/tools/javac/jvm/CRTable.java ! src/share/classes/com/sun/tools/javac/jvm/Gen.java ! src/share/classes/com/sun/tools/javac/model/JavacElements.java - src/share/classes/com/sun/tools/javac/parser/EndPosTable.java ! src/share/classes/com/sun/tools/javac/parser/JavaTokenizer.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java + src/share/classes/com/sun/tools/javac/parser/SimpleDocCommentTable.java ! src/share/classes/com/sun/tools/javac/parser/Tokens.java + src/share/classes/com/sun/tools/javac/tree/DocCommentTable.java + src/share/classes/com/sun/tools/javac/tree/EndPosTable.java ! 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/TreeInfo.java ! src/share/classes/com/sun/tools/javac/util/DiagnosticSource.java ! src/share/classes/com/sun/tools/javac/util/JCDiagnostic.java ! src/share/classes/com/sun/tools/javac/util/Log.java ! src/share/classes/com/sun/tools/javadoc/JavadocEnter.java ! src/share/classes/com/sun/tools/javadoc/JavadocMemberEnter.java ! test/tools/javac/6304921/TestLog.java ! test/tools/javac/failover/CheckAttributedTree.java ! test/tools/javac/tree/DocCommentToplevelTest.java ! test/tools/javac/tree/TreePosTest.java From david.holmes at oracle.com Thu Jun 21 01:41:41 2012 From: david.holmes at oracle.com (David Holmes) Date: Thu, 21 Jun 2012 11:41:41 +1000 Subject: Trivial review: 7178483 - Change of Embedded version string Message-ID: <4FE27BD5.8090207@oracle.com> Trivial change to the Defs-embedded.gmk build file to change the version string used for SE Embedded. http://cr.openjdk.java.net/~dholmes/7178483/webrev/ or see below. Contributed by Gary Collins, and reviewed by myself. I'd appreciate one TL reviewer as I will push to TL. Thanks, David diff -r cdcbd22cfb9d make/common/Defs-embedded.gmk --- a/make/common/Defs-embedded.gmk +++ b/make/common/Defs-embedded.gmk @@ -42,7 +42,7 @@ OTHER_CPPFLAGS += -DJAVASE_EMBEDDED # Product naming -PRODUCT_SUFFIX = SE Runtime Environment for Embedded +PRODUCT_SUFFIX = SE Embedded Runtime Environment RUNTIME_NAME = $(PRODUCT_NAME) $(PRODUCT_SUFFIX) From Lance.Andersen at oracle.com Thu Jun 21 01:56:59 2012 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Wed, 20 Jun 2012 21:56:59 -0400 Subject: Trivial review: 7178483 - Change of Embedded version string In-Reply-To: <4FE27BD5.8090207@oracle.com> References: <4FE27BD5.8090207@oracle.com> Message-ID: Looks OK David On Jun 20, 2012, at 9:41 PM, David Holmes wrote: > Trivial change to the Defs-embedded.gmk build file to change the version string used for SE Embedded. > > http://cr.openjdk.java.net/~dholmes/7178483/webrev/ > > or see below. > > Contributed by Gary Collins, and reviewed by myself. I'd appreciate one TL reviewer as I will push to TL. > > Thanks, > David > > diff -r cdcbd22cfb9d make/common/Defs-embedded.gmk > --- a/make/common/Defs-embedded.gmk > +++ b/make/common/Defs-embedded.gmk > @@ -42,7 +42,7 @@ > OTHER_CPPFLAGS += -DJAVASE_EMBEDDED > > # Product naming > -PRODUCT_SUFFIX = SE Runtime Environment for Embedded > +PRODUCT_SUFFIX = SE Embedded Runtime Environment > RUNTIME_NAME = $(PRODUCT_NAME) $(PRODUCT_SUFFIX) 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 From david.holmes at oracle.com Thu Jun 21 04:41:37 2012 From: david.holmes at oracle.com (david.holmes at oracle.com) Date: Thu, 21 Jun 2012 04:41:37 +0000 Subject: hg: jdk8/tl/jdk: 7178483: Change version string for Embedded releases Message-ID: <20120621044159.3FDE547A59@hg.openjdk.java.net> Changeset: dfe5617c18b4 Author: dholmes Date: 2012-06-20 22:40 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/dfe5617c18b4 7178483: Change version string for Embedded releases Reviewed-by: dholmes, lancea Contributed-by: Gary Collins ! make/common/Defs-embedded.gmk From yiming.wang at oracle.com Thu Jun 21 06:05:11 2012 From: yiming.wang at oracle.com (Eric Wang) Date: Thu, 21 Jun 2012 14:05:11 +0800 Subject: Patch review request - Test bug 7123972 test/java/lang/annotation/loaderLeak/Main.java fails intermittently Message-ID: <4FE2B997.7090204@oracle.com> Hi All, I come from Java SQE team who are interested in regression test bug fix. Here is the first simple fix for bug 7123972 , Can you please help to review and comment? Attachment is the patch Thanks! This bug is caused by wrong assumption that the GC is started immediately to recycle un-referenced objects after System.gc() called one or two times. The proposed solution is to make sure the un-referenced object is recycled by GC before checking if the reference is null. Regards, Eric -------------- next part -------------- --- old/test/java/lang/annotation/loaderLeak/Main.java 2012-06-21 11:30:28.242617920 +0800 +++ new/test/java/lang/annotation/loaderLeak/Main.java 2012-06-21 11:30:26.828522968 +0800 @@ -36,6 +36,8 @@ import java.io.*; public class Main { + static volatile boolean GCIndicator = false; + public static void main(String[] args) throws Exception { for (int i=0; i<100; i++) doTest(args.length != 0); @@ -57,8 +59,10 @@ System.gc(); System.gc(); loader = null; - System.gc(); - System.gc(); + while(false == GCIndicator) { + System.gc(); + Thread.sleep(5); + } if (c.get() != null) throw new AssertionError(); } } @@ -67,6 +71,7 @@ private Hashtable classes = new Hashtable(); public SimpleClassLoader() { + Main.GCIndicator = false; } private byte getClassImplFromDataBase(String className)[] { byte result[]; @@ -124,4 +129,8 @@ classes.put(className, result); return result; } + + protected void finalize() { + Main.GCIndicator = true; + } } From david.holmes at oracle.com Thu Jun 21 06:32:27 2012 From: david.holmes at oracle.com (David Holmes) Date: Thu, 21 Jun 2012 16:32:27 +1000 Subject: Patch review request - Test bug 7123972 test/java/lang/annotation/loaderLeak/Main.java fails intermittently In-Reply-To: <4FE2B997.7090204@oracle.com> References: <4FE2B997.7090204@oracle.com> Message-ID: <4FE2BFFB.8010705@oracle.com> Hi Eric, On 21/06/2012 4:05 PM, Eric Wang wrote: > I come from Java SQE team who are interested in regression test bug fix. > Here is the first simple fix for bug 7123972 > , Can you please help > to review and comment? Attachment is the patch Thanks! > > This bug is caused by wrong assumption that the GC is started > immediately to recycle un-referenced objects after System.gc() called > one or two times. > > The proposed solution is to make sure the un-referenced object is > recycled by GC before checking if the reference is null. Your patch makes its own assumptions - specifically that finalization must eventually run. At a minimum you should add System.runFinalization() calls after the System.gc() inside the loop. Even that is no guarantee in a general sense, though it should work for hotspot. David > Regards, > Eric From huizhe.wang at oracle.com Thu Jun 21 07:55:44 2012 From: huizhe.wang at oracle.com (Joe Wang) Date: Thu, 21 Jun 2012 00:55:44 -0700 Subject: RFR [JDK8]: 7169894: JAXP Plugability Layer: using service loader Message-ID: <4FE2D380.2010803@oracle.com> Hi, This is a patch to replace the manual process in the 3rd step of the JAXP implementation resolution mechanism with ServiceLoader. Please see http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7169894 for more details about the issue. Note that FactoryFinder is duplicated for each JAXP subpackage. The ones in the following packages are the same: /jaxp-api/src/javax/xml/datatype/FactoryFinder.java /jaxp-api/src/javax/xml/parsers/FactoryFinder.java /jaxp-api/src/javax/xml/stream/FactoryFinder.java /jaxp-api/src/javax/xml/transform/FactoryFinder.java The following two are similar except that they perform Schema Language or Object Model support check: /jaxp-api/src/javax/xml/validation/SchemaFactoryFinder.java /jaxp-api/src/javax/xml/xpath/XPathFactoryFinder.java It's a bit rush since I have only had time to test regular JDK using JDK 1.6.0_27. Further test on jigsaw is needed. All jaxp unit/SQE tests are passed. But TCK test is still running. So please take this as an initial review. webrev: http://cr.openjdk.java.net/~joehw/jdk8/7169894/webrev/ Thanks, Joe From huizhe.wang at oracle.com Thu Jun 21 08:32:28 2012 From: huizhe.wang at oracle.com (Joe Wang) Date: Thu, 21 Jun 2012 01:32:28 -0700 Subject: RFR [JDK8]: 7169894: JAXP Plugability Layer: using service loader In-Reply-To: <4FE2D380.2010803@oracle.com> References: <4FE2D380.2010803@oracle.com> Message-ID: <4FE2DC1C.9020005@oracle.com> jaxp tck passed. Joe On 6/21/2012 12:55 AM, Joe Wang wrote: > Hi, > > This is a patch to replace the manual process in the 3rd step of the > JAXP implementation resolution mechanism with ServiceLoader. Please > see http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7169894 for > more details about the issue. > > Note that FactoryFinder is duplicated for each JAXP subpackage. The > ones in the following packages are the same: > /jaxp-api/src/javax/xml/datatype/FactoryFinder.java > /jaxp-api/src/javax/xml/parsers/FactoryFinder.java > /jaxp-api/src/javax/xml/stream/FactoryFinder.java > /jaxp-api/src/javax/xml/transform/FactoryFinder.java > > The following two are similar except that they perform Schema Language > or Object Model support check: > /jaxp-api/src/javax/xml/validation/SchemaFactoryFinder.java > /jaxp-api/src/javax/xml/xpath/XPathFactoryFinder.java > > It's a bit rush since I have only had time to test regular JDK using > JDK 1.6.0_27. Further test on jigsaw is needed. > All jaxp unit/SQE tests are passed. But TCK test is still running. So > please take this as an initial review. > > webrev: > http://cr.openjdk.java.net/~joehw/jdk8/7169894/webrev/ > > Thanks, > Joe > > From paul.sandoz at oracle.com Thu Jun 21 09:35:29 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 21 Jun 2012 11:35:29 +0200 Subject: RFR [JDK8]: 7169894: JAXP Plugability Layer: using service loader In-Reply-To: <4FE2D380.2010803@oracle.com> References: <4FE2D380.2010803@oracle.com> Message-ID: <36EF9FE3-70F2-4F95-BDD5-972FA0DD583E@oracle.com> Hi Joe, It looks a good start. There is duplication in the 6 factory finding classes, can some of it be consolidated in one shared factory helper class? Taking javax.xml.datatyoe.FactoryFinder as an example: When iterating over the service instances you are catching ConfigurationError 264 ServiceLoader loader = ServiceLoader.load(serviceClass, cl); 265 final Iterator providers = loader.iterator(); 266 while (providers.hasNext()) { 267 try { 268 Object provider = providers.next(); 269 if (provider.getClass().getName().contains(fallbackClassName)) { 270 defaultProvider = provider; 271 } else { 272 return provider; 273 } 274 } catch (ConfigurationError e) { 275 // This can happen because of class loader mismatch or any other reason. 276 // log and continue to next one 277 if (debug) { 278 dPrint("The provider can not be instantiated due to: " + e + "."); 279 } 280 } 281 } Did you mean ServiceConfigurationError? IIUC the previous code parsed a META-INF/services file and picked the first entry if present and attempt to instantiate that. I gather the approach you want to achieve with ServiceLoader is to "keep on trucking". In addition if nothing but an instance of the default service provider class is obtained then use that. From what i can tell the "fallbackClassName" parameter is a fully qualified class name so you need to do getName().equals(fallbackClassName). An alternative approach is to always assume that the default service provider class is never registered in META-INF/services or in module declaration. It should simplify things. You are first trying to use ServiceLoader with the thread context class loader, then if that fails using the system class loader (since FactoryFinder.class.getCLassLoader() == null). 234 private static Object findServiceProvider(String factoryId, String fallbackClassName) 235 throws ConfigurationError 236 { 237 final Class serviceClass; 238 try { 239 serviceClass = Class.forName(factoryId); 240 } catch (ClassNotFoundException e) { 241 throw new ConfigurationError("Unable to load " + factoryId, e); 242 } 243 244 Object provider = null; 245 246 // First try the Context ClassLoader 247 ClassLoader cl = ss.getContextClassLoader(); 248 if (cl != null) { 249 provider = findProvider(serviceClass, cl, fallbackClassName); 250 if (provider != null) return provider; 251 } 252 253 // If no provider found then try the current ClassLoader 254 provider = findProvider(serviceClass, FactoryFinder.class.getClassLoader(), fallbackClassName); 255 if (provider != null) return provider; 256 257 return null; 258 } I am wondering if we can just get away with using ServiceLoader.load(serviceClass), possibly not given the current implemented (but not documented) behavior. In any case we should document the class loaders being used, and in what order, with ServiceLoader. I am not so sure about the "keep on trucking" approach when iterating over service instances. The service mechanism is being used to register a factory class that is a service provider class. If the first item in the service instance iterator cannot be instantiated it signals a configuration error. -- I think the use of ServiceLoader by JAXP is really good input to improving ServiceLoader e.g.: ServiceLoader.withDefault(defaultServiceProviderClass).load(serviceInterface); or MyService serviceInstance = ServiceLoader.withDefault(defaultServiceProviderClass). first(serviceInterfaceClass); You could emulate this with your own shared factory helper class. Paul. On Jun 21, 2012, at 9:55 AM, Joe Wang wrote: > Hi, > > This is a patch to replace the manual process in the 3rd step of the JAXP implementation resolution mechanism with ServiceLoader. Please see http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7169894 for more details about the issue. > > Note that FactoryFinder is duplicated for each JAXP subpackage. The ones in the following packages are the same: > /jaxp-api/src/javax/xml/datatype/FactoryFinder.java > /jaxp-api/src/javax/xml/parsers/FactoryFinder.java > /jaxp-api/src/javax/xml/stream/FactoryFinder.java > /jaxp-api/src/javax/xml/transform/FactoryFinder.java > > The following two are similar except that they perform Schema Language or Object Model support check: > /jaxp-api/src/javax/xml/validation/SchemaFactoryFinder.java > /jaxp-api/src/javax/xml/xpath/XPathFactoryFinder.java > > It's a bit rush since I have only had time to test regular JDK using JDK 1.6.0_27. Further test on jigsaw is needed. > All jaxp unit/SQE tests are passed. But TCK test is still running. So please take this as an initial review. > > webrev: > http://cr.openjdk.java.net/~joehw/jdk8/7169894/webrev/ > > Thanks, > Joe > > From Alan.Bateman at oracle.com Thu Jun 21 10:18:34 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 21 Jun 2012 11:18:34 +0100 Subject: Patch review request - Test bug 7123972 test/java/lang/annotation/loaderLeak/Main.java fails intermittently In-Reply-To: <4FE2B997.7090204@oracle.com> References: <4FE2B997.7090204@oracle.com> Message-ID: <4FE2F4FA.8040700@oracle.com> On 21/06/2012 07:05, Eric Wang wrote: > Hi All, > > I come from Java SQE team who are interested in regression test bug > fix. Here is the first simple fix for bug 7123972 > , Can you please > help to review and comment? Attachment is the patch Thanks! > > This bug is caused by wrong assumption that the GC is started > immediately to recycle un-referenced objects after System.gc() called > one or two times. > > The proposed solution is to make sure the un-referenced object is > recycled by GC before checking if the reference is null. > > Regards, > Eric You should also remove the test from the exclude list (jdk/test/ProblemList.txt) so that it will be run again. Otherwise the change looks okay to me. I agree with David's comments that you could invoke runFinalization. I would also suggest increasing the sleep time from 5ms so that it's not spinning calling System.gc. A minor comment is that "while(false==GCIndicator)" looks a bit odd, maybe rename the flag to "finalized" and change it to "while (!finalized) { ... }". -Alan. From yiming.wang at oracle.com Thu Jun 21 10:57:48 2012 From: yiming.wang at oracle.com (Eric Wang) Date: Thu, 21 Jun 2012 18:57:48 +0800 Subject: Patch review request - Test bug 7123972 test/java/lang/annotation/loaderLeak/Main.java fails intermittently In-Reply-To: <4FE2BFFB.8010705@oracle.com> References: <4FE2B997.7090204@oracle.com> <4FE2BFFB.8010705@oracle.com> Message-ID: <4FE2FE2C.1020601@oracle.com> Hi David, Thanks for your review, I have updated the code by following your suggestion. please see the attachment. I'm not sure whether there's a better way to guarantee object finalized by GC definitely within the given time. The proposed fix may work in most cases but may still throw InterruptException if execution is timeout (2 minutes of JTreg by default). Regards, Eric On 2012/6/21 14:32, David Holmes wrote: > Hi Eric, > > On 21/06/2012 4:05 PM, Eric Wang wrote: >> I come from Java SQE team who are interested in regression test bug fix. >> Here is the first simple fix for bug 7123972 >> , Can you please help >> to review and comment? Attachment is the patch Thanks! >> >> This bug is caused by wrong assumption that the GC is started >> immediately to recycle un-referenced objects after System.gc() called >> one or two times. >> >> The proposed solution is to make sure the un-referenced object is >> recycled by GC before checking if the reference is null. > > Your patch makes its own assumptions - specifically that finalization > must eventually run. At a minimum you should add > System.runFinalization() calls after the System.gc() inside the loop. > Even that is no guarantee in a general sense, though it should work > for hotspot. > > David > > >> Regards, >> Eric -------------- next part -------------- --- old/test/java/lang/annotation/loaderLeak/Main.java 2012-06-21 18:49:27.668543285 +0800 +++ new/test/java/lang/annotation/loaderLeak/Main.java 2012-06-21 18:49:26.493507985 +0800 @@ -36,6 +36,8 @@ import java.io.*; public class Main { + static volatile boolean GCIndicator = false; + public static void main(String[] args) throws Exception { for (int i=0; i<100; i++) doTest(args.length != 0); @@ -57,8 +59,11 @@ System.gc(); System.gc(); loader = null; - System.gc(); - System.gc(); + while(false == GCIndicator) { + System.gc(); + System.runFinalization(); + Thread.sleep(5); + } if (c.get() != null) throw new AssertionError(); } } @@ -67,6 +72,7 @@ private Hashtable classes = new Hashtable(); public SimpleClassLoader() { + Main.GCIndicator = false; } private byte getClassImplFromDataBase(String className)[] { byte result[]; @@ -124,4 +130,8 @@ classes.put(className, result); return result; } + + protected void finalize() { + Main.GCIndicator = true; + } } From david.holmes at oracle.com Thu Jun 21 12:16:59 2012 From: david.holmes at oracle.com (David Holmes) Date: Thu, 21 Jun 2012 22:16:59 +1000 Subject: Patch review request - Test bug 7123972 test/java/lang/annotation/loaderLeak/Main.java fails intermittently In-Reply-To: <4FE2FE2C.1020601@oracle.com> References: <4FE2B997.7090204@oracle.com> <4FE2BFFB.8010705@oracle.com> <4FE2FE2C.1020601@oracle.com> Message-ID: <4FE310BB.6000100@oracle.com> Hi Eric, On 21/06/2012 8:57 PM, Eric Wang wrote: > Hi David, > > Thanks for your review, I have updated the code by following your > suggestion. please see the attachment. > I'm not sure whether there's a better way to guarantee object finalized > by GC definitely within the given time. The proposed fix may work in > most cases but may still throw InterruptException if execution is > timeout (2 minutes of JTreg by default). There is no way to guarantee finalization in a specific timeframe, but if a simple test hasn't executed finalizers in 2 minutes then that in itself indicates a problem. Can you post a full webrev for this patch? I don't like seeing it out of context and am wondering exactly what we are trying to GC here. David > Regards, > Eric > > On 2012/6/21 14:32, David Holmes wrote: >> Hi Eric, >> >> On 21/06/2012 4:05 PM, Eric Wang wrote: >>> I come from Java SQE team who are interested in regression test bug fix. >>> Here is the first simple fix for bug 7123972 >>> , Can you please help >>> to review and comment? Attachment is the patch Thanks! >>> >>> This bug is caused by wrong assumption that the GC is started >>> immediately to recycle un-referenced objects after System.gc() called >>> one or two times. >>> >>> The proposed solution is to make sure the un-referenced object is >>> recycled by GC before checking if the reference is null. >> >> Your patch makes its own assumptions - specifically that finalization >> must eventually run. At a minimum you should add >> System.runFinalization() calls after the System.gc() inside the loop. >> Even that is no guarantee in a general sense, though it should work >> for hotspot. >> >> David >> >> >>> Regards, >>> Eric > From Alan.Bateman at oracle.com Thu Jun 21 12:44:11 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 21 Jun 2012 13:44:11 +0100 Subject: RFR [JDK8]: 7169894: JAXP Plugability Layer: using service loader In-Reply-To: <4FE2D380.2010803@oracle.com> References: <4FE2D380.2010803@oracle.com> Message-ID: <4FE3171B.8080900@oracle.com> On 21/06/2012 08:55, Joe Wang wrote: > : > webrev: > http://cr.openjdk.java.net/~joehw/jdk8/7169894/webrev/ It's great to get this work started. The javadoc changes look okay to me and fine for this change. However there are a few areas that could be made clearer, like specifying the behavior for the case that is error encountered locating the providers. Also it does not specific which class loader is used. On the implementation changes then I agree with Paul's comment that there is a lot of duplication. I realize you have inherited some technical debt but now seems a good opportunity to clean this up instead of changing essentially the same code in lots of places. I don't understand the need for the Class.forName in findServiceProvider as I thought this method should just use ServiceLoader. I see Paul also suggested that the default/fallback implementation not be registered but an important need here is that the JAXP module shouldn't need to include all of Xerces and Xalan. I think it would be cleaner to use services mechanism rather than using an optional dependency. -Alan. From paul.sandoz at oracle.com Thu Jun 21 13:34:31 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 21 Jun 2012 15:34:31 +0200 Subject: RFR [JDK8]: 7169894: JAXP Plugability Layer: using service loader In-Reply-To: <4FE3171B.8080900@oracle.com> References: <4FE2D380.2010803@oracle.com> <4FE3171B.8080900@oracle.com> Message-ID: <3DEA3871-6150-4692-8E86-F128E4B479A5@oracle.com> On Jun 21, 2012, at 2:44 PM, Alan Bateman wrote: > On 21/06/2012 08:55, Joe Wang wrote: >> : >> webrev: >> http://cr.openjdk.java.net/~joehw/jdk8/7169894/webrev/ > It's great to get this work started. > > The javadoc changes look okay to me and fine for this change. However there are a few areas that could be made clearer, like specifying the behavior for the case that is error encountered locating the providers. Also it does not specific which class loader is used. > > On the implementation changes then I agree with Paul's comment that there is a lot of duplication. I realize you have inherited some technical debt but now seems a good opportunity to clean this up instead of changing essentially the same code in lots of places. > > I don't understand the need for the Class.forName in findServiceProvider as I thought this method should just use ServiceLoader. > Good catch, one would expect the service interfaces to be visible. > I see Paul also suggested that the default/fallback implementation not be registered but an important need here is that the JAXP module shouldn't need to include all of Xerces and Xalan. I think it would be cleaner to use services mechanism rather than using an optional dependency. > Ah! I incorrectly thought a default service provider class would always be present. Paul. From jim.gish at oracle.com Thu Jun 21 15:59:47 2012 From: jim.gish at oracle.com (Jim Gish) Date: Thu, 21 Jun 2012 11:59:47 -0400 Subject: Review Request: CR 7100996 - (spec str) IndexOutOfBoundsException when using a StringBuffer from multiple threads Message-ID: <4FE344F3.6080802@oracle.com> Please review the proposed spec change to StringBuffer below, which informs the user about additional thread safety issues as described in the bug. (Thanks to Brian for the language). Thanks, Jim diff -r 46ff1b63b0c3 src/share/classes/java/lang/StringBuffer.java --- a/src/share/classes/java/lang/StringBuffer.java Mon Jun 11 07:10:48 2012 -0400 +++ b/src/share/classes/java/lang/StringBuffer.java Thu Jun 21 11:45:51 2012 -0400 @@ -63,6 +63,14 @@ * appending or inserting from a source sequence) this class synchronizes * only on the string buffer performing the operation, not on the source. *

+ * While StringBuffer is designed to be safe to use concurrently from + * multiple threads, the source data passed to append/insert, if shared + * across threads, must ensure that StringBuffer.add/insert has a + * consistent and unchanging view of the source data for the duration of + * the operation. This could be done by the caller holding a lock during + * the add/insert call, or because the source data is immutable, or because + * the source data is not shared across threads. + *

* Every string buffer has a capacity. As long as the length of the * character sequence contained in the string buffer does not exceed * the capacity, it is not necessary to allocate a new internal -- Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304 Oracle Java Platform Group | Core Libraries Team 35 Network Drive Burlington, MA 01803 jim.gish at oracle.com From Ulf.Zibis at CoSoCo.de Thu Jun 21 16:12:05 2012 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Thu, 21 Jun 2012 18:12:05 +0200 Subject: Review Request: CR 7100996 - (spec str) IndexOutOfBoundsException when using a StringBuffer from multiple threads In-Reply-To: <4FE344F3.6080802@oracle.com> References: <4FE344F3.6080802@oracle.com> Message-ID: <4FE347D5.6080007@CoSoCo.de> I would understand, what is meant. Looks good to me. -Ulf Am 21.06.2012 17:59, schrieb Jim Gish: > Please review the proposed spec change to StringBuffer below, which informs the user about > additional thread safety issues as described in the bug. (Thanks to Brian for the language). > > Thanks, > Jim > > diff -r 46ff1b63b0c3 src/share/classes/java/lang/StringBuffer.java > --- a/src/share/classes/java/lang/StringBuffer.java Mon Jun 11 07:10:48 2012 -0400 > +++ b/src/share/classes/java/lang/StringBuffer.java Thu Jun 21 11:45:51 2012 -0400 > @@ -63,6 +63,14 @@ > * appending or inserting from a source sequence) this class synchronizes > * only on the string buffer performing the operation, not on the source. > *

> + * While StringBuffer is designed to be safe to use concurrently from > + * multiple threads, the source data passed to append/insert, if shared > + * across threads, must ensure that StringBuffer.add/insert has a > + * consistent and unchanging view of the source data for the duration of > + * the operation. This could be done by the caller holding a lock during > + * the add/insert call, or because the source data is immutable, or because > + * the source data is not shared across threads. > + *

> * Every string buffer has a capacity. As long as the length of the > * character sequence contained in the string buffer does not exceed > * the capacity, it is not necessary to allocate a new internal > From dl at cs.oswego.edu Thu Jun 21 16:15:37 2012 From: dl at cs.oswego.edu (Doug Lea) Date: Thu, 21 Jun 2012 12:15:37 -0400 Subject: Review Request: CR 7100996 - (spec str) IndexOutOfBoundsException when using a StringBuffer from multiple threads In-Reply-To: <4FE344F3.6080802@oracle.com> References: <4FE344F3.6080802@oracle.com> Message-ID: <4FE348A9.3050206@cs.oswego.edu> On 06/21/12 11:59, Jim Gish wrote: > Please review the proposed spec change to StringBuffer below, which informs the > user about additional thread safety issues as described in the bug. (Thanks to > Brian for the language). Brian: Nice wording! It misses mentioning the constructor StringBuffer(CharSequence seq) case though. Perhaps change: multiple threads, the source data passed to append/insert, if shared to multiple threads, the source data passed to create/append/insert, if shared With this change, the paragraph could also be readily adapted to also be placed in class java.util.Vector, that infamously has similar issues. (For which I suspect there is some CR). ... and possibly further adapted in some other Collection methods when they are next updated for other reasons. -Doug > > Thanks, > Jim > > diff -r 46ff1b63b0c3 src/share/classes/java/lang/StringBuffer.java > --- a/src/share/classes/java/lang/StringBuffer.java Mon Jun 11 07:10:48 2012 -0400 > +++ b/src/share/classes/java/lang/StringBuffer.java Thu Jun 21 11:45:51 2012 -0400 > @@ -63,6 +63,14 @@ > * appending or inserting from a source sequence) this class synchronizes > * only on the string buffer performing the operation, not on the source. > *

> + * While StringBuffer is designed to be safe to use concurrently from > + * multiple threads, the source data passed to append/insert, if shared > + * across threads, must ensure that StringBuffer.add/insert has a > + * consistent and unchanging view of the source data for the duration of > + * the operation. This could be done by the caller holding a lock during > + * the add/insert call, or because the source data is immutable, or because > + * the source data is not shared across threads. > + *

> * Every string buffer has a capacity. As long as the length of the > * character sequence contained in the string buffer does not exceed > * the capacity, it is not necessary to allocate a new internal > From schlosna at gmail.com Thu Jun 21 16:49:21 2012 From: schlosna at gmail.com (David Schlosnagle) Date: Thu, 21 Jun 2012 12:49:21 -0400 Subject: Review Request: CR 7100996 - (spec str) IndexOutOfBoundsException when using a StringBuffer from multiple threads In-Reply-To: <4FE344F3.6080802@oracle.com> References: <4FE344F3.6080802@oracle.com> Message-ID: On Thu, Jun 21, 2012 at 11:59 AM, Jim Gish wrote: > + * across threads, must ensure that StringBuffer.add/insert has a Jim, You may want to replace "add" with "append" if you are intending to reference the actual method name and not the generic operation. Additionally, you may want to use {@code ...} to show this context. Thanks, Dave From huizhe.wang at oracle.com Thu Jun 21 17:34:12 2012 From: huizhe.wang at oracle.com (Joe Wang) Date: Thu, 21 Jun 2012 10:34:12 -0700 Subject: RFR [JDK8]: 7169894: JAXP Plugability Layer: using service loader In-Reply-To: <36EF9FE3-70F2-4F95-BDD5-972FA0DD583E@oracle.com> References: <4FE2D380.2010803@oracle.com> <36EF9FE3-70F2-4F95-BDD5-972FA0DD583E@oracle.com> Message-ID: <4FE35B14.6050802@oracle.com> On 6/21/2012 2:35 AM, Paul Sandoz wrote: > Hi Joe, > > It looks a good start. Thanks for the detailed review! > > There is duplication in the 6 factory finding classes, can some of it > be consolidated in one shared factory helper class? The duplication of FactoryFinder and SecuritySupport classes was determined by the security team at the time in that these classes should not be made public. The same existed in the RI. In a recent security change, we removed 52 duplicated classes and used package restriction instead. I could consult security if we want to do that. > > Taking javax.xml.datatyoe.FactoryFinder as an example: > > When iterating over the service instances you are catching > ConfigurationError > > 264 ServiceLoader loader = ServiceLoader.load(serviceClass, cl); > 265 final Iterator providers = loader.iterator(); > 266 while (providers.hasNext()) { > 267 try { > 268 Object provider = providers.next(); > 269 if (provider.getClass().getName().contains(fallbackClassName)) { > 270 defaultProvider = provider; > 271 } else { > 272 return provider; > 273 } > 274 } catch (ConfigurationError e) { > 275 // This can happen because of class loader mismatch or any other reason. > 276 // log and continue to next one > 277 if (debug) { > 278 dPrint("The provider can not be instantiated due to: " + e + "."); > 279 } > 280 } > 281 } > Did you mean ServiceConfigurationError? ConfigurationError is internally defined. It's a contract between the Factory and FactoryFinder classes. It seems to me it was a result of sharing the FactoryFinders and different exception types defined in the spec for different factories. > > IIUC the previous code parsed a META-INF/services file and picked the > first entry if present and attempt to instantiate that. > > I gather the approach you want to achieve with ServiceLoader is to > "keep on trucking". In addition if nothing but an instance of the > default service provider class is obtained then use that. From what i > can tell the "fallbackClassName" parameter is a fully qualified class > name so you need to do getName().equals(fallbackClassName). > > An alternative approach is to always assume that the default service > provider class is never registered in META-INF/services or in module > declaration. It should simplify things. JAXP is an supported endorsed technology. It can be placed in the endorsed directory or bootclasspath to replace the default impl. When a 3rd party impl is on the class path however, it should take preference over the default impl, thus the check for the one loaded by the context class loader. The ServiceLoader however, is doing a lot more than the original META-INF/services process. It's finding providers installed "in the form of extensions" and placed on the class path, it therefore always loads JAXP whether it's in the endorsed directory or bootclasspath. That's the reason I cached it as default impl intended to be used to replace that in the JDK. When a 3rd party impl is on the classpath, we still need to let it take preference. > > You are first trying to use ServiceLoader with the thread context > class loader, then if that fails using the system class loader (since > FactoryFinder.class.getCLassLoader() == null). > > 234 private static Object findServiceProvider(String factoryId, String fallbackClassName) > 235 throws ConfigurationError > 236 { > 237 final Class serviceClass; > 238 try { > 239 serviceClass = Class.forName(factoryId); > 240 } catch (ClassNotFoundException e) { > 241 throw new ConfigurationError("Unable to load " + factoryId, e); > 242 } > 243 > 244 Object provider = null; > 245 > 246 // First try the Context ClassLoader > 247 ClassLoader cl = ss.getContextClassLoader(); > 248 if (cl != null) { > 249 provider = findProvider(serviceClass, cl, fallbackClassName); > 250 if (provider != null) return provider; > 251 } > 252 > 253 // If no provider found then try the current ClassLoader > 254 provider = findProvider(serviceClass, FactoryFinder.class.getClassLoader(), fallbackClassName); > 255 if (provider != null) return provider; > 256 > 257 return null; > 258 } > I am wondering if we can just get away with using > ServiceLoader.load(serviceClass), possibly not given the current > implemented (but not documented) behavior. In any case we should > document the class loaders being used, and in what order, with > ServiceLoader. Yes, that's when I observed too that the ServiceLoader is doing more as I described above. > > I am not so sure about the "keep on trucking" approach when iterating > over service instances. The service mechanism is being used to > register a factory class that is a service provider class. If the > first item in the service instance iterator cannot be instantiated it > signals a configuration error. As I mentioned above, the first found can be jaxp RI. > > -- > > I think the use of ServiceLoader by JAXP is really good input to > improving ServiceLoader e.g.: > > > ServiceLoader.withDefault(defaultServiceProviderClass).load(serviceInterface); > > or > > MyService serviceInstance = > ServiceLoader.withDefault(defaultServiceProviderClass). > first(serviceInterfaceClass); > > You could emulate this with your own shared factory helper class. That would be nice. One other thing I noticed was that .load returns an instance. There's a situation where a static method or constructor with a parameter instead of the default constructor may be called to initiate the provider. -Joe > > Paul. > > > > On Jun 21, 2012, at 9:55 AM, Joe Wang wrote: > >> Hi, >> >> This is a patch to replace the manual process in the 3rd step of the >> JAXP implementation resolution mechanism with ServiceLoader. Please >> see http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7169894 for >> more details about the issue. >> >> Note that FactoryFinder is duplicated for each JAXP subpackage. The >> ones in the following packages are the same: >> /jaxp-api/src/javax/xml/datatype/FactoryFinder.java >> /jaxp-api/src/javax/xml/parsers/FactoryFinder.java >> /jaxp-api/src/javax/xml/stream/FactoryFinder.java >> /jaxp-api/src/javax/xml/transform/FactoryFinder.java >> >> The following two are similar except that they perform Schema >> Language or Object Model support check: >> /jaxp-api/src/javax/xml/validation/SchemaFactoryFinder.java >> /jaxp-api/src/javax/xml/xpath/XPathFactoryFinder.java >> >> It's a bit rush since I have only had time to test regular JDK using >> JDK 1.6.0_27. Further test on jigsaw is needed. >> All jaxp unit/SQE tests are passed. But TCK test is still running. >> So please take this as an initial review. >> >> webrev: >> http://cr.openjdk.java.net/~joehw/jdk8/7169894/webrev/ >> >> >> Thanks, >> Joe >> >> > From huizhe.wang at oracle.com Thu Jun 21 18:02:26 2012 From: huizhe.wang at oracle.com (Joe Wang) Date: Thu, 21 Jun 2012 11:02:26 -0700 Subject: RFR [JDK8]: 7169894: JAXP Plugability Layer: using service loader In-Reply-To: <4FE3171B.8080900@oracle.com> References: <4FE2D380.2010803@oracle.com> <4FE3171B.8080900@oracle.com> Message-ID: <4FE361B2.6090502@oracle.com> On 6/21/2012 5:44 AM, Alan Bateman wrote: > On 21/06/2012 08:55, Joe Wang wrote: >> : >> webrev: >> http://cr.openjdk.java.net/~joehw/jdk8/7169894/webrev/ > It's great to get this work started. > > The javadoc changes look okay to me and fine for this change. However > there are a few areas that could be made clearer, like specifying the > behavior for the case that is error encountered locating the > providers. Also it does not specific which class loader is used. Also, javax.xml.transform.TransformerFactory begins with the following: The system property that determines which Factory implementation to create is named |"javax.xml.transform.TransformerFactory"|. This property names a concrete subclass of the |TransformerFactory| abstract class. If the property is not defined, a platform default is be used. That's misleading as well. I'll update the javadoc for the next review. For the class loader, as discussed with Paul, since the ServiceLoader does so much, we may be able to skip the 'using different classloader' part, that is, simply calling load without classloader. The javadoc states that it's equivalent to load with context class loader. But from what I can, it found all that's placed in the endorsed dir or bootclasspath. I need to do a few more tests on this. > > On the implementation changes then I agree with Paul's comment that > there is a lot of duplication. I realize you have inherited some > technical debt but now seems a good opportunity to clean this up > instead of changing essentially the same code in lots of places. As discussed, it's security required. > > I don't understand the need for the Class.forName in > findServiceProvider as I thought this method should just use > ServiceLoader. For XPath, Transformer, Datatype and Validation, it's possible get rid of that since the factory finder is dedicated to a single factory. For the parsers and stream, it's shared by multiple factories, Class.forName is used to return Class by name, or factory id. Once we're clear on what the other three steps that also use the factory id would become, we can possibly further improve. > > I see Paul also suggested that the default/fallback implementation not > be registered but an important need here is that the JAXP module > shouldn't need to include all of Xerces and Xalan. I think it would be > cleaner to use services mechanism rather than using an optional > dependency. Maybe I'm a little confused. But the fallback to default implementation is in the spec. It happens the jaxp ri is installed as an endorsed technology here and loaded by the ServiceLoader. -Joe > > -Alan. > > From Alan.Bateman at oracle.com Thu Jun 21 18:04:46 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 21 Jun 2012 19:04:46 +0100 Subject: RFR [JDK8]: 7169894: JAXP Plugability Layer: using service loader In-Reply-To: <4FE35B14.6050802@oracle.com> References: <4FE2D380.2010803@oracle.com> <36EF9FE3-70F2-4F95-BDD5-972FA0DD583E@oracle.com> <4FE35B14.6050802@oracle.com> Message-ID: <4FE3623E.9040005@oracle.com> On 21/06/2012 18:34, Joe Wang wrote: > > : >> >> When iterating over the service instances you are catching >> ConfigurationError >> >> 264 ServiceLoader loader = ServiceLoader.load(serviceClass, >> cl); >> 265 final Iterator providers = loader.iterator(); >> 266 while (providers.hasNext()) { >> 267 try { >> 268 Object provider = providers.next(); >> 269 if >> (provider.getClass().getName().contains(fallbackClassName)) { >> 270 defaultProvider = provider; >> 271 } else { >> 272 return provider; >> 273 } >> 274 } catch (ConfigurationError e) { >> 275 // This can happen because of class loader >> mismatch or any other reason. >> 276 // log and continue to next one >> 277 if (debug) { >> 278 dPrint("The provider can not be >> instantiated due to: " + e + "."); >> 279 } >> 280 } >> 281 } >> Did you mean ServiceConfigurationError? > > ConfigurationError is internally defined. It's a contract between the > Factory and FactoryFinder classes. It seems to me it was a result of > sharing the FactoryFinders and different exception types defined in > the spec for different factories. With ServicLoader then ServiceConfigurationError is thrown if there is a problem reading the service configuration file or the concrete type is not a sub-type or it cannot be instantiated. With JAXP then I think most of the places it is specified to throw a JAXP ConfigurationException when the provider cannot be instantiated (it seems to be silent as to issues encountered reading the service configuration file). Minimally the above code will need to be changed to catch ServiceConfigurationError. Whether it ignores it and attempts to continue, or throws a JAXP ConfigurationError needs needs consideration. The existing behavior seems to be to ignore IOExceptions if there is a problem reading the service configuration file but I don't think it can distinguish this case when it gets a SCE. Therefore the safest thing may be to just throw ConfiguarationError and the callers of the factory finder call will translate it into the appropriate (and specified) JAXP *ConfigurationException. -Alan. From jim.gish at oracle.com Thu Jun 21 18:10:42 2012 From: jim.gish at oracle.com (Jim Gish) Date: Thu, 21 Jun 2012 14:10:42 -0400 Subject: Review Request: CR 7100996 - (spec str) IndexOutOfBoundsException when using a StringBuffer from multiple threads In-Reply-To: References: <4FE344F3.6080802@oracle.com> Message-ID: <4FE363A2.2080308@oracle.com> Taking all the previous comments into consideration, here's an update: diff -r fc575c78f5d3 src/share/classes/java/lang/StringBuffer.java --- a/src/share/classes/java/lang/StringBuffer.java Sun Jun 10 10:29:27 2012 +0100 +++ b/src/share/classes/java/lang/StringBuffer.java Thu Jun 21 14:09:17 2012 -0400 @@ -63,6 +63,16 @@ * appending or inserting from a source sequence) this class synchronizes * only on the string buffer performing the operation, not on the source. *

+ * While StringBuffer is designed to be safe to use + * concurrently from multiple threads, the source data passed to create, + * i.e. StringBuffer(source), append(source), + * or insert(source), if shared across threads, must ensure + * that create/append/insert has a consistent and unchanging + * view of the source data for the duration of the operation. This could + * be done by the caller holding a lock during the + * create/append/insert call, or because the source data is + * immutable, or because the source data is not shared across threads. + *

* Every string buffer has a capacity. As long as the length of the * character sequence contained in the string buffer does not exceed * the capacity, it is not necessary to allocate a new internal Thanks, Jim On 06/21/2012 12:49 PM, David Schlosnagle wrote: > On Thu, Jun 21, 2012 at 11:59 AM, Jim Gish wrote: >> + * across threads, must ensure that StringBuffer.add/insert has a > Jim, > > You may want to replace "add" with "append" if you are intending to > reference the actual method name and not the generic operation. > Additionally, you may want to use {@code ...} to show this context. > > Thanks, > Dave -- Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304 Oracle Java Platform Group | Core Libraries Team 35 Network Drive Burlington, MA 01803 jim.gish at oracle.com From mike.duigou at oracle.com Thu Jun 21 18:55:11 2012 From: mike.duigou at oracle.com (Mike Duigou) Date: Thu, 21 Jun 2012 11:55:11 -0700 Subject: Review Request: CR 7100996 - (spec str) IndexOutOfBoundsException when using a StringBuffer from multiple threads In-Reply-To: <4FE363A2.2080308@oracle.com> References: <4FE344F3.6080802@oracle.com> <4FE363A2.2080308@oracle.com> Message-ID: Great addition! I believe you should be using {@code} rather than tags. I would say "constructors" rather than "create". I would add the word "operation" after the first instance of "create/append/insert" I would change "This could be done" to "This could be satisfied" Mike On Jun 21 2012, at 11:10 , Jim Gish wrote: > Taking all the previous comments into consideration, here's an update: > > diff -r fc575c78f5d3 src/share/classes/java/lang/StringBuffer.java > --- a/src/share/classes/java/lang/StringBuffer.java Sun Jun 10 10:29:27 2012 +0100 > +++ b/src/share/classes/java/lang/StringBuffer.java Thu Jun 21 14:09:17 2012 -0400 > @@ -63,6 +63,16 @@ > * appending or inserting from a source sequence) this class synchronizes > * only on the string buffer performing the operation, not on the source. > *

> + * While StringBuffer is designed to be safe to use > + * concurrently from multiple threads, the source data passed to create, > + * i.e. StringBuffer(source), append(source), > + * or insert(source), if shared across threads, must ensure > + * that create/append/insert has a consistent and unchanging > + * view of the source data for the duration of the operation. This could > + * be done by the caller holding a lock during the > + * create/append/insert call, or because the source data is > + * immutable, or because the source data is not shared across threads. > + *

> * Every string buffer has a capacity. As long as the length of the > * character sequence contained in the string buffer does not exceed > * the capacity, it is not necessary to allocate a new internal > > Thanks, > Jim > > On 06/21/2012 12:49 PM, David Schlosnagle wrote: >> On Thu, Jun 21, 2012 at 11:59 AM, Jim Gish wrote: >>> + * across threads, must ensure that StringBuffer.add/insert has a >> Jim, >> >> You may want to replace "add" with "append" if you are intending to >> reference the actual method name and not the generic operation. >> Additionally, you may want to use {@code ...} to show this context. >> >> Thanks, >> Dave > > -- > Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304 > Oracle Java Platform Group | Core Libraries Team > 35 Network Drive > Burlington, MA 01803 > jim.gish at oracle.com > From jonathan.gibbons at oracle.com Thu Jun 21 20:22:32 2012 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Thu, 21 Jun 2012 20:22:32 +0000 Subject: hg: jdk8/tl/langtools: 7178297: provide mapping from doc comment position to source file position Message-ID: <20120621202236.BD8B347A72@hg.openjdk.java.net> Changeset: 067f51db3402 Author: jjg Date: 2012-06-21 13:22 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/067f51db3402 7178297: provide mapping from doc comment position to source file position Reviewed-by: mcimadamore, ksrini ! src/share/classes/com/sun/tools/javac/parser/JavaTokenizer.java ! src/share/classes/com/sun/tools/javac/parser/JavadocTokenizer.java ! src/share/classes/com/sun/tools/javac/parser/Tokens.java ! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java From jim.gish at oracle.com Thu Jun 21 20:44:23 2012 From: jim.gish at oracle.com (Jim Gish) Date: Thu, 21 Jun 2012 16:44:23 -0400 Subject: Review Request: CR 7100996 - (spec str) IndexOutOfBoundsException when using a StringBuffer from multiple threads In-Reply-To: References: <4FE344F3.6080802@oracle.com> <4FE363A2.2080308@oracle.com> Message-ID: <4FE387A7.1010806@oracle.com> I did this, and also simplified the language a bit: diff -r 7722e2bec02b src/share/classes/java/lang/StringBuffer.java --- a/src/share/classes/java/lang/StringBuffer.java Thu Jun 21 16:26:04 2012 -0400 +++ b/src/share/classes/java/lang/StringBuffer.java Thu Jun 21 16:42:19 2012 -0400 @@ -63,14 +63,15 @@ * appending or inserting from a source sequence) this class synchronizes * only on the string buffer performing the operation, not on the source. *

+ * Although {@code StringBuffer} is designed to be safe to use + * concurrently from multiple threads, if the source data passed + * to the constructor, i.e. {@code StringBuffer(source)}, or to the + * {@code append(source)}, or {@code insert(source)} operations + * is shared across threads, it must be ensured that the operations have + * a consistent and unchanging view of the source data for the duration + * of the operation. + * This could be satisfied by the caller holding a lock during the + * operation's call, or because the source data is * immutable, or because the source data is not shared across threads. *

* Every string buffer has a capacity. As long as the length of the Thanks, Jim On 06/21/2012 02:55 PM, Mike Duigou wrote: > Great addition! > > I believe you should be using {@code} rather than tags. > > I would say "constructors" rather than "create". > > I would add the word "operation" after the first instance of "create/append/insert" > > I would change "This could be done" to "This could be satisfied" > > Mike > > On Jun 21 2012, at 11:10 , Jim Gish wrote: > >> Taking all the previous comments into consideration, here's an update: >> >> diff -r fc575c78f5d3 src/share/classes/java/lang/StringBuffer.java >> --- a/src/share/classes/java/lang/StringBuffer.java Sun Jun 10 10:29:27 2012 +0100 >> +++ b/src/share/classes/java/lang/StringBuffer.java Thu Jun 21 14:09:17 2012 -0400 >> @@ -63,6 +63,16 @@ >> * appending or inserting from a source sequence) this class synchronizes >> * only on the string buffer performing the operation, not on the source. >> *

>> + * WhileStringBuffer is designed to be safe to use >> + * concurrently from multiple threads, the source data passed to create, >> + * i.e.StringBuffer(source),append(source), >> + * orinsert(source), if shared across threads, must ensure >> + * thatcreate/append/insert has a consistent and unchanging >> + * view of the source data for the duration of the operation. This could >> + * be done by the caller holding a lock during the >> + *create/append/insert call, or because the source data is >> + * immutable, or because the source data is not shared across threads. >> + *

>> * Every string buffer has a capacity. As long as the length of the >> * character sequence contained in the string buffer does not exceed >> * the capacity, it is not necessary to allocate a new internal >> >> Thanks, >> Jim >> >> On 06/21/2012 12:49 PM, David Schlosnagle wrote: >>> On Thu, Jun 21, 2012 at 11:59 AM, Jim Gish wrote: >>>> + * across threads, must ensure that StringBuffer.add/insert has a >>> Jim, >>> >>> You may want to replace "add" with "append" if you are intending to >>> reference the actual method name and not the generic operation. >>> Additionally, you may want to use {@code ...} to show this context. >>> >>> Thanks, >>> Dave >> -- >> Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304 >> Oracle Java Platform Group | Core Libraries Team >> 35 Network Drive >> Burlington, MA 01803 >> jim.gish at oracle.com >> -- Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304 Oracle Java Platform Group | Core Libraries Team 35 Network Drive Burlington, MA 01803 jim.gish at oracle.com From Alan.Bateman at oracle.com Thu Jun 21 21:00:24 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 21 Jun 2012 22:00:24 +0100 Subject: RFR [JDK8]: 7169894: JAXP Plugability Layer: using service loader In-Reply-To: <4FE361B2.6090502@oracle.com> References: <4FE2D380.2010803@oracle.com> <4FE3171B.8080900@oracle.com> <4FE361B2.6090502@oracle.com> Message-ID: <4FE38B68.5020601@oracle.com> On 21/06/2012 19:02, Joe Wang wrote: > > : > > For the class loader, as discussed with Paul, since the ServiceLoader > does so much, we may be able to skip the 'using different classloader' > part, that is, simply calling load without classloader. The javadoc > states that it's equivalent to load with context class loader. But > from what I can, it found all that's placed in the endorsed dir or > bootclasspath. I need to do a few more tests on this. It doesn't seem to be specified but the implementation (in at least some places) appears to use the TCCL or the defining loader of the FactoryFinder class (the bootstrap class loader in the case of the JDK). Using the single-argument ServiceLoader.load is probably want you want now. > : > > Maybe I'm a little confused. But the fallback to default > implementation is in the spec. It happens the jaxp ri is installed as > an endorsed technology here and loaded by the ServiceLoader. Yes, but ultimately we have to get to the point where we can scale down the platform so you may have an embedded device, for example, that doesn't validating parsers or a XPathFactory installed for example. So I think this wording will need to get adjusted in time to allow for the appropriate *ConfigurationException to be thrown then there isn't any service provider module installed. -Alan From Ulf.Zibis at CoSoCo.de Thu Jun 21 21:33:25 2012 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Thu, 21 Jun 2012 23:33:25 +0200 Subject: Review Request: CR 7100996 - (spec str) IndexOutOfBoundsException when using a StringBuffer from multiple threads In-Reply-To: References: <4FE344F3.6080802@oracle.com> <4FE363A2.2080308@oracle.com> Message-ID: <4FE39325.1040607@CoSoCo.de> Hi again, looking closer, I have some suggestions. The term "create" is not valid code, so should not be tagged as such, same for the separating slashes. The following phrase sounds wrong to me, even I'm not english native speaker: "... the source data passed to create, ... , must ensure that ..." 1. Shouldn't the ',' be after the word "data" ? 2. How can source data ensure something? I think, only the caller code can ensure something. "... call, or because the source data is immutable, or because the source data is not shared across threads." ... could be shorter and has superfluous ',' : "... call or because the source data is immutable or not shared across threads." While being here, maybe replace all tags in the entire class by {@code}, same for {@link}. So my suggestion: While {@code StringBuffer} is designed to be safe to use concurrently from multiple threads, the caller must ensure that constructor/{@code append}/{@code insert} of {@code StringBuffer} has [alternative: the constructor or {@code append}/{@code insert} methods of {@code StringBuffer} have] a consistent and unchanging view on the source data for the duration of the operation. This could be satisfied by the caller holding a lock on the source data during the [alternative: synchronizing on the source data] constructor/{@code append}/{@code insert} call or because the source data is immutable or not shared across threads. -Ulf Am 21.06.2012 20:55, schrieb Mike Duigou: > Great addition! > > I believe you should be using {@code} rather than tags. > > I would say "constructors" rather than "create". > > I would add the word "operation" after the first instance of "create/append/insert" > > I would change "This could be done" to "This could be satisfied" > > Mike > > On Jun 21 2012, at 11:10 , Jim Gish wrote: > >> Taking all the previous comments into consideration, here's an update: >> >> diff -r fc575c78f5d3 src/share/classes/java/lang/StringBuffer.java >> --- a/src/share/classes/java/lang/StringBuffer.java Sun Jun 10 10:29:27 2012 +0100 >> +++ b/src/share/classes/java/lang/StringBuffer.java Thu Jun 21 14:09:17 2012 -0400 >> @@ -63,6 +63,16 @@ >> * appending or inserting from a source sequence) this class synchronizes >> * only on the string buffer performing the operation, not on the source. >> *

>> + * While StringBuffer is designed to be safe to use >> + * concurrently from multiple threads, the source data passed to create, >> + * i.e. StringBuffer(source), append(source), >> + * or insert(source), if shared across threads, must ensure >> + * that create/append/insert has a consistent and unchanging >> + * view of the source data for the duration of the operation. This could >> + * be done by the caller holding a lock during the >> + * create/append/insert call, or because the source data is >> + * immutable, or because the source data is not shared across threads. >> + *

>> * Every string buffer has a capacity. As long as the length of the >> * character sequence contained in the string buffer does not exceed >> * the capacity, it is not necessary to allocate a new internal >> >> Thanks, >> Jim >> >> On 06/21/2012 12:49 PM, David Schlosnagle wrote: >>> On Thu, Jun 21, 2012 at 11:59 AM, Jim Gish wrote: >>>> + * across threads, must ensure that StringBuffer.add/insert has a >>> Jim, >>> >>> You may want to replace "add" with "append" if you are intending to >>> reference the actual method name and not the generic operation. >>> Additionally, you may want to use {@code ...} to show this context. >>> >>> Thanks, >>> Dave >> -- >> Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304 >> Oracle Java Platform Group | Core Libraries Team >> 35 Network Drive >> Burlington, MA 01803 >> jim.gish at oracle.com >> > From Ulf.Zibis at CoSoCo.de Thu Jun 21 21:41:06 2012 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Thu, 21 Jun 2012 23:41:06 +0200 Subject: Review Request: CR 7100996 - (spec str) IndexOutOfBoundsException when using a StringBuffer from multiple threads In-Reply-To: <4FE387A7.1010806@oracle.com> References: <4FE344F3.6080802@oracle.com> <4FE363A2.2080308@oracle.com> <4FE387A7.1010806@oracle.com> Message-ID: <4FE394F2.4040303@CoSoCo.de> Oops crossposting. Looks much better. Maybe you still consider to compare with my suggestions. IMO you do not need to use the "(source)" parts, consistent to the paragraphs above. -Ulf Am 21.06.2012 22:44, schrieb Jim Gish: > I did this, and also simplified the language a bit: > > diff -r 7722e2bec02b src/share/classes/java/lang/StringBuffer.java > --- a/src/share/classes/java/lang/StringBuffer.java Thu Jun 21 16:26:04 2012 -0400 > +++ b/src/share/classes/java/lang/StringBuffer.java Thu Jun 21 16:42:19 2012 -0400 > @@ -63,14 +63,15 @@ > * appending or inserting from a source sequence) this class synchronizes > * only on the string buffer performing the operation, not on the source. > *

> + * Although {@code StringBuffer} is designed to be safe to use > + * concurrently from multiple threads, if the source data passed > + * to the constructor, i.e. {@code StringBuffer(source)}, or to the > + * {@code append(source)}, or {@code insert(source)} operations > + * is shared across threads, it must be ensured that the operations have > + * a consistent and unchanging view of the source data for the duration > + * of the operation. > + * This could be satisfied by the caller holding a lock during the > + * operation's call, or because the source data is > * immutable, or because the source data is not shared across threads. > *

> * Every string buffer has a capacity. As long as the length of the > > > > Thanks, > Jim > > On 06/21/2012 02:55 PM, Mike Duigou wrote: >> Great addition! >> >> I believe you should be using {@code} rather than tags. >> >> I would say "constructors" rather than "create". >> >> I would add the word "operation" after the first instance of "create/append/insert" >> >> I would change "This could be done" to "This could be satisfied" >> >> Mike >> >> On Jun 21 2012, at 11:10 , Jim Gish wrote: >> >>> Taking all the previous comments into consideration, here's an update: >>> >>> diff -r fc575c78f5d3 src/share/classes/java/lang/StringBuffer.java >>> --- a/src/share/classes/java/lang/StringBuffer.java Sun Jun 10 10:29:27 2012 +0100 >>> +++ b/src/share/classes/java/lang/StringBuffer.java Thu Jun 21 14:09:17 2012 -0400 >>> @@ -63,6 +63,16 @@ >>> * appending or inserting from a source sequence) this class synchronizes >>> * only on the string buffer performing the operation, not on the source. >>> *

>>> + * WhileStringBuffer is designed to be safe to use >>> + * concurrently from multiple threads, the source data passed to create, >>> + * i.e.StringBuffer(source),append(source), >>> + * orinsert(source), if shared across threads, must ensure >>> + * thatcreate/append/insert has a consistent and unchanging >>> + * view of the source data for the duration of the operation. This could >>> + * be done by the caller holding a lock during the >>> + *create/append/insert call, or because the source data is >>> + * immutable, or because the source data is not shared across threads. >>> + *

>>> * Every string buffer has a capacity. As long as the length of the >>> * character sequence contained in the string buffer does not exceed >>> * the capacity, it is not necessary to allocate a new internal >>> >>> Thanks, >>> Jim >>> >>> On 06/21/2012 12:49 PM, David Schlosnagle wrote: >>>> On Thu, Jun 21, 2012 at 11:59 AM, Jim Gish wrote: >>>>> + * across threads, must ensure that StringBuffer.add/insert has a >>>> Jim, >>>> >>>> You may want to replace "add" with "append" if you are intending to >>>> reference the actual method name and not the generic operation. >>>> Additionally, you may want to use {@code ...} to show this context. >>>> >>>> Thanks, >>>> Dave >>> -- >>> Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304 >>> Oracle Java Platform Group | Core Libraries Team >>> 35 Network Drive >>> Burlington, MA 01803 >>> jim.gish at oracle.com >>> > From huizhe.wang at oracle.com Thu Jun 21 21:53:24 2012 From: huizhe.wang at oracle.com (Joe Wang) Date: Thu, 21 Jun 2012 14:53:24 -0700 Subject: RFR [JDK8]: 7169894: JAXP Plugability Layer: using service loader In-Reply-To: <4FE3623E.9040005@oracle.com> References: <4FE2D380.2010803@oracle.com> <36EF9FE3-70F2-4F95-BDD5-972FA0DD583E@oracle.com> <4FE35B14.6050802@oracle.com> <4FE3623E.9040005@oracle.com> Message-ID: <4FE397D4.2080609@oracle.com> On 6/21/2012 11:04 AM, Alan Bateman wrote: > On 21/06/2012 18:34, Joe Wang wrote: >> >> : >>> >>> When iterating over the service instances you are catching >>> ConfigurationError >>> >>> 264 ServiceLoader loader = >>> ServiceLoader.load(serviceClass, cl); >>> 265 final Iterator providers = loader.iterator(); >>> 266 while (providers.hasNext()) { >>> 267 try { >>> 268 Object provider = providers.next(); >>> 269 if >>> (provider.getClass().getName().contains(fallbackClassName)) { >>> 270 defaultProvider = provider; >>> 271 } else { >>> 272 return provider; >>> 273 } >>> 274 } catch (ConfigurationError e) { >>> 275 // This can happen because of class loader >>> mismatch or any other reason. >>> 276 // log and continue to next one >>> 277 if (debug) { >>> 278 dPrint("The provider can not be >>> instantiated due to: " + e + "."); >>> 279 } >>> 280 } >>> 281 } >>> Did you mean ServiceConfigurationError? >> >> ConfigurationError is internally defined. It's a contract between the >> Factory and FactoryFinder classes. It seems to me it was a result of >> sharing the FactoryFinders and different exception types defined in >> the spec for different factories. > With ServicLoader then ServiceConfigurationError is thrown if there is > a problem reading the service configuration file or the concrete type > is not a sub-type or it cannot be instantiated. > > With JAXP then I think most of the places it is specified to throw a > JAXP ConfigurationException when the provider cannot be > instantiated (it seems to be silent as to issues encountered reading > the service configuration file). > > Minimally the above code will need to be changed to catch > ServiceConfigurationError. Whether it ignores it and attempts to > continue, or throws a JAXP ConfigurationError needs needs > consideration. The existing behavior seems to be to ignore > IOExceptions if there is a problem reading the service configuration > file but I don't think it can distinguish this case when it gets a > SCE. Therefore the safest thing may be to just throw > ConfiguarationError and the callers of the factory finder call will > translate it into the appropriate (and specified) JAXP > *ConfigurationException. Right, that's a mistake. It was SCE, somehow I managed to converted all to the original ConfigurationError. The current sequence is: 1. if service loader fails to load a provider, i.e. a SCE, the process continue to try the next provider if exists -- it would have been a solution for 697514. A SEC would be thrown when an improper provider is encountered. 2. if default provider is found, returns it only if there's no other providers 3. if no provider found, return and the jaxp impl resolution process continues 4. if no provider found after the whole process, report a xxxConfigurationException. The xxxConfigurationException can not therefore take the SCE in (1) as its cause. (4) almost never happens in regular jdk, but it may in jigsaw. (2) as what I did now, maybe incorrect, since the app classloader can actually load the jaxp default impl placed in the endorsed dir or bootclasspath. This change therefore would be incorrect for regular jdk. However, it is intended when the ri becomes a default module in jigsaw. The original spec did not classify which classloader will be used. People learned that how it worked. I felt the same thing now with ServiceLoader. Now that it seems to me the 'findServiceProvider' process is dictated by the ServiceLoader. What I found was that it aggregated and delivered back all of the providers whether they are on classpath or bootclasspath or endorsed dir. We're not considering this change for jdk7 or older, i.e. I haven't thought about fixing 6975142. For jdk8, it seems we have to live with the way it is in (2), a seemly incompatible behavior in backward compatible mode, although, it is a very rare case (I regret to have taught or sent standalone jar files to those customers :) ). -Joe > > -Alan. > > > From Ulf.Zibis at CoSoCo.de Thu Jun 21 22:33:06 2012 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Fri, 22 Jun 2012 00:33:06 +0200 Subject: Review Request: CR 7100996 - (spec str) IndexOutOfBoundsException when using a StringBuffer from multiple threads In-Reply-To: <4FE394F2.4040303@CoSoCo.de> References: <4FE344F3.6080802@oracle.com> <4FE363A2.2080308@oracle.com> <4FE387A7.1010806@oracle.com> <4FE394F2.4040303@CoSoCo.de> Message-ID: <4FE3A122.1080608@CoSoCo.de> Am 21.06.2012 23:41, schrieb Ulf Zibis: > Oops crossposting. > > Looks much better. Maybe you still consider to compare with my suggestions. > IMO you do not need to use the "(source)" parts, consistent to the paragraphs above. > > -Ulf To be consistent to the before paragraph a little more, maybe (1) use "source sequence" instead "source data" and (2) start with "So although ...". Furthermore I think, both paragraphs should be combined to one. -Ulf From huizhe.wang at oracle.com Fri Jun 22 02:05:24 2012 From: huizhe.wang at oracle.com (Joe Wang) Date: Thu, 21 Jun 2012 19:05:24 -0700 Subject: RFR [JDK8]: 7169894: JAXP Plugability Layer: using service loader In-Reply-To: <4FE38B68.5020601@oracle.com> References: <4FE2D380.2010803@oracle.com> <4FE3171B.8080900@oracle.com> <4FE361B2.6090502@oracle.com> <4FE38B68.5020601@oracle.com> Message-ID: <4FE3D2E4.8040002@oracle.com> On 6/21/2012 2:00 PM, Alan Bateman wrote: > On 21/06/2012 19:02, Joe Wang wrote: >> >> : >> >> For the class loader, as discussed with Paul, since the ServiceLoader >> does so much, we may be able to skip the 'using different >> classloader' part, that is, simply calling load without classloader. >> The javadoc states that it's equivalent to load with context class >> loader. But from what I can, it found all that's placed in the >> endorsed dir or bootclasspath. I need to do a few more tests on this. > It doesn't seem to be specified but the implementation (in at least > some places) appears to use the TCCL or the defining loader of the > FactoryFinder class (the bootstrap class loader in the case of the > JDK). Using the single-argument ServiceLoader.load is probably want > you want now. Yeah, I agree. > >> : >> >> Maybe I'm a little confused. But the fallback to default >> implementation is in the spec. It happens the jaxp ri is installed >> as an endorsed technology here and loaded by the ServiceLoader. > Yes, but ultimately we have to get to the point where we can scale > down the platform so you may have an embedded device, for example, > that doesn't validating parsers or a XPathFactory installed for > example. So I think this wording will need to get adjusted in time to > allow for the appropriate *ConfigurationException to be thrown then > there isn't any service provider module installed. Yes, we need better defined error message. In the case where no impl module is installed, the current impl would treat it the same as having problem loading the default impl, and therefore throw *ConfigurationException with an error message sth. like "Provider [default impl class name] no found " and ClassNotFoundException as cause. However, as we discussed before, the current jaxp impl resolution process will change further as it becomes clear if there will be some sort of "preference mechanism" in module loading. It's likely we wont have the 4th step. So when the default module is not installed, we simply get an empty iterator (no exception), in which case we probably need an indicator (Platform.isModuleMode?) to formulate a better error message. -Joe > > -Alan From paul.sandoz at oracle.com Fri Jun 22 08:47:18 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 22 Jun 2012 10:47:18 +0200 Subject: RFR [JDK8]: 7169894: JAXP Plugability Layer: using service loader In-Reply-To: <4FE361B2.6090502@oracle.com> References: <4FE2D380.2010803@oracle.com> <4FE3171B.8080900@oracle.com> <4FE361B2.6090502@oracle.com> Message-ID: On Jun 21, 2012, at 8:02 PM, Joe Wang wrote: > >> >> On the implementation changes then I agree with Paul's comment that there is a lot of duplication. I realize you have inherited some technical debt but now seems a good opportunity to clean this up instead of changing essentially the same code in lots of places. > > As discussed, it's security required. > What exactly were the security reasons? is it related to something messing around with the static state? I still think we can factor out some common functionality. One solution is a deferral: define in the same package a public class that access information in a package private class. If you stick to using ServiceLoader.load you can avoid using SecurtySupport to obtain the TCCL for the service loading case. >> >> I don't understand the need for the Class.forName in findServiceProvider as I thought this method should just use ServiceLoader. > > For XPath, Transformer, Datatype and Validation, it's possible get rid of that since the factory finder is dedicated to a single factory. For the parsers and stream, it's shared by multiple factories, Class.forName is used to return Class by name, or factory id. But can the service interface class (factory id) be absent in the latter case? If not perhaps Class can be used instead. Paul. From Alan.Bateman at oracle.com Fri Jun 22 09:39:54 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 22 Jun 2012 10:39:54 +0100 Subject: RFR [JDK8]: 7169894: JAXP Plugability Layer: using service loader In-Reply-To: <4FE397D4.2080609@oracle.com> References: <4FE2D380.2010803@oracle.com> <36EF9FE3-70F2-4F95-BDD5-972FA0DD583E@oracle.com> <4FE35B14.6050802@oracle.com> <4FE3623E.9040005@oracle.com> <4FE397D4.2080609@oracle.com> Message-ID: <4FE43D6A.9080107@oracle.com> On 21/06/2012 22:53, Joe Wang wrote: > : > > We're not considering this change for jdk7 or older, i.e. I haven't > thought about fixing 6975142. For jdk8, it seems we have to live with > the way it is in (2), a seemly incompatible behavior in backward > compatible mode, although, it is a very rare case (I regret to have > taught or sent standalone jar files to those customers :) ). No, this isn't for jdk7 or older. I don't fully grok the issue in 6975142. That looks to me to be a case where the service provider implementation is including its own copy of the javax.xml.stream.* classes and this is the cause of the ClassCastException. -Alan. From xueming.shen at oracle.com Fri Jun 22 17:01:10 2012 From: xueming.shen at oracle.com (Xueming Shen) Date: Fri, 22 Jun 2012 10:01:10 -0700 Subject: Codereview request for 7130915: File.equals does not give expected results when path contains Non-English characters on Mac OS X Message-ID: <4FE4A4D6.4070100@oracle.com> Hi Here is the proposed change to support Unicode nfd/nfc and case insensitive file path on MacOSX file system. 7130915: File.equals does not give expected results when path contains Non-English characters on Mac OS X 7168427: FileInputStream cannot open file where the file path contains asian characters [macosx] While these two bug reports are only against java.io, we have the same issue in javax.nio.file. Here is the webrev http://cr.openjdk.java.net/~sherman/7130915_7168427/webrev/ Here is the brief summary of the changes java.io.File: (1) removed nfc->nfd conversion in io_util.h/WITH_PLATFORM_STRING, which means we are now passing nfc/composite characters directly into macosx file system APIs without normalize them to nfd. It appears macosx fs APIs do take nfc, though it uses nfd. (2) normalize the resulting file name from macosx fs APIs from nfd->nfd before passing back to java.io.File (File.list() and canonicalize()), so we deal with nfdc file name (as "usual") for java.io classes/APIs. (3) fs.compare()/hashCode() was updated to be case insensitive (4) hasCode() was updated to use the new String.hash32(). java.nio.file: (5) added a setof MacOSXFile... on top of existing BsdFile... classes. An alternative is to update those BsdFile... classes directly to address the macosx specific issues. But given there might be developers over there might work on open jdk BSD port and have dependency on these classes, it might be desirable to have another separate layer of MacOSXFile... classes. So now the default FileSystem/Provider is MacOSXFileSystemProvider and MacOSXFileSystem. (6) the "main" changes are in MacOSXFileSystem, in which the corresponding methods were added to handle, case insensitive and nfd<=>nfc normalization, including the pathmatcher. (7) compare is now are case-insensitive (8) hashCode is now murmur3_32(), this is true for all Solaris/Unix/Linux and maxosx. Though lots of files have been touched, but the line of changes are actually relatively small. The proposed change only deals with the default case-sensitiveness seting, which is case insensitive. On MaxOSX, you actually can configure the HFS+ file system or the mounted vol to be case-sensitive. A possible approach is to have some extra FileStore attributes, such as a isCaseSensitive and to use case sensitive compare/equal on such fs, but this can be dealt with separately later. Thanks, -Sherman From huizhe.wang at oracle.com Fri Jun 22 17:24:35 2012 From: huizhe.wang at oracle.com (Joe Wang) Date: Fri, 22 Jun 2012 10:24:35 -0700 Subject: RFR [JDK8]: 7169894: JAXP Plugability Layer: using service loader In-Reply-To: <4FE43D6A.9080107@oracle.com> References: <4FE2D380.2010803@oracle.com> <36EF9FE3-70F2-4F95-BDD5-972FA0DD583E@oracle.com> <4FE35B14.6050802@oracle.com> <4FE3623E.9040005@oracle.com> <4FE397D4.2080609@oracle.com> <4FE43D6A.9080107@oracle.com> Message-ID: <4FE4AA53.9080605@oracle.com> On 6/22/2012 2:39 AM, Alan Bateman wrote: > On 21/06/2012 22:53, Joe Wang wrote: >> : >> >> We're not considering this change for jdk7 or older, i.e. I haven't >> thought about fixing 6975142. For jdk8, it seems we have to live >> with the way it is in (2), a seemly incompatible behavior in backward >> compatible mode, although, it is a very rare case (I regret to have >> taught or sent standalone jar files to those customers :) ). > No, this isn't for jdk7 or older. > > I don't fully grok the issue in 6975142. That looks to me to be a case > where the service provider implementation is including its own copy of > the javax.xml.stream.* classes and this is the cause of the > ClassCastException. Yes, it's GF packaged woodstox that included its own API packages. Joe > > -Alan. From mike.duigou at oracle.com Fri Jun 22 18:02:28 2012 From: mike.duigou at oracle.com (Mike Duigou) Date: Fri, 22 Jun 2012 11:02:28 -0700 Subject: Codereview request for 7130915: File.equals does not give expected results when path contains Non-English characters on Mac OS X In-Reply-To: <4FE4A4D6.4070100@oracle.com> References: <4FE4A4D6.4070100@oracle.com> Message-ID: On Jun 22 2012, at 10:01 , Xueming Shen wrote: > Hi > > Here is the proposed change to support Unicode nfd/nfc and case insensitive > file path on MacOSX file system. > > 7130915: File.equals does not give expected results when path contains Non-English characters on Mac OS X > 7168427: FileInputStream cannot open file where the file path contains asian characters [macosx] > > While these two bug reports are only against java.io, we have the same issue in javax.nio.file. > Here is the webrev > > (3) fs.compare()/hashCode() was updated to be case insensitive Won't this cause problems on case sensitive file systems? The MacOSX filesystem is by default case insensitive but case sensitive file systems are not entirely uncommon. > (4) hasCode() was updated to use the new String.hash32(). It's possible that this interface may not make it into Java 8. Doug Lea has an alternate proposal for hash based maps that would make this interface unnecessary. > (7) compare is now are case-insensitive Repeated concern about implications for case sensitive file systems. Mike From jonathan.gibbons at oracle.com Fri Jun 22 21:41:13 2012 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Fri, 22 Jun 2012 21:41:13 +0000 Subject: hg: jdk8/tl/langtools: 7178763: javadoc OutOfMemory error results in several jdk8 tl nightly failures Message-ID: <20120622214117.3DF7E47ABC@hg.openjdk.java.net> Changeset: 3468519d9b45 Author: jjg Date: 2012-06-22 14:40 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/3468519d9b45 7178763: javadoc OutOfMemory error results in several jdk8 tl nightly failures Reviewed-by: ksrini ! src/share/classes/com/sun/tools/javac/parser/JavadocTokenizer.java From mike.duigou at oracle.com Fri Jun 22 22:15:40 2012 From: mike.duigou at oracle.com (Mike Duigou) Date: Fri, 22 Jun 2012 15:15:40 -0700 Subject: String.subSequence and CR#6924259: Remove offset and count fields from java.lang.String In-Reply-To: <1359801.KFxJhQHyve@cube> References: <20120531032252.A69774763C@hg.openjdk.java.net> <1359801.KFxJhQHyve@cube> Message-ID: I've made a test implementation of subSequence() utilizing an inner class with offset and count fields to try to understand all the parts that would be impacted. My observations thus far: - The specification of the subSequence() method is currently too specific. It says that the result is a subString(). This would no longer be true. Hopefully nobody assumed that this meant they could cast the result to String. I know, why would you if you can just call subString() instead? I've learned to assume that somebody somewhere does always does the most unexpected thing. - The CharSequences returned by subSequence would follow only the general CharSequence rules for equals()/hashCode(). Any current usages of the result of subSequence for equals() or hashing, even though it's not advised, would break. We could add equals() and hashCode() implementations to the CharSequence returned but they would probably be expensive. - In general I wonder if parsers will be satisfied with a CharSequence that only implements identity equals(). - I also worry about applications that currently do use subSequence currently and which will fail when the result is not a String instance as String.equals() will return false for all CharSequences that aren't Strings. ie. CharSequence token = line.subSequence(line, start, end); if (keyword.equals(token)) ... This would now fail. At this point I wonder if this is a feature worth pursuing. Mike On Jun 3 2012, at 13:44 , Peter Levart wrote: > On Thursday, May 31, 2012 03:22:35 AM mike.duigou at oracle.com wrote: >> Changeset: 2c773daa825d >> Author: mduigou >> Date: 2012-05-17 10:06 -0700 >> URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2c773daa825d >> >> 6924259: Remove offset and count fields from java.lang.String >> Summary: Removes the use of shared character array buffers by String along >> with the two fields needed to support the use of shared buffers. > > Wow, that's quite a change. > > So .substring() is not O(1) any more? > > Doesn't this have impact on the performance of parsers and such that rely on > the performance caracteristics of the .substring() ? > > Have you considered then implementing .subSequence() not in terms of just > delegating to .substring() but returning a special CharSequence view over the > chars of the sub-sequence? From huizhe.wang at oracle.com Fri Jun 22 23:09:40 2012 From: huizhe.wang at oracle.com (Joe Wang) Date: Fri, 22 Jun 2012 16:09:40 -0700 Subject: RFR [7u6]: 7166896: DocumentBuilder.parse(String uri) is not IPv6 enabled. It throws MalformedURLException Message-ID: <4FE4FB34.9040808@oracle.com> Hi, This is a patch to fix the IPv6 issue. In a previous patch to fix an issue with system id containing international characters, an extra character escaping was added so that any URL passed to the parser goes through method escapeNonUSAscii before it's used to construct an URL. However, literal IPv6 addresses are enclosed in square brackets. The escapeNonUSAscii encoded address will become unrecognizable to URL that would throw a java.net.MalformedURLException. An address such as http://[fe80::la03:73ff:fead:f7b0]/note.xml is encoded as http://%5Bfe80::la03:73ff:fead:f7b0%5D/note.xml", resulting in java.net.MalformedURLException: For input string: ":la03:73ff:fead:f7b0%5D". This patch skips the encoding process and returns it as is if there're no non-ascii characters. webrev: http://cr.openjdk.java.net/~joehw/7u6/7166896/webrev/ Please review. Thanks, Joe From naoto.sato at oracle.com Sat Jun 23 00:36:27 2012 From: naoto.sato at oracle.com (Naoto Sato) Date: Fri, 22 Jun 2012 17:36:27 -0700 Subject: Codereview request for 7130915: File.equals does not give expected results when path contains Non-English characters on Mac OS X In-Reply-To: <4FE4A4D6.4070100@oracle.com> References: <4FE4A4D6.4070100@oracle.com> Message-ID: <4FE50F8B.5090209@oracle.com> Hi Sherman, There are several places where Locale.ENGLISH is used for locale neutral processing. You could instead use Locale.ROOT for that purpose. Naoto On 12/06/22 10:01, Xueming Shen wrote: > Hi > > Here is the proposed change to support Unicode nfd/nfc and case insensitive > file path on MacOSX file system. > > 7130915: File.equals does not give expected results when path contains > Non-English characters on Mac OS X > 7168427: FileInputStream cannot open file where the file path contains > asian characters [macosx] > > While these two bug reports are only against java.io, we have the same > issue in javax.nio.file. > Here is the webrev > > http://cr.openjdk.java.net/~sherman/7130915_7168427/webrev/ > > Here is the brief summary of the changes > > java.io.File: > (1) removed nfc->nfd conversion in io_util.h/WITH_PLATFORM_STRING, which > means > we are now passing nfc/composite characters directly into macosx file > system APIs > without normalize them to nfd. It appears macosx fs APIs do take nfc, > though it uses > nfd. > > (2) normalize the resulting file name from macosx fs APIs from nfd->nfd > before passing > back to java.io.File (File.list() and canonicalize()), so we deal with > nfdc file name > (as "usual") for java.io classes/APIs. > > (3) fs.compare()/hashCode() was updated to be case insensitive > > (4) hasCode() was updated to use the new String.hash32(). > > java.nio.file: > > (5) added a setof MacOSXFile... on top of existing BsdFile... classes. > An alternative is to > update those BsdFile... classes directly to address the macosx specific > issues. But given > there might be developers over there might work on open jdk BSD port and > have dependency > on these classes, it might be desirable to have another separate layer > of MacOSXFile... > classes. So now the default FileSystem/Provider is > MacOSXFileSystemProvider and > MacOSXFileSystem. > > (6) the "main" changes are in MacOSXFileSystem, in which the > corresponding methods > were added to handle, case insensitive and nfd<=>nfc normalization, > including the > pathmatcher. > > (7) compare is now are case-insensitive > > (8) hashCode is now murmur3_32(), this is true for all > Solaris/Unix/Linux and maxosx. > > > Though lots of files have been touched, but the line of changes are > actually relatively > small. > > The proposed change only deals with the default case-sensitiveness > seting, which is > case insensitive. On MaxOSX, you actually can configure the HFS+ file > system or the > mounted vol to be case-sensitive. A possible approach is to have some > extra FileStore > attributes, such as a isCaseSensitive and to use case sensitive > compare/equal on > such fs, but this can be dealt with separately later. > > Thanks, > -Sherman From xueming.shen at oracle.com Sat Jun 23 04:09:48 2012 From: xueming.shen at oracle.com (Xueming Shen) Date: Fri, 22 Jun 2012 21:09:48 -0700 Subject: Codereview request for 7130915: File.equals does not give expected results when path contains Non-English characters on Mac OS X In-Reply-To: References: <4FE4A4D6.4070100@oracle.com> Message-ID: <4FE5418C.1040707@oracle.com> On 6/22/12 11:02 AM, Mike Duigou wrote: > On Jun 22 2012, at 10:01 , Xueming Shen wrote: > >> Hi >> >> Here is the proposed change to support Unicode nfd/nfc and case insensitive >> file path on MacOSX file system. >> >> 7130915: File.equals does not give expected results when path contains Non-English characters on Mac OS X >> 7168427: FileInputStream cannot open file where the file path contains asian characters [macosx] >> >> While these two bug reports are only against java.io, we have the same issue in javax.nio.file. >> Here is the webrev >> >> (3) fs.compare()/hashCode() was updated to be case insensitive > Won't this cause problems on case sensitive file systems? The MacOSX filesystem is by default case insensitive but case sensitive file systems are not entirely uncommon. > > Yes, it might/will cause problem on case sensitive hfs+ file system, but this use scenario is not this patch tries to address. On MacOSX you can format one of your disks to be case sensitive (create a new disk image and set the format to be case sensitive, via the Disk Utility, for example) or you might be able to configure your whole HFS+ file system to be case sensitive, which means the case sensitiveness is actually one of the attributes of the volume (FileStore, in JSR203's term), not the whole file system. But the file system has its default setting regarding the path case sensitiveness. On HFS+ it's case insensitive. This is actually not a unique problem of MacOS file system, you can mount a Windows FAT32 drive on LInux or vise versa, it's a difficult issue. The JSR-203's solution is to use the Path + FileSystem to "modle and be consistent with the platform's virtual file system, not the specific underlying file system", so this means on Unix/Linux, the path matching is case sensitive, on Windows it's case insensitive and on MacOSX, we go with the default case_insensitive. That said, an alternative is to set the default case sensitiveness behavior bases on the setting of the volume that the default file system is mounted on, if the root is on a volume that has case sensitive, then the MaxOSXFileSystem is case sensitive. The code to detect the volume's case sensitive setting is currently committed out. Alan and I chatted about this, we agreed that this is out of the scope of this patch, we can leave that for a future enhancement. -Sherman From Alan.Bateman at oracle.com Sat Jun 23 07:28:25 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 23 Jun 2012 08:28:25 +0100 Subject: [8] Review request for 7162111 change tests run in headless mode [macosx] In-Reply-To: <4FE5154C.2090703@oracle.com> References: <4FE5154C.2090703@oracle.com> Message-ID: <4FE57019.9090905@oracle.com> On 23/06/2012 02:01, Jason Uh wrote: > Hi, > > This fix was for regression tests failing on Mac OS X on remotely > executed environments. The changed tests now run in headless mode and > have been taken off the Problem List. > > Webrev: http://cr.openjdk.java.net/~juh/7162111/webrev.00/ > The CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7162111 > > Note that test/demo/jvmti/mtrace/TraceJFrame.java was not fixed here > because headless mode is not supported for JFrame. A separate CR will > be created for this. > > Thanks, > Jason It's good to see these tests changed to run headless and will make the test execution much more reliable. Aside from the mtrace demo there are a couple of other tests that periodically hang initializing AWT, at least when running via ssh and then depending on whether someone is logged in and other configuration settings. Some of the shell tests for serialization come to mind (BTW: no problem doing that via a separate bug, just mentioning that there are other tests that are problems too). One question, and this may be a question for Artem or others, is that in CommonSetup.sh you set AWT_TOOLKIT=XToolkit. Is that right? -Alan. From Alan.Bateman at oracle.com Sat Jun 23 11:30:22 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 23 Jun 2012 12:30:22 +0100 Subject: Codereview request for 7130915: File.equals does not give expected results when path contains Non-English characters on Mac OS X In-Reply-To: References: <4FE4A4D6.4070100@oracle.com> Message-ID: <4FE5A8CE.4030900@oracle.com> On 22/06/2012 19:02, Mike Duigou wrote: > : > > Won't this cause problems on case sensitive file systems? The MacOSX filesystem is by default case insensitive but case sensitive file systems are not entirely uncommon. > It shouldn't cause any issues accessing files, this is really just about equals, sorting, and path matching. I think it requires a bit of thought as to whether to change this because Apple's JDK6 and older releases does not appear to have changed File#equals. In any case, just to put some context on Sherman's changes, this really just another installation of the port to Mac as this area was not completely ported. In that context then the changes to fix the normalization issues are very welcome. Other missing pieces in this area included the watch service, and also a FileTypeDetector implementation. -Alan. From rob.mckenna at oracle.com Sun Jun 24 12:57:49 2012 From: rob.mckenna at oracle.com (Rob McKenna) Date: Sun, 24 Jun 2012 13:57:49 +0100 Subject: review request: 4244896: (process) Provide System.getPid(), System.killProcess(String pid) In-Reply-To: <4FC80FB0.3050701@oracle.com> References: <4F861847.5080308@oracle.com> <4F869AD6.7010903@oracle.com>, <4F8D849E.8090607@oracle.com> <4F8F56E0.6020009@oracle.com> <4F8FF15E.9080408@oracle.com> <4FAC0F5F.3090508@oracle.com> <4FC788CB.9070900@oracle.com> <4FC80FB0.3050701@oracle.com> Message-ID: <4FE70ECD.7000705@oracle.com> Hi folks, 5th, and hopefully final review has been posted to: http://cr.openjdk.java.net/~robm/4244896/webrev.05/ Let me know if there are any comments or concerns, and thanks a lot for the help so far. -Rob On 01/06/12 01:41, David Holmes wrote: > Hi Rob, > > This looks good to me. I'm glad to see that destroyForcibly mandates > that Process instances from ProcessBuilder.start and Runtime.exec must > do a forcible destroy. That addresses my concern about documenting the > actual implementations. > > Two minor comments: > > Process.java: > > 236 * {@link ProcessBuilder#start} and {@link Runtime#exec} are > of type that > > "are of type" -> "are of a type ..." > > ProcessKillTest.sh: > > BIT_FLAG is now unused. > > Thanks, > David > > > On 1/06/2012 1:05 AM, Rob McKenna wrote: >> Latest version including work on the spec language: >> >> http://cr.openjdk.java.net/~robm/4244896/webrev.04/ >> >> >> -Rob >> >> On 10/05/12 19:56, Rob McKenna wrote: >>> Hi folks, >>> >>> The latest version is at: >>> >>> http://cr.openjdk.java.net/~robm/4244896/webrev.03/ >>> >>> >>> Feedback greatly appreciated. >>> >>> -Rob >>> >>> On 19/04/12 12:05, Alan Bateman wrote: >>>> On 19/04/2012 01:05, David Holmes wrote: >>>>> On 18/04/2012 11:44 PM, Jason Mehrens wrote: >>>>>> >>>>>> Rob, >>>>>> >>>>>> It looks like waitFor is calling Object.wait(long) without owning >>>>>> this objects monitor. If I pass Long.MAX_VALUE to waitFor, >>>>>> shouldn't waitFor return if the early if the process ends? >>>>> >>>>> Also waitFor doesn't call wait() under the guard of a looping >>>>> predicate so it will suffer from lost signals and potentially >>>>> spurious wakeups. I also don't see anything calling notify[All] to >>>>> indicate the process has now terminated. It would appear that >>>>> wait(timeout) is being used as a sleep mechanism and that is wrong >>>>> on a number of levels. >>>> I assume waitFor(timout) will require 3 distinct implementations, one >>>> for Solaris/Linux/Mac, another for Windows, and a default >>>> implementations for Process implementations that exist outside of the >>>> JDK. >>>> >>>> It's likely the Solaris/Linux/Mac implementation will involve two >>>> threads, one to block in waitpid and the other to interrupt it via a >>>> signal if the timeout elapses before the child terminates. The >>>> Windows implementation should be trivial because it can be a timed >>>> wait. >>>> >>>> I assume the default implementation (which is what is being discussed >>>> here) will need to loop calling exitValue until the timeout elapses >>>> or the child terminates. Not very efficient but at least it won't be >>>> used when when creating Processes via Runtime.exec or ProcessBuilder. >>>> >>>> I think the question we need to consider is whether waitFor(timeout) >>>> is really needed. If it's something that it pushed out for another >>>> day then it brings up the question as to whether to include isAlive >>>> now or not (as waitFor without timeout gives us an isAlive equivalent >>>> too). >>>> >>>> -Alan. >>>> >>>> >>>> >>>> From xueming.shen at oracle.com Sun Jun 24 16:58:01 2012 From: xueming.shen at oracle.com (Xueming Shen) Date: Sun, 24 Jun 2012 09:58:01 -0700 Subject: Codereview request for 7130915: File.equals does not give expected results when path contains Non-English characters on Mac OS X In-Reply-To: <191321F8-8360-44A2-AA61-1504B074E264@sudo.ch> References: <4FE4A4D6.4070100@oracle.com> <191321F8-8360-44A2-AA61-1504B074E264@sudo.ch> Message-ID: <4FE74719.8080709@oracle.com> Yes, I believe the issue described in MACOSX_PORT-165 is the same issue this patch is trying to solve. Btw, it appears there are typos in the note(2), my mini keyboard obviously is too sticky:-) (2) normalize the resulting file name from macosx fs APIs from nfd->nfc before passing back to java.io.File (File.list() and canonicalize()), so we deal with nfc file name (as "usual") for java.io classes/APIs. -sherman On 6/24/12 7:50 AM, David Kocher wrote: > Will this address issue MACOSX_PORT-165 [1]? > > [1] http://java.net/jira/browse/MACOSX_PORT-165 > > -- David > > On 22.06.2012, at 19:01, Xueming Shen wrote: > >> Hi >> >> Here is the proposed change to support Unicode nfd/nfc and case insensitive >> file path on MacOSX file system. >> >> 7130915: File.equals does not give expected results when path contains Non-English characters on Mac OS X >> 7168427: FileInputStream cannot open file where the file path contains asian characters [macosx] >> >> While these two bug reports are only against java.io, we have the same issue in javax.nio.file. >> Here is the webrev >> >> http://cr.openjdk.java.net/~sherman/7130915_7168427/webrev/ >> >> Here is the brief summary of the changes >> >> java.io.File: >> (1) removed nfc->nfd conversion in io_util.h/WITH_PLATFORM_STRING, which means >> we are now passing nfc/composite characters directly into macosx file system APIs >> without normalize them to nfd. It appears macosx fs APIs do take nfc, though it uses >> nfd. >> >> (2) normalize the resulting file name from macosx fs APIs from nfd->nfd before passing >> back to java.io.File (File.list() and canonicalize()), so we deal with nfdc file name >> (as "usual") for java.io classes/APIs. >> >> (3) fs.compare()/hashCode() was updated to be case insensitive >> >> (4) hasCode() was updated to use the new String.hash32(). >> >> java.nio.file: >> >> (5) added a setof MacOSXFile... on top of existing BsdFile... classes. An alternative is to >> update those BsdFile... classes directly to address the macosx specific issues. But given >> there might be developers over there might work on open jdk BSD port and have dependency >> on these classes, it might be desirable to have another separate layer of MacOSXFile... >> classes. So now the default FileSystem/Provider is MacOSXFileSystemProvider and >> MacOSXFileSystem. >> >> (6) the "main" changes are in MacOSXFileSystem, in which the corresponding methods >> were added to handle, case insensitive and nfd<=>nfc normalization, including the >> pathmatcher. >> >> (7) compare is now are case-insensitive >> >> (8) hashCode is now murmur3_32(), this is true for all Solaris/Unix/Linux and maxosx. >> >> >> Though lots of files have been touched, but the line of changes are actually relatively >> small. >> >> The proposed change only deals with the default case-sensitiveness seting, which is >> case insensitive. On MaxOSX, you actually can configure the HFS+ file system or the >> mounted vol to be case-sensitive. A possible approach is to have some extra FileStore >> attributes, such as a isCaseSensitive and to use case sensitive compare/equal on >> such fs, but this can be dealt with separately later. >> >> Thanks, >> -Sherman >> From jason_mehrens at hotmail.com Sun Jun 24 19:06:59 2012 From: jason_mehrens at hotmail.com (Jason Mehrens) Date: Sun, 24 Jun 2012 14:06:59 -0500 Subject: String.subSequence and CR#6924259: Remove offset and count fields from java.lang.String In-Reply-To: References: <20120531032252.A69774763C@hg.openjdk.java.net>, <1359801.KFxJhQHyve@cube>, Message-ID: Mike, Why not implement subSequence as 'java.nio.CharBuffer.wrap(data, beginIndex, endIndex).asReadOnlyBuffer()' ? Easy to implement and test. The nice thing is that parsers would know what a 'CharBuffer' vs. a sub sequence String internal class. Jason > Subject: String.subSequence and CR#6924259: Remove offset and count fields from java.lang.String > From: mike.duigou at oracle.com > Date: Fri, 22 Jun 2012 15:15:40 -0700 > To: peter.levart at gmail.com > CC: core-libs-dev at openjdk.java.net > > I've made a test implementation of subSequence() utilizing an inner class with offset and count fields to try to understand all the parts that would be impacted. My observations thus far: > > - The specification of the subSequence() method is currently too specific. It says that the result is a subString(). This would no longer be true. Hopefully nobody assumed that this meant they could cast the result to String. I know, why would you if you can just call subString() instead? I've learned to assume that somebody somewhere does always does the most unexpected thing. > - The CharSequences returned by subSequence would follow only the general CharSequence rules for equals()/hashCode(). Any current usages of the result of subSequence for equals() or hashing, even though it's not advised, would break. We could add equals() and hashCode() implementations to the CharSequence returned but they would probably be expensive. > - In general I wonder if parsers will be satisfied with a CharSequence that only implements identity equals(). > - I also worry about applications that currently do use subSequence currently and which will fail when the result is not a String instance as String.equals() will return false for all CharSequences that aren't Strings. ie. CharSequence token = line.subSequence(line, start, end); if (keyword.equals(token)) ... This would now fail. > > At this point I wonder if this is a feature worth pursuing. > > Mike > > On Jun 3 2012, at 13:44 , Peter Levart wrote: > > > On Thursday, May 31, 2012 03:22:35 AM mike.duigou at oracle.com wrote: > >> Changeset: 2c773daa825d > >> Author: mduigou > >> Date: 2012-05-17 10:06 -0700 > >> URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2c773daa825d > >> > >> 6924259: Remove offset and count fields from java.lang.String > >> Summary: Removes the use of shared character array buffers by String along > >> with the two fields needed to support the use of shared buffers. > > > > Wow, that's quite a change. > > > > So .substring() is not O(1) any more? > > > > Doesn't this have impact on the performance of parsers and such that rely on > > the performance caracteristics of the .substring() ? > > > > Have you considered then implementing .subSequence() not in terms of just > > delegating to .substring() but returning a special CharSequence view over the > > chars of the sub-sequence? > From mike.duigou at oracle.com Sun Jun 24 20:17:01 2012 From: mike.duigou at oracle.com (Mike Duigou) Date: Sun, 24 Jun 2012 13:17:01 -0700 Subject: String.subSequence and CR#6924259: Remove offset and count fields from java.lang.String In-Reply-To: References: <20120531032252.A69774763C@hg.openjdk.java.net>, <1359801.KFxJhQHyve@cube>, Message-ID: As usual, an excellent idea Jason. I'll probably run an internal test/benchmark with both this and the CharSequence inner class implementation to see what breaks and where there are performance differences between the two. I was planning to also test a version of the CharSequence implementation which implemented equals() and hashCode() compatible with String and see if this produced fewer (or different) test failures. Good idea. Mike On Jun 24 2012, at 12:06 , Jason Mehrens wrote: > Mike, > > Why not implement subSequence as 'java.nio.CharBuffer.wrap(data, beginIndex, endIndex).asReadOnlyBuffer()' ? Easy to implement and test. The nice thing is that parsers would know what a 'CharBuffer' vs. a sub sequence String internal class. > > Jason > > > Subject: String.subSequence and CR#6924259: Remove offset and count fields from java.lang.String > > From: mike.duigou at oracle.com > > Date: Fri, 22 Jun 2012 15:15:40 -0700 > > To: peter.levart at gmail.com > > CC: core-libs-dev at openjdk.java.net > > > > I've made a test implementation of subSequence() utilizing an inner class with offset and count fields to try to understand all the parts that would be impacted. My observations thus far: > > > > - The specification of the subSequence() method is currently too specific. It says that the result is a subString(). This would no longer be true. Hopefully nobody assumed that this meant they could cast the result to String. I know, why would you if you can just call subString() instead? I've learned to assume that somebody somewhere does always does the most unexpected thing. > > - The CharSequences returned by subSequence would follow only the general CharSequence rules for equals()/hashCode(). Any current usages of the result of subSequence for equals() or hashing, even though it's not advised, would break. We could add equals() and hashCode() implementations to the CharSequence returned but they would probably be expensive. > > - In general I wonder if parsers will be satisfied with a CharSequence that only implements identity equals(). > > - I also worry about applications that currently do use subSequence currently and which will fail when the result is not a String instance as String.equals() will return false for all CharSequences that aren't Strings. ie. CharSequence token = line.subSequence(line, start, end); if (keyword.equals(token)) ... This would now fail. > > > > At this point I wonder if this is a feature worth pursuing. > > > > Mike > > > > On Jun 3 2012, at 13:44 , Peter Levart wrote: > > > > > On Thursday, May 31, 2012 03:22:35 AM mike.duigou at oracle.com wrote: > > >> Changeset: 2c773daa825d > > >> Author: mduigou > > >> Date: 2012-05-17 10:06 -0700 > > >> URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2c773daa825d > > >> > > >> 6924259: Remove offset and count fields from java.lang.String > > >> Summary: Removes the use of shared character array buffers by String along > > >> with the two fields needed to support the use of shared buffers. > > > > > > Wow, that's quite a change. > > > > > > So .substring() is not O(1) any more? > > > > > > Doesn't this have impact on the performance of parsers and such that rely on > > > the performance caracteristics of the .substring() ? > > > > > > Have you considered then implementing .subSequence() not in terms of just > > > delegating to .substring() but returning a special CharSequence view over the > > > chars of the sub-sequence? > > From david.holmes at oracle.com Sun Jun 24 22:27:46 2012 From: david.holmes at oracle.com (David Holmes) Date: Mon, 25 Jun 2012 08:27:46 +1000 Subject: review request: 4244896: (process) Provide System.getPid(), System.killProcess(String pid) In-Reply-To: <4FE70ECD.7000705@oracle.com> References: <4F861847.5080308@oracle.com> <4F869AD6.7010903@oracle.com>, <4F8D849E.8090607@oracle.com> <4F8F56E0.6020009@oracle.com> <4F8FF15E.9080408@oracle.com> <4FAC0F5F.3090508@oracle.com> <4FC788CB.9070900@oracle.com> <4FC80FB0.3050701@oracle.com> <4FE70ECD.7000705@oracle.com> Message-ID: <4FE79462.6060409@oracle.com> Hi Rob, A couple of minor things ... Process.waitFor: + long startTime = System.nanoTime(); + long rem = unit.toNanos(timeout) - (System.nanoTime() - startTime); should just be + long startTime = System.nanoTime(); + long rem = unit.toNanos(timeout); The second reading of nanoTime is not generally useful. Under ideal conditions "no time" will have passed and you waste more time asking for the updated time. Someone may argue that you could get preempted after the first call to nanoTime and so we need to re-check; but you could get preempted at any time: after the first nanoTime, after the second, after the calculation of rem, etc. This is a game of "chase your tail" that you can not win. These timeouts are only rough hints. Also you don't do this double-read in UnixProcess.waitFor And a style-nit: if(rem > 0), while(rem>0) - should have a space before the ( --- UNIXProcess.java.linux 221 if (timeout <= 0) return false; 222 223 long timeoutAsNanos = unit.toNanos(timeout); 224 long startTime = System.nanoTime(); Wrong indentation. --- UNIXProcess.java.solaris 167 if (timeout <= 0) return false; 168 169 long timeoutAsNanos = unit.toNanos(timeout); Wrong indentation. --- The test programs look okay. Time-based testing is always a potential problem so we will just have to see how these go in practice. David ----- On 24/06/2012 10:57 PM, Rob McKenna wrote: > Hi folks, > > 5th, and hopefully final review has been posted to: > > http://cr.openjdk.java.net/~robm/4244896/webrev.05/ > > > Let me know if there are any comments or concerns, and thanks a lot for > the help so far. > > -Rob > > On 01/06/12 01:41, David Holmes wrote: >> Hi Rob, >> >> This looks good to me. I'm glad to see that destroyForcibly mandates >> that Process instances from ProcessBuilder.start and Runtime.exec must >> do a forcible destroy. That addresses my concern about documenting the >> actual implementations. >> >> Two minor comments: >> >> Process.java: >> >> 236 * {@link ProcessBuilder#start} and {@link Runtime#exec} are of >> type that >> >> "are of type" -> "are of a type ..." >> >> ProcessKillTest.sh: >> >> BIT_FLAG is now unused. >> >> Thanks, >> David >> >> >> On 1/06/2012 1:05 AM, Rob McKenna wrote: >>> Latest version including work on the spec language: >>> >>> http://cr.openjdk.java.net/~robm/4244896/webrev.04/ >>> >>> >>> -Rob >>> >>> On 10/05/12 19:56, Rob McKenna wrote: >>>> Hi folks, >>>> >>>> The latest version is at: >>>> >>>> http://cr.openjdk.java.net/~robm/4244896/webrev.03/ >>>> >>>> >>>> Feedback greatly appreciated. >>>> >>>> -Rob >>>> >>>> On 19/04/12 12:05, Alan Bateman wrote: >>>>> On 19/04/2012 01:05, David Holmes wrote: >>>>>> On 18/04/2012 11:44 PM, Jason Mehrens wrote: >>>>>>> >>>>>>> Rob, >>>>>>> >>>>>>> It looks like waitFor is calling Object.wait(long) without owning >>>>>>> this objects monitor. If I pass Long.MAX_VALUE to waitFor, >>>>>>> shouldn't waitFor return if the early if the process ends? >>>>>> >>>>>> Also waitFor doesn't call wait() under the guard of a looping >>>>>> predicate so it will suffer from lost signals and potentially >>>>>> spurious wakeups. I also don't see anything calling notify[All] to >>>>>> indicate the process has now terminated. It would appear that >>>>>> wait(timeout) is being used as a sleep mechanism and that is wrong >>>>>> on a number of levels. >>>>> I assume waitFor(timout) will require 3 distinct implementations, one >>>>> for Solaris/Linux/Mac, another for Windows, and a default >>>>> implementations for Process implementations that exist outside of the >>>>> JDK. >>>>> >>>>> It's likely the Solaris/Linux/Mac implementation will involve two >>>>> threads, one to block in waitpid and the other to interrupt it via a >>>>> signal if the timeout elapses before the child terminates. The >>>>> Windows implementation should be trivial because it can be a timed >>>>> wait. >>>>> >>>>> I assume the default implementation (which is what is being discussed >>>>> here) will need to loop calling exitValue until the timeout elapses >>>>> or the child terminates. Not very efficient but at least it won't be >>>>> used when when creating Processes via Runtime.exec or ProcessBuilder. >>>>> >>>>> I think the question we need to consider is whether waitFor(timeout) >>>>> is really needed. If it's something that it pushed out for another >>>>> day then it brings up the question as to whether to include isAlive >>>>> now or not (as waitFor without timeout gives us an isAlive equivalent >>>>> too). >>>>> >>>>> -Alan. >>>>> >>>>> >>>>> >>>>> > > From david.holmes at oracle.com Mon Jun 25 04:26:13 2012 From: david.holmes at oracle.com (David Holmes) Date: Mon, 25 Jun 2012 14:26:13 +1000 Subject: RFR: 7161229 - PriorityBlockingQueue keeps hard reference to last removed element Message-ID: <4FE7E865.7020106@oracle.com> webrev: http://cr.openjdk.java.net/~dholmes/7161229/webrev/ When removing the last element from the PBQ the "sift down" logic would store it back in as array[0]. The simple fix is for the sift-down to be a no-op if the queue size is zero. The fix has been contributed by Doug Lea. We are taking this opportunity to synchronize PBQ with Doug's latest version at: http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/main/java/util/concurrent/PriorityBlockingQueue.java?view=log So in addition to the above functional fix there are a number of miscellaneous code and comment cleanups. The only non-trivial, but still very simple, change is to the drainTo method to make it more robust if the add() on the destination collection throws an exception. I am of course a Reviewer for this. I have provided the update to the LastElement test (as this is certainly related to the last element) but there are some reservations about examining the PBS internals this way. Unfortunately there is no good way to test for these kinds of retention issues. You either need a whitebox test like this, or need to rely on non-guaranteed GC and finalization behaviour. Thanks, David Holmes From huizhe.wang at oracle.com Mon Jun 25 07:38:58 2012 From: huizhe.wang at oracle.com (Joe Wang) Date: Mon, 25 Jun 2012 00:38:58 -0700 Subject: RFR [JDK8]: 7169894: JAXP Plugability Layer: using service loader In-Reply-To: <4FE4AA53.9080605@oracle.com> References: <4FE2D380.2010803@oracle.com> <36EF9FE3-70F2-4F95-BDD5-972FA0DD583E@oracle.com> <4FE35B14.6050802@oracle.com> <4FE3623E.9040005@oracle.com> <4FE397D4.2080609@oracle.com> <4FE43D6A.9080107@oracle.com> <4FE4AA53.9080605@oracle.com> Message-ID: <4FE81592.6050205@oracle.com> Hi all, Thanks for all the comments! I've updated the patch for the following recommended changes: 1. ServiceConfigurationError instead of ConfigurationError 2. Use factory class, class.forName section removed 3. Use load method without specifying classloader 4. To be clear on how the process handles exceptions, I've updated JavaDoc with the following: * Uses the service-provider loading facilities, defined by the {@link java.util.ServiceLoader} class, to attempt * to locate and load an implementation of the service. In case multiple providers exist, the first * valid 3rd party provider should be returned; If there is no valid 3rd party provider, * the default implementation is returned if it is on the classpath or installed as a module. * * If ServiceConfigurationError is thrown, it is interpreted as an invalid provider is encountered. * The process shall continue the search until all are exhausted. The JavaDoc is similar but slightly different for SchemaFactory and XPathFactory: *

Uses the service-provider loading facilities, defined by the {@link java.util.ServiceLoader} class, to attempt * to locate and load an implementation of the service. * Each potential service provider is required to implement the method:

* 
      *        {@link #isSchemaLanguageSupported(String schemaLanguage)}
      *
* A service provider is deemed as valid if it supports the specified schema language. * *

* In case multiple providers exist, the first * valid 3rd party provider should be returned; If there is no valid 3rd party provider, * the default implementation is returned if it is on the classpath or installed as a module. *

* If ServiceConfigurationError is thrown, it is interpreted as an invalid provider is encountered. * The process shall continue the search until all are exhausted. We can continue discussing on a solution for the duplication of the classes. For this patch, if you agree, I'd like to check it in as it stands now and work out another patch for the duplicated classes once we have a solution. New webrev: http://cr.openjdk.java.net/~joehw/jdk8/7169894/webrev/ Thanks, Joe On 6/22/2012 10:24 AM, Joe Wang wrote: > > > On 6/22/2012 2:39 AM, Alan Bateman wrote: >> On 21/06/2012 22:53, Joe Wang wrote: >>> : >>> >>> We're not considering this change for jdk7 or older, i.e. I haven't >>> thought about fixing 6975142. For jdk8, it seems we have to live >>> with the way it is in (2), a seemly incompatible behavior in >>> backward compatible mode, although, it is a very rare case (I >>> regret to have taught or sent standalone jar files to those >>> customers :) ). >> No, this isn't for jdk7 or older. >> >> I don't fully grok the issue in 6975142. That looks to me to be a >> case where the service provider implementation is including its own >> copy of the javax.xml.stream.* classes and this is the cause of the >> ClassCastException. > > Yes, it's GF packaged woodstox that included its own API packages. > > Joe > >> >> -Alan. From yiming.wang at oracle.com Mon Jun 25 08:06:20 2012 From: yiming.wang at oracle.com (Eric Wang) Date: Mon, 25 Jun 2012 16:06:20 +0800 Subject: Patch review request - Test bug 7123972 test/java/lang/annotation/loaderLeak/Main.java fails intermittently In-Reply-To: <4FE310BB.6000100@oracle.com> References: <4FE2B997.7090204@oracle.com> <4FE2BFFB.8010705@oracle.com> <4FE2FE2C.1020601@oracle.com> <4FE310BB.6000100@oracle.com> Message-ID: <4FE81BFC.8040206@oracle.com> On 2012/6/21 20:16, David Holmes wrote: > Hi Eric, > > On 21/06/2012 8:57 PM, Eric Wang wrote: >> Hi David, >> >> Thanks for your review, I have updated the code by following your >> suggestion. please see the attachment. >> I'm not sure whether there's a better way to guarantee object finalized >> by GC definitely within the given time. The proposed fix may work in >> most cases but may still throw InterruptException if execution is >> timeout (2 minutes of JTreg by default). > > There is no way to guarantee finalization in a specific timeframe, but > if a simple test hasn't executed finalizers in 2 minutes then that in > itself indicates a problem. > > Can you post a full webrev for this patch? I don't like seeing it out > of context and am wondering exactly what we are trying to GC here. > > David > >> Regards, >> Eric >> >> On 2012/6/21 14:32, David Holmes wrote: >>> Hi Eric, >>> >>> On 21/06/2012 4:05 PM, Eric Wang wrote: >>>> I come from Java SQE team who are interested in regression test bug >>>> fix. >>>> Here is the first simple fix for bug 7123972 >>>> , Can you please >>>> help >>>> to review and comment? Attachment is the patch Thanks! >>>> >>>> This bug is caused by wrong assumption that the GC is started >>>> immediately to recycle un-referenced objects after System.gc() called >>>> one or two times. >>>> >>>> The proposed solution is to make sure the un-referenced object is >>>> recycled by GC before checking if the reference is null. >>> >>> Your patch makes its own assumptions - specifically that finalization >>> must eventually run. At a minimum you should add >>> System.runFinalization() calls after the System.gc() inside the loop. >>> Even that is no guarantee in a general sense, though it should work >>> for hotspot. >>> >>> David >>> >>> >>>> Regards, >>>> Eric >> Hi Alan & David, Thank you for your comments, sorry for reply this mail late as i was just back from the dragon boat holiday. I have updated the code again based on your suggestions: rename the flag variable, increase the sleep time and remove it from problem list. The attachment is the full webrev for this patch, Can you please review again? Thanks a lot! Regards, Eric From youdwei at linux.vnet.ibm.com Mon Jun 25 08:18:30 2012 From: youdwei at linux.vnet.ibm.com (Deven You) Date: Mon, 25 Jun 2012 16:18:30 +0800 Subject: javax.sql.rowset.serial.SerialBlob doesn't support free and getBinaryStream Message-ID: <4FE81ED6.7020909@linux.vnet.ibm.com> Hi All, First of all, if the jdbc problem has a better mailing list to post please tell me. I find that javax.sql.rowset.serial.SerialBlob is not fully implemented in OpenJDK 8. Methods public InputStream getBinaryStream(long pos,long length) throws SQLException public void free() throws SQLException only throw UnsupportedOperationException. I have made a patch[1] to implement these 2 methods. Could anyone take a look to review it. BTW: I think the spec for SerialBlob is not very clear like it doesn't mention if all method rather than free() need throw any exception after free() is invoked. However that behavior seems reasonable. [1] http://cr.openjdk.java.net/~littlee/OJDK-576/webrev Thanks a lot. -- Best Regards, Deven From thomas.stuefe at gmail.com Mon Jun 25 08:56:34 2012 From: thomas.stuefe at gmail.com (=?ISO-8859-1?Q?Thomas_St=FCfe?=) Date: Mon, 25 Jun 2012 10:56:34 +0200 Subject: review request: 4244896: (process) Provide System.getPid(), System.killProcess(String pid) In-Reply-To: <4FE70ECD.7000705@oracle.com> References: <4F861847.5080308@oracle.com> <4F869AD6.7010903@oracle.com> <4F8D849E.8090607@oracle.com> <4F8F56E0.6020009@oracle.com> <4F8FF15E.9080408@oracle.com> <4FAC0F5F.3090508@oracle.com> <4FC788CB.9070900@oracle.com> <4FC80FB0.3050701@oracle.com> <4FE70ECD.7000705@oracle.com> Message-ID: Hi, Rob, src/solaris/native/java/lang/UNIXProcess_md.c: You never check the return code of kill(2). kill() may fail if you have no permission to kill the process (EPERM), or if the process id is invalid, maybe it has already been reaped. In both cases an exception would be nice, or if you decide this cannot happen in the context of Process.java, at least an assert(). The same applies to GetExitCodeProcess() on windows. Kind Regards, Thomas Stuefe SAP Germany On Sun, Jun 24, 2012 at 2:57 PM, Rob McKenna wrote: > Hi folks, > > 5th, and hopefully final review has been posted to: > > http://cr.openjdk.java.net/~robm/4244896/webrev.05/ > > > Let me know if there are any comments or concerns, and thanks a lot for the > help so far. > > ? ?-Rob > > On 01/06/12 01:41, David Holmes wrote: >> >> Hi Rob, >> >> This looks good to me. I'm glad to see that destroyForcibly mandates that >> Process instances from ProcessBuilder.start and Runtime.exec must do a >> forcible destroy. That addresses my concern about documenting the actual >> implementations. >> >> Two minor comments: >> >> Process.java: >> >> ?236 ? ? ?* {@link ProcessBuilder#start} and {@link Runtime#exec} are of >> type that >> >> "are of type" -> "are of a type ..." >> >> ProcessKillTest.sh: >> >> BIT_FLAG is now unused. >> >> Thanks, >> David >> >> >> On 1/06/2012 1:05 AM, Rob McKenna wrote: >>> >>> Latest version including work on the spec language: >>> >>> http://cr.openjdk.java.net/~robm/4244896/webrev.04/ >>> >>> >>> -Rob >>> >>> On 10/05/12 19:56, Rob McKenna wrote: >>>> >>>> Hi folks, >>>> >>>> The latest version is at: >>>> >>>> http://cr.openjdk.java.net/~robm/4244896/webrev.03/ >>>> >>>> >>>> Feedback greatly appreciated. >>>> >>>> -Rob >>>> >>>> On 19/04/12 12:05, Alan Bateman wrote: >>>>> >>>>> On 19/04/2012 01:05, David Holmes wrote: >>>>>> >>>>>> On 18/04/2012 11:44 PM, Jason Mehrens wrote: >>>>>>> >>>>>>> >>>>>>> Rob, >>>>>>> >>>>>>> It looks like waitFor is calling Object.wait(long) without owning >>>>>>> this objects monitor. If I pass Long.MAX_VALUE to waitFor, >>>>>>> shouldn't waitFor return if the early if the process ends? >>>>>> >>>>>> >>>>>> Also waitFor doesn't call wait() under the guard of a looping >>>>>> predicate so it will suffer from lost signals and potentially >>>>>> spurious wakeups. I also don't see anything calling notify[All] to >>>>>> indicate the process has now terminated. It would appear that >>>>>> wait(timeout) is being used as a sleep mechanism and that is wrong >>>>>> on a number of levels. >>>>> >>>>> I assume waitFor(timout) will require 3 distinct implementations, one >>>>> for Solaris/Linux/Mac, another for Windows, and a default >>>>> implementations for Process implementations that exist outside of the >>>>> JDK. >>>>> >>>>> It's likely the Solaris/Linux/Mac implementation will involve two >>>>> threads, one to block in waitpid and the other to interrupt it via a >>>>> signal if the timeout elapses before the child terminates. The >>>>> Windows implementation should be trivial because it can be a timed >>>>> wait. >>>>> >>>>> I assume the default implementation (which is what is being discussed >>>>> here) will need to loop calling exitValue until the timeout elapses >>>>> or the child terminates. Not very efficient but at least it won't be >>>>> used when when creating Processes via Runtime.exec or ProcessBuilder. >>>>> >>>>> I think the question we need to consider is whether waitFor(timeout) >>>>> is really needed. If it's something that it pushed out for another >>>>> day then it brings up the question as to whether to include isAlive >>>>> now or not (as waitFor without timeout gives us an isAlive equivalent >>>>> too). >>>>> >>>>> -Alan. >>>>> >>>>> >>>>> >>>>> > > From forax at univ-mlv.fr Mon Jun 25 09:01:24 2012 From: forax at univ-mlv.fr (=?UTF-8?B?UsOpbWkgRm9yYXg=?=) Date: Mon, 25 Jun 2012 11:01:24 +0200 Subject: RFR: 7161229 - PriorityBlockingQueue keeps hard reference to last removed element In-Reply-To: <4FE7E865.7020106@oracle.com> References: <4FE7E865.7020106@oracle.com> Message-ID: <4FE828E4.70200@univ-mlv.fr> Hi David, I think the test if (n > 0) { should not be in siftDown* but should be done at all callsites, by example in heapify, you can hoist the test outside of the loop. In dequeue, it's a matter of style but the 'else' is not needed anymore. Otherwise the changes looks ok for me. R?mi On 06/25/2012 06:26 AM, David Holmes wrote: > webrev: > > http://cr.openjdk.java.net/~dholmes/7161229/webrev/ > > When removing the last element from the PBQ the "sift down" logic > would store it back in as array[0]. The simple fix is for the > sift-down to be a no-op if the queue size is zero. > > The fix has been contributed by Doug Lea. We are taking this > opportunity to synchronize PBQ with Doug's latest version at: > > http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/main/java/util/concurrent/PriorityBlockingQueue.java?view=log > > > So in addition to the above functional fix there are a number of > miscellaneous code and comment cleanups. The only non-trivial, but > still very simple, change is to the drainTo method to make it more > robust if the add() on the destination collection throws an exception. > > I am of course a Reviewer for this. > > I have provided the update to the LastElement test (as this is > certainly related to the last element) but there are some reservations > about examining the PBS internals this way. Unfortunately there is no > good way to test for these kinds of retention issues. You either need > a whitebox test like this, or need to rely on non-guaranteed GC and > finalization behaviour. > > Thanks, > David Holmes From Alan.Bateman at oracle.com Mon Jun 25 09:52:47 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 25 Jun 2012 10:52:47 +0100 Subject: review request: 4244896: (process) Provide System.getPid(), System.killProcess(String pid) In-Reply-To: References: <4F861847.5080308@oracle.com> <4F869AD6.7010903@oracle.com> <4F8D849E.8090607@oracle.com> <4F8F56E0.6020009@oracle.com> <4F8FF15E.9080408@oracle.com> <4FAC0F5F.3090508@oracle.com> <4FC788CB.9070900@oracle.com> <4FC80FB0.3050701@oracle.com> <4FE70ECD.7000705@oracle.com> Message-ID: <4FE834EF.9070909@oracle.com> On 25/06/2012 09:56, Thomas St?fe wrote: > Hi, Rob, > > src/solaris/native/java/lang/UNIXProcess_md.c: > > You never check the return code of kill(2). kill() may fail if you > have no permission to kill the process (EPERM), or if the process id > is invalid, maybe it has already been reaped. In both cases an > exception would be nice, or if you decide this cannot happen in the > context of Process.java, at least an assert(). > One thing to add to this is that the destroy method has been there since jdk1.0 and is not defined or specified to throw any exceptions so we can't really change that now. From the history it doesn't look like the return from kill(2) has ever been checked. As it can only ne used to send a signal to processes created by the ProcessBuilder or Runtime.exec API (not arbitrary process) then it is unlikely to fail. Whether the new destroy method should specify an exception may require consideration and maybe a separate bug should be created to consider that. -Alan From Alan.Bateman at oracle.com Mon Jun 25 10:49:28 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 25 Jun 2012 11:49:28 +0100 Subject: review request: 4244896: (process) Provide System.getPid(), System.killProcess(String pid) In-Reply-To: <4FE70ECD.7000705@oracle.com> References: <4F861847.5080308@oracle.com> <4F869AD6.7010903@oracle.com>, <4F8D849E.8090607@oracle.com> <4F8F56E0.6020009@oracle.com> <4F8FF15E.9080408@oracle.com> <4FAC0F5F.3090508@oracle.com> <4FC788CB.9070900@oracle.com> <4FC80FB0.3050701@oracle.com> <4FE70ECD.7000705@oracle.com> Message-ID: <4FE84238.9050507@oracle.com> On 24/06/2012 13:57, Rob McKenna wrote: > Hi folks, > > 5th, and hopefully final review has been posted to: > > http://cr.openjdk.java.net/~robm/4244896/webrev.05/ > > > Let me know if there are any comments or concerns, and thanks a lot > for the help so far. > > -Rob Overall I think this has worked out well. I agree with David on the needless calls to System.nanoTime in Process.waitFor although it's not a major issue given that the implementation in the JDK overrides this method. The test additions, both in coverage and implementation, are much cleaned now, and better test coverage too. A lot of the discussion here has been on the default implementation of waitFor that Process provides but it's not covered by the tests. I didn't notice this before but it would be good to include a basic test for this, just so that code is exercise. The simplest may be to create a concrete implementation of Process that delegates to a Process instance returned by ProcessBuilder.start. Assuming you don't override the waitFor implementation then it means you will be able to exercise the default waitFor rather than the platform implementation. -Alan. From david.holmes at oracle.com Mon Jun 25 11:17:18 2012 From: david.holmes at oracle.com (David Holmes) Date: Mon, 25 Jun 2012 21:17:18 +1000 Subject: RFR: 7161229 - PriorityBlockingQueue keeps hard reference to last removed element In-Reply-To: <4FE828E4.70200@univ-mlv.fr> References: <4FE7E865.7020106@oracle.com> <4FE828E4.70200@univ-mlv.fr> Message-ID: <4FE848BE.8060401@oracle.com> Hi Remi, On 25/06/2012 7:01 PM, R?mi Forax wrote: > Hi David, > I think the test > > if (n > 0) { > > should not be in siftDown* but should be done at all callsites, > by example in heapify, you can hoist the test outside of the loop. I originally had it at the call-site (it already exists in a number of them) but Doug prefers it to be internalized. He wrote: "... a better strategy is to move the n > 0 check to the siftDown code itself, so (existing and potential) callers don't need the check. ... an explicit n > 0 check acts to hoist array index checks in loop so turns out to be faster in general." > In dequeue, it's a matter of style but the 'else' is not needed anymore. > > Otherwise the changes looks ok for me. Thanks, David > R?mi > > On 06/25/2012 06:26 AM, David Holmes wrote: >> webrev: >> >> http://cr.openjdk.java.net/~dholmes/7161229/webrev/ >> >> When removing the last element from the PBQ the "sift down" logic >> would store it back in as array[0]. The simple fix is for the >> sift-down to be a no-op if the queue size is zero. >> >> The fix has been contributed by Doug Lea. We are taking this >> opportunity to synchronize PBQ with Doug's latest version at: >> >> http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/main/java/util/concurrent/PriorityBlockingQueue.java?view=log >> >> >> So in addition to the above functional fix there are a number of >> miscellaneous code and comment cleanups. The only non-trivial, but >> still very simple, change is to the drainTo method to make it more >> robust if the add() on the destination collection throws an exception. >> >> I am of course a Reviewer for this. >> >> I have provided the update to the LastElement test (as this is >> certainly related to the last element) but there are some reservations >> about examining the PBS internals this way. Unfortunately there is no >> good way to test for these kinds of retention issues. You either need >> a whitebox test like this, or need to rely on non-guaranteed GC and >> finalization behaviour. >> >> Thanks, >> David Holmes > > From Alan.Bateman at oracle.com Mon Jun 25 11:20:59 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 25 Jun 2012 12:20:59 +0100 Subject: String.subSequence and CR#6924259: Remove offset and count fields from java.lang.String In-Reply-To: References: <20120531032252.A69774763C@hg.openjdk.java.net> <1359801.KFxJhQHyve@cube> Message-ID: <4FE8499B.4010003@oracle.com> On 22/06/2012 23:15, Mike Duigou wrote: > : > - The CharSequences returned by subSequence would follow only the general CharSequence rules for equals()/hashCode(). Any current usages of the result of subSequence for equals() or hashing, even though it's not advised, would break. We could add equals() and hashCode() implementations to the CharSequence returned but they would probably be expensive. > I think Jason's idea to use CharBuffer.wrap(...).asReadOnlyBuffer() is a great idea too. However as you mention hashCode/equals then one thing to remember is that they depend on the number of remaining elements. It should be okay assuming that someone doesn't cast to a CharBuffer and invokes a method that changes the position or limit but even so, you won't get any caching of the hash code. -Alan From Alan.Bateman at oracle.com Mon Jun 25 12:14:27 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 25 Jun 2012 13:14:27 +0100 Subject: RFR [JDK8]: 7169894: JAXP Plugability Layer: using service loader In-Reply-To: <4FE81592.6050205@oracle.com> References: <4FE2D380.2010803@oracle.com> <36EF9FE3-70F2-4F95-BDD5-972FA0DD583E@oracle.com> <4FE35B14.6050802@oracle.com> <4FE3623E.9040005@oracle.com> <4FE397D4.2080609@oracle.com> <4FE43D6A.9080107@oracle.com> <4FE4AA53.9080605@oracle.com> <4FE81592.6050205@oracle.com> Message-ID: <4FE85623.2080801@oracle.com> On 25/06/2012 08:38, Joe Wang wrote: > Hi all, > > Thanks for all the comments! > > I've updated the patch for the following recommended changes: > 1. ServiceConfigurationError instead of ConfigurationError > 2. Use factory class, class.forName section removed > 3. Use load method without specifying classloader > 4. To be clear on how the process handles exceptions, I've updated > JavaDoc with the following: > > * Uses the service-provider loading facilities, defined by the > {@link java.util.ServiceLoader} class, to attempt > * to locate and load an implementation of the service. In case > multiple providers exist, the first > * valid 3rd party provider should be returned; If there is no > valid 3rd party provider, > * the default implementation is returned if it is on the > classpath or installed as a module. I think this is better, and I'm okay with your suggestion to deal with the code duplication issue separately. On the above wording then I think term "3rd party provider" may provoke questions. How about "If there are providers other than the implementation specific default located, then the first provider that is not the default is instantiated and returned". I'm not sure about catching and ignoring the ServiceConfigurationError (or "keep on trucking" as Paul termed it in one of the replies). The existing specification reads " Any Exception thrown during the instantiation process is wrapped as a ConfigurationException" so this seems a significant change to me. Would it be cleaner if the FactoryFinder.find methods were changed to: static T find(Class c, String ...) rather than using a raw type and returning Object? That would eliminate some of the casts in this case. I guess if the short term is to have a package-private copy of FactoryFinder in each package then it could be changed to return the specific type. Related to this is the changes increase the number of warnings by using ServiceLoader without a type parameter. -Alan. From forax at univ-mlv.fr Mon Jun 25 12:54:26 2012 From: forax at univ-mlv.fr (=?UTF-8?B?UsOpbWkgRm9yYXg=?=) Date: Mon, 25 Jun 2012 14:54:26 +0200 Subject: RFR: 7161229 - PriorityBlockingQueue keeps hard reference to last removed element In-Reply-To: <4FE848BE.8060401@oracle.com> References: <4FE7E865.7020106@oracle.com> <4FE828E4.70200@univ-mlv.fr> <4FE848BE.8060401@oracle.com> Message-ID: <4FE85F82.6070908@univ-mlv.fr> On 06/25/2012 01:17 PM, David Holmes wrote: > Hi Remi, > > On 25/06/2012 7:01 PM, R?mi Forax wrote: >> Hi David, >> I think the test >> >> if (n > 0) { >> >> should not be in siftDown* but should be done at all callsites, >> by example in heapify, you can hoist the test outside of the loop. > > I originally had it at the call-site (it already exists in a number of > them) but Doug prefers it to be internalized. He wrote: > > "... a better strategy is to move the n > 0 check to the siftDown code > itself, so (existing and potential) callers don't need the check. " This can be mitigated by modifying the doc comment to say that n should be strictly positive. > "... an explicit n > 0 check acts to hoist array index checks in loop > so turns out to be faster in general." also true if n > 0 is done at callsites and methods shiftDown* is inlined, but this is not something that is easy to guarantee because it depends on the complexity of the comparator implementation. so thumb up :) > >> In dequeue, it's a matter of style but the 'else' is not needed anymore. >> >> Otherwise the changes looks ok for me. > > Thanks, > David cheers, R?mi From martijnverburg at gmail.com Mon Jun 25 12:54:53 2012 From: martijnverburg at gmail.com (Martijn Verburg) Date: Mon, 25 Jun 2012 13:54:53 +0100 Subject: Bug 7176907 - Patches for javac warnings cleanup (text and util) from Adopt OpenJDK In-Reply-To: References: <4FE1D95C.3030108@univ-mlv.fr> <4FE1F559.5070802@oracle.com> Message-ID: Hi all, Apologies for the delay. So it was simply a case of human error in missing that last fallthrough (we wanted to double check that our warnings script wasn't failing, hence the delay in getting back to you). I've respun the patch with the extra SuppressWarning. Hopefully the patch is complete now. Cheers, Martijn On 20 June 2012 17:18, Martijn Verburg wrote: > We'll look into it, hopefully have an answer for you shortly - M > > On 20 June 2012 17:07, Kurchi Subhra Hazra > wrote: >> Hi, >> >> ? I was just going through the patches, there are some more fallthrough >> cases in >> src/share/classes/java/util/regex/Pattern.java.(for example in line 2247). >> Are these not generating warnings? >> >> - Kurchi >> >> >> On 6/20/12 7:30 AM, Martijn Verburg wrote: >> >> Hi all, >> >> Apologies, I didn't check that attachments were stripped. ?The patches >> can be found at: >> >> >> https://raw.github.com/AdoptOpenJDK/PatchReview/master/submitted/core_java_text.patch >> >> https://raw.github.com/AdoptOpenJDK/PatchReview/master/submitted/core_java_util.patch >> >> Cheers, >> Martijn >> >> Hi Martijn, >> the two patches looks good. >> >> A minor nit, why is there a space between the '(' and the readUByte() in >> readUShort. >> >> Thanks for the quick review! No reason on the whitespace, I've fixed that >> now. >> >> Quick question. ?Is there a checkstyle or jcheck that we should be >> applying to any corelib patches going forwards? >> >> Cheers, >> Martijn >> >> From anthony.petrov at oracle.com Mon Jun 25 13:19:50 2012 From: anthony.petrov at oracle.com (Anthony Petrov) Date: Mon, 25 Jun 2012 17:19:50 +0400 Subject: [8] Review request for 7162111 change tests run in headless mode [macosx] In-Reply-To: <4FE57019.9090905@oracle.com> References: <4FE5154C.2090703@oracle.com> <4FE57019.9090905@oracle.com> Message-ID: <4FE86576.8020407@oracle.com> Hi Alan and Jason, On 06/23/12 11:28, Alan Bateman wrote: > On 23/06/2012 02:01, Jason Uh wrote: >> This fix was for regression tests failing on Mac OS X on remotely >> executed environments. The changed tests now run in headless mode and >> have been taken off the Problem List. >> >> Webrev: http://cr.openjdk.java.net/~juh/7162111/webrev.00/ >> The CR: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7162111 >> >> Note that test/demo/jvmti/mtrace/TraceJFrame.java was not fixed here >> because headless mode is not supported for JFrame. A separate CR will >> be created for this. >> > It's good to see these tests changed to run headless and will make the > test execution much more reliable. Aside from the mtrace demo there are > a couple of other tests that periodically hang initializing AWT, at > least when running via ssh and then depending on whether someone is > logged in and other configuration settings. Some of the shell tests for > serialization come to mind (BTW: no problem doing that via a separate > bug, just mentioning that there are other tests that are problems too). > > One question, and this may be a question for Artem or others, is that in > CommonSetup.sh you set AWT_TOOLKIT=XToolkit. Is that right? I don't think we need to force XToolkit on the Mac. We don't quite support it on that platform actually. The normal headless CToolkit should work just fine. Could you please revert the changes to CommonSetup.sh and verify if the tests pass? -- best regards, Anthony From chris.hegarty at oracle.com Mon Jun 25 13:20:58 2012 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Mon, 25 Jun 2012 13:20:58 +0000 Subject: hg: jdk8/tl/jdk: 7176784: Windows authentication not working on some computers Message-ID: <20120625132130.61A1D47AED@hg.openjdk.java.net> Changeset: 4a4a04bfeece Author: chegar Date: 2012-06-25 14:19 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4a4a04bfeece 7176784: Windows authentication not working on some computers Reviewed-by: michaelm ! src/windows/native/sun/net/www/protocol/http/ntlm/NTLMAuthSequence.c From paul.sandoz at oracle.com Mon Jun 25 16:13:41 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 25 Jun 2012 18:13:41 +0200 Subject: RFR [7u6]: 7166896: DocumentBuilder.parse(String uri) is not IPv6 enabled. It throws MalformedURLException In-Reply-To: <4FE4FB34.9040808@oracle.com> References: <4FE4FB34.9040808@oracle.com> Message-ID: <22CB14C2-C460-430C-B38D-96E9F92B22C3@oracle.com> Hi Joe, What happens if there is a space character or other characters in the string that should be encoded ? http://greenbytes.de/tech/webdav/rfc2396.html#rfc.section.2.4.3 I suspect "escapeNonUSAscii" is slightly misleading, it should be really called something like "escapeCharactersInUriString". Note that '[' and ']' are not valid URI characters outside of an IPv6 encoded address. Paul. On Jun 23, 2012, at 1:09 AM, Joe Wang wrote: > Hi, > > This is a patch to fix the IPv6 issue. > > In a previous patch to fix an issue with system id containing international characters, an extra character escaping was added so that any URL passed to the parser goes through method escapeNonUSAscii before it's used to construct an URL. > > However, literal IPv6 addresses are enclosed in square brackets. The escapeNonUSAscii encoded address will become unrecognizable to URL that would throw a java.net.MalformedURLException. An address such as http://[fe80::la03:73ff:fead:f7b0]/note.xml is encoded as http://%5Bfe80::la03:73ff:fead:f7b0%5D/note.xml", resulting in java.net.MalformedURLException: For input string: ":la03:73ff:fead:f7b0%5D". > > This patch skips the encoding process and returns it as is if there're no non-ascii characters. > > webrev: http://cr.openjdk.java.net/~joehw/7u6/7166896/webrev/ > > Please review. > > Thanks, > Joe From paul.sandoz at oracle.com Mon Jun 25 16:34:34 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 25 Jun 2012 18:34:34 +0200 Subject: RFR [JDK8]: 7169894: JAXP Plugability Layer: using service loader In-Reply-To: <4FE81592.6050205@oracle.com> References: <4FE2D380.2010803@oracle.com> <36EF9FE3-70F2-4F95-BDD5-972FA0DD583E@oracle.com> <4FE35B14.6050802@oracle.com> <4FE3623E.9040005@oracle.com> <4FE397D4.2080609@oracle.com> <4FE43D6A.9080107@oracle.com> <4FE4AA53.9080605@oracle.com> <4FE81592.6050205@oracle.com> Message-ID: <5B2503A6-374C-4769-8217-6A8CB0A9F353@oracle.com> H Joe, I just focused on javax.xml.datatype and assumed the rest follows the same pattern :-) Like Alan i am still not sure about swallowing the ServiceConfigurationError. It enables something that did not work before so i guess it does not take anything away, if choose that this should be part of the spec then we should document it (as we should the dependence on TCCL). Also i notice that the previous code that explicitly loaded META-INF/service files deferred to SecuritySupport that wraps stuff in AccessController.doPrivileged blocks. Do we need to wrap the use of ServiceLoader in such blocks too? since ServiceLoader will internally call ClassLoader.getResources() and Thread.currentThread().getContextClassLoader(). Paul. On Jun 25, 2012, at 9:38 AM, Joe Wang wrote: > Hi all, > > Thanks for all the comments! > > I've updated the patch for the following recommended changes: > 1. ServiceConfigurationError instead of ConfigurationError > 2. Use factory class, class.forName section removed > 3. Use load method without specifying classloader > 4. To be clear on how the process handles exceptions, I've updated JavaDoc with the following: > > * Uses the service-provider loading facilities, defined by the {@link java.util.ServiceLoader} class, to attempt > * to locate and load an implementation of the service. In case multiple providers exist, the first > * valid 3rd party provider should be returned; If there is no valid 3rd party provider, > * the default implementation is returned if it is on the classpath or installed as a module. > * > * If ServiceConfigurationError is thrown, it is interpreted as an invalid provider is encountered. > * The process shall continue the search until all are exhausted. > > The JavaDoc is similar but slightly different for SchemaFactory and XPathFactory: > > *

Uses the service-provider loading facilities, defined by the {@link java.util.ServiceLoader} class, to attempt > * to locate and load an implementation of the service. > * Each potential service provider is required to implement the method:

> * 
>     *        {@link #isSchemaLanguageSupported(String schemaLanguage)}
>     *
> * A service provider is deemed as valid if it supports the specified schema language. > * > *

> * In case multiple providers exist, the first > * valid 3rd party provider should be returned; If there is no valid 3rd party provider, > * the default implementation is returned if it is on the classpath or installed as a module. > *

> * If ServiceConfigurationError is thrown, it is interpreted as an invalid provider is encountered. > * The process shall continue the search until all are exhausted. > > We can continue discussing on a solution for the duplication of the classes. For this patch, if you agree, I'd like to check it in as it stands now and work out another patch for the duplicated classes once we have a solution. > > New webrev: > http://cr.openjdk.java.net/~joehw/jdk8/7169894/webrev/ > > Thanks, > Joe > > > On 6/22/2012 10:24 AM, Joe Wang wrote: >> >> >> On 6/22/2012 2:39 AM, Alan Bateman wrote: >>> On 21/06/2012 22:53, Joe Wang wrote: >>>> : >>>> >>>> We're not considering this change for jdk7 or older, i.e. I haven't thought about fixing 6975142. For jdk8, it seems we have to live with the way it is in (2), a seemly incompatible behavior in backward compatible mode, although, it is a very rare case (I regret to have taught or sent standalone jar files to those customers :) ). >>> No, this isn't for jdk7 or older. >>> >>> I don't fully grok the issue in 6975142. That looks to me to be a case where the service provider implementation is including its own copy of the javax.xml.stream.* classes and this is the cause of the ClassCastException. >> >> Yes, it's GF packaged woodstox that included its own API packages. >> >> Joe >> >>> >>> -Alan. From huizhe.wang at oracle.com Mon Jun 25 17:03:22 2012 From: huizhe.wang at oracle.com (Joe Wang) Date: Mon, 25 Jun 2012 10:03:22 -0700 Subject: RFR [JDK8]: 7169894: JAXP Plugability Layer: using service loader In-Reply-To: <4FE85623.2080801@oracle.com> References: <4FE2D380.2010803@oracle.com> <36EF9FE3-70F2-4F95-BDD5-972FA0DD583E@oracle.com> <4FE35B14.6050802@oracle.com> <4FE3623E.9040005@oracle.com> <4FE397D4.2080609@oracle.com> <4FE43D6A.9080107@oracle.com> <4FE4AA53.9080605@oracle.com> <4FE81592.6050205@oracle.com> <4FE85623.2080801@oracle.com> Message-ID: <4FE899DA.7030605@oracle.com> On 6/25/2012 5:14 AM, Alan Bateman wrote: > On 25/06/2012 08:38, Joe Wang wrote: >> Hi all, >> >> Thanks for all the comments! >> >> I've updated the patch for the following recommended changes: >> 1. ServiceConfigurationError instead of ConfigurationError >> 2. Use factory class, class.forName section removed >> 3. Use load method without specifying classloader >> 4. To be clear on how the process handles exceptions, I've updated >> JavaDoc with the following: >> >> * Uses the service-provider loading facilities, defined by the >> {@link java.util.ServiceLoader} class, to attempt >> * to locate and load an implementation of the service. In case >> multiple providers exist, the first >> * valid 3rd party provider should be returned; If there is no >> valid 3rd party provider, >> * the default implementation is returned if it is on the >> classpath or installed as a module. > I think this is better, and I'm okay with your suggestion to deal with > the code duplication issue separately. Ok. > > On the above wording then I think term "3rd party provider" may > provoke questions. How about "If there are providers other than the > implementation specific default located, then the first provider that > is not the default is instantiated and returned". That looks to be a better wording. > > I'm not sure about catching and ignoring the ServiceConfigurationError > (or "keep on trucking" as Paul termed it in one of the replies). The > existing specification reads " Any Exception thrown during the > instantiation process is wrapped as a > ConfigurationException" so this seems a significant change > to me. Indeed, that would be a significant change. I think I said I'm not going to fix 6975142, or make it work for jdk7 and older in that matter, but then I still allowed that to dictate the JavaDoc. I guess it's in my mind for too long, or it's because the whole ServiceLoader thing was actually started when I looked at old bugs and found 6975142 :) > > Would it be cleaner if the FactoryFinder.find methods were changed to: > > static T find(Class c, String ...) > > rather than using a raw type and returning Object? That would > eliminate some of the casts in this case. I guess if the short term is > to have a package-private copy of FactoryFinder in each package then > it could be changed to return the specific type. Related to this is > the changes increase the number of warnings by using ServiceLoader > without a type parameter. JAXP code supported -source 1.4 -target 1.4, and changed to 1.5 not long ago. There are lot of old code in JAXP for sure. -Joe > > -Alan. > > > > From paul.sandoz at oracle.com Mon Jun 25 17:13:30 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 25 Jun 2012 19:13:30 +0200 Subject: RFR [JDK8]: 7169894: JAXP Plugability Layer: using service loader In-Reply-To: <4FE81592.6050205@oracle.com> References: <4FE2D380.2010803@oracle.com> <36EF9FE3-70F2-4F95-BDD5-972FA0DD583E@oracle.com> <4FE35B14.6050802@oracle.com> <4FE3623E.9040005@oracle.com> <4FE397D4.2080609@oracle.com> <4FE43D6A.9080107@oracle.com> <4FE4AA53.9080605@oracle.com> <4FE81592.6050205@oracle.com> Message-ID: <90A83499-21F8-474C-B6DB-6D15CF1EB318@oracle.com> On Jun 25, 2012, at 9:38 AM, Joe Wang wrote: > New webrev: > http://cr.openjdk.java.net/~joehw/jdk8/7169894/webrev/ > In javax.xml.datatype.DatatypeFactory: 245 if (provider.getClass().getName().contains(fallbackClassName)) { Strictly speaking the above should be "provider.getClass().getName().equals(fallbackClassName)". Paul. From Alan.Bateman at oracle.com Mon Jun 25 18:59:44 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 25 Jun 2012 19:59:44 +0100 Subject: RFR [JDK8]: 7169894: JAXP Plugability Layer: using service loader In-Reply-To: <4FE899DA.7030605@oracle.com> References: <4FE2D380.2010803@oracle.com> <36EF9FE3-70F2-4F95-BDD5-972FA0DD583E@oracle.com> <4FE35B14.6050802@oracle.com> <4FE3623E.9040005@oracle.com> <4FE397D4.2080609@oracle.com> <4FE43D6A.9080107@oracle.com> <4FE4AA53.9080605@oracle.com> <4FE81592.6050205@oracle.com> <4FE85623.2080801@oracle.com> <4FE899DA.7030605@oracle.com> Message-ID: <4FE8B520.1000306@oracle.com> On 25/06/2012 18:03, Joe Wang wrote: > > : > >> >> I'm not sure about catching and ignoring the >> ServiceConfigurationError (or "keep on trucking" as Paul termed it in >> one of the replies). The existing specification reads " Any Exception >> thrown during the instantiation process is wrapped as a >> ConfigurationException" so this seems a significant change >> to me. > > Indeed, that would be a significant change. I think I said I'm not > going to fix 6975142, or make it work for jdk7 and older in that > matter, but then I still allowed that to dictate the JavaDoc. I guess > it's in my mind for too long, or it's because the whole ServiceLoader > thing was actually started when I looked at old bugs and found 6975142 :) 6975142 seems to be a case of someone trying to use two versions of the JAXP API in the same application. That's a bit different to having different service provider implementations installed. For now I would suggest focusing on the latter. Jigsaw aside, I think it's it would be good for JAXP to be using ServiceLoader anyway. -Alan. From huizhe.wang at oracle.com Mon Jun 25 19:19:49 2012 From: huizhe.wang at oracle.com (Joe Wang) Date: Mon, 25 Jun 2012 12:19:49 -0700 Subject: RFR [JDK8]: 7169894: JAXP Plugability Layer: using service loader In-Reply-To: <5B2503A6-374C-4769-8217-6A8CB0A9F353@oracle.com> References: <4FE2D380.2010803@oracle.com> <36EF9FE3-70F2-4F95-BDD5-972FA0DD583E@oracle.com> <4FE35B14.6050802@oracle.com> <4FE3623E.9040005@oracle.com> <4FE397D4.2080609@oracle.com> <4FE43D6A.9080107@oracle.com> <4FE4AA53.9080605@oracle.com> <4FE81592.6050205@oracle.com> <5B2503A6-374C-4769-8217-6A8CB0A9F353@oracle.com> Message-ID: <4FE8B9D5.6030005@oracle.com> On 6/25/2012 9:34 AM, Paul Sandoz wrote: > H Joe, > > I just focused on javax.xml.datatype and assumed the rest follows the same pattern :-) Yeah, they are mostly similar, except Schema and XPath that do a little extra check. > > Like Alan i am still not sure about swallowing the ServiceConfigurationError. It enables something that did not work before so i guess it does not take anything away, if choose that this should be part of the spec then we should document it (as we should the dependence on TCCL). Agree. It would be a compatibility concern. > > Also i notice that the previous code that explicitly loaded META-INF/service files deferred to SecuritySupport that wraps stuff in AccessController.doPrivileged blocks. Do we need to wrap the use of ServiceLoader in such blocks too? since ServiceLoader will internally call ClassLoader.getResources() and Thread.currentThread().getContextClassLoader(). Good catch, yes we do! We're virtually delegating those calls to the ServiceLoader that could be blocked when security is on. Joe > > Paul. > > On Jun 25, 2012, at 9:38 AM, Joe Wang wrote: > >> Hi all, >> >> Thanks for all the comments! >> >> I've updated the patch for the following recommended changes: >> 1. ServiceConfigurationError instead of ConfigurationError >> 2. Use factory class, class.forName section removed >> 3. Use load method without specifying classloader >> 4. To be clear on how the process handles exceptions, I've updated JavaDoc with the following: >> >> * Uses the service-provider loading facilities, defined by the {@link java.util.ServiceLoader} class, to attempt >> * to locate and load an implementation of the service. In case multiple providers exist, the first >> * valid 3rd party provider should be returned; If there is no valid 3rd party provider, >> * the default implementation is returned if it is on the classpath or installed as a module. >> * >> * If ServiceConfigurationError is thrown, it is interpreted as an invalid provider is encountered. >> * The process shall continue the search until all are exhausted. >> >> The JavaDoc is similar but slightly different for SchemaFactory and XPathFactory: >> >> *

Uses the service-provider loading facilities, defined by the {@link java.util.ServiceLoader} class, to attempt >> * to locate and load an implementation of the service. >> * Each potential service provider is required to implement the method:

>> *
>>      *        {@link #isSchemaLanguageSupported(String schemaLanguage)}
>>      *
>> * A service provider is deemed as valid if it supports the specified schema language. >> * >> *

>> * In case multiple providers exist, the first >> * valid 3rd party provider should be returned; If there is no valid 3rd party provider, >> * the default implementation is returned if it is on the classpath or installed as a module. >> *

>> * If ServiceConfigurationError is thrown, it is interpreted as an invalid provider is encountered. >> * The process shall continue the search until all are exhausted. >> >> We can continue discussing on a solution for the duplication of the classes. For this patch, if you agree, I'd like to check it in as it stands now and work out another patch for the duplicated classes once we have a solution. >> >> New webrev: >> http://cr.openjdk.java.net/~joehw/jdk8/7169894/webrev/ >> >> Thanks, >> Joe >> >> >> On 6/22/2012 10:24 AM, Joe Wang wrote: >>> >>> On 6/22/2012 2:39 AM, Alan Bateman wrote: >>>> On 21/06/2012 22:53, Joe Wang wrote: >>>>> : >>>>> >>>>> We're not considering this change for jdk7 or older, i.e. I haven't thought about fixing 6975142. For jdk8, it seems we have to live with the way it is in (2), a seemly incompatible behavior in backward compatible mode, although, it is a very rare case (I regret to have taught or sent standalone jar files to those customers :) ). >>>> No, this isn't for jdk7 or older. >>>> >>>> I don't fully grok the issue in 6975142. That looks to me to be a case where the service provider implementation is including its own copy of the javax.xml.stream.* classes and this is the cause of the ClassCastException. >>> Yes, it's GF packaged woodstox that included its own API packages. >>> >>> Joe >>> >>>> -Alan. From jim.gish at oracle.com Mon Jun 25 19:32:44 2012 From: jim.gish at oracle.com (Jim Gish) Date: Mon, 25 Jun 2012 15:32:44 -0400 Subject: Review Request: CR 7100996 - (spec str) IndexOutOfBoundsException when using a StringBuffer from multiple threads In-Reply-To: <4FE39325.1040607@CoSoCo.de> References: <4FE344F3.6080802@oracle.com> <4FE363A2.2080308@oracle.com> <4FE39325.1040607@CoSoCo.de> Message-ID: <4FE8BCDC.9040006@oracle.com> Hopefully, this will address most, if not all of the suggestions made to date. ....Jim diff -r f37afaa214e9 src/share/classes/java/lang/StringBuffer.java --- a/src/share/classes/java/lang/StringBuffer.java Mon Jun 25 14:22:42 2012 -0400 +++ b/src/share/classes/java/lang/StringBuffer.java Mon Jun 25 15:30:57 2012 -0400 @@ -39,40 +39,38 @@ * that is consistent with the order of the method calls made by each of * the individual threads involved. *

- * The principal operations on a StringBuffer are the - * append and insert methods, which are + * The principal operations on a {@code StringBuffer} are the + * {@code append} and {@code insert} methods, which are * overloaded so as to accept data of any type. Each effectively * converts a given datum to a string and then appends or inserts the * characters of that string to the string buffer. The - * append method always adds these characters at the end - * of the buffer; the insert method adds the characters at + * {@code append} method always adds these characters at the end + * of the buffer; the {@code insert} method adds the characters at * a specified point. *

- * For example, if z refers to a string buffer object - * whose current contents are "start", then - * the method call z.append("le") would cause the string - * buffer to contain "startle", whereas - * z.insert(4, "le") would alter the string buffer to - * contain "starlet". + * For example, if {@code z} refers to a string buffer object + * whose current contents are "{@code start}", then + * the method call {@code z.append("le")} would cause the string + * buffer to contain "{@code startle}", whereas + * {@code z.insert(4, "le")} would alter the string buffer to + * contain "{@code starlet}". *

- * In general, if sb refers to an instance of a StringBuffer, - * then sb.append(x) has the same effect as - * sb.insert(sb.length(), x). + * In general, if sb refers to an instance of a {@code StringBuffer}, + * then {@code sb.append(x)} has the same effect as + * {@code sb.insert(sb.length(), x)}. *

* Whenever an operation occurs involving a source sequence (such as - * appending or inserting from a source sequence) this class synchronizes + * appending or inserting from a source sequence), this class synchronizes * only on the string buffer performing the operation, not on the source. - *

- * Although {@code StringBuffer} is designed to be safe to use - * concurrently from multiple threads, if the source data passed - * to the constructor, i.e. {@code StringBuffer(source)}, or to the - * {@code append(source)}, or {@code insert(source)} operations - * is shared across threads, it must be ensured that the operations have - * a consistent and unchanging view of the source data for the duration - * of the operation. + * {@code StringBuffer} is designed to be safe to use + * concurrently from multiple threads, but if the source data passed + * to the constructor or to the {@code append()}, or {@code insert()} + * operations is shared across threads, the calling code must be ensure + * that the operations have a consistent and unchanging view of the source + * data for the duration of the operation. * This could be satisfied by the caller holding a lock during the - * operation's call, or because the source data is - * immutable, or because the source data is not shared across threads. + * operation's call, or by the source data being + * immutable, or by the source data not being shared across threads. *

* Every string buffer has a capacity. As long as the length of the * character sequence contained in the string buffer does not exceed @@ -112,8 +110,8 @@ * the specified initial capacity. * * @param capacity the initial capacity. - * @exception NegativeArraySizeException if the capacity - * argument is less than 0. + * @exception NegativeArraySizeException if the {@code capacity} + * argument is less than {@code 0}. */ public StringBuffer(int capacity) { super(capacity); @@ -122,10 +120,10 @@ /** * Constructs a string buffer initialized to the contents of the * specified string. The initial capacity of the string buffer is - * 16 plus the length of the string argument. + * {@code 16} plus the length of the string argument. * * @param str the initial contents of the buffer. - * @exception NullPointerException if str is null + * @exception NullPointerException if {@code str} is {@code null} */ public StringBuffer(String str) { super(str.length() + 16); @@ -134,16 +132,16 @@ /** * Constructs a string buffer that contains the same characters - * as the specified CharSequence. The initial capacity of - * the string buffer is 16 plus the length of the - * CharSequence argument. + * as the specified {@code CharSequence}. The initial capacity of + * the string buffer is {@code 16} plus the length of the + * {@code CharSequence} argument. *

- * If the length of the specified CharSequence is + * If the length of the specified {@code CharSequence} is * less than or equal to zero, then an empty buffer of capacity - * 16 is returned. + * {@code 16} is returned. * * @param seq the sequence to copy. - * @exception NullPointerException if seq is null + * @exception NullPointerException if {@code seq} is {@code null} * @since 1.5 */ public StringBuffer(CharSequence seq) { @@ -264,10 +262,10 @@ * the new character sequence is equal to the character at index k * in the old character sequence, if k is less than n; * otherwise, it is equal to the character at index k-n in the - * argument sb. + * argument {@code sb}. *

- * This method synchronizes on this (the destination) - * object but does not synchronize on the source (sb). + * This method synchronizes on {@code this} (the destination) + * object but does not synchronize on the source ({@code sb}). * * @param sb the StringBuffer to append. * @return a reference to this object. @@ -280,10 +278,10 @@ /** - * Appends the specified CharSequence to this + * Appends the specified {@code CharSequence} to this * sequence. *

- * The characters of the CharSequence argument are appended, + * The characters of the {@code CharSequence} argument are appended, * in order, increasing the length of this sequence by the length of the * argument. * @@ -291,12 +289,12 @@ * invocation of this.append(s, 0, s.length()); * *

This method synchronizes on this (the destination) - * object but does not synchronize on the source (s). + * object but does not synchronize on the source ({@code s}). * - *

If s is null, then the four characters - * "null" are appended. + *

If {@code s} is {@code null}, then the four characters + * {@code "null"} are appended. * - * @param s the CharSequence to append. + * @param s the {@code CharSequence} to append. * @return a reference to this object. * @since 1.5 */ From sean.coffey at oracle.com Mon Jun 25 20:26:15 2012 From: sean.coffey at oracle.com (Sean Coffey) Date: Mon, 25 Jun 2012 21:26:15 +0100 Subject: RFR : 7162902 / 6893617 Umbrella port of a number of corba bug fixes from JDK 6 to jdk7u/8 Message-ID: <4FE8C967.1030302@oracle.com> Hi, I'm looking for a code review around the following corba changes. It turns out that we've a few bug fixes in corba area for jdk6 that were never forward ported to jdk7 or 8. The port is pretty much identical to what was used in JDK6. Some formatting and diamond operator changes introduced but that's about it. There were a few bug fixes to follow up on regressions around the initial fix but this umbrella port should cover all issues. The initial bugs fixes were fixed under the "jets" category in the bug tool and that category entered read only mode over a year ago. Hence the requirement for a new bug ID. The main bug fix is 6725987 which is an issue where references to the ORB were being kept after ORB.destroy was called. http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7162902 An accompanying CNCtx fix in JDK repo is also made to correct an issue where the java.naming.corba.orb system property wasn't used correctly. (CR 6893617) http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6893617 Corba testsuites run and no issues seen. I've also run some JCK testing and saw no issues. http://cr.openjdk.java.net/~coffeys/webrev.7162902.jdk8/ (corba) http://cr.openjdk.java.net/~coffeys/webrev.6893617.jdk8/ (jdk) The corba codebase code formatting seems to vary quite a bit. I've reformatted in a small number of areas but the whole corba repo probably warrants it's own clean up project at a later date. regards, Sean. From Ulf.Zibis at CoSoCo.de Mon Jun 25 21:34:19 2012 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Mon, 25 Jun 2012 23:34:19 +0200 Subject: Review Request: CR 7100996 - (spec str) IndexOutOfBoundsException when using a StringBuffer from multiple threads In-Reply-To: <4FE8BCDC.9040006@oracle.com> References: <4FE344F3.6080802@oracle.com> <4FE363A2.2080308@oracle.com> <4FE39325.1040607@CoSoCo.de> <4FE8BCDC.9040006@oracle.com> Message-ID: <4FE8D95B.1090201@CoSoCo.de> Hi Jim, maybe you like to read some more comments... I'm not sure, wich would be better, but IMO should be used consistent: {@code append()} {@code append} I think, the double quotes belong to the code for "{@code start}" etc. --> {@code "start"} I do not understand, why you change from term "source sequence" to term "source data" at some point. Problem with commas, grammar and wording: * concurrently from multiple threads, but if the source data passed * to the constructor or to the {@code append()}, or {@code insert()} * operations is shared across threads, the calling code must be ensure * that the operations have a consistent and unchanging view of the source * data for the duration of the operation. * This could be satisfied by the caller holding a lock during the I would write: * concurrently from multiple threads, but if the source data, passed * to a constructor, to the {@code append()} or {@code insert()} * operations, is shared across threads, the calling code must ensure, * that they have a consistent and unchanging view on the source * data for the duration of the operation. * This could be satisfied by the caller, holding a lock during the Wording: * operation's call, or by the source data being * immutable, or by the source data not being shared across threads. I would write: * operation's call, by immutable source data, * or by not sharing the source data across threads. Missing commas: * character sequence contained in the string buffer does not exceed * character sequence, contained in the string buffer, does not exceed Missing comma at 2 locations of: * object but does not synchronize on the source ({@code sb}). * object, but does not synchronize on the source ({@code sb}). -Ulf Am 25.06.2012 21:32, schrieb Jim Gish: > Hopefully, this will address most, if not all of the suggestions made to date. > > ....Jim > > diff -r f37afaa214e9 src/share/classes/java/lang/StringBuffer.java > --- a/src/share/classes/java/lang/StringBuffer.java Mon Jun 25 14:22:42 2012 -0400 > +++ b/src/share/classes/java/lang/StringBuffer.java Mon Jun 25 15:30:57 2012 -0400 > @@ -39,40 +39,38 @@ > * that is consistent with the order of the method calls made by each of > * the individual threads involved. > *

> - * The principal operations on a StringBuffer are the > - * append and insert methods, which are > + * The principal operations on a {@code StringBuffer} are the > + * {@code append} and {@code insert} methods, which are > * overloaded so as to accept data of any type. Each effectively > * converts a given datum to a string and then appends or inserts the > * characters of that string to the string buffer. The > - * append method always adds these characters at the end > - * of the buffer; the insert method adds the characters at > + * {@code append} method always adds these characters at the end > + * of the buffer; the {@code insert} method adds the characters at > * a specified point. > *

> - * For example, if z refers to a string buffer object > - * whose current contents are "start", then > - * the method call z.append("le") would cause the string > - * buffer to contain "startle", whereas > - * z.insert(4, "le") would alter the string buffer to > - * contain "starlet". > + * For example, if {@code z} refers to a string buffer object > + * whose current contents are "{@code start}", then > + * the method call {@code z.append("le")} would cause the string > + * buffer to contain "{@code startle}", whereas > + * {@code z.insert(4, "le")} would alter the string buffer to > + * contain "{@code starlet}". > *

> - * In general, if sb refers to an instance of a StringBuffer, > - * then sb.append(x) has the same effect as > - * sb.insert(sb.length(), x). > + * In general, if sb refers to an instance of a {@code StringBuffer}, > + * then {@code sb.append(x)} has the same effect as > + * {@code sb.insert(sb.length(), x)}. > *

> * Whenever an operation occurs involving a source sequence (such as > - * appending or inserting from a source sequence) this class synchronizes > + * appending or inserting from a source sequence), this class synchronizes > * only on the string buffer performing the operation, not on the source. > - *

> - * Although {@code StringBuffer} is designed to be safe to use > - * concurrently from multiple threads, if the source data passed > - * to the constructor, i.e. {@code StringBuffer(source)}, or to the > - * {@code append(source)}, or {@code insert(source)} operations > - * is shared across threads, it must be ensured that the operations have > - * a consistent and unchanging view of the source data for the duration > - * of the operation. > + * {@code StringBuffer} is designed to be safe to use > + * concurrently from multiple threads, but if the source data passed > + * to the constructor or to the {@code append()}, or {@code insert()} > + * operations is shared across threads, the calling code must be ensure > + * that the operations have a consistent and unchanging view of the source > + * data for the duration of the operation. > * This could be satisfied by the caller holding a lock during the > - * operation's call, or because the source data is > - * immutable, or because the source data is not shared across threads. > + * operation's call, or by the source data being > + * immutable, or by the source data not being shared across threads. > *

> * Every string buffer has a capacity. As long as the length of the > * character sequence contained in the string buffer does not exceed > @@ -112,8 +110,8 @@ > * the specified initial capacity. > * > * @param capacity the initial capacity. > - * @exception NegativeArraySizeException if the capacity > - * argument is less than 0. > + * @exception NegativeArraySizeException if the {@code capacity} > + * argument is less than {@code 0}. > */ > public StringBuffer(int capacity) { > super(capacity); > @@ -122,10 +120,10 @@ > /** > * Constructs a string buffer initialized to the contents of the > * specified string. The initial capacity of the string buffer is > - * 16 plus the length of the string argument. > + * {@code 16} plus the length of the string argument. > * > * @param str the initial contents of the buffer. > - * @exception NullPointerException if str is null > + * @exception NullPointerException if {@code str} is {@code null} > */ > public StringBuffer(String str) { > super(str.length() + 16); > @@ -134,16 +132,16 @@ > > /** > * Constructs a string buffer that contains the same characters > - * as the specified CharSequence. The initial capacity of > - * the string buffer is 16 plus the length of the > - * CharSequence argument. > + * as the specified {@code CharSequence}. The initial capacity of > + * the string buffer is {@code 16} plus the length of the > + * {@code CharSequence} argument. > *

> - * If the length of the specified CharSequence is > + * If the length of the specified {@code CharSequence} is > * less than or equal to zero, then an empty buffer of capacity > - * 16 is returned. > + * {@code 16} is returned. > * > * @param seq the sequence to copy. > - * @exception NullPointerException if seq is null > + * @exception NullPointerException if {@code seq} is {@code null} > * @since 1.5 > */ > public StringBuffer(CharSequence seq) { > @@ -264,10 +262,10 @@ > * the new character sequence is equal to the character at index k > * in the old character sequence, if k is less than n; > * otherwise, it is equal to the character at index k-n in the > - * argument sb. > + * argument {@code sb}. > *

> - * This method synchronizes on this (the destination) > - * object but does not synchronize on the source (sb). > + * This method synchronizes on {@code this} (the destination) > + * object but does not synchronize on the source ({@code sb}). > * > * @param sb the StringBuffer to append. > * @return a reference to this object. > @@ -280,10 +278,10 @@ > > > /** > - * Appends the specified CharSequence to this > + * Appends the specified {@code CharSequence} to this > * sequence. > *

> - * The characters of the CharSequence argument are appended, > + * The characters of the {@code CharSequence} argument are appended, > * in order, increasing the length of this sequence by the length of the > * argument. > * > @@ -291,12 +289,12 @@ > * invocation of this.append(s, 0, s.length()); > * > *

This method synchronizes on this (the destination) > - * object but does not synchronize on the source (s). > + * object but does not synchronize on the source ({@code s}). > * > - *

If s is null, then the four characters > - * "null" are appended. > + *

If {@code s} is {@code null}, then the four characters > + * {@code "null"} are appended. > * > - * @param s the CharSequence to append. > + * @param s the {@code CharSequence} to append. > * @return a reference to this object. > * @since 1.5 > */ > > > > From jim.gish at oracle.com Mon Jun 25 21:41:43 2012 From: jim.gish at oracle.com (Jim Gish) Date: Mon, 25 Jun 2012 14:41:43 -0700 (PDT) Subject: Review Request: CR 7100996 - (spec str) IndexOutOfBoundsException when using a StringBuffer from multiple threads Message-ID: <2054e804-49c6-45e8-8823-7a8d8c02fc89@default> Yes "be ensure" was certainly not intended. Thanks for catching that slip-up. Also, "source sequence" was intended. I'll check out the inconsistencies so that we can nail this down on the next iteration. Thanks, Jim ----- Original Message ----- From: Ulf.Zibis at CoSoCo.de To: jim.gish at oracle.com Cc: core-libs-dev at openjdk.java.net Sent: Monday, June 25, 2012 5:34:26 PM GMT -05:00 US/Canada Eastern Subject: Re: Review Request: CR 7100996 - (spec str) IndexOutOfBoundsException when using a StringBuffer from multiple threads Hi Jim, maybe you like to read some more comments... I'm not sure, wich would be better, but IMO should be used consistent: {@code append()} {@code append} I think, the double quotes belong to the code for "{@code start}" etc. --> {@code "start"} I do not understand, why you change from term "source sequence" to term "source data" at some point. Problem with commas, grammar and wording: * concurrently from multiple threads, but if the source data passed * to the constructor or to the {@code append()}, or {@code insert()} * operations is shared across threads, the calling code must be ensure * that the operations have a consistent and unchanging view of the source * data for the duration of the operation. * This could be satisfied by the caller holding a lock during the I would write: * concurrently from multiple threads, but if the source data, passed * to a constructor, to the {@code append()} or {@code insert()} * operations, is shared across threads, the calling code must ensure, * that they have a consistent and unchanging view on the source * data for the duration of the operation. * This could be satisfied by the caller, holding a lock during the Wording: * operation's call, or by the source data being * immutable, or by the source data not being shared across threads. I would write: * operation's call, by immutable source data, * or by not sharing the source data across threads. Missing commas: * character sequence contained in the string buffer does not exceed * character sequence, contained in the string buffer, does not exceed Missing comma at 2 locations of: * object but does not synchronize on the source ({@code sb}). * object, but does not synchronize on the source ({@code sb}). -Ulf Am 25.06.2012 21:32, schrieb Jim Gish: > Hopefully, this will address most, if not all of the suggestions made to date. > > ....Jim > > diff -r f37afaa214e9 src/share/classes/java/lang/StringBuffer.java > --- a/src/share/classes/java/lang/StringBuffer.java Mon Jun 25 14:22:42 2012 -0400 > +++ b/src/share/classes/java/lang/StringBuffer.java Mon Jun 25 15:30:57 2012 -0400 > @@ -39,40 +39,38 @@ > * that is consistent with the order of the method calls made by each of > * the individual threads involved. > *

> - * The principal operations on a StringBuffer are the > - * append and insert methods, which are > + * The principal operations on a {@code StringBuffer} are the > + * {@code append} and {@code insert} methods, which are > * overloaded so as to accept data of any type. Each effectively > * converts a given datum to a string and then appends or inserts the > * characters of that string to the string buffer. The > - * append method always adds these characters at the end > - * of the buffer; the insert method adds the characters at > + * {@code append} method always adds these characters at the end > + * of the buffer; the {@code insert} method adds the characters at > * a specified point. > *

> - * For example, if z refers to a string buffer object > - * whose current contents are "start", then > - * the method call z.append("le") would cause the string > - * buffer to contain "startle", whereas > - * z.insert(4, "le") would alter the string buffer to > - * contain "starlet". > + * For example, if {@code z} refers to a string buffer object > + * whose current contents are "{@code start}", then > + * the method call {@code z.append("le")} would cause the string > + * buffer to contain "{@code startle}", whereas > + * {@code z.insert(4, "le")} would alter the string buffer to > + * contain "{@code starlet}". > *

> - * In general, if sb refers to an instance of a StringBuffer, > - * then sb.append(x) has the same effect as > - * sb.insert(sb.length(), x). > + * In general, if sb refers to an instance of a {@code StringBuffer}, > + * then {@code sb.append(x)} has the same effect as > + * {@code sb.insert(sb.length(), x)}. > *

> * Whenever an operation occurs involving a source sequence (such as > - * appending or inserting from a source sequence) this class synchronizes > + * appending or inserting from a source sequence), this class synchronizes > * only on the string buffer performing the operation, not on the source. > - *

> - * Although {@code StringBuffer} is designed to be safe to use > - * concurrently from multiple threads, if the source data passed > - * to the constructor, i.e. {@code StringBuffer(source)}, or to the > - * {@code append(source)}, or {@code insert(source)} operations > - * is shared across threads, it must be ensured that the operations have > - * a consistent and unchanging view of the source data for the duration > - * of the operation. > + * {@code StringBuffer} is designed to be safe to use > + * concurrently from multiple threads, but if the source data passed > + * to the constructor or to the {@code append()}, or {@code insert()} > + * operations is shared across threads, the calling code must be ensure > + * that the operations have a consistent and unchanging view of the source > + * data for the duration of the operation. > * This could be satisfied by the caller holding a lock during the > - * operation's call, or because the source data is > - * immutable, or because the source data is not shared across threads. > + * operation's call, or by the source data being > + * immutable, or by the source data not being shared across threads. > *

> * Every string buffer has a capacity. As long as the length of the > * character sequence contained in the string buffer does not exceed > @@ -112,8 +110,8 @@ > * the specified initial capacity. > * > * @param capacity the initial capacity. > - * @exception NegativeArraySizeException if the capacity > - * argument is less than 0. > + * @exception NegativeArraySizeException if the {@code capacity} > + * argument is less than {@code 0}. > */ > public StringBuffer(int capacity) { > super(capacity); > @@ -122,10 +120,10 @@ > /** > * Constructs a string buffer initialized to the contents of the > * specified string. The initial capacity of the string buffer is > - * 16 plus the length of the string argument. > + * {@code 16} plus the length of the string argument. > * > * @param str the initial contents of the buffer. > - * @exception NullPointerException if str is null > + * @exception NullPointerException if {@code str} is {@code null} > */ > public StringBuffer(String str) { > super(str.length() + 16); > @@ -134,16 +132,16 @@ > > /** > * Constructs a string buffer that contains the same characters > - * as the specified CharSequence. The initial capacity of > - * the string buffer is 16 plus the length of the > - * CharSequence argument. > + * as the specified {@code CharSequence}. The initial capacity of > + * the string buffer is {@code 16} plus the length of the > + * {@code CharSequence} argument. > *

> - * If the length of the specified CharSequence is > + * If the length of the specified {@code CharSequence} is > * less than or equal to zero, then an empty buffer of capacity > - * 16 is returned. > + * {@code 16} is returned. > * > * @param seq the sequence to copy. > - * @exception NullPointerException if seq is null > + * @exception NullPointerException if {@code seq} is {@code null} > * @since 1.5 > */ > public StringBuffer(CharSequence seq) { > @@ -264,10 +262,10 @@ > * the new character sequence is equal to the character at index k > * in the old character sequence, if k is less than n; > * otherwise, it is equal to the character at index k-n in the > - * argument sb. > + * argument {@code sb}. > *

> - * This method synchronizes on this (the destination) > - * object but does not synchronize on the source (sb). > + * This method synchronizes on {@code this} (the destination) > + * object but does not synchronize on the source ({@code sb}). > * > * @param sb the StringBuffer to append. > * @return a reference to this object. > @@ -280,10 +278,10 @@ > > > /** > - * Appends the specified CharSequence to this > + * Appends the specified {@code CharSequence} to this > * sequence. > *

> - * The characters of the CharSequence argument are appended, > + * The characters of the {@code CharSequence} argument are appended, > * in order, increasing the length of this sequence by the length of the > * argument. > * > @@ -291,12 +289,12 @@ > * invocation of this.append(s, 0, s.length()); > * > *

This method synchronizes on this (the destination) > - * object but does not synchronize on the source (s). > + * object but does not synchronize on the source ({@code s}). > * > - *

If s is null, then the four characters > - * "null" are appended. > + *

If {@code s} is {@code null}, then the four characters > + * {@code "null"} are appended. > * > - * @param s the CharSequence to append. > + * @param s the {@code CharSequence} to append. > * @return a reference to this object. > * @since 1.5 > */ > > > > From jim.gish at oracle.com Mon Jun 25 21:52:31 2012 From: jim.gish at oracle.com (Jim Gish) Date: Mon, 25 Jun 2012 14:52:31 -0700 (PDT) Subject: Review Request: CR 7100996 - (spec str) IndexOutOfBoundsException when using a StringBuffer from multiple threads Message-ID: <444ef83b-5eff-4dde-b011-0638108d7d88@default> I just realized that some of the things you're pointing out have already been fixed. It's just that I messed up when I did the diff :-( (Still getting used to mercurial. Ugh!). Jim ----- Original Message ----- From: jim.gish at oracle.com To: Ulf.Zibis at CoSoCo.de Cc: core-libs-dev at openjdk.java.net Sent: Monday, June 25, 2012 5:43:06 PM GMT -05:00 US/Canada Eastern Subject: Re: Review Request: CR 7100996 - (spec str) IndexOutOfBoundsException when using a StringBuffer from multiple threads Yes "be ensure" was certainly not intended. Thanks for catching that slip-up. Also, "source sequence" was intended. I'll check out the inconsistencies so that we can nail this down on the next iteration. Thanks, Jim ----- Original Message ----- From: Ulf.Zibis at CoSoCo.de To: jim.gish at oracle.com Cc: core-libs-dev at openjdk.java.net Sent: Monday, June 25, 2012 5:34:26 PM GMT -05:00 US/Canada Eastern Subject: Re: Review Request: CR 7100996 - (spec str) IndexOutOfBoundsException when using a StringBuffer from multiple threads Hi Jim, maybe you like to read some more comments... I'm not sure, wich would be better, but IMO should be used consistent: {@code append()} {@code append} I think, the double quotes belong to the code for "{@code start}" etc. --> {@code "start"} I do not understand, why you change from term "source sequence" to term "source data" at some point. Problem with commas, grammar and wording: * concurrently from multiple threads, but if the source data passed * to the constructor or to the {@code append()}, or {@code insert()} * operations is shared across threads, the calling code must be ensure * that the operations have a consistent and unchanging view of the source * data for the duration of the operation. * This could be satisfied by the caller holding a lock during the I would write: * concurrently from multiple threads, but if the source data, passed * to a constructor, to the {@code append()} or {@code insert()} * operations, is shared across threads, the calling code must ensure, * that they have a consistent and unchanging view on the source * data for the duration of the operation. * This could be satisfied by the caller, holding a lock during the Wording: * operation's call, or by the source data being * immutable, or by the source data not being shared across threads. I would write: * operation's call, by immutable source data, * or by not sharing the source data across threads. Missing commas: * character sequence contained in the string buffer does not exceed * character sequence, contained in the string buffer, does not exceed Missing comma at 2 locations of: * object but does not synchronize on the source ({@code sb}). * object, but does not synchronize on the source ({@code sb}). -Ulf Am 25.06.2012 21:32, schrieb Jim Gish: > Hopefully, this will address most, if not all of the suggestions made to date. > > ....Jim > > diff -r f37afaa214e9 src/share/classes/java/lang/StringBuffer.java > --- a/src/share/classes/java/lang/StringBuffer.java Mon Jun 25 14:22:42 2012 -0400 > +++ b/src/share/classes/java/lang/StringBuffer.java Mon Jun 25 15:30:57 2012 -0400 > @@ -39,40 +39,38 @@ > * that is consistent with the order of the method calls made by each of > * the individual threads involved. > *

> - * The principal operations on a StringBuffer are the > - * append and insert methods, which are > + * The principal operations on a {@code StringBuffer} are the > + * {@code append} and {@code insert} methods, which are > * overloaded so as to accept data of any type. Each effectively > * converts a given datum to a string and then appends or inserts the > * characters of that string to the string buffer. The > - * append method always adds these characters at the end > - * of the buffer; the insert method adds the characters at > + * {@code append} method always adds these characters at the end > + * of the buffer; the {@code insert} method adds the characters at > * a specified point. > *

> - * For example, if z refers to a string buffer object > - * whose current contents are "start", then > - * the method call z.append("le") would cause the string > - * buffer to contain "startle", whereas > - * z.insert(4, "le") would alter the string buffer to > - * contain "starlet". > + * For example, if {@code z} refers to a string buffer object > + * whose current contents are "{@code start}", then > + * the method call {@code z.append("le")} would cause the string > + * buffer to contain "{@code startle}", whereas > + * {@code z.insert(4, "le")} would alter the string buffer to > + * contain "{@code starlet}". > *

> - * In general, if sb refers to an instance of a StringBuffer, > - * then sb.append(x) has the same effect as > - * sb.insert(sb.length(), x). > + * In general, if sb refers to an instance of a {@code StringBuffer}, > + * then {@code sb.append(x)} has the same effect as > + * {@code sb.insert(sb.length(), x)}. > *

> * Whenever an operation occurs involving a source sequence (such as > - * appending or inserting from a source sequence) this class synchronizes > + * appending or inserting from a source sequence), this class synchronizes > * only on the string buffer performing the operation, not on the source. > - *

> - * Although {@code StringBuffer} is designed to be safe to use > - * concurrently from multiple threads, if the source data passed > - * to the constructor, i.e. {@code StringBuffer(source)}, or to the > - * {@code append(source)}, or {@code insert(source)} operations > - * is shared across threads, it must be ensured that the operations have > - * a consistent and unchanging view of the source data for the duration > - * of the operation. > + * {@code StringBuffer} is designed to be safe to use > + * concurrently from multiple threads, but if the source data passed > + * to the constructor or to the {@code append()}, or {@code insert()} > + * operations is shared across threads, the calling code must be ensure > + * that the operations have a consistent and unchanging view of the source > + * data for the duration of the operation. > * This could be satisfied by the caller holding a lock during the > - * operation's call, or because the source data is > - * immutable, or because the source data is not shared across threads. > + * operation's call, or by the source data being > + * immutable, or by the source data not being shared across threads. > *

> * Every string buffer has a capacity. As long as the length of the > * character sequence contained in the string buffer does not exceed > @@ -112,8 +110,8 @@ > * the specified initial capacity. > * > * @param capacity the initial capacity. > - * @exception NegativeArraySizeException if the capacity > - * argument is less than 0. > + * @exception NegativeArraySizeException if the {@code capacity} > + * argument is less than {@code 0}. > */ > public StringBuffer(int capacity) { > super(capacity); > @@ -122,10 +120,10 @@ > /** > * Constructs a string buffer initialized to the contents of the > * specified string. The initial capacity of the string buffer is > - * 16 plus the length of the string argument. > + * {@code 16} plus the length of the string argument. > * > * @param str the initial contents of the buffer. > - * @exception NullPointerException if str is null > + * @exception NullPointerException if {@code str} is {@code null} > */ > public StringBuffer(String str) { > super(str.length() + 16); > @@ -134,16 +132,16 @@ > > /** > * Constructs a string buffer that contains the same characters > - * as the specified CharSequence. The initial capacity of > - * the string buffer is 16 plus the length of the > - * CharSequence argument. > + * as the specified {@code CharSequence}. The initial capacity of > + * the string buffer is {@code 16} plus the length of the > + * {@code CharSequence} argument. > *

> - * If the length of the specified CharSequence is > + * If the length of the specified {@code CharSequence} is > * less than or equal to zero, then an empty buffer of capacity > - * 16 is returned. > + * {@code 16} is returned. > * > * @param seq the sequence to copy. > - * @exception NullPointerException if seq is null > + * @exception NullPointerException if {@code seq} is {@code null} > * @since 1.5 > */ > public StringBuffer(CharSequence seq) { > @@ -264,10 +262,10 @@ > * the new character sequence is equal to the character at index k > * in the old character sequence, if k is less than n; > * otherwise, it is equal to the character at index k-n in the > - * argument sb. > + * argument {@code sb}. > *

> - * This method synchronizes on this (the destination) > - * object but does not synchronize on the source (sb). > + * This method synchronizes on {@code this} (the destination) > + * object but does not synchronize on the source ({@code sb}). > * > * @param sb the StringBuffer to append. > * @return a reference to this object. > @@ -280,10 +278,10 @@ > > > /** > - * Appends the specified CharSequence to this > + * Appends the specified {@code CharSequence} to this > * sequence. > *

> - * The characters of the CharSequence argument are appended, > + * The characters of the {@code CharSequence} argument are appended, > * in order, increasing the length of this sequence by the length of the > * argument. > * > @@ -291,12 +289,12 @@ > * invocation of this.append(s, 0, s.length()); > * > *

This method synchronizes on this (the destination) > - * object but does not synchronize on the source (s). > + * object but does not synchronize on the source ({@code s}). > * > - *

If s is null, then the four characters > - * "null" are appended. > + *

If {@code s} is {@code null}, then the four characters > + * {@code "null"} are appended. > * > - * @param s the CharSequence to append. > + * @param s the {@code CharSequence} to append. > * @return a reference to this object. > * @since 1.5 > */ > > > > From xueming.shen at oracle.com Tue Jun 26 06:00:13 2012 From: xueming.shen at oracle.com (Xueming Shen) Date: Mon, 25 Jun 2012 23:00:13 -0700 Subject: Fwd: Codereview request for 7130915: File.equals does not give expected results when path contains Non-English characters on Mac OS X In-Reply-To: <4FE94F6F.2060002@oracle.com> References: <4FE4A4D6.4070100@oracle.com> <4FE94F6F.2060002@oracle.com> Message-ID: <4FE94FED.6050406@oracle.com> On 6/25/12 10:58 PM, Xueming Shen wrote: > Hi, > > While I still believe that case-insensitive is the right choice for > File/Path on MacOSX, it is > suggested that we might want to be a little conservative in this > patch, with the assumption > that this patch will be backport to 7u release after being baked in > jdk8 for a while (given > Apple's JDK6 is case sensitive for File, it might be too much for a > update releases to go > with two in-compatible changes, case sensitive and hash32). > > So here is the webrev for a strip-down version from the original > patch, in which it only > targets the nfd/nfc issue raised in 7130915 and 7168427. The proposed > changes for > case insensitive compare and hash32 for both java.io.File and > java.nio.file.Path are > removed. > > http://cr.openjdk.java.net/~sherman/7130915_7168427/webrev > > (The webrev for the "full" version has been moved to > http://cr.openjdk.java.net/~sherman/7130915_7168427/webrev_full) > > Thanks, > -Sherman > > > On 6/22/12 10:01 AM, Xueming Shen wrote: >> Hi >> >> Here is the proposed change to support Unicode nfd/nfc and case >> insensitive >> file path on MacOSX file system. >> >> 7130915: File.equals does not give expected results when path >> contains Non-English characters on Mac OS X >> 7168427: FileInputStream cannot open file where the file path >> contains asian characters [macosx] >> >> While these two bug reports are only against java.io, we have the >> same issue in javax.nio.file. >> Here is the webrev >> >> http://cr.openjdk.java.net/~sherman/7130915_7168427/webrev/ >> >> Here is the brief summary of the changes >> >> java.io.File: >> (1) removed nfc->nfd conversion in io_util.h/WITH_PLATFORM_STRING, >> which means >> we are now passing nfc/composite characters directly into macosx >> file system APIs >> without normalize them to nfd. It appears macosx fs APIs do >> take nfc, though it uses >> nfd. >> >> (2) normalize the resulting file name from macosx fs APIs from >> nfd->nfc before passing >> back to java.io.File (File.list() and canonicalize()), so we >> deal with nfc file name >> (as "usual") for java.io classes/APIs. >> >> (3) fs.compare()/hashCode() was updated to be case insensitive >> >> (4) hasCode() was updated to use the new String.hash32(). >> >> java.nio.file: >> >> (5) added a setof MacOSXFile... on top of existing BsdFile... >> classes. An alternative is to >> update those BsdFile... classes directly to address the macosx >> specific issues. But given >> there might be developers over there might work on open jdk BSD port >> and have dependency >> on these classes, it might be desirable to have another separate >> layer of MacOSXFile... >> classes. So now the default FileSystem/Provider is >> MacOSXFileSystemProvider and >> MacOSXFileSystem. >> >> (6) the "main" changes are in MacOSXFileSystem, in which the >> corresponding methods >> were added to handle, case insensitive and nfd<=>nfc normalization, >> including the >> pathmatcher. >> >> (7) compare is now are case-insensitive >> >> (8) hashCode is now murmur3_32(), this is true for all >> Solaris/Unix/Linux and maxosx. >> >> >> Though lots of files have been touched, but the line of changes are >> actually relatively >> small. >> >> The proposed change only deals with the default case-sensitiveness >> seting, which is >> case insensitive. On MaxOSX, you actually can configure the HFS+ file >> system or the >> mounted vol to be case-sensitive. A possible approach is to have some >> extra FileStore >> attributes, such as a isCaseSensitive and to use case sensitive >> compare/equal on >> such fs, but this can be dealt with separately later. >> >> Thanks, >> -Sherman > > From yiming.wang at oracle.com Tue Jun 26 08:49:10 2012 From: yiming.wang at oracle.com (Eric Wang) Date: Tue, 26 Jun 2012 16:49:10 +0800 Subject: Patch review request - Test bug 7123972 test/java/lang/annotation/loaderLeak/Main.java fails intermittently In-Reply-To: <4FE81BFC.8040206@oracle.com> References: <4FE2B997.7090204@oracle.com> <4FE2BFFB.8010705@oracle.com> <4FE2FE2C.1020601@oracle.com> <4FE310BB.6000100@oracle.com> <4FE81BFC.8040206@oracle.com> Message-ID: <4FE97786.10508@oracle.com> Hi Alan, Looks that the core-libs-dev group rejects zip file, so i reattached the patches again, can you please help to review? There's another bug 6948101 which is caused by same reason as this one, I'll send the fix in another mail thread. Thanks, Eric On 2012/6/25 16:06, Eric Wang wrote: > On 2012/6/21 20:16, David Holmes wrote: >> Hi Eric, >> >> On 21/06/2012 8:57 PM, Eric Wang wrote: >>> Hi David, >>> >>> Thanks for your review, I have updated the code by following your >>> suggestion. please see the attachment. >>> I'm not sure whether there's a better way to guarantee object finalized >>> by GC definitely within the given time. The proposed fix may work in >>> most cases but may still throw InterruptException if execution is >>> timeout (2 minutes of JTreg by default). >> >> There is no way to guarantee finalization in a specific timeframe, >> but if a simple test hasn't executed finalizers in 2 minutes then >> that in itself indicates a problem. >> >> Can you post a full webrev for this patch? I don't like seeing it out >> of context and am wondering exactly what we are trying to GC here. >> >> David >> >>> Regards, >>> Eric >>> >>> On 2012/6/21 14:32, David Holmes wrote: >>>> Hi Eric, >>>> >>>> On 21/06/2012 4:05 PM, Eric Wang wrote: >>>>> I come from Java SQE team who are interested in regression test >>>>> bug fix. >>>>> Here is the first simple fix for bug 7123972 >>>>> , Can you >>>>> please help >>>>> to review and comment? Attachment is the patch Thanks! >>>>> >>>>> This bug is caused by wrong assumption that the GC is started >>>>> immediately to recycle un-referenced objects after System.gc() called >>>>> one or two times. >>>>> >>>>> The proposed solution is to make sure the un-referenced object is >>>>> recycled by GC before checking if the reference is null. >>>> >>>> Your patch makes its own assumptions - specifically that finalization >>>> must eventually run. At a minimum you should add >>>> System.runFinalization() calls after the System.gc() inside the loop. >>>> Even that is no guarantee in a general sense, though it should work >>>> for hotspot. >>>> >>>> David >>>> >>>> >>>>> Regards, >>>>> Eric >>> > Hi Alan & David, > > Thank you for your comments, sorry for reply this mail late as i was > just back from the dragon boat holiday. > I have updated the code again based on your suggestions: rename the > flag variable, increase the sleep time and remove it from problem list. > The attachment is the full webrev for this patch, Can you please > review again? Thanks a lot! > > Regards, > Eric -------------- next part -------------- --- old/test/ProblemList.txt 2012-06-25 15:41:20.466150117 +0800 +++ new/test/ProblemList.txt 2012-06-25 15:41:18.998075349 +0800 @@ -122,9 +122,6 @@ # jdk_lang -# 7123972 -java/lang/annotation/loaderLeak/Main.java generic-all - # 6944188 java/lang/management/ThreadMXBean/ThreadStateTest.java generic-all -------------- next part -------------- --- old/test/java/lang/annotation/loaderLeak/Main.java 2012-06-25 15:41:26.005179716 +0800 +++ new/test/java/lang/annotation/loaderLeak/Main.java 2012-06-25 15:41:24.531076496 +0800 @@ -36,6 +36,8 @@ import java.io.*; public class Main { + static volatile boolean finalized = false; + public static void main(String[] args) throws Exception { for (int i=0; i<100; i++) doTest(args.length != 0); @@ -57,8 +59,11 @@ System.gc(); System.gc(); loader = null; - System.gc(); - System.gc(); + while(!finalized) { + System.gc(); + System.runFinalization(); + Thread.sleep(20); + } if (c.get() != null) throw new AssertionError(); } } @@ -67,6 +72,7 @@ private Hashtable classes = new Hashtable(); public SimpleClassLoader() { + Main.finalized = false; } private byte getClassImplFromDataBase(String className)[] { byte result[]; @@ -124,4 +130,8 @@ classes.put(className, result); return result; } + + protected void finalize() { + Main.finalized = true; + } } From yiming.wang at oracle.com Tue Jun 26 09:26:15 2012 From: yiming.wang at oracle.com (Eric Wang) Date: Tue, 26 Jun 2012 17:26:15 +0800 Subject: [PATCH] Review Request - Test bug: 6948101 java/rmi/transport/pinLastArguments/PinLastArguments.java failing intermittently Message-ID: <4FE98037.2050700@oracle.com> Hi All, Please help to review the fix attached for test bug 6948101 which is same root cause as bug 7123972 . The test makes wrong assumption that GC is started immediately to recycle unused objects after System.gc() called. The proposed fix is to make sure objects have been recycled by GC before checking if the weak reference is null. Regards, Eric -------------- next part -------------- --- old/test/ProblemList.txt 2012-06-26 17:02:12.934138771 +0800 +++ new/test/ProblemList.txt 2012-06-26 17:02:11.494051649 +0800 @@ -271,9 +271,6 @@ # 7140992 java/rmi/server/Unreferenced/finiteGCLatency/FiniteGCLatency.java generic-all -# 6948101 -java/rmi/transport/pinLastArguments/PinLastArguments.java generic-all - # 7146541 java/rmi/transport/rapidExportUnexport/RapidExportUnexport.java linux-all -------------- next part -------------- --- old/test/java/rmi/transport/pinLastArguments/PinLastArguments.java 2012-06-26 17:02:17.432074905 +0800 +++ new/test/java/rmi/transport/pinLastArguments/PinLastArguments.java 2012-06-26 17:02:15.984073307 +0800 @@ -43,7 +43,8 @@ import java.rmi.server.UnicastRemoteObject; public class PinLastArguments { - + private static volatile boolean finalized = false; + public interface Ping extends Remote { void ping(Object first, Object second) throws RemoteException; } @@ -53,6 +54,9 @@ public void ping(Object first, Object second) { System.err.println("ping invoked: " + first + ", " + second); } + protected void finalize() { + finalized = true; + } } public static void main(String[] args) throws Exception { @@ -78,7 +82,11 @@ } impl = null; - System.gc(); + while(!finalized) { + System.gc(); + System.runFinalization(); + Thread.sleep(20); + } if (ref.get() != null) { throw new Error("TEST FAILED: impl not garbage collected"); From rob.mckenna at oracle.com Tue Jun 26 12:26:20 2012 From: rob.mckenna at oracle.com (rob.mckenna at oracle.com) Date: Tue, 26 Jun 2012 12:26:20 +0000 Subject: hg: jdk8/tl/jdk: 4244896: (process) Provide System.getPid(), System.killProcess(String pid) Message-ID: <20120626122654.E62D947B19@hg.openjdk.java.net> Changeset: ff0da4ea08a2 Author: robm Date: 2012-06-26 13:27 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ff0da4ea08a2 4244896: (process) Provide System.getPid(), System.killProcess(String pid) Reviewed-by: alanb ! src/share/classes/java/lang/Process.java ! src/solaris/classes/java/lang/UNIXProcess.java.bsd ! src/solaris/classes/java/lang/UNIXProcess.java.linux ! src/solaris/classes/java/lang/UNIXProcess.java.solaris ! src/solaris/native/java/lang/UNIXProcess_md.c ! src/windows/classes/java/lang/ProcessImpl.java ! src/windows/native/java/lang/ProcessImpl_md.c ! test/java/lang/ProcessBuilder/Basic.java + test/java/lang/ProcessBuilder/DestroyTest.java From rob.mckenna at oracle.com Tue Jun 26 12:30:02 2012 From: rob.mckenna at oracle.com (Rob McKenna) Date: Tue, 26 Jun 2012 13:30:02 +0100 Subject: review request: 4244896: (process) Provide System.getPid(), System.killProcess(String pid) In-Reply-To: <4FE834EF.9070909@oracle.com> References: <4F861847.5080308@oracle.com> <4F869AD6.7010903@oracle.com> <4F8D849E.8090607@oracle.com> <4F8F56E0.6020009@oracle.com> <4F8FF15E.9080408@oracle.com> <4FAC0F5F.3090508@oracle.com> <4FC788CB.9070900@oracle.com> <4FC80FB0.3050701@oracle.com> <4FE70ECD.7000705@oracle.com> <4FE834EF.9070909@oracle.com> Message-ID: <4FE9AB4A.8060609@oracle.com> Thanks Thomas, As per Alan's mail, we're going to deal with this as a separate issue after we've discussed it. -Rob On 25/06/12 10:52, Alan Bateman wrote: > On 25/06/2012 09:56, Thomas St?fe wrote: >> Hi, Rob, >> >> src/solaris/native/java/lang/UNIXProcess_md.c: >> >> You never check the return code of kill(2). kill() may fail if you >> have no permission to kill the process (EPERM), or if the process id >> is invalid, maybe it has already been reaped. In both cases an >> exception would be nice, or if you decide this cannot happen in the >> context of Process.java, at least an assert(). >> > One thing to add to this is that the destroy method has been there > since jdk1.0 and is not defined or specified to throw any exceptions > so we can't really change that now. From the history it doesn't look > like the return from kill(2) has ever been checked. As it can only ne > used to send a signal to processes created by the ProcessBuilder or > Runtime.exec API (not arbitrary process) then it is unlikely to fail. > Whether the new destroy method should specify an exception may require > consideration and maybe a separate bug should be created to consider > that. > > -Alan From martin.desruisseaux at geomatys.fr Tue Jun 26 14:13:22 2012 From: martin.desruisseaux at geomatys.fr (Martin Desruisseaux) Date: Tue, 26 Jun 2012 16:13:22 +0200 Subject: String.subSequence and CR#6924259: Remove offset and count fields from java.lang.String In-Reply-To: References: <20120531032252.A69774763C@hg.openjdk.java.net> <1359801.KFxJhQHyve@cube> Message-ID: <4FE9C382.7040402@geomatys.fr> If String.substring(int, int) now performs a copy of the underlying char[] array and if there is no String.subSequence(int, int) providing the old functionality, maybe the following implications should be investigated? StringBuilder.append(...) -------------------- Since, in order to avoid a useless array copy, the users may be advised to replace the following pattern: StringBuilder.append(string.substring(lower, upper)); by: StringBuilder.append(string, lower, upper); would it be worth to add a special-case in the AbstractStringBuilder.append(CharSequence, int, int) implementation for the String case in order to reach the efficiency of the AbstractStringBuilder.append(String) method? The later copies the data with a single call to System.arraycopy, as opposed to the former which invoke CharSequence.charAt(int) in a loop. Integer.parseInt(...) ---------------- There was a thread one years ago about allowing Integer.parseInt(String) to accept a CharSequence. http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-April/thread.html#9801 One invoked reason was performance, since the cost of calling CharSequence.toString() has been measured with the NetBeans profiler as significant (assuming that the CharSequence is not already a String) when reading large ASCII files. Now if the new String.substring(...) implementation copies the internal array, we may expect a performance cost similar to StringBuilder.toString(). Would it be worth to revisit the Integer.parseInt(String) case - and similar methods in other wrapper classes - for allowing CharSequence input? Martin Le 23/06/12 00:15, Mike Duigou a ?crit : > I've made a test implementation of subSequence() utilizing an inner class with offset and count fields to try to understand all the parts that would be impacted. My observations thus far: > > - The specification of the subSequence() method is currently too specific. It says that the result is a subString(). This would no longer be true. Hopefully nobody assumed that this meant they could cast the result to String. I know, why would you if you can just call subString() instead? I've learned to assume that somebody somewhere does always does the most unexpected thing. > - The CharSequences returned by subSequence would follow only the general CharSequence rules for equals()/hashCode(). Any current usages of the result of subSequence for equals() or hashing, even though it's not advised, would break. We could add equals() and hashCode() implementations to the CharSequence returned but they would probably be expensive. > - In general I wonder if parsers will be satisfied with a CharSequence that only implements identity equals(). > - I also worry about applications that currently do use subSequence currently and which will fail when the result is not a String instance as String.equals() will return false for all CharSequences that aren't Strings. ie. CharSequence token =ine.subSequence(line, start, end); if (keyword.equals(token)) ... This would now fail. > > At this point I wonder if this is a feature worth pursuing. > > Mike From Alan.Bateman at oracle.com Tue Jun 26 15:02:11 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 26 Jun 2012 16:02:11 +0100 Subject: Fwd: Codereview request for 7130915: File.equals does not give expected results when path contains Non-English characters on Mac OS X In-Reply-To: <4FE94FED.6050406@oracle.com> References: <4FE4A4D6.4070100@oracle.com> <4FE94F6F.2060002@oracle.com> <4FE94FED.6050406@oracle.com> Message-ID: <4FE9CEF3.8080905@oracle.com> On 26/06/2012 07:00, Xueming Shen wrote: > On 6/25/12 10:58 PM, Xueming Shen wrote: >> Hi, >> >> While I still believe that case-insensitive is the right choice for >> File/Path on MacOSX, it is >> suggested that we might want to be a little conservative in this >> patch, with the assumption >> that this patch will be backport to 7u release after being baked in >> jdk8 for a while (given >> Apple's JDK6 is case sensitive for File, it might be too much for a >> update releases to go >> with two in-compatible changes, case sensitive and hash32). >> >> So here is the webrev for a strip-down version from the original >> patch, in which it only >> targets the nfd/nfc issue raised in 7130915 and 7168427. The proposed >> changes for >> case insensitive compare and hash32 for both java.io.File and >> java.nio.file.Path are >> removed. >> >> http://cr.openjdk.java.net/~sherman/7130915_7168427/webrev >> >> (The webrev for the "full" version has been moved to >> http://cr.openjdk.java.net/~sherman/7130915_7168427/webrev_full) >> >> Thanks, >> -Sherman I had to dig up the File Systems, Unicode, and Normalization presentation [1] before reviewing this, it's been a while. I think the changes for java.io for fine, I just worry that there may be a few odd cases where it will be different to Apple JDK6. I looked through the macosx-port/macosx-port/jdk forest and there is one patch from Apple that does the NFC->NFD conversation. I don't get that patch because you say that the syscalls handle NFC okay. In your changes then you normalize when decoding the file names to Strings, which seems right but that seems to be completely missing from the changes that Apple brought over. The only minor comment is that we probably need to check the return from core foundation functions such as CFStringCreateMutable (this goes for the other native code too). Adding the FileSystemProvider for MacOSX is great to see. The approach is fine for but is somewhat inefficient when ->NFD or ->NFC is needed. One inefficiency that can be fixed is in sun.nio.fs.MacOSXFileSystem. normalizeJavaPath then you can eliminate the second call to toCharArray. I think the new methods on sun.no.fs.UnixFileSystem should be given comments so that it's clear whether they should be overridden (the Unix* provider tends to be starting point for most ports). A minor comment is that MacOSXNativeDispatcher has a bunch of blank lines at the end, also I think "static final" is more normal than "final static". At some point I think we should re-write MacOSXNativeDispatcher.normalizepath so that it deosn't require the critical section or malloc as in this area we try to keep the native methods to a bare minimum. Do the tests assume they are run on HFS? Just wondering if you you need to look at the FileStore name/type to check. Some of variable namesa bit non-standard, very C like. Minor nit is that the copyright in the header isn't right in the tests. Also the tests list 2 CRs whereas I assume this is one CR (with the other closed as a dup). On case sensitive vs. insensitive then I think it should be insensitive as per the first round but that would be a significant change given that Apple's JDK does not appear to have changed File.equals. Maybe we should think about this again once these changes are in 8. -Alan [1] http://developers.sun.com/global/products_platforms/solaris/reference/presentations/IUC29-FileSystems.pdf From Alan.Bateman at oracle.com Tue Jun 26 16:35:27 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 26 Jun 2012 17:35:27 +0100 Subject: RFR: 7161229 - PriorityBlockingQueue keeps hard reference to last removed element In-Reply-To: <4FE7E865.7020106@oracle.com> References: <4FE7E865.7020106@oracle.com> Message-ID: <4FE9E4CF.4090403@oracle.com> On 25/06/2012 05:26, David Holmes wrote: > webrev: > > http://cr.openjdk.java.net/~dholmes/7161229/webrev/ > > When removing the last element from the PBQ the "sift down" logic > would store it back in as array[0]. The simple fix is for the > sift-down to be a no-op if the queue size is zero. > > The fix has been contributed by Doug Lea. We are taking this > opportunity to synchronize PBQ with Doug's latest version at: > > http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/main/java/util/concurrent/PriorityBlockingQueue.java?view=log > > > So in addition to the above functional fix there are a number of > miscellaneous code and comment cleanups. The only non-trivial, but > still very simple, change is to the drainTo method to make it more > robust if the add() on the destination collection throws an exception. > > I am of course a Reviewer for this. > > I have provided the update to the LastElement test (as this is > certainly related to the last element) but there are some reservations > about examining the PBS internals this way. Unfortunately there is no > good way to test for these kinds of retention issues. You either need > a whitebox test like this, or need to rely on non-guaranteed GC and > finalization behaviour. I looked through the changes to siftDown* and the other clean-ups and they look fine to me. As this test doesn't set a security manager then I assume it doesn't really need L92-94. It is a bit icky to use reflection and pull out a private field but I don't think it's is easily tested otherwise. -Alan, From mike.duigou at oracle.com Tue Jun 26 18:10:41 2012 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 26 Jun 2012 11:10:41 -0700 Subject: String.subSequence and CR#6924259: Remove offset and count fields from java.lang.String In-Reply-To: <4FE9C382.7040402@geomatys.fr> References: <20120531032252.A69774763C@hg.openjdk.java.net> <1359801.KFxJhQHyve@cube> <4FE9C382.7040402@geomatys.fr> Message-ID: On Jun 26 2012, at 07:13 , Martin Desruisseaux wrote: > If String.substring(int, int) now performs a copy of the underlying char[] array and if there is no String.subSequence(int, int) providing the old functionality, maybe the following implications should be investigated? > > > StringBuilder.append(...) > -------------------- > Since, in order to avoid a useless array copy, the users may be advised to replace the following pattern: > > StringBuilder.append(string.substring(lower, upper)); > by: > StringBuilder.append(string, lower, upper); This would seem to be a good refactoring regardless of the substring implementation as it avoids creation of a temporary object. > > would it be worth to add a special-case in the AbstractStringBuilder.append(CharSequence, int, int) implementation for the String case in order to reach the efficiency of the AbstractStringBuilder.append(String) method? The later copies the data with a single call to System.arraycopy, as opposed to the former which invoke CharSequence.charAt(int) in a loop. I think a microbenchmark to compare StringBuilder.append(string.substring(lower, upper)) with AbstractStringBuilder.append.append(CharSequence, int, int) would help. I wouldn't be surprised if the later is faster when a substring has to be created but slower when the string is an existing string. > > Integer.parseInt(...) > ---------------- > There was a thread one years ago about allowing Integer.parseInt(String) to accept a CharSequence. > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-April/thread.html#9801 > > One invoked reason was performance, since the cost of calling CharSequence.toString() has been measured with the NetBeans profiler as significant (assuming that the CharSequence is not already a String) when reading large ASCII files. Now if the new String.substring(...) implementation copies the internal array, we may expect a performance cost similar to StringBuilder.toString(). Would it be worth to revisit the Integer.parseInt(String) case - and similar methods in other wrapper classes - for allowing CharSequence input? Probably. > Martin > > > > Le 23/06/12 00:15, Mike Duigou a ?crit : >> I've made a test implementation of subSequence() utilizing an inner class with offset and count fields to try to understand all the parts that would be impacted. My observations thus far: >> >> - The specification of the subSequence() method is currently too specific. It says that the result is a subString(). This would no longer be true. Hopefully nobody assumed that this meant they could cast the result to String. I know, why would you if you can just call subString() instead? I've learned to assume that somebody somewhere does always does the most unexpected thing. >> - The CharSequences returned by subSequence would follow only the general CharSequence rules for equals()/hashCode(). Any current usages of the result of subSequence for equals() or hashing, even though it's not advised, would break. We could add equals() and hashCode() implementations to the CharSequence returned but they would probably be expensive. >> - In general I wonder if parsers will be satisfied with a CharSequence that only implements identity equals(). >> - I also worry about applications that currently do use subSequence currently and which will fail when the result is not a String instance as String.equals() will return false for all CharSequences that aren't Strings. ie. CharSequence token =ine.subSequence(line, start, end); if (keyword.equals(token)) ... This would now fail. >> >> At this point I wonder if this is a feature worth pursuing. >> >> Mike > From kurchi.subhra.hazra at oracle.com Tue Jun 26 18:29:37 2012 From: kurchi.subhra.hazra at oracle.com (Kurchi Hazra) Date: Tue, 26 Jun 2012 11:29:37 -0700 Subject: Bug 7176907 - Patches for javac warnings cleanup (text and util) from Adopt OpenJDK In-Reply-To: References: <4FE1D95C.3030108@univ-mlv.fr> <4FE1F559.5070802@oracle.com> Message-ID: <4FE9FF91.3010400@oracle.com> Thanks for updating this. This looks good to me. I guess Stuart will be sponsoring the patch. There are a couple of other switch statements in src/share/classes/java/util/regex/Pattern.java. which are not throwing fallthrough warnings (in Netbeans at least), although there is fallthrough happening from one case to another. From what I notice, only if there is a break statement missing before the "default" case, does Netbeans throw some warning. Is the fallthrough warning technically supposed to be thrown only when the logic falls through to the default case then? - Kurchi On 6/25/2012 5:54 AM, Martijn Verburg wrote: > Hi all, > > Apologies for the delay. So it was simply a case of human error in > missing that last fallthrough (we wanted to double check that our > warnings script wasn't failing, hence the delay in getting back to > you). I've respun the patch with the extra SuppressWarning. > > Hopefully the patch is complete now. > > Cheers, > Martijn > > On 20 June 2012 17:18, Martijn Verburg wrote: >> We'll look into it, hopefully have an answer for you shortly - M >> >> On 20 June 2012 17:07, Kurchi Subhra Hazra >> wrote: >>> Hi, >>> >>> I was just going through the patches, there are some more fallthrough >>> cases in >>> src/share/classes/java/util/regex/Pattern.java.(for example in line 2247). >>> Are these not generating warnings? >>> >>> - Kurchi >>> >>> >>> On 6/20/12 7:30 AM, Martijn Verburg wrote: >>> >>> Hi all, >>> >>> Apologies, I didn't check that attachments were stripped. The patches >>> can be found at: >>> >>> >>> https://raw.github.com/AdoptOpenJDK/PatchReview/master/submitted/core_java_text.patch >>> >>> https://raw.github.com/AdoptOpenJDK/PatchReview/master/submitted/core_java_util.patch >>> >>> Cheers, >>> Martijn >>> >>> Hi Martijn, >>> the two patches looks good. >>> >>> A minor nit, why is there a space between the '(' and the readUByte() in >>> readUShort. >>> >>> Thanks for the quick review! No reason on the whitespace, I've fixed that >>> now. >>> >>> Quick question. Is there a checkstyle or jcheck that we should be >>> applying to any corelib patches going forwards? >>> >>> Cheers, >>> Martijn >>> >>> -- -Kurchi From martin.desruisseaux at geomatys.fr Tue Jun 26 19:49:44 2012 From: martin.desruisseaux at geomatys.fr (Martin Desruisseaux) Date: Tue, 26 Jun 2012 21:49:44 +0200 Subject: String.subSequence and CR#6924259: Remove offset and count fields from java.lang.String In-Reply-To: References: <20120531032252.A69774763C@hg.openjdk.java.net> <1359801.KFxJhQHyve@cube> <4FE9C382.7040402@geomatys.fr> Message-ID: <4FEA1258.3000809@geomatys.fr> Le 26/06/12 20:10, Mike Duigou a ?crit : >> StringBuilder.append(string.substring(lower, upper)); >> by: >> StringBuilder.append(string, lower, upper); > This would seem to be a good refactoring regardless of the substring implementation as it avoids creation of a temporary object. The rational was that the performance advantage of using System.arraycopy(...) instead than a loop over CharSequence.charAt(int) may compensate the cost of creating a temporary object. I would not be surprised if the former was faster than the later for large substrings despite the temporary object creation. However it may not be true anymore now that substring(...) performs a copy. Of course this would need to be verified with benchmark... Martin From david.holmes at oracle.com Tue Jun 26 21:51:55 2012 From: david.holmes at oracle.com (David Holmes) Date: Wed, 27 Jun 2012 07:51:55 +1000 Subject: Patch review request - Test bug 7123972 test/java/lang/annotation/loaderLeak/Main.java fails intermittently In-Reply-To: <4FE81BFC.8040206@oracle.com> References: <4FE2B997.7090204@oracle.com> <4FE2BFFB.8010705@oracle.com> <4FE2FE2C.1020601@oracle.com> <4FE310BB.6000100@oracle.com> <4FE81BFC.8040206@oracle.com> Message-ID: <4FEA2EFB.4050109@oracle.com> Thanks Eric. So to summarize: - we create a custom classloader, load a class through it and store a reference to that Class in a WeakReference - we then drop the reference to the loader At this point the only reference to the loader is from the Class loaded, which in turn is only weakly reachable. I must confess that I'm unclear why this test should be failing in its original form. The first gc() should remove the strong reference to the loader. That leaves a weak cycle: WeakRef -> Class -> Loader -> Class. The second gc() should detect the cycle and clear the WeakRef. I guess the problem is that depending on which gc is in use the actual gc() calls may not in fact induce every possible GC action. The fix seems reasonable in that regard - keep gc'ing and finalizing till we see the loader is gone, and so the WeakReference should be cleared. The original bug would cause a ref to the Class to remain (from the annotation) and hence the WeakRef would not be cleared. However, in that case the loader would also be strongly referenced and so never become finalizable. So if this test was now run against a JDK with the original bug, the test would hang. So I think we need to add a timeout in there as well. David On 25/06/2012 6:06 PM, Eric Wang wrote: > On 2012/6/21 20:16, David Holmes wrote: >> Hi Eric, >> >> On 21/06/2012 8:57 PM, Eric Wang wrote: >>> Hi David, >>> >>> Thanks for your review, I have updated the code by following your >>> suggestion. please see the attachment. >>> I'm not sure whether there's a better way to guarantee object finalized >>> by GC definitely within the given time. The proposed fix may work in >>> most cases but may still throw InterruptException if execution is >>> timeout (2 minutes of JTreg by default). >> >> There is no way to guarantee finalization in a specific timeframe, but >> if a simple test hasn't executed finalizers in 2 minutes then that in >> itself indicates a problem. >> >> Can you post a full webrev for this patch? I don't like seeing it out >> of context and am wondering exactly what we are trying to GC here. >> >> David >> >>> Regards, >>> Eric >>> >>> On 2012/6/21 14:32, David Holmes wrote: >>>> Hi Eric, >>>> >>>> On 21/06/2012 4:05 PM, Eric Wang wrote: >>>>> I come from Java SQE team who are interested in regression test bug >>>>> fix. >>>>> Here is the first simple fix for bug 7123972 >>>>> , Can you please >>>>> help >>>>> to review and comment? Attachment is the patch Thanks! >>>>> >>>>> This bug is caused by wrong assumption that the GC is started >>>>> immediately to recycle un-referenced objects after System.gc() called >>>>> one or two times. >>>>> >>>>> The proposed solution is to make sure the un-referenced object is >>>>> recycled by GC before checking if the reference is null. >>>> >>>> Your patch makes its own assumptions - specifically that finalization >>>> must eventually run. At a minimum you should add >>>> System.runFinalization() calls after the System.gc() inside the loop. >>>> Even that is no guarantee in a general sense, though it should work >>>> for hotspot. >>>> >>>> David >>>> >>>> >>>>> Regards, >>>>> Eric >>> > Hi Alan & David, > > Thank you for your comments, sorry for reply this mail late as i was > just back from the dragon boat holiday. > I have updated the code again based on your suggestions: rename the flag > variable, increase the sleep time and remove it from problem list. > The attachment is the full webrev for this patch, Can you please review > again? Thanks a lot! > > Regards, > Eric From kurchi.subhra.hazra at oracle.com Tue Jun 26 21:57:34 2012 From: kurchi.subhra.hazra at oracle.com (Kurchi Hazra) Date: Tue, 26 Jun 2012 14:57:34 -0700 Subject: Code Review Request: 7160252: (prefs) NodeAddedEvent was not delivered when new node add when new Node In-Reply-To: <4FE35F86.3050109@oracle.com> References: <4FE35F86.3050109@oracle.com> Message-ID: <4FEA304E.7080503@oracle.com> Hi, On Mac OS X, for Preferences, a new child added event was not being delivered to a NodeChangeListener since the existing code depended on the return value of addNode() in the native code, which returns true if a new node is added. However, since addNode() was being called erroneously after a child node is already added to an existing node, addNode() would always return false, resulting in thw new node event never being delivered. This fix propagates the required information of whether a node is added from the method adding the child node itself. In addition, I cleaned up the constructors in MacOSXPreferences.java and added a test (AddNodeChangeListener.java) to cover this case. Finally, there were two prefs tests in ProblemList.txt which are now passing, I have removed these from the ProblemList too. Bug: http://bugs.sun.com/view_bug.do?bug_id=7160252 Webrev: http://cr.openjdk.java.net/~khazra/7160252/webrev.00/ Thanks, Kurchi From david.holmes at oracle.com Tue Jun 26 21:56:29 2012 From: david.holmes at oracle.com (David Holmes) Date: Wed, 27 Jun 2012 07:56:29 +1000 Subject: [PATCH] Review Request - Test bug: 6948101 java/rmi/transport/pinLastArguments/PinLastArguments.java failing intermittently In-Reply-To: <4FE98037.2050700@oracle.com> References: <4FE98037.2050700@oracle.com> Message-ID: <4FEA300D.6090705@oracle.com> Hi Eric, On 26/06/2012 7:26 PM, Eric Wang wrote: > Please help to review the fix attached for test bug 6948101 > which is same root > cause as bug 7123972 . > The test makes wrong assumption that GC is started immediately to > recycle unused objects after System.gc() called. > The proposed fix is to make sure objects have been recycled by GC before > checking if the weak reference is null. Again I really need to see a webrev to see the fix in context. Do you have Author role and an OpenJDK user name so you can post webrevs on cr.openjdk.java.net? I suspect this may have the same issues as the other fix and require a timeout for when the original problem is still present. Thanks, David > Regards, > Eric From huizhe.wang at oracle.com Tue Jun 26 21:59:29 2012 From: huizhe.wang at oracle.com (Joe Wang) Date: Tue, 26 Jun 2012 14:59:29 -0700 Subject: RFR [7u6]: 7166896: DocumentBuilder.parse(String uri) is not IPv6 enabled. It throws MalformedURLException In-Reply-To: <22CB14C2-C460-430C-B38D-96E9F92B22C3@oracle.com> References: <4FE4FB34.9040808@oracle.com> <22CB14C2-C460-430C-B38D-96E9F92B22C3@oracle.com> Message-ID: <4FEA30C1.7080204@oracle.com> Hi Paul, That method was contributed by engineers from Korea and intended to handle paths that contained international characters, so that was how it was named. It was an extra processing added. Outside of that scenario, we'd want to skip the process and get back to letting URL handle the input, whether the system id contains space or '[', and etc. -Joe On 6/25/2012 9:13 AM, Paul Sandoz wrote: > Hi Joe, > > What happens if there is a space character or other characters in the string that should be encoded ? > > http://greenbytes.de/tech/webdav/rfc2396.html#rfc.section.2.4.3 > > I suspect "escapeNonUSAscii" is slightly misleading, it should be really called something like "escapeCharactersInUriString". > > Note that '[' and ']' are not valid URI characters outside of an IPv6 encoded address. > > Paul. > > On Jun 23, 2012, at 1:09 AM, Joe Wang wrote: > >> Hi, >> >> This is a patch to fix the IPv6 issue. >> >> In a previous patch to fix an issue with system id containing international characters, an extra character escaping was added so that any URL passed to the parser goes through method escapeNonUSAscii before it's used to construct an URL. >> >> However, literal IPv6 addresses are enclosed in square brackets. The escapeNonUSAscii encoded address will become unrecognizable to URL that would throw a java.net.MalformedURLException. An address such as http://[fe80::la03:73ff:fead:f7b0]/note.xml is encoded as http://%5Bfe80::la03:73ff:fead:f7b0%5D/note.xml", resulting in java.net.MalformedURLException: For input string: ":la03:73ff:fead:f7b0%5D". >> >> This patch skips the encoding process and returns it as is if there're no non-ascii characters. >> >> webrev: http://cr.openjdk.java.net/~joehw/7u6/7166896/webrev/ >> >> Please review. >> >> Thanks, >> Joe From huizhe.wang at oracle.com Tue Jun 26 22:26:33 2012 From: huizhe.wang at oracle.com (huizhe.wang at oracle.com) Date: Tue, 26 Jun 2012 22:26:33 +0000 Subject: hg: jdk8/tl/jaxp: 7166896: DocumentBuilder.parse(String uri) is not IPv6 enabled. It throws MalformedURLException Message-ID: <20120626222640.28A1747B2F@hg.openjdk.java.net> Changeset: 7920ead2cc75 Author: joehw Date: 2012-06-26 15:28 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/7920ead2cc75 7166896: DocumentBuilder.parse(String uri) is not IPv6 enabled. It throws MalformedURLException Summary: skip the added international character handling for general paths Reviewed-by: lancea ! src/com/sun/org/apache/xerces/internal/impl/XMLEntityManager.java From stuart.marks at oracle.com Wed Jun 27 01:14:30 2012 From: stuart.marks at oracle.com (Stuart Marks) Date: Tue, 26 Jun 2012 18:14:30 -0700 Subject: [PATCH] Review Request - Test bug: 6948101 java/rmi/transport/pinLastArguments/PinLastArguments.java failing intermittently In-Reply-To: <4FEA300D.6090705@oracle.com> References: <4FE98037.2050700@oracle.com> <4FEA300D.6090705@oracle.com> Message-ID: <4FEA5E76.1030400@oracle.com> Hi Eric, Alan Bateman asked me to help you out with this since he's going to be unavailable for a couple weeks. I didn't see you on the OpenJDK census [1] so you might not have an Author role and thus the ability to post webrevs. If indeed you don't, I can post a webrev for you. I can also post a webrev for your other review (7123972) if it's still necessary. Finally, I can push the fixes for you when the reviews are complete. s'marks [1] http://openjdk.java.net/census On 6/26/12 2:56 PM, David Holmes wrote: > Hi Eric, > > On 26/06/2012 7:26 PM, Eric Wang wrote: >> Please help to review the fix attached for test bug 6948101 >> which is same root >> cause as bug 7123972 . >> The test makes wrong assumption that GC is started immediately to >> recycle unused objects after System.gc() called. >> The proposed fix is to make sure objects have been recycled by GC before >> checking if the weak reference is null. > > Again I really need to see a webrev to see the fix in context. Do you have > Author role and an OpenJDK user name so you can post webrevs on > cr.openjdk.java.net? > > I suspect this may have the same issues as the other fix and require a timeout > for when the original problem is still present. > > Thanks, > David > >> Regards, >> Eric From xueming.shen at oracle.com Wed Jun 27 03:33:50 2012 From: xueming.shen at oracle.com (Xueming Shen) Date: Tue, 26 Jun 2012 20:33:50 -0700 Subject: Fwd: Codereview request for 7130915: File.equals does not give expected results when path contains Non-English characters on Mac OS X In-Reply-To: <4FE9CEF3.8080905@oracle.com> References: <4FE4A4D6.4070100@oracle.com> <4FE94F6F.2060002@oracle.com> <4FE94FED.6050406@oracle.com> <4FE9CEF3.8080905@oracle.com> Message-ID: <4FEA7F1E.4070500@oracle.com> Alan, Webrev has been updated accordingly at http://cr.openjdk.java.net/~sherman/7130915/webrev with changes (1) added a CFStringCreateMutable(...) != null check in both io and nio native, though it is unlikely to fail here because we are passing a NULL and 0 length, like new StringBuilder() invocation, if it fails the system probably goes very wrong. Both FStringAppendCharacters and CFStringNormalize are void return type. (2) The first line of path.toCharArray in normalizeJavaPath is a typo, it is supposed to be deleted. The implementation only goes toCharArray when it needs to go native. Currently it uses >0x80 as the fast path criteria, it is possible to expose some sun.text.normalizer's internal methods to have a "quick nfc" check, but I'm not sure how much the performance gain would be, but might worth some investigation later. (3) Comments have been added for those override-able methods in UnixFileSystem. (4) blank lines have been removed from dispatcher.c (5) I don't think we need to do the HFS check, given we are only doing nfc/nfd stuff now, as long as it is a MacOSX, I believe its nfc/nfd layer will be there. Copyright has been re-copy/ pasted and we now only use only bugid. -Sherman On 6/26/12 8:02 AM, Alan Bateman wrote: > On 26/06/2012 07:00, Xueming Shen wrote: >> On 6/25/12 10:58 PM, Xueming Shen wrote: >>> Hi, >>> >>> While I still believe that case-insensitive is the right choice for >>> File/Path on MacOSX, it is >>> suggested that we might want to be a little conservative in this >>> patch, with the assumption >>> that this patch will be backport to 7u release after being baked in >>> jdk8 for a while (given >>> Apple's JDK6 is case sensitive for File, it might be too much for a >>> update releases to go >>> with two in-compatible changes, case sensitive and hash32). >>> >>> So here is the webrev for a strip-down version from the original >>> patch, in which it only >>> targets the nfd/nfc issue raised in 7130915 and 7168427. The >>> proposed changes for >>> case insensitive compare and hash32 for both java.io.File and >>> java.nio.file.Path are >>> removed. >>> >>> http://cr.openjdk.java.net/~sherman/7130915_7168427/webrev >>> >>> (The webrev for the "full" version has been moved to >>> http://cr.openjdk.java.net/~sherman/7130915_7168427/webrev_full) >>> >>> Thanks, >>> -Sherman > I had to dig up the File Systems, Unicode, and Normalization > presentation [1] before reviewing this, it's been a while. > > I think the changes for java.io for fine, I just worry that there may > be a few odd cases where it will be different to Apple JDK6. I looked > through the macosx-port/macosx-port/jdk forest and there is one patch > from Apple that does the NFC->NFD conversation. I don't get that patch > because you say that the syscalls handle NFC okay. In your changes > then you normalize when decoding the file names to Strings, which > seems right but that seems to be completely missing from the changes > that Apple brought over. The only minor comment is that we probably > need to check the return from core foundation functions such as > CFStringCreateMutable (this goes for the other native code too). > > Adding the FileSystemProvider for MacOSX is great to see. The approach > is fine for but is somewhat inefficient when ->NFD or ->NFC is needed. > One inefficiency that can be fixed is in sun.nio.fs.MacOSXFileSystem. > normalizeJavaPath then you can eliminate the second call to > toCharArray. I think the new methods on sun.no.fs.UnixFileSystem > should be given comments so that it's clear whether they should be > overridden (the Unix* provider tends to be starting point for most > ports). A minor comment is that MacOSXNativeDispatcher has a bunch of > blank lines at the end, also I think "static final" is more normal > than "final static". At some point I think we should re-write > MacOSXNativeDispatcher.normalizepath so that it deosn't require the > critical section or malloc as in this area we try to keep the native > methods to a bare minimum. > > Do the tests assume they are run on HFS? Just wondering if you you > need to look at the FileStore name/type to check. Some of variable > namesa bit non-standard, very C like. Minor nit is that the copyright > in the header isn't right in the tests. Also the tests list 2 CRs > whereas I assume this is one CR (with the other closed as a dup). > > On case sensitive vs. insensitive then I think it should be > insensitive as per the first round but that would be a significant > change given that Apple's JDK does not appear to have changed > File.equals. Maybe we should think about this again once these changes > are in 8. > > -Alan > > [1] > http://developers.sun.com/global/products_platforms/solaris/reference/presentations/IUC29-FileSystems.pdf From david.holmes at oracle.com Wed Jun 27 05:26:11 2012 From: david.holmes at oracle.com (David Holmes) Date: Wed, 27 Jun 2012 15:26:11 +1000 Subject: RFR: 7161229 - PriorityBlockingQueue keeps hard reference to last removed element In-Reply-To: <4FE9E4CF.4090403@oracle.com> References: <4FE7E865.7020106@oracle.com> <4FE9E4CF.4090403@oracle.com> Message-ID: <4FEA9973.50208@oracle.com> On 27/06/2012 2:35 AM, Alan Bateman wrote: > On 25/06/2012 05:26, David Holmes wrote: >> webrev: >> >> http://cr.openjdk.java.net/~dholmes/7161229/webrev/ >> >> When removing the last element from the PBQ the "sift down" logic >> would store it back in as array[0]. The simple fix is for the >> sift-down to be a no-op if the queue size is zero. >> >> The fix has been contributed by Doug Lea. We are taking this >> opportunity to synchronize PBQ with Doug's latest version at: >> >> http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/main/java/util/concurrent/PriorityBlockingQueue.java?view=log >> >> >> So in addition to the above functional fix there are a number of >> miscellaneous code and comment cleanups. The only non-trivial, but >> still very simple, change is to the drainTo method to make it more >> robust if the add() on the destination collection throws an exception. >> >> I am of course a Reviewer for this. >> >> I have provided the update to the LastElement test (as this is >> certainly related to the last element) but there are some reservations >> about examining the PBS internals this way. Unfortunately there is no >> good way to test for these kinds of retention issues. You either need >> a whitebox test like this, or need to rely on non-guaranteed GC and >> finalization behaviour. > I looked through the changes to siftDown* and the other clean-ups and > they look fine to me. Thanks Alan. > As this test doesn't set a security manager then I assume it doesn't > really need L92-94. The IllegalAccessException has to be caught as it is a checked exception from getDeclaredField(). I removed the AccessControlException though. > It is a bit icky to use reflection and pull out a > private field but I don't think it's is easily tested otherwise. The only other way is resorting to gc/finalization hacks - and that is even more icky in my opinion. If the field vanishes one day the test will fail and we'll know to update it. I've updated the webrev for reference: http://cr.openjdk.java.net/~dholmes/7161229/webrev.01/ but will go ahead with the push. Thanks, David > -Alan, From david.holmes at oracle.com Wed Jun 27 05:38:04 2012 From: david.holmes at oracle.com (david.holmes at oracle.com) Date: Wed, 27 Jun 2012 05:38:04 +0000 Subject: hg: jdk8/tl/jdk: 7161229: PriorityBlockingQueue keeps hard reference to last removed element Message-ID: <20120627053814.287DF47B46@hg.openjdk.java.net> Changeset: 94b525ce3653 Author: dholmes Date: 2012-06-27 01:36 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/94b525ce3653 7161229: PriorityBlockingQueue keeps hard reference to last removed element Reviewed-by: dholmes, forax, alanb Contributed-by: Doug Lea

! src/share/classes/java/util/concurrent/PriorityBlockingQueue.java ! test/java/util/concurrent/BlockingQueue/LastElement.java From david.holmes at oracle.com Wed Jun 27 06:19:52 2012 From: david.holmes at oracle.com (David Holmes) Date: Wed, 27 Jun 2012 16:19:52 +1000 Subject: Patch review request - Test bug 7123972 test/java/lang/annotation/loaderLeak/Main.java fails intermittently In-Reply-To: <4FEA2EFB.4050109@oracle.com> References: <4FE2B997.7090204@oracle.com> <4FE2BFFB.8010705@oracle.com> <4FE2FE2C.1020601@oracle.com> <4FE310BB.6000100@oracle.com> <4FE81BFC.8040206@oracle.com> <4FEA2EFB.4050109@oracle.com> Message-ID: <4FEAA608.1000502@oracle.com> Eric, Ignore my comment about adding the timeouts. As Alan reminded me if the test would hang then jtreg will time it out after two minutes anyway. So this is good to go as far as I am concerned. Thanks, David On 27/06/2012 7:51 AM, David Holmes wrote: > Thanks Eric. > > So to summarize: > > - we create a custom classloader, load a class through it and store a > reference to that Class in a WeakReference > - we then drop the reference to the loader > > At this point the only reference to the loader is from the Class loaded, > which in turn is only weakly reachable. > > I must confess that I'm unclear why this test should be failing in its > original form. The first gc() should remove the strong reference to the > loader. That leaves a weak cycle: WeakRef -> Class -> Loader -> Class. > The second gc() should detect the cycle and clear the WeakRef. I guess > the problem is that depending on which gc is in use the actual gc() > calls may not in fact induce every possible GC action. > > The fix seems reasonable in that regard - keep gc'ing and finalizing > till we see the loader is gone, and so the WeakReference should be > cleared. The original bug would cause a ref to the Class to remain (from > the annotation) and hence the WeakRef would not be cleared. However, in > that case the loader would also be strongly referenced and so never > become finalizable. So if this test was now run against a JDK with the > original bug, the test would hang. So I think we need to add a timeout > in there as well. > > David > > On 25/06/2012 6:06 PM, Eric Wang wrote: >> On 2012/6/21 20:16, David Holmes wrote: >>> Hi Eric, >>> >>> On 21/06/2012 8:57 PM, Eric Wang wrote: >>>> Hi David, >>>> >>>> Thanks for your review, I have updated the code by following your >>>> suggestion. please see the attachment. >>>> I'm not sure whether there's a better way to guarantee object finalized >>>> by GC definitely within the given time. The proposed fix may work in >>>> most cases but may still throw InterruptException if execution is >>>> timeout (2 minutes of JTreg by default). >>> >>> There is no way to guarantee finalization in a specific timeframe, but >>> if a simple test hasn't executed finalizers in 2 minutes then that in >>> itself indicates a problem. >>> >>> Can you post a full webrev for this patch? I don't like seeing it out >>> of context and am wondering exactly what we are trying to GC here. >>> >>> David >>> >>>> Regards, >>>> Eric >>>> >>>> On 2012/6/21 14:32, David Holmes wrote: >>>>> Hi Eric, >>>>> >>>>> On 21/06/2012 4:05 PM, Eric Wang wrote: >>>>>> I come from Java SQE team who are interested in regression test bug >>>>>> fix. >>>>>> Here is the first simple fix for bug 7123972 >>>>>> , Can you please >>>>>> help >>>>>> to review and comment? Attachment is the patch Thanks! >>>>>> >>>>>> This bug is caused by wrong assumption that the GC is started >>>>>> immediately to recycle un-referenced objects after System.gc() called >>>>>> one or two times. >>>>>> >>>>>> The proposed solution is to make sure the un-referenced object is >>>>>> recycled by GC before checking if the reference is null. >>>>> >>>>> Your patch makes its own assumptions - specifically that finalization >>>>> must eventually run. At a minimum you should add >>>>> System.runFinalization() calls after the System.gc() inside the loop. >>>>> Even that is no guarantee in a general sense, though it should work >>>>> for hotspot. >>>>> >>>>> David >>>>> >>>>> >>>>>> Regards, >>>>>> Eric >>>> >> Hi Alan & David, >> >> Thank you for your comments, sorry for reply this mail late as i was >> just back from the dragon boat holiday. >> I have updated the code again based on your suggestions: rename the flag >> variable, increase the sleep time and remove it from problem list. >> The attachment is the full webrev for this patch, Can you please review >> again? Thanks a lot! >> >> Regards, >> Eric From Alan.Bateman at oracle.com Wed Jun 27 06:41:37 2012 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 27 Jun 2012 07:41:37 +0100 Subject: Fwd: Codereview request for 7130915: File.equals does not give expected results when path contains Non-English characters on Mac OS X In-Reply-To: <4FEA7F1E.4070500@oracle.com> References: <4FE4A4D6.4070100@oracle.com> <4FE94F6F.2060002@oracle.com> <4FE94FED.6050406@oracle.com> <4FE9CEF3.8080905@oracle.com> <4FEA7F1E.4070500@oracle.com> Message-ID: <4FEAAB21.9050205@oracle.com> On 27/06/2012 04:33, Xueming Shen wrote: > Alan, > > Webrev has been updated accordingly at > > http://cr.openjdk.java.net/~sherman/7130915/webrev > > with changes > > (1) added a CFStringCreateMutable(...) != null check in both io and > nio native, though it is > unlikely to fail here because we are passing a NULL and 0 > length, like new StringBuilder() > invocation, if it fails the system probably goes very wrong. Both > FStringAppendCharacters > and CFStringNormalize are void return type. > > (2) The first line of path.toCharArray in normalizeJavaPath is a typo, > it is supposed to be > deleted. The implementation only goes toCharArray when it needs > to go native. Currently > it uses >0x80 as the fast path criteria, it is possible to expose > some sun.text.normalizer's > internal methods to have a "quick nfc" check, but I'm not sure > how much the performance > gain would be, but might worth some investigation later. > > (3) Comments have been added for those override-able methods in > UnixFileSystem. > > (4) blank lines have been removed from dispatcher.c > > (5) I don't think we need to do the HFS check, given we are only doing > nfc/nfd stuff now, as > long as it is a MacOSX, I believe its nfc/nfd layer will be > there. Copyright has been re-copy/ > pasted and we now only use only bugid. > > -Sherman I'm heading away on vacation now and only quickly scanned the updated webrev. All looks okay to me. On the calls to the CF functions then one thing is that if they fail (and this is unlikely I know) then you won't have an exception pending so may need to add code to call one of the JNU* functions to throw OOME, otherwise it might cause a NPE in the caller rather than throwing an exception as you would expect. -Alan From paul.sandoz at oracle.com Wed Jun 27 06:51:46 2012 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 27 Jun 2012 08:51:46 +0200 Subject: RFR [7u6]: 7166896: DocumentBuilder.parse(String uri) is not IPv6 enabled. It throws MalformedURLException In-Reply-To: <4FEA30C1.7080204@oracle.com> References: <4FE4FB34.9040808@oracle.com> <22CB14C2-C460-430C-B38D-96E9F92B22C3@oracle.com> <4FEA30C1.7080204@oracle.com> Message-ID: <3CA0E9EC-32EA-42B3-82A5-2998AC556912@oracle.com> Hi, On Jun 26, 2012, at 11:59 PM, Joe Wang wrote: > Hi Paul, > > That method was contributed by engineers from Korea and intended to handle paths that contained international characters, so that was how it was named. It was an extra processing added. Outside of that scenario, we'd want to skip the process and get back to letting URL handle the input, whether the system id contains space or '[', and etc. > Your fix will fail if there is an IPv6 encoded address for the host part and there are non-ASCII characters present in, for example, the path part. If the intent is to *never* percent encode ASCII characters you should change the following (and JavaDoc) to be consistent: 2638 // for each byte 2639 for (i = 0; i < len; i++) { 2640 b = bytes[i]; 2641 // for non-ascii character: make it positive, then escape 2642 if (b < 0) { 2643 ch = b + 256; 2644 buffer.append('%'); 2645 buffer.append(gHexChs[ch >> 4]); 2646 buffer.append(gHexChs[ch & 0xf]); 2647 } 2648 else if (b != '%' && b != '#' && gNeedEscaping[b]) { //<--- remove this block 2649 buffer.append('%'); 2650 buffer.append(gAfterEscaping1[b]); 2651 buffer.append(gAfterEscaping2[b]); 2652 } 2653 else { 2654 buffer.append((char)b); 2655 } 2656 } Thankfully java.net.URL is much more forgiving (a polite way of saying buggy!) than java.net.URI and accepts unencoded reserved ASCII characters as part of the URI encoded characters. Something does not smell right here. Arguably the system ID should be a correctly encoded URI to begin with otherwise an error should result. Paul. > -Joe > > On 6/25/2012 9:13 AM, Paul Sandoz wrote: >> Hi Joe, >> >> What happens if there is a space character or other characters in the string that should be encoded ? >> >> http://greenbytes.de/tech/webdav/rfc2396.html#rfc.section.2.4.3 >> >> I suspect "escapeNonUSAscii" is slightly misleading, it should be really called something like "escapeCharactersInUriString". >> >> Note that '[' and ']' are not valid URI characters outside of an IPv6 encoded address. >> >> Paul. >> >> On Jun 23, 2012, at 1:09 AM, Joe Wang wrote: >> >>> Hi, >>> >>> This is a patch to fix the IPv6 issue. >>> >>> In a previous patch to fix an issue with system id containing international characters, an extra character escaping was added so that any URL passed to the parser goes through method escapeNonUSAscii before it's used to construct an URL. >>> >>> However, literal IPv6 addresses are enclosed in square brackets. The escapeNonUSAscii encoded address will become unrecognizable to URL that would throw a java.net.MalformedURLException. An address such as http://[fe80::la03:73ff:fead:f7b0]/note.xml is encoded as http://%5Bfe80::la03:73ff:fead:f7b0%5D/note.xml", resulting in java.net.MalformedURLException: For input string: ":la03:73ff:fead:f7b0%5D". >>> >>> This patch skips the encoding process and returns it as is if there're no non-ascii characters. >>> >>> webrev: http://cr.openjdk.java.net/~joehw/7u6/7166896/webrev/ >>> >>> Please review. >>> >>> Thanks, >>> Joe From yiming.wang at oracle.com Wed Jun 27 06:50:32 2012 From: yiming.wang at oracle.com (Eric Wang) Date: Wed, 27 Jun 2012 14:50:32 +0800 Subject: Patch review request - Test bug 7123972 test/java/lang/annotation/loaderLeak/Main.java fails intermittently In-Reply-To: <4FEAA608.1000502@oracle.com> References: <4FE2B997.7090204@oracle.com> <4FE2BFFB.8010705@oracle.com> <4FE2FE2C.1020601@oracle.com> <4FE310BB.6000100@oracle.com> <4FE81BFC.8040206@oracle.com> <4FEA2EFB.4050109@oracle.com> <4FEAA608.1000502@oracle.com> Message-ID: <4FEAAD38.7020304@oracle.com> Hi David, Thank you! I run the test several times on 3 platforms (windows, solaris and linux), the average execution time is 30secs to 60secs. if the test hang 2 minutes, there should be something wrong. Hi Marks, I don't have the author role, Can you please help to review and post the webrev 7123972.zip in attachment if it is OK, Thanks a lot! Regards, Eric On 2012/6/27 14:19, David Holmes wrote: > Eric, > > Ignore my comment about adding the timeouts. As Alan reminded me if > the test would hang then jtreg will time it out after two minutes anyway. > > So this is good to go as far as I am concerned. > > Thanks, > David > > On 27/06/2012 7:51 AM, David Holmes wrote: >> Thanks Eric. >> >> So to summarize: >> >> - we create a custom classloader, load a class through it and store a >> reference to that Class in a WeakReference >> - we then drop the reference to the loader >> >> At this point the only reference to the loader is from the Class loaded, >> which in turn is only weakly reachable. >> >> I must confess that I'm unclear why this test should be failing in its >> original form. The first gc() should remove the strong reference to the >> loader. That leaves a weak cycle: WeakRef -> Class -> Loader -> Class. >> The second gc() should detect the cycle and clear the WeakRef. I guess >> the problem is that depending on which gc is in use the actual gc() >> calls may not in fact induce every possible GC action. >> >> The fix seems reasonable in that regard - keep gc'ing and finalizing >> till we see the loader is gone, and so the WeakReference should be >> cleared. The original bug would cause a ref to the Class to remain (from >> the annotation) and hence the WeakRef would not be cleared. However, in >> that case the loader would also be strongly referenced and so never >> become finalizable. So if this test was now run against a JDK with the >> original bug, the test would hang. So I think we need to add a timeout >> in there as well. >> >> David >> >> On 25/06/2012 6:06 PM, Eric Wang wrote: >>> On 2012/6/21 20:16, David Holmes wrote: >>>> Hi Eric, >>>> >>>> On 21/06/2012 8:57 PM, Eric Wang wrote: >>>>> Hi David, >>>>> >>>>> Thanks for your review, I have updated the code by following your >>>>> suggestion. please see the attachment. >>>>> I'm not sure whether there's a better way to guarantee object >>>>> finalized >>>>> by GC definitely within the given time. The proposed fix may work in >>>>> most cases but may still throw InterruptException if execution is >>>>> timeout (2 minutes of JTreg by default). >>>> >>>> There is no way to guarantee finalization in a specific timeframe, but >>>> if a simple test hasn't executed finalizers in 2 minutes then that in >>>> itself indicates a problem. >>>> >>>> Can you post a full webrev for this patch? I don't like seeing it out >>>> of context and am wondering exactly what we are trying to GC here. >>>> >>>> David >>>> >>>>> Regards, >>>>> Eric >>>>> >>>>> On 2012/6/21 14:32, David Holmes wrote: >>>>>> Hi Eric, >>>>>> >>>>>> On 21/06/2012 4:05 PM, Eric Wang wrote: >>>>>>> I come from Java SQE team who are interested in regression test bug >>>>>>> fix. >>>>>>> Here is the first simple fix for bug 7123972 >>>>>>> , Can you please >>>>>>> help >>>>>>> to review and comment? Attachment is the patch Thanks! >>>>>>> >>>>>>> This bug is caused by wrong assumption that the GC is started >>>>>>> immediately to recycle un-referenced objects after System.gc() >>>>>>> called >>>>>>> one or two times. >>>>>>> >>>>>>> The proposed solution is to make sure the un-referenced object is >>>>>>> recycled by GC before checking if the reference is null. >>>>>> >>>>>> Your patch makes its own assumptions - specifically that >>>>>> finalization >>>>>> must eventually run. At a minimum you should add >>>>>> System.runFinalization() calls after the System.gc() inside the >>>>>> loop. >>>>>> Even that is no guarantee in a general sense, though it should work >>>>>> for hotspot. >>>>>> >>>>>> David >>>>>> >>>>>> >>>>>>> Regards, >>>>>>> Eric >>>>> >>> Hi Alan & David, >>> >>> Thank you for your comments, sorry for reply this mail late as i was >>> just back from the dragon boat holiday. >>> I have updated the code again based on your suggestions: rename the >>> flag >>> variable, increase the sleep time and remove it from problem list. >>> The attachment is the full webrev for this patch, Can you please review >>> again? Thanks a lot! >>> >>> Regards, >>> Eric -------------- next part -------------- --- old/test/ProblemList.txt 2012-06-25 15:41:20.466150117 +0800 +++ new/test/ProblemList.txt 2012-06-25 15:41:18.998075349 +0800 @@ -122,9 +122,6 @@ # jdk_lang -# 7123972 -java/lang/annotation/loaderLeak/Main.java generic-all - # 6944188 java/lang/management/ThreadMXBean/ThreadStateTest.java generic-all -------------- next part -------------- --- old/test/java/lang/annotation/loaderLeak/Main.java 2012-06-25 15:41:26.005179716 +0800 +++ new/test/java/lang/annotation/loaderLeak/Main.java 2012-06-25 15:41:24.531076496 +0800 @@ -36,6 +36,8 @@ import java.io.*; public class Main { + static volatile boolean finalized = false; + public static void main(String[] args) throws Exception { for (int i=0; i<100; i++) doTest(args.length != 0); @@ -57,8 +59,11 @@ System.gc(); System.gc(); loader = null; - System.gc(); - System.gc(); + while(!finalized) { + System.gc(); + System.runFinalization(); + Thread.sleep(20); + } if (c.get() != null) throw new AssertionError(); } } @@ -67,6 +72,7 @@ private Hashtable classes = new Hashtable(); public SimpleClassLoader() { + Main.finalized = false; } private byte getClassImplFromDataBase(String className)[] { byte result[]; @@ -124,4 +130,8 @@ classes.put(className, result); return result; } + + protected void finalize() { + Main.finalized = true; + } } From yiming.wang at oracle.com Wed Jun 27 06:57:22 2012 From: yiming.wang at oracle.com (Eric Wang) Date: Wed, 27 Jun 2012 14:57:22 +0800 Subject: [PATCH] Review Request - Test bug: 6948101 java/rmi/transport/pinLastArguments/PinLastArguments.java failing intermittently In-Reply-To: <4FEA5E76.1030400@oracle.com> References: <4FE98037.2050700@oracle.com> <4FEA300D.6090705@oracle.com> <4FEA5E76.1030400@oracle.com> Message-ID: <4FEAAED2.8000901@oracle.com> Hi David & Stuart, Thank you for the help! please review the in webrev 6948101.zip in attachment. Regards, Eric On 2012/6/27 9:14, Stuart Marks wrote: > Hi Eric, > > Alan Bateman asked me to help you out with this since he's going to be > unavailable for a couple weeks. > > I didn't see you on the OpenJDK census [1] so you might not have an > Author role and thus the ability to post webrevs. If indeed you don't, > I can post a webrev for you. I can also post a webrev for your other > review (7123972) if it's still necessary. > > Finally, I can push the fixes for you when the reviews are complete. > > s'marks > > [1] http://openjdk.java.net/census > > On 6/26/12 2:56 PM, David Holmes wrote: >> Hi Eric, >> >> On 26/06/2012 7:26 PM, Eric Wang wrote: >>> Please help to review the fix attached for test bug 6948101 >>> which is same root >>> cause as bug 7123972 >>> . >>> The test makes wrong assumption that GC is started immediately to >>> recycle unused objects after System.gc() called. >>> The proposed fix is to make sure objects have been recycled by GC >>> before >>> checking if the weak reference is null. >> >> Again I really need to see a webrev to see the fix in context. Do you >> have >> Author role and an OpenJDK user name so you can post webrevs on >> cr.openjdk.java.net? >> >> I suspect this may have the same issues as the other fix and require >> a timeout >> for when the original problem is still present. >> >> Thanks, >> David >> >>> Regards, >>> Eric -------------- next part -------------- --- old/test/ProblemList.txt 2012-06-26 17:02:12.934138771 +0800 +++ new/test/ProblemList.txt 2012-06-26 17:02:11.494051649 +0800 @@ -271,9 +271,6 @@ # 7140992 java/rmi/server/Unreferenced/finiteGCLatency/FiniteGCLatency.java generic-all -# 6948101 -java/rmi/transport/pinLastArguments/PinLastArguments.java generic-all - # 7146541 java/rmi/transport/rapidExportUnexport/RapidExportUnexport.java linux-all -------------- next part -------------- --- old/test/java/rmi/transport/pinLastArguments/PinLastArguments.java 2012-06-26 17:02:17.432074905 +0800 +++ new/test/java/rmi/transport/pinLastArguments/PinLastArguments.java 2012-06-26 17:02:15.984073307 +0800 @@ -43,7 +43,8 @@ import java.rmi.server.UnicastRemoteObject; public class PinLastArguments { - + private static volatile boolean finalized = false; + public interface Ping extends Remote { void ping(Object first, Object second) throws RemoteException; } @@ -53,6 +54,9 @@ public void ping(Object first, Object second) { System.err.println("ping invoked: " + first + ", " + second); } + protected void finalize() { + finalized = true; + } } public static void main(String[] args) throws Exception { @@ -78,7 +82,11 @@ } impl = null; - System.gc(); + while(!finalized) { + System.gc(); + System.runFinalization(); + Thread.sleep(20); + } if (ref.get() != null) { throw new Error("TEST FAILED: impl not garbage collected"); From xueming.shen at oracle.com Wed Jun 27 07:03:13 2012 From: xueming.shen at oracle.com (Xueming Shen) Date: Wed, 27 Jun 2012 00:03:13 -0700 Subject: Fwd: Codereview request for 7130915: File.equals does not give expected results when path contains Non-English characters on Mac OS X In-Reply-To: <4FEAAB21.9050205@oracle.com> References: <4FE4A4D6.4070100@oracle.com> <4FE94F6F.2060002@oracle.com> <4FE94FED.6050406@oracle.com> <4FE9CEF3.8080905@oracle.com> <4FEA7F1E.4070500@oracle.com> <4FEAAB21.9050205@oracle.com> Message-ID: <4FEAB031.4080107@oracle.com> Thanks Alan! The webrev has been updated to throw OOME as your other nio native dispatcher does. http://cr.openjdk.java.net/~sherman/7130915/webrev. I can wait for your back from the vacation:-) -Sherman On 6/26/12 11:41 PM, Alan Bateman wrote: > On 27/06/2012 04:33, Xueming Shen wrote: >> Alan, >> >> Webrev has been updated accordingly at >> >> http://cr.openjdk.java.net/~sherman/7130915/webrev >> >> with changes >> >> (1) added a CFStringCreateMutable(...) != null check in both io and >> nio native, though it is >> unlikely to fail here because we are passing a NULL and 0 >> length, like new StringBuilder() >> invocation, if it fails the system probably goes very wrong. >> Both FStringAppendCharacters >> and CFStringNormalize are void return type. >> >> (2) The first line of path.toCharArray in normalizeJavaPath is a >> typo, it is supposed to be >> deleted. The implementation only goes toCharArray when it needs >> to go native. Currently >> it uses >0x80 as the fast path criteria, it is possible to >> expose some sun.text.normalizer's >> internal methods to have a "quick nfc" check, but I'm not sure >> how much the performance >> gain would be, but might worth some investigation later. >> >> (3) Comments have been added for those override-able methods in >> UnixFileSystem. >> >> (4) blank lines have been removed from dispatcher.c >> >> (5) I don't think we need to do the HFS check, given we are only >> doing nfc/nfd stuff now, as >> long as it is a MacOSX, I believe its nfc/nfd layer will be >> there. Copyright has been re-copy/ >> pasted and we now only use only bugid. >> >> -Sherman > I'm heading away on vacation now and only quickly scanned the updated > webrev. All looks okay to me. On the calls to the CF functions then > one thing is that if they fail (and this is unlikely I know) then you > won't have an exception pending so may need to add code to call one of > the JNU* functions to throw OOME, otherwise it might cause a NPE in > the caller rather than throwing an exception as you would expect. > > -Alan > From lana.steuck at oracle.com Wed Jun 27 07:10:48 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 27 Jun 2012 07:10:48 +0000 Subject: hg: jdk8/tl: 4 new changesets Message-ID: <20120627071049.3FA3047B47@hg.openjdk.java.net> Changeset: 8fb4cd2f05a1 Author: mbykov Date: 2012-06-19 14:24 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/8fb4cd2f05a1 7178241: Basic script for JDK source code legal headers conformance verification Summary: A new script lic_check.sh to check license headers in JDK source code Reviewed-by: ohair, darcy Contributed-by: misha.bykov at oracle.com + make/scripts/lic_check.sh Changeset: e4f81a817447 Author: katleman Date: 2012-06-20 15:22 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/e4f81a817447 Merge Changeset: 1e989139ce0d Author: katleman Date: 2012-06-21 17:07 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/1e989139ce0d Added tag jdk8-b44 for changeset e4f81a817447 ! .hgtags Changeset: 633f2378c904 Author: lana Date: 2012-06-25 21:37 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/633f2378c904 Merge From lana.steuck at oracle.com Wed Jun 27 07:10:54 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 27 Jun 2012 07:10:54 +0000 Subject: hg: jdk8/tl/jaxws: Added tag jdk8-b44 for changeset f6a417540ef1 Message-ID: <20120627071102.30C6A47B48@hg.openjdk.java.net> Changeset: e80ac58b5ba9 Author: katleman Date: 2012-06-21 17:07 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/e80ac58b5ba9 Added tag jdk8-b44 for changeset f6a417540ef1 ! .hgtags From lana.steuck at oracle.com Wed Jun 27 07:10:52 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 27 Jun 2012 07:10:52 +0000 Subject: hg: jdk8/tl/corba: 9 new changesets Message-ID: <20120627071104.591DD47B49@hg.openjdk.java.net> Changeset: ad3ba4b392cc Author: katleman Date: 2012-06-21 17:07 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/ad3ba4b392cc Added tag jdk8-b44 for changeset 439d9bf8e4ff ! .hgtags Changeset: 5222b7d658d4 Author: coffeys Date: 2012-03-26 14:01 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/5222b7d658d4 7143851: Improve IIOP stub and tie generation in RMIC 7149048: Changes to corba rmic stubGenerator class are not used during jdk build process Reviewed-by: mschoene, robm ! src/share/classes/sun/rmi/rmic/iiop/StubGenerator.java Changeset: e324dfb90c9e Author: mbankal Date: 2012-03-28 02:50 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/e324dfb90c9e 7079902: Refine CORBA data models Reviewed-by: coffeys ! src/share/classes/com/sun/corba/se/impl/interceptors/ClientRequestInfoImpl.java ! src/share/classes/com/sun/corba/se/impl/interceptors/ServerRequestInfoImpl.java ! src/share/classes/com/sun/corba/se/impl/javax/rmi/CORBA/Util.java ! src/share/classes/com/sun/corba/se/impl/oa/poa/POAPolicyMediatorBase_R.java ! src/share/classes/com/sun/corba/se/impl/oa/toa/TOAFactory.java ! src/share/classes/com/sun/corba/se/impl/orb/ParserTable.java ! src/share/classes/com/sun/corba/se/impl/orbutil/RepositoryId_1_3.java ! src/share/classes/com/sun/corba/se/impl/orbutil/RepositoryId_1_3_1.java ! src/share/classes/com/sun/corba/se/impl/protocol/LocalClientRequestDispatcherBase.java ! src/share/classes/com/sun/corba/se/impl/util/RepositoryId.java ! src/share/classes/com/sun/corba/se/spi/logging/CORBALogDomains.java ! src/share/classes/sun/rmi/rmic/iiop/IDLNames.java Changeset: 2846cb957582 Author: mbankal Date: 2012-03-28 02:53 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/2846cb957582 Merge Changeset: a00c5c0b1f30 Author: asaha Date: 2012-04-10 10:41 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/a00c5c0b1f30 Merge - make/tools/src/build/tools/stripproperties/StripProperties.java Changeset: 3697feea6f54 Author: asaha Date: 2012-05-08 07:27 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/3697feea6f54 Merge Changeset: 787fb5a0602f Author: asaha Date: 2012-05-21 14:50 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/787fb5a0602f Merge Changeset: 25bb958d07de Author: asaha Date: 2012-06-07 12:29 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/25bb958d07de Merge Changeset: 747dad9e9d37 Author: lana Date: 2012-06-26 10:13 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/747dad9e9d37 Merge From lana.steuck at oracle.com Wed Jun 27 07:11:03 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 27 Jun 2012 07:11:03 +0000 Subject: hg: jdk8/tl/langtools: 2 new changesets Message-ID: <20120627071110.BBD3A47B4A@hg.openjdk.java.net> Changeset: a39c99192184 Author: katleman Date: 2012-06-21 17:08 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/a39c99192184 Added tag jdk8-b44 for changeset 59cbead12ff4 ! .hgtags Changeset: e111e4587cca Author: lana Date: 2012-06-25 21:39 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/e111e4587cca Merge - src/share/classes/com/sun/tools/javac/parser/EndPosTable.java From lana.steuck at oracle.com Wed Jun 27 07:11:25 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 27 Jun 2012 07:11:25 +0000 Subject: hg: jdk8/tl/jaxp: 8 new changesets Message-ID: <20120627071151.E60B247B4B@hg.openjdk.java.net> Changeset: a5c1047a05e9 Author: katleman Date: 2012-06-21 17:07 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/a5c1047a05e9 Added tag jdk8-b44 for changeset 0b3f3a4ce139 ! .hgtags Changeset: 54a86b897fe8 Author: lana Date: 2012-06-25 21:37 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/54a86b897fe8 Merge Changeset: d117133a7283 Author: joehw Date: 2012-04-10 13:59 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/d117133a7283 7157609: Issues with loop Reviewed-by: hawtin, lancea, asaha ! src/share/classes/com/sun/org/apache/xerces/internal/impl/XMLScanner.java Changeset: 0e635b48336a Author: asaha Date: 2012-05-08 07:30 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/0e635b48336a Merge = src/com/sun/org/apache/xerces/internal/impl/XMLScanner.java < src/share/classes/com/sun/org/apache/xerces/internal/impl/XMLScanner.java - src/share/classes/com/sun/java_cup/internal/runtime/Scanner.java - src/share/classes/com/sun/java_cup/internal/runtime/Symbol.java - src/share/classes/com/sun/java_cup/internal/runtime/lr_parser.java - src/share/classes/com/sun/java_cup/internal/runtime/virtual_parse_stack.java - src/share/classes/com/sun/org/apache/bcel/internal/Constants.java - src/share/classes/com/sun/org/apache/bcel/internal/ExceptionConstants.java - src/share/classes/com/sun/org/apache/bcel/internal/Repository.java - src/share/classes/com/sun/org/apache/bcel/internal/classfile/AccessFlags.java - src/share/classes/com/sun/org/apache/bcel/internal/classfile/Attribute.java - src/share/classes/com/sun/org/apache/bcel/internal/classfile/AttributeReader.java - src/share/classes/com/sun/org/apache/bcel/internal/classfile/ClassFormatException.java - src/share/classes/com/sun/org/apache/bcel/internal/classfile/ClassParser.java - src/share/classes/com/sun/org/apache/bcel/internal/classfile/Code.java - src/share/classes/com/sun/org/apache/bcel/internal/classfile/CodeException.java - src/share/classes/com/sun/org/apache/bcel/internal/classfile/Constant.java - src/share/classes/com/sun/org/apache/bcel/internal/classfile/ConstantCP.java - src/share/classes/com/sun/org/apache/bcel/internal/classfile/ConstantClass.java - src/share/classes/com/sun/org/apache/bcel/internal/classfile/ConstantDouble.java - src/share/classes/com/sun/org/apache/bcel/internal/classfile/ConstantFieldref.java - src/share/classes/com/sun/org/apache/bcel/internal/classfile/ConstantFloat.java - src/share/classes/com/sun/org/apache/bcel/internal/classfile/ConstantInteger.java - src/share/classes/com/sun/org/apache/bcel/internal/classfile/ConstantInterfaceMethodref.java - src/share/classes/com/sun/org/apache/bcel/internal/classfile/ConstantLong.java - src/share/classes/com/sun/org/apache/bcel/internal/classfile/ConstantMethodref.java - src/share/classes/com/sun/org/apache/bcel/internal/classfile/ConstantNameAndType.java - src/share/classes/com/sun/org/apache/bcel/internal/classfile/ConstantObject.java - src/share/classes/com/sun/org/apache/bcel/internal/classfile/ConstantPool.java - src/share/classes/com/sun/org/apache/bcel/internal/classfile/ConstantString.java - src/share/classes/com/sun/org/apache/bcel/internal/classfile/ConstantUtf8.java - src/share/classes/com/sun/org/apache/bcel/internal/classfile/ConstantValue.java - src/share/classes/com/sun/org/apache/bcel/internal/classfile/Deprecated.java - src/share/classes/com/sun/org/apache/bcel/internal/classfile/DescendingVisitor.java - src/share/classes/com/sun/org/apache/bcel/internal/classfile/EmptyVisitor.java - src/share/classes/com/sun/org/apache/bcel/internal/classfile/ExceptionTable.java - src/share/classes/com/sun/org/apache/bcel/internal/classfile/Field.java - src/share/classes/com/sun/org/apache/bcel/internal/classfile/FieldOrMethod.java - src/share/classes/com/sun/org/apache/bcel/internal/classfile/InnerClass.java - src/share/classes/com/sun/org/apache/bcel/internal/classfile/InnerClasses.java - src/share/classes/com/sun/org/apache/bcel/internal/classfile/JavaClass.java - src/share/classes/com/sun/org/apache/bcel/internal/classfile/LineNumber.java - src/share/classes/com/sun/org/apache/bcel/internal/classfile/LineNumberTable.java - src/share/classes/com/sun/org/apache/bcel/internal/classfile/LocalVariable.java - src/share/classes/com/sun/org/apache/bcel/internal/classfile/LocalVariableTable.java - src/share/classes/com/sun/org/apache/bcel/internal/classfile/Method.java - src/share/classes/com/sun/org/apache/bcel/internal/classfile/Node.java - src/share/classes/com/sun/org/apache/bcel/internal/classfile/PMGClass.java - src/share/classes/com/sun/org/apache/bcel/internal/classfile/Signature.java - src/share/classes/com/sun/org/apache/bcel/internal/classfile/SourceFile.java - src/share/classes/com/sun/org/apache/bcel/internal/classfile/StackMap.java - src/share/classes/com/sun/org/apache/bcel/internal/classfile/StackMapEntry.java - src/share/classes/com/sun/org/apache/bcel/internal/classfile/StackMapType.java - src/share/classes/com/sun/org/apache/bcel/internal/classfile/Synthetic.java - src/share/classes/com/sun/org/apache/bcel/internal/classfile/Unknown.java - src/share/classes/com/sun/org/apache/bcel/internal/classfile/Utility.java - src/share/classes/com/sun/org/apache/bcel/internal/classfile/Visitor.java - src/share/classes/com/sun/org/apache/bcel/internal/classfile/package.html - src/share/classes/com/sun/org/apache/bcel/internal/generic/AALOAD.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/AASTORE.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/ACONST_NULL.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/ALOAD.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/ANEWARRAY.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/ARETURN.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/ARRAYLENGTH.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/ASTORE.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/ATHROW.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/AllocationInstruction.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/ArithmeticInstruction.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/ArrayInstruction.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/ArrayType.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/BALOAD.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/BASTORE.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/BIPUSH.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/BREAKPOINT.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/BasicType.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/BranchHandle.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/BranchInstruction.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/CALOAD.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/CASTORE.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/CHECKCAST.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/CPInstruction.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/ClassGen.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/ClassGenException.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/ClassObserver.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/CodeExceptionGen.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/CompoundInstruction.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/ConstantPoolGen.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/ConstantPushInstruction.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/ConversionInstruction.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/D2F.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/D2I.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/D2L.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/DADD.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/DALOAD.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/DASTORE.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/DCMPG.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/DCMPL.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/DCONST.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/DDIV.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/DLOAD.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/DMUL.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/DNEG.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/DREM.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/DRETURN.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/DSTORE.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/DSUB.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/DUP.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/DUP2.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/DUP2_X1.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/DUP2_X2.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/DUP_X1.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/DUP_X2.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/EmptyVisitor.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/ExceptionThrower.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/F2D.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/F2I.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/F2L.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/FADD.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/FALOAD.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/FASTORE.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/FCMPG.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/FCMPL.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/FCONST.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/FDIV.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/FLOAD.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/FMUL.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/FNEG.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/FREM.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/FRETURN.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/FSTORE.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/FSUB.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/FieldGen.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/FieldGenOrMethodGen.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/FieldInstruction.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/FieldObserver.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/FieldOrMethod.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/GETFIELD.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/GETSTATIC.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/GOTO.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/GOTO_W.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/GotoInstruction.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/I2B.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/I2C.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/I2D.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/I2F.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/I2L.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/I2S.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/IADD.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/IALOAD.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/IAND.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/IASTORE.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/ICONST.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/IDIV.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/IFEQ.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/IFGE.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/IFGT.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/IFLE.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/IFLT.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/IFNE.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/IFNONNULL.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/IFNULL.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/IF_ACMPEQ.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/IF_ACMPNE.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/IF_ICMPEQ.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/IF_ICMPGE.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/IF_ICMPGT.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/IF_ICMPLE.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/IF_ICMPLT.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/IF_ICMPNE.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/IINC.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/ILOAD.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/IMPDEP1.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/IMPDEP2.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/IMUL.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/INEG.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/INSTANCEOF.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/INVOKEINTERFACE.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/INVOKESPECIAL.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/INVOKESTATIC.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/INVOKEVIRTUAL.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/IOR.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/IREM.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/IRETURN.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/ISHL.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/ISHR.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/ISTORE.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/ISUB.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/IUSHR.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/IXOR.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/IfInstruction.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/IndexedInstruction.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/Instruction.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/InstructionComparator.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/InstructionConstants.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/InstructionFactory.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/InstructionHandle.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/InstructionList.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/InstructionListObserver.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/InstructionTargeter.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/InvokeInstruction.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/JSR.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/JSR_W.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/JsrInstruction.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/L2D.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/L2F.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/L2I.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/LADD.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/LALOAD.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/LAND.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/LASTORE.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/LCMP.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/LCONST.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/LDC.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/LDC2_W.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/LDC_W.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/LDIV.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/LLOAD.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/LMUL.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/LNEG.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/LOOKUPSWITCH.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/LOR.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/LREM.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/LRETURN.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/LSHL.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/LSHR.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/LSTORE.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/LSUB.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/LUSHR.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/LXOR.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/LineNumberGen.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/LoadClass.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/LoadInstruction.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/LocalVariableGen.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/LocalVariableInstruction.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/MONITORENTER.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/MONITOREXIT.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/MULTIANEWARRAY.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/MethodGen.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/MethodObserver.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/NEW.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/NEWARRAY.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/NOP.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/NamedAndTyped.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/ObjectType.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/POP.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/POP2.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/PUSH.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/PUTFIELD.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/PUTSTATIC.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/PopInstruction.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/PushInstruction.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/RET.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/RETURN.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/ReferenceType.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/ReturnInstruction.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/ReturnaddressType.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/SALOAD.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/SASTORE.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/SIPUSH.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/SWAP.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/SWITCH.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/Select.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/StackConsumer.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/StackInstruction.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/StackProducer.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/StoreInstruction.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/TABLESWITCH.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/TargetLostException.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/Type.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/TypedInstruction.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/UnconditionalBranch.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/VariableLengthInstruction.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/Visitor.java - src/share/classes/com/sun/org/apache/bcel/internal/generic/package.html - src/share/classes/com/sun/org/apache/bcel/internal/package.html - src/share/classes/com/sun/org/apache/bcel/internal/util/AttributeHTML.java - src/share/classes/com/sun/org/apache/bcel/internal/util/BCELFactory.java - src/share/classes/com/sun/org/apache/bcel/internal/util/BCELifier.java - src/share/classes/com/sun/org/apache/bcel/internal/util/ByteSequence.java - src/share/classes/com/sun/org/apache/bcel/internal/util/Class2HTML.java - src/share/classes/com/sun/org/apache/bcel/internal/util/ClassLoader.java - src/share/classes/com/sun/org/apache/bcel/internal/util/ClassLoaderRepository.java - src/share/classes/com/sun/org/apache/bcel/internal/util/ClassPath.java - src/share/classes/com/sun/org/apache/bcel/internal/util/ClassQueue.java - src/share/classes/com/sun/org/apache/bcel/internal/util/ClassSet.java - src/share/classes/com/sun/org/apache/bcel/internal/util/ClassStack.java - src/share/classes/com/sun/org/apache/bcel/internal/util/ClassVector.java - src/share/classes/com/sun/org/apache/bcel/internal/util/CodeHTML.java - src/share/classes/com/sun/org/apache/bcel/internal/util/ConstantHTML.java - src/share/classes/com/sun/org/apache/bcel/internal/util/InstructionFinder.java - src/share/classes/com/sun/org/apache/bcel/internal/util/JavaWrapper.java - src/share/classes/com/sun/org/apache/bcel/internal/util/MethodHTML.java - src/share/classes/com/sun/org/apache/bcel/internal/util/Repository.java - src/share/classes/com/sun/org/apache/bcel/internal/util/SyntheticRepository.java - src/share/classes/com/sun/org/apache/bcel/internal/util/package.html - src/share/classes/com/sun/org/apache/regexp/internal/CharacterArrayCharacterIterator.java - src/share/classes/com/sun/org/apache/regexp/internal/CharacterIterator.java - src/share/classes/com/sun/org/apache/regexp/internal/RE.java - src/share/classes/com/sun/org/apache/regexp/internal/RECompiler.java - src/share/classes/com/sun/org/apache/regexp/internal/REDebugCompiler.java - src/share/classes/com/sun/org/apache/regexp/internal/REProgram.java - src/share/classes/com/sun/org/apache/regexp/internal/RESyntaxException.java - src/share/classes/com/sun/org/apache/regexp/internal/RETest.java - src/share/classes/com/sun/org/apache/regexp/internal/REUtil.java - src/share/classes/com/sun/org/apache/regexp/internal/ReaderCharacterIterator.java - src/share/classes/com/sun/org/apache/regexp/internal/StreamCharacterIterator.java - src/share/classes/com/sun/org/apache/regexp/internal/StringCharacterIterator.java - src/share/classes/com/sun/org/apache/regexp/internal/recompile.java - src/share/classes/com/sun/org/apache/xalan/META-INF/services/javax.xml.transform.TransformerFactory - src/share/classes/com/sun/org/apache/xalan/META-INF/services/javax.xml.xpath.XPathFactory - src/share/classes/com/sun/org/apache/xalan/META-INF/services/org.apache.xml.dtm.DTMManager - src/share/classes/com/sun/org/apache/xalan/internal/Version.java - src/share/classes/com/sun/org/apache/xalan/internal/extensions/ExpressionContext.java - src/share/classes/com/sun/org/apache/xalan/internal/extensions/package.html - src/share/classes/com/sun/org/apache/xalan/internal/lib/ExsltBase.java - src/share/classes/com/sun/org/apache/xalan/internal/lib/ExsltCommon.java - src/share/classes/com/sun/org/apache/xalan/internal/lib/ExsltDatetime.java - src/share/classes/com/sun/org/apache/xalan/internal/lib/ExsltDynamic.java - src/share/classes/com/sun/org/apache/xalan/internal/lib/ExsltMath.java - src/share/classes/com/sun/org/apache/xalan/internal/lib/ExsltSets.java - src/share/classes/com/sun/org/apache/xalan/internal/lib/ExsltStrings.java - src/share/classes/com/sun/org/apache/xalan/internal/lib/Extensions.java - src/share/classes/com/sun/org/apache/xalan/internal/lib/NodeInfo.java - src/share/classes/com/sun/org/apache/xalan/internal/lib/ObjectFactory.java - src/share/classes/com/sun/org/apache/xalan/internal/lib/SecuritySupport.java - src/share/classes/com/sun/org/apache/xalan/internal/lib/SecuritySupport12.java - src/share/classes/com/sun/org/apache/xalan/internal/lib/package.html - src/share/classes/com/sun/org/apache/xalan/internal/res/XSLMessages.java - src/share/classes/com/sun/org/apache/xalan/internal/res/XSLTErrorResources.java - src/share/classes/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_de.java - src/share/classes/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_en.java - src/share/classes/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_es.java - src/share/classes/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_fr.java - src/share/classes/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_it.java - src/share/classes/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_ja.java - src/share/classes/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_ko.java - src/share/classes/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_pt_BR.java - src/share/classes/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_sv.java - src/share/classes/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_zh_CN.java - src/share/classes/com/sun/org/apache/xalan/internal/res/XSLTErrorResources_zh_TW.java - src/share/classes/com/sun/org/apache/xalan/internal/res/XSLTInfo.properties - src/share/classes/com/sun/org/apache/xalan/internal/res/package.html - src/share/classes/com/sun/org/apache/xalan/internal/templates/Constants.java - src/share/classes/com/sun/org/apache/xalan/internal/templates/package.html - src/share/classes/com/sun/org/apache/xalan/internal/xslt/EnvironmentCheck.java - src/share/classes/com/sun/org/apache/xalan/internal/xslt/ObjectFactory.java - src/share/classes/com/sun/org/apache/xalan/internal/xslt/Process.java - src/share/classes/com/sun/org/apache/xalan/internal/xslt/SecuritySupport.java - src/share/classes/com/sun/org/apache/xalan/internal/xslt/SecuritySupport12.java - src/share/classes/com/sun/org/apache/xalan/internal/xslt/package.html - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/CollatorFactory.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/DOM.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/DOMCache.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/DOMEnhancedForDTM.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/NodeIterator.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/ProcessorVersion.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/StripFilter.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/Translet.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/TransletException.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/cmdline/Compile.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/cmdline/ObjectFactory.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/cmdline/SecuritySupport.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/cmdline/SecuritySupport12.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/cmdline/Transform.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/cmdline/getopt/GetOpt.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/cmdline/getopt/GetOptsException.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/cmdline/getopt/IllegalArgumentException.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/cmdline/getopt/MissingOptArgException.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/AbsoluteLocationPath.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/AbsolutePathPattern.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/AlternativePattern.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/AncestorPattern.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/ApplyImports.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/ApplyTemplates.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/ArgumentList.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/Attribute.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/AttributeSet.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/AttributeValue.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/AttributeValueTemplate.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/BinOpExpr.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/BooleanCall.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/BooleanExpr.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/CallTemplate.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/CastCall.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/CastExpr.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/CeilingCall.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/Choose.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/Closure.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/Comment.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/CompilerException.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/ConcatCall.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/Constants.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/ContainsCall.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/Copy.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/CopyOf.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/CurrentCall.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/DecimalFormatting.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/DocumentCall.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/ElementAvailableCall.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/EqualityExpr.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/Expression.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/Fallback.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/FilterExpr.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/FilterParentPath.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/FilteredAbsoluteLocationPath.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/FloorCall.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/FlowList.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/ForEach.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/FormatNumberCall.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/FunctionAvailableCall.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/FunctionCall.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/GenerateIdCall.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/IdKeyPattern.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/IdPattern.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/If.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/IllegalCharException.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/Import.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/Include.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/Instruction.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/IntExpr.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/Key.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/KeyCall.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/KeyPattern.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/LangCall.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/LastCall.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/LiteralAttribute.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/LiteralElement.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/LiteralExpr.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/LocalNameCall.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/LocationPathPattern.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/LogicalExpr.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/Makefile.inc - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/Message.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/Mode.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/NameBase.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/NameCall.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/NamespaceAlias.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/NamespaceUriCall.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/NodeTest.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/NotCall.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/Number.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/NumberCall.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/ObjectFactory.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/Otherwise.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/Output.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/Param.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/ParameterRef.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/ParentLocationPath.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/ParentPattern.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/Parser.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/Pattern.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/PositionCall.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/Predicate.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/ProcessingInstruction.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/ProcessingInstructionPattern.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/QName.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/RealExpr.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/RelationalExpr.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/RelativeLocationPath.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/RelativePathPattern.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/RoundCall.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/SecuritySupport.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/SecuritySupport12.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/SimpleAttributeValue.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/Sort.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/SourceLoader.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/StartsWithCall.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/Step.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/StepPattern.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/StringCall.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/StringLengthCall.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/Stylesheet.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/SymbolTable.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/SyntaxTreeNode.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/Template.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/TestSeq.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/Text.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/TopLevelElement.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/TransletOutput.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/UnaryOpExpr.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/UnionPathExpr.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/UnparsedEntityUriCall.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/UnresolvedRef.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/UnsupportedElement.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/UseAttributeSets.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/ValueOf.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/Variable.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/VariableBase.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/VariableRef.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/VariableRefBase.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/When.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/Whitespace.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/WithParam.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/XPathLexer.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/XPathParser.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/XSLTC.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/XslAttribute.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/XslElement.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/sym.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/AttributeSetMethodGenerator.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/BooleanType.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ClassGenerator.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/CompareGenerator.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_ca.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_cs.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_de.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_es.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_fr.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_it.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_ja.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_ko.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_pt_BR.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_sk.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_sv.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_zh_CN.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages_zh_TW.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMsg.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/FilterGenerator.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/IntType.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/MatchGenerator.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/MethodGenerator.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/MethodType.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/MultiHashtable.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/NamedMethodGenerator.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/NodeCounterGenerator.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/NodeSetType.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/NodeSortRecordFactGenerator.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/NodeSortRecordGenerator.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/NodeType.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/NumberType.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ObjectFactory.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ObjectType.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/RealType.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ReferenceType.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ResultTreeType.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/RtMethodGenerator.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/SecuritySupport.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/SecuritySupport12.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/SlotAllocator.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/StringStack.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/StringType.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/TestGenerator.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/Type.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/TypeCheckError.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/Util.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/VoidType.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/xpath.cup - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/xpath.lex - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/AbsoluteIterator.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/AdaptiveResultTreeImpl.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/AnyNodeCounter.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/BitArray.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/CachedNodeListIterator.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/ClonedNodeListIterator.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/CollatorFactoryBase.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/CurrentNodeListFilter.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/CurrentNodeListIterator.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/DOMAdapter.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/DOMBuilder.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/DOMWSFilter.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/DocumentCache.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/DupFilterIterator.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/EmptyFilter.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/ExtendedSAX.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/Filter.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/FilterIterator.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/FilteredStepIterator.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/ForwardPositionIterator.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/KeyIndex.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/LoadDocument.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/MatchingIterator.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/MultiDOM.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/MultiValuedNodeHeapIterator.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/MultipleNodeCounter.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/NodeCounter.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/NodeIteratorBase.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/NodeSortRecord.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/NodeSortRecordFactory.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/NthIterator.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/ObjectFactory.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/SAXImpl.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/SecuritySupport.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/SecuritySupport12.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/SimpleResultTreeImpl.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/SingleNodeCounter.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/SingletonIterator.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/SortSettings.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/SortingIterator.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/StepIterator.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/StripWhitespaceFilter.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/UnionIterator.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/dom/XSLTCDTMManager.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/javax.xml.transform.TransformerFactory - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/runtime/AbstractTranslet.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/runtime/Attributes.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/runtime/BasisLibrary.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/runtime/Constants.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_ca.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_cs.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_de.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_es.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_fr.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_it.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_ja.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_ko.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_pt_BR.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_sk.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_sv.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_zh_CN.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages_zh_TW.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/runtime/Hashtable.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/runtime/MessageHandler.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/runtime/Node.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/runtime/ObjectFactory.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/runtime/Operators.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/runtime/Parameter.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/runtime/SecuritySupport.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/runtime/SecuritySupport12.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/runtime/StringValueHandler.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/runtime/output/OutputBuffer.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/runtime/output/StringOutputBuffer.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/runtime/output/TransletOutputHandlerFactory.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/runtime/output/WriterOutputBuffer.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/DOM2SAX.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/DOM2TO.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/ObjectFactory.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/OutputSettings.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/SAX2DOM.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/SAX2StAXBaseWriter.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/SAX2StAXEventWriter.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/SAX2StAXStreamWriter.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/SecuritySupport.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/SecuritySupport12.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/SmartTransformerFactoryImpl.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/StAXEvent2SAX.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/StAXStream2SAX.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/TemplatesHandlerImpl.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/TemplatesImpl.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/TrAXFilter.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/TransformerFactoryImpl.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/TransformerHandlerImpl.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/TransformerImpl.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/Util.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/XSLTCSource.java - src/share/classes/com/sun/org/apache/xalan/internal/xsltc/util/IntegerArray.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/AttrImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/AttrNSImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/AttributeMap.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/CDATASectionImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/CharacterDataImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/ChildNode.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/CommentImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/CoreDOMImplementationImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/CoreDocumentImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/DOMConfigurationImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/DOMErrorImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/DOMImplementationImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/DOMImplementationListImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/DOMImplementationSourceImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/DOMInputImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/DOMLocatorImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/DOMMessageFormatter.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/DOMNormalizer.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/DOMOutputImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/DOMStringListImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/DOMXSImplementationSourceImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/DeepNodeListImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/DeferredAttrImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/DeferredAttrNSImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/DeferredCDATASectionImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/DeferredCommentImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/DeferredDOMImplementationImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/DeferredDocumentImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/DeferredDocumentTypeImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/DeferredElementDefinitionImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/DeferredElementImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/DeferredElementNSImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/DeferredEntityImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/DeferredEntityReferenceImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/DeferredNode.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/DeferredNotationImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/DeferredProcessingInstructionImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/DeferredTextImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/DocumentFragmentImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/DocumentImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/DocumentTypeImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/ElementDefinitionImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/ElementImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/ElementNSImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/EntityImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/EntityReferenceImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/LCount.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/NamedNodeMapImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/NodeImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/NodeIteratorImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/NodeListCache.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/NotationImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/ObjectFactory.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/PSVIAttrNSImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/PSVIDOMImplementationImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/PSVIDocumentImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/PSVIElementNSImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/ParentNode.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/ProcessingInstructionImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/RangeExceptionImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/RangeImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/SecuritySupport.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/TextImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/TreeWalkerImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/events/EventImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/events/MutationEventImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/dom/org.apache.xerces.dom.DOMImplementationSourceImpl - src/share/classes/com/sun/org/apache/xerces/internal/dom/org.w3c.dom.DOMImplementationSourceList - src/share/classes/com/sun/org/apache/xerces/internal/impl/Constants.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/ExternalSubsetResolver.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/PropertyManager.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/RevalidationHandler.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/Version.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/XML11DTDScannerImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/XML11DocumentScannerImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/XML11EntityScanner.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/XML11NSDocumentScannerImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/XML11NamespaceBinder.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/XMLDTDScannerImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/XMLDocumentFragmentScannerImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/XMLDocumentScannerImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/XMLEntityDescription.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/XMLEntityHandler.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/XMLEntityManager.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/XMLEntityScanner.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/XMLErrorReporter.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/XMLNSDocumentScannerImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/XMLNamespaceBinder.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/XMLStreamFilterImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/XMLStreamReaderImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/XMLVersionDetector.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dtd/BalancedDTDGrammar.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dtd/DTDGrammar.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dtd/DTDGrammarBucket.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dtd/XML11DTDProcessor.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dtd/XML11DTDValidator.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dtd/XML11NSDTDValidator.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dtd/XMLAttributeDecl.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dtd/XMLContentSpec.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dtd/XMLDTDDescription.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dtd/XMLDTDLoader.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dtd/XMLDTDProcessor.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dtd/XMLDTDValidator.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dtd/XMLDTDValidatorFilter.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dtd/XMLElementDecl.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dtd/XMLEntityDecl.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dtd/XMLNSDTDValidator.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dtd/XMLNotationDecl.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dtd/XMLSimpleType.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dtd/models/CMAny.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dtd/models/CMBinOp.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dtd/models/CMLeaf.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dtd/models/CMNode.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dtd/models/CMStateSet.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dtd/models/CMUniOp.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dtd/models/ContentModelValidator.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dtd/models/DFAContentModel.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dtd/models/MixedContentModel.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dtd/models/SimpleContentModel.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/DTDDVFactory.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/DVFactoryException.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/DatatypeException.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/DatatypeValidator.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/InvalidDatatypeFacetException.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/InvalidDatatypeValueException.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/ObjectFactory.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/SchemaDVFactory.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/SecuritySupport.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/ValidatedInfo.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/ValidationContext.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/XSFacets.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/XSSimpleType.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/dtd/DTDDVFactoryImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/dtd/ENTITYDatatypeValidator.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/dtd/IDDatatypeValidator.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/dtd/IDREFDatatypeValidator.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/dtd/ListDatatypeValidator.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/dtd/NMTOKENDatatypeValidator.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/dtd/NOTATIONDatatypeValidator.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/dtd/StringDatatypeValidator.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/dtd/XML11DTDDVFactoryImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/dtd/XML11IDDatatypeValidator.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/dtd/XML11IDREFDatatypeValidator.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/dtd/XML11NMTOKENDatatypeValidator.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/util/Base64.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/util/ByteListImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/util/HexBin.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/xs/AbstractDateTimeDV.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/xs/AnyAtomicDV.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/xs/AnySimpleDV.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/xs/AnyURIDV.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/xs/Base64BinaryDV.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/xs/BaseDVFactory.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/xs/BaseSchemaDVFactory.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/xs/BooleanDV.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/xs/DateDV.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/xs/DateTimeDV.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/xs/DayDV.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/xs/DayTimeDurationDV.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/xs/DecimalDV.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/xs/DoubleDV.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/xs/DurationDV.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/xs/EntityDV.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/xs/ExtendedSchemaDVFactoryImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/xs/FloatDV.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/xs/FullDVFactory.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/xs/HexBinaryDV.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/xs/IDDV.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/xs/IDREFDV.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/xs/IntegerDV.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/xs/ListDV.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/xs/MonthDV.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/xs/MonthDayDV.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/xs/PrecisionDecimalDV.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/xs/QNameDV.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/xs/SchemaDVFactoryImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/xs/SchemaDateTimeException.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/xs/StringDV.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/xs/TimeDV.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/xs/TypeValidator.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/xs/UnionDV.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/xs/XSSimpleTypeDecl.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/xs/XSSimpleTypeDelegate.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/xs/YearDV.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/xs/YearMonthDV.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/dv/xs/YearMonthDurationDV.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/io/ASCIIReader.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/io/MalformedByteSequenceException.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/io/UCSReader.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/io/UTF8Reader.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_de.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_es.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_fr.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_it.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_ja.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_ko.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_pt_BR.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_sv.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_zh_CN.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DOMMessages_zh_TW.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DatatypeMessages.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DatatypeMessages_de.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DatatypeMessages_es.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DatatypeMessages_fr.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DatatypeMessages_it.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DatatypeMessages_ja.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DatatypeMessages_ko.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DatatypeMessages_pt_BR.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DatatypeMessages_sv.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DatatypeMessages_zh_CN.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/DatatypeMessages_zh_TW.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/JAXPValidationMessages.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/JAXPValidationMessages_de.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/JAXPValidationMessages_es.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/JAXPValidationMessages_fr.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/JAXPValidationMessages_it.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/JAXPValidationMessages_ja.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/JAXPValidationMessages_ko.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/JAXPValidationMessages_pt_BR.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/JAXPValidationMessages_sv.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/JAXPValidationMessages_zh_CN.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/JAXPValidationMessages_zh_TW.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_de.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_es.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_fr.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_it.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_ja.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_ko.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_pt_BR.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_sv.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_zh_CN.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/SAXMessages_zh_TW.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_de.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_es.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_fr.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_it.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_ja.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_ko.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_pt_BR.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_sv.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_zh_CN.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XIncludeMessages_zh_TW.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessageFormatter.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessageFormatter_de.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessageFormatter_es.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessageFormatter_fr.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessageFormatter_it.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessageFormatter_ja.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessageFormatter_ko.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessageFormatter_pt_BR.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessageFormatter_sv.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessageFormatter_zh_CN.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessageFormatter_zh_TW.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_de.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_es.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_fr.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_it.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_ja.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_ko.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_pt_BR.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_sv.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_zh_CN.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLMessages_zh_TW.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_de.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_es.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_fr.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_it.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_ja.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_ko.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_pt_BR.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_sv.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_zh_CN.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSchemaMessages_zh_TW.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSerializerMessages.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSerializerMessages_de.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSerializerMessages_es.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSerializerMessages_fr.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSerializerMessages_it.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSerializerMessages_ja.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSerializerMessages_ko.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSerializerMessages_pt_BR.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSerializerMessages_sv.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSerializerMessages_zh_CN.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XMLSerializerMessages_zh_TW.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_de.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_es.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_fr.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_it.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_ja.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_ko.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_pt_BR.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_sv.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_zh_CN.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/msg/XPointerMessages_zh_TW.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/validation/EntityState.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/validation/ValidationManager.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/validation/ValidationState.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xpath/XPath.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xpath/XPathException.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xpath/regex/BMPattern.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xpath/regex/CaseInsensitiveMap.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xpath/regex/Match.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xpath/regex/Op.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xpath/regex/ParseException.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xpath/regex/ParserForXMLSchema.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xpath/regex/REUtil.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xpath/regex/RangeToken.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xpath/regex/RegexParser.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xpath/regex/RegularExpression.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xpath/regex/Token.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xpath/regex/message.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/xpath/regex/message_fr.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/xpath/regex/message_ja.properties - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/AttributePSVImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/ElementPSVImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/SchemaGrammar.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/SchemaNamespaceSupport.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/SchemaSymbols.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/SubstitutionGroupHandler.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/XMLSchemaException.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/XMLSchemaLoader.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/XMLSchemaValidator.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/XSAnnotationImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/XSAttributeDecl.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/XSAttributeGroupDecl.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/XSAttributeUseImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/XSComplexTypeDecl.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/XSConstraints.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/XSDDescription.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/XSDeclarationPool.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/XSElementDecl.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/XSGrammarBucket.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/XSGroupDecl.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/XSImplementationImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/XSLoaderImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/XSMessageFormatter.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/XSModelGroupImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/XSModelImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/XSNotationDecl.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/XSParticleDecl.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/XSWildcardDecl.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/identity/Field.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/identity/FieldActivator.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/identity/IdentityConstraint.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/identity/KeyRef.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/identity/Selector.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/identity/UniqueOrKey.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/identity/ValueStore.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/identity/XPathMatcher.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/models/CMBuilder.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/models/CMNodeFactory.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/models/XSAllCM.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/models/XSCMBinOp.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/models/XSCMLeaf.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/models/XSCMRepeatingLeaf.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/models/XSCMUniOp.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/models/XSCMValidator.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/models/XSDFACM.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/models/XSEmptyCM.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/opti/AttrImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/opti/DefaultDocument.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/opti/DefaultElement.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/opti/DefaultNode.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/opti/DefaultText.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/opti/DefaultXMLDocumentHandler.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/opti/ElementImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/opti/NamedNodeMapImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/opti/NodeImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/opti/SchemaDOM.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/opti/SchemaDOMImplementation.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/opti/SchemaDOMParser.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/opti/SchemaParsingConfig.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/opti/TextImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/traversers/SchemaContentHandler.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/traversers/StAXSchemaParser.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/traversers/XSAnnotationInfo.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/traversers/XSAttributeChecker.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/traversers/XSDAbstractIDConstraintTraverser.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/traversers/XSDAbstractParticleTraverser.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/traversers/XSDAbstractTraverser.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/traversers/XSDAttributeGroupTraverser.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/traversers/XSDAttributeTraverser.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/traversers/XSDComplexTypeTraverser.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/traversers/XSDElementTraverser.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/traversers/XSDGroupTraverser.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/traversers/XSDHandler.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/traversers/XSDKeyrefTraverser.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/traversers/XSDNotationTraverser.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/traversers/XSDSimpleTypeTraverser.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/traversers/XSDUniqueOrKeyTraverser.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/traversers/XSDWildcardTraverser.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/traversers/XSDocumentInfo.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/util/LSInputListImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/util/ObjectListImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/util/ShortListImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/util/SimpleLocator.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/util/StringListImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/util/XInt.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/util/XIntPool.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/util/XSGrammarPool.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/util/XSInputSource.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/util/XSNamedMap4Types.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/util/XSNamedMapImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/impl/xs/util/XSObjectListImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/jaxp/DefaultValidationErrorHandler.java - src/share/classes/com/sun/org/apache/xerces/internal/jaxp/DocumentBuilderFactoryImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/jaxp/DocumentBuilderImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/jaxp/JAXPConstants.java - src/share/classes/com/sun/org/apache/xerces/internal/jaxp/JAXPValidatorComponent.java - src/share/classes/com/sun/org/apache/xerces/internal/jaxp/SAXParserFactoryImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/jaxp/SAXParserImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/jaxp/SchemaValidatorConfiguration.java - src/share/classes/com/sun/org/apache/xerces/internal/jaxp/TeeXMLDocumentFilterImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/jaxp/UnparsedEntityHandler.java - src/share/classes/com/sun/org/apache/xerces/internal/jaxp/datatype/DatatypeFactoryImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/jaxp/datatype/DurationDayTimeImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/jaxp/datatype/DurationImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/jaxp/datatype/DurationYearMonthImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/jaxp/datatype/XMLGregorianCalendarImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/jaxp/datatype/javax.xml.datatype.DatatypeFactory - src/share/classes/com/sun/org/apache/xerces/internal/jaxp/javax.xml.parsers.DocumentBuilderFactory - src/share/classes/com/sun/org/apache/xerces/internal/jaxp/javax.xml.parsers.SAXParserFactory - src/share/classes/com/sun/org/apache/xerces/internal/jaxp/validation/AbstractXMLSchema.java - src/share/classes/com/sun/org/apache/xerces/internal/jaxp/validation/DOMDocumentHandler.java - src/share/classes/com/sun/org/apache/xerces/internal/jaxp/validation/DOMResultAugmentor.java - src/share/classes/com/sun/org/apache/xerces/internal/jaxp/validation/DOMResultBuilder.java - src/share/classes/com/sun/org/apache/xerces/internal/jaxp/validation/DOMValidatorHelper.java - src/share/classes/com/sun/org/apache/xerces/internal/jaxp/validation/DraconianErrorHandler.java - src/share/classes/com/sun/org/apache/xerces/internal/jaxp/validation/EmptyXMLSchema.java - src/share/classes/com/sun/org/apache/xerces/internal/jaxp/validation/ErrorHandlerAdaptor.java - src/share/classes/com/sun/org/apache/xerces/internal/jaxp/validation/JAXPValidationMessageFormatter.java - src/share/classes/com/sun/org/apache/xerces/internal/jaxp/validation/ReadOnlyGrammarPool.java - src/share/classes/com/sun/org/apache/xerces/internal/jaxp/validation/SimpleXMLSchema.java - src/share/classes/com/sun/org/apache/xerces/internal/jaxp/validation/SoftReferenceGrammarPool.java - src/share/classes/com/sun/org/apache/xerces/internal/jaxp/validation/StAXValidatorHelper.java - src/share/classes/com/sun/org/apache/xerces/internal/jaxp/validation/StreamValidatorHelper.java - src/share/classes/com/sun/org/apache/xerces/internal/jaxp/validation/Util.java - src/share/classes/com/sun/org/apache/xerces/internal/jaxp/validation/ValidatorHandlerImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/jaxp/validation/ValidatorHelper.java - src/share/classes/com/sun/org/apache/xerces/internal/jaxp/validation/ValidatorImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/jaxp/validation/WeakReferenceXMLSchema.java - src/share/classes/com/sun/org/apache/xerces/internal/jaxp/validation/WrappedSAXException.java - src/share/classes/com/sun/org/apache/xerces/internal/jaxp/validation/XMLSchema.java - src/share/classes/com/sun/org/apache/xerces/internal/jaxp/validation/XMLSchemaFactory.java - src/share/classes/com/sun/org/apache/xerces/internal/jaxp/validation/XMLSchemaValidatorComponentManager.java - src/share/classes/com/sun/org/apache/xerces/internal/jaxp/validation/XSGrammarPoolContainer.java - src/share/classes/com/sun/org/apache/xerces/internal/jaxp/validation/javax.xml.validation.SchemaFactory - src/share/classes/com/sun/org/apache/xerces/internal/parsers/AbstractDOMParser.java - src/share/classes/com/sun/org/apache/xerces/internal/parsers/AbstractSAXParser.java - src/share/classes/com/sun/org/apache/xerces/internal/parsers/AbstractXMLDocumentParser.java - src/share/classes/com/sun/org/apache/xerces/internal/parsers/BasicParserConfiguration.java - src/share/classes/com/sun/org/apache/xerces/internal/parsers/CachingParserPool.java - src/share/classes/com/sun/org/apache/xerces/internal/parsers/DOMParser.java - src/share/classes/com/sun/org/apache/xerces/internal/parsers/DOMParserImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/parsers/DTDConfiguration.java - src/share/classes/com/sun/org/apache/xerces/internal/parsers/DTDParser.java - src/share/classes/com/sun/org/apache/xerces/internal/parsers/IntegratedParserConfiguration.java - src/share/classes/com/sun/org/apache/xerces/internal/parsers/NonValidatingConfiguration.java - src/share/classes/com/sun/org/apache/xerces/internal/parsers/ObjectFactory.java - src/share/classes/com/sun/org/apache/xerces/internal/parsers/SAXParser.java - src/share/classes/com/sun/org/apache/xerces/internal/parsers/SecurityConfiguration.java - src/share/classes/com/sun/org/apache/xerces/internal/parsers/SecuritySupport.java - src/share/classes/com/sun/org/apache/xerces/internal/parsers/StandardParserConfiguration.java - src/share/classes/com/sun/org/apache/xerces/internal/parsers/XIncludeAwareParserConfiguration.java - src/share/classes/com/sun/org/apache/xerces/internal/parsers/XIncludeParserConfiguration.java - src/share/classes/com/sun/org/apache/xerces/internal/parsers/XML11Configurable.java - src/share/classes/com/sun/org/apache/xerces/internal/parsers/XML11Configuration.java - src/share/classes/com/sun/org/apache/xerces/internal/parsers/XML11DTDConfiguration.java - src/share/classes/com/sun/org/apache/xerces/internal/parsers/XML11NonValidatingConfiguration.java - src/share/classes/com/sun/org/apache/xerces/internal/parsers/XMLDocumentParser.java - src/share/classes/com/sun/org/apache/xerces/internal/parsers/XMLGrammarCachingConfiguration.java - src/share/classes/com/sun/org/apache/xerces/internal/parsers/XMLGrammarParser.java - src/share/classes/com/sun/org/apache/xerces/internal/parsers/XMLGrammarPreparser.java - src/share/classes/com/sun/org/apache/xerces/internal/parsers/XMLParser.java - src/share/classes/com/sun/org/apache/xerces/internal/parsers/XPointerParserConfiguration.java - src/share/classes/com/sun/org/apache/xerces/internal/parsers/org.apache.xerces.xni.parser.DTDConfiguration - src/share/classes/com/sun/org/apache/xerces/internal/parsers/org.apache.xerces.xni.parser.XML11Configuration - src/share/classes/com/sun/org/apache/xerces/internal/parsers/org.apache.xerces.xni.parser.XMLParserConfiguration - src/share/classes/com/sun/org/apache/xerces/internal/parsers/org.xml.sax.driver - src/share/classes/com/sun/org/apache/xerces/internal/util/AttributesProxy.java - src/share/classes/com/sun/org/apache/xerces/internal/util/AugmentationsImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/util/DOMEntityResolverWrapper.java - src/share/classes/com/sun/org/apache/xerces/internal/util/DOMErrorHandlerWrapper.java - src/share/classes/com/sun/org/apache/xerces/internal/util/DOMInputSource.java - src/share/classes/com/sun/org/apache/xerces/internal/util/DOMUtil.java - src/share/classes/com/sun/org/apache/xerces/internal/util/DatatypeMessageFormatter.java - src/share/classes/com/sun/org/apache/xerces/internal/util/DefaultErrorHandler.java - src/share/classes/com/sun/org/apache/xerces/internal/util/DraconianErrorHandler.java - src/share/classes/com/sun/org/apache/xerces/internal/util/EncodingMap.java - src/share/classes/com/sun/org/apache/xerces/internal/util/EntityResolver2Wrapper.java - src/share/classes/com/sun/org/apache/xerces/internal/util/EntityResolverWrapper.java - src/share/classes/com/sun/org/apache/xerces/internal/util/ErrorHandlerProxy.java - src/share/classes/com/sun/org/apache/xerces/internal/util/ErrorHandlerWrapper.java - src/share/classes/com/sun/org/apache/xerces/internal/util/FeatureState.java - src/share/classes/com/sun/org/apache/xerces/internal/util/HTTPInputSource.java - src/share/classes/com/sun/org/apache/xerces/internal/util/IntStack.java - src/share/classes/com/sun/org/apache/xerces/internal/util/JAXPNamespaceContextWrapper.java - src/share/classes/com/sun/org/apache/xerces/internal/util/LocatorProxy.java - src/share/classes/com/sun/org/apache/xerces/internal/util/LocatorWrapper.java - src/share/classes/com/sun/org/apache/xerces/internal/util/MessageFormatter.java - src/share/classes/com/sun/org/apache/xerces/internal/util/NamespaceContextWrapper.java - src/share/classes/com/sun/org/apache/xerces/internal/util/NamespaceSupport.java - src/share/classes/com/sun/org/apache/xerces/internal/util/ParserConfigurationSettings.java - src/share/classes/com/sun/org/apache/xerces/internal/util/PropertyState.java - src/share/classes/com/sun/org/apache/xerces/internal/util/SAX2XNI.java - src/share/classes/com/sun/org/apache/xerces/internal/util/SAXInputSource.java - src/share/classes/com/sun/org/apache/xerces/internal/util/SAXLocatorWrapper.java - src/share/classes/com/sun/org/apache/xerces/internal/util/SAXMessageFormatter.java - src/share/classes/com/sun/org/apache/xerces/internal/util/SecurityManager.java - src/share/classes/com/sun/org/apache/xerces/internal/util/ShadowedSymbolTable.java - src/share/classes/com/sun/org/apache/xerces/internal/util/StAXInputSource.java - src/share/classes/com/sun/org/apache/xerces/internal/util/StAXLocationWrapper.java - src/share/classes/com/sun/org/apache/xerces/internal/util/Status.java - src/share/classes/com/sun/org/apache/xerces/internal/util/SymbolHash.java - src/share/classes/com/sun/org/apache/xerces/internal/util/SymbolTable.java - src/share/classes/com/sun/org/apache/xerces/internal/util/SynchronizedSymbolTable.java - src/share/classes/com/sun/org/apache/xerces/internal/util/TeeXMLDocumentFilterImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/util/TypeInfoImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/util/URI.java - src/share/classes/com/sun/org/apache/xerces/internal/util/XML11Char.java - src/share/classes/com/sun/org/apache/xerces/internal/util/XMLAttributesImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/util/XMLAttributesIteratorImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/util/XMLCatalogResolver.java - src/share/classes/com/sun/org/apache/xerces/internal/util/XMLChar.java - src/share/classes/com/sun/org/apache/xerces/internal/util/XMLDocumentFilterImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/util/XMLEntityDescriptionImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/util/XMLErrorCode.java - src/share/classes/com/sun/org/apache/xerces/internal/util/XMLGrammarPoolImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/util/XMLInputSourceAdaptor.java - src/share/classes/com/sun/org/apache/xerces/internal/util/XMLResourceIdentifierImpl.java - src/share/classes/com/sun/org/apache/xerces/internal/util/XMLStringBuffer.java - src/share/classes/com/sun/org/apache/xerces/internal/util/XMLSymbols.java - src/share/classes/com/sun/org/apache/xerces/internal/xinclude/MultipleScopeNamespaceSupport.java - src/share/classes/com/sun/org/apache/xerces/internal/xinclude/ObjectFactory.java - src/share/classes/com/sun/org/apache/xerces/internal/xinclude/SecuritySupport.java - src/share/classes/com/sun/org/apache/xerces/internal/xinclude/XInclude11TextReader.java - src/share/classes/com/sun/org/apache/xerces/internal/xinclude/XIncludeHandler.java - src/share/classes/com/sun/org/apache/xerces/internal/xinclude/XIncludeMessageFormatter.java - src/share/classes/com/sun/org/apache/xerces/internal/xinclude/XIncludeNamespaceSupport.java - src/share/classes/com/sun/org/apache/xerces/internal/xinclude/XIncludeTextReader.java - src/share/classes/com/sun/org/apache/xerces/internal/xinclude/XPointerElementHandler.java - src/share/classes/com/sun/org/apache/xerces/internal/xinclude/XPointerFramework.java - src/share/classes/com/sun/org/apache/xerces/internal/xinclude/XPointerSchema.java - src/share/classes/com/sun/org/apache/xerces/internal/xni/Augmentations.java - src/share/classes/com/sun/org/apache/xerces/internal/xni/NamespaceContext.java - src/share/classes/com/sun/org/apache/xerces/internal/xni/QName.java - src/share/classes/com/sun/org/apache/xerces/internal/xni/XMLAttributes.java - src/share/classes/com/sun/org/apache/xerces/internal/xni/XMLDTDContentModelHandler.java - src/share/classes/com/sun/org/apache/xerces/internal/xni/XMLDTDHandler.java - src/share/classes/com/sun/org/apache/xerces/internal/xni/XMLDocumentFragmentHandler.java - src/share/classes/com/sun/org/apache/xerces/internal/xni/XMLDocumentHandler.java - src/share/classes/com/sun/org/apache/xerces/internal/xni/XMLLocator.java - src/share/classes/com/sun/org/apache/xerces/internal/xni/XMLResourceIdentifier.java - src/share/classes/com/sun/org/apache/xerces/internal/xni/XMLString.java - src/share/classes/com/sun/org/apache/xerces/internal/xni/XNIException.java - src/share/classes/com/sun/org/apache/xerces/internal/xni/grammars/Grammar.java - src/share/classes/com/sun/org/apache/xerces/internal/xni/grammars/XMLDTDDescription.java - src/share/classes/com/sun/org/apache/xerces/internal/xni/grammars/XMLGrammarDescription.java - src/share/classes/com/sun/org/apache/xerces/internal/xni/grammars/XMLGrammarLoader.java - src/share/classes/com/sun/org/apache/xerces/internal/xni/grammars/XMLGrammarPool.java - src/share/classes/com/sun/org/apache/xerces/internal/xni/grammars/XMLSchemaDescription.java - src/share/classes/com/sun/org/apache/xerces/internal/xni/grammars/XSGrammar.java - src/share/classes/com/sun/org/apache/xerces/internal/xni/parser/XMLComponent.java - src/share/classes/com/sun/org/apache/xerces/internal/xni/parser/XMLComponentManager.java - src/share/classes/com/sun/org/apache/xerces/internal/xni/parser/XMLConfigurationException.java - src/share/classes/com/sun/org/apache/xerces/internal/xni/parser/XMLDTDContentModelFilter.java - src/share/classes/com/sun/org/apache/xerces/internal/xni/parser/XMLDTDContentModelSource.java - src/share/classes/com/sun/org/apache/xerces/internal/xni/parser/XMLDTDFilter.java - src/share/classes/com/sun/org/apache/xerces/internal/xni/parser/XMLDTDScanner.java - src/share/classes/com/sun/org/apache/xerces/internal/xni/parser/XMLDTDSource.java - src/share/classes/com/sun/org/apache/xerces/internal/xni/parser/XMLDocumentFilter.java - src/share/classes/com/sun/org/apache/xerces/internal/xni/parser/XMLDocumentScanner.java - src/share/classes/com/sun/org/apache/xerces/internal/xni/parser/XMLDocumentSource.java - src/share/classes/com/sun/org/apache/xerces/internal/xni/parser/XMLEntityResolver.java - src/share/classes/com/sun/org/apache/xerces/internal/xni/parser/XMLErrorHandler.java - src/share/classes/com/sun/org/apache/xerces/internal/xni/parser/XMLInputSource.java - src/share/classes/com/sun/org/apache/xerces/internal/xni/parser/XMLParseException.java - src/share/classes/com/sun/org/apache/xerces/internal/xni/parser/XMLParserConfiguration.java - src/share/classes/com/sun/org/apache/xerces/internal/xni/parser/XMLPullParserConfiguration.java - src/share/classes/com/sun/org/apache/xerces/internal/xpointer/ElementSchemePointer.java - src/share/classes/com/sun/org/apache/xerces/internal/xpointer/ShortHandPointer.java - src/share/classes/com/sun/org/apache/xerces/internal/xpointer/XPointerErrorHandler.java - src/share/classes/com/sun/org/apache/xerces/internal/xpointer/XPointerHandler.java - src/share/classes/com/sun/org/apache/xerces/internal/xpointer/XPointerMessageFormatter.java - src/share/classes/com/sun/org/apache/xerces/internal/xpointer/XPointerPart.java - src/share/classes/com/sun/org/apache/xerces/internal/xpointer/XPointerProcessor.java - src/share/classes/com/sun/org/apache/xerces/internal/xs/AttributePSVI.java - src/share/classes/com/sun/org/apache/xerces/internal/xs/ElementPSVI.java - src/share/classes/com/sun/org/apache/xerces/internal/xs/ItemPSVI.java - src/share/classes/com/sun/org/apache/xerces/internal/xs/LSInputList.java - src/share/classes/com/sun/org/apache/xerces/internal/xs/PSVIProvider.java - src/share/classes/com/sun/org/apache/xerces/internal/xs/ShortList.java - src/share/classes/com/sun/org/apache/xerces/internal/xs/StringList.java - src/share/classes/com/sun/org/apache/xerces/internal/xs/XSAnnotation.java - src/share/classes/com/sun/org/apache/xerces/internal/xs/XSAttributeDeclaration.java - src/share/classes/com/sun/org/apache/xerces/internal/xs/XSAttributeGroupDefinition.java - src/share/classes/com/sun/org/apache/xerces/internal/xs/XSAttributeUse.java - src/share/classes/com/sun/org/apache/xerces/internal/xs/XSComplexTypeDefinition.java - src/share/classes/com/sun/org/apache/xerces/internal/xs/XSConstants.java - src/share/classes/com/sun/org/apache/xerces/internal/xs/XSElementDeclaration.java - src/share/classes/com/sun/org/apache/xerces/internal/xs/XSException.java - src/share/classes/com/sun/org/apache/xerces/internal/xs/XSFacet.java - src/share/classes/com/sun/org/apache/xerces/internal/xs/XSIDCDefinition.java - src/share/classes/com/sun/org/apache/xerces/internal/xs/XSImplementation.java - src/share/classes/com/sun/org/apache/xerces/internal/xs/XSLoader.java - src/share/classes/com/sun/org/apache/xerces/internal/xs/XSModel.java - src/share/classes/com/sun/org/apache/xerces/internal/xs/XSModelGroup.java - src/share/classes/com/sun/org/apache/xerces/internal/xs/XSModelGroupDefinition.java - src/share/classes/com/sun/org/apache/xerces/internal/xs/XSMultiValueFacet.java - src/share/classes/com/sun/org/apache/xerces/internal/xs/XSNamedMap.java - src/share/classes/com/sun/org/apache/xerces/internal/xs/XSNamespaceItem.java - src/share/classes/com/sun/org/apache/xerces/internal/xs/XSNamespaceItemList.java - src/share/classes/com/sun/org/apache/xerces/internal/xs/XSNotationDeclaration.java - src/share/classes/com/sun/org/apache/xerces/internal/xs/XSObject.java - src/share/classes/com/sun/org/apache/xerces/internal/xs/XSObjectList.java - src/share/classes/com/sun/org/apache/xerces/internal/xs/XSParticle.java - src/share/classes/com/sun/org/apache/xerces/internal/xs/XSSimpleTypeDefinition.java - src/share/classes/com/sun/org/apache/xerces/internal/xs/XSTerm.java - src/share/classes/com/sun/org/apache/xerces/internal/xs/XSTypeDefinition.java - src/share/classes/com/sun/org/apache/xerces/internal/xs/XSWildcard.java - src/share/classes/com/sun/org/apache/xerces/internal/xs/datatypes/ByteList.java - src/share/classes/com/sun/org/apache/xerces/internal/xs/datatypes/ObjectList.java - src/share/classes/com/sun/org/apache/xerces/internal/xs/datatypes/XSDateTime.java - src/share/classes/com/sun/org/apache/xerces/internal/xs/datatypes/XSDecimal.java - src/share/classes/com/sun/org/apache/xerces/internal/xs/datatypes/XSDouble.java - src/share/classes/com/sun/org/apache/xerces/internal/xs/datatypes/XSFloat.java - src/share/classes/com/sun/org/apache/xerces/internal/xs/datatypes/XSQName.java - src/share/classes/com/sun/org/apache/xerces/internal/xs/datatypes/package.html - src/share/classes/com/sun/org/apache/xml/internal/dtm/Axis.java - src/share/classes/com/sun/org/apache/xml/internal/dtm/DTM.java - src/share/classes/com/sun/org/apache/xml/internal/dtm/DTMAxisIterator.java - src/share/classes/com/sun/org/apache/xml/internal/dtm/DTMAxisTraverser.java - src/share/classes/com/sun/org/apache/xml/internal/dtm/DTMConfigurationException.java - src/share/classes/com/sun/org/apache/xml/internal/dtm/DTMDOMException.java - src/share/classes/com/sun/org/apache/xml/internal/dtm/DTMException.java - src/share/classes/com/sun/org/apache/xml/internal/dtm/DTMFilter.java - src/share/classes/com/sun/org/apache/xml/internal/dtm/DTMIterator.java - src/share/classes/com/sun/org/apache/xml/internal/dtm/DTMManager.java - src/share/classes/com/sun/org/apache/xml/internal/dtm/DTMWSFilter.java - src/share/classes/com/sun/org/apache/xml/internal/dtm/ObjectFactory.java - src/share/classes/com/sun/org/apache/xml/internal/dtm/SecuritySupport.java - src/share/classes/com/sun/org/apache/xml/internal/dtm/SecuritySupport12.java - src/share/classes/com/sun/org/apache/xml/internal/dtm/ref/ChunkedIntArray.java - src/share/classes/com/sun/org/apache/xml/internal/dtm/ref/CoroutineManager.java - src/share/classes/com/sun/org/apache/xml/internal/dtm/ref/CoroutineParser.java - src/share/classes/com/sun/org/apache/xml/internal/dtm/ref/CustomStringPool.java - src/share/classes/com/sun/org/apache/xml/internal/dtm/ref/DTMAxisIterNodeList.java - src/share/classes/com/sun/org/apache/xml/internal/dtm/ref/DTMAxisIteratorBase.java - src/share/classes/com/sun/org/apache/xml/internal/dtm/ref/DTMChildIterNodeList.java - src/share/classes/com/sun/org/apache/xml/internal/dtm/ref/DTMDefaultBase.java - src/share/classes/com/sun/org/apache/xml/internal/dtm/ref/DTMDefaultBaseIterators.java - src/share/classes/com/sun/org/apache/xml/internal/dtm/ref/DTMDefaultBaseTraversers.java - src/share/classes/com/sun/org/apache/xml/internal/dtm/ref/DTMDocumentImpl.java - src/share/classes/com/sun/org/apache/xml/internal/dtm/ref/DTMManagerDefault.java - src/share/classes/com/sun/org/apache/xml/internal/dtm/ref/DTMNamedNodeMap.java - src/share/classes/com/sun/org/apache/xml/internal/dtm/ref/DTMNodeIterator.java - src/share/classes/com/sun/org/apache/xml/internal/dtm/ref/DTMNodeList.java - src/share/classes/com/sun/org/apache/xml/internal/dtm/ref/DTMNodeListBase.java - src/share/classes/com/sun/org/apache/xml/internal/dtm/ref/DTMNodeProxy.java - src/share/classes/com/sun/org/apache/xml/internal/dtm/ref/DTMSafeStringPool.java - src/share/classes/com/sun/org/apache/xml/internal/dtm/ref/DTMStringPool.java - src/share/classes/com/sun/org/apache/xml/internal/dtm/ref/DTMTreeWalker.java - src/share/classes/com/sun/org/apache/xml/internal/dtm/ref/EmptyIterator.java - src/share/classes/com/sun/org/apache/xml/internal/dtm/ref/ExpandedNameTable.java - src/share/classes/com/sun/org/apache/xml/internal/dtm/ref/ExtendedType.java - src/share/classes/com/sun/org/apache/xml/internal/dtm/ref/IncrementalSAXSource.java - src/share/classes/com/sun/org/apache/xml/internal/dtm/ref/IncrementalSAXSource_Filter.java - src/share/classes/com/sun/org/apache/xml/internal/dtm/ref/IncrementalSAXSource_Xerces.java - src/share/classes/com/sun/org/apache/xml/internal/dtm/ref/NodeLocator.java - src/share/classes/com/sun/org/apache/xml/internal/dtm/ref/ObjectFactory.java - src/share/classes/com/sun/org/apache/xml/internal/dtm/ref/SecuritySupport.java - src/share/classes/com/sun/org/apache/xml/internal/dtm/ref/SecuritySupport12.java - src/share/classes/com/sun/org/apache/xml/internal/dtm/ref/dom2dtm/DOM2DTM.java - src/share/classes/com/sun/org/apache/xml/internal/dtm/ref/dom2dtm/DOM2DTMdefaultNamespaceDeclarationNode.java - src/share/classes/com/sun/org/apache/xml/internal/dtm/ref/sax2dtm/SAX2DTM.java - src/share/classes/com/sun/org/apache/xml/internal/dtm/ref/sax2dtm/SAX2DTM2.java - src/share/classes/com/sun/org/apache/xml/internal/dtm/ref/sax2dtm/SAX2RTFDTM.java - src/share/classes/com/sun/org/apache/xml/internal/res/XMLErrorResources.java - src/share/classes/com/sun/org/apache/xml/internal/res/XMLErrorResources_ca.java - src/share/classes/com/sun/org/apache/xml/internal/res/XMLErrorResources_cs.java - src/share/classes/com/sun/org/apache/xml/internal/res/XMLErrorResources_de.java - src/share/classes/com/sun/org/apache/xml/internal/res/XMLErrorResources_en.java - src/share/classes/com/sun/org/apache/xml/internal/res/XMLErrorResources_es.java - src/share/classes/com/sun/org/apache/xml/internal/res/XMLErrorResources_fr.java - src/share/classes/com/sun/org/apache/xml/internal/res/XMLErrorResources_it.java - src/share/classes/com/sun/org/apache/xml/internal/res/XMLErrorResources_ja.java - src/share/classes/com/sun/org/apache/xml/internal/res/XMLErrorResources_ko.java - src/share/classes/com/sun/org/apache/xml/internal/res/XMLErrorResources_pt_BR.java - src/share/classes/com/sun/org/apache/xml/internal/res/XMLErrorResources_sk.java - src/share/classes/com/sun/org/apache/xml/internal/res/XMLErrorResources_sv.java - src/share/classes/com/sun/org/apache/xml/internal/res/XMLErrorResources_tr.java - src/share/classes/com/sun/org/apache/xml/internal/res/XMLErrorResources_zh_CN.java - src/share/classes/com/sun/org/apache/xml/internal/res/XMLErrorResources_zh_HK.java - src/share/classes/com/sun/org/apache/xml/internal/res/XMLErrorResources_zh_TW.java - src/share/classes/com/sun/org/apache/xml/internal/res/XMLMessages.java - src/share/classes/com/sun/org/apache/xml/internal/resolver/Catalog.java - src/share/classes/com/sun/org/apache/xml/internal/resolver/CatalogEntry.java - src/share/classes/com/sun/org/apache/xml/internal/resolver/CatalogException.java - src/share/classes/com/sun/org/apache/xml/internal/resolver/CatalogManager.java - src/share/classes/com/sun/org/apache/xml/internal/resolver/Resolver.java - src/share/classes/com/sun/org/apache/xml/internal/resolver/helpers/BootstrapResolver.java - src/share/classes/com/sun/org/apache/xml/internal/resolver/helpers/Debug.java - src/share/classes/com/sun/org/apache/xml/internal/resolver/helpers/FileURL.java - src/share/classes/com/sun/org/apache/xml/internal/resolver/helpers/Namespaces.java - src/share/classes/com/sun/org/apache/xml/internal/resolver/helpers/PublicId.java - src/share/classes/com/sun/org/apache/xml/internal/resolver/readers/CatalogReader.java - src/share/classes/com/sun/org/apache/xml/internal/resolver/readers/DOMCatalogParser.java - src/share/classes/com/sun/org/apache/xml/internal/resolver/readers/DOMCatalogReader.java - src/share/classes/com/sun/org/apache/xml/internal/resolver/readers/ExtendedXMLCatalogReader.java - src/share/classes/com/sun/org/apache/xml/internal/resolver/readers/OASISXMLCatalogReader.java - src/share/classes/com/sun/org/apache/xml/internal/resolver/readers/SAXCatalogParser.java - src/share/classes/com/sun/org/apache/xml/internal/resolver/readers/SAXCatalogReader.java - src/share/classes/com/sun/org/apache/xml/internal/resolver/readers/SAXParserHandler.java - src/share/classes/com/sun/org/apache/xml/internal/resolver/readers/TR9401CatalogReader.java - src/share/classes/com/sun/org/apache/xml/internal/resolver/readers/TextCatalogReader.java - src/share/classes/com/sun/org/apache/xml/internal/resolver/readers/XCatalogReader.java - src/share/classes/com/sun/org/apache/xml/internal/resolver/tools/CatalogResolver.java - src/share/classes/com/sun/org/apache/xml/internal/resolver/tools/ResolvingParser.java - src/share/classes/com/sun/org/apache/xml/internal/resolver/tools/ResolvingXMLFilter.java - src/share/classes/com/sun/org/apache/xml/internal/resolver/tools/ResolvingXMLReader.java - src/share/classes/com/sun/org/apache/xml/internal/serialize/BaseMarkupSerializer.java - src/share/classes/com/sun/org/apache/xml/internal/serialize/DOMSerializer.java - src/share/classes/com/sun/org/apache/xml/internal/serialize/DOMSerializerImpl.java - src/share/classes/com/sun/org/apache/xml/internal/serialize/ElementState.java - src/share/classes/com/sun/org/apache/xml/internal/serialize/EncodingInfo.java - src/share/classes/com/sun/org/apache/xml/internal/serialize/Encodings.java - src/share/classes/com/sun/org/apache/xml/internal/serialize/HTMLEntities.res - src/share/classes/com/sun/org/apache/xml/internal/serialize/HTMLSerializer.java - src/share/classes/com/sun/org/apache/xml/internal/serialize/HTMLdtd.java - src/share/classes/com/sun/org/apache/xml/internal/serialize/IndentPrinter.java - src/share/classes/com/sun/org/apache/xml/internal/serialize/LineSeparator.java - src/share/classes/com/sun/org/apache/xml/internal/serialize/Method.java - src/share/classes/com/sun/org/apache/xml/internal/serialize/ObjectFactory.java - src/share/classes/com/sun/org/apache/xml/internal/serialize/OutputFormat.java - src/share/classes/com/sun/org/apache/xml/internal/serialize/Printer.java - src/share/classes/com/sun/org/apache/xml/internal/serialize/SecuritySupport.java - src/share/classes/com/sun/org/apache/xml/internal/serialize/Serializer.java - src/share/classes/com/sun/org/apache/xml/internal/serialize/SerializerFactory.java - src/share/classes/com/sun/org/apache/xml/internal/serialize/SerializerFactoryImpl.java - src/share/classes/com/sun/org/apache/xml/internal/serialize/TextSerializer.java - src/share/classes/com/sun/org/apache/xml/internal/serialize/XHTMLSerializer.java - src/share/classes/com/sun/org/apache/xml/internal/serialize/XML11Serializer.java - src/share/classes/com/sun/org/apache/xml/internal/serialize/XMLSerializer.java - src/share/classes/com/sun/org/apache/xml/internal/serializer/AttributesImplSerializer.java - src/share/classes/com/sun/org/apache/xml/internal/serializer/CharInfo.java - src/share/classes/com/sun/org/apache/xml/internal/serializer/DOMSerializer.java - src/share/classes/com/sun/org/apache/xml/internal/serializer/ElemContext.java - src/share/classes/com/sun/org/apache/xml/internal/serializer/ElemDesc.java - src/share/classes/com/sun/org/apache/xml/internal/serializer/EmptySerializer.java - src/share/classes/com/sun/org/apache/xml/internal/serializer/EncodingInfo.java - src/share/classes/com/sun/org/apache/xml/internal/serializer/Encodings.java - src/share/classes/com/sun/org/apache/xml/internal/serializer/Encodings.properties - src/share/classes/com/sun/org/apache/xml/internal/serializer/ExtendedContentHandler.java - src/share/classes/com/sun/org/apache/xml/internal/serializer/ExtendedLexicalHandler.java - src/share/classes/com/sun/org/apache/xml/internal/serializer/HTMLEntities.properties - src/share/classes/com/sun/org/apache/xml/internal/serializer/Method.java - src/share/classes/com/sun/org/apache/xml/internal/serializer/NamespaceMappings.java - src/share/classes/com/sun/org/apache/xml/internal/serializer/ObjectFactory.java - src/share/classes/com/sun/org/apache/xml/internal/serializer/OutputPropertiesFactory.java - src/share/classes/com/sun/org/apache/xml/internal/serializer/OutputPropertyUtils.java - src/share/classes/com/sun/org/apache/xml/internal/serializer/SecuritySupport.java - src/share/classes/com/sun/org/apache/xml/internal/serializer/SecuritySupport12.java - src/share/classes/com/sun/org/apache/xml/internal/serializer/SerializationHandler.java - src/share/classes/com/sun/org/apache/xml/internal/serializer/Serializer.java - src/share/classes/com/sun/org/apache/xml/internal/serializer/SerializerBase.java - src/share/classes/com/sun/org/apache/xml/internal/serializer/SerializerConstants.java - src/share/classes/com/sun/org/apache/xml/internal/serializer/SerializerFactory.java - src/share/classes/com/sun/org/apache/xml/internal/serializer/SerializerTrace.java - src/share/classes/com/sun/org/apache/xml/internal/serializer/SerializerTraceWriter.java - src/share/classes/com/sun/org/apache/xml/internal/serializer/ToHTMLSAXHandler.java - src/share/classes/com/sun/org/apache/xml/internal/serializer/ToHTMLStream.java - src/share/classes/com/sun/org/apache/xml/internal/serializer/ToSAXHandler.java - src/share/classes/com/sun/org/apache/xml/internal/serializer/ToStream.java - src/share/classes/com/sun/org/apache/xml/internal/serializer/ToTextSAXHandler.java - src/share/classes/com/sun/org/apache/xml/internal/serializer/ToTextStream.java - src/share/classes/com/sun/org/apache/xml/internal/serializer/ToUnknownStream.java - src/share/classes/com/sun/org/apache/xml/internal/serializer/ToXMLSAXHandler.java - src/share/classes/com/sun/org/apache/xml/internal/serializer/ToXMLStream.java - src/share/classes/com/sun/org/apache/xml/internal/serializer/TransformStateSetter.java - src/share/classes/com/sun/org/apache/xml/internal/serializer/TreeWalker.java - src/share/classes/com/sun/org/apache/xml/internal/serializer/Utils.java - src/share/classes/com/sun/org/apache/xml/internal/serializer/Version.java - src/share/classes/com/sun/org/apache/xml/internal/serializer/WriterChain.java - src/share/classes/com/sun/org/apache/xml/internal/serializer/WriterToASCI.java - src/share/classes/com/sun/org/apache/xml/internal/serializer/WriterToUTF8Buffered.java - src/share/classes/com/sun/org/apache/xml/internal/serializer/XMLEntities.properties - src/share/classes/com/sun/org/apache/xml/internal/serializer/XSLOutputAttributes.java - src/share/classes/com/sun/org/apache/xml/internal/serializer/output_html.properties - src/share/classes/com/sun/org/apache/xml/internal/serializer/output_text.properties - src/share/classes/com/sun/org/apache/xml/internal/serializer/output_unknown.properties - src/share/classes/com/sun/org/apache/xml/internal/serializer/output_xml.properties - src/share/classes/com/sun/org/apache/xml/internal/serializer/package.html - src/share/classes/com/sun/org/apache/xml/internal/serializer/utils/AttList.java - src/share/classes/com/sun/org/apache/xml/internal/serializer/utils/BoolStack.java - src/share/classes/com/sun/org/apache/xml/internal/serializer/utils/DOM2Helper.java - src/share/classes/com/sun/org/apache/xml/internal/serializer/utils/Messages.java - src/share/classes/com/sun/org/apache/xml/internal/serializer/utils/MsgKey.java - src/share/classes/com/sun/org/apache/xml/internal/serializer/utils/SerializerMessages.java - src/share/classes/com/sun/org/apache/xml/internal/serializer/utils/SerializerMessages_ca.java - src/share/classes/com/sun/org/apache/xml/internal/serializer/utils/SerializerMessages_cs.java - src/share/classes/com/sun/org/apache/xml/internal/serializer/utils/SerializerMessages_de.java - src/share/classes/com/sun/org/apache/xml/internal/serializer/utils/SerializerMessages_en.java - src/share/classes/com/sun/org/apache/xml/internal/serializer/utils/SerializerMessages_es.java - src/share/classes/com/sun/org/apache/xml/internal/serializer/utils/SerializerMessages_fr.java - src/share/classes/com/sun/org/apache/xml/internal/serializer/utils/SerializerMessages_it.java - src/share/classes/com/sun/org/apache/xml/internal/serializer/utils/SerializerMessages_ja.java - src/share/classes/com/sun/org/apache/xml/internal/serializer/utils/SerializerMessages_ko.java - src/share/classes/com/sun/org/apache/xml/internal/serializer/utils/SerializerMessages_sv.java - src/share/classes/com/sun/org/apache/xml/internal/serializer/utils/SerializerMessages_zh_CN.java - src/share/classes/com/sun/org/apache/xml/internal/serializer/utils/SerializerMessages_zh_TW.java - src/share/classes/com/sun/org/apache/xml/internal/serializer/utils/StringToIntTable.java - src/share/classes/com/sun/org/apache/xml/internal/serializer/utils/SystemIDResolver.java - src/share/classes/com/sun/org/apache/xml/internal/serializer/utils/URI.java - src/share/classes/com/sun/org/apache/xml/internal/serializer/utils/Utils.java - src/share/classes/com/sun/org/apache/xml/internal/serializer/utils/WrappedRuntimeException.java - src/share/classes/com/sun/org/apache/xml/internal/utils/AttList.java - src/share/classes/com/sun/org/apache/xml/internal/utils/BoolStack.java - src/share/classes/com/sun/org/apache/xml/internal/utils/CharKey.java - src/share/classes/com/sun/org/apache/xml/internal/utils/Constants.java - src/share/classes/com/sun/org/apache/xml/internal/utils/DOM2Helper.java - src/share/classes/com/sun/org/apache/xml/internal/utils/DOMBuilder.java - src/share/classes/com/sun/org/apache/xml/internal/utils/DOMHelper.java - src/share/classes/com/sun/org/apache/xml/internal/utils/DOMOrder.java - src/share/classes/com/sun/org/apache/xml/internal/utils/DefaultErrorHandler.java - src/share/classes/com/sun/org/apache/xml/internal/utils/ElemDesc.java - src/share/classes/com/sun/org/apache/xml/internal/utils/FastStringBuffer.java - src/share/classes/com/sun/org/apache/xml/internal/utils/Hashtree2Node.java - src/share/classes/com/sun/org/apache/xml/internal/utils/IntStack.java - src/share/classes/com/sun/org/apache/xml/internal/utils/IntVector.java - src/share/classes/com/sun/org/apache/xml/internal/utils/ListingErrorHandler.java - src/share/classes/com/sun/org/apache/xml/internal/utils/LocaleUtility.java - src/share/classes/com/sun/org/apache/xml/internal/utils/MutableAttrListImpl.java - src/share/classes/com/sun/org/apache/xml/internal/utils/NSInfo.java - src/share/classes/com/sun/org/apache/xml/internal/utils/NameSpace.java - src/share/classes/com/sun/org/apache/xml/internal/utils/NamespaceSupport2.java - src/share/classes/com/sun/org/apache/xml/internal/utils/NodeConsumer.java - src/share/classes/com/sun/org/apache/xml/internal/utils/NodeVector.java - src/share/classes/com/sun/org/apache/xml/internal/utils/ObjectFactory.java - src/share/classes/com/sun/org/apache/xml/internal/utils/ObjectPool.java - src/share/classes/com/sun/org/apache/xml/internal/utils/ObjectStack.java - src/share/classes/com/sun/org/apache/xml/internal/utils/ObjectVector.java - src/share/classes/com/sun/org/apache/xml/internal/utils/PrefixResolver.java - src/share/classes/com/sun/org/apache/xml/internal/utils/PrefixResolverDefault.java - src/share/classes/com/sun/org/apache/xml/internal/utils/QName.java - src/share/classes/com/sun/org/apache/xml/internal/utils/RawCharacterHandler.java - src/share/classes/com/sun/org/apache/xml/internal/utils/SAXSourceLocator.java - src/share/classes/com/sun/org/apache/xml/internal/utils/SecuritySupport.java - src/share/classes/com/sun/org/apache/xml/internal/utils/SecuritySupport12.java - src/share/classes/com/sun/org/apache/xml/internal/utils/SerializableLocatorImpl.java - src/share/classes/com/sun/org/apache/xml/internal/utils/StopParseException.java - src/share/classes/com/sun/org/apache/xml/internal/utils/StringBufferPool.java - src/share/classes/com/sun/org/apache/xml/internal/utils/StringComparable.java - src/share/classes/com/sun/org/apache/xml/internal/utils/StringToIntTable.java - src/share/classes/com/sun/org/apache/xml/internal/utils/StringToStringTable.java - src/share/classes/com/sun/org/apache/xml/internal/utils/StringToStringTableVector.java - src/share/classes/com/sun/org/apache/xml/internal/utils/StringVector.java - src/share/classes/com/sun/org/apache/xml/internal/utils/StylesheetPIHandler.java - src/share/classes/com/sun/org/apache/xml/internal/utils/SuballocatedByteVector.java - src/share/classes/com/sun/org/apache/xml/internal/utils/SuballocatedIntVector.java - src/share/classes/com/sun/org/apache/xml/internal/utils/SystemIDResolver.java - src/share/classes/com/sun/org/apache/xml/internal/utils/ThreadControllerWrapper.java - src/share/classes/com/sun/org/apache/xml/internal/utils/TreeWalker.java - src/share/classes/com/sun/org/apache/xml/internal/utils/Trie.java - src/share/classes/com/sun/org/apache/xml/internal/utils/URI.java - src/share/classes/com/sun/org/apache/xml/internal/utils/UnImplNode.java - src/share/classes/com/sun/org/apache/xml/internal/utils/WrappedRuntimeException.java - src/share/classes/com/sun/org/apache/xml/internal/utils/WrongParserException.java - src/share/classes/com/sun/org/apache/xml/internal/utils/XML11Char.java - src/share/classes/com/sun/org/apache/xml/internal/utils/XMLChar.java - src/share/classes/com/sun/org/apache/xml/internal/utils/XMLCharacterRecognizer.java - src/share/classes/com/sun/org/apache/xml/internal/utils/XMLReaderManager.java - src/share/classes/com/sun/org/apache/xml/internal/utils/XMLString.java - src/share/classes/com/sun/org/apache/xml/internal/utils/XMLStringDefault.java - src/share/classes/com/sun/org/apache/xml/internal/utils/XMLStringFactory.java - src/share/classes/com/sun/org/apache/xml/internal/utils/XMLStringFactoryDefault.java - src/share/classes/com/sun/org/apache/xml/internal/utils/package.html - src/share/classes/com/sun/org/apache/xml/internal/utils/res/CharArrayWrapper.java - src/share/classes/com/sun/org/apache/xml/internal/utils/res/IntArrayWrapper.java - src/share/classes/com/sun/org/apache/xml/internal/utils/res/LongArrayWrapper.java - src/share/classes/com/sun/org/apache/xml/internal/utils/res/StringArrayWrapper.java - src/share/classes/com/sun/org/apache/xml/internal/utils/res/XResourceBundle.java - src/share/classes/com/sun/org/apache/xml/internal/utils/res/XResourceBundleBase.java - src/share/classes/com/sun/org/apache/xml/internal/utils/res/XResources_de.java - src/share/classes/com/sun/org/apache/xml/internal/utils/res/XResources_en.java - src/share/classes/com/sun/org/apache/xml/internal/utils/res/XResources_es.java - src/share/classes/com/sun/org/apache/xml/internal/utils/res/XResources_fr.java - src/share/classes/com/sun/org/apache/xml/internal/utils/res/XResources_it.java - src/share/classes/com/sun/org/apache/xml/internal/utils/res/XResources_ja_JP_A.java - src/share/classes/com/sun/org/apache/xml/internal/utils/res/XResources_ja_JP_HA.java - src/share/classes/com/sun/org/apache/xml/internal/utils/res/XResources_ja_JP_HI.java - src/share/classes/com/sun/org/apache/xml/internal/utils/res/XResources_ja_JP_I.java - src/share/classes/com/sun/org/apache/xml/internal/utils/res/XResources_ko.java - src/share/classes/com/sun/org/apache/xml/internal/utils/res/XResources_sv.java - src/share/classes/com/sun/org/apache/xml/internal/utils/res/XResources_zh_CN.java - src/share/classes/com/sun/org/apache/xml/internal/utils/res/XResources_zh_TW.java - src/share/classes/com/sun/org/apache/xpath/internal/Arg.java - src/share/classes/com/sun/org/apache/xpath/internal/CachedXPathAPI.java - src/share/classes/com/sun/org/apache/xpath/internal/Expression.java - src/share/classes/com/sun/org/apache/xpath/internal/ExpressionNode.java - src/share/classes/com/sun/org/apache/xpath/internal/ExpressionOwner.java - src/share/classes/com/sun/org/apache/xpath/internal/ExtensionsProvider.java - src/share/classes/com/sun/org/apache/xpath/internal/FoundIndex.java - src/share/classes/com/sun/org/apache/xpath/internal/NodeSet.java - src/share/classes/com/sun/org/apache/xpath/internal/NodeSetDTM.java - src/share/classes/com/sun/org/apache/xpath/internal/SourceTree.java - src/share/classes/com/sun/org/apache/xpath/internal/SourceTreeManager.java - src/share/classes/com/sun/org/apache/xpath/internal/VariableStack.java - src/share/classes/com/sun/org/apache/xpath/internal/WhitespaceStrippingElementMatcher.java - src/share/classes/com/sun/org/apache/xpath/internal/XPath.java - src/share/classes/com/sun/org/apache/xpath/internal/XPathAPI.java - src/share/classes/com/sun/org/apache/xpath/internal/XPathContext.java - src/share/classes/com/sun/org/apache/xpath/internal/XPathException.java - src/share/classes/com/sun/org/apache/xpath/internal/XPathFactory.java - src/share/classes/com/sun/org/apache/xpath/internal/XPathProcessorException.java - src/share/classes/com/sun/org/apache/xpath/internal/XPathVisitable.java - src/share/classes/com/sun/org/apache/xpath/internal/XPathVisitor.java - src/share/classes/com/sun/org/apache/xpath/internal/axes/AttributeIterator.java - src/share/classes/com/sun/org/apache/xpath/internal/axes/AxesWalker.java - src/share/classes/com/sun/org/apache/xpath/internal/axes/BasicTestIterator.java - src/share/classes/com/sun/org/apache/xpath/internal/axes/ChildIterator.java - src/share/classes/com/sun/org/apache/xpath/internal/axes/ChildTestIterator.java - src/share/classes/com/sun/org/apache/xpath/internal/axes/ContextNodeList.java - src/share/classes/com/sun/org/apache/xpath/internal/axes/DescendantIterator.java - src/share/classes/com/sun/org/apache/xpath/internal/axes/FilterExprIterator.java - src/share/classes/com/sun/org/apache/xpath/internal/axes/FilterExprIteratorSimple.java - src/share/classes/com/sun/org/apache/xpath/internal/axes/FilterExprWalker.java - src/share/classes/com/sun/org/apache/xpath/internal/axes/HasPositionalPredChecker.java - src/share/classes/com/sun/org/apache/xpath/internal/axes/IteratorPool.java - src/share/classes/com/sun/org/apache/xpath/internal/axes/LocPathIterator.java - src/share/classes/com/sun/org/apache/xpath/internal/axes/MatchPatternIterator.java - src/share/classes/com/sun/org/apache/xpath/internal/axes/NodeSequence.java - src/share/classes/com/sun/org/apache/xpath/internal/axes/OneStepIterator.java - src/share/classes/com/sun/org/apache/xpath/internal/axes/OneStepIteratorForward.java - src/share/classes/com/sun/org/apache/xpath/internal/axes/PathComponent.java - src/share/classes/com/sun/org/apache/xpath/internal/axes/PredicatedNodeTest.java - src/share/classes/com/sun/org/apache/xpath/internal/axes/RTFIterator.java - src/share/classes/com/sun/org/apache/xpath/internal/axes/ReverseAxesWalker.java - src/share/classes/com/sun/org/apache/xpath/internal/axes/SelfIteratorNoPredicate.java - src/share/classes/com/sun/org/apache/xpath/internal/axes/SubContextList.java - src/share/classes/com/sun/org/apache/xpath/internal/axes/UnionChildIterator.java - src/share/classes/com/sun/org/apache/xpath/internal/axes/UnionPathIterator.java - src/share/classes/com/sun/org/apache/xpath/internal/axes/WalkerFactory.java - src/share/classes/com/sun/org/apache/xpath/internal/axes/WalkingIterator.java - src/share/classes/com/sun/org/apache/xpath/internal/axes/WalkingIteratorSorted.java - src/share/classes/com/sun/org/apache/xpath/internal/axes/package.html - src/share/classes/com/sun/org/apache/xpath/internal/compiler/Compiler.java - src/share/classes/com/sun/org/apache/xpath/internal/compiler/FuncLoader.java - src/share/classes/com/sun/org/apache/xpath/internal/compiler/FunctionTable.java - src/share/classes/com/sun/org/apache/xpath/internal/compiler/Keywords.java - src/share/classes/com/sun/org/apache/xpath/internal/compiler/Lexer.java - src/share/classes/com/sun/org/apache/xpath/internal/compiler/ObjectFactory.java - src/share/classes/com/sun/org/apache/xpath/internal/compiler/OpCodes.java - src/share/classes/com/sun/org/apache/xpath/internal/compiler/OpMap.java - src/share/classes/com/sun/org/apache/xpath/internal/compiler/OpMapVector.java - src/share/classes/com/sun/org/apache/xpath/internal/compiler/PsuedoNames.java - src/share/classes/com/sun/org/apache/xpath/internal/compiler/SecuritySupport.java - src/share/classes/com/sun/org/apache/xpath/internal/compiler/SecuritySupport12.java - src/share/classes/com/sun/org/apache/xpath/internal/compiler/XPathDumper.java - src/share/classes/com/sun/org/apache/xpath/internal/compiler/XPathParser.java - src/share/classes/com/sun/org/apache/xpath/internal/compiler/package.html - src/share/classes/com/sun/org/apache/xpath/internal/domapi/XPathEvaluatorImpl.java - src/share/classes/com/sun/org/apache/xpath/internal/domapi/XPathExpressionImpl.java - src/share/classes/com/sun/org/apache/xpath/internal/domapi/XPathNSResolverImpl.java - src/share/classes/com/sun/org/apache/xpath/internal/domapi/XPathNamespaceImpl.java - src/share/classes/com/sun/org/apache/xpath/internal/domapi/XPathResultImpl.java - src/share/classes/com/sun/org/apache/xpath/internal/domapi/XPathStylesheetDOM3Exception.java - src/share/classes/com/sun/org/apache/xpath/internal/domapi/package.html - src/share/classes/com/sun/org/apache/xpath/internal/functions/FuncBoolean.java - src/share/classes/com/sun/org/apache/xpath/internal/functions/FuncCeiling.java - src/share/classes/com/sun/org/apache/xpath/internal/functions/FuncConcat.java - src/share/classes/com/sun/org/apache/xpath/internal/functions/FuncContains.java - src/share/classes/com/sun/org/apache/xpath/internal/functions/FuncCount.java - src/share/classes/com/sun/org/apache/xpath/internal/functions/FuncCurrent.java - src/share/classes/com/sun/org/apache/xpath/internal/functions/FuncDoclocation.java - src/share/classes/com/sun/org/apache/xpath/internal/functions/FuncExtElementAvailable.java - src/share/classes/com/sun/org/apache/xpath/internal/functions/FuncExtFunction.java - src/share/classes/com/sun/org/apache/xpath/internal/functions/FuncExtFunctionAvailable.java - src/share/classes/com/sun/org/apache/xpath/internal/functions/FuncFalse.java - src/share/classes/com/sun/org/apache/xpath/internal/functions/FuncFloor.java - src/share/classes/com/sun/org/apache/xpath/internal/functions/FuncGenerateId.java - src/share/classes/com/sun/org/apache/xpath/internal/functions/FuncId.java - src/share/classes/com/sun/org/apache/xpath/internal/functions/FuncLang.java - src/share/classes/com/sun/org/apache/xpath/internal/functions/FuncLast.java - src/share/classes/com/sun/org/apache/xpath/internal/functions/FuncLocalPart.java - src/share/classes/com/sun/org/apache/xpath/internal/functions/FuncNamespace.java - src/share/classes/com/sun/org/apache/xpath/internal/functions/FuncNormalizeSpace.java - src/share/classes/com/sun/org/apache/xpath/internal/functions/FuncNot.java - src/share/classes/com/sun/org/apache/xpath/internal/functions/FuncNumber.java - src/share/classes/com/sun/org/apache/xpath/internal/functions/FuncPosition.java - src/share/classes/com/sun/org/apache/xpath/internal/functions/FuncQname.java - src/share/classes/com/sun/org/apache/xpath/internal/functions/FuncRound.java - src/share/classes/com/sun/org/apache/xpath/internal/functions/FuncStartsWith.java - src/share/classes/com/sun/org/apache/xpath/internal/functions/FuncString.java - src/share/classes/com/sun/org/apache/xpath/internal/functions/FuncStringLength.java - src/share/classes/com/sun/org/apache/xpath/internal/functions/FuncSubstring.java - src/share/classes/com/sun/org/apache/xpath/internal/functions/FuncSubstringAfter.java - src/share/classes/com/sun/org/apache/xpath/internal/functions/FuncSubstringBefore.java - src/share/classes/com/sun/org/apache/xpath/internal/functions/FuncSum.java - src/share/classes/com/sun/org/apache/xpath/internal/functions/FuncSystemProperty.java - src/share/classes/com/sun/org/apache/xpath/internal/functions/FuncTranslate.java - src/share/classes/com/sun/org/apache/xpath/internal/functions/FuncTrue.java - src/share/classes/com/sun/org/apache/xpath/internal/functions/FuncUnparsedEntityURI.java - src/share/classes/com/sun/org/apache/xpath/internal/functions/Function.java - src/share/classes/com/sun/org/apache/xpath/internal/functions/Function2Args.java - src/share/classes/com/sun/org/apache/xpath/internal/functions/Function3Args.java - src/share/classes/com/sun/org/apache/xpath/internal/functions/FunctionDef1Arg.java - src/share/classes/com/sun/org/apache/xpath/internal/functions/FunctionMultiArgs.java - src/share/classes/com/sun/org/apache/xpath/internal/functions/FunctionOneArg.java - src/share/classes/com/sun/org/apache/xpath/internal/functions/ObjectFactory.java - src/share/classes/com/sun/org/apache/xpath/internal/functions/SecuritySupport.java - src/share/classes/com/sun/org/apache/xpath/internal/functions/SecuritySupport12.java - src/share/classes/com/sun/org/apache/xpath/internal/functions/WrongNumberArgsException.java - src/share/classes/com/sun/org/apache/xpath/internal/functions/package.html - src/share/classes/com/sun/org/apache/xpath/internal/jaxp/JAXPExtensionsProvider.java - src/share/classes/com/sun/org/apache/xpath/internal/jaxp/JAXPPrefixResolver.java - src/share/classes/com/sun/org/apache/xpath/internal/jaxp/JAXPVariableStack.java - src/share/classes/com/sun/org/apache/xpath/internal/jaxp/XPathExpressionImpl.java - src/share/classes/com/sun/org/apache/xpath/internal/jaxp/XPathFactoryImpl.java - src/share/classes/com/sun/org/apache/xpath/internal/jaxp/XPathImpl.java - src/share/classes/com/sun/org/apache/xpath/internal/objects/DTMXRTreeFrag.java - src/share/classes/com/sun/org/apache/xpath/internal/objects/XBoolean.java - src/share/classes/com/sun/org/apache/xpath/internal/objects/XBooleanStatic.java - src/share/classes/com/sun/org/apache/xpath/internal/objects/XMLStringFactoryImpl.java - src/share/classes/com/sun/org/apache/xpath/internal/objects/XNodeSet.java - src/share/classes/com/sun/org/apache/xpath/internal/objects/XNodeSetForDOM.java - src/share/classes/com/sun/org/apache/xpath/internal/objects/XNull.java - src/share/classes/com/sun/org/apache/xpath/internal/objects/XNumber.java - src/share/classes/com/sun/org/apache/xpath/internal/objects/XObject.java - src/share/classes/com/sun/org/apache/xpath/internal/objects/XObjectFactory.java - src/share/classes/com/sun/org/apache/xpath/internal/objects/XRTreeFrag.java - src/share/classes/com/sun/org/apache/xpath/internal/objects/XRTreeFragSelectWrapper.java - src/share/classes/com/sun/org/apache/xpath/internal/objects/XString.java - src/share/classes/com/sun/org/apache/xpath/internal/objects/XStringForChars.java - src/share/classes/com/sun/org/apache/xpath/internal/objects/XStringForFSB.java - src/share/classes/com/sun/org/apache/xpath/internal/objects/package.html - src/share/classes/com/sun/org/apache/xpath/internal/operations/And.java - src/share/classes/com/sun/org/apache/xpath/internal/operations/Bool.java - src/share/classes/com/sun/org/apache/xpath/internal/operations/Div.java - src/share/classes/com/sun/org/apache/xpath/internal/operations/Equals.java - src/share/classes/com/sun/org/apache/xpath/internal/operations/Gt.java - src/share/classes/com/sun/org/apache/xpath/internal/operations/Gte.java - src/share/classes/com/sun/org/apache/xpath/internal/operations/Lt.java - src/share/classes/com/sun/org/apache/xpath/internal/operations/Lte.java - src/share/classes/com/sun/org/apache/xpath/internal/operations/Minus.java - src/share/classes/com/sun/org/apache/xpath/internal/operations/Mod.java - src/share/classes/com/sun/org/apache/xpath/internal/operations/Mult.java - src/share/classes/com/sun/org/apache/xpath/internal/operations/Neg.java - src/share/classes/com/sun/org/apache/xpath/internal/operations/NotEquals.java - src/share/classes/com/sun/org/apache/xpath/internal/operations/Number.java - src/share/classes/com/sun/org/apache/xpath/internal/operations/Operation.java - src/share/classes/com/sun/org/apache/xpath/internal/operations/Or.java - src/share/classes/com/sun/org/apache/xpath/internal/operations/Plus.java - src/share/classes/com/sun/org/apache/xpath/internal/operations/Quo.java - src/share/classes/com/sun/org/apache/xpath/internal/operations/String.java - src/share/classes/com/sun/org/apache/xpath/internal/operations/UnaryOperation.java - src/share/classes/com/sun/org/apache/xpath/internal/operations/Variable.java - src/share/classes/com/sun/org/apache/xpath/internal/operations/VariableSafeAbsRef.java - src/share/classes/com/sun/org/apache/xpath/internal/operations/package.html - src/share/classes/com/sun/org/apache/xpath/internal/package.html - src/share/classes/com/sun/org/apache/xpath/internal/patterns/ContextMatchStepPattern.java - src/share/classes/com/sun/org/apache/xpath/internal/patterns/FunctionPattern.java - src/share/classes/com/sun/org/apache/xpath/internal/patterns/NodeTest.java - src/share/classes/com/sun/org/apache/xpath/internal/patterns/NodeTestFilter.java - src/share/classes/com/sun/org/apache/xpath/internal/patterns/StepPattern.java - src/share/classes/com/sun/org/apache/xpath/internal/patterns/UnionPattern.java - src/share/classes/com/sun/org/apache/xpath/internal/patterns/package.html - src/share/classes/com/sun/org/apache/xpath/internal/res/XPATHErrorResources.java - src/share/classes/com/sun/org/apache/xpath/internal/res/XPATHErrorResources_de.java - src/share/classes/com/sun/org/apache/xpath/internal/res/XPATHErrorResources_en.java - src/share/classes/com/sun/org/apache/xpath/internal/res/XPATHErrorResources_es.java - src/share/classes/com/sun/org/apache/xpath/internal/res/XPATHErrorResources_fr.java - src/share/classes/com/sun/org/apache/xpath/internal/res/XPATHErrorResources_it.java - src/share/classes/com/sun/org/apache/xpath/internal/res/XPATHErrorResources_ja.java - src/share/classes/com/sun/org/apache/xpath/internal/res/XPATHErrorResources_ko.java - src/share/classes/com/sun/org/apache/xpath/internal/res/XPATHErrorResources_pt_BR.java - src/share/classes/com/sun/org/apache/xpath/internal/res/XPATHErrorResources_sv.java - src/share/classes/com/sun/org/apache/xpath/internal/res/XPATHErrorResources_zh_CN.java - src/share/classes/com/sun/org/apache/xpath/internal/res/XPATHErrorResources_zh_TW.java - src/share/classes/com/sun/org/apache/xpath/internal/res/XPATHMessages.java - src/share/classes/com/sun/org/apache/xpath/internal/res/package.html - src/share/classes/com/sun/xml/internal/stream/Entity.java - src/share/classes/com/sun/xml/internal/stream/EventFilterSupport.java - src/share/classes/com/sun/xml/internal/stream/StaxEntityResolverWrapper.java - src/share/classes/com/sun/xml/internal/stream/StaxErrorReporter.java - src/share/classes/com/sun/xml/internal/stream/StaxXMLInputSource.java - src/share/classes/com/sun/xml/internal/stream/XMLBufferListener.java - src/share/classes/com/sun/xml/internal/stream/XMLEntityReader.java - src/share/classes/com/sun/xml/internal/stream/XMLEntityStorage.java - src/share/classes/com/sun/xml/internal/stream/XMLEventReaderImpl.java - src/share/classes/com/sun/xml/internal/stream/XMLInputFactoryImpl.java - src/share/classes/com/sun/xml/internal/stream/XMLOutputFactoryImpl.java - src/share/classes/com/sun/xml/internal/stream/dtd/DTDGrammarUtil.java - src/share/classes/com/sun/xml/internal/stream/dtd/nonvalidating/DTDGrammar.java - src/share/classes/com/sun/xml/internal/stream/dtd/nonvalidating/XMLAttributeDecl.java - src/share/classes/com/sun/xml/internal/stream/dtd/nonvalidating/XMLElementDecl.java - src/share/classes/com/sun/xml/internal/stream/dtd/nonvalidating/XMLNotationDecl.java - src/share/classes/com/sun/xml/internal/stream/dtd/nonvalidating/XMLSimpleType.java - src/share/classes/com/sun/xml/internal/stream/events/AttributeImpl.java - src/share/classes/com/sun/xml/internal/stream/events/CharacterEvent.java - src/share/classes/com/sun/xml/internal/stream/events/CommentEvent.java - src/share/classes/com/sun/xml/internal/stream/events/DTDEvent.java - src/share/classes/com/sun/xml/internal/stream/events/DummyEvent.java - src/share/classes/com/sun/xml/internal/stream/events/EndDocumentEvent.java - src/share/classes/com/sun/xml/internal/stream/events/EndElementEvent.java - src/share/classes/com/sun/xml/internal/stream/events/EntityDeclarationImpl.java - src/share/classes/com/sun/xml/internal/stream/events/EntityReferenceEvent.java - src/share/classes/com/sun/xml/internal/stream/events/LocationImpl.java - src/share/classes/com/sun/xml/internal/stream/events/NamedEvent.java - src/share/classes/com/sun/xml/internal/stream/events/NamespaceImpl.java - src/share/classes/com/sun/xml/internal/stream/events/NotationDeclarationImpl.java - src/share/classes/com/sun/xml/internal/stream/events/ProcessingInstructionEvent.java - src/share/classes/com/sun/xml/internal/stream/events/StartDocumentEvent.java - src/share/classes/com/sun/xml/internal/stream/events/StartElementEvent.java - src/share/classes/com/sun/xml/internal/stream/events/XMLEventAllocatorImpl.java - src/share/classes/com/sun/xml/internal/stream/events/XMLEventFactoryImpl.java - src/share/classes/com/sun/xml/internal/stream/javax.xml.stream.XMLEventFactory - src/share/classes/com/sun/xml/internal/stream/javax.xml.stream.XMLInputFactory - src/share/classes/com/sun/xml/internal/stream/javax.xml.stream.XMLOutputFactory - src/share/classes/com/sun/xml/internal/stream/util/BufferAllocator.java - src/share/classes/com/sun/xml/internal/stream/util/ReadOnlyIterator.java - src/share/classes/com/sun/xml/internal/stream/util/ThreadLocalBufferAllocator.java - src/share/classes/com/sun/xml/internal/stream/writers/UTF8OutputStreamWriter.java - src/share/classes/com/sun/xml/internal/stream/writers/WriterUtility.java - src/share/classes/com/sun/xml/internal/stream/writers/XMLDOMWriterImpl.java - src/share/classes/com/sun/xml/internal/stream/writers/XMLEventWriterImpl.java - src/share/classes/com/sun/xml/internal/stream/writers/XMLOutputSource.java - src/share/classes/com/sun/xml/internal/stream/writers/XMLStreamWriterImpl.java - src/share/classes/com/sun/xml/internal/stream/writers/XMLWriter.java - src/share/classes/javax/xml/XMLConstants.java - src/share/classes/javax/xml/datatype/DatatypeConfigurationException.java - src/share/classes/javax/xml/datatype/DatatypeConstants.java - src/share/classes/javax/xml/datatype/DatatypeFactory.java - src/share/classes/javax/xml/datatype/Duration.java - src/share/classes/javax/xml/datatype/FactoryFinder.java - src/share/classes/javax/xml/datatype/SecuritySupport.java - src/share/classes/javax/xml/datatype/XMLGregorianCalendar.java - src/share/classes/javax/xml/datatype/package.html - src/share/classes/javax/xml/namespace/NamespaceContext.java - src/share/classes/javax/xml/namespace/QName.java - src/share/classes/javax/xml/namespace/package.html - src/share/classes/javax/xml/parsers/DocumentBuilder.java - src/share/classes/javax/xml/parsers/DocumentBuilderFactory.java - src/share/classes/javax/xml/parsers/FactoryConfigurationError.java - src/share/classes/javax/xml/parsers/FactoryFinder.java - src/share/classes/javax/xml/parsers/ParserConfigurationException.java - src/share/classes/javax/xml/parsers/SAXParser.java - src/share/classes/javax/xml/parsers/SAXParserFactory.java - src/share/classes/javax/xml/parsers/SecuritySupport.java - src/share/classes/javax/xml/parsers/package.html - src/share/classes/javax/xml/stream/EventFilter.java - src/share/classes/javax/xml/stream/FactoryConfigurationError.java - src/share/classes/javax/xml/stream/FactoryFinder.java - src/share/classes/javax/xml/stream/Location.java - src/share/classes/javax/xml/stream/SecuritySupport.java - src/share/classes/javax/xml/stream/StreamFilter.java - src/share/classes/javax/xml/stream/XMLEventFactory.java - src/share/classes/javax/xml/stream/XMLEventReader.java - src/share/classes/javax/xml/stream/XMLEventWriter.java - src/share/classes/javax/xml/stream/XMLInputFactory.java - src/share/classes/javax/xml/stream/XMLOutputFactory.java - src/share/classes/javax/xml/stream/XMLReporter.java - src/share/classes/javax/xml/stream/XMLResolver.java - src/share/classes/javax/xml/stream/XMLStreamConstants.java - src/share/classes/javax/xml/stream/XMLStreamException.java - src/share/classes/javax/xml/stream/XMLStreamReader.java - src/share/classes/javax/xml/stream/XMLStreamWriter.java - src/share/classes/javax/xml/stream/events/Attribute.java - src/share/classes/javax/xml/stream/events/Characters.java - src/share/classes/javax/xml/stream/events/Comment.java - src/share/classes/javax/xml/stream/events/DTD.java - src/share/classes/javax/xml/stream/events/EndDocument.java - src/share/classes/javax/xml/stream/events/EndElement.java - src/share/classes/javax/xml/stream/events/EntityDeclaration.java - src/share/classes/javax/xml/stream/events/EntityReference.java - src/share/classes/javax/xml/stream/events/Namespace.java - src/share/classes/javax/xml/stream/events/NotationDeclaration.java - src/share/classes/javax/xml/stream/events/ProcessingInstruction.java - src/share/classes/javax/xml/stream/events/StartDocument.java - src/share/classes/javax/xml/stream/events/StartElement.java - src/share/classes/javax/xml/stream/events/XMLEvent.java - src/share/classes/javax/xml/stream/util/EventReaderDelegate.java - src/share/classes/javax/xml/stream/util/StreamReaderDelegate.java - src/share/classes/javax/xml/stream/util/XMLEventAllocator.java - src/share/classes/javax/xml/stream/util/XMLEventConsumer.java - src/share/classes/javax/xml/transform/ErrorListener.java - src/share/classes/javax/xml/transform/FactoryFinder.java - src/share/classes/javax/xml/transform/OutputKeys.java - src/share/classes/javax/xml/transform/Result.java - src/share/classes/javax/xml/transform/SecuritySupport.java - src/share/classes/javax/xml/transform/Source.java - src/share/classes/javax/xml/transform/SourceLocator.java - src/share/classes/javax/xml/transform/Templates.java - src/share/classes/javax/xml/transform/Transformer.java - src/share/classes/javax/xml/transform/TransformerConfigurationException.java - src/share/classes/javax/xml/transform/TransformerException.java - src/share/classes/javax/xml/transform/TransformerFactory.java - src/share/classes/javax/xml/transform/TransformerFactoryConfigurationError.java - src/share/classes/javax/xml/transform/URIResolver.java - src/share/classes/javax/xml/transform/dom/DOMLocator.java - src/share/classes/javax/xml/transform/dom/DOMResult.java - src/share/classes/javax/xml/transform/dom/DOMSource.java - src/share/classes/javax/xml/transform/dom/package.html - src/share/classes/javax/xml/transform/overview.html - src/share/classes/javax/xml/transform/package.html - src/share/classes/javax/xml/transform/sax/SAXResult.java - src/share/classes/javax/xml/transform/sax/SAXSource.java - src/share/classes/javax/xml/transform/sax/SAXTransformerFactory.java - src/share/classes/javax/xml/transform/sax/TemplatesHandler.java - src/share/classes/javax/xml/transform/sax/TransformerHandler.java - src/share/classes/javax/xml/transform/sax/package.html - src/share/classes/javax/xml/transform/stax/StAXResult.java - src/share/classes/javax/xml/transform/stax/StAXSource.java - src/share/classes/javax/xml/transform/stax/package.html - src/share/classes/javax/xml/transform/stream/StreamResult.java - src/share/classes/javax/xml/transform/stream/StreamSource.java - src/share/classes/javax/xml/transform/stream/package.html - src/share/classes/javax/xml/validation/Schema.java - src/share/classes/javax/xml/validation/SchemaFactory.java - src/share/classes/javax/xml/validation/SchemaFactoryFinder.java - src/share/classes/javax/xml/validation/SchemaFactoryLoader.java - src/share/classes/javax/xml/validation/SecuritySupport.java - src/share/classes/javax/xml/validation/TypeInfoProvider.java - src/share/classes/javax/xml/validation/Validator.java - src/share/classes/javax/xml/validation/ValidatorHandler.java - src/share/classes/javax/xml/validation/package.html - src/share/classes/javax/xml/xpath/SecuritySupport.java - src/share/classes/javax/xml/xpath/XPath.java - src/share/classes/javax/xml/xpath/XPathConstants.java - src/share/classes/javax/xml/xpath/XPathException.java - src/share/classes/javax/xml/xpath/XPathExpression.java - src/share/classes/javax/xml/xpath/XPathExpressionException.java - src/share/classes/javax/xml/xpath/XPathFactory.java - src/share/classes/javax/xml/xpath/XPathFactoryConfigurationException.java - src/share/classes/javax/xml/xpath/XPathFactoryFinder.java - src/share/classes/javax/xml/xpath/XPathFunction.java - src/share/classes/javax/xml/xpath/XPathFunctionException.java - src/share/classes/javax/xml/xpath/XPathFunctionResolver.java - src/share/classes/javax/xml/xpath/XPathVariableResolver.java - src/share/classes/javax/xml/xpath/package.html - src/share/classes/org/w3c/dom/Attr.java - src/share/classes/org/w3c/dom/CDATASection.java - src/share/classes/org/w3c/dom/CharacterData.java - src/share/classes/org/w3c/dom/Comment.java - src/share/classes/org/w3c/dom/DOMConfiguration.java - src/share/classes/org/w3c/dom/DOMError.java - src/share/classes/org/w3c/dom/DOMErrorHandler.java - src/share/classes/org/w3c/dom/DOMException.java - src/share/classes/org/w3c/dom/DOMImplementation.java - src/share/classes/org/w3c/dom/DOMImplementationList.java - src/share/classes/org/w3c/dom/DOMImplementationSource.java - src/share/classes/org/w3c/dom/DOMLocator.java - src/share/classes/org/w3c/dom/DOMStringList.java - src/share/classes/org/w3c/dom/Document.java - src/share/classes/org/w3c/dom/DocumentFragment.java - src/share/classes/org/w3c/dom/DocumentType.java - src/share/classes/org/w3c/dom/Element.java - src/share/classes/org/w3c/dom/Entity.java - src/share/classes/org/w3c/dom/EntityReference.java - src/share/classes/org/w3c/dom/NameList.java - src/share/classes/org/w3c/dom/NamedNodeMap.java - src/share/classes/org/w3c/dom/Node.java - src/share/classes/org/w3c/dom/NodeList.java - src/share/classes/org/w3c/dom/Notation.java - src/share/classes/org/w3c/dom/ProcessingInstruction.java - src/share/classes/org/w3c/dom/Text.java - src/share/classes/org/w3c/dom/TypeInfo.java - src/share/classes/org/w3c/dom/UserDataHandler.java - src/share/classes/org/w3c/dom/bootstrap/DOMImplementationRegistry.java - src/share/classes/org/w3c/dom/css/CSS2Properties.java - src/share/classes/org/w3c/dom/css/CSSCharsetRule.java - src/share/classes/org/w3c/dom/css/CSSFontFaceRule.java - src/share/classes/org/w3c/dom/css/CSSImportRule.java - src/share/classes/org/w3c/dom/css/CSSMediaRule.java - src/share/classes/org/w3c/dom/css/CSSPageRule.java - src/share/classes/org/w3c/dom/css/CSSPrimitiveValue.java - src/share/classes/org/w3c/dom/css/CSSRule.java - src/share/classes/org/w3c/dom/css/CSSRuleList.java - src/share/classes/org/w3c/dom/css/CSSStyleDeclaration.java - src/share/classes/org/w3c/dom/css/CSSStyleRule.java - src/share/classes/org/w3c/dom/css/CSSStyleSheet.java - src/share/classes/org/w3c/dom/css/CSSUnknownRule.java - src/share/classes/org/w3c/dom/css/CSSValue.java - src/share/classes/org/w3c/dom/css/CSSValueList.java - src/share/classes/org/w3c/dom/css/Counter.java - src/share/classes/org/w3c/dom/css/DOMImplementationCSS.java - src/share/classes/org/w3c/dom/css/DocumentCSS.java - src/share/classes/org/w3c/dom/css/ElementCSSInlineStyle.java - src/share/classes/org/w3c/dom/css/RGBColor.java - src/share/classes/org/w3c/dom/css/Rect.java - src/share/classes/org/w3c/dom/css/ViewCSS.java - src/share/classes/org/w3c/dom/events/DocumentEvent.java - src/share/classes/org/w3c/dom/events/Event.java - src/share/classes/org/w3c/dom/events/EventException.java - src/share/classes/org/w3c/dom/events/EventListener.java - src/share/classes/org/w3c/dom/events/EventTarget.java - src/share/classes/org/w3c/dom/events/MouseEvent.java - src/share/classes/org/w3c/dom/events/MutationEvent.java - src/share/classes/org/w3c/dom/events/UIEvent.java - src/share/classes/org/w3c/dom/html/HTMLAnchorElement.java - src/share/classes/org/w3c/dom/html/HTMLAppletElement.java - src/share/classes/org/w3c/dom/html/HTMLAreaElement.java - src/share/classes/org/w3c/dom/html/HTMLBRElement.java - src/share/classes/org/w3c/dom/html/HTMLBaseElement.java - src/share/classes/org/w3c/dom/html/HTMLBaseFontElement.java - src/share/classes/org/w3c/dom/html/HTMLBodyElement.java - src/share/classes/org/w3c/dom/html/HTMLButtonElement.java - src/share/classes/org/w3c/dom/html/HTMLCollection.java - src/share/classes/org/w3c/dom/html/HTMLDListElement.java - src/share/classes/org/w3c/dom/html/HTMLDOMImplementation.java - src/share/classes/org/w3c/dom/html/HTMLDirectoryElement.java - src/share/classes/org/w3c/dom/html/HTMLDivElement.java - src/share/classes/org/w3c/dom/html/HTMLDocument.java - src/share/classes/org/w3c/dom/html/HTMLElement.java - src/share/classes/org/w3c/dom/html/HTMLFieldSetElement.java - src/share/classes/org/w3c/dom/html/HTMLFontElement.java - src/share/classes/org/w3c/dom/html/HTMLFormElement.java - src/share/classes/org/w3c/dom/html/HTMLFrameElement.java - src/share/classes/org/w3c/dom/html/HTMLFrameSetElement.java - src/share/classes/org/w3c/dom/html/HTMLHRElement.java - src/share/classes/org/w3c/dom/html/HTMLHeadElement.java - src/share/classes/org/w3c/dom/html/HTMLHeadingElement.java - src/share/classes/org/w3c/dom/html/HTMLHtmlElement.java - src/share/classes/org/w3c/dom/html/HTMLIFrameElement.java - src/share/classes/org/w3c/dom/html/HTMLImageElement.java - src/share/classes/org/w3c/dom/html/HTMLInputElement.java - src/share/classes/org/w3c/dom/html/HTMLIsIndexElement.java - src/share/classes/org/w3c/dom/html/HTMLLIElement.java - src/share/classes/org/w3c/dom/html/HTMLLabelElement.java - src/share/classes/org/w3c/dom/html/HTMLLegendElement.java - src/share/classes/org/w3c/dom/html/HTMLLinkElement.java - src/share/classes/org/w3c/dom/html/HTMLMapElement.java - src/share/classes/org/w3c/dom/html/HTMLMenuElement.java - src/share/classes/org/w3c/dom/html/HTMLMetaElement.java - src/share/classes/org/w3c/dom/html/HTMLModElement.java - src/share/classes/org/w3c/dom/html/HTMLOListElement.java - src/share/classes/org/w3c/dom/html/HTMLObjectElement.java - src/share/classes/org/w3c/dom/html/HTMLOptGroupElement.java - src/share/classes/org/w3c/dom/html/HTMLOptionElement.java - src/share/classes/org/w3c/dom/html/HTMLParagraphElement.java - src/share/classes/org/w3c/dom/html/HTMLParamElement.java - src/share/classes/org/w3c/dom/html/HTMLPreElement.java - src/share/classes/org/w3c/dom/html/HTMLQuoteElement.java - src/share/classes/org/w3c/dom/html/HTMLScriptElement.java - src/share/classes/org/w3c/dom/html/HTMLSelectElement.java - src/share/classes/org/w3c/dom/html/HTMLStyleElement.java - src/share/classes/org/w3c/dom/html/HTMLTableCaptionElement.java - src/share/classes/org/w3c/dom/html/HTMLTableCellElement.java - src/share/classes/org/w3c/dom/html/HTMLTableColElement.java - src/share/classes/org/w3c/dom/html/HTMLTableElement.java - src/share/classes/org/w3c/dom/html/HTMLTableRowElement.java - src/share/classes/org/w3c/dom/html/HTMLTableSectionElement.java - src/share/classes/org/w3c/dom/html/HTMLTextAreaElement.java - src/share/classes/org/w3c/dom/html/HTMLTitleElement.java - src/share/classes/org/w3c/dom/html/HTMLUListElement.java - src/share/classes/org/w3c/dom/ls/DOMImplementationLS.java - src/share/classes/org/w3c/dom/ls/LSException.java - src/share/classes/org/w3c/dom/ls/LSInput.java - src/share/classes/org/w3c/dom/ls/LSLoadEvent.java - src/share/classes/org/w3c/dom/ls/LSOutput.java - src/share/classes/org/w3c/dom/ls/LSParser.java - src/share/classes/org/w3c/dom/ls/LSParserFilter.java - src/share/classes/org/w3c/dom/ls/LSProgressEvent.java - src/share/classes/org/w3c/dom/ls/LSResourceResolver.java - src/share/classes/org/w3c/dom/ls/LSSerializer.java - src/share/classes/org/w3c/dom/ls/LSSerializerFilter.java - src/share/classes/org/w3c/dom/package.html - src/share/classes/org/w3c/dom/ranges/DocumentRange.java - src/share/classes/org/w3c/dom/ranges/Range.java - src/share/classes/org/w3c/dom/ranges/RangeException.java - src/share/classes/org/w3c/dom/ranges/package.html - src/share/classes/org/w3c/dom/stylesheets/DocumentStyle.java - src/share/classes/org/w3c/dom/stylesheets/LinkStyle.java - src/share/classes/org/w3c/dom/stylesheets/MediaList.java - src/share/classes/org/w3c/dom/stylesheets/StyleSheet.java - src/share/classes/org/w3c/dom/stylesheets/StyleSheetList.java - src/share/classes/org/w3c/dom/traversal/DocumentTraversal.java - src/share/classes/org/w3c/dom/traversal/NodeFilter.java - src/share/classes/org/w3c/dom/traversal/NodeIterator.java - src/share/classes/org/w3c/dom/traversal/TreeWalker.java - src/share/classes/org/w3c/dom/views/AbstractView.java - src/share/classes/org/w3c/dom/views/DocumentView.java - src/share/classes/org/w3c/dom/xpath/COPYRIGHT.html - src/share/classes/org/w3c/dom/xpath/XPathEvaluator.java - src/share/classes/org/w3c/dom/xpath/XPathException.java - src/share/classes/org/w3c/dom/xpath/XPathExpression.java - src/share/classes/org/w3c/dom/xpath/XPathNSResolver.java - src/share/classes/org/w3c/dom/xpath/XPathNamespace.java - src/share/classes/org/w3c/dom/xpath/XPathResult.java - src/share/classes/org/xml/sax/AttributeList.java - src/share/classes/org/xml/sax/Attributes.java - src/share/classes/org/xml/sax/COPYING - src/share/classes/org/xml/sax/COPYING.txt - src/share/classes/org/xml/sax/ContentHandler.java - src/share/classes/org/xml/sax/DTDHandler.java - src/share/classes/org/xml/sax/DocumentHandler.java - src/share/classes/org/xml/sax/EntityResolver.java - src/share/classes/org/xml/sax/ErrorHandler.java - src/share/classes/org/xml/sax/HandlerBase.java - src/share/classes/org/xml/sax/InputSource.java - src/share/classes/org/xml/sax/Locator.java - src/share/classes/org/xml/sax/Parser.java - src/share/classes/org/xml/sax/SAXException.java - src/share/classes/org/xml/sax/SAXNotRecognizedException.java - src/share/classes/org/xml/sax/SAXNotSupportedException.java - src/share/classes/org/xml/sax/SAXParseException.java - src/share/classes/org/xml/sax/XMLFilter.java - src/share/classes/org/xml/sax/XMLReader.java - src/share/classes/org/xml/sax/ext/Attributes2.java - src/share/classes/org/xml/sax/ext/Attributes2Impl.java - src/share/classes/org/xml/sax/ext/DeclHandler.java - src/share/classes/org/xml/sax/ext/DefaultHandler2.java - src/share/classes/org/xml/sax/ext/EntityResolver2.java - src/share/classes/org/xml/sax/ext/LexicalHandler.java - src/share/classes/org/xml/sax/ext/Locator2.java - src/share/classes/org/xml/sax/ext/Locator2Impl.java - src/share/classes/org/xml/sax/ext/package.html - src/share/classes/org/xml/sax/helpers/AttributeListImpl.java - src/share/classes/org/xml/sax/helpers/AttributesImpl.java - src/share/classes/org/xml/sax/helpers/DefaultHandler.java - src/share/classes/org/xml/sax/helpers/LocatorImpl.java - src/share/classes/org/xml/sax/helpers/NamespaceSupport.java - src/share/classes/org/xml/sax/helpers/NewInstance.java - src/share/classes/org/xml/sax/helpers/ParserAdapter.java - src/share/classes/org/xml/sax/helpers/ParserFactory.java - src/share/classes/org/xml/sax/helpers/XMLFilterImpl.java - src/share/classes/org/xml/sax/helpers/XMLReaderAdapter.java - src/share/classes/org/xml/sax/helpers/XMLReaderFactory.java - src/share/classes/org/xml/sax/helpers/package.html - src/share/classes/org/xml/sax/package.html Changeset: 6aadb7d98564 Author: asaha Date: 2012-05-21 14:51 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/6aadb7d98564 Merge Changeset: c865c6951fea Author: asaha Date: 2012-06-07 12:30 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/c865c6951fea Merge Changeset: 57476f66e13c Author: lana Date: 2012-06-26 10:27 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/57476f66e13c Merge Changeset: 219e720a1baa Author: lana Date: 2012-06-26 22:47 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/219e720a1baa Merge From lana.steuck at oracle.com Wed Jun 27 07:11:43 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 27 Jun 2012 07:11:43 +0000 Subject: hg: jdk8/tl/hotspot: 45 new changesets Message-ID: <20120627071320.E74D547B4C@hg.openjdk.java.net> Changeset: 6e2633440960 Author: amurillo Date: 2012-06-01 15:30 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6e2633440960 7173438: new hotspot build - hs24-b14 Reviewed-by: jcoomes ! make/hotspot_version Changeset: fab99b17c1de Author: mikael Date: 2012-06-01 20:17 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/fab99b17c1de 7155453: [macosx] re-enable jbb tests in JPRT Summary: Run SPECjbb in headless mode and enable SPECjbb runs on OSX Reviewed-by: dcubed, dholmes ! make/jprt.properties Changeset: 4434fdad6b37 Author: dholmes Date: 2012-06-02 07:32 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4434fdad6b37 Merge ! make/jprt.properties Changeset: e17b61ba7bb3 Author: kamg Date: 2012-06-04 10:22 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e17b61ba7bb3 7166498: JVM crash in ClassVerifier Summary: Fixed raw pointer being used after potential safepoint/GC Reviewed-by: acorn, fparain, dholmes ! src/share/vm/classfile/verifier.cpp Changeset: a297b0e14605 Author: mgerdin Date: 2012-06-04 09:21 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a297b0e14605 7172226: HotSpot fails to build with GCC 4.7 because of stricter c++ argument dependent lookup Summary: Add "using" keyword to import base class functions from FreeList to fix template name lookup in gcc 4.7 Reviewed-by: brutisso, iveresov ! src/share/vm/memory/binaryTreeDictionary.cpp ! src/share/vm/memory/binaryTreeDictionary.hpp Changeset: 37552638d24a Author: brutisso Date: 2012-06-05 22:30 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/37552638d24a 7172388: G1: _total_full_collections should not be incremented for concurrent cycles Reviewed-by: azeemj, jmasa ! src/share/vm/gc_implementation/g1/concurrentMarkThread.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/vm_operations_g1.cpp ! src/share/vm/gc_implementation/g1/vm_operations_g1.hpp Changeset: b9442ac22f59 Author: brutisso Date: 2012-06-04 13:29 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b9442ac22f59 7173460: G1: java/lang/management/MemoryMXBean/CollectionUsageThreshold.java failes with G1 Summary: The scope of TraceMemoryManagerStats in G1CollectedHeap need to cover the call to G1MonitoringSupport::update_sizes() Reviewed-by: johnc, jmasa ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp Changeset: 063451aefde8 Author: jcoomes Date: 2012-06-08 09:49 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/063451aefde8 Merge Changeset: 2fe087c3e814 Author: jiangli Date: 2012-06-06 14:33 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2fe087c3e814 7172967: Eliminate constMethod's _method backpointer to methodOop. Summary: Eliminate constMethod's _method backpointer to methodOop, and move the _constant field from methodOop to constMethod. Reviewed-by: roland, bdelsart, kamg ! agent/src/share/classes/sun/jvm/hotspot/oops/ConstMethod.java ! agent/src/share/classes/sun/jvm/hotspot/oops/Method.java ! src/cpu/sparc/vm/cppInterpreter_sparc.cpp ! src/cpu/sparc/vm/interp_masm_sparc.cpp ! src/cpu/sparc/vm/interp_masm_sparc.hpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/x86/vm/cppInterpreter_x86.cpp ! src/cpu/x86/vm/interp_masm_x86_32.hpp ! src/cpu/x86/vm/interp_masm_x86_64.hpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/os/solaris/dtrace/generateJvmOffsets.cpp ! src/os/solaris/dtrace/jhelper.d ! src/os/solaris/dtrace/libjvm_db.c ! src/share/vm/oops/constMethodKlass.cpp ! src/share/vm/oops/constMethodOop.cpp ! src/share/vm/oops/constMethodOop.hpp ! src/share/vm/oops/methodKlass.cpp ! src/share/vm/oops/methodOop.cpp ! src/share/vm/oops/methodOop.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: ab6ab9f84b2d Author: bdelsart Date: 2012-06-11 04:47 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ab6ab9f84b2d Merge Changeset: dcfcdd01af4b Author: fparain Date: 2012-06-05 06:48 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/dcfcdd01af4b 7171703: JNI DefineClass crashes client VM when first parameter is NULL Reviewed-by: acorn, kamg, sspitsyn, dholmes ! src/share/vm/prims/jni.cpp Changeset: de909f001528 Author: mikael Date: 2012-06-06 05:21 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/de909f001528 7170275: os::print_os_info needs to know about Windows 8 Summary: Recognize Windows 8 and Windows Server 2012 Reviewed-by: sla, kvn, azeemj ! src/os/windows/vm/os_windows.cpp Changeset: 40b4aaf010e4 Author: dholmes Date: 2012-06-08 02:06 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/40b4aaf010e4 7172708: 32/64 bit type issues on Windows after Mac OS X port Reviewed-by: dholmes, coleenp Contributed-by: Chris Dennis ! src/share/vm/utilities/globalDefinitions_visCPP.hpp Changeset: 0a8b8cb8b22c Author: sla Date: 2012-06-11 10:28 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/0a8b8cb8b22c Merge Changeset: 4d399f013e5a Author: kamg Date: 2012-06-11 13:10 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4d399f013e5a 7175914: Usage of gcc with precompiled headers produces wrong build dependencies Summary: Add -fpch-deps flag to gcc builds Reviewed-by: kamg, coleenp Contributed-by: volker.simonis at gmail.com ! make/bsd/makefiles/gcc.make ! make/linux/makefiles/gcc.make ! make/solaris/makefiles/gcc.make Changeset: 17b1b616daf7 Author: sla Date: 2012-06-14 12:21 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/17b1b616daf7 Merge Changeset: 8f6ce6f1049b Author: kvn Date: 2012-05-25 07:53 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8f6ce6f1049b 7170463: C2 should recognize "obj.getClass() == A.class" code pattern Summary: optimize this code pattern obj.getClass() == A.class. Reviewed-by: jrose, kvn Contributed-by: Krystal Mok ! src/share/vm/opto/parse.hpp ! src/share/vm/opto/parse2.cpp ! src/share/vm/opto/subnode.cpp Changeset: 4d8787136e08 Author: twisti Date: 2012-05-25 11:39 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4d8787136e08 7170145: C1 doesn't respect the JMM with volatile field loads Reviewed-by: kvn, roland ! src/share/vm/c1/c1_ValueMap.hpp Changeset: c8289830e172 Author: twisti Date: 2012-05-30 12:17 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c8289830e172 7172843: C1: fix "assert(has_printable_bci()) failed: _printable_bci should have been set" Reviewed-by: twisti Contributed-by: Krystal Mok ! src/share/vm/c1/c1_Canonicalizer.cpp ! src/share/vm/c1/c1_Instruction.hpp Changeset: 7bc2d5136f54 Author: amurillo Date: 2012-06-01 11:25 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7bc2d5136f54 7173635: jprt.properties should include release jdk7u6 Reviewed-by: jcoomes ! make/jprt.properties Changeset: 8f37087fc13f Author: roland Date: 2012-06-05 10:15 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8f37087fc13f 7171890: C1: add Class.isInstance intrinsic Summary: Class.cast which calls Class.isInstance is heavily used by the new JSR 292 implementation Reviewed-by: roland Contributed-by: Krystal Mok ! src/share/vm/c1/c1_Canonicalizer.cpp ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/c1/c1_LIRGenerator.hpp ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/c1/c1_Runtime1.hpp Changeset: e1635876b206 Author: twisti Date: 2012-06-06 15:57 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e1635876b206 7174884: C1: failures after 7171890: assert(cur_state != NULL) failed: state_before must be set Reviewed-by: kvn ! src/share/vm/c1/c1_Canonicalizer.cpp Changeset: 829ee34e7cbd Author: kvn Date: 2012-06-11 08:35 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/829ee34e7cbd Merge ! make/jprt.properties Changeset: ccaa67adfe5b Author: twisti Date: 2012-06-11 16:47 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ccaa67adfe5b 7063674: Wrong results from basic comparisons after calls to Long.bitCount(long) Reviewed-by: kvn ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad Changeset: 0919b2e7895d Author: kvn Date: 2012-06-11 14:58 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/0919b2e7895d 7174510: 19 JCK compiler tests fail with C2 error: memNode.cpp:812 - ShouldNotReachHere Summary: Add missing check for EncodeP node in MemNode::Ideal_common_DU_postCCP() method. Reviewed-by: twisti ! src/share/vm/opto/memnode.cpp Changeset: d5dded5d1e0d Author: kvn Date: 2012-06-11 22:38 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d5dded5d1e0d Merge Changeset: e7715c222897 Author: roland Date: 2012-06-12 10:02 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e7715c222897 7174532: jdk/test/java/lang/Math/WorstCaseTests.java failing on x86 Summary: increase precision on x86 for the steps of the computation of exp and pow. Reviewed-by: kvn ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp Changeset: 121e5708ae96 Author: kvn Date: 2012-06-12 09:47 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/121e5708ae96 7169782: C2: SIGSEGV in LShiftLNode::Ideal(PhaseGVN*, bool) Summary: keep intermediate node alive till the end of the graph construction using dummy hook node trick Reviewed-by: kvn, twisti Contributed-by: vladimir.x.ivanov at oracle.com ! src/share/vm/opto/divnode.cpp + test/compiler/6732154/Test6732154.java + test/compiler/7169782/Test7169782.java Changeset: 8b0a4867acf0 Author: twisti Date: 2012-06-12 14:31 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8b0a4867acf0 7174218: remove AtomicLongCSImpl intrinsics Reviewed-by: kvn, twisti Contributed-by: Krystal Mok ! src/cpu/sparc/vm/c1_LIRGenerator_sparc.cpp ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/adlc/forms.cpp ! src/share/vm/adlc/formssel.cpp ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/c1/c1_LIRGenerator.hpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/opto/classes.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/memnode.hpp ! src/share/vm/prims/jvm.h ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 5e990493719e Author: kvn Date: 2012-06-12 16:23 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5e990493719e 7173340: C2: code cleanup: use PhaseIterGVN::replace_edge(Node*, int, Node*) where applicable Summary: replace frequent C2 optimizer code patterns with new methods calls Reviewed-by: kvn, twisti Contributed-by: vladimir.x.ivanov at oracle.com ! src/share/vm/opto/domgraph.cpp ! src/share/vm/opto/ifnode.cpp ! src/share/vm/opto/loopPredicate.cpp ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/loopUnswitch.cpp ! src/share/vm/opto/loopnode.cpp ! src/share/vm/opto/loopopts.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/phaseX.hpp ! src/share/vm/opto/split_if.cpp ! src/share/vm/opto/superword.cpp Changeset: e2fe93124108 Author: twisti Date: 2012-06-13 11:36 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e2fe93124108 7174928: JSR 292: unresolved invokedynamic call sites deopt and osr infinitely Reviewed-by: kvn ! src/cpu/sparc/vm/c1_LIRGenerator_sparc.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/oops/methodOop.cpp ! src/share/vm/oops/methodOop.hpp Changeset: eba1d5bce9e8 Author: kvn Date: 2012-06-14 14:59 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/eba1d5bce9e8 Merge ! src/share/vm/oops/methodOop.cpp ! src/share/vm/oops/methodOop.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 5ba29a1db46e Author: amurillo Date: 2012-06-15 14:07 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5ba29a1db46e Merge Changeset: 831e5c76a20a Author: amurillo Date: 2012-06-15 14:07 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/831e5c76a20a Added tag hs24-b14 for changeset 5ba29a1db46e ! .hgtags Changeset: 0976e71907b9 Author: katleman Date: 2012-06-21 17:07 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/0976e71907b9 Added tag jdk8-b44 for changeset 831e5c76a20a ! .hgtags Changeset: 1e76463170b3 Author: kamg Date: 2012-03-29 18:55 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1e76463170b3 7110720: Issue with vm config file loadingIssue with vm config file loading Summary: disabling default config files if -XX:-ReadDefaultConfigFiles Reviewed-by: phh, jrose, dcubed, dholmes ! src/share/vm/compiler/compilerOracle.cpp ! src/share/vm/compiler/compilerOracle.hpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/runtime/arguments.cpp + test/runtime/7110720/Test7110720.sh Changeset: e778c29768e6 Author: never Date: 2012-04-04 20:44 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e778c29768e6 7152811: Issues in client compiler Reviewed-by: kvn, jrose ! src/share/vm/ci/ciField.cpp ! src/share/vm/ci/ciField.hpp Changeset: 958bb4b7be49 Author: asaha Date: 2012-04-10 10:42 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/958bb4b7be49 Merge ! src/share/vm/runtime/arguments.cpp Changeset: aa07e41a9f80 Author: never Date: 2012-04-12 12:07 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/aa07e41a9f80 7160677: missing else in fix for 7152811 Reviewed-by: kvn, kevinw ! src/share/vm/ci/ciField.cpp Changeset: 5142b5110214 Author: asaha Date: 2012-05-08 07:29 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5142b5110214 Merge ! src/share/vm/opto/runtime.cpp Changeset: d558e01a72c0 Author: kamg Date: 2012-05-03 15:37 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d558e01a72c0 7160757: Problem with hotspot/runtime_classfile Summary: Allow only current and super invokespecials of Reviewed-by: never, coleenp, dcubed ! src/share/vm/classfile/verifier.cpp + test/runtime/7160757/Test7160757.java Changeset: 6d2c830e025d Author: asaha Date: 2012-05-08 11:29 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6d2c830e025d Merge Changeset: 84e198dc2474 Author: asaha Date: 2012-05-21 14:56 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/84e198dc2474 Merge - src/share/vm/gc_implementation/concurrentMarkSweep/binaryTreeDictionary.cpp - src/share/vm/gc_implementation/concurrentMarkSweep/binaryTreeDictionary.hpp - src/share/vm/gc_implementation/concurrentMarkSweep/freeBlockDictionary.cpp - src/share/vm/gc_implementation/concurrentMarkSweep/freeBlockDictionary.hpp - src/share/vm/gc_implementation/concurrentMarkSweep/freeList.cpp - src/share/vm/gc_implementation/concurrentMarkSweep/freeList.hpp ! src/share/vm/runtime/arguments.cpp Changeset: f9d57285de70 Author: asaha Date: 2012-06-07 12:30 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f9d57285de70 Merge ! src/share/vm/runtime/arguments.cpp Changeset: 9d5f20961bc5 Author: lana Date: 2012-06-26 10:27 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9d5f20961bc5 Merge ! src/share/vm/classfile/verifier.cpp From lana.steuck at oracle.com Wed Jun 27 07:16:52 2012 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 27 Jun 2012 07:16:52 +0000 Subject: hg: jdk8/tl/jdk: 36 new changesets Message-ID: <20120627072323.5563547B4D@hg.openjdk.java.net> Changeset: 9d88f2ce6338 Author: katleman Date: 2012-06-21 17:08 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9d88f2ce6338 Added tag jdk8-b44 for changeset db471a7af031 ! .hgtags Changeset: eb50eeb2eb7d Author: prr Date: 2012-06-13 12:46 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/eb50eeb2eb7d 7027300: Unsynchronized HashMap access causes endless loop Reviewed-by: bae, jgodinez ! src/share/classes/sun/font/SunLayoutEngine.java Changeset: 5959fec806d8 Author: bae Date: 2012-06-14 11:14 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5959fec806d8 7153693: Three 2D_ImageIO tests failed due ImageFormatException on OEL 6.* Unbreakable Kernel x64 Reviewed-by: jgodinez, prr ! src/share/native/sun/awt/image/jpeg/jpegdecoder.c Changeset: 2aa89f018a2f Author: prr Date: 2012-06-14 16:34 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2aa89f018a2f 7158366: [macosx] Print-to-file dialog doesn't have an entry field for a name Reviewed-by: bae, jgodinez ! src/share/classes/sun/print/ServiceDialog.java Changeset: e42563f8ec12 Author: lana Date: 2012-06-17 22:07 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e42563f8ec12 Merge - makefiles/altclasses/Makefile - makefiles/apple/Makefile - makefiles/apple/applescript/Makefile - makefiles/com/Makefile - makefiles/com/apple/Makefile - makefiles/com/apple/osx/Makefile - makefiles/com/apple/osxui/Makefile - makefiles/com/oracle/Makefile - makefiles/com/oracle/jfr/Makefile - makefiles/com/oracle/security/ucrypto/FILES_c.gmk - makefiles/com/oracle/security/ucrypto/Makefile - makefiles/com/oracle/security/ucrypto/mapfile-vers - makefiles/com/sun/Makefile - makefiles/common/shared/Defs-utils.gmk - makefiles/java/fdlibm/FILES_c.gmk - makefiles/java/fdlibm/Makefile - makefiles/java/instrument/Makefile - makefiles/java/instrument/mapfile-vers - makefiles/java/java/Exportedfiles.gmk - makefiles/java/java/FILES_c.gmk - makefiles/java/java/FILES_java.gmk - makefiles/java/java/Makefile - makefiles/java/java/localelist.sh - makefiles/java/java/mapfile-vers - makefiles/java/java/reflect/Makefile - makefiles/java/java/reorder-i586 - makefiles/java/java/reorder-sparc - makefiles/java/java/reorder-sparcv9 - makefiles/java/java_crw_demo/Makefile - makefiles/java/java_crw_demo/mapfile-vers - makefiles/java/java_hprof_demo/Makefile - makefiles/java/java_hprof_demo/mapfile-vers - makefiles/java/jexec/Makefile - makefiles/java/jli/Makefile - makefiles/java/jli/mapfile-vers - makefiles/java/jobjc/Makefile - makefiles/java/jvm/Makefile - makefiles/java/main/Makefile - makefiles/java/main/java/Makefile - makefiles/java/main/java/mapfile-amd64 - makefiles/java/main/java/mapfile-i586 - makefiles/java/main/java/mapfile-sparc - makefiles/java/main/java/mapfile-sparcv9 - makefiles/java/main/javaw/Makefile - makefiles/java/management/Exportedfiles.gmk - makefiles/java/management/FILES_c.gmk - makefiles/java/management/Makefile - makefiles/java/management/mapfile-vers - makefiles/java/net/FILES_c.gmk - makefiles/java/net/Makefile - makefiles/java/net/mapfile-vers - makefiles/java/nio/Exportedfiles.gmk - makefiles/java/nio/FILES_c.gmk - makefiles/java/nio/FILES_java.gmk - makefiles/java/nio/Makefile - makefiles/java/nio/addNotices.sh - makefiles/java/nio/genBuffer.sh - makefiles/java/nio/genCharsetProvider.sh - makefiles/java/nio/genCoder.sh - makefiles/java/nio/genExceptions.sh - makefiles/java/nio/mapfile-bsd - makefiles/java/nio/mapfile-linux - makefiles/java/nio/mapfile-solaris - makefiles/java/nio/reorder-i586 - makefiles/java/nio/reorder-sparc - makefiles/java/nio/reorder-sparcv9 - makefiles/java/npt/Makefile - makefiles/java/npt/mapfile-vers - makefiles/java/redist/fonts/Makefile - makefiles/java/security/Makefile - makefiles/java/sun_nio/FILES_java.gmk - makefiles/java/sun_nio/Makefile - makefiles/java/util/FILES_java.gmk - makefiles/java/util/FILES_properties.gmk - makefiles/java/util/Makefile - makefiles/java/verify/Makefile - makefiles/java/verify/mapfile-vers - makefiles/java/verify/reorder-i586 - makefiles/java/verify/reorder-sparc - makefiles/java/verify/reorder-sparcv9 - makefiles/javax/Makefile - makefiles/javax/imageio/Makefile - makefiles/javax/management/Makefile - makefiles/javax/sound/FILES_c.gmk - makefiles/javax/sound/Makefile - makefiles/javax/sound/SoundDefs.gmk - makefiles/javax/sound/jsoundalsa/Makefile - makefiles/javax/sound/jsoundalsa/mapfile-vers - makefiles/javax/sound/jsoundds/Makefile - makefiles/javax/sound/mapfile-vers - makefiles/javax/sql/Makefile - makefiles/javax/swing/FILES.gmk - makefiles/javax/swing/Makefile - makefiles/javax/swing/beaninfo/FILES.gmk - makefiles/javax/swing/beaninfo/Makefile - makefiles/javax/swing/beaninfo/SwingBeans.gmk - makefiles/javax/swing/beaninfo/manifest - makefiles/javax/swing/html32dtd/Makefile - makefiles/javax/swing/plaf/FILES.gmk - makefiles/javax/swing/plaf/Makefile - makefiles/sun/Makefile - makefiles/sun/awt/CondenseRules.awk - makefiles/sun/awt/Depend.mak - makefiles/sun/awt/Depend.sed - makefiles/sun/awt/FILES_c_macosx.gmk - makefiles/sun/awt/FILES_c_unix.gmk - makefiles/sun/awt/FILES_c_windows.gmk - makefiles/sun/awt/FILES_export_macosx.gmk - makefiles/sun/awt/FILES_export_unix.gmk - makefiles/sun/awt/FILES_export_windows.gmk - makefiles/sun/awt/Makefile - makefiles/sun/awt/README - makefiles/sun/awt/make.depend - makefiles/sun/awt/mapfile-mawt-vers - makefiles/sun/awt/mapfile-vers - makefiles/sun/awt/mapfile-vers-linux - makefiles/sun/awt/mawt.gmk - makefiles/sun/cmm/Makefile - makefiles/sun/cmm/kcms/FILES_c_unix.gmk - makefiles/sun/cmm/kcms/FILES_c_windows.gmk - makefiles/sun/cmm/kcms/Makefile - makefiles/sun/cmm/kcms/mapfile-vers - makefiles/sun/dcpr/FILES_c.gmk - makefiles/sun/dcpr/Makefile - makefiles/sun/dcpr/mapfile-vers - makefiles/sun/headless/Makefile - makefiles/sun/headless/mapfile-vers - makefiles/sun/headless/reorder-i586 - makefiles/sun/headless/reorder-sparc - makefiles/sun/headless/reorder-sparcv9 - makefiles/sun/image/Makefile - makefiles/sun/image/generic/FILES_c.gmk - makefiles/sun/image/generic/Makefile - makefiles/sun/image/generic/mapfile-vers - makefiles/sun/image/vis/FILES_c.gmk - makefiles/sun/image/vis/Makefile - makefiles/sun/javazic/Makefile - makefiles/sun/jdbc/Makefile - makefiles/sun/jdga/Makefile - makefiles/sun/jdga/mapfile-vers - makefiles/sun/lwawt/FILES_c_macosx.gmk - makefiles/sun/lwawt/FILES_export_macosx.gmk - makefiles/sun/lwawt/Makefile - makefiles/sun/nio/Makefile - makefiles/sun/nio/cs/FILES_java.gmk - makefiles/sun/nio/cs/Makefile - makefiles/sun/org/Makefile - makefiles/sun/org/mozilla/Makefile - makefiles/sun/org/mozilla/javascript/Makefile - makefiles/sun/osxapp/Makefile - makefiles/sun/security/Makefile - makefiles/sun/security/ec/FILES_c.gmk - makefiles/sun/security/ec/mapfile-vers - makefiles/sun/security/jgss/Makefile - makefiles/sun/security/jgss/wrapper/FILES_c.gmk - makefiles/sun/security/jgss/wrapper/Makefile - makefiles/sun/security/jgss/wrapper/mapfile-vers - makefiles/sun/security/krb5/FILES_c_windows.gmk - makefiles/sun/security/krb5/Makefile - makefiles/sun/security/mscapi/FILES_cpp.gmk - makefiles/sun/security/mscapi/Makefile - makefiles/sun/security/other/Makefile - makefiles/sun/security/smartcardio/FILES_c.gmk - makefiles/sun/security/smartcardio/Makefile - makefiles/sun/security/smartcardio/mapfile-vers - makefiles/sun/security/tools/Makefile - makefiles/sun/security/util/Makefile - makefiles/sun/splashscreen/FILES_c.gmk - makefiles/sun/splashscreen/Makefile - makefiles/sun/splashscreen/mapfile-vers - makefiles/sun/xawt/FILES_c_unix.gmk - makefiles/sun/xawt/FILES_export_unix.gmk - makefiles/sun/xawt/Makefile - makefiles/sun/xawt/mapfile-vers - src/share/classes/sun/nio/ch/DevPollSelectorProvider.java - src/share/classes/sun/security/provider/certpath/CrlRevocationChecker.java - src/share/classes/sun/security/provider/certpath/OCSPChecker.java - 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/native/java/sql/DriverManager.c - test/sun/security/krb5/auto/ok-as-delegate-xrealm.sh - test/sun/security/krb5/auto/ok-as-delegate.sh Changeset: b8ff85860648 Author: prr Date: 2012-06-19 09:07 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b8ff85860648 7124536: [macosx] PrintServiceLookup.lookupDefaultPrintService() return null Reviewed-by: bae, igor ! src/solaris/classes/sun/print/CUPSPrinter.java ! src/solaris/classes/sun/print/UnixPrintServiceLookup.java Changeset: c05893704c82 Author: lana Date: 2012-06-25 21:34 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c05893704c82 Merge Changeset: 45259658e158 Author: rupashka Date: 2012-06-09 17:42 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/45259658e158 7165725: JAVA6 HTML PARSER CANNOT PARSE MULTIPLE SCRIPT TAGS IN A LINE CORRECTLY Reviewed-by: alexsch ! src/share/classes/javax/swing/text/html/parser/Parser.java + test/javax/swing/text/html/parser/Parser/7165725/bug7165725.java + test/javax/swing/text/html/parser/Parser/7165725/false-text-after-script.html + test/javax/swing/text/html/parser/Parser/7165725/successive-script-tag.html Changeset: 0474e0ed2ef2 Author: kizune Date: 2012-06-09 19:18 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0474e0ed2ef2 7173487: closed/java/awt/Frame/RemoveNotifyTest/RemoveNotifyTest.html Reviewed-by: anthony, dcherepanov, serb ! src/macosx/classes/sun/lwawt/macosx/LWCToolkit.java Changeset: b57167b71169 Author: luchsh Date: 2012-06-11 10:52 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b57167b71169 7155887: ComboBox does not display focus outline in GTK L&F Reviewed-by: rupashka ! src/share/classes/com/sun/java/swing/plaf/gtk/GTKPainter.java Changeset: f05e517a74b3 Author: anthony Date: 2012-06-13 18:33 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f05e517a74b3 7176644: [macosx] Missing NSAutoreleasePool in CGLGraphicsConfig.m OGLGC_DestroyOGLGraphicsConfig Summary: Create and drain an autorelease pool Reviewed-by: anthony, dcherepanov Contributed-by: Tomas Hurka ! src/macosx/native/sun/java2d/opengl/CGLGraphicsConfig.m Changeset: f90369b3d61d Author: alexsch Date: 2012-06-13 18:43 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f90369b3d61d 7150049: [macosx] closed/javax/swing/JCheckBox/4449413/bug4449413.java check the checkbox again,it auto fail Reviewed-by: rupashka + test/javax/swing/JCheckBox/4449413/bug4449413.html + test/javax/swing/JCheckBox/4449413/bug4449413.java Changeset: 8326709c6315 Author: kizune Date: 2012-06-15 18:28 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8326709c6315 7171163: [macosx] Shortcomings in the design of the secondary native event loop made JavaFX DnD deadlock Reviewed-by: anthony, art ! src/macosx/classes/sun/lwawt/macosx/CToolkitThreadBlockedHandler.java ! src/macosx/classes/sun/lwawt/macosx/LWCToolkit.java ! src/macosx/native/sun/awt/LWCToolkit.m ! src/share/classes/sun/awt/dnd/SunDropTargetContextPeer.java Changeset: f709f8ebebd4 Author: lana Date: 2012-06-17 22:03 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f709f8ebebd4 Merge - makefiles/altclasses/Makefile - makefiles/apple/Makefile - makefiles/apple/applescript/Makefile - makefiles/com/Makefile - makefiles/com/apple/Makefile - makefiles/com/apple/osx/Makefile - makefiles/com/apple/osxui/Makefile - makefiles/com/oracle/Makefile - makefiles/com/oracle/jfr/Makefile - makefiles/com/oracle/security/ucrypto/FILES_c.gmk - makefiles/com/oracle/security/ucrypto/Makefile - makefiles/com/oracle/security/ucrypto/mapfile-vers - makefiles/com/sun/Makefile - makefiles/common/shared/Defs-utils.gmk - makefiles/java/fdlibm/FILES_c.gmk - makefiles/java/fdlibm/Makefile - makefiles/java/instrument/Makefile - makefiles/java/instrument/mapfile-vers - makefiles/java/java/Exportedfiles.gmk - makefiles/java/java/FILES_c.gmk - makefiles/java/java/FILES_java.gmk - makefiles/java/java/Makefile - makefiles/java/java/localelist.sh - makefiles/java/java/mapfile-vers - makefiles/java/java/reflect/Makefile - makefiles/java/java/reorder-i586 - makefiles/java/java/reorder-sparc - makefiles/java/java/reorder-sparcv9 - makefiles/java/java_crw_demo/Makefile - makefiles/java/java_crw_demo/mapfile-vers - makefiles/java/java_hprof_demo/Makefile - makefiles/java/java_hprof_demo/mapfile-vers - makefiles/java/jexec/Makefile - makefiles/java/jli/Makefile - makefiles/java/jli/mapfile-vers - makefiles/java/jobjc/Makefile - makefiles/java/jvm/Makefile - makefiles/java/main/Makefile - makefiles/java/main/java/Makefile - makefiles/java/main/java/mapfile-amd64 - makefiles/java/main/java/mapfile-i586 - makefiles/java/main/java/mapfile-sparc - makefiles/java/main/java/mapfile-sparcv9 - makefiles/java/main/javaw/Makefile - makefiles/java/management/Exportedfiles.gmk - makefiles/java/management/FILES_c.gmk - makefiles/java/management/Makefile - makefiles/java/management/mapfile-vers - makefiles/java/net/FILES_c.gmk - makefiles/java/net/Makefile - makefiles/java/net/mapfile-vers - makefiles/java/nio/Exportedfiles.gmk - makefiles/java/nio/FILES_c.gmk - makefiles/java/nio/FILES_java.gmk - makefiles/java/nio/Makefile - makefiles/java/nio/addNotices.sh - makefiles/java/nio/genBuffer.sh - makefiles/java/nio/genCharsetProvider.sh - makefiles/java/nio/genCoder.sh - makefiles/java/nio/genExceptions.sh - makefiles/java/nio/mapfile-bsd - makefiles/java/nio/mapfile-linux - makefiles/java/nio/mapfile-solaris - makefiles/java/nio/reorder-i586 - makefiles/java/nio/reorder-sparc - makefiles/java/nio/reorder-sparcv9 - makefiles/java/npt/Makefile - makefiles/java/npt/mapfile-vers - makefiles/java/redist/fonts/Makefile - makefiles/java/security/Makefile - makefiles/java/sun_nio/FILES_java.gmk - makefiles/java/sun_nio/Makefile - makefiles/java/util/FILES_java.gmk - makefiles/java/util/FILES_properties.gmk - makefiles/java/util/Makefile - makefiles/java/verify/Makefile - makefiles/java/verify/mapfile-vers - makefiles/java/verify/reorder-i586 - makefiles/java/verify/reorder-sparc - makefiles/java/verify/reorder-sparcv9 - makefiles/javax/Makefile - makefiles/javax/imageio/Makefile - makefiles/javax/management/Makefile - makefiles/javax/sound/FILES_c.gmk - makefiles/javax/sound/Makefile - makefiles/javax/sound/SoundDefs.gmk - makefiles/javax/sound/jsoundalsa/Makefile - makefiles/javax/sound/jsoundalsa/mapfile-vers - makefiles/javax/sound/jsoundds/Makefile - makefiles/javax/sound/mapfile-vers - makefiles/javax/sql/Makefile - makefiles/javax/swing/FILES.gmk - makefiles/javax/swing/Makefile - makefiles/javax/swing/beaninfo/FILES.gmk - makefiles/javax/swing/beaninfo/Makefile - makefiles/javax/swing/beaninfo/SwingBeans.gmk - makefiles/javax/swing/beaninfo/manifest - makefiles/javax/swing/html32dtd/Makefile - makefiles/javax/swing/plaf/FILES.gmk - makefiles/javax/swing/plaf/Makefile - makefiles/sun/Makefile - makefiles/sun/awt/CondenseRules.awk - makefiles/sun/awt/Depend.mak - makefiles/sun/awt/Depend.sed - makefiles/sun/awt/FILES_c_macosx.gmk - makefiles/sun/awt/FILES_c_unix.gmk - makefiles/sun/awt/FILES_c_windows.gmk - makefiles/sun/awt/FILES_export_macosx.gmk - makefiles/sun/awt/FILES_export_unix.gmk - makefiles/sun/awt/FILES_export_windows.gmk - makefiles/sun/awt/Makefile - makefiles/sun/awt/README - makefiles/sun/awt/make.depend - makefiles/sun/awt/mapfile-mawt-vers - makefiles/sun/awt/mapfile-vers - makefiles/sun/awt/mapfile-vers-linux - makefiles/sun/awt/mawt.gmk - makefiles/sun/cmm/Makefile - makefiles/sun/cmm/kcms/FILES_c_unix.gmk - makefiles/sun/cmm/kcms/FILES_c_windows.gmk - makefiles/sun/cmm/kcms/Makefile - makefiles/sun/cmm/kcms/mapfile-vers - makefiles/sun/dcpr/FILES_c.gmk - makefiles/sun/dcpr/Makefile - makefiles/sun/dcpr/mapfile-vers - makefiles/sun/headless/Makefile - makefiles/sun/headless/mapfile-vers - makefiles/sun/headless/reorder-i586 - makefiles/sun/headless/reorder-sparc - makefiles/sun/headless/reorder-sparcv9 - makefiles/sun/image/Makefile - makefiles/sun/image/generic/FILES_c.gmk - makefiles/sun/image/generic/Makefile - makefiles/sun/image/generic/mapfile-vers - makefiles/sun/image/vis/FILES_c.gmk - makefiles/sun/image/vis/Makefile - makefiles/sun/javazic/Makefile - makefiles/sun/jdbc/Makefile - makefiles/sun/jdga/Makefile - makefiles/sun/jdga/mapfile-vers - makefiles/sun/lwawt/FILES_c_macosx.gmk - makefiles/sun/lwawt/FILES_export_macosx.gmk - makefiles/sun/lwawt/Makefile - makefiles/sun/nio/Makefile - makefiles/sun/nio/cs/FILES_java.gmk - makefiles/sun/nio/cs/Makefile - makefiles/sun/org/Makefile - makefiles/sun/org/mozilla/Makefile - makefiles/sun/org/mozilla/javascript/Makefile - makefiles/sun/osxapp/Makefile - makefiles/sun/security/Makefile - makefiles/sun/security/ec/FILES_c.gmk - makefiles/sun/security/ec/mapfile-vers - makefiles/sun/security/jgss/Makefile - makefiles/sun/security/jgss/wrapper/FILES_c.gmk - makefiles/sun/security/jgss/wrapper/Makefile - makefiles/sun/security/jgss/wrapper/mapfile-vers - makefiles/sun/security/krb5/FILES_c_windows.gmk - makefiles/sun/security/krb5/Makefile - makefiles/sun/security/mscapi/FILES_cpp.gmk - makefiles/sun/security/mscapi/Makefile - makefiles/sun/security/other/Makefile - makefiles/sun/security/smartcardio/FILES_c.gmk - makefiles/sun/security/smartcardio/Makefile - makefiles/sun/security/smartcardio/mapfile-vers - makefiles/sun/security/tools/Makefile - makefiles/sun/security/util/Makefile - makefiles/sun/splashscreen/FILES_c.gmk - makefiles/sun/splashscreen/Makefile - makefiles/sun/splashscreen/mapfile-vers - makefiles/sun/xawt/FILES_c_unix.gmk - makefiles/sun/xawt/FILES_export_unix.gmk - makefiles/sun/xawt/Makefile - makefiles/sun/xawt/mapfile-vers - src/share/classes/sun/nio/ch/DevPollSelectorProvider.java - src/share/classes/sun/security/provider/certpath/CrlRevocationChecker.java - src/share/classes/sun/security/provider/certpath/OCSPChecker.java - 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/native/java/sql/DriverManager.c - test/sun/security/krb5/auto/ok-as-delegate-xrealm.sh - test/sun/security/krb5/auto/ok-as-delegate.sh Changeset: 4b470e9017da Author: alexsch Date: 2012-06-18 15:39 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4b470e9017da 7174970: NLS [ccjk] Extra mnemonic keys at standard filechooserdialog (open and save) in metal L&F Reviewed-by: rupashka ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_de.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_es.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_fr.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_it.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_ja.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_ko.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_pt_BR.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_sv.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_zh_CN.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_zh_TW.properties ! src/share/classes/com/sun/swing/internal/plaf/metal/resources/metal.properties ! src/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_de.properties ! src/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_es.properties ! src/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_fr.properties ! src/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_it.properties ! src/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_ja.properties ! src/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_ko.properties ! src/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_pt_BR.properties ! src/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_sv.properties ! src/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_zh_CN.properties ! src/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_zh_TW.properties Changeset: 3226f1968e77 Author: kizune Date: 2012-06-19 21:09 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3226f1968e77 7172430: [macosx] debug message in non debug jdk build Reviewed-by: anthony, serb ! src/macosx/native/sun/awt/AWTView.m Changeset: e7dc778d768e Author: anthony Date: 2012-06-22 16:32 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e7dc778d768e 7170716: JVM crash when opening an AWT app from a registered file. Summary: Copy the queued blocks to prevent their deallocation Reviewed-by: anthony, swingler Contributed-by: Marco Dinacci ! src/macosx/native/sun/osxapp/QueuingApplicationDelegate.h ! src/macosx/native/sun/osxapp/QueuingApplicationDelegate.m Changeset: cafcc94a11a7 Author: anthony Date: 2012-06-25 17:27 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cafcc94a11a7 7174718: [macosx] Regression in 7u6 b12: PopupFactory leaks DefaultFrames. Summary: Fix memory management Reviewed-by: art, serb ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java ! src/macosx/native/sun/awt/AWTWindow.m Changeset: 6dae09c6759e Author: lana Date: 2012-06-25 21:36 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6dae09c6759e Merge Changeset: b76779abcd7f Author: lana Date: 2012-06-25 21:38 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b76779abcd7f Merge Changeset: bff59bf994da Author: mullan Date: 2012-02-22 15:38 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bff59bf994da 7145239: Finetune package definition restriction Reviewed-by: hawtin ! src/share/lib/security/java.security ! src/share/lib/security/java.security-solaris ! src/share/lib/security/java.security-windows Changeset: 1d8a3ef381f7 Author: bae Date: 2012-02-28 10:44 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1d8a3ef381f7 7143617: Improve fontmanager layout lookup operations Reviewed-by: igor, prr, mschoene ! src/share/native/sun/font/layout/LookupProcessor.cpp ! src/share/native/sun/font/layout/LookupProcessor.h Changeset: 9e6e535a6769 Author: rupashka Date: 2012-02-28 16:09 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9e6e535a6769 7143614: SynthLookAndFeel stability improvement Reviewed-by: malenkov ! src/share/classes/javax/swing/plaf/synth/SynthButtonUI.java ! src/share/classes/javax/swing/plaf/synth/SynthLabelUI.java ! src/share/classes/javax/swing/plaf/synth/SynthLookAndFeel.java + test/javax/swing/plaf/synth/7143614/bug7143614.java Changeset: 8516c5b4521b Author: weijun Date: 2012-02-29 14:06 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8516c5b4521b 7143872: Improve certificate extension processing Reviewed-by: mullan ! src/share/classes/sun/security/x509/CRLExtensions.java ! src/share/classes/sun/security/x509/CertificateExtensions.java ! src/share/classes/sun/security/x509/X509CRLEntryImpl.java ! src/share/classes/sun/security/x509/X509CRLImpl.java ! src/share/classes/sun/security/x509/X509CertImpl.java + test/sun/security/x509/X509CRLImpl/OrderAndDup.java Changeset: 3640f1a043f8 Author: coffeys Date: 2012-03-26 14:03 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3640f1a043f8 7143851: Improve IIOP stub and tie generation in RMIC 7149048: Changes to corba rmic stubGenerator class are not used during jdk build process Reviewed-by: mschoene, robm ! make/com/sun/jmx/Makefile Changeset: 9de49289df0f Author: asaha Date: 2012-04-10 10:44 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9de49289df0f Merge ! make/com/oracle/net/Makefile - make/sun/motif12/reorder-i586 - make/sun/motif12/reorder-sparc - make/sun/motif12/reorder-sparcv9 ! make/sun/rmi/rmi/mapfile-vers - src/linux/doc/man/apt.1 - src/linux/doc/man/ja/apt.1 - src/share/classes/com/sun/tools/jdi/LinkedHashMap.java - src/share/classes/java/lang/invoke/FilterGeneric.java - src/share/classes/java/lang/invoke/FilterOneArgument.java - src/share/classes/java/lang/invoke/FromGeneric.java - src/share/classes/java/lang/invoke/SpreadGeneric.java - src/share/classes/java/lang/invoke/ToGeneric.java - src/share/classes/java/util/XMLUtils.java - src/share/classes/sun/awt/FocusingTextField.java - src/share/classes/sun/awt/HorizBagLayout.java - src/share/classes/sun/awt/OrientableFlowLayout.java - src/share/classes/sun/awt/VariableGridLayout.java - src/share/classes/sun/awt/VerticalBagLayout.java - src/share/classes/sun/io/ByteToCharASCII.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/ByteToCharConverter.java - src/share/classes/sun/io/ByteToCharCp037.java - src/share/classes/sun/io/ByteToCharCp1006.java - src/share/classes/sun/io/ByteToCharCp1025.java - src/share/classes/sun/io/ByteToCharCp1026.java - src/share/classes/sun/io/ByteToCharCp1046.java - src/share/classes/sun/io/ByteToCharCp1047.java - src/share/classes/sun/io/ByteToCharCp1097.java - src/share/classes/sun/io/ByteToCharCp1098.java - src/share/classes/sun/io/ByteToCharCp1112.java - src/share/classes/sun/io/ByteToCharCp1122.java - src/share/classes/sun/io/ByteToCharCp1123.java - src/share/classes/sun/io/ByteToCharCp1124.java - src/share/classes/sun/io/ByteToCharCp1140.java - src/share/classes/sun/io/ByteToCharCp1141.java - src/share/classes/sun/io/ByteToCharCp1142.java - src/share/classes/sun/io/ByteToCharCp1143.java - src/share/classes/sun/io/ByteToCharCp1144.java - src/share/classes/sun/io/ByteToCharCp1145.java - src/share/classes/sun/io/ByteToCharCp1146.java - src/share/classes/sun/io/ByteToCharCp1147.java - src/share/classes/sun/io/ByteToCharCp1148.java - src/share/classes/sun/io/ByteToCharCp1149.java - src/share/classes/sun/io/ByteToCharCp1250.java - src/share/classes/sun/io/ByteToCharCp1251.java - src/share/classes/sun/io/ByteToCharCp1252.java - src/share/classes/sun/io/ByteToCharCp1253.java - src/share/classes/sun/io/ByteToCharCp1254.java - src/share/classes/sun/io/ByteToCharCp1255.java - src/share/classes/sun/io/ByteToCharCp1256.java - src/share/classes/sun/io/ByteToCharCp1257.java - src/share/classes/sun/io/ByteToCharCp1258.java - src/share/classes/sun/io/ByteToCharCp1381.java - src/share/classes/sun/io/ByteToCharCp1383.java - src/share/classes/sun/io/ByteToCharCp273.java - src/share/classes/sun/io/ByteToCharCp277.java - src/share/classes/sun/io/ByteToCharCp278.java - src/share/classes/sun/io/ByteToCharCp280.java - src/share/classes/sun/io/ByteToCharCp284.java - src/share/classes/sun/io/ByteToCharCp285.java - src/share/classes/sun/io/ByteToCharCp297.java - src/share/classes/sun/io/ByteToCharCp33722.java - src/share/classes/sun/io/ByteToCharCp420.java - src/share/classes/sun/io/ByteToCharCp424.java - src/share/classes/sun/io/ByteToCharCp437.java - src/share/classes/sun/io/ByteToCharCp500.java - src/share/classes/sun/io/ByteToCharCp737.java - src/share/classes/sun/io/ByteToCharCp775.java - src/share/classes/sun/io/ByteToCharCp833.java - src/share/classes/sun/io/ByteToCharCp834.java - src/share/classes/sun/io/ByteToCharCp838.java - src/share/classes/sun/io/ByteToCharCp850.java - src/share/classes/sun/io/ByteToCharCp852.java - src/share/classes/sun/io/ByteToCharCp855.java - src/share/classes/sun/io/ByteToCharCp856.java - src/share/classes/sun/io/ByteToCharCp857.java - src/share/classes/sun/io/ByteToCharCp858.java - src/share/classes/sun/io/ByteToCharCp860.java - src/share/classes/sun/io/ByteToCharCp861.java - src/share/classes/sun/io/ByteToCharCp862.java - src/share/classes/sun/io/ByteToCharCp863.java - src/share/classes/sun/io/ByteToCharCp864.java - src/share/classes/sun/io/ByteToCharCp865.java - src/share/classes/sun/io/ByteToCharCp866.java - src/share/classes/sun/io/ByteToCharCp868.java - src/share/classes/sun/io/ByteToCharCp869.java - src/share/classes/sun/io/ByteToCharCp870.java - src/share/classes/sun/io/ByteToCharCp871.java - src/share/classes/sun/io/ByteToCharCp874.java - src/share/classes/sun/io/ByteToCharCp875.java - src/share/classes/sun/io/ByteToCharCp918.java - src/share/classes/sun/io/ByteToCharCp921.java - src/share/classes/sun/io/ByteToCharCp922.java - src/share/classes/sun/io/ByteToCharCp930.java - src/share/classes/sun/io/ByteToCharCp933.java - src/share/classes/sun/io/ByteToCharCp935.java - src/share/classes/sun/io/ByteToCharCp937.java - src/share/classes/sun/io/ByteToCharCp939.java - src/share/classes/sun/io/ByteToCharCp942.java - src/share/classes/sun/io/ByteToCharCp942C.java - src/share/classes/sun/io/ByteToCharCp943.java - src/share/classes/sun/io/ByteToCharCp943C.java - src/share/classes/sun/io/ByteToCharCp948.java - src/share/classes/sun/io/ByteToCharCp949.java - src/share/classes/sun/io/ByteToCharCp949C.java - src/share/classes/sun/io/ByteToCharCp950.java - src/share/classes/sun/io/ByteToCharCp964.java - src/share/classes/sun/io/ByteToCharCp970.java - src/share/classes/sun/io/ByteToCharDBCS_ASCII.java - src/share/classes/sun/io/ByteToCharDBCS_EBCDIC.java - src/share/classes/sun/io/ByteToCharDoubleByte.java - src/share/classes/sun/io/ByteToCharEUC.java - src/share/classes/sun/io/ByteToCharEUC2.java - src/share/classes/sun/io/ByteToCharEUC_CN.java - src/share/classes/sun/io/ByteToCharEUC_JP.java - src/share/classes/sun/io/ByteToCharEUC_JP_LINUX.java - src/share/classes/sun/io/ByteToCharEUC_JP_Solaris.java - src/share/classes/sun/io/ByteToCharEUC_KR.java - src/share/classes/sun/io/ByteToCharEUC_TW.java - src/share/classes/sun/io/ByteToCharGB18030.java - src/share/classes/sun/io/ByteToCharGB18030DB.java - src/share/classes/sun/io/ByteToCharGBK.java - src/share/classes/sun/io/ByteToCharISCII91.java - src/share/classes/sun/io/ByteToCharISO2022.java - src/share/classes/sun/io/ByteToCharISO2022CN.java - src/share/classes/sun/io/ByteToCharISO2022JP.java - src/share/classes/sun/io/ByteToCharISO2022KR.java - src/share/classes/sun/io/ByteToCharISO8859_1.java - src/share/classes/sun/io/ByteToCharISO8859_13.java - src/share/classes/sun/io/ByteToCharISO8859_15.java - src/share/classes/sun/io/ByteToCharISO8859_2.java - src/share/classes/sun/io/ByteToCharISO8859_3.java - src/share/classes/sun/io/ByteToCharISO8859_4.java - src/share/classes/sun/io/ByteToCharISO8859_5.java - src/share/classes/sun/io/ByteToCharISO8859_6.java - src/share/classes/sun/io/ByteToCharISO8859_7.java - src/share/classes/sun/io/ByteToCharISO8859_8.java - src/share/classes/sun/io/ByteToCharISO8859_9.java - src/share/classes/sun/io/ByteToCharJIS0201.java - src/share/classes/sun/io/ByteToCharJIS0208.java - src/share/classes/sun/io/ByteToCharJIS0208_Solaris.java - src/share/classes/sun/io/ByteToCharJIS0212.java - src/share/classes/sun/io/ByteToCharJIS0212_Solaris.java - src/share/classes/sun/io/ByteToCharJISAutoDetect.java - src/share/classes/sun/io/ByteToCharJohab.java - src/share/classes/sun/io/ByteToCharKOI8_R.java - src/share/classes/sun/io/ByteToCharMS874.java - src/share/classes/sun/io/ByteToCharMS932.java - src/share/classes/sun/io/ByteToCharMS936.java - src/share/classes/sun/io/ByteToCharMS949.java - src/share/classes/sun/io/ByteToCharMS950.java - src/share/classes/sun/io/ByteToCharMS950_HKSCS.java - src/share/classes/sun/io/ByteToCharMacArabic.java - src/share/classes/sun/io/ByteToCharMacCentralEurope.java - src/share/classes/sun/io/ByteToCharMacCroatian.java - src/share/classes/sun/io/ByteToCharMacCyrillic.java - src/share/classes/sun/io/ByteToCharMacDingbat.java - src/share/classes/sun/io/ByteToCharMacGreek.java - src/share/classes/sun/io/ByteToCharMacHebrew.java - src/share/classes/sun/io/ByteToCharMacIceland.java - src/share/classes/sun/io/ByteToCharMacRoman.java - src/share/classes/sun/io/ByteToCharMacRomania.java - src/share/classes/sun/io/ByteToCharMacSymbol.java - src/share/classes/sun/io/ByteToCharMacThai.java - src/share/classes/sun/io/ByteToCharMacTurkish.java - src/share/classes/sun/io/ByteToCharMacUkraine.java - src/share/classes/sun/io/ByteToCharPCK.java - src/share/classes/sun/io/ByteToCharSJIS.java - src/share/classes/sun/io/ByteToCharSingleByte.java - src/share/classes/sun/io/ByteToCharTIS620.java - src/share/classes/sun/io/ByteToCharUTF16.java - src/share/classes/sun/io/ByteToCharUTF8.java - src/share/classes/sun/io/ByteToCharUnicode.java - src/share/classes/sun/io/ByteToCharUnicodeBig.java - src/share/classes/sun/io/ByteToCharUnicodeBigUnmarked.java - src/share/classes/sun/io/ByteToCharUnicodeLittle.java - src/share/classes/sun/io/ByteToCharUnicodeLittleUnmarked.java - src/share/classes/sun/io/CharToByteASCII.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/CharToByteConverter.java - src/share/classes/sun/io/CharToByteCp037.java - src/share/classes/sun/io/CharToByteCp1006.java - src/share/classes/sun/io/CharToByteCp1025.java - src/share/classes/sun/io/CharToByteCp1026.java - src/share/classes/sun/io/CharToByteCp1046.java - src/share/classes/sun/io/CharToByteCp1047.java - src/share/classes/sun/io/CharToByteCp1097.java - src/share/classes/sun/io/CharToByteCp1098.java - src/share/classes/sun/io/CharToByteCp1112.java - src/share/classes/sun/io/CharToByteCp1122.java - src/share/classes/sun/io/CharToByteCp1123.java - src/share/classes/sun/io/CharToByteCp1124.java - src/share/classes/sun/io/CharToByteCp1140.java - src/share/classes/sun/io/CharToByteCp1141.java - src/share/classes/sun/io/CharToByteCp1142.java - src/share/classes/sun/io/CharToByteCp1143.java - src/share/classes/sun/io/CharToByteCp1144.java - src/share/classes/sun/io/CharToByteCp1145.java - src/share/classes/sun/io/CharToByteCp1146.java - src/share/classes/sun/io/CharToByteCp1147.java - src/share/classes/sun/io/CharToByteCp1148.java - src/share/classes/sun/io/CharToByteCp1149.java - src/share/classes/sun/io/CharToByteCp1250.java - src/share/classes/sun/io/CharToByteCp1251.java - src/share/classes/sun/io/CharToByteCp1252.java - src/share/classes/sun/io/CharToByteCp1253.java - src/share/classes/sun/io/CharToByteCp1254.java - src/share/classes/sun/io/CharToByteCp1255.java - src/share/classes/sun/io/CharToByteCp1256.java - src/share/classes/sun/io/CharToByteCp1257.java - src/share/classes/sun/io/CharToByteCp1258.java - src/share/classes/sun/io/CharToByteCp1381.java - src/share/classes/sun/io/CharToByteCp1383.java - src/share/classes/sun/io/CharToByteCp273.java - src/share/classes/sun/io/CharToByteCp277.java - src/share/classes/sun/io/CharToByteCp278.java - src/share/classes/sun/io/CharToByteCp280.java - src/share/classes/sun/io/CharToByteCp284.java - src/share/classes/sun/io/CharToByteCp285.java - src/share/classes/sun/io/CharToByteCp297.java - src/share/classes/sun/io/CharToByteCp33722.java - src/share/classes/sun/io/CharToByteCp420.java - src/share/classes/sun/io/CharToByteCp424.java - src/share/classes/sun/io/CharToByteCp437.java - src/share/classes/sun/io/CharToByteCp500.java - src/share/classes/sun/io/CharToByteCp737.java - src/share/classes/sun/io/CharToByteCp775.java - src/share/classes/sun/io/CharToByteCp833.java - src/share/classes/sun/io/CharToByteCp834.java - src/share/classes/sun/io/CharToByteCp838.java - src/share/classes/sun/io/CharToByteCp850.java - src/share/classes/sun/io/CharToByteCp852.java - src/share/classes/sun/io/CharToByteCp855.java - src/share/classes/sun/io/CharToByteCp856.java - src/share/classes/sun/io/CharToByteCp857.java - src/share/classes/sun/io/CharToByteCp858.java - src/share/classes/sun/io/CharToByteCp860.java - src/share/classes/sun/io/CharToByteCp861.java - src/share/classes/sun/io/CharToByteCp862.java - src/share/classes/sun/io/CharToByteCp863.java - src/share/classes/sun/io/CharToByteCp864.java - src/share/classes/sun/io/CharToByteCp865.java - src/share/classes/sun/io/CharToByteCp866.java - src/share/classes/sun/io/CharToByteCp868.java - src/share/classes/sun/io/CharToByteCp869.java - src/share/classes/sun/io/CharToByteCp870.java - src/share/classes/sun/io/CharToByteCp871.java - src/share/classes/sun/io/CharToByteCp874.java - src/share/classes/sun/io/CharToByteCp875.java - src/share/classes/sun/io/CharToByteCp918.java - src/share/classes/sun/io/CharToByteCp921.java - src/share/classes/sun/io/CharToByteCp922.java - src/share/classes/sun/io/CharToByteCp930.java - src/share/classes/sun/io/CharToByteCp933.java - src/share/classes/sun/io/CharToByteCp935.java - src/share/classes/sun/io/CharToByteCp937.java - src/share/classes/sun/io/CharToByteCp939.java - src/share/classes/sun/io/CharToByteCp942.java - src/share/classes/sun/io/CharToByteCp942C.java - src/share/classes/sun/io/CharToByteCp943.java - src/share/classes/sun/io/CharToByteCp943C.java - src/share/classes/sun/io/CharToByteCp948.java - src/share/classes/sun/io/CharToByteCp949.java - src/share/classes/sun/io/CharToByteCp949C.java - src/share/classes/sun/io/CharToByteCp950.java - src/share/classes/sun/io/CharToByteCp964.java - src/share/classes/sun/io/CharToByteCp970.java - src/share/classes/sun/io/CharToByteDBCS_ASCII.java - src/share/classes/sun/io/CharToByteDBCS_EBCDIC.java - src/share/classes/sun/io/CharToByteDoubleByte.java - src/share/classes/sun/io/CharToByteEUC.java - src/share/classes/sun/io/CharToByteEUC_CN.java - src/share/classes/sun/io/CharToByteEUC_JP.java - src/share/classes/sun/io/CharToByteEUC_JP_LINUX.java - src/share/classes/sun/io/CharToByteEUC_JP_Solaris.java - src/share/classes/sun/io/CharToByteEUC_KR.java - src/share/classes/sun/io/CharToByteEUC_TW.java - src/share/classes/sun/io/CharToByteGB18030.java - src/share/classes/sun/io/CharToByteGBK.java - src/share/classes/sun/io/CharToByteISCII91.java - src/share/classes/sun/io/CharToByteISO2022.java - src/share/classes/sun/io/CharToByteISO2022CN_CNS.java - src/share/classes/sun/io/CharToByteISO2022CN_GB.java - src/share/classes/sun/io/CharToByteISO2022JP.java - src/share/classes/sun/io/CharToByteISO2022KR.java - src/share/classes/sun/io/CharToByteISO8859_1.java - src/share/classes/sun/io/CharToByteISO8859_13.java - src/share/classes/sun/io/CharToByteISO8859_15.java - src/share/classes/sun/io/CharToByteISO8859_2.java - src/share/classes/sun/io/CharToByteISO8859_3.java - src/share/classes/sun/io/CharToByteISO8859_4.java - src/share/classes/sun/io/CharToByteISO8859_5.java - src/share/classes/sun/io/CharToByteISO8859_6.java - src/share/classes/sun/io/CharToByteISO8859_7.java - src/share/classes/sun/io/CharToByteISO8859_8.java - src/share/classes/sun/io/CharToByteISO8859_9.java - src/share/classes/sun/io/CharToByteJIS0201.java - src/share/classes/sun/io/CharToByteJIS0208.java - src/share/classes/sun/io/CharToByteJIS0208_Solaris.java - src/share/classes/sun/io/CharToByteJIS0212.java - src/share/classes/sun/io/CharToByteJIS0212_Solaris.java - src/share/classes/sun/io/CharToByteJohab.java - src/share/classes/sun/io/CharToByteKOI8_R.java - src/share/classes/sun/io/CharToByteMS874.java - src/share/classes/sun/io/CharToByteMS932.java - src/share/classes/sun/io/CharToByteMS936.java - src/share/classes/sun/io/CharToByteMS949.java - src/share/classes/sun/io/CharToByteMS950.java - src/share/classes/sun/io/CharToByteMS950_HKSCS.java - src/share/classes/sun/io/CharToByteMacArabic.java - src/share/classes/sun/io/CharToByteMacCentralEurope.java - src/share/classes/sun/io/CharToByteMacCroatian.java - src/share/classes/sun/io/CharToByteMacCyrillic.java - src/share/classes/sun/io/CharToByteMacDingbat.java - src/share/classes/sun/io/CharToByteMacGreek.java - src/share/classes/sun/io/CharToByteMacHebrew.java - src/share/classes/sun/io/CharToByteMacIceland.java - src/share/classes/sun/io/CharToByteMacRoman.java - src/share/classes/sun/io/CharToByteMacRomania.java - src/share/classes/sun/io/CharToByteMacSymbol.java - src/share/classes/sun/io/CharToByteMacThai.java - src/share/classes/sun/io/CharToByteMacTurkish.java - src/share/classes/sun/io/CharToByteMacUkraine.java - src/share/classes/sun/io/CharToBytePCK.java - src/share/classes/sun/io/CharToByteSJIS.java - src/share/classes/sun/io/CharToByteSingleByte.java - src/share/classes/sun/io/CharToByteTIS620.java - src/share/classes/sun/io/CharToByteUTF16.java - src/share/classes/sun/io/CharToByteUTF8.java - src/share/classes/sun/io/CharToByteUnicode.java - src/share/classes/sun/io/CharToByteUnicodeBig.java - src/share/classes/sun/io/CharToByteUnicodeBigUnmarked.java - src/share/classes/sun/io/CharToByteUnicodeLittle.java - src/share/classes/sun/io/CharToByteUnicodeLittleUnmarked.java - src/share/classes/sun/io/CharacterEncoding.java - src/share/classes/sun/io/ConversionBufferFullException.java - src/share/classes/sun/io/Converters.java - src/share/classes/sun/io/MalformedInputException.java - src/share/classes/sun/io/UnknownCharacterException.java - src/share/classes/sun/nio/ch/SctpMessageInfoImpl.java - src/share/classes/sun/nio/ch/SctpStdSocketOption.java - src/share/classes/sun/security/pkcs/EncodingException.java - src/share/classes/sun/security/pkcs/PKCS10.java - src/share/classes/sun/security/pkcs/PKCS10Attribute.java - src/share/classes/sun/security/pkcs/PKCS10Attributes.java - src/share/classes/sun/security/util/BigInt.java - src/share/classes/sun/security/util/PathList.java ! src/share/classes/sun/security/x509/CRLExtensions.java - src/share/classes/sun/security/x509/CertAndKeyGen.java ! src/share/classes/sun/security/x509/CertificateExtensions.java ! src/share/classes/sun/security/x509/X509CRLEntryImpl.java ! src/share/classes/sun/security/x509/X509CRLImpl.java ! src/share/classes/sun/security/x509/X509CertImpl.java - src/share/classes/sun/tools/jar/JarImageSource.java ! src/share/lib/security/java.security-solaris - src/share/native/java/lang/fdlibm/src/e_acosh.c - src/share/native/java/lang/fdlibm/src/e_gamma.c - src/share/native/java/lang/fdlibm/src/e_gamma_r.c - src/share/native/java/lang/fdlibm/src/e_j0.c - src/share/native/java/lang/fdlibm/src/e_j1.c - src/share/native/java/lang/fdlibm/src/e_jn.c - src/share/native/java/lang/fdlibm/src/e_lgamma.c - src/share/native/java/lang/fdlibm/src/e_lgamma_r.c - src/share/native/java/lang/fdlibm/src/s_asinh.c - src/share/native/java/lang/fdlibm/src/s_erf.c - src/share/native/java/lang/fdlibm/src/w_acosh.c - src/share/native/java/lang/fdlibm/src/w_gamma.c - src/share/native/java/lang/fdlibm/src/w_gamma_r.c - src/share/native/java/lang/fdlibm/src/w_j0.c - src/share/native/java/lang/fdlibm/src/w_j1.c - src/share/native/java/lang/fdlibm/src/w_jn.c - src/share/native/java/lang/fdlibm/src/w_lgamma.c - src/share/native/java/lang/fdlibm/src/w_lgamma_r.c - src/share/native/java/util/zip/zlib-1.2.3/ChangeLog - src/share/native/java/util/zip/zlib-1.2.3/README - src/share/native/java/util/zip/zlib-1.2.3/compress.c - src/share/native/java/util/zip/zlib-1.2.3/crc32.h - src/share/native/java/util/zip/zlib-1.2.3/deflate.c - src/share/native/java/util/zip/zlib-1.2.3/deflate.h - src/share/native/java/util/zip/zlib-1.2.3/gzio.c - src/share/native/java/util/zip/zlib-1.2.3/infback.c - src/share/native/java/util/zip/zlib-1.2.3/inffast.c - src/share/native/java/util/zip/zlib-1.2.3/inffast.h - src/share/native/java/util/zip/zlib-1.2.3/inffixed.h - src/share/native/java/util/zip/zlib-1.2.3/inflate.c - src/share/native/java/util/zip/zlib-1.2.3/inflate.h - src/share/native/java/util/zip/zlib-1.2.3/inftrees.c - src/share/native/java/util/zip/zlib-1.2.3/inftrees.h - src/share/native/java/util/zip/zlib-1.2.3/patches/ChangeLog_java - src/share/native/java/util/zip/zlib-1.2.3/patches/crc32.c.diff - src/share/native/java/util/zip/zlib-1.2.3/patches/inflate.c.diff - src/share/native/java/util/zip/zlib-1.2.3/patches/zconf.h.diff - src/share/native/java/util/zip/zlib-1.2.3/patches/zlib.h.diff - src/share/native/java/util/zip/zlib-1.2.3/trees.c - src/share/native/java/util/zip/zlib-1.2.3/trees.h - src/share/native/java/util/zip/zlib-1.2.3/uncompr.c - src/share/native/java/util/zip/zlib-1.2.3/zadler32.c - src/share/native/java/util/zip/zlib-1.2.3/zconf.h - src/share/native/java/util/zip/zlib-1.2.3/zcrc32.c - src/share/native/java/util/zip/zlib-1.2.3/zlib.h - src/share/native/java/util/zip/zlib-1.2.3/zutil.c - src/share/native/java/util/zip/zlib-1.2.3/zutil.h - src/share/native/sun/awt/libpng/pnggccrd.c - src/share/native/sun/awt/libpng/pngvcrd.c - src/share/native/sun/rmi/server/MarshalInputStream.c - src/solaris/classes/sun/awt/motif/AWTLockAccess.java - src/solaris/classes/sun/awt/motif/MFontPeer.java - src/solaris/classes/sun/awt/motif/MToolkit.java - src/solaris/classes/sun/awt/motif/MToolkitThreadBlockedHandler.java - src/solaris/classes/sun/awt/motif/MWindowAttributes.java - src/solaris/classes/sun/awt/motif/X11FontMetrics.java - src/solaris/classes/sun/nio/ch/SctpAssocChange.java - src/solaris/classes/sun/nio/ch/SctpAssociationImpl.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/SctpNotification.java - src/solaris/classes/sun/nio/ch/SctpPeerAddrChange.java - src/solaris/classes/sun/nio/ch/SctpResultContainer.java - src/solaris/classes/sun/nio/ch/SctpSendFailed.java - src/solaris/classes/sun/nio/ch/SctpServerChannelImpl.java - src/solaris/classes/sun/nio/ch/SctpShutdown.java - src/solaris/doc/sun/man/man1/apt.1 - src/solaris/doc/sun/man/man1/ja/apt.1 - src/solaris/native/sun/awt/MouseInfo.c - src/solaris/native/sun/awt/XDrawingArea.c - src/solaris/native/sun/awt/XDrawingArea.h - src/solaris/native/sun/awt/XDrawingAreaP.h - src/solaris/native/sun/awt/awt_Cursor.h - src/solaris/native/sun/awt/awt_KeyboardFocusManager.h - src/solaris/native/sun/awt/awt_MToolkit.c - src/solaris/native/sun/awt/awt_MToolkit.h - src/solaris/native/sun/awt/awt_MenuItem.h - src/solaris/native/sun/awt/awt_PopupMenu.h - src/solaris/native/sun/awt/awt_TopLevel.h - src/solaris/native/sun/awt/awt_Window.h - src/solaris/native/sun/awt/awt_mgrsel.c - src/solaris/native/sun/awt/awt_mgrsel.h - src/solaris/native/sun/awt/awt_motif.h - src/solaris/native/sun/awt/awt_wm.c - src/solaris/native/sun/awt/awt_wm.h - src/solaris/native/sun/awt/awt_xembed.h - src/solaris/native/sun/awt/awt_xembed_server.c - src/solaris/native/sun/awt/awt_xembed_server.h - src/solaris/native/sun/nio/ch/Sctp.h - src/solaris/native/sun/nio/ch/SctpChannelImpl.c - src/solaris/native/sun/nio/ch/SctpNet.c - src/solaris/native/sun/nio/ch/SctpServerChannelImpl.c - src/windows/classes/sun/nio/ch/SctpChannelImpl.java - src/windows/classes/sun/nio/ch/SctpMultiChannelImpl.java - src/windows/classes/sun/nio/ch/SctpServerChannelImpl.java - test/java/io/File/BlockIsDirectory.java - test/java/io/File/isDirectory/Applet.html - test/java/io/File/isDirectory/Applet.java - test/java/io/FileDescriptor/FileChannelFDTest.java - test/java/util/ResourceBundle/Control/ExpirationTest.java - test/java/util/ResourceBundle/Control/ExpirationTest.sh - test/sun/nio/cs/OLD/TestX11CS.java - test/sun/nio/cs/TestISCII91.java - test/sun/security/util/BigInt/BigIntEqualsHashCode.java - test/tools/launcher/ChangeDataModel.sh - test/tools/launcher/CreatePlatformFile.java - test/tools/launcher/DefaultLocaleTest.sh - test/tools/launcher/SomeException.java - test/tools/launcher/UnicodeCleanup.java - test/tools/launcher/UnicodeTest.sh - test/tools/launcher/deleteI18n.sh - test/tools/launcher/i18nTest.sh - test/tools/launcher/unresolvedExceptions.sh Changeset: 95998c60ab4b Author: robm Date: 2012-04-11 17:47 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/95998c60ab4b 7143606: File.createTempFile should be improved for temporary files created by the platform. Reviewed-by: sherman ! src/macosx/classes/apple/applescript/AppleScriptEngine.java ! src/share/classes/com/sun/java/util/jar/pack/Driver.java ! src/share/classes/java/awt/Font.java ! src/share/classes/javax/imageio/stream/FileCacheImageInputStream.java ! src/share/classes/javax/imageio/stream/FileCacheImageOutputStream.java ! src/share/classes/javax/management/loading/MLet.java ! src/share/classes/sun/print/PSPrinterJob.java ! src/share/classes/sun/rmi/server/Activation.java ! src/share/classes/sun/tools/jar/Main.java ! src/share/classes/sun/tools/native2ascii/Main.java ! src/solaris/classes/sun/font/FcFontConfiguration.java ! src/solaris/classes/sun/print/UnixPrintJob.java ! src/solaris/classes/sun/print/UnixPrintServiceLookup.java Changeset: afe424ee3240 Author: asaha Date: 2012-05-08 07:34 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/afe424ee3240 Merge ! src/share/lib/security/java.security ! src/share/lib/security/java.security-solaris ! src/share/lib/security/java.security-windows - test/sun/security/pkcs11/nss/lib/linux-amd64/libfreebl3.chk - test/sun/security/pkcs11/nss/lib/linux-amd64/libfreebl3.so - test/sun/security/pkcs11/nss/lib/linux-amd64/libnspr4.so - test/sun/security/pkcs11/nss/lib/linux-amd64/libnss3.so - test/sun/security/pkcs11/nss/lib/linux-amd64/libnssckbi.so - test/sun/security/pkcs11/nss/lib/linux-amd64/libplc4.so - test/sun/security/pkcs11/nss/lib/linux-amd64/libplds4.so - test/sun/security/pkcs11/nss/lib/linux-amd64/libsoftokn3.chk - test/sun/security/pkcs11/nss/lib/linux-amd64/libsoftokn3.so - test/sun/security/pkcs11/nss/lib/linux-i586/libnspr4.so - test/sun/security/pkcs11/nss/lib/linux-i586/libnss3.so - test/sun/security/pkcs11/nss/lib/linux-i586/libnssckbi.so - test/sun/security/pkcs11/nss/lib/linux-i586/libplc4.so - test/sun/security/pkcs11/nss/lib/linux-i586/libplds4.so - test/sun/security/pkcs11/nss/lib/linux-i586/libsoftokn3.so - test/sun/security/pkcs11/nss/lib/solaris-amd64/libnspr4.so - test/sun/security/pkcs11/nss/lib/solaris-amd64/libnss3.so - test/sun/security/pkcs11/nss/lib/solaris-amd64/libnssckbi.so - test/sun/security/pkcs11/nss/lib/solaris-amd64/libplc4.so - test/sun/security/pkcs11/nss/lib/solaris-amd64/libplds4.so - test/sun/security/pkcs11/nss/lib/solaris-amd64/libsoftokn3.so - test/sun/security/pkcs11/nss/lib/solaris-i586/libfreebl3.so - test/sun/security/pkcs11/nss/lib/solaris-i586/libnspr4.so - test/sun/security/pkcs11/nss/lib/solaris-i586/libnss3.so - test/sun/security/pkcs11/nss/lib/solaris-i586/libnssckbi.so - test/sun/security/pkcs11/nss/lib/solaris-i586/libplc4.so - test/sun/security/pkcs11/nss/lib/solaris-i586/libplds4.so - test/sun/security/pkcs11/nss/lib/solaris-i586/libsoftokn3.so - test/sun/security/pkcs11/nss/lib/solaris-sparc/libfreebl_hybrid_3.chk - test/sun/security/pkcs11/nss/lib/solaris-sparc/libfreebl_hybrid_3.so - test/sun/security/pkcs11/nss/lib/solaris-sparc/libnspr4.so - test/sun/security/pkcs11/nss/lib/solaris-sparc/libnss3.so - test/sun/security/pkcs11/nss/lib/solaris-sparc/libnssckbi.so - test/sun/security/pkcs11/nss/lib/solaris-sparc/libplc4.so - test/sun/security/pkcs11/nss/lib/solaris-sparc/libplds4.so - test/sun/security/pkcs11/nss/lib/solaris-sparc/libsoftokn3.chk - test/sun/security/pkcs11/nss/lib/solaris-sparc/libsoftokn3.so - test/sun/security/pkcs11/nss/lib/solaris-sparcv9/libnspr4.so - test/sun/security/pkcs11/nss/lib/solaris-sparcv9/libnss3.so - test/sun/security/pkcs11/nss/lib/solaris-sparcv9/libnssckbi.so - test/sun/security/pkcs11/nss/lib/solaris-sparcv9/libplc4.so - test/sun/security/pkcs11/nss/lib/solaris-sparcv9/libplds4.so - test/sun/security/pkcs11/nss/lib/solaris-sparcv9/libsoftokn3.so - test/sun/security/pkcs11/nss/lib/windows-i586/libnspr4.dll - test/sun/security/pkcs11/nss/lib/windows-i586/libplc4.dll - test/sun/security/pkcs11/nss/lib/windows-i586/libplds4.dll - test/sun/security/pkcs11/nss/lib/windows-i586/nss3.dll - test/sun/security/pkcs11/nss/lib/windows-i586/nssckbi.dll - test/sun/security/pkcs11/nss/lib/windows-i586/softokn3.dll Changeset: 3a2cfce96908 Author: coffeys Date: 2012-05-17 12:21 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3a2cfce96908 7123896: Unexpected behavior due to Solaris using separate IPv4 and IPv6 port spaces Reviewed-by: alanb ! src/share/native/java/net/net_util.c ! src/share/native/java/net/net_util.h ! src/solaris/native/java/net/net_util_md.c ! src/windows/native/java/net/net_util_md.c ! test/java/net/Socket/setReuseAddress/Basic.java ! test/java/net/Socket/setReuseAddress/Restart.java Changeset: cf097cda2733 Author: jrose Date: 2012-05-18 20:31 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cf097cda2733 7165628: Issues with java.lang.invoke.MethodHandles.Lookup Summary: Base SecurityManager checks on either of Lookup.lookupClass or caller class; also clarify Lookup access checks. Reviewed-by: twisti ! src/share/classes/java/lang/invoke/MethodHandles.java ! src/share/classes/sun/invoke/util/VerifyAccess.java + test/java/lang/invoke/AccessControlTest.java + test/java/lang/invoke/AccessControlTest_subpkg/Acquaintance_remote.java Changeset: 36d899822de7 Author: asaha Date: 2012-05-21 15:13 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/36d899822de7 Merge - src/macosx/bin/amd64/jvm.cfg ! src/share/classes/sun/print/PSPrinterJob.java - src/share/classes/sun/security/action/LoadLibraryAction.java ! src/solaris/classes/sun/print/UnixPrintServiceLookup.java ! src/solaris/native/java/net/net_util_md.c - test/tools/pack200/dyn.jar - test/tools/pack200/pack200-verifier/src/xmlkit/ClassSyntax.java - test/tools/pack200/pack200-verifier/src/xmlkit/ClassWriter.java - test/tools/pack200/pack200-verifier/src/xmlkit/InstructionAssembler.java - test/tools/pack200/pack200-verifier/src/xmlkit/InstructionSyntax.java Changeset: 4c403c00fdf1 Author: asaha Date: 2012-05-24 10:23 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4c403c00fdf1 7171228: closed/java/lang/SecurityManager/CheckPackageDefinition.java failure Reviewed-by: mullan ! src/share/lib/security/java.security ! src/share/lib/security/java.security-macosx ! src/share/lib/security/java.security-solaris ! src/share/lib/security/java.security-windows Changeset: 2fbf98031e65 Author: asaha Date: 2012-06-07 12:31 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2fbf98031e65 Merge ! src/share/native/java/net/net_util.h ! src/solaris/native/java/net/net_util_md.c Changeset: b92353a01aa0 Author: lana Date: 2012-06-26 10:57 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b92353a01aa0 Merge ! src/share/classes/sun/security/x509/X509CRLEntryImpl.java ! src/solaris/classes/sun/print/UnixPrintServiceLookup.java ! src/solaris/native/java/net/net_util_md.c Changeset: 7e9a7400329b Author: lana Date: 2012-06-26 22:59 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7e9a7400329b Merge Changeset: 2bba577b8ab8 Author: lana Date: 2012-06-27 00:09 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2bba577b8ab8 Merge From david.holmes at oracle.com Wed Jun 27 07:32:42 2012 From: david.holmes at oracle.com (David Holmes) Date: Wed, 27 Jun 2012 17:32:42 +1000 Subject: [PATCH] Review Request - Test bug: 6948101 java/rmi/transport/pinLastArguments/PinLastArguments.java failing intermittently In-Reply-To: <4FEAAED2.8000901@oracle.com> References: <4FE98037.2050700@oracle.com> <4FEA300D.6090705@oracle.com> <4FEA5E76.1030400@oracle.com> <4FEAAED2.8000901@oracle.com> Message-ID: <4FEAB71A.8050809@oracle.com> On 27/06/2012 4:57 PM, Eric Wang wrote: > Hi David & Stuart, > > Thank you for the help! please review the in webrev 6948101.zip in > attachment. Thanks Eric. That fix also seems fine to me. David > Regards, > Eric > > On 2012/6/27 9:14, Stuart Marks wrote: >> Hi Eric, >> >> Alan Bateman asked me to help you out with this since he's going to be >> unavailable for a couple weeks. >> >> I didn't see you on the OpenJDK census [1] so you might not have an >> Author role and thus the ability to post webrevs. If indeed you don't, >> I can post a webrev for you. I can also post a webrev for your other >> review (7123972) if it's still necessary. >> >> Finally, I can push the fixes for you when the reviews are complete. >> >> s'marks >> >> [1] http://openjdk.java.net/census >> >> On 6/26/12 2:56 PM, David Holmes wrote: >>> Hi Eric, >>> >>> On 26/06/2012 7:26 PM, Eric Wang wrote: >>>> Please help to review the fix attached for test bug 6948101 >>>> which is same root >>>> cause as bug 7123972 >>>> . >>>> The test makes wrong assumption that GC is started immediately to >>>> recycle unused objects after System.gc() called. >>>> The proposed fix is to make sure objects have been recycled by GC >>>> before >>>> checking if the weak reference is null. >>> >>> Again I really need to see a webrev to see the fix in context. Do you >>> have >>> Author role and an OpenJDK user name so you can post webrevs on >>> cr.openjdk.java.net? >>> >>> I suspect this may have the same issues as the other fix and require >>> a timeout >>> for when the original problem is still present. >>> >>> Thanks, >>> David >>> >>>> Regards, >>>> Eric > From martijnverburg at gmail.com Wed Jun 27 07:58:52 2012 From: martijnverburg at gmail.com (Martijn Verburg) Date: Wed, 27 Jun 2012 08:58:52 +0100 Subject: Bug 7176907 - Patches for javac warnings cleanup (text and util) from Adopt OpenJDK In-Reply-To: <4FE9FF91.3010400@oracle.com> References: <4FE1D95C.3030108@univ-mlv.fr> <4FE1F559.5070802@oracle.com> <4FE9FF91.3010400@oracle.com> Message-ID: Hi Kurchi, > Thanks for updating this. This looks good to me. I guess Stuart will be > sponsoring the patch. For his sins he's kindly offered to do so yes :-) > There are a couple of other switch statements in > ?src/share/classes/java/util/regex/Pattern.java. > which are not throwing fallthrough warnings (in Netbeans at least), > although there is fallthrough happening from one case to another. From what > I notice, only if there is a break statement > missing before the "default" case, does Netbeans throw some warning. Is the > fallthrough warning technically > supposed to be thrown only when the logic falls through to the default case > then? That's my understanding with the javac compiler yes. I think it was the balance that the javac folk thought was a sensible compromise in terms of not generating too many false positive warnings. Cheers, Martijn From yiming.wang at oracle.com Wed Jun 27 08:20:27 2012 From: yiming.wang at oracle.com (Eric Wang) Date: Wed, 27 Jun 2012 16:20:27 +0800 Subject: [PATCH] Review Request - Test bug: 6948101 java/rmi/transport/pinLastArguments/PinLastArguments.java failing intermittently In-Reply-To: <4FEAB71A.8050809@oracle.com> References: <4FE98037.2050700@oracle.com> <4FEA300D.6090705@oracle.com> <4FEA5E76.1030400@oracle.com> <4FEAAED2.8000901@oracle.com> <4FEAB71A.8050809@oracle.com> Message-ID: <4FEAC24B.50709@oracle.com> Hi David, Thank you for review! Hi Stuart, Can you please help to review and post the webrev, Thanks a lot! Eric On 2012/6/27 15:32, David Holmes wrote: > On 27/06/2012 4:57 PM, Eric Wang wrote: >> Hi David & Stuart, >> >> Thank you for the help! please review the in webrev 6948101.zip in >> attachment. > > Thanks Eric. That fix also seems fine to me. > > David > > >> Regards, >> Eric >> >> On 2012/6/27 9:14, Stuart Marks wrote: >>> Hi Eric, >>> >>> Alan Bateman asked me to help you out with this since he's going to be >>> unavailable for a couple weeks. >>> >>> I didn't see you on the OpenJDK census [1] so you might not have an >>> Author role and thus the ability to post webrevs. If indeed you don't, >>> I can post a webrev for you. I can also post a webrev for your other >>> review (7123972) if it's still necessary. >>> >>> Finally, I can push the fixes for you when the reviews are complete. >>> >>> s'marks >>> >>> [1] http://openjdk.java.net/census >>> >>> On 6/26/12 2:56 PM, David Holmes wrote: >>>> Hi Eric, >>>> >>>> On 26/06/2012 7:26 PM, Eric Wang wrote: >>>>> Please help to review the fix attached for test bug 6948101 >>>>> which is same >>>>> root >>>>> cause as bug 7123972 >>>>> . >>>>> The test makes wrong assumption that GC is started immediately to >>>>> recycle unused objects after System.gc() called. >>>>> The proposed fix is to make sure objects have been recycled by GC >>>>> before >>>>> checking if the weak reference is null. >>>> >>>> Again I really need to see a webrev to see the fix in context. Do you >>>> have >>>> Author role and an OpenJDK user name so you can post webrevs on >>>> cr.openjdk.java.net? >>>> >>>> I suspect this may have the same issues as the other fix and require >>>> a timeout >>>> for when the original problem is still present. >>>> >>>> Thanks, >>>> David >>>> >>>>> Regards, >>>>> Eric >> From martijnverburg at gmail.com Wed Jun 27 16:09:57 2012 From: martijnverburg at gmail.com (Martijn Verburg) Date: Wed, 27 Jun 2012 17:09:57 +0100 Subject: Bug 7176907 - Patches for javac warnings cleanup (text and util) from Adopt OpenJDK In-Reply-To: References: <4FE1D95C.3030108@univ-mlv.fr> <4FE1F559.5070802@oracle.com> <4FE9FF91.3010400@oracle.com> Message-ID: Hi all, We've been working on improving the workflow for our patch review system and so the new locations for the patches are at: https://raw.github.com/AdoptOpenJDK/PatchReview/master/5-submitted/javac_warnings/core_java_text.patch https://raw.github.com/AdoptOpenJDK/PatchReview/master/5-submitted/javac_warnings/core_java_util.patch Cheers, Martijn On 27 June 2012 08:58, Martijn Verburg wrote: > Hi Kurchi, > >> Thanks for updating this. This looks good to me. I guess Stuart will be >> sponsoring the patch. > > For his sins he's kindly offered to do so yes :-) > >> There are a couple of other switch statements in >> ?src/share/classes/java/util/regex/Pattern.java. >> which are not throwing fallthrough warnings (in Netbeans at least), >> although there is fallthrough happening from one case to another. From what >> I notice, only if there is a break statement >> missing before the "default" case, does Netbeans throw some warning. Is the >> fallthrough warning technically >> supposed to be thrown only when the logic falls through to the default case >> then? > > That's my understanding with the javac compiler yes. I think it was the balance > that the javac folk thought was a sensible compromise in terms of not > generating > too many false positive warnings. > > Cheers, > Martijn From Lance.Andersen at oracle.com Wed Jun 27 17:21:36 2012 From: Lance.Andersen at oracle.com (Lance Andersen - Oracle) Date: Wed, 27 Jun 2012 13:21:36 -0400 Subject: RFR : 7162902 / 6893617 Umbrella port of a number of corba bug fixes from JDK 6 to jdk7u/8 In-Reply-To: <4FE8C967.1030302@oracle.com> References: <4FE8C967.1030302@oracle.com> Message-ID: Hi Sean, I think this looks good. ship it :-) Best Lance On Jun 25, 2012, at 4:26 PM, Sean Coffey wrote: > Hi, > > I'm looking for a code review around the following corba changes. It turns out that we've a few bug fixes in corba area for jdk6 that were never forward ported to jdk7 or 8. The port is pretty much identical to what was used in JDK6. Some formatting and diamond operator changes introduced but that's about it. There were a few bug fixes to follow up on regressions around the initial fix but this umbrella port should cover all issues. > > The initial bugs fixes were fixed under the "jets" category in the bug tool and that category entered read only mode over a year ago. Hence the requirement for a new bug ID. > > The main bug fix is 6725987 which is an issue where references to the ORB were being kept after ORB.destroy was called. > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7162902 > An accompanying CNCtx fix in JDK repo is also made to correct an issue where the java.naming.corba.orb system property wasn't used correctly. (CR 6893617) > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6893617 > > Corba testsuites run and no issues seen. I've also run some JCK testing and saw no issues. > > http://cr.openjdk.java.net/~coffeys/webrev.7162902.jdk8/ (corba) > http://cr.openjdk.java.net/~coffeys/webrev.6893617.jdk8/ (jdk) > > The corba codebase code formatting seems to vary quite a bit. I've reformatted in a small number of areas but the whole corba repo probably warrants it's own clean up project at a later date. > > regards, > Sean. Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From peter.levart at gmail.com Sat Jun 23 07:17:05 2012 From: peter.levart at gmail.com (Peter Levart) Date: Sat, 23 Jun 2012 09:17:05 +0200 Subject: String.subSequence and CR#6924259: Remove offset and count fields from java.lang.String In-Reply-To: References: <20120531032252.A69774763C@hg.openjdk.java.net> <1359801.KFxJhQHyve@cube> Message-ID: <7407752.ev8DJVq2dA@cube> Hi Mike, Yes, all that you say below is true. CharSequence is an interface that does not define the contract of identity when implementations/subtypes of CharSequence do - each in it's own way. Much like java.util.Collection and List vs. Set. It's always dangerous for methods that return such interfaces when the implementation class of the returned instance changes so that it defines a different "hidden" contract. It is unfortunately also true that now there is no "official" way of comparing/equating/hashing a substring without copying the characters. It feels like standard Java SE API is lacking a part of functionality. Maybe this space could be filled with the addition of a new public immutable CharSequence subtype - like Rope: http://ahmadsoft.org/ropes/doc/index.html Regards, Peter On Friday, June 22, 2012 03:15:40 PM Mike Duigou wrote: > I've made a test implementation of subSequence() utilizing an inner class > with offset and count fields to try to understand all the parts that would > be impacted. My observations thus far: > > - The specification of the subSequence() method is currently too specific. > It says that the result is a subString(). This would no longer be true. > Hopefully nobody assumed that this meant they could cast the result to > String. I know, why would you if you can just call subString() instead? > I've learned to assume that somebody somewhere does always does the most > unexpected thing. - The CharSequences returned by subSequence would follow > only the general CharSequence rules for equals()/hashCode(). Any current > usages of the result of subSequence for equals() or hashing, even though > it's not advised, would break. We could add equals() and hashCode() > implementations to the CharSequence returned but they would probably be > expensive. - In general I wonder if parsers will be satisfied with a > CharSequence that only implements identity equals(). - I also worry about > applications that currently do use subSequence currently and which will > fail when the result is not a String instance as String.equals() will > return false for all CharSequences that aren't Strings. ie. CharSequence > token = line.subSequence(line, start, end); if (keyword.equals(token)) ... > This would now fail. > > At this point I wonder if this is a feature worth pursuing. > > Mike > > On Jun 3 2012, at 13:44 , Peter Levart wrote: > > On Thursday, May 31, 2012 03:22:35 AM mike.duigou at oracle.com wrote: > >> Changeset: 2c773daa825d > >> Author: mduigou > >> Date: 2012-05-17 10:06 -0700 > >> URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2c773daa825d > >> > >> 6924259: Remove offset and count fields from java.lang.String > >> Summary: Removes the use of shared character array buffers by String > >> along > >> with the two fields needed to support the use of shared buffers. > > > > Wow, that's quite a change. > > > > So .substring() is not O(1) any more? > > > > Doesn't this have impact on the performance of parsers and such that rely > > on the performance caracteristics of the .substring() ? > > > > Have you considered then implementing .subSequence() not in terms of just > > delegating to .substring() but returning a special CharSequence view over > > the chars of the sub-sequence? From dkocher at sudo.ch Sun Jun 24 14:50:21 2012 From: dkocher at sudo.ch (David Kocher) Date: Sun, 24 Jun 2012 16:50:21 +0200 Subject: Codereview request for 7130915: File.equals does not give expected results when path contains Non-English characters on Mac OS X In-Reply-To: <4FE4A4D6.4070100@oracle.com> References: <4FE4A4D6.4070100@oracle.com> Message-ID: <191321F8-8360-44A2-AA61-1504B074E264@sudo.ch> Will this address issue MACOSX_PORT-165 [1]? [1] http://java.net/jira/browse/MACOSX_PORT-165 -- David On 22.06.2012, at 19:01, Xueming Shen wrote: > Hi > > Here is the proposed change to support Unicode nfd/nfc and case insensitive > file path on MacOSX file system. > > 7130915: File.equals does not give expected results when path contains Non-English characters on Mac OS X > 7168427: FileInputStream cannot open file where the file path contains asian characters [macosx] > > While these two bug reports are only against java.io, we have the same issue in javax.nio.file. > Here is the webrev > > http://cr.openjdk.java.net/~sherman/7130915_7168427/webrev/ > > Here is the brief summary of the changes > > java.io.File: > (1) removed nfc->nfd conversion in io_util.h/WITH_PLATFORM_STRING, which means > we are now passing nfc/composite characters directly into macosx file system APIs > without normalize them to nfd. It appears macosx fs APIs do take nfc, though it uses > nfd. > > (2) normalize the resulting file name from macosx fs APIs from nfd->nfd before passing > back to java.io.File (File.list() and canonicalize()), so we deal with nfdc file name > (as "usual") for java.io classes/APIs. > > (3) fs.compare()/hashCode() was updated to be case insensitive > > (4) hasCode() was updated to use the new String.hash32(). > > java.nio.file: > > (5) added a setof MacOSXFile... on top of existing BsdFile... classes. An alternative is to > update those BsdFile... classes directly to address the macosx specific issues. But given > there might be developers over there might work on open jdk BSD port and have dependency > on these classes, it might be desirable to have another separate layer of MacOSXFile... > classes. So now the default FileSystem/Provider is MacOSXFileSystemProvider and > MacOSXFileSystem. > > (6) the "main" changes are in MacOSXFileSystem, in which the corresponding methods > were added to handle, case insensitive and nfd<=>nfc normalization, including the > pathmatcher. > > (7) compare is now are case-insensitive > > (8) hashCode is now murmur3_32(), this is true for all Solaris/Unix/Linux and maxosx. > > > Though lots of files have been touched, but the line of changes are actually relatively > small. > > The proposed change only deals with the default case-sensitiveness seting, which is > case insensitive. On MaxOSX, you actually can configure the HFS+ file system or the > mounted vol to be case-sensitive. A possible approach is to have some extra FileStore > attributes, such as a isCaseSensitive and to use case sensitive compare/equal on > such fs, but this can be dealt with separately later. > > Thanks, > -Sherman > From gregg at wonderly.org Tue Jun 26 19:24:54 2012 From: gregg at wonderly.org (Gregg Wonderly) Date: Tue, 26 Jun 2012 14:24:54 -0500 Subject: Codereview request for 7130915: File.equals does not give expected results when path contains Non-English characters on Mac OS X In-Reply-To: <4FE9CEF3.8080905@oracle.com> References: <4FE4A4D6.4070100@oracle.com> <4FE94F6F.2060002@oracle.com> <4FE94FED.6050406@oracle.com> <4FE9CEF3.8080905@oracle.com> Message-ID: <854ADF35-EC9F-4C3A-B062-39FCCAA47015@wonderly.org> On Jun 26, 2012, at 10:02 AM, Alan Bateman wrote: > > Do the tests assume they are run on HFS? Just wondering if you you need to look at the FileStore name/type to check. TensComplement's ZFS port (ZEVO) to MacOSX may need some consideration if HFS is going to be the only test bed. Gregg Wonderly From dkocher at sudo.ch Wed Jun 27 07:28:50 2012 From: dkocher at sudo.ch (David Kocher) Date: Wed, 27 Jun 2012 09:28:50 +0200 Subject: Codereview request for 7130915: File.equals does not give expected results when path contains Non-English characters on Mac OS X In-Reply-To: <4FE74719.8080709@oracle.com> References: <4FE4A4D6.4070100@oracle.com> <191321F8-8360-44A2-AA61-1504B074E264@sudo.ch> <4FE74719.8080709@oracle.com> Message-ID: <20552F03-72C0-4D3F-B30C-2C8589775002@sudo.ch> I welcome this issue is getting some serious attention then. When will this be backported to 7u? -- David On 24.06.2012, at 18:58, Xueming Shen wrote: > > Yes, I believe the issue described in MACOSX_PORT-165 is the > same issue this patch is trying to solve. > > Btw, it appears there are typos in the note(2), my mini keyboard obviously > is too sticky:-) > > (2) normalize the resulting file name from macosx fs APIs from nfd->nfc before passing > back to java.io.File (File.list() and canonicalize()), so we deal with nfc file name > (as "usual") for java.io classes/APIs. > > -sherman > > On 6/24/12 7:50 AM, David Kocher wrote: >> Will this address issue MACOSX_PORT-165 [1]? >> >> [1] http://java.net/jira/browse/MACOSX_PORT-165 >> >> -- David >> >> On 22.06.2012, at 19:01, Xueming Shen wrote: >> >>> Hi >>> >>> Here is the proposed change to support Unicode nfd/nfc and case insensitive >>> file path on MacOSX file system. >>> >>> 7130915: File.equals does not give expected results when path contains Non-English characters on Mac OS X >>> 7168427: FileInputStream cannot open file where the file path contains asian characters [macosx] >>> >>> While these two bug reports are only against java.io, we have the same issue in javax.nio.file. >>> Here is the webrev >>> >>> http://cr.openjdk.java.net/~sherman/7130915_7168427/webrev/ >>> >>> Here is the brief summary of the changes >>> >>> java.io.File: >>> (1) removed nfc->nfd conversion in io_util.h/WITH_PLATFORM_STRING, which means >>> we are now passing nfc/composite characters directly into macosx file system APIs >>> without normalize them to nfd. It appears macosx fs APIs do take nfc, though it uses >>> nfd. >>> >>> (2) normalize the resulting file name from macosx fs APIs from nfd->nfd before passing >>> back to java.io.File (File.list() and canonicalize()), so we deal with nfdc file name >>> (as "usual") for java.io classes/APIs. >>> >>> (3) fs.compare()/hashCode() was updated to be case insensitive >>> >>> (4) hasCode() was updated to use the new String.hash32(). >>> >>> java.nio.file: >>> >>> (5) added a setof MacOSXFile... on top of existing BsdFile... classes. An alternative is to >>> update those BsdFile... classes directly to address the macosx specific issues. But given >>> there might be developers over there might work on open jdk BSD port and have dependency >>> on these classes, it might be desirable to have another separate layer of MacOSXFile... >>> classes. So now the default FileSystem/Provider is MacOSXFileSystemProvider and >>> MacOSXFileSystem. >>> >>> (6) the "main" changes are in MacOSXFileSystem, in which the corresponding methods >>> were added to handle, case insensitive and nfd<=>nfc normalization, including the >>> pathmatcher. >>> >>> (7) compare is now are case-insensitive >>> >>> (8) hashCode is now murmur3_32(), this is true for all Solaris/Unix/Linux and maxosx. >>> >>> >>> Though lots of files have been touched, but the line of changes are actually relatively >>> small. >>> >>> The proposed change only deals with the default case-sensitiveness seting, which is >>> case insensitive. On MaxOSX, you actually can configure the HFS+ file system or the >>> mounted vol to be case-sensitive. A possible approach is to have some extra FileStore >>> attributes, such as a isCaseSensitive and to use case sensitive compare/equal on >>> such fs, but this can be dealt with separately later. >>> >>> Thanks, >>> -Sherman >>> > > From sean.coffey at oracle.com Wed Jun 27 20:08:15 2012 From: sean.coffey at oracle.com (sean.coffey at oracle.com) Date: Wed, 27 Jun 2012 20:08:15 +0000 Subject: hg: jdk8/tl/corba: 7162902: Umbrella port of a number of corba bug fixes from JDK 6 to jdk7u/8 Message-ID: <20120627200816.B4E2147B5C@hg.openjdk.java.net> Changeset: 47adb42076f1 Author: coffeys Date: 2012-06-27 21:09 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/47adb42076f1 7162902: Umbrella port of a number of corba bug fixes from JDK 6 to jdk7u/8 Reviewed-by: lancea ! src/share/classes/com/sun/corba/se/impl/encoding/CachedCodeBase.java ! src/share/classes/com/sun/corba/se/impl/interceptors/PIHandlerImpl.java ! src/share/classes/com/sun/corba/se/impl/interceptors/PINoOpHandlerImpl.java ! src/share/classes/com/sun/corba/se/impl/monitoring/MonitoringManagerFactoryImpl.java ! src/share/classes/com/sun/corba/se/impl/monitoring/MonitoringManagerImpl.java ! src/share/classes/com/sun/corba/se/impl/orb/ORBImpl.java ! src/share/classes/com/sun/corba/se/impl/orbutil/threadpool/ThreadPoolImpl.java ! src/share/classes/com/sun/corba/se/impl/orbutil/threadpool/ThreadPoolManagerImpl.java ! src/share/classes/com/sun/corba/se/impl/orbutil/threadpool/WorkQueueImpl.java ! src/share/classes/com/sun/corba/se/impl/protocol/CorbaMessageMediatorImpl.java ! src/share/classes/com/sun/corba/se/impl/transport/SelectorImpl.java ! src/share/classes/com/sun/corba/se/spi/logging/data/ORBUtil.mc ! src/share/classes/com/sun/corba/se/spi/monitoring/MonitoringManager.java ! src/share/classes/com/sun/corba/se/spi/monitoring/MonitoringManagerFactory.java ! src/share/classes/com/sun/corba/se/spi/orb/ORB.java ! src/share/classes/com/sun/corba/se/spi/orbutil/threadpool/ThreadPool.java ! src/share/classes/com/sun/corba/se/spi/orbutil/threadpool/ThreadPoolManager.java ! src/share/classes/com/sun/corba/se/spi/protocol/PIHandler.java ! src/share/classes/com/sun/corba/se/spi/protocol/RequestDispatcherRegistry.java From sean.coffey at oracle.com Wed Jun 27 20:08:10 2012 From: sean.coffey at oracle.com (sean.coffey at oracle.com) Date: Wed, 27 Jun 2012 20:08:10 +0000 Subject: hg: jdk8/tl/jdk: 6893617: JDK 6 CNCtx always uses the default ORB Message-ID: <20120627200849.9396647B5D@hg.openjdk.java.net> Changeset: 612e56cf284c Author: coffeys Date: 2012-06-27 21:10 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/612e56cf284c 6893617: JDK 6 CNCtx always uses the default ORB Reviewed-by: lancea ! src/share/classes/com/sun/jndi/cosnaming/CNCtx.java From stuart.marks at oracle.com Thu Jun 28 04:40:13 2012 From: stuart.marks at oracle.com (Stuart Marks) Date: Wed, 27 Jun 2012 21:40:13 -0700 Subject: Patch review request - Test bug 7123972 test/java/lang/annotation/loaderLeak/Main.java fails intermittently In-Reply-To: <4FEAAD38.7020304@oracle.com> References: <4FE2B997.7090204@oracle.com> <4FE2BFFB.8010705@oracle.com> <4FE2FE2C.1020601@oracle.com> <4FE310BB.6000100@oracle.com> <4FE81BFC.8040206@oracle.com> <4FEA2EFB.4050109@oracle.com> <4FEAA608.1000502@oracle.com> <4FEAAD38.7020304@oracle.com> Message-ID: <4FEBE02D.6010406@oracle.com> I've posted the webrev here: http://cr.openjdk.java.net/~smarks/yiming.wang/7123972/webrev.0/ I've looked at the changes and they seem fine. It's interesting that the run times take 30-60 sec in your experience. I've run them on my system (Linux in a virtual machine) and they usually run in 10-20 sec. In any case, as you say, if the test times out it indicates there really was a failure. I'll give people a chance to look at the webrev and if there aren't any more comments in another day or so I'll push in the changeset. Thanks for developing this! s'marks On 6/26/12 11:50 PM, Eric Wang wrote: > Hi David, > > Thank you! I run the test several times on 3 platforms (windows, solaris and > linux), the average execution time is 30secs to 60secs. if the test hang 2 > minutes, there should be something wrong. > > Hi Marks, > > I don't have the author role, Can you please help to review and post the webrev > 7123972.zip in attachment if it is OK, Thanks a lot! > > Regards, > Eric > > On 2012/6/27 14:19, David Holmes wrote: >> Eric, >> >> Ignore my comment about adding the timeouts. As Alan reminded me if the test >> would hang then jtreg will time it out after two minutes anyway. >> >> So this is good to go as far as I am concerned. >> >> Thanks, >> David >> >> On 27/06/2012 7:51 AM, David Holmes wrote: >>> Thanks Eric. >>> >>> So to summarize: >>> >>> - we create a custom classloader, load a class through it and store a >>> reference to that Class in a WeakReference >>> - we then drop the reference to the loader >>> >>> At this point the only reference to the loader is from the Class loaded, >>> which in turn is only weakly reachable. >>> >>> I must confess that I'm unclear why this test should be failing in its >>> original form. The first gc() should remove the strong reference to the >>> loader. That leaves a weak cycle: WeakRef -> Class -> Loader -> Class. >>> The second gc() should detect the cycle and clear the WeakRef. I guess >>> the problem is that depending on which gc is in use the actual gc() >>> calls may not in fact induce every possible GC action. >>> >>> The fix seems reasonable in that regard - keep gc'ing and finalizing >>> till we see the loader is gone, and so the WeakReference should be >>> cleared. The original bug would cause a ref to the Class to remain (from >>> the annotation) and hence the WeakRef would not be cleared. However, in >>> that case the loader would also be strongly referenced and so never >>> become finalizable. So if this test was now run against a JDK with the >>> original bug, the test would hang. So I think we need to add a timeout >>> in there as well. >>> >>> David >>> >>> On 25/06/2012 6:06 PM, Eric Wang wrote: >>>> On 2012/6/21 20:16, David Holmes wrote: >>>>> Hi Eric, >>>>> >>>>> On 21/06/2012 8:57 PM, Eric Wang wrote: >>>>>> Hi David, >>>>>> >>>>>> Thanks for your review, I have updated the code by following your >>>>>> suggestion. please see the attachment. >>>>>> I'm not sure whether there's a better way to guarantee object finalized >>>>>> by GC definitely within the given time. The proposed fix may work in >>>>>> most cases but may still throw InterruptException if execution is >>>>>> timeout (2 minutes of JTreg by default). >>>>> >>>>> There is no way to guarantee finalization in a specific timeframe, but >>>>> if a simple test hasn't executed finalizers in 2 minutes then that in >>>>> itself indicates a problem. >>>>> >>>>> Can you post a full webrev for this patch? I don't like seeing it out >>>>> of context and am wondering exactly what we are trying to GC here. >>>>> >>>>> David >>>>> >>>>>> Regards, >>>>>> Eric >>>>>> >>>>>> On 2012/6/21 14:32, David Holmes wrote: >>>>>>> Hi Eric, >>>>>>> >>>>>>> On 21/06/2012 4:05 PM, Eric Wang wrote: >>>>>>>> I come from Java SQE team who are interested in regression test bug >>>>>>>> fix. >>>>>>>> Here is the first simple fix for bug 7123972 >>>>>>>> , Can you please >>>>>>>> help >>>>>>>> to review and comment? Attachment is the patch Thanks! >>>>>>>> >>>>>>>> This bug is caused by wrong assumption that the GC is started >>>>>>>> immediately to recycle un-referenced objects after System.gc() called >>>>>>>> one or two times. >>>>>>>> >>>>>>>> The proposed solution is to make sure the un-referenced object is >>>>>>>> recycled by GC before checking if the reference is null. >>>>>>> >>>>>>> Your patch makes its own assumptions - specifically that finalization >>>>>>> must eventually run. At a minimum you should add >>>>>>> System.runFinalization() calls after the System.gc() inside the loop. >>>>>>> Even that is no guarantee in a general sense, though it should work >>>>>>> for hotspot. >>>>>>> >>>>>>> David >>>>>>> >>>>>>> >>>>>>>> Regards, >>>>>>>> Eric >>>>>> >>>> Hi Alan & David, >>>> >>>> Thank you for your comments, sorry for reply this mail late as i was >>>> just back from the dragon boat holiday. >>>> I have updated the code again based on your suggestions: rename the flag >>>> variable, increase the sleep time and remove it from problem list. >>>> The attachment is the full webrev for this patch, Can you please review >>>> again? Thanks a lot! >>>> >>>> Regards, >>>> Eric > From yiming.wang at oracle.com Thu Jun 28 06:23:01 2012 From: yiming.wang at oracle.com (Eric Wang) Date: Thu, 28 Jun 2012 14:23:01 +0800 Subject: Patch review request - Test bug 7123972 test/java/lang/annotation/loaderLeak/Main.java fails intermittently In-Reply-To: <4FEBE02D.6010406@oracle.com> References: <4FE2B997.7090204@oracle.com> <4FE2BFFB.8010705@oracle.com> <4FE2FE2C.1020601@oracle.com> <4FE310BB.6000100@oracle.com> <4FE81BFC.8040206@oracle.com> <4FEA2EFB.4050109@oracle.com> <4FEAA608.1000502@oracle.com> <4FEAAD38.7020304@oracle.com> <4FEBE02D.6010406@oracle.com> Message-ID: <4FEBF845.3080505@oracle.com> Hi Stuart, Thank you for help to publish the fix, my pleasure to contribute to OpenJDK project. Thanks, Eric On 2012/6/28 12:40, Stuart Marks wrote: > I've posted the webrev here: > > http://cr.openjdk.java.net/~smarks/yiming.wang/7123972/webrev.0/ > > I've looked at the changes and they seem fine. > > It's interesting that the run times take 30-60 sec in your experience. > I've run them on my system (Linux in a virtual machine) and they > usually run in 10-20 sec. In any case, as you say, if the test times > out it indicates there really was a failure. > > I'll give people a chance to look at the webrev and if there aren't > any more comments in another day or so I'll push in the changeset. > > Thanks for developing this! > > s'marks > > On 6/26/12 11:50 PM, Eric Wang wrote: >> Hi David, >> >> Thank you! I run the test several times on 3 platforms (windows, >> solaris and >> linux), the average execution time is 30secs to 60secs. if the test >> hang 2 >> minutes, there should be something wrong. >> >> Hi Marks, >> >> I don't have the author role, Can you please help to review and post >> the webrev >> 7123972.zip in attachment if it is OK, Thanks a lot! >> >> Regards, >> Eric >> >> On 2012/6/27 14:19, David Holmes wrote: >>> Eric, >>> >>> Ignore my comment about adding the timeouts. As Alan reminded me if >>> the test >>> would hang then jtreg will time it out after two minutes anyway. >>> >>> So this is good to go as far as I am concerned. >>> >>> Thanks, >>> David >>> >>> On 27/06/2012 7:51 AM, David Holmes wrote: >>>> Thanks Eric. >>>> >>>> So to summarize: >>>> >>>> - we create a custom classloader, load a class through it and store a >>>> reference to that Class in a WeakReference >>>> - we then drop the reference to the loader >>>> >>>> At this point the only reference to the loader is from the Class >>>> loaded, >>>> which in turn is only weakly reachable. >>>> >>>> I must confess that I'm unclear why this test should be failing in its >>>> original form. The first gc() should remove the strong reference to >>>> the >>>> loader. That leaves a weak cycle: WeakRef -> Class -> Loader -> Class. >>>> The second gc() should detect the cycle and clear the WeakRef. I guess >>>> the problem is that depending on which gc is in use the actual gc() >>>> calls may not in fact induce every possible GC action. >>>> >>>> The fix seems reasonable in that regard - keep gc'ing and finalizing >>>> till we see the loader is gone, and so the WeakReference should be >>>> cleared. The original bug would cause a ref to the Class to remain >>>> (from >>>> the annotation) and hence the WeakRef would not be cleared. >>>> However, in >>>> that case the loader would also be strongly referenced and so never >>>> become finalizable. So if this test was now run against a JDK with the >>>> original bug, the test would hang. So I think we need to add a timeout >>>> in there as well. >>>> >>>> David >>>> >>>> On 25/06/2012 6:06 PM, Eric Wang wrote: >>>>> On 2012/6/21 20:16, David Holmes wrote: >>>>>> Hi Eric, >>>>>> >>>>>> On 21/06/2012 8:57 PM, Eric Wang wrote: >>>>>>> Hi David, >>>>>>> >>>>>>> Thanks for your review, I have updated the code by following your >>>>>>> suggestion. please see the attachment. >>>>>>> I'm not sure whether there's a better way to guarantee object >>>>>>> finalized >>>>>>> by GC definitely within the given time. The proposed fix may >>>>>>> work in >>>>>>> most cases but may still throw InterruptException if execution is >>>>>>> timeout (2 minutes of JTreg by default). >>>>>> >>>>>> There is no way to guarantee finalization in a specific >>>>>> timeframe, but >>>>>> if a simple test hasn't executed finalizers in 2 minutes then >>>>>> that in >>>>>> itself indicates a problem. >>>>>> >>>>>> Can you post a full webrev for this patch? I don't like seeing it >>>>>> out >>>>>> of context and am wondering exactly what we are trying to GC here. >>>>>> >>>>>> David >>>>>> >>>>>>> Regards, >>>>>>> Eric >>>>>>> >>>>>>> On 2012/6/21 14:32, David Holmes wrote: >>>>>>>> Hi Eric, >>>>>>>> >>>>>>>> On 21/06/2012 4:05 PM, Eric Wang wrote: >>>>>>>>> I come from Java SQE team who are interested in regression >>>>>>>>> test bug >>>>>>>>> fix. >>>>>>>>> Here is the first simple fix for bug 7123972 >>>>>>>>> , Can you >>>>>>>>> please >>>>>>>>> help >>>>>>>>> to review and comment? Attachment is the patch Thanks! >>>>>>>>> >>>>>>>>> This bug is caused by wrong assumption that the GC is started >>>>>>>>> immediately to recycle un-referenced objects after System.gc() >>>>>>>>> called >>>>>>>>> one or two times. >>>>>>>>> >>>>>>>>> The proposed solution is to make sure the un-referenced object is >>>>>>>>> recycled by GC before checking if the reference is null. >>>>>>>> >>>>>>>> Your patch makes its own assumptions - specifically that >>>>>>>> finalization >>>>>>>> must eventually run. At a minimum you should add >>>>>>>> System.runFinalization() calls after the System.gc() inside the >>>>>>>> loop. >>>>>>>> Even that is no guarantee in a general sense, though it should >>>>>>>> work >>>>>>>> for hotspot. >>>>>>>> >>>>>>>> David >>>>>>>> >>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Eric >>>>>>> >>>>> Hi Alan & David, >>>>> >>>>> Thank you for your comments, sorry for reply this mail late as i was >>>>> just back from the dragon boat holiday. >>>>> I have updated the code again based on your suggestions: rename >>>>> the flag >>>>> variable, increase the sleep time and remove it from problem list. >>>>> The attachment is the full webrev for this patch, Can you please >>>>> review >>>>> again? Thanks a lot! >>>>> >>>>> Regards, >>>>> Eric >> From stuart.marks at oracle.com Thu Jun 28 21:20:03 2012 From: stuart.marks at oracle.com (Stuart Marks) Date: Thu, 28 Jun 2012 14:20:03 -0700 Subject: [PATCH] Review Request - Test bug: 6948101 java/rmi/transport/pinLastArguments/PinLastArguments.java failing intermittently In-Reply-To: <4FEAC24B.50709@oracle.com> References: <4FE98037.2050700@oracle.com> <4FEA300D.6090705@oracle.com> <4FEA5E76.1030400@oracle.com> <4FEAAED2.8000901@oracle.com> <4FEAB71A.8050809@oracle.com> <4FEAC24B.50709@oracle.com> Message-ID: <4FECCA83.5070503@oracle.com> And here's the webrev for this one: http://cr.openjdk.java.net/~smarks/yiming.wang/6948101/webrev.0/ Also looks good to me. It's pretty similar to the other fix (7123972). If there are no further comments I'll push this in the next day or so. * * * Some further comments, mainly aimed at the likes of David Holmes. I'm mostly "thinking out loud" at the moment. While I'm glad to see the reliability of these tests improved and to see them come off the problem list, it would be nice to see something more general that could be shared among other tests, and possibly more abstract so that things can be tuned to different VM characteristics if necessary. Basically what these tests want to do is to make sure that a certain object gets garbage collected. I think this is pretty common. There are several dozen tests in the jdk repo that have the word "leak" in them. I bet they all use different techniques to detect leaks. :-( The technique used here is to get a weak reference to the object, and then use the object's finalizer to set a bit telling us when finalization has occurred. At this point we can assert that the weak ref has been cleared. In addition to being somewhat roundabout, this also seems like we're merely cross-checking the garbage collector. We could easily poll for the weak ref being cleared, and then assert that the bit set by finalization has indeed been set. It seems to me we could avoid finalization entirely and just use weak refs and reference queues. Would it have the same effect and semantics as the current test if we were to do the following? - with a target object, make a weak reference registered with a ref queue - clear all references to the target object - request gc - request finalization (is this necessary?) - wait or poll on the ref queue If we get our weak ref from the queue, success. If we time out, fail. Note that there is a timeout mechanism ReferenceQueue.remove(timeout), so we could set some timeout without waiting the full jtreg timeout if we don't want to. Or we could call System.gc() in a loop using remove() with a short timeout (instead of sleep), similar to the current test, although it's not clear to me this is necessary. s'marks On 6/27/12 1:20 AM, Eric Wang wrote: > Hi David, > > Thank you for review! > > Hi Stuart, > > Can you please help to review and post the webrev, Thanks a lot! > > Eric > > On 2012/6/27 15:32, David Holmes wrote: >> On 27/06/2012 4:57 PM, Eric Wang wrote: >>> Hi David & Stuart, >>> >>> Thank you for the help! please review the in webrev 6948101.zip in >>> attachment. >> >> Thanks Eric. That fix also seems fine to me. >> >> David >> >> >>> Regards, >>> Eric >>> >>> On 2012/6/27 9:14, Stuart Marks wrote: >>>> Hi Eric, >>>> >>>> Alan Bateman asked me to help you out with this since he's going to be >>>> unavailable for a couple weeks. >>>> >>>> I didn't see you on the OpenJDK census [1] so you might not have an >>>> Author role and thus the ability to post webrevs. If indeed you don't, >>>> I can post a webrev for you. I can also post a webrev for your other >>>> review (7123972) if it's still necessary. >>>> >>>> Finally, I can push the fixes for you when the reviews are complete. >>>> >>>> s'marks >>>> >>>> [1] http://openjdk.java.net/census >>>> >>>> On 6/26/12 2:56 PM, David Holmes wrote: >>>>> Hi Eric, >>>>> >>>>> On 26/06/2012 7:26 PM, Eric Wang wrote: >>>>>> Please help to review the fix attached for test bug 6948101 >>>>>> which is same root >>>>>> cause as bug 7123972 >>>>>> . >>>>>> The test makes wrong assumption that GC is started immediately to >>>>>> recycle unused objects after System.gc() called. >>>>>> The proposed fix is to make sure objects have been recycled by GC >>>>>> before >>>>>> checking if the weak reference is null. >>>>> >>>>> Again I really need to see a webrev to see the fix in context. Do you >>>>> have >>>>> Author role and an OpenJDK user name so you can post webrevs on >>>>> cr.openjdk.java.net? >>>>> >>>>> I suspect this may have the same issues as the other fix and require >>>>> a timeout >>>>> for when the original problem is still present. >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> Regards, >>>>>> Eric >>> > From david.holmes at oracle.com Thu Jun 28 21:54:28 2012 From: david.holmes at oracle.com (David Holmes) Date: Fri, 29 Jun 2012 07:54:28 +1000 Subject: [PATCH] Review Request - Test bug: 6948101 java/rmi/transport/pinLastArguments/PinLastArguments.java failing intermittently In-Reply-To: <4FECCA83.5070503@oracle.com> References: <4FE98037.2050700@oracle.com> <4FEA300D.6090705@oracle.com> <4FEA5E76.1030400@oracle.com> <4FEAAED2.8000901@oracle.com> <4FEAB71A.8050809@oracle.com> <4FEAC24B.50709@oracle.com> <4FECCA83.5070503@oracle.com> Message-ID: <4FECD294.5080200@oracle.com> Hi Stuart, I don't think finalization or reference queues are needed in this case. We could simply do: while(true) { System.gc(); if (weakRef.get() == null) break; } We have to remember that this is not testing the correct operation of weak references, nor of finalization, but simply that no unintended strong references remain to the object referenced via the WeakReference. So if a strong ref remains, or somehow weakrefs are broken, then the loop will not terminate on its own and we rely on the test harness timing it out. David ----- On 29/06/2012 7:20 AM, Stuart Marks wrote: > And here's the webrev for this one: > > http://cr.openjdk.java.net/~smarks/yiming.wang/6948101/webrev.0/ > > Also looks good to me. It's pretty similar to the other fix (7123972). > If there are no further comments I'll push this in the next day or so. > > * * * > > Some further comments, mainly aimed at the likes of David Holmes. I'm > mostly "thinking out loud" at the moment. > > While I'm glad to see the reliability of these tests improved and to see > them come off the problem list, it would be nice to see something more > general that could be shared among other tests, and possibly more > abstract so that things can be tuned to different VM characteristics if > necessary. > > Basically what these tests want to do is to make sure that a certain > object gets garbage collected. I think this is pretty common. There are > several dozen tests in the jdk repo that have the word "leak" in them. I > bet they all use different techniques to detect leaks. :-( > > The technique used here is to get a weak reference to the object, and > then use the object's finalizer to set a bit telling us when > finalization has occurred. At this point we can assert that the weak ref > has been cleared. In addition to being somewhat roundabout, this also > seems like we're merely cross-checking the garbage collector. We could > easily poll for the weak ref being cleared, and then assert that the bit > set by finalization has indeed been set. > > It seems to me we could avoid finalization entirely and just use weak > refs and reference queues. Would it have the same effect and semantics > as the current test if we were to do the following? > > - with a target object, make a weak reference registered with a ref queue > - clear all references to the target object > - request gc > - request finalization (is this necessary?) > - wait or poll on the ref queue > > If we get our weak ref from the queue, success. If we time out, fail. > Note that there is a timeout mechanism ReferenceQueue.remove(timeout), > so we could set some timeout without waiting the full jtreg timeout if > we don't want to. Or we could call System.gc() in a loop using remove() > with a short timeout (instead of sleep), similar to the current test, > although it's not clear to me this is necessary. > > s'marks > > > On 6/27/12 1:20 AM, Eric Wang wrote: >> Hi David, >> >> Thank you for review! >> >> Hi Stuart, >> >> Can you please help to review and post the webrev, Thanks a lot! >> >> Eric >> >> On 2012/6/27 15:32, David Holmes wrote: >>> On 27/06/2012 4:57 PM, Eric Wang wrote: >>>> Hi David & Stuart, >>>> >>>> Thank you for the help! please review the in webrev 6948101.zip in >>>> attachment. >>> >>> Thanks Eric. That fix also seems fine to me. >>> >>> David >>> >>> >>>> Regards, >>>> Eric >>>> >>>> On 2012/6/27 9:14, Stuart Marks wrote: >>>>> Hi Eric, >>>>> >>>>> Alan Bateman asked me to help you out with this since he's going to be >>>>> unavailable for a couple weeks. >>>>> >>>>> I didn't see you on the OpenJDK census [1] so you might not have an >>>>> Author role and thus the ability to post webrevs. If indeed you don't, >>>>> I can post a webrev for you. I can also post a webrev for your other >>>>> review (7123972) if it's still necessary. >>>>> >>>>> Finally, I can push the fixes for you when the reviews are complete. >>>>> >>>>> s'marks >>>>> >>>>> [1] http://openjdk.java.net/census >>>>> >>>>> On 6/26/12 2:56 PM, David Holmes wrote: >>>>>> Hi Eric, >>>>>> >>>>>> On 26/06/2012 7:26 PM, Eric Wang wrote: >>>>>>> Please help to review the fix attached for test bug 6948101 >>>>>>> which is same >>>>>>> root >>>>>>> cause as bug 7123972 >>>>>>> . >>>>>>> The test makes wrong assumption that GC is started immediately to >>>>>>> recycle unused objects after System.gc() called. >>>>>>> The proposed fix is to make sure objects have been recycled by GC >>>>>>> before >>>>>>> checking if the weak reference is null. >>>>>> >>>>>> Again I really need to see a webrev to see the fix in context. Do you >>>>>> have >>>>>> Author role and an OpenJDK user name so you can post webrevs on >>>>>> cr.openjdk.java.net? >>>>>> >>>>>> I suspect this may have the same issues as the other fix and require >>>>>> a timeout >>>>>> for when the original problem is still present. >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>>> Regards, >>>>>>> Eric >>>> >> From yiming.wang at oracle.com Fri Jun 29 02:10:13 2012 From: yiming.wang at oracle.com (Eric Wang) Date: Fri, 29 Jun 2012 10:10:13 +0800 Subject: [PATCH] Review Request - Test bug: 6948101 java/rmi/transport/pinLastArguments/PinLastArguments.java failing intermittently In-Reply-To: <4FECD294.5080200@oracle.com> References: <4FE98037.2050700@oracle.com> <4FEA300D.6090705@oracle.com> <4FEA5E76.1030400@oracle.com> <4FEAAED2.8000901@oracle.com> <4FEAB71A.8050809@oracle.com> <4FEAC24B.50709@oracle.com> <4FECCA83.5070503@oracle.com> <4FECD294.5080200@oracle.com> Message-ID: <4FED0E85.4000106@oracle.com> Hi Stuart, Thank you, The fix looks simpler than the previous one, it shoud be better to add a Thread.sleep(20) in the loop to avoid multiple calls on System.gc(); Here is a small question if it is possible that after GC, the strong ref remains but somehow weakref is broken?so the loop will terminate and the test will fake pass. while(!finalized) { System.gc(); Thread.sleep(20); if(ref.get() == null) { //strong ref remains but somehow weakref broken break; } } if (ref.get() != null) { //if weakref broken, test will fake pass throw new Error("TEST FAILED: impl not garbage collected"); } Thanks, Eric On 2012/6/29 5:54, David Holmes wrote: > Hi Stuart, > > I don't think finalization or reference queues are needed in this > case. We could simply do: > > while(true) { > System.gc(); > if (weakRef.get() == null) > break; > } > > We have to remember that this is not testing the correct operation of > weak references, nor of finalization, but simply that no unintended > strong references remain to the object referenced via the WeakReference. > > So if a strong ref remains, or somehow weakrefs are broken, then the > loop will not terminate on its own and we rely on the test harness > timing it out. > > David > ----- > > On 29/06/2012 7:20 AM, Stuart Marks wrote: >> And here's the webrev for this one: >> >> http://cr.openjdk.java.net/~smarks/yiming.wang/6948101/webrev.0/ >> >> Also looks good to me. It's pretty similar to the other fix (7123972). >> If there are no further comments I'll push this in the next day or so. >> >> * * * >> >> Some further comments, mainly aimed at the likes of David Holmes. I'm >> mostly "thinking out loud" at the moment. >> >> While I'm glad to see the reliability of these tests improved and to see >> them come off the problem list, it would be nice to see something more >> general that could be shared among other tests, and possibly more >> abstract so that things can be tuned to different VM characteristics if >> necessary. >> >> Basically what these tests want to do is to make sure that a certain >> object gets garbage collected. I think this is pretty common. There are >> several dozen tests in the jdk repo that have the word "leak" in them. I >> bet they all use different techniques to detect leaks. :-( >> >> The technique used here is to get a weak reference to the object, and >> then use the object's finalizer to set a bit telling us when >> finalization has occurred. At this point we can assert that the weak ref >> has been cleared. In addition to being somewhat roundabout, this also >> seems like we're merely cross-checking the garbage collector. We could >> easily poll for the weak ref being cleared, and then assert that the bit >> set by finalization has indeed been set. >> >> It seems to me we could avoid finalization entirely and just use weak >> refs and reference queues. Would it have the same effect and semantics >> as the current test if we were to do the following? >> >> - with a target object, make a weak reference registered with a ref >> queue >> - clear all references to the target object >> - request gc >> - request finalization (is this necessary?) >> - wait or poll on the ref queue >> >> If we get our weak ref from the queue, success. If we time out, fail. >> Note that there is a timeout mechanism ReferenceQueue.remove(timeout), >> so we could set some timeout without waiting the full jtreg timeout if >> we don't want to. Or we could call System.gc() in a loop using remove() >> with a short timeout (instead of sleep), similar to the current test, >> although it's not clear to me this is necessary. >> >> s'marks >> >> >> On 6/27/12 1:20 AM, Eric Wang wrote: >>> Hi David, >>> >>> Thank you for review! >>> >>> Hi Stuart, >>> >>> Can you please help to review and post the webrev, Thanks a lot! >>> >>> Eric >>> >>> On 2012/6/27 15:32, David Holmes wrote: >>>> On 27/06/2012 4:57 PM, Eric Wang wrote: >>>>> Hi David & Stuart, >>>>> >>>>> Thank you for the help! please review the in webrev 6948101.zip in >>>>> attachment. >>>> >>>> Thanks Eric. That fix also seems fine to me. >>>> >>>> David >>>> >>>> >>>>> Regards, >>>>> Eric >>>>> >>>>> On 2012/6/27 9:14, Stuart Marks wrote: >>>>>> Hi Eric, >>>>>> >>>>>> Alan Bateman asked me to help you out with this since he's going >>>>>> to be >>>>>> unavailable for a couple weeks. >>>>>> >>>>>> I didn't see you on the OpenJDK census [1] so you might not have an >>>>>> Author role and thus the ability to post webrevs. If indeed you >>>>>> don't, >>>>>> I can post a webrev for you. I can also post a webrev for your other >>>>>> review (7123972) if it's still necessary. >>>>>> >>>>>> Finally, I can push the fixes for you when the reviews are complete. >>>>>> >>>>>> s'marks >>>>>> >>>>>> [1] http://openjdk.java.net/census >>>>>> >>>>>> On 6/26/12 2:56 PM, David Holmes wrote: >>>>>>> Hi Eric, >>>>>>> >>>>>>> On 26/06/2012 7:26 PM, Eric Wang wrote: >>>>>>>> Please help to review the fix attached for test bug 6948101 >>>>>>>> which is same >>>>>>>> root >>>>>>>> cause as bug 7123972 >>>>>>>> . >>>>>>>> The test makes wrong assumption that GC is started immediately to >>>>>>>> recycle unused objects after System.gc() called. >>>>>>>> The proposed fix is to make sure objects have been recycled by GC >>>>>>>> before >>>>>>>> checking if the weak reference is null. >>>>>>> >>>>>>> Again I really need to see a webrev to see the fix in context. >>>>>>> Do you >>>>>>> have >>>>>>> Author role and an OpenJDK user name so you can post webrevs on >>>>>>> cr.openjdk.java.net? >>>>>>> >>>>>>> I suspect this may have the same issues as the other fix and >>>>>>> require >>>>>>> a timeout >>>>>>> for when the original problem is still present. >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>>> Regards, >>>>>>>> Eric >>>>> >>> From david.holmes at oracle.com Fri Jun 29 03:04:53 2012 From: david.holmes at oracle.com (David Holmes) Date: Fri, 29 Jun 2012 13:04:53 +1000 Subject: [PATCH] Review Request - Test bug: 6948101 java/rmi/transport/pinLastArguments/PinLastArguments.java failing intermittently In-Reply-To: <4FED0E85.4000106@oracle.com> References: <4FE98037.2050700@oracle.com> <4FEA300D.6090705@oracle.com> <4FEA5E76.1030400@oracle.com> <4FEAAED2.8000901@oracle.com> <4FEAB71A.8050809@oracle.com> <4FEAC24B.50709@oracle.com> <4FECCA83.5070503@oracle.com> <4FECD294.5080200@oracle.com> <4FED0E85.4000106@oracle.com> Message-ID: <4FED1B55.2030507@oracle.com> On 29/06/2012 12:10 PM, Eric Wang wrote: > Hi Stuart, > > Thank you, The fix looks simpler than the previous one, it shoud be > better to add a Thread.sleep(20) in the loop to avoid multiple calls on > System.gc(); Oops I missed the sleep out of my suggestion too. > Here is a small question if it is possible that after GC, the strong ref > remains but somehow weakref is broken?so the loop will terminate and > the test will fake pass. As I said previously this isn't trying to test the GC. Broken weakrefs should be detected by weakref tests. David ----- > > while(!finalized) { > System.gc(); > Thread.sleep(20); > if(ref.get() == null) { //strong ref remains but somehow weakref broken > break; > } > } > > if (ref.get() != null) { //if weakref broken, test will fake pass > throw new Error("TEST FAILED: impl not garbage collected"); > } > > Thanks, > Eric > On 2012/6/29 5:54, David Holmes wrote: >> Hi Stuart, >> >> I don't think finalization or reference queues are needed in this >> case. We could simply do: >> >> while(true) { >> System.gc(); >> if (weakRef.get() == null) >> break; >> } >> >> We have to remember that this is not testing the correct operation of >> weak references, nor of finalization, but simply that no unintended >> strong references remain to the object referenced via the WeakReference. >> >> So if a strong ref remains, or somehow weakrefs are broken, then the >> loop will not terminate on its own and we rely on the test harness >> timing it out. >> >> David >> ----- >> >> On 29/06/2012 7:20 AM, Stuart Marks wrote: >>> And here's the webrev for this one: >>> >>> http://cr.openjdk.java.net/~smarks/yiming.wang/6948101/webrev.0/ >>> >>> Also looks good to me. It's pretty similar to the other fix (7123972). >>> If there are no further comments I'll push this in the next day or so. >>> >>> * * * >>> >>> Some further comments, mainly aimed at the likes of David Holmes. I'm >>> mostly "thinking out loud" at the moment. >>> >>> While I'm glad to see the reliability of these tests improved and to see >>> them come off the problem list, it would be nice to see something more >>> general that could be shared among other tests, and possibly more >>> abstract so that things can be tuned to different VM characteristics if >>> necessary. >>> >>> Basically what these tests want to do is to make sure that a certain >>> object gets garbage collected. I think this is pretty common. There are >>> several dozen tests in the jdk repo that have the word "leak" in them. I >>> bet they all use different techniques to detect leaks. :-( >>> >>> The technique used here is to get a weak reference to the object, and >>> then use the object's finalizer to set a bit telling us when >>> finalization has occurred. At this point we can assert that the weak ref >>> has been cleared. In addition to being somewhat roundabout, this also >>> seems like we're merely cross-checking the garbage collector. We could >>> easily poll for the weak ref being cleared, and then assert that the bit >>> set by finalization has indeed been set. >>> >>> It seems to me we could avoid finalization entirely and just use weak >>> refs and reference queues. Would it have the same effect and semantics >>> as the current test if we were to do the following? >>> >>> - with a target object, make a weak reference registered with a ref >>> queue >>> - clear all references to the target object >>> - request gc >>> - request finalization (is this necessary?) >>> - wait or poll on the ref queue >>> >>> If we get our weak ref from the queue, success. If we time out, fail. >>> Note that there is a timeout mechanism ReferenceQueue.remove(timeout), >>> so we could set some timeout without waiting the full jtreg timeout if >>> we don't want to. Or we could call System.gc() in a loop using remove() >>> with a short timeout (instead of sleep), similar to the current test, >>> although it's not clear to me this is necessary. >>> >>> s'marks >>> >>> >>> On 6/27/12 1:20 AM, Eric Wang wrote: >>>> Hi David, >>>> >>>> Thank you for review! >>>> >>>> Hi Stuart, >>>> >>>> Can you please help to review and post the webrev, Thanks a lot! >>>> >>>> Eric >>>> >>>> On 2012/6/27 15:32, David Holmes wrote: >>>>> On 27/06/2012 4:57 PM, Eric Wang wrote: >>>>>> Hi David & Stuart, >>>>>> >>>>>> Thank you for the help! please review the in webrev 6948101.zip in >>>>>> attachment. >>>>> >>>>> Thanks Eric. That fix also seems fine to me. >>>>> >>>>> David >>>>> >>>>> >>>>>> Regards, >>>>>> Eric >>>>>> >>>>>> On 2012/6/27 9:14, Stuart Marks wrote: >>>>>>> Hi Eric, >>>>>>> >>>>>>> Alan Bateman asked me to help you out with this since he's going >>>>>>> to be >>>>>>> unavailable for a couple weeks. >>>>>>> >>>>>>> I didn't see you on the OpenJDK census [1] so you might not have an >>>>>>> Author role and thus the ability to post webrevs. If indeed you >>>>>>> don't, >>>>>>> I can post a webrev for you. I can also post a webrev for your other >>>>>>> review (7123972) if it's still necessary. >>>>>>> >>>>>>> Finally, I can push the fixes for you when the reviews are complete. >>>>>>> >>>>>>> s'marks >>>>>>> >>>>>>> [1] http://openjdk.java.net/census >>>>>>> >>>>>>> On 6/26/12 2:56 PM, David Holmes wrote: >>>>>>>> Hi Eric, >>>>>>>> >>>>>>>> On 26/06/2012 7:26 PM, Eric Wang wrote: >>>>>>>>> Please help to review the fix attached for test bug 6948101 >>>>>>>>> which is same >>>>>>>>> root >>>>>>>>> cause as bug 7123972 >>>>>>>>> . >>>>>>>>> The test makes wrong assumption that GC is started immediately to >>>>>>>>> recycle unused objects after System.gc() called. >>>>>>>>> The proposed fix is to make sure objects have been recycled by GC >>>>>>>>> before >>>>>>>>> checking if the weak reference is null. >>>>>>>> >>>>>>>> Again I really need to see a webrev to see the fix in context. >>>>>>>> Do you >>>>>>>> have >>>>>>>> Author role and an OpenJDK user name so you can post webrevs on >>>>>>>> cr.openjdk.java.net? >>>>>>>> >>>>>>>> I suspect this may have the same issues as the other fix and >>>>>>>> require >>>>>>>> a timeout >>>>>>>> for when the original problem is still present. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Eric >>>>>> >>>> > From xueming.shen at oracle.com Fri Jun 29 05:09:06 2012 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 28 Jun 2012 22:09:06 -0700 Subject: Fwd: Codereview request 7175845:"jar uf" changes file permissions unexpectedly In-Reply-To: <4FED1FA1.4030005@oracle.com> References: <4FED1FA1.4030005@oracle.com> Message-ID: <4FED3872.5080509@oracle.com> -------- Original Message -------- Subject: Codereview request 7175845:"jar uf" changes file permissions unexpectedly Date: Thu, 28 Jun 2012 20:23:13 -0700 From: Xueming Shen To: Abhi.Saha at Oracle.Com Abhijit, please help review the changes for 7175845:"jar uf" changes file permissions unexpectedly 7177216: native2ascii changes file permissions of input file webrev is at http://cr.openjdk.java.net/~sherman/7175845_7177216/webrev/ Background info: This is a regression triggered by the fix we put in for #7143606 in which we switched most use of File.createTempFile to java.nio version Files.creteTempFile in j2se repository, aimed to make sure the temporary files created by jvm for its internal use have more restrict read/ write permission. Unfortunately it appears the changes made in jar and native2ascii tools are inappropriate and triggered regression. The fix here is to back out the change we made in these two tools. -Sherman From xueming.shen at oracle.com Fri Jun 29 05:50:06 2012 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Fri, 29 Jun 2012 05:50:06 +0000 Subject: hg: jdk8/tl/jdk: 7175845: jar uf changes file permissions unexpectedly; ... Message-ID: <20120629055025.E625C47BBE@hg.openjdk.java.net> Changeset: 819258b5002e Author: sherman Date: 2012-06-28 22:44 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/819258b5002e 7175845: jar uf changes file permissions unexpectedly 7177216: native2ascii changes file permissions of input file Summary: undo the File.createTempFile change in jar and native2ascii Reviewed-by: asaha ! src/share/classes/sun/tools/jar/Main.java ! src/share/classes/sun/tools/native2ascii/Main.java + test/sun/tools/native2ascii/Permission.java + test/tools/jar/UpdateJar.java From yiming.wang at oracle.com Fri Jun 29 08:31:02 2012 From: yiming.wang at oracle.com (Eric Wang) Date: Fri, 29 Jun 2012 16:31:02 +0800 Subject: [PATCH] Review Request - Test bug: 6948101 java/rmi/transport/pinLastArguments/PinLastArguments.java failing intermittently In-Reply-To: <4FED1B55.2030507@oracle.com> References: <4FE98037.2050700@oracle.com> <4FEA300D.6090705@oracle.com> <4FEA5E76.1030400@oracle.com> <4FEAAED2.8000901@oracle.com> <4FEAB71A.8050809@oracle.com> <4FEAC24B.50709@oracle.com> <4FECCA83.5070503@oracle.com> <4FECD294.5080200@oracle.com> <4FED0E85.4000106@oracle.com> <4FED1B55.2030507@oracle.com> Message-ID: <4FED67C6.1070504@oracle.com> Hi David, I have made changes by following your suggestion. Can you please help to review again? Thanks a lot! I also change the code of 7123972 which is sent in another mail. Regards, Eric On 2012/6/29 11:04, David Holmes wrote: > On 29/06/2012 12:10 PM, Eric Wang wrote: >> Hi Stuart, >> >> Thank you, The fix looks simpler than the previous one, it shoud be >> better to add a Thread.sleep(20) in the loop to avoid multiple calls on >> System.gc(); > > Oops I missed the sleep out of my suggestion too. > >> Here is a small question if it is possible that after GC, the strong ref >> remains but somehow weakref is broken?so the loop will terminate and >> the test will fake pass. > > As I said previously this isn't trying to test the GC. Broken weakrefs > should be detected by weakref tests. > > David > ----- > >> >> while(!finalized) { >> System.gc(); >> Thread.sleep(20); >> if(ref.get() == null) { //strong ref remains but somehow weakref broken >> break; >> } >> } >> >> if (ref.get() != null) { //if weakref broken, test will fake pass >> throw new Error("TEST FAILED: impl not garbage collected"); >> } >> >> Thanks, >> Eric >> On 2012/6/29 5:54, David Holmes wrote: >>> Hi Stuart, >>> >>> I don't think finalization or reference queues are needed in this >>> case. We could simply do: >>> >>> while(true) { >>> System.gc(); >>> if (weakRef.get() == null) >>> break; >>> } >>> >>> We have to remember that this is not testing the correct operation of >>> weak references, nor of finalization, but simply that no unintended >>> strong references remain to the object referenced via the >>> WeakReference. >>> >>> So if a strong ref remains, or somehow weakrefs are broken, then the >>> loop will not terminate on its own and we rely on the test harness >>> timing it out. >>> >>> David >>> ----- >>> >>> On 29/06/2012 7:20 AM, Stuart Marks wrote: >>>> And here's the webrev for this one: >>>> >>>> http://cr.openjdk.java.net/~smarks/yiming.wang/6948101/webrev.0/ >>>> >>>> Also looks good to me. It's pretty similar to the other fix (7123972). >>>> If there are no further comments I'll push this in the next day or so. >>>> >>>> * * * >>>> >>>> Some further comments, mainly aimed at the likes of David Holmes. I'm >>>> mostly "thinking out loud" at the moment. >>>> >>>> While I'm glad to see the reliability of these tests improved and >>>> to see >>>> them come off the problem list, it would be nice to see something more >>>> general that could be shared among other tests, and possibly more >>>> abstract so that things can be tuned to different VM >>>> characteristics if >>>> necessary. >>>> >>>> Basically what these tests want to do is to make sure that a certain >>>> object gets garbage collected. I think this is pretty common. There >>>> are >>>> several dozen tests in the jdk repo that have the word "leak" in >>>> them. I >>>> bet they all use different techniques to detect leaks. :-( >>>> >>>> The technique used here is to get a weak reference to the object, and >>>> then use the object's finalizer to set a bit telling us when >>>> finalization has occurred. At this point we can assert that the >>>> weak ref >>>> has been cleared. In addition to being somewhat roundabout, this also >>>> seems like we're merely cross-checking the garbage collector. We could >>>> easily poll for the weak ref being cleared, and then assert that >>>> the bit >>>> set by finalization has indeed been set. >>>> >>>> It seems to me we could avoid finalization entirely and just use weak >>>> refs and reference queues. Would it have the same effect and semantics >>>> as the current test if we were to do the following? >>>> >>>> - with a target object, make a weak reference registered with a ref >>>> queue >>>> - clear all references to the target object >>>> - request gc >>>> - request finalization (is this necessary?) >>>> - wait or poll on the ref queue >>>> >>>> If we get our weak ref from the queue, success. If we time out, fail. >>>> Note that there is a timeout mechanism ReferenceQueue.remove(timeout), >>>> so we could set some timeout without waiting the full jtreg timeout if >>>> we don't want to. Or we could call System.gc() in a loop using >>>> remove() >>>> with a short timeout (instead of sleep), similar to the current test, >>>> although it's not clear to me this is necessary. >>>> >>>> s'marks >>>> >>>> >>>> On 6/27/12 1:20 AM, Eric Wang wrote: >>>>> Hi David, >>>>> >>>>> Thank you for review! >>>>> >>>>> Hi Stuart, >>>>> >>>>> Can you please help to review and post the webrev, Thanks a lot! >>>>> >>>>> Eric >>>>> >>>>> On 2012/6/27 15:32, David Holmes wrote: >>>>>> On 27/06/2012 4:57 PM, Eric Wang wrote: >>>>>>> Hi David & Stuart, >>>>>>> >>>>>>> Thank you for the help! please review the in webrev 6948101.zip in >>>>>>> attachment. >>>>>> >>>>>> Thanks Eric. That fix also seems fine to me. >>>>>> >>>>>> David >>>>>> >>>>>> >>>>>>> Regards, >>>>>>> Eric >>>>>>> >>>>>>> On 2012/6/27 9:14, Stuart Marks wrote: >>>>>>>> Hi Eric, >>>>>>>> >>>>>>>> Alan Bateman asked me to help you out with this since he's going >>>>>>>> to be >>>>>>>> unavailable for a couple weeks. >>>>>>>> >>>>>>>> I didn't see you on the OpenJDK census [1] so you might not >>>>>>>> have an >>>>>>>> Author role and thus the ability to post webrevs. If indeed you >>>>>>>> don't, >>>>>>>> I can post a webrev for you. I can also post a webrev for your >>>>>>>> other >>>>>>>> review (7123972) if it's still necessary. >>>>>>>> >>>>>>>> Finally, I can push the fixes for you when the reviews are >>>>>>>> complete. >>>>>>>> >>>>>>>> s'marks >>>>>>>> >>>>>>>> [1] http://openjdk.java.net/census >>>>>>>> >>>>>>>> On 6/26/12 2:56 PM, David Holmes wrote: >>>>>>>>> Hi Eric, >>>>>>>>> >>>>>>>>> On 26/06/2012 7:26 PM, Eric Wang wrote: >>>>>>>>>> Please help to review the fix attached for test bug 6948101 >>>>>>>>>> which is >>>>>>>>>> same >>>>>>>>>> root >>>>>>>>>> cause as bug 7123972 >>>>>>>>>> . >>>>>>>>>> The test makes wrong assumption that GC is started >>>>>>>>>> immediately to >>>>>>>>>> recycle unused objects after System.gc() called. >>>>>>>>>> The proposed fix is to make sure objects have been recycled >>>>>>>>>> by GC >>>>>>>>>> before >>>>>>>>>> checking if the weak reference is null. >>>>>>>>> >>>>>>>>> Again I really need to see a webrev to see the fix in context. >>>>>>>>> Do you >>>>>>>>> have >>>>>>>>> Author role and an OpenJDK user name so you can post webrevs on >>>>>>>>> cr.openjdk.java.net? >>>>>>>>> >>>>>>>>> I suspect this may have the same issues as the other fix and >>>>>>>>> require >>>>>>>>> a timeout >>>>>>>>> for when the original problem is still present. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> David >>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> Eric >>>>>>> >>>>> >> -------------- next part -------------- --- old/test/ProblemList.txt 2012-06-29 16:22:24.447967771 +0800 +++ new/test/ProblemList.txt 2012-06-29 16:22:22.518924402 +0800 @@ -271,9 +271,6 @@ # 7140992 java/rmi/server/Unreferenced/finiteGCLatency/FiniteGCLatency.java generic-all -# 6948101 -java/rmi/transport/pinLastArguments/PinLastArguments.java generic-all - # 7146541 java/rmi/transport/rapidExportUnexport/RapidExportUnexport.java linux-all -------------- next part -------------- --- old/test/java/rmi/transport/pinLastArguments/PinLastArguments.java 2012-06-29 16:22:29.171886035 +0800 +++ new/test/java/rmi/transport/pinLastArguments/PinLastArguments.java 2012-06-29 16:22:28.092898950 +0800 @@ -78,7 +78,13 @@ } impl = null; - System.gc(); + while(true) { + System.gc(); + Thread.sleep(20); + if(ref.get() == null) { + break; + } + } if (ref.get() != null) { throw new Error("TEST FAILED: impl not garbage collected"); From yiming.wang at oracle.com Fri Jun 29 08:36:24 2012 From: yiming.wang at oracle.com (Eric Wang) Date: Fri, 29 Jun 2012 16:36:24 +0800 Subject: Patch review request - Test bug 7123972 test/java/lang/annotation/loaderLeak/Main.java fails intermittently In-Reply-To: <4FEBE02D.6010406@oracle.com> References: <4FE2B997.7090204@oracle.com> <4FE2BFFB.8010705@oracle.com> <4FE2FE2C.1020601@oracle.com> <4FE310BB.6000100@oracle.com> <4FE81BFC.8040206@oracle.com> <4FEA2EFB.4050109@oracle.com> <4FEAA608.1000502@oracle.com> <4FEAAD38.7020304@oracle.com> <4FEBE02D.6010406@oracle.com> Message-ID: <4FED6908.7080405@oracle.com> Hi Stuart & David? Attachment is the new changes to make code simply by following David suggestion, Can you help please review again, Thanks a lot! Regards, Eric On 2012/6/28 12:40, Stuart Marks wrote: > I've posted the webrev here: > > http://cr.openjdk.java.net/~smarks/yiming.wang/7123972/webrev.0/ > > I've looked at the changes and they seem fine. > > It's interesting that the run times take 30-60 sec in your experience. > I've run them on my system (Linux in a virtual machine) and they > usually run in 10-20 sec. In any case, as you say, if the test times > out it indicates there really was a failure. > > I'll give people a chance to look at the webrev and if there aren't > any more comments in another day or so I'll push in the changeset. > > Thanks for developing this! > > s'marks > > On 6/26/12 11:50 PM, Eric Wang wrote: >> Hi David, >> >> Thank you! I run the test several times on 3 platforms (windows, >> solaris and >> linux), the average execution time is 30secs to 60secs. if the test >> hang 2 >> minutes, there should be something wrong. >> >> Hi Marks, >> >> I don't have the author role, Can you please help to review and post >> the webrev >> 7123972.zip in attachment if it is OK, Thanks a lot! >> >> Regards, >> Eric >> >> On 2012/6/27 14:19, David Holmes wrote: >>> Eric, >>> >>> Ignore my comment about adding the timeouts. As Alan reminded me if >>> the test >>> would hang then jtreg will time it out after two minutes anyway. >>> >>> So this is good to go as far as I am concerned. >>> >>> Thanks, >>> David >>> >>> On 27/06/2012 7:51 AM, David Holmes wrote: >>>> Thanks Eric. >>>> >>>> So to summarize: >>>> >>>> - we create a custom classloader, load a class through it and store a >>>> reference to that Class in a WeakReference >>>> - we then drop the reference to the loader >>>> >>>> At this point the only reference to the loader is from the Class >>>> loaded, >>>> which in turn is only weakly reachable. >>>> >>>> I must confess that I'm unclear why this test should be failing in its >>>> original form. The first gc() should remove the strong reference to >>>> the >>>> loader. That leaves a weak cycle: WeakRef -> Class -> Loader -> Class. >>>> The second gc() should detect the cycle and clear the WeakRef. I guess >>>> the problem is that depending on which gc is in use the actual gc() >>>> calls may not in fact induce every possible GC action. >>>> >>>> The fix seems reasonable in that regard - keep gc'ing and finalizing >>>> till we see the loader is gone, and so the WeakReference should be >>>> cleared. The original bug would cause a ref to the Class to remain >>>> (from >>>> the annotation) and hence the WeakRef would not be cleared. >>>> However, in >>>> that case the loader would also be strongly referenced and so never >>>> become finalizable. So if this test was now run against a JDK with the >>>> original bug, the test would hang. So I think we need to add a timeout >>>> in there as well. >>>> >>>> David >>>> >>>> On 25/06/2012 6:06 PM, Eric Wang wrote: >>>>> On 2012/6/21 20:16, David Holmes wrote: >>>>>> Hi Eric, >>>>>> >>>>>> On 21/06/2012 8:57 PM, Eric Wang wrote: >>>>>>> Hi David, >>>>>>> >>>>>>> Thanks for your review, I have updated the code by following your >>>>>>> suggestion. please see the attachment. >>>>>>> I'm not sure whether there's a better way to guarantee object >>>>>>> finalized >>>>>>> by GC definitely within the given time. The proposed fix may >>>>>>> work in >>>>>>> most cases but may still throw InterruptException if execution is >>>>>>> timeout (2 minutes of JTreg by default). >>>>>> >>>>>> There is no way to guarantee finalization in a specific >>>>>> timeframe, but >>>>>> if a simple test hasn't executed finalizers in 2 minutes then >>>>>> that in >>>>>> itself indicates a problem. >>>>>> >>>>>> Can you post a full webrev for this patch? I don't like seeing it >>>>>> out >>>>>> of context and am wondering exactly what we are trying to GC here. >>>>>> >>>>>> David >>>>>> >>>>>>> Regards, >>>>>>> Eric >>>>>>> >>>>>>> On 2012/6/21 14:32, David Holmes wrote: >>>>>>>> Hi Eric, >>>>>>>> >>>>>>>> On 21/06/2012 4:05 PM, Eric Wang wrote: >>>>>>>>> I come from Java SQE team who are interested in regression >>>>>>>>> test bug >>>>>>>>> fix. >>>>>>>>> Here is the first simple fix for bug 7123972 >>>>>>>>> , Can you >>>>>>>>> please >>>>>>>>> help >>>>>>>>> to review and comment? Attachment is the patch Thanks! >>>>>>>>> >>>>>>>>> This bug is caused by wrong assumption that the GC is started >>>>>>>>> immediately to recycle un-referenced objects after System.gc() >>>>>>>>> called >>>>>>>>> one or two times. >>>>>>>>> >>>>>>>>> The proposed solution is to make sure the un-referenced object is >>>>>>>>> recycled by GC before checking if the reference is null. >>>>>>>> >>>>>>>> Your patch makes its own assumptions - specifically that >>>>>>>> finalization >>>>>>>> must eventually run. At a minimum you should add >>>>>>>> System.runFinalization() calls after the System.gc() inside the >>>>>>>> loop. >>>>>>>> Even that is no guarantee in a general sense, though it should >>>>>>>> work >>>>>>>> for hotspot. >>>>>>>> >>>>>>>> David >>>>>>>> >>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Eric >>>>>>> >>>>> Hi Alan & David, >>>>> >>>>> Thank you for your comments, sorry for reply this mail late as i was >>>>> just back from the dragon boat holiday. >>>>> I have updated the code again based on your suggestions: rename >>>>> the flag >>>>> variable, increase the sleep time and remove it from problem list. >>>>> The attachment is the full webrev for this patch, Can you please >>>>> review >>>>> again? Thanks a lot! >>>>> >>>>> Regards, >>>>> Eric >> -------------- next part -------------- --- old/test/ProblemList.txt 2012-06-29 16:03:38.666958301 +0800 +++ new/test/ProblemList.txt 2012-06-29 16:03:37.955871329 +0800 @@ -122,9 +122,6 @@ # jdk_lang -# 7123972 -java/lang/annotation/loaderLeak/Main.java generic-all - # 6944188 java/lang/management/ThreadMXBean/ThreadStateTest.java generic-all -------------- next part -------------- --- old/test/java/lang/annotation/loaderLeak/Main.java 2012-06-29 16:03:41.487870022 +0800 +++ new/test/java/lang/annotation/loaderLeak/Main.java 2012-06-29 16:03:40.780873652 +0800 @@ -57,8 +57,13 @@ System.gc(); System.gc(); loader = null; - System.gc(); - System.gc(); + while(true) { + System.gc(); + Thread.sleep(20); + if(c.get() == null) { + break; + } + } if (c.get() != null) throw new AssertionError(); } } From stuart.marks at oracle.com Fri Jun 29 20:40:37 2012 From: stuart.marks at oracle.com (Stuart Marks) Date: Fri, 29 Jun 2012 13:40:37 -0700 Subject: Bug 7176907 - Patches for javac warnings cleanup (text and util) from Adopt OpenJDK In-Reply-To: References: <4FE1D95C.3030108@univ-mlv.fr> <4FE1F559.5070802@oracle.com> <4FE9FF91.3010400@oracle.com> Message-ID: <4FEE12C5.8080700@oracle.com> Hi Martijn, Thanks for this contribution. I'm finally getting back to it. (Also, Kurchi, Remi, thanks for taking a look as well.) The java.util patches look good and are almost ready to go in. The only issue is how to format the Contributed-by line in the changeset comment. What I have so far for the comment is: 7176907: additional warnings cleanup in java.util, java.util.regexp, java.util.zip Reviewed-by: forax, khazra, smarks Contributed-by: ??? The contributed-by line takes one or more email addresses or email/name pairs. For an earlier contribution from LJC, see here [1]. This isn't a terribly big deal but I want to make sure that credit goes where it's due. Can you tell me what I should put for the contributed-by line? The warnings in java.text have already been fixed by Deepak Bhole's changeset [2]. Not a problem, this took two minutes to figure out. There were a couple questions from earlier in the thread. On the discussion of when the compiler issues switch fallthrough warnings, from what I can tell, the compiler issues a warning whenever there is actual code in a case that doesn't end with break, continue, return, or throw. This seems independent of whether what follows is another case or the 'default' case. If there are several case clauses together with no intervening code, this isn't considered a fallthrough and thus there is no warning. This make sense, as sometimes you want several different cases to be handled by the same code. For example, switch (ch) { case 'a': // no warning here case 'b': someActualWork(); break; // ... } Regarding whether there is a style checker for indentation and spacing, I'm not aware of a good one that I can recommend. We generally adhere to the (very old) Java Coding Conventions [3]. I think most people just deal with style issues manually by hand and by eye; I know I do. We do run jcheck [4] on every incoming changeset, but the only things it checks in files' contents are for trailing whitespace, and CR (as opposed to LF) and TAB characters. s'marks [1] http://hg.openjdk.java.net/jdk8/tl/jdk/rev/445ada5e6b4a [2] http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e309917fb9af [3] http://www.oracle.com/technetwork/java/codeconv-138413.html [4] http://hg.openjdk.java.net/code-tools/jcheck On 6/27/12 9:09 AM, Martijn Verburg wrote: > Hi all, > > We've been working on improving the workflow for our patch review > system and so the new locations for the patches are at: > > https://raw.github.com/AdoptOpenJDK/PatchReview/master/5-submitted/javac_warnings/core_java_text.patch > https://raw.github.com/AdoptOpenJDK/PatchReview/master/5-submitted/javac_warnings/core_java_util.patch > > Cheers, > Martijn > > On 27 June 2012 08:58, Martijn Verburg wrote: >> Hi Kurchi, >> >>> Thanks for updating this. This looks good to me. I guess Stuart will be >>> sponsoring the patch. >> >> For his sins he's kindly offered to do so yes :-) >> >>> There are a couple of other switch statements in >>> src/share/classes/java/util/regex/Pattern.java. >>> which are not throwing fallthrough warnings (in Netbeans at least), >>> although there is fallthrough happening from one case to another. From what >>> I notice, only if there is a break statement >>> missing before the "default" case, does Netbeans throw some warning. Is the >>> fallthrough warning technically >>> supposed to be thrown only when the logic falls through to the default case >>> then? >> >> That's my understanding with the javac compiler yes. I think it was the balance >> that the javac folk thought was a sensible compromise in terms of not >> generating >> too many false positive warnings. >> >> Cheers, >> Martijn From stuart.marks at oracle.com Fri Jun 29 22:00:16 2012 From: stuart.marks at oracle.com (Stuart Marks) Date: Fri, 29 Jun 2012 15:00:16 -0700 Subject: [PATCH] Review Request - Test bug: 6948101 java/rmi/transport/pinLastArguments/PinLastArguments.java failing intermittently In-Reply-To: <4FED67C6.1070504@oracle.com> References: <4FE98037.2050700@oracle.com> <4FEA300D.6090705@oracle.com> <4FEA5E76.1030400@oracle.com> <4FEAAED2.8000901@oracle.com> <4FEAB71A.8050809@oracle.com> <4FEAC24B.50709@oracle.com> <4FECCA83.5070503@oracle.com> <4FECD294.5080200@oracle.com> <4FED0E85.4000106@oracle.com> <4FED1B55.2030507@oracle.com> <4FED67C6.1070504@oracle.com> Message-ID: <4FEE2570.9090602@oracle.com> Thanks for updating this. I've posted the revised webrev: http://cr.openjdk.java.net/~smarks/yiming.wang/6948101/webrev.1/ It's good that this is getting simpler in that we don't have to deal with finalization. But it can still get simpler.... The code is in the webrev but I'll also paste it here for convenience: 81 while(true) { 82 System.gc(); 83 Thread.sleep(20); 84 if(ref.get() == null) { 85 break; 86 } 87 } 88 89 if (ref.get() != null) { 90 throw new Error("TEST FAILED: impl not garbage collected"); 91 } The only way we the loop can terminate normally is if ref.get() returns null, so it's pointless to test ref.get() again after the loop. I'd just take out this second test of ref.get(). Now, how can the test fail? If ref is never cleared, the while loop will never terminate, and we rely on jtreg to timeout and kill this test. It would be good to have a brief comment above the while loop that explains this. Finally, a style nitpick: there should be a space before the ( for the while and if statements. That's the prevailing style we use in the JDK. s'marks On 6/29/12 1:31 AM, Eric Wang wrote: > Hi David, > > I have made changes by following your suggestion. Can you please help to review > again? Thanks a lot! > I also change the code of 7123972 which is sent in another mail. > > Regards, > Eric > > On 2012/6/29 11:04, David Holmes wrote: >> On 29/06/2012 12:10 PM, Eric Wang wrote: >>> Hi Stuart, >>> >>> Thank you, The fix looks simpler than the previous one, it shoud be >>> better to add a Thread.sleep(20) in the loop to avoid multiple calls on >>> System.gc(); >> >> Oops I missed the sleep out of my suggestion too. >> >>> Here is a small question if it is possible that after GC, the strong ref >>> remains but somehow weakref is broken?so the loop will terminate and >>> the test will fake pass. >> >> As I said previously this isn't trying to test the GC. Broken weakrefs should >> be detected by weakref tests. >> >> David >> ----- >> >>> >>> while(!finalized) { >>> System.gc(); >>> Thread.sleep(20); >>> if(ref.get() == null) { //strong ref remains but somehow weakref broken >>> break; >>> } >>> } >>> >>> if (ref.get() != null) { //if weakref broken, test will fake pass >>> throw new Error("TEST FAILED: impl not garbage collected"); >>> } >>> >>> Thanks, >>> Eric >>> On 2012/6/29 5:54, David Holmes wrote: >>>> Hi Stuart, >>>> >>>> I don't think finalization or reference queues are needed in this >>>> case. We could simply do: >>>> >>>> while(true) { >>>> System.gc(); >>>> if (weakRef.get() == null) >>>> break; >>>> } >>>> >>>> We have to remember that this is not testing the correct operation of >>>> weak references, nor of finalization, but simply that no unintended >>>> strong references remain to the object referenced via the WeakReference. >>>> >>>> So if a strong ref remains, or somehow weakrefs are broken, then the >>>> loop will not terminate on its own and we rely on the test harness >>>> timing it out. >>>> >>>> David >>>> ----- >>>> >>>> On 29/06/2012 7:20 AM, Stuart Marks wrote: >>>>> And here's the webrev for this one: >>>>> >>>>> http://cr.openjdk.java.net/~smarks/yiming.wang/6948101/webrev.0/ >>>>> >>>>> Also looks good to me. It's pretty similar to the other fix (7123972). >>>>> If there are no further comments I'll push this in the next day or so. >>>>> >>>>> * * * >>>>> >>>>> Some further comments, mainly aimed at the likes of David Holmes. I'm >>>>> mostly "thinking out loud" at the moment. >>>>> >>>>> While I'm glad to see the reliability of these tests improved and to see >>>>> them come off the problem list, it would be nice to see something more >>>>> general that could be shared among other tests, and possibly more >>>>> abstract so that things can be tuned to different VM characteristics if >>>>> necessary. >>>>> >>>>> Basically what these tests want to do is to make sure that a certain >>>>> object gets garbage collected. I think this is pretty common. There are >>>>> several dozen tests in the jdk repo that have the word "leak" in them. I >>>>> bet they all use different techniques to detect leaks. :-( >>>>> >>>>> The technique used here is to get a weak reference to the object, and >>>>> then use the object's finalizer to set a bit telling us when >>>>> finalization has occurred. At this point we can assert that the weak ref >>>>> has been cleared. In addition to being somewhat roundabout, this also >>>>> seems like we're merely cross-checking the garbage collector. We could >>>>> easily poll for the weak ref being cleared, and then assert that the bit >>>>> set by finalization has indeed been set. >>>>> >>>>> It seems to me we could avoid finalization entirely and just use weak >>>>> refs and reference queues. Would it have the same effect and semantics >>>>> as the current test if we were to do the following? >>>>> >>>>> - with a target object, make a weak reference registered with a ref >>>>> queue >>>>> - clear all references to the target object >>>>> - request gc >>>>> - request finalization (is this necessary?) >>>>> - wait or poll on the ref queue >>>>> >>>>> If we get our weak ref from the queue, success. If we time out, fail. >>>>> Note that there is a timeout mechanism ReferenceQueue.remove(timeout), >>>>> so we could set some timeout without waiting the full jtreg timeout if >>>>> we don't want to. Or we could call System.gc() in a loop using remove() >>>>> with a short timeout (instead of sleep), similar to the current test, >>>>> although it's not clear to me this is necessary. >>>>> >>>>> s'marks >>>>> >>>>> >>>>> On 6/27/12 1:20 AM, Eric Wang wrote: >>>>>> Hi David, >>>>>> >>>>>> Thank you for review! >>>>>> >>>>>> Hi Stuart, >>>>>> >>>>>> Can you please help to review and post the webrev, Thanks a lot! >>>>>> >>>>>> Eric >>>>>> >>>>>> On 2012/6/27 15:32, David Holmes wrote: >>>>>>> On 27/06/2012 4:57 PM, Eric Wang wrote: >>>>>>>> Hi David & Stuart, >>>>>>>> >>>>>>>> Thank you for the help! please review the in webrev 6948101.zip in >>>>>>>> attachment. >>>>>>> >>>>>>> Thanks Eric. That fix also seems fine to me. >>>>>>> >>>>>>> David >>>>>>> >>>>>>> >>>>>>>> Regards, >>>>>>>> Eric >>>>>>>> >>>>>>>> On 2012/6/27 9:14, Stuart Marks wrote: >>>>>>>>> Hi Eric, >>>>>>>>> >>>>>>>>> Alan Bateman asked me to help you out with this since he's going >>>>>>>>> to be >>>>>>>>> unavailable for a couple weeks. >>>>>>>>> >>>>>>>>> I didn't see you on the OpenJDK census [1] so you might not have an >>>>>>>>> Author role and thus the ability to post webrevs. If indeed you >>>>>>>>> don't, >>>>>>>>> I can post a webrev for you. I can also post a webrev for your other >>>>>>>>> review (7123972) if it's still necessary. >>>>>>>>> >>>>>>>>> Finally, I can push the fixes for you when the reviews are complete. >>>>>>>>> >>>>>>>>> s'marks >>>>>>>>> >>>>>>>>> [1] http://openjdk.java.net/census >>>>>>>>> >>>>>>>>> On 6/26/12 2:56 PM, David Holmes wrote: >>>>>>>>>> Hi Eric, >>>>>>>>>> >>>>>>>>>> On 26/06/2012 7:26 PM, Eric Wang wrote: >>>>>>>>>>> Please help to review the fix attached for test bug 6948101 >>>>>>>>>>> which is same >>>>>>>>>>> root >>>>>>>>>>> cause as bug 7123972 >>>>>>>>>>> . >>>>>>>>>>> The test makes wrong assumption that GC is started immediately to >>>>>>>>>>> recycle unused objects after System.gc() called. >>>>>>>>>>> The proposed fix is to make sure objects have been recycled by GC >>>>>>>>>>> before >>>>>>>>>>> checking if the weak reference is null. >>>>>>>>>> >>>>>>>>>> Again I really need to see a webrev to see the fix in context. >>>>>>>>>> Do you >>>>>>>>>> have >>>>>>>>>> Author role and an OpenJDK user name so you can post webrevs on >>>>>>>>>> cr.openjdk.java.net? >>>>>>>>>> >>>>>>>>>> I suspect this may have the same issues as the other fix and >>>>>>>>>> require >>>>>>>>>> a timeout >>>>>>>>>> for when the original problem is still present. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> David >>>>>>>>>> >>>>>>>>>>> Regards, >>>>>>>>>>> Eric >>>>>>>> >>>>>> >>> > From stuart.marks at oracle.com Fri Jun 29 22:01:36 2012 From: stuart.marks at oracle.com (Stuart Marks) Date: Fri, 29 Jun 2012 15:01:36 -0700 Subject: Patch review request - Test bug 7123972 test/java/lang/annotation/loaderLeak/Main.java fails intermittently In-Reply-To: <4FED6908.7080405@oracle.com> References: <4FE2B997.7090204@oracle.com> <4FE2BFFB.8010705@oracle.com> <4FE2FE2C.1020601@oracle.com> <4FE310BB.6000100@oracle.com> <4FE81BFC.8040206@oracle.com> <4FEA2EFB.4050109@oracle.com> <4FEAA608.1000502@oracle.com> <4FEAAD38.7020304@oracle.com> <4FEBE02D.6010406@oracle.com> <4FED6908.7080405@oracle.com> Message-ID: <4FEE25C0.2040900@oracle.com> I've posted the updated webrev here: http://cr.openjdk.java.net/~smarks/yiming.wang/7123972/webrev.1/ This code is pretty much the same as 6948101 and the same comments I had on that bug apply here as well, so please make similar updates to this one. Thanks. s'marks On 6/29/12 1:36 AM, Eric Wang wrote: > Hi Stuart & David? > > Attachment is the new changes to make code simply by following David > suggestion, Can you help please review again, Thanks a lot! > > Regards, > Eric > On 2012/6/28 12:40, Stuart Marks wrote: >> I've posted the webrev here: >> >> http://cr.openjdk.java.net/~smarks/yiming.wang/7123972/webrev.0/ >> >> I've looked at the changes and they seem fine. >> >> It's interesting that the run times take 30-60 sec in your experience. I've >> run them on my system (Linux in a virtual machine) and they usually run in >> 10-20 sec. In any case, as you say, if the test times out it indicates there >> really was a failure. >> >> I'll give people a chance to look at the webrev and if there aren't any more >> comments in another day or so I'll push in the changeset. >> >> Thanks for developing this! >> >> s'marks >> >> On 6/26/12 11:50 PM, Eric Wang wrote: >>> Hi David, >>> >>> Thank you! I run the test several times on 3 platforms (windows, solaris and >>> linux), the average execution time is 30secs to 60secs. if the test hang 2 >>> minutes, there should be something wrong. >>> >>> Hi Marks, >>> >>> I don't have the author role, Can you please help to review and post the webrev >>> 7123972.zip in attachment if it is OK, Thanks a lot! >>> >>> Regards, >>> Eric >>> >>> On 2012/6/27 14:19, David Holmes wrote: >>>> Eric, >>>> >>>> Ignore my comment about adding the timeouts. As Alan reminded me if the test >>>> would hang then jtreg will time it out after two minutes anyway. >>>> >>>> So this is good to go as far as I am concerned. >>>> >>>> Thanks, >>>> David >>>> >>>> On 27/06/2012 7:51 AM, David Holmes wrote: >>>>> Thanks Eric. >>>>> >>>>> So to summarize: >>>>> >>>>> - we create a custom classloader, load a class through it and store a >>>>> reference to that Class in a WeakReference >>>>> - we then drop the reference to the loader >>>>> >>>>> At this point the only reference to the loader is from the Class loaded, >>>>> which in turn is only weakly reachable. >>>>> >>>>> I must confess that I'm unclear why this test should be failing in its >>>>> original form. The first gc() should remove the strong reference to the >>>>> loader. That leaves a weak cycle: WeakRef -> Class -> Loader -> Class. >>>>> The second gc() should detect the cycle and clear the WeakRef. I guess >>>>> the problem is that depending on which gc is in use the actual gc() >>>>> calls may not in fact induce every possible GC action. >>>>> >>>>> The fix seems reasonable in that regard - keep gc'ing and finalizing >>>>> till we see the loader is gone, and so the WeakReference should be >>>>> cleared. The original bug would cause a ref to the Class to remain (from >>>>> the annotation) and hence the WeakRef would not be cleared. However, in >>>>> that case the loader would also be strongly referenced and so never >>>>> become finalizable. So if this test was now run against a JDK with the >>>>> original bug, the test would hang. So I think we need to add a timeout >>>>> in there as well. >>>>> >>>>> David >>>>> >>>>> On 25/06/2012 6:06 PM, Eric Wang wrote: >>>>>> On 2012/6/21 20:16, David Holmes wrote: >>>>>>> Hi Eric, >>>>>>> >>>>>>> On 21/06/2012 8:57 PM, Eric Wang wrote: >>>>>>>> Hi David, >>>>>>>> >>>>>>>> Thanks for your review, I have updated the code by following your >>>>>>>> suggestion. please see the attachment. >>>>>>>> I'm not sure whether there's a better way to guarantee object finalized >>>>>>>> by GC definitely within the given time. The proposed fix may work in >>>>>>>> most cases but may still throw InterruptException if execution is >>>>>>>> timeout (2 minutes of JTreg by default). >>>>>>> >>>>>>> There is no way to guarantee finalization in a specific timeframe, but >>>>>>> if a simple test hasn't executed finalizers in 2 minutes then that in >>>>>>> itself indicates a problem. >>>>>>> >>>>>>> Can you post a full webrev for this patch? I don't like seeing it out >>>>>>> of context and am wondering exactly what we are trying to GC here. >>>>>>> >>>>>>> David >>>>>>> >>>>>>>> Regards, >>>>>>>> Eric >>>>>>>> >>>>>>>> On 2012/6/21 14:32, David Holmes wrote: >>>>>>>>> Hi Eric, >>>>>>>>> >>>>>>>>> On 21/06/2012 4:05 PM, Eric Wang wrote: >>>>>>>>>> I come from Java SQE team who are interested in regression test bug >>>>>>>>>> fix. >>>>>>>>>> Here is the first simple fix for bug 7123972 >>>>>>>>>> , Can you please >>>>>>>>>> help >>>>>>>>>> to review and comment? Attachment is the patch Thanks! >>>>>>>>>> >>>>>>>>>> This bug is caused by wrong assumption that the GC is started >>>>>>>>>> immediately to recycle un-referenced objects after System.gc() called >>>>>>>>>> one or two times. >>>>>>>>>> >>>>>>>>>> The proposed solution is to make sure the un-referenced object is >>>>>>>>>> recycled by GC before checking if the reference is null. >>>>>>>>> >>>>>>>>> Your patch makes its own assumptions - specifically that finalization >>>>>>>>> must eventually run. At a minimum you should add >>>>>>>>> System.runFinalization() calls after the System.gc() inside the loop. >>>>>>>>> Even that is no guarantee in a general sense, though it should work >>>>>>>>> for hotspot. >>>>>>>>> >>>>>>>>> David >>>>>>>>> >>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> Eric >>>>>>>> >>>>>> Hi Alan & David, >>>>>> >>>>>> Thank you for your comments, sorry for reply this mail late as i was >>>>>> just back from the dragon boat holiday. >>>>>> I have updated the code again based on your suggestions: rename the flag >>>>>> variable, increase the sleep time and remove it from problem list. >>>>>> The attachment is the full webrev for this patch, Can you please review >>>>>> again? Thanks a lot! >>>>>> >>>>>> Regards, >>>>>> Eric >>> > From stuart.marks at oracle.com Fri Jun 29 22:29:23 2012 From: stuart.marks at oracle.com (Stuart Marks) Date: Fri, 29 Jun 2012 15:29:23 -0700 (PDT) Subject: RFR: 7170938 (str) incorrect wording in doc for String.subSequence Message-ID: <4FEE2C43.4030009@oracle.com> Hi Core Libbers, Please review some small wording and markup changes to the doc for String.subSequence. The wording change is simply fixing a mistake, not a semantic spec change. http://cr.openjdk.java.net/~smarks/reviews/7170938/webrev.0/ Thanks, s'marks From forax at univ-mlv.fr Fri Jun 29 22:48:26 2012 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Sat, 30 Jun 2012 00:48:26 +0200 Subject: RFR: 7170938 (str) incorrect wording in doc for String.subSequence In-Reply-To: <4FEE2C43.4030009@oracle.com> References: <4FEE2C43.4030009@oracle.com> Message-ID: <4FEE30BA.4060203@univ-mlv.fr> On 06/30/2012 12:29 AM, Stuart Marks wrote: > Hi Core Libbers, > > Please review some small wording and markup changes to the doc for > String.subSequence. The wording change is simply fixing a mistake, not > a semantic spec change. > > http://cr.openjdk.java.net/~smarks/reviews/7170938/webrev.0/ > > Thanks, > > s'marks looks good. R?mi From mike.duigou at oracle.com Fri Jun 29 22:45:25 2012 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Fri, 29 Jun 2012 22:45:25 +0000 Subject: hg: jdk8/tl/jdk: 7100996: (spec str) IndexOutOfBoundsException when using a StringBuffer from multiple threads Message-ID: <20120629224601.4E0A947C00@hg.openjdk.java.net> Changeset: 9e15068b6946 Author: jgish Date: 2012-06-29 15:36 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9e15068b6946 7100996: (spec str) IndexOutOfBoundsException when using a StringBuffer from multiple threads Summary: add usage note to clarify thread safety Reviewed-by: briangoetz, mduigou Contributed-by: jim.gish at oracle.com ! src/share/classes/java/lang/StringBuffer.java From mike.duigou at oracle.com Fri Jun 29 22:52:02 2012 From: mike.duigou at oracle.com (Mike Duigou) Date: Fri, 29 Jun 2012 15:52:02 -0700 (PDT) Subject: RFR: 7170938 (str) incorrect wording in doc for String.subSequence In-Reply-To: <4FEE2C43.4030009@oracle.com> References: <4FEE2C43.4030009@oracle.com> Message-ID: <8089FCFB-A38E-47E2-80B0-6C84675E98A8@oracle.com> Looks good from me too! Mike On Jun 29 2012, at 15:29 , Stuart Marks wrote: > Hi Core Libbers, > > Please review some small wording and markup changes to the doc for String.subSequence. The wording change is simply fixing a mistake, not a semantic spec change. > > http://cr.openjdk.java.net/~smarks/reviews/7170938/webrev.0/ > > Thanks, > > s'marks From Ulf.Zibis at CoSoCo.de Fri Jun 29 23:02:05 2012 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Sat, 30 Jun 2012 01:02:05 +0200 Subject: RFR: 7170938 (str) incorrect wording in doc for String.subSequence In-Reply-To: <4FEE2C43.4030009@oracle.com> References: <4FEE2C43.4030009@oracle.com> Message-ID: <4FEE33ED.30208@CoSoCo.de> I think, you could drop the comma before "or" and align indentation after @param, @return and @throws. -Ulf Am 30.06.2012 00:29, schrieb Stuart Marks: > Hi Core Libbers, > > Please review some small wording and markup changes to the doc for String.subSequence. The wording > change is simply fixing a mistake, not a semantic spec change. > > http://cr.openjdk.java.net/~smarks/reviews/7170938/webrev.0/ > > Thanks, > > s'marks > From stuart.marks at oracle.com Fri Jun 29 23:28:15 2012 From: stuart.marks at oracle.com (stuart.marks at oracle.com) Date: Fri, 29 Jun 2012 23:28:15 +0000 Subject: hg: jdk8/tl/jdk: 7170938: (str) incorrect wording in doc for String.subSequence Message-ID: <20120629232837.1AE5247C03@hg.openjdk.java.net> Changeset: 9df29b658145 Author: smarks Date: 2012-06-29 16:16 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9df29b658145 7170938: (str) incorrect wording in doc for String.subSequence Reviewed-by: forax, mduigou Contributed-by: Joe Bowbeer ! src/share/classes/java/lang/String.java From stuart.marks at oracle.com Fri Jun 29 23:36:29 2012 From: stuart.marks at oracle.com (Stuart Marks) Date: Fri, 29 Jun 2012 16:36:29 -0700 Subject: RFR: 7170938 (str) incorrect wording in doc for String.subSequence In-Reply-To: <4FEE33ED.30208@CoSoCo.de> References: <4FEE2C43.4030009@oracle.com> <4FEE33ED.30208@CoSoCo.de> Message-ID: <4FEE3BFD.3050105@oracle.com> Thanks guys. I lined up the indentation to make things a bit nicer. I prefer the Oxford comma, though, and presumably so did the original author. For further discussion see http://en.wikipedia.org/wiki/Serial_comma s'marks On 6/29/12 4:02 PM, Ulf Zibis wrote: > I think, you could drop the comma before "or" and align indentation after > @param, @return and @throws. > > -Ulf > > > Am 30.06.2012 00:29, schrieb Stuart Marks: >> Hi Core Libbers, >> >> Please review some small wording and markup changes to the doc for >> String.subSequence. The wording >> change is simply fixing a mistake, not a semantic spec change. >> >> http://cr.openjdk.java.net/~smarks/reviews/7170938/webrev.0/ >> >> Thanks, >> >> s'marks >> > > From Ulf.Zibis at gmx.de Fri Jun 29 23:01:24 2012 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Sat, 30 Jun 2012 01:01:24 +0200 Subject: RFR: 7170938 (str) incorrect wording in doc for String.subSequence In-Reply-To: <4FEE2C43.4030009@oracle.com> References: <4FEE2C43.4030009@oracle.com> Message-ID: <4FEE33C4.7050609@gmx.de> I think, you could drop the comma before "or" and align indentation after @param, @return and @throws. -Ulf Am 30.06.2012 00:29, schrieb Stuart Marks: > Hi Core Libbers, > > Please review some small wording and markup changes to the doc for String.subSequence. The wording > change is simply fixing a mistake, not a semantic spec change. > > http://cr.openjdk.java.net/~smarks/reviews/7170938/webrev.0/ > > Thanks, > > s'marks >