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
       JPEGCodec.createJPEGDecoder(...);
       ^
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
warning

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  customer  enough estimate which predicts
JDK7 - late 2008
JDK8 - late 2010
Posted Date : 2007-02-23 17:51:09.0

N/A

All relevant interest aliases have been solicited and so far there have been
no objections to this proposal.
Posted Date : 2007-02-23 17:51:09.0

The proposal (subject to change) is :

1. document in release notes it will be gone in JDK 8
2. In JDK 7 hide it completely from all compilation but keep it for runtime
3. Once that is done file a separate bug to track removing it in JDK8

The alternate proposal is
- remove completely in JDK 7 and document this in the release notes.
Posted Date : 2007-02-23 17:55:30.0

The fix that has been put back is just to hide this API from new compilation
by the JDK 7 javac compiler.
Posted Date : 2007-07-11 22:24:13.0

I'm disappointed by the decision to not support this API indefinitely.
The API was published and never deprecated.
If the javax.imageio API provides equivalent functionality,
it should be possible to modify the implementation of
com.sun.image.jpeg.codec to just act as an adapter shim
over javax.imageio.  If doing this is difficult, then
it will also be difficult for applications to migrate,
making it unreassonable to remove these classes.

Meanwhile, the IcedTea people have created a patch to
re-create this package, but with a stub implementation.
I'm not sure whether the intent is to flesh out the stubs,
or to merely make it possible for legacy applications
that use com.sun.image.codec.jpeg to continue to compile,
but perhaps fail at runtime.  The latter option is not 
in the spirit of Java, which is to prefer compile-time failure.

Um, you do *realize* that as of today, Java Advanced Imaging API still uses this class in the latest cvs? Why not just create a shim to Image I/O, like suggested?

Good to see this finally being dropped.  Use of this legacy API by applications prevents them from working with non-Sun JDKs like GNU Classpath and Apache Harmony.