Igor's Blog

Well, I don’t believe so. However, the JVM could have some chances. Let me step back a little after such a flaming introduction and present various and mostly unrelated points.

What is all about?

As many others in my situation for the last year or so, I have been working in the world of Java but daydreamed about exciting and shining worlds like Ruby or its enjoyable "resort" Ruby on Rails. Although I have some issues with some of the perception in that new world, most of the innovations started happing there because of the Rails explosion.

...is there any hope?

Looking more and more in my old world, I started realizing that I, as well as many others would not be able to escape from it, at least not any time soon. Enterprise software development is more about politics and questionable higher level decisions than real values, passion about what you are doing and ability to "get real".

...alternatives?

WOA, REST and “are web services become a web services again” look promisingly exciting. It is not so much about language and technologies, it is about new way of thinking, designing and using systems. Sure, there a lot of interesting innovation there, but most of it is overtaken by extremely complex specification and vendor implementation of “enterprise” tools and frameworks for generating unmanageable code that doesn’t work as expected.

… actually, it is even worse...

Although there are some important battles that could be won, the overall war with the “old enterprise world” is not going well. The hope is fading away even faster if we combine the application world (stand alone applications) with the integration (service oriented) world where the wide spread opinion is that we need even more vendor tools that solve magically all our problems.

...!?!?!?!?!?!?!?!?!

Well, the Ruby and ROR outburst was big and definitely started a (r)evolution:
From a blog comment:

“Java community was so tied up with doing things the 'right' way. People won't change their way of thinking before something else comes up which shows them otherwise. So thanks to RoR for opening some blind eyes in the conservative community.”

However, Java enterprise world has grown too much to be overthrown too easily or fast enough. What is more, Ruby/Rails is a (r)evolution but it is still not powerful enough:

- “My pet peeves with Rails were the same like most other people back then: i18n, oracle support, integration with web servers wasn't as simple as deploying a WAR file.”

- From Rails performance tuning presentation:

“Ruby interpreter is sloooow:
Deeply rooted in 60’s technology:
• no byte code, no JIT, interprets ASTs directly
• doesn’t perform any code optimization at compile time
• GC performance is erratic

Ruby’s GC collects and is garbage!
Designed for batch scripts, not long running server apps
• tries to minimize memory usage
• simple mark and sweep algorithm
• uses malloc to manage contiguous blocks of Ruby objects”

- From “Ruby threads are week":

