Ok Chris. Now I undertand.
Working with JSP when I found that type of mistakes I went to see the .java
generated. There I matched the line number so I could see which was the bad
code. Then I had to go to the jsp to fix it.
It is not the best of the world, but is that that bad?
On the other hand we can trick the compiler to make it fit the line numbers,
just generating really hugly java code.
package jklfe.fel.ef; import java.util.*; .... // line 1
user.code.here() // line 2
Just an idea.
Chau,
Gaston
>
> From my view, the problem with JSP->Java->Class isn't performance its
> debugging. JSP is hard to work with when you make a mistake, very often the
> error message is less than helpful. A very large step in improving this is
> by making the line number given by the stack trace match the line numbers
of
> the JSP page. This currently is not the case because of the intermediate
> step of a java file. It would be beneficial to compile JSP straight to
Java,
> complete with debugging information included in the class file.
>
> - Chris.
>
> > -----Original Message-----
> > From: Carlos Gaston Alvarez [mailto:[EMAIL PROTECTED]]
> > Sent: 17 May 2001 12:51
> > To: [EMAIL PROTECTED]
> > Subject: RE: Jasper performance
> >
> >
> > I dont know if I really understood. You (some) are
> > thinking to compile a
> > jsp using xslt. I didnt know that that was possible. I mean,
> > can a jsp be
> > loaded as a dom object? I think that it cannot because a nice
> > guy can write
> > some code like <% out.writeln("</html>"); %> and that is, it
> > is not more xml
> > compliant. (please tellme if I am wrong).
> > If the problem is the compilation time I can hardly
> > believe that we can
> > do something faster that a java compiler. Not because we dont have the
> > skill, but because there are groups working in this kind of
> > implementations.
> > We should be blindly proud to think out compiler would be faster than
> > theirs. Also, I consider that a waste of time.
> > Let me do some guessing. I know, I should be reading the
> > code, but I
> > have been realy overloaded for the last months. Lets see if I have
> > understood the problem.
> > Saving a file for compilation is slow. So we need a
> > faster solution.
> > But, why is it slow?
> > It sounds like we are saving the .java in file and then invoking a
> > javacc process. The new process needs loads the compiler
> > classes, compiles
> > them (?) and then compiles our .java source.
> > If we could have the compiler just loaded on our own
> > memory space, we
> > could invoke it saving the loading compiling (?) time. We
> > could also send
> > the .java 'file' in memory and expect the .class 'file' also
> > in memory.
> > Yes, may be we need some modifications in the compiler,
> > but as part of
> > the apache project we are at a good position for asking it an
> > having a good
> > answer.
> >
> > Chau,
> >
> > Gaston
> >
> > ps: sorry for doing so much guessing but next month I will
> > have much more
> > time.
> > ps
> >
>
>
> -----------------------------------------------------------------
> This e-mail is intended only for the addressee(s) named above. It
> may contain confidential or privileged information and if you are
> not the intended addressee you are not authorized to disclose,
> copy, distribute or place any reliance on it whatsoever and we
> request that you inform our postmaster ([EMAIL PROTECTED]) that
> you have received this e-mail. Any attachment(s) to this message
> has been checked for viruses, but please rely on your own virus
> checker and procedures. If you contact us by e-mail, we will
> store your name and address to facilitate communications.
> -----------------------------------------------------------------
---------------------------------------------
Este mensaje ha sido enviado desde el servidor de Webmail de Tournet S.A.
http://www.tournet.com.ar/
