Hi Carlos,
On Thu, 17 May 2001, Carlos Gaston Alvarez wrote:
> 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).
The JspParser object knows how to deal with that. And it's easy to convert
it into a SAX event generator. The script will be equivalent with a CDATA
section ( and you can have <tag> in a CDATA ).
In 1.2 you also have the "XML" representation ( and we can use it to
generate exactly the same type of sax events from a non-xml jsp file )
> 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.
Not quite - look at XSLTC ( part of xml-xalan project ). This is intended
only for "pure" JSP pages, with no java fragments.
We are in a very similar situation with XSLTC - the page-generated code
itself it's not very complex ( in fact it's much simpler in our case ), so
we don't benefit a lot from javac optimizations. And no, this is not going
to be a compilator ( but some cut&paste from another apache project :-)
One important thing to keep in mind: sometimes there is a tradeof between
compilation time and runtime performance. The more optimizations you do at
compile time - the slower it is to compile, faster to run. That mean that
would be more of an option for development time, I would still use the
real compiler before deployment.
This is a "long term" project - it's definitely something "cool", but I
think we should hold that until we solve more important issues.
( and compilation time can be improved few times by just using jikes ).
> 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.
I like guessing, but it would help if you'ld also read the code, and maybe
write some patches :-)
> 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.
Not quite. Almost all of the time is spent doing javac compilation.
The jsp->java translation is insignifiant.
What we care about is getting the response time for the first request
below a second ( so developer will not "feel" the delay and get fast
feedback ). On my computer, using jikes - this is exactly the case, and I
have a 300MHz laptop. I run a lot of XSLTs ( that's part of my job ) and I
never "felt" a delay ( and benchmarks for most transforms I do are well
bellow a second ).
> 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.
Unfortunately we can't compile from and to memory with the current javac,
and even if it would be possible - the compiler is a complex application,
doing optimizations, verifications, etc: I don't think the time
for read/write source/class is predominant.
Costin
