Re: java continuations
Bertrand Delacretaz wrote:
Le 29 mars 04, à 19:05, Sylvain Wallez a écrit :
snip/
...Ah, and would it be possible to use the class enhancer to enable
continuations in a compiled (as in .class) JS script? This may help
us solving the current Rhino issues...
This sounds interesting but I don't get it, can you elaborate about
the compiled JS part?
Do you mean using our own JS compiler? At runtime?
JS compiler yes, but our own certainly not!! Rhino can produce
regular class files from JS source code, and I was wondering it it would
be possible to instrument these Rhino-generated classes with the
continuation classloader.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: java continuations
You have different pros and cons about both implementations. Some users do not want to use javascrpt because of it's interpreted nature and some political issues (you cannot make your work closed source if you want to sell it). Java needs to be compiled, the container restarted for each change, but the Not if we integrate the CompilingClassloader as it is on the TODO list. But we need that eclipse license issue solved first! development cycle could shorten when using an advanced java ide (like eclipse) - so you do not make such great number if stupid typos you cannot predict. It could be faster than javascript and more attractive to commercial vendors. Even though commercial issues are the last thing that matters here on this list it is something that should not be forgotten as if the commerce gets interest in cocoon it could provide additional resources for the project. Who knows :) cheers -- Torsten
Re: java continuations
Le 30 mars 04, à 10:45, Sylvain Wallez a écrit : ...JS compiler yes, but our own certainly not!! Rhino can produce regular class files from JS source code, and I was wondering it it would be possible to instrument these Rhino-generated classes with the continuation classloader... Ok, got it. You mentioned that this could solve Rhino issues, I assume these are technical issues, not the community/licensing ones? -Bertrand, being curious today ;-)
Re: java continuations
Leszek Gawron wrote:
snip/
Even though commercial issues are the last thing that matters here on this list it is something that should not be forgotten as if the commerce gets interest in cocoon it could provide additional resources for the project.
You're wrong, mate! Apache is a mix of personal and business interests,
and a lot of people around there are making a living with Cocoon. So
Cocoon features that help it to be adopted by more customers are most
than welcome ;-)
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
business questions on opensource lists (was Re: java continuations)
Leszek Gawron wrote:
Even though commercial issues are the last thing that matters here on this list it is something that should not be forgotten as if the commerce gets
interest in cocoon it could provide additional resources for the project.
You're wrong, mate! Apache is a mix of personal and business interests, and a lot of people around there are making a living with Cocoon. So Cocoon features that help it to be adopted by more customers are most than welcome ;-)
just got this impression after asking 2 strictly commercial question on users group and got something like: buzz off, figure it out yourself we're open sourcing here.
Ah yes, that's true that we don't directly discuss business here, but
I'm surprised that people were pissed because of this kind of question.
I guess most of the people doing their living with Cocoon are on this
list, but it's also not really the place for business discussions.
Nicola Ken long ago started a list about opensource-related business,
but I don't remember its address.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: business questions on opensource lists (was Re: java continuations)
That was over at krysalis.org. He closed it a few weeks ago because there was not enough traffic. On 30.03.2004 19:05:01 Sylvain Wallez wrote: Nicola Ken long ago started a list about opensource-related business, but I don't remember its address. Jeremias Maerki
Re: business questions on opensource lists (was Re: java continuations)
Jeremias Maerki wrote:
That was over at krysalis.org. He closed it a few weeks ago because there was not enough traffic.
... which explains why I couldn't find it :-/
Maybe this list had a too broad scope or not enough visibility. But at
the same time, I don't think a [EMAIL PROTECTED] is part of the
ASF charter.
On 30.03.2004 19:05:01 Sylvain Wallez wrote:
Nicola Ken long ago started a list about opensource-related business, but I don't remember its address.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: java continuations
Torsten Curdt wrote: as already announce on the PMC list we now have another flow implementation for java! Great! [ ] jflow [X] javaflow [ ] [ ] nah... put it somewhere else Ugo
Re: java continuations
On 29 Mar 2004, at 15:33, Upayavira wrote: JFlow could be JavaScript. Only JavaFlow gets it right. or we should start making the distinction between JSFLow and JavaFlow. I'm sure we will in the future. :-) Anyway, here my +1 for a javaflow block. /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source Java XMLAn Orixo Member Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
RE: java continuations
Torsten Curdt wrote: Dear friends and folks, as already announce on the PMC list we now have another flow implementation for java! Stephan completed my proof-of-concept and replaced the Brakes stuff by an own implementation. So we are now fully in ASL land. We would like to commit this implementation as a block. It comes with examples so anyone can give it a try. The block is currently named jflow. But we also talked about javaflow. So what would you guys prefer: [ ] jflow [ ] javaflow [ ] I really value all the work and effort that you all put into this, but I would say: [X] nah... put it somewhere else We only want to have one flow implementation (language), which is Javascript. If we put the Java version as a block in our CVS, it immediately looks like that if we would have two and more implementations or even worse, that the JavaScript implementation was a mistake. And then the confusion about Which one should I use?, Which one is better?, How long is the JavaScript impl. supported? etc. starts. And I would really like to avoid this. It's ok for me, to evaluate the Java Continuations and decide later which version to support (with a clear migration path if required), so I would prefer to put it somewhere else (sf, cocoondev etc.). If everyone else wants to have it directly in our cocoon cvs then I would prefer the scratchpad block. Carsten
RE: java continuations
I don't get to see the PMC list. I love the idea of Cocoon supporing Java Flow! Ralph -Original Message- From: Torsten Curdt [mailto:[EMAIL PROTECTED] Sent: Monday, March 29, 2004 5:31 AM To: [EMAIL PROTECTED] Subject: java continuations Dear friends and folks, as already announce on the PMC list we now have another flow implementation for java! Stephan completed my proof-of-concept and replaced the Brakes stuff by an own implementation. So we are now fully in ASL land. We would like to commit this implementation as a block. It comes with examples so anyone can give it a try. The block is currently named jflow. But we also talked about javaflow. So what would you guys prefer: [ ] jflow [ ] javaflow [ ] [ ] nah... put it somewhere else cheers -- Torsten
RE: java continuations
Am Mo, den 29.03.2004 schrieb Carsten Ziegeler um 16:18: I really value all the work and effort that you all put into this, but I would say: [X] nah... put it somewhere else We only want to have one flow implementation (language), which is Javascript. If we put the Java version as a block in our CVS, it immediately looks like that if we would have two and more implementations or even worse, that the JavaScript implementation was a mistake. And then the confusion about Which one should I use?, Which one is better?, How long is the JavaScript impl. supported? etc. starts. And I would really like to avoid this. IMHO, making the java impl. optional by using a block, should be enough to send the right signal that the javascript impl. is the main flow impl. Stephan.
Re: java continuations
Torsten Curdt wrote: Dear friends and folks, as already announce on the PMC list we now have another flow implementation for java! Stephan completed my proof-of-concept and replaced the Brakes stuff by an own implementation. So we are now fully in ASL land. We would like to commit this implementation as a block. It comes with examples so anyone can give it a try. The block is currently named jflow. But we also talked about javaflow. So what would you guys prefer: [ ] jflow [ ] javaflow [ ] [ ] nah... put it somewhere else +1 javaflow congrats on this achievement and big thx I find today a 'block' the correct flexibility for plugin' in and out anything that is optional to cocoon (nice unit contaiment with self explaining xpatch files that serve as runnable documentation on how to install it in your own project etc etc) the scratchpad block is IMHO too much cluttering together a lot of other things regards, -marc= -- Marc Portierhttp://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center Read my weblog athttp://blogs.cocoondev.org/mpo/ [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: java continuations
I really value all the work and effort that you all put into this, but I would say: [X] nah... put it somewhere else Uff... a bit discouraging I have to admit. Actually I hoped noone would pick that option. We only want to have one flow implementation (language), which is Javascript. If we put the Java version as a block in our CVS, it immediately looks like that if we would have two and more implementations or even worse, that the JavaScript implementation was a mistake. And then the confusion about Which one should I use?, Which one is better?, How long is the JavaScript impl. supported? etc. starts. And I would really like to avoid this. It's ok for me, to evaluate the Java Continuations and decide later which version to support (with a clear migration path if required), so I would prefer to put it somewhere else (sf, cocoondev etc.). If everyone else wants to have it directly in our cocoon cvs then I would prefer the scratchpad block. Well, for sure we know from our long and winded road to a single form framework that too many options are bad ...but since it implements all the very same interfaces it feels just like a different language. ...like we have different options for xsp. Since I was one the preachers of less options this might feel a bit awkward but I *do* think a block is the better choice. It's going to be marked as unstable and the javascript flow is in the core. I don't think this will give a wrong perception. But we are never immune to any of those questions as soon as it's available somewhere. I remember you don't like to have too many blocks in the CVS but going from modular back to monolithic (scratchpad) doesn't help IMO. The only thing that will help are the real blocks ...and I am glad Pier is helping us to finally get this thing rollin' cheers -- Torsten
Re: java continuations
Torsten Curdt dijo: The block is currently named jflow. But we also talked about javaflow. So what would you guys prefer: [X] jflow [ ] javaflow [ ] [ ] nah... put it somewhere else jflow is shorter and jsflow can be used for javascript flow. To me as far as both flow engines (J JS) show the same API, will be fine to allow user write the flow in what language they like or maybe both. Who knows? :-D The problem of a JFlow block tag is that it will suggest it contains the ONLY one implemented Flow Engine. Then will be a good idea to move the JSFlow out of the Cocoon core. I think the Cocoon core need to be a total minimum Think in people that will only want the JFlow and don't will use the JSFlow at all. BTW, I tought Geoff comment about inheration in JavaFlow will work and how it can be benefical in flow. Best Regards, Antonio Gallardo
Re: java continuations
Torsten Curdt wrote: Dear friends and folks, as already announce on the PMC list we now have another flow implementation for java! Stephan completed my proof-of-concept and replaced the Brakes stuff by an own implementation. So we are now fully in ASL land. Cool. We would like to commit this implementation as a block. It comes with examples so anyone can give it a try. Please do. The block is currently named jflow. But we also talked about javaflow. So what would you guys prefer: [ ] jflow [ ] javaflow [ ] [ ] nah... put it somewhere else cheers -- Torsten javaflow seems fine. +1. BTW, I think it's important to give people a chance to review the code and experiment with a Java-based flow controller before we jump to conclusions about its pros and cons versus the JS-based one. Regards, Chris
Re: java continuations
Carsten Ziegeler wrote: I really value all the work and effort that you all put into this, but I would say: [X] nah... put it somewhere else We only want to have one flow implementation (language), which is Javascript. If we put the Java version as a block in our CVS, it immediately looks like that if we would have two and more implementations or even worse, that the JavaScript implementation was a mistake. And then the confusion about Which one should I use?, Which one is better?, How long is the JavaScript impl. supported? etc. starts. And I would really like to avoid this. It's ok for me, to evaluate the Java Continuations and decide later which version to support (with a clear migration path if required), so I would prefer to put it somewhere else (sf, cocoondev etc.). If everyone else wants to have it directly in our cocoon cvs then I would prefer the scratchpad block. This brings up an interesting idea... I'm not an expert on how the Rhino interpreter works, but wouldn't some sort of abstraction layer that sits between the language we're writing the flow in, and what actually gets run be an option? In the future, if we end up getting Groovy or Jython-based continuations, we wouldn't have to maintain multiple copies of the Flow API, etc. But like I said, I'm no expert on programming languages so the very design of how it all works could block some sort of abstraction layer from being built. Just a thought. Carsten Regards, Tony
Re: java continuations
Torsten Curdt wrote:
Dear friends and folks,
as already announce on the PMC list we now have another flow
implementation for java!
Stephan completed my proof-of-concept and replaced the Brakes stuff by
an own implementation. So we are now fully in ASL land.
Yeah! You're kings guys!
We would like to commit this implementation as a block. It comes with
examples so anyone can give it a try.
The block is currently named jflow. But we also talked about
javaflow. So what would you guys prefer:
[ ] jflow
[X] javaflow
[ ]
[ ] nah... put it somewhere else
jflow isn't good as it doesn't allow the distinction between JS and Java.
Now what should go in that block: the _flow_ implementations, or the
class enhancer? I would stay that only the flow implementation has its
place inside Cocoon's CVS. But finding a more suitable place for the
enhancer (BCEL, jakarta-commons, codehaus?) may take some time, and we
may temporarily host in in the javaflow block.
Now about whether Cocoon should have two flow implementations, I think
that this is a very special case where it makes sense, as it touches the
programming language area, where Cocoon brings nothing new to the
picture (except of course continuations), and therefore has to consider
people's habits. Convincing people that flow is a good thing is rather
easy (considering the number of Wows!), but selling a particular
programming language (as opposed to some XML dialect) is sometimes
difficult. Some people will love JS and be frightened by Java, and some
others won't consider writing code using a language other than Java.
That's why I think both implementations have their place in Cocoon.
Ah, and would it be possible to use the class enhancer to enable
continuations in a compiled (as in .class) JS script? This may help us
solving the current Rhino issues.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: java continuations
Am Mo, den 29.03.2004 schrieb Sylvain Wallez um 19:05: jflow isn't good as it doesn't allow the distinction between JS and Java. Okay, seems that we agree on javaflow. Now what should go in that block: the _flow_ implementations, or the class enhancer? I would stay that only the flow implementation has its place inside Cocoon's CVS. But finding a more suitable place for the enhancer (BCEL, jakarta-commons, codehaus?) may take some time, and we may temporarily host in in the javaflow block. Yes, we have already talked with james strachan. And he seems to be interested too. But for the first time I would start within Cocoon. Now about whether Cocoon should have two flow implementations, I think that this is a very special case where it makes sense, as it touches the programming language area, where Cocoon brings nothing new to the picture (except of course continuations), and therefore has to consider people's habits. Convincing people that flow is a good thing is rather easy (considering the number of Wows!), but selling a particular programming language (as opposed to some XML dialect) is sometimes difficult. Some people will love JS and be frightened by Java, and some others won't consider writing code using a language other than Java. That's why I think both implementations have their place in Cocoon. Ah, and would it be possible to use the class enhancer to enable continuations in a compiled (as in .class) JS script? This may help us solving the current Rhino issues. I think all java classes are capsulated in wrapper classes, and if these classes suppport the continuation, then it should work. Okay, then I start to commit the block. Stephan.
Commited was Re: java continuations
Am Mo, den 29.03.2004 schrieb Torsten Curdt um 15:30: Dear friends and folks, as already announce on the PMC list we now have another flow implementation for java! Stephan completed my proof-of-concept and replaced the Brakes stuff by an own implementation. So we are now fully in ASL land. Okay, the implementation is now in the CVS, and is ready to get tested. I should try to explain how is works. The java flow use the bytecode pass3b verifier of BCEL to analyse the the control flow of the bytecode sequence, and to analyse the content of the current frame for every instruction. Means, I know at every instruction which objects are in the stack and in the local variables. Next step is to add intercepting code for every method invocation, which tests if the current invoction should be captured to continue the invocation next time. To capure the invcation the complete frame will be stored in the continuation. To restore the invocation the frame will be restored and jumps to the last invocation, and this will be done for every stack trace element. The implementation is rather simple. The core consists of 3 classes: ContinuationClassLoader, Continuation and ContiationStack. The ContinuationClassLoader adds the intercepting code to the classes, the Continuation stores the information about the current running continuation, and ContinuationStack stores the capured stack.
Re: java continuations
On 29.03.2004 15:30, Torsten Curdt wrote: [x] jflow [ ] javaflow [ ] [ ] nah... put it somewhere else Hmm, 4h for a vote was a bit short, wasn't it? So just for the records: I'm with Antonio and so like JFlow vs. JSFlow. Joerg
Re: java continuations
Am Mo, den 29.03.2004 schrieb Joerg Heinicke um 20:32: On 29.03.2004 15:30, Torsten Curdt wrote: [x] jflow [ ] javaflow [ ] [ ] nah... put it somewhere else Hmm, 4h for a vote was a bit short, wasn't it? So just for the records: I'm with Antonio and so like JFlow vs. JSFlow. I know, I know, sorry about that, guys. I was very impatient. I could revert it if you want. Stephan.
Re: java continuations
On 29.03.2004 20:39, Stephan Michels wrote: Hmm, 4h for a vote was a bit short, wasn't it? So just for the records: I'm with Antonio and so like JFlow vs. JSFlow. I know, I know, sorry about that, guys. I was very impatient. I could revert it if you want. Not because of my comment. If the vote majority will shift to another name instead of javaflow we can still move it around. If Carsten does not insist on his -1 including a removal I would let it at the place where it is at the moment. Joerg
Re: java continuations
Joerg Heinicke wrote:
On 29.03.2004 20:39, Stephan Michels wrote:
Hmm, 4h for a vote was a bit short, wasn't it? So just for the
records: I'm with Antonio and so like JFlow vs. JSFlow.
I know, I know, sorry about that, guys. I was very impatient. I could
revert it if you want.
Not because of my comment. If the vote majority will shift to another
name instead of javaflow we can still move it around. If Carsten does
not insist on his -1 including a removal I would let it at the place
where it is at the moment.
Uh? If it's a majority vote, then can Carsten's -1 be considered as a veto?
I also agree that 4 hours is a bit short, but also understand Stephan's
impatience ;-)
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: java continuations
On 29.03.2004 21:02, Sylvain Wallez wrote: If the vote majority will shift to another name instead of javaflow we can still move it around. If Carsten does not insist on his -1 including a removal I would let it at the place where it is at the moment. Uh? If it's a majority vote, then can Carsten's -1 be considered as a veto? In which cases our votes are veto-able? Joerg
Re: java continuations
Joerg Heinicke wrote: On 29.03.2004 21:02, Sylvain Wallez wrote: If the vote majority will shift to another name instead of javaflow we can still move it around. If Carsten does not insist on his -1 including a removal I would let it at the place where it is at the moment. Uh? If it's a majority vote, then can Carsten's -1 be considered as a veto? In which cases our votes are veto-able? http://incubator.apache.org/learn/voting.html I guess this falls under code modification ? Joerg Tony
Re: java continuations
Carsten Ziegeler wrote: snip We only want to have one flow implementation (language), which is Javascript. If we put the Java version as a block in our CVS, it immediately looks like that if we would have two and more implementations or even worse, that the JavaScript implementation was a mistake. And then the confusion about Which one should I use?, Which one is better?, How long is the JavaScript impl. supported? etc. starts. And I would really like to avoid this. I've been disconnected for a couple months, when was it decided that we only want to have one flow implementation ? Additionally, I can't see how it would be confusing if we put it in a block, mark it unstable and experimental, and put a note stating clearly so, since that's precisely what it is. It's ok for me, to evaluate the Java Continuations and decide later which version to support (with a clear migration path if required), so I would prefer to put it somewhere else (sf, cocoondev etc.). If everyone else wants to have it directly in our cocoon cvs then I would prefer the scratchpad block. IMO the best way to evaluate it and see if it's worthwhile is exactly by putting it in our CVS, so I can't see any problem housing it in the scratchpad. If it becomes strong enough on its own to become a separate project, then I would not have any qualms about wanting to move the Java continuations stuff to SF or a separate project housing place. Carsten Tony
Re: java continuations
Joerg Heinicke dijo: On 29.03.2004 20:39, Stephan Michels wrote: Hmm, 4h for a vote was a bit short, wasn't it? So just for the records: I'm with Antonio and so like JFlow vs. JSFlow. I know, I know, sorry about that, guys. I was very impatient. I could revert it if you want. Not because of my comment. If the vote majority will shift to another name instead of javaflow we can still move it around. If Carsten does not insist on his -1 including a removal I would let it at the place where it is at the moment. I am with Carsten too. Note he is just against the right place to put it. That is all. Think in newbies. You will see a big neon: JavaFlow inside blocks and none telling you JavascriptFlow. Also BTW, If one will be called JavaFlow, then the over must be called using the ugly large name: Javascriptflow. This is why I prefer: JFlow and JSFlow. Best Regards, Antonio Gallardo
Re: java continuations
Le 29 mars 04, à 19:05, Sylvain Wallez a écrit : ...Now what should go in that block: the _flow_ implementations, or the class enhancer? I would stay that only the flow implementation has its place inside Cocoon's CVS. But finding a more suitable place for the enhancer (BCEL, jakarta-commons, codehaus?) may take some time, and we may temporarily host in in the javaflow block... +1, the base continuations stuff certainly deserves a separate distribution. But there's no hurry, it can live here for a while. ...Some people will love JS and be frightened by Java, and some others won't consider writing code using a language other than Java... Agreed, but I still think the official focus should be on *one* Flow language. It seems like we all agree to declare the java Flow experimental for now, but we must be careful about the user's perception (which is reality ;-), by putting big EXPERIMENTAL STUFF signs where needed. ...Ah, and would it be possible to use the class enhancer to enable continuations in a compiled (as in .class) JS script? This may help us solving the current Rhino issues... This sounds interesting but I don't get it, can you elaborate about the compiled JS part? Do you mean using our own JS compiler? At runtime? -Bertrand
Re: Java continuations
Torsten Curdt wrote: ...but java continuations with the compiling classloader sounds pretty cool to me :) I agree. I would also like to try out Groovy or Jython... but I do have fears on diverging too much. I mean: do you guys think we really got the point where we understand what we want to do with continuations? Do you guys want me to push this a little more again? I would like to have a discussion on where do we stand research-wise on the flow with continuations concept, before trying to attach what syntax should we use. I mean, it would be totally cool if we had - javascript - java - groovy - python and then, just like we did with Woody, we would standardize on one. But I still feel this is too early to do, I mean, we already have to sell the concept and we don't want to spoil our own marketing by early-diversifying that much. This said, I see nothing wrong in starting a continuations for java project, say under jakarta, that would glue together people from cocoon and groovy (potentially rhino and jython too!). This can totally happen in parallel. And, if anything comes out, put it in the scratchpad for people to try out. I mean, stabilizing is good, but we don't want to stop innovating either ;-) In media stat virtus. -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: Java continuations with joeq
Bertrand Delacretaz wrote: Le Samedi, 21 fév 2004, à 17:13 Europe/Zurich, Christopher Oliver a écrit : ...I did some informal tests and it appears to actually be slower than interpreted Rhino (not sure exactly why, perhaps because Rhino bytecodes are higher level), but was significantly faster than BeanShell (which is a Java source code interpreter). Is it a lot slower, do you think it would make a significant difference? My opinion: probably not. However, I just thought of another drawback with using Joeq's interpreter, namely you wouldn't be able to debug it with a standard Java debugger. The Brakes-like approach doesn't have this limitation. In addition, since that approach simply modifies the bytecode it would still be optimized by Hotspot and would still outperform any scripting language. Torsten, what's the status of your work on this? Chris
Re: Java continuations with joeq
Christopher Oliver wrote: Bertrand Delacretaz wrote: Le Samedi, 21 fév 2004, à 17:13 Europe/Zurich, Christopher Oliver a écrit : ...I did some informal tests and it appears to actually be slower than interpreted Rhino (not sure exactly why, perhaps because Rhino bytecodes are higher level), but was significantly faster than BeanShell (which is a Java source code interpreter). Is it a lot slower, do you think it would make a significant difference? My opinion: probably not. However, I just thought of another drawback with using Joeq's interpreter, namely you wouldn't be able to debug it with a standard Java debugger. The Brakes-like approach doesn't have this limitation. In addition, since that approach simply modifies the bytecode it would still be optimized by Hotspot and would still outperform any scripting language. Torsten, what's the status of your work on this? Chris Slight correction: the current implementation of Brakes does indeed have this limitation - it discards debugging info during class file enhancement - that would have to be fixed to make it truly usable, in my opinion. Chris
Re: Java continuations with joeq
Le Samedi, 21 fév 2004, à 17:13 Europe/Zurich, Christopher Oliver a écrit : ...I did some informal tests and it appears to actually be slower than interpreted Rhino (not sure exactly why, perhaps because Rhino bytecodes are higher level), but was significantly faster than BeanShell (which is a Java source code interpreter). Is it a lot slower, do you think it would make a significant difference? 2) It has an LGPL license. Means we might have to talk its author into changing the license, it wouldn't be the first one ;-) Note also an interesting comment of Geert Bevin on Steven's weblog at http://blogs.cocoondev.org/stevenn/archives/001745.html, he says I'll soon have added support for continuations with Groovy in RIFE too From what I've seen Groovy looks like a very nice and fairly complete scripting language, which also has an ASF-like license. So, if Groovy is really close to have continuations, we might want to wait or help? The only mention of continuations that I found on the groovy mailing lists is at http://thread.gmane.org/gmane.comp.lang.groovy.devel/298 -Bertrand
RE: Java continuations with joeq
From: Bertrand Delacretaz Le Samedi, 21 fév 2004, à 17:13 Europe/Zurich, Christopher Oliver a écrit : ...I did some informal tests and it appears to actually be slower than interpreted Rhino (not sure exactly why, perhaps because Rhino bytecodes are higher level), but was significantly faster than BeanShell (which is a Java source code interpreter). Is it a lot slower, do you think it would make a significant difference? 2) It has an LGPL license. Means we might have to talk its author into changing the license, it wouldn't be the first one ;-) Note also an interesting comment of Geert Bevin on Steven's weblog at http://blogs.cocoondev.org/stevenn/arch ives/001745.html, he says I'll soon have added support for continuations with Groovy in RIFE too From what I've seen Groovy looks like a very nice and fairly complete scripting language, which also has an ASF-like license. So, if Groovy is really close to have continuations, we might want to wait or help? The only mention of continuations that I found on the groovy mailing lists is at http://thread.gmane.org/gmane.comp.lang.groovy.devel/298 Since Cocoon supports continuations they seem to attract more and more interest in the web development world ;-) Anyway, for me only **Java** Flowscript would really make sense because this would safe the two (technical) arguments against JavaScript flow: Java is type safe and it is compiled. So you can catch (some) errors at compile time and not at run time. If there is support for Groovy, Pyhton, [or whatever] continuations, I personally don't care because it doesn't make a real difference (languages are a matter of taste ...) and I don't think we should spread our energy over different Flowscript interpreter implementations which have to be maintained. Only my 2 cents ... -- Reinhard
Re: Java continuations with joeq
On 21 Feb 2004, at 17:48, Reinhard Poetz wrote: Since Cocoon supports continuations they seem to attract more and more interest in the web development world ;-) Which proves Ovidiu's visionary skills. We owe him a great deal because of this. /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source Java XMLAn Orixo Member Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Re: Java continuations with joeq
Reinhard Poetz wrote: If there is support for Groovy, Pyhton, [or whatever] continuations, I personally don't care because it doesn't make a real difference (languages are a matter of taste ...) and I don't think we should spread our energy over different Flowscript interpreter implementations which have to be maintained. Well, we actually have to maintain a non-current forked version of Rhino (even if pretty stable actually), so I'd much rather change my taste (I quite like Javascript flow actually) if that buys me a more hassle-free continuation engine. Ciao, -- Gianugo Rabellino
RE: Java continuations with joeq
From: Gianugo Rabellino Reinhard Poetz wrote: If there is support for Groovy, Pyhton, [or whatever] continuations, I personally don't care because it doesn't make a real difference (languages are a matter of taste ...) and I don't think we should spread our energy over different Flowscript interpreter implementations which have to be maintained. Well, we actually have to maintain a non-current forked version of Rhino (even if pretty stable actually), so I'd much rather change my taste (I quite like Javascript flow actually) if that buys me a more hassle-free continuation engine. Point taken, but we released Cocoon 2.1 half a year ago. Let's say we manage adding support for e.g. a GroovyFlowInterpreter and declare it as stable let's say in half a year. Firstly, I think this move would be very confusing for our user base. Secondly, I think somebody will come up with a JavaFlow implementation sooner or later. Let's say this happens in 18 months. This would mean we release an 'official flow implementation' every year ... -- Reinhard
RE: Java continuations with joeq
From: Gianugo Rabellino Reinhard Poetz wrote: If there is support for Groovy, Pyhton, [or whatever] continuations, I personally don't care because it doesn't make a real difference (languages are a matter of taste ...) and I don't think we should spread our energy over different Flowscript interpreter implementations which have to be maintained. Well, we actually have to maintain a non-current forked version of Rhino (even if pretty stable actually), so I'd much rather change my taste (I quite like Javascript flow actually) if that buys me a more hassle-free continuation engine. Point taken, but we released Cocoon 2.1 half a year ago. Let's say we manage adding support for e.g. a GroovyFlowInterpreter and declare it as stable let's say in half a year. Firstly, I think this move would be very confusing for our user base. Secondly, I think somebody will come up with a JavaFlow implementation sooner or later. Let's say this happens in 18 months. This would mean we release an 'official flow implementation' every year ... -- Reinhard
Re: Java continuations with joeq
On 21 Feb 2004, at 19:24, Gianugo Rabellino wrote: Well, we actually have to maintain a non-current forked version of Rhino (even if pretty stable actually), so I'd much rather change my taste (I quite like Javascript flow actually) if that buys me a more hassle-free continuation engine. I'm two of a kind on this: at the very least, JavaScript is a well-known standardized language, and looking at other uses of Rhino, it is a well-known and robust library. Too bad about the fork unfortunately. Groovy might have more sensible bindings with the Java language, it looks cool, but it's still a little language ATM. Then again, the expression language we use in Woody is a little language as well. Overall, I sense an interest to opt for ASF packages whenever possible. Both Rhino++ and Groovy aren't (c) ASF, so that point is moot. /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source Java XMLAn Orixo Member Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Re: Java continuations with joeq
On Feb 21, 2004, at 2:47 PM, Steven Noels wrote: Overall, I sense an interest to opt for ASF packages whenever possible. Both Rhino++ and Groovy aren't (c) ASF, so that point is moot. Umh... continuations in PHP or Jelly. That covers Apache (c) languages available ;-) -Brian
RE: Java continuations with joeq
Reinhard Poetz dijo: Since Cocoon supports continuations they seem to attract more and more interest in the web development world ;-) This is great! This means Cocoon is the leader in webapp development! :-DD Anyway, for me only **Java** Flowscript would really make sense because this would safe the two (technical) arguments against JavaScript flow: Java is type safe and it is compiled. So you can catch (some) errors at compile time and not at run time. But it can be abused too. This is one of the plus we found a year ago. comment AFAIK, the initial wisdom started with scheme, then we switched to javascript (thanks to Christian Oliver). All is documented in the 1 year of development in maillists. After Flow development reached a milestone, people started to comment about the pros and cons of using Javascript. Here is a interesting mail of these times (from Stefano): http://marc.theaimsgroup.com/?l=xml-cocoon-devm=105284906231855w=2 The full thread is here: http://marc.theaimsgroup.com/?t=10527582916r=1w=2 /comment Now we have a year of Flow in Cocoon and based on our experience with Flow it is time to think how to improve it. I am not sure if Java is the best. Sometimes I will like to have the power of the eclipse IDE to debug my show flows, but In short I think this is a very interesting discusion that for sure will bring Flow to the next level. Best Regards, Antonio Gallardo
Re: Java continuations with joeq
Stefano Mazzocchi wrote: Brian McCallister wrote: Umh... continuations in PHP or Jelly. That covers Apache (c) languages available ;-) Correction: as of a few days ago, PHP is no more a project of the ASF :-) Interesting... I always wondered why PHP is sooo non-Apache... Neither Apache front page nor PHP yet got updated with these news. Vadim
