Scott first introduces us to the death of Java, or more precisely, that rumors "of [its] death have been greatly exaggerated." Instead, Java is the COBOL of the 21st century. Although it is over 10 years old now, it was designed with C and C++ in mind so you might consider it even older than that.

Scott notes that after ten years many technologies are dead (or rotten and decaying!). Does anyone still use DOS, Lotus 1-2-3, or WordPerfect? (Do you still want to?) I might be partial to DOS because that's where I cut my teeth (and the thought of using it still has me licking my chops), but other than that, I think the answer is a loud "hell, no!"

On the other hand, some technologies "age like a fine wine." Scott includes HTTP and TCP/IP in this category.

Finally, the third class of applications adapt and evolve to stay alive. FTP moved to SFTP and now we're using BitTorrent. Telnet moved to SSH and POP to IMAP. It is in this vein that Java finds itself, struggling to adapt.

It's not that Java (the language) isn't capable - it's that it gets in your way. Scott points out that in essence, the main complaint about Java is "that it is one level of abstraction too low." The soup du jour is simplicity - we want things to be "better, faster, [and] lighter." In fact, anyone who has written a line of code in Java knows he's got around 29 more to write before he's done anything useful. Scott then shows a 35 line example of reading a file and printing it out line by line to illustrate his point.

In Java, we often "develop 'util' classes to overcome this abstraction layer mismatch," Scott says, noting that being forced into having com.mycompany.StringUtil due to Sun's declaration of String as final is a code smell. Surely there is a better way!

Enter Groovy, the "first scripting language to be officially sanctioned by Sun to run on the JVM." It can run in compiled or interpreted mode and it is easy to install (though it took me some time because of less than helpful error messages about me pointing to the bin directory under Java, rather than the base Java directory). Most importantly, it fills the void of that "abstraction layer mismatch." Reading and writing lines in a file with Groovy is reduced to:


Look familiar? It's definitely Ruby-esque, but based on my cursory inspection, also keeps some Java idioms where appropriate (for example, import over require). I can definitely see how it would be easy for a Ruby developer to pick up, but on the other hand, I think it would be easier for a Java developer to transition to this than to Ruby. I'm looking forward to playing with it some more.

