Better Null Handling Strategies for Java

Uploaded a presentation on “Better Null Handling Strategies for Java” to SlideShare. Enjoy.

The best Markup Builder I could build in Java

Using Groovy MarkupBuilders spoiled me for other ways to create HTML pages from code. Others think the same. But in some organizations you have to use Java and can’t use Groovy - at least when you can’t sneak it in.

So I tinkered around in Java to see what’s the best MarkupBuilder I can write with Java. Using DSLs and Fluent Interfaces (times(5).loop), I came up with a nice solution. It’s not Groovy, but it works.

   Page page = page(
      html(
        body(
          // A comment
          h1("Name games"),
          p("Hello ${coolName}, and hello", "id:${id}"),
          ul(
            new Loop("stefanie", "${name}") {
              protected Element each(String item) {
                return li(item);
              }
            }),
          loop("[${number}] ", "number", 1, 2, 3),
          text("..."),
          box("Warning private!"),
          p("Are you dynamic?"),
          // Some dynamic content
          new Action() {
            protected String with(Context context) {
              return "I'm dynamic, " + context.get("name") + ".";
            }
          }
        )
      )
    );

There are some tricks to make it better than most such Markup Builders in Java. I tried to use ideas from building DSLs in Java. Those are using static imports and varargs. The body, html and other elements are static imports from a MarkupBuilder class.

  public static Element body(String body) {
    return new Element("body", body);
  }
  public static Element body(Element... elements) {
    return new Element("body", elements);
  }
  ...

The varargs helps with adding a variable number of childs to an element:

h1(
   p("One"),
   p("Two"),
   p("Three")
);

Another problem is how to put object values into the generated markup. String concatenation leads to noisy code

  "Hello " + name + "!"

so I decided to use a expression language where the Java unified expression language comes to mind. There is an open source version available called JUEL. Now I can use

  "Hello ${name}!"

Attributes are also treated as expressions and seperated by commas, their names and values seperated with a colon.

   p("Hello ${coolName}, and hello", "id:${id}, class:list"),

Loop and Action classes allow for dynamic content.

          ul(
            new Loop("stefanie", "${name}") {
              protected Element each(String item) {
                return li(item);
              }
           }),

I’ve used the template design pattern for this, again with expressions, in a way Spring provides JDBC templates. Another nice idea is with static methods it’s also easy to develop custom, semantic tags, so the developer doesn’t need to know or see the actual HTML markup which is created. For example I used a box “tag” which translates to

public static Element box(String text) {
  return div(
                 p(text)
           );
}

Closures in Java 7 will make it much easier to write a MarkupBuilder. The Action and Loop inner classes will go away and the code will be more Groovy like. When they add syntactic sugar to create maps I can drop the “name:value, name:${value}” style for attributes and move to [ "name" : value, "name": value ] instead, which doesn’t need the EL to work. With some small things to add the MarkupBuilder can be used for JSON or XML.

I’m interested and open to all techniques and ideas to improve the markup builder.

Thanks for listening.

Graeme - the Grails bug buster

While testing Reposita with the Grails repository, I was amazed about Graeme who is the Grails project lead and recently became the CTO of G2One.

Scanning the Grails subversion commits and searching for bug fixes, Graeme seems to be a very very active bug buster. One in four commits is a bug fix. Perhaps this directly contributes to the Grails success story. I hope he keeps up fixing bugs, now that he’s CTO.

See for yourself:

More Hibernate JPA troubles

When running JPA together with Grails (not tested on it’s own), with a Hibernate ORM either Hibernate, or with a pool the pool (c3p0), runs out of connections. The architecture of Reposita has a Grails frontend with a (Java) JPA backend to enable switching the frontend and backend independently. The MySQL database barks about to many connections. I do some persist() calls to the database, I guess around 50. Each call gets an EntityManager, does a transaction and closes the EM. Shouldn’t closing the EM close the connection and return it to the pool? Or is this a problem together with Grails, which also runs Hibernate to a MySQL database? Any ideas? I’ve run out of mine.

Update: I’m not sure what I’m doing wrong,

em = getEntityManager();
em.getTransaction().begin();
em.persist(entity);
em.getTransaction().commit();
...
em.close();

should work. But even when using with c3p0 as a pool, when calling this code several times, the connection count to the database increases until it reaches the limit, where the MySQL database barks about too many connections.

This might be caused by create-drop of my testing setup.

Update 2: As Dirk pointed out, of course em.close() should go into a finally block and I might add there should be some exception handling and rollback() action.

