This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Summary: | Single compilation of a jsp file fails due to a uncompilable java source which is not used in the jsp file. | ||
---|---|---|---|
Product: | javaee | Reporter: | ssoong <ssoong> |
Component: | JSP | Assignee: | Matthew Bohm <mbohm> |
Status: | RESOLVED WONTFIX | ||
Severity: | blocker | CC: | pjiricka, ppisl |
Priority: | P3 | ||
Version: | 5.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | DEFECT | Exception Reporter: | |
Attachments: | Project z |
Description
ssoong
2006-11-03 22:13:43 UTC
"The jspcompiler should my its own business ..." I meant to say "The jspcompiler should mind its own business ..." This affects NB5.5 20061124/JDK1.5_5 too. It is too debilitating. I have to move all my incomplete stub source files out of the view of the IDE. I also need to move all my incompletely modified files. Issue needs to be on P1. I don't think that this is regression. I have just tested this with NetBeans 5.0 FCS and NetBeans 5.5 FCS and the behavior is the same and IMHO it works in way how I expect this. I did a new web application and created new java class. Then I did the java class uncompilable and did the <%@page import %> in the index jsp. Then I compiled (through F9) the index and as I expected the build failed due to the uncompilable class. I also look through the sources and I didn't find a commit which should changed the behavior. In which build it works differently? This behavior is intentional. Since JSP pages may import JavaBeans, the JSP compiler requires that this bean is compiled, in order to compile the JSP. Try for example adding the following to the page: <jsp:useBean id="x" class="com.foo.MyBean"/> If you don't have a class called com.foo.MyBean, you will get compilation errors, not runtime errors. If we did not compile Java classes before compiling JSPs, this could result in some hard to find errors, such as that I add a property into my class, then try to use in <jsp:getProperty... />, and the IDE reports compilation errors, although the code is correct. It is the same situation as when javac always determines dependencies, and when you want to compile class X, it compiles all the classes that X depends on (if they are not up to date), not only X. I suggest marking this as invalid. I'm afraid you misunderstood the problem I am hi-liting. Let me restate. My project has a a.jsp. It does not depend on any class or beans. I decide to create a few incomplete java files. a.jsp still does not depend on nor imports any of the new impending classes. Impending, because they are merely uncompilable java source files. Now, I click on F9 just to validate a.jsp. Well, the JSP compiler could not mind its own business and dependencies and crawled around attempting to compile java files that has nothing to do with a.jsp simply because they are in the same project. I forgot to say that you need to have a b.jsp which depends on one of the incomplete java files. But still the same, I am trying to compile/validate a.jsp not b.jsp. I understand. However, the JSP compiler has no way of knowing what Java classes the JSP uses, without actually compiling the JSP. So in order to find out which classes the JSP needs, we need to run the JSP compiler. If we run the JSP compiler and we find out that a.jsp depends on class X and class X is not compiled, it is too late - compilation of a.jsp will fail even if everything is correct. I understand you may not like the fact that the compilation is currently too defensive, but I would not classify this as a bug. I think at some level, the request you describe makes sense, so we are willing to consider the change of the behavior. Any suggestions on how it all should behave so it behaves plausibly in all the cases? I am changing this to P2 enhancement. Created attachment 36651 [details]
Project z
[quote] If we run the JSP compiler and we find out that a.jsp depends on class X and class X is not compiled, it is too late [/quote] No, no, no ... I think there is still a misunderstanding: If a.jsp depends on class X and class X is not compiled, then I want JSP compiler to show error. I request not to change that behaviour. Zttachment 36651 (Project z) is a simple project. a.jsp is an empty file. xyz.a.java is a bare-bone java source that compiles properly. xyz.b.java is a bare-bone java source that has an intentional error and would not compile. When I compile xyz.a.java, the java compiler does not react with errors. When I compile/validate a.jsp (which does not depend on any beans - since it is empty - not even on xyx.b.java), compilation fails showing that xyz.b.java has errors. Why is it that compiling xyz.a.java would not stop on errors due to xyz.b.java, but compiling a.jsp would? In more colloquil terms, why is compiling xyz.a.java able to mind its on business while compiling a.jsp can't keeps its hands off its neighbour's properties? Please let me restate - a.jsp is empty - has no dependencies. But its compilation stops on errors in xyz.b.java. ~ thou shalt not covet thy neighbour's java class on which you have no dependencies. Yes I agree with ssoong. If the behavior is different, that should be consolidate and there is real use case. I'm marking the issue back as defect, at least to evaluate again. The compile-single-jsp target depends on compile target, which compiles the java sources. I think, whether there is a way how to say ant target don't fail, if the depend target fails, then this issue can be fixed. I changed the summary of this issue, because the original one "Case of busybody jsp compiler" doesn't mirror the real problem. Yesterday I was playing with this issue. I'm able to change the ant script in a way that when the compilation of the java files fails, then the jsp compilation continue. The problem is that java files are compiled with javac. Javac at first round try to parse all java sources and if there is a syntax error (no compilation error), then it stops and doesn't produce any class file. The solution for this obstacle is that we would find out all classes needed for the jsp file compilation. But this solution has performance disadvantages. You need to find out all the jsp files, which are needed for compilation (included files, tag files, preludes, codas) and obtain the list of needed classes. In the current state it means that the jsp files will be parsed twice. One time for finding needed information and second time during compilation. After this we can try to compile with javac the obtained list of java sources. IMHO the suggested solution is too much work and I'm not sure whether it worth doing this. I tried Idea and Eclipse as well and in both IDE it doesn't work as I expect. I close this issue as WONTFIX. If you don't agree, reopen and switch to enhancement. I find it difficult to accept that the compiler treats direct and jsp-precompiled java source files differently. I have a.jsp, b.java and c.java. a.jsp has no errors. b.java has no errors. c.java has errors. I have b.java up on the editor. I press F9 specifically on b.java . The compiler behaves properly and minds its own business. It does not put a telescope at its neighbour (c.java) and say "hey you have sinned!" It minds its own business. Now, I put a.jsp up on the editor and press f9. Holy smoke, why is the jsp compiler so busybody and pokes its nose at c.java where it doesn't belong? How is it that compiling a java class does not face the problem? How is it that we are able to detect the b.java does not depend on c.java? Let's say that a.jsp is precompiled to a_jsp.java. There should be no discrimination between compiling a_jsp.java and b.java. a_jsp.java is just another source file. If the compiler could detect that b.java does not depend on c.java, why can't it detect that a_jsp.java also does not depend on c.java? I am not changing the status but I simply need to express my frustration because, as I said, I need the latitude to put in experimental and incomplete classes within the project. If I had perfect classes that compiled correctly the first time why would I even need an IDE?? I understand your point and basically I agree with you. I will try to implement a solution, which will look for the classes, which are used in the compiled jsp file, and compile just these classes. I'm opening this issue just for tracking this issue, because IMHO it is not very often use case. Also I'm increasing the priority. moving opened issues from TM <= 6.1 to TM=Dev Here's my understanding of the issue. ppisl, please let me know if any of the following is inaccurate. The limitation in question appears to stem from the fact that the jasper JSP compiler (org.apache.jasper.JspC) needs to know a classpath specifying the classes on which the generated servlet will depend. In other words, it requires that such classes already be compiled. The IDE, not knowing exactly on which classes these are, compiles all the classes in the project before invoking the JSP compiler. In order to compile just the classes on which the generated servlet will depend, the IDE would have to perform the extra step of examining the JSP source and calculating a list of those classes. It could then compile just those classes and then invoke the JSP compiler. As I see it, considering the development time it would require to implement this behavior, and given that there will be a performance hit for this extra step, however potentially slight, I'm not convinced we ought to implement this without more demand from the community. The fact that this is not a common request probably indicates that among those developers who explicitly attempt to precompile JSPs during their development, most do not find it unreasonable to make their Java classes compilable first. It's not that the request is impossible to implement. It is just that the JSP compiler doesn't selectively compile the relevant Java classes; rather, it expects the relevant Java classes already to be compiled. So the work of selective compilation would have to fall to the IDE. The question is whether the IDE ought to implement it. I think it only makes sense if there is a fair amount of community demand. ppisl, do you agree? I agree with this assessment. We can probably mark this as RESOLVED/LATER. Marking resolved/later. NetBeans.org Migration: changing resolution from LATER to WONTFIX |