Jeff Brown on Groovy for Java Developers


News: Jeff Brown on Groovy for Java Developers

  1. Jeff Brown on Groovy for Java Developers (20 messages)

    Groovy, an agile dynamic language for the Java platform, has a Java-like syntax along with many features inspired by languages like Python, Ruby and Smalltalk. In this presentation, recorded at the recent Grails Exchange event in London (organized by Skills Matter), Jeff Brown, core member of the Grails development team, demonstrates the power of Groovy through many interactive examples and explains how Java developers can leverage that power in their enterprise applications. The slides for this presentation can be downloaded here (1.57 MB) Watch other Tech Briefs

    Threaded Messages (20)

  2. whew, it seems i am the first one to comment :) well looks like an awesome language very easy and flexible to use, i am just wondering where will groovy fit in software architecture ?I mean in typical java architecture with struts at web layer, ejb at business layer and hibernate at persistence layer can i directly replace java code with Groovy ? Or do we need to wait for hibernate to support groovy pojo's, ejb to support groovy beans web servers and application servers to support servlets written in groovy ? PS this is first time I heard about groovy so xcuse me if above question are not relevant and groovy is already supported.
  3. second that[ Go to top ]

    I don't think replacing all your code is a good idea (if it ain't broke...), unless your boss gives you the direct order to do so :) It seems that groovy can be intergrated in you existing architecture. E.g. from now on you _could_ write your webpages in groovy while connecting with your existing business layer. But with this example you have to be aware of the look-and-feel of the gui: endusers should not see somewhat different pages. Personally i would only use groovy in new, small projects: - new: This way you have to use one technology instead of xx, and you don't have to hack around to get integration with yor existing architecture done. - small: Talking about groovy, i sense a little to-magic-for-me-smell : i am afraid that groovy projects are hard to debug and maintain. Maybe this is not true, but this is my general feeling with most emerging techs (groovy, jruby, ..). As i now see things, this might be only true for larger projects, so i would stick to smaller projects.
  4. Re: second that[ Go to top ]

    My take on groovy from what I have seen of it so far ( I have actually used it on a project in a small way to support scripting for dynamic and configurable IF conditions), is that it is great if you want to learn and use a scripting language which support the java api and looks almost identical to java. In that sense its a fantastic time saver. From the perspective of having java api support, JRuby is a good choice too but I dont know how much of a learning curve it has. Groovy is very good from a learning curve perspective.
  5. Re: second that[ Go to top ]

    Thanks Jan and Sameer, my still not clear about the support from various products like hibernate for groovy Jan say i use groovy for new and small project can i write dto's as groovy class and tell hibernate to map it to my database tables?
  6. Re: second that[ Go to top ]

    You can do anything in Groovy that you can do in Java and some more. Its sweet for some quick hacking(Paul grahams definition) and has got some nice features such as replacing a method definition on the fly and so on. Whether you can do all your development in Groovy I do not know anyone personally who does that. Also why would anyone want to do it? I had this need to provide users with an ability to script within my application. The script would follow the java syntax. I used groovy, I could have just as well used BeanShell. In the end I like it for scripting. I have often wanted to do quick scripting using Java api which i know so well but do not want to open an ide, compile code, set up classpaths just to open and tinker with some files.
  7. Re: second that[ Go to top ]

    ... I have often wanted to do quick scripting using Java api which i know so well but do not want to open an ide, compile code, set up classpaths just to open and tinker with some files...
    Well, I do want to use IDE for quick hacking or one off scripts because it helps tremendously with many trivial things, what is cumbersome and time consuming is the other things you have mentioned: setting classpath and and packaging. If all those things were quick and simple then need for "scripting" will be greatly reduced. We are almost there with dependency managers like Ivy and (sorry) Maven just need some pragmatic tool that will do majority of dumb work. I imagine it working like this: jh --create-project=job myjob jh --add-dependency=oracle-jdbc,regexp,http-client,log4j ...edit class or two jh run jh --remove-dependency=log4j jh --add-dependency=ognl ...edit class or two jh run under the hood such JavaHelper (jh) would take care of packaging, setting project files for all the major IDEs etc. And every routine operation should be quick! <= 5 seconds You might say that Maven is doing this already - not quite IMO - it is slow, unstable, and verbose. The tool of my dream should work like apt-get for dependency management and as fast as script for compile/package/run.
  8. Re: second that[ Go to top ]

    Point taken. I do like IDE's but I had packaging and setting classpaths for writing quick and dirty yet VERY useful utilities.
  9. Bandwidth Limit Exceeded The server is temporarily unable to service your request due to the site owner reaching his/her bandwidth limit. Please try again later. Apache/1.3.36 Server at Port 80
  10. ZK + Grails[ Go to top ]

    There is another way to integrate Grails with Ajax framework
  11. What we need on the JVM is Boo[ Go to top ]

  12. Re: What we need on the JVM is Boo[ Go to top ]

    Hi Frank, If you say it often enough, the penny drops finally!!! I read through the Boo Manifesto and I love it! Have you used Boo in anger? Duck typing demands a different programming style, that plays well with TDD. I've never used type inference so I have no idea how it pans out in practice. Can it get in the way like static typing does at times? BTW, I like the idea of uniformity, and maximum flexibility. Using duck typing where you need to, assumes that you will know where flexibility is needed upfront. If you program in an exploratory style then your basic assumption is that you don't. That's why defaulting to duck typing fits will with exploratory, emergent design and extreme programming. I don't know enough about type inference to have a firm view. I started learning Ocaml once and never finished. I don't know whether it is a good fit for a TDD/BDD programming style or an hindrance. I'll have to try it and see. Boo does look impressive though, and it does potentially offer the best of both worlds!!! Cheers, Paul.
  13. Re: What we need on the JVM is Boo[ Go to top ]

    Hi Paul. Yeah, I'll keep on pimping "Boo on the JVM". The language really does seem to be close to the holy grail for mainstream development. I could just imagine kickass plugins for Eclipse, Netbeans, IDEA. The whole local type inference and dynamic where needed does seem to hit a sweet spot. They python-like syntax (where wanted), coupled with the Macro system really bind together to make a powerful, but extremely readable system. The JVM just doesn't have something like Boo, and it's a shame.
  14. Re: What we need on the JVM is Boo[ Go to top ]

    Hi Paul, On a somewhat related note, have you taken a look at VODKA
  15. That means I can use Groovy easily elsewhere where BSF is supported.
  16. Some Groovy success...[ Go to top ]

    I've been using Groovy as part of our project's architecture and have had pretty good success so far. There is a plugin for Maven that makes it trivial to add a groovy compile task as part of the build. We are also using Spring so it is easy to define an interface in Java and have Spring inject the Groovy implementation - so basically using both Java and Spring is a cinch. I've kept it mostly on the edges of the architecture: I use it to: 1. Be the view for our REST services - basically render XML and HTML. Main benefit is very concise syntax using the Groovy builders 2. Unit testing - Works especially well when you want to load up input data files from the resources on the classpath. - Again the main benefit is you can write a lot of testing code with not so much work. 3. XML transformation/parsing. Groovy's XML tools are so nice I never really want to use dom4j or JDOM again. 4. Write a test client to be used by the BA's to interact with the REST service layer 5. Write a test HTML client that converts the XML services to an HTML view. (Here think of Groovy as a replacement for JSP) So far performance hasn't been an issue though I've read reports that Groovy is still slow. I've found if you have a decently compartmentalized design then the worry for performance tends to fade away. If you run into an issue you can just tweak the bottleneck without affecting the rest of the code. We do some heavy duty math processing on this project and I'm not confident enough to create our algorithms in Groovy yet. I guess my advice is if you are interested in Groovy or another JVM-based scripting language then start using it in one area (testing, maybe) and then as you have success let it leak more into other areas. The one thing I worry about is Grails overshadowing Groovy just like Rails has kind of overshadowed Ruby. I've played with Grails and read the "Grails in Action" book last summer and it didn't seem ready for prime-time yet. The best thing about learning Grails for me was that I really understood the Rails framework better coming from a Java perspective. ------------------------------------------------- George Coller DevilElephant
  17. Re: Some Groovy success...[ Go to top ]

    In terms of performance, we found two areas where groovy gets bogged down; 1. Arithmetic - it uses BigDecimal under the covers, even when you are dealing with int or long in the code. Try a little example of counting to 500k in java and then groovy and you'll see. 2. Templates (which GSPs are built upon) - We found that if the template is generated from the classpath before using it then the performance isn't too bad, but the file parsing is slow and if you aren't aware of the problem then it can slow things down. Once the template is loaded, the performance isn't too bad tho. Under the covers, groovy uses a metadata object for each of your own projects. There are performance issues with the current implementation, but the guys at G2one are aware of where the problems are and I'm sure we'll see some huge gains once the 1.1 release is finished. In terms of where it should be used, I still don't like breaking away from a strongly-typed environment into groovy for application logic. What we try and do is write our code and tests in java and wire the code together in groovy, in some ways we use it as a replacement for all the XML we used to use. Grails does a similar thing, it wraps up Spring and Hibernate and hides a lot of the tedious configuration, but leaves you with the option of using it when you really need it. I'd recommend that anyone doing web development in java tries it, it's controllers and GSPs are much quicker to develop than straight Spring MVC and JSP. Groovy can import all of your existing java code so you could try it with some existing applications and find your own sweet spot.
  18. Re: Some Groovy success...[ Go to top ]

    In terms of where it should be used, I still don't like breaking away from a strongly-typed environment into groovy for application logic. What we try and do is write our code and tests in java and wire the code together in groovy, in some ways we use it as a replacement for all the XML we used to use.
    I agree with this - using it as glue between stable java components. I think writing tests in Groovy is a lot nicer so we part there on advice. 90% of the pain in testing is writing all the boilerplate to mock out objects and load test data. Groovy just makes this simpler (load and parse an xml input file in one line of code), which makes testing more fun (and that could lead tobetter testing habits) But truthfully I have unit tests on my project both in groovy and regular Java. I probably will be writing more of the business logic in Groovy (or some other JVM scripting language) as time goes on and performance/tools are improved. Static typing isn't an issue (Groovy can do that when needed) as much as performance. But for now with Java 1.5 eye candy, Java algorithms are starting to look more script-like.
  19. Slides the other way around?[ Go to top ]

    Is there a way to make a pdf file with the slides the other way so we can read them without printing the whole document?
  20. How to flip slides[ Go to top ]

    In Adobe 8, use the menu View|Rotate View|Clockwise. Also Shift-Ctrl-Plus.
  21. Bean shell wanna bees not welcome[ Go to top ]

    You cannot talk about Java scripting and Java beans at the same time. Java Beans have no place in scripting. Scripting languages have structures that supercede beans. All a java bean is to a script is a map of fields and a map of methods keyed by name. This does not require beans or the Java language to accomplish. So I wish groovy well but there are already alternatives which do not require any of this to accomplish, and yet use the Java language as a host. I hope you find it soon Jeff. Because it aint grails and it aint groovy. Keep looking and you might find it, but its not in you.