From Sergey.Bylokhov at oracle.com Mon Sep 14 13:29:55 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 14 Sep 2015 16:29:55 +0300 Subject: [9] Review Request: 8135100 Behavior of null arguments not specified in javax.sound.sampled.spi Message-ID: <55F6CBD3.5080805@oracle.com> Hello Audio Guru. Please review the fix for jdk9. This issue is a subtask of: 4912693: Behavior of null arguments not specified in Java Sound In this patch I cover the whole javax.sound.sampled.spi package. The small description of the fix: - I have checked all methods in the spi package and all related methods in AudioSystem class. - I have moved related tests to the folder corresponding the package and class name. - I have written a tests for every method and class which I changed. Note that these classes related to the different service providers, so I have covered all installed implementations of each provider. Long description. I splits the fix to 3 use cases: - If the method always throw a NPE, then I simply update a javadoc and write a small test. - If the method most of the time throw a NPE then I update a javadoc and change the method to always throw a NPE. Also I write a test which tries to emulate both cases when NPE was thrown and when not. For example AudioFileWriter.isFileTypeSupported(Type) always throws a NPE if at least one type is supported, but if the array is empty then false is returned. - If the method have a few parameters and throw a NPE for some set of them. For example AudioFloatFormatConverter. isConversionSupported(Encoding,AudioFormat), the appropriate test tries to cover these cases. It turned out that all methods throw a NPE except of one: AudioSystem.getMixer()(MixerProvider.getMixer()), but it was found that the specification of MixerProvider.getMixer has no information about the null, so I copied it from the AudioSystem.getMixer(). Also one implementation of MixerProvider - PortMixerProvider.getMixer() throws NPE, so updated its implementation to the same as DirectAudioDeviceProvider.getMixer(); I have done all related regression/jck/sqe tests, and I found one issue in jck and regression tests. Both are related to JDK-4941629 [1] (see comments in this CR). The jck test assumes that the method AudioSystem.write(ais, null, stream) should throw IllegalArgumentException. But according to specification it should throw IllegalArgumentException if the type is unsupported, but the related method AudioSystem.isFileTypeSupported(Type) will always throw a NPE for null. I prefer to file a bug against jck for this case. [1] https://bugs.openjdk.java.net/browse/JDK-4941629 Bug: https://bugs.openjdk.java.net/browse/JDK-8135100 The new test: http://cr.openjdk.java.net/~serb/8135100/webrev.01 -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Wed Sep 23 15:30:15 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 23 Sep 2015 18:30:15 +0300 Subject: [9] Review Request: 8135100 Behavior of null arguments not specified in javax.sound.sampled.spi In-Reply-To: <55F6CBD3.5080805@oracle.com> References: <55F6CBD3.5080805@oracle.com> Message-ID: <5602C587.4000208@oracle.com> Hello, can somebody take a look to this fix? Thanks. On 14.09.15 16:29, Sergey Bylokhov wrote: > Hello Audio Guru. > > Please review the fix for jdk9. This issue is a subtask of: > 4912693: Behavior of null arguments not specified in Java Sound > > In this patch I cover the whole javax.sound.sampled.spi package. > > The small description of the fix: > - I have checked all methods in the spi package and all related methods > in AudioSystem class. > - I have moved related tests to the folder corresponding the package and > class name. > - I have written a tests for every method and class which I changed. > Note that these classes related to the different service providers, so I > have covered all installed implementations of each provider. > > > Long description. > I splits the fix to 3 use cases: > - If the method always throw a NPE, then I simply update a javadoc and > write a small test. > - If the method most of the time throw a NPE then I update a javadoc and > change the method to always throw a NPE. Also I write a test which tries > to emulate both cases when NPE was thrown and when not. For example > AudioFileWriter.isFileTypeSupported(Type) always throws a NPE if at > least one type is supported, but if the array is empty then false is > returned. > - If the method have a few parameters and throw a NPE for some set of > them. For example AudioFloatFormatConverter. > isConversionSupported(Encoding,AudioFormat), the appropriate test tries > to cover these cases. > > It turned out that all methods throw a NPE except of one: > AudioSystem.getMixer()(MixerProvider.getMixer()), but it was found that > the specification of MixerProvider.getMixer has no information about the > null, so I copied it from the AudioSystem.getMixer(). Also one > implementation of MixerProvider - PortMixerProvider.getMixer() throws > NPE, so updated its implementation to the same as > DirectAudioDeviceProvider.getMixer(); > > I have done all related regression/jck/sqe tests, and I found one issue > in jck and regression tests. Both are related to JDK-4941629 [1] (see > comments in this CR). The jck test assumes that the method > AudioSystem.write(ais, null, stream) should throw > IllegalArgumentException. But according to specification it should throw > IllegalArgumentException if the type is unsupported, but the related > method AudioSystem.isFileTypeSupported(Type) will always throw a NPE > for null. I prefer to file a bug against jck for this case. > > > [1] https://bugs.openjdk.java.net/browse/JDK-4941629 > > Bug: https://bugs.openjdk.java.net/browse/JDK-8135100 > The new test: http://cr.openjdk.java.net/~serb/8135100/webrev.01 > -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Wed Sep 23 16:03:09 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 23 Sep 2015 19:03:09 +0300 Subject: [9] Review Request: 6646604 Typos in documentation In-Reply-To: <53CF92D5.5090009@oracle.com> References: <53C6AEC6.7050303@oracle.com> <9D050722-1DF5-4A9A-BF5A-A1C847061D29@oracle.com> <53CF83EB.9010607@oracle.com> <53CF92D5.5090009@oracle.com> Message-ID: <5602CD3D.2070607@oracle.com> Hi, Alexander. After some time, I have a fix for this: http://cr.openjdk.java.net/~serb/6646604/webrev.00 Note that most of the typos in the swing code were fixed already. I also tries to split long lines but as usual these html files use such style a lot. On 23.07.14 14:47, Alexander Zvegintsev wrote: > Hi Sergey, > > here is the list where I've found trailing dots: > > midi/MidiDevice.java:338 > midi/SysexMessage.java:127 > midi/Synthesizer.java:347 > sampled/LineEvent.java:85 > sampled/AudioInputStream.java:395 > > > Otherwise the fix looks good to me. > > > Thanks, > > Alexander. > > On 07/23/2014 01:44 PM, Sergey Bylokhov wrote: >> Hello, >> Any volunteers to be a second reviewer? >> >> On 17.07.2014 12:18, Petr Pchelko wrote: >>> Hello, Sergey. >>> >>> The fix looks good to me. >>> >>> With best regards. Petr. >>> >>> On 16 ???? 2014 ?., at 20:56, Sergey Bylokhov >>> wrote: >>> >>>> Hello. >>>> Please review another one javadoc cleanup in jdk 9 in sound area: >>>> - @param, @return should not end with a dot, except a case when more >>>> than one sentences are used. >>>> - @param, @throws, @return now align, to be more readable. >>>> - @see tags simplified in some places. >>>> - Description of the class/method/field should be followed by dot. >>>> - Broken links/typos fixed >>>> - 80 column limit. >>>> - sets of spaces in the middle of text were deleted. >>>> - replaced by {@tag }. >>>> - unnecessary imports were removed. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8050852 >>>> See the full specdiff: >>>> http://cr.openjdk.java.net/~serb/8050852/javadoc/overview-summary.html >>>> Webrev can be found at: >>>> http://cr.openjdk.java.net/~serb/8050852/webrev.02 >>>> >>>> -- >>>> Best regards, Sergey. >>>> >> >> > -- Best regards, Sergey. From alexander.zvegintsev at oracle.com Wed Sep 23 16:11:50 2015 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Wed, 23 Sep 2015 19:11:50 +0300 Subject: [9] Review Request: 6646604 Typos in documentation In-Reply-To: <5602CD3D.2070607@oracle.com> References: <53C6AEC6.7050303@oracle.com> <9D050722-1DF5-4A9A-BF5A-A1C847061D29@oracle.com> <53CF83EB.9010607@oracle.com> <53CF92D5.5090009@oracle.com> <5602CD3D.2070607@oracle.com> Message-ID: <5602CF46.3000407@oracle.com> Looks fine. Thanks, Alexander. On 09/23/2015 07:03 PM, Sergey Bylokhov wrote: > Hi, Alexander. > After some time, I have a fix for this: > > http://cr.openjdk.java.net/~serb/6646604/webrev.00 > > Note that most of the typos in the swing code were fixed already. I > also tries to split long lines but as usual these html files use such > style a lot. > > On 23.07.14 14:47, Alexander Zvegintsev wrote: >> Hi Sergey, >> >> here is the list where I've found trailing dots: >> >> midi/MidiDevice.java:338 >> midi/SysexMessage.java:127 >> midi/Synthesizer.java:347 >> sampled/LineEvent.java:85 >> sampled/AudioInputStream.java:395 >> >> >> Otherwise the fix looks good to me. >> >> >> Thanks, >> >> Alexander. >> >> On 07/23/2014 01:44 PM, Sergey Bylokhov wrote: >>> Hello, >>> Any volunteers to be a second reviewer? >>> >>> On 17.07.2014 12:18, Petr Pchelko wrote: >>>> Hello, Sergey. >>>> >>>> The fix looks good to me. >>>> >>>> With best regards. Petr. >>>> >>>> On 16 ???? 2014 ?., at 20:56, Sergey Bylokhov >>>> wrote: >>>> >>>>> Hello. >>>>> Please review another one javadoc cleanup in jdk 9 in sound area: >>>>> - @param, @return should not end with a dot, except a case when more >>>>> than one sentences are used. >>>>> - @param, @throws, @return now align, to be more readable. >>>>> - @see tags simplified in some places. >>>>> - Description of the class/method/field should be followed by dot. >>>>> - Broken links/typos fixed >>>>> - 80 column limit. >>>>> - sets of spaces in the middle of text were deleted. >>>>> - replaced by {@tag }. >>>>> - unnecessary imports were removed. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8050852 >>>>> See the full specdiff: >>>>> http://cr.openjdk.java.net/~serb/8050852/javadoc/overview-summary.html >>>>> >>>>> Webrev can be found at: >>>>> http://cr.openjdk.java.net/~serb/8050852/webrev.02 >>>>> >>>>> -- >>>>> Best regards, Sergey. >>>>> >>> >>> >> > > From Sergey.Bylokhov at oracle.com Thu Sep 24 23:38:25 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 25 Sep 2015 02:38:25 +0300 Subject: [9] Review Request: 8135160 Endless Loop in RiffReader Message-ID: <56048971.40902@oracle.com> Hello. Please review the fix for jdk9. While working on some bugs in javasound, I found one issue which can cause an endless loop for some specific audio file. The bug is located in the com.sun.media.sound.RIFFReader.skipBytes() method, which incorrectly assumes that Inputstrem.skip() method should return -1 at the end of the stream. Note that the specification of the read() method has this assumption. The current implementation of the skip method has a loop which stops when the necessary amount of bytes are skipped or the -1 is returned. In the fix I change implementation of this loop: - The check for the negative value is removed, because such checks are not specified. - The check for the zero is enhanced using read() method. This is necessary, because the specification of the skip method mention that the zero can be returned if EOF occurred or nothing was skipped for some other reason and the user should try again. - Note that the skip method can return more bytes than was requested if EOF occurred(at least this part of spec is unclear???), the check for this is also added(otherwise the avail variable can became negative). One new test was added, it was used as initial reproducer. One existed test was updated. Bug: https://bugs.openjdk.java.net/browse/JDK-8135160 Webrev can be found at: http://cr.openjdk.java.net/~serb/8135160/webrev.00 ps: Note that two review requests still active in the javasound: http://mail.openjdk.java.net/pipermail/sound-dev/2015-September/000330.html http://mail.openjdk.java.net/pipermail/sound-dev/2015-September/000332.html -- Best regards, Sergey. From alexey.menkov at oracle.com Fri Sep 25 15:23:18 2015 From: alexey.menkov at oracle.com (alexey menkov) Date: Fri, 25 Sep 2015 18:23:18 +0300 Subject: [9] Review Request: 8135100 Behavior of null arguments not specified in javax.sound.sampled.spi In-Reply-To: <55F6CBD3.5080805@oracle.com> References: <55F6CBD3.5080805@oracle.com> Message-ID: <560566E6.5070307@oracle.com> Hi Sergey, Overall looks good, but I don't like change in MixerProvider.getMixer and PortMixerProvider.getMixer. MixerProvider.getMixer(null) is used by AudioSystem.getMixer(null) (to get the default mixer), but provide PortMixer as the default does not look good, I'd expect AudioSystem.getMixer(null) returns some playback-able device. (Note also that for Ports "SourceDataLine" means controls for recording device) Also comment for MixerProvider.getMixer(Mixer.Info): > * @param info an info object that describes the desired mixer, > * or {@code null} for the system default mixer is unclear and is not consistent with the description above: > * The full set of the mixer info objects that represent the mixers > * supported by this {@code MixerProvider} may be obtained through the > * {@code getMixerInfo} method. Use the {@code isMixerSupported} method to > * test whether this {@code MixerProvider} supports a particular mixer. It looks like MixerProvider.getMixerInfo should add "null" to the supported mixers and MixerProvider.isMixerSupported(null) should return "true". For now I don't have a proposal how to fix this. Maybe it would be better to fix behavior of AudioSystem.getMixer(null) - now it ignores "sound.properties" file (see AudioSystem spec for explanations). regards Alex On 14.09.2015 16:29, Sergey Bylokhov wrote: > Hello Audio Guru. > > Please review the fix for jdk9. This issue is a subtask of: > 4912693: Behavior of null arguments not specified in Java Sound > > In this patch I cover the whole javax.sound.sampled.spi package. > > The small description of the fix: > - I have checked all methods in the spi package and all related methods > in AudioSystem class. > - I have moved related tests to the folder corresponding the package and > class name. > - I have written a tests for every method and class which I changed. > Note that these classes related to the different service providers, so I > have covered all installed implementations of each provider. > > > Long description. > I splits the fix to 3 use cases: > - If the method always throw a NPE, then I simply update a javadoc and > write a small test. > - If the method most of the time throw a NPE then I update a javadoc and > change the method to always throw a NPE. Also I write a test which tries > to emulate both cases when NPE was thrown and when not. For example > AudioFileWriter.isFileTypeSupported(Type) always throws a NPE if at > least one type is supported, but if the array is empty then false is > returned. > - If the method have a few parameters and throw a NPE for some set of > them. For example AudioFloatFormatConverter. > isConversionSupported(Encoding,AudioFormat), the appropriate test tries > to cover these cases. > > It turned out that all methods throw a NPE except of one: > AudioSystem.getMixer()(MixerProvider.getMixer()), but it was found that > the specification of MixerProvider.getMixer has no information about the > null, so I copied it from the AudioSystem.getMixer(). Also one > implementation of MixerProvider - PortMixerProvider.getMixer() throws > NPE, so updated its implementation to the same as > DirectAudioDeviceProvider.getMixer(); > > I have done all related regression/jck/sqe tests, and I found one issue > in jck and regression tests. Both are related to JDK-4941629 [1] (see > comments in this CR). The jck test assumes that the method > AudioSystem.write(ais, null, stream) should throw > IllegalArgumentException. But according to specification it should throw > IllegalArgumentException if the type is unsupported, but the related > method AudioSystem.isFileTypeSupported(Type) will always throw a NPE > for null. I prefer to file a bug against jck for this case. > > > [1] https://bugs.openjdk.java.net/browse/JDK-4941629 > > Bug: https://bugs.openjdk.java.net/browse/JDK-8135100 > The new test: http://cr.openjdk.java.net/~serb/8135100/webrev.01 > From alexey.menkov at oracle.com Fri Sep 25 15:41:33 2015 From: alexey.menkov at oracle.com (alexey menkov) Date: Fri, 25 Sep 2015 18:41:33 +0300 Subject: [9] Review Request: 6646604 Typos in documentation In-Reply-To: <5602CD3D.2070607@oracle.com> References: <53C6AEC6.7050303@oracle.com> <9D050722-1DF5-4A9A-BF5A-A1C847061D29@oracle.com> <53CF83EB.9010607@oracle.com> <53CF92D5.5090009@oracle.com> <5602CD3D.2070607@oracle.com> Message-ID: <56056B2D.1010602@oracle.com> Looks good. --alex On 23.09.2015 19:03, Sergey Bylokhov wrote: > Hi, Alexander. > After some time, I have a fix for this: > > http://cr.openjdk.java.net/~serb/6646604/webrev.00 > > Note that most of the typos in the swing code were fixed already. I also > tries to split long lines but as usual these html files use such style a > lot. > > On 23.07.14 14:47, Alexander Zvegintsev wrote: >> Hi Sergey, >> >> here is the list where I've found trailing dots: >> >> midi/MidiDevice.java:338 >> midi/SysexMessage.java:127 >> midi/Synthesizer.java:347 >> sampled/LineEvent.java:85 >> sampled/AudioInputStream.java:395 >> >> >> Otherwise the fix looks good to me. >> >> >> Thanks, >> >> Alexander. >> >> On 07/23/2014 01:44 PM, Sergey Bylokhov wrote: >>> Hello, >>> Any volunteers to be a second reviewer? >>> >>> On 17.07.2014 12:18, Petr Pchelko wrote: >>>> Hello, Sergey. >>>> >>>> The fix looks good to me. >>>> >>>> With best regards. Petr. >>>> >>>> On 16 ???? 2014 ?., at 20:56, Sergey Bylokhov >>>> wrote: >>>> >>>>> Hello. >>>>> Please review another one javadoc cleanup in jdk 9 in sound area: >>>>> - @param, @return should not end with a dot, except a case when more >>>>> than one sentences are used. >>>>> - @param, @throws, @return now align, to be more readable. >>>>> - @see tags simplified in some places. >>>>> - Description of the class/method/field should be followed by dot. >>>>> - Broken links/typos fixed >>>>> - 80 column limit. >>>>> - sets of spaces in the middle of text were deleted. >>>>> - replaced by {@tag }. >>>>> - unnecessary imports were removed. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8050852 >>>>> See the full specdiff: >>>>> http://cr.openjdk.java.net/~serb/8050852/javadoc/overview-summary.html >>>>> Webrev can be found at: >>>>> http://cr.openjdk.java.net/~serb/8050852/webrev.02 >>>>> >>>>> -- >>>>> Best regards, Sergey. >>>>> >>> >>> >> > > From Sergey.Bylokhov at oracle.com Fri Sep 25 15:41:35 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 25 Sep 2015 18:41:35 +0300 Subject: [9] Review Request: 8135100 Behavior of null arguments not specified in javax.sound.sampled.spi In-Reply-To: <560566E6.5070307@oracle.com> References: <55F6CBD3.5080805@oracle.com> <560566E6.5070307@oracle.com> Message-ID: <56056B2F.7050406@oracle.com> Hi, Alexey. Thanks for review! see my comments inline. On 25.09.15 18:23, alexey menkov wrote: > Hi Sergey, > > Overall looks good, but I don't like change in MixerProvider.getMixer > and PortMixerProvider.getMixer. > > MixerProvider.getMixer(null) is used by AudioSystem.getMixer(null) (to > get the default mixer), but provide PortMixer as the default does not > look good, I'd expect AudioSystem.getMixer(null) returns some > playback-able device. (Note also that for Ports "SourceDataLine" means > controls for recording device) > > Also comment for MixerProvider.getMixer(Mixer.Info): > > * @param info an info object that describes the desired mixer, > > * or {@code null} for the system default mixer > > is unclear and is not consistent with the description above: > > * The full set of the mixer info objects that represent the mixers > > * supported by this {@code MixerProvider} may be obtained through the > > * {@code getMixerInfo} method. Use the {@code isMixerSupported} > method to > > * test whether this {@code MixerProvider} supports a particular mixer. > It looks like MixerProvider.getMixerInfo should add "null" to the > supported mixers and MixerProvider.isMixerSupported(null) should return > "true". In this case the null means that some default mixer will be returned. I am not sure that isMixerSupported(null) should return true, instead I can clarify the specification of getMixer(null), and mention that if null is provided then this mixer will try to return some default( supported) mixer if possible, otherwise IllegalArgumentException will be thrown. For the case of PortMixerProvider and "null" I can throw a IllegalArgumentException which will mean that this provider do not have "default" mixer. > > For now I don't have a proposal how to fix this. > Maybe it would be better to fix behavior of AudioSystem.getMixer(null) - > now it ignores "sound.properties" file (see AudioSystem spec for > explanations). > > regards > Alex > > On 14.09.2015 16:29, Sergey Bylokhov wrote: >> Hello Audio Guru. >> >> Please review the fix for jdk9. This issue is a subtask of: >> 4912693: Behavior of null arguments not specified in Java Sound >> >> In this patch I cover the whole javax.sound.sampled.spi package. >> >> The small description of the fix: >> - I have checked all methods in the spi package and all related methods >> in AudioSystem class. >> - I have moved related tests to the folder corresponding the package and >> class name. >> - I have written a tests for every method and class which I changed. >> Note that these classes related to the different service providers, so I >> have covered all installed implementations of each provider. >> >> >> Long description. >> I splits the fix to 3 use cases: >> - If the method always throw a NPE, then I simply update a javadoc and >> write a small test. >> - If the method most of the time throw a NPE then I update a javadoc and >> change the method to always throw a NPE. Also I write a test which tries >> to emulate both cases when NPE was thrown and when not. For example >> AudioFileWriter.isFileTypeSupported(Type) always throws a NPE if at >> least one type is supported, but if the array is empty then false is >> returned. >> - If the method have a few parameters and throw a NPE for some set of >> them. For example AudioFloatFormatConverter. >> isConversionSupported(Encoding,AudioFormat), the appropriate test tries >> to cover these cases. >> >> It turned out that all methods throw a NPE except of one: >> AudioSystem.getMixer()(MixerProvider.getMixer()), but it was found that >> the specification of MixerProvider.getMixer has no information about the >> null, so I copied it from the AudioSystem.getMixer(). Also one >> implementation of MixerProvider - PortMixerProvider.getMixer() throws >> NPE, so updated its implementation to the same as >> DirectAudioDeviceProvider.getMixer(); >> >> I have done all related regression/jck/sqe tests, and I found one issue >> in jck and regression tests. Both are related to JDK-4941629 [1] (see >> comments in this CR). The jck test assumes that the method >> AudioSystem.write(ais, null, stream) should throw >> IllegalArgumentException. But according to specification it should throw >> IllegalArgumentException if the type is unsupported, but the related >> method AudioSystem.isFileTypeSupported(Type) will always throw a NPE >> for null. I prefer to file a bug against jck for this case. >> >> >> [1] https://bugs.openjdk.java.net/browse/JDK-4941629 >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8135100 >> The new test: http://cr.openjdk.java.net/~serb/8135100/webrev.01 >> -- Best regards, Sergey. From philip.race at oracle.com Fri Sep 25 16:12:31 2015 From: philip.race at oracle.com (Phil Race) Date: Fri, 25 Sep 2015 09:12:31 -0700 Subject: [9] Review Request: 8135160 Endless Loop in RiffReader In-Reply-To: <56048971.40902@oracle.com> References: <56048971.40902@oracle.com> Message-ID: <5605726F.6050609@oracle.com> > long ret = Math.min(stream.skip(remaining), remaining); what is to stop stream.skip returning '-100' ? should you not check for negative ? -phil. On 09/24/2015 04:38 PM, Sergey Bylokhov wrote: > Hello. > Please review the fix for jdk9. > > While working on some bugs in javasound, I found one issue which > can cause an endless loop for some specific audio file. The bug is > located in the com.sun.media.sound.RIFFReader.skipBytes() method, > which incorrectly assumes that Inputstrem.skip() method should return > -1 at the end of the stream. Note that the specification of the read() > method has this assumption. > > The current implementation of the skip method has a loop which stops > when the necessary amount of bytes are skipped or the -1 is returned. > > In the fix I change implementation of this loop: > - The check for the negative value is removed, because such checks > are not specified. > - The check for the zero is enhanced using read() method. This is > necessary, because the specification of the skip method mention that > the zero can be returned if EOF occurred or nothing was skipped for > some other reason and the user should try again. > - Note that the skip method can return more bytes than was requested > if EOF occurred(at least this part of spec is unclear???), the check > for this is also added(otherwise the avail variable can became negative). > > One new test was added, it was used as initial reproducer. One existed > test was updated. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8135160 > Webrev can be found at: > http://cr.openjdk.java.net/~serb/8135160/webrev.00 > > > ps: Note that two review requests still active in the javasound: > > http://mail.openjdk.java.net/pipermail/sound-dev/2015-September/000330.html > > > http://mail.openjdk.java.net/pipermail/sound-dev/2015-September/000332.html > > > From Sergey.Bylokhov at oracle.com Fri Sep 25 16:22:37 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 25 Sep 2015 19:22:37 +0300 Subject: [9] Review Request: 8135160 Endless Loop in RiffReader In-Reply-To: <5605726F.6050609@oracle.com> References: <56048971.40902@oracle.com> <5605726F.6050609@oracle.com> Message-ID: <560574CD.4090007@oracle.com> On 25.09.15 19:12, Phil Race wrote: >> long ret = Math.min(stream.skip(remaining), remaining); > > what is to stop stream.skip returning '-100' ? > > should you not check for negative ? This part of specification is unclear also. If the requested number of bytes is positive, then can the skip method returns the negative value or not. And it is unclear how the negative value should be processed. > > -phil. > > > On 09/24/2015 04:38 PM, Sergey Bylokhov wrote: >> Hello. >> Please review the fix for jdk9. >> >> While working on some bugs in javasound, I found one issue which >> can cause an endless loop for some specific audio file. The bug is >> located in the com.sun.media.sound.RIFFReader.skipBytes() method, >> which incorrectly assumes that Inputstrem.skip() method should return >> -1 at the end of the stream. Note that the specification of the read() >> method has this assumption. >> >> The current implementation of the skip method has a loop which stops >> when the necessary amount of bytes are skipped or the -1 is returned. >> >> In the fix I change implementation of this loop: >> - The check for the negative value is removed, because such checks >> are not specified. >> - The check for the zero is enhanced using read() method. This is >> necessary, because the specification of the skip method mention that >> the zero can be returned if EOF occurred or nothing was skipped for >> some other reason and the user should try again. >> - Note that the skip method can return more bytes than was requested >> if EOF occurred(at least this part of spec is unclear???), the check >> for this is also added(otherwise the avail variable can became negative). >> >> One new test was added, it was used as initial reproducer. One existed >> test was updated. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8135160 >> Webrev can be found at: >> http://cr.openjdk.java.net/~serb/8135160/webrev.00 >> >> >> ps: Note that two review requests still active in the javasound: >> >> http://mail.openjdk.java.net/pipermail/sound-dev/2015-September/000330.html >> >> >> http://mail.openjdk.java.net/pipermail/sound-dev/2015-September/000332.html >> >> >> > -- Best regards, Sergey. From philip.race at oracle.com Fri Sep 25 16:29:58 2015 From: philip.race at oracle.com (Phil Race) Date: Fri, 25 Sep 2015 09:29:58 -0700 Subject: [9] Review Request: 8135100 Behavior of null arguments not specified in javax.sound.sampled.spi In-Reply-To: <56056B2F.7050406@oracle.com> References: <55F6CBD3.5080805@oracle.com> <560566E6.5070307@oracle.com> <56056B2F.7050406@oracle.com> Message-ID: <56057686.1040204@oracle.com> The specification of the sound properties file - and the system property - seems to imply that you can configure javax.sound to use classes that are external to the JDK. So far as I know this has not come up in looking into things that may need some work for jigsaw. Also the very location of the sound.properties file will need to be updated to reflect the modular jdk layout. Is this file expected to be configured by end-users ? If so it would end up in the "conf" directory. Aside from all of that, the various spec clean up should have an approved CCC before it can be pushed. -phil. On 09/25/2015 08:41 AM, Sergey Bylokhov wrote: > Hi, Alexey. > Thanks for review! see my comments inline. > > On 25.09.15 18:23, alexey menkov wrote: >> Hi Sergey, >> >> Overall looks good, but I don't like change in MixerProvider.getMixer >> and PortMixerProvider.getMixer. >> >> MixerProvider.getMixer(null) is used by AudioSystem.getMixer(null) (to >> get the default mixer), but provide PortMixer as the default does not >> look good, I'd expect AudioSystem.getMixer(null) returns some >> playback-able device. (Note also that for Ports "SourceDataLine" means >> controls for recording device) > >> >> Also comment for MixerProvider.getMixer(Mixer.Info): >> > * @param info an info object that describes the desired mixer, >> > * or {@code null} for the system default mixer >> >> is unclear and is not consistent with the description above: >> > * The full set of the mixer info objects that represent the mixers >> > * supported by this {@code MixerProvider} may be obtained through the >> > * {@code getMixerInfo} method. Use the {@code isMixerSupported} >> method to >> > * test whether this {@code MixerProvider} supports a particular >> mixer. >> It looks like MixerProvider.getMixerInfo should add "null" to the >> supported mixers and MixerProvider.isMixerSupported(null) should return >> "true". > > In this case the null means that some default mixer will be returned. > I am not sure that isMixerSupported(null) should return true, instead > I can clarify the specification of getMixer(null), and mention that if > null is provided then this mixer will try to return some default( > supported) mixer if possible, otherwise IllegalArgumentException will > be thrown. > > For the case of PortMixerProvider and "null" I can throw a > IllegalArgumentException which will mean that this provider do not > have "default" mixer. > >> >> For now I don't have a proposal how to fix this. >> Maybe it would be better to fix behavior of AudioSystem.getMixer(null) - >> now it ignores "sound.properties" file (see AudioSystem spec for >> explanations). >> >> regards >> Alex >> >> On 14.09.2015 16:29, Sergey Bylokhov wrote: >>> Hello Audio Guru. >>> >>> Please review the fix for jdk9. This issue is a subtask of: >>> 4912693: Behavior of null arguments not specified in Java Sound >>> >>> In this patch I cover the whole javax.sound.sampled.spi package. >>> >>> The small description of the fix: >>> - I have checked all methods in the spi package and all related methods >>> in AudioSystem class. >>> - I have moved related tests to the folder corresponding the package >>> and >>> class name. >>> - I have written a tests for every method and class which I changed. >>> Note that these classes related to the different service providers, >>> so I >>> have covered all installed implementations of each provider. >>> >>> >>> Long description. >>> I splits the fix to 3 use cases: >>> - If the method always throw a NPE, then I simply update a javadoc and >>> write a small test. >>> - If the method most of the time throw a NPE then I update a javadoc >>> and >>> change the method to always throw a NPE. Also I write a test which >>> tries >>> to emulate both cases when NPE was thrown and when not. For example >>> AudioFileWriter.isFileTypeSupported(Type) always throws a NPE if at >>> least one type is supported, but if the array is empty then false is >>> returned. >>> - If the method have a few parameters and throw a NPE for some set of >>> them. For example AudioFloatFormatConverter. >>> isConversionSupported(Encoding,AudioFormat), the appropriate test tries >>> to cover these cases. >>> >>> It turned out that all methods throw a NPE except of one: >>> AudioSystem.getMixer()(MixerProvider.getMixer()), but it was found that >>> the specification of MixerProvider.getMixer has no information about >>> the >>> null, so I copied it from the AudioSystem.getMixer(). Also one >>> implementation of MixerProvider - PortMixerProvider.getMixer() throws >>> NPE, so updated its implementation to the same as >>> DirectAudioDeviceProvider.getMixer(); >>> >>> I have done all related regression/jck/sqe tests, and I found one issue >>> in jck and regression tests. Both are related to JDK-4941629 [1] (see >>> comments in this CR). The jck test assumes that the method >>> AudioSystem.write(ais, null, stream) should throw >>> IllegalArgumentException. But according to specification it should >>> throw >>> IllegalArgumentException if the type is unsupported, but the related >>> method AudioSystem.isFileTypeSupported(Type) will always throw a NPE >>> for null. I prefer to file a bug against jck for this case. >>> >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-4941629 >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8135100 >>> The new test: http://cr.openjdk.java.net/~serb/8135100/webrev.01 >>> > > From philip.race at oracle.com Fri Sep 25 16:31:24 2015 From: philip.race at oracle.com (Phil Race) Date: Fri, 25 Sep 2015 09:31:24 -0700 Subject: [9] Review Request: 8135160 Endless Loop in RiffReader In-Reply-To: <560574CD.4090007@oracle.com> References: <56048971.40902@oracle.com> <5605726F.6050609@oracle.com> <560574CD.4090007@oracle.com> Message-ID: <560576DC.4070309@oracle.com> I think skip is *supposed* to return >=0 but we should protect against it doing the wrong thing. Treat < 0 as 0 .. or EOF .. -phil. On 09/25/2015 09:22 AM, Sergey Bylokhov wrote: > On 25.09.15 19:12, Phil Race wrote: >>> long ret = Math.min(stream.skip(remaining), remaining); >> >> what is to stop stream.skip returning '-100' ? >> >> should you not check for negative ? > > This part of specification is unclear also. If the requested number of > bytes is positive, then can the skip method returns the negative value > or not. And it is unclear how the negative value should be processed. > > >> >> -phil. >> >> >> On 09/24/2015 04:38 PM, Sergey Bylokhov wrote: >>> Hello. >>> Please review the fix for jdk9. >>> >>> While working on some bugs in javasound, I found one issue which >>> can cause an endless loop for some specific audio file. The bug is >>> located in the com.sun.media.sound.RIFFReader.skipBytes() method, >>> which incorrectly assumes that Inputstrem.skip() method should return >>> -1 at the end of the stream. Note that the specification of the read() >>> method has this assumption. >>> >>> The current implementation of the skip method has a loop which stops >>> when the necessary amount of bytes are skipped or the -1 is returned. >>> >>> In the fix I change implementation of this loop: >>> - The check for the negative value is removed, because such checks >>> are not specified. >>> - The check for the zero is enhanced using read() method. This is >>> necessary, because the specification of the skip method mention that >>> the zero can be returned if EOF occurred or nothing was skipped for >>> some other reason and the user should try again. >>> - Note that the skip method can return more bytes than was requested >>> if EOF occurred(at least this part of spec is unclear???), the check >>> for this is also added(otherwise the avail variable can became >>> negative). >>> >>> One new test was added, it was used as initial reproducer. One existed >>> test was updated. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8135160 >>> Webrev can be found at: >>> http://cr.openjdk.java.net/~serb/8135160/webrev.00 >>> >>> >>> ps: Note that two review requests still active in the javasound: >>> >>> http://mail.openjdk.java.net/pipermail/sound-dev/2015-September/000330.html >>> >>> >>> >>> http://mail.openjdk.java.net/pipermail/sound-dev/2015-September/000332.html >>> >>> >>> >>> >> > > From Sergey.Bylokhov at oracle.com Fri Sep 25 16:43:24 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 25 Sep 2015 19:43:24 +0300 Subject: [9] Review Request: 8135100 Behavior of null arguments not specified in javax.sound.sampled.spi In-Reply-To: <56057686.1040204@oracle.com> References: <55F6CBD3.5080805@oracle.com> <560566E6.5070307@oracle.com> <56056B2F.7050406@oracle.com> <56057686.1040204@oracle.com> Message-ID: <560579AC.40608@oracle.com> On 25.09.15 19:29, Phil Race wrote: > The specification of the sound properties file - and the system property - > seems to imply that you can configure javax.sound to use classes that are > external to the JDK. So far as I know this has not come up in looking into > things that may need some work for jigsaw. yes, some update for jigsaw should be done. > > Also the very location of the sound.properties file will need to be updated > to reflect the modular jdk layout. Is this file expected to be > configured by > end-users ? If so it would end up in the "conf" directory. Yes it can be updated by the users, and It is already in the conf directory. > > Aside from all of that, the various spec clean up should have an approved > CCC before it can be pushed. I will create a ccc request after the technical review. > > -phil. > > > On 09/25/2015 08:41 AM, Sergey Bylokhov wrote: >> Hi, Alexey. >> Thanks for review! see my comments inline. >> >> On 25.09.15 18:23, alexey menkov wrote: >>> Hi Sergey, >>> >>> Overall looks good, but I don't like change in MixerProvider.getMixer >>> and PortMixerProvider.getMixer. >>> >>> MixerProvider.getMixer(null) is used by AudioSystem.getMixer(null) (to >>> get the default mixer), but provide PortMixer as the default does not >>> look good, I'd expect AudioSystem.getMixer(null) returns some >>> playback-able device. (Note also that for Ports "SourceDataLine" means >>> controls for recording device) >> >>> >>> Also comment for MixerProvider.getMixer(Mixer.Info): >>> > * @param info an info object that describes the desired mixer, >>> > * or {@code null} for the system default mixer >>> >>> is unclear and is not consistent with the description above: >>> > * The full set of the mixer info objects that represent the mixers >>> > * supported by this {@code MixerProvider} may be obtained through the >>> > * {@code getMixerInfo} method. Use the {@code isMixerSupported} >>> method to >>> > * test whether this {@code MixerProvider} supports a particular >>> mixer. >>> It looks like MixerProvider.getMixerInfo should add "null" to the >>> supported mixers and MixerProvider.isMixerSupported(null) should return >>> "true". >> >> In this case the null means that some default mixer will be returned. >> I am not sure that isMixerSupported(null) should return true, instead >> I can clarify the specification of getMixer(null), and mention that if >> null is provided then this mixer will try to return some default( >> supported) mixer if possible, otherwise IllegalArgumentException will >> be thrown. >> >> For the case of PortMixerProvider and "null" I can throw a >> IllegalArgumentException which will mean that this provider do not >> have "default" mixer. >> >>> >>> For now I don't have a proposal how to fix this. >>> Maybe it would be better to fix behavior of AudioSystem.getMixer(null) - >>> now it ignores "sound.properties" file (see AudioSystem spec for >>> explanations). >>> >>> regards >>> Alex >>> >>> On 14.09.2015 16:29, Sergey Bylokhov wrote: >>>> Hello Audio Guru. >>>> >>>> Please review the fix for jdk9. This issue is a subtask of: >>>> 4912693: Behavior of null arguments not specified in Java Sound >>>> >>>> In this patch I cover the whole javax.sound.sampled.spi package. >>>> >>>> The small description of the fix: >>>> - I have checked all methods in the spi package and all related methods >>>> in AudioSystem class. >>>> - I have moved related tests to the folder corresponding the package >>>> and >>>> class name. >>>> - I have written a tests for every method and class which I changed. >>>> Note that these classes related to the different service providers, >>>> so I >>>> have covered all installed implementations of each provider. >>>> >>>> >>>> Long description. >>>> I splits the fix to 3 use cases: >>>> - If the method always throw a NPE, then I simply update a javadoc and >>>> write a small test. >>>> - If the method most of the time throw a NPE then I update a javadoc >>>> and >>>> change the method to always throw a NPE. Also I write a test which >>>> tries >>>> to emulate both cases when NPE was thrown and when not. For example >>>> AudioFileWriter.isFileTypeSupported(Type) always throws a NPE if at >>>> least one type is supported, but if the array is empty then false is >>>> returned. >>>> - If the method have a few parameters and throw a NPE for some set of >>>> them. For example AudioFloatFormatConverter. >>>> isConversionSupported(Encoding,AudioFormat), the appropriate test tries >>>> to cover these cases. >>>> >>>> It turned out that all methods throw a NPE except of one: >>>> AudioSystem.getMixer()(MixerProvider.getMixer()), but it was found that >>>> the specification of MixerProvider.getMixer has no information about >>>> the >>>> null, so I copied it from the AudioSystem.getMixer(). Also one >>>> implementation of MixerProvider - PortMixerProvider.getMixer() throws >>>> NPE, so updated its implementation to the same as >>>> DirectAudioDeviceProvider.getMixer(); >>>> >>>> I have done all related regression/jck/sqe tests, and I found one issue >>>> in jck and regression tests. Both are related to JDK-4941629 [1] (see >>>> comments in this CR). The jck test assumes that the method >>>> AudioSystem.write(ais, null, stream) should throw >>>> IllegalArgumentException. But according to specification it should >>>> throw >>>> IllegalArgumentException if the type is unsupported, but the related >>>> method AudioSystem.isFileTypeSupported(Type) will always throw a NPE >>>> for null. I prefer to file a bug against jck for this case. >>>> >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-4941629 >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8135100 >>>> The new test: http://cr.openjdk.java.net/~serb/8135100/webrev.01 >>>> >> >> > -- Best regards, Sergey. From philip.race at oracle.com Fri Sep 25 16:45:50 2015 From: philip.race at oracle.com (Phil Race) Date: Fri, 25 Sep 2015 09:45:50 -0700 Subject: [9] Review Request: 8135100 Behavior of null arguments not specified in javax.sound.sampled.spi In-Reply-To: <560579AC.40608@oracle.com> References: <55F6CBD3.5080805@oracle.com> <560566E6.5070307@oracle.com> <56056B2F.7050406@oracle.com> <56057686.1040204@oracle.com> <560579AC.40608@oracle.com> Message-ID: <56057A3E.4070804@oracle.com> On 09/25/2015 09:43 AM, Sergey Bylokhov wrote: > On 25.09.15 19:29, Phil Race wrote: >> The specification of the sound properties file - and the system >> property - >> seems to imply that you can configure javax.sound to use classes that >> are >> external to the JDK. So far as I know this has not come up in looking >> into >> things that may need some work for jigsaw. > > yes, some update for jigsaw should be done. > >> >> Also the very location of the sound.properties file will need to be >> updated >> to reflect the modular jdk layout. Is this file expected to be >> configured by >> end-users ? If so it would end up in the "conf" directory. > > Yes it can be updated by the users, and It is already in the conf > directory. Ah. I looked at the JDK 8 docs ! JDK 9 is already updated. -phil. > >> >> Aside from all of that, the various spec clean up should have an >> approved >> CCC before it can be pushed. > > I will create a ccc request after the technical review. > >> >> -phil. >> >> >> On 09/25/2015 08:41 AM, Sergey Bylokhov wrote: >>> Hi, Alexey. >>> Thanks for review! see my comments inline. >>> >>> On 25.09.15 18:23, alexey menkov wrote: >>>> Hi Sergey, >>>> >>>> Overall looks good, but I don't like change in MixerProvider.getMixer >>>> and PortMixerProvider.getMixer. >>>> >>>> MixerProvider.getMixer(null) is used by AudioSystem.getMixer(null) (to >>>> get the default mixer), but provide PortMixer as the default does not >>>> look good, I'd expect AudioSystem.getMixer(null) returns some >>>> playback-able device. (Note also that for Ports "SourceDataLine" means >>>> controls for recording device) >>> >>>> >>>> Also comment for MixerProvider.getMixer(Mixer.Info): >>>> > * @param info an info object that describes the desired mixer, >>>> > * or {@code null} for the system default mixer >>>> >>>> is unclear and is not consistent with the description above: >>>> > * The full set of the mixer info objects that represent the mixers >>>> > * supported by this {@code MixerProvider} may be obtained >>>> through the >>>> > * {@code getMixerInfo} method. Use the {@code isMixerSupported} >>>> method to >>>> > * test whether this {@code MixerProvider} supports a particular >>>> mixer. >>>> It looks like MixerProvider.getMixerInfo should add "null" to the >>>> supported mixers and MixerProvider.isMixerSupported(null) should >>>> return >>>> "true". >>> >>> In this case the null means that some default mixer will be returned. >>> I am not sure that isMixerSupported(null) should return true, instead >>> I can clarify the specification of getMixer(null), and mention that if >>> null is provided then this mixer will try to return some default( >>> supported) mixer if possible, otherwise IllegalArgumentException will >>> be thrown. >>> >>> For the case of PortMixerProvider and "null" I can throw a >>> IllegalArgumentException which will mean that this provider do not >>> have "default" mixer. >>> >>>> >>>> For now I don't have a proposal how to fix this. >>>> Maybe it would be better to fix behavior of >>>> AudioSystem.getMixer(null) - >>>> now it ignores "sound.properties" file (see AudioSystem spec for >>>> explanations). >>>> >>>> regards >>>> Alex >>>> >>>> On 14.09.2015 16:29, Sergey Bylokhov wrote: >>>>> Hello Audio Guru. >>>>> >>>>> Please review the fix for jdk9. This issue is a subtask of: >>>>> 4912693: Behavior of null arguments not specified in Java Sound >>>>> >>>>> In this patch I cover the whole javax.sound.sampled.spi package. >>>>> >>>>> The small description of the fix: >>>>> - I have checked all methods in the spi package and all related >>>>> methods >>>>> in AudioSystem class. >>>>> - I have moved related tests to the folder corresponding the package >>>>> and >>>>> class name. >>>>> - I have written a tests for every method and class which I changed. >>>>> Note that these classes related to the different service providers, >>>>> so I >>>>> have covered all installed implementations of each provider. >>>>> >>>>> >>>>> Long description. >>>>> I splits the fix to 3 use cases: >>>>> - If the method always throw a NPE, then I simply update a javadoc >>>>> and >>>>> write a small test. >>>>> - If the method most of the time throw a NPE then I update a javadoc >>>>> and >>>>> change the method to always throw a NPE. Also I write a test which >>>>> tries >>>>> to emulate both cases when NPE was thrown and when not. For example >>>>> AudioFileWriter.isFileTypeSupported(Type) always throws a NPE if at >>>>> least one type is supported, but if the array is empty then false is >>>>> returned. >>>>> - If the method have a few parameters and throw a NPE for some set of >>>>> them. For example AudioFloatFormatConverter. >>>>> isConversionSupported(Encoding,AudioFormat), the appropriate test >>>>> tries >>>>> to cover these cases. >>>>> >>>>> It turned out that all methods throw a NPE except of one: >>>>> AudioSystem.getMixer()(MixerProvider.getMixer()), but it was found >>>>> that >>>>> the specification of MixerProvider.getMixer has no information about >>>>> the >>>>> null, so I copied it from the AudioSystem.getMixer(). Also one >>>>> implementation of MixerProvider - PortMixerProvider.getMixer() >>>>> throws >>>>> NPE, so updated its implementation to the same as >>>>> DirectAudioDeviceProvider.getMixer(); >>>>> >>>>> I have done all related regression/jck/sqe tests, and I found one >>>>> issue >>>>> in jck and regression tests. Both are related to JDK-4941629 [1] (see >>>>> comments in this CR). The jck test assumes that the method >>>>> AudioSystem.write(ais, null, stream) should throw >>>>> IllegalArgumentException. But according to specification it should >>>>> throw >>>>> IllegalArgumentException if the type is unsupported, but the related >>>>> method AudioSystem.isFileTypeSupported(Type) will always throw a NPE >>>>> for null. I prefer to file a bug against jck for this case. >>>>> >>>>> >>>>> [1] https://bugs.openjdk.java.net/browse/JDK-4941629 >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8135100 >>>>> The new test: http://cr.openjdk.java.net/~serb/8135100/webrev.01 >>>>> >>> >>> >> > > From alexey.menkov at oracle.com Fri Sep 25 17:32:38 2015 From: alexey.menkov at oracle.com (alexey menkov) Date: Fri, 25 Sep 2015 20:32:38 +0300 Subject: [9] Review Request: 8135100 Behavior of null arguments not specified in javax.sound.sampled.spi In-Reply-To: <56056B2F.7050406@oracle.com> References: <55F6CBD3.5080805@oracle.com> <560566E6.5070307@oracle.com> <56056B2F.7050406@oracle.com> Message-ID: <56058536.1050307@oracle.com> Ok, lets only clarify MixerProvider.getMixer(null) behavior. Actually AusioSystem.getMixer(null) looks unclear because unclear what is the "default mixer" in the case (we may have different "default playback mixer", "default recording mixer", "default port mixer"). regards Alex On 25.09.2015 18:41, Sergey Bylokhov wrote: > Hi, Alexey. > Thanks for review! see my comments inline. > > On 25.09.15 18:23, alexey menkov wrote: >> Hi Sergey, >> >> Overall looks good, but I don't like change in MixerProvider.getMixer >> and PortMixerProvider.getMixer. >> >> MixerProvider.getMixer(null) is used by AudioSystem.getMixer(null) (to >> get the default mixer), but provide PortMixer as the default does not >> look good, I'd expect AudioSystem.getMixer(null) returns some >> playback-able device. (Note also that for Ports "SourceDataLine" means >> controls for recording device) > >> >> Also comment for MixerProvider.getMixer(Mixer.Info): >> > * @param info an info object that describes the desired mixer, >> > * or {@code null} for the system default mixer >> >> is unclear and is not consistent with the description above: >> > * The full set of the mixer info objects that represent the mixers >> > * supported by this {@code MixerProvider} may be obtained through the >> > * {@code getMixerInfo} method. Use the {@code isMixerSupported} >> method to >> > * test whether this {@code MixerProvider} supports a particular mixer. >> It looks like MixerProvider.getMixerInfo should add "null" to the >> supported mixers and MixerProvider.isMixerSupported(null) should return >> "true". > > In this case the null means that some default mixer will be returned. I > am not sure that isMixerSupported(null) should return true, instead I > can clarify the specification of getMixer(null), and mention that if > null is provided then this mixer will try to return some default( > supported) mixer if possible, otherwise IllegalArgumentException will be > thrown. > > For the case of PortMixerProvider and "null" I can throw a > IllegalArgumentException which will mean that this provider do not have > "default" mixer. > >> >> For now I don't have a proposal how to fix this. >> Maybe it would be better to fix behavior of AudioSystem.getMixer(null) - >> now it ignores "sound.properties" file (see AudioSystem spec for >> explanations). >> >> regards >> Alex >> >> On 14.09.2015 16:29, Sergey Bylokhov wrote: >>> Hello Audio Guru. >>> >>> Please review the fix for jdk9. This issue is a subtask of: >>> 4912693: Behavior of null arguments not specified in Java Sound >>> >>> In this patch I cover the whole javax.sound.sampled.spi package. >>> >>> The small description of the fix: >>> - I have checked all methods in the spi package and all related methods >>> in AudioSystem class. >>> - I have moved related tests to the folder corresponding the package and >>> class name. >>> - I have written a tests for every method and class which I changed. >>> Note that these classes related to the different service providers, so I >>> have covered all installed implementations of each provider. >>> >>> >>> Long description. >>> I splits the fix to 3 use cases: >>> - If the method always throw a NPE, then I simply update a javadoc and >>> write a small test. >>> - If the method most of the time throw a NPE then I update a javadoc and >>> change the method to always throw a NPE. Also I write a test which tries >>> to emulate both cases when NPE was thrown and when not. For example >>> AudioFileWriter.isFileTypeSupported(Type) always throws a NPE if at >>> least one type is supported, but if the array is empty then false is >>> returned. >>> - If the method have a few parameters and throw a NPE for some set of >>> them. For example AudioFloatFormatConverter. >>> isConversionSupported(Encoding,AudioFormat), the appropriate test tries >>> to cover these cases. >>> >>> It turned out that all methods throw a NPE except of one: >>> AudioSystem.getMixer()(MixerProvider.getMixer()), but it was found that >>> the specification of MixerProvider.getMixer has no information about the >>> null, so I copied it from the AudioSystem.getMixer(). Also one >>> implementation of MixerProvider - PortMixerProvider.getMixer() throws >>> NPE, so updated its implementation to the same as >>> DirectAudioDeviceProvider.getMixer(); >>> >>> I have done all related regression/jck/sqe tests, and I found one issue >>> in jck and regression tests. Both are related to JDK-4941629 [1] (see >>> comments in this CR). The jck test assumes that the method >>> AudioSystem.write(ais, null, stream) should throw >>> IllegalArgumentException. But according to specification it should throw >>> IllegalArgumentException if the type is unsupported, but the related >>> method AudioSystem.isFileTypeSupported(Type) will always throw a NPE >>> for null. I prefer to file a bug against jck for this case. >>> >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-4941629 >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8135100 >>> The new test: http://cr.openjdk.java.net/~serb/8135100/webrev.01 >>> > > From Sergey.Bylokhov at oracle.com Fri Sep 25 17:42:30 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 25 Sep 2015 20:42:30 +0300 Subject: [9] Review Request: 8135100 Behavior of null arguments not specified in javax.sound.sampled.spi In-Reply-To: <56058536.1050307@oracle.com> References: <55F6CBD3.5080805@oracle.com> <560566E6.5070307@oracle.com> <56056B2F.7050406@oracle.com> <56058536.1050307@oracle.com> Message-ID: <56058786.5070809@oracle.com> On 25.09.15 20:32, alexey menkov wrote: > Ok, lets only clarify MixerProvider.getMixer(null) behavior. > Actually AusioSystem.getMixer(null) looks unclear because unclear what > is the "default mixer" in the case (we may have different "default > playback mixer", "default recording mixer", "default port mixer"). Right, if to consider that the sequence of providers isn't specified, then it is unclear what this method should actually return. I do not understand the purpose to return some random mixer. I think that intention was to return "default playback mixer"? > > regards > Alex > > On 25.09.2015 18:41, Sergey Bylokhov wrote: >> Hi, Alexey. >> Thanks for review! see my comments inline. >> >> On 25.09.15 18:23, alexey menkov wrote: >>> Hi Sergey, >>> >>> Overall looks good, but I don't like change in MixerProvider.getMixer >>> and PortMixerProvider.getMixer. >>> >>> MixerProvider.getMixer(null) is used by AudioSystem.getMixer(null) (to >>> get the default mixer), but provide PortMixer as the default does not >>> look good, I'd expect AudioSystem.getMixer(null) returns some >>> playback-able device. (Note also that for Ports "SourceDataLine" means >>> controls for recording device) >> >>> >>> Also comment for MixerProvider.getMixer(Mixer.Info): >>> > * @param info an info object that describes the desired mixer, >>> > * or {@code null} for the system default mixer >>> >>> is unclear and is not consistent with the description above: >>> > * The full set of the mixer info objects that represent the mixers >>> > * supported by this {@code MixerProvider} may be obtained through the >>> > * {@code getMixerInfo} method. Use the {@code isMixerSupported} >>> method to >>> > * test whether this {@code MixerProvider} supports a particular >>> mixer. >>> It looks like MixerProvider.getMixerInfo should add "null" to the >>> supported mixers and MixerProvider.isMixerSupported(null) should return >>> "true". >> >> In this case the null means that some default mixer will be returned. I >> am not sure that isMixerSupported(null) should return true, instead I >> can clarify the specification of getMixer(null), and mention that if >> null is provided then this mixer will try to return some default( >> supported) mixer if possible, otherwise IllegalArgumentException will be >> thrown. >> >> For the case of PortMixerProvider and "null" I can throw a >> IllegalArgumentException which will mean that this provider do not have >> "default" mixer. >> >>> >>> For now I don't have a proposal how to fix this. >>> Maybe it would be better to fix behavior of AudioSystem.getMixer(null) - >>> now it ignores "sound.properties" file (see AudioSystem spec for >>> explanations). >>> >>> regards >>> Alex >>> >>> On 14.09.2015 16:29, Sergey Bylokhov wrote: >>>> Hello Audio Guru. >>>> >>>> Please review the fix for jdk9. This issue is a subtask of: >>>> 4912693: Behavior of null arguments not specified in Java Sound >>>> >>>> In this patch I cover the whole javax.sound.sampled.spi package. >>>> >>>> The small description of the fix: >>>> - I have checked all methods in the spi package and all related methods >>>> in AudioSystem class. >>>> - I have moved related tests to the folder corresponding the package >>>> and >>>> class name. >>>> - I have written a tests for every method and class which I changed. >>>> Note that these classes related to the different service providers, >>>> so I >>>> have covered all installed implementations of each provider. >>>> >>>> >>>> Long description. >>>> I splits the fix to 3 use cases: >>>> - If the method always throw a NPE, then I simply update a javadoc and >>>> write a small test. >>>> - If the method most of the time throw a NPE then I update a javadoc >>>> and >>>> change the method to always throw a NPE. Also I write a test which >>>> tries >>>> to emulate both cases when NPE was thrown and when not. For example >>>> AudioFileWriter.isFileTypeSupported(Type) always throws a NPE if at >>>> least one type is supported, but if the array is empty then false is >>>> returned. >>>> - If the method have a few parameters and throw a NPE for some set of >>>> them. For example AudioFloatFormatConverter. >>>> isConversionSupported(Encoding,AudioFormat), the appropriate test tries >>>> to cover these cases. >>>> >>>> It turned out that all methods throw a NPE except of one: >>>> AudioSystem.getMixer()(MixerProvider.getMixer()), but it was found that >>>> the specification of MixerProvider.getMixer has no information about >>>> the >>>> null, so I copied it from the AudioSystem.getMixer(). Also one >>>> implementation of MixerProvider - PortMixerProvider.getMixer() throws >>>> NPE, so updated its implementation to the same as >>>> DirectAudioDeviceProvider.getMixer(); >>>> >>>> I have done all related regression/jck/sqe tests, and I found one issue >>>> in jck and regression tests. Both are related to JDK-4941629 [1] (see >>>> comments in this CR). The jck test assumes that the method >>>> AudioSystem.write(ais, null, stream) should throw >>>> IllegalArgumentException. But according to specification it should >>>> throw >>>> IllegalArgumentException if the type is unsupported, but the related >>>> method AudioSystem.isFileTypeSupported(Type) will always throw a NPE >>>> for null. I prefer to file a bug against jck for this case. >>>> >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-4941629 >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8135100 >>>> The new test: http://cr.openjdk.java.net/~serb/8135100/webrev.01 >>>> >> >> -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Fri Sep 25 18:14:45 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 25 Sep 2015 21:14:45 +0300 Subject: [9] Review Request: 8135160 Endless Loop in RiffReader In-Reply-To: <560576DC.4070309@oracle.com> References: <56048971.40902@oracle.com> <5605726F.6050609@oracle.com> <560574CD.4090007@oracle.com> <560576DC.4070309@oracle.com> Message-ID: <56058F15.5060107@oracle.com> Hi, Phil. The new version is here: http://cr.openjdk.java.net/~serb/8135160/webrev.01 In case of negative value we assume an EOF. On 25.09.15 19:31, Phil Race wrote: > I think skip is *supposed* to return >=0 but we should protect against > it doing the wrong thing. Treat < 0 as 0 .. or EOF .. > > -phil. > > On 09/25/2015 09:22 AM, Sergey Bylokhov wrote: >> On 25.09.15 19:12, Phil Race wrote: >>>> long ret = Math.min(stream.skip(remaining), remaining); >>> >>> what is to stop stream.skip returning '-100' ? >>> >>> should you not check for negative ? >> >> This part of specification is unclear also. If the requested number of >> bytes is positive, then can the skip method returns the negative value >> or not. And it is unclear how the negative value should be processed. >> >> >>> >>> -phil. >>> >>> >>> On 09/24/2015 04:38 PM, Sergey Bylokhov wrote: >>>> Hello. >>>> Please review the fix for jdk9. >>>> >>>> While working on some bugs in javasound, I found one issue which >>>> can cause an endless loop for some specific audio file. The bug is >>>> located in the com.sun.media.sound.RIFFReader.skipBytes() method, >>>> which incorrectly assumes that Inputstrem.skip() method should return >>>> -1 at the end of the stream. Note that the specification of the read() >>>> method has this assumption. >>>> >>>> The current implementation of the skip method has a loop which stops >>>> when the necessary amount of bytes are skipped or the -1 is returned. >>>> >>>> In the fix I change implementation of this loop: >>>> - The check for the negative value is removed, because such checks >>>> are not specified. >>>> - The check for the zero is enhanced using read() method. This is >>>> necessary, because the specification of the skip method mention that >>>> the zero can be returned if EOF occurred or nothing was skipped for >>>> some other reason and the user should try again. >>>> - Note that the skip method can return more bytes than was requested >>>> if EOF occurred(at least this part of spec is unclear???), the check >>>> for this is also added(otherwise the avail variable can became >>>> negative). >>>> >>>> One new test was added, it was used as initial reproducer. One existed >>>> test was updated. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8135160 >>>> Webrev can be found at: >>>> http://cr.openjdk.java.net/~serb/8135160/webrev.00 >>>> >>>> >>>> ps: Note that two review requests still active in the javasound: >>>> >>>> http://mail.openjdk.java.net/pipermail/sound-dev/2015-September/000330.html >>>> >>>> >>>> >>>> http://mail.openjdk.java.net/pipermail/sound-dev/2015-September/000332.html >>>> >>>> >>>> >>>> >>> >> >> > -- Best regards, Sergey. From philip.race at oracle.com Fri Sep 25 18:18:17 2015 From: philip.race at oracle.com (Phil Race) Date: Fri, 25 Sep 2015 11:18:17 -0700 Subject: [9] Review Request: 8135160 Endless Loop in RiffReader In-Reply-To: <56058F15.5060107@oracle.com> References: <56048971.40902@oracle.com> <5605726F.6050609@oracle.com> <560574CD.4090007@oracle.com> <560576DC.4070309@oracle.com> <56058F15.5060107@oracle.com> Message-ID: <56058FE9.8040406@oracle.com> Approved. I am not sure about Thread.yield() being useful here but I do not see it causing any harm and it was pre-existing. -phil. On 09/25/2015 11:14 AM, Sergey Bylokhov wrote: > Hi, Phil. > The new version is here: > http://cr.openjdk.java.net/~serb/8135160/webrev.01 > > In case of negative value we assume an EOF. > > On 25.09.15 19:31, Phil Race wrote: >> I think skip is *supposed* to return >=0 but we should protect against >> it doing the wrong thing. Treat < 0 as 0 .. or EOF .. >> >> -phil. >> >> On 09/25/2015 09:22 AM, Sergey Bylokhov wrote: >>> On 25.09.15 19:12, Phil Race wrote: >>>>> long ret = Math.min(stream.skip(remaining), remaining); >>>> >>>> what is to stop stream.skip returning '-100' ? >>>> >>>> should you not check for negative ? >>> >>> This part of specification is unclear also. If the requested number of >>> bytes is positive, then can the skip method returns the negative value >>> or not. And it is unclear how the negative value should be processed. >>> >>> >>>> >>>> -phil. >>>> >>>> >>>> On 09/24/2015 04:38 PM, Sergey Bylokhov wrote: >>>>> Hello. >>>>> Please review the fix for jdk9. >>>>> >>>>> While working on some bugs in javasound, I found one issue which >>>>> can cause an endless loop for some specific audio file. The bug is >>>>> located in the com.sun.media.sound.RIFFReader.skipBytes() method, >>>>> which incorrectly assumes that Inputstrem.skip() method should return >>>>> -1 at the end of the stream. Note that the specification of the >>>>> read() >>>>> method has this assumption. >>>>> >>>>> The current implementation of the skip method has a loop which stops >>>>> when the necessary amount of bytes are skipped or the -1 is returned. >>>>> >>>>> In the fix I change implementation of this loop: >>>>> - The check for the negative value is removed, because such checks >>>>> are not specified. >>>>> - The check for the zero is enhanced using read() method. This is >>>>> necessary, because the specification of the skip method mention that >>>>> the zero can be returned if EOF occurred or nothing was skipped for >>>>> some other reason and the user should try again. >>>>> - Note that the skip method can return more bytes than was requested >>>>> if EOF occurred(at least this part of spec is unclear???), the check >>>>> for this is also added(otherwise the avail variable can became >>>>> negative). >>>>> >>>>> One new test was added, it was used as initial reproducer. One >>>>> existed >>>>> test was updated. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8135160 >>>>> Webrev can be found at: >>>>> http://cr.openjdk.java.net/~serb/8135160/webrev.00 >>>>> >>>>> >>>>> ps: Note that two review requests still active in the javasound: >>>>> >>>>> http://mail.openjdk.java.net/pipermail/sound-dev/2015-September/000330.html >>>>> >>>>> >>>>> >>>>> >>>>> http://mail.openjdk.java.net/pipermail/sound-dev/2015-September/000332.html >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>> >>> >> > > From alexey.menkov at oracle.com Fri Sep 25 18:33:02 2015 From: alexey.menkov at oracle.com (alexey menkov) Date: Fri, 25 Sep 2015 21:33:02 +0300 Subject: [9] Review Request: 8135100 Behavior of null arguments not specified in javax.sound.sampled.spi In-Reply-To: <56058786.5070809@oracle.com> References: <55F6CBD3.5080805@oracle.com> <560566E6.5070307@oracle.com> <56056B2F.7050406@oracle.com> <56058536.1050307@oracle.com> <56058786.5070809@oracle.com> Message-ID: <5605935E.3050208@oracle.com> On 25.09.2015 20:42, Sergey Bylokhov wrote: > On 25.09.15 20:32, alexey menkov wrote: >> Ok, lets only clarify MixerProvider.getMixer(null) behavior. >> Actually AusioSystem.getMixer(null) looks unclear because unclear what >> is the "default mixer" in the case (we may have different "default >> playback mixer", "default recording mixer", "default port mixer"). > > Right, if to consider that the sequence of providers isn't specified, > then it is unclear what this method should actually return. I do not > understand the purpose to return some random mixer. I think that > intention was to return "default playback mixer"? I don't know. I suppose this is ancient method (and most likely nobody use it) and the implementation was changed this way to get DirectAudioDevice as default (it supports both playback and recording). For me the most logical is to return default playback mixer :) --alex > >> >> regards >> Alex >> >> On 25.09.2015 18:41, Sergey Bylokhov wrote: >>> Hi, Alexey. >>> Thanks for review! see my comments inline. >>> >>> On 25.09.15 18:23, alexey menkov wrote: >>>> Hi Sergey, >>>> >>>> Overall looks good, but I don't like change in MixerProvider.getMixer >>>> and PortMixerProvider.getMixer. >>>> >>>> MixerProvider.getMixer(null) is used by AudioSystem.getMixer(null) (to >>>> get the default mixer), but provide PortMixer as the default does not >>>> look good, I'd expect AudioSystem.getMixer(null) returns some >>>> playback-able device. (Note also that for Ports "SourceDataLine" means >>>> controls for recording device) >>> >>>> >>>> Also comment for MixerProvider.getMixer(Mixer.Info): >>>> > * @param info an info object that describes the desired mixer, >>>> > * or {@code null} for the system default mixer >>>> >>>> is unclear and is not consistent with the description above: >>>> > * The full set of the mixer info objects that represent the mixers >>>> > * supported by this {@code MixerProvider} may be obtained through >>>> the >>>> > * {@code getMixerInfo} method. Use the {@code isMixerSupported} >>>> method to >>>> > * test whether this {@code MixerProvider} supports a particular >>>> mixer. >>>> It looks like MixerProvider.getMixerInfo should add "null" to the >>>> supported mixers and MixerProvider.isMixerSupported(null) should return >>>> "true". >>> >>> In this case the null means that some default mixer will be returned. I >>> am not sure that isMixerSupported(null) should return true, instead I >>> can clarify the specification of getMixer(null), and mention that if >>> null is provided then this mixer will try to return some default( >>> supported) mixer if possible, otherwise IllegalArgumentException will be >>> thrown. >>> >>> For the case of PortMixerProvider and "null" I can throw a >>> IllegalArgumentException which will mean that this provider do not have >>> "default" mixer. >>> >>>> >>>> For now I don't have a proposal how to fix this. >>>> Maybe it would be better to fix behavior of >>>> AudioSystem.getMixer(null) - >>>> now it ignores "sound.properties" file (see AudioSystem spec for >>>> explanations). >>>> >>>> regards >>>> Alex >>>> >>>> On 14.09.2015 16:29, Sergey Bylokhov wrote: >>>>> Hello Audio Guru. >>>>> >>>>> Please review the fix for jdk9. This issue is a subtask of: >>>>> 4912693: Behavior of null arguments not specified in Java Sound >>>>> >>>>> In this patch I cover the whole javax.sound.sampled.spi package. >>>>> >>>>> The small description of the fix: >>>>> - I have checked all methods in the spi package and all related >>>>> methods >>>>> in AudioSystem class. >>>>> - I have moved related tests to the folder corresponding the package >>>>> and >>>>> class name. >>>>> - I have written a tests for every method and class which I changed. >>>>> Note that these classes related to the different service providers, >>>>> so I >>>>> have covered all installed implementations of each provider. >>>>> >>>>> >>>>> Long description. >>>>> I splits the fix to 3 use cases: >>>>> - If the method always throw a NPE, then I simply update a javadoc and >>>>> write a small test. >>>>> - If the method most of the time throw a NPE then I update a javadoc >>>>> and >>>>> change the method to always throw a NPE. Also I write a test which >>>>> tries >>>>> to emulate both cases when NPE was thrown and when not. For example >>>>> AudioFileWriter.isFileTypeSupported(Type) always throws a NPE if at >>>>> least one type is supported, but if the array is empty then false is >>>>> returned. >>>>> - If the method have a few parameters and throw a NPE for some set of >>>>> them. For example AudioFloatFormatConverter. >>>>> isConversionSupported(Encoding,AudioFormat), the appropriate test >>>>> tries >>>>> to cover these cases. >>>>> >>>>> It turned out that all methods throw a NPE except of one: >>>>> AudioSystem.getMixer()(MixerProvider.getMixer()), but it was found >>>>> that >>>>> the specification of MixerProvider.getMixer has no information about >>>>> the >>>>> null, so I copied it from the AudioSystem.getMixer(). Also one >>>>> implementation of MixerProvider - PortMixerProvider.getMixer() throws >>>>> NPE, so updated its implementation to the same as >>>>> DirectAudioDeviceProvider.getMixer(); >>>>> >>>>> I have done all related regression/jck/sqe tests, and I found one >>>>> issue >>>>> in jck and regression tests. Both are related to JDK-4941629 [1] (see >>>>> comments in this CR). The jck test assumes that the method >>>>> AudioSystem.write(ais, null, stream) should throw >>>>> IllegalArgumentException. But according to specification it should >>>>> throw >>>>> IllegalArgumentException if the type is unsupported, but the related >>>>> method AudioSystem.isFileTypeSupported(Type) will always throw a NPE >>>>> for null. I prefer to file a bug against jck for this case. >>>>> >>>>> >>>>> [1] https://bugs.openjdk.java.net/browse/JDK-4941629 >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8135100 >>>>> The new test: http://cr.openjdk.java.net/~serb/8135100/webrev.01 >>>>> >>> >>> > > From alexey.menkov at oracle.com Fri Sep 25 18:44:54 2015 From: alexey.menkov at oracle.com (alexey menkov) Date: Fri, 25 Sep 2015 21:44:54 +0300 Subject: [9] Review Request: 8135160 Endless Loop in RiffReader In-Reply-To: <56058F15.5060107@oracle.com> References: <56048971.40902@oracle.com> <5605726F.6050609@oracle.com> <560574CD.4090007@oracle.com> <560576DC.4070309@oracle.com> <56058F15.5060107@oracle.com> Message-ID: <56059626.7020903@oracle.com> looks ok --alex On 25.09.2015 21:14, Sergey Bylokhov wrote: > Hi, Phil. > The new version is here: > http://cr.openjdk.java.net/~serb/8135160/webrev.01 > > In case of negative value we assume an EOF. > > On 25.09.15 19:31, Phil Race wrote: >> I think skip is *supposed* to return >=0 but we should protect against >> it doing the wrong thing. Treat < 0 as 0 .. or EOF .. >> >> -phil. >> >> On 09/25/2015 09:22 AM, Sergey Bylokhov wrote: >>> On 25.09.15 19:12, Phil Race wrote: >>>>> long ret = Math.min(stream.skip(remaining), remaining); >>>> >>>> what is to stop stream.skip returning '-100' ? >>>> >>>> should you not check for negative ? >>> >>> This part of specification is unclear also. If the requested number of >>> bytes is positive, then can the skip method returns the negative value >>> or not. And it is unclear how the negative value should be processed. >>> >>> >>>> >>>> -phil. >>>> >>>> >>>> On 09/24/2015 04:38 PM, Sergey Bylokhov wrote: >>>>> Hello. >>>>> Please review the fix for jdk9. >>>>> >>>>> While working on some bugs in javasound, I found one issue which >>>>> can cause an endless loop for some specific audio file. The bug is >>>>> located in the com.sun.media.sound.RIFFReader.skipBytes() method, >>>>> which incorrectly assumes that Inputstrem.skip() method should return >>>>> -1 at the end of the stream. Note that the specification of the read() >>>>> method has this assumption. >>>>> >>>>> The current implementation of the skip method has a loop which stops >>>>> when the necessary amount of bytes are skipped or the -1 is returned. >>>>> >>>>> In the fix I change implementation of this loop: >>>>> - The check for the negative value is removed, because such checks >>>>> are not specified. >>>>> - The check for the zero is enhanced using read() method. This is >>>>> necessary, because the specification of the skip method mention that >>>>> the zero can be returned if EOF occurred or nothing was skipped for >>>>> some other reason and the user should try again. >>>>> - Note that the skip method can return more bytes than was requested >>>>> if EOF occurred(at least this part of spec is unclear???), the check >>>>> for this is also added(otherwise the avail variable can became >>>>> negative). >>>>> >>>>> One new test was added, it was used as initial reproducer. One existed >>>>> test was updated. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8135160 >>>>> Webrev can be found at: >>>>> http://cr.openjdk.java.net/~serb/8135160/webrev.00 >>>>> >>>>> >>>>> ps: Note that two review requests still active in the javasound: >>>>> >>>>> http://mail.openjdk.java.net/pipermail/sound-dev/2015-September/000330.html >>>>> >>>>> >>>>> >>>>> >>>>> http://mail.openjdk.java.net/pipermail/sound-dev/2015-September/000332.html >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>> >>> >> > >