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()
}
}
