Re: [OpenJDK 2D-Dev] Status of com.sun.image.codec.jpeg

[Martin Buchholz]

I decided to pursue this a little more,
since our code base contains multiple references
to com.sun.image.codec.jpeg
and I'll probably have to deal with it,
even though I know nothing about image I/O.

I added the following comment to the bug:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6527962
====
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.

Martin

On Thu, Aug 14, 2008 at 9:54 AM, Martin Buchholz <[EMAIL PROTECTED]> wrote:
> Hi Chris,
>
> Thanks very much for that informative pointer.
>
> In hindsight, it would have been good if @deprecated
> warnings had been added to these classes years ago.
> Today it's probably too late to do much good.
>
> Martin
>
> On Thu, Aug 14, 2008 at 9:45 AM, Chris Campbell
> <[EMAIL PROTECTED]> wrote:
>> Hi Martin,
>>
>> The history (and fate) of those classes is documented here:
>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6527962
>>
>> Chris
>>
>>
>> On Aug 14, 2008, at 9:32 AM, Martin Buchholz wrote:
>>>
>>> Hi 2d guys,
>>>
>>> We're testing different flavors of OpenJDK,
>>> and noticing uses of classes in com.sun.image.codec.jpeg.
>>> These classes are still in non-OpenJDK JDK7.
>>> They were removed from OpenJDK, probably
>>> because they were encumbered (proprietary Kodak code).
>>> The IcedTea folks have created new versions of these
>>> classes, but they appear to be only stubs.
>>>
>>> Can we have a clear statement about the status?
>>> These classes were documented at least for 1.4, e.g.
>>>
>>>
>>> http://java.sun.com/j2se/1.4.2/docs/guide/2d/api-jpeg/com/sun/image/codec/jpeg/JPEGImageEncoder.html
>>>
>>> There does appear to be full support for the JPEG image
>>> standard in OpenJDK and IcedTea.  It would be nice if the
>>> API in com.sun.image.codec.jpeg could be adapted, or if not,
>>> at least provide stubs with clear @deprecated tags that
>>> explain to maintainers of legacy code
>>> what APIs should be used instead.
>>>
>>> Thanks,
>>>
>>> Martin
>>
>>
>