techno.blog("Dion")

Wow it keeps on coming (and ironically I am adding to it). This last slew of postings on Rails vs. Java came after Patrick Peak Rails: Where are the Implications for “No Deploying”?.

As soon as that came out we saw:

• Dave Thomas: Rails and FUD
• DHH: Letting cooler minds prevail
• Jamis Buck: Application Deployment with Rails
• James Duncan Davidson: Rails: Sandbox, Develop, and Deploy
• Patrick Lightbody: It’s the tools, stupid!

The funny thing is that it is hard to know what we are really arguing about :)

Scalability

Can Rails scale? Sure. As Brian McCallister just said, scalability isn’t about a particular language.

Do the different languages/platforms give you different implementation choices for scaling? Sure. Scaling with FCGI clusters is different to using Tangosol Coherence in a J2EE cluster.

In some ways it is much simpler to scale a web app with shared nothing. However, on really huge enterprise systems (not web apps), tools *like* Coherence really help you out. It is nice to have the many levels and buttons available in your architecture.

Again, Slashdot? Scales like a champ with Perl. There are a lot of huge enterprise Java systems that take in billions of transactions.

So, conclusion? You can make both scale. You can make both run like a dog :)

Tools

Patrick has some good points in his post. I am not sure if he has checked out Textmate for doing Ruby development. It is quite nice indeed, although I do miss IDEA for some things (can’t beat its refactoring etc).

With Ruby you really don’t need as MUCH tooling though. It is a nice concise language which doesn’t need as much scaffolding in the tools area. You can be very productive with Ruby – IDEA.

However, IDEA really does do a good job of getting you closer to the productivity. I notice this a lot in Groovy world, and I am excited about GroovyJ.

Tool support is only one leg on the chair though. There are many other components that matter as much, more-so, and maybe not as much.

Refresh, Reload

Tools can help get around the dev cycle that we have in Java, but we aren’t there yet. Patrick is correct in spotting the potential with dynamic languages on the JVM, where we could get the best of both. But we aren’t quite there yet.

It is painful to jump to the Java world once you are used to hitting SAVE and refresh for every type of change (we can get far w/ JSP, etc etc).

Both are beautiful, both can be ugly

I love both platforms in many ways. I don’t like both platforms in others.

• Java Dion: I wish we had the Ruby language on the JVM.
• Ruby Dion: I wish Ruby had a nice VM to run on (the JVM would be really nice).

Or maybe I will just do everything in JavaScript 2.0? ;)

Oh, and David Geary had too much caffeine at the Rails Cafe? :)

You work all night and finish off your lovely application for the meeting the following day. You check and re-check your application and it works like a champ. You are feeling good about the demo.

Then you get to the office where you are giving the demo, and spend time configuring your browser so you can get through the lovely corporate proxy/firewall. Always a pleasure.

Then you bring your app up, and all of a sudden you get a stacktrace that could reach to the moon and back, and at the heart of it you see:

org.springframework.beans.factory.BeanDefinitionStoreException: IOException parsing XML document from URL [jar:file:/C:/servers/tomcat/webapps/your-app/WEB-INF/lib/jsf-spring.jar!/META-INF/faces-config.xml]; nested exception is java.net.ConnectException: Connection timed out: connect
at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.loadBeanDefinitions(XmlBeanDefinitionReader.java:139)

Er. Huh?

The faces-config.xml looks good in there. Everything seems fine.

You then look deeper into the message of stacktraces from Tomcat, and you find a bunch of connection errors. Hmm, what kind of connection?

After awhile you realise that this is ALL due to Digester, using Xerces, and VALIDATING the damn XML.

So the errors are due to loading the faces-config which has the DTD:

<!DOCTYPE faces-config PUBLIC
“-//Sun Microsystems, Inc.//DTD JavaServer Faces Config 1.1//EN”
“http://java.sun.com/dtd/web-facesconfig_1_1.dtd”>

