Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-6527962

Retire the non-standard package com.sun.image.codec.jpeg



    • Subcomponent:
    • Resolved In Build:
    • CPU:
    • OS:
    • Verification:



        The package com.sun.image.codec.jpeg was added in JDK 1.2 (Dec 1998)
        as a non-standard way of controlling the loading and saving of JPEG
        format image files.
        It has never been part of the platform specification and is not part
        of any compatibility test suite and so compatible Java implementations
        are not required to include it.
        The documentation for it has always been buried under a separate
        'other API' heading, clearly distinct from the Java platform API
        specification. The intention was to replace it with a standard API.

        In JDK 1.4 (FCS/GA 2001) the Java Image I/O API was added
        (see JSR-15 at http://jcp.org/en/jsr/detail?id=15) as a standard API.
        This resides in the package javax.imageio.
        It provides a standard mechanism for controlling the loading and
        saving of sampled image formats and requires all compliant Java SE
        implementations to support JPEG as per the Image I/O specification.

        In JDK 6 to encourage migration to Image I/O several things happened.

        1. All documentation of com.sun.image.codec.jpeg was removed
        although the classes are still present in *Sun* implementations
        - I can't speak for others - and probably only direct Sun licensees
        are likely to ship the API assuming they bother to do so.

        2. When compiling code using these classes using JDK 6 a warning
        is emitted :

        warning: com.sun.image.codec.jpeg.JPEGCodec is Sun proprietary API and
        may be removed in a future release
        3. There were substantial performance improvements to Image I/O
        including JPEG, and overall the performance is now very similar
        between the two APIs.

        So we think its time to retire com.sun.image.codec.jpeg so we
        can focus on the single preferred standard API.

        However we are aware that applications do still use it, typically
        because they were written to run on JDK versions prior to 1.4,

        There are several options, not all exclusive :

        1. Remove completely in JDK 7 - the most aggressive option.

        2. Warn in JDK 7 release notes that it will be removed completely in
        JDK8 - this is really just incremental to the existing compilation

        3. Make further javac changes in JDK 7 so that the classes are not
        located when compiling. ie the compilation warning turns into an error.
        Again, with this option the classes *are* still available at runtime so
        that code compiled with 1.6 or earlier will still find these classes
        and run on JDK 7 This preserves binary compatibility.

        4. Remove the classes completely in a release after JDK 7
        after a combination of notifications via release notes
        and compiler warnings/errors. Ideally this would then
        happen in JDK8

        Implementing 2+3+4 comes down to using JDK 7 to provide
        a further period of grace to migrate and probably provides
        the right balance between notice and compatibility (to these
        non-standard, unsupported APIs). Particularly since JDK 6
        already began this process.

        How long does this give people to migrate?
        Our historical run rate of releases is one every two years.
        JDK 1.2 - Dec 1998
        JDK 6 Nov 2006
        Management may try different models and so forth but I think
        that's a good enough estimate which predicts
        JDK7 - late 2008
        JDK8 - late 2010


            Issue Links



                prr Philip Race
                prr Philip Race
                0 Vote for this issue
                0 Start watching this issue