<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 22.07.15 1:25, Phil Race wrote:<br>
</div>
<blockquote cite="mid:55AEC6D8.40608@oracle.com" type="cite">
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
<br>
<tt>Is this the issue behind the somewhat cryptic "</tt><tt>8130305:
AudioSystem behavior depends on order that providers are
located" ?<br>
</tt></blockquote>
Yes, the order is changed, the test caused a problem in the latest
reader, and the reset of stream was unnecessary, so the bug was not
visible.<br>
<blockquote cite="mid:55AEC6D8.40608@oracle.com" type="cite"><tt> </tt><br>
<pre><span class="changed"> 80 public AudioInputStream getAudioInputStream(final InputStream stream)</span>
<span class="changed"> 81 throws UnsupportedAudioFileException, IOException {</span>
<span class="changed"> 82 stream.mark(200);</span>
<span class="changed"> 83 try {</span>
<span class="changed"> 84 final AudioFileFormat fileFormat = getAudioFileFormatImpl(stream);</span></pre>
<tt>You aren't wrapping the stream here. This is OK if it is
called via one of the other<br>
two methods that do, but can it not be called directly ?<br>
<br>
Same for</tt>
<pre><span class="changed">public final AudioFileFormat getAudioFileFormat(final InputStream stream)
but it may not matter on the methods that just read a few bytes of header anyway ..</span></pre>
</blockquote>
In both cases this stream is passed to the method by the user, so I
guess this is responsibility of the user what the stream it is
passed. All old readers do not wrap it before.<br>
<br>
<blockquote cite="mid:55AEC6D8.40608@oracle.com" type="cite">
<pre><span class="changed">
</span><span class="changed">stream.mark(200);
seems arbitrary and I assume it was your calculation of the max likely to
be needed by any subclass but it would be good to add a comment about this.</span></pre>
</blockquote>
I select the biggest value which was used in WaveFloatFileReader,
all other readers used smaller value.
<meta http-equiv="content-type" content="text/html;
charset=windows-1252">
<blockquote cite="mid:55AEC6D8.40608@oracle.com" type="cite">
<pre><span class="changed">
-phil.
</span></pre>
<tt> </tt>
<blockquote cite="mid:55AE626D.70107@oracle.com" type="cite"><tt>
<br>
<br>
In the fix I merge all implementations of getAudioXXX to the
SunFileReader.<br>
<br>
Note that I added a comment to the
SunFileReader.getAudioFileFormat(InputStream) that
implementation contradicts the specification, and it seems the
javadoc should be updated? And I created a new issue about
EOFException: <a moz-do-not-send="true"
class="moz-txt-link-freetext"
href="https://bugs.openjdk.java.net/browse/JDK-8131974">https://bugs.openjdk.java.net/browse/JDK-8131974</a><br>
</tt><br>
<tt>Also I have a related question about
WaveExtensibleFileReader why it was not added to the
spi.AudioFileReader? Because of this WaveExtensibleFileReader
actually is never used. Is that intentionally?<br>
<br>
Bug: <a moz-do-not-send="true" class="moz-txt-link-freetext"
href="https://bugs.openjdk.java.net/browse/JDK-8013586">https://bugs.openjdk.java.net/browse/JDK-8013586</a><br>
Webrev can be found at: <a moz-do-not-send="true"
class="moz-txt-link-freetext"
href="http://cr.openjdk.java.net/%7Eserb/8013586/webrev.02">http://cr.openjdk.java.net/~serb/8013586/webrev.02</a></tt><br>
<pre class="moz-signature" cols="72">--
Best regards, Sergey. </pre>
</blockquote>
<br>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">--
Best regards, Sergey. </pre>
</body>
</html>