Steven Devijver

This article was originally published on February 5, 2008. When a new piece of coding material comes out, the entire coding community tends to get pretty excited about it. They care because they know that it means that there are new applications that they can play around with, and it is entirely possible that there will be some incredible new creations that come out of all of this as well. Thus, there has been a lot of buzz around the Grails 1.0 release, and we are so excited to share with you some of the reasons why this is exciting. Web Development Is More Complicated Than It Needs To Be One universal truth about website development as it stands today is the fact that it is more complex than it honestly needs to be. There are many tools that one may use to work their way through some of it, but few things simplify it down enough for the average person to hop on and feel good about what they are creating. People will tell you that they feel shaky at best about their creations, and that is really saying something. Java is what most people use when they are coding, and it is likely to remain the dominant player for a very long time to come. That said, there are tools like Grail 1.0 that seek to help users get a better sense of what is going on within the coding that they are doing. The hope is that by explaining what is happening, users of Grail 1.0 can get a firmer grip on the concepts that they are working with. What Makes Grail Different? There are plenty of coding languages out there, so what makes Grail so different, and why should people honestly care about it at all? It turns out that the main reason we need to care about it is that it works with Java and leverages Spring to make things even more straightforward and easy to understand. Grail has typically been used for web applications in the past, but the role that it has is now expanding to desktop applications as well. There are different types of people looking to access it at this time, and it seems that allowing them to view it over as wide of a scope as possible is a great way to make sure everyone gets a crack at it even if they don't yet realize that this is something that they want in their lives. Is Grail Catching On? You could say that Grail 1.0 has made quite the splash in the coding community. This is not just some niche product. The makers of this program anticipate that they will see between 5,000 to 10,000 downloads of it per month as it gets kicked off. That is a lot of interest to be circulating around a single product in the coding world. It means that they are expecting an explosion of users to want to hop on and check out what it is all about. If they are right in their projects, then this download could prove to be something very big indeed. It may even become a must-have product in coding. When you have something that catches on with that big of a segment of the population, it is often the case that it has struck some kind of chord with them, and it means that there is a lot to be excited about on the product development side. It is a huge deal that things have gotten as far as they have, and we must recognize that there is still room to grow this project out even more, but it is exciting that it is doing as well as it is already. Graeme Rocher just announced on the Grails mailing list the release of Grails 1.0. I'm very happy to announce this news here on Groovy Zone since more than 2 years ago I stood at the cradle of Grails together with Graeme, Guillaume La Forge and Dierk Koenig. Grails, Groovy and the entire Java community has gone a long way since then. Grails has seen the rise of many competitors since its inception. JRuby on Rails has become a reality. Seam is going strong. Yet the popularity of Groovy and Grails is undeniable, as the traffic on Groovy Zone indicates. Thanks to the Grails development team for all the hard work. Grails went through quite a few refactorings. Out of this came ExpandoMetaClass which helped to re-write the Meta-Object Protocol in Groovy 1.5. I also like BeanBuilder, a Groovy builder for configuring a Spring ApplicationContext. For me Grails is the ultimate rapid prototyping platform for Java. I've built numerous applications by dropping in existing Hibernate-configured classes and generating scaffolding views. It gets you started really quickly and helps you to focus on the application you're building. GSP and the Grails tag libraries are amazing, they're so much better than JSP tags. And let's not forget the numerous Grails plugins. The Search plugin is terrific, it instantly adds search functionality to your application. Check out all the Grails plugins for your needs. Download Grails 1.0 here. Read the user guide here. Watch the screen casts here. Check out the Grails and Groovy books here. An Open Source Product As with many things these days, Grail 1.0 is an open-source product. That is a huge deal simply for the fact that it means that you can access the Grail 1.0 program that you need without having to pay a penny for it. It also means that people are constantly adding more features to the program as time goes on. You will want to check in on this regularly because it means that there may be some interesting updates that are added to it from time to time. You certainly don't want to let those pass you by. There is a whole world of developers out there who are adding their own personal touches to projects like this. You will discover that many of them are extremely well-versed and great at what they do. You may even learn a thing or two about how you need to structure your own coding projects in the future. There may be some critical information that you learn from other coders and discover that you can tweak your own codes to make them even more functional. Add it to Your List of Tools You may love Grail 1.0, or you may feel more uncertain about it. At the end of the day, it doesn't matter all that much. What is ultimately important is if you can use it as part of your overall routine for getting more information out into the world. You likely have tools that can help the rest of humanity, and you need to just add it to the other tools that you have for coding. It might come in handy someday, and it is unclear when that day will be. Think about this and make sure you throw it in there with everything else that you have going for you. It could prove to be extremely useful at some point in time.

Through DZone I found Architecture Rules, a lovely little framework that abstracts JDepend. Architecture Rules is configured via its own XML schema.

