cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: Brakes (was: [control flow] changes and new sample)
Date Wed, 11 Sep 2002 14:48:42 GMT
Tim Coninx wrote:

>As I was pointed by a friend to the previous thread, I noticed a
>proposal to prototype Brakes, which I have been working on a time ago.
>This is not a commercial message, but a status report of the technology.
>Brakes consists of two parts:
>- A bytecode transformer adds bytecode after every method start,
>  and before every method call.
>  The bytecode before each method call makes sure the control flow of
>  the executing thread gets saved.
>  The bytecode at the start of each method checks the state of the
>  thread, and acts upon that (normal/saving/restoring)
>- A small experimental framework which serves as a starting point for a
>  thread, a place in which the control flow gets saved, and the point
>  from which the control flow gets restored.
>The research on brakes is being discontinued, partly because too few
>people worked on it, partly because we (I) didn't had the nerve to get
>this project into a more serious prototype stage.
>The code however exists, and is usuable to certain extent.
>The biggest problem is the bytecode transformer. This is a huge piece of
>work by Bert Robben, a member of our research group who left four years
>ago. We suspect he is the only one with full understanding about the
>A positive thing is that the transformer is based on BCEL (the bytecode
>engineering library) by Markus Dahm. (During that time named JavaClass).
>BCEL is still under development, now under the wings of Jakarta
>I am pretty sure that much of the 'difficult' functionality in the
>transformer is now handled within the BCEL. So a rewrite of the
>transformer /should/ be feasible.

Agree. I'm also using BCEL for class transformation, and I must say it 
makes things relatively easy... once you master the virtual machine 
specification !

>The framework part is of course something that should be redesigned to
>fit on Cocoon.
>The past weeks, I have been looking again at BCEL, and have been
>gathering ideas about how to redesign the bytecode transformer. When
>you are serious about using Brakes in Cocoon, I am of course willing
>to devote a great deal of time in helping with the transformer and the
>framework's integration in Cocoon.

We are *very serious* at using something like Brakes in Cocoon. The use 
case is however a little bit different than Brakes : we want to 
implement continuations, which are the capability for a program to 
interrupt itself and be resume later in the state where it was 
interrupted. The main difference (as far as I understand) with Brakes is 
that program interruption is not triggered externally in our case.

>About licensing: because Brakes was abandoned so early, it is covered
>under the same proprietary license as it's parent project, Correlate
>However, (again when you are serious about using brakes into Cocoon) it
>will be possible to decouple Brakes from Correlate and embed the
>subproject (Brakes) into Cocoon, or at least release it seperately under
>the APL.

We would be *very interested* in that. Is some license change possible 
so that we can at least look at the source code ?

>Oh, I am new to this list, so forgive me if I broke some rules.

No problem. This was perfect. Welcome !


Sylvain Wallez
  Anyware Technologies                  Apache Cocoon 

To unsubscribe, e-mail:
For additional commands, email:

View raw message