Tim Coninx wrote: >Hello, > >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 >transformer. >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 > http://jakarta.apache.org/bcel/ > >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 > http://www.cs.kuleuven.ac.be/~distrinet/projects/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 -- Sylvain Wallez Anyware Technologies Apache Cocoon http://www.anyware-tech.com mailto:[EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