JPA hangs Grails, Part 2

As I wrote before, using Java JPA in my Grails application, the Grails application (0.6) hanged. After not much help from the mailing list, I updated to Grails RC1.0 without success. Adding the newest Hibernate JARs and Annotations JARs to the grails/lib directory solved my issue though. Grails no happily uses my JPA/Dao backend. Puh.

Creating a fluent interface for Google Collections

Chris wrote about functional programming in Java. As an example he used Google Collections which “is a suite of new collections and collection-related goodness for Java 5.0″.

Looking at his post he gives the following code on how to use Goolge Collections

files = Iterables.transform(
  Iterables.filter(
      Iterables.filter(getPagesList(),WebPage.class),undeletedPages),
  new PagesToFilesTransformation()))

This is very verbose and hard to read. Mostly due to the static method calls and the seperation of the first “filter” and the “new PagesToFilesTransformation()” parameter. Using a static import we can reduce this to:

import static Iterables.*;

transform(
   filter(
      filter(getPagesList(),WebPage.class), undeletedPages),
   new PagesToFilesTransformation()))

Better. I’ll show you how to make this even more readable with a fluent interface. I use the following example for this:

List names = Arrays.asList("Stephan", "Chris", "Mike", "Miha", "Katrin");

Iterable filtered =  Iterables.filter(
  Iterables.filter(names, or( isEqualTo("Katrin"), isEqualTo("Miha"))),
    lengthLessThan(5)) ;

We want to move this code to a fluent interface. Martin Fowler wrote about Fluent Interfaces on his bliki and there is a entry on Wikipedia. They were made popular by JMock as a way to specify mock expectations.

logger.expects(once()).method("setLoggingLevel").with(eq(newLevel));

What is a fluent interface though? For me it’s an interface to an API which is more consistent and readable. Which helps you do several steps with an API in a correct way. It’s often implemented with speaking method names and call chaining. These together create the illusion of natural, descriptive language. When the chained methods return the correct type, most often it’s impossible to call the wrong methods or methods in the wrong sequence. Therefor fluent interfaces create better readable code with less bugs. Which distinguishes them from domain specific languages (like in Ruby on Rails), macro programming (Lisp) or plain language constructs (methods which take closures) like “[1..5].each { … }”. The differences is fluent ;-) “5.times.each {…}” could be considered a simple fluent interface.

The most recent fluent interface in Java with some fame is Quaere, a kind of LINQ for Java for querying object graphs. There even is a promising Quaere API for JPA. I really think fluent interfaces are useful, although others think they are stupid. I keep to myself what I think is stupid and we see where this all is going to.

Back to our example. I’ve recently shown how to create a fluent interface for object creation. One for Google Collections might look like this:

Iterable<T> filtered =
    with(names)
   .filter( or(isEqualTo("Chris"), isEqualTo("Miha")))
   .filter(lengthLessThan(5));

This example isn’t optimal, but much more readable than the one given by Chris. The or() part could be improved because it doesn’t look very nice. This will change with closures. Fluent interfaces will boom with closures in Java 7.

In the comment to his blog post, Chris mentions “Making a fluent interface to do this might be a little risky, because I think there’s an expectation* that a method like Iterable.filter() wouldn’t modify the source iterable itself, but rather would return a new, filtered iterable.” We do not need to modify the Iterable, we only hold a reference and create new fluent interfaces on the fly as needed. Our code to enable a fluent interface for Google Collections this is rather simple:

public class FluentIterable<T> implements Iterable<T> {
  private Iterable<T> iterable;

  public FluentIterable(Iterable<T> iterable) {
    this.iterable = iterable;
  }

  public static <T> FluentIterable<T> with(Iterable<T> iterable) {
    return new FluentIterable<T>(iterable);
  }

  public FluentIterable<T> filter(Predicate<? super T> predicate) {
    return new FluentIterable<T>(
        Iterables.filter(this.iterable, predicate)
    );
  }

  public Iterator<T> iterator() {
    return this.iterable.iterator();
  }
}

This example has several main points. The with() static method call is descriptive and creates a fluent interface object for us to hold the Iterable object. Second most methods in fluent interfaces return the object itself. We create a new fluent interface object in filter to wrap the filtered iterable and enable chaining. My last example with object creation did hold the same bean and did not create new objects on the fly. This really depends on what should be done. We could have set the new iterable instead of creating a new wrapper like this:

  public FluentIterable<T> filter(Predicate predicate) {
    Iterable filtered = Iterables.filter(this.iterable, predicate);
    this.iterable = filtered;
    return this;
  }

