Several posts on this forum that suggest taking an application written in a dynamic interpreted language and running it under the
Java VM in an embedded interpreter is a trivial exercise. Well I'm afraid that's not the case.
Most of the dynamic languages are based on a relatively small command sets and are dependent on third party extensions to provide the rich set of features required for enteprise deployment. In most cases the Java derivatives of dynamic languages only support the core syntax of the mother language and do not provide support for non core extensions unless those extensions have also been ported to Java. A Ruby application that makes use of the Ruby ldap extension will not run under Jruby because the Ruby ldap extension has not been ported to Java. The Developers would have to either port the ldap extension to Java thenselves or rewrite the application to use the a native java ldap library.
The other popular embedded dynamic languages Jacl and Jython suffer precisely the same problem. The situation is unlikely to improve because changes to the mother language and it's extensions have to be back ported to the Java derivative; a complex and expensive task which ensures that the Java versions of these languages will always lag behind and lack the features of the mother language.
Java embedded dynamic languages are very much a niche product. Dynamic languages that can call java libraries from the C runtime are much more appealing and much more valuable to non Java programmers who want to use Java libraries or interact with Java applications. Unfortunately there is not much choice at the moment. Only Perl(inlineJava) and Tcl(TclBlend) offer this feature. Ruby needs RJNI(now defunct) or something similar.