From kalli at midverk.is Mon Apr 5 13:29:01 2010 From: kalli at midverk.is (Karl Helgason) Date: Mon, 5 Apr 2010 20:29:01 +0000 Subject: [Request for review and bugid] A collection of fixes for gervill (2010-04) Message-ID: <36EC82E93EB0AD40A4301DAD654323860146CD9D88F8@mail.midverk.is> Hi, I need code review and bugid for the fix: http://cr.openjdk.java.net/~kalli/gervill-update/webrev.01/ Major fixes this webrev includes are: * Allow access to cached emergency soundbank using AccessController.doPrivileged This fix allows using cached emergency soundbank in applets which speeds up loading of applets especially on slow computers. And also using AccessController.doPrivileged we can use user-installed soundfonts in applets e.g. soundfonts found in audio folder of JRE. * Support for user config file. Default settings for Gervill don't always suit everybody, some needed lower latency, different samplerate and e.t.c To fix that a support to allow user to change default settings using Preferences API was added. * Fixed how getAvailableInstruments and getLoadedInstruments worked. SoftSynthesizer.getAvailableInstruments now always returns instruments from default soundbank. And getLoadedInstruments now always returns loaded instruments. The behavior of these methods where not correct. * Improved support for large soundbanks a) Indexed version of ModelStandardDirector added which speeds up looking up notes in instruments with many layers. b) Allow unused instrument to be garbage collected more easily, we now put null value to unused variable. c) Prevent unnecessary lookup of instrument object on pseudo program change (when bank and program is unchanged) * Enable user to disable loading default soundbank. Some users wanted to be able to open the synthesizer without the synthesizer loading the default soundbank. And then there was several other bug fixes: * Fix: Synchronization bug in n SoftSynthesizer.getDefaultSoundbank * Fix: AudioFloatInputStreamResampler.skip broken * Fix: RealTime scale/octave tuning doesn't affect sounding notes. * Fix: ModelByteBufferWaveTable.openStream().getFrameLength() returns incorrect values in some cases. Heres complete list of changes made: - Fix: Use AccessController.doPrivileged to access user settings and cached emergency soundbank. Affected File/Method: SoftSynthesizer.getDefaultSoundbank - Add: Support for user config file. Affected File/Method: SoftSynthesizer.getPropertyInfo - Add: Let SoftSynthesizer.getPropertyInfo use type conversion when needed. JTreg test added: /test/SoftSynthesizer/GetPropertyInfo - Add: Enable user to disable loading default soundbank. Affected File/Method: SoftSynthesizer.getPropertyInfo SoftSynthesizer.processPropertyInfo SoftSynthesizer.openStream JTreg test added: /test/SoftSynthesizer/TestDisableLoadDefaultSoundbank - Fix: SoftSynthesizer.getAvailableInstruments should always return instruments from default soundbank. Affected File/Method: SoftSynthesizer.getAvailableInstruments JTreg test added: /test/SoftSynthesizer/GetAvailableInstruments2 - Fix: SoftSynthesizer.getLoadedInstruments should always return loaded instrument. Affected File/Method: SoftSynthesizer.getLoadedInstruments JTreg test added: /test/SoftSynthesizer/GetLoadedInstruments2 JTreg tests fixed: /test/SoftSynthesizer/LoadAllInstruments /test/SoftSynthesizer/LoadInstrument /test/SoftSynthesizer/LoadInstruments /test/SoftSynthesizer/RemapInstrument * this test never worked correctly /test/SoftSynthesizer/UnloadAllInstruments /test/SoftSynthesizer/UnloadInstrument /test/SoftSynthesizer/UnloadInstruments - Fix: SoftSynthesizer.getDefaultSoundbank is not properly synchronized. Affected File/Method: SoftSynthesizer.getDefaultSoundbank - Optimization: Indexed version of ModelStandardDirector added. - Optimization: Fully unload instruments by setting null to unused values. Affected Files: SoftVoice, SoftChannel, SoftSynthesizer - Optimization: Prevent unnecessary lookup of instrument object on pseudo program change (when bank and program is unchanged) Affected File/Method: SoftChannel.programChange - Fix: AudioFloatInputStreamResampler.skip broken. (Gervill Bug Issues 5) see: https://gervill.dev.java.net/issues/show_bug.cgi?id=5 Affected File/Method: AudioFloatFormatConverter.AudioFloatInputStreamResampler.skip JTreg test added: /test/AudioFloatFormatConverter/SkipTest - Fix: ModelByteBufferWaveTable.openStream().getFrameLength() returns incorrect values in some cases. (Gervill Bug Issues 4) see: https://gervill.dev.java.net/issues/show_bug.cgi?id=4 Affected File/Method: ModelByteBufferWaveTable.openStream JTreg test added: /test/ModelByteBufferWavetable/OpenStream - Fix: RealTime scale/octave tuning doesn't affect sounding notes. Affected File/Method: SoftVoice.updateTuning JTreg test added: /test/ModelByteBufferWavetable/OpenStream From joe.darcy at oracle.com Mon Apr 5 18:43:25 2010 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 05 Apr 2010 18:43:25 -0700 Subject: Test Backports In-Reply-To: References: <17c6771e1003291310u3e1b3231i6a054fd76bc24182@mail.gmail.com> <4BB112FD.9070702@oracle.com> <17c6771e1003291849m7d920b2ey7e4b15bd0f748a0a@mail.gmail.com> <4BB3ABEE.4070102@oracle.com> Message-ID: <4BBA91BD.8020105@oracle.com> On 03/31/10 02:41 PM, Andrew John Hughes wrote: > On 31 March 2010 20:09, Joe Darcy wrote: > >> Andrew John Hughes wrote: >> >>> On 29 March 2010 20:52, Joe Darcy wrote: >>> >>> >>>> Andrew John Hughes wrote: >>>> >>>> >>>>> There are a set of bidi and math tests: >>>>> >>>>> changeset: 817:8ea49fa4c2f7 >>>>> user: peytoia >>>>> date: Fri Oct 17 13:34:03 2008 +0900 >>>>> summary: 6759521: Move Bidi test programs from closed to open. >>>>> >>>>> http://hg.openjdk.java.net/jdk7/jdk7/jdk/rev/8ea49fa4c2f7 >>>>> >>>>> >>>>> >>>> I approve the bidi tests going back; please verify they pass first though >>>> :-) >>>> >>>> >>>> >>> Passed and pushed; >>> http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/e1549056d958 >>> >>> >> Thanks. >> >> >>>>> changeset: 809:f3ad2ee4600b >>>>> user: darcy >>>>> date: Mon Jan 26 19:49:26 2009 -0800 >>>>> description: >>>>> 6601457: Move wrapper class tests from closed to open >>>>> 6601458: Move java.math tests from closed to open >>>>> 6740185: Move java/lang/annotations tests to open >>>>> 6759433: Move Math and StrictMath regression tests from closed to open >>>>> Summary: Move some more regression tests to the open >>>>> Reviewed-by: jjg >>>>> >>>>> http://hg.openjdk.java.net/jdk7/jdk7/jdk/rev/f3ad2ee4600b >>>>> >>>>> that were opened up in OpenJDK7. Ok to backport these to 6? >>>>> >>>>> >>>>> >>>> However, I deny these other tests being backported since they have long >>>> been >>>> in OpenJDK 6 :-) >>>> >>>> >>>> >>> Doh! Looks like they were still lurking around in the IcedTea tree >>> but no longer being applied. >>> >>> I found a bunch of others too: >>> >>> comparing with ssh://hg.openjdk.java.net/jdk6/jdk6-gate/jdk >>> searching for changes >>> changeset: 308:d5dc9130bdb0 >>> user: volk >>> date: Sun Apr 13 23:41:40 2008 +0400 >>> summary: 6686273: Some AWT reg. tests should be moved to open >>> repository (for CRs 6444769, 6480547, and 6560348) >>> >>> changeset: 309:fa6cfc27b519 >>> user: ant >>> date: Wed Mar 26 16:20:01 2008 +0300 >>> summary: 6680135: A number of test/closed/java/awt/Focus/* tests >>> should be opened >>> >>> changeset: 310:285a274f844a >>> user: sherman >>> date: Mon Jun 30 14:06:34 2008 -0700 >>> summary: 6675856: Open charset tests >>> >>> changeset: 311:47f907e9c9b3 >>> user: malenkov >>> date: Thu Jun 26 15:11:04 2008 +0400 >>> summary: 6718964: Swing border tests should be open source >>> >>> changeset: 312:a6d7e84e31e1 >>> user: malenkov >>> date: Thu Jun 26 15:39:12 2008 +0400 >>> summary: 6718965: Swing color chooser tests should be open source >>> >>> changeset: 313:62168e9450f9 >>> user: sherman >>> date: Thu Aug 13 15:01:18 2009 -0700 >>> summary: 6676423: (prefs) Opensource unit/regression tests for >>> java.util.prefs >>> >>> changeset: 314:83980d94b138 >>> tag: tip >>> user: sherman >>> date: Wed Jan 27 19:39:55 2010 -0800 >>> summary: 6920732: opensource test/java/nio/charset >>> >>> Ok to backport? The majority pass, with the failures being in the AWT >>> ones (may be my setup, as some of the existing ones fail too) and >>> prefs (I think it's trying to acquire a lock on a NFS mount). >>> >>> >> Yes in principle, but let me dig into the particular changes a bit to >> double-check they're applicable to and appropriate for OpenJDK 6. >> >> > > Ok, the comments suggested to me they were forwardports from the > proprietary tree but good to check. > I've looked over each of these patches, and they all seem applicable to OpenJDK 6 so I approve all of them going back. (It is feasible a patch would be applicable to a portion of the proprietary JDK 7, but not applicable to the corresponding portion of OpenJDK 6.) > On my queue, I have four more Zero patches and a set of backports I'd > like in (making the source/target explicit as we did in 7 already, and > Kelly's ant 1.8 patch). Everything else can wait until b20 Sounds good. Cheers, -Joe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/jdk6-dev/attachments/20100405/1b7742fa/attachment.html From joe.darcy at oracle.com Mon Apr 5 19:20:37 2010 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Mon, 05 Apr 2010 19:20:37 -0700 Subject: [Request for review and bugid] A collection of fixes for gervill (2010-04) In-Reply-To: <36EC82E93EB0AD40A4301DAD654323860146CD9D88F8@mail.midverk.is> References: <36EC82E93EB0AD40A4301DAD654323860146CD9D88F8@mail.midverk.is> Message-ID: <4BBA9A75.5060408@oracle.com> Hello. I've filed bug 6941027 "Gervill update, April 2010" for this work. However, I will leave Alexey to do the actual code reviewing for OpenJDK 6 and JDK 7. Note that test/javax/sound/midi/Gervill/AudioFloatFormatConverter/SkipTest.java doesn't have a newline at the end of the file. -Joe On 4/5/2010 1:29 PM, Karl Helgason wrote: > Hi, > > I need code review and bugid for the fix: > http://cr.openjdk.java.net/~kalli/gervill-update/webrev.01/ > > Major fixes this webrev includes are: > > * Allow access to cached emergency soundbank using AccessController.doPrivileged > This fix allows using cached emergency soundbank in applets > which speeds up loading of applets especially on slow computers. > And also using AccessController.doPrivileged we can use user-installed > soundfonts in applets e.g. soundfonts found in audio folder of JRE. > > * Support for user config file. > Default settings for Gervill don't always suit everybody, > some needed lower latency, different samplerate and e.t.c > To fix that a support to allow user to change default settings using > Preferences API was added. > > * Fixed how getAvailableInstruments and getLoadedInstruments worked. > SoftSynthesizer.getAvailableInstruments now always returns instruments > from default soundbank. And getLoadedInstruments now always returns > loaded instruments. The behavior of these methods where not correct. > > * Improved support for large soundbanks > a) Indexed version of ModelStandardDirector added which speeds up > looking up notes in instruments with many layers. > b) Allow unused instrument to be garbage collected more easily, > we now put null value to unused variable. > c) Prevent unnecessary lookup of instrument object > on pseudo program change (when bank and program is unchanged) > > * Enable user to disable loading default soundbank. > Some users wanted to be able to open the synthesizer > without the synthesizer loading the default soundbank. > > And then there was several other bug fixes: > * Fix: Synchronization bug in n SoftSynthesizer.getDefaultSoundbank > * Fix: AudioFloatInputStreamResampler.skip broken > * Fix: RealTime scale/octave tuning doesn't affect sounding notes. > * Fix: ModelByteBufferWaveTable.openStream().getFrameLength() > returns incorrect values in some cases. > > Heres complete list of changes made: > - Fix: Use AccessController.doPrivileged to access user settings > and cached emergency soundbank. > Affected File/Method: SoftSynthesizer.getDefaultSoundbank > - Add: Support for user config file. > Affected File/Method: SoftSynthesizer.getPropertyInfo > - Add: Let SoftSynthesizer.getPropertyInfo use type conversion when needed. > JTreg test added: > /test/SoftSynthesizer/GetPropertyInfo > - Add: Enable user to disable loading default soundbank. > Affected File/Method: SoftSynthesizer.getPropertyInfo > SoftSynthesizer.processPropertyInfo > SoftSynthesizer.openStream > JTreg test added: > /test/SoftSynthesizer/TestDisableLoadDefaultSoundbank > - Fix: SoftSynthesizer.getAvailableInstruments should > always return instruments from default soundbank. > Affected File/Method: SoftSynthesizer.getAvailableInstruments > JTreg test added: > /test/SoftSynthesizer/GetAvailableInstruments2 > - Fix: SoftSynthesizer.getLoadedInstruments should always > return loaded instrument. > Affected File/Method: SoftSynthesizer.getLoadedInstruments > JTreg test added: > /test/SoftSynthesizer/GetLoadedInstruments2 > JTreg tests fixed: > /test/SoftSynthesizer/LoadAllInstruments > /test/SoftSynthesizer/LoadInstrument > /test/SoftSynthesizer/LoadInstruments > /test/SoftSynthesizer/RemapInstrument > * this test never worked correctly > /test/SoftSynthesizer/UnloadAllInstruments > /test/SoftSynthesizer/UnloadInstrument > /test/SoftSynthesizer/UnloadInstruments > - Fix: SoftSynthesizer.getDefaultSoundbank is not properly synchronized. > Affected File/Method: SoftSynthesizer.getDefaultSoundbank > - Optimization: Indexed version of ModelStandardDirector added. > - Optimization: Fully unload instruments by setting null to unused values. > Affected Files: SoftVoice, SoftChannel, SoftSynthesizer > - Optimization: Prevent unnecessary lookup of instrument object > on pseudo program change (when bank and program is unchanged) > Affected File/Method: SoftChannel.programChange > - Fix: AudioFloatInputStreamResampler.skip broken. > (Gervill Bug Issues 5) > see: https://gervill.dev.java.net/issues/show_bug.cgi?id=5 > Affected File/Method: > AudioFloatFormatConverter.AudioFloatInputStreamResampler.skip > JTreg test added: > /test/AudioFloatFormatConverter/SkipTest > - Fix: ModelByteBufferWaveTable.openStream().getFrameLength() > returns incorrect values in some cases. > (Gervill Bug Issues 4) > see: https://gervill.dev.java.net/issues/show_bug.cgi?id=4 > Affected File/Method: ModelByteBufferWaveTable.openStream > JTreg test added: > /test/ModelByteBufferWavetable/OpenStream > - Fix: RealTime scale/octave tuning doesn't affect sounding notes. > Affected File/Method: SoftVoice.updateTuning > JTreg test added: > /test/ModelByteBufferWavetable/OpenStream > From kalli at midverk.is Tue Apr 6 00:56:31 2010 From: kalli at midverk.is (Karl Helgason) Date: Tue, 6 Apr 2010 07:56:31 +0000 Subject: SV: [Request for review and bugid] A collection of fixes for gervill (2010-04) In-Reply-To: <4BBA9A75.5060408@oracle.com> References: <36EC82E93EB0AD40A4301DAD654323860146CD9D88F8@mail.midverk.is>, <4BBA9A75.5060408@oracle.com> Message-ID: <36EC82E93EB0AD40A4301DAD654323860146CD9D88F9@mail.midverk.is> Hi, I added the missing "newline at the end of the file" to both SkipTest.java and ModelStandardIndexedDirector.java. http://cr.openjdk.java.net/~kalli/gervill-update/webrev.02/ regards, Karl ________________________________________ Fr?: joe.darcy at oracle.com [joe.darcy at oracle.com] Sent: 6. apr?l 2010 02:20 Vi?takandi: Karl Helgason Afrit: jdk6-dev at openjdk.java.net; alexey.menkov at sun.com; joe.darcy at sun.com; Dalibor.Topic at Sun.COM Efni: Re: [Request for review and bugid] A collection of fixes for gervill (2010-04) Hello. I've filed bug 6941027 "Gervill update, April 2010" for this work. However, I will leave Alexey to do the actual code reviewing for OpenJDK 6 and JDK 7. Note that test/javax/sound/midi/Gervill/AudioFloatFormatConverter/SkipTest.java doesn't have a newline at the end of the file. -Joe On 4/5/2010 1:29 PM, Karl Helgason wrote: > Hi, > > I need code review and bugid for the fix: > http://cr.openjdk.java.net/~kalli/gervill-update/webrev.01/ > > Major fixes this webrev includes are: > > * Allow access to cached emergency soundbank using AccessController.doPrivileged > This fix allows using cached emergency soundbank in applets > which speeds up loading of applets especially on slow computers. > And also using AccessController.doPrivileged we can use user-installed > soundfonts in applets e.g. soundfonts found in audio folder of JRE. > > * Support for user config file. > Default settings for Gervill don't always suit everybody, > some needed lower latency, different samplerate and e.t.c > To fix that a support to allow user to change default settings using > Preferences API was added. > > * Fixed how getAvailableInstruments and getLoadedInstruments worked. > SoftSynthesizer.getAvailableInstruments now always returns instruments > from default soundbank. And getLoadedInstruments now always returns > loaded instruments. The behavior of these methods where not correct. > > * Improved support for large soundbanks > a) Indexed version of ModelStandardDirector added which speeds up > looking up notes in instruments with many layers. > b) Allow unused instrument to be garbage collected more easily, > we now put null value to unused variable. > c) Prevent unnecessary lookup of instrument object > on pseudo program change (when bank and program is unchanged) > > * Enable user to disable loading default soundbank. > Some users wanted to be able to open the synthesizer > without the synthesizer loading the default soundbank. > > And then there was several other bug fixes: > * Fix: Synchronization bug in n SoftSynthesizer.getDefaultSoundbank > * Fix: AudioFloatInputStreamResampler.skip broken > * Fix: RealTime scale/octave tuning doesn't affect sounding notes. > * Fix: ModelByteBufferWaveTable.openStream().getFrameLength() > returns incorrect values in some cases. > > Heres complete list of changes made: > - Fix: Use AccessController.doPrivileged to access user settings > and cached emergency soundbank. > Affected File/Method: SoftSynthesizer.getDefaultSoundbank > - Add: Support for user config file. > Affected File/Method: SoftSynthesizer.getPropertyInfo > - Add: Let SoftSynthesizer.getPropertyInfo use type conversion when needed. > JTreg test added: > /test/SoftSynthesizer/GetPropertyInfo > - Add: Enable user to disable loading default soundbank. > Affected File/Method: SoftSynthesizer.getPropertyInfo > SoftSynthesizer.processPropertyInfo > SoftSynthesizer.openStream > JTreg test added: > /test/SoftSynthesizer/TestDisableLoadDefaultSoundbank > - Fix: SoftSynthesizer.getAvailableInstruments should > always return instruments from default soundbank. > Affected File/Method: SoftSynthesizer.getAvailableInstruments > JTreg test added: > /test/SoftSynthesizer/GetAvailableInstruments2 > - Fix: SoftSynthesizer.getLoadedInstruments should always > return loaded instrument. > Affected File/Method: SoftSynthesizer.getLoadedInstruments > JTreg test added: > /test/SoftSynthesizer/GetLoadedInstruments2 > JTreg tests fixed: > /test/SoftSynthesizer/LoadAllInstruments > /test/SoftSynthesizer/LoadInstrument > /test/SoftSynthesizer/LoadInstruments > /test/SoftSynthesizer/RemapInstrument > * this test never worked correctly > /test/SoftSynthesizer/UnloadAllInstruments > /test/SoftSynthesizer/UnloadInstrument > /test/SoftSynthesizer/UnloadInstruments > - Fix: SoftSynthesizer.getDefaultSoundbank is not properly synchronized. > Affected File/Method: SoftSynthesizer.getDefaultSoundbank > - Optimization: Indexed version of ModelStandardDirector added. > - Optimization: Fully unload instruments by setting null to unused values. > Affected Files: SoftVoice, SoftChannel, SoftSynthesizer > - Optimization: Prevent unnecessary lookup of instrument object > on pseudo program change (when bank and program is unchanged) > Affected File/Method: SoftChannel.programChange > - Fix: AudioFloatInputStreamResampler.skip broken. > (Gervill Bug Issues 5) > see: https://gervill.dev.java.net/issues/show_bug.cgi?id=5 > Affected File/Method: > AudioFloatFormatConverter.AudioFloatInputStreamResampler.skip > JTreg test added: > /test/AudioFloatFormatConverter/SkipTest > - Fix: ModelByteBufferWaveTable.openStream().getFrameLength() > returns incorrect values in some cases. > (Gervill Bug Issues 4) > see: https://gervill.dev.java.net/issues/show_bug.cgi?id=4 > Affected File/Method: ModelByteBufferWaveTable.openStream > JTreg test added: > /test/ModelByteBufferWavetable/OpenStream > - Fix: RealTime scale/octave tuning doesn't affect sounding notes. > Affected File/Method: SoftVoice.updateTuning > JTreg test added: > /test/ModelByteBufferWavetable/OpenStream > From ahughes at redhat.com Tue Apr 6 03:58:43 2010 From: ahughes at redhat.com (ahughes at redhat.com) Date: Tue, 06 Apr 2010 10:58:43 +0000 Subject: hg: jdk6/jdk6/jdk: 8 new changesets Message-ID: <20100406110044.38A73443E8@hg.openjdk.java.net> Changeset: d5dc9130bdb0 Author: volk Date: 2008-04-13 23:41 +0400 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/d5dc9130bdb0 6686273: Some AWT reg. tests should be moved to open repository (for CRs 6444769, 6480547, and 6560348) Summary: Some AWT reg. tests are moved to open repository (for CRs 6444769, 6480547, and 6560348) Reviewed-by: ant + test/java/awt/Insets/WindowWithWarningTest/WindowWithWarningTest.html + test/java/awt/Insets/WindowWithWarningTest/WindowWithWarningTest.java + test/java/awt/TextField/ScrollSelectionTest/ScrollSelectionTest.html + test/java/awt/TextField/ScrollSelectionTest/ScrollSelectionTest.java + test/java/awt/xembed/server/JavaClient.java + test/java/awt/xembed/server/RunTestXEmbed.java + test/java/awt/xembed/server/TestXEmbedServer.java + test/java/awt/xembed/server/TestXEmbedServerJava.java + test/java/awt/xembed/server/TesterClient.java Changeset: fa6cfc27b519 Author: ant Date: 2008-03-26 16:20 +0300 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/fa6cfc27b519 6680135: A number of test/closed/java/awt/Focus/* tests should be opened Summary: The tests moved from the closed repository. Reviewed-by: son + test/java/awt/Focus/ActualFocusedWindowTest/ActualFocusedWindowBlockingTest.java + test/java/awt/Focus/ActualFocusedWindowTest/ActualFocusedWindowRetaining.java + test/java/awt/Focus/AppletInitialFocusTest/AppletInitialFocusTest.html + test/java/awt/Focus/AppletInitialFocusTest/AppletInitialFocusTest.java + test/java/awt/Focus/AppletInitialFocusTest/AppletInitialFocusTest1.html + test/java/awt/Focus/AppletInitialFocusTest/AppletInitialFocusTest1.java + test/java/awt/Focus/FrameJumpingToMouse/FrameJumpingToMouse.java + test/java/awt/Focus/NonFocusableWindowTest/NonfocusableOwnerTest.java + test/java/awt/Focus/NonFocusableWindowTest/Test.java + test/java/awt/Focus/TypeAhead/TestFocusFreeze.java + test/java/awt/Focus/WrongKeyTypedConsumedTest/WrongKeyTypedConsumedTest.java Changeset: 285a274f844a Author: sherman Date: 2008-06-30 14:06 -0700 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/285a274f844a 6675856: Open charset tests Summary: Moved non-confidiential test cased from closed repo to open repo Reviewed-by: martin + test/sun/nio/cs/BufferUnderflowEUCTWTest.java + test/sun/nio/cs/CheckCaseInsensitiveEncAliases.java + test/sun/nio/cs/CheckHistoricalNames.java + test/sun/nio/cs/ConvertSingle.java + test/sun/nio/cs/Decode.java + test/sun/nio/cs/DecoderOverflow.java + test/sun/nio/cs/EUCJPUnderflowDecodeTest.java + test/sun/nio/cs/EucJpLinux0212.java + test/sun/nio/cs/EucJpLinuxDecoderRecoveryTest.java + test/sun/nio/cs/EuroConverter.java + test/sun/nio/cs/FindASCIICodingBugs.java + test/sun/nio/cs/FindASCIIRangeCodingBugs.java + test/sun/nio/cs/FindCanEncodeBugs.java + test/sun/nio/cs/FindDecoderBugs.java + test/sun/nio/cs/FindEncoderBugs.java + test/sun/nio/cs/FindOneCharEncoderBugs.java + test/sun/nio/cs/HWKatakanaMS932EncodeTest.java + test/sun/nio/cs/ISCIITest.java + test/sun/nio/cs/ISO2022JP.trailEsc + test/sun/nio/cs/ISO8859x.java + test/sun/nio/cs/JISAutoDetectTest.java + test/sun/nio/cs/LatinCharReplacementTWTest.java + test/sun/nio/cs/LeftOverSurrogate.java + test/sun/nio/cs/MalformedSurrogates.java + test/sun/nio/cs/NIOJISAutoDetectTest.java + test/sun/nio/cs/ReadZero.java + test/sun/nio/cs/SJISCanEncode.java + test/sun/nio/cs/StreamEncoderClose.java + test/sun/nio/cs/SurrogateGB18030Test.java + test/sun/nio/cs/SurrogateTestEUCTW.java + test/sun/nio/cs/SurrogateTestEUCTW.plane15.surrogates + test/sun/nio/cs/SurrogateTestEUCTW.plane3.surrogates + test/sun/nio/cs/SurrogateTestEUCTW.plane4.surrogates + test/sun/nio/cs/SurrogateTestEUCTW.plane5.surrogates + test/sun/nio/cs/SurrogateTestEUCTW.plane6.surrogates + test/sun/nio/cs/SurrogateTestEUCTW.plane7.surrogates + test/sun/nio/cs/SurrogateTestHKSCS.java + test/sun/nio/cs/Test4200310.sh + test/sun/nio/cs/Test4206507.java + test/sun/nio/cs/Test6254467.java + test/sun/nio/cs/Test6275027.java + test/sun/nio/cs/Test6392804.java + test/sun/nio/cs/TestCompoundTest.java + test/sun/nio/cs/TestConverterDroppedCharacters.java + test/sun/nio/cs/TestCp834_SBCS.java + test/sun/nio/cs/TestCp93xSISO.java + test/sun/nio/cs/TestIBMBugs.java + test/sun/nio/cs/TestISCII91.java + test/sun/nio/cs/TestISO2022CNDecoder.java + test/sun/nio/cs/TestISO2022JP.java + test/sun/nio/cs/TestISO2022JPEncoder.java + test/sun/nio/cs/TestISO2022JPSubBytes.java + test/sun/nio/cs/TestIllegalISO2022Esc.java + test/sun/nio/cs/TestIllegalSJIS.java + test/sun/nio/cs/TestJIS0208Decoder.java + test/sun/nio/cs/TestJIS0212Decoder.java + test/sun/nio/cs/TestMS5022X.java + test/sun/nio/cs/TestMiscEUC_JP.java + test/sun/nio/cs/TestSJIS0213.java + test/sun/nio/cs/TestTrailingEscapesISO2022JP.java + test/sun/nio/cs/TestUTF8BOM.java + test/sun/nio/cs/TestUTF_16.java + test/sun/nio/cs/TestUTF_32.java + test/sun/nio/cs/TestUni2HKSCS.java + test/sun/nio/cs/TestX11JIS0201.java + test/sun/nio/cs/UkrainianIsNotRussian.java + test/sun/nio/cs/ZeroedByteArrayEUCTWTest.java Changeset: 47f907e9c9b3 Author: malenkov Date: 2008-06-26 15:11 +0400 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/47f907e9c9b3 6718964: Swing border tests should be open source Reviewed-by: peterz + test/javax/swing/border/Test4120351.java + test/javax/swing/border/Test4124729.java + test/javax/swing/border/Test4243289.html + test/javax/swing/border/Test4243289.java + test/javax/swing/border/Test4247606.html + test/javax/swing/border/Test4247606.java + test/javax/swing/border/Test4252164.html + test/javax/swing/border/Test4252164.java + test/javax/swing/border/Test6461042.java Changeset: a6d7e84e31e1 Author: malenkov Date: 2008-06-26 15:39 +0400 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/a6d7e84e31e1 6718965: Swing color chooser tests should be open source Reviewed-by: peterz + test/javax/swing/JColorChooser/Test4165217.java + test/javax/swing/JColorChooser/Test4177735.java + test/javax/swing/JColorChooser/Test4193384.java + test/javax/swing/JColorChooser/Test4234761.java + test/javax/swing/JColorChooser/Test4380468.html + test/javax/swing/JColorChooser/Test4380468.java + test/javax/swing/JColorChooser/Test4461329.java + test/javax/swing/JColorChooser/Test4711996.java + test/javax/swing/JColorChooser/Test4759306.html + test/javax/swing/JColorChooser/Test4759306.java + test/javax/swing/JColorChooser/Test4759934.html + test/javax/swing/JColorChooser/Test4759934.java + test/javax/swing/JColorChooser/Test4887836.html + test/javax/swing/JColorChooser/Test4887836.java Changeset: 62168e9450f9 Author: sherman Date: 2009-08-13 15:01 -0700 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/62168e9450f9 6676423: (prefs) Opensource unit/regression tests for java.util.prefs Summary: Moved the existing test cases for prefs to open area Reviewed-by: martin, alanb + test/java/util/prefs/CommentsInXml.java + test/java/util/prefs/ConflictInFlush.java + test/java/util/prefs/ExportNode.java + test/java/util/prefs/ExportSubtree.java + test/java/util/prefs/PrefsSpi.java + test/java/util/prefs/PrefsSpi.sh + test/java/util/prefs/RemoveReadOnlyNode.java + test/java/util/prefs/RemoveUnregedListener.java + test/java/util/prefs/SerializeExceptions.java Changeset: 83980d94b138 Author: sherman Date: 2010-01-27 19:39 -0800 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/83980d94b138 6920732: opensource test/java/nio/charset Summary: move the test cases to openjdk Reviewed-by: martin + test/java/nio/charset/Charset/AvailableCharsetNames.java + test/java/nio/charset/Charset/CharsetContainmentTest.java + test/java/nio/charset/Charset/Contains.java + test/java/nio/charset/Charset/Default.java + test/java/nio/charset/Charset/EmptyCharsetName.java + test/java/nio/charset/Charset/EncDec.java + test/java/nio/charset/Charset/IllegalCharsetName.java + test/java/nio/charset/Charset/NIOCharsetAvailabilityTest.java + test/java/nio/charset/Charset/NullCharsetName.java + test/java/nio/charset/Charset/RegisteredCharsets.java + test/java/nio/charset/Charset/default.sh + test/java/nio/charset/CharsetDecoder/AverageMax.java + test/java/nio/charset/CharsetDecoder/EmptyInput.java + test/java/nio/charset/CharsetEncoder/CanEncode.java + test/java/nio/charset/CharsetEncoder/Flush.java + test/java/nio/charset/RemovingSunIO/SunioAlias.java + test/java/nio/charset/RemovingSunIO/TestCOMP.java + test/java/nio/charset/RemovingSunIO/TestUnmappableForLength.java + test/java/nio/charset/coders/BashCache.java + test/java/nio/charset/coders/BashStreams.java + test/java/nio/charset/coders/Check.java + test/java/nio/charset/coders/CheckSJISMappingProp.sh + test/java/nio/charset/coders/Errors.java + test/java/nio/charset/coders/FullRead.java + test/java/nio/charset/coders/IOCoders.java + test/java/nio/charset/coders/IsLegalReplacement.java + test/java/nio/charset/coders/ResetISO2022JP.java + test/java/nio/charset/coders/SJISPropTest.java + test/java/nio/charset/coders/StreamTimeout.java + test/java/nio/charset/coders/Surrogate.java + test/java/nio/charset/coders/Surrogates.java + test/java/nio/charset/coders/Util.java + test/java/nio/charset/coders/ref.shift_jis + test/java/nio/charset/coders/ref.windows-31j + test/java/nio/charset/spi/FooCharset.java + test/java/nio/charset/spi/FooProvider.java + test/java/nio/charset/spi/Test.java + test/java/nio/charset/spi/basic.sh + test/java/nio/charset/spi/charsetProvider.sp + test/java/nio/charset/spi/default-pol Changeset: fd831ae629ff Author: andrew Date: 2010-04-06 11:57 +0100 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/fd831ae629ff Merge From ahughes at redhat.com Tue Apr 6 10:16:26 2010 From: ahughes at redhat.com (Andrew John Hughes) Date: Tue, 6 Apr 2010 17:16:26 +0000 Subject: Security fixes in b19 - Re: hg: jdk6/jdk6/jdk: 23 new changesets In-Reply-To: <17c6771e1003301752j5c01500fh2a83bcc16ad74cda@mail.gmail.com> References: <20100330234719.5834544A94@hg.openjdk.java.net> <4BB29B7D.1050903@oracle.com> <17c6771e1003301752j5c01500fh2a83bcc16ad74cda@mail.gmail.com> Message-ID: On 31 March 2010 00:52, Andrew John Hughes wrote: > On 31 March 2010 00:46, Joe Darcy wrote: >> The latest round of security fixes are now in the OpenJDK 6 master >> repositories. >> > > And IcedTea6 1.6, 1.7, 1.8, HEAD and IcedTea7 :-) > Joe, where are the fixes for the HotSpot tree? See top of http://hg.openjdk.java.net/icedtea/jdk7/hotspot >> -Joe >> >> abhijit.saha at sun.com wrote: >>> >>> Changeset: c60109723bf8 >>> Author: ? ?dl >>> Date: ? ? ?2009-11-18 11:39 +0000 >>> URL: ? ? ? http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/c60109723bf8 >>> >>> 6888149: AtomicReferenceArray causes SIGSEGV -> SEGV_MAPERR error >>> Summary: Avoid integer overflow by using long arithmetic >>> Reviewed-by: dholmes, alanb, chegar >>> >>> ! src/share/classes/java/util/concurrent/atomic/AtomicIntegerArray.java >>> ! src/share/classes/java/util/concurrent/atomic/AtomicLongArray.java >>> ! src/share/classes/java/util/concurrent/atomic/AtomicReferenceArray.java >>> >>> Changeset: 2e29fe2bfc9c >>> Author: ? ?chegar >>> Date: ? ? ?2009-11-23 12:51 +0000 >>> URL: ? ? ? http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/2e29fe2bfc9c >>> >>> 6639665: ThreadGroup finalizer allows creation of false root ThreadGroups >>> Reviewed-by: alanb, hawtin >>> >>> ! src/share/classes/java/lang/ThreadGroup.java >>> >>> Changeset: 1cd847ef273e >>> Author: ? ?weijun >>> Date: ? ? ?2009-11-23 19:05 -0800 >>> URL: ? ? ? http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/1cd847ef273e >>> >>> 6898622: ObjectIdentifer.equals is not capable of detecting incorrectly >>> encoded CommonName OIDs >>> Reviewed-by: mullan, xuelei >>> >>> ! src/share/classes/sun/security/util/ObjectIdentifier.java >>> + test/sun/security/util/Oid/BerOid.java >>> >>> Changeset: 3b74a067dcb4 >>> Author: ? ?alanb >>> Date: ? ? ?2009-11-25 13:05 +0000 >>> URL: ? ? ? http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/3b74a067dcb4 >>> >>> 6736390: File TOCTOU deserialization vulnerability >>> Reviewed-by: hawtin >>> >>> ! src/share/classes/java/io/File.java >>> >>> Changeset: cda5a0661316 >>> Author: ? ?sherman >>> Date: ? ? ?2009-11-25 15:40 -0800 >>> URL: ? ? ? http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/cda5a0661316 >>> >>> 6745393: Inflater/Deflater clone issue >>> Summary: To use an explicit lock object >>> Reviewed-by: alanb >>> >>> ! src/share/classes/java/util/zip/Deflater.java >>> ! src/share/classes/java/util/zip/Inflater.java >>> + src/share/classes/java/util/zip/ZStreamRef.java >>> ! src/share/native/java/util/zip/Deflater.c >>> ! src/share/native/java/util/zip/Inflater.c >>> >>> Changeset: 4509549ab091 >>> Author: ? ?mchung >>> Date: ? ? ?2009-11-30 08:25 -0800 >>> URL: ? ? ? http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/4509549ab091 >>> >>> 6893947: Deserialization of RMIConnectionImpl objects should enforce >>> stricter checks [ZDI-CAN-588] >>> Summary: narrow the doPrivileged block to only set context ClassLoader >>> Reviewed-by: hawtin, emcmanus >>> >>> ! src/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java >>> >>> Changeset: 065fc20465a9 >>> Author: ? ?michaelm >>> Date: ? ? ?2009-12-02 12:51 +0000 >>> URL: ? ? ? http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/065fc20465a9 >>> >>> 6893954: Subclasses of InetAddress may incorrectly interpret network >>> addresses >>> Summary: runtime type checks and deserialization check >>> Reviewed-by: chegar, alanb, jccollet >>> >>> ! src/share/classes/java/net/DatagramSocket.java >>> ! src/share/classes/java/net/InetAddress.java >>> ! src/share/classes/java/net/MulticastSocket.java >>> ! src/share/classes/java/net/NetworkInterface.java >>> ! src/share/classes/java/net/Socket.java >>> ! src/share/classes/sun/nio/ch/Net.java >>> >>> Changeset: 76484a1390b5 >>> Author: ? ?michaelm >>> Date: ? ? ?2009-12-02 13:39 +0000 >>> URL: ? ? ? http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/76484a1390b5 >>> >>> Merge >>> >>> >>> Changeset: a82975fed3bb >>> Author: ? ?asaha >>> Date: ? ? ?2009-12-04 10:22 -0800 >>> URL: ? ? ? http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/a82975fed3bb >>> >>> Merge >>> >>> >>> Changeset: 56d70fff0a49 >>> Author: ? ?xuelei >>> Date: ? ? ?2009-12-08 20:14 -0800 >>> URL: ? ? ? http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/56d70fff0a49 >>> >>> 6898739: TLS renegotiation issue >>> Summary: the interim fix disables TLS/SSL renegotiation >>> Reviewed-by: mullan, chegar, wetmore >>> >>> ! src/share/classes/sun/security/ssl/ClientHandshaker.java >>> ! src/share/classes/sun/security/ssl/Handshaker.java >>> ! src/share/classes/sun/security/ssl/SSLEngineImpl.java >>> ! src/share/classes/sun/security/ssl/SSLSocketImpl.java >>> ! src/share/classes/sun/security/ssl/ServerHandshaker.java >>> ! >>> test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/InvalidateServerSessionRenegotiate.java >>> ! test/sun/security/ssl/javax/net/ssl/NewAPIs/JSSERenegotiate.java >>> ! test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/CheckStatus.java >>> ! >>> test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/ConnectionTest.java >>> ! >>> test/sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/NoAuthClientAuth.java >>> >>> Changeset: c33996d22908 >>> Author: ? ?mullan >>> Date: ? ? ?2009-12-09 14:13 -0500 >>> URL: ? ? ? http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/c33996d22908 >>> >>> 6633872: Policy/PolicyFile leak dynamic ProtectionDomains. >>> Reviewed-by: hawtin >>> >>> ! src/share/classes/java/security/Policy.java >>> ! src/share/classes/java/security/ProtectionDomain.java >>> + src/share/classes/sun/misc/JavaSecurityProtectionDomainAccess.java >>> ! src/share/classes/sun/misc/SharedSecrets.java >>> ! src/share/classes/sun/security/provider/PolicyFile.java >>> >>> Changeset: 0d6a7c587b34 >>> Author: ? ?mullan >>> Date: ? ? ?2009-12-09 14:17 -0500 >>> URL: ? ? ? http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/0d6a7c587b34 >>> >>> Merge >>> >>> >>> Changeset: 30601d76d1a9 >>> Author: ? ?malenkov >>> Date: ? ? ?2009-12-22 17:34 +0300 >>> URL: ? ? ? http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/30601d76d1a9 >>> >>> 6904691: Java Applet Trusted Methods Chaining Privilege Escalation >>> Vulnerability >>> Reviewed-by: hawtin, peterz >>> >>> ! src/share/classes/java/beans/EventHandler.java >>> ! src/share/classes/java/beans/Statement.java >>> ! test/java/beans/EventHandler/Test6277246.java >>> ! test/java/beans/EventHandler/Test6277266.java >>> >>> Changeset: 475c20b5ead9 >>> Author: ? ?michaelm >>> Date: ? ? ?2010-01-12 15:24 +0000 >>> URL: ? ? ? http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/475c20b5ead9 >>> >>> 6910590: Application can modify command array, in ProcessBuilder >>> Reviewed-by: michaelm, chegar >>> >>> ! src/share/classes/java/lang/ProcessBuilder.java >>> >>> Changeset: a70c2cb935ed >>> Author: ? ?bae >>> Date: ? ? ?2010-02-17 14:47 +0300 >>> URL: ? ? ? http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/a70c2cb935ed >>> >>> 6909597: Sun Java Runtime Environment JPEGImageReader stepX Integer >>> Overflow Vulnerability >>> Reviewed-by: igor >>> >>> ! src/share/native/sun/awt/image/jpeg/imageioJPEG.c >>> >>> Changeset: 47494ceba862 >>> Author: ? ?bae >>> Date: ? ? ?2010-02-19 21:34 +0300 >>> URL: ? ? ? http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/47494ceba862 >>> >>> 6914866: Sun JRE ImagingLib arbitrary code execution vulnerability >>> Reviewed-by: prr >>> >>> ! src/share/native/sun/awt/medialib/awt_ImagingLib.c >>> ! src/share/native/sun/awt/medialib/safe_alloc.h >>> >>> Changeset: 54cecb672e0f >>> Author: ? ?bae >>> Date: ? ? ?2010-02-19 22:13 +0300 >>> URL: ? ? ? http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/54cecb672e0f >>> >>> 6899653: Sun Java Runtime CMM readMabCurveData Buffer Overflow >>> Vulnerability >>> Reviewed-by: prr >>> >>> ! src/share/native/sun/java2d/cmm/lcms/cmsio1.c >>> ! src/share/native/sun/java2d/cmm/lcms/cmsxform.c >>> >>> Changeset: b6fe2c6e58e3 >>> Author: ? ?bae >>> Date: ? ? ?2010-02-19 22:50 +0300 >>> URL: ? ? ? http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/b6fe2c6e58e3 >>> >>> 6914823: Java AWT Library Invalid Index Vulnerability >>> Reviewed-by: prr >>> >>> ! src/share/classes/sun/awt/image/ImageRepresentation.java >>> >>> Changeset: 0fc5eabbab3a >>> Author: ? ?ksrini >>> Date: ? ? ?2010-02-22 14:27 -0800 >>> URL: ? ? ? http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/0fc5eabbab3a >>> >>> 6902299: Java JAR "unpack200" must verify input parameters >>> Summary: Added several checks for addition of values before memory >>> allocation >>> Reviewed-by: asaha >>> >>> ! src/share/native/com/sun/java/util/jar/pack/bytes.cpp >>> ! src/share/native/com/sun/java/util/jar/pack/unpack.cpp >>> ! test/tools/pack200/MemoryAllocatorTest.java >>> >>> Changeset: d45c527b8218 >>> Author: ? ?denis >>> Date: ? ? ?2010-03-01 07:17 -0800 >>> URL: ? ? ? http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/d45c527b8218 >>> >>> 6887703: Unsigned applet can retrieve the dragged information before drop >>> action occur >>> Reviewed-by: uta >>> >>> ! src/share/classes/sun/awt/dnd/SunDropTargetContextPeer.java >>> >>> Changeset: ed52e9d31440 >>> Author: ? ?asaha >>> Date: ? ? ?2010-03-15 16:39 -0700 >>> URL: ? ? ? http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/ed52e9d31440 >>> >>> Merge >>> >>> - test/sun/tools/native2ascii/test2 >>> >>> Changeset: 61629da41f38 >>> Author: ? ?asaha >>> Date: ? ? ?2010-03-25 16:42 -0700 >>> URL: ? ? ? http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/61629da41f38 >>> >>> Merge >>> >>> ! src/share/classes/sun/security/ssl/SSLSocketImpl.java >>> >>> Changeset: 599b469958a8 >>> Author: ? ?asaha >>> Date: ? ? ?2010-03-30 07:58 -0700 >>> URL: ? ? ? http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/599b469958a8 >>> >>> Merge >>> >>> >>> >> >> > > > > -- > Andrew :-) > > Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > Support Free Java! > Contribute to GNU Classpath and the OpenJDK > http://www.gnu.org/software/classpath > http://openjdk.java.net > > PGP Key: 94EFD9D8 (http://subkeys.pgp.net) > Fingerprint: F8EF F1EA 401E 2E60 15FA ?7927 142C 2591 94EF D9D8 > -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From joe.darcy at oracle.com Tue Apr 6 10:34:03 2010 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 06 Apr 2010 10:34:03 -0700 Subject: Security fixes in b19 - Re: hg: jdk6/jdk6/jdk: 23 new changesets In-Reply-To: References: <20100330234719.5834544A94@hg.openjdk.java.net> <4BB29B7D.1050903@oracle.com> <17c6771e1003301752j5c01500fh2a83bcc16ad74cda@mail.gmail.com> Message-ID: <4BBB708B.40108@oracle.com> Andrew John Hughes wrote: > On 31 March 2010 00:52, Andrew John Hughes wrote: > >> On 31 March 2010 00:46, Joe Darcy wrote: >> >>> The latest round of security fixes are now in the OpenJDK 6 master >>> repositories. >>> >>> >> And IcedTea6 1.6, 1.7, 1.8, HEAD and IcedTea7 :-) >> >> > > Joe, where are the fixes for the HotSpot tree? See top of > http://hg.openjdk.java.net/icedtea/jdk7/hotspot > > This time around, all the security fixes were in the jdk repository. -Joe From ahughes at redhat.com Tue Apr 6 10:43:04 2010 From: ahughes at redhat.com (Andrew John Hughes) Date: Tue, 6 Apr 2010 17:43:04 +0000 Subject: Security fixes in b19 - Re: hg: jdk6/jdk6/jdk: 23 new changesets In-Reply-To: <4BBB708B.40108@oracle.com> References: <20100330234719.5834544A94@hg.openjdk.java.net> <4BB29B7D.1050903@oracle.com> <17c6771e1003301752j5c01500fh2a83bcc16ad74cda@mail.gmail.com> <4BBB708B.40108@oracle.com> Message-ID: On 6 April 2010 17:34, Joe Darcy wrote: > Andrew John Hughes wrote: >> >> On 31 March 2010 00:52, Andrew John Hughes wrote: >> >>> >>> On 31 March 2010 00:46, Joe Darcy wrote: >>> >>>> >>>> The latest round of security fixes are now in the OpenJDK 6 master >>>> repositories. >>>> >>>> >>> >>> And IcedTea6 1.6, 1.7, 1.8, HEAD and IcedTea7 :-) >>> >>> >> >> Joe, where are the fixes for the HotSpot tree? ?See top of >> http://hg.openjdk.java.net/icedtea/jdk7/hotspot >> >> > > This time around, all the security fixes were in the jdk repository. > > -Joe > Err... no they weren't... 6626217: Loader-constraint table allows arrays instead of only the base-classes (CVE-2010-0082) 6892265: System.arraycopy unable to reference elements beyond Integer.MAX_VALUE bytes (CVE-2010-0093) 6894807: No ClassCastException for HashAttributeSet constructors if run with -Xcomp (CVE-2010-0845) and 6932480: Crash in CompilerThread/Parser. Unloaded array klass? due to a breakage caused by one of the above. -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From joe.darcy at oracle.com Tue Apr 6 11:08:34 2010 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 06 Apr 2010 11:08:34 -0700 Subject: Security fixes in b19 - Re: hg: jdk6/jdk6/jdk: 23 new changesets In-Reply-To: References: <20100330234719.5834544A94@hg.openjdk.java.net> <4BB29B7D.1050903@oracle.com> <17c6771e1003301752j5c01500fh2a83bcc16ad74cda@mail.gmail.com> <4BBB708B.40108@oracle.com> Message-ID: <4BBB78A2.9040803@oracle.com> Andrew John Hughes wrote: > On 6 April 2010 17:34, Joe Darcy wrote: > >> Andrew John Hughes wrote: >> >>> On 31 March 2010 00:52, Andrew John Hughes wrote: >>> >>> >>>> On 31 March 2010 00:46, Joe Darcy wrote: >>>> >>>> >>>>> The latest round of security fixes are now in the OpenJDK 6 master >>>>> repositories. >>>>> >>>>> >>>>> >>>> And IcedTea6 1.6, 1.7, 1.8, HEAD and IcedTea7 :-) >>>> >>>> >>>> >>> Joe, where are the fixes for the HotSpot tree? See top of >>> http://hg.openjdk.java.net/icedtea/jdk7/hotspot >>> >>> >>> >> This time around, all the security fixes were in the jdk repository. >> >> -Joe >> >> > > Err... no they weren't... > > 6626217: Loader-constraint table allows arrays instead of only the > base-classes (CVE-2010-0082) > 6892265: System.arraycopy unable to reference elements beyond > Integer.MAX_VALUE bytes (CVE-2010-0093) > 6894807: No ClassCastException for HashAttributeSet constructors if > run with -Xcomp (CVE-2010-0845) > > and > > 6932480: Crash in CompilerThread/Parser. Unloaded array klass? > > due to a breakage caused by one of the above. > Hmm, let me check into that... -Joe From abhijit.saha at sun.com Tue Apr 6 12:05:16 2010 From: abhijit.saha at sun.com (abhijit.saha at sun.com) Date: Tue, 06 Apr 2010 19:05:16 +0000 Subject: hg: jdk6/jdk6/hotspot: 6892265: System.arraycopy unable to reference elements beyond Integer.MAX_VALUE bytes Message-ID: <20100406190531.749DC44417@hg.openjdk.java.net> Changeset: 9393e8c14eaa Author: kvn Date: 2009-12-03 14:26 -0800 URL: http://hg.openjdk.java.net/jdk6/jdk6/hotspot/rev/9393e8c14eaa 6892265: System.arraycopy unable to reference elements beyond Integer.MAX_VALUE bytes Summary: Use size_t type cast to widen int values in typeArrayKlass::copy_array(). Reviewed-by: never, jcoomes ! src/share/vm/oops/typeArrayKlass.cpp + test/compiler/6892265/Test.java From ahughes at redhat.com Tue Apr 6 13:27:09 2010 From: ahughes at redhat.com (Andrew John Hughes) Date: Tue, 6 Apr 2010 20:27:09 +0000 Subject: Test Backports In-Reply-To: <4BBA91BD.8020105@oracle.com> References: <17c6771e1003291310u3e1b3231i6a054fd76bc24182@mail.gmail.com> <4BB112FD.9070702@oracle.com> <17c6771e1003291849m7d920b2ey7e4b15bd0f748a0a@mail.gmail.com> <4BB3ABEE.4070102@oracle.com> <4BBA91BD.8020105@oracle.com> Message-ID: On 6 April 2010 01:43, Joe Darcy wrote: > On 03/31/10 02:41 PM, Andrew John Hughes wrote: > > On 31 March 2010 20:09, Joe Darcy wrote: > > > Andrew John Hughes wrote: > > > On 29 March 2010 20:52, Joe Darcy wrote: > > > > Andrew John Hughes wrote: > > > > There are a set of bidi and math tests: > > changeset: ? 817:8ea49fa4c2f7 > user: ? ? ? ?peytoia > date: ? ? ? ?Fri Oct 17 13:34:03 2008 +0900 > summary: ? ? 6759521: Move Bidi test programs from closed to open. > > http://hg.openjdk.java.net/jdk7/jdk7/jdk/rev/8ea49fa4c2f7 > > > > > I approve the bidi tests going back; please verify they pass first though > :-) > > > > > Passed and pushed; > http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/e1549056d958 > > > > Thanks. > > > > changeset: ? 809:f3ad2ee4600b > user: ? ? ? ?darcy > date: ? ? ? ?Mon Jan 26 19:49:26 2009 -0800 > description: > 6601457: Move wrapper class tests from closed to open > 6601458: Move java.math tests from closed to open > 6740185: Move java/lang/annotations tests to open > 6759433: Move Math and StrictMath regression tests from closed to open > Summary: Move some more regression tests to the open > Reviewed-by: jjg > > http://hg.openjdk.java.net/jdk7/jdk7/jdk/rev/f3ad2ee4600b > > that were opened up in OpenJDK7. ?Ok to backport these to 6? > > > > > However, I deny these other tests being backported since they have long > been > in OpenJDK 6 :-) > > > > > Doh! ?Looks like they were still lurking around in the IcedTea tree > but no longer being applied. > > I found a bunch of others too: > > comparing with ssh://hg.openjdk.java.net/jdk6/jdk6-gate/jdk > searching for changes > changeset: ? 308:d5dc9130bdb0 > user: ? ? ? ?volk > date: ? ? ? ?Sun Apr 13 23:41:40 2008 +0400 > summary: ? ? 6686273: Some AWT reg. tests should be moved to open > repository (for CRs 6444769, 6480547, and 6560348) > > changeset: ? 309:fa6cfc27b519 > user: ? ? ? ?ant > date: ? ? ? ?Wed Mar 26 16:20:01 2008 +0300 > summary: ? ? 6680135: A number of test/closed/java/awt/Focus/* tests > should be opened > > changeset: ? 310:285a274f844a > user: ? ? ? ?sherman > date: ? ? ? ?Mon Jun 30 14:06:34 2008 -0700 > summary: ? ? 6675856: Open charset tests > > changeset: ? 311:47f907e9c9b3 > user: ? ? ? ?malenkov > date: ? ? ? ?Thu Jun 26 15:11:04 2008 +0400 > summary: ? ? 6718964: Swing border tests should be open source > > changeset: ? 312:a6d7e84e31e1 > user: ? ? ? ?malenkov > date: ? ? ? ?Thu Jun 26 15:39:12 2008 +0400 > summary: ? ? 6718965: Swing color chooser tests should be open source > > changeset: ? 313:62168e9450f9 > user: ? ? ? ?sherman > date: ? ? ? ?Thu Aug 13 15:01:18 2009 -0700 > summary: ? ? 6676423: (prefs) Opensource unit/regression tests for > java.util.prefs > > changeset: ? 314:83980d94b138 > tag: ? ? ? ? tip > user: ? ? ? ?sherman > date: ? ? ? ?Wed Jan 27 19:39:55 2010 -0800 > summary: ? ? 6920732: opensource test/java/nio/charset > > Ok to backport? ?The majority pass, with the failures being in the AWT > ones (may be my setup, as some of the existing ones fail too) and > prefs (I think it's trying to acquire a lock on a NFS mount). > > > > Yes in principle, but let me dig into the particular changes a bit to > double-check they're applicable to and appropriate for OpenJDK 6. > > > > Ok, the comments suggested to me they were forwardports from the > proprietary tree but good to check. > > > I've looked over each of these patches, and they all seem applicable to > OpenJDK 6 so I approve all of them going back. > > (It is feasible a patch would be applicable to a portion of the proprietary > JDK 7, but not applicable to the corresponding portion of OpenJDK 6.) > Thanks for checking. Obviously you're one of the few who can do so for the proprietary JDKs. Pushed: http://mail.openjdk.java.net/pipermail/jdk6-dev/2010-April/001427.html > On my queue, I have four more Zero patches and a set of backports I'd > like in (making the source/target explicit as we did in 7 already, and > Kelly's ant 1.8 patch). Everything else can wait until b20 > Here's the backport: http://cr.openjdk.java.net/~andrew/6873059/webrev.01/jdk6.patch It's a replica of 6873059 as applied to the HotSpot, JDK and CORBA trees in OpenJDK7, the only difference being that we use 5 instead of 6 as the bootstrap version for OpenJDK6. Ok to push? Should I use the same bug ID or do you want to allocate a fresh one? On another note, there is now some code requiring source level 6 in OpenJDK6 (due to use of the @Override annotation on interfaces): src/share/classes/javax/swing/plaf/synth/SynthComboBoxUI.java src/share/classes/javax/swing/plaf/synth/SynthLookAndFeel.java src/share/classes/javax/swing/plaf/synth/SynthTreeUI.java src/share/classes/sun/security/provider/certpath/OCSPResponse.java src/share/classes/sun/swing/plaf/synth/SynthFileChooserUIImpl.java So we should look at bumping the generated code version to 6 (it still seems to be 5 even though this is OpenJDK6). I'd prefer to leave that until b20 though. I see Kelly's patch went in. It would be nice to also backport http://hg.openjdk.java.net/jdk7/jdk7/hotspot/rev/5fdbe2cdf565 (a minor warning fix) so IcedTea6's OpenJDK backport set is empty again. > Sounds good. > > Cheers, > > -Joe > -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From ahughes at redhat.com Tue Apr 6 13:34:21 2010 From: ahughes at redhat.com (Andrew John Hughes) Date: Tue, 6 Apr 2010 20:34:21 +0000 Subject: Security fixes in b19 - Re: hg: jdk6/jdk6/jdk: 23 new changesets In-Reply-To: <4BBB78A2.9040803@oracle.com> References: <20100330234719.5834544A94@hg.openjdk.java.net> <4BB29B7D.1050903@oracle.com> <17c6771e1003301752j5c01500fh2a83bcc16ad74cda@mail.gmail.com> <4BBB708B.40108@oracle.com> <4BBB78A2.9040803@oracle.com> Message-ID: On 6 April 2010 18:08, Joe Darcy wrote: > Andrew John Hughes wrote: >> >> On 6 April 2010 17:34, Joe Darcy wrote: >> >>> >>> Andrew John Hughes wrote: >>> >>>> >>>> On 31 March 2010 00:52, Andrew John Hughes wrote: >>>> >>>> >>>>> >>>>> On 31 March 2010 00:46, Joe Darcy wrote: >>>>> >>>>> >>>>>> >>>>>> The latest round of security fixes are now in the OpenJDK 6 master >>>>>> repositories. >>>>>> >>>>>> >>>>>> >>>>> >>>>> And IcedTea6 1.6, 1.7, 1.8, HEAD and IcedTea7 :-) >>>>> >>>>> >>>>> >>>> >>>> Joe, where are the fixes for the HotSpot tree? ?See top of >>>> http://hg.openjdk.java.net/icedtea/jdk7/hotspot >>>> >>>> >>>> >>> >>> This time around, all the security fixes were in the jdk repository. >>> >>> -Joe >>> >>> >> >> Err... no they weren't... >> >> 6626217: Loader-constraint table allows arrays instead of only the >> base-classes (CVE-2010-0082) >> 6892265: System.arraycopy unable to reference elements beyond >> Integer.MAX_VALUE bytes (CVE-2010-0093) >> 6894807: No ClassCastException for HashAttributeSet constructors if >> run with -Xcomp (CVE-2010-0845) >> >> and >> >> 6932480: Crash in CompilerThread/Parser. Unloaded array klass? >> >> due to a breakage caused by one of the above. >> > > Hmm, let me check into that... > > -Joe > There's also a fix missing that we had to apply locally in IcedTea6. With current OpenJDK6 hg, rmid crashes: $ /home/andrew/build/icedtea6-hg/bin/rmid Activation.main: an exception occurred: java.lang.NullPointerException java.lang.NullPointerException at sun.security.provider.PolicyFile$PolicyInfo.(PolicyFile.java:2491) at sun.security.provider.PolicyFile.init(PolicyFile.java:468) at sun.security.provider.PolicyFile.(PolicyFile.java:327) at java.security.Policy.getPolicyNoCheck(Policy.java:189) at java.security.Policy.getPolicy(Policy.java:152) at sun.rmi.server.Activation$DefaultExecPolicy$1.run(Activation.java:1823) at sun.rmi.server.Activation$DefaultExecPolicy$1.run(Activation.java:1821) at java.security.AccessController.doPrivileged(Native Method) at sun.rmi.server.Activation$DefaultExecPolicy.checkConfiguration(Activation.java:1820) The fix is simple: diff -r fd831ae629ff src/share/classes/sun/misc/SharedSecrets.java --- a/src/share/classes/sun/misc/SharedSecrets.java Tue Apr 06 11:57:39 2010 +0100 +++ b/src/share/classes/sun/misc/SharedSecrets.java Tue Apr 06 21:30:03 2010 +0100 @@ -29,6 +29,7 @@ import java.io.Console; import java.io.File; import java.io.FileDescriptor; +import java.security.ProtectionDomain; /** A repository of "shared secrets", which are a mechanism for calling implementation-private methods in another package without @@ -118,6 +119,9 @@ public static JavaSecurityProtectionDomainAccess getJavaSecurityProtectionDomainAccess() { - return javaSecurityProtectionDomainAccess; + if (javaSecurityProtectionDomainAccess == null) + unsafe.ensureClassInitialized(ProtectionDomain.class); + + return javaSecurityProtectionDomainAccess; } } This ensures the class is initialized, making that SharedSecrets accessor like all the others. Can I have a bug ID to push this? -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From abhijit.saha at sun.com Tue Apr 6 13:39:34 2010 From: abhijit.saha at sun.com (abhijit.saha at sun.com) Date: Tue, 06 Apr 2010 20:39:34 +0000 Subject: hg: jdk6/jdk6/hotspot: 3 new changesets Message-ID: <20100406203947.1DDC74441D@hg.openjdk.java.net> Changeset: 178969b3e14f Author: acorn Date: 2010-04-06 12:30 -0700 URL: http://hg.openjdk.java.net/jdk6/jdk6/hotspot/rev/178969b3e14f 6626217: Fixed loader constraint array handling Summary: Loader constraints track array elements, not arrays themselves. Reviewed-by: dcubed, kevinw ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/classfile/loaderConstraints.cpp ! src/share/vm/classfile/loaderConstraints.hpp ! src/share/vm/classfile/systemDictionary.cpp Changeset: d31e8375f994 Author: kvn Date: 2010-04-06 12:38 -0700 URL: http://hg.openjdk.java.net/jdk6/jdk6/hotspot/rev/d31e8375f994 6894807: No ClassCastException for HashAttributeSet constructors if run with -Xcomp Summary: Return interface klass type if it is exact. Reviewed-by: never ! src/share/vm/opto/cfgnode.cpp ! src/share/vm/opto/type.cpp Changeset: 577f7204441a Author: acorn Date: 2010-03-15 14:28 -0400 URL: http://hg.openjdk.java.net/jdk6/jdk6/hotspot/rev/577f7204441a 6932480: Crash in CompilerThread/Parser. Unloaded array klass? Summary: Restore code deleted in 6626217 Reviewed-by: asaha, kevinw ! src/share/vm/ci/ciEnv.cpp From joe.darcy at oracle.com Tue Apr 6 13:40:39 2010 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 06 Apr 2010 13:40:39 -0700 Subject: Security fixes in b19 - Re: hg: jdk6/jdk6/jdk: 23 new changesets In-Reply-To: <4BBB78A2.9040803@oracle.com> References: <20100330234719.5834544A94@hg.openjdk.java.net> <4BB29B7D.1050903@oracle.com> <17c6771e1003301752j5c01500fh2a83bcc16ad74cda@mail.gmail.com> <4BBB708B.40108@oracle.com> <4BBB78A2.9040803@oracle.com> Message-ID: <4BBB9C47.7070705@oracle.com> Joe Darcy wrote: > Andrew John Hughes wrote: >> On 6 April 2010 17:34, Joe Darcy wrote: >> >>> Andrew John Hughes wrote: >>> >>>> On 31 March 2010 00:52, Andrew John Hughes wrote: >>>> >>>> >>>>> On 31 March 2010 00:46, Joe Darcy wrote: >>>>> >>>>> >>>>>> The latest round of security fixes are now in the OpenJDK 6 master >>>>>> repositories. >>>>>> >>>>>> >>>>>> >>>>> And IcedTea6 1.6, 1.7, 1.8, HEAD and IcedTea7 :-) >>>>> >>>>> >>>>> >>>> Joe, where are the fixes for the HotSpot tree? See top of >>>> http://hg.openjdk.java.net/icedtea/jdk7/hotspot >>>> >>>> >>>> >>> This time around, all the security fixes were in the jdk repository. >>> >>> -Joe >>> >>> >> >> Err... no they weren't... >> >> 6626217: Loader-constraint table allows arrays instead of only the >> base-classes (CVE-2010-0082) >> 6892265: System.arraycopy unable to reference elements beyond >> Integer.MAX_VALUE bytes (CVE-2010-0093) >> 6894807: No ClassCastException for HashAttributeSet constructors if >> run with -Xcomp (CVE-2010-0845) >> >> and >> >> 6932480: Crash in CompilerThread/Parser. Unloaded array klass? >> >> due to a breakage caused by one of the above. >> > > Hmm, let me check into that... > Thanks for catching this; the remaining security fixes are on the way. (The rebasing of the HotSpot repo caused a hiccup in the security integration process which will be corrected.) -Joe From ahughes at redhat.com Tue Apr 6 13:57:00 2010 From: ahughes at redhat.com (Andrew John Hughes) Date: Tue, 6 Apr 2010 20:57:00 +0000 Subject: Security fixes in b19 - Re: hg: jdk6/jdk6/jdk: 23 new changesets In-Reply-To: <4BBB9C47.7070705@oracle.com> References: <20100330234719.5834544A94@hg.openjdk.java.net> <4BB29B7D.1050903@oracle.com> <17c6771e1003301752j5c01500fh2a83bcc16ad74cda@mail.gmail.com> <4BBB708B.40108@oracle.com> <4BBB78A2.9040803@oracle.com> <4BBB9C47.7070705@oracle.com> Message-ID: On 6 April 2010 20:40, Joe Darcy wrote: > Joe Darcy wrote: >> >> Andrew John Hughes wrote: >>> >>> On 6 April 2010 17:34, Joe Darcy wrote: >>> >>>> >>>> Andrew John Hughes wrote: >>>> >>>>> >>>>> On 31 March 2010 00:52, Andrew John Hughes wrote: >>>>> >>>>> >>>>>> >>>>>> On 31 March 2010 00:46, Joe Darcy wrote: >>>>>> >>>>>> >>>>>>> >>>>>>> The latest round of security fixes are now in the OpenJDK 6 master >>>>>>> repositories. >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> And IcedTea6 1.6, 1.7, 1.8, HEAD and IcedTea7 :-) >>>>>> >>>>>> >>>>>> >>>>> >>>>> Joe, where are the fixes for the HotSpot tree? ?See top of >>>>> http://hg.openjdk.java.net/icedtea/jdk7/hotspot >>>>> >>>>> >>>>> >>>> >>>> This time around, all the security fixes were in the jdk repository. >>>> >>>> -Joe >>>> >>>> >>> >>> Err... no they weren't... >>> >>> 6626217: Loader-constraint table allows arrays instead of only the >>> base-classes (CVE-2010-0082) >>> 6892265: System.arraycopy unable to reference elements beyond >>> Integer.MAX_VALUE bytes (CVE-2010-0093) >>> 6894807: No ClassCastException for HashAttributeSet constructors if >>> run with -Xcomp (CVE-2010-0845) >>> >>> and >>> >>> 6932480: Crash in CompilerThread/Parser. Unloaded array klass? >>> >>> due to a breakage caused by one of the above. >>> >> >> Hmm, let me check into that... >> > > Thanks for catching this; the remaining security fixes are on the way. ?(The > rebasing of the HotSpot repo caused a hiccup in the security integration > process which will be corrected.) > > -Joe > Thanks; all seem to be present and correct now. We just need the fix I posted (http://mail.openjdk.java.net/pipermail/jdk6-dev/2010-April/001434.html) so rmid isn't broken. -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From joe.darcy at oracle.com Tue Apr 6 17:13:18 2010 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 06 Apr 2010 17:13:18 -0700 Subject: Security fixes in b19 - Re: hg: jdk6/jdk6/jdk: 23 new changesets In-Reply-To: References: <20100330234719.5834544A94@hg.openjdk.java.net> <4BB29B7D.1050903@oracle.com> <17c6771e1003301752j5c01500fh2a83bcc16ad74cda@mail.gmail.com> <4BBB708B.40108@oracle.com> <4BBB78A2.9040803@oracle.com> Message-ID: <4BBBCE1E.7020806@oracle.com> Sean, Please have a look at this fix proposed by Andrew to address a crash in rmid in OpenJDK 6. Looking at the changes to SharedSecrets, your fix for 6633872 "Policy/PolicyFile leak dynamic ProtectionDomains." when applied to OpenJDK 6 looks like the proximal cause of the crash. Thanks, -Joe On 04/06/10 01:34 PM, Andrew John Hughes wrote: > On 6 April 2010 18:08, Joe Darcy wrote: > >> Andrew John Hughes wrote: >> >>> On 6 April 2010 17:34, Joe Darcy wrote: >>> >>> >>>> Andrew John Hughes wrote: >>>> >>>> >>>>> On 31 March 2010 00:52, Andrew John Hughes wrote: >>>>> >>>>> >>>>> >>>>>> On 31 March 2010 00:46, Joe Darcy wrote: >>>>>> >>>>>> >>>>>> >>>>>>> The latest round of security fixes are now in the OpenJDK 6 master >>>>>>> repositories. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> And IcedTea6 1.6, 1.7, 1.8, HEAD and IcedTea7 :-) >>>>>> >>>>>> >>>>>> >>>>>> >>>>> Joe, where are the fixes for the HotSpot tree? See top of >>>>> http://hg.openjdk.java.net/icedtea/jdk7/hotspot >>>>> >>>>> >>>>> >>>>> >>>> This time around, all the security fixes were in the jdk repository. >>>> >>>> -Joe >>>> >>>> >>>> >>> Err... no they weren't... >>> >>> 6626217: Loader-constraint table allows arrays instead of only the >>> base-classes (CVE-2010-0082) >>> 6892265: System.arraycopy unable to reference elements beyond >>> Integer.MAX_VALUE bytes (CVE-2010-0093) >>> 6894807: No ClassCastException for HashAttributeSet constructors if >>> run with -Xcomp (CVE-2010-0845) >>> >>> and >>> >>> 6932480: Crash in CompilerThread/Parser. Unloaded array klass? >>> >>> due to a breakage caused by one of the above. >>> >>> >> Hmm, let me check into that... >> >> -Joe >> >> > > There's also a fix missing that we had to apply locally in IcedTea6. > With current OpenJDK6 hg, rmid crashes: > > $ /home/andrew/build/icedtea6-hg/bin/rmid > Activation.main: an exception occurred: java.lang.NullPointerException > java.lang.NullPointerException > at sun.security.provider.PolicyFile$PolicyInfo.(PolicyFile.java:2491) > at sun.security.provider.PolicyFile.init(PolicyFile.java:468) > at sun.security.provider.PolicyFile.(PolicyFile.java:327) > at java.security.Policy.getPolicyNoCheck(Policy.java:189) > at java.security.Policy.getPolicy(Policy.java:152) > at sun.rmi.server.Activation$DefaultExecPolicy$1.run(Activation.java:1823) > at sun.rmi.server.Activation$DefaultExecPolicy$1.run(Activation.java:1821) > at java.security.AccessController.doPrivileged(Native Method) > at sun.rmi.server.Activation$DefaultExecPolicy.checkConfiguration(Activation.java:1820) > > The fix is simple: > > diff -r fd831ae629ff src/share/classes/sun/misc/SharedSecrets.java > --- a/src/share/classes/sun/misc/SharedSecrets.java Tue Apr 06 > 11:57:39 2010 +0100 > +++ b/src/share/classes/sun/misc/SharedSecrets.java Tue Apr 06 > 21:30:03 2010 +0100 > @@ -29,6 +29,7 @@ > import java.io.Console; > import java.io.File; > import java.io.FileDescriptor; > +import java.security.ProtectionDomain; > > /** A repository of "shared secrets", which are a mechanism for > calling implementation-private methods in another package without > @@ -118,6 +119,9 @@ > > public static JavaSecurityProtectionDomainAccess > getJavaSecurityProtectionDomainAccess() { > - return javaSecurityProtectionDomainAccess; > + if (javaSecurityProtectionDomainAccess == null) > + unsafe.ensureClassInitialized(ProtectionDomain.class); > + > + return javaSecurityProtectionDomainAccess; > } > } > > This ensures the class is initialized, making that SharedSecrets > accessor like all the others. > > Can I have a bug ID to push this? > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/jdk6-dev/attachments/20100406/390994f7/attachment-0001.html From joe.darcy at oracle.com Tue Apr 6 17:25:18 2010 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 06 Apr 2010 17:25:18 -0700 Subject: Test Backports In-Reply-To: References: <17c6771e1003291310u3e1b3231i6a054fd76bc24182@mail.gmail.com> <4BB112FD.9070702@oracle.com> <17c6771e1003291849m7d920b2ey7e4b15bd0f748a0a@mail.gmail.com> <4BB3ABEE.4070102@oracle.com> <4BBA91BD.8020105@oracle.com> Message-ID: <4BBBD0EE.7040705@oracle.com> On 04/06/10 01:27 PM, Andrew John Hughes wrote: > On 6 April 2010 01:43, Joe Darcy wrote: > >> On 03/31/10 02:41 PM, Andrew John Hughes wrote: >> >> On 31 March 2010 20:09, Joe Darcy wrote: >> >> >> Andrew John Hughes wrote: >> >> >> On 29 March 2010 20:52, Joe Darcy wrote: >> >> >> >> Andrew John Hughes wrote: >> >> >> >> There are a set of bidi and math tests: >> >> changeset: 817:8ea49fa4c2f7 >> user: peytoia >> date: Fri Oct 17 13:34:03 2008 +0900 >> summary: 6759521: Move Bidi test programs from closed to open. >> >> http://hg.openjdk.java.net/jdk7/jdk7/jdk/rev/8ea49fa4c2f7 >> >> >> >> >> I approve the bidi tests going back; please verify they pass first though >> :-) >> >> >> >> >> Passed and pushed; >> http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/e1549056d958 >> >> >> >> Thanks. >> >> >> >> changeset: 809:f3ad2ee4600b >> user: darcy >> date: Mon Jan 26 19:49:26 2009 -0800 >> description: >> 6601457: Move wrapper class tests from closed to open >> 6601458: Move java.math tests from closed to open >> 6740185: Move java/lang/annotations tests to open >> 6759433: Move Math and StrictMath regression tests from closed to open >> Summary: Move some more regression tests to the open >> Reviewed-by: jjg >> >> http://hg.openjdk.java.net/jdk7/jdk7/jdk/rev/f3ad2ee4600b >> >> that were opened up in OpenJDK7. Ok to backport these to 6? >> >> >> >> >> However, I deny these other tests being backported since they have long >> been >> in OpenJDK 6 :-) >> >> >> >> >> Doh! Looks like they were still lurking around in the IcedTea tree >> but no longer being applied. >> >> I found a bunch of others too: >> >> comparing with ssh://hg.openjdk.java.net/jdk6/jdk6-gate/jdk >> searching for changes >> changeset: 308:d5dc9130bdb0 >> user: volk >> date: Sun Apr 13 23:41:40 2008 +0400 >> summary: 6686273: Some AWT reg. tests should be moved to open >> repository (for CRs 6444769, 6480547, and 6560348) >> >> changeset: 309:fa6cfc27b519 >> user: ant >> date: Wed Mar 26 16:20:01 2008 +0300 >> summary: 6680135: A number of test/closed/java/awt/Focus/* tests >> should be opened >> >> changeset: 310:285a274f844a >> user: sherman >> date: Mon Jun 30 14:06:34 2008 -0700 >> summary: 6675856: Open charset tests >> >> changeset: 311:47f907e9c9b3 >> user: malenkov >> date: Thu Jun 26 15:11:04 2008 +0400 >> summary: 6718964: Swing border tests should be open source >> >> changeset: 312:a6d7e84e31e1 >> user: malenkov >> date: Thu Jun 26 15:39:12 2008 +0400 >> summary: 6718965: Swing color chooser tests should be open source >> >> changeset: 313:62168e9450f9 >> user: sherman >> date: Thu Aug 13 15:01:18 2009 -0700 >> summary: 6676423: (prefs) Opensource unit/regression tests for >> java.util.prefs >> >> changeset: 314:83980d94b138 >> tag: tip >> user: sherman >> date: Wed Jan 27 19:39:55 2010 -0800 >> summary: 6920732: opensource test/java/nio/charset >> >> Ok to backport? The majority pass, with the failures being in the AWT >> ones (may be my setup, as some of the existing ones fail too) and >> prefs (I think it's trying to acquire a lock on a NFS mount). >> >> >> >> Yes in principle, but let me dig into the particular changes a bit to >> double-check they're applicable to and appropriate for OpenJDK 6. >> >> >> >> Ok, the comments suggested to me they were forwardports from the >> proprietary tree but good to check. >> >> >> I've looked over each of these patches, and they all seem applicable to >> OpenJDK 6 so I approve all of them going back. >> >> (It is feasible a patch would be applicable to a portion of the proprietary >> JDK 7, but not applicable to the corresponding portion of OpenJDK 6.) >> >> > > Thanks for checking. Obviously you're one of the few who can do so > for the proprietary JDKs. > > Pushed: http://mail.openjdk.java.net/pipermail/jdk6-dev/2010-April/001427.html > Thanks. > >> On my queue, I have four more Zero patches and a set of backports I'd >> like in (making the source/target explicit as we did in 7 already, and >> Kelly's ant 1.8 patch). Everything else can wait until b20 >> >> > > Here's the backport: > > http://cr.openjdk.java.net/~andrew/6873059/webrev.01/jdk6.patch > > It's a replica of 6873059 as applied to the HotSpot, JDK and CORBA > trees in OpenJDK7, the only difference being that we use 5 instead of > 6 as the bootstrap version for OpenJDK6. Ok to push? Should I use > the same bug ID or do you want to allocate a fresh one? > Using the same bug id is fine, but I'd like Kelly to sanity check it before it goes back. > On another note, there is now some code requiring source level 6 in > OpenJDK6 (due to use of the @Override annotation on interfaces): > > src/share/classes/javax/swing/plaf/synth/SynthComboBoxUI.java > src/share/classes/javax/swing/plaf/synth/SynthLookAndFeel.java > src/share/classes/javax/swing/plaf/synth/SynthTreeUI.java > src/share/classes/sun/security/provider/certpath/OCSPResponse.java > src/share/classes/sun/swing/plaf/synth/SynthFileChooserUIImpl.java > There is an overly-long story behind -source 5 vs. -source 6 and @Override. The short answer is that javac in JDK 6 unconditionally applies the more liberal (and more useful) semantics for @Override. For the JDK sources, a compiler that does the same should be used. > So we should look at bumping the generated code version to 6 (it still > seems to be 5 even though this is OpenJDK6). I'd prefer to leave that > until b20 though. > > I see Kelly's patch went in. It would be nice to also backport > http://hg.openjdk.java.net/jdk7/jdk7/hotspot/rev/5fdbe2cdf565 (a minor > warning fix) so IcedTea6's OpenJDK backport set is empty again. > I approve the warning fix being backported. -Joe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/jdk6-dev/attachments/20100406/c0a620c3/attachment.html From ahughes at redhat.com Tue Apr 6 18:14:50 2010 From: ahughes at redhat.com (Andrew John Hughes) Date: Wed, 7 Apr 2010 01:14:50 +0000 Subject: Security fixes in b19 - Re: hg: jdk6/jdk6/jdk: 23 new changesets In-Reply-To: <4BBBCE1E.7020806@oracle.com> References: <20100330234719.5834544A94@hg.openjdk.java.net> <4BB29B7D.1050903@oracle.com> <17c6771e1003301752j5c01500fh2a83bcc16ad74cda@mail.gmail.com> <4BBB708B.40108@oracle.com> <4BBB78A2.9040803@oracle.com> <4BBBCE1E.7020806@oracle.com> Message-ID: On 7 April 2010 00:13, Joe Darcy wrote: > Sean, > > Please have a look at this fix proposed by Andrew to address a crash in rmid > in OpenJDK 6.? Looking at the changes to SharedSecrets, your fix for 6633872 > "Policy/PolicyFile leak dynamic ProtectionDomains." when applied to OpenJDK > 6 looks like the proximal cause of the crash. > Just to go into a little more detail on what I said below. Each existing accessor in that class does an explicit class initialisation beforehand to protect against the null pointer exception which may occur if the class has not been initialised and the reference set. Looking at the new addition in context, it is a clear odd-one-out and would have benefited from being simply copied from one of the existing accessors rather than written afresh. Perhaps the reason this slipped through the net is that it performs fine on OpenJDK7 (and may thus also do so on the proprietary JDKs). It's currently a matter of luck as to which class gets initialised first. Applying the fix below ensure the dependent class is initialised explicitly. > Thanks, > > -Joe > > On 04/06/10 01:34 PM, Andrew John Hughes wrote: > > On 6 April 2010 18:08, Joe Darcy wrote: > > > Andrew John Hughes wrote: > > > On 6 April 2010 17:34, Joe Darcy wrote: > > > > Andrew John Hughes wrote: > > > > On 31 March 2010 00:52, Andrew John Hughes wrote: > > > > > On 31 March 2010 00:46, Joe Darcy wrote: > > > > > The latest round of security fixes are now in the OpenJDK 6 master > repositories. > > > > > > And IcedTea6 1.6, 1.7, 1.8, HEAD and IcedTea7 :-) > > > > > > Joe, where are the fixes for the HotSpot tree? ?See top of > http://hg.openjdk.java.net/icedtea/jdk7/hotspot > > > > > > This time around, all the security fixes were in the jdk repository. > > -Joe > > > > > Err... no they weren't... > > 6626217: Loader-constraint table allows arrays instead of only the > base-classes (CVE-2010-0082) > 6892265: System.arraycopy unable to reference elements beyond > Integer.MAX_VALUE bytes (CVE-2010-0093) > 6894807: No ClassCastException for HashAttributeSet constructors if > run with -Xcomp (CVE-2010-0845) > > and > > 6932480: Crash in CompilerThread/Parser. Unloaded array klass? > > due to a breakage caused by one of the above. > > > > Hmm, let me check into that... > > -Joe > > > > There's also a fix missing that we had to apply locally in IcedTea6. > With current OpenJDK6 hg, rmid crashes: > > $ /home/andrew/build/icedtea6-hg/bin/rmid > Activation.main: an exception occurred: java.lang.NullPointerException > java.lang.NullPointerException > at sun.security.provider.PolicyFile$PolicyInfo.(PolicyFile.java:2491) > at sun.security.provider.PolicyFile.init(PolicyFile.java:468) > at sun.security.provider.PolicyFile.(PolicyFile.java:327) > at java.security.Policy.getPolicyNoCheck(Policy.java:189) > at java.security.Policy.getPolicy(Policy.java:152) > at sun.rmi.server.Activation$DefaultExecPolicy$1.run(Activation.java:1823) > at sun.rmi.server.Activation$DefaultExecPolicy$1.run(Activation.java:1821) > at java.security.AccessController.doPrivileged(Native Method) > at > sun.rmi.server.Activation$DefaultExecPolicy.checkConfiguration(Activation.java:1820) > > The fix is simple: > > diff -r fd831ae629ff src/share/classes/sun/misc/SharedSecrets.java > --- a/src/share/classes/sun/misc/SharedSecrets.java Tue Apr 06 > 11:57:39 2010 +0100 > +++ b/src/share/classes/sun/misc/SharedSecrets.java Tue Apr 06 > 21:30:03 2010 +0100 > @@ -29,6 +29,7 @@ > import java.io.Console; > import java.io.File; > import java.io.FileDescriptor; > +import java.security.ProtectionDomain; > > /** A repository of "shared secrets", which are a mechanism for > calling implementation-private methods in another package without > @@ -118,6 +119,9 @@ > > public static JavaSecurityProtectionDomainAccess > getJavaSecurityProtectionDomainAccess() { > - return javaSecurityProtectionDomainAccess; > + if (javaSecurityProtectionDomainAccess == null) > + unsafe.ensureClassInitialized(ProtectionDomain.class); > + > + return javaSecurityProtectionDomainAccess; > } > } > > This ensures the class is initialized, making that SharedSecrets > accessor like all the others. > > Can I have a bug ID to push this? > > -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From sean.mullan at oracle.com Wed Apr 7 06:32:25 2010 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 07 Apr 2010 09:32:25 -0400 Subject: Security fixes in b19 - Re: hg: jdk6/jdk6/jdk: 23 new changesets In-Reply-To: <4BBBCE1E.7020806@oracle.com> References: <20100330234719.5834544A94@hg.openjdk.java.net> <4BB29B7D.1050903@oracle.com> <17c6771e1003301752j5c01500fh2a83bcc16ad74cda@mail.gmail.com> <4BBB708B.40108@oracle.com> <4BBB78A2.9040803@oracle.com> <4BBBCE1E.7020806@oracle.com> Message-ID: <4BBC8969.6060802@oracle.com> Joe Darcy wrote: > Sean, > > Please have a look at this fix proposed by Andrew to address a crash in > rmid in OpenJDK 6. Looking at the changes to SharedSecrets, your fix > for 6633872 "Policy/PolicyFile leak dynamic ProtectionDomains." when > applied to OpenJDK 6 looks like the proximal cause of the crash. > > Thanks, Hmm. This bug was fixed already in our JDK releases but hasn't been integrated into 6-open yet. See http://bugs.sun.com/view_bug.do?bug_id=6909281 You won't be able to see much of the details because the comments section is non-public. I'll add a release for 6-open. You can go ahead and push the fix. The diffs look good. It is the same fix. --Sean > > -Joe > > On 04/06/10 01:34 PM, Andrew John Hughes wrote: >> On 6 April 2010 18:08, Joe Darcy wrote: >> >>> Andrew John Hughes wrote: >>> >>>> On 6 April 2010 17:34, Joe Darcy wrote: >>>> >>>> >>>>> Andrew John Hughes wrote: >>>>> >>>>> >>>>>> On 31 March 2010 00:52, Andrew John Hughes wrote: >>>>>> >>>>>> >>>>>> >>>>>>> On 31 March 2010 00:46, Joe Darcy wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>>> The latest round of security fixes are now in the OpenJDK 6 master >>>>>>>> repositories. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> And IcedTea6 1.6, 1.7, 1.8, HEAD and IcedTea7 :-) >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> Joe, where are the fixes for the HotSpot tree? See top of >>>>>> http://hg.openjdk.java.net/icedtea/jdk7/hotspot >>>>>> >>>>>> >>>>>> >>>>>> >>>>> This time around, all the security fixes were in the jdk repository. >>>>> >>>>> -Joe >>>>> >>>>> >>>>> >>>> Err... no they weren't... >>>> >>>> 6626217: Loader-constraint table allows arrays instead of only the >>>> base-classes (CVE-2010-0082) >>>> 6892265: System.arraycopy unable to reference elements beyond >>>> Integer.MAX_VALUE bytes (CVE-2010-0093) >>>> 6894807: No ClassCastException for HashAttributeSet constructors if >>>> run with -Xcomp (CVE-2010-0845) >>>> >>>> and >>>> >>>> 6932480: Crash in CompilerThread/Parser. Unloaded array klass? >>>> >>>> due to a breakage caused by one of the above. >>>> >>>> >>> Hmm, let me check into that... >>> >>> -Joe >>> >>> >> >> There's also a fix missing that we had to apply locally in IcedTea6. >> With current OpenJDK6 hg, rmid crashes: >> >> $ /home/andrew/build/icedtea6-hg/bin/rmid >> Activation.main: an exception occurred: java.lang.NullPointerException >> java.lang.NullPointerException >> at sun.security.provider.PolicyFile$PolicyInfo.(PolicyFile.java:2491) >> at sun.security.provider.PolicyFile.init(PolicyFile.java:468) >> at sun.security.provider.PolicyFile.(PolicyFile.java:327) >> at java.security.Policy.getPolicyNoCheck(Policy.java:189) >> at java.security.Policy.getPolicy(Policy.java:152) >> at sun.rmi.server.Activation$DefaultExecPolicy$1.run(Activation.java:1823) >> at sun.rmi.server.Activation$DefaultExecPolicy$1.run(Activation.java:1821) >> at java.security.AccessController.doPrivileged(Native Method) >> at sun.rmi.server.Activation$DefaultExecPolicy.checkConfiguration(Activation.java:1820) >> >> The fix is simple: >> >> diff -r fd831ae629ff src/share/classes/sun/misc/SharedSecrets.java >> --- a/src/share/classes/sun/misc/SharedSecrets.java Tue Apr 06 >> 11:57:39 2010 +0100 >> +++ b/src/share/classes/sun/misc/SharedSecrets.java Tue Apr 06 >> 21:30:03 2010 +0100 >> @@ -29,6 +29,7 @@ >> import java.io.Console; >> import java.io.File; >> import java.io.FileDescriptor; >> +import java.security.ProtectionDomain; >> >> /** A repository of "shared secrets", which are a mechanism for >> calling implementation-private methods in another package without >> @@ -118,6 +119,9 @@ >> >> public static JavaSecurityProtectionDomainAccess >> getJavaSecurityProtectionDomainAccess() { >> - return javaSecurityProtectionDomainAccess; >> + if (javaSecurityProtectionDomainAccess == null) >> + unsafe.ensureClassInitialized(ProtectionDomain.class); >> + >> + return javaSecurityProtectionDomainAccess; >> } >> } >> >> This ensures the class is initialized, making that SharedSecrets >> accessor like all the others. >> >> Can I have a bug ID to push this? >> > From ahughes at redhat.com Wed Apr 7 09:00:02 2010 From: ahughes at redhat.com (ahughes at redhat.com) Date: Wed, 07 Apr 2010 16:00:02 +0000 Subject: hg: jdk6/jdk6/jdk: 6909281: NPE is thrown when running rmid Message-ID: <20100407160036.7367744433@hg.openjdk.java.net> Changeset: 7b641a18cf0b Author: andrew Date: 2010-04-07 16:59 +0100 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/7b641a18cf0b 6909281: NPE is thrown when running rmid Summary: Fix for 6633872 causes NPE due to uninitialised ProtectionDomain class Reviewed-by: mullan ! src/share/classes/sun/misc/SharedSecrets.java From ahughes at redhat.com Wed Apr 7 09:16:59 2010 From: ahughes at redhat.com (Andrew John Hughes) Date: Wed, 7 Apr 2010 16:16:59 +0000 Subject: Security fixes in b19 - Re: hg: jdk6/jdk6/jdk: 23 new changesets In-Reply-To: <4BBC8969.6060802@oracle.com> References: <20100330234719.5834544A94@hg.openjdk.java.net> <4BB29B7D.1050903@oracle.com> <17c6771e1003301752j5c01500fh2a83bcc16ad74cda@mail.gmail.com> <4BBB708B.40108@oracle.com> <4BBB78A2.9040803@oracle.com> <4BBBCE1E.7020806@oracle.com> <4BBC8969.6060802@oracle.com> Message-ID: On 7 April 2010 13:32, Sean Mullan wrote: > Joe Darcy wrote: >> >> Sean, >> >> Please have a look at this fix proposed by Andrew to address a crash in >> rmid in OpenJDK 6. ?Looking at the changes to SharedSecrets, your fix for >> 6633872 "Policy/PolicyFile leak dynamic ProtectionDomains." when applied to >> OpenJDK 6 looks like the proximal cause of the crash. >> >> Thanks, > > Hmm. This bug was fixed already in our JDK releases but hasn't been > integrated into 6-open yet. See > http://bugs.sun.com/view_bug.do?bug_id=6909281 > > You won't be able to see much of the details because the comments section is > non-public. > > I'll add a release for 6-open. You can go ahead and push the fix. > > The diffs look good. It is the same fix. > > --Sean > Thanks Sean. Pushed: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/7b641a18cf0b > >> >> -Joe >> >> On 04/06/10 01:34 PM, Andrew John Hughes wrote: >>> >>> On 6 April 2010 18:08, Joe Darcy wrote: >>> >>>> >>>> Andrew John Hughes wrote: >>>> >>>>> >>>>> On 6 April 2010 17:34, Joe Darcy wrote: >>>>> >>>>> >>>>>> >>>>>> Andrew John Hughes wrote: >>>>>> >>>>>> >>>>>>> >>>>>>> On 31 March 2010 00:52, Andrew John Hughes >>>>>>> wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> On 31 March 2010 00:46, Joe Darcy wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> The latest round of security fixes are now in the OpenJDK 6 master >>>>>>>>> repositories. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> And IcedTea6 1.6, 1.7, 1.8, HEAD and IcedTea7 :-) >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> Joe, where are the fixes for the HotSpot tree? ?See top of >>>>>>> http://hg.openjdk.java.net/icedtea/jdk7/hotspot >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> This time around, all the security fixes were in the jdk repository. >>>>>> >>>>>> -Joe >>>>>> >>>>>> >>>>>> >>>>> >>>>> Err... no they weren't... >>>>> >>>>> 6626217: Loader-constraint table allows arrays instead of only the >>>>> base-classes (CVE-2010-0082) >>>>> 6892265: System.arraycopy unable to reference elements beyond >>>>> Integer.MAX_VALUE bytes (CVE-2010-0093) >>>>> 6894807: No ClassCastException for HashAttributeSet constructors if >>>>> run with -Xcomp (CVE-2010-0845) >>>>> >>>>> and >>>>> >>>>> 6932480: Crash in CompilerThread/Parser. Unloaded array klass? >>>>> >>>>> due to a breakage caused by one of the above. >>>>> >>>>> >>>> >>>> Hmm, let me check into that... >>>> >>>> -Joe >>>> >>>> >>> >>> There's also a fix missing that we had to apply locally in IcedTea6. >>> With current OpenJDK6 hg, rmid crashes: >>> >>> $ /home/andrew/build/icedtea6-hg/bin/rmid >>> Activation.main: an exception occurred: java.lang.NullPointerException >>> java.lang.NullPointerException >>> ? ? ? ?at >>> sun.security.provider.PolicyFile$PolicyInfo.(PolicyFile.java:2491) >>> ? ? ? ?at sun.security.provider.PolicyFile.init(PolicyFile.java:468) >>> ? ? ? ?at sun.security.provider.PolicyFile.(PolicyFile.java:327) >>> ? ? ? ?at java.security.Policy.getPolicyNoCheck(Policy.java:189) >>> ? ? ? ?at java.security.Policy.getPolicy(Policy.java:152) >>> ? ? ? ?at >>> sun.rmi.server.Activation$DefaultExecPolicy$1.run(Activation.java:1823) >>> ? ? ? ?at >>> sun.rmi.server.Activation$DefaultExecPolicy$1.run(Activation.java:1821) >>> ? ? ? ?at java.security.AccessController.doPrivileged(Native Method) >>> ? ? ? ?at >>> sun.rmi.server.Activation$DefaultExecPolicy.checkConfiguration(Activation.java:1820) >>> >>> The fix is simple: >>> >>> diff -r fd831ae629ff src/share/classes/sun/misc/SharedSecrets.java >>> --- a/src/share/classes/sun/misc/SharedSecrets.java ? ? Tue Apr 06 >>> 11:57:39 2010 +0100 >>> +++ b/src/share/classes/sun/misc/SharedSecrets.java ? ? Tue Apr 06 >>> 21:30:03 2010 +0100 >>> @@ -29,6 +29,7 @@ >>> ?import java.io.Console; >>> ?import java.io.File; >>> ?import java.io.FileDescriptor; >>> +import java.security.ProtectionDomain; >>> >>> ?/** A repository of "shared secrets", which are a mechanism for >>> ? ? calling implementation-private methods in another package without >>> @@ -118,6 +119,9 @@ >>> >>> ? ? public static JavaSecurityProtectionDomainAccess >>> ? ? ? ? getJavaSecurityProtectionDomainAccess() { >>> - ? ? ? ? ? ?return javaSecurityProtectionDomainAccess; >>> + ? ? ? ?if (javaSecurityProtectionDomainAccess == null) >>> + ? ? ? ? ? ?unsafe.ensureClassInitialized(ProtectionDomain.class); >>> + >>> + ? ? ? ?return javaSecurityProtectionDomainAccess; >>> ? ? } >>> ?} >>> >>> This ensures the class is initialized, making that SharedSecrets >>> accessor like all the others. >>> >>> Can I have a bug ID to push this? >>> >> > -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From alex.menkov at sun.com Wed Apr 7 09:30:43 2010 From: alex.menkov at sun.com (Alex Menkov) Date: Wed, 07 Apr 2010 20:30:43 +0400 Subject: SV: [Request for review and bugid] A collection of fixes for gervill (2010-04) In-Reply-To: <36EC82E93EB0AD40A4301DAD654323860146CD9D88F9@mail.midverk.is> References: <36EC82E93EB0AD40A4301DAD654323860146CD9D88F8@mail.midverk.is> <4BBA9A75.5060408@oracle.com> <36EC82E93EB0AD40A4301DAD654323860146CD9D88F9@mail.midverk.is> Message-ID: <4BBCB333.5060101@sun.com> Hi Karl, my comments about the fix: src/share/classes/com/sun/media/sound/AudioFloatFormatConverter.java could you please remove empty statements at lines 178 & 188 (the lines consist of only ";" symbol) src/share/classes/com/sun/media/sound/SoftChannel.java year in the copyright header has been changed from 2007 to 2010 I believe 2007-2010 would be more correct. src/share/classes/com/sun/media/sound/SoftSynthesizer.java line 28: +import java.awt.image.BufferedImage; the import is definitely unnecessary. getDefaultSoundbank method: Now you search for available soundbank (jre home, windows system soundbank, saved soundbank) and open InputStream (returned from doPrivileged). Then use MidiSystem.getSoundbank() to get soundbank from the stream. If, for example, jre home have a soundbank in lib/audio, but the file is corrupted, MidiSystem.getSoundbank() throws exception and windows system sounbank & saved soundbank won't be tried to load. I think old algorithm was better (in the case I described it tries to load soundbank from other locations). (Note that you are completely right that MidiSystem.getSoundbank() must be called outside of privileged code to prevent security vulnerability) About using Preferences (support for user config file). It's not evident for me that the synthesizer needs the feature. Could you please describe how it's supposed to be used? And couple notes about the implementation: - Could you reformat the code like the rest of the code (now it looks like code in "C/C++ style") - AudioFormat parsing (lines 966-995): StringTokenizer uses default delimiters. I think it would be better to add comma to the delimiter list - it would add compatibility with AudioFormat.toString implementation (it uses commas). for the same reason "channels" would be better than "ch". regards Alex Karl Helgason wrote: > Hi, > > I added the missing "newline at the end of the file" to both SkipTest.java and ModelStandardIndexedDirector.java. > > http://cr.openjdk.java.net/~kalli/gervill-update/webrev.02/ > > regards, > Karl > ________________________________________ > Fr?: joe.darcy at oracle.com [joe.darcy at oracle.com] > Sent: 6. apr?l 2010 02:20 > Vi?takandi: Karl Helgason > Afrit: jdk6-dev at openjdk.java.net; alexey.menkov at sun.com; joe.darcy at sun.com; Dalibor.Topic at Sun.COM > Efni: Re: [Request for review and bugid] A collection of fixes for gervill (2010-04) > > Hello. > > I've filed bug 6941027 "Gervill update, April 2010" for this work. > However, I will leave Alexey to do the actual code reviewing for OpenJDK > 6 and JDK 7. > > Note that > test/javax/sound/midi/Gervill/AudioFloatFormatConverter/SkipTest.java > doesn't have a newline at the end of the file. > > -Joe > > On 4/5/2010 1:29 PM, Karl Helgason wrote: >> Hi, >> >> I need code review and bugid for the fix: >> http://cr.openjdk.java.net/~kalli/gervill-update/webrev.01/ >> >> Major fixes this webrev includes are: >> >> * Allow access to cached emergency soundbank using AccessController.doPrivileged >> This fix allows using cached emergency soundbank in applets >> which speeds up loading of applets especially on slow computers. >> And also using AccessController.doPrivileged we can use user-installed >> soundfonts in applets e.g. soundfonts found in audio folder of JRE. >> >> * Support for user config file. >> Default settings for Gervill don't always suit everybody, >> some needed lower latency, different samplerate and e.t.c >> To fix that a support to allow user to change default settings using >> Preferences API was added. >> >> * Fixed how getAvailableInstruments and getLoadedInstruments worked. >> SoftSynthesizer.getAvailableInstruments now always returns instruments >> from default soundbank. And getLoadedInstruments now always returns >> loaded instruments. The behavior of these methods where not correct. >> >> * Improved support for large soundbanks >> a) Indexed version of ModelStandardDirector added which speeds up >> looking up notes in instruments with many layers. >> b) Allow unused instrument to be garbage collected more easily, >> we now put null value to unused variable. >> c) Prevent unnecessary lookup of instrument object >> on pseudo program change (when bank and program is unchanged) >> >> * Enable user to disable loading default soundbank. >> Some users wanted to be able to open the synthesizer >> without the synthesizer loading the default soundbank. >> >> And then there was several other bug fixes: >> * Fix: Synchronization bug in n SoftSynthesizer.getDefaultSoundbank >> * Fix: AudioFloatInputStreamResampler.skip broken >> * Fix: RealTime scale/octave tuning doesn't affect sounding notes. >> * Fix: ModelByteBufferWaveTable.openStream().getFrameLength() >> returns incorrect values in some cases. >> >> Heres complete list of changes made: >> - Fix: Use AccessController.doPrivileged to access user settings >> and cached emergency soundbank. >> Affected File/Method: SoftSynthesizer.getDefaultSoundbank >> - Add: Support for user config file. >> Affected File/Method: SoftSynthesizer.getPropertyInfo >> - Add: Let SoftSynthesizer.getPropertyInfo use type conversion when needed. >> JTreg test added: >> /test/SoftSynthesizer/GetPropertyInfo >> - Add: Enable user to disable loading default soundbank. >> Affected File/Method: SoftSynthesizer.getPropertyInfo >> SoftSynthesizer.processPropertyInfo >> SoftSynthesizer.openStream >> JTreg test added: >> /test/SoftSynthesizer/TestDisableLoadDefaultSoundbank >> - Fix: SoftSynthesizer.getAvailableInstruments should >> always return instruments from default soundbank. >> Affected File/Method: SoftSynthesizer.getAvailableInstruments >> JTreg test added: >> /test/SoftSynthesizer/GetAvailableInstruments2 >> - Fix: SoftSynthesizer.getLoadedInstruments should always >> return loaded instrument. >> Affected File/Method: SoftSynthesizer.getLoadedInstruments >> JTreg test added: >> /test/SoftSynthesizer/GetLoadedInstruments2 >> JTreg tests fixed: >> /test/SoftSynthesizer/LoadAllInstruments >> /test/SoftSynthesizer/LoadInstrument >> /test/SoftSynthesizer/LoadInstruments >> /test/SoftSynthesizer/RemapInstrument >> * this test never worked correctly >> /test/SoftSynthesizer/UnloadAllInstruments >> /test/SoftSynthesizer/UnloadInstrument >> /test/SoftSynthesizer/UnloadInstruments >> - Fix: SoftSynthesizer.getDefaultSoundbank is not properly synchronized. >> Affected File/Method: SoftSynthesizer.getDefaultSoundbank >> - Optimization: Indexed version of ModelStandardDirector added. >> - Optimization: Fully unload instruments by setting null to unused values. >> Affected Files: SoftVoice, SoftChannel, SoftSynthesizer >> - Optimization: Prevent unnecessary lookup of instrument object >> on pseudo program change (when bank and program is unchanged) >> Affected File/Method: SoftChannel.programChange >> - Fix: AudioFloatInputStreamResampler.skip broken. >> (Gervill Bug Issues 5) >> see: https://gervill.dev.java.net/issues/show_bug.cgi?id=5 >> Affected File/Method: >> AudioFloatFormatConverter.AudioFloatInputStreamResampler.skip >> JTreg test added: >> /test/AudioFloatFormatConverter/SkipTest >> - Fix: ModelByteBufferWaveTable.openStream().getFrameLength() >> returns incorrect values in some cases. >> (Gervill Bug Issues 4) >> see: https://gervill.dev.java.net/issues/show_bug.cgi?id=4 >> Affected File/Method: ModelByteBufferWaveTable.openStream >> JTreg test added: >> /test/ModelByteBufferWavetable/OpenStream >> - Fix: RealTime scale/octave tuning doesn't affect sounding notes. >> Affected File/Method: SoftVoice.updateTuning >> JTreg test added: >> /test/ModelByteBufferWavetable/OpenStream >> From ahughes at redhat.com Wed Apr 7 09:37:50 2010 From: ahughes at redhat.com (ahughes at redhat.com) Date: Wed, 07 Apr 2010 16:37:50 +0000 Subject: hg: jdk6/jdk6/hotspot: 6879689: Fix warning about ignored return value when compiling with -O2 Message-ID: <20100407163804.8156E44438@hg.openjdk.java.net> Changeset: 6ee696377676 Author: andrew Date: 2009-09-08 09:01 +0100 URL: http://hg.openjdk.java.net/jdk6/jdk6/hotspot/rev/6ee696377676 6879689: Fix warning about ignored return value when compiling with -O2 Summary: Store the return value of fwrite and check it matches the size of the array. Reviewed-by: twisti, dholmes ! src/share/vm/adlc/archDesc.cpp From ahughes at redhat.com Wed Apr 7 14:35:29 2010 From: ahughes at redhat.com (Andrew John Hughes) Date: Wed, 7 Apr 2010 21:35:29 +0000 Subject: Test Backports In-Reply-To: <4BBBD0EE.7040705@oracle.com> References: <17c6771e1003291310u3e1b3231i6a054fd76bc24182@mail.gmail.com> <4BB112FD.9070702@oracle.com> <17c6771e1003291849m7d920b2ey7e4b15bd0f748a0a@mail.gmail.com> <4BB3ABEE.4070102@oracle.com> <4BBA91BD.8020105@oracle.com> <4BBBD0EE.7040705@oracle.com> Message-ID: On 7 April 2010 00:25, Joe Darcy wrote: > On 04/06/10 01:27 PM, Andrew John Hughes wrote: > > On 6 April 2010 01:43, Joe Darcy wrote: > > > On 03/31/10 02:41 PM, Andrew John Hughes wrote: > > On 31 March 2010 20:09, Joe Darcy wrote: > > > Andrew John Hughes wrote: > > > On 29 March 2010 20:52, Joe Darcy wrote: > > > > Andrew John Hughes wrote: > > > > There are a set of bidi and math tests: > > changeset: ? 817:8ea49fa4c2f7 > user: ? ? ? ?peytoia > date: ? ? ? ?Fri Oct 17 13:34:03 2008 +0900 > summary: ? ? 6759521: Move Bidi test programs from closed to open. > > http://hg.openjdk.java.net/jdk7/jdk7/jdk/rev/8ea49fa4c2f7 > > > > > I approve the bidi tests going back; please verify they pass first though > :-) > > > > > Passed and pushed; > http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/e1549056d958 > > > > Thanks. > > > > changeset: ? 809:f3ad2ee4600b > user: ? ? ? ?darcy > date: ? ? ? ?Mon Jan 26 19:49:26 2009 -0800 > description: > 6601457: Move wrapper class tests from closed to open > 6601458: Move java.math tests from closed to open > 6740185: Move java/lang/annotations tests to open > 6759433: Move Math and StrictMath regression tests from closed to open > Summary: Move some more regression tests to the open > Reviewed-by: jjg > > http://hg.openjdk.java.net/jdk7/jdk7/jdk/rev/f3ad2ee4600b > > that were opened up in OpenJDK7. ?Ok to backport these to 6? > > > > > However, I deny these other tests being backported since they have long > been > in OpenJDK 6 :-) > > > > > Doh! ?Looks like they were still lurking around in the IcedTea tree > but no longer being applied. > > I found a bunch of others too: > > comparing with ssh://hg.openjdk.java.net/jdk6/jdk6-gate/jdk > searching for changes > changeset: ? 308:d5dc9130bdb0 > user: ? ? ? ?volk > date: ? ? ? ?Sun Apr 13 23:41:40 2008 +0400 > summary: ? ? 6686273: Some AWT reg. tests should be moved to open > repository (for CRs 6444769, 6480547, and 6560348) > > changeset: ? 309:fa6cfc27b519 > user: ? ? ? ?ant > date: ? ? ? ?Wed Mar 26 16:20:01 2008 +0300 > summary: ? ? 6680135: A number of test/closed/java/awt/Focus/* tests > should be opened > > changeset: ? 310:285a274f844a > user: ? ? ? ?sherman > date: ? ? ? ?Mon Jun 30 14:06:34 2008 -0700 > summary: ? ? 6675856: Open charset tests > > changeset: ? 311:47f907e9c9b3 > user: ? ? ? ?malenkov > date: ? ? ? ?Thu Jun 26 15:11:04 2008 +0400 > summary: ? ? 6718964: Swing border tests should be open source > > changeset: ? 312:a6d7e84e31e1 > user: ? ? ? ?malenkov > date: ? ? ? ?Thu Jun 26 15:39:12 2008 +0400 > summary: ? ? 6718965: Swing color chooser tests should be open source > > changeset: ? 313:62168e9450f9 > user: ? ? ? ?sherman > date: ? ? ? ?Thu Aug 13 15:01:18 2009 -0700 > summary: ? ? 6676423: (prefs) Opensource unit/regression tests for > java.util.prefs > > changeset: ? 314:83980d94b138 > tag: ? ? ? ? tip > user: ? ? ? ?sherman > date: ? ? ? ?Wed Jan 27 19:39:55 2010 -0800 > summary: ? ? 6920732: opensource test/java/nio/charset > > Ok to backport? ?The majority pass, with the failures being in the AWT > ones (may be my setup, as some of the existing ones fail too) and > prefs (I think it's trying to acquire a lock on a NFS mount). > > > > Yes in principle, but let me dig into the particular changes a bit to > double-check they're applicable to and appropriate for OpenJDK 6. > > > > Ok, the comments suggested to me they were forwardports from the > proprietary tree but good to check. > > > I've looked over each of these patches, and they all seem applicable to > OpenJDK 6 so I approve all of them going back. > > (It is feasible a patch would be applicable to a portion of the proprietary > JDK 7, but not applicable to the corresponding portion of OpenJDK 6.) > > > > Thanks for checking. Obviously you're one of the few who can do so > for the proprietary JDKs. > > Pushed: > http://mail.openjdk.java.net/pipermail/jdk6-dev/2010-April/001427.html > > > Thanks. > > > > On my queue, I have four more Zero patches and a set of backports I'd > like in (making the source/target explicit as we did in 7 already, and > Kelly's ant 1.8 patch). Everything else can wait until b20 > > > > Here's the backport: > > http://cr.openjdk.java.net/~andrew/6873059/webrev.01/jdk6.patch > > It's a replica of 6873059 as applied to the HotSpot, JDK and CORBA > trees in OpenJDK7, the only difference being that we use 5 instead of > 6 as the bootstrap version for OpenJDK6. Ok to push? Should I use > the same bug ID or do you want to allocate a fresh one? > > > Using the same bug id is fine, but I'd like Kelly to sanity check it before > it goes back. > Ok, waiting for Kelly's response. > On another note, there is now some code requiring source level 6 in > OpenJDK6 (due to use of the @Override annotation on interfaces): > > src/share/classes/javax/swing/plaf/synth/SynthComboBoxUI.java > src/share/classes/javax/swing/plaf/synth/SynthLookAndFeel.java > src/share/classes/javax/swing/plaf/synth/SynthTreeUI.java > src/share/classes/sun/security/provider/certpath/OCSPResponse.java > src/share/classes/sun/swing/plaf/synth/SynthFileChooserUIImpl.java > > > There is an overly-long story behind -source 5 vs. -source 6 and @Override. > The short answer is that javac in JDK 6 unconditionally applies the more > liberal (and more useful) semantics for @Override.? For the JDK sources, a > compiler that does the same should be used. > Exactly. I know ecj throws it out for 5 but not for 6 and thus building using ecj (our method for bootstrapping) falls foul of the classes above. I'm not sure if javac is allowing them through because its version of 1.5 allows it or it is simply defaulting to 6 because nothing else is specified. I had a quick look but the version is currently set in more than one place, so I think this needs a more in-depth review and I'd prefer it waits until b20 to be on the safe side. > So we should look at bumping the generated code version to 6 (it still > seems to be 5 even though this is OpenJDK6). I'd prefer to leave that > until b20 though. > > I see Kelly's patch went in. It would be nice to also backport > http://hg.openjdk.java.net/jdk7/jdk7/hotspot/rev/5fdbe2cdf565 (a minor > warning fix) so IcedTea6's OpenJDK backport set is empty again. > > > I approve the warning fix being backported. > Done: http://hg.openjdk.java.net/jdk6/jdk6/hotspot/rev/6ee696377676 The first of the four Zero backports is 6903453: Zero build on ARM and IA-64. http://cr.openjdk.java.net/~andrew/6903453/webrev.01/ It adds a few build conditionals for building on arm and ia64 platforms. Ok to push? > -Joe > > -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From joe.darcy at oracle.com Wed Apr 7 18:20:41 2010 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 07 Apr 2010 18:20:41 -0700 Subject: Test Backports In-Reply-To: References: <17c6771e1003291310u3e1b3231i6a054fd76bc24182@mail.gmail.com> <4BB112FD.9070702@oracle.com> <17c6771e1003291849m7d920b2ey7e4b15bd0f748a0a@mail.gmail.com> <4BB3ABEE.4070102@oracle.com> <4BBA91BD.8020105@oracle.com> <4BBBD0EE.7040705@oracle.com> Message-ID: <4BBD2F69.4070609@oracle.com> Andrew John Hughes wrote: > On 7 April 2010 00:25, Joe Darcy wrote: > >> On 04/06/10 01:27 PM, Andrew John Hughes wrote: >> >> On 6 April 2010 01:43, Joe Darcy wrote: >> [snip] >> >> >> On my queue, I have four more Zero patches and a set of backports I'd >> like in (making the source/target explicit as we did in 7 already, and >> Kelly's ant 1.8 patch). Everything else can wait until b20 >> >> >> >> Here's the backport: >> >> http://cr.openjdk.java.net/~andrew/6873059/webrev.01/jdk6.patch >> >> It's a replica of 6873059 as applied to the HotSpot, JDK and CORBA >> trees in OpenJDK7, the only difference being that we use 5 instead of >> 6 as the bootstrap version for OpenJDK6. Ok to push? Should I use >> the same bug ID or do you want to allocate a fresh one? >> >> >> Using the same bug id is fine, but I'd like Kelly to sanity check it before >> it goes back. >> >> > > Ok, waiting for Kelly's response. > Acknowledged. > >> On another note, there is now some code requiring source level 6 in >> OpenJDK6 (due to use of the @Override annotation on interfaces): >> >> src/share/classes/javax/swing/plaf/synth/SynthComboBoxUI.java >> src/share/classes/javax/swing/plaf/synth/SynthLookAndFeel.java >> src/share/classes/javax/swing/plaf/synth/SynthTreeUI.java >> src/share/classes/sun/security/provider/certpath/OCSPResponse.java >> src/share/classes/sun/swing/plaf/synth/SynthFileChooserUIImpl.java >> >> >> There is an overly-long story behind -source 5 vs. -source 6 and @Override. >> The short answer is that javac in JDK 6 unconditionally applies the more >> liberal (and more useful) semantics for @Override. For the JDK sources, a >> compiler that does the same should be used. >> >> > > Exactly. I know ecj throws it out for 5 but not for 6 and thus > building using ecj (our method for bootstrapping) falls foul of the > classes above. I'm not sure if javac is allowing them through because > its version of 1.5 allows it or it is simply defaulting to 6 because > nothing else is specified. I had a quick look but the version is > currently set in more than one place, so I think this needs a more > in-depth review and I'd prefer it waits until b20 to be on the safe > side. > The javac command in JDK 6, both open and proprietary, will allow use of @Override on interfaces, even if "-source 5" is specified. >> So we should look at bumping the generated code version to 6 (it still >> seems to be 5 even though this is OpenJDK6). I'd prefer to leave that >> until b20 though. >> >> I see Kelly's patch went in. It would be nice to also backport >> http://hg.openjdk.java.net/jdk7/jdk7/hotspot/rev/5fdbe2cdf565 (a minor >> warning fix) so IcedTea6's OpenJDK backport set is empty again. >> >> >> I approve the warning fix being backported. >> >> > > Done: http://hg.openjdk.java.net/jdk6/jdk6/hotspot/rev/6ee696377676 > Thanks, > The first of the four Zero backports is 6903453: Zero build on ARM and IA-64. > > http://cr.openjdk.java.net/~andrew/6903453/webrev.01/ > > It adds a few build conditionals for building on arm and ia64 platforms. > > Ok to push? > Approved to go back. I've run some regression tests on a build from the current tip and the result look good; in particular, all the rmid tests pass again :-) Detailed diffs from b18: 0: ../test_results.b18/JTreport.hotspot pass: 24 1: JTreport.hotspot pass: 62 0 1 Test --- pass compiler/5057225/Test5057225.java --- pass compiler/6378821/Test6378821.java --- pass compiler/6539464/Test.java --- pass compiler/6589834/Test_ia32.java --- pass compiler/6603011/Test.java --- pass compiler/6636138/Test1.java --- pass compiler/6636138/Test2.java --- pass compiler/6711117/Test.java --- pass compiler/6772683/InterruptedTest.java --- pass compiler/6778657/Test.java --- pass compiler/6795161/Test.java --- pass compiler/6795465/Test6795465.java --- pass compiler/6797305/Test6797305.java --- pass compiler/6799693/Test.java --- pass compiler/6800154/Test6800154.java --- pass compiler/6814842/Test6814842.java --- pass compiler/6823354/Test6823354.java --- pass compiler/6823453/Test.java --- pass compiler/6826736/Test.java --- pass compiler/6832293/Test.java --- pass compiler/6833129/Test.java --- pass compiler/6837011/Test6837011.java --- pass compiler/6837094/Test.java --- pass compiler/6843752/Test.java --- pass compiler/6849574/Test.java --- pass compiler/6851282/Test.java --- pass compiler/6852078/Test6852078.java --- pass compiler/6855164/Test.java --- pass compiler/6855215/Test6855215.java --- pass compiler/6857159/Test6857159.java --- pass compiler/6859338/Test6859338.java --- pass compiler/6860469/Test.java --- pass compiler/6863155/Test6863155.java --- pass compiler/6863420/Test.java --- pass compiler/6865031/Test.java --- pass compiler/6875866/Test.java --- pass compiler/6892265/Test.java --- pass gc/6845368/bigobj.java 38 differences Langtools: 0: ../test_results.b18/JTreport.langtools pass: 1,355 1: JTreport.langtools pass: 1,359 0 1 Test --- pass tools/javac/enum/T6724345.java --- pass tools/javac/processing/6511613/clss41701.java --- pass tools/javac/processing/6634138/T6634138.java --- pass tools/javac/processing/model/util/elements/VacuousEnum.java 4 differences JDK: 0: ../test_results.b18/JTreport.jdk pass: 3,148; fail: 19; error: 2 1: JTreport.jdk pass: 3,252; fail: 29; error: 4 0 1 Test pass fail com/sun/crypto/provider/KeyFactory/TestProviderLeak.java --- error java/awt/Focus/ActualFocusedWindowTest/ActualFocusedWindowBlockingTest.java --- error java/awt/Focus/ActualFocusedWindowTest/ActualFocusedWindowRetaining.java --- error java/awt/Focus/NonFocusableWindowTest/NonfocusableOwnerTest.java --- pass java/awt/Focus/NonFocusableWindowTest/Test.java --- pass java/awt/Focus/TypeAhead/TestFocusFreeze.java pass fail java/awt/Frame/MaximizedToIconified/MaximizedToIconified.java --- fail java/awt/Insets/WindowWithWarningTest/WindowWithWarningTest.html pass fail java/awt/TextArea/UsingWithMouse/SelectionAutoscrollTest.html fail pass java/awt/event/KeyEvent/CorrectTime/CorrectTime.java --- pass java/awt/xembed/server/RunTestXEmbed.java --- pass java/nio/charset/Charset/AvailableCharsetNames.java --- pass java/nio/charset/Charset/CharsetContainmentTest.java --- fail java/nio/charset/Charset/Contains.java --- pass java/nio/charset/Charset/EmptyCharsetName.java --- pass java/nio/charset/Charset/EncDec.java --- pass java/nio/charset/Charset/IllegalCharsetName.java --- fail java/nio/charset/Charset/NIOCharsetAvailabilityTest.java --- pass java/nio/charset/Charset/NullCharsetName.java --- pass java/nio/charset/Charset/RegisteredCharsets.java --- pass java/nio/charset/Charset/default.sh --- pass java/nio/charset/CharsetDecoder/AverageMax.java --- pass java/nio/charset/CharsetDecoder/EmptyInput.java --- pass java/nio/charset/CharsetEncoder/CanEncode.java --- pass java/nio/charset/CharsetEncoder/Flush.java --- pass java/nio/charset/RemovingSunIO/SunioAlias.java --- pass java/nio/charset/RemovingSunIO/TestCOMP.java --- pass java/nio/charset/RemovingSunIO/TestUnmappableForLength.java --- pass java/nio/charset/coders/BashCache.java --- pass java/nio/charset/coders/BashStreams.java --- pass java/nio/charset/coders/Check.java --- pass java/nio/charset/coders/CheckSJISMappingProp.sh --- pass java/nio/charset/coders/Errors.java --- pass java/nio/charset/coders/FullRead.java --- pass java/nio/charset/coders/IOCoders.java --- pass java/nio/charset/coders/IsLegalReplacement.java --- pass java/nio/charset/coders/ResetISO2022JP.java --- pass java/nio/charset/coders/StreamTimeout.java --- pass java/nio/charset/coders/Surrogates.java --- pass java/nio/charset/spi/basic.sh fail pass java/rmi/transport/pinLastArguments/PinLastArguments.java --- pass java/text/Bidi/BidiBug.java --- pass java/text/Bidi/BidiEmbeddingTest.java --- pass java/text/Bidi/BidiSurrogateTest.java --- pass java/util/prefs/CommentsInXml.java --- pass java/util/prefs/ConflictInFlush.java --- pass java/util/prefs/ExportNode.java --- pass java/util/prefs/ExportSubtree.java --- pass java/util/prefs/PrefsSpi.sh --- pass java/util/prefs/RemoveReadOnlyNode.java --- pass java/util/prefs/RemoveUnregedListener.java --- pass java/util/prefs/SerializeExceptions.java --- pass javax/swing/JColorChooser/Test4165217.java --- pass javax/swing/JColorChooser/Test4177735.java --- pass javax/swing/JColorChooser/Test4193384.java --- pass javax/swing/JColorChooser/Test4234761.java --- pass javax/swing/JColorChooser/Test4461329.java --- pass javax/swing/JColorChooser/Test4711996.java --- pass javax/swing/border/Test4120351.java --- pass javax/swing/border/Test4124729.java --- pass javax/swing/border/Test6461042.java --- pass sun/nio/cs/BufferUnderflowEUCTWTest.java --- pass sun/nio/cs/CheckCaseInsensitiveEncAliases.java --- pass sun/nio/cs/CheckHistoricalNames.java --- pass sun/nio/cs/ConvertSingle.java --- pass sun/nio/cs/DecoderOverflow.java --- pass sun/nio/cs/EUCJPUnderflowDecodeTest.java --- pass sun/nio/cs/EucJpLinux0212.java --- pass sun/nio/cs/EucJpLinuxDecoderRecoveryTest.java --- pass sun/nio/cs/EuroConverter.java --- pass sun/nio/cs/FindASCIICodingBugs.java --- pass sun/nio/cs/FindASCIIRangeCodingBugs.java --- pass sun/nio/cs/FindCanEncodeBugs.java --- pass sun/nio/cs/FindDecoderBugs.java --- pass sun/nio/cs/FindEncoderBugs.java --- pass sun/nio/cs/FindOneCharEncoderBugs.java --- pass sun/nio/cs/HWKatakanaMS932EncodeTest.java --- pass sun/nio/cs/ISCIITest.java --- pass sun/nio/cs/ISO8859x.java --- pass sun/nio/cs/JISAutoDetectTest.java --- pass sun/nio/cs/LatinCharReplacementTWTest.java --- pass sun/nio/cs/LeftOverSurrogate.java --- pass sun/nio/cs/MalformedSurrogates.java --- pass sun/nio/cs/NIOJISAutoDetectTest.java --- pass sun/nio/cs/ReadZero.java --- pass sun/nio/cs/SJISCanEncode.java --- pass sun/nio/cs/StreamEncoderClose.java --- pass sun/nio/cs/SurrogateGB18030Test.java --- pass sun/nio/cs/SurrogateTestEUCTW.java --- pass sun/nio/cs/SurrogateTestHKSCS.java --- fail sun/nio/cs/Test4200310.sh --- pass sun/nio/cs/Test4206507.java --- pass sun/nio/cs/Test6254467.java --- pass sun/nio/cs/Test6275027.java --- pass sun/nio/cs/TestCompoundTest.java --- pass sun/nio/cs/TestConverterDroppedCharacters.java --- pass sun/nio/cs/TestCp834_SBCS.java --- pass sun/nio/cs/TestCp93xSISO.java --- pass sun/nio/cs/TestIBMBugs.java --- pass sun/nio/cs/TestISCII91.java --- pass sun/nio/cs/TestISO2022CNDecoder.java --- pass sun/nio/cs/TestISO2022JP.java --- pass sun/nio/cs/TestISO2022JPEncoder.java --- pass sun/nio/cs/TestISO2022JPSubBytes.java --- pass sun/nio/cs/TestIllegalISO2022Esc.java --- pass sun/nio/cs/TestIllegalSJIS.java --- pass sun/nio/cs/TestJIS0208Decoder.java --- pass sun/nio/cs/TestJIS0212Decoder.java --- pass sun/nio/cs/TestMS5022X.java --- pass sun/nio/cs/TestMiscEUC_JP.java --- fail sun/nio/cs/TestSJIS0213.java --- pass sun/nio/cs/TestTrailingEscapesISO2022JP.java --- pass sun/nio/cs/TestUTF8BOM.java --- pass sun/nio/cs/TestUTF_16.java --- pass sun/nio/cs/TestUni2HKSCS.java --- pass sun/nio/cs/TestX11JIS0201.java --- pass sun/nio/cs/UkrainianIsNotRussian.java --- pass sun/nio/cs/ZeroedByteArrayEUCTWTest.java pass --- sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/InvalidateServerSessionRenegotiate.java pass --- sun/security/ssl/javax/net/ssl/NewAPIs/JSSERenegotiate.java pass --- sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/CheckStatus.java pass --- sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/ConnectionTest.java pass --- sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/NoAuthClientAuth.java error pass sun/security/ssl/javax/net/ssl/NewAPIs/SessionTimeOutTests.java --- fail sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/DNSIdentities.java --- pass sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/HttpsCreateSockTest.java --- pass sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/HttpsSocketFacTest.java --- pass sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/IPAddressDNSIdentities.java --- fail sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/IPAddressIPIdentities.java --- fail sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/IPIdentities.java --- fail sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/Identities.java --- pass sun/security/util/Oid/BerOid.java 132 differences -Joe From kalli at midverk.is Thu Apr 8 01:26:40 2010 From: kalli at midverk.is (Karl Helgason) Date: Thu, 8 Apr 2010 08:26:40 +0000 Subject: SV: SV: [Request for review and bugid] A collection of fixes for gervill (2010-04) In-Reply-To: <4BBCB333.5060101@sun.com> References: <36EC82E93EB0AD40A4301DAD654323860146CD9D88F8@mail.midverk.is> <4BBA9A75.5060408@oracle.com> <36EC82E93EB0AD40A4301DAD654323860146CD9D88F9@mail.midverk.is>, <4BBCB333.5060101@sun.com> Message-ID: <36EC82E93EB0AD40A4301DAD654323860146CD9D88FD@mail.midverk.is> Hi, I have made those changes you talked about: http://cr.openjdk.java.net/~kalli/gervill-update/webrev.03/ I'm however not sure if I got all code formatting correct. > About using Preferences (support for user config file). > It's not evident for me that the synthesizer needs the feature. Could > you please describe how it's supposed to be used? Only way now to change synthesizer settings is to use the AudioSynthesizer interface. But the problem is that most programs don't know about it. So the only way to change those settings would be to allow user to change the default settings using for example the Preference API. One reason for changing the default settings would be that users want to use different audio format or require lower latency settings, it is by default 120 msec but on windows we can go as low as 20 msec latency and and other platforms we can go even lower. regards, Karl ________________________________________ Fr?: Alexey.Menkov at Sun.COM [Alexey.Menkov at Sun.COM] Fyrir hönd Alex Menkov [alex.menkov at Sun.COM] Sent: 7. apr?l 2010 16:30 Vi?takandi: Karl Helgason Afrit: jdk6-dev at openjdk.java.net Efni: Re: SV: [Request for review and bugid] A collection of fixes for gervill (2010-04) Hi Karl, my comments about the fix: src/share/classes/com/sun/media/sound/AudioFloatFormatConverter.java could you please remove empty statements at lines 178 & 188 (the lines consist of only ";" symbol) src/share/classes/com/sun/media/sound/SoftChannel.java year in the copyright header has been changed from 2007 to 2010 I believe 2007-2010 would be more correct. src/share/classes/com/sun/media/sound/SoftSynthesizer.java line 28: +import java.awt.image.BufferedImage; the import is definitely unnecessary. getDefaultSoundbank method: Now you search for available soundbank (jre home, windows system soundbank, saved soundbank) and open InputStream (returned from doPrivileged). Then use MidiSystem.getSoundbank() to get soundbank from the stream. If, for example, jre home have a soundbank in lib/audio, but the file is corrupted, MidiSystem.getSoundbank() throws exception and windows system sounbank & saved soundbank won't be tried to load. I think old algorithm was better (in the case I described it tries to load soundbank from other locations). (Note that you are completely right that MidiSystem.getSoundbank() must be called outside of privileged code to prevent security vulnerability) About using Preferences (support for user config file). It's not evident for me that the synthesizer needs the feature. Could you please describe how it's supposed to be used? And couple notes about the implementation: - Could you reformat the code like the rest of the code (now it looks like code in "C/C++ style") - AudioFormat parsing (lines 966-995): StringTokenizer uses default delimiters. I think it would be better to add comma to the delimiter list - it would add compatibility with AudioFormat.toString implementation (it uses commas). for the same reason "channels" would be better than "ch". regards Alex Karl Helgason wrote: > Hi, > > I added the missing "newline at the end of the file" to both SkipTest.java and ModelStandardIndexedDirector.java. > > http://cr.openjdk.java.net/~kalli/gervill-update/webrev.02/ > > regards, > Karl > ________________________________________ > Fr?: joe.darcy at oracle.com [joe.darcy at oracle.com] > Sent: 6. apr?l 2010 02:20 > Vi?takandi: Karl Helgason > Afrit: jdk6-dev at openjdk.java.net; alexey.menkov at sun.com; joe.darcy at sun.com; Dalibor.Topic at Sun.COM > Efni: Re: [Request for review and bugid] A collection of fixes for gervill (2010-04) > > Hello. > > I've filed bug 6941027 "Gervill update, April 2010" for this work. > However, I will leave Alexey to do the actual code reviewing for OpenJDK > 6 and JDK 7. > > Note that > test/javax/sound/midi/Gervill/AudioFloatFormatConverter/SkipTest.java > doesn't have a newline at the end of the file. > > -Joe > > On 4/5/2010 1:29 PM, Karl Helgason wrote: >> Hi, >> >> I need code review and bugid for the fix: >> http://cr.openjdk.java.net/~kalli/gervill-update/webrev.01/ >> >> Major fixes this webrev includes are: >> >> * Allow access to cached emergency soundbank using AccessController.doPrivileged >> This fix allows using cached emergency soundbank in applets >> which speeds up loading of applets especially on slow computers. >> And also using AccessController.doPrivileged we can use user-installed >> soundfonts in applets e.g. soundfonts found in audio folder of JRE. >> >> * Support for user config file. >> Default settings for Gervill don't always suit everybody, >> some needed lower latency, different samplerate and e.t.c >> To fix that a support to allow user to change default settings using >> Preferences API was added. >> >> * Fixed how getAvailableInstruments and getLoadedInstruments worked. >> SoftSynthesizer.getAvailableInstruments now always returns instruments >> from default soundbank. And getLoadedInstruments now always returns >> loaded instruments. The behavior of these methods where not correct. >> >> * Improved support for large soundbanks >> a) Indexed version of ModelStandardDirector added which speeds up >> looking up notes in instruments with many layers. >> b) Allow unused instrument to be garbage collected more easily, >> we now put null value to unused variable. >> c) Prevent unnecessary lookup of instrument object >> on pseudo program change (when bank and program is unchanged) >> >> * Enable user to disable loading default soundbank. >> Some users wanted to be able to open the synthesizer >> without the synthesizer loading the default soundbank. >> >> And then there was several other bug fixes: >> * Fix: Synchronization bug in n SoftSynthesizer.getDefaultSoundbank >> * Fix: AudioFloatInputStreamResampler.skip broken >> * Fix: RealTime scale/octave tuning doesn't affect sounding notes. >> * Fix: ModelByteBufferWaveTable.openStream().getFrameLength() >> returns incorrect values in some cases. >> >> Heres complete list of changes made: >> - Fix: Use AccessController.doPrivileged to access user settings >> and cached emergency soundbank. >> Affected File/Method: SoftSynthesizer.getDefaultSoundbank >> - Add: Support for user config file. >> Affected File/Method: SoftSynthesizer.getPropertyInfo >> - Add: Let SoftSynthesizer.getPropertyInfo use type conversion when needed. >> JTreg test added: >> /test/SoftSynthesizer/GetPropertyInfo >> - Add: Enable user to disable loading default soundbank. >> Affected File/Method: SoftSynthesizer.getPropertyInfo >> SoftSynthesizer.processPropertyInfo >> SoftSynthesizer.openStream >> JTreg test added: >> /test/SoftSynthesizer/TestDisableLoadDefaultSoundbank >> - Fix: SoftSynthesizer.getAvailableInstruments should >> always return instruments from default soundbank. >> Affected File/Method: SoftSynthesizer.getAvailableInstruments >> JTreg test added: >> /test/SoftSynthesizer/GetAvailableInstruments2 >> - Fix: SoftSynthesizer.getLoadedInstruments should always >> return loaded instrument. >> Affected File/Method: SoftSynthesizer.getLoadedInstruments >> JTreg test added: >> /test/SoftSynthesizer/GetLoadedInstruments2 >> JTreg tests fixed: >> /test/SoftSynthesizer/LoadAllInstruments >> /test/SoftSynthesizer/LoadInstrument >> /test/SoftSynthesizer/LoadInstruments >> /test/SoftSynthesizer/RemapInstrument >> * this test never worked correctly >> /test/SoftSynthesizer/UnloadAllInstruments >> /test/SoftSynthesizer/UnloadInstrument >> /test/SoftSynthesizer/UnloadInstruments >> - Fix: SoftSynthesizer.getDefaultSoundbank is not properly synchronized. >> Affected File/Method: SoftSynthesizer.getDefaultSoundbank >> - Optimization: Indexed version of ModelStandardDirector added. >> - Optimization: Fully unload instruments by setting null to unused values. >> Affected Files: SoftVoice, SoftChannel, SoftSynthesizer >> - Optimization: Prevent unnecessary lookup of instrument object >> on pseudo program change (when bank and program is unchanged) >> Affected File/Method: SoftChannel.programChange >> - Fix: AudioFloatInputStreamResampler.skip broken. >> (Gervill Bug Issues 5) >> see: https://gervill.dev.java.net/issues/show_bug.cgi?id=5 >> Affected File/Method: >> AudioFloatFormatConverter.AudioFloatInputStreamResampler.skip >> JTreg test added: >> /test/AudioFloatFormatConverter/SkipTest >> - Fix: ModelByteBufferWaveTable.openStream().getFrameLength() >> returns incorrect values in some cases. >> (Gervill Bug Issues 4) >> see: https://gervill.dev.java.net/issues/show_bug.cgi?id=4 >> Affected File/Method: ModelByteBufferWaveTable.openStream >> JTreg test added: >> /test/ModelByteBufferWavetable/OpenStream >> - Fix: RealTime scale/octave tuning doesn't affect sounding notes. >> Affected File/Method: SoftVoice.updateTuning >> JTreg test added: >> /test/ModelByteBufferWavetable/OpenStream >> From alex.menkov at sun.com Thu Apr 8 03:40:05 2010 From: alex.menkov at sun.com (Alex Menkov) Date: Thu, 08 Apr 2010 14:40:05 +0400 Subject: SV: SV: [Request for review and bugid] A collection of fixes for gervill (2010-04) In-Reply-To: <36EC82E93EB0AD40A4301DAD654323860146CD9D88FD@mail.midverk.is> References: <36EC82E93EB0AD40A4301DAD654323860146CD9D88F8@mail.midverk.is> <4BBA9A75.5060408@oracle.com> <36EC82E93EB0AD40A4301DAD654323860146CD9D88F9@mail.midverk.is> <4BBCB333.5060101@sun.com> <36EC82E93EB0AD40A4301DAD654323860146CD9D88FD@mail.midverk.is> Message-ID: <4BBDB285.7030803@sun.com> Hi Karl, Thank you, it looks fine. Feel free to push the fix. About Preferences: I understand the reason, but it's unclear for me how it should be used (by developers or users). Am I right that it supposes creation of a "config utility" which allows to set synthesizer properties and saves them into Preferences storage (and this utility should be run by end user to configure default properties)? regards Alex Karl Helgason wrote: > Hi, > I have made those changes you talked about: > http://cr.openjdk.java.net/~kalli/gervill-update/webrev.03/ > > I'm however not sure if I got all code formatting correct. > >> About using Preferences (support for user config file). >> It's not evident for me that the synthesizer needs the feature. Could >> you please describe how it's supposed to be used? > > Only way now to change synthesizer settings is to use the > AudioSynthesizer interface. But the problem is that > most programs don't know about it. > So the only way to change those settings would be > to allow user to change the default settings > using for example the Preference API. > > One reason for changing the default settings would > be that users want to use different audio format > or require lower latency settings, it is by default 120 msec > but on windows we can go as low as 20 msec latency > and and other platforms we can go even lower. > > regards, > Karl > ________________________________________ > Fr?: Alexey.Menkov at Sun.COM [Alexey.Menkov at Sun.COM] Fyrir hönd Alex Menkov [alex.menkov at Sun.COM] > Sent: 7. apr?l 2010 16:30 > Vi?takandi: Karl Helgason > Afrit: jdk6-dev at openjdk.java.net > Efni: Re: SV: [Request for review and bugid] A collection of fixes for gervill (2010-04) > > Hi Karl, > > my comments about the fix: > > src/share/classes/com/sun/media/sound/AudioFloatFormatConverter.java > could you please remove empty statements at lines 178 & 188 (the lines > consist of only ";" symbol) > > > src/share/classes/com/sun/media/sound/SoftChannel.java > year in the copyright header has been changed from 2007 to 2010 > I believe 2007-2010 would be more correct. > > > src/share/classes/com/sun/media/sound/SoftSynthesizer.java > > line 28: +import java.awt.image.BufferedImage; > the import is definitely unnecessary. > > getDefaultSoundbank method: > Now you search for available soundbank (jre home, windows system > soundbank, saved soundbank) and open InputStream (returned from > doPrivileged). Then use MidiSystem.getSoundbank() to get soundbank from > the stream. > If, for example, jre home have a soundbank in lib/audio, but the file is > corrupted, MidiSystem.getSoundbank() throws exception and windows system > sounbank & saved soundbank won't be tried to load. > I think old algorithm was better (in the case I described it tries to > load soundbank from other locations). > (Note that you are completely right that MidiSystem.getSoundbank() must > be called outside of privileged code to prevent security vulnerability) > > About using Preferences (support for user config file). > It's not evident for me that the synthesizer needs the feature. Could > you please describe how it's supposed to be used? > And couple notes about the implementation: > - Could you reformat the code like the rest of the code (now it looks > like code in "C/C++ style") > - AudioFormat parsing (lines 966-995): StringTokenizer uses default > delimiters. I think it would be better to add comma to the delimiter > list - it would add compatibility with AudioFormat.toString > implementation (it uses commas). for the same reason "channels" would be > better than "ch". > > > regards > Alex > > Karl Helgason wrote: >> Hi, >> >> I added the missing "newline at the end of the file" to both SkipTest.java and ModelStandardIndexedDirector.java. >> >> http://cr.openjdk.java.net/~kalli/gervill-update/webrev.02/ >> >> regards, >> Karl >> ________________________________________ >> Fr?: joe.darcy at oracle.com [joe.darcy at oracle.com] >> Sent: 6. apr?l 2010 02:20 >> Vi?takandi: Karl Helgason >> Afrit: jdk6-dev at openjdk.java.net; alexey.menkov at sun.com; joe.darcy at sun.com; Dalibor.Topic at Sun.COM >> Efni: Re: [Request for review and bugid] A collection of fixes for gervill (2010-04) >> >> Hello. >> >> I've filed bug 6941027 "Gervill update, April 2010" for this work. >> However, I will leave Alexey to do the actual code reviewing for OpenJDK >> 6 and JDK 7. >> >> Note that >> test/javax/sound/midi/Gervill/AudioFloatFormatConverter/SkipTest.java >> doesn't have a newline at the end of the file. >> >> -Joe >> >> On 4/5/2010 1:29 PM, Karl Helgason wrote: >>> Hi, >>> >>> I need code review and bugid for the fix: >>> http://cr.openjdk.java.net/~kalli/gervill-update/webrev.01/ >>> >>> Major fixes this webrev includes are: >>> >>> * Allow access to cached emergency soundbank using AccessController.doPrivileged >>> This fix allows using cached emergency soundbank in applets >>> which speeds up loading of applets especially on slow computers. >>> And also using AccessController.doPrivileged we can use user-installed >>> soundfonts in applets e.g. soundfonts found in audio folder of JRE. >>> >>> * Support for user config file. >>> Default settings for Gervill don't always suit everybody, >>> some needed lower latency, different samplerate and e.t.c >>> To fix that a support to allow user to change default settings using >>> Preferences API was added. >>> >>> * Fixed how getAvailableInstruments and getLoadedInstruments worked. >>> SoftSynthesizer.getAvailableInstruments now always returns instruments >>> from default soundbank. And getLoadedInstruments now always returns >>> loaded instruments. The behavior of these methods where not correct. >>> >>> * Improved support for large soundbanks >>> a) Indexed version of ModelStandardDirector added which speeds up >>> looking up notes in instruments with many layers. >>> b) Allow unused instrument to be garbage collected more easily, >>> we now put null value to unused variable. >>> c) Prevent unnecessary lookup of instrument object >>> on pseudo program change (when bank and program is unchanged) >>> >>> * Enable user to disable loading default soundbank. >>> Some users wanted to be able to open the synthesizer >>> without the synthesizer loading the default soundbank. >>> >>> And then there was several other bug fixes: >>> * Fix: Synchronization bug in n SoftSynthesizer.getDefaultSoundbank >>> * Fix: AudioFloatInputStreamResampler.skip broken >>> * Fix: RealTime scale/octave tuning doesn't affect sounding notes. >>> * Fix: ModelByteBufferWaveTable.openStream().getFrameLength() >>> returns incorrect values in some cases. >>> >>> Heres complete list of changes made: >>> - Fix: Use AccessController.doPrivileged to access user settings >>> and cached emergency soundbank. >>> Affected File/Method: SoftSynthesizer.getDefaultSoundbank >>> - Add: Support for user config file. >>> Affected File/Method: SoftSynthesizer.getPropertyInfo >>> - Add: Let SoftSynthesizer.getPropertyInfo use type conversion when needed. >>> JTreg test added: >>> /test/SoftSynthesizer/GetPropertyInfo >>> - Add: Enable user to disable loading default soundbank. >>> Affected File/Method: SoftSynthesizer.getPropertyInfo >>> SoftSynthesizer.processPropertyInfo >>> SoftSynthesizer.openStream >>> JTreg test added: >>> /test/SoftSynthesizer/TestDisableLoadDefaultSoundbank >>> - Fix: SoftSynthesizer.getAvailableInstruments should >>> always return instruments from default soundbank. >>> Affected File/Method: SoftSynthesizer.getAvailableInstruments >>> JTreg test added: >>> /test/SoftSynthesizer/GetAvailableInstruments2 >>> - Fix: SoftSynthesizer.getLoadedInstruments should always >>> return loaded instrument. >>> Affected File/Method: SoftSynthesizer.getLoadedInstruments >>> JTreg test added: >>> /test/SoftSynthesizer/GetLoadedInstruments2 >>> JTreg tests fixed: >>> /test/SoftSynthesizer/LoadAllInstruments >>> /test/SoftSynthesizer/LoadInstrument >>> /test/SoftSynthesizer/LoadInstruments >>> /test/SoftSynthesizer/RemapInstrument >>> * this test never worked correctly >>> /test/SoftSynthesizer/UnloadAllInstruments >>> /test/SoftSynthesizer/UnloadInstrument >>> /test/SoftSynthesizer/UnloadInstruments >>> - Fix: SoftSynthesizer.getDefaultSoundbank is not properly synchronized. >>> Affected File/Method: SoftSynthesizer.getDefaultSoundbank >>> - Optimization: Indexed version of ModelStandardDirector added. >>> - Optimization: Fully unload instruments by setting null to unused values. >>> Affected Files: SoftVoice, SoftChannel, SoftSynthesizer >>> - Optimization: Prevent unnecessary lookup of instrument object >>> on pseudo program change (when bank and program is unchanged) >>> Affected File/Method: SoftChannel.programChange >>> - Fix: AudioFloatInputStreamResampler.skip broken. >>> (Gervill Bug Issues 5) >>> see: https://gervill.dev.java.net/issues/show_bug.cgi?id=5 >>> Affected File/Method: >>> AudioFloatFormatConverter.AudioFloatInputStreamResampler.skip >>> JTreg test added: >>> /test/AudioFloatFormatConverter/SkipTest >>> - Fix: ModelByteBufferWaveTable.openStream().getFrameLength() >>> returns incorrect values in some cases. >>> (Gervill Bug Issues 4) >>> see: https://gervill.dev.java.net/issues/show_bug.cgi?id=4 >>> Affected File/Method: ModelByteBufferWaveTable.openStream >>> JTreg test added: >>> /test/ModelByteBufferWavetable/OpenStream >>> - Fix: RealTime scale/octave tuning doesn't affect sounding notes. >>> Affected File/Method: SoftVoice.updateTuning >>> JTreg test added: >>> /test/ModelByteBufferWavetable/OpenStream >>> From ahughes at redhat.com Thu Apr 8 07:21:05 2010 From: ahughes at redhat.com (ahughes at redhat.com) Date: Thu, 08 Apr 2010 14:21:05 +0000 Subject: hg: jdk6/jdk6/corba: 6903453: Zero build on ARM and IA-64 Message-ID: <20100408142107.C256E4445D@hg.openjdk.java.net> Changeset: e83301fe4687 Author: gbenson Date: 2009-11-23 10:04 +0000 URL: http://hg.openjdk.java.net/jdk6/jdk6/corba/rev/e83301fe4687 6903453: Zero build on ARM and IA-64 Summary: Correctly set uname on ARM, and correctly build fdlibm on IA-64 Reviewed-by: ohair ! make/common/shared/Platform.gmk From ahughes at redhat.com Thu Apr 8 07:30:10 2010 From: ahughes at redhat.com (ahughes at redhat.com) Date: Thu, 08 Apr 2010 14:30:10 +0000 Subject: hg: jdk6/jdk6/jdk: 6903453: Zero build on ARM and IA-64 Message-ID: <20100408143043.9C0DB4445F@hg.openjdk.java.net> Changeset: 17a217fd1d49 Author: gbenson Date: 2009-11-23 10:04 +0000 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/17a217fd1d49 6903453: Zero build on ARM and IA-64 Summary: Correctly set uname on ARM, and correctly build fdlibm on IA-64 Reviewed-by: ohair ! make/common/shared/Platform.gmk ! src/share/native/java/lang/fdlibm/include/fdlibm.h From ahughes at redhat.com Thu Apr 8 08:20:42 2010 From: ahughes at redhat.com (Andrew John Hughes) Date: Thu, 8 Apr 2010 16:20:42 +0100 Subject: Test Backports In-Reply-To: <4BBD2F69.4070609@oracle.com> References: <17c6771e1003291310u3e1b3231i6a054fd76bc24182@mail.gmail.com> <4BB112FD.9070702@oracle.com> <17c6771e1003291849m7d920b2ey7e4b15bd0f748a0a@mail.gmail.com> <4BB3ABEE.4070102@oracle.com> <4BBA91BD.8020105@oracle.com> <4BBBD0EE.7040705@oracle.com> <4BBD2F69.4070609@oracle.com> Message-ID: On 8 April 2010 02:20, Joe Darcy wrote: > Andrew John Hughes wrote: >> >> On 7 April 2010 00:25, Joe Darcy wrote: >> >>> >>> On 04/06/10 01:27 PM, Andrew John Hughes wrote: >>> >>> On 6 April 2010 01:43, Joe Darcy wrote: >>> > > [snip] >>> >>> >>> On my queue, I have four more Zero patches and a set of backports I'd >>> like in (making the source/target explicit as we did in 7 already, and >>> Kelly's ant 1.8 patch). ?Everything else can wait until b20 >>> >>> >>> >>> Here's the backport: >>> >>> http://cr.openjdk.java.net/~andrew/6873059/webrev.01/jdk6.patch >>> >>> It's a replica of 6873059 as applied to the HotSpot, JDK and CORBA >>> trees in OpenJDK7, the only difference being that we use 5 instead of >>> 6 as the bootstrap version for OpenJDK6. ?Ok to push? ?Should I use >>> the same bug ID or do you want to allocate a fresh one? >>> >>> >>> Using the same bug id is fine, but I'd like Kelly to sanity check it >>> before >>> it goes back. >>> >>> >> >> Ok, waiting for Kelly's response. >> > > Acknowledged. > >> >>> >>> On another note, there is now some code requiring source level 6 in >>> OpenJDK6 (due to use of the @Override annotation on interfaces): >>> >>> ?src/share/classes/javax/swing/plaf/synth/SynthComboBoxUI.java >>> ?src/share/classes/javax/swing/plaf/synth/SynthLookAndFeel.java >>> ?src/share/classes/javax/swing/plaf/synth/SynthTreeUI.java >>> ?src/share/classes/sun/security/provider/certpath/OCSPResponse.java >>> ?src/share/classes/sun/swing/plaf/synth/SynthFileChooserUIImpl.java >>> >>> >>> There is an overly-long story behind -source 5 vs. -source 6 and >>> @Override. >>> The short answer is that javac in JDK 6 unconditionally applies the more >>> liberal (and more useful) semantics for @Override. ?For the JDK sources, >>> a >>> compiler that does the same should be used. >>> >>> >> >> Exactly. ?I know ecj throws it out for 5 but not for 6 and thus >> building using ecj (our method for bootstrapping) falls foul of the >> classes above. ?I'm not sure if javac is allowing them through because >> its version of 1.5 allows it or it is simply defaulting to 6 because >> nothing else is specified. ?I had a quick look but the version is >> currently set in more than one place, so I think this needs a more >> in-depth review and I'd prefer it waits until b20 to be on the safe >> side. >> > > The javac command in JDK 6, both open and proprietary, will allow use of > @Override on interfaces, even if "-source 5" is specified. > Ok, that explains why it works for javac and fails for ecj. Is there any reason we're using 5 for a build of OpenJDK 6? The bootstrapping classes are now explicitly 5, but surely the final JDK code should be 6. >>> So we should look at bumping the generated code version to 6 (it still >>> seems to be 5 even though this is OpenJDK6). ?I'd prefer to leave that >>> until b20 though. >>> >>> I see Kelly's patch went in. ?It would be nice to also backport >>> http://hg.openjdk.java.net/jdk7/jdk7/hotspot/rev/5fdbe2cdf565 (a minor >>> warning fix) so IcedTea6's OpenJDK backport set is empty again. >>> >>> >>> I approve the warning fix being backported. >>> >>> >> >> Done: http://hg.openjdk.java.net/jdk6/jdk6/hotspot/rev/6ee696377676 >> > > Thanks, > >> The first of the four Zero backports is 6903453: Zero build on ARM and >> IA-64. >> >> http://cr.openjdk.java.net/~andrew/6903453/webrev.01/ >> >> It adds a few build conditionals for building on arm and ia64 platforms. >> >> Ok to push? >> > > Approved to go back. > Done: http://hg.openjdk.java.net/jdk6/jdk6/corba/rev/e83301fe4687 http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/17a217fd1d49 Next one is 6909153 which turns off a number of options that fail or are inappropriate on Zero: http://cr.openjdk.java.net/~andrew/6909153/webrev.01/ Ok to push? > I've run some regression tests on a build from the current tip and the > result look good; in particular, all the rmid tests pass again :-) > These results look good. Plenty of new tests :-) The only odd one seems to be > pass fail com/sun/crypto/provider/KeyFactory/TestProviderLeak.java The rest are either new or disabled by the security update. > Detailed diffs from b18: > > 0: ../test_results.b18/JTreport.hotspot ?pass: 24 > 1: JTreport.hotspot ?pass: 62 > > 0 ? ? ?1 ? ? ?Test > --- ? ?pass ? compiler/5057225/Test5057225.java > --- ? ?pass ? compiler/6378821/Test6378821.java > --- ? ?pass ? compiler/6539464/Test.java > --- ? ?pass ? compiler/6589834/Test_ia32.java > --- ? ?pass ? compiler/6603011/Test.java > --- ? ?pass ? compiler/6636138/Test1.java > --- ? ?pass ? compiler/6636138/Test2.java > --- ? ?pass ? compiler/6711117/Test.java > --- ? ?pass ? compiler/6772683/InterruptedTest.java > --- ? ?pass ? compiler/6778657/Test.java > --- ? ?pass ? compiler/6795161/Test.java > --- ? ?pass ? compiler/6795465/Test6795465.java > --- ? ?pass ? compiler/6797305/Test6797305.java > --- ? ?pass ? compiler/6799693/Test.java > --- ? ?pass ? compiler/6800154/Test6800154.java > --- ? ?pass ? compiler/6814842/Test6814842.java > --- ? ?pass ? compiler/6823354/Test6823354.java > --- ? ?pass ? compiler/6823453/Test.java > --- ? ?pass ? compiler/6826736/Test.java > --- ? ?pass ? compiler/6832293/Test.java > --- ? ?pass ? compiler/6833129/Test.java > --- ? ?pass ? compiler/6837011/Test6837011.java > --- ? ?pass ? compiler/6837094/Test.java > --- ? ?pass ? compiler/6843752/Test.java > --- ? ?pass ? compiler/6849574/Test.java > --- ? ?pass ? compiler/6851282/Test.java > --- ? ?pass ? compiler/6852078/Test6852078.java > --- ? ?pass ? compiler/6855164/Test.java > --- ? ?pass ? compiler/6855215/Test6855215.java > --- ? ?pass ? compiler/6857159/Test6857159.java > --- ? ?pass ? compiler/6859338/Test6859338.java > --- ? ?pass ? compiler/6860469/Test.java > --- ? ?pass ? compiler/6863155/Test6863155.java > --- ? ?pass ? compiler/6863420/Test.java > --- ? ?pass ? compiler/6865031/Test.java > --- ? ?pass ? compiler/6875866/Test.java > --- ? ?pass ? compiler/6892265/Test.java > --- ? ?pass ? gc/6845368/bigobj.java > > 38 differences > > Langtools: > 0: ../test_results.b18/JTreport.langtools ?pass: 1,355 > 1: JTreport.langtools ?pass: 1,359 > > 0 ? ? ?1 ? ? ?Test > --- ? ?pass ? tools/javac/enum/T6724345.java > --- ? ?pass ? tools/javac/processing/6511613/clss41701.java > --- ? ?pass ? tools/javac/processing/6634138/T6634138.java > --- ? ?pass ? tools/javac/processing/model/util/elements/VacuousEnum.java > > 4 differences > > JDK: > > 0: ../test_results.b18/JTreport.jdk ?pass: 3,148; fail: 19; error: 2 > 1: JTreport.jdk ?pass: 3,252; fail: 29; error: 4 > > 0 ? ? ?1 ? ? ?Test > pass ? fail ? com/sun/crypto/provider/KeyFactory/TestProviderLeak.java > --- ? ?error > ?java/awt/Focus/ActualFocusedWindowTest/ActualFocusedWindowBlockingTest.java > --- ? ?error > ?java/awt/Focus/ActualFocusedWindowTest/ActualFocusedWindowRetaining.java > --- ? ?error > ?java/awt/Focus/NonFocusableWindowTest/NonfocusableOwnerTest.java > --- ? ?pass ? java/awt/Focus/NonFocusableWindowTest/Test.java > --- ? ?pass ? java/awt/Focus/TypeAhead/TestFocusFreeze.java > pass ? fail ? java/awt/Frame/MaximizedToIconified/MaximizedToIconified.java > --- ? ?fail > java/awt/Insets/WindowWithWarningTest/WindowWithWarningTest.html > pass ? fail ? java/awt/TextArea/UsingWithMouse/SelectionAutoscrollTest.html > fail ? pass ? java/awt/event/KeyEvent/CorrectTime/CorrectTime.java > --- ? ?pass ? java/awt/xembed/server/RunTestXEmbed.java > --- ? ?pass ? java/nio/charset/Charset/AvailableCharsetNames.java > --- ? ?pass ? java/nio/charset/Charset/CharsetContainmentTest.java > --- ? ?fail ? java/nio/charset/Charset/Contains.java > --- ? ?pass ? java/nio/charset/Charset/EmptyCharsetName.java > --- ? ?pass ? java/nio/charset/Charset/EncDec.java > --- ? ?pass ? java/nio/charset/Charset/IllegalCharsetName.java > --- ? ?fail ? java/nio/charset/Charset/NIOCharsetAvailabilityTest.java > --- ? ?pass ? java/nio/charset/Charset/NullCharsetName.java > --- ? ?pass ? java/nio/charset/Charset/RegisteredCharsets.java > --- ? ?pass ? java/nio/charset/Charset/default.sh > --- ? ?pass ? java/nio/charset/CharsetDecoder/AverageMax.java > --- ? ?pass ? java/nio/charset/CharsetDecoder/EmptyInput.java > --- ? ?pass ? java/nio/charset/CharsetEncoder/CanEncode.java > --- ? ?pass ? java/nio/charset/CharsetEncoder/Flush.java > --- ? ?pass ? java/nio/charset/RemovingSunIO/SunioAlias.java > --- ? ?pass ? java/nio/charset/RemovingSunIO/TestCOMP.java > --- ? ?pass ? java/nio/charset/RemovingSunIO/TestUnmappableForLength.java > --- ? ?pass ? java/nio/charset/coders/BashCache.java > --- ? ?pass ? java/nio/charset/coders/BashStreams.java > --- ? ?pass ? java/nio/charset/coders/Check.java > --- ? ?pass ? java/nio/charset/coders/CheckSJISMappingProp.sh > --- ? ?pass ? java/nio/charset/coders/Errors.java > --- ? ?pass ? java/nio/charset/coders/FullRead.java > --- ? ?pass ? java/nio/charset/coders/IOCoders.java > --- ? ?pass ? java/nio/charset/coders/IsLegalReplacement.java > --- ? ?pass ? java/nio/charset/coders/ResetISO2022JP.java > --- ? ?pass ? java/nio/charset/coders/StreamTimeout.java > --- ? ?pass ? java/nio/charset/coders/Surrogates.java > --- ? ?pass ? java/nio/charset/spi/basic.sh > fail ? pass ? java/rmi/transport/pinLastArguments/PinLastArguments.java > --- ? ?pass ? java/text/Bidi/BidiBug.java > --- ? ?pass ? java/text/Bidi/BidiEmbeddingTest.java > --- ? ?pass ? java/text/Bidi/BidiSurrogateTest.java > --- ? ?pass ? java/util/prefs/CommentsInXml.java > --- ? ?pass ? java/util/prefs/ConflictInFlush.java > --- ? ?pass ? java/util/prefs/ExportNode.java > --- ? ?pass ? java/util/prefs/ExportSubtree.java > --- ? ?pass ? java/util/prefs/PrefsSpi.sh > --- ? ?pass ? java/util/prefs/RemoveReadOnlyNode.java > --- ? ?pass ? java/util/prefs/RemoveUnregedListener.java > --- ? ?pass ? java/util/prefs/SerializeExceptions.java > --- ? ?pass ? javax/swing/JColorChooser/Test4165217.java > --- ? ?pass ? javax/swing/JColorChooser/Test4177735.java > --- ? ?pass ? javax/swing/JColorChooser/Test4193384.java > --- ? ?pass ? javax/swing/JColorChooser/Test4234761.java > --- ? ?pass ? javax/swing/JColorChooser/Test4461329.java > --- ? ?pass ? javax/swing/JColorChooser/Test4711996.java > --- ? ?pass ? javax/swing/border/Test4120351.java > --- ? ?pass ? javax/swing/border/Test4124729.java > --- ? ?pass ? javax/swing/border/Test6461042.java > --- ? ?pass ? sun/nio/cs/BufferUnderflowEUCTWTest.java > --- ? ?pass ? sun/nio/cs/CheckCaseInsensitiveEncAliases.java > --- ? ?pass ? sun/nio/cs/CheckHistoricalNames.java > --- ? ?pass ? sun/nio/cs/ConvertSingle.java > --- ? ?pass ? sun/nio/cs/DecoderOverflow.java > --- ? ?pass ? sun/nio/cs/EUCJPUnderflowDecodeTest.java > --- ? ?pass ? sun/nio/cs/EucJpLinux0212.java > --- ? ?pass ? sun/nio/cs/EucJpLinuxDecoderRecoveryTest.java > --- ? ?pass ? sun/nio/cs/EuroConverter.java > --- ? ?pass ? sun/nio/cs/FindASCIICodingBugs.java > --- ? ?pass ? sun/nio/cs/FindASCIIRangeCodingBugs.java > --- ? ?pass ? sun/nio/cs/FindCanEncodeBugs.java > --- ? ?pass ? sun/nio/cs/FindDecoderBugs.java > --- ? ?pass ? sun/nio/cs/FindEncoderBugs.java > --- ? ?pass ? sun/nio/cs/FindOneCharEncoderBugs.java > --- ? ?pass ? sun/nio/cs/HWKatakanaMS932EncodeTest.java > --- ? ?pass ? sun/nio/cs/ISCIITest.java > --- ? ?pass ? sun/nio/cs/ISO8859x.java > --- ? ?pass ? sun/nio/cs/JISAutoDetectTest.java > --- ? ?pass ? sun/nio/cs/LatinCharReplacementTWTest.java > --- ? ?pass ? sun/nio/cs/LeftOverSurrogate.java > --- ? ?pass ? sun/nio/cs/MalformedSurrogates.java > --- ? ?pass ? sun/nio/cs/NIOJISAutoDetectTest.java > --- ? ?pass ? sun/nio/cs/ReadZero.java > --- ? ?pass ? sun/nio/cs/SJISCanEncode.java > --- ? ?pass ? sun/nio/cs/StreamEncoderClose.java > --- ? ?pass ? sun/nio/cs/SurrogateGB18030Test.java > --- ? ?pass ? sun/nio/cs/SurrogateTestEUCTW.java > --- ? ?pass ? sun/nio/cs/SurrogateTestHKSCS.java > --- ? ?fail ? sun/nio/cs/Test4200310.sh > --- ? ?pass ? sun/nio/cs/Test4206507.java > --- ? ?pass ? sun/nio/cs/Test6254467.java > --- ? ?pass ? sun/nio/cs/Test6275027.java > --- ? ?pass ? sun/nio/cs/TestCompoundTest.java > --- ? ?pass ? sun/nio/cs/TestConverterDroppedCharacters.java > --- ? ?pass ? sun/nio/cs/TestCp834_SBCS.java > --- ? ?pass ? sun/nio/cs/TestCp93xSISO.java > --- ? ?pass ? sun/nio/cs/TestIBMBugs.java > --- ? ?pass ? sun/nio/cs/TestISCII91.java > --- ? ?pass ? sun/nio/cs/TestISO2022CNDecoder.java > --- ? ?pass ? sun/nio/cs/TestISO2022JP.java > --- ? ?pass ? sun/nio/cs/TestISO2022JPEncoder.java > --- ? ?pass ? sun/nio/cs/TestISO2022JPSubBytes.java > --- ? ?pass ? sun/nio/cs/TestIllegalISO2022Esc.java > --- ? ?pass ? sun/nio/cs/TestIllegalSJIS.java > --- ? ?pass ? sun/nio/cs/TestJIS0208Decoder.java > --- ? ?pass ? sun/nio/cs/TestJIS0212Decoder.java > --- ? ?pass ? sun/nio/cs/TestMS5022X.java > --- ? ?pass ? sun/nio/cs/TestMiscEUC_JP.java > --- ? ?fail ? sun/nio/cs/TestSJIS0213.java > --- ? ?pass ? sun/nio/cs/TestTrailingEscapesISO2022JP.java > --- ? ?pass ? sun/nio/cs/TestUTF8BOM.java > --- ? ?pass ? sun/nio/cs/TestUTF_16.java > --- ? ?pass ? sun/nio/cs/TestUni2HKSCS.java > --- ? ?pass ? sun/nio/cs/TestX11JIS0201.java > --- ? ?pass ? sun/nio/cs/UkrainianIsNotRussian.java > --- ? ?pass ? sun/nio/cs/ZeroedByteArrayEUCTWTest.java > pass ? --- > ?sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/InvalidateServerSessionRenegotiate.java > pass ? --- ? ?sun/security/ssl/javax/net/ssl/NewAPIs/JSSERenegotiate.java > pass ? --- > ?sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/CheckStatus.java > pass ? --- > ?sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/ConnectionTest.java > pass ? --- > ?sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/NoAuthClientAuth.java > error ?pass > sun/security/ssl/javax/net/ssl/NewAPIs/SessionTimeOutTests.java > --- ? ?fail > sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/DNSIdentities.java > --- ? ?pass > sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/HttpsCreateSockTest.java > --- ? ?pass > sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/HttpsSocketFacTest.java > --- ? ?pass > sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/IPAddressDNSIdentities.java > --- ? ?fail > sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/IPAddressIPIdentities.java > --- ? ?fail > sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/IPIdentities.java > --- ? ?fail > sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/Identities.java > --- ? ?pass ? sun/security/util/Oid/BerOid.java > > 132 differences > > -Joe > -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From ahughes at redhat.com Thu Apr 8 12:57:27 2010 From: ahughes at redhat.com (Andrew John Hughes) Date: Thu, 8 Apr 2010 20:57:27 +0100 Subject: [kelly.ohair@oracle.com: Re: Test Backports] Message-ID: <20100408195726.GG13436@rivendell.middle-earth.co.uk> This discussion seems to have moved off-list... :-( ----- Forwarded message from Kelly O'Hair ----- Date: Thu, 8 Apr 2010 12:00:36 -0700 From: Kelly O'Hair To: Joe Darcy Subject: Re: Test Backports On Apr 8, 2010, at 11:21 AM, Joe Darcy wrote: > On 04/08/10 10:16 AM, Kelly O'Hair wrote: >> >> If there is something I need to do on this email thread, please >> let me know, >> I am unable to follow the discussion very well. >> >> -kto > > Kelly, > > Please review Andrew's backport of 6873059 "Explicitly use -source > 6 -target 6 when compiling with the boot jdk javac" to OpenJDK 6: > > http://cr.openjdk.java.net/~andrew/6873059/webrev.01/ The jdk and corba changes look fine. For hotspot... I don't know what various javac's will do when the -source and -target options show up twice, and I think where the makefiles are using 1.4 settings, that will happen. Is that ok? Last setting wins? I'm kind of surprised that hotspot used javac -g all over the place, seems needless for normal builds. So I'm happy with the removals of the -g's, but wonder if the default should be no -g at all, or at least isolate the -g option and have it controlled by the same make variables that the jdk uses to control 'javac -g'? And there is still the outstanding issue that hotspot makefiles should really be using the langtools javac to do all it's java compilations, not the boot javac, but that's for another day. I've kind of distanced myself a bit from the hotspot makefiles recently, since they just added back all kinds of jdk5-isms (_g suffix etc.). They pretty much belong to the hotspot team now. -kto > > -Joe ----- End forwarded message ----- -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint = F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From kelly.ohair at oracle.com Thu Apr 8 13:10:16 2010 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Thu, 8 Apr 2010 13:10:16 -0700 Subject: [kelly.ohair@oracle.com: Re: Test Backports] In-Reply-To: <20100408195726.GG13436@rivendell.middle-earth.co.uk> References: <20100408195726.GG13436@rivendell.middle-earth.co.uk> Message-ID: <16FFC054-DF30-42D0-A158-A0D6D5D58A23@oracle.com> Sorry. My fault. -kto On Apr 8, 2010, at 12:57 PM, Andrew John Hughes wrote: > This discussion seems to have moved off-list... :-( > > ----- Forwarded message from Kelly O'Hair > ----- > > Date: Thu, 8 Apr 2010 12:00:36 -0700 > From: Kelly O'Hair > To: Joe Darcy > Subject: Re: Test Backports > > > On Apr 8, 2010, at 11:21 AM, Joe Darcy wrote: > >> On 04/08/10 10:16 AM, Kelly O'Hair wrote: >>> >>> If there is something I need to do on this email thread, please >>> let me know, >>> I am unable to follow the discussion very well. >>> >>> -kto >> >> Kelly, >> >> Please review Andrew's backport of 6873059 "Explicitly use -source >> 6 -target 6 when compiling with the boot jdk javac" to OpenJDK 6: >> >> http://cr.openjdk.java.net/~andrew/6873059/webrev.01/ > > The jdk and corba changes look fine. > > For hotspot... > I don't know what various javac's will do when the -source and -target > options show up twice, > and I think where the makefiles are using 1.4 settings, that will > happen. Is that ok? Last setting wins? > > I'm kind of surprised that hotspot used javac -g all over the place, > seems needless for > normal builds. So I'm happy with the removals of the -g's, but wonder > if the default > should be no -g at all, or at least isolate the -g option and have it > controlled by the > same make variables that the jdk uses to control 'javac -g'? > And there is still the outstanding issue that hotspot makefiles should > really be using the > langtools javac to do all it's java compilations, not the boot javac, > but that's for another day. > > I've kind of distanced myself a bit from the hotspot makefiles > recently, since they just added > back all kinds of jdk5-isms (_g suffix etc.). They pretty much belong > to the hotspot team now. > > -kto > >> >> -Joe > > > ----- End forwarded message ----- > > -- > Andrew :) > > Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > Support Free Java! > Contribute to GNU Classpath and the OpenJDK > http://www.gnu.org/software/classpath > http://openjdk.java.net > PGP Key: 94EFD9D8 (http://subkeys.pgp.net) > Fingerprint = F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From martinrb at google.com Thu Apr 8 15:22:39 2010 From: martinrb at google.com (Martin Buchholz) Date: Thu, 8 Apr 2010 15:22:39 -0700 Subject: javadoc no longer inherits doc from sourcepath Message-ID: Hi javadoc team, This is a bug report. Seems pretty serious - S2? javadoc man page says, """ The source file for the inherited method need only be on the path spec ified by -sourcepath for the doc comment to actually be available to copy. Neither the class nor its package needs to be passed in on the command line. This contrasts with 1.3.x and earlier releases, where the class had to be a documented class """ It seems that the jdk has reverted to the 1.3.x behavior. This happened somewhere between openjdk6-b12 and openjdk6-b13, and is still broken at head of openjdk7. But 6u19 works fine! E.g. public class JavadocBug { public String toString() { return ""; } } Then try javadoc -sourcepath $PATH_TO_JDK_SOURCES/src/share/classes JavadocBug.java Martin From joe.darcy at oracle.com Thu Apr 8 15:22:44 2010 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 08 Apr 2010 15:22:44 -0700 Subject: Test Backports In-Reply-To: References: <17c6771e1003291310u3e1b3231i6a054fd76bc24182@mail.gmail.com> <4BB112FD.9070702@oracle.com> <17c6771e1003291849m7d920b2ey7e4b15bd0f748a0a@mail.gmail.com> <4BB3ABEE.4070102@oracle.com> <4BBA91BD.8020105@oracle.com> <4BBBD0EE.7040705@oracle.com> <4BBD2F69.4070609@oracle.com> Message-ID: <4BBE5734.30101@oracle.com> On 04/08/10 08:20 AM, Andrew John Hughes wrote: > On 8 April 2010 02:20, Joe Darcy wrote: > >> Andrew John Hughes wrote: >> >>> On 7 April 2010 00:25, Joe Darcy wrote: >>> >>> >>>> On 04/06/10 01:27 PM, Andrew John Hughes wrote: >>>> >>>> On 6 April 2010 01:43, Joe Darcy wrote: >>>> >>>> >> [snip] >> >>>> On my queue, I have four more Zero patches and a set of backports I'd >>>> like in (making the source/target explicit as we did in 7 already, and >>>> Kelly's ant 1.8 patch). Everything else can wait until b20 >>>> >>>> >>>> >>>> Here's the backport: >>>> >>>> http://cr.openjdk.java.net/~andrew/6873059/webrev.01/jdk6.patch >>>> >>>> It's a replica of 6873059 as applied to the HotSpot, JDK and CORBA >>>> trees in OpenJDK7, the only difference being that we use 5 instead of >>>> 6 as the bootstrap version for OpenJDK6. Ok to push? Should I use >>>> the same bug ID or do you want to allocate a fresh one? >>>> >>>> >>>> Using the same bug id is fine, but I'd like Kelly to sanity check it >>>> before >>>> it goes back. >>>> >>>> >>>> >>> Ok, waiting for Kelly's response. >>> >>> >> Acknowledged. >> >> >>>> On another note, there is now some code requiring source level 6 in >>>> OpenJDK6 (due to use of the @Override annotation on interfaces): >>>> >>>> src/share/classes/javax/swing/plaf/synth/SynthComboBoxUI.java >>>> src/share/classes/javax/swing/plaf/synth/SynthLookAndFeel.java >>>> src/share/classes/javax/swing/plaf/synth/SynthTreeUI.java >>>> src/share/classes/sun/security/provider/certpath/OCSPResponse.java >>>> src/share/classes/sun/swing/plaf/synth/SynthFileChooserUIImpl.java >>>> >>>> >>>> There is an overly-long story behind -source 5 vs. -source 6 and >>>> @Override. >>>> The short answer is that javac in JDK 6 unconditionally applies the more >>>> liberal (and more useful) semantics for @Override. For the JDK sources, >>>> a >>>> compiler that does the same should be used. >>>> >>>> >>>> >>> Exactly. I know ecj throws it out for 5 but not for 6 and thus >>> building using ecj (our method for bootstrapping) falls foul of the >>> classes above. I'm not sure if javac is allowing them through because >>> its version of 1.5 allows it or it is simply defaulting to 6 because >>> nothing else is specified. I had a quick look but the version is >>> currently set in more than one place, so I think this needs a more >>> in-depth review and I'd prefer it waits until b20 to be on the safe >>> side. >>> >>> >> The javac command in JDK 6, both open and proprietary, will allow use of >> @Override on interfaces, even if "-source 5" is specified. >> >> > > Ok, that explains why it works for javac and fails for ecj. Is there > any reason we're using 5 for a build of OpenJDK 6? The bootstrapping > classes are now explicitly 5, but surely the final JDK code should be > 6. > Not necessarily. How rt.jar and tools.jar are compiled (and even if there is a rt.jar and tools.jar) is an implementation artifact of the JDK. One of the main benefits of target 6 over target 5 is that stackmaps are supported in the class files which allows for faster class file verification. However, files on the bootclasspath, such as rt.jar, are not verified anyway so using target 6 to compile the classes going into rt.jar would add to the size of rt.jar without conferring any speed benefit since verification is skipped anyway. >>>> So we should look at bumping the generated code version to 6 (it still >>>> seems to be 5 even though this is OpenJDK6). I'd prefer to leave that >>>> until b20 though. >>>> >>>> I see Kelly's patch went in. It would be nice to also backport >>>> http://hg.openjdk.java.net/jdk7/jdk7/hotspot/rev/5fdbe2cdf565 (a minor >>>> warning fix) so IcedTea6's OpenJDK backport set is empty again. >>>> >>>> >>>> I approve the warning fix being backported. >>>> >>>> >>>> >>> Done: http://hg.openjdk.java.net/jdk6/jdk6/hotspot/rev/6ee696377676 >>> >>> >> Thanks, >> >> >>> The first of the four Zero backports is 6903453: Zero build on ARM and >>> IA-64. >>> >>> http://cr.openjdk.java.net/~andrew/6903453/webrev.01/ >>> >>> It adds a few build conditionals for building on arm and ia64 platforms. >>> >>> Ok to push? >>> >>> >> Approved to go back. >> >> > > Done: > > http://hg.openjdk.java.net/jdk6/jdk6/corba/rev/e83301fe4687 > http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/17a217fd1d49 > > Next one is 6909153 which turns off a number of options that fail or > are inappropriate on Zero: > > http://cr.openjdk.java.net/~andrew/6909153/webrev.01/ > > Ok to push? > Approved to go back. I'm not sure of the HotSpot conventions, but the removal of the opening brace on the end of line 1824 of compileBroker.cpp looks suspect to me. However, I see this was done in the JDK 7 HotSpot sources so it is more important to keep the patches the same. > >> I've run some regression tests on a build from the current tip and the >> result look good; in particular, all the rmid tests pass again :-) >> >> > > These results look good. Plenty of new tests :-) > > The only odd one seems to be > > >> pass fail com/sun/crypto/provider/KeyFactory/TestProviderLeak.java >> > > The rest are either new or disabled by the security update. > It appears a port of 6923976: TestProviderLeak.java is using too small of an initial heap under newer Hotspot (b79+) is needed: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/7136683a33d2 I've applied the patch to a local repo, the test passes again, and I've pushed this changeset into the master. Thanks for noticing this and prompting an investigation, -Joe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/jdk6-dev/attachments/20100408/9be67044/attachment.html From joe.darcy at sun.com Thu Apr 8 15:20:13 2010 From: joe.darcy at sun.com (joe.darcy at sun.com) Date: Thu, 08 Apr 2010 22:20:13 +0000 Subject: hg: jdk6/jdk6/jdk: 6923976: TestProviderLeak.java is using too small of an initial heap under newer Hotspot (b79+) Message-ID: <20100408222044.1ADF94446A@hg.openjdk.java.net> Changeset: 450ca9670efb Author: wetmore Date: 2010-02-05 17:05 -0800 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/450ca9670efb 6923976: TestProviderLeak.java is using too small of an initial heap under newer Hotspot (b79+) Reviewed-by: ohair ! test/com/sun/crypto/provider/KeyFactory/TestProviderLeak.java From ahughes at redhat.com Thu Apr 8 16:36:54 2010 From: ahughes at redhat.com (ahughes at redhat.com) Date: Thu, 08 Apr 2010 23:36:54 +0000 Subject: hg: jdk6/jdk6/hotspot: 6909153: Fix broken options on Zero Message-ID: <20100408233706.75C574446C@hg.openjdk.java.net> Changeset: 131295e4931b Author: twisti Date: 2010-01-04 00:22 -0800 URL: http://hg.openjdk.java.net/jdk6/jdk6/hotspot/rev/131295e4931b 6909153: Fix broken options on Zero Summary: Smaller fixes to ensure that Zero still works with non-standard options. Reviewed-by: twisti Contributed-by: Gary Benson ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/runtime/arguments.cpp From ahughes at redhat.com Thu Apr 8 16:54:57 2010 From: ahughes at redhat.com (Andrew John Hughes) Date: Fri, 9 Apr 2010 00:54:57 +0100 Subject: Test Backports In-Reply-To: <4BBE5734.30101@oracle.com> References: <17c6771e1003291310u3e1b3231i6a054fd76bc24182@mail.gmail.com> <4BB3ABEE.4070102@oracle.com> <4BBA91BD.8020105@oracle.com> <4BBBD0EE.7040705@oracle.com> <4BBD2F69.4070609@oracle.com> <4BBE5734.30101@oracle.com> Message-ID: On 8 April 2010 23:22, Joe Darcy wrote: [snip] > > On another note, there is now some code requiring source level 6 in > OpenJDK6 (due to use of the @Override annotation on interfaces): > > ?src/share/classes/javax/swing/plaf/synth/SynthComboBoxUI.java > ?src/share/classes/javax/swing/plaf/synth/SynthLookAndFeel.java > ?src/share/classes/javax/swing/plaf/synth/SynthTreeUI.java > ?src/share/classes/sun/security/provider/certpath/OCSPResponse.java > ?src/share/classes/sun/swing/plaf/synth/SynthFileChooserUIImpl.java > > > There is an overly-long story behind -source 5 vs. -source 6 and > @Override. > The short answer is that javac in JDK 6 unconditionally applies the more > liberal (and more useful) semantics for @Override. ?For the JDK sources, > a > compiler that does the same should be used. > > > > > Exactly. ?I know ecj throws it out for 5 but not for 6 and thus > building using ecj (our method for bootstrapping) falls foul of the > classes above. ?I'm not sure if javac is allowing them through because > its version of 1.5 allows it or it is simply defaulting to 6 because > nothing else is specified. ?I had a quick look but the version is > currently set in more than one place, so I think this needs a more > in-depth review and I'd prefer it waits until b20 to be on the safe > side. > > > > The javac command in JDK 6, both open and proprietary, will allow use of > @Override on interfaces, even if "-source 5" is specified. > > > > Ok, that explains why it works for javac and fails for ecj. Is there > any reason we're using 5 for a build of OpenJDK 6? The bootstrapping > classes are now explicitly 5, but surely the final JDK code should be > 6. > > > Not necessarily.? How rt.jar and tools.jar are compiled (and even if there > is a rt.jar and tools.jar) is an implementation artifact of the JDK.? One of > the main benefits of target 6 over target 5 is that stackmaps are supported > in the class files which allows for faster class file verification. > However, files on the bootclasspath, such as rt.jar, are not verified anyway > so using target 6 to compile the classes going into rt.jar would add to the > size of rt.jar without conferring any speed benefit since verification is > skipped anyway. > Ok. Well we have 1.6 code listed above, so we either need to decide to move to 6 or revert these @Override annotations. [snip] > Next one is 6909153 which turns off a number of options that fail or > are inappropriate on Zero: > > http://cr.openjdk.java.net/~andrew/6909153/webrev.01/ > > Ok to push? > > > Approved to go back. > > I'm not sure of the HotSpot conventions, but the removal of the opening > brace on the end of line 1824 of compileBroker.cpp looks suspect to me. > > However, I see this was done in the JDK 7 HotSpot sources so it is more > important to keep the patches the same. > The if block was a one-liner, so the brace is now being used to close the new conditional instead. Not ideal, but not a bug and, as you say, it's as it is in 7. This was a clean hg import. Pushed: http://hg.openjdk.java.net/jdk6/jdk6/hotspot/rev/131295e4931b The next one is 6913869, an assertion fix needed to build on ppc and ZSeries: http://cr.openjdk.java.net/~andrew/6913869/webrev.01/ Ok to push? Another clean hg import from jdk7. > > > I've run some regression tests on a build from the current tip and the > result look good; in particular, all the rmid tests pass again :-) > > > > These results look good. Plenty of new tests :-) > > The only odd one seems to be > > > > pass fail com/sun/crypto/provider/KeyFactory/TestProviderLeak.java > > > The rest are either new or disabled by the security update. > > > It appears a port of 6923976: TestProviderLeak.java is using too small of an > initial heap under newer Hotspot (b79+) is needed: > http://hg.openjdk.java.net/jdk7/tl/jdk/rev/7136683a33d2 > > I've applied the patch to a local repo, the test passes again, and I've > pushed this changeset into the master. > > Thanks for noticing this and prompting an investigation, > No problem. Thanks for finding the issue. > -Joe > Cheers, -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From ahughes at redhat.com Thu Apr 8 17:05:35 2010 From: ahughes at redhat.com (ahughes at redhat.com) Date: Fri, 09 Apr 2010 00:05:35 +0000 Subject: hg: jdk6/jdk6/corba: 6873059: Explicitly use -source 5 -target 5 when compiling with the boot jdk javac Message-ID: <20100409000537.A62444446E@hg.openjdk.java.net> Changeset: 9eeb441e885c Author: andrew Date: 2010-04-09 00:56 +0100 URL: http://hg.openjdk.java.net/jdk6/jdk6/corba/rev/9eeb441e885c 6873059: Explicitly use -source 5 -target 5 when compiling with the boot jdk javac Summary: Don't rely on bootstrap compiler defaults Reviewed-by: jjg, ohair ! make/common/shared/Defs-java.gmk From ahughes at redhat.com Thu Apr 8 17:08:50 2010 From: ahughes at redhat.com (ahughes at redhat.com) Date: Fri, 09 Apr 2010 00:08:50 +0000 Subject: hg: jdk6/jdk6/jdk: 2 new changesets Message-ID: <20100409000915.9A3E244470@hg.openjdk.java.net> Changeset: cca800e22daa Author: andrew Date: 2010-04-09 01:07 +0100 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/cca800e22daa 6873059: Explicitly use -source 5 -target 5 when compiling with the boot jdk javac Summary: The bootstrap javac currently uses the default source and targets of the boot javac Reviewed-by: ohair ! make/common/shared/Defs-java.gmk Changeset: 5b407bce9940 Author: andrew Date: 2010-04-09 01:08 +0100 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/5b407bce9940 Merge From jonathan.gibbons at oracle.com Thu Apr 8 16:41:53 2010 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 08 Apr 2010 16:41:53 -0700 Subject: javadoc no longer inherits doc from sourcepath In-Reply-To: References: Message-ID: <4BBE69C1.8020502@oracle.com> Martin, Thank you for your report. I have created CR 6942366 to track this issue. -- Jon Martin Buchholz wrote: > Hi javadoc team, > > This is a bug report. Seems pretty serious - S2? > > javadoc man page says, > > """ > The source file for the inherited method need only be on the path spec > ified by -sourcepath for the doc comment to actually be available to > copy. Neither the class nor its package needs to be passed in on the > command line. This contrasts with 1.3.x and earlier releases, where the > class had to be a documented class > """ > > It seems that the jdk has reverted to the 1.3.x behavior. > This happened somewhere between openjdk6-b12 and openjdk6-b13, > and is still broken at head of openjdk7. But 6u19 works fine! > > E.g. > > public class JavadocBug { > public String toString() { return ""; } > } > > Then try > > javadoc -sourcepath $PATH_TO_JDK_SOURCES/src/share/classes JavadocBug.java > > Martin > From joe.darcy at oracle.com Thu Apr 8 17:27:32 2010 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 08 Apr 2010 17:27:32 -0700 Subject: Test Backports In-Reply-To: References: <17c6771e1003291310u3e1b3231i6a054fd76bc24182@mail.gmail.com> <4BB3ABEE.4070102@oracle.com> <4BBA91BD.8020105@oracle.com> <4BBBD0EE.7040705@oracle.com> <4BBD2F69.4070609@oracle.com> <4BBE5734.30101@oracle.com> Message-ID: <4BBE7474.6020704@oracle.com> On 04/08/10 04:54 PM, Andrew John Hughes wrote: > On 8 April 2010 23:22, Joe Darcy wrote: > > [snip] > > >> On another note, there is now some code requiring source level 6 in >> OpenJDK6 (due to use of the @Override annotation on interfaces): >> >> src/share/classes/javax/swing/plaf/synth/SynthComboBoxUI.java >> src/share/classes/javax/swing/plaf/synth/SynthLookAndFeel.java >> src/share/classes/javax/swing/plaf/synth/SynthTreeUI.java >> src/share/classes/sun/security/provider/certpath/OCSPResponse.java >> src/share/classes/sun/swing/plaf/synth/SynthFileChooserUIImpl.java >> >> >> There is an overly-long story behind -source 5 vs. -source 6 and >> @Override. >> The short answer is that javac in JDK 6 unconditionally applies the more >> liberal (and more useful) semantics for @Override. For the JDK sources, >> a >> compiler that does the same should be used. >> >> >> >> >> Exactly. I know ecj throws it out for 5 but not for 6 and thus >> building using ecj (our method for bootstrapping) falls foul of the >> classes above. I'm not sure if javac is allowing them through because >> its version of 1.5 allows it or it is simply defaulting to 6 because >> nothing else is specified. I had a quick look but the version is >> currently set in more than one place, so I think this needs a more >> in-depth review and I'd prefer it waits until b20 to be on the safe >> side. >> >> >> >> The javac command in JDK 6, both open and proprietary, will allow use of >> @Override on interfaces, even if "-source 5" is specified. >> >> >> >> Ok, that explains why it works for javac and fails for ecj. Is there >> any reason we're using 5 for a build of OpenJDK 6? The bootstrapping >> classes are now explicitly 5, but surely the final JDK code should be >> 6. >> >> >> Not necessarily. How rt.jar and tools.jar are compiled (and even if there >> is a rt.jar and tools.jar) is an implementation artifact of the JDK. One of >> the main benefits of target 6 over target 5 is that stackmaps are supported >> in the class files which allows for faster class file verification. >> However, files on the bootclasspath, such as rt.jar, are not verified anyway >> so using target 6 to compile the classes going into rt.jar would add to the >> size of rt.jar without conferring any speed benefit since verification is >> skipped anyway. >> >> > > Ok. Well we have 1.6 code listed above, so we either need to decide > to move to 6 or revert these @Override annotations. > Is there still a need to bootstrap with ecj as opposed to an earlier OpenJDK/IcedTea build? > [snip] > > >> Next one is 6909153 which turns off a number of options that fail or >> are inappropriate on Zero: >> >> http://cr.openjdk.java.net/~andrew/6909153/webrev.01/ >> >> Ok to push? >> >> >> Approved to go back. >> >> I'm not sure of the HotSpot conventions, but the removal of the opening >> brace on the end of line 1824 of compileBroker.cpp looks suspect to me. >> >> However, I see this was done in the JDK 7 HotSpot sources so it is more >> important to keep the patches the same. >> >> > > The if block was a one-liner, so the brace is now being used to close > the new conditional instead. Right; I had to look twice to verify it was all okay :-) > Not ideal, but not a bug and, as you > say, it's as it is in 7. This was a clean hg import. > > Pushed: http://hg.openjdk.java.net/jdk6/jdk6/hotspot/rev/131295e4931b > > The next one is 6913869, an assertion fix needed to build on ppc and ZSeries: > > http://cr.openjdk.java.net/~andrew/6913869/webrev.01/ > > Ok to push? Another clean hg import from jdk7. > Approved to go back. -Joe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/jdk6-dev/attachments/20100408/4fe4bb42/attachment.html From ahughes at redhat.com Thu Apr 8 17:28:57 2010 From: ahughes at redhat.com (Andrew John Hughes) Date: Fri, 9 Apr 2010 01:28:57 +0100 Subject: [kelly.ohair@oracle.com: Re: Test Backports] In-Reply-To: <16FFC054-DF30-42D0-A158-A0D6D5D58A23@oracle.com> References: <20100408195726.GG13436@rivendell.middle-earth.co.uk> <16FFC054-DF30-42D0-A158-A0D6D5D58A23@oracle.com> Message-ID: On 8 April 2010 21:10, Kelly O'Hair wrote: > Sorry. My fault. > > -kto > > On Apr 8, 2010, at 12:57 PM, Andrew John Hughes wrote: > >> This discussion seems to have moved off-list... :-( >> >> ----- Forwarded message from Kelly O'Hair ----- >> >> Date: Thu, 8 Apr 2010 12:00:36 -0700 >> From: Kelly O'Hair >> To: Joe Darcy >> Subject: Re: Test Backports >> >> >> On Apr 8, 2010, at 11:21 AM, Joe Darcy wrote: >> >>> On 04/08/10 10:16 AM, Kelly O'Hair wrote: >>>> >>>> If there is something I need to do on this email thread, please >>>> let me know, >>>> I am unable to follow the discussion very well. >>>> >>>> -kto >>> >>> Kelly, >>> >>> Please review Andrew's backport of 6873059 "Explicitly use -source >>> 6 -target 6 when compiling with the boot jdk javac" to OpenJDK 6: >>> >>> http://cr.openjdk.java.net/~andrew/6873059/webrev.01/ >> >> The jdk and corba changes look fine. >> Pushed: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/cca800e22daa http://hg.openjdk.java.net/jdk6/jdk6/corba/rev/9eeb441e885c >> For hotspot... >> I don't know what various javac's will do when the -source and -target >> options show up twice, >> and I think where the makefiles are using 1.4 settings, that will >> happen. Is that ok? Last setting wins? >> >> I'm kind of surprised that hotspot used javac -g all over the place, >> seems needless for >> normal builds. So I'm happy with the removals of the -g's, but wonder >> if the default >> should be no -g at all, or at least isolate the -g option and have it >> controlled by the >> same make variables that the jdk uses to control 'javac -g'? >> And there is still the outstanding issue that hotspot makefiles should >> really be using the >> langtools javac to do all it's java compilations, not the boot javac, >> but that's for another day. >> >> I've kind of distanced myself a bit from the hotspot makefiles >> recently, since they just added >> back all kinds of jdk5-isms (_g suffix etc.). They pretty much belong >> to the hotspot team now. >> As Joe noted, javac uses the last source specification. ecj errors out if multiple source definitions are specified, but we already work around this with a wrapper in IcedTea. Are you ok for the HotSpot backport to be pushed? >> -kto >> >>> >>> -Joe >> >> >> ----- End forwarded message ----- >> >> -- >> Andrew :) >> >> Free Java Software Engineer >> Red Hat, Inc. (http://www.redhat.com) >> >> Support Free Java! >> Contribute to GNU Classpath and the OpenJDK >> http://www.gnu.org/software/classpath >> http://openjdk.java.net >> PGP Key: 94EFD9D8 (http://subkeys.pgp.net) >> Fingerprint = F8EF F1EA 401E 2E60 15FA ?7927 142C 2591 94EF D9D8 > > -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From ahughes at redhat.com Thu Apr 8 17:32:53 2010 From: ahughes at redhat.com (ahughes at redhat.com) Date: Fri, 09 Apr 2010 00:32:53 +0000 Subject: hg: jdk6/jdk6/hotspot: 6913869: Zero assert fix Message-ID: <20100409003255.D534344472@hg.openjdk.java.net> Changeset: 3b8413513ece Author: twisti Date: 2010-01-04 03:34 -0800 URL: http://hg.openjdk.java.net/jdk6/jdk6/hotspot/rev/3b8413513ece 6913869: Zero assert fix Summary: Zero currently won't build on zSeries or PowerPC machines with assertions turned on. Reviewed-by: twisti Contributed-by: Gary Benson ! src/share/vm/prims/jni.cpp From ahughes at redhat.com Thu Apr 8 17:43:45 2010 From: ahughes at redhat.com (Andrew John Hughes) Date: Fri, 9 Apr 2010 01:43:45 +0100 Subject: Test Backports In-Reply-To: <4BBE7474.6020704@oracle.com> References: <17c6771e1003291310u3e1b3231i6a054fd76bc24182@mail.gmail.com> <4BBA91BD.8020105@oracle.com> <4BBBD0EE.7040705@oracle.com> <4BBD2F69.4070609@oracle.com> <4BBE5734.30101@oracle.com> <4BBE7474.6020704@oracle.com> Message-ID: On 9 April 2010 01:27, Joe Darcy wrote: > On 04/08/10 04:54 PM, Andrew John Hughes wrote: > > On 8 April 2010 23:22, Joe Darcy wrote: > > [snip] > > > > On another note, there is now some code requiring source level 6 in > OpenJDK6 (due to use of the @Override annotation on interfaces): > > ?src/share/classes/javax/swing/plaf/synth/SynthComboBoxUI.java > ?src/share/classes/javax/swing/plaf/synth/SynthLookAndFeel.java > ?src/share/classes/javax/swing/plaf/synth/SynthTreeUI.java > ?src/share/classes/sun/security/provider/certpath/OCSPResponse.java > ?src/share/classes/sun/swing/plaf/synth/SynthFileChooserUIImpl.java > > > There is an overly-long story behind -source 5 vs. -source 6 and > @Override. > The short answer is that javac in JDK 6 unconditionally applies the more > liberal (and more useful) semantics for @Override. ?For the JDK sources, > a > compiler that does the same should be used. > > > > > Exactly. ?I know ecj throws it out for 5 but not for 6 and thus > building using ecj (our method for bootstrapping) falls foul of the > classes above. ?I'm not sure if javac is allowing them through because > its version of 1.5 allows it or it is simply defaulting to 6 because > nothing else is specified. ?I had a quick look but the version is > currently set in more than one place, so I think this needs a more > in-depth review and I'd prefer it waits until b20 to be on the safe > side. > > > > The javac command in JDK 6, both open and proprietary, will allow use of > @Override on interfaces, even if "-source 5" is specified. > > > > Ok, that explains why it works for javac and fails for ecj. Is there > any reason we're using 5 for a build of OpenJDK 6? The bootstrapping > classes are now explicitly 5, but surely the final JDK code should be > 6. > > > Not necessarily.? How rt.jar and tools.jar are compiled (and even if there > is a rt.jar and tools.jar) is an implementation artifact of the JDK.? One of > the main benefits of target 6 over target 5 is that stackmaps are supported > in the class files which allows for faster class file verification. > However, files on the bootclasspath, such as rt.jar, are not verified anyway > so using target 6 to compile the classes going into rt.jar would add to the > size of rt.jar without conferring any speed benefit since verification is > skipped anyway. > > > > Ok. Well we have 1.6 code listed above, so we either need to decide > to move to 6 or revert these @Override annotations. > > > Is there still a need to bootstrap with ecj as opposed to an earlier > OpenJDK/IcedTea build? > We keep it working. It makes it possible to port to new platforms as gcj can be built without an existing Java stack being present. > [snip] > > > > Next one is 6909153 which turns off a number of options that fail or > are inappropriate on Zero: > > http://cr.openjdk.java.net/~andrew/6909153/webrev.01/ > > Ok to push? > > > Approved to go back. > > I'm not sure of the HotSpot conventions, but the removal of the opening > brace on the end of line 1824 of compileBroker.cpp looks suspect to me. > > However, I see this was done in the JDK 7 HotSpot sources so it is more > important to keep the patches the same. > > > > The if block was a one-liner, so the brace is now being used to close > the new conditional instead. > > Right; I had to look twice to verify it was all okay :-) > Me too! > Not ideal, but not a bug and, as you > say, it's as it is in 7. This was a clean hg import. > > Pushed: http://hg.openjdk.java.net/jdk6/jdk6/hotspot/rev/131295e4931b > > The next one is 6913869, an assertion fix needed to build on ppc and > ZSeries: > > http://cr.openjdk.java.net/~andrew/6913869/webrev.01/ > > Ok to push? Another clean hg import from jdk7. > > > Approved to go back. > Done: The last one is 6914622: http://cr.openjdk.java.net/~andrew/6914622/webrev.01/ This ensures that all flags are printed on product VMs, rather than options being hidden. Ok to push? With this approved and Kelly's ok on the HotSpot patch, I'm done for b19. > -Joe > -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From ahughes at redhat.com Thu Apr 8 17:44:24 2010 From: ahughes at redhat.com (Andrew John Hughes) Date: Fri, 9 Apr 2010 01:44:24 +0100 Subject: Test Backports In-Reply-To: References: <17c6771e1003291310u3e1b3231i6a054fd76bc24182@mail.gmail.com> <4BBBD0EE.7040705@oracle.com> <4BBD2F69.4070609@oracle.com> <4BBE5734.30101@oracle.com> <4BBE7474.6020704@oracle.com> Message-ID: On 9 April 2010 01:43, Andrew John Hughes wrote: > On 9 April 2010 01:27, Joe Darcy wrote: >> On 04/08/10 04:54 PM, Andrew John Hughes wrote: >> >> On 8 April 2010 23:22, Joe Darcy wrote: >> >> [snip] >> >> >> >> On another note, there is now some code requiring source level 6 in >> OpenJDK6 (due to use of the @Override annotation on interfaces): >> >> ?src/share/classes/javax/swing/plaf/synth/SynthComboBoxUI.java >> ?src/share/classes/javax/swing/plaf/synth/SynthLookAndFeel.java >> ?src/share/classes/javax/swing/plaf/synth/SynthTreeUI.java >> ?src/share/classes/sun/security/provider/certpath/OCSPResponse.java >> ?src/share/classes/sun/swing/plaf/synth/SynthFileChooserUIImpl.java >> >> >> There is an overly-long story behind -source 5 vs. -source 6 and >> @Override. >> The short answer is that javac in JDK 6 unconditionally applies the more >> liberal (and more useful) semantics for @Override. ?For the JDK sources, >> a >> compiler that does the same should be used. >> >> >> >> >> Exactly. ?I know ecj throws it out for 5 but not for 6 and thus >> building using ecj (our method for bootstrapping) falls foul of the >> classes above. ?I'm not sure if javac is allowing them through because >> its version of 1.5 allows it or it is simply defaulting to 6 because >> nothing else is specified. ?I had a quick look but the version is >> currently set in more than one place, so I think this needs a more >> in-depth review and I'd prefer it waits until b20 to be on the safe >> side. >> >> >> >> The javac command in JDK 6, both open and proprietary, will allow use of >> @Override on interfaces, even if "-source 5" is specified. >> >> >> >> Ok, that explains why it works for javac and fails for ecj. ?Is there >> any reason we're using 5 for a build of OpenJDK 6? ?The bootstrapping >> classes are now explicitly 5, but surely the final JDK code should be >> 6. >> >> >> Not necessarily.? How rt.jar and tools.jar are compiled (and even if there >> is a rt.jar and tools.jar) is an implementation artifact of the JDK.? One of >> the main benefits of target 6 over target 5 is that stackmaps are supported >> in the class files which allows for faster class file verification. >> However, files on the bootclasspath, such as rt.jar, are not verified anyway >> so using target 6 to compile the classes going into rt.jar would add to the >> size of rt.jar without conferring any speed benefit since verification is >> skipped anyway. >> >> >> >> Ok. ?Well we have 1.6 code listed above, so we either need to decide >> to move to 6 or revert these @Override annotations. >> >> >> Is there still a need to bootstrap with ecj as opposed to an earlier >> OpenJDK/IcedTea build? >> > > We keep it working. ?It makes it possible to port to new platforms as > gcj can be built without an existing Java stack being present. > >> [snip] >> >> >> >> Next one is 6909153 which turns off a number of options that fail or >> are inappropriate on Zero: >> >> http://cr.openjdk.java.net/~andrew/6909153/webrev.01/ >> >> Ok to push? >> >> >> Approved to go back. >> >> I'm not sure of the HotSpot conventions, but the removal of the opening >> brace on the end of line 1824 of compileBroker.cpp looks suspect to me. >> >> However, I see this was done in the JDK 7 HotSpot sources so it is more >> important to keep the patches the same. >> >> >> >> The if block was a one-liner, so the brace is now being used to close >> the new conditional instead. >> >> Right; I had to look twice to verify it was all okay :-) >> > > Me too! > >> Not ideal, but not a bug and, as you >> say, it's as it is in 7. ?This was a clean hg import. >> >> Pushed: http://hg.openjdk.java.net/jdk6/jdk6/hotspot/rev/131295e4931b >> >> The next one is 6913869, an assertion fix needed to build on ppc and >> ZSeries: >> >> http://cr.openjdk.java.net/~andrew/6913869/webrev.01/ >> >> Ok to push? ?Another clean hg import from jdk7. >> >> >> Approved to go back. >> > > Done: > > The last one is 6914622: > > http://cr.openjdk.java.net/~andrew/6914622/webrev.01/ > > This ensures that all flags are printed on product VMs, rather than > options being hidden. > > Ok to push? > > With this approved and Kelly's ok on the HotSpot patch, I'm done for b19. > >> -Joe >> > > > > -- > Andrew :-) > > Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > Support Free Java! > Contribute to GNU Classpath and the OpenJDK > http://www.gnu.org/software/classpath > http://openjdk.java.net > > PGP Key: 94EFD9D8 (http://subkeys.pgp.net) > Fingerprint: F8EF F1EA 401E 2E60 15FA ?7927 142C 2591 94EF D9D8 > Forgot the link: http://hg.openjdk.java.net/jdk6/jdk6/hotspot/rev/3b8413513ece -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From joe.darcy at oracle.com Thu Apr 8 17:47:57 2010 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 08 Apr 2010 17:47:57 -0700 Subject: Test Backports In-Reply-To: References: <17c6771e1003291310u3e1b3231i6a054fd76bc24182@mail.gmail.com> <4BBA91BD.8020105@oracle.com> <4BBBD0EE.7040705@oracle.com> <4BBD2F69.4070609@oracle.com> <4BBE5734.30101@oracle.com> <4BBE7474.6020704@oracle.com> Message-ID: <4BBE793D.4050505@oracle.com> On 04/08/10 05:43 PM, Andrew John Hughes wrote: > On 9 April 2010 01:27, Joe Darcy wrote: > >> On 04/08/10 04:54 PM, Andrew John Hughes wrote: >> >> On 8 April 2010 23:22, Joe Darcy wrote: >> >> [snip] >> >> >> >> On another note, there is now some code requiring source level 6 in >> OpenJDK6 (due to use of the @Override annotation on interfaces): >> >> src/share/classes/javax/swing/plaf/synth/SynthComboBoxUI.java >> src/share/classes/javax/swing/plaf/synth/SynthLookAndFeel.java >> src/share/classes/javax/swing/plaf/synth/SynthTreeUI.java >> src/share/classes/sun/security/provider/certpath/OCSPResponse.java >> src/share/classes/sun/swing/plaf/synth/SynthFileChooserUIImpl.java >> >> >> There is an overly-long story behind -source 5 vs. -source 6 and >> @Override. >> The short answer is that javac in JDK 6 unconditionally applies the more >> liberal (and more useful) semantics for @Override. For the JDK sources, >> a >> compiler that does the same should be used. >> >> >> >> >> Exactly. I know ecj throws it out for 5 but not for 6 and thus >> building using ecj (our method for bootstrapping) falls foul of the >> classes above. I'm not sure if javac is allowing them through because >> its version of 1.5 allows it or it is simply defaulting to 6 because >> nothing else is specified. I had a quick look but the version is >> currently set in more than one place, so I think this needs a more >> in-depth review and I'd prefer it waits until b20 to be on the safe >> side. >> >> >> >> The javac command in JDK 6, both open and proprietary, will allow use of >> @Override on interfaces, even if "-source 5" is specified. >> >> >> >> Ok, that explains why it works for javac and fails for ecj. Is there >> any reason we're using 5 for a build of OpenJDK 6? The bootstrapping >> classes are now explicitly 5, but surely the final JDK code should be >> 6. >> >> >> Not necessarily. How rt.jar and tools.jar are compiled (and even if there >> is a rt.jar and tools.jar) is an implementation artifact of the JDK. One of >> the main benefits of target 6 over target 5 is that stackmaps are supported >> in the class files which allows for faster class file verification. >> However, files on the bootclasspath, such as rt.jar, are not verified anyway >> so using target 6 to compile the classes going into rt.jar would add to the >> size of rt.jar without conferring any speed benefit since verification is >> skipped anyway. >> >> >> >> Ok. Well we have 1.6 code listed above, so we either need to decide >> to move to 6 or revert these @Override annotations. >> >> >> Is there still a need to bootstrap with ecj as opposed to an earlier >> OpenJDK/IcedTea build? >> >> > > We keep it working. It makes it possible to port to new platforms as > gcj can be built without an existing Java stack being present. > I suppose that is easier than setting up a cross compilation environment for Java... > >> [snip] >> >> >> >> Next one is 6909153 which turns off a number of options that fail or >> are inappropriate on Zero: >> >> http://cr.openjdk.java.net/~andrew/6909153/webrev.01/ >> >> Ok to push? >> >> >> Approved to go back. >> >> I'm not sure of the HotSpot conventions, but the removal of the opening >> brace on the end of line 1824 of compileBroker.cpp looks suspect to me. >> >> However, I see this was done in the JDK 7 HotSpot sources so it is more >> important to keep the patches the same. >> >> >> >> The if block was a one-liner, so the brace is now being used to close >> the new conditional instead. >> >> Right; I had to look twice to verify it was all okay :-) >> >> > > Me too! > > >> Not ideal, but not a bug and, as you >> say, it's as it is in 7. This was a clean hg import. >> >> Pushed: http://hg.openjdk.java.net/jdk6/jdk6/hotspot/rev/131295e4931b >> >> The next one is 6913869, an assertion fix needed to build on ppc and >> ZSeries: >> >> http://cr.openjdk.java.net/~andrew/6913869/webrev.01/ >> >> Ok to push? Another clean hg import from jdk7. >> >> >> Approved to go back. >> >> > > Done: > > The last one is 6914622: > > http://cr.openjdk.java.net/~andrew/6914622/webrev.01/ > > This ensures that all flags are printed on product VMs, rather than > options being hidden. > Looks fine; approved to push! -Joe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/jdk6-dev/attachments/20100408/af89d3e5/attachment.html From ahughes at redhat.com Thu Apr 8 17:59:33 2010 From: ahughes at redhat.com (ahughes at redhat.com) Date: Fri, 09 Apr 2010 00:59:33 +0000 Subject: hg: jdk6/jdk6/hotspot: 6914622: Print values of all flags for product VM Message-ID: <20100409005936.7567844474@hg.openjdk.java.net> Changeset: 5c6d1b90dc19 Author: kvn Date: 2010-01-07 16:24 -0800 URL: http://hg.openjdk.java.net/jdk6/jdk6/hotspot/rev/5c6d1b90dc19 6914622: Print values of all flags for product VM Summary: Change the flag -XX:+PrintFlagsFinal to product and add new product flag -XX:+PrintFlagsInitial. Reviewed-by: phh, ysr Contributed-by: gbenson at redhat.com ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.cpp ! src/share/vm/runtime/globals.hpp From kalli at midverk.is Thu Apr 8 18:40:07 2010 From: kalli at midverk.is (kalli at midverk.is) Date: Fri, 09 Apr 2010 01:40:07 +0000 Subject: hg: jdk6/jdk6/jdk: 6941027: Gervill update, April 2010 Message-ID: <20100409014020.147B84447A@hg.openjdk.java.net> Changeset: 74e449a8c951 Author: kalli Date: 2010-04-09 01:38 +0000 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/74e449a8c951 6941027: Gervill update, April 2010 Reviewed-by: amenkov ! src/share/classes/com/sun/media/sound/AudioFloatFormatConverter.java ! src/share/classes/com/sun/media/sound/AudioSynthesizerPropertyInfo.java ! src/share/classes/com/sun/media/sound/ModelByteBufferWavetable.java ! src/share/classes/com/sun/media/sound/ModelInstrument.java + src/share/classes/com/sun/media/sound/ModelStandardIndexedDirector.java ! src/share/classes/com/sun/media/sound/SoftChannel.java ! src/share/classes/com/sun/media/sound/SoftSynthesizer.java ! src/share/classes/com/sun/media/sound/SoftVoice.java + test/javax/sound/midi/Gervill/AudioFloatFormatConverter/SkipTest.java + test/javax/sound/midi/Gervill/ModelByteBufferWavetable/OpenStream.java + test/javax/sound/midi/Gervill/SoftSynthesizer/GetAvailableInstruments2.java + test/javax/sound/midi/Gervill/SoftSynthesizer/GetLoadedInstruments2.java + test/javax/sound/midi/Gervill/SoftSynthesizer/GetPropertyInfo.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/LoadAllInstruments.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/LoadInstrument.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/LoadInstruments.java ! test/javax/sound/midi/Gervill/SoftSynthesizer/RemapInstrument.java + test/javax/sound/midi/Gervill/SoftSynthesizer/TestDisableLoadDefaultSoundbank.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/SoftTuning/RealTimeTuning.java From ahughes at redhat.com Fri Apr 9 06:56:02 2010 From: ahughes at redhat.com (Andrew John Hughes) Date: Fri, 9 Apr 2010 14:56:02 +0100 Subject: Test Backports In-Reply-To: <4BBE793D.4050505@oracle.com> References: <17c6771e1003291310u3e1b3231i6a054fd76bc24182@mail.gmail.com> <4BBBD0EE.7040705@oracle.com> <4BBD2F69.4070609@oracle.com> <4BBE5734.30101@oracle.com> <4BBE7474.6020704@oracle.com> <4BBE793D.4050505@oracle.com> Message-ID: On 9 April 2010 01:47, Joe Darcy wrote: > On 04/08/10 05:43 PM, Andrew John Hughes wrote: > > On 9 April 2010 01:27, Joe Darcy wrote: > > > On 04/08/10 04:54 PM, Andrew John Hughes wrote: > > On 8 April 2010 23:22, Joe Darcy wrote: > > [snip] > > > > On another note, there is now some code requiring source level 6 in > OpenJDK6 (due to use of the @Override annotation on interfaces): > > ?src/share/classes/javax/swing/plaf/synth/SynthComboBoxUI.java > ?src/share/classes/javax/swing/plaf/synth/SynthLookAndFeel.java > ?src/share/classes/javax/swing/plaf/synth/SynthTreeUI.java > ?src/share/classes/sun/security/provider/certpath/OCSPResponse.java > ?src/share/classes/sun/swing/plaf/synth/SynthFileChooserUIImpl.java > > > There is an overly-long story behind -source 5 vs. -source 6 and > @Override. > The short answer is that javac in JDK 6 unconditionally applies the more > liberal (and more useful) semantics for @Override. ?For the JDK sources, > a > compiler that does the same should be used. > > > > > Exactly. ?I know ecj throws it out for 5 but not for 6 and thus > building using ecj (our method for bootstrapping) falls foul of the > classes above. ?I'm not sure if javac is allowing them through because > its version of 1.5 allows it or it is simply defaulting to 6 because > nothing else is specified. ?I had a quick look but the version is > currently set in more than one place, so I think this needs a more > in-depth review and I'd prefer it waits until b20 to be on the safe > side. > > > > The javac command in JDK 6, both open and proprietary, will allow use of > @Override on interfaces, even if "-source 5" is specified. > > > > Ok, that explains why it works for javac and fails for ecj. Is there > any reason we're using 5 for a build of OpenJDK 6? The bootstrapping > classes are now explicitly 5, but surely the final JDK code should be > 6. > > > Not necessarily.? How rt.jar and tools.jar are compiled (and even if there > is a rt.jar and tools.jar) is an implementation artifact of the JDK.? One of > the main benefits of target 6 over target 5 is that stackmaps are supported > in the class files which allows for faster class file verification. > However, files on the bootclasspath, such as rt.jar, are not verified anyway > so using target 6 to compile the classes going into rt.jar would add to the > size of rt.jar without conferring any speed benefit since verification is > skipped anyway. > > > > Ok. Well we have 1.6 code listed above, so we either need to decide > to move to 6 or revert these @Override annotations. > > > Is there still a need to bootstrap with ecj as opposed to an earlier > OpenJDK/IcedTea build? > > > > We keep it working. It makes it possible to port to new platforms as > gcj can be built without an existing Java stack being present. > > > I suppose that is easier than setting up a cross compilation environment for > Java... > > > > [snip] > > > > Next one is 6909153 which turns off a number of options that fail or > are inappropriate on Zero: > > http://cr.openjdk.java.net/~andrew/6909153/webrev.01/ > > Ok to push? > > > Approved to go back. > > I'm not sure of the HotSpot conventions, but the removal of the opening > brace on the end of line 1824 of compileBroker.cpp looks suspect to me. > > However, I see this was done in the JDK 7 HotSpot sources so it is more > important to keep the patches the same. > > > > The if block was a one-liner, so the brace is now being used to close > the new conditional instead. > > Right; I had to look twice to verify it was all okay :-) > > > > Me too! > > > > Not ideal, but not a bug and, as you > say, it's as it is in 7. This was a clean hg import. > > Pushed: http://hg.openjdk.java.net/jdk6/jdk6/hotspot/rev/131295e4931b > > The next one is 6913869, an assertion fix needed to build on ppc and > ZSeries: > > http://cr.openjdk.java.net/~andrew/6913869/webrev.01/ > > Ok to push? Another clean hg import from jdk7. > > > Approved to go back. > > > > Done: > > The last one is 6914622: > > http://cr.openjdk.java.net/~andrew/6914622/webrev.01/ > > This ensures that all flags are printed on product VMs, rather than > options being hidden. > > > Looks fine; approved to push! > > -Joe > > Done: http://hg.openjdk.java.net/jdk6/jdk6/hotspot/rev/5c6d1b90dc19 I know I said that was the last one, but it seems another was pushed recently that I missed (presumably after I finished for the Easter vacation): http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/f61d795ce6de webrev: http://cr.openjdk.java.net/~andrew/6939845/webrev.01/ Ok to push? I know it's still a bit fresh but is #ifdef on ZERO. -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From joe.darcy at oracle.com Fri Apr 9 09:30:22 2010 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 09 Apr 2010 09:30:22 -0700 Subject: Test Backports In-Reply-To: References: <17c6771e1003291310u3e1b3231i6a054fd76bc24182@mail.gmail.com> <4BBBD0EE.7040705@oracle.com> <4BBD2F69.4070609@oracle.com> <4BBE5734.30101@oracle.com> <4BBE7474.6020704@oracle.com> <4BBE793D.4050505@oracle.com> Message-ID: <4BBF561E.2070801@oracle.com> Andrew John Hughes wrote: > On 9 April 2010 01:47, Joe Darcy wrote: > >> On 04/08/10 05:43 PM, Andrew John Hughes wrote: >> >> On 9 April 2010 01:27, Joe Darcy wrote: >> >> >> On 04/08/10 04:54 PM, Andrew John Hughes wrote: >> >> On 8 April 2010 23:22, Joe Darcy wrote: >> >> [snip] >> >> >> >> On another note, there is now some code requiring source level 6 in >> OpenJDK6 (due to use of the @Override annotation on interfaces): >> >> src/share/classes/javax/swing/plaf/synth/SynthComboBoxUI.java >> src/share/classes/javax/swing/plaf/synth/SynthLookAndFeel.java >> src/share/classes/javax/swing/plaf/synth/SynthTreeUI.java >> src/share/classes/sun/security/provider/certpath/OCSPResponse.java >> src/share/classes/sun/swing/plaf/synth/SynthFileChooserUIImpl.java >> >> >> There is an overly-long story behind -source 5 vs. -source 6 and >> @Override. >> The short answer is that javac in JDK 6 unconditionally applies the more >> liberal (and more useful) semantics for @Override. For the JDK sources, >> a >> compiler that does the same should be used. >> >> >> >> >> Exactly. I know ecj throws it out for 5 but not for 6 and thus >> building using ecj (our method for bootstrapping) falls foul of the >> classes above. I'm not sure if javac is allowing them through because >> its version of 1.5 allows it or it is simply defaulting to 6 because >> nothing else is specified. I had a quick look but the version is >> currently set in more than one place, so I think this needs a more >> in-depth review and I'd prefer it waits until b20 to be on the safe >> side. >> >> >> >> The javac command in JDK 6, both open and proprietary, will allow use of >> @Override on interfaces, even if "-source 5" is specified. >> >> >> >> Ok, that explains why it works for javac and fails for ecj. Is there >> any reason we're using 5 for a build of OpenJDK 6? The bootstrapping >> classes are now explicitly 5, but surely the final JDK code should be >> 6. >> >> >> Not necessarily. How rt.jar and tools.jar are compiled (and even if there >> is a rt.jar and tools.jar) is an implementation artifact of the JDK. One of >> the main benefits of target 6 over target 5 is that stackmaps are supported >> in the class files which allows for faster class file verification. >> However, files on the bootclasspath, such as rt.jar, are not verified anyway >> so using target 6 to compile the classes going into rt.jar would add to the >> size of rt.jar without conferring any speed benefit since verification is >> skipped anyway. >> >> >> >> Ok. Well we have 1.6 code listed above, so we either need to decide >> to move to 6 or revert these @Override annotations. >> >> >> Is there still a need to bootstrap with ecj as opposed to an earlier >> OpenJDK/IcedTea build? >> >> >> >> We keep it working. It makes it possible to port to new platforms as >> gcj can be built without an existing Java stack being present. >> >> >> I suppose that is easier than setting up a cross compilation environment for >> Java... >> >> >> >> [snip] >> >> >> >> Next one is 6909153 which turns off a number of options that fail or >> are inappropriate on Zero: >> >> http://cr.openjdk.java.net/~andrew/6909153/webrev.01/ >> >> Ok to push? >> >> >> Approved to go back. >> >> I'm not sure of the HotSpot conventions, but the removal of the opening >> brace on the end of line 1824 of compileBroker.cpp looks suspect to me. >> >> However, I see this was done in the JDK 7 HotSpot sources so it is more >> important to keep the patches the same. >> >> >> >> The if block was a one-liner, so the brace is now being used to close >> the new conditional instead. >> >> Right; I had to look twice to verify it was all okay :-) >> >> >> >> Me too! >> >> >> >> Not ideal, but not a bug and, as you >> say, it's as it is in 7. This was a clean hg import. >> >> Pushed: http://hg.openjdk.java.net/jdk6/jdk6/hotspot/rev/131295e4931b >> >> The next one is 6913869, an assertion fix needed to build on ppc and >> ZSeries: >> >> http://cr.openjdk.java.net/~andrew/6913869/webrev.01/ >> >> Ok to push? Another clean hg import from jdk7. >> >> >> Approved to go back. >> >> >> >> Done: >> >> The last one is 6914622: >> >> http://cr.openjdk.java.net/~andrew/6914622/webrev.01/ >> >> This ensures that all flags are printed on product VMs, rather than >> options being hidden. >> >> >> Looks fine; approved to push! >> >> -Joe >> >> >> > > Done: http://hg.openjdk.java.net/jdk6/jdk6/hotspot/rev/5c6d1b90dc19 > > I know I said that was the last one, but it seems another was pushed > recently that I missed (presumably after I finished for the Easter > vacation): > > http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/f61d795ce6de > > webrev: http://cr.openjdk.java.net/~andrew/6939845/webrev.01/ > > Ok to push? I know it's still a bit fresh but is #ifdef on ZERO. > Approved to go back. -Joe From ahughes at redhat.com Fri Apr 9 16:44:26 2010 From: ahughes at redhat.com (ahughes at redhat.com) Date: Fri, 09 Apr 2010 23:44:26 +0000 Subject: hg: jdk6/jdk6/hotspot: 6939845: zero needs fallback path in C++ interpreter for platform dependent fast bytecodes Message-ID: <20100409234439.67C16444C3@hg.openjdk.java.net> Changeset: dd5a19d97c1d Author: never Date: 2010-03-31 11:54 -0700 URL: http://hg.openjdk.java.net/jdk6/jdk6/hotspot/rev/dd5a19d97c1d 6939845: zero needs fallback path in C++ interpreter for platform dependent fast bytecodes Reviewed-by: never Contributed-by: ed at camswl.com ! src/share/vm/interpreter/bytecodeInterpreter.cpp From ahughes at redhat.com Fri Apr 9 17:05:01 2010 From: ahughes at redhat.com (Andrew John Hughes) Date: Sat, 10 Apr 2010 01:05:01 +0100 Subject: Test Backports In-Reply-To: <4BBF561E.2070801@oracle.com> References: <17c6771e1003291310u3e1b3231i6a054fd76bc24182@mail.gmail.com> <4BBD2F69.4070609@oracle.com> <4BBE5734.30101@oracle.com> <4BBE7474.6020704@oracle.com> <4BBE793D.4050505@oracle.com> <4BBF561E.2070801@oracle.com> Message-ID: On 9 April 2010 17:30, Joe Darcy wrote: > Andrew John Hughes wrote: >> >> On 9 April 2010 01:47, Joe Darcy wrote: >> >>> >>> On 04/08/10 05:43 PM, Andrew John Hughes wrote: >>> >>> On 9 April 2010 01:27, Joe Darcy wrote: >>> >>> >>> On 04/08/10 04:54 PM, Andrew John Hughes wrote: >>> >>> On 8 April 2010 23:22, Joe Darcy wrote: >>> >>> [snip] >>> >>> >>> >>> On another note, there is now some code requiring source level 6 in >>> OpenJDK6 (due to use of the @Override annotation on interfaces): >>> >>> ?src/share/classes/javax/swing/plaf/synth/SynthComboBoxUI.java >>> ?src/share/classes/javax/swing/plaf/synth/SynthLookAndFeel.java >>> ?src/share/classes/javax/swing/plaf/synth/SynthTreeUI.java >>> ?src/share/classes/sun/security/provider/certpath/OCSPResponse.java >>> ?src/share/classes/sun/swing/plaf/synth/SynthFileChooserUIImpl.java >>> >>> >>> There is an overly-long story behind -source 5 vs. -source 6 and >>> @Override. >>> The short answer is that javac in JDK 6 unconditionally applies the more >>> liberal (and more useful) semantics for @Override. ?For the JDK sources, >>> a >>> compiler that does the same should be used. >>> >>> >>> >>> >>> Exactly. ?I know ecj throws it out for 5 but not for 6 and thus >>> building using ecj (our method for bootstrapping) falls foul of the >>> classes above. ?I'm not sure if javac is allowing them through because >>> its version of 1.5 allows it or it is simply defaulting to 6 because >>> nothing else is specified. ?I had a quick look but the version is >>> currently set in more than one place, so I think this needs a more >>> in-depth review and I'd prefer it waits until b20 to be on the safe >>> side. >>> >>> >>> >>> The javac command in JDK 6, both open and proprietary, will allow use of >>> @Override on interfaces, even if "-source 5" is specified. >>> >>> >>> >>> Ok, that explains why it works for javac and fails for ecj. ?Is there >>> any reason we're using 5 for a build of OpenJDK 6? ?The bootstrapping >>> classes are now explicitly 5, but surely the final JDK code should be >>> 6. >>> >>> >>> Not necessarily. ?How rt.jar and tools.jar are compiled (and even if >>> there >>> is a rt.jar and tools.jar) is an implementation artifact of the JDK. ?One >>> of >>> the main benefits of target 6 over target 5 is that stackmaps are >>> supported >>> in the class files which allows for faster class file verification. >>> However, files on the bootclasspath, such as rt.jar, are not verified >>> anyway >>> so using target 6 to compile the classes going into rt.jar would add to >>> the >>> size of rt.jar without conferring any speed benefit since verification is >>> skipped anyway. >>> >>> >>> >>> Ok. ?Well we have 1.6 code listed above, so we either need to decide >>> to move to 6 or revert these @Override annotations. >>> >>> >>> Is there still a need to bootstrap with ecj as opposed to an earlier >>> OpenJDK/IcedTea build? >>> >>> >>> >>> We keep it working. ?It makes it possible to port to new platforms as >>> gcj can be built without an existing Java stack being present. >>> >>> >>> I suppose that is easier than setting up a cross compilation environment >>> for >>> Java... >>> >>> >>> >>> [snip] >>> >>> >>> >>> Next one is 6909153 which turns off a number of options that fail or >>> are inappropriate on Zero: >>> >>> http://cr.openjdk.java.net/~andrew/6909153/webrev.01/ >>> >>> Ok to push? >>> >>> >>> Approved to go back. >>> >>> I'm not sure of the HotSpot conventions, but the removal of the opening >>> brace on the end of line 1824 of compileBroker.cpp looks suspect to me. >>> >>> However, I see this was done in the JDK 7 HotSpot sources so it is more >>> important to keep the patches the same. >>> >>> >>> >>> The if block was a one-liner, so the brace is now being used to close >>> the new conditional instead. >>> >>> Right; I had to look twice to verify it was all okay :-) >>> >>> >>> >>> Me too! >>> >>> >>> >>> Not ideal, but not a bug and, as you >>> say, it's as it is in 7. ?This was a clean hg import. >>> >>> Pushed: http://hg.openjdk.java.net/jdk6/jdk6/hotspot/rev/131295e4931b >>> >>> The next one is 6913869, an assertion fix needed to build on ppc and >>> ZSeries: >>> >>> http://cr.openjdk.java.net/~andrew/6913869/webrev.01/ >>> >>> Ok to push? ?Another clean hg import from jdk7. >>> >>> >>> Approved to go back. >>> >>> >>> >>> Done: >>> >>> The last one is 6914622: >>> >>> http://cr.openjdk.java.net/~andrew/6914622/webrev.01/ >>> >>> This ensures that all flags are printed on product VMs, rather than >>> options being hidden. >>> >>> >>> Looks fine; approved to push! >>> >>> -Joe >>> >>> >>> >> >> Done: http://hg.openjdk.java.net/jdk6/jdk6/hotspot/rev/5c6d1b90dc19 >> >> I know I said that was the last one, but it seems another was pushed >> recently that I missed (presumably after I finished for the Easter >> vacation): >> >> http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/f61d795ce6de >> >> webrev: http://cr.openjdk.java.net/~andrew/6939845/webrev.01/ >> >> Ok to push? ?I know it's still a bit fresh but is #ifdef on ZERO. >> > > Approved to go back. > > -Joe > Done: http://hg.openjdk.java.net/jdk6/jdk6/hotspot/rev/dd5a19d97c1d Just waiting on Kelly's reponse now wrt. the HotSpot source/target fix. Thanks, -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From joe.darcy at oracle.com Fri Apr 9 17:32:48 2010 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 09 Apr 2010 17:32:48 -0700 Subject: Test Backports In-Reply-To: References: <17c6771e1003291310u3e1b3231i6a054fd76bc24182@mail.gmail.com> <4BBD2F69.4070609@oracle.com> <4BBE5734.30101@oracle.com> <4BBE7474.6020704@oracle.com> <4BBE793D.4050505@oracle.com> <4BBF561E.2070801@oracle.com> Message-ID: <4BBFC730.3060607@oracle.com> On 04/09/10 05:05 PM, Andrew John Hughes wrote: > On 9 April 2010 17:30, Joe Darcy wrote: > >> Andrew John Hughes wrote: >> >>> On 9 April 2010 01:47, Joe Darcy wrote: >>> >>> >>>> On 04/08/10 05:43 PM, Andrew John Hughes wrote: >>>> >>>> On 9 April 2010 01:27, Joe Darcy wrote: >>>> >>>> >>>> On 04/08/10 04:54 PM, Andrew John Hughes wrote: >>>> >>>> On 8 April 2010 23:22, Joe Darcy wrote: >>>> >>>> [snip] >>>> >>>> >>>> >>>> On another note, there is now some code requiring source level 6 in >>>> OpenJDK6 (due to use of the @Override annotation on interfaces): >>>> >>>> src/share/classes/javax/swing/plaf/synth/SynthComboBoxUI.java >>>> src/share/classes/javax/swing/plaf/synth/SynthLookAndFeel.java >>>> src/share/classes/javax/swing/plaf/synth/SynthTreeUI.java >>>> src/share/classes/sun/security/provider/certpath/OCSPResponse.java >>>> src/share/classes/sun/swing/plaf/synth/SynthFileChooserUIImpl.java >>>> >>>> >>>> There is an overly-long story behind -source 5 vs. -source 6 and >>>> @Override. >>>> The short answer is that javac in JDK 6 unconditionally applies the more >>>> liberal (and more useful) semantics for @Override. For the JDK sources, >>>> a >>>> compiler that does the same should be used. >>>> >>>> >>>> >>>> >>>> Exactly. I know ecj throws it out for 5 but not for 6 and thus >>>> building using ecj (our method for bootstrapping) falls foul of the >>>> classes above. I'm not sure if javac is allowing them through because >>>> its version of 1.5 allows it or it is simply defaulting to 6 because >>>> nothing else is specified. I had a quick look but the version is >>>> currently set in more than one place, so I think this needs a more >>>> in-depth review and I'd prefer it waits until b20 to be on the safe >>>> side. >>>> >>>> >>>> >>>> The javac command in JDK 6, both open and proprietary, will allow use of >>>> @Override on interfaces, even if "-source 5" is specified. >>>> >>>> >>>> >>>> Ok, that explains why it works for javac and fails for ecj. Is there >>>> any reason we're using 5 for a build of OpenJDK 6? The bootstrapping >>>> classes are now explicitly 5, but surely the final JDK code should be >>>> 6. >>>> >>>> >>>> Not necessarily. How rt.jar and tools.jar are compiled (and even if >>>> there >>>> is a rt.jar and tools.jar) is an implementation artifact of the JDK. One >>>> of >>>> the main benefits of target 6 over target 5 is that stackmaps are >>>> supported >>>> in the class files which allows for faster class file verification. >>>> However, files on the bootclasspath, such as rt.jar, are not verified >>>> anyway >>>> so using target 6 to compile the classes going into rt.jar would add to >>>> the >>>> size of rt.jar without conferring any speed benefit since verification is >>>> skipped anyway. >>>> >>>> >>>> >>>> Ok. Well we have 1.6 code listed above, so we either need to decide >>>> to move to 6 or revert these @Override annotations. >>>> >>>> >>>> Is there still a need to bootstrap with ecj as opposed to an earlier >>>> OpenJDK/IcedTea build? >>>> >>>> >>>> >>>> We keep it working. It makes it possible to port to new platforms as >>>> gcj can be built without an existing Java stack being present. >>>> >>>> >>>> I suppose that is easier than setting up a cross compilation environment >>>> for >>>> Java... >>>> >>>> >>>> >>>> [snip] >>>> >>>> >>>> >>>> Next one is 6909153 which turns off a number of options that fail or >>>> are inappropriate on Zero: >>>> >>>> http://cr.openjdk.java.net/~andrew/6909153/webrev.01/ >>>> >>>> Ok to push? >>>> >>>> >>>> Approved to go back. >>>> >>>> I'm not sure of the HotSpot conventions, but the removal of the opening >>>> brace on the end of line 1824 of compileBroker.cpp looks suspect to me. >>>> >>>> However, I see this was done in the JDK 7 HotSpot sources so it is more >>>> important to keep the patches the same. >>>> >>>> >>>> >>>> The if block was a one-liner, so the brace is now being used to close >>>> the new conditional instead. >>>> >>>> Right; I had to look twice to verify it was all okay :-) >>>> >>>> >>>> >>>> Me too! >>>> >>>> >>>> >>>> Not ideal, but not a bug and, as you >>>> say, it's as it is in 7. This was a clean hg import. >>>> >>>> Pushed: http://hg.openjdk.java.net/jdk6/jdk6/hotspot/rev/131295e4931b >>>> >>>> The next one is 6913869, an assertion fix needed to build on ppc and >>>> ZSeries: >>>> >>>> http://cr.openjdk.java.net/~andrew/6913869/webrev.01/ >>>> >>>> Ok to push? Another clean hg import from jdk7. >>>> >>>> >>>> Approved to go back. >>>> >>>> >>>> >>>> Done: >>>> >>>> The last one is 6914622: >>>> >>>> http://cr.openjdk.java.net/~andrew/6914622/webrev.01/ >>>> >>>> This ensures that all flags are printed on product VMs, rather than >>>> options being hidden. >>>> >>>> >>>> Looks fine; approved to push! >>>> >>>> -Joe >>>> >>>> >>>> >>>> >>> Done: http://hg.openjdk.java.net/jdk6/jdk6/hotspot/rev/5c6d1b90dc19 >>> >>> I know I said that was the last one, but it seems another was pushed >>> recently that I missed (presumably after I finished for the Easter >>> vacation): >>> >>> http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/f61d795ce6de >>> >>> webrev: http://cr.openjdk.java.net/~andrew/6939845/webrev.01/ >>> >>> Ok to push? I know it's still a bit fresh but is #ifdef on ZERO. >>> >>> >> Approved to go back. >> >> -Joe >> >> > > Done: http://hg.openjdk.java.net/jdk6/jdk6/hotspot/rev/dd5a19d97c1d > > Just waiting on Kelly's reponse now wrt. the HotSpot source/target fix. > > > Acknowledged. I'll send out a separate "last call for b19 changes" message. Thanks, -Joe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/jdk6-dev/attachments/20100409/b31934bb/attachment.html From joe.darcy at oracle.com Fri Apr 9 17:35:08 2010 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 09 Apr 2010 17:35:08 -0700 Subject: Last call for b19 changes! Message-ID: <4BBFC7BC.2050209@oracle.com> Hear ye, hear ye, OpenJDK 6 b19 nears completion! If any other fixes are desired for the build, please send requests and information about the changes to the list by Monday April 12. -Joe From kelly.ohair at oracle.com Fri Apr 9 17:48:45 2010 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Fri, 9 Apr 2010 17:48:45 -0700 Subject: Test Backports In-Reply-To: References: <17c6771e1003291310u3e1b3231i6a054fd76bc24182@mail.gmail.com> <4BBD2F69.4070609@oracle.com> <4BBE5734.30101@oracle.com> <4BBE7474.6020704@oracle.com> <4BBE793D.4050505@oracle.com> <4BBF561E.2070801@oracle.com> Message-ID: On Apr 9, 2010, at 5:05 PM, Andrew John Hughes wrote: > Just waiting on Kelly's reponse now wrt. the HotSpot source/target > fix. > Can you clarify what response you are waiting on? -kto > Thanks, > -- > Andrew :-) From ahughes at redhat.com Fri Apr 9 19:20:32 2010 From: ahughes at redhat.com (Andrew John Hughes) Date: Sat, 10 Apr 2010 03:20:32 +0100 Subject: Test Backports In-Reply-To: References: <17c6771e1003291310u3e1b3231i6a054fd76bc24182@mail.gmail.com> <4BBE5734.30101@oracle.com> <4BBE7474.6020704@oracle.com> <4BBE793D.4050505@oracle.com> <4BBF561E.2070801@oracle.com> Message-ID: On 10 April 2010 01:48, Kelly O'Hair wrote: > > On Apr 9, 2010, at 5:05 PM, Andrew John Hughes wrote: > >> Just waiting on Kelly's reponse now wrt. the HotSpot source/target fix. >> > > > Can you clarify what response you are waiting on? > Yes, sorry it's this one: http://mail.openjdk.java.net/pipermail/jdk6-dev/2010-April/001464.html It wasn't clear whether you were ok with the HotSpot change or wanted more time to review. The patch is pretty much as-is in OpenJDK7, the only difference being the version change from 6 to 5. > -kto > >> Thanks, >> -- >> Andrew :-) > > -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From kelly.ohair at oracle.com Fri Apr 9 19:40:18 2010 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Fri, 9 Apr 2010 19:40:18 -0700 Subject: Test Backports In-Reply-To: References: <17c6771e1003291310u3e1b3231i6a054fd76bc24182@mail.gmail.com> <4BBE5734.30101@oracle.com> <4BBE7474.6020704@oracle.com> <4BBE793D.4050505@oracle.com> <4BBF561E.2070801@oracle.com> Message-ID: <8351CCF8-B710-4443-96BD-C9604505CF85@oracle.com> On Apr 9, 2010, at 7:20 PM, Andrew John Hughes wrote: > On 10 April 2010 01:48, Kelly O'Hair wrote: >> >> On Apr 9, 2010, at 5:05 PM, Andrew John Hughes wrote: >> >>> Just waiting on Kelly's reponse now wrt. the HotSpot source/target >>> fix. >>> >> >> >> Can you clarify what response you are waiting on? >> > > Yes, sorry it's this one: > http://mail.openjdk.java.net/pipermail/jdk6-dev/2010-April/001464.html > > It wasn't clear whether you were ok with the HotSpot change or wanted > more time to review. The patch is pretty much as-is in OpenJDK7, the > only difference being the version change from 6 to 5. The hotspot file changes look ok, but I have no idea how the hotspot changes are being handled for openjdk6. If it's in openjdk7 already, then it's fine. -kto > >> -kto >> >>> Thanks, >>> -- >>> Andrew :-) >> >> > > > > -- > Andrew :-) > > Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > Support Free Java! > Contribute to GNU Classpath and the OpenJDK > http://www.gnu.org/software/classpath > http://openjdk.java.net > > PGP Key: 94EFD9D8 (http://subkeys.pgp.net) > Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From ahughes at redhat.com Sun Apr 11 13:35:57 2010 From: ahughes at redhat.com (ahughes at redhat.com) Date: Sun, 11 Apr 2010 20:35:57 +0000 Subject: hg: jdk6/jdk6/hotspot: 6873059: Explicitly use -source 5 -target 5 when compiling with the boot jdk Message-ID: <20100411203610.7A5BB444E4@hg.openjdk.java.net> Changeset: e77ed20ce981 Author: andrew Date: 2010-04-11 21:35 +0100 URL: http://hg.openjdk.java.net/jdk6/jdk6/hotspot/rev/e77ed20ce981 6873059: Explicitly use -source 5 -target 5 when compiling with the boot jdk Summary: The build fails if the bootstrap JDK defaults to <1.5 Reviewed-by: jcoomes, ohair ! make/linux/makefiles/jvmti.make ! make/linux/makefiles/rules.make ! make/linux/makefiles/sa.make ! make/linux/makefiles/top.make ! make/solaris/makefiles/jvmti.make ! make/solaris/makefiles/rules.make ! make/solaris/makefiles/sa.make ! make/solaris/makefiles/top.make ! make/windows/makefiles/generated.make ! make/windows/makefiles/jvmti.make ! make/windows/makefiles/rules.make ! make/windows/makefiles/sa.make ! make/windows/projectfiles/common/Makefile From ahughes at redhat.com Sun Apr 11 13:42:35 2010 From: ahughes at redhat.com (Andrew John Hughes) Date: Sun, 11 Apr 2010 21:42:35 +0100 Subject: Test Backports In-Reply-To: <8351CCF8-B710-4443-96BD-C9604505CF85@oracle.com> References: <17c6771e1003291310u3e1b3231i6a054fd76bc24182@mail.gmail.com> <4BBE7474.6020704@oracle.com> <4BBE793D.4050505@oracle.com> <4BBF561E.2070801@oracle.com> <8351CCF8-B710-4443-96BD-C9604505CF85@oracle.com> Message-ID: On 10 April 2010 03:40, Kelly O'Hair wrote: > > On Apr 9, 2010, at 7:20 PM, Andrew John Hughes wrote: > >> On 10 April 2010 01:48, Kelly O'Hair wrote: >>> >>> On Apr 9, 2010, at 5:05 PM, Andrew John Hughes wrote: >>> >>>> Just waiting on Kelly's reponse now wrt. the HotSpot source/target fix. >>>> >>> >>> >>> Can you clarify what response you are waiting on? >>> >> >> Yes, sorry it's this one: >> http://mail.openjdk.java.net/pipermail/jdk6-dev/2010-April/001464.html >> >> It wasn't clear whether you were ok with the HotSpot change or wanted >> more time to review. ?The patch is pretty much as-is in OpenJDK7, the >> only difference being the version change from 6 to 5. > > The hotspot file changes look ok, but I have no idea how the hotspot > changes are being handled for openjdk6. We regularly import from the stablisation branches: http://hg.openjdk.java.net/hsx/hsx14/master/ (OpenJDK6 b17 & b18) http://hg.openjdk.java.net/hsx/hsx16/master/ (OpenJDK6 b19) http://hg.openjdk.java.net/hsx/hsx17/master/ (OpenJDK6 b20?) The last one, hs17, includes the OpenJDK7 version of this fix. Including an OpenJDK6 version now with 1.5 source and target versions has the advantage that we won't bring in a version that requires source and target versions of 1.6 from hs17. Joe, does b20 sound appropriate for hs17? I know it's a bit soon after hs16, but the proprietary JDK6 is already moving towards this and we could do with catching up. It will be take time for such an OpenJDK6 release to roll through into an IcedTea6 release and then the distros anyway, so I'd prefer sooner rather than later. > If it's in openjdk7 already, then it's fine. I pushed the fix: http://hg.openjdk.java.net/jdk6/jdk6/hotspot/rev/e77ed20ce981 I'm done now for b19. > > -kto > >> >>> -kto >>> >>>> Thanks, >>>> -- >>>> Andrew :-) >>> >>> >> >> >> >> -- >> Andrew :-) >> >> Free Java Software Engineer >> Red Hat, Inc. (http://www.redhat.com) >> >> Support Free Java! >> Contribute to GNU Classpath and the OpenJDK >> http://www.gnu.org/software/classpath >> http://openjdk.java.net >> >> PGP Key: 94EFD9D8 (http://subkeys.pgp.net) >> Fingerprint: F8EF F1EA 401E 2E60 15FA ?7927 142C 2591 94EF D9D8 > > -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From joe.darcy at oracle.com Mon Apr 12 09:53:30 2010 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 12 Apr 2010 09:53:30 -0700 Subject: Regression test results on latest pre-b19 Message-ID: <4BC3500A.7060106@oracle.com> Hello. I did a fresh build with all the latest changes and ran the regression test suite. As before, all the HotSpot and langtools tests pass. I think these results are good enough for b19. Comparing to b18, 0: ../test_results.b18/JTreport.hotspot pass: 24 1: JTreport.hotspot pass: 62 0 1 Test --- pass compiler/5057225/Test5057225.java --- pass compiler/6378821/Test6378821.java --- pass compiler/6539464/Test.java --- pass compiler/6589834/Test_ia32.java --- pass compiler/6603011/Test.java --- pass compiler/6636138/Test1.java --- pass compiler/6636138/Test2.java --- pass compiler/6711117/Test.java --- pass compiler/6772683/InterruptedTest.java --- pass compiler/6778657/Test.java --- pass compiler/6795161/Test.java --- pass compiler/6795465/Test6795465.java --- pass compiler/6797305/Test6797305.java --- pass compiler/6799693/Test.java --- pass compiler/6800154/Test6800154.java --- pass compiler/6814842/Test6814842.java --- pass compiler/6823354/Test6823354.java --- pass compiler/6823453/Test.java --- pass compiler/6826736/Test.java --- pass compiler/6832293/Test.java --- pass compiler/6833129/Test.java --- pass compiler/6837011/Test6837011.java --- pass compiler/6837094/Test.java --- pass compiler/6843752/Test.java --- pass compiler/6849574/Test.java --- pass compiler/6851282/Test.java --- pass compiler/6852078/Test6852078.java --- pass compiler/6855164/Test.java --- pass compiler/6855215/Test6855215.java --- pass compiler/6857159/Test6857159.java --- pass compiler/6859338/Test6859338.java --- pass compiler/6860469/Test.java --- pass compiler/6863155/Test6863155.java --- pass compiler/6863420/Test.java --- pass compiler/6865031/Test.java --- pass compiler/6875866/Test.java --- pass compiler/6892265/Test.java --- pass gc/6845368/bigobj.java 38 differences 0: ../test_results.b18/JTreport.langtools pass: 1,355 1: JTreport.langtools pass: 1,359 0 1 Test --- pass tools/javac/enum/T6724345.java --- pass tools/javac/processing/6511613/clss41701.java --- pass tools/javac/processing/6634138/T6634138.java --- pass tools/javac/processing/model/util/elements/VacuousEnum.java 4 differences 0: ../test_results.b18/JTreport.jdk pass: 3,148; fail: 19; error: 2 1: JTreport.jdk pass: 3,260; fail: 28; error: 4 0 1 Test --- error java/awt/Focus/ActualFocusedWindowTest/ActualFocusedWindowBlockingTest.java --- error java/awt/Focus/ActualFocusedWindowTest/ActualFocusedWindowRetaining.java --- error java/awt/Focus/NonFocusableWindowTest/NonfocusableOwnerTest.java --- pass java/awt/Focus/NonFocusableWindowTest/Test.java --- fail java/awt/Focus/TypeAhead/TestFocusFreeze.java --- fail java/awt/Insets/WindowWithWarningTest/WindowWithWarningTest.html fail pass java/awt/event/KeyEvent/CorrectTime/CorrectTime.java --- fail java/awt/xembed/server/RunTestXEmbed.java --- pass java/nio/charset/Charset/AvailableCharsetNames.java --- pass java/nio/charset/Charset/CharsetContainmentTest.java --- fail java/nio/charset/Charset/Contains.java --- pass java/nio/charset/Charset/EmptyCharsetName.java --- pass java/nio/charset/Charset/EncDec.java --- pass java/nio/charset/Charset/IllegalCharsetName.java --- fail java/nio/charset/Charset/NIOCharsetAvailabilityTest.java --- pass java/nio/charset/Charset/NullCharsetName.java --- pass java/nio/charset/Charset/RegisteredCharsets.java --- pass java/nio/charset/Charset/default.sh --- pass java/nio/charset/CharsetDecoder/AverageMax.java --- pass java/nio/charset/CharsetDecoder/EmptyInput.java --- pass java/nio/charset/CharsetEncoder/CanEncode.java --- pass java/nio/charset/CharsetEncoder/Flush.java --- pass java/nio/charset/RemovingSunIO/SunioAlias.java --- pass java/nio/charset/RemovingSunIO/TestCOMP.java --- pass java/nio/charset/RemovingSunIO/TestUnmappableForLength.java --- pass java/nio/charset/coders/BashCache.java --- pass java/nio/charset/coders/BashStreams.java --- pass java/nio/charset/coders/Check.java --- pass java/nio/charset/coders/CheckSJISMappingProp.sh --- pass java/nio/charset/coders/Errors.java --- pass java/nio/charset/coders/FullRead.java --- pass java/nio/charset/coders/IOCoders.java --- pass java/nio/charset/coders/IsLegalReplacement.java --- pass java/nio/charset/coders/ResetISO2022JP.java --- pass java/nio/charset/coders/StreamTimeout.java --- pass java/nio/charset/coders/Surrogates.java --- pass java/nio/charset/spi/basic.sh fail pass java/rmi/transport/pinLastArguments/PinLastArguments.java --- pass java/text/Bidi/BidiBug.java --- pass java/text/Bidi/BidiEmbeddingTest.java --- pass java/text/Bidi/BidiSurrogateTest.java --- pass java/util/prefs/CommentsInXml.java --- pass java/util/prefs/ConflictInFlush.java --- pass java/util/prefs/ExportNode.java --- pass java/util/prefs/ExportSubtree.java --- pass java/util/prefs/PrefsSpi.sh --- pass java/util/prefs/RemoveReadOnlyNode.java --- pass java/util/prefs/RemoveUnregedListener.java --- pass java/util/prefs/SerializeExceptions.java --- pass javax/sound/midi/Gervill/AudioFloatFormatConverter/SkipTest.java --- pass javax/sound/midi/Gervill/ModelByteBufferWavetable/OpenStream.java --- pass javax/sound/midi/Gervill/SoftSynthesizer/GetAvailableInstruments2.java --- pass javax/sound/midi/Gervill/SoftSynthesizer/GetLoadedInstruments2.java --- pass javax/sound/midi/Gervill/SoftSynthesizer/GetPropertyInfo.java --- pass javax/sound/midi/Gervill/SoftSynthesizer/TestDisableLoadDefaultSoundbank.java --- pass javax/sound/midi/Gervill/SoftTuning/RealTimeTuning.java --- pass javax/swing/JColorChooser/Test4165217.java --- pass javax/swing/JColorChooser/Test4177735.java --- pass javax/swing/JColorChooser/Test4193384.java --- pass javax/swing/JColorChooser/Test4234761.java --- pass javax/swing/JColorChooser/Test4461329.java --- pass javax/swing/JColorChooser/Test4711996.java --- pass javax/swing/border/Test4120351.java --- pass javax/swing/border/Test4124729.java --- pass javax/swing/border/Test6461042.java --- pass sun/nio/cs/BufferUnderflowEUCTWTest.java --- pass sun/nio/cs/CheckCaseInsensitiveEncAliases.java --- pass sun/nio/cs/CheckHistoricalNames.java --- pass sun/nio/cs/ConvertSingle.java --- pass sun/nio/cs/DecoderOverflow.java --- pass sun/nio/cs/EUCJPUnderflowDecodeTest.java --- pass sun/nio/cs/EucJpLinux0212.java --- pass sun/nio/cs/EucJpLinuxDecoderRecoveryTest.java --- pass sun/nio/cs/EuroConverter.java --- pass sun/nio/cs/FindASCIICodingBugs.java --- pass sun/nio/cs/FindASCIIRangeCodingBugs.java --- pass sun/nio/cs/FindCanEncodeBugs.java --- pass sun/nio/cs/FindDecoderBugs.java --- pass sun/nio/cs/FindEncoderBugs.java --- pass sun/nio/cs/FindOneCharEncoderBugs.java --- pass sun/nio/cs/HWKatakanaMS932EncodeTest.java --- pass sun/nio/cs/ISCIITest.java --- pass sun/nio/cs/ISO8859x.java --- pass sun/nio/cs/JISAutoDetectTest.java --- pass sun/nio/cs/LatinCharReplacementTWTest.java --- pass sun/nio/cs/LeftOverSurrogate.java --- pass sun/nio/cs/MalformedSurrogates.java --- pass sun/nio/cs/NIOJISAutoDetectTest.java --- pass sun/nio/cs/ReadZero.java --- pass sun/nio/cs/SJISCanEncode.java --- pass sun/nio/cs/StreamEncoderClose.java --- pass sun/nio/cs/SurrogateGB18030Test.java --- pass sun/nio/cs/SurrogateTestEUCTW.java --- pass sun/nio/cs/SurrogateTestHKSCS.java --- fail sun/nio/cs/Test4200310.sh --- pass sun/nio/cs/Test4206507.java --- pass sun/nio/cs/Test6254467.java --- pass sun/nio/cs/Test6275027.java --- pass sun/nio/cs/TestCompoundTest.java --- pass sun/nio/cs/TestConverterDroppedCharacters.java --- pass sun/nio/cs/TestCp834_SBCS.java --- pass sun/nio/cs/TestCp93xSISO.java --- pass sun/nio/cs/TestIBMBugs.java --- pass sun/nio/cs/TestISCII91.java --- pass sun/nio/cs/TestISO2022CNDecoder.java --- pass sun/nio/cs/TestISO2022JP.java --- pass sun/nio/cs/TestISO2022JPEncoder.java --- pass sun/nio/cs/TestISO2022JPSubBytes.java --- pass sun/nio/cs/TestIllegalISO2022Esc.java --- pass sun/nio/cs/TestIllegalSJIS.java --- pass sun/nio/cs/TestJIS0208Decoder.java --- pass sun/nio/cs/TestJIS0212Decoder.java --- pass sun/nio/cs/TestMS5022X.java --- pass sun/nio/cs/TestMiscEUC_JP.java --- fail sun/nio/cs/TestSJIS0213.java --- pass sun/nio/cs/TestTrailingEscapesISO2022JP.java --- pass sun/nio/cs/TestUTF8BOM.java --- pass sun/nio/cs/TestUTF_16.java --- pass sun/nio/cs/TestUni2HKSCS.java --- pass sun/nio/cs/TestX11JIS0201.java --- pass sun/nio/cs/UkrainianIsNotRussian.java --- pass sun/nio/cs/ZeroedByteArrayEUCTWTest.java pass --- sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/InvalidateServerSessionRenegotiate.java pass --- sun/security/ssl/javax/net/ssl/NewAPIs/JSSERenegotiate.java pass --- sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/CheckStatus.java pass --- sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/ConnectionTest.java pass --- sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/NoAuthClientAuth.java error pass sun/security/ssl/javax/net/ssl/NewAPIs/SessionTimeOutTests.java --- fail sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/DNSIdentities.java --- pass sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/HttpsCreateSockTest.java --- pass sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/HttpsSocketFacTest.java --- pass sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/IPAddressDNSIdentities.java --- fail sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/IPAddressIPIdentities.java --- fail sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/IPIdentities.java --- fail sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/Identities.java --- pass sun/security/util/Oid/BerOid.java 136 differences -Joe From kalli at midverk.is Mon Apr 12 12:04:02 2010 From: kalli at midverk.is (Karl Helgason) Date: Mon, 12 Apr 2010 19:04:02 +0000 Subject: [Request for review and bugid] Gervill - ModelStandardIndexedDirector fails on invalid ranges. Message-ID: <36EC82E93EB0AD40A4301DAD654323860146CD9D8900@mail.midverk.is> Hi, I need code review and bugid for the fix: http://cr.openjdk.java.net/~kalli/gervill-update2/webrev.01/ This fixes two issues: * ModelStandardIndexedDirector fails on invalid ranges. This fix is very IMPORTANT! Some songs+soundfonts combinations fails playing without this fix. * Program change with 16-bit banks doesn't work correctly. This is a very minor fix. JTreg tests have been created for both those issues. I am also working on another fix (not included in this fix) * SoftAbstractResampler doesn't work correctly when using interpolation algorithms that requires large padding like sinc interpolation. regards, Karl From ahughes at redhat.com Mon Apr 12 12:46:06 2010 From: ahughes at redhat.com (Andrew John Hughes) Date: Mon, 12 Apr 2010 20:46:06 +0100 Subject: [Request for review and bugid] Gervill - ModelStandardIndexedDirector fails on invalid ranges. In-Reply-To: <36EC82E93EB0AD40A4301DAD654323860146CD9D8900@mail.midverk.is> References: <36EC82E93EB0AD40A4301DAD654323860146CD9D8900@mail.midverk.is> Message-ID: On 12 April 2010 20:04, Karl Helgason wrote: > Hi, > > I need code review and bugid for the fix: > ?http://cr.openjdk.java.net/~kalli/gervill-update2/webrev.01/ > > This fixes two issues: > > ?* ModelStandardIndexedDirector fails on invalid ranges. > ? This fix is very IMPORTANT! > ? Some songs+soundfonts combinations fails playing without this fix. > > ?* Program change with 16-bit banks doesn't work correctly. > ? ?This is a very minor fix. > > JTreg tests have been created for both those issues. > > I am also working on another fix (not included in this fix) > > ?* SoftAbstractResampler doesn't work correctly > ? ?when using interpolation algorithms that requires > ? ?large padding like sinc interpolation. > > regards, > Karl > > > > A slightly off-topic point, but it would be good if this fix had a more descriptive summary than the last when pushed: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/74e449a8c951 Are these being pushed to JDK7 as well? -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From ahughes at redhat.com Mon Apr 12 12:47:12 2010 From: ahughes at redhat.com (Andrew John Hughes) Date: Mon, 12 Apr 2010 20:47:12 +0100 Subject: Regression test results on latest pre-b19 In-Reply-To: <4BC3500A.7060106@oracle.com> References: <4BC3500A.7060106@oracle.com> Message-ID: On 12 April 2010 17:53, Joe Darcy wrote: > Hello. > > I did a fresh build with all the latest changes and ran the regression test > suite. ?As before, all the HotSpot and langtools tests pass. ?I think these > results are good enough for b19. > > Comparing to b18, > > 0: ../test_results.b18/JTreport.hotspot ?pass: 24 > 1: JTreport.hotspot ?pass: 62 > > 0 ? ? ?1 ? ? ?Test > --- ? ?pass ? compiler/5057225/Test5057225.java > --- ? ?pass ? compiler/6378821/Test6378821.java > --- ? ?pass ? compiler/6539464/Test.java > --- ? ?pass ? compiler/6589834/Test_ia32.java > --- ? ?pass ? compiler/6603011/Test.java > --- ? ?pass ? compiler/6636138/Test1.java > --- ? ?pass ? compiler/6636138/Test2.java > --- ? ?pass ? compiler/6711117/Test.java > --- ? ?pass ? compiler/6772683/InterruptedTest.java > --- ? ?pass ? compiler/6778657/Test.java > --- ? ?pass ? compiler/6795161/Test.java > --- ? ?pass ? compiler/6795465/Test6795465.java > --- ? ?pass ? compiler/6797305/Test6797305.java > --- ? ?pass ? compiler/6799693/Test.java > --- ? ?pass ? compiler/6800154/Test6800154.java > --- ? ?pass ? compiler/6814842/Test6814842.java > --- ? ?pass ? compiler/6823354/Test6823354.java > --- ? ?pass ? compiler/6823453/Test.java > --- ? ?pass ? compiler/6826736/Test.java > --- ? ?pass ? compiler/6832293/Test.java > --- ? ?pass ? compiler/6833129/Test.java > --- ? ?pass ? compiler/6837011/Test6837011.java > --- ? ?pass ? compiler/6837094/Test.java > --- ? ?pass ? compiler/6843752/Test.java > --- ? ?pass ? compiler/6849574/Test.java > --- ? ?pass ? compiler/6851282/Test.java > --- ? ?pass ? compiler/6852078/Test6852078.java > --- ? ?pass ? compiler/6855164/Test.java > --- ? ?pass ? compiler/6855215/Test6855215.java > --- ? ?pass ? compiler/6857159/Test6857159.java > --- ? ?pass ? compiler/6859338/Test6859338.java > --- ? ?pass ? compiler/6860469/Test.java > --- ? ?pass ? compiler/6863155/Test6863155.java > --- ? ?pass ? compiler/6863420/Test.java > --- ? ?pass ? compiler/6865031/Test.java > --- ? ?pass ? compiler/6875866/Test.java > --- ? ?pass ? compiler/6892265/Test.java > --- ? ?pass ? gc/6845368/bigobj.java > > 38 differences > > > 0: ../test_results.b18/JTreport.langtools ?pass: 1,355 > 1: JTreport.langtools ?pass: 1,359 > > 0 ? ? ?1 ? ? ?Test > --- ? ?pass ? tools/javac/enum/T6724345.java > --- ? ?pass ? tools/javac/processing/6511613/clss41701.java > --- ? ?pass ? tools/javac/processing/6634138/T6634138.java > --- ? ?pass ? tools/javac/processing/model/util/elements/VacuousEnum.java > > 4 differences > > > 0: ../test_results.b18/JTreport.jdk ?pass: 3,148; fail: 19; error: 2 > 1: JTreport.jdk ?pass: 3,260; fail: 28; error: 4 > > 0 ? ? ?1 ? ? ?Test > --- ? ?error > ?java/awt/Focus/ActualFocusedWindowTest/ActualFocusedWindowBlockingTest.java > --- ? ?error > ?java/awt/Focus/ActualFocusedWindowTest/ActualFocusedWindowRetaining.java > --- ? ?error > ?java/awt/Focus/NonFocusableWindowTest/NonfocusableOwnerTest.java > --- ? ?pass ? java/awt/Focus/NonFocusableWindowTest/Test.java > --- ? ?fail ? java/awt/Focus/TypeAhead/TestFocusFreeze.java > --- ? ?fail > java/awt/Insets/WindowWithWarningTest/WindowWithWarningTest.html > fail ? pass ? java/awt/event/KeyEvent/CorrectTime/CorrectTime.java > --- ? ?fail ? java/awt/xembed/server/RunTestXEmbed.java > --- ? ?pass ? java/nio/charset/Charset/AvailableCharsetNames.java > --- ? ?pass ? java/nio/charset/Charset/CharsetContainmentTest.java > --- ? ?fail ? java/nio/charset/Charset/Contains.java > --- ? ?pass ? java/nio/charset/Charset/EmptyCharsetName.java > --- ? ?pass ? java/nio/charset/Charset/EncDec.java > --- ? ?pass ? java/nio/charset/Charset/IllegalCharsetName.java > --- ? ?fail ? java/nio/charset/Charset/NIOCharsetAvailabilityTest.java > --- ? ?pass ? java/nio/charset/Charset/NullCharsetName.java > --- ? ?pass ? java/nio/charset/Charset/RegisteredCharsets.java > --- ? ?pass ? java/nio/charset/Charset/default.sh > --- ? ?pass ? java/nio/charset/CharsetDecoder/AverageMax.java > --- ? ?pass ? java/nio/charset/CharsetDecoder/EmptyInput.java > --- ? ?pass ? java/nio/charset/CharsetEncoder/CanEncode.java > --- ? ?pass ? java/nio/charset/CharsetEncoder/Flush.java > --- ? ?pass ? java/nio/charset/RemovingSunIO/SunioAlias.java > --- ? ?pass ? java/nio/charset/RemovingSunIO/TestCOMP.java > --- ? ?pass ? java/nio/charset/RemovingSunIO/TestUnmappableForLength.java > --- ? ?pass ? java/nio/charset/coders/BashCache.java > --- ? ?pass ? java/nio/charset/coders/BashStreams.java > --- ? ?pass ? java/nio/charset/coders/Check.java > --- ? ?pass ? java/nio/charset/coders/CheckSJISMappingProp.sh > --- ? ?pass ? java/nio/charset/coders/Errors.java > --- ? ?pass ? java/nio/charset/coders/FullRead.java > --- ? ?pass ? java/nio/charset/coders/IOCoders.java > --- ? ?pass ? java/nio/charset/coders/IsLegalReplacement.java > --- ? ?pass ? java/nio/charset/coders/ResetISO2022JP.java > --- ? ?pass ? java/nio/charset/coders/StreamTimeout.java > --- ? ?pass ? java/nio/charset/coders/Surrogates.java > --- ? ?pass ? java/nio/charset/spi/basic.sh > fail ? pass ? java/rmi/transport/pinLastArguments/PinLastArguments.java > --- ? ?pass ? java/text/Bidi/BidiBug.java > --- ? ?pass ? java/text/Bidi/BidiEmbeddingTest.java > --- ? ?pass ? java/text/Bidi/BidiSurrogateTest.java > --- ? ?pass ? java/util/prefs/CommentsInXml.java > --- ? ?pass ? java/util/prefs/ConflictInFlush.java > --- ? ?pass ? java/util/prefs/ExportNode.java > --- ? ?pass ? java/util/prefs/ExportSubtree.java > --- ? ?pass ? java/util/prefs/PrefsSpi.sh > --- ? ?pass ? java/util/prefs/RemoveReadOnlyNode.java > --- ? ?pass ? java/util/prefs/RemoveUnregedListener.java > --- ? ?pass ? java/util/prefs/SerializeExceptions.java > --- ? ?pass > javax/sound/midi/Gervill/AudioFloatFormatConverter/SkipTest.java > --- ? ?pass > javax/sound/midi/Gervill/ModelByteBufferWavetable/OpenStream.java > --- ? ?pass > javax/sound/midi/Gervill/SoftSynthesizer/GetAvailableInstruments2.java > --- ? ?pass > javax/sound/midi/Gervill/SoftSynthesizer/GetLoadedInstruments2.java > --- ? ?pass ? javax/sound/midi/Gervill/SoftSynthesizer/GetPropertyInfo.java > --- ? ?pass > javax/sound/midi/Gervill/SoftSynthesizer/TestDisableLoadDefaultSoundbank.java > --- ? ?pass ? javax/sound/midi/Gervill/SoftTuning/RealTimeTuning.java > --- ? ?pass ? javax/swing/JColorChooser/Test4165217.java > --- ? ?pass ? javax/swing/JColorChooser/Test4177735.java > --- ? ?pass ? javax/swing/JColorChooser/Test4193384.java > --- ? ?pass ? javax/swing/JColorChooser/Test4234761.java > --- ? ?pass ? javax/swing/JColorChooser/Test4461329.java > --- ? ?pass ? javax/swing/JColorChooser/Test4711996.java > --- ? ?pass ? javax/swing/border/Test4120351.java > --- ? ?pass ? javax/swing/border/Test4124729.java > --- ? ?pass ? javax/swing/border/Test6461042.java > --- ? ?pass ? sun/nio/cs/BufferUnderflowEUCTWTest.java > --- ? ?pass ? sun/nio/cs/CheckCaseInsensitiveEncAliases.java > --- ? ?pass ? sun/nio/cs/CheckHistoricalNames.java > --- ? ?pass ? sun/nio/cs/ConvertSingle.java > --- ? ?pass ? sun/nio/cs/DecoderOverflow.java > --- ? ?pass ? sun/nio/cs/EUCJPUnderflowDecodeTest.java > --- ? ?pass ? sun/nio/cs/EucJpLinux0212.java > --- ? ?pass ? sun/nio/cs/EucJpLinuxDecoderRecoveryTest.java > --- ? ?pass ? sun/nio/cs/EuroConverter.java > --- ? ?pass ? sun/nio/cs/FindASCIICodingBugs.java > --- ? ?pass ? sun/nio/cs/FindASCIIRangeCodingBugs.java > --- ? ?pass ? sun/nio/cs/FindCanEncodeBugs.java > --- ? ?pass ? sun/nio/cs/FindDecoderBugs.java > --- ? ?pass ? sun/nio/cs/FindEncoderBugs.java > --- ? ?pass ? sun/nio/cs/FindOneCharEncoderBugs.java > --- ? ?pass ? sun/nio/cs/HWKatakanaMS932EncodeTest.java > --- ? ?pass ? sun/nio/cs/ISCIITest.java > --- ? ?pass ? sun/nio/cs/ISO8859x.java > --- ? ?pass ? sun/nio/cs/JISAutoDetectTest.java > --- ? ?pass ? sun/nio/cs/LatinCharReplacementTWTest.java > --- ? ?pass ? sun/nio/cs/LeftOverSurrogate.java > --- ? ?pass ? sun/nio/cs/MalformedSurrogates.java > --- ? ?pass ? sun/nio/cs/NIOJISAutoDetectTest.java > --- ? ?pass ? sun/nio/cs/ReadZero.java > --- ? ?pass ? sun/nio/cs/SJISCanEncode.java > --- ? ?pass ? sun/nio/cs/StreamEncoderClose.java > --- ? ?pass ? sun/nio/cs/SurrogateGB18030Test.java > --- ? ?pass ? sun/nio/cs/SurrogateTestEUCTW.java > --- ? ?pass ? sun/nio/cs/SurrogateTestHKSCS.java > --- ? ?fail ? sun/nio/cs/Test4200310.sh > --- ? ?pass ? sun/nio/cs/Test4206507.java > --- ? ?pass ? sun/nio/cs/Test6254467.java > --- ? ?pass ? sun/nio/cs/Test6275027.java > --- ? ?pass ? sun/nio/cs/TestCompoundTest.java > --- ? ?pass ? sun/nio/cs/TestConverterDroppedCharacters.java > --- ? ?pass ? sun/nio/cs/TestCp834_SBCS.java > --- ? ?pass ? sun/nio/cs/TestCp93xSISO.java > --- ? ?pass ? sun/nio/cs/TestIBMBugs.java > --- ? ?pass ? sun/nio/cs/TestISCII91.java > --- ? ?pass ? sun/nio/cs/TestISO2022CNDecoder.java > --- ? ?pass ? sun/nio/cs/TestISO2022JP.java > --- ? ?pass ? sun/nio/cs/TestISO2022JPEncoder.java > --- ? ?pass ? sun/nio/cs/TestISO2022JPSubBytes.java > --- ? ?pass ? sun/nio/cs/TestIllegalISO2022Esc.java > --- ? ?pass ? sun/nio/cs/TestIllegalSJIS.java > --- ? ?pass ? sun/nio/cs/TestJIS0208Decoder.java > --- ? ?pass ? sun/nio/cs/TestJIS0212Decoder.java > --- ? ?pass ? sun/nio/cs/TestMS5022X.java > --- ? ?pass ? sun/nio/cs/TestMiscEUC_JP.java > --- ? ?fail ? sun/nio/cs/TestSJIS0213.java > --- ? ?pass ? sun/nio/cs/TestTrailingEscapesISO2022JP.java > --- ? ?pass ? sun/nio/cs/TestUTF8BOM.java > --- ? ?pass ? sun/nio/cs/TestUTF_16.java > --- ? ?pass ? sun/nio/cs/TestUni2HKSCS.java > --- ? ?pass ? sun/nio/cs/TestX11JIS0201.java > --- ? ?pass ? sun/nio/cs/UkrainianIsNotRussian.java > --- ? ?pass ? sun/nio/cs/ZeroedByteArrayEUCTWTest.java > pass ? --- > ?sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/InvalidateServerSessionRenegotiate.java > pass ? --- ? ?sun/security/ssl/javax/net/ssl/NewAPIs/JSSERenegotiate.java > pass ? --- > ?sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/CheckStatus.java > pass ? --- > ?sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/ConnectionTest.java > pass ? --- > ?sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/NoAuthClientAuth.java > error ?pass > sun/security/ssl/javax/net/ssl/NewAPIs/SessionTimeOutTests.java > --- ? ?fail > sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/DNSIdentities.java > --- ? ?pass > sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/HttpsCreateSockTest.java > --- ? ?pass > sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/HttpsSocketFacTest.java > --- ? ?pass > sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/IPAddressDNSIdentities.java > --- ? ?fail > sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/IPAddressIPIdentities.java > --- ? ?fail > sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/IPIdentities.java > --- ? ?fail > sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/Identities.java > --- ? ?pass ? sun/security/util/Oid/BerOid.java > > 136 differences > > -Joe > Looks good to me. I don't see any regressions (pass-->fail). -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From joe.darcy at oracle.com Mon Apr 12 13:02:51 2010 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 12 Apr 2010 13:02:51 -0700 Subject: [Request for review and bugid] Gervill - ModelStandardIndexedDirector fails on invalid ranges. In-Reply-To: <36EC82E93EB0AD40A4301DAD654323860146CD9D8900@mail.midverk.is> References: <36EC82E93EB0AD40A4301DAD654323860146CD9D8900@mail.midverk.is> Message-ID: <4BC37C6B.2050009@oracle.com> Hello. Karl Helgason wrote: > Hi, > > I need code review and bugid for the fix: > http://cr.openjdk.java.net/~kalli/gervill-update2/webrev.01/ > > This fixes two issues: > > * ModelStandardIndexedDirector fails on invalid ranges. > This fix is very IMPORTANT! > Some songs+soundfonts combinations fails playing without this fix. > > * Program change with 16-bit banks doesn't work correctly. > This is a very minor fix. > I've created bug 6943053 "Gervill: failures on invalid ranges and 16-bit banks" for these issues. Alexey will need to do the technical code review. Since the fix is near at hand, I'm willing to hold OpenJDK 6 b19 for a few days until this can get in. > JTreg tests have been created for both those issues. > > I am also working on another fix (not included in this fix) > > * SoftAbstractResampler doesn't work correctly > when using interpolation algorithms that requires > large padding like sinc interpolation. > Unless I hear arguments otherwise, I do not plan to hold b19 for this fix; it can go into b20 after the fix is ready. -Joe From joe.darcy at oracle.com Mon Apr 12 13:07:45 2010 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 12 Apr 2010 13:07:45 -0700 Subject: [Request for review and bugid] Gervill - ModelStandardIndexedDirector fails on invalid ranges. In-Reply-To: References: <36EC82E93EB0AD40A4301DAD654323860146CD9D8900@mail.midverk.is> Message-ID: <4BC37D91.40201@oracle.com> Andrew John Hughes wrote: > On 12 April 2010 20:04, Karl Helgason wrote: > >> Hi, >> >> I need code review and bugid for the fix: >> http://cr.openjdk.java.net/~kalli/gervill-update2/webrev.01/ >> >> This fixes two issues: >> >> * ModelStandardIndexedDirector fails on invalid ranges. >> This fix is very IMPORTANT! >> Some songs+soundfonts combinations fails playing without this fix. >> >> * Program change with 16-bit banks doesn't work correctly. >> This is a very minor fix. >> >> JTreg tests have been created for both those issues. >> >> I am also working on another fix (not included in this fix) >> >> * SoftAbstractResampler doesn't work correctly >> when using interpolation algorithms that requires >> large padding like sinc interpolation. >> >> regards, >> Karl >> >> >> >> >> > > A slightly off-topic point, but it would be good if this fix had a > more descriptive summary than the last when pushed: > > http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/74e449a8c951 > > Are these being pushed to JDK7 as well? > These Gervill fixes should also be pushed to JDK 7. -Joe From ahughes at redhat.com Mon Apr 12 13:11:01 2010 From: ahughes at redhat.com (Andrew John Hughes) Date: Mon, 12 Apr 2010 21:11:01 +0100 Subject: [Request for review and bugid] Gervill - ModelStandardIndexedDirector fails on invalid ranges. In-Reply-To: <4BC37D91.40201@oracle.com> References: <36EC82E93EB0AD40A4301DAD654323860146CD9D8900@mail.midverk.is> <4BC37D91.40201@oracle.com> Message-ID: On 12 April 2010 21:07, Joe Darcy wrote: > Andrew John Hughes wrote: >> >> On 12 April 2010 20:04, Karl Helgason wrote: >> >>> >>> Hi, >>> >>> I need code review and bugid for the fix: >>> ?http://cr.openjdk.java.net/~kalli/gervill-update2/webrev.01/ >>> >>> This fixes two issues: >>> >>> ?* ModelStandardIndexedDirector fails on invalid ranges. >>> ?This fix is very IMPORTANT! >>> ?Some songs+soundfonts combinations fails playing without this fix. >>> >>> ?* Program change with 16-bit banks doesn't work correctly. >>> ? This is a very minor fix. >>> >>> JTreg tests have been created for both those issues. >>> >>> I am also working on another fix (not included in this fix) >>> >>> ?* SoftAbstractResampler doesn't work correctly >>> ? when using interpolation algorithms that requires >>> ? large padding like sinc interpolation. >>> >>> regards, >>> Karl >>> >>> >>> >>> >>> >> >> A slightly off-topic point, but it would be good if this fix had a >> more descriptive summary than the last when pushed: >> >> http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/74e449a8c951 >> >> Are these being pushed to JDK7 as well? >> > > These Gervill fixes should also be pushed to JDK 7. > Which tree? I can forwardport the last one now. > -Joe > -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From joe.darcy at oracle.com Mon Apr 12 13:09:55 2010 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 12 Apr 2010 13:09:55 -0700 Subject: Regression test results on latest pre-b19 In-Reply-To: References: <4BC3500A.7060106@oracle.com> Message-ID: <4BC37E13.8030104@oracle.com> Andrew John Hughes wrote: > On 12 April 2010 17:53, Joe Darcy wrote: > >> Hello. >> >> I did a fresh build with all the latest changes and ran the regression test >> suite. As before, all the HotSpot and langtools tests pass. I think these >> results are good enough for b19. >> >> Comparing to b18, >> >> 0: ../test_results.b18/JTreport.hotspot pass: 24 >> 1: JTreport.hotspot pass: 62 >> >> 0 1 Test >> --- pass compiler/5057225/Test5057225.java >> --- pass compiler/6378821/Test6378821.java >> --- pass compiler/6539464/Test.java >> --- pass compiler/6589834/Test_ia32.java >> --- pass compiler/6603011/Test.java >> --- pass compiler/6636138/Test1.java >> --- pass compiler/6636138/Test2.java >> --- pass compiler/6711117/Test.java >> --- pass compiler/6772683/InterruptedTest.java >> --- pass compiler/6778657/Test.java >> --- pass compiler/6795161/Test.java >> --- pass compiler/6795465/Test6795465.java >> --- pass compiler/6797305/Test6797305.java >> --- pass compiler/6799693/Test.java >> --- pass compiler/6800154/Test6800154.java >> --- pass compiler/6814842/Test6814842.java >> --- pass compiler/6823354/Test6823354.java >> --- pass compiler/6823453/Test.java >> --- pass compiler/6826736/Test.java >> --- pass compiler/6832293/Test.java >> --- pass compiler/6833129/Test.java >> --- pass compiler/6837011/Test6837011.java >> --- pass compiler/6837094/Test.java >> --- pass compiler/6843752/Test.java >> --- pass compiler/6849574/Test.java >> --- pass compiler/6851282/Test.java >> --- pass compiler/6852078/Test6852078.java >> --- pass compiler/6855164/Test.java >> --- pass compiler/6855215/Test6855215.java >> --- pass compiler/6857159/Test6857159.java >> --- pass compiler/6859338/Test6859338.java >> --- pass compiler/6860469/Test.java >> --- pass compiler/6863155/Test6863155.java >> --- pass compiler/6863420/Test.java >> --- pass compiler/6865031/Test.java >> --- pass compiler/6875866/Test.java >> --- pass compiler/6892265/Test.java >> --- pass gc/6845368/bigobj.java >> >> 38 differences >> >> >> 0: ../test_results.b18/JTreport.langtools pass: 1,355 >> 1: JTreport.langtools pass: 1,359 >> >> 0 1 Test >> --- pass tools/javac/enum/T6724345.java >> --- pass tools/javac/processing/6511613/clss41701.java >> --- pass tools/javac/processing/6634138/T6634138.java >> --- pass tools/javac/processing/model/util/elements/VacuousEnum.java >> >> 4 differences >> >> >> 0: ../test_results.b18/JTreport.jdk pass: 3,148; fail: 19; error: 2 >> 1: JTreport.jdk pass: 3,260; fail: 28; error: 4 >> >> 0 1 Test >> --- error >> java/awt/Focus/ActualFocusedWindowTest/ActualFocusedWindowBlockingTest.java >> --- error >> java/awt/Focus/ActualFocusedWindowTest/ActualFocusedWindowRetaining.java >> --- error >> java/awt/Focus/NonFocusableWindowTest/NonfocusableOwnerTest.java >> --- pass java/awt/Focus/NonFocusableWindowTest/Test.java >> --- fail java/awt/Focus/TypeAhead/TestFocusFreeze.java >> --- fail >> java/awt/Insets/WindowWithWarningTest/WindowWithWarningTest.html >> fail pass java/awt/event/KeyEvent/CorrectTime/CorrectTime.java >> --- fail java/awt/xembed/server/RunTestXEmbed.java >> --- pass java/nio/charset/Charset/AvailableCharsetNames.java >> --- pass java/nio/charset/Charset/CharsetContainmentTest.java >> --- fail java/nio/charset/Charset/Contains.java >> --- pass java/nio/charset/Charset/EmptyCharsetName.java >> --- pass java/nio/charset/Charset/EncDec.java >> --- pass java/nio/charset/Charset/IllegalCharsetName.java >> --- fail java/nio/charset/Charset/NIOCharsetAvailabilityTest.java >> --- pass java/nio/charset/Charset/NullCharsetName.java >> --- pass java/nio/charset/Charset/RegisteredCharsets.java >> --- pass java/nio/charset/Charset/default.sh >> --- pass java/nio/charset/CharsetDecoder/AverageMax.java >> --- pass java/nio/charset/CharsetDecoder/EmptyInput.java >> --- pass java/nio/charset/CharsetEncoder/CanEncode.java >> --- pass java/nio/charset/CharsetEncoder/Flush.java >> --- pass java/nio/charset/RemovingSunIO/SunioAlias.java >> --- pass java/nio/charset/RemovingSunIO/TestCOMP.java >> --- pass java/nio/charset/RemovingSunIO/TestUnmappableForLength.java >> --- pass java/nio/charset/coders/BashCache.java >> --- pass java/nio/charset/coders/BashStreams.java >> --- pass java/nio/charset/coders/Check.java >> --- pass java/nio/charset/coders/CheckSJISMappingProp.sh >> --- pass java/nio/charset/coders/Errors.java >> --- pass java/nio/charset/coders/FullRead.java >> --- pass java/nio/charset/coders/IOCoders.java >> --- pass java/nio/charset/coders/IsLegalReplacement.java >> --- pass java/nio/charset/coders/ResetISO2022JP.java >> --- pass java/nio/charset/coders/StreamTimeout.java >> --- pass java/nio/charset/coders/Surrogates.java >> --- pass java/nio/charset/spi/basic.sh >> fail pass java/rmi/transport/pinLastArguments/PinLastArguments.java >> --- pass java/text/Bidi/BidiBug.java >> --- pass java/text/Bidi/BidiEmbeddingTest.java >> --- pass java/text/Bidi/BidiSurrogateTest.java >> --- pass java/util/prefs/CommentsInXml.java >> --- pass java/util/prefs/ConflictInFlush.java >> --- pass java/util/prefs/ExportNode.java >> --- pass java/util/prefs/ExportSubtree.java >> --- pass java/util/prefs/PrefsSpi.sh >> --- pass java/util/prefs/RemoveReadOnlyNode.java >> --- pass java/util/prefs/RemoveUnregedListener.java >> --- pass java/util/prefs/SerializeExceptions.java >> --- pass >> javax/sound/midi/Gervill/AudioFloatFormatConverter/SkipTest.java >> --- pass >> javax/sound/midi/Gervill/ModelByteBufferWavetable/OpenStream.java >> --- pass >> javax/sound/midi/Gervill/SoftSynthesizer/GetAvailableInstruments2.java >> --- pass >> javax/sound/midi/Gervill/SoftSynthesizer/GetLoadedInstruments2.java >> --- pass javax/sound/midi/Gervill/SoftSynthesizer/GetPropertyInfo.java >> --- pass >> javax/sound/midi/Gervill/SoftSynthesizer/TestDisableLoadDefaultSoundbank.java >> --- pass javax/sound/midi/Gervill/SoftTuning/RealTimeTuning.java >> --- pass javax/swing/JColorChooser/Test4165217.java >> --- pass javax/swing/JColorChooser/Test4177735.java >> --- pass javax/swing/JColorChooser/Test4193384.java >> --- pass javax/swing/JColorChooser/Test4234761.java >> --- pass javax/swing/JColorChooser/Test4461329.java >> --- pass javax/swing/JColorChooser/Test4711996.java >> --- pass javax/swing/border/Test4120351.java >> --- pass javax/swing/border/Test4124729.java >> --- pass javax/swing/border/Test6461042.java >> --- pass sun/nio/cs/BufferUnderflowEUCTWTest.java >> --- pass sun/nio/cs/CheckCaseInsensitiveEncAliases.java >> --- pass sun/nio/cs/CheckHistoricalNames.java >> --- pass sun/nio/cs/ConvertSingle.java >> --- pass sun/nio/cs/DecoderOverflow.java >> --- pass sun/nio/cs/EUCJPUnderflowDecodeTest.java >> --- pass sun/nio/cs/EucJpLinux0212.java >> --- pass sun/nio/cs/EucJpLinuxDecoderRecoveryTest.java >> --- pass sun/nio/cs/EuroConverter.java >> --- pass sun/nio/cs/FindASCIICodingBugs.java >> --- pass sun/nio/cs/FindASCIIRangeCodingBugs.java >> --- pass sun/nio/cs/FindCanEncodeBugs.java >> --- pass sun/nio/cs/FindDecoderBugs.java >> --- pass sun/nio/cs/FindEncoderBugs.java >> --- pass sun/nio/cs/FindOneCharEncoderBugs.java >> --- pass sun/nio/cs/HWKatakanaMS932EncodeTest.java >> --- pass sun/nio/cs/ISCIITest.java >> --- pass sun/nio/cs/ISO8859x.java >> --- pass sun/nio/cs/JISAutoDetectTest.java >> --- pass sun/nio/cs/LatinCharReplacementTWTest.java >> --- pass sun/nio/cs/LeftOverSurrogate.java >> --- pass sun/nio/cs/MalformedSurrogates.java >> --- pass sun/nio/cs/NIOJISAutoDetectTest.java >> --- pass sun/nio/cs/ReadZero.java >> --- pass sun/nio/cs/SJISCanEncode.java >> --- pass sun/nio/cs/StreamEncoderClose.java >> --- pass sun/nio/cs/SurrogateGB18030Test.java >> --- pass sun/nio/cs/SurrogateTestEUCTW.java >> --- pass sun/nio/cs/SurrogateTestHKSCS.java >> --- fail sun/nio/cs/Test4200310.sh >> --- pass sun/nio/cs/Test4206507.java >> --- pass sun/nio/cs/Test6254467.java >> --- pass sun/nio/cs/Test6275027.java >> --- pass sun/nio/cs/TestCompoundTest.java >> --- pass sun/nio/cs/TestConverterDroppedCharacters.java >> --- pass sun/nio/cs/TestCp834_SBCS.java >> --- pass sun/nio/cs/TestCp93xSISO.java >> --- pass sun/nio/cs/TestIBMBugs.java >> --- pass sun/nio/cs/TestISCII91.java >> --- pass sun/nio/cs/TestISO2022CNDecoder.java >> --- pass sun/nio/cs/TestISO2022JP.java >> --- pass sun/nio/cs/TestISO2022JPEncoder.java >> --- pass sun/nio/cs/TestISO2022JPSubBytes.java >> --- pass sun/nio/cs/TestIllegalISO2022Esc.java >> --- pass sun/nio/cs/TestIllegalSJIS.java >> --- pass sun/nio/cs/TestJIS0208Decoder.java >> --- pass sun/nio/cs/TestJIS0212Decoder.java >> --- pass sun/nio/cs/TestMS5022X.java >> --- pass sun/nio/cs/TestMiscEUC_JP.java >> --- fail sun/nio/cs/TestSJIS0213.java >> --- pass sun/nio/cs/TestTrailingEscapesISO2022JP.java >> --- pass sun/nio/cs/TestUTF8BOM.java >> --- pass sun/nio/cs/TestUTF_16.java >> --- pass sun/nio/cs/TestUni2HKSCS.java >> --- pass sun/nio/cs/TestX11JIS0201.java >> --- pass sun/nio/cs/UkrainianIsNotRussian.java >> --- pass sun/nio/cs/ZeroedByteArrayEUCTWTest.java >> pass --- >> sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/InvalidateServerSessionRenegotiate.java >> pass --- sun/security/ssl/javax/net/ssl/NewAPIs/JSSERenegotiate.java >> pass --- >> sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/CheckStatus.java >> pass --- >> sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/ConnectionTest.java >> pass --- >> sun/security/ssl/javax/net/ssl/NewAPIs/SSLEngine/NoAuthClientAuth.java >> error pass >> sun/security/ssl/javax/net/ssl/NewAPIs/SessionTimeOutTests.java >> --- fail >> sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/DNSIdentities.java >> --- pass >> sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/HttpsCreateSockTest.java >> --- pass >> sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/HttpsSocketFacTest.java >> --- pass >> sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/IPAddressDNSIdentities.java >> --- fail >> sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/IPAddressIPIdentities.java >> --- fail >> sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/IPIdentities.java >> --- fail >> sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/Identities.java >> --- pass sun/security/util/Oid/BerOid.java >> >> 136 differences >> >> -Joe >> >> > > Looks good to me. I don't see any regressions (pass-->fail). > And there are lots more passing tests :-) Other than the Gervill fix under review, I don't have any other outstanding changes to get into b19. Assuming the Gervill fix goes back soon and the test results are consistent, I'll label the repos post-fix as b19. -Joe From joe.darcy at oracle.com Mon Apr 12 13:13:06 2010 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 12 Apr 2010 13:13:06 -0700 Subject: [Request for review and bugid] Gervill - ModelStandardIndexedDirector fails on invalid ranges. In-Reply-To: References: <36EC82E93EB0AD40A4301DAD654323860146CD9D8900@mail.midverk.is> <4BC37D91.40201@oracle.com> Message-ID: <4BC37ED2.4080406@oracle.com> Andrew John Hughes wrote: > On 12 April 2010 21:07, Joe Darcy wrote: > >> Andrew John Hughes wrote: >> >>> On 12 April 2010 20:04, Karl Helgason wrote: >>> >>> >>>> Hi, >>>> >>>> I need code review and bugid for the fix: >>>> http://cr.openjdk.java.net/~kalli/gervill-update2/webrev.01/ >>>> >>>> This fixes two issues: >>>> >>>> * ModelStandardIndexedDirector fails on invalid ranges. >>>> This fix is very IMPORTANT! >>>> Some songs+soundfonts combinations fails playing without this fix. >>>> >>>> * Program change with 16-bit banks doesn't work correctly. >>>> This is a very minor fix. >>>> >>>> JTreg tests have been created for both those issues. >>>> >>>> I am also working on another fix (not included in this fix) >>>> >>>> * SoftAbstractResampler doesn't work correctly >>>> when using interpolation algorithms that requires >>>> large padding like sinc interpolation. >>>> >>>> regards, >>>> Karl >>>> >>>> >>>> >>>> >>>> >>>> >>> A slightly off-topic point, but it would be good if this fix had a >>> more descriptive summary than the last when pushed: >>> >>> http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/74e449a8c951 >>> >>> Are these being pushed to JDK7 as well? >>> >>> >> These Gervill fixes should also be pushed to JDK 7. >> >> > > Which tree? I can forwardport the last one now. > > I would suggest TL, but as the technical code reviewer, the repo to use is Alexey's call. Thanks, -Joe From ahughes at redhat.com Mon Apr 12 13:51:18 2010 From: ahughes at redhat.com (Andrew John Hughes) Date: Mon, 12 Apr 2010 21:51:18 +0100 Subject: [Request for review and bugid] Gervill - ModelStandardIndexedDirector fails on invalid ranges. In-Reply-To: <4BC37ED2.4080406@oracle.com> References: <36EC82E93EB0AD40A4301DAD654323860146CD9D8900@mail.midverk.is> <4BC37D91.40201@oracle.com> <4BC37ED2.4080406@oracle.com> Message-ID: On 12 April 2010 21:13, Joe Darcy wrote: > Andrew John Hughes wrote: >> >> On 12 April 2010 21:07, Joe Darcy wrote: >> >>> >>> Andrew John Hughes wrote: >>> >>>> >>>> On 12 April 2010 20:04, Karl Helgason wrote: >>>> >>>> >>>>> >>>>> Hi, >>>>> >>>>> I need code review and bugid for the fix: >>>>> ?http://cr.openjdk.java.net/~kalli/gervill-update2/webrev.01/ >>>>> >>>>> This fixes two issues: >>>>> >>>>> ?* ModelStandardIndexedDirector fails on invalid ranges. >>>>> ?This fix is very IMPORTANT! >>>>> ?Some songs+soundfonts combinations fails playing without this fix. >>>>> >>>>> ?* Program change with 16-bit banks doesn't work correctly. >>>>> ?This is a very minor fix. >>>>> >>>>> JTreg tests have been created for both those issues. >>>>> >>>>> I am also working on another fix (not included in this fix) >>>>> >>>>> ?* SoftAbstractResampler doesn't work correctly >>>>> ?when using interpolation algorithms that requires >>>>> ?large padding like sinc interpolation. >>>>> >>>>> regards, >>>>> Karl >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> A slightly off-topic point, but it would be good if this fix had a >>>> more descriptive summary than the last when pushed: >>>> >>>> http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/74e449a8c951 >>>> >>>> Are these being pushed to JDK7 as well? >>>> >>>> >>> >>> These Gervill fixes should also be pushed to JDK 7. >>> >>> >> >> Which tree? I can forwardport the last one now. >> >> > > I would suggest TL, but as the technical code reviewer, the repo to use is > Alexey's call. > > Thanks, > > -Joe > > TL was what I was going to suggest until I realised it was a sound-related patch. I gave it a quick try, and it breaks horribly in applying to 7, seemingly due to whitespace changes. -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From joe.darcy at oracle.com Mon Apr 12 14:15:42 2010 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 12 Apr 2010 14:15:42 -0700 Subject: [Request for review and bugid] Gervill - ModelStandardIndexedDirector fails on invalid ranges. In-Reply-To: References: <36EC82E93EB0AD40A4301DAD654323860146CD9D8900@mail.midverk.is> <4BC37D91.40201@oracle.com> <4BC37ED2.4080406@oracle.com> Message-ID: <4BC38D7E.8010804@oracle.com> Andrew John Hughes wrote: > On 12 April 2010 21:13, Joe Darcy wrote: > >> Andrew John Hughes wrote: >> >>> On 12 April 2010 21:07, Joe Darcy wrote: >>> >>> >>>> Andrew John Hughes wrote: >>>> >>>> >>>>> On 12 April 2010 20:04, Karl Helgason wrote: >>>>> >>>>> >>>>> >>>>>> Hi, >>>>>> >>>>>> I need code review and bugid for the fix: >>>>>> http://cr.openjdk.java.net/~kalli/gervill-update2/webrev.01/ >>>>>> >>>>>> This fixes two issues: >>>>>> >>>>>> * ModelStandardIndexedDirector fails on invalid ranges. >>>>>> This fix is very IMPORTANT! >>>>>> Some songs+soundfonts combinations fails playing without this fix. >>>>>> >>>>>> * Program change with 16-bit banks doesn't work correctly. >>>>>> This is a very minor fix. >>>>>> >>>>>> JTreg tests have been created for both those issues. >>>>>> >>>>>> I am also working on another fix (not included in this fix) >>>>>> >>>>>> * SoftAbstractResampler doesn't work correctly >>>>>> when using interpolation algorithms that requires >>>>>> large padding like sinc interpolation. >>>>>> >>>>>> regards, >>>>>> Karl >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> A slightly off-topic point, but it would be good if this fix had a >>>>> more descriptive summary than the last when pushed: >>>>> >>>>> http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/74e449a8c951 >>>>> >>>>> Are these being pushed to JDK7 as well? >>>>> >>>>> >>>>> >>>> These Gervill fixes should also be pushed to JDK 7. >>>> >>>> >>>> >>> Which tree? I can forwardport the last one now. >>> >>> >>> >> I would suggest TL, but as the technical code reviewer, the repo to use is >> Alexey's call. >> >> Thanks, >> >> -Joe >> >> >> > > TL was what I was going to suggest until I realised it was a > sound-related patch. > > I gave it a quick try, and it breaks horribly in applying to 7, > seemingly due to whitespace changes. > Hmm, I thought both copies of Gervill had normalized whitespace. If not, we have scripts to turn a patch for non-normalized sources into a patch for normalized sources. -Joe From alex.menkov at sun.com Tue Apr 13 05:58:18 2010 From: alex.menkov at sun.com (Alex Menkov) Date: Tue, 13 Apr 2010 16:58:18 +0400 Subject: [Request for review and bugid] Gervill - ModelStandardIndexedDirector fails on invalid ranges. In-Reply-To: <4BC37C6B.2050009@oracle.com> References: <36EC82E93EB0AD40A4301DAD654323860146CD9D8900@mail.midverk.is> <4BC37C6B.2050009@oracle.com> Message-ID: <4BC46A6A.7040506@sun.com> Hi Karl, The fix looks fine for me. Feel free to push. regards Alex Joe Darcy wrote: > Hello. > > Karl Helgason wrote: >> Hi, >> >> I need code review and bugid for the fix: >> http://cr.openjdk.java.net/~kalli/gervill-update2/webrev.01/ >> >> This fixes two issues: >> >> * ModelStandardIndexedDirector fails on invalid ranges. >> This fix is very IMPORTANT! >> Some songs+soundfonts combinations fails playing without this fix. >> >> * Program change with 16-bit banks doesn't work correctly. >> This is a very minor fix. >> > > I've created bug 6943053 "Gervill: failures on invalid ranges and 16-bit > banks" for these issues. Alexey will need to do the technical code review. > > Since the fix is near at hand, I'm willing to hold OpenJDK 6 b19 for a > few days until this can get in. > >> JTreg tests have been created for both those issues. >> >> I am also working on another fix (not included in this fix) >> >> * SoftAbstractResampler doesn't work correctly >> when using interpolation algorithms that requires >> large padding like sinc interpolation. >> > > Unless I hear arguments otherwise, I do not plan to hold b19 for this > fix; it can go into b20 after the fix is ready. > > -Joe From alex.menkov at sun.com Tue Apr 13 06:20:41 2010 From: alex.menkov at sun.com (Alex Menkov) Date: Tue, 13 Apr 2010 17:20:41 +0400 Subject: [Request for review and bugid] Gervill - ModelStandardIndexedDirector fails on invalid ranges. In-Reply-To: <4BC38D7E.8010804@oracle.com> References: <36EC82E93EB0AD40A4301DAD654323860146CD9D8900@mail.midverk.is> <4BC37D91.40201@oracle.com> <4BC37ED2.4080406@oracle.com> <4BC38D7E.8010804@oracle.com> Message-ID: <4BC46FA9.4020007@sun.com> Joe, Andrew, sound fixes have a bit tangled "patch logistics" :) Karl pushes changes into openjdk6, then I forwardport them into jdk7 (to minimize QE I push sound fixes in batches, so often fixes go to jdk7 with a delay). openjdk6 repo does not use jcheck extension, so I fix whitespace normalization issues only pushing changes into jdk7. regards Alex Joe Darcy wrote: > Andrew John Hughes wrote: >> On 12 April 2010 21:13, Joe Darcy wrote: >> >>> Andrew John Hughes wrote: >>> >>>> On 12 April 2010 21:07, Joe Darcy wrote: >>>> >>>>> Andrew John Hughes wrote: >>>>> >>>>>> On 12 April 2010 20:04, Karl Helgason wrote: >>>>>>> Hi, >>>>>>> >>>>>>> I need code review and bugid for the fix: >>>>>>> http://cr.openjdk.java.net/~kalli/gervill-update2/webrev.01/ >>>>>>> >>>>>>> This fixes two issues: >>>>>>> >>>>>>> * ModelStandardIndexedDirector fails on invalid ranges. >>>>>>> This fix is very IMPORTANT! >>>>>>> Some songs+soundfonts combinations fails playing without this fix. >>>>>>> >>>>>>> * Program change with 16-bit banks doesn't work correctly. >>>>>>> This is a very minor fix. >>>>>>> >>>>>>> JTreg tests have been created for both those issues. >>>>>>> >>>>>>> I am also working on another fix (not included in this fix) >>>>>>> >>>>>>> * SoftAbstractResampler doesn't work correctly >>>>>>> when using interpolation algorithms that requires >>>>>>> large padding like sinc interpolation. >>>>>>> >>>>>>> regards, >>>>>>> Karl >>>>>>> >>>>>> A slightly off-topic point, but it would be good if this fix had a >>>>>> more descriptive summary than the last when pushed: >>>>>> http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/74e449a8c951 >>>>>> Are these being pushed to JDK7 as well? >>>>>> >>>>> These Gervill fixes should also be pushed to JDK 7. >>>>> >>>> Which tree? I can forwardport the last one now. >>>> >>> I would suggest TL, but as the technical code reviewer, the repo to >>> use is >>> Alexey's call. >>> >>> Thanks, >>> >>> -Joe >> >> TL was what I was going to suggest until I realised it was a >> sound-related patch. >> >> I gave it a quick try, and it breaks horribly in applying to 7, >> seemingly due to whitespace changes. > > Hmm, I thought both copies of Gervill had normalized whitespace. If > not, we have scripts to turn a patch for non-normalized sources into a > patch for normalized sources. > > -Joe From joe.darcy at oracle.com Tue Apr 13 09:29:18 2010 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 13 Apr 2010 09:29:18 -0700 Subject: [Request for review and bugid] Gervill - ModelStandardIndexedDirector fails on invalid ranges. In-Reply-To: <4BC46FA9.4020007@sun.com> References: <36EC82E93EB0AD40A4301DAD654323860146CD9D8900@mail.midverk.is> <4BC37D91.40201@oracle.com> <4BC37ED2.4080406@oracle.com> <4BC38D7E.8010804@oracle.com> <4BC46FA9.4020007@sun.com> Message-ID: <4BC49BDE.6030002@oracle.com> Alex Menkov wrote: > Joe, Andrew, > > sound fixes have a bit tangled "patch logistics" :) > Karl pushes changes into openjdk6, then I forwardport them into jdk7 > (to minimize QE I push sound fixes in batches, so often fixes go to > jdk7 with a delay). > openjdk6 repo does not use jcheck extension, so I fix whitespace > normalization issues only pushing changes into jdk7. About jcheck, OpenJDK 6 does use jcheck, but it is configured differently than in JDK 7. For OpenJDK 6, jcheck is lax on both repeated bug ids and whitespace. The former was necessary for some HotSpot merge issues and the latter was necessary to capture the full public history of OpenJDK 6. -Joe From kalli at midverk.is Tue Apr 13 15:15:06 2010 From: kalli at midverk.is (kalli at midverk.is) Date: Tue, 13 Apr 2010 22:15:06 +0000 Subject: hg: jdk6/jdk6/jdk: 6943053: Gervill: failures on invalid ranges and 14-bit banks Message-ID: <20100413221519.4D62E44530@hg.openjdk.java.net> Changeset: 6c55c39d0b33 Author: kalli Date: 2010-04-13 22:14 +0000 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/6c55c39d0b33 6943053: Gervill: failures on invalid ranges and 14-bit banks Summary: ModelStandardIndexedDirector fails on invalid ranges. Program changes with 14-bit banks where handled incorectly as 7-bit banks. Reviewed-by: amenkov ! src/share/classes/com/sun/media/sound/ModelStandardIndexedDirector.java ! src/share/classes/com/sun/media/sound/SoftChannel.java + test/javax/sound/midi/Gervill/ModelStandardIndexedDirector/ModelStandardIndexedDirectorTest.java + test/javax/sound/midi/Gervill/SoftChannel/ProgramAndBankChange.java From joe.darcy at oracle.com Tue Apr 13 18:49:14 2010 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Tue, 13 Apr 2010 18:49:14 -0700 Subject: [Request for review and bugid] Gervill - ModelStandardIndexedDirector fails on invalid ranges. In-Reply-To: <4BC46A6A.7040506@sun.com> References: <36EC82E93EB0AD40A4301DAD654323860146CD9D8900@mail.midverk.is> <4BC37C6B.2050009@oracle.com> <4BC46A6A.7040506@sun.com> Message-ID: <4BC51F1A.3040000@oracle.com> Hello. It would be preferable if this got back in the next day or two. Thanks, -Joe On 4/13/2010 5:58 AM, Alex Menkov wrote: > Hi Karl, > > The fix looks fine for me. > Feel free to push. > > regards > Alex > > Joe Darcy wrote: >> Hello. >> >> Karl Helgason wrote: >>> Hi, >>> >>> I need code review and bugid for the fix: >>> http://cr.openjdk.java.net/~kalli/gervill-update2/webrev.01/ >>> >>> This fixes two issues: >>> >>> * ModelStandardIndexedDirector fails on invalid ranges. >>> This fix is very IMPORTANT! >>> Some songs+soundfonts combinations fails playing without this fix. >>> >>> * Program change with 16-bit banks doesn't work correctly. >>> This is a very minor fix. >>> >> >> I've created bug 6943053 "Gervill: failures on invalid ranges and >> 16-bit banks" for these issues. Alexey will need to do the technical >> code review. >> >> Since the fix is near at hand, I'm willing to hold OpenJDK 6 b19 for >> a few days until this can get in. >> >>> JTreg tests have been created for both those issues. >>> >>> I am also working on another fix (not included in this fix) >>> >>> * SoftAbstractResampler doesn't work correctly >>> when using interpolation algorithms that requires >>> large padding like sinc interpolation. >>> >> >> Unless I hear arguments otherwise, I do not plan to hold b19 for this >> fix; it can go into b20 after the fix is ready. >> >> -Joe From joe.darcy at oracle.com Wed Apr 14 11:20:48 2010 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 14 Apr 2010 11:20:48 -0700 Subject: [Request for review and bugid] Gervill - ModelStandardIndexedDirector fails on invalid ranges. In-Reply-To: <4BC51F1A.3040000@oracle.com> References: <36EC82E93EB0AD40A4301DAD654323860146CD9D8900@mail.midverk.is> <4BC37C6B.2050009@oracle.com> <4BC46A6A.7040506@sun.com> <4BC51F1A.3040000@oracle.com> Message-ID: <4BC60780.8060301@oracle.com> Thanks for the fix, -Joe joe.darcy at oracle.com wrote: > Hello. > > It would be preferable if this got back in the next day or two. > > Thanks, > > -Joe > > On 4/13/2010 5:58 AM, Alex Menkov wrote: >> Hi Karl, >> >> The fix looks fine for me. >> Feel free to push. >> >> regards >> Alex >> >> Joe Darcy wrote: >>> Hello. >>> >>> Karl Helgason wrote: >>>> Hi, >>>> >>>> I need code review and bugid for the fix: >>>> http://cr.openjdk.java.net/~kalli/gervill-update2/webrev.01/ >>>> >>>> This fixes two issues: >>>> >>>> * ModelStandardIndexedDirector fails on invalid ranges. >>>> This fix is very IMPORTANT! >>>> Some songs+soundfonts combinations fails playing without this fix. >>>> >>>> * Program change with 16-bit banks doesn't work correctly. >>>> This is a very minor fix. >>>> >>> >>> I've created bug 6943053 "Gervill: failures on invalid ranges and >>> 16-bit banks" for these issues. Alexey will need to do the >>> technical code review. >>> >>> Since the fix is near at hand, I'm willing to hold OpenJDK 6 b19 for >>> a few days until this can get in. >>> >>>> JTreg tests have been created for both those issues. >>>> >>>> I am also working on another fix (not included in this fix) >>>> >>>> * SoftAbstractResampler doesn't work correctly >>>> when using interpolation algorithms that requires >>>> large padding like sinc interpolation. >>>> >>> >>> Unless I hear arguments otherwise, I do not plan to hold b19 for >>> this fix; it can go into b20 after the fix is ready. >>> >>> -Joe From joe.darcy at oracle.com Wed Apr 14 14:32:35 2010 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Wed, 14 Apr 2010 21:32:35 +0000 Subject: hg: jdk6/jdk6/corba: Added tag jdk6-b19 for changeset 9eeb441e885c Message-ID: <20100414213241.C170644554@hg.openjdk.java.net> Changeset: 413a30f894b9 Author: darcy Date: 2010-04-14 14:31 -0700 URL: http://hg.openjdk.java.net/jdk6/jdk6/corba/rev/413a30f894b9 Added tag jdk6-b19 for changeset 9eeb441e885c ! .hgtags From joe.darcy at oracle.com Wed Apr 14 14:34:01 2010 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Wed, 14 Apr 2010 21:34:01 +0000 Subject: hg: jdk6/jdk6/hotspot: Added tag jdk6-b19 for changeset e77ed20ce981 Message-ID: <20100414213415.DBE2044556@hg.openjdk.java.net> Changeset: 587f774a3e70 Author: darcy Date: 2010-04-14 14:33 -0700 URL: http://hg.openjdk.java.net/jdk6/jdk6/hotspot/rev/587f774a3e70 Added tag jdk6-b19 for changeset e77ed20ce981 ! .hgtags From joe.darcy at oracle.com Wed Apr 14 14:35:07 2010 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Wed, 14 Apr 2010 21:35:07 +0000 Subject: hg: jdk6/jdk6/jaxp: Added tag jdk6-b19 for changeset 5c070921580c Message-ID: <20100414213508.25C5E44558@hg.openjdk.java.net> Changeset: 2d633453d86b Author: darcy Date: 2010-04-14 14:34 -0700 URL: http://hg.openjdk.java.net/jdk6/jdk6/jaxp/rev/2d633453d86b Added tag jdk6-b19 for changeset 5c070921580c ! .hgtags From joe.darcy at oracle.com Wed Apr 14 14:35:28 2010 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Wed, 14 Apr 2010 21:35:28 +0000 Subject: hg: jdk6/jdk6/jaxws: Added tag jdk6-b19 for changeset 961cf80a02a8 Message-ID: <20100414213528.C42E44455A@hg.openjdk.java.net> Changeset: ff7b646cf297 Author: darcy Date: 2010-04-14 14:35 -0700 URL: http://hg.openjdk.java.net/jdk6/jdk6/jaxws/rev/ff7b646cf297 Added tag jdk6-b19 for changeset 961cf80a02a8 ! .hgtags From joe.darcy at oracle.com Wed Apr 14 14:35:53 2010 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Wed, 14 Apr 2010 21:35:53 +0000 Subject: hg: jdk6/jdk6/langtools: Added tag jdk6-b19 for changeset 7306e2127357 Message-ID: <20100414213555.660C34455C@hg.openjdk.java.net> Changeset: 937c49732f33 Author: darcy Date: 2010-04-14 14:35 -0700 URL: http://hg.openjdk.java.net/jdk6/jdk6/langtools/rev/937c49732f33 Added tag jdk6-b19 for changeset 7306e2127357 ! .hgtags From joe.darcy at oracle.com Wed Apr 14 14:36:25 2010 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Wed, 14 Apr 2010 21:36:25 +0000 Subject: hg: jdk6/jdk6/jdk: Added tag jdk6-b19 for changeset 6c55c39d0b33 Message-ID: <20100414213652.B436D4455E@hg.openjdk.java.net> Changeset: e1d1417392db Author: darcy Date: 2010-04-14 14:36 -0700 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/e1d1417392db Added tag jdk6-b19 for changeset 6c55c39d0b33 ! .hgtags From joe.darcy at oracle.com Wed Apr 14 14:38:39 2010 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Wed, 14 Apr 2010 21:38:39 +0000 Subject: hg: jdk6/jdk6: Added tag jdk6-b19 for changeset 5bf8bda5b515 Message-ID: <20100414213839.2812544560@hg.openjdk.java.net> Changeset: 45c60530719d Author: darcy Date: 2010-04-14 14:38 -0700 URL: http://hg.openjdk.java.net/jdk6/jdk6/rev/45c60530719d Added tag jdk6-b19 for changeset 5bf8bda5b515 ! .hgtags From Joe.Darcy at Sun.COM Wed Apr 14 14:41:14 2010 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Wed, 14 Apr 2010 14:41:14 -0700 Subject: Regression test results on latest pre-b19 -- repos tagged with b19 In-Reply-To: <4BC37E13.8030104@oracle.com> References: <4BC3500A.7060106@oracle.com> <4BC37E13.8030104@oracle.com> Message-ID: <4BC6367A.5010006@sun.com> Joe Darcy wrote: > Andrew John Hughes wrote: >> On 12 April 2010 17:53, Joe Darcy wrote: >> >>> Hello. >>> >>> I did a fresh build with all the latest changes and ran the >>> regression test >>> suite. As before, all the HotSpot and langtools tests pass. I >>> think these >>> results are good enough for b19. >>> [snip] >>> >>> -Joe >>> >>> >> >> Looks good to me. I don't see any regressions (pass-->fail). >> > > And there are lots more passing tests :-) > > Other than the Gervill fix under review, I don't have any other > outstanding changes to get into b19. Assuming the Gervill fix goes > back soon and the test results are consistent, I'll label the repos > post-fix as b19. > The tests results were consistent as expected. I've tagged the repos with b19 and the usual source bundles, etc. should follow within a few days. -Joe From kelly.ohair at oracle.com Wed Apr 14 15:48:33 2010 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Wed, 14 Apr 2010 15:48:33 -0700 Subject: ant 1.7.1 and make 3.81 In-Reply-To: <9DB28096-E0DB-4776-8324-E23FBBE83230@oracle.com> References: <9DB28096-E0DB-4776-8324-E23FBBE83230@oracle.com> Message-ID: Just an update on this ant 1.8.0 and make 3.81 issue. I will try and move forward on the make 3.81 change, but the ant 1.8.0 one is a problem. We will try and find another way around the package-info.java issues in ant 1.7.1. I had assumed this would be an easy ant upgrade, but obviously it is not. The fixes in ant 1.8.0 for the most part seem correct, and other than the false 'exit code' running 'ant -diagnostics', I don't know of any major flaws in 1.8.0. However, I'm seeing various ant scripts failing, and most appear to be just incorrect ant syntax, or some loophole closed by a valid fix in ant 1.8.0. None of these questionable ant scripts are in OpenJDK as far as I know, however it makes me think that upgrading now is the wrong thing to do. Once ant 1.8.0 becomes more available we can re-visit this, or there is always ant 1.8.1. -kto From joe.darcy at oracle.com Wed Apr 14 18:03:58 2010 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 14 Apr 2010 18:03:58 -0700 Subject: Test Backports In-Reply-To: References: <17c6771e1003291310u3e1b3231i6a054fd76bc24182@mail.gmail.com> <4BBE7474.6020704@oracle.com> <4BBE793D.4050505@oracle.com> <4BBF561E.2070801@oracle.com> <8351CCF8-B710-4443-96BD-C9604505CF85@oracle.com> Message-ID: <4BC665FE.3080903@oracle.com> On 04/11/10 01:42 PM, Andrew John Hughes wrote: > On 10 April 2010 03:40, Kelly O'Hair wrote: > >> On Apr 9, 2010, at 7:20 PM, Andrew John Hughes wrote: >> >> >>> On 10 April 2010 01:48, Kelly O'Hair wrote: >>> >>>> On Apr 9, 2010, at 5:05 PM, Andrew John Hughes wrote: >>>> >>>> >>>>> Just waiting on Kelly's reponse now wrt. the HotSpot source/target fix. >>>>> >>>>> >>>> Can you clarify what response you are waiting on? >>>> >>>> >>> Yes, sorry it's this one: >>> http://mail.openjdk.java.net/pipermail/jdk6-dev/2010-April/001464.html >>> >>> It wasn't clear whether you were ok with the HotSpot change or wanted >>> more time to review. The patch is pretty much as-is in OpenJDK7, the >>> only difference being the version change from 6 to 5. >>> >> The hotspot file changes look ok, but I have no idea how the hotspot >> changes are being handled for openjdk6. >> > > We regularly import from the stablisation branches: > > http://hg.openjdk.java.net/hsx/hsx14/master/ (OpenJDK6 b17 & b18) > http://hg.openjdk.java.net/hsx/hsx16/master/ (OpenJDK6 b19) > http://hg.openjdk.java.net/hsx/hsx17/master/ (OpenJDK6 b20?) > > The last one, hs17, includes the OpenJDK7 version of this fix. > Including an OpenJDK6 version now with 1.5 source and target versions > has the advantage that we won't bring in a version that requires > source and target versions of 1.6 from hs17. > > Joe, does b20 sound appropriate for hs17? I know it's a bit soon > after hs16, but the proprietary JDK6 is already moving towards this > and we could do with catching up. It will be take time for such an > OpenJDK6 release to roll through into an IcedTea6 release and then the > distros anyway, so I'd prefer sooner rather than later. > > I'm not sure of the timeline for hs17. At some point, the copyright notices in the OpenJDK 6 repo will be changed from Sun -> Oracle. A more general announcement about this process and the new conventions will be forthcoming. Making these copyright changes, at least in the langtools and jdk repos, might warrant a separate build with just those changes, in which case the upgrade of the HotSpot sources to HS 17 (with changed copyrights?) might occur in build 21 or later. -Joe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/jdk6-dev/attachments/20100414/9d24a481/attachment.html From ahughes at redhat.com Thu Apr 15 05:52:59 2010 From: ahughes at redhat.com (Andrew John Hughes) Date: Thu, 15 Apr 2010 13:52:59 +0100 Subject: Test Backports In-Reply-To: <4BC665FE.3080903@oracle.com> References: <17c6771e1003291310u3e1b3231i6a054fd76bc24182@mail.gmail.com> <4BBE793D.4050505@oracle.com> <4BBF561E.2070801@oracle.com> <8351CCF8-B710-4443-96BD-C9604505CF85@oracle.com> <4BC665FE.3080903@oracle.com> Message-ID: On 15 April 2010 02:03, Joe Darcy wrote: > On 04/11/10 01:42 PM, Andrew John Hughes wrote: > > On 10 April 2010 03:40, Kelly O'Hair wrote: > > > On Apr 9, 2010, at 7:20 PM, Andrew John Hughes wrote: > > > > On 10 April 2010 01:48, Kelly O'Hair wrote: > > > On Apr 9, 2010, at 5:05 PM, Andrew John Hughes wrote: > > > > Just waiting on Kelly's reponse now wrt. the HotSpot source/target fix. > > > > Can you clarify what response you are waiting on? > > > > Yes, sorry it's this one: > http://mail.openjdk.java.net/pipermail/jdk6-dev/2010-April/001464.html > > It wasn't clear whether you were ok with the HotSpot change or wanted > more time to review. ?The patch is pretty much as-is in OpenJDK7, the > only difference being the version change from 6 to 5. > > > The hotspot file changes look ok, but I have no idea how the hotspot > changes are being handled for openjdk6. > > > We regularly import from the stablisation branches: > > http://hg.openjdk.java.net/hsx/hsx14/master/ (OpenJDK6 b17 & b18) > http://hg.openjdk.java.net/hsx/hsx16/master/ (OpenJDK6 b19) > http://hg.openjdk.java.net/hsx/hsx17/master/ (OpenJDK6 b20?) > > The last one, hs17, includes the OpenJDK7 version of this fix. > Including an OpenJDK6 version now with 1.5 source and target versions > has the advantage that we won't bring in a version that requires > source and target versions of 1.6 from hs17. > > Joe, does b20 sound appropriate for hs17? I know it's a bit soon > after hs16, but the proprietary JDK6 is already moving towards this > and we could do with catching up. It will be take time for such an > OpenJDK6 release to roll through into an IcedTea6 release and then the > distros anyway, so I'd prefer sooner rather than later. > > > > I'm not sure of the timeline for hs17. > > At some point, the copyright notices in the OpenJDK 6 repo will be changed > from Sun -> Oracle.? A more general announcement about this process and the > new conventions will be forthcoming. This has already happened in hs17. I queried the rather strange ranges used on the new notices earlier this week. Making these copyright changes, at > least in the langtools and jdk repos, might warrant a separate build with > just those changes, in which case the upgrade of the HotSpot sources to HS > 17 (with changed copyrights?) might occur in build 21 or later. > Do we really need a new build just for that? I doubt we'd bother upgrading IcedTea6 to such a build just for that change. > -Joe > -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From ahughes at redhat.com Thu Apr 15 06:25:51 2010 From: ahughes at redhat.com (Andrew John Hughes) Date: Thu, 15 Apr 2010 14:25:51 +0100 Subject: [Request for review and bugid] Gervill - ModelStandardIndexedDirector fails on invalid ranges. In-Reply-To: <4BC49BDE.6030002@oracle.com> References: <36EC82E93EB0AD40A4301DAD654323860146CD9D8900@mail.midverk.is> <4BC37D91.40201@oracle.com> <4BC37ED2.4080406@oracle.com> <4BC38D7E.8010804@oracle.com> <4BC46FA9.4020007@sun.com> <4BC49BDE.6030002@oracle.com> Message-ID: On 13 April 2010 17:29, Joe Darcy wrote: > Alex Menkov wrote: >> >> Joe, Andrew, >> >> sound fixes have a bit tangled "patch logistics" :) >> Karl pushes changes into openjdk6, then I forwardport them into jdk7 (to >> minimize QE I push sound fixes in batches, so often fixes go to jdk7 with a >> delay). >> openjdk6 repo does not use jcheck extension, so I fix whitespace >> normalization issues only pushing changes into jdk7. > > About jcheck, OpenJDK 6 does use jcheck, but it is configured differently > than in JDK 7. ?For OpenJDK 6, jcheck is lax on both repeated bug ids and > whitespace. ?The former was necessary for some HotSpot merge issues and the > latter was necessary to capture the full public history of OpenJDK 6. > > -Joe > Any reason we can't enforce the whitespace check on new OpenJDK6 patches? This would help keep 6 & 7 in sync. -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From joe.darcy at oracle.com Thu Apr 15 18:09:44 2010 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 15 Apr 2010 18:09:44 -0700 Subject: Test Backports In-Reply-To: References: <17c6771e1003291310u3e1b3231i6a054fd76bc24182@mail.gmail.com> <4BBE793D.4050505@oracle.com> <4BBF561E.2070801@oracle.com> <8351CCF8-B710-4443-96BD-C9604505CF85@oracle.com> <4BC665FE.3080903@oracle.com> Message-ID: <4BC7B8D8.5010105@oracle.com> Andrew John Hughes wrote: > On 15 April 2010 02:03, Joe Darcy wrote: > >> On 04/11/10 01:42 PM, Andrew John Hughes wrote: >> >> On 10 April 2010 03:40, Kelly O'Hair wrote: >> >> >> On Apr 9, 2010, at 7:20 PM, Andrew John Hughes wrote: >> >> >> >> On 10 April 2010 01:48, Kelly O'Hair wrote: >> >> >> On Apr 9, 2010, at 5:05 PM, Andrew John Hughes wrote: >> >> >> >> Just waiting on Kelly's reponse now wrt. the HotSpot source/target fix. >> >> >> >> Can you clarify what response you are waiting on? >> >> >> >> Yes, sorry it's this one: >> http://mail.openjdk.java.net/pipermail/jdk6-dev/2010-April/001464.html >> >> It wasn't clear whether you were ok with the HotSpot change or wanted >> more time to review. The patch is pretty much as-is in OpenJDK7, the >> only difference being the version change from 6 to 5. >> >> >> The hotspot file changes look ok, but I have no idea how the hotspot >> changes are being handled for openjdk6. >> >> >> We regularly import from the stablisation branches: >> >> http://hg.openjdk.java.net/hsx/hsx14/master/ (OpenJDK6 b17 & b18) >> http://hg.openjdk.java.net/hsx/hsx16/master/ (OpenJDK6 b19) >> http://hg.openjdk.java.net/hsx/hsx17/master/ (OpenJDK6 b20?) >> >> The last one, hs17, includes the OpenJDK7 version of this fix. >> Including an OpenJDK6 version now with 1.5 source and target versions >> has the advantage that we won't bring in a version that requires >> source and target versions of 1.6 from hs17. >> >> Joe, does b20 sound appropriate for hs17? I know it's a bit soon >> after hs16, but the proprietary JDK6 is already moving towards this >> and we could do with catching up. It will be take time for such an >> OpenJDK6 release to roll through into an IcedTea6 release and then the >> distros anyway, so I'd prefer sooner rather than later. >> >> >> >> I'm not sure of the timeline for hs17. >> >> At some point, the copyright notices in the OpenJDK 6 repo will be changed >> from Sun -> Oracle. A more general announcement about this process and the >> new conventions will be forthcoming. >> > > This has already happened in hs17. I queried the rather strange > ranges used on the new notices earlier this week. > > Making these copyright changes, at > >> least in the langtools and jdk repos, might warrant a separate build with >> just those changes, in which case the upgrade of the HotSpot sources to HS >> 17 (with changed copyrights?) might occur in build 21 or later. >> >> > > Do we really need a new build just for that? I doubt we'd bother > upgrading IcedTea6 to such a build just for that change. > > I don't think a new build number is strictly required for the copyright change, but I think it makes the change easier to administer: "before build N, Sun copyrights; build N and later, Oracle copyrights." I agree there would be little motivation for IcedTea 6 to pick up that build just to get new copyright notices. -Joe From joe.darcy at oracle.com Thu Apr 15 19:23:08 2010 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 15 Apr 2010 19:23:08 -0700 Subject: [Request for review and bugid] Gervill - ModelStandardIndexedDirector fails on invalid ranges. In-Reply-To: References: <36EC82E93EB0AD40A4301DAD654323860146CD9D8900@mail.midverk.is> <4BC37D91.40201@oracle.com> <4BC37ED2.4080406@oracle.com> <4BC38D7E.8010804@oracle.com> <4BC46FA9.4020007@sun.com> <4BC49BDE.6030002@oracle.com> Message-ID: <4BC7CA0C.8020103@oracle.com> Andrew John Hughes wrote: > On 13 April 2010 17:29, Joe Darcy wrote: > >> Alex Menkov wrote: >> >>> Joe, Andrew, >>> >>> sound fixes have a bit tangled "patch logistics" :) >>> Karl pushes changes into openjdk6, then I forwardport them into jdk7 (to >>> minimize QE I push sound fixes in batches, so often fixes go to jdk7 with a >>> delay). >>> openjdk6 repo does not use jcheck extension, so I fix whitespace >>> normalization issues only pushing changes into jdk7. >>> >> About jcheck, OpenJDK 6 does use jcheck, but it is configured differently >> than in JDK 7. For OpenJDK 6, jcheck is lax on both repeated bug ids and >> whitespace. The former was necessary for some HotSpot merge issues and the >> latter was necessary to capture the full public history of OpenJDK 6. >> >> -Joe >> >> > > Any reason we can't enforce the whitespace check on new OpenJDK6 > patches? This would help keep 6 & 7 in sync. > I suppose it would just be a "small matter of programming" to have jcheck be lax in whitespace for older changesets but enforce the checks after a certain point... -Joe From Joe.Darcy at Sun.COM Thu Apr 15 19:34:19 2010 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Thu, 15 Apr 2010 19:34:19 -0700 Subject: Regression test results on latest pre-b19 -- repos tagged with b19 - b19 complete! In-Reply-To: <4BC6367A.5010006@sun.com> References: <4BC3500A.7060106@oracle.com> <4BC37E13.8030104@oracle.com> <4BC6367A.5010006@sun.com> Message-ID: <4BC7CCAB.20205@sun.com> Joseph D. Darcy wrote: > Joe Darcy wrote: >> Andrew John Hughes wrote: >>> On 12 April 2010 17:53, Joe Darcy wrote: >>> >>>> Hello. >>>> >>>> I did a fresh build with all the latest changes and ran the >>>> regression test >>>> suite. As before, all the HotSpot and langtools tests pass. I >>>> think these >>>> results are good enough for b19. >>>> > > [snip] > >>>> >>>> -Joe >>>> >>>> >>> >>> Looks good to me. I don't see any regressions (pass-->fail). >>> >> >> And there are lots more passing tests :-) >> >> Other than the Gervill fix under review, I don't have any other >> outstanding changes to get into b19. Assuming the Gervill fix goes >> back soon and the test results are consistent, I'll label the repos >> post-fix as b19. >> > > The tests results were consistent as expected. I've tagged the repos > with b19 and the usual source bundles, etc. should follow within a few > days. > Source bundles posted: http://download.java.net/openjdk/jdk6/promoted/b19/openjdk-6-src-b19-15_apr_2010.tar.gz OpenJDK 6 build 19 is done, on to build 20! As implied in some other recent messages to the list, I was considering having OpenJDK 6 build 20 be dedicated to updating the copyrights in the repositories from Sun -> Oracle. That is not terribly compelling technically, but it would make the administration of this change easier. In the next build open to technical changes, what changes are of interest? -Joe PS The security issue recently fixed in the proprietary 6u20 does *not* impact OpenJDK 6. From ahughes at redhat.com Fri Apr 16 01:29:28 2010 From: ahughes at redhat.com (Andrew John Hughes) Date: Fri, 16 Apr 2010 09:29:28 +0100 Subject: Test Backports In-Reply-To: <4BC7B8D8.5010105@oracle.com> References: <17c6771e1003291310u3e1b3231i6a054fd76bc24182@mail.gmail.com> <4BBF561E.2070801@oracle.com> <8351CCF8-B710-4443-96BD-C9604505CF85@oracle.com> <4BC665FE.3080903@oracle.com> <4BC7B8D8.5010105@oracle.com> Message-ID: On 16 April 2010 02:09, Joe Darcy wrote: > Andrew John Hughes wrote: >> >> On 15 April 2010 02:03, Joe Darcy wrote: >> >>> >>> On 04/11/10 01:42 PM, Andrew John Hughes wrote: >>> >>> On 10 April 2010 03:40, Kelly O'Hair wrote: >>> >>> >>> On Apr 9, 2010, at 7:20 PM, Andrew John Hughes wrote: >>> >>> >>> >>> On 10 April 2010 01:48, Kelly O'Hair wrote: >>> >>> >>> On Apr 9, 2010, at 5:05 PM, Andrew John Hughes wrote: >>> >>> >>> >>> Just waiting on Kelly's reponse now wrt. the HotSpot source/target fix. >>> >>> >>> >>> Can you clarify what response you are waiting on? >>> >>> >>> >>> Yes, sorry it's this one: >>> http://mail.openjdk.java.net/pipermail/jdk6-dev/2010-April/001464.html >>> >>> It wasn't clear whether you were ok with the HotSpot change or wanted >>> more time to review. ?The patch is pretty much as-is in OpenJDK7, the >>> only difference being the version change from 6 to 5. >>> >>> >>> The hotspot file changes look ok, but I have no idea how the hotspot >>> changes are being handled for openjdk6. >>> >>> >>> We regularly import from the stablisation branches: >>> >>> http://hg.openjdk.java.net/hsx/hsx14/master/ (OpenJDK6 b17 & b18) >>> http://hg.openjdk.java.net/hsx/hsx16/master/ (OpenJDK6 b19) >>> http://hg.openjdk.java.net/hsx/hsx17/master/ (OpenJDK6 b20?) >>> >>> The last one, hs17, includes the OpenJDK7 version of this fix. >>> Including an OpenJDK6 version now with 1.5 source and target versions >>> has the advantage that we won't bring in a version that requires >>> source and target versions of 1.6 from hs17. >>> >>> Joe, does b20 sound appropriate for hs17? ?I know it's a bit soon >>> after hs16, but the proprietary JDK6 is already moving towards this >>> and we could do with catching up. ?It will be take time for such an >>> OpenJDK6 release to roll through into an IcedTea6 release and then the >>> distros anyway, so I'd prefer sooner rather than later. >>> >>> >>> >>> I'm not sure of the timeline for hs17. >>> >>> At some point, the copyright notices in the OpenJDK 6 repo will be >>> changed >>> from Sun -> Oracle. ?A more general announcement about this process and >>> the >>> new conventions will be forthcoming. >>> >> >> This has already happened in hs17. ?I queried the rather strange >> ranges used on the new notices earlier this week. >> >> Making these copyright changes, at >> >>> >>> least in the langtools and jdk repos, might warrant a separate build with >>> just those changes, in which case the upgrade of the HotSpot sources to >>> HS >>> 17 (with changed copyrights?) might occur in build 21 or later. >>> >>> >> >> Do we really need a new build just for that? ?I doubt we'd bother >> upgrading IcedTea6 to such a build just for that change. >> >> > > I don't think a new build number is strictly required for the copyright > change, but I think it makes the change easier to administer: "before build > N, Sun copyrights; build N and later, Oracle copyrights." > > I agree there would be little motivation for IcedTea 6 to pick up that build > just to get new copyright notices. > > -Joe > > Ok, do you have any idea when these changes will happen? My worry is that this effectively means a block on OpenJDK6 activity until then. Assuming we want b20 to be the N mentioned above, we could upgrade HotSpot to 17 as part of b20, bringing with it both the new copyrights and keeping us in sync with the proprietary JDK6 (hs17b13, the current build, will be used in 6u21 b03 - http://mail.openjdk.java.net/pipermail/hotspot-dev/2010-April/002843.html). Then it really would be the case that all copyrights change in that build and we also have a single new feature (hs17) too. The only changes to langtools & jdk would be the copyrights. Does this sound sensible? The alternative for HotSpot would be to change the copyrights on the current OpenJDK6 version, which would duplicate the work already done on hs17 and may make merging hs17 harder. Will the copyrights in CORBA, JAXP and JAXWS be changing? Thanks, -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From ahughes at redhat.com Fri Apr 16 06:31:58 2010 From: ahughes at redhat.com (Andrew John Hughes) Date: Fri, 16 Apr 2010 14:31:58 +0100 Subject: Regression test results on latest pre-b19 -- repos tagged with b19 - b19 complete! In-Reply-To: <4BC7CCAB.20205@sun.com> References: <4BC3500A.7060106@oracle.com> <4BC37E13.8030104@oracle.com> <4BC6367A.5010006@sun.com> <4BC7CCAB.20205@sun.com> Message-ID: On 16 April 2010 03:34, Joseph D. Darcy wrote: > Joseph D. Darcy wrote: >> >> Joe Darcy wrote: >>> >>> Andrew John Hughes wrote: >>>> >>>> On 12 April 2010 17:53, Joe Darcy wrote: >>>> >>>>> >>>>> Hello. >>>>> >>>>> I did a fresh build with all the latest changes and ran the regression >>>>> test >>>>> suite. ?As before, all the HotSpot and langtools tests pass. ?I think >>>>> these >>>>> results are good enough for b19. >>>>> >> >> [snip] >> >>>>> >>>>> -Joe >>>>> >>>>> >>>> >>>> Looks good to me. ?I don't see any regressions (pass-->fail). >>>> >>> >>> And there are lots more passing tests :-) >>> >>> Other than the Gervill fix under review, I don't have any other >>> outstanding changes to get into b19. ?Assuming the Gervill fix goes back >>> soon and the test results are consistent, I'll label the repos post-fix as >>> b19. >>> >> >> The tests results were consistent as expected. ?I've tagged the repos with >> b19 and the usual source bundles, etc. should follow within a few days. >> > > Source bundles posted: > http://download.java.net/openjdk/jdk6/promoted/b19/openjdk-6-src-b19-15_apr_2010.tar.gz > > OpenJDK 6 build 19 is done, on to build 20! > IcedTea6 now bumped to b19 too. > As implied in some other recent messages to the list, I was considering > having OpenJDK 6 build 20 be dedicated to updating the copyrights in the > repositories from Sun -> Oracle. ?That is not terribly compelling > technically, but it would make the administration of this change easier. > > In the next build open to technical changes, what changes are of interest? > hs17 would be my primary one, though as I suggested in another mail, it may make more sense to include this in the license updating. There's a fix I just posted to tl which needs backporting: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c444651077d2 I need to review what we have in IcedTea6 to see what else is needed. > -Joe > > PS The security issue recently fixed in the proprietary 6u20 does *not* > impact OpenJDK 6. Probably because the Webstart code was never open-sourced... hey, there is a good side to it after all! :-) > -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From joe.darcy at oracle.com Fri Apr 16 09:35:31 2010 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 16 Apr 2010 09:35:31 -0700 Subject: Test Backports In-Reply-To: References: <17c6771e1003291310u3e1b3231i6a054fd76bc24182@mail.gmail.com> <4BBF561E.2070801@oracle.com> <8351CCF8-B710-4443-96BD-C9604505CF85@oracle.com> <4BC665FE.3080903@oracle.com> <4BC7B8D8.5010105@oracle.com> Message-ID: <4BC891D3.4030906@oracle.com> Andrew John Hughes wrote: > On 16 April 2010 02:09, Joe Darcy wrote: > >> Andrew John Hughes wrote: >> >>> On 15 April 2010 02:03, Joe Darcy wrote: >>> >>> >>>> On 04/11/10 01:42 PM, Andrew John Hughes wrote: >>>> >>>> On 10 April 2010 03:40, Kelly O'Hair wrote: >>>> >>>> >>>> On Apr 9, 2010, at 7:20 PM, Andrew John Hughes wrote: >>>> >>>> >>>> >>>> On 10 April 2010 01:48, Kelly O'Hair wrote: >>>> >>>> >>>> On Apr 9, 2010, at 5:05 PM, Andrew John Hughes wrote: >>>> >>>> >>>> >>>> Just waiting on Kelly's reponse now wrt. the HotSpot source/target fix. >>>> >>>> >>>> >>>> Can you clarify what response you are waiting on? >>>> >>>> >>>> >>>> Yes, sorry it's this one: >>>> http://mail.openjdk.java.net/pipermail/jdk6-dev/2010-April/001464.html >>>> >>>> It wasn't clear whether you were ok with the HotSpot change or wanted >>>> more time to review. The patch is pretty much as-is in OpenJDK7, the >>>> only difference being the version change from 6 to 5. >>>> >>>> >>>> The hotspot file changes look ok, but I have no idea how the hotspot >>>> changes are being handled for openjdk6. >>>> >>>> >>>> We regularly import from the stablisation branches: >>>> >>>> http://hg.openjdk.java.net/hsx/hsx14/master/ (OpenJDK6 b17 & b18) >>>> http://hg.openjdk.java.net/hsx/hsx16/master/ (OpenJDK6 b19) >>>> http://hg.openjdk.java.net/hsx/hsx17/master/ (OpenJDK6 b20?) >>>> >>>> The last one, hs17, includes the OpenJDK7 version of this fix. >>>> Including an OpenJDK6 version now with 1.5 source and target versions >>>> has the advantage that we won't bring in a version that requires >>>> source and target versions of 1.6 from hs17. >>>> >>>> Joe, does b20 sound appropriate for hs17? I know it's a bit soon >>>> after hs16, but the proprietary JDK6 is already moving towards this >>>> and we could do with catching up. It will be take time for such an >>>> OpenJDK6 release to roll through into an IcedTea6 release and then the >>>> distros anyway, so I'd prefer sooner rather than later. >>>> >>>> >>>> >>>> I'm not sure of the timeline for hs17. >>>> >>>> At some point, the copyright notices in the OpenJDK 6 repo will be >>>> changed >>>> from Sun -> Oracle. A more general announcement about this process and >>>> the >>>> new conventions will be forthcoming. >>>> >>>> >>> This has already happened in hs17. I queried the rather strange >>> ranges used on the new notices earlier this week. >>> >>> Making these copyright changes, at >>> >>> >>>> least in the langtools and jdk repos, might warrant a separate build with >>>> just those changes, in which case the upgrade of the HotSpot sources to >>>> HS >>>> 17 (with changed copyrights?) might occur in build 21 or later. >>>> >>>> >>>> >>> Do we really need a new build just for that? I doubt we'd bother >>> upgrading IcedTea6 to such a build just for that change. >>> >>> >>> >> I don't think a new build number is strictly required for the copyright >> change, but I think it makes the change easier to administer: "before build >> N, Sun copyrights; build N and later, Oracle copyrights." >> >> I agree there would be little motivation for IcedTea 6 to pick up that build >> just to get new copyright notices. >> >> -Joe >> >> >> > > Ok, do you have any idea when these changes will happen? My worry is > that this effectively means a block on OpenJDK6 activity until then. > I think this could be taken care of in the next two weeks. > Assuming we want b20 to be the N mentioned above, we could upgrade > HotSpot to 17 as part of b20, bringing with it both the new copyrights > and keeping us in sync with the proprietary JDK6 (hs17b13, the current > build, will be used in 6u21 b03 - > http://mail.openjdk.java.net/pipermail/hotspot-dev/2010-April/002843.html). > Then it really would be the case that all copyrights change in that > build and we also have a single new feature (hs17) too. The only > changes to langtools & jdk would be the copyrights. > > Does this sound sensible? Yes. > The alternative for HotSpot would be to > change the copyrights on the current OpenJDK6 version, which would > duplicate the work already done on hs17 and may make merging hs17 > harder. > I agree that path would be undesirable. > Will the copyrights in CORBA, JAXP and JAXWS be changing? > > Yes. For jaxp and jaxws, new source files will need to be generated. -Joe From ahughes at redhat.com Mon Apr 19 00:47:08 2010 From: ahughes at redhat.com (Andrew John Hughes) Date: Mon, 19 Apr 2010 08:47:08 +0100 Subject: Test Backports In-Reply-To: <4BC891D3.4030906@oracle.com> References: <17c6771e1003291310u3e1b3231i6a054fd76bc24182@mail.gmail.com> <8351CCF8-B710-4443-96BD-C9604505CF85@oracle.com> <4BC665FE.3080903@oracle.com> <4BC7B8D8.5010105@oracle.com> <4BC891D3.4030906@oracle.com> Message-ID: On 16 April 2010 17:35, Joe Darcy wrote: > Andrew John Hughes wrote: >> >> On 16 April 2010 02:09, Joe Darcy wrote: >> >>> >>> Andrew John Hughes wrote: >>> >>>> >>>> On 15 April 2010 02:03, Joe Darcy wrote: >>>> >>>> >>>>> >>>>> On 04/11/10 01:42 PM, Andrew John Hughes wrote: >>>>> >>>>> On 10 April 2010 03:40, Kelly O'Hair wrote: >>>>> >>>>> >>>>> On Apr 9, 2010, at 7:20 PM, Andrew John Hughes wrote: >>>>> >>>>> >>>>> >>>>> On 10 April 2010 01:48, Kelly O'Hair wrote: >>>>> >>>>> >>>>> On Apr 9, 2010, at 5:05 PM, Andrew John Hughes wrote: >>>>> >>>>> >>>>> >>>>> Just waiting on Kelly's reponse now wrt. the HotSpot source/target fix. >>>>> >>>>> >>>>> >>>>> Can you clarify what response you are waiting on? >>>>> >>>>> >>>>> >>>>> Yes, sorry it's this one: >>>>> http://mail.openjdk.java.net/pipermail/jdk6-dev/2010-April/001464.html >>>>> >>>>> It wasn't clear whether you were ok with the HotSpot change or wanted >>>>> more time to review. ?The patch is pretty much as-is in OpenJDK7, the >>>>> only difference being the version change from 6 to 5. >>>>> >>>>> >>>>> The hotspot file changes look ok, but I have no idea how the hotspot >>>>> changes are being handled for openjdk6. >>>>> >>>>> >>>>> We regularly import from the stablisation branches: >>>>> >>>>> http://hg.openjdk.java.net/hsx/hsx14/master/ (OpenJDK6 b17 & b18) >>>>> http://hg.openjdk.java.net/hsx/hsx16/master/ (OpenJDK6 b19) >>>>> http://hg.openjdk.java.net/hsx/hsx17/master/ (OpenJDK6 b20?) >>>>> >>>>> The last one, hs17, includes the OpenJDK7 version of this fix. >>>>> Including an OpenJDK6 version now with 1.5 source and target versions >>>>> has the advantage that we won't bring in a version that requires >>>>> source and target versions of 1.6 from hs17. >>>>> >>>>> Joe, does b20 sound appropriate for hs17? ?I know it's a bit soon >>>>> after hs16, but the proprietary JDK6 is already moving towards this >>>>> and we could do with catching up. ?It will be take time for such an >>>>> OpenJDK6 release to roll through into an IcedTea6 release and then the >>>>> distros anyway, so I'd prefer sooner rather than later. >>>>> >>>>> >>>>> >>>>> I'm not sure of the timeline for hs17. >>>>> >>>>> At some point, the copyright notices in the OpenJDK 6 repo will be >>>>> changed >>>>> from Sun -> Oracle. ?A more general announcement about this process and >>>>> the >>>>> new conventions will be forthcoming. >>>>> >>>>> >>>> >>>> This has already happened in hs17. ?I queried the rather strange >>>> ranges used on the new notices earlier this week. >>>> >>>> Making these copyright changes, at >>>> >>>> >>>>> >>>>> least in the langtools and jdk repos, might warrant a separate build >>>>> with >>>>> just those changes, in which case the upgrade of the HotSpot sources to >>>>> HS >>>>> 17 (with changed copyrights?) might occur in build 21 or later. >>>>> >>>>> >>>>> >>>> >>>> Do we really need a new build just for that? ?I doubt we'd bother >>>> upgrading IcedTea6 to such a build just for that change. >>>> >>>> >>>> >>> >>> I don't think a new build number is strictly required for the copyright >>> change, but I think it makes the change easier to administer: "before >>> build >>> N, Sun copyrights; build N and later, Oracle copyrights." >>> >>> I agree there would be little motivation for IcedTea 6 to pick up that >>> build >>> just to get new copyright notices. >>> >>> -Joe >>> >>> >>> >> >> Ok, do you have any idea when these changes will happen? ?My worry is >> that this effectively means a block on OpenJDK6 activity until then. >> > > I think this could be taken care of in the next two weeks. > >> Assuming we want b20 to be the N mentioned above, we could upgrade >> HotSpot to 17 as part of b20, bringing with it both the new copyrights >> and keeping us in sync with the proprietary JDK6 (hs17b13, the current >> build, will be used in 6u21 b03 - >> >> http://mail.openjdk.java.net/pipermail/hotspot-dev/2010-April/002843.html). >> ?Then it really would be the case that all copyrights change in that >> build and we also have a single new feature (hs17) too. ?The only >> changes to langtools & jdk would be the copyrights. >> >> Does this sound sensible? > > Yes. > Ok, I'll post a webrev when I'm back next week. >> ?The alternative for HotSpot would be to >> change the copyrights on the current OpenJDK6 version, which would >> duplicate the work already done on hs17 and may make merging hs17 >> harder. >> > > I agree that path would be undesirable. > >> Will the copyrights in CORBA, JAXP and JAXWS be changing? >> >> > > Yes. ?For jaxp and jaxws, new source files will need to be generated. > > -Joe > -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From joe.darcy at oracle.com Tue Apr 27 17:55:11 2010 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 27 Apr 2010 17:55:11 -0700 Subject: Regression test results on latest pre-b19 -- repos tagged with b19 - b19 complete! In-Reply-To: References: <4BC3500A.7060106@oracle.com> <4BC37E13.8030104@oracle.com> <4BC6367A.5010006@sun.com> <4BC7CCAB.20205@sun.com> Message-ID: <4BD7876F.4010803@oracle.com> On 04/16/10 06:31 AM, Andrew John Hughes wrote: > On 16 April 2010 03:34, Joseph D. Darcy wrote: > >> Joseph D. Darcy wrote: >> >>> Joe Darcy wrote: >>> >>>> Andrew John Hughes wrote: >>>> >>>>> On 12 April 2010 17:53, Joe Darcy wrote: >>>>> >>>>> >>>>>> Hello. >>>>>> >>>>>> I did a fresh build with all the latest changes and ran the regression >>>>>> test >>>>>> suite. As before, all the HotSpot and langtools tests pass. I think >>>>>> these >>>>>> results are good enough for b19. >>>>>> >>>>>> >>> [snip] >>> >>> >>>>>> -Joe >>>>>> >>>>>> >>>>>> >>>>> Looks good to me. I don't see any regressions (pass-->fail). >>>>> >>>>> >>>> And there are lots more passing tests :-) >>>> >>>> Other than the Gervill fix under review, I don't have any other >>>> outstanding changes to get into b19. Assuming the Gervill fix goes back >>>> soon and the test results are consistent, I'll label the repos post-fix as >>>> b19. >>>> >>>> >>> The tests results were consistent as expected. I've tagged the repos with >>> b19 and the usual source bundles, etc. should follow within a few days. >>> >>> >> Source bundles posted: >> http://download.java.net/openjdk/jdk6/promoted/b19/openjdk-6-src-b19-15_apr_2010.tar.gz >> >> OpenJDK 6 build 19 is done, on to build 20! >> >> > > IcedTea6 now bumped to b19 too. > > >> As implied in some other recent messages to the list, I was considering >> having OpenJDK 6 build 20 be dedicated to updating the copyrights in the >> repositories from Sun -> Oracle. That is not terribly compelling >> technically, but it would make the administration of this change easier. >> >> In the next build open to technical changes, what changes are of interest? >> >> > > hs17 would be my primary one, though as I suggested in another mail, > it may make more sense to include this in the license updating. > > There's a fix I just posted to tl which needs backporting: > http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c444651077d2 > > I need to review what we have in IcedTea6 to see what else is needed. > I've confirmed with Brad this fix is good for OpenJDK 6 too. If the fix is important, we can include it with the copyright updates; otherwise it can be deferred until b21. -Joe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/jdk6-dev/attachments/20100427/00d93209/attachment.html From ptisnovs at redhat.com Wed Apr 28 05:10:43 2010 From: ptisnovs at redhat.com (Pavel Tisnovsky) Date: Wed, 28 Apr 2010 14:10:43 +0200 Subject: JTreg errors in OpenJDK6 - missing HTML files Message-ID: <4BD825C3.8060207@redhat.com> Hi, I saw that some JTreg tests, specifically: java/awt/Focus/ActualFocusedWindowTest/ActualFocusedWindowBlockingTest.java java/awt/Focus/ActualFocusedWindowTest/ActualFocusedWindowRetaining.java java/awt/Focus/NonFocusableWindowTest/NonfocusableOwnerTest.java fails due to absence of HTML files from which these tests are started as applets. There are some error messages: Error. Can't find HTML file: /jck/icedtea6/openjdk/jdk/test/java/awt/Focus/ActualFocusedWindowTest/ActualFocusedWindowBlockingTest.html Error. Can't find HTML file: /jck/icedtea6/openjdk/jdk/test/java/awt/Focus/ActualFocusedWindowTest/ActualFocusedWindowRetaining.html Error. Can't find HTML file: /jck/icedtea6/openjdk/jdk/test/java/awt/Focus/NonFocusableWindowTest/NonfocusableOwnerTest.html May I write the required HTML files or are these files missing due to some improper commit? Cheers Pavel From ahughes at redhat.com Wed Apr 28 06:14:11 2010 From: ahughes at redhat.com (Andrew John Hughes) Date: Wed, 28 Apr 2010 14:14:11 +0100 Subject: JTreg errors in OpenJDK6 - missing HTML files In-Reply-To: <4BD825C3.8060207@redhat.com> References: <4BD825C3.8060207@redhat.com> Message-ID: On 28 April 2010 13:10, Pavel Tisnovsky wrote: > Hi, > > I saw that some JTreg tests, specifically: > > java/awt/Focus/ActualFocusedWindowTest/ActualFocusedWindowBlockingTest.java > java/awt/Focus/ActualFocusedWindowTest/ActualFocusedWindowRetaining.java > ?java/awt/Focus/NonFocusableWindowTest/NonfocusableOwnerTest.java > > fails due to absence of HTML files from which these tests are started as > applets. > > There are some error messages: > Error. Can't find HTML file: > /jck/icedtea6/openjdk/jdk/test/java/awt/Focus/ActualFocusedWindowTest/ActualFocusedWindowBlockingTest.html > Error. Can't find HTML file: > /jck/icedtea6/openjdk/jdk/test/java/awt/Focus/ActualFocusedWindowTest/ActualFocusedWindowRetaining.html > Error. Can't find HTML file: > /jck/icedtea6/openjdk/jdk/test/java/awt/Focus/NonFocusableWindowTest/NonfocusableOwnerTest.html > > May I write the required HTML files or are these files missing due to some > improper commit? > > Cheers > Pavel > I think this fix needs to be backported: changeset: 202:4a6dd11fe9fc user: ant date: Wed Mar 26 17:38:26 2008 +0300 summary: 6616792: five AWT focus regression tests should be fixed http://hg.openjdk.java.net/jdk7/jdk7/jdk/rev/4a6dd11fe9fc Joe, ok for OpenJDK6? -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From joe.darcy at oracle.com Thu Apr 29 10:40:11 2010 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 29 Apr 2010 10:40:11 -0700 Subject: JTreg errors in OpenJDK6 - missing HTML files In-Reply-To: References: <4BD825C3.8060207@redhat.com> Message-ID: <4BD9C47B.3060505@oracle.com> Hello. On 04/28/10 06:14 AM, Andrew John Hughes wrote: > On 28 April 2010 13:10, Pavel Tisnovsky wrote: > >> Hi, >> >> I saw that some JTreg tests, specifically: >> >> java/awt/Focus/ActualFocusedWindowTest/ActualFocusedWindowBlockingTest.java >> java/awt/Focus/ActualFocusedWindowTest/ActualFocusedWindowRetaining.java >> java/awt/Focus/NonFocusableWindowTest/NonfocusableOwnerTest.java >> >> fails due to absence of HTML files from which these tests are started as >> applets. >> I looked into those error messages a little bit; the corresponding tests pass fine on JDK 7 and JDK 7 doesn't have the *.html files reported as missing in OpenJDK 6. >> There are some error messages: >> Error. Can't find HTML file: >> /jck/icedtea6/openjdk/jdk/test/java/awt/Focus/ActualFocusedWindowTest/ActualFocusedWindowBlockingTest.html >> Error. Can't find HTML file: >> /jck/icedtea6/openjdk/jdk/test/java/awt/Focus/ActualFocusedWindowTest/ActualFocusedWindowRetaining.html >> Error. Can't find HTML file: >> /jck/icedtea6/openjdk/jdk/test/java/awt/Focus/NonFocusableWindowTest/NonfocusableOwnerTest.html >> >> May I write the required HTML files or are these files missing due to some >> improper commit? >> >> Cheers >> Pavel >> >> > > I think this fix needs to be backported: > > changeset: 202:4a6dd11fe9fc > user: ant > date: Wed Mar 26 17:38:26 2008 +0300 > summary: 6616792: five AWT focus regression tests should be fixed > http://hg.openjdk.java.net/jdk7/jdk7/jdk/rev/4a6dd11fe9fc > > Joe, ok for OpenJDK6? > If applying the patch resolves the test failures, I approve it going back now. I've been thinking a bit more about the changes to accept for this build. Other than the copyright changes (a general message about those coming soon), I think it would be helpful to also take back any fixes from JDK 7 applied to IcedTea but not OpenJDK 6, etc., before the copyright swap occurs. -Joe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/jdk6-dev/attachments/20100429/ce088fbe/attachment.html From joe.darcy at oracle.com Thu Apr 29 10:41:44 2010 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 29 Apr 2010 10:41:44 -0700 Subject: Regression test results on latest pre-b19 -- repos tagged with b19 - b19 complete! In-Reply-To: References: <4BC3500A.7060106@oracle.com> <4BC37E13.8030104@oracle.com> <4BC6367A.5010006@sun.com> <4BC7CCAB.20205@sun.com> Message-ID: <4BD9C4D8.2040502@oracle.com> On 04/16/10 06:31 AM, Andrew John Hughes wrote: > On 16 April 2010 03:34, Joseph D. Darcy wrote: > >> Joseph D. Darcy wrote: >> >>> Joe Darcy wrote: >>> >>>> Andrew John Hughes wrote: >>>> >>>>> On 12 April 2010 17:53, Joe Darcy wrote: >>>>> >>>>> >>>>>> Hello. >>>>>> >>>>>> I did a fresh build with all the latest changes and ran the regression >>>>>> test >>>>>> suite. As before, all the HotSpot and langtools tests pass. I think >>>>>> these >>>>>> results are good enough for b19. >>>>>> >>>>>> >>> [snip] >>> >>> >>>>>> -Joe >>>>>> >>>>>> >>>>>> >>>>> Looks good to me. I don't see any regressions (pass-->fail). >>>>> >>>>> >>>> And there are lots more passing tests :-) >>>> >>>> Other than the Gervill fix under review, I don't have any other >>>> outstanding changes to get into b19. Assuming the Gervill fix goes back >>>> soon and the test results are consistent, I'll label the repos post-fix as >>>> b19. >>>> >>>> >>> The tests results were consistent as expected. I've tagged the repos with >>> b19 and the usual source bundles, etc. should follow within a few days. >>> >>> >> Source bundles posted: >> http://download.java.net/openjdk/jdk6/promoted/b19/openjdk-6-src-b19-15_apr_2010.tar.gz >> >> OpenJDK 6 build 19 is done, on to build 20! >> >> > > IcedTea6 now bumped to b19 too. > > >> As implied in some other recent messages to the list, I was considering >> having OpenJDK 6 build 20 be dedicated to updating the copyrights in the >> repositories from Sun -> Oracle. That is not terribly compelling >> technically, but it would make the administration of this change easier. >> >> In the next build open to technical changes, what changes are of interest? >> >> > > hs17 would be my primary one, though as I suggested in another mail, > it may make more sense to include this in the license updating. > > There's a fix I just posted to tl which needs backporting: > http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c444651077d2 > > I need to review what we have in IcedTea6 to see what else is needed. > Yes, I agree undertaking such a review now is prudent. I've verified with Brad the fix in question is appropriate for OpenJDK 6 and I approve it going back now. -Joe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/jdk6-dev/attachments/20100429/a4a0ee31/attachment.html From ahughes at redhat.com Thu Apr 29 16:24:58 2010 From: ahughes at redhat.com (ahughes at redhat.com) Date: Thu, 29 Apr 2010 23:24:58 +0000 Subject: hg: jdk6/jdk6/jdk: 2 new changesets Message-ID: <20100429232515.1D62344390@hg.openjdk.java.net> Changeset: 4684c385160e Author: ant Date: 2008-03-26 17:38 +0300 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/4684c385160e 6616792: five AWT focus regression tests should be fixed Summary: Fixed/refactored the tests. Reviewed-by: volk ! test/java/awt/Focus/ActualFocusedWindowTest/ActualFocusedWindowBlockingTest.java ! test/java/awt/Focus/ActualFocusedWindowTest/ActualFocusedWindowRetaining.java ! test/java/awt/Focus/FrameJumpingToMouse/FrameJumpingToMouse.java + test/java/awt/Focus/NonFocusableWindowTest/NoEventsTest.java ! test/java/awt/Focus/NonFocusableWindowTest/NonfocusableOwnerTest.java - test/java/awt/Focus/NonFocusableWindowTest/Test.java ! test/java/awt/Focus/TypeAhead/TestFocusFreeze.java ! test/java/awt/Focus/WrongKeyTypedConsumedTest/WrongKeyTypedConsumedTest.java Changeset: c3a035784a3a Author: andrew Date: 2010-04-16 09:54 +0100 URL: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/c3a035784a3a 6944361: Missing CKR_ values in PKCS11Exception Summary: Allow native NSS errors to be observed and correctly reported Reviewed-by: wetmore, valeriep ! src/share/classes/sun/security/pkcs11/wrapper/PKCS11Exception.java ! src/share/classes/sun/security/x509/X509Key.java From ahughes at redhat.com Thu Apr 29 16:38:50 2010 From: ahughes at redhat.com (Andrew John Hughes) Date: Fri, 30 Apr 2010 00:38:50 +0100 Subject: JTreg errors in OpenJDK6 - missing HTML files In-Reply-To: <4BD9C47B.3060505@oracle.com> References: <4BD825C3.8060207@redhat.com> <4BD9C47B.3060505@oracle.com> Message-ID: On 29 April 2010 18:40, Joe Darcy wrote: > Hello. > > On 04/28/10 06:14 AM, Andrew John Hughes wrote: > > On 28 April 2010 13:10, Pavel Tisnovsky wrote: > > > Hi, > > I saw that some JTreg tests, specifically: > > java/awt/Focus/ActualFocusedWindowTest/ActualFocusedWindowBlockingTest.java > java/awt/Focus/ActualFocusedWindowTest/ActualFocusedWindowRetaining.java > ?java/awt/Focus/NonFocusableWindowTest/NonfocusableOwnerTest.java > > fails due to absence of HTML files from which these tests are started as > applets. > > > I looked into those error messages a little bit; the corresponding tests > pass fine on JDK 7 and JDK 7 doesn't have the *.html files reported as > missing in OpenJDK 6. > > There are some error messages: > Error. Can't find HTML file: > /jck/icedtea6/openjdk/jdk/test/java/awt/Focus/ActualFocusedWindowTest/ActualFocusedWindowBlockingTest.html > Error. Can't find HTML file: > /jck/icedtea6/openjdk/jdk/test/java/awt/Focus/ActualFocusedWindowTest/ActualFocusedWindowRetaining.html > Error. Can't find HTML file: > /jck/icedtea6/openjdk/jdk/test/java/awt/Focus/NonFocusableWindowTest/NonfocusableOwnerTest.html > > May I write the required HTML files or are these files missing due to some > improper commit? > > Cheers > Pavel > > > > I think this fix needs to be backported: > > changeset: 202:4a6dd11fe9fc > user: ant > date: Wed Mar 26 17:38:26 2008 +0300 > summary: 6616792: five AWT focus regression tests should be fixed > http://hg.openjdk.java.net/jdk7/jdk7/jdk/rev/4a6dd11fe9fc > > Joe, ok for OpenJDK6? > > > If applying the patch resolves the test failures, I approve it going back > now. It syncs the tests with JDK7, removing the HTML file references. Pushed: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/4684c385160e > > I've been thinking a bit more about the changes to accept for this build. > Other than the copyright changes (a general message about those coming > soon), I think it would be helpful to also take back any fixes from JDK 7 > applied to IcedTea but not OpenJDK 6, etc., before the copyright swap > occurs. > I'll take a look next week, though I think most IcedTea patches are in neither version of OpenJDK at present (most backports have been pushed upstream). > -Joe > -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From joe.darcy at oracle.com Thu Apr 29 16:50:28 2010 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 29 Apr 2010 16:50:28 -0700 Subject: JTreg errors in OpenJDK6 - missing HTML files In-Reply-To: References: <4BD825C3.8060207@redhat.com> <4BD9C47B.3060505@oracle.com> Message-ID: <4BDA1B44.8020207@oracle.com> On 04/29/10 04:38 PM, Andrew John Hughes wrote: > On 29 April 2010 18:40, Joe Darcy wrote: > >> Hello. >> >> On 04/28/10 06:14 AM, Andrew John Hughes wrote: >> >> On 28 April 2010 13:10, Pavel Tisnovsky wrote: >> >> >> Hi, >> >> I saw that some JTreg tests, specifically: >> >> java/awt/Focus/ActualFocusedWindowTest/ActualFocusedWindowBlockingTest.java >> java/awt/Focus/ActualFocusedWindowTest/ActualFocusedWindowRetaining.java >> java/awt/Focus/NonFocusableWindowTest/NonfocusableOwnerTest.java >> >> fails due to absence of HTML files from which these tests are started as >> applets. >> >> >> I looked into those error messages a little bit; the corresponding tests >> pass fine on JDK 7 and JDK 7 doesn't have the *.html files reported as >> missing in OpenJDK 6. >> >> There are some error messages: >> Error. Can't find HTML file: >> /jck/icedtea6/openjdk/jdk/test/java/awt/Focus/ActualFocusedWindowTest/ActualFocusedWindowBlockingTest.html >> Error. Can't find HTML file: >> /jck/icedtea6/openjdk/jdk/test/java/awt/Focus/ActualFocusedWindowTest/ActualFocusedWindowRetaining.html >> Error. Can't find HTML file: >> /jck/icedtea6/openjdk/jdk/test/java/awt/Focus/NonFocusableWindowTest/NonfocusableOwnerTest.html >> >> May I write the required HTML files or are these files missing due to some >> improper commit? >> >> Cheers >> Pavel >> >> >> >> I think this fix needs to be backported: >> >> changeset: 202:4a6dd11fe9fc >> user: ant >> date: Wed Mar 26 17:38:26 2008 +0300 >> summary: 6616792: five AWT focus regression tests should be fixed >> http://hg.openjdk.java.net/jdk7/jdk7/jdk/rev/4a6dd11fe9fc >> >> Joe, ok for OpenJDK6? >> >> >> If applying the patch resolves the test failures, I approve it going back >> now. >> > > It syncs the tests with JDK7, removing the HTML file references. > > Pushed: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/4684c385160e > > Thanks. >> I've been thinking a bit more about the changes to accept for this build. >> Other than the copyright changes (a general message about those coming >> soon), I think it would be helpful to also take back any fixes from JDK 7 >> applied to IcedTea but not OpenJDK 6, etc., before the copyright swap >> occurs. >> >> > > I'll take a look next week, though I think most IcedTea patches are in > neither version of OpenJDK at present (most backports have been pushed > upstream). > > Acknowledged. -Joe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/jdk6-dev/attachments/20100429/e4776489/attachment.html From ptisnovs at redhat.com Fri Apr 30 00:17:29 2010 From: ptisnovs at redhat.com (Pavel Tisnovsky) Date: Fri, 30 Apr 2010 09:17:29 +0200 Subject: JTreg errors in OpenJDK6 - missing HTML files In-Reply-To: <4BD9C47B.3060505@oracle.com> References: <4BD825C3.8060207@redhat.com> <4BD9C47B.3060505@oracle.com> Message-ID: <4BDA8409.3030603@redhat.com> Joe Darcy wrote: > Hello. > > On 04/28/10 06:14 AM, Andrew John Hughes wrote: >> On 28 April 2010 13:10, Pavel Tisnovsky wrote: >> >>> Hi, >>> >>> I saw that some JTreg tests, specifically: >>> >>> java/awt/Focus/ActualFocusedWindowTest/ActualFocusedWindowBlockingTest.java >>> java/awt/Focus/ActualFocusedWindowTest/ActualFocusedWindowRetaining.java >>> java/awt/Focus/NonFocusableWindowTest/NonfocusableOwnerTest.java >>> >>> fails due to absence of HTML files from which these tests are started as >>> applets. >>> > > I looked into those error messages a little bit; the corresponding tests > pass fine on JDK 7 and JDK 7 doesn't have the *.html files reported as > missing in OpenJDK 6. The tests itself is different in JDK 7. While in JDK 6 these tests are started as applets in JDK 7 the tests are modified to run as regular Java application. > >>> There are some error messages: >>> Error. Can't find HTML file: >>> /jck/icedtea6/openjdk/jdk/test/java/awt/Focus/ActualFocusedWindowTest/ActualFocusedWindowBlockingTest.html >>> Error. Can't find HTML file: >>> /jck/icedtea6/openjdk/jdk/test/java/awt/Focus/ActualFocusedWindowTest/ActualFocusedWindowRetaining.html >>> Error. Can't find HTML file: >>> /jck/icedtea6/openjdk/jdk/test/java/awt/Focus/NonFocusableWindowTest/NonfocusableOwnerTest.html >>> >>> May I write the required HTML files or are these files missing due to some >>> improper commit? >>> >>> Cheers >>> Pavel >>> >>> >> I think this fix needs to be backported: >> >> changeset: 202:4a6dd11fe9fc >> user: ant >> date: Wed Mar 26 17:38:26 2008 +0300 >> summary: 6616792: five AWT focus regression tests should be fixed >> http://hg.openjdk.java.net/jdk7/jdk7/jdk/rev/4a6dd11fe9fc >> >> Joe, ok for OpenJDK6? >> > > If applying the patch resolves the test failures, I approve it going > back now. > > I've been thinking a bit more about the changes to accept for this > build. Other than the copyright changes (a general message about those > coming soon), I think it would be helpful to also take back any fixes > from JDK 7 applied to IcedTea but not OpenJDK 6, etc., before the > copyright swap occurs. > > -Joe From ptisnovs at redhat.com Fri Apr 30 02:22:09 2010 From: ptisnovs at redhat.com (Pavel Tisnovsky) Date: Fri, 30 Apr 2010 11:22:09 +0200 Subject: JTreg errors in OpenJDK6 - missing HTML files In-Reply-To: <4BD9C47B.3060505@oracle.com> References: <4BD825C3.8060207@redhat.com> <4BD9C47B.3060505@oracle.com> Message-ID: <4BDAA141.2070204@redhat.com> Joe Darcy wrote: > Hello. > > On 04/28/10 06:14 AM, Andrew John Hughes wrote: >> On 28 April 2010 13:10, Pavel Tisnovsky wrote: >> >>> Hi, >>> >>> I saw that some JTreg tests, specifically: >>> >>> java/awt/Focus/ActualFocusedWindowTest/ActualFocusedWindowBlockingTest.java >>> java/awt/Focus/ActualFocusedWindowTest/ActualFocusedWindowRetaining.java >>> java/awt/Focus/NonFocusableWindowTest/NonfocusableOwnerTest.java >>> >>> fails due to absence of HTML files from which these tests are started as >>> applets. >>> > > I looked into those error messages a little bit; the corresponding tests > pass fine on JDK 7 and JDK 7 doesn't have the *.html files reported as > missing in OpenJDK 6. > >>> There are some error messages: >>> Error. Can't find HTML file: >>> /jck/icedtea6/openjdk/jdk/test/java/awt/Focus/ActualFocusedWindowTest/ActualFocusedWindowBlockingTest.html >>> Error. Can't find HTML file: >>> /jck/icedtea6/openjdk/jdk/test/java/awt/Focus/ActualFocusedWindowTest/ActualFocusedWindowRetaining.html >>> Error. Can't find HTML file: >>> /jck/icedtea6/openjdk/jdk/test/java/awt/Focus/NonFocusableWindowTest/NonfocusableOwnerTest.html >>> >>> May I write the required HTML files or are these files missing due to some >>> improper commit? >>> >>> Cheers >>> Pavel >>> >>> >> I think this fix needs to be backported: >> >> changeset: 202:4a6dd11fe9fc >> user: ant >> date: Wed Mar 26 17:38:26 2008 +0300 >> summary: 6616792: five AWT focus regression tests should be fixed >> http://hg.openjdk.java.net/jdk7/jdk7/jdk/rev/4a6dd11fe9fc >> >> Joe, ok for OpenJDK6? >> > > If applying the patch resolves the test failures, I approve it going > back now. Hi Joe, should we create webrev for these changes? > > I've been thinking a bit more about the changes to accept for this > build. Other than the copyright changes (a general message about those > coming soon), I think it would be helpful to also take back any fixes > from JDK 7 applied to IcedTea but not OpenJDK 6, etc., before the > copyright swap occurs. > > -Joe From ptisnovs at redhat.com Fri Apr 30 06:07:13 2010 From: ptisnovs at redhat.com (Pavel Tisnovsky) Date: Fri, 30 Apr 2010 15:07:13 +0200 Subject: Request for change in JDK6 - proper ISO-8859-15 charset handling Message-ID: <4BDAD601.1040806@redhat.com> Hi, please review change in JDK6 which provides correct relationship between ISO-8859-1 and ISO-8859-15 charsets. The webrew is available at: http://cr.openjdk.java.net/~ptisnovs/ISO-8859-15/ This bug was closed and verified in JDK7 (http://bugs.sun.com/view_bug.do?bug_id=6798572) but not in JDK6, where the sources are a bit different. The correct/incorrect behaviour of charset relationship handling can be tested by regression test java/nio/charset/Charset/Contains.java Cheers Pavel Tisnovsky From xueming.shen at oracle.com Fri Apr 30 08:35:21 2010 From: xueming.shen at oracle.com (Xueming Shen) Date: Fri, 30 Apr 2010 08:35:21 -0700 Subject: [Fwd: Request for change in JDK6 - proper ISO-8859-15 charset handling] In-Reply-To: <4BDAD6FE.7020600@oracle.com> References: <4BDAD6FE.7020600@oracle.com> Message-ID: <4BDAF8B9.3040204@oracle.com> Hi Pavel, The change itself looks fine. This remind me that we have not brought in the test/java/nio/charset in openjdk6 repo yet. Thanks, Sherman > > > -------- Original Message -------- > Subject: Request for change in JDK6 - proper ISO-8859-15 charset > handling > Date: Fri, 30 Apr 2010 15:07:13 +0200 > From: Pavel Tisnovsky > To: jdk6-dev > > > > Hi, > > please review change in JDK6 which provides correct relationship between > ISO-8859-1 and ISO-8859-15 charsets. The webrew is available at: > http://cr.openjdk.java.net/~ptisnovs/ISO-8859-15/ > > This bug was closed and verified in JDK7 > (http://bugs.sun.com/view_bug.do?bug_id=6798572) but not in JDK6, where > the sources are a bit different. > > The correct/incorrect behaviour of charset relationship handling can be > tested by regression test java/nio/charset/Charset/Contains.java > > Cheers > Pavel Tisnovsky > From ptisnovs at redhat.com Fri Apr 30 09:32:09 2010 From: ptisnovs at redhat.com (Pavel Tisnovsky) Date: Fri, 30 Apr 2010 18:32:09 +0200 Subject: [Fwd: Request for change in JDK6 - proper ISO-8859-15 charset handling] In-Reply-To: <4BDAF8B9.3040204@oracle.com> References: <4BDAD6FE.7020600@oracle.com> <4BDAF8B9.3040204@oracle.com> Message-ID: <4BDB0609.3080101@redhat.com> Hi Xueming, may I use bug #6798572 to push changes to OpenJDK6? Only JDK7 is mentioned in this bug... Pavel Xueming Shen wrote: > Hi Pavel, > > The change itself looks fine. > > This remind me that we have not brought in the test/java/nio/charset in > openjdk6 repo yet. > > Thanks, > Sherman > >> >> >> -------- Original Message -------- >> Subject: Request for change in JDK6 - proper ISO-8859-15 charset >> handling >> Date: Fri, 30 Apr 2010 15:07:13 +0200 >> From: Pavel Tisnovsky >> To: jdk6-dev >> >> >> >> Hi, >> >> please review change in JDK6 which provides correct relationship >> between ISO-8859-1 and ISO-8859-15 charsets. The webrew is available at: >> http://cr.openjdk.java.net/~ptisnovs/ISO-8859-15/ >> >> This bug was closed and verified in JDK7 >> (http://bugs.sun.com/view_bug.do?bug_id=6798572) but not in JDK6, >> where the sources are a bit different. >> >> The correct/incorrect behaviour of charset relationship handling can >> be tested by regression test java/nio/charset/Charset/Contains.java >> >> Cheers >> Pavel Tisnovsky >> > From joe.darcy at oracle.com Fri Apr 30 09:51:49 2010 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 30 Apr 2010 09:51:49 -0700 Subject: JTreg errors in OpenJDK6 - missing HTML files In-Reply-To: <4BDAA141.2070204@redhat.com> References: <4BD825C3.8060207@redhat.com> <4BD9C47B.3060505@oracle.com> <4BDAA141.2070204@redhat.com> Message-ID: <4BDB0AA5.7080602@oracle.com> Pavel Tisnovsky wrote: > Joe Darcy wrote: >> Hello. >> >> On 04/28/10 06:14 AM, Andrew John Hughes wrote: >>> On 28 April 2010 13:10, Pavel Tisnovsky >>> wrote: >>> >>>> Hi, >>>> >>>> I saw that some JTreg tests, specifically: >>>> >>>> java/awt/Focus/ActualFocusedWindowTest/ActualFocusedWindowBlockingTest.java >>>> >>>> java/awt/Focus/ActualFocusedWindowTest/ActualFocusedWindowRetaining.java >>>> >>>> java/awt/Focus/NonFocusableWindowTest/NonfocusableOwnerTest.java >>>> >>>> fails due to absence of HTML files from which these tests are >>>> started as >>>> applets. >>>> >> >> I looked into those error messages a little bit; the corresponding >> tests pass fine on JDK 7 and JDK 7 doesn't have the *.html files >> reported as missing in OpenJDK 6. >> >>>> There are some error messages: >>>> Error. Can't find HTML file: >>>> /jck/icedtea6/openjdk/jdk/test/java/awt/Focus/ActualFocusedWindowTest/ActualFocusedWindowBlockingTest.html >>>> >>>> Error. Can't find HTML file: >>>> /jck/icedtea6/openjdk/jdk/test/java/awt/Focus/ActualFocusedWindowTest/ActualFocusedWindowRetaining.html >>>> >>>> Error. Can't find HTML file: >>>> /jck/icedtea6/openjdk/jdk/test/java/awt/Focus/NonFocusableWindowTest/NonfocusableOwnerTest.html >>>> >>>> >>>> May I write the required HTML files or are these files missing due >>>> to some >>>> improper commit? >>>> >>>> Cheers >>>> Pavel >>>> >>>> >>> I think this fix needs to be backported: >>> >>> changeset: 202:4a6dd11fe9fc >>> user: ant >>> date: Wed Mar 26 17:38:26 2008 +0300 >>> summary: 6616792: five AWT focus regression tests should be fixed >>> http://hg.openjdk.java.net/jdk7/jdk7/jdk/rev/4a6dd11fe9fc >>> >>> Joe, ok for OpenJDK6? >>> >> >> If applying the patch resolves the test failures, I approve it going >> back now. > > Hi Joe, > > should we create webrev for these changes? > Since the change has already been pushed, I don't think that is necessary :-) If a change is a small, straight backport that applies cleanly, the release-specific webrev often can be skipped. -Joe From joe.darcy at oracle.com Fri Apr 30 10:06:44 2010 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 30 Apr 2010 10:06:44 -0700 Subject: [Fwd: Request for change in JDK6 - proper ISO-8859-15 charset handling] In-Reply-To: <4BDB0609.3080101@redhat.com> References: <4BDAD6FE.7020600@oracle.com> <4BDAF8B9.3040204@oracle.com> <4BDB0609.3080101@redhat.com> Message-ID: <4BDB0E24.5050106@oracle.com> Pavel Tisnovsky wrote: > Hi Xueming, > > may I use bug #6798572 to push changes to OpenJDK6? Only JDK7 is > mentioned in this bug... Per the OpenJDK 6 processes (http://openjdk.java.net/projects/jdk6/), the approval of the release manager (currently me) is also needed for all changes before they go back. Given that Sherman has reviewed the technical contents of the change, I also approve it going back as long as the now-failing regression test java/nio/charset/Charset/Contains.java is updated to include 6798572 in its @bug line. > > Pavel > > Xueming Shen wrote: >> Hi Pavel, >> >> The change itself looks fine. >> >> This remind me that we have not brought in the test/java/nio/charset >> in openjdk6 repo yet. Actually Andrew John Hughes ported the tests from JDK 7 to OpenJDK 6 in b19: http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/83980d94b138 Cheers, -Joe >> Thanks, >> Sherman >> >>> >>> >>> -------- Original Message -------- >>> Subject: Request for change in JDK6 - proper ISO-8859-15 charset >>> handling >>> Date: Fri, 30 Apr 2010 15:07:13 +0200 >>> From: Pavel Tisnovsky >>> To: jdk6-dev >>> >>> >>> >>> Hi, >>> >>> please review change in JDK6 which provides correct relationship >>> between ISO-8859-1 and ISO-8859-15 charsets. The webrew is available >>> at: >>> http://cr.openjdk.java.net/~ptisnovs/ISO-8859-15/ >>> >>> This bug was closed and verified in JDK7 >>> (http://bugs.sun.com/view_bug.do?bug_id=6798572) but not in JDK6, >>> where the sources are a bit different. >>> >>> The correct/incorrect behaviour of charset relationship handling can >>> be tested by regression test java/nio/charset/Charset/Contains.java >>> >>> Cheers >>> Pavel Tisnovsky >>> >> > From xueming.shen at oracle.com Fri Apr 30 10:37:14 2010 From: xueming.shen at oracle.com (Xueming Shen) Date: Fri, 30 Apr 2010 10:37:14 -0700 Subject: [Fwd: Request for change in JDK6 - proper ISO-8859-15 charset handling] In-Reply-To: <4BDB0E24.5050106@oracle.com> References: <4BDAD6FE.7020600@oracle.com> <4BDAF8B9.3040204@oracle.com> <4BDB0609.3080101@redhat.com> <4BDB0E24.5050106@oracle.com> Message-ID: <4BDB154A.9050503@oracle.com> Joe Darcy wrote: > >> >> Pavel >> >> Xueming Shen wrote: >>> Hi Pavel, >>> >>> The change itself looks fine. >>> >>> This remind me that we have not brought in the test/java/nio/charset >>> in openjdk6 repo yet. > > Actually Andrew John Hughes ported the tests from JDK 7 to OpenJDK 6 > in b19: > http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/83980d94b138 > Oops. I just checked my OpenJDK6 ws when reviewed change, which is obvious very "old". -Sherman From Joe.Darcy at Sun.COM Fri Apr 30 10:49:38 2010 From: Joe.Darcy at Sun.COM (Joseph D. Darcy) Date: Fri, 30 Apr 2010 10:49:38 -0700 Subject: Some backports of langtools bug fixes likely for b20 Message-ID: <4BDB1832.20500@sun.com> Hello. FYI, there are a few fixes to langtools that have been made in JDK 7 there are we are considering backporting the OpenJDK 6 b20: 6548436 java/compiler: Incorrect inconvertible types error 6920317 java/compiler: package-info.java file has to be specified on the javac cmdline, else it will not be avail. 6948251: need to quote args in langtools launcher script -Joe From jonathan.gibbons at oracle.com Fri Apr 30 12:06:18 2010 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 30 Apr 2010 12:06:18 -0700 Subject: Some backports of langtools bug fixes likely for b20 In-Reply-To: <4BDB1832.20500@sun.com> References: <4BDB1832.20500@sun.com> Message-ID: <4BDB2A2A.9040409@oracle.com> Joseph D. Darcy wrote: > Hello. > > FYI, there are a few fixes to langtools that have been made in JDK 7 > there are we are considering backporting the OpenJDK 6 b20: > > 6548436 java/compiler: Incorrect inconvertible types error > 6920317 java/compiler: package-info.java file has to be specified on > the javac cmdline, else it will not be avail. > 6948251: need to quote args in langtools launcher script > > -Joe Joe, I would like to include 6916986: handle spaces in langtools launcher path The combination of 6916986 and 6948251 will bring src/share/bin/launcher.sh-template up to date in 6-open with 7. -- Jon From joe.darcy at oracle.com Fri Apr 30 12:09:46 2010 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 30 Apr 2010 12:09:46 -0700 Subject: Some backports of langtools bug fixes likely for b20 In-Reply-To: <4BDB2A2A.9040409@oracle.com> References: <4BDB1832.20500@sun.com> <4BDB2A2A.9040409@oracle.com> Message-ID: <4BDB2AFA.5040908@oracle.com> Jonathan Gibbons wrote: > Joseph D. Darcy wrote: >> Hello. >> >> FYI, there are a few fixes to langtools that have been made in JDK 7 >> there are we are considering backporting the OpenJDK 6 b20: >> >> 6548436 java/compiler: Incorrect inconvertible types error >> 6920317 java/compiler: package-info.java file has to be specified on >> the javac cmdline, else it will not be avail. >> 6948251: need to quote args in langtools launcher script >> >> -Joe > > Joe, > > I would like to include > 6916986: handle spaces in langtools launcher path > > The combination of 6916986 and 6948251 will bring > src/share/bin/launcher.sh-template up to date in 6-open with 7. > Sounds good; 6916986 and 6948251 and approved to be ported to OpenJDK 6. Thanks, -Joe From jonathan.gibbons at sun.com Fri Apr 30 12:26:00 2010 From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com) Date: Fri, 30 Apr 2010 19:26:00 +0000 Subject: hg: jdk6/jdk6/langtools: 2 new changesets Message-ID: <20100430192603.CC8344455C@hg.openjdk.java.net> Changeset: 5ad939c11037 Author: jjg Date: 2010-01-14 17:23 -0800 URL: http://hg.openjdk.java.net/jdk6/jdk6/langtools/rev/5ad939c11037 6916986: handle spaces in langtools launcher path Reviewed-by: darcy, jjg Contributed-by: mali at csail.mit.edu, mernst at cs.washington.edu ! src/share/bin/launcher.sh-template Changeset: 6010c91842f0 Author: jjg Date: 2010-04-29 14:25 -0700 URL: http://hg.openjdk.java.net/jdk6/jdk6/langtools/rev/6010c91842f0 6948251: need to quote args in langtools launcher script Reviewed-by: darcy ! src/share/bin/launcher.sh-template From jonathan.gibbons at oracle.com Fri Apr 30 14:19:08 2010 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 30 Apr 2010 14:19:08 -0700 Subject: Some backports of langtools bug fixes likely for b20 In-Reply-To: <4BDB2AFA.5040908@oracle.com> References: <4BDB1832.20500@sun.com> <4BDB2A2A.9040409@oracle.com> <4BDB2AFA.5040908@oracle.com> Message-ID: <4BDB494C.1020506@oracle.com> Joe Darcy wrote: > Jonathan Gibbons wrote: >> Joseph D. Darcy wrote: >>> Hello. >>> >>> FYI, there are a few fixes to langtools that have been made in JDK 7 >>> there are we are considering backporting the OpenJDK 6 b20: >>> >>> 6548436 java/compiler: Incorrect inconvertible types error >>> 6920317 java/compiler: package-info.java file has to be specified on >>> the javac cmdline, else it will not be avail. >>> 6948251: need to quote args in langtools launcher script >>> >>> -Joe >> >> Joe, >> >> I would like to include >> 6916986: handle spaces in langtools launcher path >> >> The combination of 6916986 and 6948251 will bring >> src/share/bin/launcher.sh-template up to date in 6-open with 7. >> > > Sounds good; 6916986 and 6948251 and approved to be ported to OpenJDK 6. > > Thanks, > > -Joe > Joe, How about 6548436 -- fix for 7 applies cleanly to 6-open. -- Jon From joe.darcy at oracle.com Fri Apr 30 14:47:51 2010 From: joe.darcy at oracle.com (Joe Darcy) Date: Fri, 30 Apr 2010 14:47:51 -0700 Subject: Some backports of langtools bug fixes likely for b20 In-Reply-To: <4BDB494C.1020506@oracle.com> References: <4BDB1832.20500@sun.com> <4BDB2A2A.9040409@oracle.com> <4BDB2AFA.5040908@oracle.com> <4BDB494C.1020506@oracle.com> Message-ID: <4BDB5007.3060803@oracle.com> On 04/30/10 02:19 PM, Jonathan Gibbons wrote: > Joe Darcy wrote: >> Jonathan Gibbons wrote: >>> Joseph D. Darcy wrote: >>>> Hello. >>>> >>>> FYI, there are a few fixes to langtools that have been made in JDK >>>> 7 there are we are considering backporting the OpenJDK 6 b20: >>>> >>>> 6548436 java/compiler: Incorrect inconvertible types error >>>> 6920317 java/compiler: package-info.java file has to be specified >>>> on the javac cmdline, else it will not be avail. >>>> 6948251: need to quote args in langtools launcher script >>>> >>>> -Joe >>> >>> Joe, >>> >>> I would like to include >>> 6916986: handle spaces in langtools launcher path >>> >>> The combination of 6916986 and 6948251 will bring >>> src/share/bin/launcher.sh-template up to date in 6-open with 7. >>> >> >> Sounds good; 6916986 and 6948251 and approved to be ported to OpenJDK 6. >> >> Thanks, >> >> -Joe >> > > Joe, > > How about 6548436 -- fix for 7 applies cleanly to 6-open. > > -- Jon Yes, that is fine to go back. Thanks, -Joe From jonathan.gibbons at sun.com Fri Apr 30 14:53:53 2010 From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com) Date: Fri, 30 Apr 2010 21:53:53 +0000 Subject: hg: jdk6/jdk6/langtools: 6548436: Incorrect inconvertible types error Message-ID: <20100430215354.D2F0B445A1@hg.openjdk.java.net> Changeset: 92fc97e8f8d4 Author: mcimadamore Date: 2008-10-23 18:10 +0100 URL: http://hg.openjdk.java.net/jdk6/jdk6/langtools/rev/92fc97e8f8d4 6548436: Incorrect inconvertible types error Summary: Types.rewrite quantifiers should cope with captured type-variables properly Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Types.java + test/tools/javac/cast/6548436/T6548436a.java + test/tools/javac/cast/6548436/T6548436b.java + test/tools/javac/cast/6548436/T6548436c.java + test/tools/javac/cast/6548436/T6548436d.java From jonathan.gibbons at sun.com Fri Apr 30 14:59:04 2010 From: jonathan.gibbons at sun.com (jonathan.gibbons at sun.com) Date: Fri, 30 Apr 2010 21:59:04 +0000 Subject: hg: jdk6/jdk6/langtools: 6920317: package-info.java file has to be specified on the javac cmdline, else it will not be avail. Message-ID: <20100430215906.20033445AE@hg.openjdk.java.net> Changeset: 9f028decce2b Author: jjg Date: 2010-04-30 14:58 -0700 URL: http://hg.openjdk.java.net/jdk6/jdk6/langtools/rev/9f028decce2b 6920317: package-info.java file has to be specified on the javac cmdline, else it will not be avail. Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/comp/Enter.java ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java + test/tools/javac/processing/6499119/ClassProcessor.java + test/tools/javac/processing/6499119/package-info.java + test/tools/javac/processing/T6920317.java