Is there a Java Scripting Language that Can Work Without Caching? Jython? Groovy? etc?

Question

We have an existing java-based heavyweight project that needed an interactive script interpreter. After a fair amount of research we eventually ended up with Jython, one of the reasons being that the customer's group already has a large amount of python expertise, and it's an easier sell to give them an api in a language close to one they already know.

Alright, well at first this was fine, but there turned out to be a problem- there are deployment environments which are locked down for ordinary, (ie: non-admin) users. Such ordinary users have no permission to write anywhere on the local drives of their machines. Additionally, their $Home (on windows) is usually over a high-latency network (often 100ms+), and to top it off, the size of the writeable folder itself is usually below 10mb. Yes, that's megabytes.

Given these restrictions, it looks like Jython may not fit the bill. We need to be able to run without access to a low-latency disk cache, even if that means a small speed penalty. After a search through Google and the forums, there doesn't appear to be a way in Jython to accomplish this.

There are a couple obvious workarounds:

• Get the customer to open up their security. Unfortunately, it's a large bureaucracy and trying to justify changing an enterprise-wide security policy to provide scripting for one product isn't really an option.
• Set up a ramdisk and put the script interpreter's cache there. The problem with this approach on windows is that it involves a level of interference with the OS that will remain whether our application is running or not. (At least as I understand the techniques for doing so)

So here's my plea - does anyone know of a java scripting interpreter that has an interactive mode and does not necessarily require a disk cache? It does not necessarily need to use python syntax, if there's a way to get others, (ie: javaLUA, Groovy, etc) to do this, I'd be open to it.

Answer 1

You may just set

python.cachedir.skip=true

You'll have to check your imports, though...

http://wiki.python.org/jython/PackageScanning

http://ghattus.com/2009/09/no-wlst-cachedir-with-python-cachedir-skip.html

Answer 2

I can't tell you for sure, but I can give you a couple suggestions.

There is a plugable scripting framework for java where you can plug in any scripting language--the user can choose his own language. If you haven't found this yet I suggest you search for it.

Since the framework is implemented in one place, I wonder if it supports the caching... if so, you should be able to intercept the calls and implement your own ram-based cache (Since all the source code should be available).

I'd also look into BeanShell. As far as a simple, loose scripting language goes, it's pretty good. It's lightweight and might be easier to modify.

Finally you might contact the various teams and offer to sponsor a switch that re-routes disk accesses. You're using the product, supporting the team should be something you'd prefer to do anyway.

Answer 3

I have no idea about caching requirements, sorry. I wasn't even aware that interpretive Java environments needed such a thing. OK, that's easy for me to say with a 1 TB disk locally and fully accessible to me.

While I can't speak for caching issues, I'd suggest giving Clojure a try. It's a relatively tiny language with excellent Java interoperability, and I wouldn't be surprised if it chews up less of this mysterious cache than other languages.

The biggest downside is that Clojure is a Lisp derivative, significantly different from Java, Python and probably any other languages your customer may know. Unless some of them develop emacs extensions on the side :)

Answer 4

Groovy does not use a cache directory in the same way that Jython does. Groovy compiles down to actual Java class files (in memory, not on disk when you use a script). My understanding of Jython is that it caches Java packages and things like that. Groovy uses the same package structure and does not require such a cache.