This mostly depends on your style and if you think immutable objects are good or bad. For this I prefer the immutable Fluent Interface object over the mutable. Perhaps this is a pattern.

Conculsion:: A fluent interface for Google Collections would be useful. It’s more readable, less error prone and flows. Although my example works and is usable, there needs to go more work into a fluent interface for Google Collections to make it useful. For example support more Predicates and support transformations.

Thanks for listening.

Grails, Hibernate and JPA: hanging application

When developing an application in Grails I’ve been adding a backend written for JPA. This should be no problem - you think. But while the unit test for the JPA backend work fine for themselves, when adding the backend to the Grails application, Grails hangs when accessing the EntityManager. It does not help that all my efforts to join the Grails mailing list with my gmail address have failed so far. I have no clue how to fix this problem which took most time out of my last weekend :-) Perhaps Hibernate does not like to act as a Grails ORM and at the same time as a JPA provider. Or I have JAR conflicts. Any ideas?

Update: It has been suggested that the problem might be that there are several incompatible ASM jars in the classpath.

Drop IDEA, move to Eclipse? No open source license from IntelliJ

I need a tough decision to make. I’ve been using and evangelizing IDEA from the first IDEA release several years back. Whenever I came to a new company I introduced IDEA as an IDE and kept using it for commercial and open source use since then. Because I’m less productive with other IDEs I moved several projects where I arrived to IDEA ;-) I evangelized nearly the whole German Java IRC channel into IDEA. When I left my last employeer, I lost access to an IDEA license. Thinking that IDEA is the best IDE around - with quite some margin - I wanted to get an Open Source License for IDEA to develop Reposita, Messages, Meaxure and Radeox. I have a difficult case as there is no community for those projects yet because they just started. Writing to Intellij and pleading for a license, I got no answer.

So now I have three options: Buy a $249/year personal license, move to Eclipse (which I use at work, but which is far from being a good IDE) or learn something new and go with NetBeans? What does that mean for other contributers? Some of them will have access to an IDEA license. What are your experiences with different IDEs in on open source project? What would you do?

The IDE should support Groovy, Grails and Seam. Guice would be nice. Any other options?

Thanks for listening.

Update: See here.

Grails more productive than Rails

Catchy title. But the guys from ALTERthought have some - much needed - numbers. Their numbers show Grails to be more productive than Rails, which is in turn more productive than Spring and pure JEE. As I’ve argued for years, there is no science in computer science. We need to put facts back into computer science. Hard numbers instead of faery tales. Hacknot thinks so too. Thanks for the real numbers. Two thoughts:

1. This is development effort, not maintenance. Glass shows that 40 to 80 % of effort go into maintenance.
2. We compared Grails to Seam and think they have much in common. Seam productivity should be nearer to Grails than to the standard JEE stack

Thanks for listening.

Convention over Configuration Framework in Ruby from 2002

I thought about what I did in the past. In the 90s I was heavily into developing applications with dynamic languages. Mostly Perl and Python. And a lot of Ruby later. They were much easier and faster to develop than C. Especially Python had the best web frameworks back then. Other languages we used like Delphi weren’t very useful for web development. Some of those projects went down in flames due to the dynamic nature of Python and the cryptic nature of Perl, but that’s another story to be told.

Moving into Java

At the end of the 90s I moved into Ruby development. Ruby was much cleaner than Perl and more C-like than Python. We started using Ruby for shell scripting and maintenance work and moved into web development. The problem back then was that the Ruby community was small, documentation sparse and the most promising frameworks came from Japan and had only Japanese websites and documentation. Ruby was a joy to develop in, compared to Java which had risen to more prominence in the second half of the nineties.

But over time we used more and more Java for server-side development and departed for various reasons from dynamic languages. Mostly because the documentation for Java was better, the JDK provided all you needed and the language was C-like, which meant a lot of potential developers from university - the only source of web talent at the time. Pure servlets were very bare bone but usable and I wrote my first HTML rendering library which was later replaced by JSP.

My Ruby web and database framework

Ruby development moved to my spare time and I kept developing web sites with and frameworks for Ruby. Which brings me to my last Ruby project, a web and database rapid development framework. I named the Framework Ruby.APP, in reference to NeXTStep and WebOjects, both which made a great impression on me when I first used them. Back in 2003, some time into development - which started in 2002 - I wrote

The most important design goal is *ease of use*. Ruby.APP will provide the easiest way for building web applications (from my point of view :-)

or stated the same as a tag line:

