What's That Noise?! [Ian Kallen's Weblog]

Main | Next month (May 2004) »

Monday April 26, 2004

It's not just far out, it's Groovy Does the programming world need another scripting language? There's already a ton of them and they all have their pros and cons and their adherents and detractors. Well, kick down your cobblestone and look for some fun: now there's Groovy.

I've always enjoyed the expressiveness and rapid development qualities of Perl, Python and Ruby. However, the proliferation of Perl's obscure idioms and linear of scripting tendencies of many of its users is enough to make you shudder. The absence of semi-colon statement delimiters is enough to always make me feel like I've forgotten something with the latter two. Then there's function-crazed languages like PHP and Tcl. Maybe the world does need a clean break from it all? Well, Groovy is definitely a departure of sorts. It looks a little like Ruby and a little Java with a dash of JSTL but not entirely like any one of them. And it compiles down to ye olde JVM's bytecode.

The Groovy website is loaded with examples for using SQL and writing servlets (um, make that "Groovelets") using the Groovy syntax. Support for regexp and xpath matching is in there. Reading through it, I'm impressed with the familiarity and yet the newness of the syntax. But I can't help wondering if I'd really use it to build any substantial software. In many respects, it took Java so long to mature as far as lots of those little things that matter to me like regexp support, cached prepared statements in the JDBC API and the various jax-foo API's -- all good stuff but a long time coming. So why start using Groovy?

Well, I thought of one place where I'd imagine using Groovy. When collaborating with GUI implementers on the web tier of an application, I have in the past found myself working hard to keep the communications loop tight between those dealing with the markup and the tags and on the other end those dealing with Action classes, servlets and filters. "The MonkeyBean has a Collection of Bananas... you can iterate over each of them to access their Peels..." Wouldn't it be nice if the folks working with the markup and tags could write their own beans and actions without having to know all of that Hard Java Stuff? Well, maybe. I mean if they're implementing a lot of the display logic with JSTL, why not give them an easy entry into the data-centric modules that the JSTL accesses?

Well, I don't know but I'm willing to be open minded about it and I guess the powers that be in JCPville are as well; Groovy has it's own JSR. There are a lot of important check-off items already in place:

The latter two are really important when your practicing continuous integration. Other stuff like XML-RPC support and embeddability, that's all nice too.

