Bug 144414 - JDT Compiler fails while standard javac compiler can proceed
Summary: JDT Compiler fails while standard javac compiler can proceed
Status: VERIFIED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.1.2   Edit
Hardware: PC Windows 2000
: P3 normal (vote)
Target Milestone: 3.2.1   Edit
Assignee: Kent Johnson CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-05-30 07:16 EDT by Maarten Coene CLA
Modified: 2006-09-12 08:19 EDT (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Maarten Coene CLA 2006-05-30 07:16:28 EDT
Hi,

I have a situation where the standard javac compiler can compile my source file, while the JDT compiler fails with a compilation error.

Consider the following classes:

================= test/Dao.java ===================
package test;

import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;

public class Dao {
    protected static Log log = LogFactory.getLog(Dao.class);
}


================= Test.java ===================
import test.Dao;

public class Test extends Dao {
    private static Object log = new Object();
}


The Dao.class is located in a jar file named "commons.jar"
The file Test.java is located in an Eclipse project. The build path of the project only contains the commons.jar file.

The project fails to build with the following error: 
The type org.apache.commons.logging.Log cannot be resolved. It is in directly referenced from required .class files

However: I can compile this Test.java file with the standard javac compiler without any error! (And yes: I only have the commons.jar in my classpath when compiling with the standard javac compiler :-))

regards,
Maarten
Comment 1 Frederic Fusier CLA 2006-05-30 10:39:08 EDT
Reproduced using 3.2 RC6.
This problem already occured in 3.1.2
Comment 2 Kent Johnson CLA 2006-06-01 16:26:09 EDT
This is a straight forward 1 line fix. We did not notice that FieldDeclaration had called findField() with needToResolve set to false.

Added BuildpathTest.testMissingFieldType
Comment 3 Frederic Fusier CLA 2006-06-12 06:16:12 EDT
Released for 3.2.1
Released for 3.3 M1 while merging TARGET_321 in HEAD
Comment 4 Frederic Fusier CLA 2006-08-07 11:18:11 EDT
Verified for 3.3 M1 using build I20060807-0010.
Comment 5 Frederic Fusier CLA 2006-09-12 08:19:27 EDT
Verified for 3.2.1 using build M20060908-1655.