Easy and fast development of web applications

That was the overall goal after more than 8 years of web development experience. I’ve had written the same code over and over again, in different languages and different frameworks. We wrote the same stuff for nearly every customer and project. I thought to myself the computer should try to figure things out, not me. And frameworks should reflect the standard cases and make them easy.

Convention over configuration

This directly bounced me into the direction of convention over configuration. Ruby.APP contained Ruby.RO, a component framework and Ruby.RDO, a simple database ORM. Both favored conventions, so no need for configuration.

As I stated in one example:

Displays a table of persons that are read from the database. This is all the code you need, no database code.

No database code meant no configuration, no schema and especially no SQL. The same went for Ruby.RO, where you could attach events to view objects like text input fields and the connection was with convention, not configuration. There are a lot of similarities to Ruby on Rails, Grails or Seam, e.g. I used a “findAll” method to get all models from the database. Ruby.APP wasn’t as sophisticated as RoR, Grails and Seam are now, but it was 2002 and people have learned a lot since then. Most developers today will understand “person.store” and that there is no need for XML to make this work, when the framework automatically creates the schema from the model and attaches all CRUD operations as methods to it. As I wasn’t very knowledgeable with meta-programming of Ruby and still needed a lot to learn, from hindsight lines like

person = ObjectFactory.getFactory(Person).create

look crude and would be written as “person = Person.new” or “def person = new Person()” with current frameworks. The factory also shows my background with design patterns and Java at the time and shows
that I didn’t know how to do meta programming and attaching methods and fields without going through a factory. Other goals from 2003 in contrast sound familiar today:

Object Store: You do not have to write SQL queries. Objects can be stored, retrieved, found and changed. Relationships are automatically managed.

Beiing prophetic

And in the light of several current Ruby on Rails problems, some statements sound prophetic:

Where not to use Ruby.APP: Integration of legacy applications, integration of existing databases [...], mission critical systems. Ruby.APP will not try to solve *every* problem like some frameworks try. For ease of use Ruby.APP will sacrifice flexibility.

The GUI code was quite lean. Reading code like

<ro:table name="pTable"/>

conjures up similarities in current Java component frameworks and is still a good approach to component based web development. The listeners were not very lean though and could be optimized. Especially dependencies between components, say a comment field and a input field, had to be managed by hand.

Other parts of Ruby.APP just sound like Grails advertisements:

Integrated Database: By using Aruna, for a lot of projects there is no need for an external database. Ruby.APP works out of the box. Applications can be very easily reconfigured to use a SQL database, should the need arise. [...] Standalone application server: No need to install and administer Apache or IIS. Ruby.APP works without a webserver. This way Ruby.APP applications can be installed and used on desktops by ordinary users.

Why did it fail?

When everything was great, why didn’t Ruby.APP became the Ruby on Rails of 2003? There are several causes. I had no time for the framework, which resulted in no really useful release. There were very few Ruby developers back than and it was hard to rise interest in Ruby application frameworks. It was a Java world (it still is?). The window of opportunity wasn’t open yet, it later was for RoR. And last not least there was no success story. RoR had one, all could see that RoR can be used for real world applications. The success story came before RoR, not after RoR. Proof of success through existence. Today I write applications in Grails and Java. Who knows what would have happened if I had pushed Ruby.APP.

Thanks for listening.

Groovy and Grails User Group in Berlin?

After reading about new Groovy and Grails user groups around the world, I thought there might be Groovy and Grails users in Berlin. I would be interested in meeting to exchange ideas and experiences. Anyone interested?

Groovy, Grails and #IRC

Grails is a great project. I’m currently implementing a webish2.0 website and with Grails my implementation speed is very fast. What Groovy and Grails lack though, is a decent IRC channel. I’ve been on IRC for 15 years and IRC helped me through Java, Servlets, Python, Ruby, Delphi and other technologies. There is a #groovy channel on codehaus, but the core committers of Grails and Groovy are seldom there*.

I think a successfull IRC channel is essential to the success of an OSS project. So we need to push Groovy and Grails to IRC. For starters I’m on #groovy on freenode. Lot’s of OSS projects are on freenode and more people will join the channel there than on codehaus. Please help, join us.

* jez is the exception and always helpful ;-)

Groovy and IDEA, a mixed blessing [Updated]

I’ve been an Intellij IDEA user from the very, very beginning. I think we bought some of the first licenses. I’ve been promoting IDEA against Eclipse cultures for years. IDEA is the most usable IDE around. I’ve got several companies I worked for to buy IDEA although they are Eclipse shops. I got all people in the team I manage to use IDEA instead of Eclipse. I converted Eclipse users. I’m an evangelist. I love IDEA!

