views:

98

answers:

4

Hi all,

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.

+1  A: 

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.

Chris Dail
A: 

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 :)

Carl Smotricz
Thanks for the suggestion! I checked into clojure back when the script engine evaluations went on for this project. I find it intriguing, but I've also found that the mention of Lisp seems to elicit a rather negative response from most people in production environments. Getting buy-in gets more difficult. If it weren't mentioned right away on Clojure's website, we might be able to fool people for a while. :)
JPDecker
A: 

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.

Bill K
Checking the code supporting JSR223 was a great idea. A cursory examination of the Sun code appears to allow script engines the latitude to do whatever they want, so long as they conform to the proper interface. As such, I had trouble finding any mention of cache handling. They may leave it up to the implementation, though I could be mistaken.
JPDecker
+2  A: 

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

rapto
On the Standalone jar install this is always set to true, (just not on the full install jar). The downside of this approach is you lose the package scanning features. That's a non-issue when working with loaded scripts from files, but it's a bit more inconvenient when running from the interactive prompt; to navigate your packages you either have to search the file system yourself or have your structure memorized. I'd like to preserve the scan if possible...
JPDecker