4 ms·

Groovy doesn't get enough love as a post java jvm language IMO. I agree that grails is a bit heavyweight. The people at my former place did some work on using

by babs474 13y ago

Groovy doesn't get enough love as a post java jvm language IMO. I agree that grails is a bit heavyweight. The people at my former place did some work on using groovy with dropwizard: https://speakerdeck.com/kyleboon/webservices-with-dropwizard-and-groovy https://speakerdeck.com/kyleboon/webservices-with-dropwizard... which is seems to be more of a nice collection of libraries, rather than a box you in framework.

netcraft 13y ago
My biggest complaint with Grails is its reliance on GORM - You can do sql, but it doesn't make it easy and the whole framework is really geared towards the ORM functionality and the opinionated view of the database and naming conventions. I need to be able to integrate with legacy data sets, and need more control over the database in general. Grails works well if your database is just a simple store for your application data.
- babs474 13y ago
  That is my experience too, but I blame it on hibernate which GORM is just a dsl wrapper for. Its fine when it works, but expect inscrutable session flushing errors when you try and flex it too hard.
- _JamesA_ 13y ago
  You can easily peel away the layers all the way down to direct SQL, completely bypassing GORM and Hibernate, when necessary.
- ebiester 13y ago
  I've used it with legacy applications with good success. If you really want, you can completely ignore GORM. Leave the domain directory blank, use command objects for your DAOs and DTOs. You can add your validation straight to command objects. On top of that, you can write your own hibernate xml on which your domain objects depend. If you get too fancy, you'll lose some of your GORM syntactic sugar, but you do have options.
  - netcraft 13y ago
    This is interesting - do you know of any examples out there of the structure you're talking about?
    - ebiester 13y ago
      I've personally used it in a few hairy situations, but I haven't had to in a long time. http://stackoverflow.com/questions/425294/sql-database-views-in-grails http://stackoverflow.com/questions/425294/sql-database-views... is how you would do direct SQL without GORM, which you would use if you wanted to avoid hibernate entirely. The rest is just command objects - http://grails.org/doc/latest/guide/theWebLayer.html#commandObjects http://grails.org/doc/latest/guide/theWebLayer.html#commandO... - and more importantly, @Validatable. http://grails.org/doc/latest/guide/validation.html#validationNonDomainAndCommandObjectClasses http://grails.org/doc/latest/guide/validation.html#validatio... (Technically, command objects are a specific function within the controller, but what we're really looking to do is leverage the validation framework.) It's extra work, but no less so than avoiding an ORM in any framework. But if you can do it in Hibernate, you probably don't need to bother with this most of the time. (When I had to do it, it was to interface with stored procedures.) http://grails.org/doc/latest/guide/hibernate.html http://grails.org/doc/latest/guide/hibernate.html is there if you want to bolt GORM on to legacy classes.
- hatchoo 13y ago
  We use Grails purely for the convenience of its Views, Controllers, and Services. For the backend, we use Java - backed REST-like services. It is trivial to remove the GORM/Hibernate dependencies from Grails. If you can use No-Sql databases that offer a REST API, all you will need is an additional dependency on Httplib so you can make the calls.
- olavgg 13y ago
  Use Groovy SQL, it is as easy as: Sql sql = new Sql(dataSource) List results = sql.rows('SELECT * FROM mytable WHERE type_id = :type_id', [type_id: id])
stephen 13y ago
Groovy doesn't get enough love as a post-JVM language because they missed the static typing boat. People that like static languages use Java, Scala, etc. People that like dynamic languages use Python, Ruby (JRuby), etc. Who's left over to use Groovy? The people that like Grails and Gradle. Which is fine, but the popularity of the whole language is resting on these two frameworks, IMO, which seems precarious. It's original thesis, a scripting language for the JVM, was interesting when it first started, but since then the JVM implementations of traditional scripting languages has gotten really good. Personally, I believe that if they'd pivoted to static typing around Groovy 1.0, they would have been the Java next by now. They would have won. They were years ahead of Scala. And it's always sounded like a great, working man's language/compiler, e.g. powerful AST/meta-programming/etc. There were people in the Groovy camp who wanted to do this (the @Typed annotations that they have now), but it took too long, AFAICT, because the core committers had spent so much time convincing everyone that a dynamic language on the JVM was worthwhile that they didn't realize a static one would have taken their adoption to the next level.

