Cocoon flow in Java

Posted on Mon 12 May 2003
Ovidiu tells us about Cocoon flow controller implemented in Java. Wow, this is something I've been dreaming of for a long time, and had some deep thoughts about just yesterday while digging the soil in my garden (yes, physical work frees the brain, and this is often at that time that I have very deep technical thoughts...)

Although JavaScript allows rapid prototyping, I miss many of Java's features when writing flow scripts, such as strong typing and all the Eclipse features (code completion, javadoc tooltips, etc).

Yesterday's thoughts ended with the following action items to have flow written in Java :
  • Hardest point : we first must have continuations in Java. Taking Brakes as a starting point, this shouldn't be that much work. I also thought about tail-call optimization (tail recursion is easy), which can partially be implemented (we can trash all local variables, but I think we need to keep the full method call chain).
  • Automatic compiling classloader. Next to continuations, the niciest feature of flow script is the fast trial and error cycle : save your file, reload and see your changes. The same can be possible with a smart classloader that takes a source files directory instead of a class files directory. If the source file changes, it is recompiled a soon as someone calls ClassLoader.loadClass() on the corresponding class. We can also use some delegating proxies for the case where classes are loaded only once (e.g. Avalon container factories). Once you're satified with your class, you can deactivate the auto-compiling class loader and deploy a class file as usual.
  • On-the-fly continuation enabler. This is another classloader which passes bytecode through the continuation transforming engine (first point above). Since not all classes require to be continuation-enabled, only classes implementing a particular marker interface will be transformed.
With the above features, Cocoon flow would rock the planet even more than it is today. I'll do all this in my copious free time. Are there some friendly volunteers with enough bytecode hacking knowledge that would like to help me ?

With the flow implemented in Java, does the "Interpreter" interface name still make sense as it does with Scheme or JavaScript ? It seems to me "Controller" or "ContinuationEnabledLanguage" would be more appropriate.

Bertrand discovers LF5

Virtuality as strong as reality