Mailing-List: contact user-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Users List" <user@commons.apache.org>
Received-SPF: pass (athena.apache.org: local policy)
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: javaflow & aranea continuations
Date: Fri, 29 Aug 2008 09:56:46 -0700
Message-ID: <22C5A81B3491F241BF9447DC9C79E24D0778DC3C@modmsx011.network.local>
Thread-Topic: javaflow & aranea continuations
Thread-Index: AckJWlCrb/trInKBRdGi+q62gIjWPAAmSt0A
References: <30677473.499834.1219849272854.JavaMail.root@elysia.void.it>
 <B432809C-84C5-46E2-8585-3F0ACBA8F5D2@apache.org>
From: "Spies, Brennan" <Brennan.Spies@ejgallo.com>
To: "Commons Users List" <user@commons.apache.org>

Torsten,

You sound a little discouraged.=20

As someone who is trying to get my own project off the ground, I can
sympathize a bit with you. It's a lot of work. I can't speak for you, =
but my
own motivation is the challenge of the task itself. I'm scratching an =
itch,
if you will, to build a little cooler mouse trap.

As for javaflow, I suspect that continuations on the JVM are going to =
become
very important very soon. John Rose has added an initial implementation
(http://blogs.sun.com/jrose/entry/continuations_in_the_vm) of it in the
OpenJDK (of course, there is still no language support in Java, but =
other
languages...), but this still leaves a gaping JSE 5.0 and 6.0-sized hole =
to
be filled. With the advent of Comet/Reverse Ajax and the planned =
asynchronous
API in Servlet 3.0, continuations become the "right way" of handling =
this. I
haven't delved too much into the current asynchronous implementations in
Tomcat or Jetty, but my understanding is that they are based on
exceptions--not really continuations at all, but a pretty weak =
imitation.

Honestly, I am surprised that the Tomcat or Jetty team (or any other =
Java app
server) has not shown interest in javaflow. It seems to me that it would =
be
in their best interest. The only sticking point I can think of is the =
ability
to control the depth of the call stack that is saved (perhaps an idea =
for a
feature here?).

Anyway, keep up the good work.

Regards,

Brennan


-----Original Message-----
From: Torsten Curdt [mailto:tcurdt@apache.org]=20
Sent: Thursday, August 28, 2008 3:05 PM
To: Commons Users List
Subject: Re: javaflow & aranea continuations

Hey Stefano

> I've discovered this cool stuff only few days ago and I browsed a =20
> lot the web searching for info and now I'm here ;-)
>
> I didn't find aranea-continuations mentioned in javaflow, but I =20
> think it is a very interesting abstraction layer on top of javaflow, =20
> it is pretty generic (core is generic, then they have specific stuff =20
> for swing and their mvc framework) and it is Apache "ALv2" Licensed.

I didn't hear about that before.

> I read this:
> http://svn.apache.org/repos/asf/commons/sandbox/javaflow/trunk/TODO
> but it seems a bit outdated (asm support marked as "maybe" seems to =20
> be there, the BCEL issues seems fixed following rhe links)... =20
> Running the tests seems that ASM and BCEL enhancer have the same =20
> quality level, but I may be missing something as I simply looked at =20
> test results.

Well, the ASM enhancer should still be considered experimental. And =20
someone reported it to be much slower than the BCEL one.
(Which is a bit of a surprise) Still I would love to see ASM being =20
used as the main engine. Just because the library has a much better =20
community.

> I see there is no action around javaflow in the last year: is this =20
> because of critical issues with its continuation approach or simply =20
> lack of interest?

Well, I don't really use it at work anymore. And rarely people even =20
just gave feedback. Not talking about any contributions. Especially =20
when in the end I hear about people using it in their PhD thesis or =20
some cool projects I am a little in between. "Cool!" and "WTF didn't =20
you show up on the mailing lists". It's too much work if you don't get =20
paid for it and don't even use it. Plus I am not a big fan of one man =20
shows.

> About "talk to the RIFE guys"/"talk to the aspectwerkz and aspectj =20
> folks", did anything happen?

I only have talked briefly with Geert. He was considering changing the =20
license and working together on it. While it is not as generic as =20
javaflow he is happy with his implementation. So I guess I just did =20
not have enough energy following up on this.

> I didn't find too much activity (docs/webpages) around RIFE =20
> continuations or any of the above and even about the JSR proposal.

Geert did file the JSR proposal though. Unfortunately it got rejected. =20
Even from the ASF. Which really annoyed me a little. But anyway.

> I checked out the sources with eclipse and enabled m2eclipse, the =20
> only issue I found is that the main pom references commons-jci-core:=20
> 1.0-SNAPSHOT. I see commons-jci-core:1.0 has been released so I =20
> removed "-SNAPSHOT" and it succesfully built.

Nice

> I found at least a couple of projects around using self compiled =20
> javaflow libraries so it seems that even if it is incomplete it is =20
> useful to the world. Is there any motivation against making a 0.1 =20
> release in commons or is it simply lack of time?

A few people asked for a release. But I didn't know about so many =20
projects using it. (Guess I know about 3-4 projects plus a couple of =20
PhD thesis). I would be happy to follow up and do a release. But there =20
are a couple of things that I would like to see fixed before you =20
finalize and commit to an API. And that's still quite a bit of work.

> Indeed JavaFlow is cool stuff!

Thanks :)

cheers
--
Torsten

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org