From tim.bell at sun.com Mon Feb 2 03:37:48 2009 From: tim.bell at sun.com (tim.bell at sun.com) Date: Mon, 02 Feb 2009 03:37:48 +0000 Subject: hg: jdk7/tl: Added tag jdk7-b45 for changeset 99846f001ca2 Message-ID: <20090202033748.6815EE6C3@hg.openjdk.java.net> Changeset: e8a2a4d18777 Author: xdono Date: 2009-01-29 13:20 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/rev/e8a2a4d18777 Added tag jdk7-b45 for changeset 99846f001ca2 ! .hgtags From tim.bell at sun.com Mon Feb 2 03:40:08 2009 From: tim.bell at sun.com (tim.bell at sun.com) Date: Mon, 02 Feb 2009 03:40:08 +0000 Subject: hg: jdk7/tl/corba: Added tag jdk7-b45 for changeset 68814aa5b44b Message-ID: <20090202034009.A95D6E6C8@hg.openjdk.java.net> Changeset: 1691dbfc08f8 Author: xdono Date: 2009-01-29 13:20 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/1691dbfc08f8 Added tag jdk7-b45 for changeset 68814aa5b44b ! .hgtags From tim.bell at sun.com Mon Feb 2 03:44:33 2009 From: tim.bell at sun.com (tim.bell at sun.com) Date: Mon, 02 Feb 2009 03:44:33 +0000 Subject: hg: jdk7/tl/hotspot: Added tag jdk7-b45 for changeset 945bf7540697 Message-ID: <20090202034434.F3037E6CD@hg.openjdk.java.net> Changeset: 16bb38eeda35 Author: xdono Date: 2009-01-29 13:20 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/16bb38eeda35 Added tag jdk7-b45 for changeset 945bf7540697 ! .hgtags From tim.bell at sun.com Mon Feb 2 03:48:55 2009 From: tim.bell at sun.com (tim.bell at sun.com) Date: Mon, 02 Feb 2009 03:48:55 +0000 Subject: hg: jdk7/tl/jaxp: Added tag jdk7-b45 for changeset 0f113667880d Message-ID: <20090202034857.11A94E6D2@hg.openjdk.java.net> Changeset: b2271877894a Author: xdono Date: 2009-01-29 13:21 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/b2271877894a Added tag jdk7-b45 for changeset 0f113667880d ! .hgtags From tim.bell at sun.com Mon Feb 2 03:51:18 2009 From: tim.bell at sun.com (tim.bell at sun.com) Date: Mon, 02 Feb 2009 03:51:18 +0000 Subject: hg: jdk7/tl/jaxws: Added tag jdk7-b45 for changeset dea7753d7139 Message-ID: <20090202035120.1E3FEE6D7@hg.openjdk.java.net> Changeset: af4a3eeb7812 Author: xdono Date: 2009-01-29 13:21 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/af4a3eeb7812 Added tag jdk7-b45 for changeset dea7753d7139 ! .hgtags From tim.bell at sun.com Mon Feb 2 03:53:47 2009 From: tim.bell at sun.com (tim.bell at sun.com) Date: Mon, 02 Feb 2009 03:53:47 +0000 Subject: hg: jdk7/tl/jdk: 3 new changesets Message-ID: <20090202035422.799FBE6DC@hg.openjdk.java.net> Changeset: 997c6403bf2e Author: xdono Date: 2009-01-29 13:21 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/997c6403bf2e Added tag jdk7-b45 for changeset 527b426497a2 ! .hgtags Changeset: 2113813eda62 Author: tbell Date: 2009-01-29 21:46 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/2113813eda62 Merge Changeset: f9cf49b7b248 Author: tbell Date: 2009-01-30 23:27 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f9cf49b7b248 Merge From tim.bell at sun.com Mon Feb 2 04:00:28 2009 From: tim.bell at sun.com (tim.bell at sun.com) Date: Mon, 02 Feb 2009 04:00:28 +0000 Subject: hg: jdk7/tl/langtools: 3 new changesets Message-ID: <20090202040032.CC5A3E6E1@hg.openjdk.java.net> Changeset: d957ceba29f9 Author: xdono Date: 2009-01-29 13:21 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/d957ceba29f9 Added tag jdk7-b45 for changeset 30db5e0aaf83 ! .hgtags Changeset: be546a6c08e3 Author: tbell Date: 2009-01-29 21:48 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/be546a6c08e3 Merge Changeset: 49281ea88125 Author: tbell Date: 2009-01-30 23:28 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/49281ea88125 Merge From jean-christophe.collet at sun.com Mon Feb 2 15:58:01 2009 From: jean-christophe.collet at sun.com (jean-christophe.collet at sun.com) Date: Mon, 02 Feb 2009 15:58:01 +0000 Subject: hg: jdk7/tl/jdk: 6791927: Wrong Locale in HttpCookie::expiryDate2DeltaSeconds Message-ID: <20090202155813.E597312696@hg.openjdk.java.net> Changeset: 6c5d04d1eff4 Author: jccollet Date: 2009-02-02 16:50 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/6c5d04d1eff4 6791927: Wrong Locale in HttpCookie::expiryDate2DeltaSeconds Summary: Force Locale.US when parsing the cookie expiration date. Reviewed-by: chegar ! src/share/classes/java/net/HttpCookie.java + test/java/net/CookieHandler/B6791927.java From martinrb at google.com Mon Feb 2 23:02:37 2009 From: martinrb at google.com (Martin Buchholz) Date: Mon, 2 Feb 2009 15:02:37 -0800 Subject: Strange speed dependency In-Reply-To: <49877528.3000105@gmx.de> References: <49877528.3000105@gmx.de> Message-ID: <1ccfd1c10902021502h2671e07tda39b4d0b3aef18a@mail.gmail.com> Ulf, the new UTF_8 decoder in very recent jdks is much faster, and the primary trick that was used to achieve that was reducing the size of the bytecode in the hot methods and moving cold code to separate methods. Martin On Mon, Feb 2, 2009 at 14:35, Ulf Zibis wrote: > Hi all, > > I have experienced a strange speed dependency of HotSpot compiled code after > little change in code, which is not part of the "hot" loop. > Is there any explanation for this behavior? > > Code before little change: > > class UTF_8_new extends Unicode { > > // .... > > private static CoderResult malformed(ByteBuffer src, int sp, > CharBuffer dst, int dp, int nb) { > src.position(sp -= nb - src.arrayOffset()); > CoderResult cr = malformedN(src, nb); > updatePositions(src, sp, dst, dp); > return cr; > } > > // .... > > while (sp < sl) { > // .... > int b2 = sa[sp++]; > int b3 = sa[sp++]; > int b4 = sa[sp++]; > if (isMalformed4(b1, b2)) > return malformed(src, sp-2, dst, dp, 2); > if (isNotContinuation(b3)) > return malformed(src, sp-1, dst, dp, 3); > if (isNotContinuation(b4)) > return malformed(src, sp, dst, dp, 4); > if (dp >= dl - 1) > return overflow(src, sp-4, dst, dp); > int uc = (b1 << 18) ^ (b2 << 12) ^ (b3 << 06) ^ b4 ^ > 0x00381f80; > // .... > } > > The above code has following output (note gain against UTF_8_70$Decoder): > time for sun.nio.cs.UTF_8_60$Decoder: 2701 ms > time for sun.nio.cs.UTF_8_70$Decoder: 1984 ms > time for sun.nio.cs.UTF_8_new$Decoder: 1720 ms // gain: 264 ms > time for sun.nio.cs.UTF_8_last$Decoder: 2110 ms > > > Following small code change made the "hot" part of the loop much slower: > > class UTF_8_new extends Unicode { > > // .... > > private static CoderResult malformed(ByteBuffer src, int sp, > CharBuffer dst, int dp, int nb) { > src.position(sp - src.arrayOffset()); // removed subtraction of > nb > CoderResult cr = malformedN(src, nb); > updatePositions(src, sp, dst, dp); > return cr; > } > > // .... > > while (sp < sl) { > // .... > int b2 = sa[sp++]; > int b3 = sa[sp++]; > int b4 = sa[sp++]; > if (isMalformed4(b1, b2)) > return malformed(src, sp-4, dst, dp, 2); > if (isNotContinuation(b3)) > return malformed(src, sp-4, dst, dp, 3); > if (isNotContinuation(b4)) > return malformed(src, sp-4, dst, dp, 4); > if (dp >= dl - 1) > return overflow(src, sp-4, dst, dp); > int uc = (b1 << 18) ^ (b2 << 12) ^ (b3 << 06) ^ b4 ^ > 0x00381f80; > // .... > } > > time for sun.nio.cs.UTF_8_60$Decoder: 2731 ms > time for sun.nio.cs.UTF_8_70$Decoder: 1981 ms > time for sun.nio.cs.UTF_8_new$Decoder: 1872 ms // gain: 109 ms > time for sun.nio.cs.UTF_8_last$Decoder: 2094 ms > > For complete sources compare following revisions (... and run > UTF_8Benchmark.java ): > https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/trunk/test/sun/nio/cs/?diff_format=s&rev=613 > https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/trunk/test/sun/nio/cs/?diff_format=s&rev=614 > > > -Ulf > > > > From Ulf.Zibis at gmx.de Tue Feb 3 01:03:31 2009 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Tue, 03 Feb 2009 02:03:31 +0100 Subject: Strange speed dependency In-Reply-To: <1ccfd1c10902021502h2671e07tda39b4d0b3aef18a@mail.gmail.com> References: <49877528.3000105@gmx.de> <1ccfd1c10902021502h2671e07tda39b4d0b3aef18a@mail.gmail.com> Message-ID: <498797E3.5040602@gmx.de> Martin, the reason for my post was to give the HotSpot guys some hint for additional enhancement. BTW, I have used the recent UTF_8 decoder for my reference. ... But I have experienced some errors: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6795537 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6798514 Most of them I have repaired yet, and fortunately I could enhance the speed by another ~20 % (on my machine, should be evaluated). -Ulf Am 03.02.2009 00:02, Martin Buchholz schrieb: > Ulf, the new UTF_8 decoder in very recent jdks is much faster, > and the primary trick that was used to achieve that > was reducing the size of the bytecode in the hot methods > and moving cold code to separate methods. > > Martin > > On Mon, Feb 2, 2009 at 14:35, Ulf Zibis wrote: > >> Hi all, >> >> I have experienced a strange speed dependency of HotSpot compiled code after >> little change in code, which is not part of the "hot" loop. >> Is there any explanation for this behavior? >> >> Code before little change: >> >> class UTF_8_new extends Unicode { >> >> // .... >> >> private static CoderResult malformed(ByteBuffer src, int sp, >> CharBuffer dst, int dp, int nb) { >> src.position(sp -= nb - src.arrayOffset()); >> CoderResult cr = malformedN(src, nb); >> updatePositions(src, sp, dst, dp); >> return cr; >> } >> >> // .... >> >> while (sp < sl) { >> // .... >> int b2 = sa[sp++]; >> int b3 = sa[sp++]; >> int b4 = sa[sp++]; >> if (isMalformed4(b1, b2)) >> return malformed(src, sp-2, dst, dp, 2); >> if (isNotContinuation(b3)) >> return malformed(src, sp-1, dst, dp, 3); >> if (isNotContinuation(b4)) >> return malformed(src, sp, dst, dp, 4); >> if (dp >= dl - 1) >> return overflow(src, sp-4, dst, dp); >> int uc = (b1 << 18) ^ (b2 << 12) ^ (b3 << 06) ^ b4 ^ >> 0x00381f80; >> // .... >> } >> >> The above code has following output (note gain against UTF_8_70$Decoder): >> time for sun.nio.cs.UTF_8_60$Decoder: 2701 ms >> time for sun.nio.cs.UTF_8_70$Decoder: 1984 ms >> time for sun.nio.cs.UTF_8_new$Decoder: 1720 ms // gain: 264 ms >> time for sun.nio.cs.UTF_8_last$Decoder: 2110 ms >> >> >> Following small code change made the "hot" part of the loop much slower: >> >> class UTF_8_new extends Unicode { >> >> // .... >> >> private static CoderResult malformed(ByteBuffer src, int sp, >> CharBuffer dst, int dp, int nb) { >> src.position(sp - src.arrayOffset()); // removed subtraction of >> nb >> CoderResult cr = malformedN(src, nb); >> updatePositions(src, sp, dst, dp); >> return cr; >> } >> >> // .... >> >> while (sp < sl) { >> // .... >> int b2 = sa[sp++]; >> int b3 = sa[sp++]; >> int b4 = sa[sp++]; >> if (isMalformed4(b1, b2)) >> return malformed(src, sp-4, dst, dp, 2); >> if (isNotContinuation(b3)) >> return malformed(src, sp-4, dst, dp, 3); >> if (isNotContinuation(b4)) >> return malformed(src, sp-4, dst, dp, 4); >> if (dp >= dl - 1) >> return overflow(src, sp-4, dst, dp); >> int uc = (b1 << 18) ^ (b2 << 12) ^ (b3 << 06) ^ b4 ^ >> 0x00381f80; >> // .... >> } >> >> time for sun.nio.cs.UTF_8_60$Decoder: 2731 ms >> time for sun.nio.cs.UTF_8_70$Decoder: 1981 ms >> time for sun.nio.cs.UTF_8_new$Decoder: 1872 ms // gain: 109 ms >> time for sun.nio.cs.UTF_8_last$Decoder: 2094 ms >> >> For complete sources compare following revisions (... and run >> UTF_8Benchmark.java ): >> https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/trunk/test/sun/nio/cs/?diff_format=s&rev=613 >> https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/trunk/test/sun/nio/cs/?diff_format=s&rev=614 >> >> >> -Ulf >> >> >> >> >> > > > From weijun.wang at sun.com Tue Feb 3 01:43:22 2009 From: weijun.wang at sun.com (weijun.wang at sun.com) Date: Tue, 03 Feb 2009 01:43:22 +0000 Subject: hg: jdk7/tl/jdk: 2 new changesets Message-ID: <20090203014346.3710F126AF@hg.openjdk.java.net> Changeset: dbb82636df41 Author: weijun Date: 2009-02-03 09:38 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/dbb82636df41 6552334: Enable DNS in Kerberos by default Reviewed-by: valeriep ! src/share/classes/sun/security/krb5/Config.java ! src/share/classes/sun/security/krb5/KrbServiceLocator.java ! test/sun/security/krb5/DnsFallback.java Changeset: ca32af4c0ea5 Author: weijun Date: 2009-02-03 09:38 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/ca32af4c0ea5 6785456: Read Kerberos setting from Windows environment variables Reviewed-by: valeriep ! src/share/classes/sun/security/krb5/Config.java From martinrb at google.com Tue Feb 3 05:49:17 2009 From: martinrb at google.com (Martin Buchholz) Date: Mon, 2 Feb 2009 21:49:17 -0800 Subject: Strange speed dependency In-Reply-To: <498797E3.5040602@gmx.de> References: <49877528.3000105@gmx.de> <1ccfd1c10902021502h2671e07tda39b4d0b3aef18a@mail.gmail.com> <498797E3.5040602@gmx.de> Message-ID: <1ccfd1c10902022149r79f33d5fjeb297c00c75a60a8@mail.gmail.com> On Mon, Feb 2, 2009 at 17:03, Ulf Zibis wrote: > Martin, > > the reason for my post was to give the HotSpot guys some hint for additional > enhancement. > > BTW, I have used the recent UTF_8 decoder for my reference. > ... But I have experienced some errors: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6795537 > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6798514 Oh dear. Thanks for finding these. Fortunately it only affects erroneous input, so it not so terrible. Still, we should fix them right away, esp. since the fix is in openjdk6. Martin > Most of them I have repaired yet, and fortunately I could enhance the speed > by another ~20 % (on my machine, should be evaluated). > > -Ulf > > > Am 03.02.2009 00:02, Martin Buchholz schrieb: >> >> Ulf, the new UTF_8 decoder in very recent jdks is much faster, >> and the primary trick that was used to achieve that >> was reducing the size of the bytecode in the hot methods >> and moving cold code to separate methods. >> >> Martin >> >> On Mon, Feb 2, 2009 at 14:35, Ulf Zibis wrote: >> >>> >>> Hi all, >>> >>> I have experienced a strange speed dependency of HotSpot compiled code >>> after >>> little change in code, which is not part of the "hot" loop. >>> Is there any explanation for this behavior? >>> >>> Code before little change: >>> >>> class UTF_8_new extends Unicode { >>> >>> // .... >>> >>> private static CoderResult malformed(ByteBuffer src, int sp, >>> CharBuffer dst, int dp, int nb) >>> { >>> src.position(sp -= nb - src.arrayOffset()); >>> CoderResult cr = malformedN(src, nb); >>> updatePositions(src, sp, dst, dp); >>> return cr; >>> } >>> >>> // .... >>> >>> while (sp < sl) { >>> // .... >>> int b2 = sa[sp++]; >>> int b3 = sa[sp++]; >>> int b4 = sa[sp++]; >>> if (isMalformed4(b1, b2)) >>> return malformed(src, sp-2, dst, dp, 2); >>> if (isNotContinuation(b3)) >>> return malformed(src, sp-1, dst, dp, 3); >>> if (isNotContinuation(b4)) >>> return malformed(src, sp, dst, dp, 4); >>> if (dp >= dl - 1) >>> return overflow(src, sp-4, dst, dp); >>> int uc = (b1 << 18) ^ (b2 << 12) ^ (b3 << 06) ^ b4 ^ >>> 0x00381f80; >>> // .... >>> } >>> >>> The above code has following output (note gain against UTF_8_70$Decoder): >>> time for sun.nio.cs.UTF_8_60$Decoder: 2701 ms >>> time for sun.nio.cs.UTF_8_70$Decoder: 1984 ms >>> time for sun.nio.cs.UTF_8_new$Decoder: 1720 ms // gain: 264 ms >>> time for sun.nio.cs.UTF_8_last$Decoder: 2110 ms >>> >>> >>> Following small code change made the "hot" part of the loop much slower: >>> >>> class UTF_8_new extends Unicode { >>> >>> // .... >>> >>> private static CoderResult malformed(ByteBuffer src, int sp, >>> CharBuffer dst, int dp, int nb) >>> { >>> src.position(sp - src.arrayOffset()); // removed subtraction >>> of >>> nb >>> CoderResult cr = malformedN(src, nb); >>> updatePositions(src, sp, dst, dp); >>> return cr; >>> } >>> >>> // .... >>> >>> while (sp < sl) { >>> // .... >>> int b2 = sa[sp++]; >>> int b3 = sa[sp++]; >>> int b4 = sa[sp++]; >>> if (isMalformed4(b1, b2)) >>> return malformed(src, sp-4, dst, dp, 2); >>> if (isNotContinuation(b3)) >>> return malformed(src, sp-4, dst, dp, 3); >>> if (isNotContinuation(b4)) >>> return malformed(src, sp-4, dst, dp, 4); >>> if (dp >= dl - 1) >>> return overflow(src, sp-4, dst, dp); >>> int uc = (b1 << 18) ^ (b2 << 12) ^ (b3 << 06) ^ b4 ^ >>> 0x00381f80; >>> // .... >>> } >>> >>> time for sun.nio.cs.UTF_8_60$Decoder: 2731 ms >>> time for sun.nio.cs.UTF_8_70$Decoder: 1981 ms >>> time for sun.nio.cs.UTF_8_new$Decoder: 1872 ms // gain: 109 ms >>> time for sun.nio.cs.UTF_8_last$Decoder: 2094 ms >>> >>> For complete sources compare following revisions (... and run >>> UTF_8Benchmark.java ): >>> >>> https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/trunk/test/sun/nio/cs/?diff_format=s&rev=613 >>> >>> https://java-nio-charset-enhanced.dev.java.net/source/browse/java-nio-charset-enhanced/trunk/test/sun/nio/cs/?diff_format=s&rev=614 >>> >>> >>> -Ulf >>> >>> >>> >>> >>> >> >> >> > > From i30817 at gmail.com Wed Feb 4 00:00:42 2009 From: i30817 at gmail.com (Paulo Levi) Date: Wed, 4 Feb 2009 00:00:42 +0000 Subject: I tried to send this to the sound dev mailing list Message-ID: <212322090902031600qf3dd16dx8c945031c8fe95dc@mail.gmail.com> But the "pending moderator approval" never happened. I think there is a problem in the linux implementation of javax.sound.sampled.AudioSystem.getLine(DataLine.Info info); It throws a line unavailable exception when trying to send data, not on construction. Apparently its just each Line is saying that it supports the AudioFormat when it does no such thing, leading to innumerable exceptions when trying to use freetts in linux. BTW is FreeTTS dead or undead? Seeing projects like acapela tts with their much higher quality voices in many languages is slightly depressing from my the java is the platform and native is taboo mindset. Original message: I've recently tried to wrap freetts in a api, and it works ok on windows, but not so very much in linux. It outputs: LINE UNAVAILABLE: Format is PCM_SIGNED 16000.0 Hz, 16 bit, mono, 2 bytes/frame, big-endian Looking at the code it appears that its because in launches the exception, you guess it, LineUnavailableException. Now this is really weird since i thought we were past those dark ages in which only one system resource was available per application. Searching around in google i found this: http://forums.sun.com/thread.jspa?threadID=5189363 And that is just wrong. I'm going to try to adapt his solution to freetts, and i guess this would fix it, but can the sound team assure me there are plans to fix this bug? From joe.darcy at sun.com Wed Feb 4 00:34:41 2009 From: joe.darcy at sun.com (joe.darcy at sun.com) Date: Wed, 04 Feb 2009 00:34:41 +0000 Subject: hg: jdk7/tl/jdk: 6548433: (enum spec) java.lang.Enum docs should explain about values() and valueOf(String) Message-ID: <20090204003456.E60F61270A@hg.openjdk.java.net> Changeset: 050da121df16 Author: darcy Date: 2009-02-03 16:29 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/050da121df16 6548433: (enum spec) java.lang.Enum docs should explain about values() and valueOf(String) Reviewed-by: martin ! src/share/classes/java/lang/Enum.java From Alan.Bateman at Sun.COM Wed Feb 4 09:01:41 2009 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Wed, 04 Feb 2009 09:01:41 +0000 Subject: I tried to send this to the sound dev mailing list In-Reply-To: <212322090902031600qf3dd16dx8c945031c8fe95dc@mail.gmail.com> References: <212322090902031600qf3dd16dx8c945031c8fe95dc@mail.gmail.com> Message-ID: <49895975.6070208@sun.com> Paulo Levi wrote: > But the "pending moderator approval" never happened. > If you subscribe to sound-dev then you should be able to send mail to the mailing lists without problems. -Alan. From xuelei.fan at sun.com Wed Feb 4 11:19:41 2009 From: xuelei.fan at sun.com (xuelei.fan at sun.com) Date: Wed, 04 Feb 2009 11:19:41 +0000 Subject: hg: jdk7/tl/jdk: 6782783: regtest HttpsURLConnection/B6216082.java throws ClosedByInterruptException Message-ID: <20090204111952.F33C712732@hg.openjdk.java.net> Changeset: a96a1f0edeeb Author: xuelei Date: 2009-02-04 19:10 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/a96a1f0edeeb 6782783: regtest HttpsURLConnection/B6216082.java throws ClosedByInterruptException Summary: make the test robust Reviewed-by: weijun ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/B6216082.java From jean-christophe.collet at sun.com Wed Feb 4 13:21:49 2009 From: jean-christophe.collet at sun.com (jean-christophe.collet at sun.com) Date: Wed, 04 Feb 2009 13:21:49 +0000 Subject: hg: jdk7/tl/jdk: 6585546: Please update API doc for java.net.CookieManager Message-ID: <20090204132201.5ACE91273C@hg.openjdk.java.net> Changeset: 61ee91f965ac Author: jccollet Date: 2009-02-04 14:15 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/61ee91f965ac 6585546: Please update API doc for java.net.CookieManager Summary: Trivial doc updates Reviewed-by: chegar ! src/share/classes/java/net/CookieManager.java From jonathan.gibbons at sun.com Fri Feb 6 18:26:38 2009 From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com) Date: Fri, 06 Feb 2009 18:26:38 +0000 Subject: hg: jdk7/tl/langtools: 6595666: fix -Werror Message-ID: <20090206182641.6878D12C81@hg.openjdk.java.net> Changeset: 9d541fd2916b Author: jjg Date: 2009-02-06 10:23 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/9d541fd2916b 6595666: fix -Werror Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/main/Main.java ! src/share/classes/com/sun/tools/javac/main/RecognizedOptions.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/resources/javac.properties ! test/tools/javac/6304921/T6304921.out ! test/tools/javac/6758789/T6758789b.out ! test/tools/javac/T6241723.out + test/tools/javac/T6595666.java ! test/tools/javac/depDocComment/DeprecatedDocComment.out From joe.darcy at sun.com Fri Feb 6 20:54:27 2009 From: joe.darcy at sun.com (joe.darcy at sun.com) Date: Fri, 06 Feb 2009 20:54:27 +0000 Subject: hg: jdk7/tl/langtools: 6794071: Provide exception superclass for UnknownFooExceptions Message-ID: <20090206205429.889C0D06B@hg.openjdk.java.net> Changeset: 58fcba61a77d Author: darcy Date: 2009-02-06 12:49 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/58fcba61a77d 6794071: Provide exception superclass for UnknownFooExceptions Reviewed-by: jjg + src/share/classes/javax/lang/model/UnknownEntityException.java ! src/share/classes/javax/lang/model/element/UnknownAnnotationValueException.java ! src/share/classes/javax/lang/model/element/UnknownElementException.java ! src/share/classes/javax/lang/model/type/UnknownTypeException.java + test/tools/javac/processing/model/TestExceptions.java From forax at univ-mlv.fr Fri Feb 6 20:59:58 2009 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Fri, 06 Feb 2009 21:59:58 +0100 Subject: Fix for 5015163, and my first webrev Message-ID: <498CA4CE.1090207@univ-mlv.fr> Hi all, bug 5015163 is a RFE that advocate to add a method join (like in Python) to String/StringBuilder/StringBuffer. Here is the corresponding webrev (using the new infrastucture :) http://cr.openjdk.java.net/~forax/5015163/webrev.00/ The patch is against tl repository. Who want to review it ? For the record, i have previously proposed this fix using the jdk-collaboration forum more than one year ago but because i am lazy i haven't take the time to post it here. cheers, R?mi Forax From Xueming.Shen at Sun.COM Fri Feb 6 22:25:31 2009 From: Xueming.Shen at Sun.COM (Xueming Shen) Date: Fri, 06 Feb 2009 14:25:31 -0800 Subject: Fix for 5015163, and my first webrev In-Reply-To: <498CA4CE.1090207@univ-mlv.fr> References: <498CA4CE.1090207@univ-mlv.fr> Message-ID: <498CB8DB.8060708@sun.com> public String join(Object first, Object... elements) { if (elements.length==0) return String.valueOf(first); return new StringBuilder().join(this, first, elements).toString(); } It does not look right to simply return String.valueOf(first); when elements size is 0, where is "this"? No, I'm not endorsing the APIs provided, at least for now:-) there is room to debate what would be the best choice(APIs) to support the "joint", if we decided to add one. Sherman R?mi Forax wrote: > Hi all, > bug 5015163 is a RFE that advocate to add a method join (like in Python) > to String/StringBuilder/StringBuffer. > > Here is the corresponding webrev (using the new infrastucture :) > http://cr.openjdk.java.net/~forax/5015163/webrev.00/ > The patch is against tl repository. > > Who want to review it ? > > For the record, i have previously proposed this fix using the > jdk-collaboration forum more than > one year ago but because i am lazy i haven't take the time to post it > here. > > cheers, > R?mi Forax > > From forax at univ-mlv.fr Fri Feb 6 22:33:56 2009 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Fri, 06 Feb 2009 23:33:56 +0100 Subject: Fix for 5015163, and my first webrev In-Reply-To: <498CB8DB.8060708@sun.com> References: <498CA4CE.1090207@univ-mlv.fr> <498CB8DB.8060708@sun.com> Message-ID: <498CBAD4.5060104@univ-mlv.fr> Xueming Shen a ?crit : > public String join(Object first, Object... elements) { > if (elements.length==0) > return String.valueOf(first); > return new StringBuilder().join(this, first, elements).toString(); > } > > It does not look right to simply return String.valueOf(first); when > elements size is 0, where is "this"? "this" is the delimiter. ",".join("hello", "world") => "hello,world" Thus it doesn't use "this" if there is only one argument. > > No, I'm not endorsing the APIs provided, at least for now:-) there is > room to debate what would be > the best choice(APIs) to support the "joint", if we decided to add one. Is it more clear now ? By the way, I've written 3 tests, one by class (String, StringBuilder, StringBuffer) Should I add them to the webrev ? > > > Sherman R?mi From Xueming.Shen at Sun.COM Fri Feb 6 22:59:22 2009 From: Xueming.Shen at Sun.COM (Xueming Shen) Date: Fri, 06 Feb 2009 14:59:22 -0800 Subject: Fix for 5015163, and my first webrev In-Reply-To: <498CBAD4.5060104@univ-mlv.fr> References: <498CA4CE.1090207@univ-mlv.fr> <498CB8DB.8060708@sun.com> <498CBAD4.5060104@univ-mlv.fr> Message-ID: <498CC0CA.60102@sun.com> R?mi Forax wrote: > Xueming Shen a ?crit : >> public String join(Object first, Object... elements) { >> if (elements.length==0) >> return String.valueOf(first); >> return new StringBuilder().join(this, first, elements).toString(); >> } >> >> It does not look right to simply return String.valueOf(first); when >> elements size is 0, where is "this"? > "this" is the delimiter. > > ",".join("hello", "world") => "hello,world" > > Thus it doesn't use "this" if there is only one argument. oops, did not pay attention to the "deimiter part:-) From kevinb at google.com Fri Feb 6 23:03:04 2009 From: kevinb at google.com (Kevin Bourrillion) Date: Fri, 6 Feb 2009 15:03:04 -0800 Subject: Fix for 5015163, and my first webrev In-Reply-To: <498CA4CE.1090207@univ-mlv.fr> References: <498CA4CE.1090207@univ-mlv.fr> Message-ID: <108fcdeb0902061503j626b4727y520afe683b43f184@mail.gmail.com> Hello, A few thoughts. First, this functionality is badly needed. Absolutely everyone rewrites this, in hundreds of different ways. At Google we're no exception, we have our own hand-rolled Join.java class full of static methods, and it has thousands of callers in our private codebase. Your selection of overloads (Iterable, Object[], and (Object,Object...)) is exactly correct. Kudos. We'd added Iterator versions as well, but almost no one uses them, so forget that. My main concerns with your current API are: * I don't think that ",".join(collection) is a good idea. It clashes too strongly with the StringBuilder etc. versions. It also plain "looks weird". A static String.join(",", collection) is preferable. I don't think anyone would be surprised by this. * It should be considered separately whether to support other Appendables via static methods (somewhere) like: static A join(A appendable, String delimiter, Iterable tokens) throws IOException This provides a superset of what your StringBuilder etc. methods can do, but your methods are still good because of their convenience especially in chains of method calls, and because they don't need to throw any exception. * The biggest problem we've had with our Join class is that it turns out that everyone has a different idea of how they'd like nulls handled. - output as "null" (your, and our, current behavior) - skip? - skip only if trailing? - throw NPE? (often the best thing) We now support everyone by having the concept of an instantiable Joiner (I've seen this in other languages). Example: private static final Joiner JOINER = Joiner.with(", ").skipNulls(); . . . return JOINER.join("Harry", "Ron", "Hermione"); Just to give everyone food for thought, our Joiner's API currently looks like this: static Joiner with(String separator) Joiner skipNulls() Joiner useForNull(String nullText) A appendTo(A appendable, Iterable parts) throws IOException A appendTo(A appendable, Object[] parts) throws IOException A appendTo(A appendable, Object first, Object... rest) throws IOException StringBuilder appendTo(StringBuilder builder, Iterable parts) StringBuilder appendTo(StringBuilder builder, Object[] parts) StringBuilder appendTo(StringBuilder builder, Object first, Object... rest) String join(Iterable parts) String join(Object[] parts) String join(Object first, Object... rest) MapJoiner withKeyValueSeparator(String keyValueSeparator) class MapJoiner { A appendTo(A appendable, Map map) throws IOException StringBuilder appendTo(StringBuilder builder, Map map) String join(Map map) MapJoiner useForNull(String nullText) } End of random thoughts. On Fri, Feb 6, 2009 at 12:59 PM, R?mi Forax wrote: > > Hi all, > bug 5015163 is a RFE that advocate to add a method join (like in Python) > to String/StringBuilder/StringBuffer. > > Here is the corresponding webrev (using the new infrastucture :) > http://cr.openjdk.java.net/~forax/5015163/webrev.00/ > The patch is against tl repository. > > Who want to review it ? > > For the record, i have previously proposed this fix using the jdk-collaboration forum more than > one year ago but because i am lazy i haven't take the time to post it here. > > cheers, > R?mi Forax > > -- Kevin Bourrillion @ Google internal: http://go/javalibraries google-collections.googlecode.com google-guice.googlecode.com From forax at univ-mlv.fr Sat Feb 7 01:01:39 2009 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Sat, 07 Feb 2009 02:01:39 +0100 Subject: Fix for 5015163, and my first webrev In-Reply-To: <108fcdeb0902061503j626b4727y520afe683b43f184@mail.gmail.com> References: <498CA4CE.1090207@univ-mlv.fr> <108fcdeb0902061503j626b4727y520afe683b43f184@mail.gmail.com> Message-ID: <498CDD73.7080803@univ-mlv.fr> Kevin Bourrillion a ?crit : > Hello, > > A few thoughts. > > First, this functionality is badly needed. Absolutely everyone > rewrites this, in hundreds of different ways. At Google we're no > exception, we have our own hand-rolled Join.java class full of static > methods, and it has thousands of callers in our private codebase. > > Your selection of overloads (Iterable, Object[], and > (Object,Object...)) is exactly correct. Kudos. We'd added Iterator > versions as well, but almost no one uses them, so forget that. > > My main concerns with your current API are: > > * I don't think that ",".join(collection) is a good idea. It clashes > too strongly with the StringBuilder etc. versions. It also plain > "looks weird". A static String.join(",", collection) is preferable. > I don't think anyone would be surprised by this. > Use the receiver or not: Pro: - join works with split and split use the receiver - Python use the receiver too Cons: - static seems least surprising. - Perl's join and PHP's join are functions I'm convinced, I will modify the patch. > * It should be considered separately whether to support other > Appendables via static methods (somewhere) like: > > static A join(A appendable, String delimiter, > Iterable tokens) throws IOException > > This provides a superset of what your StringBuilder etc. methods can > do, but your methods are still good because of their convenience > especially in chains of method calls, and because they don't need to > throw any exception. > Or perhaps, in JDK8 (when closure will be integrated) the compiler will be able to infer that because join is used with String, it can't throw an IOE That's not what BGGA propose but I will love to see that :) But that's another story. > * The biggest problem we've had with our Join class is that it turns > out that everyone has a different idea of how they'd like nulls > handled. > > - output as "null" (your, and our, current behavior) > - skip? > - skip only if trailing? > - throw NPE? (often the best thing) > In my opinion (i am perhaps wong) join will be mostly used just before print the String. That's why I have chosen the the print(ln) behavior. > We now support everyone by having the concept of an instantiable > Joiner (I've seen this in other languages). Example: > > private static final Joiner JOINER = Joiner.with(", ").skipNulls(); > . . . > > return JOINER.join("Harry", "Ron", "Hermione"); > > Just to give everyone food for thought, our Joiner's API currently > looks like this: > > static Joiner with(String separator) > > Joiner skipNulls() > Joiner useForNull(String nullText) > > A appendTo(A appendable, Iterable parts) > throws IOException > A appendTo(A appendable, Object[] parts) > throws IOException > A appendTo(A appendable, Object first, > Object... rest) throws IOException > > StringBuilder appendTo(StringBuilder builder, Iterable parts) > StringBuilder appendTo(StringBuilder builder, Object[] parts) > StringBuilder appendTo(StringBuilder builder, Object first, Object... rest) > > String join(Iterable parts) > String join(Object[] parts) > String join(Object first, Object... rest) > > MapJoiner withKeyValueSeparator(String keyValueSeparator) > > class MapJoiner { > A appendTo(A appendable, Map map) > throws IOException > StringBuilder appendTo(StringBuilder builder, Map map) > String join(Map map) > > MapJoiner useForNull(String nullText) > } > > End of random thoughts. > Cool, i don't think this should be integrated in the JDK, After all, If i want a full featured joiner, I can download the google collection jar :) > > -- > Kevin Bourrillion @ Google > internal: http://go/javalibraries > google-collections.googlecode.com > google-guice.googlecode.com > R?mi From tim.bell at sun.com Sat Feb 7 05:31:03 2009 From: tim.bell at sun.com (tim.bell at sun.com) Date: Sat, 07 Feb 2009 05:31:03 +0000 Subject: hg: jdk7/tl: Added tag jdk7-b46 for changeset e8a2a4d18777 Message-ID: <20090207053104.02C30D0FB@hg.openjdk.java.net> Changeset: d7744e86dedc Author: xdono Date: 2009-02-05 16:07 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/rev/d7744e86dedc Added tag jdk7-b46 for changeset e8a2a4d18777 ! .hgtags From tim.bell at sun.com Sat Feb 7 05:34:53 2009 From: tim.bell at sun.com (tim.bell at sun.com) Date: Sat, 07 Feb 2009 05:34:53 +0000 Subject: hg: jdk7/tl/corba: Added tag jdk7-b46 for changeset 1691dbfc08f8 Message-ID: <20090207053454.2098CD104@hg.openjdk.java.net> Changeset: 167ad0164301 Author: xdono Date: 2009-02-05 16:07 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/167ad0164301 Added tag jdk7-b46 for changeset 1691dbfc08f8 ! .hgtags From tim.bell at sun.com Sat Feb 7 05:40:40 2009 From: tim.bell at sun.com (tim.bell at sun.com) Date: Sat, 07 Feb 2009 05:40:40 +0000 Subject: hg: jdk7/tl/hotspot: Added tag jdk7-b46 for changeset 16bb38eeda35 Message-ID: <20090207054043.28DABD109@hg.openjdk.java.net> Changeset: ba02d80fc550 Author: xdono Date: 2009-02-05 16:07 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/ba02d80fc550 Added tag jdk7-b46 for changeset 16bb38eeda35 ! .hgtags From tim.bell at sun.com Sat Feb 7 05:47:55 2009 From: tim.bell at sun.com (tim.bell at sun.com) Date: Sat, 07 Feb 2009 05:47:55 +0000 Subject: hg: jdk7/tl/jaxp: Added tag jdk7-b46 for changeset b2271877894a Message-ID: <20090207054757.31F9FD10F@hg.openjdk.java.net> Changeset: d711ad1954b2 Author: xdono Date: 2009-02-05 16:07 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/d711ad1954b2 Added tag jdk7-b46 for changeset b2271877894a ! .hgtags From tim.bell at sun.com Sat Feb 7 05:52:06 2009 From: tim.bell at sun.com (tim.bell at sun.com) Date: Sat, 07 Feb 2009 05:52:06 +0000 Subject: hg: jdk7/tl/jaxws: Added tag jdk7-b46 for changeset af4a3eeb7812 Message-ID: <20090207055207.DD786D114@hg.openjdk.java.net> Changeset: 223011570edb Author: xdono Date: 2009-02-05 16:07 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/223011570edb Added tag jdk7-b46 for changeset af4a3eeb7812 ! .hgtags From tim.bell at sun.com Sat Feb 7 05:57:59 2009 From: tim.bell at sun.com (tim.bell at sun.com) Date: Sat, 07 Feb 2009 05:57:59 +0000 Subject: hg: jdk7/tl/jdk: 31 new changesets Message-ID: <20090207060405.84E91D119@hg.openjdk.java.net> Changeset: 443db0030323 Author: peytoia Date: 2008-10-02 15:54 +0900 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/443db0030323 6645263: (cal) Calendar throw java.lang.IllegalArgumentException: WEEK_OF_MONTH Reviewed-by: okutsu ! src/share/classes/java/util/Calendar.java + test/java/util/Calendar/Bug6645263.java Changeset: 7f4488e9ba24 Author: peytoia Date: 2008-10-03 15:54 +0900 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/7f4488e9ba24 6683975: [fmt-da] Regression: Java 6 returns English DateFormatPatterns for Thai locale Reviewed-by: okutsu ! src/share/classes/sun/text/resources/FormatData_th.java + test/java/text/Format/DateFormat/Bug6683975.java Changeset: f71879c0999f Author: naoto Date: 2008-10-06 17:16 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f71879c0999f 6706382: jdk/test/java/util/Locale/data/deflocale.sol10 has incorrect legal notice Reviewed-by: okutsu ! test/java/util/Locale/data/deflocale.sol10 Changeset: a9be64f0ad3e Author: peytoia Date: 2008-10-07 18:25 +0900 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/a9be64f0ad3e 6756569: (tz) Support tzdata2008g Reviewed-by: okutsu ! make/sun/javazic/tzdata/VERSION ! make/sun/javazic/tzdata/africa ! make/sun/javazic/tzdata/asia ! make/sun/javazic/tzdata/europe ! make/sun/javazic/tzdata/southamerica Changeset: 7560426ed283 Author: rkennke Date: 2008-10-15 15:55 +0200 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/7560426ed283 6759311: RepaintManager casts Tookit to SunToolkit without instanceof check Summary: Check type of Toolkit before casting. Reviewed-by: alexp ! src/share/classes/javax/swing/RepaintManager.java Changeset: 244f62312fec Author: peytoia Date: 2008-10-16 14:00 +0900 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/244f62312fec 6758988: (tz) Support tzdata2008h Reviewed-by: okutsu ! make/sun/javazic/tzdata/VERSION ! make/sun/javazic/tzdata/africa ! make/sun/javazic/tzdata/asia ! make/sun/javazic/tzdata/southamerica ! make/sun/javazic/tzdata/zone.tab Changeset: 8ea49fa4c2f7 Author: peytoia Date: 2008-10-17 13:34 +0900 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/8ea49fa4c2f7 6759521: Move Bidi test programs from closed to open. Reviewed-by: okutsu + test/java/text/Bidi/BidiBug.java + test/java/text/Bidi/BidiEmbeddingTest.java + test/java/text/Bidi/BidiSurrogateTest.java Changeset: 3bc97f84a8aa Author: lana Date: 2008-10-17 15:01 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/3bc97f84a8aa Merge - make/ASSEMBLY_EXCEPTION - make/LICENSE - make/README - make/README-builds.html - make/README.html - make/THIRD_PARTY_README - src/share/classes/java/nio/channels/package.html - src/share/classes/sun/nio/ch/OptionAdaptor.java - src/share/classes/sun/nio/ch/SocketOpts.java - src/share/classes/sun/nio/ch/SocketOptsImpl.java - src/share/classes/sun/nio/ch/exceptions - src/share/javavm/include/opcodes.h - src/share/javavm/include/opcodes.length - src/share/javavm/include/opcodes.list - src/share/javavm/include/opcodes.weight - src/share/javavm/include/opcodes.wide - src/share/javavm/include/sys_api.h - src/share/javavm/include/typedefs.h - src/solaris/classes/sun/awt/motif/MButtonPeer.java - src/solaris/classes/sun/awt/motif/MCanvasPeer.java - src/solaris/classes/sun/awt/motif/MCheckboxMenuItemPeer.java - src/solaris/classes/sun/awt/motif/MCheckboxPeer.java - src/solaris/classes/sun/awt/motif/MChoicePeer.java - src/solaris/classes/sun/awt/motif/MComponentPeer.java - src/solaris/classes/sun/awt/motif/MCustomCursor.java - src/solaris/classes/sun/awt/motif/MDataTransferer.java - src/solaris/classes/sun/awt/motif/MDialogPeer.java - src/solaris/classes/sun/awt/motif/MDragSourceContextPeer.java - src/solaris/classes/sun/awt/motif/MDropTargetContextPeer.java - src/solaris/classes/sun/awt/motif/MEmbedCanvasPeer.java - src/solaris/classes/sun/awt/motif/MEmbeddedFrame.java - src/solaris/classes/sun/awt/motif/MEmbeddedFramePeer.java - src/solaris/classes/sun/awt/motif/MFileDialogPeer.java - src/solaris/classes/sun/awt/motif/MFramePeer.java - src/solaris/classes/sun/awt/motif/MGlobalCursorManager.java - src/solaris/classes/sun/awt/motif/MInputMethod.java - src/solaris/classes/sun/awt/motif/MInputMethodControl.java - src/solaris/classes/sun/awt/motif/MInputMethodDescriptor.java - src/solaris/classes/sun/awt/motif/MLabelPeer.java - src/solaris/classes/sun/awt/motif/MListPeer.java - src/solaris/classes/sun/awt/motif/MMenuBarPeer.java - src/solaris/classes/sun/awt/motif/MMenuItemPeer.java - src/solaris/classes/sun/awt/motif/MMenuPeer.java - src/solaris/classes/sun/awt/motif/MMouseDragGestureRecognizer.java - src/solaris/classes/sun/awt/motif/MPanelPeer.java - src/solaris/classes/sun/awt/motif/MPopupMenuPeer.java - src/solaris/classes/sun/awt/motif/MRobotPeer.java - src/solaris/classes/sun/awt/motif/MScrollPanePeer.java - src/solaris/classes/sun/awt/motif/MScrollbarPeer.java - src/solaris/classes/sun/awt/motif/MTextAreaPeer.java - src/solaris/classes/sun/awt/motif/MTextFieldPeer.java - src/solaris/classes/sun/awt/motif/MWindowPeer.java - src/solaris/classes/sun/awt/motif/X11Clipboard.java - src/solaris/classes/sun/awt/motif/X11DragSourceContextPeer.java - src/solaris/classes/sun/awt/motif/X11DropTargetContextPeer.java - src/solaris/classes/sun/awt/motif/X11Selection.java - src/solaris/classes/sun/awt/motif/X11SelectionHolder.java - src/solaris/javavm/include/typedefs_md.h - src/solaris/native/sun/awt/awt_Button.c - src/solaris/native/sun/awt/awt_Canvas.c - src/solaris/native/sun/awt/awt_Checkbox.c - src/solaris/native/sun/awt/awt_Choice12.c - src/solaris/native/sun/awt/awt_Choice21.c - src/solaris/native/sun/awt/awt_Component.c - src/solaris/native/sun/awt/awt_Cursor.c - src/solaris/native/sun/awt/awt_DataTransferer.c - src/solaris/native/sun/awt/awt_DataTransferer.h - src/solaris/native/sun/awt/awt_FileDialog.c - src/solaris/native/sun/awt/awt_GlobalCursorManager.c - src/solaris/native/sun/awt/awt_KeyboardFocusManager.c - src/solaris/native/sun/awt/awt_Label.c - src/solaris/native/sun/awt/awt_List.c - src/solaris/native/sun/awt/awt_Menu.c - src/solaris/native/sun/awt/awt_Menu.h - src/solaris/native/sun/awt/awt_MenuBar.c - src/solaris/native/sun/awt/awt_MenuBar.h - src/solaris/native/sun/awt/awt_MenuComponent.c - src/solaris/native/sun/awt/awt_MenuItem.c - src/solaris/native/sun/awt/awt_PopupMenu.c - src/solaris/native/sun/awt/awt_ScrollPane.c - src/solaris/native/sun/awt/awt_Scrollbar.c - src/solaris/native/sun/awt/awt_Selection.c - src/solaris/native/sun/awt/awt_TextArea.c - src/solaris/native/sun/awt/awt_TextArea.h - src/solaris/native/sun/awt/awt_TextField.c - src/solaris/native/sun/awt/awt_TextField.h - src/solaris/native/sun/awt/awt_TopLevel.c - src/solaris/native/sun/awt/awt_XmDnD.c - src/solaris/native/sun/awt/awt_XmDnD.h - src/solaris/native/sun/awt/awt_dnd.c - src/solaris/native/sun/awt/awt_dnd.h - src/solaris/native/sun/awt/awt_dnd_ds.c - src/solaris/native/sun/awt/awt_dnd_dt.c - src/solaris/native/sun/awt/awt_motif.c - src/solaris/native/sun/awt/awt_motif12.c - src/solaris/native/sun/awt/awt_motif21.c - src/solaris/native/sun/awt/awt_xembed.c - src/solaris/native/sun/awt/canvas.c - src/solaris/native/sun/awt/cursor.c - src/windows/javavm/include/typedefs_md.h Changeset: f67599e0ee33 Author: peytoia Date: 2008-10-30 13:12 +0900 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f67599e0ee33 6764308: (tz) Support tzdata2008i Reviewed-by: okutsu ! make/sun/javazic/tzdata/VERSION ! make/sun/javazic/tzdata/southamerica ! make/sun/javazic/tzdata/zone.tab ! src/share/classes/sun/util/resources/TimeZoneNames.java ! src/share/classes/sun/util/resources/TimeZoneNames_de.java ! src/share/classes/sun/util/resources/TimeZoneNames_es.java ! src/share/classes/sun/util/resources/TimeZoneNames_fr.java ! src/share/classes/sun/util/resources/TimeZoneNames_it.java ! src/share/classes/sun/util/resources/TimeZoneNames_ja.java ! src/share/classes/sun/util/resources/TimeZoneNames_ko.java ! src/share/classes/sun/util/resources/TimeZoneNames_sv.java ! src/share/classes/sun/util/resources/TimeZoneNames_zh_CN.java ! src/share/classes/sun/util/resources/TimeZoneNames_zh_TW.java Changeset: f8461a705330 Author: rupashka Date: 2008-11-17 17:36 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f8461a705330 6771030: Code improvement and warnings removing from the com.sun.java.swing.plaf.gtk package Summary: Removed unnecessary castings and other warnings Reviewed-by: malenkov ! src/share/classes/com/sun/java/swing/plaf/gtk/GTKColorChooserPanel.java ! src/share/classes/com/sun/java/swing/plaf/gtk/GTKEngine.java ! src/share/classes/com/sun/java/swing/plaf/gtk/GTKFileChooserUI.java ! src/share/classes/com/sun/java/swing/plaf/gtk/GTKPainter.java ! src/share/classes/com/sun/java/swing/plaf/gtk/Metacity.java Changeset: 6c5781fc3818 Author: peytoia Date: 2008-11-18 13:58 +0900 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/6c5781fc3818 6769873: Regression test java/text/Date/DateFormat/Bug6683975.java started failing after DST ended. Reviewed-by: okutsu ! test/java/text/Format/DateFormat/Bug6683975.java Changeset: bdfe33408ed8 Author: peytoia Date: 2008-11-18 15:59 +0900 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/bdfe33408ed8 6772646: Regression test java/text/Date/DateFormat/Bug4823811.java started failing after DST ended. Reviewed-by: okutsu ! test/java/text/Format/DateFormat/Bug4823811.java Changeset: 63e684c4ed2f Author: rupashka Date: 2008-11-25 16:42 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/63e684c4ed2f 6698013: JFileChooser can no longer navigate non-local file systems. Summary: ShellFolder is used only if possible Reviewed-by: peterz ! src/share/classes/javax/swing/plaf/basic/BasicFileChooserUI.java ! src/share/classes/sun/swing/FilePane.java + test/javax/swing/JFileChooser/6698013/bug6698013.html + test/javax/swing/JFileChooser/6698013/bug6698013.java Changeset: be2b6b030a79 Author: rupashka Date: 2008-11-26 19:08 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/be2b6b030a79 6560349: REGRESSION :folder having ".lnk" in the name can not be opened by 5.0 and later versions Reviewed-by: alexp ! src/share/classes/javax/swing/plaf/basic/BasicFileChooserUI.java Changeset: 8b842701af50 Author: rupashka Date: 2008-11-26 19:38 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/8b842701af50 6776856: Code with useShellFolder field shuold be simplify Reviewed-by: peterz ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsFileChooserUI.java ! src/share/classes/javax/swing/plaf/metal/MetalFileChooserUI.java ! src/share/classes/sun/swing/FilePane.java ! src/share/classes/sun/swing/plaf/synth/SynthFileChooserUIImpl.java Changeset: 5784f5dfe3ac Author: rupashka Date: 2008-11-27 17:55 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/5784f5dfe3ac 6776095: Code improvement and warnings removing from swing packages Reviewed-by: malenkov Contributed-by: Florian Brunner ! src/share/classes/com/sun/java/swing/plaf/gtk/GTKFileChooserUI.java ! src/share/classes/com/sun/java/swing/plaf/gtk/GTKLookAndFeel.java ! src/share/classes/javax/swing/ImageIcon.java ! src/share/classes/javax/swing/ProgressMonitor.java ! src/share/classes/javax/swing/SwingWorker.java ! src/share/classes/javax/swing/colorchooser/DefaultColorSelectionModel.java ! src/share/classes/javax/swing/table/DefaultTableColumnModel.java ! src/share/classes/javax/swing/tree/DefaultMutableTreeNode.java ! src/share/classes/javax/swing/undo/CompoundEdit.java Changeset: 50a9a4db3500 Author: malenkov Date: 2008-12-22 17:42 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/50a9a4db3500 4864117: RFE: Make XMLDecoder API more reusable Reviewed-by: peterz, loneid - src/share/classes/com/sun/beans/ObjectHandler.java + src/share/classes/com/sun/beans/decoder/AccessorElementHandler.java + src/share/classes/com/sun/beans/decoder/ArrayElementHandler.java + src/share/classes/com/sun/beans/decoder/BooleanElementHandler.java + src/share/classes/com/sun/beans/decoder/ByteElementHandler.java + src/share/classes/com/sun/beans/decoder/CharElementHandler.java + src/share/classes/com/sun/beans/decoder/ClassElementHandler.java + src/share/classes/com/sun/beans/decoder/DocumentHandler.java + src/share/classes/com/sun/beans/decoder/DoubleElementHandler.java + src/share/classes/com/sun/beans/decoder/ElementHandler.java + src/share/classes/com/sun/beans/decoder/FalseElementHandler.java + src/share/classes/com/sun/beans/decoder/FieldElementHandler.java + src/share/classes/com/sun/beans/decoder/FloatElementHandler.java + src/share/classes/com/sun/beans/decoder/IntElementHandler.java + src/share/classes/com/sun/beans/decoder/JavaElementHandler.java + src/share/classes/com/sun/beans/decoder/LongElementHandler.java + src/share/classes/com/sun/beans/decoder/MethodElementHandler.java + src/share/classes/com/sun/beans/decoder/NewElementHandler.java + src/share/classes/com/sun/beans/decoder/NullElementHandler.java + src/share/classes/com/sun/beans/decoder/ObjectElementHandler.java + src/share/classes/com/sun/beans/decoder/PropertyElementHandler.java + src/share/classes/com/sun/beans/decoder/ShortElementHandler.java + src/share/classes/com/sun/beans/decoder/StringElementHandler.java + src/share/classes/com/sun/beans/decoder/TrueElementHandler.java + src/share/classes/com/sun/beans/decoder/ValueObject.java + src/share/classes/com/sun/beans/decoder/ValueObjectImpl.java + src/share/classes/com/sun/beans/decoder/VarElementHandler.java + src/share/classes/com/sun/beans/decoder/VoidElementHandler.java + src/share/classes/com/sun/beans/finder/AbstractFinder.java ! src/share/classes/com/sun/beans/finder/ClassFinder.java + src/share/classes/com/sun/beans/finder/ConstructorFinder.java + src/share/classes/com/sun/beans/finder/FieldFinder.java + src/share/classes/com/sun/beans/finder/MethodFinder.java ! src/share/classes/com/sun/beans/finder/PrimitiveTypeMap.java + src/share/classes/com/sun/beans/finder/PrimitiveWrapperMap.java + src/share/classes/com/sun/beans/finder/Signature.java ! src/share/classes/java/beans/MetaData.java ! src/share/classes/java/beans/ReflectionUtils.java ! src/share/classes/java/beans/XMLDecoder.java ! src/share/classes/javax/swing/plaf/synth/SynthParser.java + test/java/beans/XMLDecoder/Test4864117.java ! test/java/beans/XMLDecoder/Test6341798.java + test/java/beans/XMLDecoder/spec/AbstractTest.java + test/java/beans/XMLDecoder/spec/TestArray.java + test/java/beans/XMLDecoder/spec/TestBoolean.java + test/java/beans/XMLDecoder/spec/TestByte.java + test/java/beans/XMLDecoder/spec/TestChar.java + test/java/beans/XMLDecoder/spec/TestClass.java + test/java/beans/XMLDecoder/spec/TestDouble.java + test/java/beans/XMLDecoder/spec/TestFalse.java + test/java/beans/XMLDecoder/spec/TestField.java + test/java/beans/XMLDecoder/spec/TestFloat.java + test/java/beans/XMLDecoder/spec/TestInt.java + test/java/beans/XMLDecoder/spec/TestJava.java + test/java/beans/XMLDecoder/spec/TestLong.java + test/java/beans/XMLDecoder/spec/TestMethod.java + test/java/beans/XMLDecoder/spec/TestNew.java + test/java/beans/XMLDecoder/spec/TestNull.java + test/java/beans/XMLDecoder/spec/TestObject.java + test/java/beans/XMLDecoder/spec/TestProperty.java + test/java/beans/XMLDecoder/spec/TestShort.java + test/java/beans/XMLDecoder/spec/TestString.java + test/java/beans/XMLDecoder/spec/TestTrue.java + test/java/beans/XMLDecoder/spec/TestVar.java Changeset: 2b8a0d8b5cbb Author: malenkov Date: 2008-12-25 20:43 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/2b8a0d8b5cbb 6736248: EnumEditor bug. Class check incorrect Reviewed-by: rupashka, alexp ! src/share/classes/sun/beans/editors/EnumEditor.java + test/java/beans/PropertyEditor/TestEnumSubclass.java + test/java/beans/PropertyEditor/TestEnumSubclassJava.java + test/java/beans/PropertyEditor/TestEnumSubclassNull.java + test/java/beans/PropertyEditor/TestEnumSubclassValue.java Changeset: b06c29386f63 Author: amenkov Date: 2009-01-19 20:11 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/b06c29386f63 6702956: OpenJDK: replace encumbered code (software synthesizer) 6717691: Update Gervill with post 1.0 fixes 6740210: Update Gervill with more post 1.0 fixes 6748247: Further update Gervill with still more post 1.0 fixes 6748251: Apply IcedTea midi sound patch 6758986: Gervill: Turn SoftJitterCorrector, SoftAudioPusher threads into a daemon threads Reviewed-by: ohair, darcy ! make/common/Release.gmk ! make/common/internal/BinaryPlugs.gmk ! make/javax/sound/Makefile - make/javax/sound/jsoundhs/FILES.gmk - make/javax/sound/jsoundhs/Makefile - make/javax/sound/jsoundhs/mapfile-vers ! src/share/classes/com/sun/media/sound/AbstractMidiDevice.java + src/share/classes/com/sun/media/sound/AudioFileSoundbankReader.java + src/share/classes/com/sun/media/sound/AudioFloatConverter.java + src/share/classes/com/sun/media/sound/AudioFloatFormatConverter.java + src/share/classes/com/sun/media/sound/AudioFloatInputStream.java + src/share/classes/com/sun/media/sound/AudioSynthesizer.java + src/share/classes/com/sun/media/sound/AudioSynthesizerPropertyInfo.java + src/share/classes/com/sun/media/sound/DLSInfo.java + src/share/classes/com/sun/media/sound/DLSInstrument.java + src/share/classes/com/sun/media/sound/DLSModulator.java + src/share/classes/com/sun/media/sound/DLSRegion.java + src/share/classes/com/sun/media/sound/DLSSample.java + src/share/classes/com/sun/media/sound/DLSSampleLoop.java + src/share/classes/com/sun/media/sound/DLSSampleOptions.java + src/share/classes/com/sun/media/sound/DLSSoundbank.java + src/share/classes/com/sun/media/sound/DLSSoundbankReader.java ! src/share/classes/com/sun/media/sound/DirectAudioDevice.java + src/share/classes/com/sun/media/sound/EmergencySoundbank.java + src/share/classes/com/sun/media/sound/FFT.java + src/share/classes/com/sun/media/sound/InvalidDataException.java + src/share/classes/com/sun/media/sound/InvalidFormatException.java + src/share/classes/com/sun/media/sound/JARSoundbankReader.java + src/share/classes/com/sun/media/sound/ModelAbstractChannelMixer.java + src/share/classes/com/sun/media/sound/ModelAbstractOscillator.java + src/share/classes/com/sun/media/sound/ModelByteBuffer.java + src/share/classes/com/sun/media/sound/ModelByteBufferWavetable.java + src/share/classes/com/sun/media/sound/ModelChannelMixer.java + src/share/classes/com/sun/media/sound/ModelConnectionBlock.java + src/share/classes/com/sun/media/sound/ModelDestination.java + src/share/classes/com/sun/media/sound/ModelDirectedPlayer.java + src/share/classes/com/sun/media/sound/ModelDirector.java + src/share/classes/com/sun/media/sound/ModelIdentifier.java + src/share/classes/com/sun/media/sound/ModelInstrument.java + src/share/classes/com/sun/media/sound/ModelInstrumentComparator.java + src/share/classes/com/sun/media/sound/ModelMappedInstrument.java + src/share/classes/com/sun/media/sound/ModelOscillator.java + src/share/classes/com/sun/media/sound/ModelOscillatorStream.java + src/share/classes/com/sun/media/sound/ModelPatch.java + src/share/classes/com/sun/media/sound/ModelPerformer.java + src/share/classes/com/sun/media/sound/ModelSource.java + src/share/classes/com/sun/media/sound/ModelStandardDirector.java + src/share/classes/com/sun/media/sound/ModelStandardTransform.java + src/share/classes/com/sun/media/sound/ModelTransform.java + src/share/classes/com/sun/media/sound/ModelWavetable.java ! src/share/classes/com/sun/media/sound/Platform.java + src/share/classes/com/sun/media/sound/RIFFInvalidDataException.java + src/share/classes/com/sun/media/sound/RIFFInvalidFormatException.java + src/share/classes/com/sun/media/sound/RIFFReader.java + src/share/classes/com/sun/media/sound/RIFFWriter.java ! src/share/classes/com/sun/media/sound/RealTimeSequencer.java + src/share/classes/com/sun/media/sound/SF2GlobalRegion.java + src/share/classes/com/sun/media/sound/SF2Instrument.java + src/share/classes/com/sun/media/sound/SF2InstrumentRegion.java + src/share/classes/com/sun/media/sound/SF2Layer.java + src/share/classes/com/sun/media/sound/SF2LayerRegion.java + src/share/classes/com/sun/media/sound/SF2Modulator.java + src/share/classes/com/sun/media/sound/SF2Region.java + src/share/classes/com/sun/media/sound/SF2Sample.java + src/share/classes/com/sun/media/sound/SF2Soundbank.java + src/share/classes/com/sun/media/sound/SF2SoundbankReader.java + src/share/classes/com/sun/media/sound/SimpleInstrument.java + src/share/classes/com/sun/media/sound/SimpleSoundbank.java + src/share/classes/com/sun/media/sound/SoftAbstractResampler.java + src/share/classes/com/sun/media/sound/SoftAudioBuffer.java + src/share/classes/com/sun/media/sound/SoftAudioProcessor.java + src/share/classes/com/sun/media/sound/SoftAudioPusher.java + src/share/classes/com/sun/media/sound/SoftChannel.java + src/share/classes/com/sun/media/sound/SoftChannelProxy.java + src/share/classes/com/sun/media/sound/SoftChorus.java + src/share/classes/com/sun/media/sound/SoftControl.java + src/share/classes/com/sun/media/sound/SoftCubicResampler.java + src/share/classes/com/sun/media/sound/SoftEnvelopeGenerator.java + src/share/classes/com/sun/media/sound/SoftFilter.java + src/share/classes/com/sun/media/sound/SoftInstrument.java + src/share/classes/com/sun/media/sound/SoftJitterCorrector.java + src/share/classes/com/sun/media/sound/SoftLanczosResampler.java + src/share/classes/com/sun/media/sound/SoftLimiter.java + src/share/classes/com/sun/media/sound/SoftLinearResampler.java + src/share/classes/com/sun/media/sound/SoftLinearResampler2.java + src/share/classes/com/sun/media/sound/SoftLowFrequencyOscillator.java + src/share/classes/com/sun/media/sound/SoftMainMixer.java + src/share/classes/com/sun/media/sound/SoftMidiAudioFileReader.java + src/share/classes/com/sun/media/sound/SoftMixingClip.java + src/share/classes/com/sun/media/sound/SoftMixingDataLine.java + src/share/classes/com/sun/media/sound/SoftMixingMainMixer.java + src/share/classes/com/sun/media/sound/SoftMixingMixer.java + src/share/classes/com/sun/media/sound/SoftMixingMixerProvider.java + src/share/classes/com/sun/media/sound/SoftMixingSourceDataLine.java + src/share/classes/com/sun/media/sound/SoftPerformer.java + src/share/classes/com/sun/media/sound/SoftPointResampler.java + src/share/classes/com/sun/media/sound/SoftProcess.java + src/share/classes/com/sun/media/sound/SoftProvider.java + src/share/classes/com/sun/media/sound/SoftReceiver.java + src/share/classes/com/sun/media/sound/SoftResampler.java + src/share/classes/com/sun/media/sound/SoftResamplerStreamer.java + src/share/classes/com/sun/media/sound/SoftReverb.java + src/share/classes/com/sun/media/sound/SoftShortMessage.java + src/share/classes/com/sun/media/sound/SoftSincResampler.java + src/share/classes/com/sun/media/sound/SoftSynthesizer.java + src/share/classes/com/sun/media/sound/SoftTuning.java + src/share/classes/com/sun/media/sound/SoftVoice.java + src/share/classes/com/sun/media/sound/WaveExtensibleFileReader.java + src/share/classes/com/sun/media/sound/WaveFloatFileReader.java + src/share/classes/com/sun/media/sound/WaveFloatFileWriter.java ! src/share/classes/com/sun/media/sound/services/javax.sound.midi.spi.MidiDeviceProvider ! src/share/classes/com/sun/media/sound/services/javax.sound.midi.spi.MidiFileReader ! src/share/classes/com/sun/media/sound/services/javax.sound.midi.spi.SoundbankReader ! src/share/classes/com/sun/media/sound/services/javax.sound.sampled.spi.AudioFileReader ! src/share/classes/com/sun/media/sound/services/javax.sound.sampled.spi.FormatConversionProvider ! src/share/classes/com/sun/media/sound/services/javax.sound.sampled.spi.MixerProvider - src/share/lib/audio/soundbank.gm + test/javax/sound/midi/Gervill/AudioFloatConverter/GetFormat.java + test/javax/sound/midi/Gervill/AudioFloatConverter/ToFloatArray.java + test/javax/sound/midi/Gervill/AudioFloatInputStream/Available.java + test/javax/sound/midi/Gervill/AudioFloatInputStream/Close.java + test/javax/sound/midi/Gervill/AudioFloatInputStream/GetFormat.java + test/javax/sound/midi/Gervill/AudioFloatInputStream/GetFrameLength.java + test/javax/sound/midi/Gervill/AudioFloatInputStream/MarkSupported.java + test/javax/sound/midi/Gervill/AudioFloatInputStream/Read.java + test/javax/sound/midi/Gervill/AudioFloatInputStream/ReadFloatArray.java + test/javax/sound/midi/Gervill/AudioFloatInputStream/ReadFloatArrayIntInt.java + test/javax/sound/midi/Gervill/AudioFloatInputStream/Reset.java + test/javax/sound/midi/Gervill/AudioFloatInputStream/Skip.java + test/javax/sound/midi/Gervill/DLSSoundbankReader/TestGetSoundbankFile.java + test/javax/sound/midi/Gervill/DLSSoundbankReader/TestGetSoundbankInputStream.java + test/javax/sound/midi/Gervill/DLSSoundbankReader/TestGetSoundbankInputStream2.java + test/javax/sound/midi/Gervill/DLSSoundbankReader/TestGetSoundbankUrl.java + test/javax/sound/midi/Gervill/DLSSoundbankReader/ding.dls + test/javax/sound/midi/Gervill/EmergencySoundbank/TestCreateSoundbank.java + test/javax/sound/midi/Gervill/ModelByteBuffer/GetInputStream.java + test/javax/sound/midi/Gervill/ModelByteBuffer/GetRoot.java + test/javax/sound/midi/Gervill/ModelByteBuffer/Load.java + test/javax/sound/midi/Gervill/ModelByteBuffer/LoadAll.java + test/javax/sound/midi/Gervill/ModelByteBuffer/NewModelByteBufferByteArray.java + test/javax/sound/midi/Gervill/ModelByteBuffer/NewModelByteBufferByteArrayIntInt.java + test/javax/sound/midi/Gervill/ModelByteBuffer/NewModelByteBufferFile.java + test/javax/sound/midi/Gervill/ModelByteBuffer/NewModelByteBufferFileLongLong.java + test/javax/sound/midi/Gervill/ModelByteBuffer/RandomFileInputStream/Available.java + test/javax/sound/midi/Gervill/ModelByteBuffer/RandomFileInputStream/Close.java + test/javax/sound/midi/Gervill/ModelByteBuffer/RandomFileInputStream/MarkReset.java + test/javax/sound/midi/Gervill/ModelByteBuffer/RandomFileInputStream/MarkSupported.java + test/javax/sound/midi/Gervill/ModelByteBuffer/RandomFileInputStream/Read.java + test/javax/sound/midi/Gervill/ModelByteBuffer/RandomFileInputStream/ReadByte.java + test/javax/sound/midi/Gervill/ModelByteBuffer/RandomFileInputStream/ReadByteIntInt.java + test/javax/sound/midi/Gervill/ModelByteBuffer/RandomFileInputStream/Skip.java + test/javax/sound/midi/Gervill/ModelByteBuffer/SubbufferLong.java + test/javax/sound/midi/Gervill/ModelByteBuffer/SubbufferLongLong.java + test/javax/sound/midi/Gervill/ModelByteBuffer/SubbufferLongLongBoolean.java + test/javax/sound/midi/Gervill/ModelByteBuffer/Unload.java + test/javax/sound/midi/Gervill/ModelByteBuffer/WriteTo.java + test/javax/sound/midi/Gervill/ModelByteBufferWavetable/GetAttenuation.java + test/javax/sound/midi/Gervill/ModelByteBufferWavetable/GetChannels.java + test/javax/sound/midi/Gervill/ModelByteBufferWavetable/GetLoopLength.java + test/javax/sound/midi/Gervill/ModelByteBufferWavetable/GetLoopStart.java + test/javax/sound/midi/Gervill/ModelByteBufferWavetable/GetPitchCorrection.java + test/javax/sound/midi/Gervill/ModelByteBufferWavetable/NewModelByteBufferWavetableModelByteBuffer.java + test/javax/sound/midi/Gervill/ModelByteBufferWavetable/NewModelByteBufferWavetableModelByteBufferAudioFormat.java + test/javax/sound/midi/Gervill/ModelByteBufferWavetable/NewModelByteBufferWavetableModelByteBufferAudioFormatFloat.java + test/javax/sound/midi/Gervill/ModelByteBufferWavetable/NewModelByteBufferWavetableModelByteBufferFloat.java + test/javax/sound/midi/Gervill/ModelByteBufferWavetable/Open.java + test/javax/sound/midi/Gervill/ModelByteBufferWavetable/Set8BitExtensionBuffer.java + test/javax/sound/midi/Gervill/ModelByteBufferWavetable/SetLoopType.java + test/javax/sound/midi/Gervill/ModelDestination/NewModelDestination.java + test/javax/sound/midi/Gervill/ModelDestination/NewModelDestinationModelIdentifier.java + test/javax/sound/midi/Gervill/ModelDestination/SetIdentifier.java + test/javax/sound/midi/Gervill/ModelDestination/SetTransform.java + test/javax/sound/midi/Gervill/ModelIdentifier/EqualsObject.java + test/javax/sound/midi/Gervill/ModelIdentifier/NewModelIdentifierString.java + test/javax/sound/midi/Gervill/ModelIdentifier/NewModelIdentifierStringInt.java + test/javax/sound/midi/Gervill/ModelIdentifier/NewModelIdentifierStringString.java + test/javax/sound/midi/Gervill/ModelIdentifier/NewModelIdentifierStringStringInt.java + test/javax/sound/midi/Gervill/ModelIdentifier/SetInstance.java + test/javax/sound/midi/Gervill/ModelIdentifier/SetObject.java + test/javax/sound/midi/Gervill/ModelIdentifier/SetVariable.java + test/javax/sound/midi/Gervill/ModelPerformer/GetOscillators.java + test/javax/sound/midi/Gervill/ModelPerformer/SetConnectionBlocks.java + test/javax/sound/midi/Gervill/ModelPerformer/SetDefaultConnectionsEnabled.java + test/javax/sound/midi/Gervill/ModelPerformer/SetExclusiveClass.java + test/javax/sound/midi/Gervill/ModelPerformer/SetKeyFrom.java + test/javax/sound/midi/Gervill/ModelPerformer/SetKeyTo.java + test/javax/sound/midi/Gervill/ModelPerformer/SetName.java + test/javax/sound/midi/Gervill/ModelPerformer/SetSelfNonExclusive.java + test/javax/sound/midi/Gervill/ModelPerformer/SetVelFrom.java + test/javax/sound/midi/Gervill/ModelPerformer/SetVelTo.java + test/javax/sound/midi/Gervill/ModelSource/NewModelSource.java + test/javax/sound/midi/Gervill/ModelSource/NewModelSourceModelIdentifier.java + test/javax/sound/midi/Gervill/ModelSource/NewModelSourceModelIdentifierBoolean.java + test/javax/sound/midi/Gervill/ModelSource/NewModelSourceModelIdentifierBooleanBoolean.java + test/javax/sound/midi/Gervill/ModelSource/NewModelSourceModelIdentifierBooleanBooleanInt.java + test/javax/sound/midi/Gervill/ModelSource/NewModelSourceModelIdentifierModelTransform.java + test/javax/sound/midi/Gervill/ModelSource/SetIdentifier.java + test/javax/sound/midi/Gervill/ModelSource/SetTransform.java + test/javax/sound/midi/Gervill/ModelStandardTransform/NewModelStandardTransform.java + test/javax/sound/midi/Gervill/ModelStandardTransform/NewModelStandardTransformBoolean.java + test/javax/sound/midi/Gervill/ModelStandardTransform/NewModelStandardTransformBooleanBoolean.java + test/javax/sound/midi/Gervill/ModelStandardTransform/NewModelStandardTransformBooleanBooleanInt.java + test/javax/sound/midi/Gervill/ModelStandardTransform/SetDirection.java + test/javax/sound/midi/Gervill/ModelStandardTransform/SetPolarity.java + test/javax/sound/midi/Gervill/ModelStandardTransform/SetTransform.java + test/javax/sound/midi/Gervill/ModelStandardTransform/TransformAbsolute.java + test/javax/sound/midi/Gervill/ModelStandardTransform/TransformConcave.java + test/javax/sound/midi/Gervill/ModelStandardTransform/TransformConvex.java + test/javax/sound/midi/Gervill/ModelStandardTransform/TransformLinear.java + test/javax/sound/midi/Gervill/ModelStandardTransform/TransformSwitch.java + test/javax/sound/midi/Gervill/RiffReaderWriter/Available.java + test/javax/sound/midi/Gervill/RiffReaderWriter/Close.java + test/javax/sound/midi/Gervill/RiffReaderWriter/GetFilePointer.java + test/javax/sound/midi/Gervill/RiffReaderWriter/GetSize.java + test/javax/sound/midi/Gervill/RiffReaderWriter/HasNextChunk.java + test/javax/sound/midi/Gervill/RiffReaderWriter/Read.java + test/javax/sound/midi/Gervill/RiffReaderWriter/ReadByte.java + test/javax/sound/midi/Gervill/RiffReaderWriter/ReadByteArrayIntInt.java + test/javax/sound/midi/Gervill/RiffReaderWriter/ReadInt.java + test/javax/sound/midi/Gervill/RiffReaderWriter/ReadLong.java + test/javax/sound/midi/Gervill/RiffReaderWriter/ReadShort.java + test/javax/sound/midi/Gervill/RiffReaderWriter/ReadString.java + test/javax/sound/midi/Gervill/RiffReaderWriter/ReadUnsignedByte.java + test/javax/sound/midi/Gervill/RiffReaderWriter/ReadUnsignedInt.java + test/javax/sound/midi/Gervill/RiffReaderWriter/ReadUnsignedShort.java + test/javax/sound/midi/Gervill/RiffReaderWriter/Skip.java + test/javax/sound/midi/Gervill/RiffReaderWriter/WriteOutputStream.java + test/javax/sound/midi/Gervill/SF2SoundbankReader/TestGetSoundbankFile.java + test/javax/sound/midi/Gervill/SF2SoundbankReader/TestGetSoundbankInputStream.java + test/javax/sound/midi/Gervill/SF2SoundbankReader/TestGetSoundbankInputStream2.java + test/javax/sound/midi/Gervill/SF2SoundbankReader/TestGetSoundbankUrl.java + test/javax/sound/midi/Gervill/SF2SoundbankReader/ding.sf2 + test/javax/sound/midi/Gervill/SimpleInstrument/AddModelInstrument.java + test/javax/sound/midi/Gervill/SimpleInstrument/AddModelInstrumentIntInt.java + test/javax/sound/midi/Gervill/SimpleInstrument/AddModelInstrumentIntIntIntInt.java + test/javax/sound/midi/Gervill/SimpleInstrument/AddModelInstrumentIntIntIntIntInt.java + test/javax/sound/midi/Gervill/SimpleInstrument/AddModelPerformer.java + test/javax/sound/midi/Gervill/SimpleInstrument/AddModelPerformerArray.java + test/javax/sound/midi/Gervill/SimpleInstrument/AddModelPerformerArrayIntInt.java + test/javax/sound/midi/Gervill/SimpleInstrument/AddModelPerformerArrayIntIntIntInt.java + test/javax/sound/midi/Gervill/SimpleInstrument/AddModelPerformerArrayIntIntIntIntInt.java + test/javax/sound/midi/Gervill/SimpleInstrument/AddModelPerformerIntInt.java + test/javax/sound/midi/Gervill/SimpleInstrument/AddModelPerformerIntIntIntInt.java + test/javax/sound/midi/Gervill/SimpleInstrument/AddModelPerformerIntIntIntIntInt.java + test/javax/sound/midi/Gervill/SimpleInstrument/Clear.java + test/javax/sound/midi/Gervill/SimpleInstrument/SetName.java + test/javax/sound/midi/Gervill/SimpleInstrument/SetPatch.java + test/javax/sound/midi/Gervill/SimpleSoundbank/AddInstrument.java + test/javax/sound/midi/Gervill/SimpleSoundbank/AddResource.java + test/javax/sound/midi/Gervill/SimpleSoundbank/GetInstrument.java + test/javax/sound/midi/Gervill/SimpleSoundbank/RemoveInstrument.java + test/javax/sound/midi/Gervill/SimpleSoundbank/SetDescription.java + test/javax/sound/midi/Gervill/SimpleSoundbank/SetName.java + test/javax/sound/midi/Gervill/SimpleSoundbank/SetVendor.java + test/javax/sound/midi/Gervill/SimpleSoundbank/SetVersion.java + test/javax/sound/midi/Gervill/SoftAudioBuffer/Array.java + test/javax/sound/midi/Gervill/SoftAudioBuffer/Clear.java + test/javax/sound/midi/Gervill/SoftAudioBuffer/Get.java + test/javax/sound/midi/Gervill/SoftAudioBuffer/NewSoftAudioBuffer.java + test/javax/sound/midi/Gervill/SoftAudioSynthesizer/DummySourceDataLine.java + test/javax/sound/midi/Gervill/SoftAudioSynthesizer/GetFormat.java + test/javax/sound/midi/Gervill/SoftAudioSynthesizer/GetPropertyInfo.java + test/javax/sound/midi/Gervill/SoftAudioSynthesizer/Open.java + test/javax/sound/midi/Gervill/SoftAudioSynthesizer/OpenStream.java + test/javax/sound/midi/Gervill/SoftChannel/AllNotesOff.java + test/javax/sound/midi/Gervill/SoftChannel/AllSoundOff.java + test/javax/sound/midi/Gervill/SoftChannel/ChannelPressure.java + test/javax/sound/midi/Gervill/SoftChannel/Controller.java + test/javax/sound/midi/Gervill/SoftChannel/LocalControl.java + test/javax/sound/midi/Gervill/SoftChannel/Mono.java + test/javax/sound/midi/Gervill/SoftChannel/Mute.java + test/javax/sound/midi/Gervill/SoftChannel/NoteOff.java + test/javax/sound/midi/Gervill/SoftChannel/NoteOff2.java + test/javax/sound/midi/Gervill/SoftChannel/NoteOn.java + test/javax/sound/midi/Gervill/SoftChannel/Omni.java + test/javax/sound/midi/Gervill/SoftChannel/PitchBend.java + test/javax/sound/midi/Gervill/SoftChannel/PolyPressure.java + test/javax/sound/midi/Gervill/SoftChannel/ProgramChange.java + test/javax/sound/midi/Gervill/SoftChannel/ResetAllControllers.java + test/javax/sound/midi/Gervill/SoftChannel/SoftTestUtils.java + test/javax/sound/midi/Gervill/SoftChannel/Solo.java + test/javax/sound/midi/Gervill/SoftCubicResampler/Interpolate.java + test/javax/sound/midi/Gervill/SoftLanczosResampler/Interpolate.java + test/javax/sound/midi/Gervill/SoftLimiter/ProcessAudio_replace_mix.java + test/javax/sound/midi/Gervill/SoftLimiter/ProcessAudio_replace_mix_mono.java + test/javax/sound/midi/Gervill/SoftLimiter/ProcessAudio_replace_mix_mono_overdrive.java + test/javax/sound/midi/Gervill/SoftLimiter/ProcessAudio_replace_mix_overdrive.java + test/javax/sound/midi/Gervill/SoftLimiter/ProcessAudio_replace_normal.java + test/javax/sound/midi/Gervill/SoftLimiter/ProcessAudio_replace_normal_mono.java + test/javax/sound/midi/Gervill/SoftLimiter/ProcessAudio_replace_overdrive.java + test/javax/sound/midi/Gervill/SoftLimiter/ProcessAudio_replace_overdrive_mono.java + test/javax/sound/midi/Gervill/SoftLinearResampler/Interpolate.java + test/javax/sound/midi/Gervill/SoftLinearResampler2/Interpolate.java + test/javax/sound/midi/Gervill/SoftPointResampler/Interpolate.java + test/javax/sound/midi/Gervill/SoftProvider/GetDevice.java + test/javax/sound/midi/Gervill/SoftReceiver/Close.java + test/javax/sound/midi/Gervill/SoftReceiver/Send_ActiveSense.java + test/javax/sound/midi/Gervill/SoftReceiver/Send_AllNotesOff.java + test/javax/sound/midi/Gervill/SoftReceiver/Send_AllSoundOff.java + test/javax/sound/midi/Gervill/SoftReceiver/Send_ChannelPressure.java + test/javax/sound/midi/Gervill/SoftReceiver/Send_Controller.java + test/javax/sound/midi/Gervill/SoftReceiver/Send_Mono.java + test/javax/sound/midi/Gervill/SoftReceiver/Send_NoteOff.java + test/javax/sound/midi/Gervill/SoftReceiver/Send_NoteOn.java + test/javax/sound/midi/Gervill/SoftReceiver/Send_NoteOn_AllChannels.java + test/javax/sound/midi/Gervill/SoftReceiver/Send_NoteOn_Delayed.java + test/javax/sound/midi/Gervill/SoftReceiver/Send_NoteOn_Multiple.java + test/javax/sound/midi/Gervill/SoftReceiver/Send_Omni.java + test/javax/sound/midi/Gervill/SoftReceiver/Send_PitchBend.java + test/javax/sound/midi/Gervill/SoftReceiver/Send_PolyPressure.java + test/javax/sound/midi/Gervill/SoftReceiver/Send_ProgramChange.java + test/javax/sound/midi/Gervill/SoftReceiver/Send_ResetAllControllers.java + test/javax/sound/midi/Gervill/SoftReceiver/SoftTestUtils.java + test/javax/sound/midi/Gervill/SoftSincResampler/Interpolate.java + test/javax/sound/midi/Gervill/SoftSynthesizer/Close.java + test/javax/sound/midi/Gervill/SoftSynthesizer/DummySourceDataLine.java + test/javax/sound/midi/Gervill/SoftSynthesizer/GetAvailableInstruments.java + test/javax/sound/midi/Gervill/SoftSynthesizer/GetChannels.java + test/javax/sound/midi/Gervill/SoftSynthesizer/GetDefaultSoundbank.java + test/javax/sound/midi/Gervill/SoftSynthesizer/GetDeviceInfo.java + test/javax/sound/midi/Gervill/SoftSynthesizer/GetLatency.java + test/javax/sound/midi/Gervill/SoftSynthesizer/GetLoadedInstruments.java + test/javax/sound/midi/Gervill/SoftSynthesizer/GetMaxPolyphony.java + test/javax/sound/midi/Gervill/SoftSynthesizer/GetMaxReceivers.java + test/javax/sound/midi/Gervill/SoftSynthesizer/GetMaxTransmitters.java + test/javax/sound/midi/Gervill/SoftSynthesizer/GetMicrosecondPosition.java + test/javax/sound/midi/Gervill/SoftSynthesizer/GetReceiver.java + test/javax/sound/midi/Gervill/SoftSynthesizer/GetReceiver2.java + test/javax/sound/midi/Gervill/SoftSynthesizer/GetReceivers.java + test/javax/sound/midi/Gervill/SoftSynthesizer/GetTransmitter.java + test/javax/sound/midi/Gervill/SoftSynthesizer/GetTransmitters.java + test/javax/sound/midi/Gervill/SoftSynthesizer/GetVoiceStatus.java + test/javax/sound/midi/Gervill/SoftSynthesizer/ImplicitOpenClose.java + test/javax/sound/midi/Gervill/SoftSynthesizer/IsOpen.java + test/javax/sound/midi/Gervill/SoftSynthesizer/IsSoundbankSupported.java + test/javax/sound/midi/Gervill/SoftSynthesizer/LoadAllInstruments.java + test/javax/sound/midi/Gervill/SoftSynthesizer/LoadInstrument.java + test/javax/sound/midi/Gervill/SoftSynthesizer/LoadInstruments.java + test/javax/sound/midi/Gervill/SoftSynthesizer/Open.java + test/javax/sound/midi/Gervill/SoftSynthesizer/OpenStream.java + test/javax/sound/midi/Gervill/SoftSynthesizer/RemapInstrument.java + test/javax/sound/midi/Gervill/SoftSynthesizer/TestRender1.java + test/javax/sound/midi/Gervill/SoftSynthesizer/UnloadAllInstruments.java + test/javax/sound/midi/Gervill/SoftSynthesizer/UnloadInstrument.java + test/javax/sound/midi/Gervill/SoftSynthesizer/UnloadInstruments.java + test/javax/sound/midi/Gervill/SoftSynthesizer/ding.sf2 + test/javax/sound/midi/Gervill/SoftSynthesizer/expresso.mid + test/javax/sound/midi/Gervill/SoftTuning/GetName.java + test/javax/sound/midi/Gervill/SoftTuning/GetTuning.java + test/javax/sound/midi/Gervill/SoftTuning/GetTuningInt.java + test/javax/sound/midi/Gervill/SoftTuning/Load1.java + test/javax/sound/midi/Gervill/SoftTuning/Load2.java + test/javax/sound/midi/Gervill/SoftTuning/Load4.java + test/javax/sound/midi/Gervill/SoftTuning/Load5.java + test/javax/sound/midi/Gervill/SoftTuning/Load6.java + test/javax/sound/midi/Gervill/SoftTuning/Load7.java + test/javax/sound/midi/Gervill/SoftTuning/Load8.java + test/javax/sound/midi/Gervill/SoftTuning/Load9.java + test/javax/sound/midi/Gervill/SoftTuning/NewSoftTuning.java + test/javax/sound/midi/Gervill/SoftTuning/NewSoftTuningByteArray.java + test/javax/sound/midi/Gervill/SoftTuning/NewSoftTuningPatch.java + test/javax/sound/midi/Gervill/SoftTuning/NewSoftTuningPatchByteArray.java Changeset: cda097df492f Author: peterz Date: 2009-01-21 21:30 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/cda097df492f 6792401: Windows LAF: ActiveWindowsIcon should not be greedy with fallback icon Summary: Fallback mechanism changed to use symbolic name instead of icon. Reviewed-by: igor, rupashka ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java Changeset: cf591ddc3456 Author: naoto Date: 2009-01-21 13:58 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/cf591ddc3456 6627549: ISO 3166 code addition: Saint Barthelemy and Saint Martin 6786276: Locale.getISOCountries() still contains country code "CS" Reviewed-by: okutsu ! src/share/classes/java/util/CurrencyData.properties ! src/share/classes/java/util/LocaleISOData.java ! src/share/classes/sun/util/resources/LocaleNames.properties ! test/java/util/Currency/ValidateISO4217.java ! test/java/util/Locale/LocaleTest.java ! test/sun/text/resources/LocaleData Changeset: f650e6e22c16 Author: malenkov Date: 2009-01-23 18:31 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f650e6e22c16 4222508: JColorChooser ignores setEnabled() function call Reviewed-by: peterz, rupashka ! src/share/classes/javax/swing/colorchooser/AbstractColorChooserPanel.java ! src/share/classes/javax/swing/colorchooser/ColorChooserPanel.java ! src/share/classes/javax/swing/colorchooser/DefaultSwatchChooserPanel.java + test/javax/swing/JColorChooser/Test4222508.html + test/javax/swing/JColorChooser/Test4222508.java Changeset: d75ae3f11e01 Author: peytoia Date: 2009-01-26 09:19 +0900 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d75ae3f11e01 6796489: (tz) Support tzdata2009a Reviewed-by: okutsu ! make/sun/javazic/tzdata/VERSION ! make/sun/javazic/tzdata/asia ! make/sun/javazic/tzdata/backward ! make/sun/javazic/tzdata/europe ! make/sun/javazic/tzdata/northamerica ! make/sun/javazic/tzdata/zone.tab ! src/share/classes/sun/util/resources/TimeZoneNames.java ! src/share/classes/sun/util/resources/TimeZoneNames_de.java ! src/share/classes/sun/util/resources/TimeZoneNames_es.java ! src/share/classes/sun/util/resources/TimeZoneNames_fr.java ! src/share/classes/sun/util/resources/TimeZoneNames_it.java ! src/share/classes/sun/util/resources/TimeZoneNames_ja.java ! src/share/classes/sun/util/resources/TimeZoneNames_ko.java ! src/share/classes/sun/util/resources/TimeZoneNames_sv.java ! src/share/classes/sun/util/resources/TimeZoneNames_zh_CN.java ! src/share/classes/sun/util/resources/TimeZoneNames_zh_TW.java Changeset: e02f2d591cd5 Author: malenkov Date: 2009-01-29 15:34 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e02f2d591cd5 6788531: java.beans.Statement imposes excessive access control Reviewed-by: peterz, rupashka ! src/share/classes/com/sun/beans/finder/MethodFinder.java ! src/share/classes/java/beans/EventHandler.java ! src/share/classes/java/beans/ReflectionUtils.java ! src/share/classes/java/beans/Statement.java + test/java/beans/EventHandler/Test6788531.java + test/java/beans/Statement/Test6788531.java Changeset: ff6633279632 Author: rupashka Date: 2009-01-29 19:06 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/ff6633279632 6794836: BasicSliderUI throws NullPointerExc when JSlider maximum is Integer.MAX_VALUE Reviewed-by: peterz ! src/share/classes/javax/swing/plaf/basic/BasicSliderUI.java + test/javax/swing/JSlider/6794836/bug6794836.java Changeset: 1f6ff90d9692 Author: lana Date: 2009-01-29 09:25 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/1f6ff90d9692 Merge - make/javax/sound/jsoundhs/FILES.gmk - make/javax/sound/jsoundhs/Makefile - make/javax/sound/jsoundhs/mapfile-vers - src/share/classes/com/sun/beans/ObjectHandler.java ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsFileChooserUI.java ! src/share/classes/javax/swing/RepaintManager.java ! src/share/classes/javax/swing/plaf/metal/MetalFileChooserUI.java ! src/share/classes/javax/swing/plaf/synth/SynthParser.java ! src/share/classes/sun/swing/plaf/synth/SynthFileChooserUIImpl.java ! src/share/classes/sun/util/resources/TimeZoneNames.java ! src/share/classes/sun/util/resources/TimeZoneNames_de.java ! src/share/classes/sun/util/resources/TimeZoneNames_es.java ! src/share/classes/sun/util/resources/TimeZoneNames_fr.java ! src/share/classes/sun/util/resources/TimeZoneNames_it.java ! src/share/classes/sun/util/resources/TimeZoneNames_ja.java ! src/share/classes/sun/util/resources/TimeZoneNames_ko.java ! src/share/classes/sun/util/resources/TimeZoneNames_sv.java ! src/share/classes/sun/util/resources/TimeZoneNames_zh_CN.java ! src/share/classes/sun/util/resources/TimeZoneNames_zh_TW.java - src/share/lib/audio/soundbank.gm Changeset: 4b03e27a4409 Author: lana Date: 2009-02-03 22:02 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/4b03e27a4409 Merge - make/javax/sound/jsoundhs/FILES.gmk - make/javax/sound/jsoundhs/Makefile - make/javax/sound/jsoundhs/mapfile-vers - src/share/classes/com/sun/beans/ObjectHandler.java - src/share/lib/audio/soundbank.gm Changeset: 886a56291f1c Author: tbell Date: 2009-02-05 09:24 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/886a56291f1c Merge - make/javax/sound/jsoundhs/FILES.gmk - make/javax/sound/jsoundhs/Makefile - make/javax/sound/jsoundhs/mapfile-vers - src/share/classes/com/sun/beans/ObjectHandler.java - src/share/lib/audio/soundbank.gm Changeset: c87205c0e215 Author: tbell Date: 2009-02-05 09:28 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c87205c0e215 Merge Changeset: b4ac413b1f12 Author: xdono Date: 2009-02-05 16:07 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/b4ac413b1f12 Added tag jdk7-b46 for changeset 4b03e27a4409 ! .hgtags Changeset: 2753acfbf013 Author: tbell Date: 2009-02-06 09:43 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/2753acfbf013 Merge From tim.bell at sun.com Sat Feb 7 06:17:21 2009 From: tim.bell at sun.com (tim.bell at sun.com) Date: Sat, 07 Feb 2009 06:17:21 +0000 Subject: hg: jdk7/tl/langtools: 3 new changesets Message-ID: <20090207061726.7F471D11E@hg.openjdk.java.net> Changeset: 2b8f6bab2392 Author: xdono Date: 2009-02-05 16:07 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/2b8f6bab2392 Added tag jdk7-b46 for changeset be546a6c08e3 ! .hgtags Changeset: 638d5fbf5e78 Author: tbell Date: 2009-02-06 09:44 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/638d5fbf5e78 Merge Changeset: 000d1e518bc5 Author: tbell Date: 2009-02-06 17:24 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/000d1e518bc5 Merge From poonam.bajaj at sun.com Tue Feb 10 12:53:27 2009 From: poonam.bajaj at sun.com (poonam.bajaj at sun.com) Date: Tue, 10 Feb 2009 12:53:27 +0000 Subject: hg: jdk7/tl/jdk: 6755621: Include SA binaries into Windows JDK Message-ID: <20090210125340.EAD98D264@hg.openjdk.java.net> Changeset: 40ce81649cd6 Author: poonam Date: 2009-02-10 03:26 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/40ce81649cd6 6755621: Include SA binaries into Windows JDK Summary: These changes will enable inclusion of sa-jdi.jar and sawindbg.dll into Windows JDK bundle. Reviewed-by: never, jjh, alanb ! make/common/Defs-windows.gmk From Boris.Just at wuestenrot.at Tue Feb 10 14:38:31 2009 From: Boris.Just at wuestenrot.at (Boris.Just at wuestenrot.at) Date: Tue, 10 Feb 2009 15:38:31 +0100 Subject: New charset IBM1153 Message-ID: Hi everybody! Is there any possibility that a further charset (HOST IBM CP1153/1375 Latin 2 - EBCDIC Multilingual) will be part of a next JRE version or update? It is quite a new charset and is simular to IBM870, but has the EURO sign in addition. As more and more countries in eastern europe change their currency to euro or use it for payment, it is getting more and more important (in particular for mainframes). We have a problem just now with a DB2 java driver, which does not support this charset because it is at the moment not part of the standard JVM. Thanks for your reply in advance! Best regards Boris Just -------------- next part -------------- An HTML attachment was scrubbed... URL: From Xueming.Shen at Sun.COM Tue Feb 10 18:51:54 2009 From: Xueming.Shen at Sun.COM (Xueming Shen) Date: Tue, 10 Feb 2009 10:51:54 -0800 Subject: New charset IBM1153 In-Reply-To: References: Message-ID: <4991CCCA.3080000@sun.com> No plan to add them yet. With the java.nio.charset.spi introduced into JDK since 1.4, developers and third party vendors are encouraged to implement the new charsets themself via SPI, when those charsets are not included in the JDK/JRE default chraset repository and they are needed in their business. That said, we consantly consider the possibility of adding more charsets into the JDK/JRE default repository, should need/request be justified. Sherman Boris.Just at wuestenrot.at wrote: > > Hi everybody! > > Is there any possibility that a further charset (HOST IBM CP1153/1375 > Latin 2 - EBCDIC Multilingual) will be part of > a next JRE version or update? It is quite a new charset and is simular > to IBM870, but has the EURO sign in addition. > As more and more countries in eastern europe change their currency to > euro or use it for payment, it is getting more > and more important (in particular for mainframes). > > We have a problem just now with a DB2 java driver, which does not > support this charset because it is at the moment not part of the > standard JVM. > > Thanks for your reply in advance! > > > Best regards > > Boris Just > From Ulf.Zibis at gmx.de Tue Feb 10 19:22:47 2009 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Tue, 10 Feb 2009 20:22:47 +0100 Subject: New charset IBM1153 In-Reply-To: References: Message-ID: <4991D407.1020008@gmx.de> Hi Boris, I'm on the way, to include extended charsets in my project https://java-nio-charset-enhanced.dev.java.net/ in footprint saving way. Give me some more 2..3 weeks. Then it would be easy for me to compile a special jar for you, which you could preload via -Xbootclasspath/p:, if you are using Java version 6. -Ulf Am 10.02.2009 15:38, Boris.Just at wuestenrot.at schrieb: > > Hi everybody! > > Is there any possibility that a further charset (HOST IBM CP1153/1375 > Latin 2 - EBCDIC Multilingual) will be part of > a next JRE version or update? It is quite a new charset and is simular > to IBM870, but has the EURO sign in addition. > As more and more countries in eastern europe change their currency to > euro or use it for payment, it is getting more > and more important (in particular for mainframes). > > We have a problem just now with a DB2 java driver, which does not > support this charset because it is at the moment not part of the > standard JVM. > > Thanks for your reply in advance! > > > Best regards > > Boris Just > From martinrb at google.com Wed Feb 11 01:00:21 2009 From: martinrb at google.com (Martin Buchholz) Date: Tue, 10 Feb 2009 17:00:21 -0800 Subject: Adding Josh Bloch as a member of the Core Libraries Group Message-ID: <1ccfd1c10902101700u31b79222kfc346cb492a29c58@mail.gmail.com> I'd like to add Josh Bloch as a member of this group. Should I hold the call for votes (I've never done that) or should a Sun person help do that? Does the Core Libraries Group have a moderator? If so, how would I find out? Thanks, Martin From Alan.Bateman at Sun.COM Wed Feb 11 09:00:24 2009 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Wed, 11 Feb 2009 09:00:24 +0000 Subject: Adding Josh Bloch as a member of the Core Libraries Group In-Reply-To: <1ccfd1c10902101700u31b79222kfc346cb492a29c58@mail.gmail.com> References: <1ccfd1c10902101700u31b79222kfc346cb492a29c58@mail.gmail.com> Message-ID: <499293A8.4060001@sun.com> Martin Buchholz wrote: > I'd like to add Josh Bloch as a member of this group. > Should I hold the call for votes (I've never done that) > or should a Sun person help do that? Does the > Core Libraries Group have a moderator? If so, > how would I find out? > > Thanks, > > Martin > Iris is still the moderator (I don't know if moderator names are listed anywhere, except on the listinfo page for each mailing list). -Alan. From christopher.hegarty at sun.com Wed Feb 11 13:21:15 2009 From: christopher.hegarty at sun.com (christopher.hegarty at sun.com) Date: Wed, 11 Feb 2009 13:21:15 +0000 Subject: hg: jdk7/tl/jdk: 6799040: Portability issues in src/solaris/native/java/net/Inet4AddressImpl.c Message-ID: <20090211132141.20231D38E@hg.openjdk.java.net> Changeset: 043dfafc41a5 Author: chegar Date: 2009-02-11 13:16 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/043dfafc41a5 6799040: Portability issues in src/solaris/native/java/net/Inet4AddressImpl.c Reviewed-by: alanb Contributed-by: christos at zoulas.com ! src/solaris/native/java/net/Inet4AddressImpl.c ! src/solaris/native/java/net/Inet6AddressImpl.c From i30817 at gmail.com Wed Feb 11 15:56:43 2009 From: i30817 at gmail.com (Paulo Levi) Date: Wed, 11 Feb 2009 15:56:43 +0000 Subject: Question about Executors. Message-ID: <212322090902110756p2430daa6od1ea7dc2b25628a0@mail.gmail.com> Why is there no (a horrible name) newFixedCachedThreadPool() static factory? I think it makes sense for tasks that have a upper throughput, but still want to release the threads after some idle time. Or am i wrong? From David.Holmes at Sun.COM Thu Feb 12 01:09:41 2009 From: David.Holmes at Sun.COM (David Holmes - Sun Microsystems) Date: Thu, 12 Feb 2009 11:09:41 +1000 Subject: Question about Executors. In-Reply-To: <212322090902110756p2430daa6od1ea7dc2b25628a0@mail.gmail.com> References: <212322090902110756p2430daa6od1ea7dc2b25628a0@mail.gmail.com> Message-ID: <499376D5.4090206@sun.com> FYI This question was redirected to the concurrency-interest at cs.oswego.edu mailing list. David Paulo Levi said the following on 02/12/09 01:56: > Why is there no (a horrible name) newFixedCachedThreadPool() static factory? > > I think it makes sense for tasks that have a upper throughput, but > still want to release the threads after some idle time. Or am i wrong? From irisg at alum.mit.edu Thu Feb 12 19:37:47 2009 From: irisg at alum.mit.edu (Iris Clark) Date: Thu, 12 Feb 2009 14:37:47 -0500 (EST) Subject: CFV: Josh Bloch to Membership in the Core Libraries Group Message-ID: <10780596.3316.1234467467105.JavaMail.help@alum.mit.edu> Greetings, voting members of the Core Libraries Group! I nominate Josh Bloch to Membership in the Core Libraries Group. Please cast your vote by replying, publicly, to this message with either Vote: yes or Vote: no as the first line of the message body. You may, at your option, indicate the reason for your decision on subsequent lines. Votes must be cast in the open; votes sent as private replies will not be counted. Votes are due by midnight UTC next Thursday, 19 February, after which time the votes will be tallied and reported to this list. Only Members of the Core Libraries are eligible to vote on this decision. The current Members are: Alan Bateman Christopher Hegarty David Bristor Doug Lea Iris Clark Jeff Nisewanger Joe Darcy Mark Reinhold Martin Buchholz Pete Soper Peter Jones Xueming Shen Thanks, iris core-libs-dev moderator From Alan.Bateman at Sun.COM Thu Feb 12 22:15:53 2009 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Thu, 12 Feb 2009 22:15:53 +0000 Subject: CFV: Josh Bloch to Membership in the Core Libraries Group In-Reply-To: <10780596.3316.1234467467105.JavaMail.help@alum.mit.edu> References: <10780596.3316.1234467467105.JavaMail.help@alum.mit.edu> Message-ID: <49949F99.2010702@sun.com> Vote: yes From martinrb at google.com Thu Feb 12 23:24:22 2009 From: martinrb at google.com (Martin Buchholz) Date: Thu, 12 Feb 2009 15:24:22 -0800 Subject: CFV: Josh Bloch to Membership in the Core Libraries Group In-Reply-To: <10780596.3316.1234467467105.JavaMail.help@alum.mit.edu> References: <10780596.3316.1234467467105.JavaMail.help@alum.mit.edu> Message-ID: <1ccfd1c10902121524i3c328bfu438677abf858752f@mail.gmail.com> Vote: yes From Xueming.Shen at Sun.COM Thu Feb 12 23:31:28 2009 From: Xueming.Shen at Sun.COM (Xueming Shen) Date: Thu, 12 Feb 2009 15:31:28 -0800 Subject: CFV: Josh Bloch to Membership in the Core Libraries Group In-Reply-To: <10780596.3316.1234467467105.JavaMail.help@alum.mit.edu> References: <10780596.3316.1234467467105.JavaMail.help@alum.mit.edu> Message-ID: <4994B150.9020906@sun.com> Vote: yes From dl at cs.oswego.edu Thu Feb 12 23:41:05 2009 From: dl at cs.oswego.edu (Doug Lea) Date: Thu, 12 Feb 2009 18:41:05 -0500 Subject: CFV: Josh Bloch to Membership in the Core Libraries Group In-Reply-To: <10780596.3316.1234467467105.JavaMail.help@alum.mit.edu> References: <10780596.3316.1234467467105.JavaMail.help@alum.mit.edu> Message-ID: <4994B391.8030308@cs.oswego.edu> Vote: yes -Doug From Joe.Darcy at Sun.COM Thu Feb 12 23:49:07 2009 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Thu, 12 Feb 2009 15:49:07 -0800 Subject: CFV: Josh Bloch to Membership in the Core Libraries Group In-Reply-To: <10780596.3316.1234467467105.JavaMail.help@alum.mit.edu> References: <10780596.3316.1234467467105.JavaMail.help@alum.mit.edu> Message-ID: <4994B573.6070107@sun.com> Vote: yes Iris Clark wrote: > Greetings, voting members of the Core Libraries Group! > > I nominate Josh Bloch to Membership in the Core Libraries Group. > > Please cast your vote by replying, publicly, to this message with > either > > Vote: yes > > or > > Vote: no > > as the first line of the message body. > > You may, at your option, indicate the reason for your decision on > subsequent lines. > > Votes must be cast in the open; votes sent as private replies will > not be counted. > > Votes are due by midnight UTC next Thursday, 19 February, after which > time the votes will be tallied and reported to this list. > > Only Members of the Core Libraries are eligible to vote on this > decision. The current Members are: > > Alan Bateman > Christopher Hegarty > David Bristor > Doug Lea > Iris Clark > Jeff Nisewanger > Joe Darcy > Mark Reinhold > Martin Buchholz > Pete Soper > Peter Jones > Xueming Shen > > Thanks, > iris > core-libs-dev moderator > From Peter.Jones at Sun.COM Fri Feb 13 00:03:46 2009 From: Peter.Jones at Sun.COM (Peter Jones) Date: Thu, 12 Feb 2009 19:03:46 -0500 Subject: CFV: Josh Bloch to Membership in the Core Libraries Group In-Reply-To: <10780596.3316.1234467467105.JavaMail.help@alum.mit.edu> References: <10780596.3316.1234467467105.JavaMail.help@alum.mit.edu> Message-ID: <2712235F-116A-4E0E-B0A8-BAB2150DF08F@sun.com> Vote: yes From maurizio.cimadamore at sun.com Fri Feb 13 12:08:28 2009 From: maurizio.cimadamore at sun.com (maurizio.cimadamore at sun.com) Date: Fri, 13 Feb 2009 12:08:28 +0000 Subject: hg: jdk7/tl/langtools: 6769027: Source line should be displayed immediately after the first diagnostic line Message-ID: <20090213120832.C151FD698@hg.openjdk.java.net> Changeset: 6ada6122dd4f Author: mcimadamore Date: 2009-02-13 11:57 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/6ada6122dd4f 6769027: Source line should be displayed immediately after the first diagnostic line Summary: Added support for customizing diagnostic output via API/command line flags Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/api/DiagnosticFormatter.java ! src/share/classes/com/sun/tools/javac/api/Messages.java ! src/share/classes/com/sun/tools/javac/main/OptionName.java ! src/share/classes/com/sun/tools/javac/main/RecognizedOptions.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/util/AbstractDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javac/util/BasicDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javac/util/LayoutCharacters.java ! src/share/classes/com/sun/tools/javac/util/Log.java ! src/share/classes/com/sun/tools/javac/util/RawDiagnosticFormatter.java ! test/tools/javac/6304921/T6304921.out ! test/tools/javac/6668794/badClass/Test.java ! test/tools/javac/6668794/badSource/Test.out ! test/tools/javac/6758789/T6758789b.out + test/tools/javac/Diagnostics/6769027/T6769027.java + test/tools/javac/Diagnostics/6769027/tester.properties ! test/tools/javac/ExtendArray.out ! test/tools/javac/T5048776b.out ! test/tools/javac/T6214885a.out ! test/tools/javac/T6214885b.out ! test/tools/javac/T6230128.out ! test/tools/javac/annotations/6365854/test1.out ! test/tools/javac/cast/6557182/T6557182.out ! test/tools/javac/cast/6665356/T6665356.out ! test/tools/javac/cast/6795580/T6795580.out ! test/tools/javac/generics/6207386/T6207386.out ! test/tools/javac/generics/inference/6315770/T6315770.out ! test/tools/javac/generics/inference/6718364/T6718364.out ! test/tools/javac/generics/typevars/6680106/T6680106.out ! test/tools/javac/missingSuperRecovery/MissingSuperRecovery.out ! test/tools/javac/unicode/UnicodeNewline.out From Christopher.Hegarty at Sun.COM Fri Feb 13 15:39:16 2009 From: Christopher.Hegarty at Sun.COM (Christopher Hegarty - Sun Microsystems Ireland) Date: Fri, 13 Feb 2009 15:39:16 +0000 Subject: CFV: Josh Bloch to Membership in the Core Libraries Group In-Reply-To: <10780596.3316.1234467467105.JavaMail.help@alum.mit.edu> References: <10780596.3316.1234467467105.JavaMail.help@alum.mit.edu> Message-ID: <49959424.3030102@Sun.COM> Vote: yes From irisg at alum.mit.edu Fri Feb 13 19:11:10 2009 From: irisg at alum.mit.edu (Iris Clark) Date: Fri, 13 Feb 2009 14:11:10 -0500 (EST) Subject: CFV: Josh Bloch to Membership in the Core Libraries Group Message-ID: <22170243.3811.1234552270327.JavaMail.help@alum.mit.edu> Vote: yes From bristor at yahoo.com Fri Feb 13 19:18:44 2009 From: bristor at yahoo.com (Dave Bristor) Date: Fri, 13 Feb 2009 11:18:44 -0800 (PST) Subject: CFV: Josh Bloch to Membership in the Core Libraries Group In-Reply-To: <10780596.3316.1234467467105.JavaMail.help@alum.mit.edu> Message-ID: <928793.92259.qm@web31003.mail.mud.yahoo.com> Vote: yes Dave From martinrb at google.com Mon Feb 16 00:46:35 2009 From: martinrb at google.com (Martin Buchholz) Date: Sun, 15 Feb 2009 16:46:35 -0800 Subject: jtreg throws StackOverflowError when writing xml report In-Reply-To: <49931B19.8060703@redhat.com> References: <49931B19.8060703@redhat.com> Message-ID: <1ccfd1c10902151646y5f857030vd26b7df4753dc47f@mail.gmail.com> There have been recent changes to the UTF_8 encoder in OpenJDK that might be responsible. You can try to isolate the exact change to UTF_8 that could cause this difference, and then create a proper test case. changeset: 497:3dcc69147ff9 user: sherman date: Fri Aug 22 14:37:46 2008 -0700 summary: 4486841: UTF-8 decoder should adhere to corrigendum to Unicode 3.0.1 It is surprising that one can get StackOverflowError without a very long stack trace of methods invoking themselves recursively, which is not what we're seeing. Martin On Wed, Feb 11, 2009 at 10:38, Omair Majid wrote: > Hi all, > > I am trying to generate xml reports from jtreg. The problem is that jtreg > throws a StackOverflowError when writing the output xml file when running > the jdk tests. The xml report works fine for the 16 compiler tests and 1351 > langtools tests. > > I am using Icedtea6 to run the tests. These are the commands it executes: > > $ mkdir -p test/jdk/JTwork test/jdk/JTreport > $ /notnfs/omajid/icedtea6/bootstrap/jdk1.6.0/bin/java \ > -Djavatest.report.kinds="xml text html" \ > -jar test/jtreg.jar -v1 -a -ignore:quiet \ > -w:test/jdk/JTwork -r:test/jdk/JTreport \ > -s -jdk:`pwd`/openjdk/control/build/linux-i586/j2sdk-image \ > `pwd`/openjdk/jdk/test \ > | tee test/check-jdk.log > > The error appears after the jtreg run completes: > > [ lots of output ] > Passed: vm/verifier/VerifyProtectedConstructor.java > Passed: vm/verifier/VerifyStackForExceptionHandlers.java > Test results: passed: 3,306; failed: 73; error: 5 > Exception in thread "main" java.lang.StackOverflowError > at sun.nio.cs.UTF_8.updatePositions(UTF_8.java:76) > at sun.nio.cs.UTF_8$Encoder.encodeArrayLoop(UTF_8.java:411) > at sun.nio.cs.UTF_8$Encoder.encodeLoop(UTF_8.java:466) > at java.nio.charset.CharsetEncoder.encode(CharsetEncoder.java:561) > at java.lang.StringCoding$StringEncoder.encode(StringCoding.java:258) > at java.lang.StringCoding.encode(StringCoding.java:290) > at java.lang.String.getBytes(String.java:954) > at > com.sun.org.apache.xml.internal.serializer.EncodingInfo.inEncoding(EncodingInfo.java:413) > at > com.sun.org.apache.xml.internal.serializer.EncodingInfo.access$100(EncodingInfo.java:62) > at > com.sun.org.apache.xml.internal.serializer.EncodingInfo$EncodingImpl.isInEncoding(EncodingInfo.java:205) > at > com.sun.org.apache.xml.internal.serializer.EncodingInfo$EncodingImpl.isInEncoding(EncodingInfo.java:181) > at > com.sun.org.apache.xml.internal.serializer.EncodingInfo$EncodingImpl.isInEncoding(EncodingInfo.java:181) > [...SNIP...] > at > com.sun.org.apache.xml.internal.serializer.EncodingInfo$EncodingImpl.isInEncoding(EncodingInfo.java:181) > > > Has anyone ever seen this before? > > Thanks, > Omair > > From Jonathan.Gibbons at Sun.COM Mon Feb 16 00:49:39 2009 From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons) Date: Sun, 15 Feb 2009 16:49:39 -0800 Subject: jtreg throws StackOverflowError when writing xml report In-Reply-To: <1ccfd1c10902151646y5f857030vd26b7df4753dc47f@mail.gmail.com> References: <49931B19.8060703@redhat.com> <1ccfd1c10902151646y5f857030vd26b7df4753dc47f@mail.gmail.com> Message-ID: <3654F14A-AC36-4A86-BAE0-0A8E8F85EFF9@sun.com> Martin, Given the [SNIP] in the middle of the trace, I would think we are seeing >> com.sun.org.apache.xml.internal.serializer.EncodingInfo >> $EncodingImpl.isInEncoding(EncodingInfo.java:181) invoking itself recursively. -- Jon On Feb 15, 2009, at 4:46 PM, Martin Buchholz wrote: > There have been recent changes to the > UTF_8 encoder in OpenJDK that might be responsible. > You can try to isolate the exact change to UTF_8 that > could cause this difference, and then create a proper test case. > > changeset: 497:3dcc69147ff9 > user: sherman > date: Fri Aug 22 14:37:46 2008 -0700 > summary: 4486841: UTF-8 decoder should adhere to corrigendum to > Unicode 3.0.1 > > It is surprising that one can get StackOverflowError without > a very long stack trace of methods invoking themselves recursively, > which is not what we're seeing. > > Martin > > On Wed, Feb 11, 2009 at 10:38, Omair Majid wrote: >> Hi all, >> >> I am trying to generate xml reports from jtreg. The problem is that >> jtreg >> throws a StackOverflowError when writing the output xml file when >> running >> the jdk tests. The xml report works fine for the 16 compiler tests >> and 1351 >> langtools tests. >> >> I am using Icedtea6 to run the tests. These are the commands it >> executes: >> >> $ mkdir -p test/jdk/JTwork test/jdk/JTreport >> $ /notnfs/omajid/icedtea6/bootstrap/jdk1.6.0/bin/java \ >> -Djavatest.report.kinds="xml text html" \ >> -jar test/jtreg.jar -v1 -a -ignore:quiet \ >> -w:test/jdk/JTwork -r:test/jdk/JTreport \ >> -s -jdk:`pwd`/openjdk/control/build/linux-i586/j2sdk-image \ >> `pwd`/openjdk/jdk/test \ >> | tee test/check-jdk.log >> >> The error appears after the jtreg run completes: >> >> [ lots of output ] >> Passed: vm/verifier/VerifyProtectedConstructor.java >> Passed: vm/verifier/VerifyStackForExceptionHandlers.java >> Test results: passed: 3,306; failed: 73; error: 5 >> Exception in thread "main" java.lang.StackOverflowError >> at sun.nio.cs.UTF_8.updatePositions(UTF_8.java:76) >> at sun.nio.cs.UTF_8$Encoder.encodeArrayLoop(UTF_8.java:411) >> at sun.nio.cs.UTF_8$Encoder.encodeLoop(UTF_8.java:466) >> at java.nio.charset.CharsetEncoder.encode(CharsetEncoder.java:561) >> at java.lang.StringCoding$StringEncoder.encode(StringCoding.java: >> 258) >> at java.lang.StringCoding.encode(StringCoding.java:290) >> at java.lang.String.getBytes(String.java:954) >> at >> com >> .sun >> .org >> .apache >> .xml.internal.serializer.EncodingInfo.inEncoding(EncodingInfo.java: >> 413) >> at >> com.sun.org.apache.xml.internal.serializer.EncodingInfo.access >> $100(EncodingInfo.java:62) >> at >> com.sun.org.apache.xml.internal.serializer.EncodingInfo >> $EncodingImpl.isInEncoding(EncodingInfo.java:205) >> at >> com.sun.org.apache.xml.internal.serializer.EncodingInfo >> $EncodingImpl.isInEncoding(EncodingInfo.java:181) >> at >> com.sun.org.apache.xml.internal.serializer.EncodingInfo >> $EncodingImpl.isInEncoding(EncodingInfo.java:181) >> [...SNIP...] >> at >> com.sun.org.apache.xml.internal.serializer.EncodingInfo >> $EncodingImpl.isInEncoding(EncodingInfo.java:181) >> >> >> Has anyone ever seen this before? >> >> Thanks, >> Omair >> >> From alan.bateman at sun.com Mon Feb 16 13:07:40 2009 From: alan.bateman at sun.com (alan.bateman at sun.com) Date: Mon, 16 Feb 2009 13:07:40 +0000 Subject: hg: jdk7/tl/jdk: 6781363: New I/O: Update socket-channel API to jsr203/nio2-b99; ... Message-ID: <20090216130815.AAEA7D9DF@hg.openjdk.java.net> Changeset: f06f30b29f36 Author: alanb Date: 2009-02-15 12:25 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f06f30b29f36 6781363: New I/O: Update socket-channel API to jsr203/nio2-b99 4313887: New I/O: Improved filesystem interface 4607272: New I/O: Support asynchronous I/O Reviewed-by: sherman, chegar ! make/docs/CORE_PKGS.gmk ! make/docs/NON_CORE_PKGS.gmk ! make/java/nio/Exportedfiles.gmk ! make/java/nio/FILES_c.gmk ! make/java/nio/FILES_java.gmk ! make/java/nio/Makefile ! make/java/nio/mapfile-linux ! make/java/nio/mapfile-solaris ! make/mksample/nio/Makefile + make/mksample/nio/file/Makefile + src/share/classes/com/sun/nio/file/ExtendedCopyOption.java + src/share/classes/com/sun/nio/file/ExtendedOpenOption.java + src/share/classes/com/sun/nio/file/ExtendedWatchEventModifier.java + src/share/classes/com/sun/nio/file/SensitivityWatchEventModifier.java ! src/share/classes/java/io/File.java ! src/share/classes/java/io/FilePermission.java ! src/share/classes/java/net/StandardProtocolFamily.java ! src/share/classes/java/net/StandardSocketOption.java + src/share/classes/java/nio/channels/AsynchronousByteChannel.java + src/share/classes/java/nio/channels/AsynchronousChannel.java + src/share/classes/java/nio/channels/AsynchronousChannelGroup.java + src/share/classes/java/nio/channels/AsynchronousDatagramChannel.java + src/share/classes/java/nio/channels/AsynchronousFileChannel.java + src/share/classes/java/nio/channels/AsynchronousServerSocketChannel.java + src/share/classes/java/nio/channels/AsynchronousSocketChannel.java ! src/share/classes/java/nio/channels/Channels.java + src/share/classes/java/nio/channels/CompletionHandler.java ! src/share/classes/java/nio/channels/DatagramChannel.java ! src/share/classes/java/nio/channels/FileChannel.java ! src/share/classes/java/nio/channels/FileLock.java ! src/share/classes/java/nio/channels/MembershipKey.java ! src/share/classes/java/nio/channels/MulticastChannel.java ! src/share/classes/java/nio/channels/NetworkChannel.java + src/share/classes/java/nio/channels/SeekableByteChannel.java ! src/share/classes/java/nio/channels/ServerSocketChannel.java ! src/share/classes/java/nio/channels/SocketChannel.java ! src/share/classes/java/nio/channels/exceptions ! src/share/classes/java/nio/channels/package-info.java + src/share/classes/java/nio/channels/spi/AsynchronousChannelProvider.java ! src/share/classes/java/nio/channels/spi/SelectorProvider.java ! src/share/classes/java/nio/channels/spi/package.html + src/share/classes/java/nio/file/AccessDeniedException.java + src/share/classes/java/nio/file/AccessMode.java + src/share/classes/java/nio/file/AtomicMoveNotSupportedException.java + src/share/classes/java/nio/file/ClosedDirectoryStreamException.java + src/share/classes/java/nio/file/ClosedFileSystemException.java + src/share/classes/java/nio/file/ClosedWatchServiceException.java + src/share/classes/java/nio/file/CopyOption.java + src/share/classes/java/nio/file/DirectoryNotEmptyException.java + src/share/classes/java/nio/file/DirectoryStream.java + src/share/classes/java/nio/file/DirectoryStreamFilters.java + src/share/classes/java/nio/file/FileAction.java + src/share/classes/java/nio/file/FileAlreadyExistsException.java + src/share/classes/java/nio/file/FileRef.java + src/share/classes/java/nio/file/FileStore.java + src/share/classes/java/nio/file/FileSystem.java + src/share/classes/java/nio/file/FileSystemAlreadyExistsException.java + src/share/classes/java/nio/file/FileSystemException.java + src/share/classes/java/nio/file/FileSystemNotFoundException.java + src/share/classes/java/nio/file/FileSystems.java + src/share/classes/java/nio/file/FileTreeWalker.java + src/share/classes/java/nio/file/FileVisitOption.java + src/share/classes/java/nio/file/FileVisitResult.java + src/share/classes/java/nio/file/FileVisitor.java + src/share/classes/java/nio/file/Files.java + src/share/classes/java/nio/file/InvalidPathException.java + src/share/classes/java/nio/file/LinkOption.java + src/share/classes/java/nio/file/LinkPermission.java + src/share/classes/java/nio/file/NoSuchFileException.java + src/share/classes/java/nio/file/NotDirectoryException.java + src/share/classes/java/nio/file/NotLinkException.java + src/share/classes/java/nio/file/OpenOption.java + src/share/classes/java/nio/file/Path.java + src/share/classes/java/nio/file/PathMatcher.java + src/share/classes/java/nio/file/Paths.java + src/share/classes/java/nio/file/ProviderMismatchException.java + src/share/classes/java/nio/file/ProviderNotFoundException.java + src/share/classes/java/nio/file/ReadOnlyFileSystemException.java + src/share/classes/java/nio/file/SecureDirectoryStream.java + src/share/classes/java/nio/file/SimpleFileVisitor.java + src/share/classes/java/nio/file/StandardCopyOption.java + src/share/classes/java/nio/file/StandardOpenOption.java + src/share/classes/java/nio/file/StandardWatchEventKind.java + src/share/classes/java/nio/file/WatchEvent.java + src/share/classes/java/nio/file/WatchKey.java + src/share/classes/java/nio/file/WatchService.java + src/share/classes/java/nio/file/Watchable.java + src/share/classes/java/nio/file/attribute/AclEntry.java + src/share/classes/java/nio/file/attribute/AclEntryFlag.java + src/share/classes/java/nio/file/attribute/AclEntryPermission.java + src/share/classes/java/nio/file/attribute/AclEntryType.java + src/share/classes/java/nio/file/attribute/AclFileAttributeView.java + src/share/classes/java/nio/file/attribute/AttributeView.java + src/share/classes/java/nio/file/attribute/Attributes.java + src/share/classes/java/nio/file/attribute/BasicFileAttributeView.java + src/share/classes/java/nio/file/attribute/BasicFileAttributes.java + src/share/classes/java/nio/file/attribute/DosFileAttributeView.java + src/share/classes/java/nio/file/attribute/DosFileAttributes.java + src/share/classes/java/nio/file/attribute/FileAttribute.java + src/share/classes/java/nio/file/attribute/FileAttributeView.java + src/share/classes/java/nio/file/attribute/FileOwnerAttributeView.java + src/share/classes/java/nio/file/attribute/FileStoreAttributeView.java + src/share/classes/java/nio/file/attribute/FileStoreSpaceAttributeView.java + src/share/classes/java/nio/file/attribute/FileStoreSpaceAttributes.java + src/share/classes/java/nio/file/attribute/GroupPrincipal.java + src/share/classes/java/nio/file/attribute/PosixFileAttributeView.java + src/share/classes/java/nio/file/attribute/PosixFileAttributes.java + src/share/classes/java/nio/file/attribute/PosixFilePermission.java + src/share/classes/java/nio/file/attribute/PosixFilePermissions.java + src/share/classes/java/nio/file/attribute/UserDefinedFileAttributeView.java + src/share/classes/java/nio/file/attribute/UserPrincipal.java + src/share/classes/java/nio/file/attribute/UserPrincipalLookupService.java + src/share/classes/java/nio/file/attribute/UserPrincipalNotFoundException.java + src/share/classes/java/nio/file/attribute/package-info.java + src/share/classes/java/nio/file/package-info.java + src/share/classes/java/nio/file/spi/AbstractPath.java + src/share/classes/java/nio/file/spi/FileSystemProvider.java + src/share/classes/java/nio/file/spi/FileTypeDetector.java + src/share/classes/java/nio/file/spi/package-info.java ! src/share/classes/java/util/Scanner.java + src/share/classes/sun/nio/ch/AbstractFuture.java + src/share/classes/sun/nio/ch/AsynchronousChannelGroupImpl.java + src/share/classes/sun/nio/ch/AsynchronousFileChannelImpl.java + src/share/classes/sun/nio/ch/AsynchronousServerSocketChannelImpl.java + src/share/classes/sun/nio/ch/AsynchronousSocketChannelImpl.java + src/share/classes/sun/nio/ch/Cancellable.java + src/share/classes/sun/nio/ch/CompletedFuture.java ! src/share/classes/sun/nio/ch/DatagramChannelImpl.java ! src/share/classes/sun/nio/ch/ExtendedSocketOption.java ! src/share/classes/sun/nio/ch/FileChannelImpl.java + src/share/classes/sun/nio/ch/FileDispatcher.java ! src/share/classes/sun/nio/ch/FileLockImpl.java + src/share/classes/sun/nio/ch/FileLockTable.java + src/share/classes/sun/nio/ch/Groupable.java ! src/share/classes/sun/nio/ch/IOUtil.java + src/share/classes/sun/nio/ch/Invoker.java ! src/share/classes/sun/nio/ch/MembershipKeyImpl.java ! src/share/classes/sun/nio/ch/MembershipRegistry.java ! src/share/classes/sun/nio/ch/NativeThreadSet.java ! src/share/classes/sun/nio/ch/Net.java ! src/share/classes/sun/nio/ch/OptionKey.java + src/share/classes/sun/nio/ch/PendingFuture.java ! src/share/classes/sun/nio/ch/Reflect.java ! src/share/classes/sun/nio/ch/ServerSocketChannelImpl.java + src/share/classes/sun/nio/ch/SimpleAsynchronousDatagramChannelImpl.java + src/share/classes/sun/nio/ch/SimpleAsynchronousFileChannelImpl.java ! src/share/classes/sun/nio/ch/SocketChannelImpl.java + src/share/classes/sun/nio/ch/ThreadPool.java ! src/share/classes/sun/nio/ch/Util.java + src/share/classes/sun/nio/fs/AbstractAclFileAttributeView.java + src/share/classes/sun/nio/fs/AbstractBasicFileAttributeView.java + src/share/classes/sun/nio/fs/AbstractFileStoreSpaceAttributeView.java + src/share/classes/sun/nio/fs/AbstractFileTypeDetector.java + src/share/classes/sun/nio/fs/AbstractPoller.java + src/share/classes/sun/nio/fs/AbstractUserDefinedFileAttributeView.java + src/share/classes/sun/nio/fs/AbstractWatchKey.java + src/share/classes/sun/nio/fs/AbstractWatchService.java + src/share/classes/sun/nio/fs/Cancellable.java + src/share/classes/sun/nio/fs/FileOwnerAttributeViewImpl.java + src/share/classes/sun/nio/fs/Globs.java + src/share/classes/sun/nio/fs/MimeType.java + src/share/classes/sun/nio/fs/NativeBuffer.java + src/share/classes/sun/nio/fs/NativeBuffers.java + src/share/classes/sun/nio/fs/PollingWatchService.java + src/share/classes/sun/nio/fs/Reflect.java ! src/share/classes/sun/security/util/SecurityConstants.java ! src/share/native/sun/nio/ch/genSocketOptionRegistry.c + src/share/sample/nio/file/AclEdit.java + src/share/sample/nio/file/Chmod.java + src/share/sample/nio/file/Copy.java + src/share/sample/nio/file/DiskUsage.java + src/share/sample/nio/file/FileType.java + src/share/sample/nio/file/WatchDir.java + src/share/sample/nio/file/Xdd.java ! src/solaris/classes/sun/nio/ch/DatagramDispatcher.java + src/solaris/classes/sun/nio/ch/DefaultAsynchronousChannelProvider.java ! src/solaris/classes/sun/nio/ch/DevPollArrayWrapper.java ! src/solaris/classes/sun/nio/ch/DevPollSelectorImpl.java + src/solaris/classes/sun/nio/ch/EPoll.java ! src/solaris/classes/sun/nio/ch/EPollArrayWrapper.java + src/solaris/classes/sun/nio/ch/EPollPort.java ! src/solaris/classes/sun/nio/ch/EPollSelectorImpl.java - src/solaris/classes/sun/nio/ch/FileDispatcher.java + src/solaris/classes/sun/nio/ch/FileDispatcherImpl.java + src/solaris/classes/sun/nio/ch/LinuxAsynchronousChannelProvider.java ! src/solaris/classes/sun/nio/ch/PollSelectorImpl.java + src/solaris/classes/sun/nio/ch/Port.java ! src/solaris/classes/sun/nio/ch/SinkChannelImpl.java ! src/solaris/classes/sun/nio/ch/SocketDispatcher.java + src/solaris/classes/sun/nio/ch/SolarisAsynchronousChannelProvider.java + src/solaris/classes/sun/nio/ch/SolarisEventPort.java ! src/solaris/classes/sun/nio/ch/SourceChannelImpl.java + src/solaris/classes/sun/nio/ch/UnixAsynchronousServerSocketChannelImpl.java + src/solaris/classes/sun/nio/ch/UnixAsynchronousSocketChannelImpl.java + src/solaris/classes/sun/nio/fs/DefaultFileSystemProvider.java + src/solaris/classes/sun/nio/fs/DefaultFileTypeDetector.java + src/solaris/classes/sun/nio/fs/GnomeFileTypeDetector.java + src/solaris/classes/sun/nio/fs/LinuxDosFileAttributeView.java + src/solaris/classes/sun/nio/fs/LinuxFileStore.java + src/solaris/classes/sun/nio/fs/LinuxFileSystem.java + src/solaris/classes/sun/nio/fs/LinuxFileSystemProvider.java + src/solaris/classes/sun/nio/fs/LinuxNativeDispatcher.java + src/solaris/classes/sun/nio/fs/LinuxUserDefinedFileAttributeView.java + src/solaris/classes/sun/nio/fs/LinuxWatchService.java + src/solaris/classes/sun/nio/fs/SolarisAclFileAttributeView.java + src/solaris/classes/sun/nio/fs/SolarisFileStore.java + src/solaris/classes/sun/nio/fs/SolarisFileSystem.java + src/solaris/classes/sun/nio/fs/SolarisFileSystemProvider.java + src/solaris/classes/sun/nio/fs/SolarisNativeDispatcher.java + src/solaris/classes/sun/nio/fs/SolarisUserDefinedFileAttributeView.java + src/solaris/classes/sun/nio/fs/SolarisWatchService.java + src/solaris/classes/sun/nio/fs/UnixChannelFactory.java + src/solaris/classes/sun/nio/fs/UnixCopyFile.java + src/solaris/classes/sun/nio/fs/UnixDirectoryStream.java + src/solaris/classes/sun/nio/fs/UnixException.java + src/solaris/classes/sun/nio/fs/UnixFileAttributeViews.java + src/solaris/classes/sun/nio/fs/UnixFileAttributes.java + src/solaris/classes/sun/nio/fs/UnixFileKey.java + src/solaris/classes/sun/nio/fs/UnixFileModeAttribute.java + src/solaris/classes/sun/nio/fs/UnixFileStore.java + src/solaris/classes/sun/nio/fs/UnixFileStoreAttributes.java + src/solaris/classes/sun/nio/fs/UnixFileSystem.java + src/solaris/classes/sun/nio/fs/UnixFileSystemProvider.java + src/solaris/classes/sun/nio/fs/UnixMountEntry.java + src/solaris/classes/sun/nio/fs/UnixNativeDispatcher.java + src/solaris/classes/sun/nio/fs/UnixPath.java + src/solaris/classes/sun/nio/fs/UnixSecureDirectoryStream.java + src/solaris/classes/sun/nio/fs/UnixUriUtils.java + src/solaris/classes/sun/nio/fs/UnixUserPrincipals.java + src/solaris/native/sun/nio/ch/EPoll.c + src/solaris/native/sun/nio/ch/EPollPort.c ! src/solaris/native/sun/nio/ch/FileChannelImpl.c - src/solaris/native/sun/nio/ch/FileDispatcher.c + src/solaris/native/sun/nio/ch/FileDispatcherImpl.c ! src/solaris/native/sun/nio/ch/SocketDispatcher.c + src/solaris/native/sun/nio/ch/SolarisEventPort.c + src/solaris/native/sun/nio/ch/UnixAsynchronousServerSocketChannelImpl.c + src/solaris/native/sun/nio/ch/UnixAsynchronousSocketChannelImpl.c + src/solaris/native/sun/nio/fs/GnomeFileTypeDetector.c + src/solaris/native/sun/nio/fs/LinuxNativeDispatcher.c + src/solaris/native/sun/nio/fs/LinuxWatchService.c + src/solaris/native/sun/nio/fs/SolarisNativeDispatcher.c + src/solaris/native/sun/nio/fs/SolarisWatchService.c + src/solaris/native/sun/nio/fs/UnixCopyFile.c + src/solaris/native/sun/nio/fs/UnixNativeDispatcher.c + src/solaris/native/sun/nio/fs/genSolarisConstants.c + src/solaris/native/sun/nio/fs/genUnixConstants.c + src/windows/classes/sun/nio/ch/DefaultAsynchronousChannelProvider.java - src/windows/classes/sun/nio/ch/FileDispatcher.java + src/windows/classes/sun/nio/ch/FileDispatcherImpl.java + src/windows/classes/sun/nio/ch/Iocp.java + src/windows/classes/sun/nio/ch/PendingIoCache.java + src/windows/classes/sun/nio/ch/WindowsAsynchronousChannelProvider.java + src/windows/classes/sun/nio/ch/WindowsAsynchronousFileChannelImpl.java + src/windows/classes/sun/nio/ch/WindowsAsynchronousServerSocketChannelImpl.java + src/windows/classes/sun/nio/ch/WindowsAsynchronousSocketChannelImpl.java + src/windows/classes/sun/nio/fs/DefaultFileSystemProvider.java + src/windows/classes/sun/nio/fs/DefaultFileTypeDetector.java + src/windows/classes/sun/nio/fs/RegistryFileTypeDetector.java + src/windows/classes/sun/nio/fs/WindowsAclFileAttributeView.java + src/windows/classes/sun/nio/fs/WindowsChannelFactory.java + src/windows/classes/sun/nio/fs/WindowsConstants.java + src/windows/classes/sun/nio/fs/WindowsDirectoryStream.java + src/windows/classes/sun/nio/fs/WindowsException.java + src/windows/classes/sun/nio/fs/WindowsFileAttributeViews.java + src/windows/classes/sun/nio/fs/WindowsFileAttributes.java + src/windows/classes/sun/nio/fs/WindowsFileCopy.java + src/windows/classes/sun/nio/fs/WindowsFileStore.java + src/windows/classes/sun/nio/fs/WindowsFileSystem.java + src/windows/classes/sun/nio/fs/WindowsFileSystemProvider.java + src/windows/classes/sun/nio/fs/WindowsLinkSupport.java + src/windows/classes/sun/nio/fs/WindowsNativeDispatcher.java + src/windows/classes/sun/nio/fs/WindowsPath.java + src/windows/classes/sun/nio/fs/WindowsPathParser.java + src/windows/classes/sun/nio/fs/WindowsPathType.java + src/windows/classes/sun/nio/fs/WindowsSecurity.java + src/windows/classes/sun/nio/fs/WindowsSecurityDescriptor.java + src/windows/classes/sun/nio/fs/WindowsUriSupport.java + src/windows/classes/sun/nio/fs/WindowsUserDefinedFileAttributeView.java + src/windows/classes/sun/nio/fs/WindowsUserPrincipals.java + src/windows/classes/sun/nio/fs/WindowsWatchService.java ! src/windows/native/sun/nio/ch/FileChannelImpl.c - src/windows/native/sun/nio/ch/FileDispatcher.c + src/windows/native/sun/nio/ch/FileDispatcherImpl.c + src/windows/native/sun/nio/ch/Iocp.c + src/windows/native/sun/nio/ch/WindowsAsynchronousFileChannelImpl.c + src/windows/native/sun/nio/ch/WindowsAsynchronousServerSocketChannelImpl.c + src/windows/native/sun/nio/ch/WindowsAsynchronousSocketChannelImpl.c + src/windows/native/sun/nio/fs/RegistryFileTypeDetector.c + src/windows/native/sun/nio/fs/WindowsNativeDispatcher.c + test/java/nio/channels/AsynchronousChannelGroup/AsExecutor.java + test/java/nio/channels/AsynchronousChannelGroup/Attack.java + test/java/nio/channels/AsynchronousChannelGroup/BadProperties.java + test/java/nio/channels/AsynchronousChannelGroup/Basic.java + test/java/nio/channels/AsynchronousChannelGroup/GroupOfOne.java + test/java/nio/channels/AsynchronousChannelGroup/Identity.java + test/java/nio/channels/AsynchronousChannelGroup/PrivilegedThreadFactory.java + test/java/nio/channels/AsynchronousChannelGroup/Restart.java + test/java/nio/channels/AsynchronousChannelGroup/Unbounded.java + test/java/nio/channels/AsynchronousChannelGroup/run_any_task.sh + test/java/nio/channels/AsynchronousDatagramChannel/Basic.java + test/java/nio/channels/AsynchronousFileChannel/Basic.java + test/java/nio/channels/AsynchronousFileChannel/CustomThreadPool.java + test/java/nio/channels/AsynchronousFileChannel/Lock.java + test/java/nio/channels/AsynchronousFileChannel/MyThreadFactory.java + test/java/nio/channels/AsynchronousServerSocketChannel/Basic.java + test/java/nio/channels/AsynchronousServerSocketChannel/WithSecurityManager.java + test/java/nio/channels/AsynchronousServerSocketChannel/java.policy.allow + test/java/nio/channels/AsynchronousServerSocketChannel/java.policy.deny + test/java/nio/channels/AsynchronousSocketChannel/Basic.java + test/java/nio/channels/AsynchronousSocketChannel/Leaky.java + test/java/nio/channels/Channels/Basic2.java ! test/java/nio/channels/DatagramChannel/BasicMulticastTests.java ! test/java/nio/channels/DatagramChannel/SocketOptionTests.java ! test/java/nio/channels/ServerSocketChannel/SocketOptionTests.java ! test/java/nio/channels/SocketChannel/SocketOptionTests.java ! test/java/nio/channels/etc/NetworkChannelTests.java + test/java/nio/channels/spi/AsynchronousChannelProvider/CheckProvider.java + test/java/nio/channels/spi/AsynchronousChannelProvider/META-INF/services/java.nio.channels.spi.AsynchronousChannelProvider + test/java/nio/channels/spi/AsynchronousChannelProvider/Provider1.java + test/java/nio/channels/spi/AsynchronousChannelProvider/Provider2.java + test/java/nio/channels/spi/AsynchronousChannelProvider/custom_provider.sh + test/java/nio/file/DirectoryStream/Basic.java + test/java/nio/file/DirectoryStream/Filters.java + test/java/nio/file/DirectoryStream/SecureDS.java + test/java/nio/file/FileStore/Basic.java + test/java/nio/file/FileSystem/Basic.java + test/java/nio/file/Files/ContentType.java + test/java/nio/file/Files/CreateFileTree.java + test/java/nio/file/Files/ForceLoad.java + test/java/nio/file/Files/META-INF/services/java.nio.file.spi.FileTypeDetector + test/java/nio/file/Files/Misc.java + test/java/nio/file/Files/PrintFileTree.java + test/java/nio/file/Files/SimpleFileTypeDetector.java + test/java/nio/file/Files/SkipSiblings.java + test/java/nio/file/Files/TerminateWalk.java + test/java/nio/file/Files/content_type.sh + test/java/nio/file/Files/walk_file_tree.sh + test/java/nio/file/Path/CopyAndMove.java + test/java/nio/file/Path/DeleteOnClose.java + test/java/nio/file/Path/InterruptCopy.java + test/java/nio/file/Path/Links.java + test/java/nio/file/Path/Misc.java + test/java/nio/file/Path/PathOps.java + test/java/nio/file/Path/SBC.java + test/java/nio/file/Path/TemporaryFiles.java + test/java/nio/file/Path/UriImportExport.java + test/java/nio/file/Path/delete_on_close.sh + test/java/nio/file/Path/temporary_files.sh + test/java/nio/file/PathMatcher/Basic.java + test/java/nio/file/TestUtil.java + test/java/nio/file/WatchService/Basic.java + test/java/nio/file/WatchService/FileTreeModifier.java + test/java/nio/file/WatchService/SensitivityModifier.java + test/java/nio/file/WatchService/WithSecurityManager.java + test/java/nio/file/WatchService/denyAll.policy + test/java/nio/file/WatchService/grantDirAndOneLevel.policy + test/java/nio/file/WatchService/grantDirAndTree.policy + test/java/nio/file/WatchService/grantDirOnly.policy + test/java/nio/file/attribute/AclFileAttributeView/Basic.java + test/java/nio/file/attribute/Attributes/Basic.java + test/java/nio/file/attribute/BasicFileAttributeView/Basic.java + test/java/nio/file/attribute/DosFileAttributeView/Basic.java + test/java/nio/file/attribute/FileStoreAttributeView/Basic.java + test/java/nio/file/attribute/PosixFileAttributeView/Basic.java + test/java/nio/file/attribute/UserDefinedFileAttributeView/Basic.java + test/java/nio/file/spi/SetDefaultProvider.java + test/java/nio/file/spi/TestProvider.java From Ulf.Zibis at gmx.de Mon Feb 16 16:22:17 2009 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Mon, 16 Feb 2009 17:22:17 +0100 Subject: How to get list of classes from a package Message-ID: <499992B9.9090306@gmx.de> Hi all, can anybody tell me, how I could get al list or enumeration of the classes, which belong to a package. I can't see any appropriate method in java.lang.Package :-( Thanks in advance for useful hints, -Ulf From david.lloyd at redhat.com Mon Feb 16 17:12:54 2009 From: david.lloyd at redhat.com (David M. Lloyd) Date: Mon, 16 Feb 2009 11:12:54 -0600 Subject: How to get list of classes from a package In-Reply-To: <499992B9.9090306@gmx.de> References: <499992B9.9090306@gmx.de> Message-ID: <49999E96.1090908@redhat.com> On 02/16/2009 10:22 AM, Ulf Zibis wrote: > Hi all, > > can anybody tell me, how I could get al list or enumeration of the > classes, which belong to a package. > I can't see any appropriate method in java.lang.Package :-( This isn't really possible at run time, since one doesn't know whether a class exists until one tries to load it. The classloader might not even know. Also, a package can span classloaders, adding more complexity to the problem. - DML From christopher.hegarty at sun.com Mon Feb 16 17:23:17 2009 From: christopher.hegarty at sun.com (christopher.hegarty at sun.com) Date: Mon, 16 Feb 2009 17:23:17 +0000 Subject: hg: jdk7/tl/jdk: 6800805: java.net.NetworkInterface.getNetworkInterfaces() does not list IPv6 network interfaces correctly Message-ID: <20090216172341.F2FCBDA03@hg.openjdk.java.net> Changeset: f8a9a7aff362 Author: chegar Date: 2009-02-16 17:19 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f8a9a7aff362 6800805: java.net.NetworkInterface.getNetworkInterfaces() does not list IPv6 network interfaces correctly Reviewed-by: jccollet ! src/solaris/native/java/net/NetworkInterface.c From Thomas.Hawtin at Sun.COM Mon Feb 16 17:29:42 2009 From: Thomas.Hawtin at Sun.COM (Tom Hawtin) Date: Mon, 16 Feb 2009 17:29:42 +0000 Subject: How to get list of classes from a package In-Reply-To: <49999E96.1090908@redhat.com> References: <499992B9.9090306@gmx.de> <49999E96.1090908@redhat.com> Message-ID: <4999A286.9020206@sun.com> David M. Lloyd wrote: > On 02/16/2009 10:22 AM, Ulf Zibis wrote: >> >> can anybody tell me, how I could get al list or enumeration of the >> classes, which belong to a package. >> I can't see any appropriate method in java.lang.Package :-( > > This isn't really possible at run time, since one doesn't know whether a > class exists until one tries to load it. The classloader might not even > know. Also, a package can span classloaders, adding more complexity to > the problem. IIRC, you will get a different Package for each class loader, for a given package name. Certainly classes with the same package name will not have Java access to default/protected members/classes/interface/constructors from different class loaders. But yes, a list of classes is not necessarily complete. Also, IIRC, Proxy dynamically inserts classes into packages as well. Tom Hawtin From forax at univ-mlv.fr Mon Feb 16 20:35:53 2009 From: forax at univ-mlv.fr (=?UTF-8?B?UsOpbWkgRm9yYXg=?=) Date: Mon, 16 Feb 2009 21:35:53 +0100 Subject: How to get list of classes from a package In-Reply-To: <4999A286.9020206@sun.com> References: <499992B9.9090306@gmx.de> <49999E96.1090908@redhat.com> <4999A286.9020206@sun.com> Message-ID: <4999CE29.2090807@univ-mlv.fr> Tom Hawtin a ?crit : > David M. Lloyd wrote: >> On 02/16/2009 10:22 AM, Ulf Zibis wrote: >>> >>> can anybody tell me, how I could get al list or enumeration of the >>> classes, which belong to a package. >>> I can't see any appropriate method in java.lang.Package :-( >> >> This isn't really possible at run time, since one doesn't know >> whether a class exists until one tries to load it. The classloader >> might not even know. Also, a package can span classloaders, adding >> more complexity to the problem. > > IIRC, you will get a different Package for each class loader, for a > given package name. Certainly classes with the same package name will > not have Java access to default/protected > members/classes/interface/constructors from different class loaders. > > But yes, a list of classes is not necessarily complete. Also, IIRC, > Proxy dynamically inserts classes into packages as well. > > Tom Hawtin Ulf, if you can create an agent, you can get all loaded classes: http://download.java.net/jdk7/docs/api/java/lang/instrument/Instrumentation.html#getAllLoadedClasses() But if you want thoses classes to find some that implement an interface, java.util.ServiceLoader is your friend: http://download.java.net/jdk7/docs/api/java/util/ServiceLoader.html cheers, R?mi From Ulf.Zibis at gmx.de Mon Feb 16 21:30:31 2009 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Mon, 16 Feb 2009 22:30:31 +0100 Subject: How to get list of classes from a package In-Reply-To: <4999CE29.2090807@univ-mlv.fr> References: <499992B9.9090306@gmx.de> <49999E96.1090908@redhat.com> <4999A286.9020206@sun.com> <4999CE29.2090807@univ-mlv.fr> Message-ID: <4999DAF7.4060807@gmx.de> Am 16.02.2009 21:35, R?mi Forax schrieb: > Tom Hawtin a ?crit : >> David M. Lloyd wrote: >>> On 02/16/2009 10:22 AM, Ulf Zibis wrote: >>>> >>>> can anybody tell me, how I could get al list or enumeration of the >>>> classes, which belong to a package. >>>> I can't see any appropriate method in java.lang.Package :-( >>> >>> This isn't really possible at run time, since one doesn't know >>> whether a class exists until one tries to load it. The classloader >>> might not even know. Also, a package can span classloaders, adding >>> more complexity to the problem. >> >> IIRC, you will get a different Package for each class loader, for a >> given package name. Certainly classes with the same package name will >> not have Java access to default/protected >> members/classes/interface/constructors from different class loaders. >> >> But yes, a list of classes is not necessarily complete. Also, IIRC, >> Proxy dynamically inserts classes into packages as well. >> >> Tom Hawtin > Ulf, if you can create an agent, you can get all loaded classes: > http://download.java.net/jdk7/docs/api/java/lang/instrument/Instrumentation.html#getAllLoadedClasses() > > > But if you want thoses classes to find some that implement an interface, > java.util.ServiceLoader is your friend: > http://download.java.net/jdk7/docs/api/java/util/ServiceLoader.html > > cheers, > R?mi > Hi David, Tom and R?mi, very much thanks for your hints. They were really valuable. :-) I just finished to code a tricky solution: package sun.nio.cs; import java.io.*; import java.net.*; import java.nio.charset.*; import java.util.*; import java.util.jar.*; /** * * @author Ulf Zibis */ public class LegacyCharsets { private static StandardCharsets standChars = new StandardCharsets(); // Maps lowered canonical names to legacy class names static final Map legacyClassNameMap; static { legacyClassNameMap = new HashMap(256); collectLegacyClassNames("StandardCharsets.class"); collectLegacyClassNames("ext/DelegatableDecoder.class"); } @SuppressWarnings("static-access") private static void collectLegacyClassNames(String searchAnchor) { String[] paths = LegacyCharsets.class.getResource(searchAnchor).getPath().split("!"); paths[1] = paths[1].substring(paths[1].indexOf('/')+1, paths[1].lastIndexOf('/')); try { Enumeration en = new JarFile(new File(new URI(paths[0]))).entries(); while (en.hasMoreElements()) { String name = en.nextElement().getName(); int extPos; if (name.indexOf('$') < 0 && name.startsWith(paths[1]) && (extPos = name.indexOf(".class")) > 0) { Class c = Class.forName(name.substring(0, extPos).replace('/', '.'), true, LegacyCharsets.class.getClassLoader()); if (Charset.class.isAssignableFrom(c)) try { legacyClassNameMap.put(standChars.toLower(((Charset)c.newInstance()).name()), c.getName().substring("sun.nio.cs.".length())); } catch (IllegalAccessException iae) { } catch (InstantiationException ie) {} } } } catch (Exception ex) { System.err.println(ex); } } @SuppressWarnings("static-access") static Charset legacyCharset(String canonicalName) { return standChars.newCharsetForClassName(legacyClassNameMap.get(standChars.toLower(canonicalName))); } } From martinrb at google.com Mon Feb 16 22:08:37 2009 From: martinrb at google.com (Martin Buchholz) Date: Mon, 16 Feb 2009 14:08:37 -0800 Subject: How to get list of classes from a package In-Reply-To: <4999DAF7.4060807@gmx.de> References: <499992B9.9090306@gmx.de> <49999E96.1090908@redhat.com> <4999A286.9020206@sun.com> <4999CE29.2090807@univ-mlv.fr> <4999DAF7.4060807@gmx.de> Message-ID: <1ccfd1c10902161408h7cad1a29x4312f868e29dc442@mail.gmail.com> Ulf, This kind of solution is likely to be brittle. For example, you appear to assume that the code you are looking for is in a jar file. But it might not be; in jdk "developer mode", they are likely to be in a "classes" directory. Martin On Mon, Feb 16, 2009 at 13:30, Ulf Zibis wrote: > Am 16.02.2009 21:35, R?mi Forax schrieb: >> >> Tom Hawtin a ?crit : >>> >>> David M. Lloyd wrote: >>>> >>>> On 02/16/2009 10:22 AM, Ulf Zibis wrote: >>>>> >>>>> can anybody tell me, how I could get al list or enumeration of the >>>>> classes, which belong to a package. >>>>> I can't see any appropriate method in java.lang.Package :-( >>>> >>>> This isn't really possible at run time, since one doesn't know whether a >>>> class exists until one tries to load it. The classloader might not even >>>> know. Also, a package can span classloaders, adding more complexity to the >>>> problem. >>> >>> IIRC, you will get a different Package for each class loader, for a given >>> package name. Certainly classes with the same package name will not have >>> Java access to default/protected members/classes/interface/constructors from >>> different class loaders. >>> >>> But yes, a list of classes is not necessarily complete. Also, IIRC, Proxy >>> dynamically inserts classes into packages as well. >>> >>> Tom Hawtin >> >> Ulf, if you can create an agent, you can get all loaded classes: >> >> http://download.java.net/jdk7/docs/api/java/lang/instrument/Instrumentation.html#getAllLoadedClasses() >> >> But if you want thoses classes to find some that implement an interface, >> java.util.ServiceLoader is your friend: >> http://download.java.net/jdk7/docs/api/java/util/ServiceLoader.html >> >> cheers, >> R?mi >> > > Hi David, Tom and R?mi, > > very much thanks for your hints. They were really valuable. :-) > I just finished to code a tricky solution: > > package sun.nio.cs; > > import java.io.*; > import java.net.*; > import java.nio.charset.*; > import java.util.*; > import java.util.jar.*; > > /** > * > * @author Ulf Zibis > */ > public class LegacyCharsets { > > private static StandardCharsets standChars = new StandardCharsets(); > // Maps lowered canonical names to legacy class names > static final Map legacyClassNameMap; > > static { > legacyClassNameMap = new HashMap(256); > collectLegacyClassNames("StandardCharsets.class"); > collectLegacyClassNames("ext/DelegatableDecoder.class"); > } > > @SuppressWarnings("static-access") > private static void collectLegacyClassNames(String searchAnchor) { > String[] paths = > LegacyCharsets.class.getResource(searchAnchor).getPath().split("!"); > paths[1] = paths[1].substring(paths[1].indexOf('/')+1, > paths[1].lastIndexOf('/')); > try { > Enumeration en = new JarFile(new File(new > URI(paths[0]))).entries(); > while (en.hasMoreElements()) { > String name = en.nextElement().getName(); > int extPos; > if (name.indexOf('$') < 0 && name.startsWith(paths[1]) && > (extPos = name.indexOf(".class")) > 0) { > Class c = Class.forName(name.substring(0, > extPos).replace('/', '.'), > true, LegacyCharsets.class.getClassLoader()); > if (Charset.class.isAssignableFrom(c)) try { > > legacyClassNameMap.put(standChars.toLower(((Charset)c.newInstance()).name()), > > c.getName().substring("sun.nio.cs.".length())); > } catch (IllegalAccessException iae) { > } catch (InstantiationException ie) {} > } > } > } catch (Exception ex) { > System.err.println(ex); > } > } > > @SuppressWarnings("static-access") > static Charset legacyCharset(String canonicalName) { > return > standChars.newCharsetForClassName(legacyClassNameMap.get(standChars.toLower(canonicalName))); > } > } > > > From Ulf.Zibis at gmx.de Mon Feb 16 22:35:37 2009 From: Ulf.Zibis at gmx.de (Ulf Zibis) Date: Mon, 16 Feb 2009 23:35:37 +0100 Subject: How to get list of classes from a package In-Reply-To: <1ccfd1c10902161408h7cad1a29x4312f868e29dc442@mail.gmail.com> References: <499992B9.9090306@gmx.de> <49999E96.1090908@redhat.com> <4999A286.9020206@sun.com> <4999CE29.2090807@univ-mlv.fr> <4999DAF7.4060807@gmx.de> <1ccfd1c10902161408h7cad1a29x4312f868e29dc442@mail.gmail.com> Message-ID: <4999EA39.4020301@gmx.de> Martin, thanks for your additional hints. I'm aware, that my solution is not suitable for general cases, but it solves my needs perfectly. For my enhancement of charsets I need to compare my new coders against the legacy coders from rt.jar + charsets.jar from JDK 6 for testing equality. -Ulf Am 16.02.2009 23:08, Martin Buchholz schrieb: > Ulf, > > This kind of solution is likely to be brittle. > For example, you appear to assume that the code > you are looking for is in a jar file. But it might not be; > in jdk "developer mode", they are likely to be in > a "classes" directory. > > Martin > > On Mon, Feb 16, 2009 at 13:30, Ulf Zibis wrote: > >> Am 16.02.2009 21:35, R?mi Forax schrieb: >> >>> Tom Hawtin a ?crit : >>> >>>> David M. Lloyd wrote: >>>> >>>>> On 02/16/2009 10:22 AM, Ulf Zibis wrote: >>>>> >>>>>> can anybody tell me, how I could get al list or enumeration of the >>>>>> classes, which belong to a package. >>>>>> I can't see any appropriate method in java.lang.Package :-( >>>>>> >>>>> This isn't really possible at run time, since one doesn't know whether a >>>>> class exists until one tries to load it. The classloader might not even >>>>> know. Also, a package can span classloaders, adding more complexity to the >>>>> problem. >>>>> >>>> IIRC, you will get a different Package for each class loader, for a given >>>> package name. Certainly classes with the same package name will not have >>>> Java access to default/protected members/classes/interface/constructors from >>>> different class loaders. >>>> >>>> But yes, a list of classes is not necessarily complete. Also, IIRC, Proxy >>>> dynamically inserts classes into packages as well. >>>> >>>> Tom Hawtin >>>> >>> Ulf, if you can create an agent, you can get all loaded classes: >>> >>> http://download.java.net/jdk7/docs/api/java/lang/instrument/Instrumentation.html#getAllLoadedClasses() >>> >>> But if you want thoses classes to find some that implement an interface, >>> java.util.ServiceLoader is your friend: >>> http://download.java.net/jdk7/docs/api/java/util/ServiceLoader.html >>> >>> cheers, >>> R?mi >>> >>> >> Hi David, Tom and R?mi, >> >> very much thanks for your hints. They were really valuable. :-) >> I just finished to code a tricky solution: >> >> package sun.nio.cs; >> >> import java.io.*; >> import java.net.*; >> import java.nio.charset.*; >> import java.util.*; >> import java.util.jar.*; >> >> /** >> * >> * @author Ulf Zibis >> */ >> public class LegacyCharsets { >> >> private static StandardCharsets standChars = new StandardCharsets(); >> // Maps lowered canonical names to legacy class names >> static final Map legacyClassNameMap; >> >> static { >> legacyClassNameMap = new HashMap(256); >> collectLegacyClassNames("StandardCharsets.class"); >> collectLegacyClassNames("ext/DelegatableDecoder.class"); >> } >> >> @SuppressWarnings("static-access") >> private static void collectLegacyClassNames(String searchAnchor) { >> String[] paths = >> LegacyCharsets.class.getResource(searchAnchor).getPath().split("!"); >> paths[1] = paths[1].substring(paths[1].indexOf('/')+1, >> paths[1].lastIndexOf('/')); >> try { >> Enumeration en = new JarFile(new File(new >> URI(paths[0]))).entries(); >> while (en.hasMoreElements()) { >> String name = en.nextElement().getName(); >> int extPos; >> if (name.indexOf('$') < 0 && name.startsWith(paths[1]) && >> (extPos = name.indexOf(".class")) > 0) { >> Class c = Class.forName(name.substring(0, >> extPos).replace('/', '.'), >> true, LegacyCharsets.class.getClassLoader()); >> if (Charset.class.isAssignableFrom(c)) try { >> >> legacyClassNameMap.put(standChars.toLower(((Charset)c.newInstance()).name()), >> >> c.getName().substring("sun.nio.cs.".length())); >> } catch (IllegalAccessException iae) { >> } catch (InstantiationException ie) {} >> } >> } >> } catch (Exception ex) { >> System.err.println(ex); >> } >> } >> >> @SuppressWarnings("static-access") >> static Charset legacyCharset(String canonicalName) { >> return >> standChars.newCharsetForClassName(legacyClassNameMap.get(standChars.toLower(canonicalName))); >> } >> } >> >> >> >> > > > From Xiaobin.Lu at Sun.COM Mon Feb 16 22:33:42 2009 From: Xiaobin.Lu at Sun.COM (Xiaobin Lu) Date: Mon, 16 Feb 2009 14:33:42 -0800 Subject: review request for 6622432 Message-ID: <4999E9C6.9000004@Sun.COM> Webrev: http://webrev.invokedynamic.info/xiaobin.lu/6622432/ 6622432: RFE: Performance improvements to java.math.BigDecimal Details: This work is targeted to improve the performance of BigDecimal and related classes. Along with the performance improvement, the implementation of many methods has been simplified or complicated for reasons described below. Before delving into details of the webrev, here is the summary of the improvement, for derby benchmark inside SPECjvm2008, we saw about 84.65% improvement measured on a 2 socket 2.8GHz, 12G RAM Nehalem machine. Similarly, we saw about 6.57% improvement on SPECjbb2005. The usage of BigDecimal is quite different for derby and SPECjbb2005, the former benchmark emphasizes more on inflated cases and the later is mostly using small numbers (i.e. non-inflated case), so we are trying our best to take care of both in the whole optimization, as a result, the optimization putting in the webrev is made as general as possible. The change is quite significant and I can only try to highlight some general ideas of the optimization. First is some background of the current implementation of BigDecimal. Among all the fields of BigDecimal classes, the two most interesting fields are intCompact which is long type and intVal which is BigInteger type. When the unscaled value of BigDecimal falls into (Long.MIN_VALUE, Long.MAX_VALUE], its intCompact field is set and intVal is set to null most of time until it is used to perform operations with another BigInteger. This is a good thing to do since it will reduce the object allocation significantly and make the operation faster since obviously adding two primitive numbers for example just needs one instruction while adding two BigInteger object requires a method call, get the magnitude array out of the object, a for loop and so on. So one of the big idea of optimization made in the webrev is to take a further step from this idea and try to make some of the hot methods aware of the non-inflated and inflated cases. For example, the constructor of BigDecimal(char[] in, int offset, int len), when the number is not inflated, we came up with some code to make the constructor as efficient as possible. Another example is the multiply(BigDecimal multiplicand) method, when one of the objects is not inflated, we came up with a internal multiply method in BigInteger to accept long parameter. The second big change to BigDecimal is its divide method. In the inflated case, the current implementation calls divide method in BigInteger which makes MutableBigInteger objects for both operators, then perform the division. Our change made to divide method directly makes MutableBigInteger object out of the magnitude array of the intVal and calls divide method directly. When we get rid of the middle man, we again can reduce the object allocation significantly when divide is a hot method. The third change to BigDecimal is the improvement of calculating the precision of a given BigDecimal object. The current implementation actually uses a static tens power array for incoming number to compare with. And when the number is inflated, it keeps dividing itself by 1 billion until it becomes very small, every division adds 9 digits to the precision. As you know, the division operation is expensive and the algorithm to compare with the ten's power array can be made more efficiently by correlating the bit length of the number with the index to the array so that the time to compute the precision is O(1) rather than being O(n) (where n is the length of the array). And that is exactly what we are doing in the webrev. First, we get the bit length of the number and then multiply it with log2 (10 base), use the result to index to a dynamically expanded ten's power array so that division operation can be avoided completely. Last but not least, the optimization we've made in layoutChars implementation significantly reduces the array allocation rate by making a thread local StringBuilder object. As a result, the buffer to hold the temporary characters is the same for every thread to call the method. Further using the idea I mentioned, we also make it intCompact aware. When the number is not inflated, we use a thread local character array to hold that number in char(s). This reduces the burden for every method call to allocate that character array. Reviewed by: Verified by: JCK regression tests in JDK workspace Also contributed by: Doug Lea (thanks so much for a lot of tedious code clean up work you've done, and of course, many fantastic ideas. ) Joe Darcy contributed most of the tests Regards, -Xiaobin From Christian.Thalinger at Sun.COM Tue Feb 17 11:15:15 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Tue, 17 Feb 2009 12:15:15 +0100 Subject: review request for 6622432 In-Reply-To: <4999E9C6.9000004@Sun.COM> References: <4999E9C6.9000004@Sun.COM> Message-ID: <1234869315.11228.56.camel@localhost.localdomain> On Mon, 2009-02-16 at 14:33 -0800, Xiaobin Lu wrote: > Webrev: http://webrev.invokedynamic.info/xiaobin.lu/6622432/ > > 6622432: RFE: Performance improvements to java.math.BigDecimal > As you know, the division operation is expensive and the > algorithm to compare with the ten's power array can be made more > efficiently by correlating the bit length of the number with the index > to the array so that the time to compute the precision is O(1) rather > than being O(n) (where n is the length of the array). And that is > exactly what we are doing in the webrev. First, we get the bit length of > the number and then multiply it with log2 (10 base), use the result to > index to a dynamically expanded ten's power array so that division > operation can be avoided completely. Actually I'm not reviewing the webrev but I have some questions. 1. Is bitCount() called often and performance critical? There is a RFE (6378821) to intrinsify it and I am thinking about to implement it. 2. Why is BigInteger using it's own implementation of bit-count (bitCnt()) instead of using Integer.bitCount()? -- Christian From forax at univ-mlv.fr Tue Feb 17 13:20:12 2009 From: forax at univ-mlv.fr (=?UTF-8?B?UsOpbWkgRm9yYXg=?=) Date: Tue, 17 Feb 2009 14:20:12 +0100 Subject: review request for 6622432 In-Reply-To: <1234869315.11228.56.camel@localhost.localdomain> References: <4999E9C6.9000004@Sun.COM> <1234869315.11228.56.camel@localhost.localdomain> Message-ID: <499AB98C.4020604@univ-mlv.fr> Hi Christian, Christian Thalinger a ?crit : > On Mon, 2009-02-16 at 14:33 -0800, Xiaobin Lu wrote: > >> Webrev: http://webrev.invokedynamic.info/xiaobin.lu/6622432/ >> >> 6622432: RFE: Performance improvements to java.math.BigDecimal >> > > > > >> As you know, the division operation is expensive and the >> algorithm to compare with the ten's power array can be made more >> efficiently by correlating the bit length of the number with the index >> to the array so that the time to compute the precision is O(1) rather >> than being O(n) (where n is the length of the array). And that is >> exactly what we are doing in the webrev. First, we get the bit length of >> the number and then multiply it with log2 (10 base), use the result to >> index to a dynamically expanded ten's power array so that division >> operation can be avoided completely. >> > > Actually I'm not reviewing the webrev but I have some questions. > > 1. Is bitCount() called often and performance critical? There is a RFE > (6378821) to intrinsify it and I am thinking about to implement it. > It's not related to BigInteger but the fastest multi-dispatch algorithm that I know relies heavily on bitCount too (on Long.bitCount). So you have my vote :) > 2. Why is BigInteger using it's own implementation of bit-count > (bitCnt()) instead of using Integer.bitCount()? > because Integer.bitCount() was introduced in 1.5 and BigInteger in 1.4. BigInteger was not retrofited. > -- Christian > R?mi From Christian.Thalinger at Sun.COM Tue Feb 17 13:51:53 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Tue, 17 Feb 2009 14:51:53 +0100 Subject: review request for 6622432 In-Reply-To: <499AB98C.4020604@univ-mlv.fr> References: <4999E9C6.9000004@Sun.COM> <1234869315.11228.56.camel@localhost.localdomain> <499AB98C.4020604@univ-mlv.fr> Message-ID: <1234878713.11228.64.camel@localhost.localdomain> On Tue, 2009-02-17 at 14:20 +0100, R?mi Forax wrote: > > 1. Is bitCount() called often and performance critical? There is a RFE > > (6378821) to intrinsify it and I am thinking about to implement it. > > > It's not related to BigInteger but the fastest multi-dispatch algorithm > that I know relies heavily on > bitCount too (on Long.bitCount). > So you have my vote :) Interesting, do you have a pointer to an example algorithm? > > 2. Why is BigInteger using it's own implementation of bit-count > > (bitCnt()) instead of using Integer.bitCount()? > > > because Integer.bitCount() was introduced in 1.5 and BigInteger in 1.4. > BigInteger was not retrofited. Ohh, I missed that. Could someone fix that or should I propose a patch? -- Christian From Christian.Thalinger at Sun.COM Tue Feb 17 14:59:51 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Tue, 17 Feb 2009 15:59:51 +0100 Subject: inefficient Des3DkCrypto/DigestMD5Base.setParityBit() Message-ID: <1234882791.11228.79.camel@localhost.localdomain> Hi! While looking at the bitCount() thing I mentioned in the other thread, I noticed that Des3DkCrypto and DigestMD5Base are using a very inefficient implementation of setParityBit(). The one from DESKeyGenerator is much better and uses Integer.bitCount(), which could benefit from a population-count intrinsic. Should I file a CR or even propose a patch? -- Christian From Alan.Bateman at Sun.COM Tue Feb 17 15:18:55 2009 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Tue, 17 Feb 2009 15:18:55 +0000 Subject: inefficient Des3DkCrypto/DigestMD5Base.setParityBit() In-Reply-To: <1234882791.11228.79.camel@localhost.localdomain> References: <1234882791.11228.79.camel@localhost.localdomain> Message-ID: <499AD55F.6020300@sun.com> Christian Thalinger wrote: > Hi! > > While looking at the bitCount() thing I mentioned in the other thread, I > noticed that Des3DkCrypto and DigestMD5Base are using a very inefficient > implementation of setParityBit(). The one from DESKeyGenerator is much > better and uses Integer.bitCount(), which could benefit from a > population-count intrinsic. > > Should I file a CR or even propose a patch? > > -- Christian > I don't know if the security folks on this mailing list so it might be better to send it to security-dev. -Alan. From Christian.Thalinger at Sun.COM Tue Feb 17 15:25:50 2009 From: Christian.Thalinger at Sun.COM (Christian Thalinger) Date: Tue, 17 Feb 2009 16:25:50 +0100 Subject: inefficient Des3DkCrypto/DigestMD5Base.setParityBit() In-Reply-To: <499AD55F.6020300@sun.com> References: <1234882791.11228.79.camel@localhost.localdomain> <499AD55F.6020300@sun.com> Message-ID: <1234884350.11228.84.camel@localhost.localdomain> On Tue, 2009-02-17 at 15:18 +0000, Alan Bateman wrote: > Christian Thalinger wrote: > > Hi! > > > > While looking at the bitCount() thing I mentioned in the other thread, I > > noticed that Des3DkCrypto and DigestMD5Base are using a very inefficient > > implementation of setParityBit(). The one from DESKeyGenerator is much > > better and uses Integer.bitCount(), which could benefit from a > > population-count intrinsic. > > > > Should I file a CR or even propose a patch? > > > > -- Christian > > > I don't know if the security folks on this mailing list so it might be > better to send it to security-dev. Ohh, good point, thanks. I thought everything related to the core library should be posted here. I will forward it to the security-dev list. -- Christian From Xiaobin.Lu at Sun.COM Tue Feb 17 18:29:43 2009 From: Xiaobin.Lu at Sun.COM (Xiaobin Lu) Date: Tue, 17 Feb 2009 10:29:43 -0800 Subject: review request for 6622432 In-Reply-To: <1234869315.11228.56.camel@localhost.localdomain> References: <4999E9C6.9000004@Sun.COM> <1234869315.11228.56.camel@localhost.localdomain> Message-ID: <499B0217.8080500@Sun.COM> On 02/17/09 03:15, Christian Thalinger wrote: > On Mon, 2009-02-16 at 14:33 -0800, Xiaobin Lu wrote: > >> Webrev: http://webrev.invokedynamic.info/xiaobin.lu/6622432/ >> >> 6622432: RFE: Performance improvements to java.math.BigDecimal >> > > > > >> As you know, the division operation is expensive and the >> algorithm to compare with the ten's power array can be made more >> efficiently by correlating the bit length of the number with the index >> to the array so that the time to compute the precision is O(1) rather >> than being O(n) (where n is the length of the array). And that is >> exactly what we are doing in the webrev. First, we get the bit length of >> the number and then multiply it with log2 (10 base), use the result to >> index to a dynamically expanded ten's power array so that division >> operation can be avoided completely. >> > > Actually I'm not reviewing the webrev but I have some questions. > > 1. Is bitCount() called often and performance critical? There is a RFE > (6378821) to intrinsify it and I am thinking about to implement it. > No, I don't think it is a hot method in both derby and SPECjbb2005 based on the profiling information from Analyzer. I might be wrong, but you can verify it easily. > 2. Why is BigInteger using it's own implementation of bit-count > (bitCnt()) instead of using Integer.bitCount()? > That is a good catch. I will fix it. -Xiaobin -------------- next part -------------- An HTML attachment was scrubbed... URL: From mr at sun.com Wed Feb 18 04:24:56 2009 From: mr at sun.com (Mark Reinhold) Date: Tue, 17 Feb 2009 20:24:56 -0800 Subject: CFV: Josh Bloch to Membership in the Core Libraries Group In-Reply-To: irisg@alum.mit.edu; Thu, 12 Feb 2009 14:37:47 EST; <10780596.3316.1234467467105.javamail.help@alum.mit.edu Message-ID: <20090218042456.A7488CFD3@callebaut.niobe.net> Vote: yes From bhavesh.patel at sun.com Wed Feb 18 21:52:53 2009 From: bhavesh.patel at sun.com (bhavesh.patel at sun.com) Date: Wed, 18 Feb 2009 21:52:53 +0000 Subject: hg: jdk7/tl/langtools: 6802694: Javadoc doclet does not display deprecated information with -nocomment option for serialized form Message-ID: <20090218215259.D0CF0DB3A@hg.openjdk.java.net> Changeset: d424ed561993 Author: bpatel Date: 2009-02-18 13:47 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/d424ed561993 6802694: Javadoc doclet does not display deprecated information with -nocomment option for serialized form Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlSerialFieldWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/TagletOutputImpl.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/SerializedFormWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/SerializedFormBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclet.xml + test/com/sun/javadoc/testSerializedFormDeprecationInfo/TestSerializedFormDeprecationInfo.java + test/com/sun/javadoc/testSerializedFormDeprecationInfo/pkg1/C1.java + test/com/sun/javadoc/testSerializedFormDeprecationInfo/pkg1/C2.java + test/com/sun/javadoc/testSerializedFormDeprecationInfo/pkg1/C3.java From i30817 at gmail.com Thu Feb 19 01:57:23 2009 From: i30817 at gmail.com (Paulo Levi) Date: Thu, 19 Feb 2009 01:57:23 +0000 Subject: Just saw that socket is not closeable. Message-ID: <212322090902181757w1e273e02o3ab2e96a0bb2e78e@mail.gmail.com> I mean really! Why not? Its the exact same signature. Please include this at least in jdk 1.6. It almost seems that people appreciate using try{}catch()finally{try{}catch()}. I am tempted to blaspheme but will restrain myself. From neal at gafter.com Thu Feb 19 02:33:41 2009 From: neal at gafter.com (Neal Gafter) Date: Wed, 18 Feb 2009 18:33:41 -0800 Subject: Just saw that socket is not closeable. In-Reply-To: <212322090902181757w1e273e02o3ab2e96a0bb2e78e@mail.gmail.com> References: <212322090902181757w1e273e02o3ab2e96a0bb2e78e@mail.gmail.com> Message-ID: <15e8b9d20902181833t416d093se2e3967f0df1011b@mail.gmail.com> It is too late to change the specification for JDK6, but the change has already been made in openjdk7. On Wed, Feb 18, 2009 at 5:57 PM, Paulo Levi wrote: > I mean really! Why not? Its the exact same signature. Please include > this at least in jdk 1.6. > It almost seems that people appreciate using > try{}catch()finally{try{}catch()}. > > I am tempted to blaspheme but will restrain myself. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From i30817 at gmail.com Thu Feb 19 02:41:57 2009 From: i30817 at gmail.com (Paulo Levi) Date: Thu, 19 Feb 2009 02:41:57 +0000 Subject: Just saw that socket is not closeable. In-Reply-To: <15e8b9d20902181833t416d093se2e3967f0df1011b@mail.gmail.com> References: <212322090902181757w1e273e02o3ab2e96a0bb2e78e@mail.gmail.com> <15e8b9d20902181833t416d093se2e3967f0df1011b@mail.gmail.com> Message-ID: <212322090902181841g68732cc3j448f6e60a245fcb7@mail.gmail.com> Fortunately there is always overloading. From xuelei.fan at sun.com Fri Feb 20 04:59:40 2009 From: xuelei.fan at sun.com (xuelei.fan at sun.com) Date: Fri, 20 Feb 2009 04:59:40 +0000 Subject: hg: jdk7/tl/jdk: 4918870: Examine session cache implementation (sun.misc.Cache) Message-ID: <20090220050015.726B0DC37@hg.openjdk.java.net> Changeset: a144afafb6fe Author: xuelei Date: 2009-02-20 12:50 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/a144afafb6fe 4918870: Examine session cache implementation (sun.misc.Cache) Summary: replace sun.misc.Cache with sun.security.util.Cache Reviewed-by: weijun ! src/share/classes/sun/security/ssl/SSLSessionContextImpl.java ! src/share/classes/sun/security/util/Cache.java From xuelei.fan at sun.com Fri Feb 20 05:14:30 2009 From: xuelei.fan at sun.com (xuelei.fan at sun.com) Date: Fri, 20 Feb 2009 05:14:30 +0000 Subject: hg: jdk7/tl/jdk: 6697270: Inputstream dosent behave correct Message-ID: <20090220051504.13A42DC3E@hg.openjdk.java.net> Changeset: 6bdbb2f5c763 Author: xuelei Date: 2009-02-20 13:05 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/6bdbb2f5c763 6697270: Inputstream dosent behave correct Summary: do not try to read zero byte from a InputStream, and do always return immediately for zero byte reading in a InputStream implementation. Reviewed-by: weijun ! src/share/classes/sun/security/ssl/AppInputStream.java ! src/share/classes/sun/security/ssl/AppOutputStream.java ! src/share/classes/sun/security/ssl/ByteBufferInputStream.java + test/sun/security/ssl/com/sun/net/ssl/internal/ssl/AppInputStream/ReadZeroBytes.java From irisg at alum.mit.edu Fri Feb 20 19:31:20 2009 From: irisg at alum.mit.edu (Iris Clark) Date: Fri, 20 Feb 2009 14:31:20 -0500 (EST) Subject: CFV: Josh Bloch to Membership in the Core Libraries Group Message-ID: <23579734.1113.1235158280668.JavaMail.help@alum.mit.edu> The CVF for Josh Bloch's membership[1] has now closed, and the results have been tallied. Valid votes were received from the following Members of the Core Libraries Group: Alan Bateman vote: yes Christopher Hegarty vote: yes David Bristor vote: yes Doug Lea vote: yes Iris Clark vote: yes Joe Darcy vote: yes Mark Reinhold vote: yes Martin Buchholz vote: yes Peter Jones vote: yes Xueming Shen vote: yes According to the rules describing group expansion[2], this is sufficient to approve the proposal for Josh Bloch to become a Member of the Core Libraries Group. Congratulations and Welcome Josh! iris core-libs-dev moderator [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2009-February/001083.html [2] http://openjdk.java.net/groups/ From joe.darcy at sun.com Fri Feb 20 20:02:02 2009 From: joe.darcy at sun.com (joe.darcy at sun.com) Date: Fri, 20 Feb 2009 20:02:02 +0000 Subject: hg: jdk7/tl/langtools: 6460529: Provide mixin interfaces for getQualifiedName and getTypeParameters Message-ID: <20090220200206.60A85DC76@hg.openjdk.java.net> Changeset: dab918a1c907 Author: darcy Date: 2009-02-20 11:56 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/dab918a1c907 6460529: Provide mixin interfaces for getQualifiedName and getTypeParameters Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/processing/PrintingProcessor.java ! src/share/classes/javax/lang/model/element/ExecutableElement.java ! src/share/classes/javax/lang/model/element/PackageElement.java + src/share/classes/javax/lang/model/element/Parameterizable.java + src/share/classes/javax/lang/model/element/QualifiedNameable.java ! src/share/classes/javax/lang/model/element/TypeElement.java From Christopher.Hegarty at Sun.COM Fri Feb 20 21:46:19 2009 From: Christopher.Hegarty at Sun.COM (Christopher Hegarty - Sun Microsystems Ireland) Date: Fri, 20 Feb 2009 21:46:19 +0000 Subject: Request for review: 6806649 Message-ID: <499F24AB.1040803@sun.com> 6806649: synchronization bottleneck when constructing Thread subclasses Webrev: http://cr.openjdk.java.net/~chegar/6806649/webrev.00/webrev/ The global synchronization on Thread.subclassAudits at Thread construction time has been discussed as a bottleneck: http://cs.oswego.edu/pipermail/concurrency-interest/2009-February/005839.html The implementation approach for this cache of subclass audits matches the once-similar implementations in ObjectInputStream and ObjectOutputStream, but since the 5056445 fix in JDKs 5.0u7 and 6, those classes were changed to use a ConcurrentHashMap (with weakly referenced Class keys) instead-- Thread should probably be changed similarly. Thanks, -Chris. From David.Holmes at Sun.COM Fri Feb 20 22:16:08 2009 From: David.Holmes at Sun.COM (David Holmes - Sun Microsystems) Date: Sat, 21 Feb 2009 08:16:08 +1000 Subject: Request for review: 6806649 In-Reply-To: <499F24AB.1040803@sun.com> References: <499F24AB.1040803@sun.com> Message-ID: <499F2BA8.9060307@sun.com> Chris, Looks good to me. David Holmes Christopher Hegarty - Sun Microsystems Ireland said the following on 02/21/09 07:46: > 6806649: synchronization bottleneck when constructing Thread subclasses > > Webrev: > http://cr.openjdk.java.net/~chegar/6806649/webrev.00/webrev/ > > The global synchronization on Thread.subclassAudits at Thread > construction time has been discussed as a bottleneck: > > http://cs.oswego.edu/pipermail/concurrency-interest/2009-February/005839.html > > > The implementation approach for this cache of subclass audits matches > the once-similar implementations in ObjectInputStream and > ObjectOutputStream, but since the 5056445 fix in JDKs 5.0u7 and 6, those > classes were changed to use a ConcurrentHashMap (with weakly referenced > Class keys) instead-- Thread should probably be changed similarly. > > Thanks, > -Chris. From fw at deneb.enyo.de Sat Feb 21 20:20:06 2009 From: fw at deneb.enyo.de (Florian Weimer) Date: Sat, 21 Feb 2009 21:20:06 +0100 Subject: Just saw that socket is not closeable. In-Reply-To: <212322090902181841g68732cc3j448f6e60a245fcb7@mail.gmail.com> (Paulo Levi's message of "Thu, 19 Feb 2009 02:41:57 +0000") References: <212322090902181757w1e273e02o3ab2e96a0bb2e78e@mail.gmail.com> <15e8b9d20902181833t416d093se2e3967f0df1011b@mail.gmail.com> <212322090902181841g68732cc3j448f6e60a245fcb7@mail.gmail.com> Message-ID: <87fxi7o83t.fsf@mid.deneb.enyo.de> * Paulo Levi: > Fortunately there is always overloading. Isn't it overloading which makes this change technically backwards-incompatible? From tim.bell at sun.com Sun Feb 22 21:49:00 2009 From: tim.bell at sun.com (tim.bell at sun.com) Date: Sun, 22 Feb 2009 21:49:00 +0000 Subject: hg: jdk7/tl: 2 new changesets Message-ID: <20090222214901.0EDE2DDEC@hg.openjdk.java.net> Changeset: 4ae9f4bfdb98 Author: xdono Date: 2009-02-12 14:00 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/rev/4ae9f4bfdb98 Added tag jdk7-b47 for changeset d7744e86dedc ! .hgtags Changeset: aee93a8992d2 Author: xdono Date: 2009-02-19 14:07 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/rev/aee93a8992d2 Added tag jdk7-b48 for changeset 4ae9f4bfdb98 ! .hgtags From tim.bell at sun.com Sun Feb 22 21:51:52 2009 From: tim.bell at sun.com (tim.bell at sun.com) Date: Sun, 22 Feb 2009 21:51:52 +0000 Subject: hg: jdk7/tl/corba: 2 new changesets Message-ID: <20090222215153.F2715DDF1@hg.openjdk.java.net> Changeset: 0be222241fd4 Author: xdono Date: 2009-02-12 14:00 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/0be222241fd4 Added tag jdk7-b47 for changeset 167ad0164301 ! .hgtags Changeset: d70978bc64bc Author: xdono Date: 2009-02-19 14:07 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/d70978bc64bc Added tag jdk7-b48 for changeset 0be222241fd4 ! .hgtags From tim.bell at sun.com Sun Feb 22 21:56:44 2009 From: tim.bell at sun.com (tim.bell at sun.com) Date: Sun, 22 Feb 2009 21:56:44 +0000 Subject: hg: jdk7/tl/hotspot: 34 new changesets Message-ID: <20090222215748.E3547DDF6@hg.openjdk.java.net> Changeset: 3cd5c5b027b1 Author: trims Date: 2008-12-23 19:28 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/3cd5c5b027b1 6788797: Fork HS14 to HS15 - renumber Major and build numbers of JVM Summary: fork Hotspot 15 - redo verisoning numbers Reviewed-by: jcoomes ! make/hotspot_version Changeset: 6d8fc951eb25 Author: kvn Date: 2008-12-22 15:43 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/6d8fc951eb25 6778657: Casts in SharedRuntime::f2i, f2l, d2i and d2l rely on undefined C++ behaviour Summary: Replaces SharedRuntime::f2i et al with versions that should work Reviewed-by: never Contributed-by: gbenson at redhat.com ! src/share/vm/runtime/sharedRuntime.cpp + test/compiler/6778657/Test.java Changeset: 9656bebe85a7 Author: kvn Date: 2008-12-22 16:53 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/9656bebe85a7 6778662: fixes 64-bits libraries directory search paths on linux Summary: Fixes 64-bits libraries directory search paths. Reviewed-by: never Contributed-by: langel at redhat.com ! src/os/linux/vm/os_linux.cpp Changeset: 1a767c61ad01 Author: never Date: 2009-01-06 16:10 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/1a767c61ad01 Merge Changeset: dabd8d202164 Author: coleenp Date: 2008-12-23 06:16 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/dabd8d202164 4997835: RFE: crash dump will only be created when running w/ -XX:+ShowMessageBoxOnError Summary: Using UseOSErrorReporting will provide both an hs_err file and a crash dump or debug launch and works better. Reviewed-by: xlu, acorn, poonam ! src/share/vm/utilities/vmError.cpp Changeset: db4caa99ef11 Author: xlu Date: 2008-12-24 13:06 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/db4caa99ef11 6787106: Hotspot 32 bit build fails on platforms having different definitions for intptr_t & int32_t Summary: Avoid casting between int32_t and intptr_t specifically for MasmAssembler::movptr in 32 bit platforms. Reviewed-by: jrose, kvn ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/c1_Runtime1_x86.cpp ! src/cpu/x86/vm/interp_masm_x86_32.cpp ! src/cpu/x86/vm/interp_masm_x86_32.hpp ! src/cpu/x86/vm/interpreterRT_x86_32.cpp ! src/cpu/x86/vm/runtime_x86_32.cpp ! src/cpu/x86/vm/sharedRuntime_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/x86_32.ad ! src/share/vm/utilities/globalDefinitions_gcc.hpp ! src/share/vm/utilities/globalDefinitions_sparcWorks.hpp Changeset: 2328d1d3f8cf Author: xlu Date: 2008-12-24 19:13 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/2328d1d3f8cf 6781583: Hotspot build fails on linux 64 bit platform with gcc 4.3.2 Summary: Fixed the wrong cast between types since more restrictions are imposed by gcc 4.3.2 Reviewed-by: jcoomes, acorn, phh, never ! src/cpu/sparc/vm/jni_sparc.h ! src/cpu/x86/vm/jni_x86.h ! src/os/linux/vm/os_linux.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/libadt/port.hpp ! src/share/vm/oops/constantPoolOop.cpp ! src/share/vm/oops/oopsHierarchy.hpp ! src/share/vm/opto/idealGraphPrinter.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/memprofiler.cpp ! src/share/vm/runtime/safepoint.cpp ! src/share/vm/runtime/synchronizer.cpp ! src/share/vm/utilities/globalDefinitions.hpp ! src/share/vm/utilities/ostream.cpp ! src/share/vm/utilities/vmError.hpp Changeset: c81d2ef51ca3 Author: acorn Date: 2009-01-05 13:44 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/c81d2ef51ca3 4670071: loadClassInternal is too restrictive. Summary: VM support for deadlock fix. Library fix in 4735126. See API proposal. Reviewed-by: dholmes, blacklion ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/runtime/globals.hpp Changeset: a0401dc51d0b Author: acorn Date: 2009-01-08 16:27 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/a0401dc51d0b 6791656: nsk defclass0 asserts handles.hpp Reviewed-by: phh, xlu ! src/share/vm/classfile/systemDictionary.cpp Changeset: fc7ab6287598 Author: coleenp Date: 2009-01-09 14:39 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/fc7ab6287598 Merge ! src/os/linux/vm/os_linux.cpp ! src/share/vm/oops/constantPoolOop.cpp Changeset: e9be0e04635a Author: jmasa Date: 2009-01-06 07:05 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/e9be0e04635a 6689653: JMapPerm fails with UseConcMarkSweepIncGC and compressed oops off Summary: Added safe_object_iterate() for use by JMapPerm. Reviewed-by: tonyp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.hpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/genCollectedHeap.hpp ! src/share/vm/memory/generation.cpp ! src/share/vm/memory/generation.hpp ! src/share/vm/memory/heapInspection.cpp ! src/share/vm/memory/space.cpp ! src/share/vm/memory/space.hpp ! src/share/vm/prims/jvmtiTagMap.cpp ! src/share/vm/services/heapDumper.cpp Changeset: 0af8b0718fc9 Author: jmasa Date: 2009-01-11 16:58 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/0af8b0718fc9 6692899: CMS: many vm.parallel_class_loading tests fail with assert "missing Printezis mark" Summary: The CMS concurrent precleaning and concurrent marking phases should work around classes that are undergoing redefinition. Reviewed-by: ysr, dcubed ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/memory/oopFactory.cpp ! src/share/vm/memory/oopFactory.hpp ! src/share/vm/memory/space.cpp ! src/share/vm/oops/constMethodKlass.cpp ! src/share/vm/oops/constMethodKlass.hpp ! src/share/vm/oops/constMethodOop.hpp ! src/share/vm/oops/constantPoolKlass.cpp ! src/share/vm/oops/constantPoolKlass.hpp ! src/share/vm/oops/constantPoolOop.hpp ! src/share/vm/oops/klass.hpp ! src/share/vm/oops/methodOop.cpp ! src/share/vm/oops/methodOop.hpp ! src/share/vm/oops/oop.hpp ! src/share/vm/oops/oop.inline.hpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp Changeset: 65de26b5ea82 Author: jcoomes Date: 2009-01-14 14:12 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/65de26b5ea82 Merge ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp Changeset: 52a431267315 Author: coleenp Date: 2009-01-13 14:41 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/52a431267315 6791168: Fix invalid code in bytecodeInterpreter that can cause gcc ICE Summary: Fix compilation errors from latest gcc in CC_INTERP including offending missing void* cast. Reviewed-by: xlu ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/bytecodeInterpreter_x86.inline.hpp ! src/cpu/x86/vm/cppInterpreter_x86.cpp ! src/cpu/x86/vm/frame_x86.inline.hpp ! src/cpu/x86/vm/interp_masm_x86_64.cpp ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp ! src/share/vm/interpreter/bytecodeInterpreter.cpp ! src/share/vm/interpreter/bytecodeInterpreter.hpp Changeset: 4db4e58c16bd Author: xlu Date: 2009-01-13 12:08 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/4db4e58c16bd 6791815: Fix for 6471657 can cause deadlock on non-Solaris platforms when initializing direct buffer support Summary: Place the state transition inside the loop so that the VMThread could proceed for safepoint Reviewed-by: dholmes, never, acorn ! src/share/vm/prims/jni.cpp Changeset: 9250583801d2 Author: xlu Date: 2009-01-13 12:14 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/9250583801d2 Merge Changeset: 2ddbaf7b8e1c Author: xlu Date: 2009-01-13 14:49 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/2ddbaf7b8e1c Merge Changeset: c9004fe53695 Author: xlu Date: 2009-01-13 17:39 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/c9004fe53695 6792301: StackAlignmentInBytes not honored for compiled native methods Summary: Fixed the stack misalignment when generate_native_wrapper is called. Reviewed-by: never, kamg, kvn, phh ! src/cpu/x86/vm/sharedRuntime_x86_32.cpp ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp Changeset: f6c0827e5919 Author: coleenp Date: 2009-01-15 12:44 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/f6c0827e5919 Merge Changeset: 818efdefcc99 Author: tonyp Date: 2009-01-16 13:02 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/818efdefcc99 6484956: G1: improve evacuation pause efficiency Summary: A bunch of performance optimizations to decrease GC pause times in G1. Reviewed-by: apetrusenko, jmasa, iveresov ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.inline.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1OopClosures.hpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp ! src/share/vm/gc_implementation/g1/g1_specialized_oop_closures.hpp ! src/share/vm/gc_implementation/includeDB_gc_g1 ! src/share/vm/gc_implementation/includeDB_gc_shared Changeset: 2b1de1db9a9d Author: jcoomes Date: 2009-01-21 13:40 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/2b1de1db9a9d Merge Changeset: 37b3ca071522 Author: coleenp Date: 2009-01-14 20:14 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/37b3ca071522 6793825: Missing include dependancies for GCC without predefined headers Summary: With predefined headers off for gcc, some .inline.hpp files aren't included to make definition visible for inline functions Reviewed-by: jcoomes, xlu ! src/share/vm/gc_implementation/includeDB_gc_concurrentMarkSweep ! src/share/vm/gc_implementation/includeDB_gc_g1 ! src/share/vm/gc_implementation/includeDB_gc_parNew ! src/share/vm/gc_implementation/includeDB_gc_parallelScavenge ! src/share/vm/includeDB_compiler2 ! src/share/vm/includeDB_core ! src/share/vm/includeDB_features Changeset: 8db2b3e46c38 Author: swamyv Date: 2009-01-14 19:45 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/8db2b3e46c38 6786948: SA on core file fails on solaris-amd64 if vm started with -XX:+StartAttachListener Reviewed-by: jjh, dcubed ! agent/src/os/linux/ps_core.c ! agent/src/os/solaris/proc/saproc.cpp Changeset: fc14734c5aec Author: swamyv Date: 2009-01-15 13:30 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/fc14734c5aec Merge Changeset: 40ee984935b9 Author: phh Date: 2009-01-21 11:14 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/40ee984935b9 6792705: Add JAR file to bootclasspath when using AggressiveOpts Summary: During argument processing, add alt-rt.jar to the bootclasspath between bootclasspath/p and default elements. Reviewed-by: xlu, coleenp ! src/share/vm/runtime/arguments.cpp Changeset: 99c597293e35 Author: coleenp Date: 2009-01-23 10:41 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/99c597293e35 Merge ! src/share/vm/gc_implementation/includeDB_gc_g1 Changeset: dc3ad84615cf Author: xlu Date: 2009-01-26 12:07 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/dc3ad84615cf 6795913: A few remaining wrong casts need to be fixed for building hotspot successfully on Mac OS. Summary: Use NULL_WORD in the places where intptr_t is expected due to incompatible types between intptr_t & int32_t Reviewed-by: phh, coleenp, never ! src/cpu/x86/vm/c1_Runtime1_x86.cpp ! src/cpu/x86/vm/interp_masm_x86_32.cpp ! src/cpu/x86/vm/interpreterRT_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp Changeset: 5cfd8d19e546 Author: ysr Date: 2009-01-26 12:47 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/5cfd8d19e546 6786503: Overflow list performance can be improved Summary: Avoid overflow list walk in CMS & ParNew when it is unnecessary. Fix a couple of correctness issues, including a C-heap leak, in ParNew at the intersection of promotion failure, work queue overflow and object array chunking. Add stress testing option and related assertion checking. Reviewed-by: jmasa ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp ! src/share/vm/gc_implementation/includeDB_gc_parNew ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.hpp ! src/share/vm/memory/referenceProcessor.cpp ! src/share/vm/runtime/globals.hpp Changeset: 4e400c36026f Author: iveresov Date: 2009-01-27 18:13 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/4e400c36026f 6783381: NUMA allocator: don't pretouch eden space with UseNUMA Summary: Moved pretouching to MutableSpace. Also MutableSpace now turns on page interleaving for the region it covers. Reviewed-by: jmasa, jcoomes ! src/share/vm/gc_implementation/parallelScavenge/psOldGen.cpp ! src/share/vm/gc_implementation/parallelScavenge/psVirtualspace.cpp ! src/share/vm/gc_implementation/parallelScavenge/psVirtualspace.hpp ! src/share/vm/gc_implementation/parallelScavenge/psYoungGen.cpp ! src/share/vm/gc_implementation/shared/mutableNUMASpace.cpp ! src/share/vm/gc_implementation/shared/mutableNUMASpace.hpp ! src/share/vm/gc_implementation/shared/mutableSpace.cpp ! src/share/vm/gc_implementation/shared/mutableSpace.hpp Changeset: 5b39c489c39d Author: ysr Date: 2009-01-29 21:25 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/5b39c489c39d Merge ! src/share/vm/gc_implementation/includeDB_gc_parNew Changeset: 3f844a28c5f4 Author: trims Date: 2009-01-30 15:28 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/3f844a28c5f4 Merge Changeset: fcb923bad68e Author: trims Date: 2009-02-10 20:33 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/fcb923bad68e Merge Changeset: bcb33806d186 Author: xdono Date: 2009-02-12 14:00 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/bcb33806d186 Added tag jdk7-b47 for changeset fcb923bad68e ! .hgtags Changeset: d61c7c22b25c Author: xdono Date: 2009-02-19 14:08 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/d61c7c22b25c Added tag jdk7-b48 for changeset bcb33806d186 ! .hgtags From tim.bell at sun.com Sun Feb 22 22:02:18 2009 From: tim.bell at sun.com (tim.bell at sun.com) Date: Sun, 22 Feb 2009 22:02:18 +0000 Subject: hg: jdk7/tl/jaxp: 2 new changesets Message-ID: <20090222220221.A9F79DDFB@hg.openjdk.java.net> Changeset: 39de90eb4822 Author: xdono Date: 2009-02-12 14:00 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/39de90eb4822 Added tag jdk7-b47 for changeset d711ad1954b2 ! .hgtags Changeset: 5c1f24531903 Author: xdono Date: 2009-02-19 14:08 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/5c1f24531903 Added tag jdk7-b48 for changeset 39de90eb4822 ! .hgtags From tim.bell at sun.com Sun Feb 22 22:04:59 2009 From: tim.bell at sun.com (tim.bell at sun.com) Date: Sun, 22 Feb 2009 22:04:59 +0000 Subject: hg: jdk7/tl/jaxws: 2 new changesets Message-ID: <20090222220502.1AAB6DE02@hg.openjdk.java.net> Changeset: 01e5dd31d0c1 Author: xdono Date: 2009-02-12 14:00 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/01e5dd31d0c1 Added tag jdk7-b47 for changeset 223011570edb ! .hgtags Changeset: 18ca864890f3 Author: xdono Date: 2009-02-19 14:08 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/18ca864890f3 Added tag jdk7-b48 for changeset 01e5dd31d0c1 ! .hgtags From tim.bell at sun.com Sun Feb 22 22:10:17 2009 From: tim.bell at sun.com (tim.bell at sun.com) Date: Sun, 22 Feb 2009 22:10:17 +0000 Subject: hg: jdk7/tl/jdk: 32 new changesets Message-ID: <20090222221631.5B088DE07@hg.openjdk.java.net> Changeset: 2ab03c2f814b Author: xdono Date: 2009-02-12 14:00 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/2ab03c2f814b Added tag jdk7-b47 for changeset b4ac413b1f12 ! .hgtags Changeset: 14681728d6af Author: tbell Date: 2009-02-17 09:06 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/14681728d6af Merge Changeset: 75755e92430c Author: art Date: 2008-08-26 13:09 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/75755e92430c 6585765: RFE: Remove Unicows-related code from AWT 6733976: VS2008 errors compiling AWT files - explicit casts need to be added 6728735: VS2008 errors compiling UnicowsLoader.h and fatal error in awtmsg.h Summary: Unicows-related and Win95/98/Me-related code is removed Reviewed-by: uta, tdv ! make/sun/awt/FILES_c_windows.gmk ! make/sun/awt/Makefile ! make/sun/awt/make.depend ! make/sun/jawt/make.depend ! make/sun/splashscreen/Makefile ! src/windows/classes/sun/awt/windows/WComponentPeer.java ! src/windows/native/sun/awt/splashscreen/splashscreen_sys.c ! src/windows/native/sun/java2d/d3d/D3DPipelineManager.cpp ! src/windows/native/sun/java2d/d3d/D3DRenderQueue.cpp ! src/windows/native/sun/java2d/d3d/D3DRenderer.cpp ! src/windows/native/sun/java2d/d3d/D3DSurfaceData.cpp ! src/windows/native/sun/java2d/windows/GDIBlitLoops.cpp ! src/windows/native/sun/java2d/windows/GDIRenderer.cpp ! src/windows/native/sun/java2d/windows/GDIWindowSurfaceData.cpp ! src/windows/native/sun/java2d/windows/WindowsFlags.cpp ! src/windows/native/sun/windows/ComCtl32Util.cpp ! src/windows/native/sun/windows/ComCtl32Util.h ! src/windows/native/sun/windows/Devices.cpp ! src/windows/native/sun/windows/Devices.h ! src/windows/native/sun/windows/GDIHashtable.cpp ! src/windows/native/sun/windows/GDIHashtable.h ! src/windows/native/sun/windows/ShellFolder2.cpp - src/windows/native/sun/windows/UnicowsLoader.cpp - src/windows/native/sun/windows/UnicowsLoader.h ! src/windows/native/sun/windows/WPrinterJob.cpp ! src/windows/native/sun/windows/awt.h ! src/windows/native/sun/windows/awt_Button.cpp ! src/windows/native/sun/windows/awt_Checkbox.cpp ! src/windows/native/sun/windows/awt_Choice.cpp ! src/windows/native/sun/windows/awt_Color.cpp ! src/windows/native/sun/windows/awt_Component.cpp ! src/windows/native/sun/windows/awt_Component.h ! src/windows/native/sun/windows/awt_Cursor.cpp ! src/windows/native/sun/windows/awt_Cursor.h ! src/windows/native/sun/windows/awt_DataTransferer.cpp ! src/windows/native/sun/windows/awt_Desktop.cpp ! src/windows/native/sun/windows/awt_DesktopProperties.cpp ! src/windows/native/sun/windows/awt_Dialog.cpp ! src/windows/native/sun/windows/awt_DnDDS.cpp ! src/windows/native/sun/windows/awt_DnDDT.cpp ! src/windows/native/sun/windows/awt_DrawingSurface.cpp ! src/windows/native/sun/windows/awt_FileDialog.cpp ! src/windows/native/sun/windows/awt_FileDialog.h ! src/windows/native/sun/windows/awt_Font.cpp ! src/windows/native/sun/windows/awt_Font.h ! src/windows/native/sun/windows/awt_Frame.cpp ! src/windows/native/sun/windows/awt_InputMethod.cpp ! src/windows/native/sun/windows/awt_InputTextInfor.cpp ! src/windows/native/sun/windows/awt_InputTextInfor.h ! src/windows/native/sun/windows/awt_List.cpp - src/windows/native/sun/windows/awt_MMStub.cpp - src/windows/native/sun/windows/awt_MMStub.h ! src/windows/native/sun/windows/awt_MenuItem.cpp - src/windows/native/sun/windows/awt_Multimon.h ! src/windows/native/sun/windows/awt_Object.cpp ! src/windows/native/sun/windows/awt_Palette.cpp ! src/windows/native/sun/windows/awt_PopupMenu.cpp ! src/windows/native/sun/windows/awt_PrintControl.cpp ! src/windows/native/sun/windows/awt_PrintDialog.cpp ! src/windows/native/sun/windows/awt_PrintJob.cpp ! src/windows/native/sun/windows/awt_Robot.cpp ! src/windows/native/sun/windows/awt_ScrollPane.cpp ! 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_Toolkit.cpp ! src/windows/native/sun/windows/awt_Toolkit.h ! src/windows/native/sun/windows/awt_TrayIcon.cpp ! src/windows/native/sun/windows/awt_TrayIcon.h - src/windows/native/sun/windows/awt_Unicode.cpp - src/windows/native/sun/windows/awt_Unicode.h ! src/windows/native/sun/windows/awt_Win32GraphicsConfig.cpp ! src/windows/native/sun/windows/awt_Win32GraphicsDevice.cpp ! src/windows/native/sun/windows/awt_Win32GraphicsDevice.h ! src/windows/native/sun/windows/awt_Win32GraphicsEnv.cpp ! src/windows/native/sun/windows/awt_Window.cpp - src/windows/native/sun/windows/awt_dlls.cpp - src/windows/native/sun/windows/awt_dlls.h ! src/windows/native/sun/windows/awtmsg.h ! src/windows/native/sun/windows/jawt.cpp Changeset: 95a618c79382 Author: art Date: 2008-08-26 16:31 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/95a618c79382 6741364: Some input method problems after the fix for 6585765 Summary: the fix for 6585765 is corrected Reviewed-by: uta ! src/windows/native/sun/windows/awt_InputTextInfor.cpp ! src/windows/native/sun/windows/awt_InputTextInfor.h Changeset: 39c8e06919a9 Author: art Date: 2008-09-01 17:41 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/39c8e06919a9 6707023: Chenese Characters in JTextPane Cause Pane to Hang Summary: input method events are dispatched to correct AppContext Reviewed-by: naoto, yan ! src/windows/classes/sun/awt/windows/WInputMethod.java Changeset: b942efbc1c72 Author: dav Date: 2008-09-04 17:20 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/b942efbc1c72 6738181: api/java_awt/Toolkit/index.html#GetAWTEventListeners Fails with:empty array returned unexpectedly Summary: redirect getAWTEventListeners(long l) from Headless to underlying toolkit. Reviewed-by: art ! src/share/classes/sun/awt/HeadlessToolkit.java + test/java/awt/Toolkit/Headless/AWTEventListener/AWTListener.java Changeset: f0ce5b54bd90 Author: dav Date: 2008-09-04 17:24 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f0ce5b54bd90 Merge - src/windows/native/sun/windows/UnicowsLoader.cpp - src/windows/native/sun/windows/UnicowsLoader.h - src/windows/native/sun/windows/awt_MMStub.cpp - src/windows/native/sun/windows/awt_MMStub.h - src/windows/native/sun/windows/awt_Multimon.h - src/windows/native/sun/windows/awt_Unicode.cpp - src/windows/native/sun/windows/awt_Unicode.h - src/windows/native/sun/windows/awt_dlls.cpp - src/windows/native/sun/windows/awt_dlls.h Changeset: 31a7769b5fd1 Author: martin Date: 2008-09-08 17:26 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/31a7769b5fd1 6744609: Disable MMX support when building libpng library Summary: Define -DPNG_NO_MMX_CODE unconditionally, not just on 64-bit Linux Reviewed-by: anthony, art ! make/sun/splashscreen/Makefile Changeset: fd13d8cce933 Author: dcherepanov Date: 2008-09-10 15:02 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/fd13d8cce933 6743433: IM candidate window is not shown until window is deactivated and reactivated again Summary: OpenCandidateWindow procedure should directly call ::DefWindowProc Reviewed-by: art ! src/windows/native/sun/windows/awt_Component.cpp Changeset: b0c557c745e8 Author: art Date: 2008-09-11 10:38 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/b0c557c745e8 6727884: Some Uncaught Exceptions are no longer getting sent to the Uncaught Exception Handlers Reviewed-by: anthony, dav ! src/share/classes/java/awt/EventDispatchThread.java + test/java/awt/EventDispatchThread/HandleExceptionOnEDT/HandleExceptionOnEDT.java Changeset: 3b9a288d7ddb Author: dav Date: 2008-09-16 12:17 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/3b9a288d7ddb 6315717: Support for mouse with multiple scroll wheels and 4 or more buttons Summary: implementation of the more mouse buttons support Reviewed-by: art, dcherepanov ! make/sun/xawt/mapfile-vers ! src/share/classes/java/awt/Robot.java ! src/share/classes/java/awt/Toolkit.java ! src/share/classes/java/awt/doc-files/DesktopProperties.html ! src/share/classes/java/awt/event/InputEvent.java ! src/share/classes/java/awt/event/MouseEvent.java ! src/share/classes/java/awt/peer/RobotPeer.java ! src/share/classes/sun/awt/HeadlessToolkit.java ! src/solaris/classes/sun/awt/X11/XBaseWindow.java ! src/solaris/classes/sun/awt/X11/XConstants.java ! src/solaris/classes/sun/awt/X11/XDragSourceContextPeer.java ! src/solaris/classes/sun/awt/X11/XRobotPeer.java ! src/solaris/classes/sun/awt/X11/XToolkit.java ! src/solaris/classes/sun/awt/X11/XWindow.java ! src/solaris/classes/sun/awt/X11/XWindowPeer.java ! src/solaris/native/sun/awt/awt_Robot.c ! src/windows/classes/sun/awt/windows/WRobotPeer.java ! src/windows/classes/sun/awt/windows/WToolkit.java ! src/windows/native/sun/windows/awt_Component.cpp ! src/windows/native/sun/windows/awt_Component.h ! src/windows/native/sun/windows/awt_Robot.cpp ! src/windows/native/sun/windows/awt_Robot.h ! src/windows/native/sun/windows/awt_Toolkit.cpp ! src/windows/native/sun/windows/awt_Toolkit.h ! src/windows/native/sun/windows/awt_TrayIcon.cpp + test/java/awt/Mouse/MouseModifiersUnitTest/ExtraButtonDrag.java + test/java/awt/Mouse/MouseModifiersUnitTest/ModifierPermutation.java + test/java/awt/Mouse/MouseModifiersUnitTest/MouseModifiersUnitTest_Extra.java + test/java/awt/Mouse/MouseModifiersUnitTest/MouseModifiersUnitTest_Standard.java + test/java/awt/Robot/AcceptExtraMouseButtons/AcceptExtraMouseButtons.java + test/java/awt/Robot/ManualInstructions/ManualInstructions.java + test/java/awt/Robot/RobotExtraButton/RobotExtraButton.java + test/java/awt/Toolkit/ToolkitPropertyTest/SystemPropTest_1.java + test/java/awt/Toolkit/ToolkitPropertyTest/SystemPropTest_2.java + test/java/awt/Toolkit/ToolkitPropertyTest/SystemPropTest_3.java + test/java/awt/Toolkit/ToolkitPropertyTest/SystemPropTest_4.java + test/java/awt/Toolkit/ToolkitPropertyTest/SystemPropTest_5.java + test/java/awt/Toolkit/ToolkitPropertyTest/ToolkitPropertyTest_Disable.java + test/java/awt/Toolkit/ToolkitPropertyTest/ToolkitPropertyTest_Enable.java + test/java/awt/event/InputEvent/ButtonArraysEquality/ButtonArraysEquality.java + test/java/awt/event/MouseEvent/AcceptExtraButton/AcceptExtraButton.java + test/java/awt/event/MouseEvent/CTORRestrictions/CTORRestrictions.java + test/java/awt/event/MouseEvent/CTORRestrictions/CTORRestrictions_Disable.java + test/java/awt/event/MouseEvent/CheckGetMaskForButton/CheckGetMaskForButton.java Changeset: 7e0533679ea1 Author: dav Date: 2008-09-29 14:54 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/7e0533679ea1 6746212: Broken MouseEvents for TrayIcon Reviewed-by: dcherepanov, art ! src/windows/native/sun/windows/awt_TrayIcon.cpp Changeset: 672290c883fd Author: rkennke Date: 2008-09-29 20:16 +0200 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/672290c883fd 6749920: Cleanup AWT peer interfaces Summary: Remove duplicate and obsolete methods in the AWT peer interfaces. Reviewed-by: art, dav ! src/share/classes/java/awt/Choice.java ! src/share/classes/java/awt/Component.java ! src/share/classes/java/awt/Container.java ! src/share/classes/java/awt/Dialog.java ! src/share/classes/java/awt/List.java ! src/share/classes/java/awt/MenuItem.java ! src/share/classes/java/awt/TextArea.java ! src/share/classes/java/awt/TextField.java ! src/share/classes/java/awt/peer/ChoicePeer.java ! src/share/classes/java/awt/peer/ComponentPeer.java ! src/share/classes/java/awt/peer/ContainerPeer.java ! src/share/classes/java/awt/peer/ListPeer.java ! src/share/classes/java/awt/peer/MenuItemPeer.java ! src/share/classes/java/awt/peer/TextAreaPeer.java ! src/share/classes/java/awt/peer/TextComponentPeer.java ! src/share/classes/java/awt/peer/TextFieldPeer.java ! src/share/classes/java/awt/peer/WindowPeer.java Changeset: 485e803c2d5a Author: dav Date: 2008-10-03 10:33 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/485e803c2d5a 6755110: Solaris build has corrupted with extra mouse buttons RFE Reviewed-by: yan ! src/solaris/native/sun/awt/awt_Robot.c Changeset: 5482ef16fe78 Author: yan Date: 2008-10-06 16:45 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/5482ef16fe78 5100701: Toolkit.getLockingKeyState() does not work on XToolkit, but works on Motif Summary: Does not work on Motif but works on XToolkit now; implemented using XQueryPointer. Reviewed-by: anthony ! make/sun/xawt/mapfile-vers ! src/solaris/classes/sun/awt/X11/XKeysym.java ! src/solaris/classes/sun/awt/X11/XToolkit.java ! src/solaris/classes/sun/awt/X11/XlibWrapper.java ! src/solaris/classes/sun/awt/X11/keysym2ucs.h ! src/solaris/native/sun/xawt/XlibWrapper.c Changeset: ce224a356eb8 Author: dav Date: 2008-10-07 16:34 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/ce224a356eb8 6750288: Regression after 6315717. ArrayIndexOutOfBoundsException. Reviewed-by: dcherepanov, denis ! src/solaris/classes/sun/awt/X11/XToolkit.java Changeset: 724eb9cbd3bb Author: dav Date: 2008-10-07 16:43 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/724eb9cbd3bb Merge ! src/solaris/classes/sun/awt/X11/XToolkit.java Changeset: aed796ac3788 Author: dav Date: 2008-10-08 12:50 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/aed796ac3788 5076635: Double click speed is not honored in KDE linux Reviewed-by: art, dcherepanov ! src/solaris/classes/sun/awt/X11/XToolkit.java + test/java/awt/Mouse/MaximizedFrameTest/MaximizedFrameTest.html + test/java/awt/Mouse/MaximizedFrameTest/MaximizedFrameTest.java Changeset: 346127532313 Author: dav Date: 2008-10-08 13:01 +0400 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/346127532313 Merge - make/java/nio/spp.sh - make/tools/winver/Makefile - make/tools/winver/bin/winver.exe - make/tools/winver/src/StdAfx.cpp - make/tools/winver/src/StdAfx.h - make/tools/winver/src/winver.cpp - src/share/classes/com/sun/jmx/mbeanserver/OpenConverter.java - src/share/classes/javax/management/ToQueryString.java ! src/solaris/classes/sun/awt/X11/XToolkit.java - src/windows/classes/sun/java2d/d3d/D3DBackBufferSurfaceData.java - src/windows/classes/sun/java2d/windows/DDBlitLoops.java - src/windows/classes/sun/java2d/windows/DDRenderer.java - src/windows/classes/sun/java2d/windows/DDScaleLoops.java - src/windows/classes/sun/java2d/windows/Win32OffScreenSurfaceData.java - src/windows/classes/sun/java2d/windows/Win32SurfaceData.java - src/windows/classes/sun/java2d/windows/Win32SurfaceDataProxy.java - src/windows/classes/sun/java2d/windows/WinBackBuffer.java - src/windows/classes/sun/java2d/windows/WinBackBufferSurfaceData.java - src/windows/classes/sun/java2d/windows/WinVolatileSurfaceManager.java - src/windows/native/sun/java2d/d3d/D3DRuntimeTest.cpp - src/windows/native/sun/java2d/d3d/D3DRuntimeTest.h - src/windows/native/sun/java2d/d3d/D3DTestRaster.h - src/windows/native/sun/java2d/d3d/D3DTextRenderer_md.cpp - src/windows/native/sun/java2d/d3d/D3DUtils.cpp - src/windows/native/sun/java2d/d3d/D3DUtils.h - src/windows/native/sun/java2d/windows/DDBlitLoops.cpp - src/windows/native/sun/java2d/windows/DDRenderer.cpp - src/windows/native/sun/java2d/windows/RegistryKey.cpp - src/windows/native/sun/java2d/windows/RegistryKey.h - src/windows/native/sun/java2d/windows/Win32OffScreenSurfaceData.cpp - src/windows/native/sun/java2d/windows/Win32SurfaceData.cpp - src/windows/native/sun/java2d/windows/Win32SurfaceData.h - src/windows/native/sun/java2d/windows/WinBackBufferSurfaceData.cpp - src/windows/native/sun/java2d/windows/ddrawObject.cpp - src/windows/native/sun/java2d/windows/ddrawObject.h - src/windows/native/sun/java2d/windows/ddrawUtils.cpp - src/windows/native/sun/java2d/windows/ddrawUtils.h - src/windows/native/sun/java2d/windows/dxCapabilities.cpp - src/windows/native/sun/java2d/windows/dxCapabilities.h - src/windows/native/sun/java2d/windows/dxInit.cpp - src/windows/native/sun/java2d/windows/dxInit.h - src/windows/native/sun/windows/UnicowsLoader.cpp - src/windows/native/sun/windows/UnicowsLoader.h - src/windows/native/sun/windows/awt_MMStub.cpp - src/windows/native/sun/windows/awt_MMStub.h - src/windows/native/sun/windows/awt_Multimon.h - src/windows/native/sun/windows/awt_Unicode.cpp - src/windows/native/sun/windows/awt_Unicode.h - src/windows/native/sun/windows/awt_dlls.cpp - src/windows/native/sun/windows/awt_dlls.h Changeset: 0c515369b48b Author: lana Date: 2008-10-20 19:07 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/0c515369b48b Merge - make/ASSEMBLY_EXCEPTION - make/LICENSE - make/README - make/README-builds.html - make/README.html - make/THIRD_PARTY_README ! make/sun/awt/Makefile - make/tools/auto_multi/Makefile - make/tools/src/build/tools/automulti/AutoMulti.java - make/tools/src/build/tools/automulti/README.txt - make/tools/src/build/tools/automulti/TestALFGenerator.java - make/tools/src/build/tools/automulti/TestALFLookAndFeel.java ! src/share/classes/java/awt/EventDispatchThread.java - src/share/classes/java/nio/channels/package.html - src/share/classes/javax/swing/colorchooser/DefaultHSBChooserPanel.java - src/share/classes/javax/swing/colorchooser/DefaultRGBChooserPanel.java - src/share/classes/javax/swing/colorchooser/SyntheticImage.java - src/share/classes/org/jcp/xml/dsig/internal/package.html - src/share/classes/sun/launcher/LauncherHelp.java - src/share/classes/sun/nio/ch/OptionAdaptor.java - src/share/classes/sun/nio/ch/SocketOpts.java - src/share/classes/sun/nio/ch/SocketOptsImpl.java - src/share/classes/sun/nio/ch/exceptions - src/share/javavm/include/opcodes.h - src/share/javavm/include/opcodes.length - src/share/javavm/include/opcodes.list - src/share/javavm/include/opcodes.weight - src/share/javavm/include/opcodes.wide - src/share/javavm/include/sys_api.h - src/share/javavm/include/typedefs.h - src/solaris/javavm/include/typedefs_md.h - src/windows/javavm/include/typedefs_md.h ! src/windows/native/sun/windows/ComCtl32Util.cpp ! src/windows/native/sun/windows/ComCtl32Util.h ! src/windows/native/sun/windows/awt_TextArea.cpp - test/javax/swing/JFileChooser/4252173/bug4252173.java - test/javax/swing/JFileChooser/6524424/bug6524424.html - test/javax/swing/JFileChooser/6524424/bug6524424.java - test/sun/net/www/http/ChunkedInputStream/test.txt - test/tools/launcher/Arrrghs.sh Changeset: 7406833af6e4 Author: art Date: 2008-10-28 17:06 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/7406833af6e4 6758673: WeakReference leak in Window.ownedWindowList Summary: WindowDisposerRecord parent field is correctly initialized Reviewed-by: dav, ant ! src/share/classes/java/awt/Window.java + test/java/awt/Window/OwnedWindowsLeak/OwnedWindowsLeak.java Changeset: 9daa41eca0d9 Author: art Date: 2008-11-26 16:25 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/9daa41eca0d9 6699589: java/awt/EventQueue/PostEventOrderingTest.java fails Reviewed-by: dav, anthony ! src/share/classes/sun/awt/SunToolkit.java Changeset: d5bf2dd61ed5 Author: art Date: 2008-12-19 16:04 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d5bf2dd61ed5 6773985: OutOfMemory (PermGen space) under Linux / Firefox when switching bw. applets Summary: XEmbedClientHelper is uninstalled when its embedded frame is disposed. Reviewed-by: dcherepanov, ant ! src/solaris/classes/sun/awt/X11/XEmbedClientHelper.java ! src/solaris/classes/sun/awt/X11/XEmbeddedFramePeer.java Changeset: 63d087cacbf9 Author: rkennke Date: 2009-01-13 20:04 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/63d087cacbf9 6792515: Specify awt peer's API Summary: Document AWT peer API. Reviewed-by: art, dav ! src/share/classes/java/awt/peer/ButtonPeer.java ! src/share/classes/java/awt/peer/CanvasPeer.java ! src/share/classes/java/awt/peer/CheckboxMenuItemPeer.java ! src/share/classes/java/awt/peer/CheckboxPeer.java ! src/share/classes/java/awt/peer/ChoicePeer.java ! src/share/classes/java/awt/peer/ComponentPeer.java ! src/share/classes/java/awt/peer/ContainerPeer.java ! src/share/classes/java/awt/peer/DesktopPeer.java ! src/share/classes/java/awt/peer/DialogPeer.java ! src/share/classes/java/awt/peer/FileDialogPeer.java ! src/share/classes/java/awt/peer/FontPeer.java ! src/share/classes/java/awt/peer/FramePeer.java ! src/share/classes/java/awt/peer/KeyboardFocusManagerPeer.java ! src/share/classes/java/awt/peer/LabelPeer.java ! src/share/classes/java/awt/peer/ListPeer.java ! src/share/classes/java/awt/peer/MenuBarPeer.java ! src/share/classes/java/awt/peer/MenuComponentPeer.java ! src/share/classes/java/awt/peer/MenuItemPeer.java ! src/share/classes/java/awt/peer/MenuPeer.java ! src/share/classes/java/awt/peer/MouseInfoPeer.java ! src/share/classes/java/awt/peer/PanelPeer.java ! src/share/classes/java/awt/peer/PopupMenuPeer.java ! src/share/classes/java/awt/peer/RobotPeer.java ! src/share/classes/java/awt/peer/ScrollPanePeer.java ! src/share/classes/java/awt/peer/ScrollbarPeer.java ! src/share/classes/java/awt/peer/SystemTrayPeer.java ! src/share/classes/java/awt/peer/TextAreaPeer.java ! src/share/classes/java/awt/peer/TextComponentPeer.java ! src/share/classes/java/awt/peer/TextFieldPeer.java ! src/share/classes/java/awt/peer/TrayIconPeer.java ! src/share/classes/java/awt/peer/WindowPeer.java Changeset: 127e3269ee1f Author: bae Date: 2009-01-20 19:51 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/127e3269ee1f 6551075: screenshot image taken through clipboard on W2K terminal server is shifted Reviewed-by: dav, uta ! src/windows/native/sun/windows/awt_DataTransferer.cpp Changeset: 9fa2e56c8a30 Author: art Date: 2009-01-29 14:58 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/9fa2e56c8a30 6721088: Bad window size calculation after using pack() Reviewed-by: anthony Contributed-by: Omair Majid ! src/solaris/classes/sun/awt/X11/WindowDimensions.java ! src/solaris/classes/sun/awt/X11/XDecoratedPeer.java + test/java/awt/Frame/FrameSize/TestFrameSize.java Changeset: f36e9200cb85 Author: anthony Date: 2009-02-04 11:58 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f36e9200cb85 6797195: Forward-port enhancements for hw/lw mixing from 6u12 to 7 Reviewed-by: art, dcherepanov ! make/sun/awt/Makefile ! make/tools/sharing/classlist.linux ! make/tools/sharing/classlist.solaris ! make/tools/sharing/classlist.windows + src/share/classes/com/sun/awt/AWTUtilities.java ! src/share/classes/java/awt/Component.java ! src/share/classes/java/awt/Container.java ! src/share/classes/javax/swing/JRootPane.java + src/share/classes/sun/awt/AWTAccessor.java ! src/share/classes/sun/awt/SunToolkit.java ! src/share/classes/sun/java2d/pipe/Region.java ! src/solaris/classes/sun/awt/X11/XComponentPeer.java ! src/solaris/native/sun/xawt/XlibWrapper.c ! src/windows/classes/sun/awt/windows/WComponentPeer.java ! src/windows/native/sun/windows/awt_Component.cpp + test/java/awt/Mixing/HWDisappear.java + test/java/awt/Mixing/JButtonInGlassPane.java + test/java/awt/Mixing/LWComboBox.java + test/java/awt/Mixing/MixingOnShrinkingHWButton.java + test/java/awt/Mixing/NonOpaqueInternalFrame.java ! test/java/awt/Mixing/OpaqueTest.java ! test/java/awt/Mixing/OverlappingButtons.java Changeset: 8b96fb2d0c3a Author: lana Date: 2009-02-10 12:26 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/8b96fb2d0c3a Merge ! make/sun/xawt/mapfile-vers ! src/share/classes/java/awt/EventDispatchThread.java - src/windows/native/sun/windows/UnicowsLoader.cpp - src/windows/native/sun/windows/UnicowsLoader.h - src/windows/native/sun/windows/awt_MMStub.cpp - src/windows/native/sun/windows/awt_MMStub.h - src/windows/native/sun/windows/awt_Multimon.h - src/windows/native/sun/windows/awt_Unicode.cpp - src/windows/native/sun/windows/awt_Unicode.h - src/windows/native/sun/windows/awt_dlls.cpp - src/windows/native/sun/windows/awt_dlls.h Changeset: 5fbd9ea7def1 Author: lana Date: 2009-02-18 10:05 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/5fbd9ea7def1 Merge - src/windows/native/sun/windows/UnicowsLoader.cpp - src/windows/native/sun/windows/UnicowsLoader.h - src/windows/native/sun/windows/awt_MMStub.cpp - src/windows/native/sun/windows/awt_MMStub.h - src/windows/native/sun/windows/awt_Multimon.h - src/windows/native/sun/windows/awt_Unicode.cpp - src/windows/native/sun/windows/awt_Unicode.h - src/windows/native/sun/windows/awt_dlls.cpp - src/windows/native/sun/windows/awt_dlls.h Changeset: 8311105ea7a3 Author: xdono Date: 2009-02-19 14:08 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/8311105ea7a3 Added tag jdk7-b48 for changeset 5fbd9ea7def1 ! .hgtags Changeset: 1109646be6f6 Author: tbell Date: 2009-02-19 18:04 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/1109646be6f6 Merge - src/solaris/classes/sun/nio/ch/FileDispatcher.java - src/solaris/native/sun/nio/ch/FileDispatcher.c - src/windows/classes/sun/nio/ch/FileDispatcher.java - src/windows/native/sun/nio/ch/FileDispatcher.c Changeset: 7443278199cb Author: tbell Date: 2009-02-20 10:53 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/7443278199cb Merge From tim.bell at sun.com Sun Feb 22 22:26:30 2009 From: tim.bell at sun.com (tim.bell at sun.com) Date: Sun, 22 Feb 2009 22:26:30 +0000 Subject: hg: jdk7/tl/langtools: 4 new changesets Message-ID: <20090222222636.3FE9CDE0C@hg.openjdk.java.net> Changeset: fedc96614330 Author: xdono Date: 2009-02-12 14:00 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/fedc96614330 Added tag jdk7-b47 for changeset 2b8f6bab2392 ! .hgtags Changeset: c53007f34195 Author: tbell Date: 2009-02-17 09:07 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/c53007f34195 Merge Changeset: f4717c901346 Author: tbell Date: 2009-02-19 18:04 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/f4717c901346 Merge Changeset: c4d3cbe3765a Author: tbell Date: 2009-02-21 09:58 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/c4d3cbe3765a Merge From weijun.wang at sun.com Mon Feb 23 02:10:04 2009 From: weijun.wang at sun.com (weijun.wang at sun.com) Date: Mon, 23 Feb 2009 02:10:04 +0000 Subject: hg: jdk7/tl/jdk: 5 new changesets Message-ID: <20090223021105.E4177DE53@hg.openjdk.java.net> Changeset: 9b1bc2e28518 Author: weijun Date: 2009-02-23 10:03 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/9b1bc2e28518 6535697: keytool can be more flexible on format of PEM-encoded X.509 certificates Reviewed-by: vinnie ! src/share/classes/sun/security/provider/X509Factory.java ! test/java/security/cert/CertificateFactory/BadX509CertData.java + test/java/security/cert/CertificateFactory/openssl/OpenSSLCert.java + test/java/security/cert/CertificateFactory/openssl/open + test/java/security/cert/CertificateFactory/openssl/pem Changeset: 33bc32405045 Author: weijun Date: 2009-02-23 10:04 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/33bc32405045 6789935: cross-realm capath search error Reviewed-by: xuelei ! src/share/classes/sun/security/krb5/Realm.java + test/sun/security/krb5/ParseCAPaths.java + test/sun/security/krb5/krb5-capaths.conf Changeset: ec98d5f9b338 Author: weijun Date: 2009-02-23 10:04 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/ec98d5f9b338 6804045: DerValue does not accept empty OCTET STRING Reviewed-by: xuelei ! src/share/classes/sun/security/util/DerValue.java + test/sun/security/util/DerValue/EmptyValue.java Changeset: 8edcd68fb6ac Author: weijun Date: 2009-02-23 10:05 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/8edcd68fb6ac 6803376: BasicConstraintsExtension does not encode when (ca==false && pathLen<0) Reviewed-by: xuelei ! src/share/classes/sun/security/x509/BasicConstraintsExtension.java + test/sun/security/x509/Extensions/BCNull.java Changeset: 90ab7b4891e3 Author: weijun Date: 2009-02-23 10:05 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/90ab7b4891e3 6780416: New keytool commands/options: -gencert, -printcertreq, -ext Reviewed-by: xuelei, mullan ! src/share/classes/sun/security/tools/KeyTool.java ! src/share/classes/sun/security/util/Resources.java ! src/share/classes/sun/security/x509/AccessDescription.java ! src/share/classes/sun/security/x509/AuthorityInfoAccessExtension.java ! src/share/classes/sun/security/x509/AuthorityKeyIdentifierExtension.java ! src/share/classes/sun/security/x509/CertAndKeyGen.java ! src/share/classes/sun/security/x509/CertificateExtensions.java ! src/share/classes/sun/security/x509/IssuerAlternativeNameExtension.java ! src/share/classes/sun/security/x509/OIDMap.java + src/share/classes/sun/security/x509/SubjectInfoAccessExtension.java ! test/sun/security/tools/keytool/KeyToolTest.java ! test/sun/security/tools/keytool/autotest.sh + test/sun/security/tools/keytool/standard.sh From jjb at google.com Mon Feb 23 07:34:15 2009 From: jjb at google.com (Joshua Bloch) Date: Sun, 22 Feb 2009 23:34:15 -0800 Subject: CFV: Josh Bloch to Membership in the Core Libraries Group In-Reply-To: <23579734.1113.1235158280668.JavaMail.help@alum.mit.edu> References: <23579734.1113.1235158280668.JavaMail.help@alum.mit.edu> Message-ID: <17b2302a0902222334g548dafd1me5d1e0673322cfab@mail.gmail.com> Iris, Thanks! Josh On Fri, Feb 20, 2009 at 11:31 AM, Iris Clark wrote: > The CVF for Josh Bloch's membership[1] has now closed, and the results > have been tallied. > > Valid votes were received from the following Members of the Core > Libraries Group: > > Alan Bateman vote: yes > Christopher Hegarty vote: yes > David Bristor vote: yes > Doug Lea vote: yes > Iris Clark vote: yes > Joe Darcy vote: yes > Mark Reinhold vote: yes > Martin Buchholz vote: yes > Peter Jones vote: yes > Xueming Shen vote: yes > > According to the rules describing group expansion[2], this is > sufficient to approve the proposal for Josh Bloch to become a Member > of the Core Libraries Group. > > Congratulations and Welcome Josh! > > iris > core-libs-dev moderator > > [1] > http://mail.openjdk.java.net/pipermail/core-libs-dev/2009-February/001083.html > [2] http://openjdk.java.net/groups/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From xuelei.fan at sun.com Mon Feb 23 09:42:15 2009 From: xuelei.fan at sun.com (xuelei.fan at sun.com) Date: Mon, 23 Feb 2009 09:42:15 +0000 Subject: hg: jdk7/tl/jdk: 5067458: Loopback SSLSocketImpl createSocket is throwing an exception Message-ID: <20090223094227.B9419DE8A@hg.openjdk.java.net> Changeset: 2a7c1a997102 Author: xuelei Date: 2009-02-23 17:32 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/2a7c1a997102 5067458: Loopback SSLSocketImpl createSocket is throwing an exception Summary: A null hostname should be regarded as a loopback address. Reviewed-by: weijun ! src/share/classes/sun/security/ssl/SSLSocketImpl.java + test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/LoopbackSSLSocket.java From christopher.hegarty at sun.com Mon Feb 23 10:39:42 2009 From: christopher.hegarty at sun.com (christopher.hegarty at sun.com) Date: Mon, 23 Feb 2009 10:39:42 +0000 Subject: hg: jdk7/tl/jdk: 6806649: synchronization bottleneck when constructing Thread subclasses Message-ID: <20090223103954.A79CADE91@hg.openjdk.java.net> Changeset: 0f4497002345 Author: chegar Date: 2009-02-23 10:36 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/0f4497002345 6806649: synchronization bottleneck when constructing Thread subclasses Summary: Replace subclass audits synchronization with ConcurrentHashMap with weakly referenced Class keys Reviewed-by: peterjones, dholmes, martin ! src/share/classes/java/lang/Thread.java From Karen.Kinnear at Sun.COM Mon Feb 23 21:14:11 2009 From: Karen.Kinnear at Sun.COM (Karen Kinnear) Date: Mon, 23 Feb 2009 16:14:11 -0500 Subject: Unicode support in Java JRE on Windows In-Reply-To: References: Message-ID: <49A311A3.1070904@sun.com> Heiko, I'm copying this to the core-libs-dev at openjdk.java.net alias, since I think the APIs you are referring to are more familiar to that team. And I've retitled it "Java JRE" so folks see the bigger picture. hope this helps, Karen Heiko Wagner wrote: > Hi, > > I am currently investigating on a problem of the Java VM on Windows. The VM > is started using the JNI invocation api. This works unless the path contains > non-ansi characters. So I hacked the classpath with addURLToAppClassLoader() > in sun.misc.Launcher. I at least could make a shared JRE installation, > started from a ansi path, find my JARs. Since one of my JARs does use native > code I then got stuck at the System.loadLibrary() call. Hacking the correct > path into the 'usr_paths' field into the ClassLoader did not help, because > the actual Windows API call LoadLibrary() seems to be ansi flavour instead > of wide char api. Would it be possible to make this two enhancements without > hurting the Java VM spec?: > > 1) fill the property java.class.path from the env variable CLASSPATH with a > call to GetEnvironmentVariableW instead of GetEnvironmentVariableA to enable > setting the classpath with unicode characters > > 2) fill the property java.library.path and issue the actual LoadLibrary with > appropriate wide char api > >>From a quick look at the VM source I found out, that most string operations > use the ANSI C string functions. > Maybe it would be possible to use UTF-8 encoding to transfer the path > strings throu the Java VM routines to the final Windows API calls, to avoid > large changes in the code base. > > Regards > Heiko Wagner > From xueming.shen at sun.com Tue Feb 24 05:16:20 2009 From: xueming.shen at sun.com (xueming.shen at sun.com) Date: Tue, 24 Feb 2009 05:16:20 +0000 Subject: hg: jdk7/tl/jdk: 6350801: Add support for named (instead of numbered) capture groups in regular expression; ... Message-ID: <20090224051632.3F13FE019@hg.openjdk.java.net> Changeset: 27e1141d436c Author: sherman Date: 2009-02-23 21:06 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/27e1141d436c 6350801: Add support for named (instead of numbered) capture groups in regular expression 6676425: Opensource unit/regression tests for java.util.regex Summary: Added "named capturing group" into regex. Moved most of reg/unit tests to openjdk. Reviewed-by: alanb, okutsu ! src/share/classes/java/util/regex/Matcher.java ! src/share/classes/java/util/regex/Pattern.java + test/java/util/regex/BMPTestCases.txt + test/java/util/regex/RegExTest.java + test/java/util/regex/SupplementaryTestCases.txt + test/java/util/regex/TestCases.txt From alan.bateman at sun.com Tue Feb 24 14:02:08 2009 From: alan.bateman at sun.com (alan.bateman at sun.com) Date: Tue, 24 Feb 2009 14:02:08 +0000 Subject: hg: jdk7/tl/jdk: 3 new changesets Message-ID: <20090224140250.5D2B3E04F@hg.openjdk.java.net> Changeset: 910f9cceb0f8 Author: alanb Date: 2009-02-24 09:11 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/910f9cceb0f8 6808647: (file) Paths.get("C:").newDirectoryStream() iterates over Path elements with additional slash [win] 6808648: (file) Files.walkFileTree should obtain file attributes during iteration [win] Reviewed-by: sherman ! make/java/nio/FILES_java.gmk ! src/share/classes/java/nio/file/FileTreeWalker.java + src/share/classes/sun/nio/fs/BasicFileAttributesHolder.java ! src/windows/classes/sun/nio/fs/WindowsDirectoryStream.java ! src/windows/classes/sun/nio/fs/WindowsFileAttributes.java ! src/windows/classes/sun/nio/fs/WindowsFileSystem.java ! src/windows/classes/sun/nio/fs/WindowsNativeDispatcher.java ! src/windows/classes/sun/nio/fs/WindowsPath.java ! src/windows/native/sun/nio/fs/WindowsNativeDispatcher.c + test/java/nio/file/DirectoryStream/DriveLetter.java Changeset: c7f39995fcf4 Author: alanb Date: 2009-02-24 11:31 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c7f39995fcf4 6809132: (file) Javadoc style and consistency issues Reviewed-by: vinnie Contributed-by: cquinn at google.com ! src/share/classes/java/nio/file/AccessDeniedException.java ! src/share/classes/java/nio/file/AtomicMoveNotSupportedException.java ! src/share/classes/java/nio/file/DirectoryNotEmptyException.java ! src/share/classes/java/nio/file/DirectoryStream.java ! src/share/classes/java/nio/file/DirectoryStreamFilters.java ! src/share/classes/java/nio/file/FileAction.java ! src/share/classes/java/nio/file/FileAlreadyExistsException.java ! src/share/classes/java/nio/file/FileStore.java ! src/share/classes/java/nio/file/FileSystemAlreadyExistsException.java ! src/share/classes/java/nio/file/FileSystemException.java ! src/share/classes/java/nio/file/FileSystemNotFoundException.java ! src/share/classes/java/nio/file/FileSystems.java ! src/share/classes/java/nio/file/FileVisitor.java ! src/share/classes/java/nio/file/InvalidPathException.java ! src/share/classes/java/nio/file/LinkPermission.java ! src/share/classes/java/nio/file/NoSuchFileException.java ! src/share/classes/java/nio/file/NotDirectoryException.java ! src/share/classes/java/nio/file/NotLinkException.java ! src/share/classes/java/nio/file/Path.java ! src/share/classes/java/nio/file/PathMatcher.java ! src/share/classes/java/nio/file/Paths.java ! src/share/classes/java/nio/file/ProviderMismatchException.java ! src/share/classes/java/nio/file/ProviderNotFoundException.java ! src/share/classes/java/nio/file/SecureDirectoryStream.java ! src/share/classes/java/nio/file/SimpleFileVisitor.java ! src/share/classes/java/nio/file/WatchEvent.java ! src/share/classes/java/nio/file/WatchKey.java ! src/share/classes/java/nio/file/WatchService.java ! src/share/classes/java/nio/file/Watchable.java ! src/share/classes/java/nio/file/attribute/AclEntry.java ! src/share/classes/java/nio/file/attribute/AclFileAttributeView.java ! src/share/classes/java/nio/file/attribute/AttributeView.java ! src/share/classes/java/nio/file/attribute/BasicFileAttributeView.java ! src/share/classes/java/nio/file/attribute/BasicFileAttributes.java ! src/share/classes/java/nio/file/attribute/DosFileAttributeView.java ! src/share/classes/java/nio/file/attribute/DosFileAttributes.java ! src/share/classes/java/nio/file/attribute/FileOwnerAttributeView.java ! src/share/classes/java/nio/file/attribute/PosixFileAttributeView.java ! src/share/classes/java/nio/file/attribute/PosixFileAttributes.java ! src/share/classes/java/nio/file/attribute/PosixFilePermissions.java ! src/share/classes/java/nio/file/attribute/UserPrincipalLookupService.java ! src/share/classes/java/nio/file/attribute/UserPrincipalNotFoundException.java ! src/share/classes/java/nio/file/package-info.java Changeset: abe5e7125bd3 Author: alanb Date: 2009-02-24 11:33 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/abe5e7125bd3 Merge From kevin.walls at sun.com Tue Feb 24 14:27:05 2009 From: kevin.walls at sun.com (kevin.walls at sun.com) Date: Tue, 24 Feb 2009 14:27:05 +0000 Subject: hg: jdk7/tl/jdk: 6599383: Unable to open zip files more than 2GB in size Message-ID: <20090224142722.CF9F0E05C@hg.openjdk.java.net> Changeset: dc237aecf7cf Author: kevinw Date: 2009-02-24 14:22 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/dc237aecf7cf 6599383: Unable to open zip files more than 2GB in size Reviewed-by: alanb ! src/share/native/java/util/zip/zip_util.c ! src/share/native/java/util/zip/zip_util.h + test/java/util/zip/ZipFile/LargeZipFile.java From i30817 at gmail.com Tue Feb 24 19:00:04 2009 From: i30817 at gmail.com (Paulo Levi) Date: Tue, 24 Feb 2009 19:00:04 +0000 Subject: Just saw that socket is not closeable. In-Reply-To: <87fxi7o83t.fsf@mid.deneb.enyo.de> References: <212322090902181757w1e273e02o3ab2e96a0bb2e78e@mail.gmail.com> <15e8b9d20902181833t416d093se2e3967f0df1011b@mail.gmail.com> <212322090902181841g68732cc3j448f6e60a245fcb7@mail.gmail.com> <87fxi7o83t.fsf@mid.deneb.enyo.de> Message-ID: <212322090902241100w1750212eh6d2b2f4f5f12304@mail.gmail.com> I don't think puting extends closeable in the socket class is incompatible... But any way i didn't mean overloading the class function, i meant my own utility function to close closeables in finally clauses. From Alan.Bateman at Sun.COM Tue Feb 24 19:36:56 2009 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Tue, 24 Feb 2009 19:36:56 +0000 Subject: Should Lance be a member of the core libraries group? Message-ID: <49A44C58.7090301@sun.com> Iris, Lance Andersen is the long-time spec lead for JDBC. He's on this mailing list, has push-rights, but isn't formally a member of any group. He was on the original list when the census was initiated last year but he seems to have got lost along the way. He would like to be a member of this group. Can you nominate him and initiate the CFV? Thanks, -Alan. From martinrb at google.com Tue Feb 24 22:06:05 2009 From: martinrb at google.com (martinrb at google.com) Date: Tue, 24 Feb 2009 22:06:05 +0000 Subject: hg: jdk7/tl/jdk: 6803402: Race condition in AbstractQueuedSynchronizer Message-ID: <20090224220625.3FD3EE0BF@hg.openjdk.java.net> Changeset: 266358f13a6f Author: dl Date: 2009-02-24 14:01 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/266358f13a6f 6803402: Race condition in AbstractQueuedSynchronizer Summary: Read fields in reverse initialization order Reviewed-by: martin ! src/share/classes/java/util/concurrent/locks/AbstractQueuedLongSynchronizer.java ! src/share/classes/java/util/concurrent/locks/AbstractQueuedSynchronizer.java From joe.darcy at sun.com Wed Feb 25 01:20:40 2009 From: joe.darcy at sun.com (joe.darcy at sun.com) Date: Wed, 25 Feb 2009 01:20:40 +0000 Subject: hg: jdk7/tl/langtools: 6501749: 6501749 Filer should state connection between created files and root elements Message-ID: <20090225012042.65D7CE0EA@hg.openjdk.java.net> Changeset: 435d5d9bb87d Author: darcy Date: 2009-02-24 17:16 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/435d5d9bb87d 6501749: 6501749 Filer should state connection between created files and root elements Reviewed-by: jjg ! src/share/classes/javax/annotation/processing/Filer.java From joe.darcy at sun.com Wed Feb 25 01:52:23 2009 From: joe.darcy at sun.com (joe.darcy at sun.com) Date: Wed, 25 Feb 2009 01:52:23 +0000 Subject: hg: jdk7/tl/langtools: 6498938: Faulty comparison of TypeMirror objects in getElementsAnnotatedWith implementation Message-ID: <20090225015225.63EB3E0EF@hg.openjdk.java.net> Changeset: 1fbc1cc6e260 Author: darcy Date: 2009-02-24 17:48 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/1fbc1cc6e260 6498938: Faulty comparison of TypeMirror objects in getElementsAnnotatedWith implementation Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/processing/JavacRoundEnvironment.java + test/tools/javac/processing/environment/round/Foo.java ! test/tools/javac/processing/environment/round/TestElementsAnnotatedWith.java From Naoto.Sato at Sun.COM Wed Feb 25 01:54:42 2009 From: Naoto.Sato at Sun.COM (Naoto Sato) Date: Tue, 24 Feb 2009 17:54:42 -0800 Subject: [Fwd: Re: Unicode support in Java JRE on Windows] In-Reply-To: <49A4997E.9030900@sun.com> References: <49A4997E.9030900@sun.com> Message-ID: <49A4A4E2.7010503@Sun.COM> 4519026: (process) Process should support Unicode on Win NT This is a long standing known limitation, which has never been addressed because it would require fairly big effort. Thanks, Naoto > Subject: Re: Unicode support in Java JRE on Windows > Date: Mon, 23 Feb 2009 16:14:11 -0500 > From: Karen Kinnear > To: Heiko Wagner > CC: hotspot-dev at openjdk.java.net, core-libs-dev at openjdk.java.net > References: > > Heiko, > > I'm copying this to the core-libs-dev at openjdk.java.net alias, since > I think the APIs you are referring to are more familiar to that team. > And I've retitled it "Java JRE" so folks see the bigger picture. > > hope this helps, > Karen > > Heiko Wagner wrote: >> Hi, >> >> I am currently investigating on a problem of the Java VM on Windows. >> The VM >> is started using the JNI invocation api. This works unless the path >> contains >> non-ansi characters. So I hacked the classpath with >> addURLToAppClassLoader() >> in sun.misc.Launcher. I at least could make a shared JRE installation, >> started from a ansi path, find my JARs. Since one of my JARs does use >> native >> code I then got stuck at the System.loadLibrary() call. Hacking the >> correct >> path into the 'usr_paths' field into the ClassLoader did not help, >> because >> the actual Windows API call LoadLibrary() seems to be ansi flavour >> instead >> of wide char api. Would it be possible to make this two enhancements >> without >> hurting the Java VM spec?: >> >> 1) fill the property java.class.path from the env variable CLASSPATH >> with a >> call to GetEnvironmentVariableW instead of GetEnvironmentVariableA to >> enable >> setting the classpath with unicode characters >> >> 2) fill the property java.library.path and issue the actual >> LoadLibrary with >> appropriate wide char api >> >>> From a quick look at the VM source I found out, that most string >>> operations >> use the ANSI C string functions. >> Maybe it would be possible to use UTF-8 encoding to transfer the path >> strings throu the Java VM routines to the final Windows API calls, to >> avoid >> large changes in the code base. >> >> Regards >> Heiko Wagner >> > -- Naoto Sato From martinrb at google.com Wed Feb 25 02:22:49 2009 From: martinrb at google.com (Martin Buchholz) Date: Tue, 24 Feb 2009 18:22:49 -0800 Subject: [Fwd: Re: Unicode support in Java JRE on Windows] In-Reply-To: <49A4A4E2.7010503@Sun.COM> References: <49A4997E.9030900@sun.com> <49A4A4E2.7010503@Sun.COM> Message-ID: <1ccfd1c10902241822w39ccced3y62cdd12d89c22516@mail.gmail.com> Part of the history here is that the JDK used to continue supporting windows 98 for many years, longer than Microsoft itself! With that support having been dropped, it is much easier to make changes like this (switch from "A" to "W" interfaces consistently) but it's hard to find the enthusiasm. Fighting with the win32 API is no fun. Many distinct jdk teams own affected interfaces, making a thorough fix organizationally difficult. Martin On Tue, Feb 24, 2009 at 17:54, Naoto Sato wrote: > 4519026: (process) Process should support Unicode on Win NT > > This is a long standing known limitation, which has never been addressed > because it would require fairly big effort. > > Thanks, > Naoto > >> Subject: Re: Unicode support in Java JRE on Windows >> Date: Mon, 23 Feb 2009 16:14:11 -0500 >> From: Karen Kinnear >> To: Heiko Wagner >> CC: hotspot-dev at openjdk.java.net, core-libs-dev at openjdk.java.net >> References: >> >> Heiko, >> >> I'm copying this to the core-libs-dev at openjdk.java.net alias, since >> I think the APIs you are referring to are more familiar to that team. >> And I've retitled it "Java JRE" so folks see the bigger picture. >> >> hope this helps, >> Karen >> >> Heiko Wagner wrote: >>> >>> Hi, >>> >>> I am currently investigating on a problem of the Java VM on Windows. The >>> VM >>> is started using the JNI invocation api. This works unless the path >>> contains >>> non-ansi characters. So I hacked the classpath with >>> addURLToAppClassLoader() >>> in sun.misc.Launcher. I at least could make a shared JRE installation, >>> started from a ansi path, find my JARs. Since one of my JARs does use >>> native >>> code I then got stuck at the System.loadLibrary() call. Hacking the >>> correct >>> path into the 'usr_paths' field into the ClassLoader did not help, >>> because >>> the actual Windows API call LoadLibrary() seems to be ansi flavour >>> instead >>> of wide char api. Would it be possible to make this two enhancements >>> without >>> hurting the Java VM spec?: >>> >>> 1) fill the property java.class.path from the env variable CLASSPATH with >>> a >>> call to GetEnvironmentVariableW instead of GetEnvironmentVariableA to >>> enable >>> setting the classpath with unicode characters >>> >>> 2) fill the property java.library.path and issue the actual LoadLibrary >>> with >>> appropriate wide char api >>> >>>> From a quick look at the VM source I found out, that most string >>>> operations >>> >>> use the ANSI C string functions. >>> Maybe it would be possible to use UTF-8 encoding to transfer the path >>> strings throu the Java VM routines to the final Windows API calls, to >>> avoid >>> large changes in the code base. >>> >>> Regards >>> Heiko Wagner >>> >> > > > -- > Naoto Sato > From heiko.wagner at apis.de Wed Feb 25 11:46:52 2009 From: heiko.wagner at apis.de (Heiko Wagner) Date: Wed, 25 Feb 2009 12:46:52 +0100 Subject: [Fwd: Re: Unicode support in Java JRE on Windows] In-Reply-To: <1ccfd1c10902241822w39ccced3y62cdd12d89c22516@mail.gmail.com> Message-ID: <194C4BEA64A042A08A8CFDF12A2474BC@HeikoXP> Martin, thanks for your explanation. As I am fighting against WIN32 API, for over ten years, I can understand what you are pointing out. I usually also have the bad feeling the WIN32 API wins the fight almost all the time. Despite my great admiration for our fellow japanese friends, who have achieved great zen mastership in painlessly using software that has some issues in a unicode environment, I wonder if there is any way of contributing/suggesting some changes without a bunch of jdk team members getting mad at me? ;-) Regards Heiko -----Original Message----- From: hotspot-dev-bounces at openjdk.java.net [mailto:hotspot-dev-bounces at openjdk.java.net]On Behalf Of Martin Buchholz Sent: Mittwoch, 25. Februar 2009 03:23 To: Naoto Sato Cc: hotspot-dev at openjdk.java.net; Core-Libs-Dev Subject: Re: [Fwd: Re: Unicode support in Java JRE on Windows] Part of the history here is that the JDK used to continue supporting windows 98 for many years, longer than Microsoft itself! With that support having been dropped, it is much easier to make changes like this (switch from "A" to "W" interfaces consistently) but it's hard to find the enthusiasm. Fighting with the win32 API is no fun. Many distinct jdk teams own affected interfaces, making a thorough fix organizationally difficult. Martin On Tue, Feb 24, 2009 at 17:54, Naoto Sato wrote: > 4519026: (process) Process should support Unicode on Win NT > > This is a long standing known limitation, which has never been addressed > because it would require fairly big effort. > > Thanks, > Naoto > >> Subject: Re: Unicode support in Java JRE on Windows >> Date: Mon, 23 Feb 2009 16:14:11 -0500 >> From: Karen Kinnear >> To: Heiko Wagner >> CC: hotspot-dev at openjdk.java.net, core-libs-dev at openjdk.java.net >> References: >> >> Heiko, >> >> I'm copying this to the core-libs-dev at openjdk.java.net alias, since >> I think the APIs you are referring to are more familiar to that team. >> And I've retitled it "Java JRE" so folks see the bigger picture. >> >> hope this helps, >> Karen >> >> Heiko Wagner wrote: >>> >>> Hi, >>> >>> I am currently investigating on a problem of the Java VM on Windows. The >>> VM >>> is started using the JNI invocation api. This works unless the path >>> contains >>> non-ansi characters. So I hacked the classpath with >>> addURLToAppClassLoader() >>> in sun.misc.Launcher. I at least could make a shared JRE installation, >>> started from a ansi path, find my JARs. Since one of my JARs does use >>> native >>> code I then got stuck at the System.loadLibrary() call. Hacking the >>> correct >>> path into the 'usr_paths' field into the ClassLoader did not help, >>> because >>> the actual Windows API call LoadLibrary() seems to be ansi flavour >>> instead >>> of wide char api. Would it be possible to make this two enhancements >>> without >>> hurting the Java VM spec?: >>> >>> 1) fill the property java.class.path from the env variable CLASSPATH with >>> a >>> call to GetEnvironmentVariableW instead of GetEnvironmentVariableA to >>> enable >>> setting the classpath with unicode characters >>> >>> 2) fill the property java.library.path and issue the actual LoadLibrary >>> with >>> appropriate wide char api >>> >>>> From a quick look at the VM source I found out, that most string >>>> operations >>> >>> use the ANSI C string functions. >>> Maybe it would be possible to use UTF-8 encoding to transfer the path >>> strings throu the Java VM routines to the final Windows API calls, to >>> avoid >>> large changes in the code base. >>> >>> Regards >>> Heiko Wagner >>> >> > > > -- > Naoto Sato > From kevin.walls at sun.com Wed Feb 25 14:37:39 2009 From: kevin.walls at sun.com (kevin.walls at sun.com) Date: Wed, 25 Feb 2009 14:37:39 +0000 Subject: hg: jdk7/tl/jdk: 2 new changesets Message-ID: <20090225143807.82326E137@hg.openjdk.java.net> Changeset: f9c187839d72 Author: kevinw Date: 2009-02-24 19:03 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f9c187839d72 6809463: Missing license header in test LargeZipFile.java Reviewed-by: alanb ! test/java/util/zip/ZipFile/LargeZipFile.java Changeset: dde3fe2e8164 Author: kevinw Date: 2009-02-25 14:32 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/dde3fe2e8164 Merge From martinrb at google.com Wed Feb 25 16:05:24 2009 From: martinrb at google.com (Martin Buchholz) Date: Wed, 25 Feb 2009 08:05:24 -0800 Subject: [Fwd: Re: Unicode support in Java JRE on Windows] In-Reply-To: <194C4BEA64A042A08A8CFDF12A2474BC@HeikoXP> References: <1ccfd1c10902241822w39ccced3y62cdd12d89c22516@mail.gmail.com> <194C4BEA64A042A08A8CFDF12A2474BC@HeikoXP> Message-ID: <1ccfd1c10902250805q790ed497o9aece863efcca3c2@mail.gmail.com> On Wed, Feb 25, 2009 at 03:46, Heiko Wagner wrote: > Martin, > > thanks for your explanation. As I am fighting against WIN32 API, for over > ten years, I can understand what you are pointing out. I usually also have > the bad feeling the WIN32 API wins the fight almost all the time. Despite my > great admiration for our fellow japanese friends, who have achieved great > zen mastership in painlessly using software that has some issues in a > unicode environment, I wonder if there is any way of contributing/suggesting > some changes without a bunch of jdk team members getting mad at me? ;-) You can start by fixing the JDK one piece at a time. My personal favorite is command line, both java's own in the launcher, and when starting subprocesses. If you fix ProcessImpl.c to use CreateProcessW, I will be your reviewer. There are already comments there to get you started. /* Java and Windows are both pure Unicode systems at heart. * Windows has both a legacy byte-based API and a 16-bit Unicode * "W" API. The Right Thing here is to call CreateProcessW, since * that will allow all process-related information like command * line arguments to be passed properly to the child. We don't do * that currently, since we would first have to have "W" versions * of JVM_NativePath and perhaps other functions. In the * meantime, we can call CreateProcess with the magic flag * CREATE_UNICODE_ENVIRONMENT, which passes only the environment * in "W" mode. We will fix this later. */ ret = CreateProcess(0, /* executable name */ Apparently, "We" means "you". Martin > Regards > Heiko > > -----Original Message----- > From: hotspot-dev-bounces at openjdk.java.net > [mailto:hotspot-dev-bounces at openjdk.java.net]On Behalf Of Martin > Buchholz > Sent: Mittwoch, 25. Februar 2009 03:23 > To: Naoto Sato > Cc: hotspot-dev at openjdk.java.net; Core-Libs-Dev > Subject: Re: [Fwd: Re: Unicode support in Java JRE on Windows] > > > Part of the history here is that the JDK used to continue supporting > windows 98 for many years, longer than Microsoft itself! > With that support having been dropped, it is much easier to make > changes like this (switch from "A" to "W" interfaces consistently) > but it's hard to find the enthusiasm. ?Fighting with the win32 API is no > fun. > Many distinct jdk teams own affected interfaces, making a thorough > fix organizationally difficult. > > Martin > > On Tue, Feb 24, 2009 at 17:54, Naoto Sato wrote: >> 4519026: (process) Process should support Unicode on Win NT >> >> This is a long standing known limitation, which has never been addressed >> because it would require fairly big effort. >> >> Thanks, >> Naoto >> >>> Subject: Re: Unicode support in Java JRE on Windows >>> Date: Mon, 23 Feb 2009 16:14:11 -0500 >>> From: Karen Kinnear >>> To: Heiko Wagner >>> CC: hotspot-dev at openjdk.java.net, core-libs-dev at openjdk.java.net >>> References: >>> >>> Heiko, >>> >>> I'm copying this to the core-libs-dev at openjdk.java.net alias, since >>> I think the APIs you are referring to are more familiar to that team. >>> And I've retitled it "Java JRE" so folks see the bigger picture. >>> >>> hope this helps, >>> Karen >>> >>> Heiko Wagner wrote: >>>> >>>> Hi, >>>> >>>> I am currently investigating on a problem of the Java VM on Windows. The >>>> VM >>>> is started using the JNI invocation api. This works unless the path >>>> contains >>>> non-ansi characters. So I hacked the classpath with >>>> addURLToAppClassLoader() >>>> in sun.misc.Launcher. I at least could make a shared JRE installation, >>>> started from a ansi path, find my JARs. Since one of my JARs does use >>>> native >>>> code I then got stuck at the System.loadLibrary() call. Hacking the >>>> correct >>>> path into the 'usr_paths' field into the ClassLoader did not help, >>>> because >>>> the actual Windows API call LoadLibrary() seems to be ansi flavour >>>> instead >>>> of wide char api. Would it be possible to make this two enhancements >>>> without >>>> hurting the Java VM spec?: >>>> >>>> 1) fill the property java.class.path from the env variable CLASSPATH > with >>>> a >>>> call to GetEnvironmentVariableW instead of GetEnvironmentVariableA to >>>> enable >>>> setting the classpath with unicode characters >>>> >>>> 2) fill the property java.library.path and issue the actual LoadLibrary >>>> with >>>> appropriate wide char api >>>> >>>>> From a quick look at the VM source I found out, that most string >>>>> operations >>>> >>>> use the ANSI C string functions. >>>> Maybe it would be possible to use UTF-8 encoding to transfer the path >>>> strings throu the Java VM routines to the final Windows API calls, to >>>> avoid >>>> large changes in the code base. >>>> >>>> Regards >>>> Heiko Wagner >>>> >>> >> >> >> -- >> Naoto Sato >> > > From Mandy.Chung at Sun.COM Thu Feb 26 01:27:57 2009 From: Mandy.Chung at Sun.COM (Mandy Chung) Date: Wed, 25 Feb 2009 17:27:57 -0800 Subject: Request for review: 6799689 Message-ID: <49A5F01D.6040303@Sun.com> 6799689 Make sun.misc.FloatingDecimal.hexFloatPattern static field initialized lazily Webrev: http://cr.openjdk.java.net/~mchung/6799689/webrev.00/ The Pattern object is not always needed but is currently instantiated in the static initializer. Lazy initialization of the hexFloatFattern static field will save the regex classes not to be loaded until it's needed. Thanks Mandy From jjb at google.com Thu Feb 26 01:50:47 2009 From: jjb at google.com (Joshua Bloch) Date: Wed, 25 Feb 2009 17:50:47 -0800 Subject: Request for review: 6799689 In-Reply-To: <49A5F01D.6040303@Sun.com> References: <49A5F01D.6040303@Sun.com> Message-ID: <17b2302a0902251750s29b4a69dy77f41e0a52c64360@mail.gmail.com> Mandy, Hi! Looks good, but if you care about the performance of parseHexString, you might want to use the "lazy initialization holder class idiom" (Effective Java 2e, Page 283). I can't promise that you'll be able to measure the difference, or that it will be faster, but I suspect so. Josh On Wed, Feb 25, 2009 at 5:27 PM, Mandy Chung wrote: > 6799689 Make sun.misc.FloatingDecimal.hexFloatPattern static field > initialized lazily > > Webrev: > http://cr.openjdk.java.net/~mchung/6799689/webrev.00/ > > The Pattern object is not always needed but is currently instantiated in > the static initializer. Lazy initialization of the hexFloatFattern static > field will save the regex classes not to be loaded until it's needed. > > Thanks > Mandy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Mandy.Chung at Sun.COM Thu Feb 26 02:00:59 2009 From: Mandy.Chung at Sun.COM (Mandy Chung) Date: Wed, 25 Feb 2009 18:00:59 -0800 Subject: Request for review: 6799689 In-Reply-To: <17b2302a0902251750s29b4a69dy77f41e0a52c64360@mail.gmail.com> References: <49A5F01D.6040303@Sun.com> <17b2302a0902251750s29b4a69dy77f41e0a52c64360@mail.gmail.com> Message-ID: <49A5F7DB.5010802@Sun.com> Thanks. Josh. I considered the lazy initialization holder class idiom (thanks to your Effective Java book and Brian's Java Concurrency in Practice book). I discussed with Joe Darcy about the performance of parseHexString. Since it's not a hot method, I decided to go with the simple approach making it a synchronized method as a tradeoff of adding one additional class. Thanks Mandy On 02/25/09 17:50, Joshua Bloch wrote: > Mandy, > > Hi! Looks good, but if you care about the performance of parseHexString, > you might want to use the "lazy initialization holder class idiom" > (Effective Java 2e, Page 283). I can't promise that you'll be able to > measure the difference, or that it will be faster, but I suspect so. > > Josh > > On Wed, Feb 25, 2009 at 5:27 PM, Mandy Chung > wrote: > > 6799689 Make sun.misc.FloatingDecimal.hexFloatPattern static field > initialized lazily > > Webrev: > http://cr.openjdk.java.net/~mchung/6799689/webrev.00/ > > The Pattern object is not always needed but is currently > instantiated in the static initializer. Lazy initialization of the > hexFloatFattern static field will save the regex classes not to be > loaded until it's needed. > > Thanks > Mandy > > From jjb at google.com Thu Feb 26 02:07:03 2009 From: jjb at google.com (Joshua Bloch) Date: Wed, 25 Feb 2009 18:07:03 -0800 Subject: Request for review: 6799689 In-Reply-To: <49A5F7DB.5010802@Sun.com> References: <49A5F01D.6040303@Sun.com> <17b2302a0902251750s29b4a69dy77f41e0a52c64360@mail.gmail.com> <49A5F7DB.5010802@Sun.com> Message-ID: <17b2302a0902251807y5d344cb7geeadec76f2906ea1@mail.gmail.com> OK, then LGTM:) Josh On Wed, Feb 25, 2009 at 6:00 PM, Mandy Chung wrote: > Thanks. Josh. > > I considered the lazy initialization holder class idiom (thanks to your > Effective Java book and Brian's Java Concurrency in Practice book). I > discussed with Joe Darcy about the performance of parseHexString. Since it's > not a hot method, I decided to go with the simple approach making it a > synchronized method as a tradeoff of adding one additional class. > > Thanks > Mandy > > On 02/25/09 17:50, Joshua Bloch wrote: > >> Mandy, >> >> Hi! Looks good, but if you care about the performance of parseHexString, >> you might want to use the "lazy initialization holder class idiom" >> (Effective Java 2e, Page 283). I can't promise that you'll be able to >> measure the difference, or that it will be faster, but I suspect so. >> >> Josh >> >> On Wed, Feb 25, 2009 at 5:27 PM, Mandy Chung > Mandy.Chung at sun.com>> wrote: >> >> 6799689 Make sun.misc.FloatingDecimal.hexFloatPattern static field >> initialized lazily >> >> Webrev: >> http://cr.openjdk.java.net/~mchung/6799689/webrev.00/ >> >> The Pattern object is not always needed but is currently >> instantiated in the static initializer. Lazy initialization of the >> hexFloatFattern static field will save the regex classes not to be >> loaded until it's needed. >> >> Thanks >> Mandy >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From Joe.Darcy at Sun.COM Thu Feb 26 02:08:34 2009 From: Joe.Darcy at Sun.COM (Joe Darcy) Date: Wed, 25 Feb 2009 18:08:34 -0800 Subject: Request for review: 6799689 In-Reply-To: <49A5F7DB.5010802@Sun.com> References: <49A5F01D.6040303@Sun.com> <17b2302a0902251750s29b4a69dy77f41e0a52c64360@mail.gmail.com> <49A5F7DB.5010802@Sun.com> Message-ID: <49A5F9A2.5020703@sun.com> Mandy, Looks fine; approved. -Joe On 02/25/09 06:00 PM, Mandy Chung wrote: > Thanks. Josh. > > I considered the lazy initialization holder class idiom (thanks to > your Effective Java book and Brian's Java Concurrency in Practice > book). I discussed with Joe Darcy about the performance of > parseHexString. Since it's not a hot method, I decided to go with the > simple approach making it a synchronized method as a tradeoff of > adding one additional class. > > Thanks > Mandy > > On 02/25/09 17:50, Joshua Bloch wrote: >> Mandy, >> >> Hi! Looks good, but if you care about the performance of >> parseHexString, you might want to use the "lazy initialization holder >> class idiom" (Effective Java 2e, Page 283). I can't promise that >> you'll be able to measure the difference, or that it will be faster, >> but I suspect so. >> >> Josh >> >> On Wed, Feb 25, 2009 at 5:27 PM, Mandy Chung > > wrote: >> >> 6799689 Make sun.misc.FloatingDecimal.hexFloatPattern static field >> initialized lazily >> >> Webrev: >> http://cr.openjdk.java.net/~mchung/6799689/webrev.00/ >> >> The Pattern object is not always needed but is currently >> instantiated in the static initializer. Lazy initialization of the >> hexFloatFattern static field will save the regex classes not to be >> loaded until it's needed. >> >> Thanks >> Mandy >> >> From david.lloyd at redhat.com Thu Feb 26 16:02:44 2009 From: david.lloyd at redhat.com (David M. Lloyd) Date: Thu, 26 Feb 2009 10:02:44 -0600 Subject: [PATCH 0/2] Class- and class loader-local storage (Bug ID #6493635) Message-ID: <49A6BD24.3070806@redhat.com> After running into the problem described in this bug for the umpteenth time, I decided to get off my duff and do something about it. Following are two patches. The first one adds the notion of class-local storage, and the second adds class loader-local storage; both mechanisms work basically the same way. There's a map on the Class or ClassLoader that's lazily created, weakly keyed by an object which is private to the ClassLocal or ClassLoaderLocal instance. The *Local instance itself has operations to read and write the values with operations similar to what one might find on Map and ConcurrentMap. A possible future optimization might be to replace the simple synchronization I am using with a more complex mechanism (like one of the concurrent reference map implementations floating out there). References: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6493635 http://crazybob.org/2006/12/caching-class-related-information.html http://weblogs.java.net/blog/jhook/archive/2006/12/class_metadata.html http://dmlloyd.blogspot.com/2009/02/class-local-data.html - DML From david.lloyd at redhat.com Thu Feb 26 16:05:30 2009 From: david.lloyd at redhat.com (David M. Lloyd) Date: Thu, 26 Feb 2009 10:05:30 -0600 Subject: [PATCH 1/2] Class local storage In-Reply-To: <49A6BD24.3070806@redhat.com> References: <49A6BD24.3070806@redhat.com> Message-ID: <49A6BDCA.9000404@redhat.com> This first patch adds a ClassLocal mechanism. The cost is one reference per loaded class, plus one WeakHashMap for every loaded class which has local information associated with it. The map has one key for every ClassLocal which is currently storing data on this ClassLocal. - DML -- diff -r dde3fe2e8164 src/share/classes/java/lang/Class.java --- a/src/share/classes/java/lang/Class.java Wed Feb 25 14:32:01 2009 +0000 +++ b/src/share/classes/java/lang/Class.java Thu Feb 26 09:53:00 2009 -0600 @@ -52,6 +52,7 @@ import java.util.Set; import java.util.Map; import java.util.HashMap; +import java.util.WeakHashMap; import sun.misc.Unsafe; import sun.reflect.ConstantPool; import sun.reflect.Reflection; @@ -3113,4 +3114,18 @@ AnnotationType getAnnotationType() { return annotationType; } + + // Class local variables use this storage + + private transient Map classLocalData; + + // Callers must synchronize on this class instance. + Map getClassLocalMap() { + final Map classLocalData = this.classLocalData; + if (classLocalData != null) { + return classLocalData; + } else { + return (this.classLocalData = new WeakHashMap()); + } + } } diff -r dde3fe2e8164 src/share/classes/java/lang/ClassLocal.java --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/src/share/classes/java/lang/ClassLocal.java Thu Feb 26 09:53:00 2009 -0600 @@ -0,0 +1,205 @@ +/* + * Copyright 1994-2008 Sun Microsystems, Inc. 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. Sun designates this + * particular file as subject to the "Classpath" exception as provided + * by Sun in the LICENSE file that accompanied this code. + * + * 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 Sun Microsystems, Inc., 4150 Network Circle, Santa Clara, + * CA 95054 USA or visit www.sun.com if you need additional information or + * have any questions. + */ +package java.lang; + +import java.util.Map; + +/** + * This class provides class local variables. Data stored in a class local + * variable is strongly referenced by the class it is associated with. + * + * @author David M. Lloyd + * @param the type of the value of this class local variable + * @since 1.7 + */ +public final class ClassLocal { + private volatile Object key = new Object(); + + /** + * Construct a new instance. A new instance will contain no mappings. + */ + public ClassLocal() { + } + + /** + * Determine whether the given class has a mapping for this variable (even + * if it is {@code null}). + * + * @param clazz the class to check + * + * @return {@code true} if the given class contains a value for this + * class-local + */ + public boolean hasValue(Class clazz) { + synchronized (clazz) { + return clazz.getClassLocalMap().containsKey(key); + } + } + + /** + * Get the value associated with the given class for this variable. + * + * @return the value associated with the given class, or {@code null} if + * there is no mapping (a {@code null} return could also indicate + * that a {@code null} value is stored in this variable) + */ + public T get(Class clazz) { + synchronized (clazz) { + return (T) clazz.getClassLocalMap().get(key); + } + } + + /** + * Associate a new value with the given class for this variable. + * + * @param clazz the class to update + * @param value the value to associate + * + * @return the previous value associated with this variable, or {@code null} + * if there was no mapping (a {@code null} return could also + * indicate that a {@code null} value was stored in this variable) + */ + public T put(Class clazz, T value) { + synchronized (clazz) { + return (T) clazz.getClassLocalMap().put(key, value); + } + } + + /** + * Associate a value with the given class for this variable if there was + * previously no mapping. + * + * @param clazz the class to update + * @param value the value to associate + * + * @return the previous value associated with this variable, or {@code null} + * if there was no mapping (a {@code null} return could also + * indicate that a {@code null} value was stored in this variable) + */ + public T putIfAbsent(Class clazz, T value) { + synchronized (clazz) { + final Object key = this.key; + final Map cldMap = clazz.getClassLocalMap(); + if (cldMap.containsKey(key)) { + return (T) cldMap.get(key); + } else { + cldMap.put(key, value); + return null; + } + } + } + + /** + * Get and remove the value of this variable. After this method returns, + * there will be no value stored in this variable for the given class + * (calling {@code hasValue(clazz)} for this class and variable will return + * {@code false}). + * + * @param clazz the class to update + * + * @return the previous value associated with this variable, or {@code null} + * if there was no mapping (a {@code null} return could also + * indicate that a {@code null} value was stored in this variable) + */ + public T remove(Class clazz) { + synchronized (clazz) { + return (T) clazz.getClassLocalMap().remove(key); + } + } + + /** + * Remove the entry for this variable only if it is currently set to a given + * value. + * + * @param clazz the class to update + * @param oldValue the value expected to be associated with the variable + * + * @return {@code true} if the value was removed + */ + public boolean remove(Class clazz, T oldValue) { + synchronized (clazz) { + final Map clMap = clazz.getClassLocalMap(); + final Object key = this.key; + if (clMap.containsKey(key) && clMap.get(key).equals(oldValue)) { + clMap.remove(key); + return true; + } else { + return false; + } + } + } + + /** + * Replace the entry for this variable, returning the old value. + * + * @param clazz the class to update + * @param newValue the value to associate with this variable + * + * @return the previous value associated with this variable, or {@code null} + * if there was no mapping (a {@code null} return could also + * indicate that a {@code null} value was stored in this variable) + */ + public T replace(Class clazz, T newValue) { + synchronized (clazz) { + final Map clMap = clazz.getClassLocalMap(); + if (clMap.containsKey(key)) { + return (T) clMap.put(key, newValue); + } else { + return null; + } + } + } + + /** + * Replace the entry for this variable, if it was previously set to a given + * value. + * + * @param clazz the class to update + * @param oldValue the value expected to be associated with the variable + * @param newValue the value to associate with this variable + * + * @return {@code true} if the value was replaced + */ + public boolean replace(Class clazz, T oldValue, T newValue) { + synchronized (clazz) { + final Map clMap = clazz.getClassLocalMap(); + final Object key = this.key; + if (clMap.containsKey(key) && clMap.get(key).equals(oldValue)) { + clMap.put(key, newValue); + return true; + } else { + return false; + } + } + } + + /** + * Cause all existing mappings to be cleared. Once this method is called, + * prior values are no longer retrievable. + */ + public void clear() { + key = new Object(); + } +} From david.lloyd at redhat.com Thu Feb 26 16:07:00 2009 From: david.lloyd at redhat.com (David M. Lloyd) Date: Thu, 26 Feb 2009 10:07:00 -0600 Subject: [PATCH 2/2] Class loader local storage In-Reply-To: <49A6BD24.3070806@redhat.com> References: <49A6BD24.3070806@redhat.com> Message-ID: <49A6BE24.8000300@redhat.com> This second patch adds a ClassLoaderLocal mechanism. The cost is one reference per class loader, plus one WeakHashMap for every class class loader which has local information associated with it. The map has one key for every ClassLoaderLocal which is currently storing data on this ClassLoaderLocal. - DML -- diff -r dde3fe2e8164 src/share/classes/java/lang/ClassLoader.java --- a/src/share/classes/java/lang/ClassLoader.java Wed Feb 25 14:32:01 2009 +0000 +++ b/src/share/classes/java/lang/ClassLoader.java Thu Feb 26 09:53:12 2009 -0600 @@ -48,6 +48,7 @@ import java.util.Stack; import java.util.Map; import java.util.Vector; +import java.util.WeakHashMap; import sun.misc.ClassFileTransformer; import sun.misc.CompoundEnumeration; import sun.misc.Resource; @@ -2012,6 +2013,17 @@ // Retrieves the assertion directives from the VM. private static native AssertionStatusDirectives retrieveDirectives(); + + private Map classLoaderLocalMap; + + Map getClassLoaderLocalMap() { + final Map classLoaderLocalMap = this.classLoaderLocalMap; + if (classLoaderLocalMap == null) { + return (this.classLoaderLocalMap = new WeakHashMap()); + } else { + return classLoaderLocalMap; + } + } } diff -r dde3fe2e8164 src/share/classes/java/lang/ClassLoaderLocal.java --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/src/share/classes/java/lang/ClassLoaderLocal.java Thu Feb 26 09:53:12 2009 -0600 @@ -0,0 +1,211 @@ +/* + * Copyright 1994-2008 Sun Microsystems, Inc. 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. Sun designates this + * particular file as subject to the "Classpath" exception as provided + * by Sun in the LICENSE file that accompanied this code. + * + * 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 Sun Microsystems, Inc., 4150 Network Circle, Santa Clara, + * CA 95054 USA or visit www.sun.com if you need additional information or + * have any questions. + */ +package java.lang; + +import java.util.Map; + +/** + * This class provides class loader local variables. Data stored in a class + * loader local variable is strongly referenced by the class loader it is + * associated with. + * + * @author David M. Lloyd + * @param the type of the value of this class loader local variable + * @since 1.7 + */ +public final class ClassLoaderLocal { + private volatile Object key = new Object(); + + /** + * Construct a new instance. A new instance will contain no mappings. + */ + public ClassLoaderLocal() { + } + + /** + * Determine whether the given class has a mapping for this variable (even + * if it is {@code null}). + * + * @param classLoader the class loader to check + * + * @return {@code true} if the given class loader contains a value for this + * variable + */ + public boolean hasValue(ClassLoader classLoader) { + synchronized (classLoader) { + return classLoader.getClassLoaderLocalMap().containsKey(key); + } + } + + /** + * Get the value associated with the given class loader for this variable. + * + * @return the value associated with the given class, or {@code null} if + * there is no mapping (a {@code null} return could also indicate + * that a {@code null} value is stored in this variable) + */ + public T get(ClassLoader classLoader) { + synchronized (classLoader) { + return (T) classLoader.getClassLoaderLocalMap().get(key); + } + } + + /** + * Associate a new value with the given class loader for this variable. + * + * @param classLoader the class loader to update + * @param value the value to associate + * + * @return the previous value associated with this variable, or {@code null} + * if there was no mapping (a {@code null} return could also + * indicate that a {@code null} value was stored in this variable) + */ + public T put(ClassLoader classLoader, T value) { + synchronized (classLoader) { + return (T) classLoader.getClassLoaderLocalMap().put(key, value); + } + } + + /** + * Associate a value with the given class loader for this variable if there + * was previously no mapping. + * + * @param classLoader the class loader to update + * @param value the value to associate + * + * @return the previous value associated with this variable, or {@code null} + * if there was no mapping (a {@code null} return could also + * indicate that a {@code null} value was stored in this variable) + */ + public T putIfAbsent(ClassLoader classLoader, T value) { + synchronized (classLoader) { + final Object key = this.key; + final Map cllMap = + classLoader.getClassLoaderLocalMap(); + if (cllMap.containsKey(key)) { + return (T) cllMap.get(key); + } else { + cllMap.put(key, value); + return null; + } + } + } + + /** + * Get and remove the value of this variable. After this method returns, + * there will be no value stored in this variable for the given class loader + * (calling {@code hasValue(classLoader)} for this class loader and variable + * will return {@code false}). + * + * @param classLoader the class loader to update + * + * @return the previous value associated with this variable, or {@code null} + * if there was no mapping (a {@code null} return could also + * indicate that a {@code null} value was stored in this variable) + */ + public T remove(ClassLoader classLoader) { + synchronized (classLoader) { + return (T) classLoader.getClassLoaderLocalMap().remove(key); + } + } + + /** + * Remove the entry for this variable only if it is currently set to a given + * value. + * + * @param classLoader the class loader to update + * @param oldValue the value expected to be associated with the variable + * + * @return {@code true} if the value was removed + */ + public boolean remove(ClassLoader classLoader, T oldValue) { + synchronized (classLoader) { + final Map cllMap = + classLoader.getClassLoaderLocalMap(); + final Object key = this.key; + if (cllMap.containsKey(key) && cllMap.get(key).equals(oldValue)) { + cllMap.remove(key); + return true; + } else { + return false; + } + } + } + + /** + * Replace the entry for this variable, returning the old value. + * + * @param classLoader the class loader to update + * @param newValue the value to associate with this variable + * + * @return the previous value associated with this variable, or {@code null} + * if there was no mapping (a {@code null} return could also + * indicate that a {@code null} value was stored in this variable) + */ + public T replace(ClassLoader classLoader, T newValue) { + synchronized (classLoader) { + final Map cllMap = + classLoader.getClassLoaderLocalMap(); + final Object key = this.key; + if (cllMap.containsKey(key)) { + return (T) cllMap.put(key, newValue); + } else { + return null; + } + } + } + + /** + * Replace the entry for this variable, if it was previously set to a given + * value. + * + * @param classLoader the class loader to update + * @param oldValue the value expected to be associated with the variable + * @param newValue the value to associate with this variable + * + * @return {@code true} if the value was replaced + */ + public boolean replace(ClassLoader classLoader, T oldValue, T newValue) { + synchronized (classLoader) { + final Map cllMap = + classLoader.getClassLoaderLocalMap(); + final Object key = this.key; + if (cllMap.containsKey(key) && cllMap.get(key).equals(oldValue)) { + cllMap.put(key, newValue); + return true; + } else { + return false; + } + } + } + + /** + * Cause all existing mappings to be cleared. Once this method is called, + * prior values are no longer retrievable. + */ + public void clear() { + key = new Object(); + } +} \ No newline at end of file From mandy.chung at sun.com Thu Feb 26 22:41:55 2009 From: mandy.chung at sun.com (mandy.chung at sun.com) Date: Thu, 26 Feb 2009 22:41:55 +0000 Subject: hg: jdk7/tl/jdk: 6801467: Defer get the launcher resource bundle until it's needed Message-ID: <20090226224206.F0ADDE213@hg.openjdk.java.net> Changeset: 2fb53eb9df14 Author: mchung Date: 2009-02-26 14:36 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/2fb53eb9df14 6801467: Defer get the launcher resource bundle until it's needed Summary: Lazily initialize the launcher resource bundle Reviewed-by: ksrini, darcy ! src/share/classes/sun/launcher/LauncherHelper.java From irisg at alum.mit.edu Thu Feb 26 23:18:20 2009 From: irisg at alum.mit.edu (Iris Clark) Date: Thu, 26 Feb 2009 18:18:20 -0500 (EST) Subject: Should Lance be a member of the core libraries group? Message-ID: <27296983.93.1235690300637.JavaMail.help@alum.mit.edu> Hi, Alan. Before I consider initiating the CFV, I have one question. Is JDBC really considered part of "Core Libraries"? We want to make sure that "Core Libraries" does not become the catch-all for APIs that don't belong anywhere else. As far as I know Lance already has all the privileges necessary to enhance JDBC, including commit rights. What additional benefits would becoming a member of Core Libraries confer on him? Thanks, iris http://mail.openjdk.java.net/pipermail/core-libs-dev/2009-February/001141.html From jonathan.gibbons at sun.com Fri Feb 27 02:31:21 2009 From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com) Date: Fri, 27 Feb 2009 02:31:21 +0000 Subject: hg: jdk7/tl/corba: 6809563: corba build in JDK uses invalid bootclasspath for javah Message-ID: <20090227023122.14A42E25F@hg.openjdk.java.net> Changeset: 9e6c48c2582d Author: jjg Date: 2009-02-26 18:28 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/9e6c48c2582d 6809563: corba build in JDK uses invalid bootclasspath for javah Reviewed-by: ohair ! make/common/shared/Defs-java.gmk From jonathan.gibbons at sun.com Fri Feb 27 02:35:40 2009 From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com) Date: Fri, 27 Feb 2009 02:35:40 +0000 Subject: hg: jdk7/tl/corba: 6810915: Sun proprietary warnings in JDK build Message-ID: <20090227023541.747B5E26C@hg.openjdk.java.net> Changeset: db35452e8965 Author: jjg Date: 2009-02-26 18:32 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/db35452e8965 6810915: Sun proprietary warnings in JDK build Reviewed-by: ohair ! make/Makefile ! make/common/shared/Defs-java.gmk From jonathan.gibbons at sun.com Fri Feb 27 02:54:47 2009 From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com) Date: Fri, 27 Feb 2009 02:54:47 +0000 Subject: hg: jdk7/tl/jdk: 6810915: Sun proprietary warnings in JDK build Message-ID: <20090227025459.28062E271@hg.openjdk.java.net> Changeset: 4f0b6455a977 Author: jjg Date: 2009-02-26 18:51 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/4f0b6455a977 6810915: Sun proprietary warnings in JDK build Reviewed-by: ohair ! make/common/shared/Defs-java.gmk ! make/docs/Makefile ! make/javax/swing/beaninfo/SwingBeans.gmk From Alan.Bateman at Sun.COM Fri Feb 27 18:08:26 2009 From: Alan.Bateman at Sun.COM (Alan Bateman) Date: Fri, 27 Feb 2009 18:08:26 +0000 Subject: Should Lance be a member of the core libraries group? In-Reply-To: <27296983.93.1235690300637.JavaMail.help@alum.mit.edu> References: <27296983.93.1235690300637.JavaMail.help@alum.mit.edu> Message-ID: <49A82C1A.2010206@sun.com> Iris Clark wrote: > Hi, Alan. > > Before I consider initiating the CFV, I have one question. Is JDBC really considered part of "Core Libraries"? We want to make sure that "Core Libraries" does not become the catch-all for APIs that don't belong anywhere else. > You are right and that is the real question. It would be extending the scope because JDBC isn't really related to any of the feature areas currently listed on the group page. > As far as I know Lance already has all the privileges necessary to enhance JDBC, including commit rights. What additional benefits would becoming a member of Core Libraries confer on him? > Yes, I believe he has push-rights so this isn't an issue. I'm sorta the messenger here, not the campaign manager :-) so I'll have to defer to Lance on this. -Alan. From openjdk at crazybob.org Fri Feb 27 18:10:33 2009 From: openjdk at crazybob.org (Bob Lee) Date: Fri, 27 Feb 2009 10:10:33 -0800 Subject: [PATCH 0/2] Class- and class loader-local storage (Bug ID #6493635) Message-ID: I have a simpler and more secure solution. I just need one method on ClassLoader: public class ClassLoader { public void keepReferenceTo(Object o) { ... } ... } The ClassLoader would keep a strong reference to the passed reference indefinitely (using some sort of minimal memory footprint, wait-free data structure internally). We could add a convenience method to Class, too, but it would just delegate to the same method on the Class's loader. Now, my library code can just keep a weak reference to the object, and I know it won't be cleared until the class loader is reclaimed. Bob From Lance.Andersen at Sun.COM Fri Feb 27 18:36:58 2009 From: Lance.Andersen at Sun.COM (Lance J. Andersen) Date: Fri, 27 Feb 2009 13:36:58 -0500 Subject: Should Lance be a member of the core libraries group? In-Reply-To: <49A82C1A.2010206@sun.com> References: <27296983.93.1235690300637.JavaMail.help@alum.mit.edu> <49A82C1A.2010206@sun.com> Message-ID: <49A832CA.7040603@sun.com> Alan Bateman wrote: > Iris Clark wrote: >> Hi, Alan. >> >> Before I consider initiating the CFV, I have one question. Is JDBC >> really considered part of "Core Libraries"? We want to make sure >> that "Core Libraries" does not become the catch-all for APIs that >> don't belong anywhere else. >> > You are right and that is the real question. It would be extending the > scope because JDBC isn't really related to any of the feature areas > currently listed on the group page. Originally when we rolling out the content for core-libs pages I had sent JDBC info for inclusion on that page last March. It made sense as I dotted line report into the core libs manager. It was decided in previous discussions that JDBC did not warrant its own group on OpenJDK and why i had sent the info for inclusion on the core libs page. > >> As far as I know Lance already has all the privileges necessary to >> enhance JDBC, including commit rights. What additional benefits >> would becoming a member of Core Libraries confer on him? >> > Yes, I believe he has push-rights so this isn't an issue. I'm sorta > the messenger here, not the campaign manager :-) so I'll have to > defer to Lance on this. This is a core Java API as everything talks to a database so it should have a voice/home in OpenJDK :-) Regards Lance > > -Alan. > From david.lloyd at redhat.com Fri Feb 27 18:40:21 2009 From: david.lloyd at redhat.com (David M. Lloyd) Date: Fri, 27 Feb 2009 12:40:21 -0600 Subject: [PATCH 0/2] Class- and class loader-local storage (Bug ID #6493635) In-Reply-To: References: Message-ID: <49A83395.80308@redhat.com> On 02/27/2009 12:10 PM, Bob Lee wrote: > I have a simpler and more secure solution. I just need one method on > ClassLoader: > > public class ClassLoader { > public void keepReferenceTo(Object o) { ... } > ... > } > > The ClassLoader would keep a strong reference to the passed reference > indefinitely (using some sort of minimal memory footprint, wait-free > data structure internally). We could add a convenience method to > Class, too, but it would just delegate to the same method on the > Class's loader. > > Now, my library code can just keep a weak reference to the object, and > I know it won't be cleared until the class loader is reclaimed. Seems like a reasonable alternate approach, *however* I think there ought to be a way to clear the reference as well, which would complicate matters a little with respect to the internal data structure. I felt I could get away with simply using a synchronized weak hash map on the Class (with a vague intention of using Reference*Map that I expect will appear in the JDK sometime soon-ish) because it's reasonably granular, but this simple idea probably won't work if everything is stuck on the ClassLoader due to contention problems. So while your solution is simpler and more elegant in a lot of ways, from a usage perspective at least, it prohibits a simple two-hour solution like mine. :) Though it would be easy enough to whip up a simple synchronized-identity-hash-set first implementation, and let the concurrency-interest maniacs like you have a crack at making it superfast; I'd be willing to do that much at least. But I'm just not sure it'll be possible to avoid contention problems - call it a gut feeling. My solution is based mainly on existing ideas/usage patterns in the JDK; that's why I went the route that I did. Another advantage to your approach is that it doesn't grow Class, which is what bothered me the most about my solution... though that could be a simple solution to the granularity/contention issue (put the method/structure on each Class instead of the ClassLoader), but is the benefit worth the cost? Upon reflection though, is the cost even that great? Adding annotations had a greater cost than adding a single reference field would. - DML From openjdk at crazybob.org Fri Feb 27 18:56:09 2009 From: openjdk at crazybob.org (Bob Lee) Date: Fri, 27 Feb 2009 10:56:09 -0800 Subject: [PATCH 0/2] Class- and class loader-local storage (Bug ID #6493635) In-Reply-To: <49A83395.80308@redhat.com> References: <49A83395.80308@redhat.com> Message-ID: On Fri, Feb 27, 2009 at 10:40 AM, David M. Lloyd wrote: > Seems like a reasonable alternate approach, *however* I think there ought to > be a way to clear the reference as well, Do you have a use case? *If* we wanted to support removals (I don't think we should), I would do something like this: public class ClassLoader { public Reference keepReferenceTo(Object o) { ... } ... } You could call clear() on the returned reference to clear the ClassLoader's reference. Internally, it would use some sort of CAS doubly-linked list. Bob From david.lloyd at redhat.com Fri Feb 27 19:04:55 2009 From: david.lloyd at redhat.com (David M. Lloyd) Date: Fri, 27 Feb 2009 13:04:55 -0600 Subject: [PATCH 0/2] Class- and class loader-local storage (Bug ID #6493635) In-Reply-To: References: <49A83395.80308@redhat.com> Message-ID: <49A83957.3060102@redhat.com> On 02/27/2009 12:52 PM, Bob Lee wrote: > On Fri, Feb 27, 2009 at 10:40 AM, David M. Lloyd wrote: >> Seems like a reasonable alternate approach, *however* I think there ought to >> be a way to clear the reference as well, which would complicate matters a >> little with respect to the internal data structure. > > Do you have a use case? > > *If* we wanted to support removals, I would do something like this: > > public class ClassLoader { > public Reference keepReferenceTo(Object o) { ... } > ... > } > > You could call clear() on the returned reference to clear the > ClassLoader's reference. Internally, it would use some sort of CAS > doubly-linked list. A couple use cases, off the top of my head: 1) I've got a set of FooBars that associate with Classes; now for whatever reason, I want to change the FooBar that is associated with the Class. The old FooBar is now completely unreferenced; keeping a reference to it is a leak. 2) I've got an application server deployment that provides some kind of service by class, so I stash refs on the ClassLoaders of the Classes for whom the service is provided. I want to undeploy my application, but all those classloaders have strong refs to my deployment. They all have to be cleared or you face a OOM: PermGen after a few redeployments. In this case I'd use a stop() + finalize() on my service which clears them. 2a) OK, you say, just stash an Object or something that isn't from my deployment's classloader. Nevertheless, every time you redeploy, you're now permanently leaking data and you *will* run out of heap space eventually, even if your deployment is meticulous about cleaning up references. My solution solves the problem by having a "key" (similar to your Reference above) - however the difference is that you use one key instead of many References (for a space savings), so it works like this: - App keeps strong reference to key - Class(loader) keeps a weak->strong map of keys to refs - When app is removed, the key goes away, and all the references simply clean themselves up (in other words, no special action is needed on the part of the app to clean up refs stashed on other class(loader)s) Using a CAS linked list like you describe would be very nice, from a performance perspective, but you lose a little of the manageability that you would gain from not having to worry about manually cleaning up all your junk. - DML From openjdk at crazybob.org Fri Feb 27 19:15:06 2009 From: openjdk at crazybob.org (Bob Lee) Date: Fri, 27 Feb 2009 11:15:06 -0800 Subject: [PATCH 0/2] Class- and class loader-local storage (Bug ID #6493635) In-Reply-To: <49A83957.3060102@redhat.com> References: <49A83395.80308@redhat.com> <49A83957.3060102@redhat.com> Message-ID: On Fri, Feb 27, 2009 at 11:04 AM, David M. Lloyd wrote: > A couple use cases, off the top of my head: > > 1) I've got a set of FooBars that associate with Classes; now for whatever > reason, I want to change the FooBar that is associated with the Class. ?The > old FooBar is now completely unreferenced; keeping a reference to it is a > leak. What's a FooBar? Use cases should be concrete. :-) > 2) I've got an application server deployment that provides some kind of > service by class, so I stash refs on the ClassLoaders of the Classes for > whom the service is provided. ?I want to undeploy my application, but all > those classloaders have strong refs to my deployment. ?They all have to be > cleared or you face a OOM: PermGen after a few redeployments. ?In this case > I'd use a stop() + finalize() on my service which clears them. Can you provide more detail? It sounds to me like you're saying that the service impl classes are in the parent class loader and the server (that binds the services) is in the child class loader, but from my experience, it's usually the other way around. Bob From david.lloyd at redhat.com Fri Feb 27 19:44:18 2009 From: david.lloyd at redhat.com (David M. Lloyd) Date: Fri, 27 Feb 2009 13:44:18 -0600 Subject: [PATCH 0/2] Class- and class loader-local storage (Bug ID #6493635) In-Reply-To: References: <49A83395.80308@redhat.com> <49A83957.3060102@redhat.com> Message-ID: <49A84292.1070207@redhat.com> On 02/27/2009 01:15 PM, Bob Lee wrote: > On Fri, Feb 27, 2009 at 11:04 AM, David M. Lloyd wrote: >> A couple use cases, off the top of my head: >> >> 1) I've got a set of FooBars that associate with Classes; now for whatever >> reason, I want to change the FooBar that is associated with the Class. The >> old FooBar is now completely unreferenced; keeping a reference to it is a >> leak. > > What's a FooBar? Use cases should be concrete. :-) > >> 2) I've got an application server deployment that provides some kind of >> service by class, so I stash refs on the ClassLoaders of the Classes for >> whom the service is provided. I want to undeploy my application, but all >> those classloaders have strong refs to my deployment. They all have to be >> cleared or you face a OOM: PermGen after a few redeployments. In this case >> I'd use a stop() + finalize() on my service which clears them. > > Can you provide more detail? It sounds to me like you're saying that > the service impl classes are in the parent class loader and the server > (that binds the services) is in the child class loader, but from my > experience, it's usually the other way around. It comes back to the whole point of the exercise. Using JBoss Marshalling as a concrete use case - WeakHashMap, Externalizer>() *fails* because Externalizer instances are usually customized to the class they externalize (which, by the way, could well be a system class). This means that Externalizer keeps a strong ref to the Class after all. So we need a map with weak keys -> weak values, and a way to associate a strong ref from the Class. This covers the case of the Class going away. But if the deployment containing the Externalizer goes away? It's a leak, and a big one (it includes the whole classloader of the Externalizer implementation, not to mention the classloader of Externalizer.class itself) unless we can remove the reference somehow. Even if you attempt to work around it by using an intermediate object from the system classloader, like an Object[1], to hold the references, and you manually keep a Set of them and clear them all out on redeploy, you've still leaked an Object[1] on every class or classloader for every redeployment. So it doesn't matter what classloader the service is bound from, though it can exacerbate the problem. If I ever want to associate some data with, say, a class from the system classloader - *even if I make that data be a type from the system classloader* - that data is now permanent, even when I don't need it anymore. So if I cause a deployment to happen again, which re-executes the association, the old data is now leaked. Your solution puts permanent, uncollectible data on classloaders, no matter how you slice it. There *has* to be a way to clean it up. - DML From openjdk at crazybob.org Fri Feb 27 20:18:35 2009 From: openjdk at crazybob.org (Bob Lee) Date: Fri, 27 Feb 2009 12:18:35 -0800 Subject: [PATCH 0/2] Class- and class loader-local storage (Bug ID #6493635) In-Reply-To: <49A84292.1070207@redhat.com> References: <49A83395.80308@redhat.com> <49A83957.3060102@redhat.com> <49A84292.1070207@redhat.com> Message-ID: On Fri, Feb 27, 2009 at 11:44 AM, David M. Lloyd wrote: > WeakHashMap, Externalizer>() > > *fails* because Externalizer instances are usually customized to the class > they externalize (which, by the way, could well be a system class). This > means that Externalizer keeps a strong ref to the Class after all. If the class is from a parent class loader, you should just keep a strong reference to the data and not use ClassLoader.keepReferenceTo(). Bob From david.lloyd at redhat.com Fri Feb 27 20:48:08 2009 From: david.lloyd at redhat.com (David M. Lloyd) Date: Fri, 27 Feb 2009 14:48:08 -0600 Subject: [PATCH 0/2] Class- and class loader-local storage (Bug ID #6493635) In-Reply-To: References: <49A83395.80308@redhat.com> <49A83957.3060102@redhat.com> <49A84292.1070207@redhat.com> Message-ID: <49A85188.5060903@redhat.com> On 02/27/2009 02:18 PM, Bob Lee wrote: > On Fri, Feb 27, 2009 at 11:44 AM, David M. Lloyd wrote: >> WeakHashMap, Externalizer>() >> >> *fails* because Externalizer instances are usually customized to the class >> they externalize (which, by the way, could well be a system class). This >> means that Externalizer keeps a strong ref to the Class after all. > > If the class is from a parent class loader, you should just keep a > strong reference to the data and not use > ClassLoader.keepReferenceTo(). I don't think you understood what I wrote - keeping a strong reference to the data defeats the purpose of the mechanism utterly. I'll try to lay it out a little more plainly - 1) I need to associate some data with classes - which can come from anywhere, any class loader. This is not an uncommon requirement. Anyone who has ever written a Map, ?> has realized this requirement. 2) The data may have a strong ref to the class it is associated with. This is a consequence of the purpose of associating data with a class key. 3) The module responsible for establishing the mapping must not maintain a strong reference to the class, to allow that classloader to be collected. 4) The module responsible for establishing the mapping must not maintain a strong reference to the data, to allow the deployment which created the data to be collected. 5) The mapping must remain until a collection of (3) or (4) occurs, or else the purpose of caching data per-class has been defeated. These rules would apply for *ANY* case where one might want to maintain a Map, ?> of any sort. Your solution allows the map, but does not allow the value to be changed or removed - EVER - and if the map is collected, all the values would still hang around. My solution fits the use cases I've provided. I don't understand how it could possibly be OK to *ever* put a permanent reference on to any classloader but your own, without a way to clean it up. And if you're going to do that, just use a static final field. I just don't see the use case that would benefit from such an ability. - DML From openjdk at crazybob.org Fri Feb 27 20:59:25 2009 From: openjdk at crazybob.org (Bob Lee) Date: Fri, 27 Feb 2009 12:59:25 -0800 Subject: [PATCH 0/2] Class- and class loader-local storage (Bug ID #6493635) In-Reply-To: <49A85188.5060903@redhat.com> References: <49A83395.80308@redhat.com> <49A83957.3060102@redhat.com> <49A84292.1070207@redhat.com> <49A85188.5060903@redhat.com> Message-ID: On Fri, Feb 27, 2009 at 12:48 PM, David M. Lloyd wrote: > I don't think you understood what I wrote I understood. I just think you're trying to solve a problem that no one really has. 99% of the time, the problem is with a class from a parent class loader keeping a strong reference to a class in a child class loader. If a class in a child class loader wants to keep a reference to a class in a parent class loader, it can just do so directly--no need for a weak reference. It sounds to me like you want to support both cases at once, but I don't think anyone really has this problem. At least, I've never seen it. If they do, they should: a) redesign their code, or b) keep two maps, one for classes in child loaders (which need weak refs), and one for classes in parent loaders (which don't) Bob From david.lloyd at redhat.com Fri Feb 27 21:12:46 2009 From: david.lloyd at redhat.com (David M. Lloyd) Date: Fri, 27 Feb 2009 15:12:46 -0600 Subject: [PATCH 0/2] Class- and class loader-local storage (Bug ID #6493635) In-Reply-To: References: <49A83395.80308@redhat.com> <49A83957.3060102@redhat.com> <49A84292.1070207@redhat.com> <49A85188.5060903@redhat.com> Message-ID: <49A8574E.1020601@redhat.com> On 02/27/2009 02:59 PM, Bob Lee wrote: > On Fri, Feb 27, 2009 at 12:48 PM, David M. Lloyd wrote: >> I don't think you understood what I wrote > > I understood. I just think you're trying to solve a problem that no > one really has. 99% of the time, the problem is with a class from a > parent class loader keeping a strong reference to a class in a child > class loader. I'm not talking about a parent/child relationship at all. I'm talking about parent, child, AND sibling class loaders. You're presenting a very simplistic view here, but in a real application server, things can get a lot more complex. A class loader for JAR of an implementation of an API might not be visible to anyone else; however the API might be visible from several other deployments. And any deployment who has access to an API can pass data to any other deployment. It's not as simple as you make it out to be - there's not just two use cases. I think what you meant to say is "99% of the time (in Bob Lee's experience, and nobody else's experience matters here)..." You agree that there needs to be a mechanism to store a reference on a classloader. Yet you say that there is no valid use case for removing the reference. I've given you use cases. You reject them because you don't think they're important or common enough. Yet you do not produce a use case which *justifies* the ability to *add* a reference on to the classloader, which does not also cause a problem with leakage. I contend, unequivocally, that there is *no* justification to put a strong reference on any classloader but your own which you cannot again remove; and if you're going to do that, you should just use a static final field. You *must* either demonstrate the utility of such a situation (which, by the way, you just stated is no less than 99 times more common of a use case than the one I propose), or concede that reference removal is required. I don't see any other logical course. - DML From mandy.chung at sun.com Fri Feb 27 21:47:34 2009 From: mandy.chung at sun.com (mandy.chung at sun.com) Date: Fri, 27 Feb 2009 21:47:34 +0000 Subject: hg: jdk7/tl/jdk: 6799689: Make sun.misc.FloatingDecimal.hexFloatPattern static field initialized lazily Message-ID: <20090227214800.8D3CFE3DE@hg.openjdk.java.net> Changeset: de1d02ad2d1d Author: mchung Date: 2009-02-27 13:43 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/de1d02ad2d1d 6799689: Make sun.misc.FloatingDecimal.hexFloatPattern static field initialized lazily Summary: Lazily initialize the hexFloatPattern static field Reviewed-by: darcy ! src/share/classes/sun/misc/FloatingDecimal.java From openjdk at crazybob.org Fri Feb 27 21:51:23 2009 From: openjdk at crazybob.org (Bob Lee) Date: Fri, 27 Feb 2009 13:51:23 -0800 Subject: [PATCH 0/2] Class- and class loader-local storage (Bug ID #6493635) In-Reply-To: <49A8574E.1020601@redhat.com> References: <49A83395.80308@redhat.com> <49A83957.3060102@redhat.com> <49A84292.1070207@redhat.com> <49A85188.5060903@redhat.com> <49A8574E.1020601@redhat.com> Message-ID: There's no need for insults, David. Have some perspective. I've been nothing but civil and respectful (even after you presumed to know what I do and don't understand). On Fri, Feb 27, 2009 at 1:12 PM, David M. Lloyd wrote: > I'm not talking about a parent/child relationship at all. I'm talking > about > parent, child, AND sibling class loaders. You're presenting a very > simplistic view here, but in a real application server, things can get a > lot > more complex. A class loader for JAR of an implementation of an API might > not be visible to anyone else; however the API might be visible from > several > other deployments. And any deployment who has access to an API can pass > data to any other deployment. It's not as simple as you make it out to be > - > there's not just two use cases. > Non-hierarchical class loaders fall under a) in my book--"code that should probably be redesigned." But having used WebSphere in a past life, I realize that's too much to ask. We should probably just wait for ephemerons. I think they alleviate the need for this altogether. With ephemerons, you could have a map of Class -> [some value] where [some value] doesn't prevent Class from being reclaimed. If Class if reclaimed, the reference to [some value] is dropped, too. Bob -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.lloyd at redhat.com Fri Feb 27 22:32:05 2009 From: david.lloyd at redhat.com (David M. Lloyd) Date: Fri, 27 Feb 2009 16:32:05 -0600 Subject: [PATCH 0/2] Class- and class loader-local storage (Bug ID #6493635) In-Reply-To: References: <49A83395.80308@redhat.com> <49A83957.3060102@redhat.com> <49A84292.1070207@redhat.com> <49A85188.5060903@redhat.com> <49A8574E.1020601@redhat.com> Message-ID: <49A869E5.9050102@redhat.com> On 02/27/2009 03:51 PM, Bob Lee wrote: > There's no need for insults, David. Have some perspective. I've been > nothing but civil and respectful (even after you presumed to know what I > do and don't understand). I haven't insulted you that I am aware of, only stated the facts as I see them. Since you haven't responded to any of my points, I can only assume that you do not understand them (which seems unlikely) or you're not interested in understanding (which does imply, among other things, a lack of respect). Being ignored in this way gives a distinct impression that you're not interested in any solution that did not spring from your own mind. Allow me to explain another way. You readily agreed that this problem needs a solution (after all, your presentation of your alternative solution was the start of the thread). But you stated flat out that removal should not be supported (no justification given); then you basically placed the burden on me to justify my position. Now I have no problem with that; I justified myself (more than one time, and quite concisely I thought). But you didn't respond to me at all - instead you circularly argued that my use case was invalid; I demonstrated that my use case could not be invalid without your use case also being invalid; you ignored me (twice) and restated that my use case was not valid without responding to my points. Does this help you understand my position? > Non-hierarchical class loaders fall under a) in my book--"code that > should probably be redesigned." > > But having used WebSphere in a past life, I realize that's too much to ask. Not just websphere - any modern application server or container (think OSGi for another perspective on the same problem). This type of problem is also quite common with frameworks. Any application server which provides any level of isolation between deployments and libraries can and will give rise to a non-hierarchical classloader situation. > We should probably just wait for ephemerons. I think they alleviate the > need for this altogether. With ephemerons, you could have a map of Class > -> [some value] where [some value] doesn't prevent Class from being > reclaimed. If Class if reclaimed, the reference to [some value] is > dropped, too. I like the notion of ephemerons, but unless I'm mistaken, a notion is all they are right now. I think that we could put in place a solution to this problem today, and then migrate the solution to ephemerons later on, if they ever become more than ephemeral. :-) - DML From kevinb at google.com Fri Feb 27 22:50:52 2009 From: kevinb at google.com (Kevin Bourrillion) Date: Fri, 27 Feb 2009 14:50:52 -0800 Subject: [PATCH 0/2] Class- and class loader-local storage (Bug ID #6493635) In-Reply-To: <49A869E5.9050102@redhat.com> References: <49A83957.3060102@redhat.com> <49A84292.1070207@redhat.com> <49A85188.5060903@redhat.com> <49A8574E.1020601@redhat.com> <49A869E5.9050102@redhat.com> Message-ID: <108fcdeb0902271450o4791ce7eq8e5276b2cee673f0@mail.gmail.com> This thread needs a third perspective (which I can't provide for lack of expertise). On Fri, Feb 27, 2009 at 2:32 PM, David M. Lloyd wrote: > On 02/27/2009 03:51 PM, Bob Lee wrote: > >> There's no need for insults, David. Have some perspective. I've been >> nothing but civil and respectful (even after you presumed to know what I do >> and don't understand). >> > > I haven't insulted you that I am aware of, only stated the facts as I see > them. Since you haven't responded to any of my points, I can only assume > that you do not understand them (which seems unlikely) or you're not > interested in understanding (which does imply, among other things, a lack of > respect). Being ignored in this way gives a distinct impression that you're > not interested in any solution that did not spring from your own mind. > > Allow me to explain another way. You readily agreed that this problem > needs a solution (after all, your presentation of your alternative solution > was the start of the thread). But you stated flat out that removal should > not be supported (no justification given); then you basically placed the > burden on me to justify my position. Now I have no problem with that; I > justified myself (more than one time, and quite concisely I thought). But > you didn't respond to me at all - instead you circularly argued that my use > case was invalid; I demonstrated that my use case could not be invalid > without your use case also being invalid; you ignored me (twice) and > restated that my use case was not valid without responding to my points. > > Does this help you understand my position? > > Non-hierarchical class loaders fall under a) in my book--"code that should >> probably be redesigned." >> >> But having used WebSphere in a past life, I realize that's too much to >> ask. >> > > Not just websphere - any modern application server or container (think OSGi > for another perspective on the same problem). This type of problem is also > quite common with frameworks. Any application server which provides any > level of isolation between deployments and libraries can and will give rise > to a non-hierarchical classloader situation. > > We should probably just wait for ephemerons. I think they alleviate the >> need for this altogether. With ephemerons, you could have a map of Class -> >> [some value] where [some value] doesn't prevent Class from being reclaimed. >> If Class if reclaimed, the reference to [some value] is dropped, too. >> > > I like the notion of ephemerons, but unless I'm mistaken, a notion is all > they are right now. I think that we could put in place a solution to this > problem today, and then migrate the solution to ephemerons later on, if they > ever become more than ephemeral. :-) > > - DML > -- Kevin Bourrillion @ Google internal: http://go/javalibraries google-collections.googlecode.com google-guice.googlecode.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mandy.chung at sun.com Sat Feb 28 00:38:07 2009 From: mandy.chung at sun.com (mandy.chung at sun.com) Date: Sat, 28 Feb 2009 00:38:07 +0000 Subject: hg: jdk7/tl/jdk: 6809504: Remove enctype="text/xml" from the offline registration page Message-ID: <20090228003831.99499E477@hg.openjdk.java.net> Changeset: 0da45c759116 Author: mchung Date: 2009-02-27 16:34 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/0da45c759116 6809504: Remove enctype="text/xml" from the offline registration page Summary: Remove enctype="text/xml" from register.html and other localized versions Reviewed-by: ksrini ! src/share/classes/com/sun/servicetag/resources/register.html ! src/share/classes/com/sun/servicetag/resources/register_ja.html ! src/share/classes/com/sun/servicetag/resources/register_zh_CN.html From openjdk at crazybob.org Sat Feb 28 01:09:03 2009 From: openjdk at crazybob.org (Bob Lee) Date: Fri, 27 Feb 2009 17:09:03 -0800 Subject: [PATCH 0/2] Class- and class loader-local storage (Bug ID #6493635) In-Reply-To: <49A869E5.9050102@redhat.com> References: <49A83957.3060102@redhat.com> <49A84292.1070207@redhat.com> <49A85188.5060903@redhat.com> <49A8574E.1020601@redhat.com> <49A869E5.9050102@redhat.com> Message-ID: David, I regret making my suggestion in the first place. I really think we need ephemerons, but for the sake of discussion: - Your patch adds 2 new classes. My suggestion adds one method (maybe 2 for convenience). - Your approach enables explicit clearing, but I thought the whole point of adding this extension was to avoid explicit clearing. If you're going to explicitly clear, why do you need this functionality at all? If we want to support circular dependencies between class loaders, we should pursue ephemerons because your solution requires explicit clearing whereas ephemerons would not. - Say for example that I need a static map from Class to List (some filtered list of methods in Class). Your patch requires one WeakHashMap per Class. My suggestion requires only one map total and one lightweight data structure per ClassLoader. - Your patch forces users to use your data structure. My suggestion enables users to use whatever data structure they like. Your patch introduces a point of contention between completely orthogonal libraries. Mine introduces almost none (assuming you implement the internal data structure in a non-locking fashion). Bob -------------- next part -------------- An HTML attachment was scrubbed... URL: From bhavesh.patel at sun.com Sat Feb 28 03:01:50 2009 From: bhavesh.patel at sun.com (bhavesh.patel at sun.com) Date: Sat, 28 Feb 2009 03:01:50 +0000 Subject: hg: jdk7/tl/langtools: 6786690: Javadoc HTML WCAG 2.0 accessibility issues in standard doclet - DL tag and nesting issue Message-ID: <20090228030154.74B22E48B@hg.openjdk.java.net> Changeset: 5240b1120530 Author: bpatel Date: 2009-02-27 18:57 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/5240b1120530 6786690: Javadoc HTML WCAG 2.0 accessibility issues in standard doclet - DL tag and nesting issue Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractMemberWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeOptionalMemberWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeRequiredMemberWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ClassWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ConstructorWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/EnumConstantWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/FieldWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlSerialFieldWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlSerialMethodWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/MethodWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/NestedClassWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageTreeWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/TagletWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/TreeWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlDocWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/SerializedFormWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/SerializedFormBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclet.xml ! test/com/sun/javadoc/AuthorDD/AuthorDD.java ! test/com/sun/javadoc/testClassCrossReferences/TestClassCrossReferences.java ! test/com/sun/javadoc/testConstructorIndent/TestConstructorIndent.java ! test/com/sun/javadoc/testDeprecatedDocs/TestDeprecatedDocs.java ! test/com/sun/javadoc/testExternalOverridenMethod/TestExternalOverridenMethod.java ! test/com/sun/javadoc/testHref/TestHref.java + test/com/sun/javadoc/testHtmlDefinitionListTag/TestHtmlDefinitionListTag.java + test/com/sun/javadoc/testHtmlDefinitionListTag/pkg1/C1.java + test/com/sun/javadoc/testHtmlDefinitionListTag/pkg1/C2.java + test/com/sun/javadoc/testHtmlDefinitionListTag/pkg1/C3.java + test/com/sun/javadoc/testHtmlDefinitionListTag/pkg1/C4.java + test/com/sun/javadoc/testHtmlDefinitionListTag/pkg1/C5.java ! test/com/sun/javadoc/testIndex/TestIndex.java ! test/com/sun/javadoc/testInterface/TestInterface.java ! test/com/sun/javadoc/testLinkOption/TestLinkOption.java ! test/com/sun/javadoc/testLinkTaglet/TestLinkTaglet.java ! test/com/sun/javadoc/testMemberInheritence/TestMemberInheritence.java ! test/com/sun/javadoc/testNewLanguageFeatures/TestNewLanguageFeatures.java ! test/com/sun/javadoc/testOverridenMethods/TestOverridenPrivateMethods.java ! test/com/sun/javadoc/testOverridenMethods/TestOverridenPrivateMethodsWithPackageFlag.java ! test/com/sun/javadoc/testOverridenMethods/TestOverridenPrivateMethodsWithPrivateFlag.java ! test/com/sun/javadoc/testParamTaglet/TestParamTaglet.java ! test/com/sun/javadoc/testPrivateClasses/TestPrivateClasses.java ! test/com/sun/javadoc/testSerializedFormDeprecationInfo/TestSerializedFormDeprecationInfo.java ! test/com/sun/javadoc/testThrowsTag/TestThrowsTag.java