import com.sun.image.codec.jpeg.*

Question

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.

score 58 · Answer 1 · edited May 23 '17 at 10:31

58

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.

edited May 23 '17 at 10:31

Community

1
1

answered Oct 26 '12 at 06:47

mainzelM

678
1
5
8

7

With Maven: Use version 3.1 of maven-compiler-plugin and then -XDignore.symbol.file – ATorras Sep 22 '14 at 17:42
You can use `-XDignore.symbol.file` just as successfully without having to upgrade maven-compiler-plugin – Dzmitry Jul 06 '15 at 11:18
@mainze How to add this through command prompt ? i need to apply it for my web app deployed in tomcat under linux – Santhosh Jul 10 '15 at 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 Aug 27 '15 at 06:40

Jesper · Accepted Answer · 2015-04-07T12:08:51.373

37

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.

edited Apr 07 '15 at 12:08

answered Dec 15 '09 at 12:20

Jesper

202,709
46
318
350

Yes, unfortunately, reading a JPEG with ImageIO is much slower – Maurice Perry Apr 03 '12 at 12:13
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 Nov 21 '12 at 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 Nov 21 '12 at 14:17
6

Yes, but *I* am not. I am compiling some software that does. I am NOT going to re-write it. – mjaggard Nov 22 '12 at 10:48
1

@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 Feb 11 '15 at 09:51
2

@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](http://docs.oracle.com/javase/8/docs/api/). Note that the linked document mentions you should only use the documented `java.*`, `javax.*` and `org.*` packages. – Jesper Feb 11 '15 at 12:14
@Jesper, I give you what I think is a good counter example. [The Javamail API](https://javamail.java.net/nonav/docs/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 Feb 11 '15 at 13:10
@danidemi But the JavaMail API is not part of the standard Java SE API, it's a separate library. – Jesper Feb 11 '15 at 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 Feb 11 '15 at 13:36
1

@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](http://www.oracle.com/technetwork/java/faq-sun-packages-142232.html) 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 Feb 11 '15 at 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 Feb 11 '15 at 17:21

score 3 · Answer 3 · answered Jul 02 '19 at 12:22

In general, try not to use classes from "sun." or "com.sun." packages, as this packages are considered implementation details, and are not part of the Java API.

They can cause problems when moving to new versions of Java because there is no backwards compatibility guarantee. Similarly, they can cause problems when moving to a different Java vendor, such as OpenJDK.

Such classes are almost always wrapped by Java API classes that should be used instead.

See: https://sonarcloud.io/organizations/default/rules?languages=java&open=squid%3AS1191&q=sun

score 1 · Answer 4 · answered Dec 15 '09 at 11:07

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.

score 1 · Answer 5 · answered Dec 15 '09 at 11:10

1

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.

answered Dec 15 '09 at 11:10

Francis Upton IV

19,322
3
53
57

score 1 · Answer 6 · answered Nov 26 '20 at 03:23

Add the below configuration in pom.xml for this issue

<build>
        <plugins>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-compiler-plugin</artifactId>
                <version>3.8.1</version>
                <configuration>
                    <source>1.7</source>
                    <target>1.7</target>
                    <encoding>UTF-8</encoding>
                    <compilerArguments>
                    <bootclasspath>
                            ${java.home}/lib/rt.jar${path.separator}${java.home}/lib/javaws.jar${path.separator}${java.home}/lib/jce.jar
                        </bootclasspath>
                     </compilerArguments>
                </configuration>
            </plugin>
        </plugins>
    </build>

It works for me.

import com.sun.image.codec.jpeg.*

6 Answers6

Linked

Related