"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