Finally, Scott goes through some "Groovy hacks" related to File I/O, XML and HTML, SQL, Groovlets (surprisingly, Groovy's servlets), and Grails. In particular, you should have a look at the Groovy Markup way of writing markup, because its quite a bit more elegant than ><ML (that my 13375p34|< for an X). I won't go into detail about the code samples, as you can find those elsewhere (.PDF) if you wanted (perhaps in GINA, the canonical Groovy book), but I do plan to cover an introduction to Grails in a future post related to another presentation from NFJS. When I start playing more with Groovy I'll put up some real code samples then.

Thoughts about Groovy?

First set of sessions: No clue. Leaning toward session 1, Groovy: Greasing the Wheels of Java by Scott Davis.

Second set: 7 (Groovy and Java: The Integration Story by Scott Davis), 8 (Java 6 Features, what's in it for you? by Venkat Subramaniam), 9 (Power Regular Expressions in Java by Neal Ford), or 11 (Agile Release Estimating, Planning and Tracking by Pete Behrens). But, no idea really.

Third set: 13 (Real World Grails by Scott Davis), 15 (10 Ways to Improve Your Code by Neal Ford), or 17 (Agile Pattern: The Product Increment by Pete Behrens). I'm also considering doing the JavaScript Exposed: There's a Real Programming Language in There! talks in the 2nd and 3rd sets by Glenn Vanderburg.

Fourth set: Almost certainly I'll be attending session 20, Drooling with Groovy and Rules by Venkat Subramaniam, which will focus on declarative rules-based programming in Groovy, although Debugging and Testing the Web Tier by Neal Ford (session 22) and Java Performance Myths by Brian Goetz (session 24) are also of interest to me.

Fifth set: Again, almost certainly I'll go to Session 27, Building DSLs in Static and Dynamic Languages by Neal Ford.

Sixth set: No clue - I'm interested in all of them.

Seventh set: Session 37, Advanced View Techniques With Grails by Jeff Brown and Session 39, Advanced Hibernate by Scott Leberknight, and Session 42, Mocking Web Services by Scott Davis all stick out at me.

Eighth set: Session 47, Pragmatic Extreme Programming by Neal Ford, Session 46, What's New in Java 6 by Jason Hunter, Session 45, RAD JSF with Seam, Facelets, and Ajax4jsf, Part One by David Geary, or Session 44, Enterprise Applications with Spring: Part 1 by Ramnivas Laddad all seem nice.

Ninth set: Session 50, Enterprise Applications with Spring: Part 2 by Ramnivas Laddad or Session 51, RAD JSF with Seam, Facelets, and Ajax4jsf, Part Two by David Geary are appealing, which probably means the eight set will be the part 1 of either of these talks.

Tenth set: Session 59, Productive Programmer: Acceleration, Focus, and Indirection by Neal Ford is looking to be my choice, though the sessions on Reflection, Spring/Hibernate Integration Patterns, Idioms, and Pitfalls, and NetKernel (which "turns the wisdom" of "XML is like lye. It is very useful, but humans shouldn't touch it," "on its head" all interest me.

Final set: Most probably I'll go to Session #65: Productive Programmer: Automation and Canonicality by Neal Ford.

As you can see, there's tons to choose from - and that's just my narrowed down version. So much so, I wonder how many people will leave the symposium more disappointed about what they missed than satisfied with what they saw =).

Anyway, let me know what you'd like to see. Even if its not something from the list I made, I'll consider it, especially if there seems to be enough interest in it.

The first item where I see a distinction that needs to be made is on, "what do we mean when we are talking about XML?" I see two types - XML the paradigm where you use tags to describe data, and the XML you write - as in, the concrete tags you put into a file (like, "see that XML?"). We're talking about XML you've written, not the abstract notion of XML.

The second idea: what is code? What is data? Sean Corfield offers what I would consider to be a concice, and mostly correct definition: "Code executes, non-code (data) does not execute." To make it correct (rather than partially so), he adds that (especially in Lisp) code can be data, but data is not code. You see this code-as-data any time you are using closures or passing code around as data. But taking it a bit further - your source code is always just data to be passed to a compiler or interpreter, which figures out what the code means, and does what it has been told to do.

So is XML code? Certainly we see it can be: ColdFusion, MXML, and others are languages where your source code is written (largely) in XML. But what about the broader issue of having a programmatic configuration file versus a "data-only" config file?

Is the data in the config file executable? It depends on the purpose behind the data. In the case of data like


I think (assuming there is nothing strange going on) that it is clearly data. Without knowing anything about the back end, it seems like we're just creating a data structure. But In the case of DI (and many others uses for config files), I see it as giving a command to the DI framework to configure a new bean. In essence, as Peter notes, we've just substituted one concrete syntax for another.

In the case of XML, we're writing (or using) a parser to send data to an intepreter we've written that figures out what "real" commands to run based on what the programmer wrote in the configuration file. We've just created a higher level language than we had before - it is doing the same thing any other non-machine code language does (and you might even argue about the machine code comment). In the configuration case, often it is a DSL (in the DI case specifically, used to describe which objects depend on which other objects and load them for us).

While we don't often have control structures, there is nothing stopping us from implementing them, and as Peter also notes, just because a language is not Turing complete), doesn't mean it is not a programming language. In the end, I see it as code.

Both approaches are known to have their benefits and drawbacks, and choosing one over the other is largely a matter of personal taste, size and scope of problem, and problem/solution domain. For me, in the worlds of JIT compiling and interpreted langages, the programmatic way of doing things tends to win out - especially with large configurations because I prefer to have the power of control structures to help me do my job (without having to implement them myself). On the other hand, going the hard-coded XML route is especially popular in the compiled world, if not for any other reason than you can change configurations without recompiling your application.

I don't make a distinction between the two on terms of XML is data, while programming (or using an in-language DSL) in your general-purpose language is code. To me, they are both code, and if either is done incorrectly it will blow-up your program.

Finally, I'm not sure what value we gain from seeing that code is data (and in many cases config data is code), other than perhaps a new way of looking at problems which might lead us to find better solutions. But that isn't provided by the distinction itself, just the fact that we saw it.

Comments, thoughts, questions, and requests for clarifications are welcome and appreciated.

Next, of interest to Java programmers and ORM fans, Google has contributed code to Hibernate that allows people to "keep their data in more than one relational database for whatever reason-too much data or to isolate certain datasets, for instance-without added complexity when building and managing applications."

Then, Bruce Tate, who is probably best known for his books Beyond Java and From Java to Ruby (by me anyway) has a case study on ChangingThePresent.org, his new project that uses Rails. It looks like a good starting point if you are developing a high-traffic Rails site. And, the site does some good charity work - taking only the credit card processing fee from your donation to the causes of your choice.

Finally, Gilad Bracha speaks about dynamic languages on the JVM. Until recently he was the Computational Theologist (is that someone who studies the religion of computation?) at Sun. The talk is just over 30 minutes long, and is at a surprisingly low level - so geeks only! He discusses a few of the challenges with implementation details on getting dynamic languages to run natively in byte-code (as opposed to writing an interpreter in Java which would then interpret the dynamic language). This includes a new instruction for invoking methods - invokedynamic, as well as a discussion on possible implementations of hotswapping - the technique that allows you to modify code at runtime. Very interesting stuff.

For today, I should be done referencing InfoQ, except to give them credit in my next post for turning me on to a couple of good resources for implementing DSLs in Ruby (which is the subject of my next post). I'll post the link in the comments when I'm done with it - I try not to edit these posts anymore since MXNA likes to visit every 30 seconds and thinks the date is the unique identifier of the post... you know, instead of using the XML field called "guid." =) (sorry guys, just poking a little fun - thanks for aggregating me).