You can try to turn off the validation, or just through in your proxy info to Tomcat:

-Dhttp.proxyHost=extproxy -Dhttp.proxyPort=80

Now, just 2 hours later, you are ready to give your demo :)

Ruby on Rails and J2EE: Is there room for both? is the title of a new article that tries to give a sober view of a Struts-based J2EE web stack, compared to Rails.

What is interesting about this article? It isn’t the content, it is the fact that this article is written.

Where was the “Seaside vs. Spring MVC” article? :)

I think there have really only been the following comparison articles done:

• Various Java Frameworks (Struts vs. JSF vs. Tapestry vs. WebWork vs. …)
• J2EE vs. .NET
• and now Rails vs. J2EE

Having it on developerWorks shows that they think Java guys care too. I think the Java camp is polarised with extremes of “Rail looks great” and “Man can I NOT hear about Rails for a day and talk about Java?”.

I liked reading the Java Specialists’ Newsletter from Heinz.

An interesting statement is this: “ArrayList is faster than LinkedList, except when you remove an element from the middle of the list.” I have heard this on more than one occasion, and a few months ago, decided to try out how true that statement really was.

How many Java developers actually test the affect that a particular collection type would have on the performance? I would be willing ~0.01%.

Heinz goes on to benchmark both lists working at the beginning, middle, and end of sample lists:

beginning ArrayList took 4346
beginning LinkedList took 0
middle ArrayList took 2104
middle LinkedList took 26728
end ArrayList took 731
end LinkedList took 1242

And the conclusion is hilarious:

So, when should you use LinkedList? For a long list that works as a FIFO queue, the LinkedList should be faster than the ArrayList. However, even faster is the ArrayBlockingQueue or the CircularArrayList that I wrote a few years ago. The answer is probably “never”.

A cool tool would be one that goes through and tests various Lists in your live code. AOP could wrap around the creation and inject different versions ;)

Of course, this would only be used AFTER we found that the Collection was a bottleneck. Who would optimize prematurely? :)

There has been a big rush in non-Rails based communities to see what they can learn from that world, and if it makes sense to port any ideas over.

Thomas Risberg has started to port over ActiveRecord to a project called ActiveMapper which sits a-top of JdbcTemplate.

It has been interesting to see the two sides:

• Lets tweak our frameworks to use smart defaults
• Lets do code-gen to generate artifacts on our frameworks
• Lets write a new framework / port something from Rails

We all knew it was coming :)

Stu Halloway is a wise, wise man :) Even though I read about Growl in Pragmatic Automation, I didn’t think anything of it, until Stu re-introduced it to me this weekend.

For those that don’t know about it, Growl is an open source service for the Mac, which gives you a nice standard way to define user alerts. To start with, on the Windows side, think of the system tray fade away alerts that you get with IM tools, email, and the like.

However, wouldn’t it be nice to NOT reinvent that wheel in every application. Growl gives you the flexibility to do just this. Apps can send messages to Growl, and users can determine how much they care about them, and the look and feel for these alerts (e.g. colors, where on the screen, even items such as “read it”).

This is only the beginning though. If you take this to the next level, Growl can tie into external items. Have a text message sent, an email, a message to a MOM queue, and lighting up a lava lamp (Mike Clark talks about setting up build alerts).

I would love to see a Windows based version of Growl (and other OSes), and have them builtin to the OS’es. We should have one way to access this guy (sending messages to the service), and it would work everywhere. We could even have a JSR ;)

If you want to get all aspecty, you could write aspects that tie into various application code, and inject in these alerts.

Very cool stuff Stu! Growl joins my “I wish it was on Windows list”, sitting next to QuickSilver :)

Howard Lewis Ship is another on the list of “frustrated with generics”.

I totally agree. If we were going to REALLY go generic, then we should have bite the bullet and made all of the changes, especially so we didn’t have runtime erasure.

As someone said, all you need to do is look at the JavaDoc and see something like:

public abstract class Enum<E extends Enum<E>>

