Community
Participate
Working Groups
Created attachment 141752 [details] simplest project to recreate the problem without hibernate jars (to be included) STEPS TO REPRODUCE ON AN EMPTY WORKSPACE: 1. Create new EAR 1.4 targeting WAS 6.1: "SimplestEAR" 2. Create new Dynamic Web Module "SimplestDummyWeb" 3. Add to the root directory of the EAR the following jars: hibernate-annotations-3.4GA.jar hibernate-commons-annotations-3.3.1.jar hibernate-core-3.3.1GA.jar hibernate-entitymanager-3.4.jar hibernate-validator-3.1.0GA.jar (probably only the first three are actually needed) 4. Create a Java project "JavaProjBase" containing the following class: ----------------------- package types; public class Type1 { } ----------------------- Export it as a jar file called: "java-proj-base.jar" 5. Add this jar to the root directory of the EAR 6. Create a Java Utility Project "JavaProjUtil" with following classpath: <?xml version="1.0" encoding="UTF-8"?> <classpath> <classpathentry kind="src" path="src"/> <classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER"/> <classpathentry combineaccessrules="false" kind="src" path="/JavaProjBase"/> <classpathentry kind="con" path="org.eclipse.jst.j2ee.internal.module.container"/> <classpathentry kind="output" path="bin"/> </classpath> and MANIFEST.MF Manifest-Version: 1.0 Class-Path: java-proj-util.jar hibernate-annotations-3.4GA.jar 7. Add the following class to this project: ----------------- package utils; @org.hibernate.annotations.TypeDefs( value={ @org.hibernate.annotations.TypeDef(name="Type1", typeClass=types.Type1.class), }) public class Util1 { } ---------------- THE TRICK IS THE TYPE OF REFERENCE FROM Util1 to Type1, via the ANNOTATION. 8. Export the above project as jar, reusing the existing MANIFEST: java-proj-util.jar 9. Add to the EAR the following jars: java-proj-util.jar 10. Add to the Java EE Module dependencies of the project "SimplestDummyWeb" the java-proj-util.jar 11. Add to "SimplestDummyWeb" the following Java file: ------------- package com; import utils.Util1; public class Class2 { Util1 myUtil; Util1 doSomething(Util1 util1){ return new Util1(); }; } ------------- Result: You have no errors in problem view nor in Enterprise Explorer/Project Explorer/Navigator. However, when you open the file in the Java editor you get the error: "The type types.Type1 cannot be resolved. It is indirectly referenced from required .class files" The simple project is attached SimplestCorrectedPI_withoutHibernateJars - without hibernate jars (which need to be included).
Created attachment 141753 [details] Eclipse34Ganymede recreation of the problem
Created attachment 141754 [details] Ganymede: error shown in class file
Created attachment 141756 [details] Eclipse Galileo - no sign of error anywhere When trying to reproduce the problem on Galileo it turned out that there is not indicator in any view (problem, project explorer, etc.) as well as in the java class file. Question arises: which of these two behaviours is erroneous?
Assigning to Jason for initial investigation.
The problem is with JDT, and the only problem they should be fixing is to ensure the error is visible in the usual manner in the errors view and as a label decorator in the package explorer. The actual classpath issue is easy to fix. The customer simply needs to open the SimplestDummyWeb properties and select the Java EE Module Dependencies properties page and select the JavaProBase.jar. This will add the that project to the classpath which is necessary because the utils.Util1 class in java-projr-util.jar references class types.Type1 via annotations.
Move to JDT/UI
What do I need to install in Eclipse to be able to reproduce this issue?
This can come from the reconciler not using the same name environment than the regular java builder.
Why are you saying that Galileo has a problem? Do you have runtime issues ? Kent and I will look into this one.
So builds on 3.4.x and 3.5 produce no errors - correct ? And only the Java editor in 3.4.x shows the error, but not 3.5 - correct ?
Jason, David, Carl, Blazej - we need one of you to respond to the questions in comment 7, comment 9 and comment 10. Olivier asked questions 9 days ago and no one has answered him. Who is going to be our contact for this bug ?
Created attachment 143130 [details] JDT projects required for reproduction steps I'll be your contact. Blazej is off today and next week. I have reduced the test case to 4 projects: Annotation This project contain an annotation which can be used for indirect referencing (it takes a Class as an argument). JavaBase Contains single class. JavaUtil Depends on JavaBase and Annotation. Contains single class annotated: @IndirectReference(clazz=base.Base.class) FinalProject This project contains single class which uses JavaUtil. The trick is that this project cannot depend on aforementioned projects, it has to use jars. So, we have 3 jars: annotation, base & util. If we place annotation & util into final project, galileo says that everything is fine (no single error marker), but buildpath is not complete - base is missing. Ganymede shows in Text Editor error as in screenshot attached by Blazej before. Placing base.jar in finalproject without adding it to the buildpath removes the error marker in Ganymede. Simplest reproduction steps are to import FinalProject from PI_283687_1 and delete base.jar. In reply to comment 7: Nothing but Galileo/Ganymede In reply to comment 9: Ganymede is able to partially mark that something is wrong. Galileo ignores the problem. In reply to comment 10: correct. Further testing (replacing annotations with regular imports, etc) allows me to think that Eclipse never supported diagnosing of library dependencies (no error for regular import neither in Ganymede nor Galileo). Therefore I believe it is a bug that Galileo shows error message in text editor - and this bug is relatively minor one. The biggest problem would appear if Eclipse was able to diagnose missing libraries - then we have serious regression.
I have found two similar issues: bug 61706 (FIXED) which says that Eclipse should complain on unbound reference from binaries bug 36397 comment 34 (LATER) > The JLS deliberatly does not address dealing with incomplete libraries. It is left up to compiler implementations.
Sorry but I do not see how this is anything but an editor bug in 3.4.x that has been fixed in 3.5. No build in 3.4.x or 3.5 reports this error - which means the only 'problem' is the editor in 3.4.x incorrectly showing an error. As Olivier mentioned in comment 8, the reconciler in the editor has had problems resolving types in some cases. So is anyone convinced the error should be reported in a build in 3.4.x and 3.5 (but is not) and should be reported in the editor in 3.5 (but is not) ? Or is this simply an editor bug that was fixed during 3.5 development ?
Not all errors can be detected at compile time in Java. Types can be loaded at runtime only using reflection. In this case it is up to the developers to know what needs to be on the runtime classpath. There is no way they can delegate this check to the compiler. In your case, both Eclipse and javac don't need the base.jar to be on the classpath to compile that source. The problem might be different if apt is involved, but this is not what the current test case is showing. If the type Main extends Util1 and it defines a method that has Base as a return type in the super class, then you will get an error saying that the classpath is incomplete. For now I am closing as INVALID as there is absolutely no proof so far that the Eclipse compiler is not working as expected.
Verified for 3.6M1