import com.sun.image.codec.jpeg.* - 【StackMirror】|java|image-processing

I have a Java program when I compile it I get the following error

[javac] ...\MyClass.java:33: package com.sun.image.codec.jpeg does not exist
[javac] import com.sun.image.codec.jpeg.*;
[javac] ^

what can I do ?

What is the correct way of writing an image file now that the com.sun package is deprecated.

2009-12-15 11:00
by silverkid

Why are you using classes in the package com.sun.image.codec.jpeg? You are not supposed to use those classes directly: Why Developers Should Not Write Programs That Call 'sun' Packages.

What does your program do? Does it just try to read or write a JPG image? That's very easy with the ImageIO API. See this tutorial: Writing/Saving an Image.

Addition - The package com.sun.image.codec.jpeg has been removed in Java 7 as mentioned in the Java SE 7 and JDK 7 Compatibility Guide.

Synopsis: The Non-standard com.sun.image.codec.jpeg Package is Retired

Description: The com.sun.image.codec.jpeg package was added in JDK 1.2 (Dec 1998) as a non-standard way of controlling the loading and saving of JPEG format image files. This package was never part of the platform specification and it has been removed from the Java SE 7 release. The Java Image I/O API was added to the JDK 1.4 release as a standard API and eliminated the need for the com.sun.image.codec.jpeg package.

2009-12-15 12:20
by Jesper

Yes, unfortunately, reading a JPEG with ImageIO is much slowe - Maurice Perry 2012-04-03 12:13

ImageIO does not work with CMYK-JPEG - AvrDragon 2012-06-11 17:10

This is only an option if you're compiling your own code. This isn't always true. No-one wants to go and re-write a program just to compile it. The correct answer is by @mainzelM (just below at time of writing) - mjaggard 2012-11-21 13:47

@mjaggard The point is that you should not be using classes that are not in the public API. Doing so is at your own risk, and your program might not work on a future Java version. In this case, there's even a standard API (ImageIO) for loading JPG files, so even more reason not to use an undocumented, internal API - Jesper 2012-11-21 14:17

Yes, but I am not. I am compiling some software that does. I am NOT going to re-write it - mjaggard 2012-11-22 10:48

@Jesper, the document you linked about not using 'sun' packages, talks about not using packages that start with sun.. It does not tell anything about com.sun packages! So I think your comment is wrong in this context - danidemi 2015-02-11 09:51

@danidemi No, both sun.* and com.sun.* packages are part of the internals of the JDK and must not be used. You should only use what is documented in the Java API documentation. Note that the linked document mentions you should only use the documented java.*, javax.* and org.* packages - Jesper 2015-02-11 12:14

@Jesper, I give you what I think is a good counter example. The Javamail API contains lot of classes in com.sun. packages, like com.sun.mail.smtp.SMTPMessage that are well documented. So I see no reasons why a programmer should avoid using them - danidemi 2015-02-11 13:10

@danidemi But the JavaMail API is not part of the standard Java SE API, it's a separate library - Jesper 2015-02-11 13:16

@Jesper, at the end, there is a document that does not say explicitly that com.sun. classes should not be used, and there is an available well documented API from Oracle that offers classes, indeed, in the com.sun. package. So, can we say that, based only on the link you provided, it's not correct to say that a developer should not use com.sun. classes - danidemi 2015-02-11 13:36

@danidemi This is about packages in the Java SE API and not about add-on libraries that are not part of the API of the standard platform (such as JavaMail). As the FAQ clearly states you should not use anything else than the officially documented API of the standard platform. com.sun.image.codec.jpeg is an internal API of the standard platform, which you should not use directly - Jesper 2015-02-11 13:41

@Jesper, Ok I think got it. If a developer use just the classes from the JRE, she should only stick with java.*, javax.* and org.* if she wants to be sure the software runs on other JREs. At this point it's the Oracle document title that is misleading. It should be something like Why Developers Should Not Write Programs That Call Packages Others Than java.*, javax.*, org.*danidemi 2015-02-11 17:21

@Jesper Can you please join this http://chat.stackoverflow.com/rooms/82945/discussion-between-san-krish-and-stephen-c , i have an doubt with this issu - San Krish 2015-07-10 12:54

I had this problem when compiling with JDK 7. Strange enough Eclipse did not show this error, only javac did. The answer can be found in this Stackoverflow answer: javac uses a special symbol table that does not include all Sun-proprietary classes, and suppliying -XDignore.symbol.file makes the problem go away.

Of course, a much better solution is to rewrite the code without using the proprietary classes, but to support JDK 7 quickly, this option works.

2012-10-26 06:47
by mainzelM

With Maven: Use version 3.1 of maven-compiler-plugin and then -XDignore.symbol.fileATorras 2014-09-22 17:42

You can use <compilerArgument>-XDignore.symbol.file</compilerArgument> just as successfully without having to upgrade maven-compiler-plugi - Dzmitry 2015-07-06 11:18

@mainze How to add this through command prompt ? i need to apply it for my web app deployed in tomcat under linu - San Krish 2015-07-10 11:41

It's an argument for the Java compiler (javac) not for the JVM. It depends on your build tool how to add it - mainzelM 2015-08-27 06:40

Which JDK are you using? I think that this package is not a requirement and will only be available in Sun's JDK. This discussion explains.

You may be able to download the jar file and include it on your path file separately if you really want to use it though.

According to docs:

Note that the classes in the com.sun.image.codec.jpeg package are not part of the core Java APIs. They are a part of Sun's JDK and JRE distributions. Although other licensees may choose to distribute these classes, developers cannot depend on their availability in non-Sun implementations. We expect that equivalent functionality will eventually be available in a core API or standard extension.

2009-12-15 11:07
by Vincent Ramdhanie

Looks like you are using something that has been replaced. Maybe you are on Java 7?

Here is something that seems to describe this, and where to go to find it's proper replacement.

2009-12-15 11:10
by Francis Upton