The Groovy language is capable of reaching to the far corners of the Java space, it even managed to catch the attention of developers from the land of the Rising Sun: Japan. Yasuharu Nakano is a well known member of the JGGUG (Japan Groovy and Grails User Group) and co-author of GroovyServ. If you're daily work relates to running Groovy scripts periodically you owe to yourself to have a look at GroovyServ. Enjoy!
Andres Almiray: Could you please introduce yourself
Yasuharu Nakano: My name is Yasuharu Nakano and I live in Japan. I always use "nobeans" as my handle but I love all kind of beans ;-)
I work for NTT Software Corporation, which is a system integrator in Japan. We offer advanced ICT (information and communication technology) solutions to enhance the competitive edge of enterprises. Yeah, I confess this is a copy from my company website! My responsibilities at work are technical support and training for my colleagues. Additionally the development of OSS products, like GroovyServ.
Andres: How did you get into Groovy?
Yasuharu: Junji Uehara who is my senior colleague have been so crazy about Groovy. He is surely one of the "early adopters" of Groovy in Japan. And now, he is a committee member of the JGGUG (Japan Grails/Groovy User Group) and the author of the sample of Japanese DSL using GEP 3 which was quoted at the release notes for Groovy 1.8, and the author of the LispBuilder. He is also a committer on the GroovyServ project.
When I moved to his team 3 years ago, he talked and talked to me about how excellent and useful Groovy was. Since then I've gradually learned Groovy and have been using it for various purposes. Of course, now I understand why he talked so much about it.
Andres: You’re the author of GroovyServ. What prompted you to start the project?
Yasuharu: Uehara and I thought that "our organization should not use various OSS products only as a free rider but it should contribute something to the communities in a positive way." So, having secured approval from our understanding boss, we've started up the "Kobo Project" and tried to develop something that could contribute back to the Groovy community. GroovyServ which was born from Uehara's idea is one of the results of this initiative. Fortunately, it seems GroovyServ makes somebody happy out there, so we're happy too. [Ed: Hamlet D’Arcy is quite happy with it, so thank you!]
Andres: What excites you the most about GroovyServ?
Yasuharu: It's just a helpful tool to speed up the startup of script execution. That's all. It's very important for a programmer who writes a script for every task all the time, like me. Groovy is powerful and useful and easy to use. But performance is a problem. Certainly, it has been improving gradually by each release, but for example compared with Ruby, it's never enough. Regularly it takes at least 1 or more seconds to invoke a script. The rhythm of development degrades as time passes. [Ed: the problem is the cold startup of a JVM instance.]
GroovyServ helps you under such a situation by keeping a JVM running in the background. You can program at your own rhythm. In GroovyServ, certainly, there are some restrictions and some different behaviors from Groovy. But for over 80% of my uses, it's good enough for me. How about you?
Andres: You mentioned other Open Source contributions besides GroovyServ. Are any of those publicly available today?
Yasuharu: Yeah, it's Kobo-commons. It's also the OSS product of the Kobo Project. Kobo-commons is a set of helper libraries for Groovy, containing a supplement of standard API, a proposal of new features and so on. We hope that these features will be eventually merged with Groovy or influence it in a positive way.
As a result, the String#tr method which has been merged in Groovy 1.7.3 is a graduate from Kobo-commons. And I heard that @EqualsAndHashCode AST transformation, etc. which were released in Groovy 1.8, were inspired by Kobo-commons and others. We're so happy. Thank you, Paul!
Though it's not the related to Kobo project, there is my GExcelAPI too. It's a helper library that extends ApachePOI (not to be confused with JExcelAPI!) by using Groovy. It makes handling of Excel files much easier, compared with direct use of Apache POI. For example, you can access a cell by using its label directly (like "A1"). It's very intuitive and user friendly, compared to using row and column indexes. Both are already available at Github. Please check them out!
Andres: What features can we expect in future releases of GroovyServ?
Yasuharu: At the point of view in the short term, I'll try to implement better support for Windows and an improvement over how threads and connections are handled. If you have other expectations, please create an issue at project page. In the future, I hope that Groovy and GroovyServ will be merged or the relationship between them become closer.
Andres: Do you make use of other Groovy related projects (Grails, Griffon, Gradle, Spock, etc)?
Yasuharu: Sure! I love Grails. Uehara and I have lectured at a Groovy & Grails training seminar for our colleagues. The power of Grails is quite enough for my needs. Actually there are some cases using Grails for our customers’ requirements. The task of translating Grails' documentation to Japanese has been started on a voluntary basis. From now on, I expect that cases using Grails in Japan to become more widespread.
Then I think Gradle is the most powerful build tool. It can build a project including Groovy code very easily. Even when I want to do something complex for my special individual requirement, I can write Groovy code as I want. It's very flexible and powerful. Japanese transaltion of the Gradle documentation is in progress too!
Of course, I'm also watching Griffon! To tell the truth, my field is server side technology, so I can't make use of it well yet. But I introduced Griffon’s FxBuilder at the JavaFX.jp and Glassfish.jp conferences.
Andres: What would you like to see in a future release of the Groovy language?
Yasuharu: I'd like to see the support of all operator overloading, the Scala-like pattern-match, and if possible, the built-in GroovyServ mode.
Andres: Could you elaborate a bit further on operator overloading? Groovy already supports a set of operators that can be overloaded via a method naming convention. What’s missing from your perspective?
Yasuharu: Yes, of course, I know the Groovy's operator overloading feature, and it's my favorite. But the "all operator overloading" which I mentioned is about the currently unsupported operators. Especially, I want an overloadable range operator. I think it's useful in order to create a list as a range for a special object, for example, like the cell range of GExcelAPI. The similar issue has been already created on Groovy's JIRA. (http://jira.codehaus.org/browse/GROOVY-1889)
Andres: How’s the community reaction to JGGUG? Does the group organize hackathons?
Yasuharu: Once every one or two months, JGGUG holds a workshop where some speakers talk about Groovy or related technologies. I think it's pretty popular for people who have interest in learning Groovy in Japan. So far, Paul King who is the Groovy committer, Kousuke Kawaguchi who is the lead of Jenkins, and so on have talked at the workshop as a special guests.
Also JGGUG holds the development camp at an accommodation where there is a hot spring every year.
Last year an online event named "g100pon" was held in benefit of those who couldn’t take part in the camp. For g100pon (whose title was obtained from a training method of Budo) both the camp participants and the online members on the Internet created Groovy programs and scripts for the 100 topics that were prepared specially for this event. You can see the results by searching gists with keyword "g100pon" on Github.
Andres: How do you keep in touch with Groovy news and community?
Yasuharu: I'm almost checking the latest news of Groovy via Twitter. Sometimes reading the mailing lists. I'm not good at English so it's difficult to read many complex sentences in English... If I find a bug or an improvement point, I use JIRA.
Andres: What's on your reading table right now?
Yasuharu: There are the high stack of books and ebooks behind me. But now on the reading table I have "Domain Driven Design" and iPad2! Both are very interesting!
Andres: Any parting thoughts you may want to share?
Yasuharu: Ok. If the performance problem of the script on the JVM is confusing you, I want you to try GroovyServ. Even if your programming language isn't Groovy, GroovyServ may help you. Try it and enjoy! And then, send me your feedback!
Thank you Yasuharu!
Yasuharu posts regularly to his twitter account under the name @nobeans.