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 Does anyone think they have current code that uses com.sun.image.codec.jpeg that would have a problem with this proposed removal? Any comment on the options? FYI I am sending this to each of : [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] so many of you may get this message several times. -Phil Race, Java 2D. =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff JAVA2D-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".