• slow as hell, threads tend to die unexpectedly
• documentation and sample code limited to a handful of pages in the Pickaxe (lack of people using should have been clue #1)
• non-OO (in Ruby! an int in Ruby is an object!), all examples use code blocks, subclassing Thread can have unexpected (to me, with my Java threading biases)
results
•many core libraries, and more painfully (in that I lost several weeks of my life, and some hair) ActiveRecord aren't thread safe.”

(Well, Hibernate session is not thread safe either but this is different story.)

While Ruby/Rails hit Java very badly (C# as well to some degree but rapidly increasing the pressure with C#-3), the JVM is holding almost indestructibly against Ruby VM and doing pretty well against CRL as well.

So, if Java/JVM world is still sustaining big hits from outside (even from .NET these days) can it sustain a (r)evolution from inside?

...wakening the sleeping giant.

“In many respects Groovy is the best combination of the Java platform and dynamic language design. Groovy has been quiet, but like a sleeping giant Groovy will awaken and effectively take over as the dominate dynamic programming language…..”

I omitted the last part of the sentence “…after it becomes a JCP standard.” because I disagree with that part. Although JCP standard could help with the adoption from the conservative corporate/enterprise world I think that standards can actually make Groovy worse. Anyway, it sounds exciting. Let see more.

Groovy: The Sleeping Giant, an Elaboration

At first look, Groovy looked to me as Ruby without the Perl with obvious Java perception.
Sounds very attractive to me so let me take deeper look into the language:

Mix and match - interfacing with java and using the enormous amount of Java APIs and libraries directly.

“But, it is there where Groovy's true strength lies in its ability to cleanly interface with Java.” Basically, we can use existing java classless dynamically, test or extend them directly in Groovy. This is one of the best features in Groovy. We can introduce Groovy incrementally on old/new projects or just for specific tasks like configuration, tests and so on. Actually, test are very compelling candidate to be written in Groovy:

- faster feedback (removing the compilation step)
- test code doesn’t have the same strict requirements as the application source code.
- much more productive when doing exploratory testing or scripting behavior specifications of a system.
- writing test in DSL is very appealing.

Another good feature here is the ability to extend interfaces. It is kind of nonsense for a dynamic language but it is very beneficial to provide Groovy implementation of existing Java interface and use the Groovy implementation in the java code.

Ability to create DSLs with Groovy.

“In addition there are other, largely undocumented, reasons why Groovy has huge amounts of potential:

Meta-programming - Groovy has the ability to inject methods, constructors, properties, fields, etc. into ANY java class at runtime. Most of what AOP is used for nowadays can be achieved with Groovy's Meta-programming capability. No byte-code manipulation a la AspectJ, this is awesomely powerful and in combination with Groovy's support for closures and builders it makes it possibly to create mini-DSLs

Power Features - Although there has been a lot of argument about the optional parenthesis, and the optional semi-colons etc. There are very good reasons for these things being optional: For combining closures and method calls to allow builder syntax. Builders and closures are very powerful, especially when you consider you can pass the same closure to a multiple different builders. Why you say? Well one may output a tree structure as XML another might render a GUI from it, I'll leave the rest to your imagination.”

“… the rest to your imagination”. Ruby does have similar features, but this is one of the first things that I looked for in Groovy. Ability to create DSLs is actually the real power of Ruby and it looks that Groovy can do it too.

... is that all?

Of course not, but these are the most compelling features that made me look even deeper into the language. There is a lot more at the Groovy web site. Especially impressive (at least for a Java guy) are:
- Grails Object Relational Mapping (GORM)
- Groovy SQL
- GPath
- Groovy Markup
- Groovy SOAP

This is it!

I feel very excited and I think I like the name Groovy a lot. I am going to play around with Grovy. The most obvious choice is to start with Quick Start from Grails framework.

Grails is inspired by Ruby on Rails and built with Groovy. From the Grails presentations:

Why Groovy?
- Meta-Programming
- Closure Support
- Syntactically Expressive
- Java Integration

Built on very compelling and solid foundation:
- Spring IoC, MVC and WebFlow
- Hibernate
- SiteMesh

Are you familiar with these frameworks? Me too!

When working with Grails, you don’t understand that these frameworks are there but if you want more flexibility (configuration), you can always use them directly.

The reality...

Downloaded the framework, set up a home variable and I am ready to go.

… the build.

Positives:
- It is working as expected (as in RoR).
> grails create-app

create-app:

[input] Enter application name:

Negatives:
- Ant! This was great a few years ago but it is now clear that xml is not the best way to write build files. Groovy could’ve eaten its own dog food and create something similar to Rake (probably something like GrAnt!? It is not too late though.).

- I can’t specify the name of the application directly instead, I have to wait to enter it.

... the domain. Oooh, this could take a while.

Positives:
1. I can optionally define property types in a domain class:

class Book {
@Property Long id
@Property Long version
@Property String title
@Property String author
}

The @Property thing is not the best way to do it but I can live with that when I have the options to define types for domain object properties.

Why the option to define Types is so important to me?
This is something that is not possible in Ruby and it is interesting to explore whether it could be beneficial in Groovy in some way.

1.1.) Domain Driven Design

This allows frameworks like Grails to use an approach where everything is driven by the application - you create the domain class first and then Grails will create the different database objects.

This is absolutely the opposite of the RoR approach where you are leveraging an existing database object and creating the domain class on top of it. One of the reasons is that you can’t optionally specify types in Ruby. Since the current relation databases work with types, the only choice is to go from the stricter to the more loosely couple system, or db-to-ruby. Well, this is an issue only if you don’t fill comfortable defining your domain model in a database schema.

It is still an issue at least for me but I believe that the second point is relevant for almost everybody.

1.2.) Powerfull IDEs and refactoring

“The fact remains there are still huge benefits to compiled languages such as Java especially in large systems where the benefit of refactoring and powerful IDEs becomes clear.”

I am not very sure for the compiled languages but the refactoring and powerful IDE do matter enormously. Unfortunately, you have to give up on this for dynamic languages. There is really impressive progress with IDE’s like RedRails. However, the dynamic nature of the language constraints a lot what such IDEs can do. The problem is that a tool or many times, even a person can’t figure out what is the type of a variable.
Example:

class Song{
length
name
author
}

Is the “length” a string or an integer? Is the name a string or is a type Name? Many times, you don’t need to know but some times it would’ve been nice to know. What about if you can mix statically typed with dynamically typed? What about if we have the option to specify a type if we feel like doing it? Do we get the best from the both worlds? I don’t know but we can do that in Groovy:

class Song{
Integer length
String name
Author author
}

