Practically Groovy: Get Groovy with JDBC programming

Discussions

News: Practically Groovy: Get Groovy with JDBC programming

  1. Development is distinctively breezy with Groovy, and its lightweight syntax can alleviate some of the verbosity of JDBC in Java. This article in the Practically Groovy series discusses GroovySql to build a simple data-reporting application. GroovySql combines closures and iterators to shift the burden of resource management from you to the Groovy framework itself.

    Read the article: Practically Groovy: JDBC programming with Groovy.

    Other articles in the Groovy series:

    Practically Groovy: Ant scripting with Groovy

    Practically Groovy: Unit test your Java code faster with Groovy

    Threaded Messages (13)

  2. Development is distinctively breezy with Groovy, and its lightweight syntax can alleviate some of the verbosity of JDBC in Java.

    So I thought. Some months ago I thought it would be a good idea to have parts of my code as scripts which could be easily altered to cope with changing requirements. I soon hit problems with Groovy - the main site seemed to have a lack of full examples and documentation of how exactly to use groovy + sql (I managed to get something going by looking at the groovy source). When I tried to embed Groovy scripts that ran fine stand-alone in my Java code, I ended up with inexplicable 'Invalid Index' exceptions. And finally, I'm a Netbeans user. I know Groovy integrates very well with Eclipse, but that is of little use to me. So, I can't easily run and debug Groovy.

    I believe a many of these issues are fixed now (articles like this help with the documentation), so I may take another look, but my impression was that Groovy was a very good idea, but incomplete. I am prepared to be proved wrong! Any sign of a plug-in for Netbeans 4.0 (not as popular as Eclipse, I know, but widely used)?
  3. groovy and such
  4. unfair comparison[ Go to top ]

    Why compare Groovy with plain JDBC? It is not fair comparison IMO.
    Groovy is a library and a framework, so it would fair to compare with other libraries like iBatis or just CGLib(or AOP) instrumented source code.
    With this kind of comparison Groovy does not look that compelling anymore, quite contrary, with Groovy I do not have code completion and syntax checking which are available when I work with plain Java code.
    Code differences are minimal and I do not feel that doing DB work with Groovy worth the troubles.
  5. unfair comparison[ Go to top ]

    completely agree
  6. unfair comparison[ Go to top ]

    And even if someone will say that the reason it was compared to plain jdbc is to show how groovy can be used to make fast sql scripts - i.e. in cases where using a higher level java library might make quick (non-production and/or throwaway )script development less quick - I would still counter that a few simple abstraction classes (that can even be put together in house over an afternoon) can reduce the jdbc code to just about the same size as groovy. (And adding a new language to a project - even for ad-hoc jobs - involves added risk-management requirements..)
  7. unfair comparison[ Go to top ]

    Why compare Groovy with plain JDBC? It is not fair comparison IMO.Groovy is a library and a framework, so it would fair to compare with other libraries like iBatis or just CGLib(or AOP) instrumented source code.With this kind of comparison Groovy does not look that compelling anymore, quite contrary, with Groovy I do not have code completion and syntax checking which are available when I work with plain Java code.Code differences are minimal and I do not feel that doing DB work with Groovy worth the troubles.

    Well, as an ex-Smalltalker I find the closures in Groovy look like a very powerful and natural way to handle lists and iteration, and so for handling records in JDBC. Also, the lack of requirement for types in Groovy means that it can be a far more expressive way to code business logic (until Java adds math operators for BigDecimal etc).
  8. unfair?[ Go to top ]

    Well, you can use iBatis, and Hibernate, and OJB and all them in Groovy -- and guess what, they get even better:

    session.find("from Bar").each { bar| println bar.name }

    Sometimes working with SQL and relational stuff dynamically is a good thing =)
  9. unfair?[ Go to top ]

    Well, you can use iBatis, and Hibernate, and OJB and all them in Groovy -- and guess what, they get even better:session.find("from Bar").each { bar| println bar.name }Sometimes working with SQL and relational stuff dynamically is a good thing =)
    I am not sure what meaning word ‘dynamically’ mean when applied to Groovy scripts.
    Do I have wrong idea or I still have write-execute cycle when working in IDE or text editor?
    Well, it is not that much different from quick write-compile-execute with plain Java.
    Or does Groovy assume me working in a Groovy console and execute as I write? That is really dynamic, but I will question convenience of it.

    Closures: kind of nice to have, but no thanks if there is no syntax checks, navigation and autocompletion available from IDE, I am too lazy to memorize all the little quirks in all the languages and environments I use.
  10. unfair?[ Go to top ]

    I am not sure what meaning word ‘dynamically’ mean when applied to Groovy scripts.Do I have wrong idea or I still have write-execute cycle when working in IDE or text editor? Well, it is not that much different from quick write-compile-execute with plain Java.Or does Groovy assume me working in a Groovy console and execute as I write? That is really dynamic, but I will question convenience of it.Closures: kind of nice to have, but no thanks if there is no syntax checks, navigation and autocompletion available from IDE, I am too lazy to memorize all the little quirks in all the languages and environments I use.

    You have both write-execute AND direct execution - you can run groovy interactively or compile to java bytecodes. As for the syntax checking, autocompletion etc., that depends on the IDE - it's nothing to do with the language. From what I have seen, the Eclipse plug-in is pretty full-featured.
  11. unfair comparison - huh?[ Go to top ]

    Groovy is a library and a framework...

    I'm not sure I get your point. Groovy is not a persistence framework like iBatis but is simply a scripting language with features that reduce the amount of code you have to write to do common programming tasks.

    Writing JDBC DAOs is still very common (for good reasons) but they are a pain to create and maintain. Looking at the amount of code reduction for similar functionality it is hard not to see the advantages of using scripting over raw Java code.

    Yes native IDE features make creating Java files easier than but that seems a shallow comparison when compared to an order of magnitude less code to maintain.

    I guess it could be argued that in certain cases using a framework may reduce the amount of code that needs to be written but in my experience the learning curve of a new framework, a bunch of xml files describing the tables I want to use, and the possibility that my chosen framework may go out of style has kept me leaning toward plain JDBC.

    If JDBC code reduction was groovy's only glowing point I'd have to agree that it wouldn't be worth the trouble. When you look at all the other handy things it simplifies (xml, regex, iterations, etc) it is hard to argue against it.

    If it does become the "standard" java scripting language as promised (see JSR), my guess is that deep IDE support will follow.
  12. unfair comparison - huh?[ Go to top ]

    ... When you look at all the other handy things it simplifies (xml, regex, iterations, etc) it is hard to argue against it....

    Perl simplifies many things too. Yet for some (count me here) Perl is a language from hell.
    Such a reaction caused by philosophical differences: one environment grows by incorporating various things directly into language syntax and runtime( Perl ) and other keeps core language intact and does everything in libraries.

    I do not think that combining two approaches (Java as one and Groovy as another) is a good thing.

    Just 2 c
  13. Yeah, I understand your point.

    I think that the difference between perl and groovy is that groovy is pretty java-like in structure. You use the same class structures, the very same java libraries, etc so as new SDK's get put out Groovy should grow with it.

    Really, what it comes down to is that groovy is just a nice java library that makes development simpler as opposed to a jRuby or jPython where the learning curve is steaper (coming from java).

    I think there is a strong argument for scripting langauges in today's development, though probably not for every project. If someone is interested in scripting for java, Groovy makes the strongest argument I think.

    The only strong negative is that the developer's of Groovy don't seem less concerned with finishing the JSR 1.0 version/along with substantial documentation than they do with adding new features.

    Last February at a No Fluff conference we were told that a stable 1.0 would be out withing the year. Still waiting and can't quite recommend it to our clients until it gets some sort of stamp-of-approval from Sun/community.
  14. Yeah, I understand your point.I think that the difference between perl and groovy is that groovy is pretty java-like in structure.
    According to Mike Spille it is not the case.
    He used to be a big fan of Groovy but now publishes Groovy's A Lost Cause Very interesting reading IMO