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.
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.jpegPackage is Retired
com.sun.image.codec.jpegpackage 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
sun.. It does not tell anything about
com.sunpackages! So I think your comment is wrong in this context - danidemi 2015-02-11 09:51
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
org.*packages - Jesper 2015-02-11 12:14
com.sun.mail.smtp.SMTPMessagethat are well documented. So I see no reasons why a programmer should avoid using them - danidemi 2015-02-11 13:10
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
com.sun.image.codec.jpegis an internal API of the standard platform, which you should not use directly - Jesper 2015-02-11 13:41
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
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.
<compilerArgument>-XDignore.symbol.file</compilerArgument>just as successfully without having to upgrade maven-compiler-plugi - Dzmitry 2015-07-06 11:18
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.
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.