FINAL PROPOSAL: JavaSound extensions and service providers for Ogg/Vorbis and Ogg/FLAC

[Tor-Einar Jarnbjo]

* Proposed goals:

  - Add JavaSound service providers for reading Ogg/Vorbis and Ogg/FLAC.
 
    There are several RFEs touching this subject, e.g. 4671067, 6405350
    and 4499904. I am not going to reinvent the wheel for this, but I
    would refurbish the code from my J-Ogg project (www.j-ogg.de) and
    donate it to the OpenJDK project. I beleive that J-Ogg is mostly
    bug free, but the code base could need some refactoring and cleanup.
    
    Some specific points to consider:
    
    - add generics
    - migrating to NIO may make it easier to support different datasources
    - better abstraction of the different datasources, especially when
      it comes to caching and positioning

  - Extend AudioInputStream to optionally support positioning within the
    audio stream.
 
    To make JavaSound a feasible backing technology for e.g. simple media
    (audio) players, AudioInputStream should support public methods for
    positioning. Although this functionality is offered by JMF, it makes
    sense to me, to offer such functionality in the standard J2SE API.

    boolean AudioInputStream#isSeekable();

    long    AudioInputStream#getFramePos();
    void    AudioInputStream#setFramePos(long newpos);
    
    The last methods acting on the protected field
    AudioInputStream#framePos.
    
  - Extend AudioFileReader to support further seekable sources for raw data.
 
    Currently, AudioFileReader can read an audio stream from either a File,
    an InputStream or a URL. This means, that to propagate "seekability" to
    the AudioInputStream without much fuzz, the source has to be a File,
    since InputStreams and URLs per se, are not offering a public interface
    for positioning. In practice however, some InputStream implementations
    are indeed seekable, e.g. ByteArrayInputStream and FileInputStream and
    depending on the underlying protocol, InputStreams returned from URL/
    URLConnection may be seekable as well. Positioning in the stream from a
    file URL should always be possible, and utilizing the range header in
    HTTP, positioning in the stream from an HTTP URL may also be possible
    (and desired, e.g. for audio streaming over HTTP) if the  server
    supports that functionality.
    
    Considering that positioning with a stream can be useful in many other
    situations as well, my suggestion would be to either introduce a new
    interface java.io.SeekableInputStream, or perhaps just as well add the
    following methods to InputStream directly:
    
    boolean ...#isSeekable();
    long    ...#getPosition();
    void    ...#setPosition(long newpos);
    
    Having the methods directly in the InputStream class, would make it
    easier for delegating implementations of InputStream to propagate the
    functionality, e.g. if a seekable stream is wrapped by a
    BufferedInputStream.
    
    In InputStream, these methods would of course be implemented to return
    false and throw UnsupportedOperationException, but as a starter, it
    would be very easy to add this functionality to at least the following
    classes:
    
    - ByteArrayInputStream
    - FileInputStream
    - FilterInputStream
    - BufferedInputStream
    
    At some further point (it's not part of this actual proposal), it
    should also be considered to add this functionality to the InputStreams
    return by URL/URLConnection, if the protocol used supports positioning.
    

Regards,
Tor