RE: [PLAN] New Jasper
[mailto:[EMAIL PROTECTED]] Enviado el: martes 26 de marzo de 2002 0:37 Nice to hear that, one comment, there is a jakarta-tomcat-jasper repository with code Costin and Mel did some time ago as an initial effort to refactor the 3.3 Jasper, i dont know which is the state of the code there but maybe it's good idea to use it for your effort.. Unfortunately, Mel has been COMPLETELY immersed in matters unrelated to Tomcat or Jasper for many months. You know, silly stuff like earning money with new job to pay for overpriced new house. :-| So the state of the Jasper refactoring has been pretty much frozen for ages. If someone wants to pick up the ball and run with it, don't worry about my ego. I'd just like to see SOMETHING done to fix Jasper! Kin-Man : If it helps, feel free to build on what we started. We did not get too far, unfortunately before my job situation changed (like a lot of folks last year, eh?). There were a few goals of the refactoring effort we started to keep in mind: 1) modularity (a) - able to use the result with various servlet engines. For example, it should be able to support a Jasper implementation as servlet, intercepter, command line or whatever. We did not want a Jasper that was tied to a particular Tomcat implementation or even to tomcat at all, except as barely required. It should be possible to plug Jasper into most any servlet container. Done correctly, this should STILL allow one to utilize optimizations provided by the particular engine. 1) modularity (b) - nearly ALL functionality of Jasper should be plug-replaceable in a clean, consistent fashion. This is necessary to support not just (1a), but also to make it easier to improve Jasper without proposing the annual rewrite from scratch. 2) able to support both jsp servlet specs 3) able to support pre-jdk 1.2 systems My scheme for this was to heavily utilize the factory pattern via a highly extendable Toolkit metaphor. The toolkit would be driven by configurations in .properties file. The configurations would first of all allow the toolkit to generate an extention of itself appropriate for the particular container (for ex., TC3 or TC4). Then the toolkit would be used to generate all the requisite pieces of functionality required for Jasper such as class loaders, parsers, compilers, caches, etc. I had started with the base toolkit with providing some base utility functions (all replaceable through configuration properties). Basically, any identifiable functionality of Jasper that can be represented with a consistent interface could be implemented with a toolkit factory method. Because the pattern allowed for the toolkit to generate extentions of itself, there is no limit to the factory methods that can be supported. The utilization of this pattern is pretty straightforward. A particular jasper implementation would ask the toolkit to first generate an extention of itself appropriate for the implementation, then it would ask for the appropriate pieces needed to build the functionality of Jasper into that implementation. At the time, I thought the idea had a ton of merit and wish I could devote the cycles to finishing it. I simply do NOT have the time necessary to do so. Take a look at it. If you feel it is something you can use, great! If not, that's also great! I would just like to see SOME progress at improving Jasper once and for all. I would be a little sad if our modularity goals were lost along the way, though. You definitely should use the jakarta-tomcat-jasper repository, though. Cheers and good luck! Mel Dr. Mel Martinez Extreme Blue/Cambridge IBM __ Do You Yahoo!? Yahoo! Greetings - send holiday greetings for Easter, Passover http://greetings.yahoo.com/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [PLAN] New Jasper
I checked out jakarta-tomcat-jasper briefly looked at the files there. I agree with you (and constin) that it can be used as a repository for jasper2. However, files and directory structures are too different from the one used in tomcat 4, and I am a little hesitant to just go in there and wipe out everything, not knowing the current status of that repository, or its intended use (tomcat 3, 4, or both?). In the interest of getting jasper2 out in reasonable time, I am going to stick with my original plan. That'd also give me some time to digest what's in jakarta-tomcat-jasper, and see if jasper2 should move in there. Thanks for the suggestion. Date: Tue, 26 Mar 2002 15:04:16 +0100 From: Ignacio J. Ortega [EMAIL PROTECTED] Subject: RE: [PLAN] New Jasper To: 'Tomcat Developers List' [EMAIL PROTECTED], 'Kin-Man Chung' [EMAIL PROTECTED] MIME-version: 1.0 X-Priority: 3 Delivered-to: mailing list [EMAIL PROTECTED] Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N List-Post: mailto:[EMAIL PROTECTED] List-Subscribe: mailto:[EMAIL PROTECTED] List-Unsubscribe: mailto:[EMAIL PROTECTED] List-Help: mailto:[EMAIL PROTECTED] List-Id: Tomcat Developers List tomcat-dev.jakarta.apache.org De: Kin-Man Chung [mailto:[EMAIL PROTECTED]] Enviado el: martes 26 de marzo de 2002 1:13 Thanks for the pointer. I'll look at both places to see if there are codes/ideas I can borrow. My comment was more geared toward the use of this repository, than to reuse the code there, i think is cleanest to build Jasper2 in his own repo.., Well and if you can borrow some of the code there, much better. :)) Saludos , Ignacio J. Ortega -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [PLAN] New Jasper
On Wed, 27 Mar 2002, Kin-Man Chung wrote: I checked out jakarta-tomcat-jasper briefly looked at the files there. I agree with you (and constin) that it can be used as a repository for jasper2. However, files and directory structures are too different from the one used in tomcat 4, and I am a little hesitant to just go in there and wipe out everything, not knowing the current status of that repository, or its intended use (tomcat 3, 4, or both?). In the interest of getting jasper2 out in reasonable time, I am going to stick with my original plan. That'd also give me some time to digest what's in jakarta-tomcat-jasper, and see if jasper2 should move in there. Just create a jasper2 directory - and don't touch the old one. The idea is similar with what's in j-t-c - there are multiple 'projects' going on, each using its own conventions. The structure of jasper3.4 shouldn't affect jasper2, and you don't need to 'digest' the old code ( any more than we digest each other's work in connectors ). I can't see how creating the directory in j-t-j can affect your timing. If it's build issue ( build.xml, etc) - it's easy to solve ( Remy already did most of the work for coyote ) costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [PLAN] New Jasper
OK, that'd be easier. :) I'll give it a try. Thanks for the suggestion. Date: Wed, 27 Mar 2002 14:59:00 -0800 (PST) From: [EMAIL PROTECTED] Subject: RE: [PLAN] New Jasper X-X-Sender: [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED], Kin-Man Chung [EMAIL PROTECTED] MIME-version: 1.0 X-Authentication-warning: dyn-181.sfo.covalent.net: costinm owned process doing -bs On Wed, 27 Mar 2002, Kin-Man Chung wrote: I checked out jakarta-tomcat-jasper briefly looked at the files there. I agree with you (and constin) that it can be used as a repository for jasper2. However, files and directory structures are too different from the one used in tomcat 4, and I am a little hesitant to just go in there and wipe out everything, not knowing the current status of that repository, or its intended use (tomcat 3, 4, or both?). In the interest of getting jasper2 out in reasonable time, I am going to stick with my original plan. That'd also give me some time to digest what's in jakarta-tomcat-jasper, and see if jasper2 should move in there. Just create a jasper2 directory - and don't touch the old one. The idea is similar with what's in j-t-c - there are multiple 'projects' going on, each using its own conventions. The structure of jasper3.4 shouldn't affect jasper2, and you don't need to 'digest' the old code ( any more than we digest each other's work in connectors ). I can't see how creating the directory in j-t-j can affect your timing. If it's build issue ( build.xml, etc) - it's easy to solve ( Remy already did most of the work for coyote ) costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PLAN] New Jasper
Kin-Man Chung [EMAIL PROTECTED] wrote: I also would welcome ideas or suggestion about what and how to make jasper better. Pier's is the first complain that I've heard about jasper translation perfromance. :-) Not translation (I didn't explain myself right, was too late yesterday night to put some sense in what I wrote), but the code generated... It's slow :) Pier -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [PLAN] New Jasper
De: Kin-Man Chung [mailto:[EMAIL PROTECTED]] Enviado el: martes 26 de marzo de 2002 1:13 Thanks for the pointer. I'll look at both places to see if there are codes/ideas I can borrow. My comment was more geared toward the use of this repository, than to reuse the code there, i think is cleanest to build Jasper2 in his own repo.., Well and if you can borrow some of the code there, much better. :)) Saludos , Ignacio J. Ortega -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PLAN] New Jasper
Possibly very stupid question... Is there any reason not to use JavaCC on the JSP compiler? I know the grammar is pretty nasty, but that doesn't make a custom solution any easier either. Bob - Original Message - From: Ignacio J. Ortega [EMAIL PROTECTED] To: 'Tomcat Developers List' [EMAIL PROTECTED]; 'Kin-Man Chung' [EMAIL PROTECTED] Sent: Tuesday, March 26, 2002 8:04 AM Subject: RE: [PLAN] New Jasper De: Kin-Man Chung [mailto:[EMAIL PROTECTED]] Enviado el: martes 26 de marzo de 2002 1:13 Thanks for the pointer. I'll look at both places to see if there are codes/ideas I can borrow. My comment was more geared toward the use of this repository, than to reuse the code there, i think is cleanest to build Jasper2 in his own repo.., Well and if you can borrow some of the code there, much better. :)) Saludos , Ignacio J. Ortega -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [PLAN] New Jasper
May be because of license of javacc ;-) - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 -Original Message- From: Bob Lee [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 26, 2002 3:17 PM To: Tomcat Developers List; 'Kin-Man Chung' Subject: Re: [PLAN] New Jasper Possibly very stupid question... Is there any reason not to use JavaCC on the JSP compiler? I know the grammar is pretty nasty, but that doesn't make a custom solution any easier either. Bob - Original Message - From: Ignacio J. Ortega [EMAIL PROTECTED] To: 'Tomcat Developers List' [EMAIL PROTECTED]; 'Kin-Man Chung' [EMAIL PROTECTED] Sent: Tuesday, March 26, 2002 8:04 AM Subject: RE: [PLAN] New Jasper De: Kin-Man Chung [mailto:[EMAIL PROTECTED]] Enviado el: martes 26 de marzo de 2002 1:13 Thanks for the pointer. I'll look at both places to see if there are codes/ideas I can borrow. My comment was more geared toward the use of this repository, than to reuse the code there, i think is cleanest to build Jasper2 in his own repo.., Well and if you can borrow some of the code there, much better. :)) Saludos , Ignacio J. Ortega -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PLAN] New Jasper
JavaCC is owned by Sun. The license doesn't look any more restrictive than that of javac. Bob - Original Message - From: GOMEZ Henri [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Tuesday, March 26, 2002 8:18 AM Subject: RE: [PLAN] New Jasper May be because of license of javacc ;-) - Henri Gomez ___[_] EMAIL : [EMAIL PROTECTED](. .) PGP KEY : 697ECEDD...oOOo..(_)..oOOo... PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 -Original Message- From: Bob Lee [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 26, 2002 3:17 PM To: Tomcat Developers List; 'Kin-Man Chung' Subject: Re: [PLAN] New Jasper Possibly very stupid question... Is there any reason not to use JavaCC on the JSP compiler? I know the grammar is pretty nasty, but that doesn't make a custom solution any easier either. Bob - Original Message - From: Ignacio J. Ortega [EMAIL PROTECTED] To: 'Tomcat Developers List' [EMAIL PROTECTED]; 'Kin-Man Chung' [EMAIL PROTECTED] Sent: Tuesday, March 26, 2002 8:04 AM Subject: RE: [PLAN] New Jasper De: Kin-Man Chung [mailto:[EMAIL PROTECTED]] Enviado el: martes 26 de marzo de 2002 1:13 Thanks for the pointer. I'll look at both places to see if there are codes/ideas I can borrow. My comment was more geared toward the use of this repository, than to reuse the code there, i think is cleanest to build Jasper2 in his own repo.., Well and if you can borrow some of the code there, much better. :)) Saludos , Ignacio J. Ortega -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PLAN] New Jasper
Henri Gomez wrote: May be because of license of javacc ;-) That hasn't stopped Velocity from using it. But in any case, there was an announcement on the JavaCC list a couple of days ago that JavaCC will be open sourced over the next few months. Louis Tribble -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PLAN] New Jasper
On Tue, 26 Mar 2002, Louis Tribble wrote: Henri Gomez wrote: May be because of license of javacc ;-) That hasn't stopped Velocity from using it. But in any case, there was an announcement on the JavaCC list a couple of days ago that JavaCC will be open sourced over the next few months. Maybe javacc is not the right tool for this. JSPs are more XML than programming language - especially in jsp1.2 where the non-xml constructs have clear mappings into XML. Javacc would be overkill, a customized version of xerces2 that can understand the jsp1.1 syntax would be a better fit. I'm waiting to see the code and how Node looks like, but if possible I would very much like to see it closer to an XML model. Even DOM - so people implementing optimizations/code generation/etc will not have to learn another API, but use a standard one and maybe existing tools ( even XSLT - which can transform a DOM tree ). Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PLAN] New Jasper
The primary reason for not using a parser generator is the grammar for a JSP page is context sensitive, and highly ambiguous, so its parsing does not fit the model used in parsing of conventional languages. Also, the grammar is relative simple, once you get past the attributes, so using a custom parser is actually easier and more flexible. As you'll see when I put back the sources, I tried to write down the grammar for a JSP page, just to put the parser on a more vigorous basis, but there are still cases where the context sensitivity interfere with normal parsing (e.g. the recognition of custom tags). It is much easier for a custom parser to just handle them as special cases. Date: Tue, 26 Mar 2002 08:17:12 -0600 From: Bob Lee [EMAIL PROTECTED] Subject: Re: [PLAN] New Jasper To: Tomcat Developers List [EMAIL PROTECTED], 'Kin-Man Chung' [EMAIL PROTECTED] MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600. Content-transfer-encoding: 7bit X-Priority: 3 X-MSMail-priority: Normal Delivered-to: mailing list [EMAIL PROTECTED] Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N List-Post: mailto:[EMAIL PROTECTED] List-Subscribe: mailto:[EMAIL PROTECTED] List-Unsubscribe: mailto:[EMAIL PROTECTED] List-Help: mailto:[EMAIL PROTECTED] List-Id: Tomcat Developers List tomcat-dev.jakarta.apache.org Possibly very stupid question... Is there any reason not to use JavaCC on the JSP compiler? I know the grammar is pretty nasty, but that doesn't make a custom solution any easier either. Bob - Original Message - From: Ignacio J. Ortega [EMAIL PROTECTED] To: 'Tomcat Developers List' [EMAIL PROTECTED]; 'Kin-Man Chung' [EMAIL PROTECTED] Sent: Tuesday, March 26, 2002 8:04 AM Subject: RE: [PLAN] New Jasper De: Kin-Man Chung [mailto:[EMAIL PROTECTED]] Enviado el: martes 26 de marzo de 2002 1:13 Thanks for the pointer. I'll look at both places to see if there are codes/ideas I can borrow. My comment was more geared toward the use of this repository, than to reuse the code there, i think is cleanest to build Jasper2 in his own repo.., Well and if you can borrow some of the code there, much better. :)) Saludos , Ignacio J. Ortega -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [PLAN] New Jasper
May be because of license of javacc ;-) That hasn't stopped Velocity from using it. But in any case, there was an announcement on the JavaCC list a couple of days ago that JavaCC will be open sourced over the next few months. Excellent news ;-) will the license allow its distribution in rpm form ? we need it in jpackage project : www.jpackage.org -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[PLAN] New Jasper
As I have announced here before, I have been working on rewriting part of Jasper. There are several goals for the new Jasper: 1. To reorganize/simplify parsing and code generation to make it more maintainable and yet runs faster. 2. To be used as a basis for reference implementation for JSP1.3. 3. To be used as a basis for performance optimizations, especially with custom tags. The majority of work has been concentrated on the compiler engine: the parser, the syntax checker, the attribute validator, and the code generator. Most of the utilities (except those related to parsing) and compiler environments (e.g. taglib infos), and runtimes have not been changed. The major change to the compiler has been the introduction of nodes as an internal representation of a JSP page or JSP document. Nodes are created by the parsers; and they are read, annotated, or transformed by other phases of the compiler. The compiler has added some new features (e.g. JSP id, pluggable error handlers); and it conforms the specs better, in terms of parsing and syntax error checking. Not much has changed in the servlet (java) file produced by the code generator, to maintain backward compatibility. Of couse this will be changed, as we move to goal 2 and 3. I have been doing it so far in my own sandbox. The reason for this is not to keep it a secret, but to avoid de-stablizing the current tomcat, since a lot of my early work was mainly experimental. There have been interests recently in making the new Jasper public, so I am going to do that, even though it is not ready to replace the current jasper yet. My plan is to create a new jasper directory (jasper2) under jakarta-tomcat-4.0, and to modify build.xml to allow for building jasper from sources under either jasper(the default) or jasper2 (the new jasper). This arrangement allows both the existing jasper and the new jasper to coexist and be co-developed without affecting each other. One drawback is that some files are duplicated in both directories and bugs fixed in one need to be duplicated in the other. But hopefully such an arranagement is only temporary and when the new jasper is in good enough shape, it will replace the existing one. I plan to put back the new japser source tree in a day or two. If anyone has comments, concerns, or objections, please let me know. Of course, anyone interested in contributing to the new jasper development is also welcome. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [PLAN] New Jasper
De: Kin-Man Chung [mailto:[EMAIL PROTECTED]] Enviado el: martes 26 de marzo de 2002 0:37 Nice to hear that, one comment, there is a jakarta-tomcat-jasper repository with code Costin and Mel did some time ago as an initial effort to refactor the 3.3 Jasper, i dont know which is the state of the code there but maybe it's good idea to use it for your effort.. Coyote builds from a parallel repostory, so the build file can be borrowed from there.. What do you think? Saludos , Ignacio J. Ortega -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [PLAN] New Jasper
On Tue, 26 Mar 2002, Ignacio J. Ortega wrote: De: Kin-Man Chung [mailto:[EMAIL PROTECTED]] Enviado el: martes 26 de marzo de 2002 0:37 Nice to hear that, one comment, there is a jakarta-tomcat-jasper repository with code Costin and Mel did some time ago as an initial effort to refactor the 3.3 Jasper, i dont know which is the state of the code there but maybe it's good idea to use it for your effort.. The state of my effort is bad - I have no time for it right now. Our focus was more on the runtime optimizations - so it may be possible to merge at least the tag reuse and few other things. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [PLAN] New Jasper
Thanks for the pointer. I'll look at both places to see if there are codes/ideas I can borrow. I also would welcome ideas or suggestion about what and how to make jasper better. Pier's is the first complain that I've heard about jasper translation perfromance. :-) Date: Tue, 26 Mar 2002 00:47:12 +0100 From: Ignacio J. Ortega [EMAIL PROTECTED] Subject: RE: [PLAN] New Jasper To: 'Tomcat Developers List' [EMAIL PROTECTED], 'Kin-Man Chung' [EMAIL PROTECTED] MIME-version: 1.0 X-Priority: 3 Delivered-to: mailing list [EMAIL PROTECTED] Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N List-Post: mailto:[EMAIL PROTECTED] List-Subscribe: mailto:[EMAIL PROTECTED] List-Unsubscribe: mailto:[EMAIL PROTECTED] List-Help: mailto:[EMAIL PROTECTED] List-Id: Tomcat Developers List tomcat-dev.jakarta.apache.org De: Kin-Man Chung [mailto:[EMAIL PROTECTED]] Enviado el: martes 26 de marzo de 2002 0:37 Nice to hear that, one comment, there is a jakarta-tomcat-jasper repository with code Costin and Mel did some time ago as an initial effort to refactor the 3.3 Jasper, i dont know which is the state of the code there but maybe it's good idea to use it for your effort.. Coyote builds from a parallel repostory, so the build file can be borrowed from there.. What do you think? Saludos , Ignacio J. Ortega -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PLAN] New Jasper
On Mon, 25 Mar 2002, Kin-Man Chung wrote: I have noticed that the current Jasper does a lot of string manipulations very slowly, e.g. there are unnecessary copying or concatenations, and the uses of String where StringBuffer should be used. Hopefully I can avoid all of these. But I don't have high hopes that Jasper performance can be improved to the point that an user will notice, because the time spent in Jasper is probably small compared with that spent in javac. Now if we could have jasper generate byte code directly... I wouldn't worry too much about this kind of optimizations - the page compilation happens only once and it's quite easy to pre-compile the pages with jspc. The place where optimizations do matter the most is the runtime - I would be happy with a generator/compiler that is slower but generates faster code. Even if it is possible to use BCEL to generate bytecodes directly, I think this would be a huge waste of time if done before the runtime is optimized. A clean generator that makes it easier to improve the generated code is better than the fastest generator. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PLAN] New Jasper
I have noticed that the current Jasper does a lot of string manipulations very slowly, e.g. there are unnecessary copying or concatenations, and the uses of String where StringBuffer should be used. Hopefully I can avoid all of these. But I don't have high hopes that Jasper performance can be improved to the point that an user will notice, because the time spent in Jasper is probably small compared with that spent in javac. Now if we could have jasper generate byte code directly... Date: Mon, 25 Mar 2002 23:40:05 + From: Pier Fumagalli [EMAIL PROTECTED] Subject: Re: [PLAN] New Jasper To: Tomcat Developers List [EMAIL PROTECTED] MIME-version: 1.0 Content-transfer-encoding: 7bit Delivered-to: mailing list [EMAIL PROTECTED] Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm User-Agent: Microsoft-Entourage/10.0.0.1309 X-Antivirus-Data: Virus data file v4189 created Mar 06 2002 X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N List-Post: mailto:[EMAIL PROTECTED] List-Subscribe: mailto:[EMAIL PROTECTED] List-Unsubscribe: mailto:[EMAIL PROTECTED] List-Help: mailto:[EMAIL PROTECTED] List-Id: Tomcat Developers List tomcat-dev.jakarta.apache.org Kin-Man Chung [EMAIL PROTECTED] wrote: I plan to put back the new japser source tree in a day or two. If anyone has comments, concerns, or objections, please let me know. Of course, anyone interested in contributing to the new jasper development is also welcome. YES PLEASE :) It's quite some time I'm waiting for this... We have a pretty heavily loaded website all using JSP, and the current jasper is just so slow to even considering using it (not the actual servlet, but the code generated). Can't wait to try it out... Pier -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PLAN] New Jasper
On Mon, 25 Mar 2002, Kin-Man Chung wrote: I have noticed that the current Jasper does a lot of string manipulations very slowly, e.g. there are unnecessary copying or concatenations, and the uses of String where StringBuffer should be used. Hopefully I can avoid all of these. But I don't have high hopes that Jasper performance can be improved to the point that an user will notice, because the time spent in Jasper is probably small compared with that spent in javac. Now if we could have jasper generate byte code directly... I wouldn't worry too much about this kind of optimizations - the page compilation happens only once and it's quite easy to pre-compile the pages with jspc. The place where optimizations do matter the most is the runtime - I would be happy with a generator/compiler that is slower but generates faster code. Even if it is possible to use BCEL to generate bytecodes directly, I think this would be a huge waste of time if done before the runtime is optimized. A clean generator that makes it easier to improve the generated code is better than the fastest generator. Costin I happen to agree with you. My initial effort in performance improvement would certainly be on the generated codes. I wasn't really serious when I suggested that Jasper generates byte codes. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PLAN] New Jasper
On Mon, 25 Mar 2002, Kin-Man Chung wrote: I wasn't really serious when I suggested that Jasper generates byte codes. Xalan is doing that already ( actually XSLTC ), and it's not very difficult since we generate quite simple code, unlikely to be optimized by javac too much. It'll work only for 'pure' pages, without % % - if the code uses scriptlets it has to fall back to javac. It can be done - but this should be at the very end of the todo list. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PLAN] New Jasper
On Mon, 25 Mar 2002, Kin-Man Chung wrote: I have noticed that the current Jasper does a lot of string manipulations very slowly, e.g. there are unnecessary copying or concatenations, and the uses of String where StringBuffer should be used. Hopefully I can avoid all of these. But I don't have high hopes that Jasper performance can be improved to the point that an user will notice, because the time spent in Jasper is probably small compared with that spent in javac. Now if we could have jasper generate byte code directly... I wouldn't worry too much about this kind of optimizations - the page compilation happens only once and it's quite easy to pre-compile the pages with jspc. The place where optimizations do matter the most is the runtime - I would be happy with a generator/compiler that is slower but generates faster code. Even if it is possible to use BCEL to generate bytecodes directly, I think this would be a huge waste of time if done before the runtime is optimized. I'll try to see if I can help a bit with the runtime optimizations, now that the HTTP/1.1 stack is mostly done. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
