I built a fairly complex app in vert.x a few years back. If you don't start with a promises library off the bat, you end up in a callback hell not unlike node.js.
You also realize very quickly how synchronous many of the Java libraries for things like databases, redis, etc are. The ecosystem just isn't built to work like that, but that's not the fault of the vert.x guys.
Vert.x provides the things like databases, redis, too. And no I don't use Vert.x
However in Java it isn't that hard anymore to make a Sync Library Async, especially JDBC. Thanks to CompletableFuture on Java8, the problem is, is that not lot's of companies are on Java8, however if you are using vert.x that shouldn't be the case.
Libraries in Java are mostly Synchronous cause people use Java4, Java5, Java6, Java7 and not Lambda's and Futures. I mean there are really libraries out there who providing Java4 support. They provided Java3 Support until the end of 2014.. Especially Libraries who are generating content are having backwards compability to the beginnings.
Edit: Oh and the Vert.x JDBC Client is a wrapper around JDBC with RxJava / Future's. Which is basically the best thing you could do.
Edit2: Oh and what I dislike more than synchronous code is code that has getters and setters, since that makes it hard to wrap a library into a thread pool since mutable data isn't a nice thing to deal with inside a async fashion. However it was traditional to have getter and setter classes . But more and more this isn't the case for newer things.
> However in Java it isn't that hard anymore to make a Sync Library Async
Not necessarily true. Sure you can create a set of worker threads that take requests, process them synchronously, and hand stuff back but that's going to inflate your thread count and it's nowhere as optimal as writing a library that is async-aware from the first line of code.
On top of that, lots of Java code assumes that you'll be making various sequenced calls from the same thread. You'll find that libraries will randomly corrupt data or return stale reads if they haven't been synchronized properly. Many protocols (ie: Redis) have built-in pipelining that isn't used in sync libraries.
Your comment would have been upvote-worthy had you simply left this bit of snark out. How on earth do you think this is a decent thing to say to someone you do not know?
It's been a while since I've seen that code, but we used an external promises library and wrote some utility functions to make it easier to work with vert.x code.
I also highly recommend using JDK8's closures to reduce the boilerplate.
In some ways. Verticles can sort-of be analogized to individual node.js processes. The underlying service bus, however, is tremendously helpful and well-designed and, IMO, the real reason to use it.
The choices for me for my current project were vert.x or Dropwizard; I went with Dropwizard for now for ease of early development, but I've structured it so that I could fairly easily convert my Jersey resources (structured themselves as completely separate modules inside a monolithic application) into vert.x verticles.
Vert.x indeed looks pretty cool. But I found it a little bit weird that they used the term "reactive" in the title, but I'm not sure what the "reactive" is referring to: maybe Reactive Extensions, or at least RxJava? which should be perfect with vert.x to solve the callback hell problem. Or they just use it as a generic term for async technology used in vert.x/node.js/tornado etc?
So is what we know of as "async" and "non-blocking". The point is that instead of spinning up many blocking threads, a single select/poll/epoll() call triggers a set of callbacks.
ah, thanks for the explanation... I guess we probably need a "new_cool_term" namespace for every new/re-purposed term. Simply use "reactive" to refer to "async" already caused a name collision for me here....
It's not a direct replacement for asynchronous, as reactive implies quite a different set of semantics. The collision is only in your misunderstanding of the pattern. The jargon is meaningful, not marketing.
Good to know. Then the "reactive" mentioned in the title is not exactly async, and not exactly as in "Reactive Extensions" either, so where can I find the intended meaning of "reactive" in that context?
What's weirder is the fact that they used the name Vert.x, which sounds like "vertex" in my head, which doesn't seem to have anything to do with what this library is trying to accomplish.
You also realize very quickly how synchronous many of the Java libraries for things like databases, redis, etc are. The ecosystem just isn't built to work like that, but that's not the fault of the vert.x guys.