54

Is there a way to disable restrictions of javac 1.6.0_22 that prevent me from using JRE internal classes like sun.awt.event.* ?

I'm not looking for:

  1. an explanation why it is forbidden.
  2. suggestion to use different classes
  3. suggestion to use reflection
  4. suggestion to use ecj/eclipse

I just want to know if it is possible or not, and if it is then how.

Marcin Wisnicki
  • 4,511
  • 4
  • 35
  • 57
  • What errors are you getting exactly? I can compile against `sun.awt.*` just fine with javac 1.6.0_22 (on the Mac, though). – Thilo Nov 01 '10 at 03:00
  • I'm doing some experiments with Swing/AWT and have to access their internals. – Marcin Wisnicki Nov 01 '10 at 16:18
  • The same issue applies to other classes like SOAP implementations in com.sun.xml.internal.messaging.saaj.util.* and the same ignore.symbol.file trick (top answer below) is a work-around. Adding this comment here to help folks searching for this problem in that context. – jlevy Jun 15 '15 at 22:41

7 Answers7

97

I have found the answer myself.

When javac is compiling code it doesn't link against rt.jar by default. Instead it uses special symbol file lib/ct.sym with class stubs.

Surprisingly this file contains many but not all of internal sun classes. In my case one of those more-internal-than-usual classes was sun.awt.event.IgnorePaintEvent.

And the answer to my question is: javac -XDignore.symbol.file

That's what javac uses for compiling rt.jar.

Marcin Wisnicki
  • 4,511
  • 4
  • 35
  • 57
  • I had exactly the same problem, was trying to compile but I was getting this error `package sun.nio.fs does not exist` for `sun.nio.fs.BasicFileAttributesHolder` – Jaime Hablutzel Jan 10 '13 at 20:19
  • Also see @karmakaze answer for additional workaround for Maven compiler plugin. – karmakaze May 27 '15 at 03:16
  • 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:42
  • @SanKrish - What part of `javac -XDignore.symbol.file` do you not understand? – Stephen C Jul 10 '15 at 12:35
  • @Stephen Thanks for your reply. i just wanted to config the `javac -XDignore.symbol.file` for tomcat instead for a class – Santhosh Jul 10 '15 at 12:36
  • The problem is i dont use any build tools manually . just use eclipse to build. so is it possible to configure the property for an environment ? – Santhosh Jul 10 '15 at 12:39
  • So why did you say you wanted to turn off the warning for >>Tomcat<< and for the command line?? You are really not making much sense ... – Stephen C Jul 10 '15 at 12:41
  • Anyhow, the answer make Eclipse suppress those errors / warnings is to update the compiler preferences: in the Eclipse "Java > Compiler > Errors/Warnings" preference page. – Stephen C Jul 10 '15 at 12:44
  • Thanks . Can you please elaborate ? What to add there ? – Santhosh Jul 10 '15 at 12:46
  • Let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/82945/discussion-between-san-krish-and-stephen-c). – Santhosh Jul 10 '15 at 12:46
  • @StephenC Thanks ! Can you please have a look at issue mentioned in chat and provide your suggestion on it – Santhosh Jul 10 '15 at 12:52
  • Yea ... well that is a consequence using a proprietary / internal `com.sun.*` class that was available in one version of Java and not another. The best solution is to stop using that class; http://stackoverflow.com/questions/1834826/it-is-a-bad-practice-to-use-suns-proprietary-java-classes – Stephen C Jul 10 '15 at 13:10
42

In addition to the answer by @marcin-wisnicki if you're using Maven, note that the compiler plugin will silently drop any -XD flags, unless you also specify <fork>true</fork>: e.g.

<build>
    <plugins>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-compiler-plugin</artifactId>
            <version>3.3</version>
            <configuration>
                <source>1.7</source>
                <target>1.7</target>
                <compilerArgs>
                    <arg>-XDignore.symbol.file</arg>
                </compilerArgs>
                <fork>true</fork>
            </configuration>
            ...
davidxxx
  • 125,838
  • 23
  • 214
  • 215
karmakaze
  • 34,689
  • 1
  • 30
  • 32
2

There's a better solution. First add the option to javac -XDenableSunApiLintControl and then use @SupressWarnings("sunapi") in your code.

juancn
  • 2,483
  • 2
  • 20
  • 25
1

If you are using Gradle, you need to use these options

compileJava {
    // enable using internal libraries
    options.fork = true
    options.forkOptions.executable = 'javac'
    options.compilerArgs << '-XDignore.symbol.file' }
Kamiel Ahmadpour
  • 1,215
  • 12
  • 16
0

Normally, this only produces a Warning message; e.g.

[javac] /media/disk/opensso2/opensso/products/federation/openfm/source/com/sun/identity/wss/xmlsig/WSSSignatureProvider.java:46: warning: com.sun.org.apache.xpath.internal.XPathAPI is Sun proprietary API and may be removed in a future release
[javac] import com.sun.org.apache.xpath.internal.XPathAPI;

Perhaps you have told the Java compiler to treat warnings as errors.

Stephen C
  • 698,415
  • 94
  • 811
  • 1,216
  • 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:43
0

Another way is change jdk.

In my case project java version 1.8. I used from jdk 11. Therefore This error has found in my project. So I changed my jdk from 11 to 1.8. It has worked for me.

0

Adding to the answer by @kamiel-ahmadpour: I had to set the javaHome when running Gradle's compile tasks via IntelliJ. My config now looks like this written in Kotlin DSL:

tasks.withType<JavaCompile> {
    options.isFork = true
    options.forkOptions.executable = "javac"
    options.forkOptions.javaHome = file(System.getProperty("java.home"))
    options.compilerArgs.add("-XDignore.symbol.file")
}

Without the javaHome the build would fail with errors like:

... error: package javax.xml.bind.annotation does not exist
import javax.xml.bind.annotation.XmlAccessType;
                            ^

Running Gradle tasks from the terminal doesn't need the explicitly configured javaHome and I didn't find the actual cause for the different behaviour, yet.

Environment:

  • Java 8
  • Gradle 7.5.1
  • IntelliJ 2022.2.3
gesellix
  • 3,024
  • 28
  • 31