Ignoring Compilation errors - Java

I have around 1500 files to compile, in which 15-20 file开发者_JAVA百科s have compilation errors. These files are not under my control, so I could not do any modification/update/delete. So, i have two questions here.

1) how do i ignore the compilation errors from these 15-20 files and continue to produce the .class file for rest of them. is there any javac commandline option or anything which will ignore the compliation errors and produce the .class files for all other non error files.

2)will the java compiler abort compilation as soon as it sees these errors or will it continue compiling(producing .class files) everything else and at the end then complain about these files with errors.

You can use Eclipse. Its internal compiler is - at least in some cases - able to keep going with the rest of the build, even when some classes don't compile fully. It will even produce class files for the broken classes if possible, generating methods which throw an exception as soon as they're called.

I would strongly recommend that you simply take a copy of all the source and fix the errors at least in your own copy as early as possible, but Eclipse's partial compilation may help you.

You cannot ignore compile errors. They will always fail the build.

Your only choices are to talk to whoever controls the files to get them fixed or find a way to otherwise replace them.

If you try to remove them from the build, you will also have to remove any files that use those files. For example

class A {
    B b;
}

If B has a compile error, your build script can skip B.java, but when you hit A.java, it's going to try to compile B anyway, so A has to be removed. This may prove to be a non-trivial task.

You could write yourself a script that traverses your source tree and calls javac for each java file individually. This way you will end up with all files compiled correctly that do not depend on the files with errors. This would be a horrendously slow operation, though. I would expect it to take several 100 times longer than a single call to javac (considering you would end up with about 1500 calls).

You can exclude certain source files from compiling using an exclude tag in the ant task.

  <target name="compile" description="Compile Java source files">
    <javac destdir="classes" classpathref="classpath">
      <src path="src"/>
      <exclude name="**/excluded_folder/**"/>
    </javac>
  </target>

EDIT: But of course any java files that are dependent on the excluded classes will also fail to compile unless you already have a pre-compiled version of excluded files in the classpath.

Create mockups of the offending files. Basically the same idea as a C header file, include the function signatures and reasonable default return values (null, false, 0). This will allow javac to compile everything, just make sure the mock classes don't get included in the final distribution, or you'll have strange bugs when they end up first in the classpath. This works for implementing broken interfaces and inheriting from broken classes too.

What do you mean

which will ignore the compliation errors and produce the .class files for all other non error files

Do you realise that if these files are related ( as if in a single project ) then the dependent source files will not compile too.. ? There is no way to by-pass that except to correct the compilation errors and retrying !

1. Tell the one who broke the code (diplomatically, of course) to fix it ASAP. Others have suggested (see 2nd comment there) to make these occurrences public (within a team/company), which greatly reduces the number of such compilation errors
2. Comment everything that prevents the code from compiling (supposed that you don't need those parts)

You should not have to deal with not-compiling code, but the one who committed it. If there are more people working on that project, everyone has to deal with that same problem on his local machine (find out why it didn't compile, track down the erroneous classes, exclude/comment those classes if your code does not depend on them, rebuild, etc.) It is much more efficient to have only 1 person to fix the problem, and everyone else just updates his local repository.