I can see the why Groovy might be more attractive that Jython or something like that that uses the JVM but isn't native to it. On the other hand, if I didn't know better were I hiring an engineer (and I'm not, please, no phone calls) and a candidate had "Groovy" listed on their resume, I might pass them by as a goofball. Although, knowing what I do now about what Groovy may potentially be good for, I might put that resume on top of the file.

I think I feel a song coming on:

Slow down, you move too fast
You got to make the morning last
Just kicking down the cobblestones
Looking for fun and feeling groovy
Ba da da da da da da, feeling groovy

Hello lamppost, what'cha knowing
I've come to watch your flowers growin'
Ain't cha got no rhymes for me?
Doo-it in doo doo, feeling groovy
Ba da da da da da da, feeling groovy

I got no deeds to do
No promises to keep
I'm dappled and drowsy and ready to sleep
Let the morning time drop all its petals on me
Life I love you, all is groovy

59th Street Bridge Song

Sorry, I got carried away there. I couldn't help myself. ( Apr 26 2004, 09:25:52 PM PDT ) Permalink

Wednesday April 21, 2004

Container? I don't need no stinkin' container! There's no denying it. A Boston Tea Party is swelling against Sun, the JCP and the way Java API's have been handed down from that Cathedral. Look at all of the bitchin' publications that've cropped up in the last few weeks and are expected in the coming weeks and months

Object-relation mapping without the container: A quick rundown of Hibernate, Spring Framework based transaction management plus a side order of DbUnit; more fun than you can shake a stick at.
Hibernate: A Developer's Notebook: O'Reilly has posted a sample chapter with a simple Hibernate example.
Hibernate In Action: The publish date on this is now listed as August 2004; I thought this was coming sooner but nonetheless seeing as how it's from the horses mouth, it should be a good read.
Java theory and practice: Coaxing J2EE out of the container Projects like Somnifugi JMS blur the boundary between J2EE and J2SE: Discusses using JMS, JNDI and JMX for J2EE outside of the EJB container.
Expert One-on-One: J2EE Development without EJB: From the Spring Framework creator, Rod Johnson follows up on his fine 2002 publication "Expert One-on-One: J2EE Design and Development"

That's just the activity that's bubbled up through The Establishment. The J2EE blogosphere and TheServerSide is effervescing with stuff about Velocity, Tapestry, Jython, Java Groups, Pico, Hivemind, iBATIS and so on week in and week out. Struts and Ant are probably the prime examples of de-facto standards arising from outside of Sun but Hibernate has certainly opened everyone's eyes to the notion that the blueprints and the pet store aren't ominpotent and in fact, the whole "work inside our container API's and let the magic get handled for you" concept is pretty limited.

The bottom line for me is: I want to be able to easily test stuff outside of the containers and the mandatory interface implementations. Traditional J2EE, the practices promoted around it and the tools provided haven't accounted for that requirement. So the grassroots have.

Sun, consider yourself put on notice!

Due to space constraints, I couldn't get into it in my article about AOP (Aspect Oriented Programming: An Introduction) earlier this month but as I was looking around the landscape of AOP implementations and the related technologies (i.e. Inversion of Control) it's become increasingly apparent that Hibernate, Spring and an array of other projects that've gained momentum from the grassroots level are really the important story this year in J2EE, not Java Server Faces or EJB 2.1 or EJB 3.0 -- the J2EE developers in the trenches are tired of Sun groping around trying to get it right and they're pressing ahead with real-world solutions without Sun's official blessing. If useful standards can arise out of the open source ecosystem, then Sun's JCP, the insular and opaque JSR working groups and the Decisions From On High about what's important at JavaOne are likely to see their relevance ebb.

Hasta La Vista, Baby

( Apr 21 2004, 11:31:18 PM PDT ) Permalink
Comments [2]

Saturday April 17, 2004

What Is The Matrix? I just noticed that TheServerSide has posted a comparison matrix of J2EE servers.

TheServerSide apparently has had this little gem published for a while, their Application Server Matrix provides links to downloads, data sheets and product reviews. Great resource! ( Apr 17 2004, 10:28:29 AM PDT ) Permalink

Friday April 16, 2004

Dumping Java object contents If you've ever exploited Perl's Data::Dumper to inspect a Perl object, you know how useful it can be. For Java programmers, the reflection API provides tools to perform a similar interogation but the API has long lacked a higher level tool. The Jakarta commons-lang jar has a goodie to help.

I first ran across the ToStringBuilder class looking for a tool to standardise the formatting of toString() -- it's annoying to trace a set of objects' contents to a log file and find that they all implement toString() with different levels of completeness or with different formatting conventions. Well, this class has another little gem in one of it's static methods. Check this out:
System.out.println("An object: " + ToStringBuilder.reflectionToString(anObject));
<Emeril Lagasse>BAM!</Emeril Lagasse>
That's it.

By providing a higher-level wrapper API, ToStringBuilder makes using reflection to dump a Java object contents a little bit easier. Of course, seeing as how I started off talking about Perl, it's worth a mention that TMTOWDI'ness presents itself in this case. The Java bean API's XMLEncoder can be used to serialize a Java object to XML. ( Apr 16 2004, 10:59:39 PM PDT ) Permalink
Comments [2]

Wednesday April 14, 2004

PHP versus J2EE I don't like language wars, different languages and frameworks usually have a mix of strengths and weaknesses. However, I'm presently looking at some fixes (mostly resiliency issues) that have to be applied to a web tier built on PHP and am thinking about what's over the horizon for future scaling requirements.

I first used PHP in 1996 (it was called PHP/FI at the time) -- it offered a very innovative alternative to Perl and CGI generated content by making the execution flow out UI embedded logic. I liked it. The language was easy; very Perl-ish. But over the years, other frameworks have emerged that, despite the many improvements PHP has enjoyed, easily eclipse PHP.

PHP's primary strength is its enablement of rapid development of database backended web applications. For prototyping and providing "functional mockups", that's all well and good. But what I'm seeing is that as soon as you want to scale the application along some axis (runtime traffic, i18l, collaborative development, multiple presentation formats), it's difficult to justify sticking with PHP. From what I reckon, a J2EE web tier (servlet container, JSP w/jstl taglibs, MVC i.e. struts, etc) offers a lot of high level infrastructure and, when contrasted with PHP, is a clear winner:

	PHP	J2EE
Runtime scaling	There are opcode caching extensions but it's not a core component of the PHP runtime environment PHP is not thread-safe. You pretty much have to run PHP on a pre-forked Apache server. That's not too bad but it means that if you have a large Apache process pool, each process has to have its own connection to a database. If you have multiple persistent connections and a few hundred Apache processes, you're taxing the databases (because of the large number of open connections) and taxing the OS (because of the large number file descriptors open and memory consumption). And every forked process is an island of process space; sharing data between them is a PITA (you have to manage shared memory) and sharing resources is impossible (e.g. forget about pooling your persistent database connections).	Servlet container hosted runtime engines (such as JSP or Velocity) usually have code caching out-of-the-box. Higher level caches such as OSCache promise to provide even more to reduce the computational burden on the web tier. They easily take advantage of resources shared between threads such as database connection pools, external service interfaces (e.g. remote and/or local EJB factories; the home interfaces) and the container itself.
Content format scaling	If you want to co-brand a PHP site, plan on having conditional logic scattered and tangled all over the UI code. This quickly degrades down into a maintenance nightmare.	A J2EE MVC framework such as Jakarta Struts (with tiles) provides a centralized mechanism to declaritively and programmatically control how content is assembled for presentation.
Locale scaling	PHP allow you to extend the runtime with the GNU gettext framework. IMO, this is a difficult to use system; you have to manage PO files that have a peculiar file format.	The standard Java library has ResourceBundle support built-in with a simple file format (properties files) and, again, web tier infrastructure such as the servlet container, JSTL and Struts provides easy-to-use tools to access ResourceBundles.
Functional scaling	Extending PHP often requires recompiling the PHP runtime to statically link in different extensions. This results in closely binding your runtime requirements and your infrastructure compilation requirements. Maintaining persistence flexibility is difficult with PHP; while the PEAR abstraction layer provides a baseline of RDBMS independence the language is still bloated with database function calls with every backend you use. Furthermore, as outlined above, changing backends requires platform dependent code, perhaps recompiling PHP itself and then having client libraries installed where the runtime is executing.	Most Java libraries are available as "Pure Java" i.e. jni support, deploying OS-native libraries, isn't an issue. You never have to recompile Java to extend it. JDBC provides a standard interface to different database backends. While this won't help with things like SQL implementation differences, higher level tools like Hibernate's object-relational framework potentially will. Furthermore most database drivers are "Pure Java" i.e. there's no need to recompile anything and no need to, say, make sure LD_LIBRARY_PATH is set properly to enable your database drivers.
Collaborative scaling	The distinction between UI code and business logic is fuzzy and requires lots of developer discipline to keep it cleanly separated; there's little support in the framework itself. This pretty guarantees closely mingling formatting and display code with lots of logic. Yuck.	While it's certainly possible to write horrible applications with J2EE web infrastructure (i.e. the the fact that you can embed Java code, er, scriptlets, directly into a JSP is a terrible fact of life), the wealth of framework support (JSTL, Struts, etc) makes it easy to follow practices that keep the separation of concerns clean.

A clean separation of concerns is important. Collaborative web application development usually has different roles (the Java programmer providing business API's and beans, the UI layout coder developing the HTML structures, the UI logic programmer writing tag libraries and/or integrating them with the HTML structures) -- even if you're one person coding all of these out, having the different work elements clearly defined and cleanly separated will make your job easier. When you're working in a collaborative environment, the separation of concerns is essential.

There are other little things in the pro's and con's. PHP can support URL rewriting session tracking without doing anything special in the markup code -- nice that it can do that unintrusively but icky on other counts

Markup has to parsed outside of PHP's normal tokenization; it's a post-processing of the markup
It doesn't adaptively enable URL rewriting when cookies are disabled at request time, it has to set at runtime

I'd rather use a taglib in a servlet container to keep track of the URL rewriting needed, if any.

All of these points of contrast lay atop the basic structural differences between the PHP and Java languages: Java has Object Oriented Programming (OOP) as a core part of it's design, PHP has OOP as an odd afterthought. Java has real exception handling, PHP awkwardly provides function calls to register error handlers and function to trigger an error. OO is a core element of code modularization, reuse and extension.

Additionally, while I have my misgivings about EJB's and their misuse, EJB's are an established framework for separating the business and persistence tiers from that of the UI. Service oriented architecture (SOA) patterns are also well established amongst the J2EE development community -- this also better enables collaborative development and clean separations of concern, ergo, long term maintainability.

A final point of comparison and contrast is how closely bound PHP is to the web server in a typical architecture. It's nice to have the ability to scale the HTTP interface independently from the application layer. With PHP, the only option there is to run another webserver; a reverse proxy to offload all of the HTTP servicing. With a servlet container there are various options to connect the HTTP interface to the Java engine via a connector. For example with Apache and Tomcat, you can use mod_jk to connect them, and just to sweeten the deal a bit, mod_jk provides a bit of scaffolding to support load balancing.

It's not my intention to sweepingly indict PHP. For the simple stuff, I like it. And I know it's extremely popular ("50 Million Elvis Fans Can't Be Wrong!"). But when you get beyond needing "Server Side Includes On Steroids" and have to deploy a scaled up database backended application, PHP's weaknesses come to the foreground. Yea, yea... I know that Yahoo! uses PHP and I bet there's a lot to learn from their experiences with it -- I expect PHP creator Rasmus Lerdorf's employment with Yahoo! to drive a lot of innovation in PHP's future. But at this point in time, for the web application requirements I'm looking at, I gotta give it to J2EE.