I'm assuming you are referring to the guava ListenableFuture<http://docs.guava-libraries.googlecode.com/git-history/release/javadoc/com/google/common/util/concurrent/ListenableFuture.html>. This is the first time I've see this library, but it definitely looks like it would work. The goal of the guice-asynchronous<https://code.google.com/p/guice-asynchronous/> extension is to completely (or mostly) abstract away the cross-cutting concern of making asynchronous calls. A method can be asynchronized by simply marking it with the @Asynchronous annotation. Callbacks and Futures still need to be used to return values, but it looks like that's true with the ListenableFuture<http://docs.guava-libraries.googlecode.com/git-history/release/javadoc/com/google/common/util/concurrent/ListenableFuture.html> too.
Thank you for showing me the ListenableFuture<http://docs.guava-libraries.googlecode.com/git-history/release/javadoc/com/google/common/util/concurrent/ListenableFuture.html> :) I'll probably use it until I get this project out the door. BTW, I like your avatar... new doctor this Christmas! On Monday, August 12, 2013 10:21:23 AM UTC-7, Joshua Ball wrote: > > There are at least two approaches to asynchronous programming. One is your > approach: void methods that take a continuation. An alternative approach is > to return ListenableFutures from your methods. In the alternative approach, > AOP is very straightforward. For example, you can catch Throwables and > stick them inside the futures that are returned. > > > On Mon, Aug 12, 2013 at 10:08 AM, Sam Berlin <[email protected]<javascript:> > > wrote: > >> Can you maybe describe what you're doing and what you're looking to do in >> more detail? I don't totally understand what you're asking. >> >> sam >> >> >> On Mon, Aug 12, 2013 at 1:07 PM, Isaiah van der Elst < >> [email protected] <javascript:>> wrote: >> >>> Hi, >>> >>> I'm working on an extension, >>> guice-asynchronous<https://code.google.com/p/guice-asynchronous/>, >>> that allows for asynchronous method calls. Currently the framework uses the >>> Elements SPI mechanism to hijack bindings. I'm not really a fan for this >>> approach. I'd rather have a module that applies the behavior without any >>> sort of hijacking. The problem is that I can't get the interceptor bindings >>> & matchers from within a module. How hard would it be to get a binding >>> listener into v4.0? If I found the time to implement it, what's the >>> probability that it would actually end up in v4.0? >>> >>> thanks :) >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "google-guice" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected] <javascript:>. >>> To post to this group, send email to [email protected]<javascript:> >>> . >>> Visit this group at http://groups.google.com/group/google-guice. >>> For more options, visit https://groups.google.com/groups/opt_out. >>> >>> >>> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "google-guice" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <javascript:>. >> To post to this group, send email to [email protected]<javascript:> >> . >> Visit this group at http://groups.google.com/group/google-guice. >> For more options, visit https://groups.google.com/groups/opt_out. >> >> >> > > -- You received this message because you are subscribed to the Google Groups "google-guice" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/google-guice. For more options, visit https://groups.google.com/groups/opt_out.
