You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Christopher Oliver <re...@verizon.net> on 2004/02/21 17:13:24 UTC
Java continuations with joeq
I recently took a look at joeq (http://joeq.sourceforge.net/) which is a
Java virtual machine written in Java. Included is a "reflective" Java
interpreter that can run on top of an existing Java virtual machine
(e.g. Sun JRE). It can interpret class files, but can also delegate some
(or all) method calls to the underlying VM as well. It looks like it
would be quite easy to support Java language continuations with this
interpreter. There are some drawbacks however:
1) In order to be included in a continuation a method call must be
interpreted by joeq - not by the underlying VM (= severe performance
penalty. Probably at least 15 to 20 times slower than hotspot compiled
code). Although the joeq interpeter is very high quality, 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).
2) It has an LGPL license.
Chris
Re: Java continuations
Posted by Stefano Mazzocchi <st...@apache.org>.
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.
Java continuations (was: with joeq)
Posted by Torsten Curdt <tc...@vafer.org>.
> 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?
Since my proof-of-concept nothing much happend regarding the code.
I prepared a block that is sitting on my disk.
I talked to the brakes guys and was supposed to get an official
"go" around christmas. I haven't heard anything yet and have to
admit I did not press on this anymore. Maybe it's not even necessary
but I'd prefer to be save on such legal aspects.
I also talked to James Strachan and the guy from RIFE. We thought
it would be a good idea to share the efforts and create general
java continuations project until java might get native continuations.
We could also (at least) try to push this a little. But this also
stalled probably due to the lack of time.
Although quite some people contacted me in private on this subject
I thought we (cocoon) decided to go the javascript way and not create
too many options in this area.
...but java continuations with the compiling classloader sounds
pretty cool to me :)
Do you guys want me to push this a little more again?
cheers
--
Torsten
Re: Java continuations with joeq
Posted by Christopher Oliver <re...@verizon.net>.
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
Posted by Christopher Oliver <re...@verizon.net>.
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
Posted by Christopher Oliver <re...@verizon.net>.
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?
>
>> 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?
>
Groovy itself doesn't have any support for continuations. In RIFE this
is provided by the RIFE framework (however, RIFE doesn't appear to
support general continuations in Java).
Chris
RE: Java continuations with joeq
Posted by Antonio Gallardo <ag...@agssa.net>.
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-dev&m=105284906231855&w=2
The full thread is here:
http://marc.theaimsgroup.com/?t=105275829100006&r=1&w=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
Posted by Antonio Gallardo <ag...@agssa.net>.
Steven Noels dijo:
> 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.
+1
Best Regards,
Antonio Gallardo
Re: Java continuations with joeq
Posted by Steven Noels <st...@outerthought.org>.
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 Noels http://outerthought.org/
Outerthought - Open Source Java & XML An Orixo Member
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
Re: Java continuations with joeq
Posted by Vadim Gritsenko <va...@reverycodes.com>.
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
Re: Java continuations with joeq
Posted by Stefano Mazzocchi <st...@apache.org>.
Brian McCallister wrote:
>
> 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 ;-)
Correction: as of a few days ago, PHP is no more a project of the ASF :-)
--
Stefano.
Re: Java continuations with joeq
Posted by Brian McCallister <mc...@forthillcompany.com>.
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
Posted by Steven Noels <st...@outerthought.org>.
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 Noels http://outerthought.org/
Outerthought - Open Source Java & XML An Orixo Member
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
RE: Java continuations with joeq
Posted by Reinhard Poetz <re...@apache.org>.
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
Posted by Reinhard Poetz <re...@apache.org>.
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
Posted by Gianugo Rabellino <gi...@apache.org>.
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
Posted by Reinhard Poetz <re...@apache.org>.
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
Posted by Bertrand Delacretaz <bd...@apache.org>.
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