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 good enough estimate which predicts
JDK7 - late 2008
JDK8 - late 2010