Generics will be introduced in the Java language in 2003 (probably June for JavaONE). [for more info look here http://www.javaworld.com/javaworld/javaone01/j1-01-improvements_p.html] Generics are a cool feature that allows you to avoid the problems with runtime casting of objects (and may lead to performance optimization at compilation time or even jit-interpretation time) but for the Cocoon project they will have a weird side effect: the syntax uses XML-like markup to introduce the genericity of the object containers. For example List<Integer> myList = new LinkedList<Integer>(); which must be written as <xsp:logic> List<Integer> myList = new LinkedList<Integer>(); </xsp:logic> or <xsp:logic><![CDATA[ List<Integer> myList = new LinkedList<Integer>(); ]]></xsp:logic> since writing something like <xsp:logic> List<Integer> myList = new LinkedList<Integer>(); </xsp:logic> will generate three syntax errors for java and two well-formness errors for the XML, since the XSP engine (which is based on a XML parser) will believe that the two <Integer> are markup. XSP was based on the fact that XML syntax and java code were "mostly" orthogonal (except for the < and > signs used for conditionals that must be escaped). Since the Collection API will be fully genericized in Java 1.5, I forsee an extensive use of this syntax, thus making XSP even less readable (thus, more expensive to write and maintain). Note that this very same thing will plague the xml-ized version of JSP as well. This is the last step of a reasoning that indicates how mixing markup and code is indeed bad practice and should not only be incouradged against (as both XSP and JSP do with taglibs) but should be architecturally prohibited. I know this is where Ricardo is leading with his yet-to-be announced research on an XSP successor. I'm curious to see where this leads to. Another thing that some "behind close doors" tests show is that server page compilation may indeed turn out to be a "slower" solution that interpretation. This is very likely to hold true for sitemap compilation as well. Why? one word: hotspots. Modern JVMs are entirely based on the concept that hotspots should be optimized into native code the more they are executed. Well, by compiling a server page or a sitemap, we are, in fact, "unrolling" the interpretation hotspots in a series of actions built at compilation time. This was a great optimization feature for x86 assembly up until Pentiums, but is likely to reduce performance on more modern processors (Itanium processors given the 64 bit instructions and granularity of first level caching). Just like assembly optimization is inherently tied to the silicon used, I suspect that page compilation is a performance improvement that is tied to the JVM technology as well. (in fact, it makes a perfect parallel if you think at Transmeta's code morphing techniques which are something in between a CISC-2-RISC-ifier and a JVM. Anyway, it is for sure that the first "n" executions of the compiled page will be faster than their interpreted counterpart, but what happens after 10000 iterations? 1000000? or what happens of the interpreting hotspot is shared by "all" the dynamic pages on the server side and the server has an uptime of 6 months? or what happens when Sun sees its hardware market shrink and starts selling hardware-accelerated java virtual machines? will compilation (read: optimization done by a software known as compiler) be inherently more performant than interpretation (read: optimiation done by a software known as virtual processor) no matter what? I sure see more research into JVMs than into java compilers. And to tell the truth, there is not much a java compiler can optimize rather than avoiding the need for interpretation overhead, but that, since executed all the time, will very likely be hotspotted and just-in-time-compiled down to the very native bit. I came to the conclusion that code inlining in markup and markup code compilation (which account for much of the Cocoon2 architecture and are the overlap with JSP) were architectural mistakes and will need to be corrected. This has the interesting side effect of considering dynamic tags as the only good design idea that came from JSP. Which, interesting enough, was "borrowed" from ColdFusion and now makes the concept of XSLT extensions much more appealing from an architectural point of view (even if the syntax still sucks big time and portability is almost unexistant). Anyway, don't worry, we have years to overcome these architectural details and will be so smooth that won't break any of your work but will rather be you to push for this to happen, just like the transition from Cocoon1 to Cocoon2. :) Anyway just the usual bunch of RT to make your synapses fire in unusual directions. ----------- o ----------- Ah, FYI, an headup on my status: I finished my college exams and my thesis is due June 29 with the title "Reducing the effect of growth saturation on web sites with the use of a publishing framework based on XML technologies" I will discuss it July 16. If you happen to be around Pavia, Italy, and want to be present, let me know privately and we can arrange that. Anyway, for those of you who won't make it, the thesis will be written in english and will be available on my web site (http://www.apache.org/~stefano/) the day after. Take care. -- Stefano Mazzocchi One must still have chaos in oneself to be able to give birth to a dancing star. <[EMAIL PROTECTED]> Friedrich Nietzsche -------------------------------------------------------------------- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
