DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=29308>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=29308 issue with javaflow continuations ------- Additional Comments From [EMAIL PROTECTED] 2004-06-02 04:25 ------- why is it failing if it is not an inner class but just a package class (not public) as outlined in the first code sample in initial bug report ? I would favour your idea of using a regular expression in class loader to determine which classes need to be instrumented. This is because, if an end client is using the continuations based third party set of classes, it will be really difficult for him to determine which classes needs continuations and which dont. Although it is inefficient perf wise, still it is worth the convenience. It would be nice if sun folks realize the importance of continuations and provide a framework to transparently migrate the current stack and program counter for execution. I am toying with the idea of using this continuation framework with Java NIO so that we can get seemless transparent asynchronous I/O framework with programmer coding sequentially. This way, we can emulate a socket which is internally asynchronous but for outside world, might appear blocking. Although there is a hidden cost of continuation stack capture etc.,. if we code the I/O framework sensibly (doing enough buffering in async I/O layer before passing the control back to program), the programming convenience outweighs the performance drop a lot.
