Community
Participate
Working Groups
Created attachment 106261 [details] 3 projects with problems in 1.6 classes using 1.4 classes I have 3 projects, 2 Java 1.4 compatible, 1 Java 1.6 (maybe 1.5). The Test14Dep contains just one class. The Test14 project contains a class with overloaded methods with arrays as last parameters. (The classes of arrays later got template parameters in the new Java.) The project Test16 contain two classes with different, but similar symptoms. There are failing methods, and also correct in them. Some of them are reported in the side line, but not reported in the problems view. I am not sure whether these are all bugs, but it seems to be very inconsistent. (It behaves differently when the project's exported jar is used instead of the project, but both has problems.) Sample: Java14Dep: class X{}; Java14: Object test(Class[] classes); X test(); Java16: Class<?>[] classes = new Classes<?>[]{}; //test(classes);//fails, complains about //The type X cannot be resolved. It is indirectly referenced from required .class files. Class[] classesWithoutParam = new Classes<?>[]{}; test(classesWithoutParams);//OK
Created attachment 106262 [details] 3 projects with problems in 1.6 classes using 1.4 classes using project dependencies instead of jar
Not a regression from 3.3.x
What exactly are the problems you're seeing in each case ? These are the problems I see for the first attachment: 1. The project was not built since its build path is incomplete. Cannot find the class file for X. Fix the build path then try building this project 2. The type X cannot be resolved. It is indirectly referenced from required .class files These problems are expected since X cannot be found on the classpath of the project Test16. You need to include the referenced types (X in this case) as well as the type Test14 on the classpath for the project Test16.
(In reply to comment #3) > What exactly are the problems you're seeing in each case ? I see two in the Problems view, the same you are mentioning. (I guess your second is in TestOther16.java, 6th line.) I see two error markers in the TestOther16.java when opened: - line 6: Multiple markers at this line: - The method test3(Comparable[]) from the type Test14 refers to the missing type X - The type X cannot be resolved. It is indirectly referenced from required .class files. - line 12: The method test3(Comparable[]) from the type Test14 refers to the missing type X I think this is inconsistent. The Problem view is not showing the same errors as the file error markers. (For the project wide error I feel sorry. I have not seen it previously because of my Problems filter preferences.) > These problems are expected since X cannot be found on the classpath of the > project Test16. I think an error is missing from the line 12. (Or it is handling differently the Class[] and Class<?>[] arrays.) > You need to include the referenced types (X in this case) as well as the type > Test14 on the classpath for the project Test16. I know. The other attachment is much more interesting. It has errors in both classes, not just in TestOther16. I guess the problem is that the compiler selects different methods to call if the argument array has <?> type parameter, or has not. That is the root problem I think. I have tried the original problem (with jar dependencies) in NetBeans (with Sun's javac), and it handles the calls uniformly. The <?> type parameter does not make it fail. PS.: I have not seen the Java specification regarding this behaviour. I do not know what is the correct. Sorry, I am not a Java compiler guru...
(In reply to comment #3) > These problems are expected since X cannot be found on the classpath of the > project Test16. I think I should exchange the return types of the two test3 methods in Tet14.java. I that case only two errors are reported (one classpath and the indirectly reference problem). In this case I do not see why it is reported. It seems there it wants to use the public X test3() method instead of public String test3(final Comparable[] comparables) when using the arguments with Class<?>[] type parameter.
If I comment out the methods with fail in name the "The project was not built since its build path is incomplete. Cannot find the class file for X. Fix the build path then try building this project" problem also disappears and everything compiles (the ok calls look really similar to the failing ones).
"I think this is inconsistent. The Problem view is not showing the same errors as the file error markers." This is done on purpose - in the problems view, we want you to focus on the missing type error since its usually the cause of many other errors. Its nearly impossible to find a missing type error when the problems view shows 100's of errors. The editor doesn't remove all other errors, that is why you're seeing errors that will appear once the missing type X is added to your classpath. I've played around with the test classes (adding/removing X from the classpath) and I do not see a compiler bug with any of the reported errors. Please clarify what you think the problem is and how we differ from javac.
Created attachment 107668 [details] The Test16 project shows problems, but with ant script it compiles. This project set shows the problems in Problem view, while it is successfully compiles with ant (you may check, that ant does not see X, if you uncomment Test16#thisShouldReallyFailToCompile() method).
Created attachment 107669 [details] All of these compile in IDE, no complaints about build path. If you uncomment any of the commented lines in Test16's fail method there is a build path problem. (Please do not uncomment thisShouldReallyFailToCompile()) The Test16 has additional resources, but only the Test16 class is interesting.
(In reply to comment #7) > "Please clarify what you think the problem is and how we differ from javac." Do you need more information? Could you reproduce the problem? (Or have I explained something wrong, uploaded wrong files?)
Reproduce what problem ? As I said, X is not available on the classpath and it needs to be since you're overloading methods & specifying X as the return type. We intentionally remove all other errors so there is only ONE classpath error for X. Argument count is not used to pick a method, only its name is used. So we resolve ALL methods named test, not the ones which take only 1 parameter, or the ones that do not include a missing type X. Please clarify the problem if its not an issue with how missing required class file errors are reported.
(In reply to comment #11) > Reproduce what problem ? Errors are reported, while the build.xml compiles fine the project Test16 with eclipsec or with javac (in attachment 107668 [details]). (I think this is a symptom of the problem.) The problem is that the selected method (for error report) depends on whether we use the existential type parameter (<?>) on arrays or a raw type. > As I said, X is not available on the classpath and it needs to be since you're > overloading methods & specifying X as the return type. We intentionally remove > all other errors so there is only ONE classpath error for X. I understand and accept this, thank you for explaining this behavior. > Argument count is not used to pick a method, only its name is used. This must be false. See the attachment 107669 [details]. All of the methods int Test14 class has an overloaded version which returns X. So it should report missing class X. (Fortunately it does not. :) ) What I find strange is that the error report *depends* on presence of ? type parameters. The only real difference between the compiling attachment (107669) and the in eclipse failing one (107668) is the <?> type parameters for the arrays. If there are no possibly missing classes involved the same method is selected independently the added or not <?> type parameters, so I expected the same behavior in this case too. (I have tested this in the testsrc folder in Test16 project, but it is not so interesting, since it is working well.) > Please clarify the problem if its not an issue with how missing required class > file errors are reported. No it is not an issue about how missing class file errors reported. The issue is with the type parameter handling in this context. I thought this was clear from my first post. See the difference between the compiling: Class[] classesWithoutParam = new Classes<?>[]{}; test(classesWithoutParams);//OK and the not compiling: Class<?>[] classes = new Classes<?>[]{}; test(classes);//does not compile If no calls in the project with arrays with <?> type parameters everything compiles. If we add at least one: ant compiles, eclipse complains about missing X class. I hope now it is clear what is my problem.
Thank you - I'll look at it again.
So we can breakdown the problem to these 2 types: public class Test14 { public X test(Object[] objects) { return null; } public String test(Object[] objects, Class[] classes) { return ""; } } public class Test16 { void ok() { Class[] classes = new Class<?>[] {}; new Test14().test(new Object[] { "" }, classes); } void fails() { Class<?>[] classes = new Class<?>[] {}; new Test14().test(new Object[] { "" }, classes); } } In Test16.ok(), the method in Test14.test has 2 parameters Object[] & Class[] That matches exactly with the second test method in Test14 : public String test(Object[] objects, Class[] classes) { return ""; } So we do not need to see if there is a better match. (Sorry I left that step out of comment 11 when I talked about argument count). But in Test16.fail(), the method parameters are Object[] & Class<?>[] Since these do not match exactly, we're forced to consider all test methods and so we encounter the missing type X when resolving all types referenced by the first test method. BTW - It doesn't matter what the second parameter was. It could have been null, or an int. We would still have run into the missing type X. Ok ?
(In reply to comment #14) > Ok ? Thanks Ken, now I think it is clear for me, I understand why it does not work as I expect. Should this be(come) a feature request to search for other possible matches even if there are "wrong" methods there? Or a better algorithm to find exact matches? (I do not see any difference between raw types and with same types type parameter <?>. So in my humble (but maybe not so correct) opinion those are exact matches.)
We're unlikely to change how exact method matches handle raw types, and its a very bad idea to expect that overloaded methods can be found using an exact match, when a missing type is part of the other method. You may be able to compile your example, but any other user that chooses to use your project can easily run into this problem because you did not export the missing type. The easiest change in these cases, if you choose to not export the missing type, is to rename 1 of the overloaded methods. Then there is only 1 matching method named "test". Closing as WORKSFORME since the classpath error is the expected behaviour in this case.
I am a bit sad about this behavior, but accept it. Other build environments, like NetBeans has no problem with projects like this. (Actually this problem has arisen from a multi-IDE project.) The problem remains if I am not the release engineer of the project like Test14. (This was the case in that project, it was a 3rd party jar.) The method with missing class may be deprecated also with the returned type, and which may be in a deprecated jar. If I do not use deprecated features, in this case I have to add that jar for development, or create classes with those names. I guess I will use a workaround in my case. Thanks for your help.
Verified for 3.5M1 using I20080805-1307
It seems that with eclipse 3.5 the things get more strict/consistent... Now it is enough to have a method overloaded with a not present result type. Is this intentional? Like if the project structure is same as in https://bugs.eclipse.org/bugs/attachment.cgi?id=106262 in Test14.java: public class Test14 { public String test5(String s) { return s; } public X test5(Object o) { return null; } } in TestOther16.java does not compile: public class TestOther16 { void fail0() { final String s = new Test14().test5(""); } } //Error message: //Description Resource Path Location Type //The project was not built since its build path is incomplete. Cannot find the class file for X. Fix the build path then try building this project Test16 Unknown Java Problem