by babs474 13y ago

netcraft 13y ago

My biggest complaint with Grails is its reliance on GORM - You can do sql, but it doesn't make it easy and the whole framework is really geared towards the ORM functionality and the opinionated view of the database and naming conventions. I need to be able to integrate with legacy data sets, and need more control over the database in general. Grails works well if your database is just a simple store for your application data.

babs474 13y ago
That is my experience too, but I blame it on hibernate which GORM is just a dsl wrapper for. Its fine when it works, but expect inscrutable session flushing errors when you try and flex it too hard.
_JamesA_ 13y ago
You can easily peel away the layers all the way down to direct SQL, completely bypassing GORM and Hibernate, when necessary.
ebiester 13y ago
I've used it with legacy applications with good success. If you really want, you can completely ignore GORM. Leave the domain directory blank, use command objects for your DAOs and DTOs. You can add your validation straight to command objects. On top of that, you can write your own hibernate xml on which your domain objects depend. If you get too fancy, you'll lose some of your GORM syntactic sugar, but you do have options.
- netcraft 13y ago
  This is interesting - do you know of any examples out there of the structure you're talking about?
  - ebiester 13y ago
    I've personally used it in a few hairy situations, but I haven't had to in a long time. http://stackoverflow.com/questions/425294/sql-database-views-in-grails http://stackoverflow.com/questions/425294/sql-database-views... is how you would do direct SQL without GORM, which you would use if you wanted to avoid hibernate entirely. The rest is just command objects - http://grails.org/doc/latest/guide/theWebLayer.html#commandObjects http://grails.org/doc/latest/guide/theWebLayer.html#commandO... - and more importantly, @Validatable. http://grails.org/doc/latest/guide/validation.html#validationNonDomainAndCommandObjectClasses http://grails.org/doc/latest/guide/validation.html#validatio... (Technically, command objects are a specific function within the controller, but what we're really looking to do is leverage the validation framework.) It's extra work, but no less so than avoiding an ORM in any framework. But if you can do it in Hibernate, you probably don't need to bother with this most of the time. (When I had to do it, it was to interface with stored procedures.) http://grails.org/doc/latest/guide/hibernate.html http://grails.org/doc/latest/guide/hibernate.html is there if you want to bolt GORM on to legacy classes.
hatchoo 13y ago
We use Grails purely for the convenience of its Views, Controllers, and Services. For the backend, we use Java - backed REST-like services. It is trivial to remove the GORM/Hibernate dependencies from Grails. If you can use No-Sql databases that offer a REST API, all you will need is an additional dependency on Httplib so you can make the calls.
olavgg 13y ago
Use Groovy SQL, it is as easy as: Sql sql = new Sql(dataSource) List results = sql.rows('SELECT * FROM mytable WHERE type_id = :type_id', [type_id: id])

stephen 13y ago

Groovy doesn't get enough love as a post-JVM language because they missed the static typing boat. People that like static languages use Java, Scala, etc. People that like dynamic languages use Python, Ruby (JRuby), etc. Who's left over to use Groovy? The people that like Grails and Gradle. Which is fine, but the popularity of the whole language is resting on these two frameworks, IMO, which seems precarious. It's original thesis, a scripting language for the JVM, was interesting when it first started, but since then the JVM implementations of traditional scripting languages has gotten really good. Personally, I believe that if they'd pivoted to static typing around Groovy 1.0, they would have been the Java next by now. They would have won. They were years ahead of Scala. And it's always sounded like a great, working man's language/compiler, e.g. powerful AST/meta-programming/etc. There were people in the Groovy camp who wanted to do this (the @Typed annotations that they have now), but it took too long, AFAICT, because the core committers had spent so much time convincing everyone that a dynamic language on the JVM was worthwhile that they didn't realize a static one would have taken their adoption to the next level.