Now I’ve been working on Grails for some time, thinking about using it in a project and deciding if it’s better than JS for the task. And the Groovy support in IDEA is very very bad. The plugin is not from Intellij, but it reflects badly on them. So I have to decide if I should use Grails for the project, drop IDEA and move to Eclipse or drop Grails and stay with IDEA. Groovy with the current plugin is no option in the long run. Going to the forums on the IntelliJ site reveal lots of discouraging comments by IntelliJ employees. Groovy seems to have a much lower priority than Scala (very nice, but who uses it?), Ruby, Python and JS. And that although Groovy seems a natural choice for Java. When I, a long time IDEA user drop IDEA as a Java developer, they will lose a customer from their core group (Java developers) which sounds stupid from a marketing and sales point of view.

What a difficult choice, but currently I lean on dropping IDEA, after all those years. What can the Grails/Groovy community, the users and developers do to get better support from IntelliJ?

Update (see comments): “Actually right now the situation regarding Groovy support has changed, which you may have found out from recent forum posts. We are no longer actively developing the Scala plugin, and the team responsible for it is now working on a new Groovy plugin.”

Rails and Grails: A language shootout?

Following the benchmarking, I think it’s a very good idea from Graeme to stop benchmarking until Grails gets some optimizations. Currently performance should not be a big concern for the Grails developers. Keeping up the good work with implementing features and fixing bugs should stay their main concern.

When looking at the Grails versus Rails benchmarks, I thought this might be more about languages than web frameworks.


Rails: Ruby
Ruby: Ruby/C
MySQL: C
MySQL driver: C/Ruby
Mongrel: Ruby/C

Grails: Java/Groovy
Groovy: Java/Groovy
Java: Java/C
MySQL: C
MySQL driver: Java
Tomcat: Java


(Correct me if I’m wrong please)

It’s great news to me that for example mongrel is primary ruby. Some years ago when I did some projects with Ruby, a lot of stuff was written in C and needed to be compiled, which is always a lot of pain. Also the code looks quite good and clean. And they thought about performance:


# Does the majority of the IO processing.
# It has been written in Ruby using
# about 7 different IO processing strategies
# and no matter how it's done
# the performance just does not improve.
# It is currently carefully constructed
# to make sure that it gets the best possible
# performance [...]


Good to see.

So is this about Rails versus Grails or Ruby versus Groovy or C versus Java? But as I said in the beginning, I think it’s a very good idea from Graeme to stop benchmarking until Grails gets some optimizations

Why Grails instead of JRails

The JRuby team has accomplished an amazing thing, running Ruby on Rails with JRuby. So is Grails dead? No! Why should someone then use Grails and not JRuby on Rails? Ruby is a very nice and clean language, Rails has a lot of extensions and documentation. But Groovy is more similar to Java, like Java on steroids, is tighter integrated and has more appeal to Java developers. But to quote Oracle “at the end what you generate with Grails is a J2EE app, web container managed and deployed. You can manage it in the same way you manage any other J2EE app.” via InfoQ.

Update: I really like Ruby :-) I’ve written a Ruby OR Mapper called Ruby.RDO and a web framework called Ruby.RO more than 4 years ago which focused on ease of use and components (think tapestry).

Google trends proves: Java is doomed

Google trends is a nice idea, and I had to apply it adhoc to Java, Ruby, Python and C#. Interesting results, I can see a decline in Java! We’re doomed :-)

And the Rails evangelists jump in and present this. Probably people would search for that or even that because Rails mostly doesn’t find RoR though. All others ignore the quabble and use Jetty or Grails.

For fun try this.

Update: Searching for Web 2.0 creates a nice graph and close to my heart: wiki.

Grails 0.1 released

Grails 0.1 has been released. Congratulations to the team and thanks for the great support.

Weak versus strong languages, who wins the fight?

With all the buzz in scripting languages (again :-) often programming languages are divided into weak versus strong typed or dynamic versus static typed languages. I don’t know how often some of us have seen this discussion, the first time for me was when I had to argue with C++ developers because I wanted to use Python (and then did) for web/database development nearly then years ago (back then, Python had the first usable web/CGI interface).

Static versus dynamic

What does weak versus strong mean? This is based on the type system of the programming language. Languages where the type of references can change are usually called dynamic (weak), languages where the type of a reference is fixed are called static (strong). Take these two examples:


