Some of the nice features of groovy is because it is a dynamic language, that can be compiled down to the JVM by the parser when it it reread/reloaded/redefined. According to my understanding however that capability comes at a price: The dynamic code that it generates relies on a lot of reflection to do some of its magic, so the code is not optimized the way the standard javac does with static class/method lookup at compile time, thus it runs slower. JDK 7 is slated to include JSR 292<http://jcp.org/en/jsr/detail?id=292> which is supposed to add new JVM Bytecode Ops specifically for dynamically invoking and redefining class/method structures, which extend beyond just groovy to being able to efficently target lots of different dynamic languages to the JVM efficently, you can read more about this at Dynamic Language Support<http://java.sun.com/developer/technicalArticles/DynTypeLang/index.html> .
NOTE, I am not saying we should not use Groovy, I am just pointing out the potential inefficiency until JDK 7 is available. In fact one of the things I am looking at is using these type of features (Groovy or another dynamic scripting language that can be run in java such as Ruby) in the prototype to replace our server. Note that our current server is written in PERL, and in some ways using a dynamic scripting language with simplified DBI style of untyped SQL access would greatly simplify the porting of much of our buisness logic. The problems we have had with the PERL include low-level bugs in the Net::SSLeay code when a Socket is disconnect during packet writes. Because of this low-level library bug processes sometimes hang around, consuming cpu and memory trying to write and renegotiate the link instead of propogating this disconnect error condition up. In fact one of the tasks on my plate during business hours is to determine a way to fix this, and submit the patch to CPAN. Another problem (which we believe was fixed sometine ago, but have not rewritten our server to take advantage of) is that at one time the PERL thread model was broken when run on SMP (bug on early Perl 5 and 2.2 linux kernels...) machines, so our server was changed to use process forks, which is not nearly as scalable as the threaded server we started out with. We have had no problems with the SSL layer on our client side in java,and the java SSL implementation is much more heavily utilized and maintained in this world of JavaEE servers, so the entire reason for prototyping the new server on java using some the more recent technology is to move to a much more scalable infrastructure as we add clients, using a common code base on both the server and client, and limiting the number of concurrent transactions on the DB via worker threads in a que to optimize server load, and support asynchronous messaging back to the client for push style updates on data changes from other clients, which can not be cleanly/easily done with our PERL forked server. SO my two cents worth is we use Groovy knowing that it will eventually become much more efficent on the JVM. On Wed, Jul 15, 2009 at 12:01 AM, Peter Firmstone <[email protected]> wrote: > Gee, that looks easy Dennis, > > We could also support using java source too in JDK 1.6 or later as the > compiler API is included, but groovy looks so much like java (less > semicolon) it's not funny! > > I can't see any reason why we can't use Groovy? Users can choose with > their feet. > > What was the objection? > > +1 Peter. > > > > > Dennis Reedy wrote: > >> >> On Jul 13, 2009, at 753AM, Tom Hobbs wrote: >> >>> >>> >>> Someone on the Jini-Users (or similar, I can't quite remember) a while >>> ago was talking about using Groovy classes to describe service >>> configuration. Something like this sounds pretty neat, but anything >>> that needs to be recompiled for changes can take affect is likely to be >>> unworkable for obvious reasons. >>> >> >> I brought up the Groovy config support. Rio has switched over from the >> Jini configuration file approach to now use Groovy classes. No compilation >> is required, the Groovy classes are parsed when loaded by the >> GroovyConfiguration utility. A simple example of a Groovy configuration for >> Reggie follows: >> >> @Component('com.sun.jini.reggie') >> class ReggieConfig { >> >> String[] getInitialMemberGroups() { >> def groups = [System.getProperty(Constants.GROUPS_PROPERTY_NAME, >> 'rio')] >> return (String[])groups >> } >> >> String getUnicastDiscoveryHost() { >> return java.net.InetAddress.getLocalHost().getHostAddress() >> } >> >> } >> >> >> >> >> >> >
