Hi Mike,
The issue of static vs dynamic typing is important in the IDE and arguably important in general. Sometimes new Groovy developers are like kids leaving for college after growing up in a restrictive environment, using def everywhere just because they can. As they gain more experience, Groovy coders tend to use def less and less.
Dierk Koenig, lead author on _Groovy in Action_, had the best quote on that I've seen. He says, "if I'm coding and I think of a type, I type it (pun intended)." In other words, if he knows the reference is going to be a
String, or a Date, or an Employee, he puts in the static type rather than saying def. In that sense, Groovy is said to be optionally typed.
The def keyword is useful for
testing, because if I want to create a mock object and the resource I'm mocking uses a def reference, I can set it to anything I like and rely on duck typing to provide the correct methods. If the reference is a File, though, I can only substitute in Files (or subclasses of File).
You will often find def used as a return type on methods. For example, in Grails controllers, by default each action (which is what Grails calls its methods) uses def as a return type, because it may return something, or do a redirect, or do a forward. Using def keeps its options open.
Of course, using actual types makes IDEs happier, and the Groovy plugin for Eclipse has improved by leaps and bounds over the last couple of years. IntelliJ IDEA is usually better, though.
You raised two other issues:
1. The list of automatic imports in Groovy is java.lang, java.util, java.io, java.net, java.math.BigInteger, java.math.BigDecimal, groovy.lang, and groovy.util. I agree that Java ought to do that too, but so be it.
2. Java is good for tools, libraries, and basic infrastructure. Those tools prefer Java interfaces, too, so one easy integration technique is to use Java for interfaces but implement them in Groovy. That makes the Java tools happy, while also keeping the developers happy.
Ken
