An IO time: Apache, OSJava and Groovy
April 18th, 2004 by HenI’ve had a fun few days of coding. Nothing big, but it feels good to do the code exercise.
First off, I’m porting a bash script at work to Groovy whenever the odd hour or two presents itself. It’s meant a lot of time on the Groovy IRC channel, which is very enjoyable and I’m quickly falling in love with Groovy. Implementation wise, the parser seems to have a fair few minor bugs, but the concept behind the language is good.
While I’ve not done much with PNuts and Beanshell, other scripting languages are hard for me to work with a lot as they are not a part of the Java community. So despite liking Perl, Python and Ruby, and having read quite a bit about them [in fact, I learnt Perl just before Java in 98 and use it constantly], they’ve never fit with my Java work. Groovy however is from the Java community and feels right.
I get the feeling that many are using Groovy as a Java replacement, with a few using it as an embedded language. Well, that’s not for me. I plan to use Groovy as a scripting language. Many of the classes I write will be in Java, because it’s more mature for me. One of the problems I’ve hit is that there is not much file level support. ‘zip -r’, ‘find’, ‘perl -pi -e’, ‘rm -r’ etc. So I’m now working on adding that.
First stop. OSJava’s GenJava/gj-core. This is my personal utility package and contains a find implementation from a while back. Nothing fancy in terms of options. So the weekends work has been to make it fancy in terms of options. Basically a complete rewrite. It’s not all tested yet, but all relevant UNIX find options have been added. It’s also very useful from the Java side, you can attach a listener to the find ‘command’ and get at the results sooner.
At the same time, I’ve had to implement wildcard functionality. Also quite fun to do. Now I have WildcardUtils.match(String text, String wildcard).
Next step here is to finish testing, then break it out as gj-find, a separate sub-project to gj-core. I quite like this approach and half think Jakarta Commons should try the same thing. A chaotic single project that releases a large entity, then spawns tighter, smaller components.
Speaking of which. Commons IO 1.0 RC1 is now available in www.apache.org/~bayard/io/. It’s much overdue, and my failure to get it moving has been holding it up. Any opinions are welcome, either to my email or if you’re on commons-user or commons-dev, to those lists.
Commons IO 1.1 would hopefully contain the gj-find stuff, so if that moves quickly I may not even break it out.
The end result will, I hope, be for Groovy to depend on commons-io (?) and to have something seriously sweet like:
find( directory, { "DEPTH" : "true" } ) { f | f.delete() }
Admittedly, a file.recursiveDelete should exist, but the above is sweet, sweet scripting. How about:
find( directory ) { f | f.replace(repl, with) }
None of it legal Groovy yet, but hopefully someday.