On Wed, Jun 18, 2003 at 10:06:42AM +0600, Sanjiva Weerawarana wrote: > > The crux of the issue, I have found, is that either you have to > > manage bytecode so that the correlation to the original source is > > maintained, or you deal with the fact that you have an interpreter > > running under java, and realize the performance loss and loss of > > coherent debugging. > > So really what you're saying applies whether Rhino, for example, > is integrated to Jasper directly or via BSF. If that's true then > how do you actually use another language in JSPs? Maybe compile > the entire page into a servlet in that language? (That'll work as > long as you have the entire page using one language I guess.) > Yes, it applies in both cases. And the answer is, you use the language in a decidedly suboptimal manner. I think that JSR-223 (just getting started) has been created to address that issue to some extent, but how far it will get is anyone's guess.
I think the best case integration/performance scenario comes from management of bytecode. I also think that the management code would be hairy as all get out, if nothing else. > > Standard trade-off of performance vs. maintainability, as far as I > > can tell. > > Maintainability? You mean in terms of debugging I assume. > In terms of keeping track of how the generated bytecode from any particular language engine capable of compilation equates to line numbers in the original source when doing postprocessing. So yes, from the perspective of debugging. > > Works, yes. Mostly. There are cross-environmental issues that crop > > up. Performance-wise, once the generated servlet is created, the > > main BSF hit is re-interpreting the script that is passed to the > > engine every time the page is loaded - not bad for only a few > > concurrent clients; awful starting around 500 or more. > > Recompiling the script problem can be fixed easily for scripting > languages that support compilation. For those that don't such is > life. > Yes. We can cache the bytecode. Not a problem, I agree - but the debugging maintainability tradeoff appears. > I agree seemless integration would be very nice and my comment about > Matt's initial integration was rather stupid .. sorry. > Don't worry about it. > However, there are lots of people who are happily developing lots > of real applications using LAMP (linux, apache, mysql and php). I'd > be surprised to hear that they have fully integrated seamless > debugging etc. in that environment. However, it works and they are > happily building apps. > Agreed. Perhaps the best suggestion is to try to ensure that any possible interaction between the language environments is handled as well as possible, and debugging is limited to a simple error reporting mechanism (that the JSP compilation handles via an error page if there is a blow-up). I can believe in that, though I think the management of the interaction between compiled scripts and the generation of the servlet will be more complex than anyone expects (imagine Jasper compiling a page, hits a script, compiles it; hits a taglib call later in the page, that wants to read/write a variable that's in the compiled script - do you now load the script to get the value? What if the script modifies some backend data store every time it's called?). > Do we want to enable a php user to write JSPs and move them to > the Java platform? How would you integrate php to Jasper with or > without BSF? > I'm not sure I would. :) All you would be buying for the php migrator to JSP would be syntax - unless you're suggesting that you make available the entire library of php functions to which the migrator would be used. And then, what incentive do they have to learn JSP, unless we cripple the php that's available to force them to use the implicit objects. In that case, all that gets offered is the "security blanket" of familiar syntax, when they get dumped into learning a new object model. And there's really no point in writing a php parser that generates servlets, IMO. So, as I stated in the beginning, I think EL is the way to go. Syntax is based off of a combination of XPath and EcmaScript, it is required in the JSP 2.0 spec, the document becomes similar in appearance to php, and all of the Java objects are available - a big win, at the cost of new syntax comparable in complexity to php. I'm really unsure why the language attribute was added to the page directive in the first place, w/o something like JSR-223 and JSR-045 having been defined first. Just my thoughts, Victor -- Victor J. Orlikowski | The Wall is Down, But the Threat Remains! ================================================================== [EMAIL PROTECTED] | [EMAIL PROTECTED] | [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
