8 ms·

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

47 points by jyrki 13y ago

davedx 13y 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/WorkingWithThreads https://github.com/excilys/androidannotations/wiki/WorkingWi...
- fharper1961 13y 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!
- bkirwi 13y 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.
  - mattgreenrocks 13y 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?
    - bkirwi 13y ago
      I agree, you're unlikely to feel the need for this when threads are cheap and blocking is OK. (For some client environments, like JavaScript, that's not the case: which is why you see so many similar things in that space, like promises and bacon.js.) Though in some languages the syntax is light enough that it's actually more convenient to do in in the nonblocking style; Scala has a good story here, and C#'s async/await seems perhaps even cleaner.
      - mattgreenrocks 13y ago
        That's what pains me about JS: there's this meme of being unable to use threads, but it's OK, because threads are bad and scary. Thus, promises must be good. Async/await is beautiful: compiler produces CPS, but logical control flow remains exactly as you'd expect. One slight reservation: the async specifier seems to pollute the entire call tree of otherwise un-related code.
deleted 13y ago
[deleted]
maaaats 13y ago
This looks promising. The syntax is a bit clunky, however. How would this look with Java8 and lambdas?
- puzanop 13y ago
  sexy
- thescrewdriver 13y ago
  Probably a lot like http://docs.scala-lang.org/sips/completed/futures-promises.html http://docs.scala-lang.org/sips/completed/futures-promises.h...
- acjohnson55 13y 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.
foreigner 13y ago
... or just use NodeJS instead.
- mabufo 13y ago
  ...to compose async code in Java?
- deleted 13y ago
  [deleted]
landakram 13y ago
I'm curious — how does this deal with errors in async calls? RxJava has error handling built in with `onError` functions.
- pettermahlen 13y ago
  Trickle has a similar concept - you can add a 'fallback' to a node: https://github.com/spotify/trickle/blob/master/src/examples/java/com/spotify/trickle/example/Examples.java#L155 https://github.com/spotify/trickle/blob/master/src/examples/...
l3nz 13y 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).

47 points by jyrki 13y 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/WorkingWithThreads https://github.com/excilys/androidannotations/wiki/WorkingWi...

fharper1961 13y 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!
bkirwi 13y 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.
- mattgreenrocks 13y 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?
  - bkirwi 13y ago
    I agree, you're unlikely to feel the need for this when threads are cheap and blocking is OK. (For some client environments, like JavaScript, that's not the case: which is why you see so many similar things in that space, like promises and bacon.js.) Though in some languages the syntax is light enough that it's actually more convenient to do in in the nonblocking style; Scala has a good story here, and C#'s async/await seems perhaps even cleaner.
    - mattgreenrocks 13y ago
      That's what pains me about JS: there's this meme of being unable to use threads, but it's OK, because threads are bad and scary. Thus, promises must be good. Async/await is beautiful: compiler produces CPS, but logical control flow remains exactly as you'd expect. One slight reservation: the async specifier seems to pollute the entire call tree of otherwise un-related code.

deleted 13y ago

[deleted]

maaaats 13y ago

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

puzanop 13y ago
sexy
thescrewdriver 13y ago
Probably a lot like http://docs.scala-lang.org/sips/completed/futures-promises.html http://docs.scala-lang.org/sips/completed/futures-promises.h...
acjohnson55 13y 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.

foreigner 13y ago

... or just use NodeJS instead.

mabufo 13y ago
...to compose async code in Java?
deleted 13y ago
[deleted]

landakram 13y ago

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

pettermahlen 13y ago
Trickle has a similar concept - you can add a 'fallback' to a node: https://github.com/spotify/trickle/blob/master/src/examples/java/com/spotify/trickle/example/Examples.java#L155 https://github.com/spotify/trickle/blob/master/src/examples/...

l3nz 13y 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).