String name = "stephan";


and


def name = "stephan"


The first one is in Java and the second one is in Groovy. In the Java example a reference (variable) name is created. Then a data structure which contains stephan is created and assigned to the reference.

In the second example the same is done in Groovy. Where is the difference? Consider this:


String name = "stephan";
...
name = new Name("stephan");


and


def name = "stephan"
...
name = new Name("stephan")


The first example doesn’t work, but the second does. This is because Java is statically typed which means the reference is statically typed. A reference possesses a type, in this case String. A reference with type String can only point to data structures which contain data of type String. In Groovy the reference is dynamically typed. So the type of the reference can change from String to Name when the data which it points to changes.

Another example in Groovy:


String name = "stephan"


Hey, this is Java right? Didn’t I say, Groovy is dynamic not static typed? Yes, you’re right. But Groovy is more than this. Groovy is both dynamic and static. So the developer can choose a reference to be dynamic or static, just as needed.

Although categorizing languages into dynamic versus static (which the dynamic camp uses) describes languages better than weak versus strong (which the static camp uses), those categorizations are too simple to be useful, as seen already in the case of Groovy.

And there are at least two dimensions for typing, reference typing and data structure typing. In programming languages both references and data structures can be typed. This matrix divides languages between dynamic and static typed languages for references and for data structures.

Ruby, Python, Smalltalk and Java have all statically typed data structures (you could argue Ruby has dynamically typed data structures). But Ruby and Python use dynamic references while Java uses static references.

In the bottom right, there is C which has typed references but untyped data structures. And C doesn’t enforce that typed references point to the correct data structures (because those are not typed). C data structures can be typed by adding a type field to the structure and checking the type before any operations on the data structure. Some C developers did this for more reference safety.

Other languages are even more free. Javascript for example uses prototyping for object creation, not classes in the traditional way. Maps and objects do not differ in Javascript and are essentially the same. Javascript does not know methods but executable attributes are used as methods. Libraries like Prototype or Base extend Javascript with an inheritance based class system.

Some languages can change the data structures although the data structures are typed. In languages with Meta support (Ruby, Groovy, …) data structures can be changed, fields and methods can be added at runtime.

Scripting languages

I think there is more to this than the simple 2×2 matrix from above. Sometimes people use the terms dynamic and static, but mean scripting and compiled. What is scripting? Traditionally scripting languages were interpreted languages. In web devlopment scripting languages like Ruby and PHP make development easier. No compilation is needed and after changing your programm you can hit reload in the browser and see the new result. This way turn around times are minimized and development is speed up. But the line gets blurred. Scripting languages get virtual machines and are compiled to byte code for better performance. Java compiles to byte code which is interpreted. New Java VMs then don’t interpret all byte code but compile the byte code to native code on the fly and as needed. Also compiled languages like Java get new classloaders and containers which compile new source code to byte code on the fly. And VMs like the Java VM run new languages like Groovy which can be compiled on the fly. For example in the excellent Grails framework.

Functional languages

Some people use dynamic versus static and mean object oriented versus functional. Consider these two examples (taken from Cedric Beust):


List result = new ArrayList();
File f = new File(directory);
for (String fileName : f.list()) {
if (fileName.endsWith(".gz")) {
result.add(fileName);
}
}
Collections.sort(result, new Comparator() {
public int compare(String o1, String o2) {
return o2.compareTo(o1);
}
public boolean equals(Object o) {
return super.equals(o);
}
});


and


zippedFiles = Dir.new(dir).
entries.sort.reverse.delete_if { |x| ! (x =~ /gz$/) }


Both code fragments do the same thing which is sorting all zipped files in a directory.
The first is Java style object oriented (though this could be written shorter) and the second
is Ruby functional style. As can be seen, the second is easier to write, understand and
maintain. Especially in applications which have to deal with lots of lists functional programming makes code considerably shorter. Web applications often use lists (customers, projects, todo items) and so profit from languages which support functional style programming.

Conclusion

The whole discussion about dynamic and static languages is senseless. There are more dimensions which characterize a language than dynamic versus static. Scripting/compiled and functional/OO are other important things to consider. Languages like Groovy support object oriented and functional programming styles, can be used as a scripting language and compiled to byte code, support both dynamic and static typing of references and with meta programming capabilites support modifying static typed data structures.

I think there is still more to say about dynamic versus static. But this post needs to end here.

Who wins the fight? The is no fight, know your tools and use the best tool for the job. But at least the static/dynamic dimension is less usefull than it seams at first.