Greeeeat. Explain that to the average Java Joe.

We get compile time checking, and we make everything thrice as complicated in the mix. Is that good? Seeing Map<String> looks good and all, and then you get into writing generic code and you scream.

I am getting to play with Hibernate 3, and they have done a nice job. I was poking around the Caveat Emptor example from Hibernate in Action, which was updated for Hibernate3.

I happened across this file: package-info.java:

@TypeDefs({
@TypeDef(
name="monetary_amount_usd",
typeClass = MonetaryAmountType.class,
parameters = { @Parameter(name="convertTo", value="USD") }
),
@TypeDef(
name="monetary_amount_eur",
typeClass = MonetaryAmountType.class,
parameters = { @Parameter(name="convertTo", value="EUR") }
),
@TypeDef(
name="item_state",
typeClass = EnumUserType.class,
parameters = { @Parameter(name="enumClassName", value="org.hibernate.ce.auction.model.ItemState") }
),

@TypeDef(
name="creditcard_type",
typeClass = EnumUserType.class,
parameters = { @Parameter(name="enumClassName", value="org.hibernate.ce.auction.model.CreditCardType") }
),
@TypeDef(
name="rating",
typeClass = EnumUserType.class,
parameters = { @Parameter(name="enumClassName", value="org.hibernate.ce.auction.model.Rating") }
)
})

@NamedQueries({
@NamedQuery(
name="minBid",
queryString="select b from Bid b where b.amount.value = (select min(b.amount.value) from Bid b where b.item.id = :itemid)"
),
@NamedQuery(
name="maxBid",
queryString="select b from Bid b where b.amount.value = (select max(b.amount.value) from Bid b where b.item.id = :itemid)"
)
})

package org.hibernate.ce.auction.persistence;

import org.hibernate.annotations.*;
import javax.persistence.*;

Is this better than XML? To have this code sucked in?

NOTE: You don’t have to use the annotations of course.

SourceLabs has released a search engine called Swik which is:

Swik brings together concepts from wikipedia, delicious, and blogs to provide a service that is both open and structured.

More and more services are popping up to help out in this area, such as O’Reillys CodeZoo, and the interactive JDocs.

The fact that it is a wiki is interesting, and the tagging makes a lot of sense. As always, there are pros and cons to the “wiki” effect.

It is also good to see that “ajax” is a top term ;)

The term “lightweight container” has been en-vogue for a few years now (roughly since Pico/Spring came about). At first it kinda made sense, as they did seem tiny little containers compared to the big beasts WebLogic/WebSphere.

However, I think that the term is actually completely the wrong one. This thought came about as people have been saying:

“Spring is far from a lightweight container. Look at how much crap is available for you! Web/DAO/IoC/TX/AOP/RCP/JMX/Portal/WebFlow…. call that lightweight!!!”

It is true that Spring now has a lot of functionality available in its core, and a ton more hidden in the sandbox.

To me, the point is that Spring lets you apply lightweight development. I don’t need my container to be 10kb for enterprise development, and just be an IoC container. I actually WANT my enterprise container to be able to do the HEAVY lifting, allowing ‘lil ‘ole me to write in a lightweight, POJO based model.

So, I no longer think lightweight container. I think lightweight development.

I hope Spring keeps putting on the pounds as it makes more and more aspects of our development easier.

EJB 3 is a perfect example

EJB 3 is not a more lightweight container. They have just fixed the programming model, but the guts are exactly the same! People didn’t complain about the fact that EJB could grok TX automatically for us, they hated the programming model (Bean/Home/Remote interface etc etc etc).

I agree that EJB 3 is going in the correct direction, in that it is making our development simpler, and POJO based. We have to be careful with what we put in annotations though. I hate to see items like SQL hard coded in there, and ending up with a munge of the XML descriptors right in the bean.

Some items should be annotation driven. Others deserve to be external. Deployment is a big issue for large enterprises, and we need to have lightweight deployment too!