Tuesday, December 10, 2002

JavaBlogs is Mavenised btw JavaBlogs is Mavenised btw. I forgot to mention, javablogs.com is now completely built, tested and deployed with Maven! Congrats to the Maven guys on producing a kickass piece of software, that's only going to improve with age. (Oh - and if you want to peddle your Maven or javablogs suggestions, try #maven on irc.werken.com) [rebelutionary] Excellent! Glad you like Maven! Do you mind if we add a link to javablogs.com on Maven's powerd by page? 11:43:12 AM    comment []

The privilege of XML parsing - Data types, binary XML and XML pipelines The privilege of XML parsing - Data types, binary XML and XML pipelines [Sean McGrath, CTO, Propylon] A good post on data types support in XML and why XML pipelines are important. XML pipelines are used extensively in Cocoon and Jelly. One interesting detail of using XML pipelines in Jelly scripts is that its easy to use nested tags to pipline XML events into XSLT, into JARV to perform some validation via DTD, XML Schema or RelaxNG, or to pineline into SOAP (via Axis) or into betwixt or digester to construct beans etc. Other custom filters, transformers or processors can easily be mixed into a pipeline. In Jelly a single tag can consume, emit, filter or transform the XML events created by its body which leads to a really flexible and powerful XML pipeline model which can easily be combined with powerful expression and scripting languages. 11:38:14 AM    comment []

JSR 201 thoughts and JSE JSR 201 thoughts.  As I pointed out in previous threads, I think the JSR 201 should broaden the scope of the proposed extensions. Instead of proposing just some minor syntactic sugars to the Java syntax, it should try to extend the language in such a way that allows unlimited extensibility of the syntax by means of macros. The idea of macros comes from Lisp languages, which use this to successfully extend the semantic of the language. In Lisp the core runtime engine deals with very few abstractions, everything else is implemented through macros. A very interesting macro system written for Java is Java Syntactic Extensions (JSE) from MIT, which allows the language to be extended by developers, with no need for a JSR. The scope of JSR 201 for example is already implemented in few lines of code in JSE and is completely portable. No need for compiler or VM changes to support them. Many of the proposed extensions being talked on Java blogs these days, like functions (with or without closures), blocks and many other syntactic sugars can be easily implemented with a macro facility, as demonstrated by JSE. Here are some examples taken from the JSE distribution: enums public enum PowerWarning BATTERY_NORMAL, BATTERY_LOW, BATTERY_CRITICAL; asserts, which are completely portable, no need to upgrade to JDK 1.4 to use them: public void yuk (boolean x) { assert(x, "hello"); } foreach: static void tst (List c, List l) { forEach (Integer i in c, Float f in l) System.out.println("contents: " + i + " and " + f); } when: static void tst (boolean b) { when (b) { panic(); } } JSE works by preprocessing the extended source code and generating pure Java source code which runs on any Java platform. There is no need for any compiler change or JVM change. Very beautifully done I think! The beaty of this approach is that one can extend the syntax of the language to support C# annotations, functions , blocks or anything else which is needed using macros and the existing Java language. [Ovidiu Predescu's Weblog] A great post on the excellent looking Java Syntactic Extensions (JSE) from MIT. Very neat.   10:56:39 AM    comment []

Electric XML vs. MSXML benchmark (CLR/JVM). Electric XML vs. MSXML benchmark (CLR/JVM). i did another benchmark for fun tonite, parsing a small (12-line) XML file using Electric XML running on CLR (compiled using J#) versus the same file using the native microsoft XML parser MSXML. surprisingly enough, Electric XML was twice as fast in all of my simple tests, whether the parsers were called from J# or C#. the contents of the file was read just once into a string, and then the string was parsed 50,000 times to generate an accurate value. Electric XML parsed the string in 0.14 milliseconds, and MSXML parsed the string in 0.28 milliseconds. not a big deal, but an interesting result. Electric XML running on a JVM parses the same string in just 0.09 milliseconds. so EXML running on a JVM is three times faster than MSXML on a CLR, at least for small files. what about MSXML running on a JVM? hah, hah, trick question! ;-) [graham glass' Radio Weblog] :-). I know EXML is optimised for XML parsing of Strings. I wonder what the performance characteristics would be like if the benchmark used Streams instead? 10:52:41 AM    comment []

.NET CLR Slower Than Most JVMs .NET CLR Slower Than Most JVMs. A recent study on Method Devirtualization and Inlining performed by Osvaldo Doederlein reveals that several JIT compilers for Java outperform .NET's CLR by a considerable margin.  This benchmark exposes the flawed reasoning of the "virtual" keyword of C#: ".NET code is likely to be uglier, harder to write and maintain (if not "unsafe" too), when compared to Java code that can just rely on the compiler."  Furthermore, .NET's code management architecture, that is compile once and cache to disk, makes speculative and profile based optimizations (ala Hotspot) a unlikely feature in the foreseeable future.  [::Manageability::] Wow. What with this and that .NET isn't very good for high level languages. I guess its gonna take a while for MS to catch up with the rest of the industry on making fast VMs though I am suprised with the ugly 'virtual' keyword in C#. Premature optimisation is the root of all evil. 8:44:26 AM    comment []