Trickle: Spotify's library for composing asynchronous code in Java

https://github.com/spotify/trickle

by jyrki • 12 years ago

47 15 12 years ago

github.com

maaaats• 12 years ago

This looks promising. The syntax is a bit clunky, however. How would this look with Java8 and lambdas?

puzanop• 12 years ago

sexy

thescrewdriver• 12 years ago

Probably a lot like http://docs.scala-lang.org/sips/completed/futures-promises.h...

acjohnson55• 12 years ago

Agreed, it looks super clunky. Even JS feels clunky for me at times for async stuff, compared to, say CoffeeScript. But I suppose it's possibly the case that async isn't used as much in Java, compared to its ubiquity in the browser.

davedx• 12 years ago

I much prefer the Android Annotations [1] approach to asynchronous functions, but I'm not sure they are solving exactly the same problem. Can anyone comment?

[1] https://github.com/excilys/androidannotations/wiki/WorkingWi...

fharper1961• 12 years ago

I think they address different use-cases.

AA is for simple UI related asynchronous calls.

While this lib is for complicated nested asynchronous calls. On Android a good example would be in app purchases. To consume an IAP there's an async call to connect to Google Play, followed by an async call to query inventory, followed by an async call to consume the item. It gets hairy fast!

bkirwi2• 12 years ago

I can comment!

I'm not very familiar with Android Annotations, but they seem to be primarily a way to shuffle some processing to a background thread. All those methods return `void`, so if that method wants to return some results (or failures) to the caller, it needs to find some other mechanism to do so. It's not impossible, but it's bound to be more inconvenient than a plain old return value.

A common solution is to return what Trickle calls a `ListenableFuture`. The method can do any amount of async processing (on a background thread, or using async I/O, or whatever) and eventually will 'populate' that future with a value. You can test if that value has been set at any time, or add a callback to be called when the future completes / fails.

The problem with that solution comes when you're dealing with multiple APIs, and need the results of some as inputs to others. (This is commonly known as 'callback hell'.) Trickle's solution to this is to make you define the information-flow graph explicitly, and it does all the shuttling-of-intermediate-results around for you. It seems like an improvement, but I much prefer the RxJava / Akka approach to this, since the types are checked and error handling is more explicit and convenient.

mattgreenrocks2• 12 years ago

Nice write-up.

I'm surprised people don't mind chaining together the information flow like this; it feels more like the runtime should do this sort of leg work. I understand why you'd do this on servers, but not as much on clients. Why not tie up a worker thread waiting for these things?

foreigner• 12 years ago

... or just use NodeJS instead.

mabufo• 12 years ago

...to compose async code in Java?

landakram• 12 years ago

I'm curious — how does this deal with errors in async calls? RxJava has error handling built in with `onError` functions.

pettermahlen• 12 years ago

Trickle has a similar concept - you can add a 'fallback' to a node: https://github.com/spotify/trickle/blob/master/src/examples/...

l3nz• 12 years ago

Interesting idea, but my eyes bleed. And I'm a Java programmer. Would rather use Akka or SlicedBread (the latter trading almost all features for the added simplicity but working well and being super-simple).

Trickle: Spotify's library for composing asynchronous code in Java

Related Stories