Bugzilla – Full Text Bug Listing
| Summary: | No compilation error for argument types that are not on the build path | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Mauro Molinari <mauromol> | ||||
| Component: | Core | Assignee: | JDT-Core-Inbox <jdt-core-inbox> | ||||
| Status: | CLOSED WONTFIX | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | stephan.herrmann, thatnitind | ||||
| Version: | 3.7.1 | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | PC | ||||||
| OS: | Windows 7 | ||||||
| Whiteboard: | stalebug | ||||||
| Attachments: |
|
||||||
We use JDT's reconciling of the compilation unit backing the JSP to collect these types of problems. The problem seems to be fairly generic and not specific to JSPs. If you try to pass an object of a type that is not on the build path as an argument to a constructor or any method, it will not generate an error. For example:
package test;
import noexist.Nope;
public class Foo {
static void createFromContext() {
Nope nope = null;
MyClass c = new MyClass(nope);
}
}
This generates two errors indicating "The import noexist cannot be resolved" and "Nope cannot be resolved to a type", but no error about "The constructor MyClass(Nope) is undefined".
I did open Bug 365369 to enable validation of JSPs to indicate problems with the target runtime missing from the build path.
(In reply to comment #1) > [...] > This generates two errors indicating "The import noexist cannot be resolved" > and "Nope cannot be resolved to a type", but no error about "The constructor > MyClass(Nope) is undefined". The JDT Compiler by design avoids reporting many errors that are secondary errors with an obvious relation to some primary error. In this case resolving MyClass.<init>(Nope) cannot possibly succeed, because we already know that Nope is a missing type. Can you explain, why reporting the two errors you mention is not sufficient? In the Java setting suppressing secondary errors guides the user towards fixing those primary errors first, because without them fixed the program can never be corrected. Are the two errors swallowed by the JSP tooling? If so, I would consider that as the actual bug. Created attachment 207863 [details] translated source (In reply to comment #2) > Are the two errors swallowed by the JSP tooling? If so, I would consider > that as the actual bug. Comment 1 had, perhaps, a less than ideal example since we wanted to avoid throwing the entire source from comment 0, translated into Java source, your way. In that example the import statement does point to a class that exists. in "new MyClass(pageContext)", pageContext is declared as a method argument but the type for it was not on the Build Path (message reads "javax.servlet cannot be resolved to a type"). Errors not in user-authored sources are usually swallowed, but even as the translated Servlet source, I'm not warned about the constructor call when MyClass does exist. Is that also expected? (In reply to comment #3) > [...] > in "new MyClass(pageContext)", pageContext is declared as a method argument but > the type for it was not on the Build Path (message reads "javax.servlet cannot > be resolved to a type"). So the only difference is that the missing type is given with a qualified name rather than via an unresolvable import? I don't see why this would change expectations towards the compiler. A variable declaration has a missing type, resolving a constructor using that missing type remains silent, because the primary error must be fixed first. > Errors not in user-authored sources are usually swallowed, Good, but then the tooling should validate whether the not-user-authored sources actually work and give appropriate errors (which may be much more helpful then just passing through the original compiler errors). > but even as the > translated Servlet source, I'm not warned about the constructor call when > MyClass does exist. Is that also expected? You mean "when MyClass has no constructor taking a PageContext argument"? I'd say: yes. This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie. |
Build Identifier: 20110916-0149 If no server runtime is bound to a dynamic web project, the JSP editor does not show some compile time errors. I think the problem is about using classes that should be provided by the server runtime library. Reproducible: Always Steps to Reproduce: 1. download Eclipse IDE for Java EE Developers 2. open on a brand-new workspace (i.e.: no server runtime defined) 3. create a Dynamic Web Project with dynamic web module version 2.4, no target runtime 4. create the following Java class and leave the Java editor open: package test; public class MyClass { } 5. create the following JSP in WebContent: <%@ page language="java" contentType="text/html; charset=ISO-8859-1" pageEncoding="ISO-8859-1"%> <%@page import="test.MyClass"%> <% final MyClass myc = new MyClass(pageContext); %> <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"> <title>Insert title here</title> </head> <body> </body> </html> EXPECTED BEHAVIOUR: A compilation error should be given at line 5, since MyClass does not have any constructor that receives a PageContext object. ACTUAL BEHAVIOUR: No compile time error is given by the JSP editor.