The option to declare the type (at least in our domain objects) can bring the power of IDEs (refactoring, auto completion and so on…) into dynamic languages.

2. Domain objects don’t extend any base framework object.

Positives:

This one is so obvious by itself that I am not sure what to add more.

Negatives:

2.1.) Grails generated toString, hashCode and equals method as well as id and version property. The method basically uses only the id property in an object.
This is good to have but the problem with generation is that you have to maintain afterwards and usually this is clear indicator of typical code smells. Let say that I generate 20 domain objects, all of them has the same three generated method as well as id and version property. Let say I use a lot of caching and I have problems with stale data and uniqueness of objects. I see the version property in the objects and decide that the id plus the version number define the uniqueness of an object. Oh, boy… I have to go and copy and paste the three methods with included version property to all 20 classes.

One way to refactor this is to have base object, something like “IdentifiableObject” where we can define the id and version property as well as the three methods defined above. I know that the framework creators don’t want to create bad association with having base objects but the difference here is that the base object is not part of a framework.

Having a base object like that could be beneficial in situation (I have encountered very often) when you want to perform an operation to all entity objects (identifiable objects) and disregard the value objects (entity and value definition according to Domain Driven Design book).

2.2.) Another negative was that there was a unit test generated but it was empty. I didn’t see test for the three generated methods mentioned above!?

controllers:

Is there anything to be said after I saw this?

class BookController {
@Property scaffold = true
}

which auto-generated at runtime the necessary actions and views:
• list
• show
• edit
• delete
• create
• save
• update

I don’t know if you spotted but the controller again doesn’t need to extend a framework base class. Good to mention here that you can inject services in the controller (through Spring although you don’t understand this) just with using naming conventions.

view.

The view is similar to RoR but without the scripting code inside. Everything is a proper xml which is very nice. On a different topic, I would much prefer something like Google Web Toolkit at this point but this is different story.

….conclusion.

There are lots of nice things in Groovy or Grails but there are many not so nice too. A short list (but very critical) includes: not very good error messages, currently not debugging support, not IDE support (…yes, there is something there but at least for Eclipse the plugging is far for even reasonable solution).

All these issues could be resolved but the biggest issue for me is that there is still no well defined community with clear vision and commitment behind Groovy. One example is that I tried to look for mixins in Groovy (a very important feature for me) but the only thing that I found is a proposal to include them in the language and nothing else.

Despite that and the fact that some frameworks integrate already with Groovy including Spring 2.0, RIFE, NanoContainer, and Drool, I am cautiously optimistic about Groovy and Grails and I will continue my further exploration.

For the two people left that still reading this long post, do you file like Grooving?

I was reading: http://jroller.com/page/peter_pilgrim?entry=my_javaone_2006_conference_second1

where Rod Johnson was quoted:

“It is possible to write unit test for applications in J2EE that run under five minutes. If your unit test take place longer than this, then it is wrong.”

I little more relax time is stated in Martin Fowler's Continuous Integration article:

“For most projects, however, the XP guideline of a ten minute build is perfectly within reason. Most of our modern projects achieve this. It's worth putting in concentrated effort to make it happen, because every minute you reduce off the build time is a minute saved for each developer every time they commit. Since CI demands frequent commits, this adds up to a lot of time. “

I completely agree with both of them although I would prefer the five minute constrain. Slow builds could have huge impact on the productivity of an Agile/XP team. Some of the reasons for slow build times are if we use database fixtures (as the accepted practices in RoR) or if we don’t bother to use stabs/mocks when appropriate in our test. All of that could be disregarded by many as unnecessary complication but from my previous experience on various projects using db fixtures or not using stabs/mocks have been an issue at some point or another.

An example is the fact that the build for my current project that has been continuing for the last year and a half, on average 6-8 developers, more that 1000 classes, about 100 domain objects with up to 83% unit test coverage (at times :-)) is taking just a little more that 4 min and about 1 min of that is xdoclet generation. The real time is 3 min!!! It is not even a pure unit test build. Our build includes testing the persistence for all domain objects with the database that would be in production as well as the instantiation of Spring IoC container inside the unit tests.

In the beginning we didn’t use stubs/mocks and everything was “freely” accessing the database. After the second month of the project, the build (probably about 20-25% of the current size of the project) was taking already more than 4 min! I have seen/heard about many projects where the unit test build is taking from 30 -1.30 min. I strongly believe that built times like that are unacceptable for an XP team.

I haven’t had the chance to use RoR on something more than a personal learning projects and I wonder how much time is a build taking on an average enterprise project using RoR or how do you overcome this potential problem in RoR projects?