Eclipse/Android:"Errors Running Builder 'Android Pre Compiler' on Project..."

Eclipse / Android : Errors running builder 'Android Pre Compiler' on project...

I always hate answering my own questions, but this is a genuine solution.

The 21.0.1 version of the ADT tools has a bug that prevents a project building if you have any files without extensions in them. This is a particular problem for users (like me) using subversion with has extension-less files.

One recommended solution is to install these 'subversive' Eclipse plugins (Help > Install new Software > Work with your Eclipse version site > Expand 'Collaboration' > Choose 'Subversive SVN JDT Ignore Extensions' and 'Subversive SVN Team Provider') but this didn't work for me (I'm on Indigo, perhaps on Juno it works).

The solution is to install the 21.1 preview version of the ADT tools and SDK manager from Google. Clear instructions can be found here and you can read all the background add your voice to the angry mob of developers here.

Annoying Errors running builder 'Android Pre Compiler' on project dialog

Someone found the answer! In my case, it was the svn extension-less files that were causing the problems. See solution here.

Errors occurred during the build. Errors running builder 'Android Pre Compiler' on project 'com.xxx...'. com/android/sdklib/util/SparseArray

Eclipse platform
version=4.2.0. Android SDK 4.3 and 4.2.2 both I used.
Nothing worked for me in the web. Tried to update the eclipse and many more setting changes as suggested in forums.

Eventually I use a fresh eclipse. That was the only way.

Android Pre Compiler' error 'Path must include project and resource name'

This one's my fault: I had the *.c files at the root of the project (hoping to keep the same paths as upstream svn), and thus the root as a source folder, and ADT started objecting to that, by crashing in com.android.ide.eclipse.adt.internal.build.SourceProcessor.buildSourceFileList() trying to resolve /SGTPuzzles to a project and resource (i.e. subfolder), which fails. Fixed in current git by mv *.c jni/.

How to fix java.lang.UnsupportedClassVersionError: Unsupported major.minor version

The version number shown describes the version of the JRE the class file is compatible with.

The reported major numbers are:

Java SE 18 = 62,
Java SE 17 = 61,
Java SE 16 = 60, 
Java SE 15 = 59,
Java SE 14 = 58,
Java SE 13 = 57,
Java SE 12 = 56,
Java SE 11 = 55,
Java SE 10 = 54,
Java SE 9 = 53,
Java SE 8 = 52,
Java SE 7 = 51,
Java SE 6.0 = 50,
Java SE 5.0 = 49,
JDK 1.4 = 48,
JDK 1.3 = 47,
JDK 1.2 = 46,
JDK 1.1 = 45

(Source: Wikipedia)

To fix the actual problem you should try to either run the Java code with a newer version of Java JRE or specify the target parameter to the Java compiler to instruct the compiler to create code compatible with earlier Java versions.

For example, in order to generate class files compatible with Java 1.4, use the following command line:

javac -target 1.4 HelloWorld.java

With newer versions of the Java compiler you are likely to get a warning about the bootstrap class path not being set. More information about this error is available in a blog post New javac warning for setting an older source without bootclasspath.

How can I solve java.lang.NoClassDefFoundError?

After you compile your code, you end up with .class files for each class in your program. These binary files are the bytecode that Java interprets to execute your program. The NoClassDefFoundError indicates that the classloader (in this case java.net.URLClassLoader), which is responsible for dynamically loading classes, cannot find the .class file for the class that you're trying to use.

Your code wouldn't compile if the required classes weren't present (unless classes are loaded with reflection), so usually this exception means that your classpath doesn't include the required classes. Remember that the classloader (specifically java.net.URLClassLoader) will look for classes in package a.b.c in folder a/b/c/ in each entry in your classpath. NoClassDefFoundError can also indicate that you're missing a transitive dependency of a .jar file that you've compiled against and you're trying to use.

For example, if you had a class com.example.Foo, after compiling you would have a class file Foo.class. Say for example your working directory is .../project/. That class file must be placed in .../project/com/example, and you would set your classpath to .../project/.

Side note: I would recommend taking advantage of the amazing tooling that exists for Java and JVM languages. Modern IDEs like Eclipse and IntelliJ IDEA and build management tools like Maven or Gradle will help you not have to worry about classpaths (as much) and focus on the code! That said, this link explains how to set the classpath when you execute on the command line.

---

Related Topics