Time to talk about creating new classes at runtime in Groovy. There seems to be some fear, uncertainty and doubt about memory leaks and evaluating code with Groovy in the form of calling an eval() method. The code that seems to cause consternation is this: def shell = new GroovyShell() 1000.times { shell.evaluate "x = 100" } The groovy.lang.GroovyShell instance will call the parseClass() method on an internal groovy.lang.GroovyClassLoader instance, which will create a 1000 new classes. The classes will all extend the groovy.lang.Script class. With every new Class created a little bit more memory will be used. As long as the groovy.lang.GroovyShell instance and thus its internal groovy.lang.GroovyClassLoader instance is not garbage collected this memory will remain occupied, even if you don't keep a reference to these classes. This is standard Java ClassLoader behavior. So, how to solve this problem? Well, ClassLoaders in Java are somewhat hard to handle, but it's not so hard once you understand how they work. But lets also consider the root of the problem, namely the fact that Groovy creates a new Class for each script that is evaluated. Before answering why Groovy always creates new Class objects when evaluating code let's first try to fix the code above. One way to fix it is this: def shell = new GroovyShell() 1000.times { shell.evaluate "x = 100" } shell = null By setting the shell variable to null, will the GroovyClassLoader instance be garbage collected? We can guarantee it will in this bit of code. But then again this code does not do anything useful :-) Here's another way to fix it: def shell = new GroovyShell() def script = shell.parse "x = 100" 1000.times { script.run() } By evaluating - parsing - the code only once and calling the run() method on the groovy.lang.Script instance a 1000 times we only use 1/1000th of the memory :-) The parse() method returns a groovy.lang.Script instance. But again, let's consider a more realistic use case. After all, the article that originally critized Groovy for causing memory leaks implies that evaluating code any number of times is a valid requirement in entreprise applications. Let's say it's more of a corner case but still, the functionality is there and it can solve real-world problems. Evaluating Groovy code may be particularly useful and critical when evaluating code on demand. This could happen when an application reads code from file or a database to execute custom business logic. Let's consider the case where developers create a DSL or Domain Specific Language like this: assert customer instanceof Customer assert invoice instanceof Invoice letterHead { customer { name = customer.name address { line1 = "${customer.streetName}, ${customer.streetNumber}" line2 = "${customer.zipCode} ${customer.location}, ${customer.state}" } } invoiceSummary { number = invoice.id creationDate = invoice.createdOn dueDate = invoice.payableOn } } To parse this DSL developers wrote this code (using the iText PDF library): import com.lowagie.text.* import com.lowagie.text.pdf.* class LetterHeadFormatter { static byte[] createLetterHeadForInvoice(Customer cust, Invoice inv, String dsl) { Script dslScript = new GroovyShell().parse(dsl) dslScript.binding.variables.customer = cust dslScript.binding.variables.invoice = inv Document doc = new Document(PageSize.A4) def out = new ByteArrayOutputStream() PdfWriter writer = PdfWriter.getInstance(doc, out) doc.open() dslScript.metaClass = createEMC(writer, dslScript) dslScript.run() doc.close() return out.toByteArray() } static ExpandoMetaClass createEMC(PdfWriter writer, Script script) { ExpandoMetaClass emc = new ExpandoMetaClass(script.class, false) emc.letterHead = { Closure cl -> PdfContentByte content = writer.directContent cl.delegate = new LetterHeadDelegate(content) cl.resolveStrategy = Closure.DELEGATE_FIRST cl() } emc.initialize() return emc } } (Check the attachements of this article to download this code. Read the README.txt file if you want to run the load test yourself, and please report back the results. Also, check the PDF file for the output of the DSL.) On line 6 the parse() method is called. I wrote a load test that calls the createLetterHeadForInvoice() method 1 million (!) times (with regular calls to System.gc()). On my Windows XP machine, when I run the load test with Ant the java process memory usage fluctuates between 32 and 37Mb and remains stable over the course of several hours. Are the GroovyShell and internal GroovyClassLoader instances garbage collected? Yes they are. Is there a memory leak? No. So why does Groovy create Classes when evaluating scripts? Every bit of code in Groovy is a java.lang.Class. This means that it's loaded by a java.lang.ClassLoader and remains in memory unless the ClassLoader can be garbage collected. Why isn't a Class object garbage collected as soon as it's no longer used? Why does the ClassLoader itself have to be garbage collected before the classes it has loaded are removed from memory? If classes would be automatically discarded and reloaded their static variables and static initialization would be executed on each reload. That would be quite surprising and unpredictable. That's why ClassLoaders have to keep hold of their classes, to assure predictable behavior. There may be other technical reasons, but this is the most obvious one. Once the ClassLoader object itself gets garbage collected (because it's no longer referenced in any stack) the garbage collector will attempt to unload all its Class objects. Obviously, creating a lot of classes at runtime in the same ClassLoader will increase the memory usage and will typically create a memory leak. On the other hand, since every Groovy class is a real Java Class (without exception) you don't have to make the distinction. In conclusion: there is no memory leak in GroovyShell or GroovyClassLoader. Download the sample code and verify for yourself. Your code can create a memory leak by the way ClassLoaders are used - either explicitly by your code or implicitly.

Sometimes you need special measures. Not to make Groovy work, but to make your applications or frameworks a little bit more powerful or versatile.