Search code examples
javajavac

Ignore unresolved symbols when compiling java with javac

I am using Google Plugin in STS and it reports missing class. I decided to go a quick and dirty way and download the class, compile it and put it into plugin folder or jar file.

The class is here: Java2HTMLEntityReader.java

When I compile, I of course get some errors:

Java2HTMLEntityReader.java:19: error: package org.eclipse.jdt.internal.compiler.parser does not exist
import org.eclipse.jdt.internal.compiler.parser.*;
^
Java2HTMLEntityReader.java:28: error: cannot find symbol
public class Java2HTMLEntityReader extends SubstitutionTextReader {
                                           ^
  symbol: class SubstitutionTextReader
Java2HTMLEntityReader.java:58: error: cannot find symbol
                setSkipWhitespace(false);
                ^
  symbol:   method setSkipWhitespace(boolean)
  location: class Java2HTMLEntityReader
Java2HTMLEntityReader.java:69: error: cannot find symbol
                        c = nextChar();
                            ^
  symbol:   method nextChar()
  location: class Java2HTMLEntityReader
Java2HTMLEntityReader.java:105: error: cannot find symbol
                } else if (!ScannerHelper.isWhitespace((char) c)) {
                            ^
  symbol:   variable ScannerHelper
  location: class Java2HTMLEntityReader
Note: Java2HTMLEntityReader.java uses unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
5 errors

That's because I didn't give the java compiler refference to the package. And I don't intend to! I want to compile it with those errors, I assume it will work when I put it on the correct classpath.

Solution

  • If you'd use the Eclipse compiler to compile that class, you could request creation of .class files despite compile errors. On the command line this is done using the option -proceedOnError. To the best of my knowledge javac does not have such an option.

    Mind you, that unresolved types in API positions (super types, method signatures) may render the resulting class file useless.

    I don't really see a good reason for hacking such a stub .class file for compilation. If you have the corresponding jar file available at runtime, you should really use the same jar also during compilation.