Bug 239589 - java.lang.Object cannot be resolved during buidling eclipse3.4 for IPF
Summary: java.lang.Object cannot be resolved during buidling eclipse3.4 for IPF
Status: RESOLVED DUPLICATE of bug 271953
Alias: None
Product: Platform
Classification: Eclipse Project
Component: Releng (show other bugs)
Version: 3.4   Edit
Hardware: PC Windows XP
: P3 critical with 3 votes (vote)
Target Milestone: ---   Edit
Assignee: Kim Moir CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-07-04 06:17 EDT by Lei Li CLA
Modified: 2009-08-17 11:18 EDT (History)
6 users (show)

See Also:


Attachments
log of building eclipse 3.4 for IPF on windows xp (91.68 KB, text/plain)
2008-07-04 06:17 EDT, Lei Li CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Lei Li CLA 2008-07-04 06:17:04 EDT
Created attachment 106566 [details]
log of building eclipse 3.4 for IPF on windows xp 

When I set $JAVA_HOME and $ANT_HOME environment variables and then build eclipse3.4 for IPF on windows xp professional, a lot of errors occurred at the beginning of building. The first error is as follows:

    [javac] ----------
    [javac] 1. ERROR in C:\3.4\eclipse-sourceBuild-srcIncluded-3.4\plugins\org.eclipse.equinox.launcher\src\org\eclipse\core\launcher\Main.java (at line 1)
    [javac] 	/*******************************************************************************
    [javac] 	^
    [javac] The type java.lang.Object cannot be resolved. It is indirectly referenced from required .class files


Moreover, when I build eclipse 3.4M7 for IPF on the same machine with the same environment variables setting, it is successful. However, when I build eclipse3.4 with build date--17th,June,2008, it always failed with the same above error.
Comment 1 Kim Moir CLA 2008-07-17 17:13:31 EDT
What vm are you using to build this drop? What is $JAVA_HOME set to?
Comment 2 Lei Li CLA 2008-07-18 02:13:18 EDT
(In reply to comment #1)
> What vm are you using to build this drop? What is $JAVA_HOME set to?

 I am always using jdk-1_5_0_15-windows-i586-p.exe downloaded from Sun. And $JAVA_HOME is set to C:\Program files\Java\jdk1.5.0_15.Two months ago, when I build eclipse 3.4M7 for IPF with this environment variables setting, it is successful.
Comment 3 Jörg Schaible CLA 2008-08-05 03:13:54 EDT
This not only happens when building Eclipse, this is a general problem. We have a workplace with ~220 dependent projects and the problem occur quite often. 

Suddenly out of plain air (typically when opening a Java file and starting to edit it) java.lang.Object is no longer known. It can only be solved by "refreshing" the classpath e.g. opening the properties and change the order of the build path. If you're lucky the dependent projects will fix themselves also, but that's not always the case.

The error view contains in Eclipse 3.4 several entries of this type:

============== %< ===================
Severity: Error
Message: Could not retrieve declared methods
Stack trace:
org.eclipse.jdt.internal.compiler.problem.AbortCompilation
at org.eclipse.jdt.internal.compiler.problem.ProblemHandler.handle(ProblemHandler.java:121)
at org.eclipse.jdt.internal.compiler.problem.ProblemHandler.handle(ProblemHandler.java:179)
at org.eclipse.jdt.internal.compiler.problem.ProblemReporter.handle(ProblemReporter.java:1830)
at org.eclipse.jdt.internal.compiler.problem.ProblemReporter.isClassPathCorrect(ProblemReporter.java:3702)
at org.eclipse.jdt.internal.compiler.lookup.UnresolvedReferenceBinding.resolve(UnresolvedReferenceBinding.java:54)
at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.resolveType(BinaryTypeBinding.java:101)
at org.eclipse.jdt.internal.compiler.lookup.PackageBinding.getType(PackageBinding.java:137)
at org.eclipse.jdt.internal.compiler.lookup.Scope.findType(Scope.java:1390)
at org.eclipse.jdt.internal.compiler.lookup.Scope.getTypeOrPackage(Scope.java:2483)
at org.eclipse.jdt.internal.compiler.lookup.Scope.getType(Scope.java:2184)
at org.eclipse.jdt.internal.compiler.ast.SingleTypeReference.getTypeBinding(SingleTypeReference.java:44)
at org.eclipse.jdt.internal.compiler.ast.TypeReference.internalResolveType(TypeReference.java:130)
at org.eclipse.jdt.internal.compiler.ast.TypeReference.resolveType(TypeReference.java:197)
at org.eclipse.jdt.internal.compiler.lookup.SourceTypeBinding.resolveTypesFor(SourceTypeBinding.java:1392)
at org.eclipse.jdt.internal.compiler.lookup.SourceTypeBinding.methods(SourceTypeBinding.java:1123)
at org.eclipse.jdt.internal.compiler.lookup.ReferenceBinding.availableMethods(ReferenceBinding.java:174)
at org.eclipse.jdt.core.dom.TypeBinding.getDeclaredMethods(TypeBinding.java:232)
at org.eclipse.jdt.internal.corext.dom.Bindings.findOverriddenMethodInType(Bindings.java:439)
at org.eclipse.jdt.internal.corext.dom.Bindings.findOverriddenMethodInHierarchy(Bindings.java:456)
at org.eclipse.jdt.internal.corext.dom.Bindings.findOverriddenMethod(Bindings.java:490)
at org.eclipse.jdt.internal.ui.javaeditor.OverrideIndicatorManager$1.visit(OverrideIndicatorManager.java:182)
at org.eclipse.jdt.core.dom.MethodDeclaration.accept0(MethodDeclaration.java:487)
at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2478)
at org.eclipse.jdt.core.dom.ASTNode.acceptChildren(ASTNode.java:2548)
at org.eclipse.jdt.core.dom.TypeDeclaration.accept0(TypeDeclaration.java:484)
at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2478)
at org.eclipse.jdt.core.dom.ASTNode.acceptChildren(ASTNode.java:2548)
at org.eclipse.jdt.core.dom.CompilationUnit.accept0(CompilationUnit.java:214)
at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2478)
at org.eclipse.jdt.internal.ui.javaeditor.OverrideIndicatorManager.updateAnnotations(OverrideIndicatorManager.java:175)
at org.eclipse.jdt.internal.ui.javaeditor.OverrideIndicatorManager.reconciled(OverrideIndicatorManager.java:254)
at org.eclipse.jdt.internal.ui.javaeditor.CompilationUnitEditor.reconciled(CompilationUnitEditor.java:1616)
at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy.reconciled(JavaReconcilingStrategy.java:210)
at org.eclipse.jdt.internal.ui.text.JavaCompositeReconcilingStrategy.reconciled(JavaCompositeReconcilingStrategy.java:161)
at org.eclipse.jdt.internal.ui.text.JavaCompositeReconcilingStrategy.reconcile(JavaCompositeReconcilingStrategy.java:110)
at org.eclipse.jface.text.reconciler.MonoReconciler.process(MonoReconciler.java:77)
at org.eclipse.jface.text.reconciler.AbstractReconciler$BackgroundThread.run(AbstractReconciler.java:206)
============== %< ===================

I am running Eclipse on Windows with JDK 1.6.0, but the default compiler of the workspace is JDK 1.4.2_13. Note, that all people in our team are hit by this problem from time to time and we all use different JDK versions (1.5.0_x and 1.6.0_x) on Windows. Also note, that we suffer from this annoying problem since long ago, it happened to me with all versions since 3.0.x. On top this problem was reported here in Bugzilla more than once and closed as fixed! It's not!

However, what this case might have in common with the original posters issue: He seems to compile the Java sources externally with Ant. We do so with Maven.
Comment 4 Andrea Aime CLA 2008-09-15 03:53:35 EDT
I am too experiencing the same problem as reported by Joerg Shaible, I have a workspace with 100+ projects, all generated by maven, and almost every day some of the projects do loose their ability to reference java.lang.Object.
The cure is usually to:
- force a change in the classpath from the UI (such as removing the jre library and adding it back)
- run mvn eclipse:eclipse again and force a project refresh in Eclipse
Comment 5 TsanChung CLA 2008-09-28 17:10:55 EDT
I want to build a 64-bit eclipse binary for 64-bit jdk 1.6, AIX 5.3 on ppc.
I unzip source R-3.4.1 eclipse-sourceBuild-srcIncluded-3.4.1.zip.
Then do:
export PATH=$PATH:/home/twong/apache-ant-1.7.1/bin
export ANT_HOME=/home/twong/apache-ant-1.7.1
export JAVA_HOME=/usr/java6_64

I tried different JavaSE-1.6 values for the build.properties file:
#JavaSE-1.6=/usr/java6_64/lib
#JavaSE-1.6=/usr/java6_64/jre/lib/;/usr/java6_64/lib
JavaSE-1.6=/usr/java6_64/jre/lib

I tried several times with different dtterm and ssh sessions but still have "The type java.lang.Object cannot be resolved" compile error.

$ sh build -os aix -ws motif -arch ppc
     [echo] TARGET: compiler
     [echo] UPDATE ecj.jar

BUILD SUCCESSFUL
Total time: 38 seconds
     [echo] TARGET: compiler2
     [echo] compilerArg -enableJavadoc -nowarn -encoding ISO-8859-1
     [echo] build compiler org.eclipse.jdt.core.JDTCompilerAdapter
     [echo] UPDATE ecj.jar

BUILD SUCCESSFUL
Total time: 43 seconds
     [echo] Deleting jars to recompile...
     [echo] Compiling...
    [javac] ----------
    [javac] 1. ERROR in /home/twong/eclipsesrc/plugins/org.eclipse.equinox.launcher/src/org/eclipse/core/launcher/Main.java (at line 1)
    [javac] 	/*******************************************************************************
    [javac] 	^
    [javac] The type java.lang.Object cannot be resolved. It is indirectly referenced from required .class files
    [javac] ----------
...

$ java -version
java version "1.6.0"
Java(TM) SE Runtime Environment (build pap6460sr2-20080818_01(SR2))
IBM J9 VM (build 2.4, J2RE 1.6.0 IBM J9 2.4 AIX ppc64-64 jvmap6460-20080816_22093 (JIT enabled, AOT enabled)
J9VM - 20080816_022093_BHdSMr
JIT  - r9_20080721_1330ifx2
GC   - 20080724_AA)
JCL  - 20080808_02

Comment 6 Kim Moir CLA 2009-08-17 11:18:49 EDT
Regarding  the issue with java.lang.Object not being resolved, you need to add JAVA_HOME to your PATH.  

Since 3.4 isn't an open build stream anymore, please refer to bug 271953 for issues related to source build in the 3.5 and 3.6 stream builds.

*** This bug has been marked as a duplicate of bug 271953 ***