Bug ID: JDK-4075967 Add-on Image Formats

Type: Enhancement
Component: client-libs
Sub-Component: 2d
Affected Version: 1.1.2

Priority: P5
Status: Closed
Resolution: Duplicate
OS: windows_95
CPU: x86

Submitted: 1997-09-02
Updated: 1999-05-10
Resolved: 1999-05-10


Name: rlT66838			Date: 09/02/97


There isn't a standard way to teach the system
about new image formats. The 'natural' way of
doing so would be to define an 'imageFormat'
interface, which would have a 'getImage' method
accepting a URL. If the URL is recognized by the
imageFormat (by using the file prefix or any other
criteria), it would return an Image object;
otherwise null. given a registerImageFormat
method, getImage could just loop on the available
formats and return the first one which claims the
URL.

Variants would be to allow the imageFormat to
examine the first few bytes of the file; or,
alternatively, have each imageFormat provide a
getFilePrefix method and have getImage use this
exclusively to decide which imageFormat to use.

======================================================================

WORK AROUND Name: rlT66838 Date: 09/02/97 We're trying to set up a system which would deal with a lot of image files from many sources. We'd like to allow our users to support such formats, and to be able to use formats which would become available in the future. Given the current state of affairs, we are forced to add each new format by manually adapting the system to the new drivers. The feature described above would allow format vendors to package their drivers so that no additional coding would be requires, and in fact the users would be able to just "drop in" the new format, just like they can add JavaBeans to an application generator. ======================================================================

11-06-2004