4 ms·

I've been using http://vertx.io http://vertx.io pretty heavily in the last few months, and rather enjoying it. It's an asynchronous I/O framework that wraps the

I've been using http://vertx.io http://vertx.io pretty heavily in the last few months, and rather enjoying it. It's an asynchronous I/O framework that wraps the powerful NIO and Netty infrastructure with some elegant APIs and design patterns. It does a bunch of other things as well, but digging through the code, those are the concepts that will jump out at you. Vert.x is a decidedly "modern" Java codebase; it's written in a decidedly different style from "traditional" enterprise Java. From the build tooling (Gradle) to the use of callbacks and delegation, you'll find it a bit refreshing. I'd recommend thinking about how you would use other patterns or structures in concert with Vert.x as well, as that will get you thinking about architectures. Exploring its model of concurrency in concert with Java concurrency tools is a must; some of my favorite Vert.x code mixes its reactor with Grand Central Dispatch-like threadpools and clever message passing. I've really enjoyed working with Vert.x. It's not without warts, but I feel like the code I've written around it represents a great advance in my Java style.

eip 14y ago
I have to use vertx for work. It's not my favorite. It's not Maven friendly. It's not Spring friendly. Callback spaghetti is hard to read and maintain. It uses it's own half baked messaging framework instead of something more powerful like AMQP. The documentation is confusing and often times self contradictory. ("Worker verticles use threadpools" vs "All verticles are strictly single threaded") It encourages message passing and queuing even when it doesn't make sense. That leads to code that is very hard to understand and even harder to debug. It uses Hazelcast for in memory datagrid but doesn't explain it at all in the docs. It also doesn't expose any of the useful Hazelcast APIs. So unless you are already familiar with Hazelcast you will miss most of its benefits. I think Spring Integration is a much better solution to the problems vertx tries to solve. That fact that vertx tries to be polyglot friendly doesn't really seem like a benefit to me either. Just makes feature development much slower.
- voidlogic 14y ago
  spartango: "Vert.x is a decidedly "modern" Java codebase" eip: "[Vert.x] Callback spaghetti is hard to read and maintain." My take, "modern" = like node.js = Callback spaghetti = hard to read and maintain Of course this is coming from someone who hates callbacks, javascript and has ported node.js apps to Go and finds them faster and more maintainable in that form.

eip 14y ago

I have to use vertx for work. It's not my favorite. It's not Maven friendly. It's not Spring friendly. Callback spaghetti is hard to read and maintain. It uses it's own half baked messaging framework instead of something more powerful like AMQP. The documentation is confusing and often times self contradictory. ("Worker verticles use threadpools" vs "All verticles are strictly single threaded") It encourages message passing and queuing even when it doesn't make sense. That leads to code that is very hard to understand and even harder to debug. It uses Hazelcast for in memory datagrid but doesn't explain it at all in the docs. It also doesn't expose any of the useful Hazelcast APIs. So unless you are already familiar with Hazelcast you will miss most of its benefits. I think Spring Integration is a much better solution to the problems vertx tries to solve. That fact that vertx tries to be polyglot friendly doesn't really seem like a benefit to me either. Just makes feature development much slower.

voidlogic 14y ago
spartango: "Vert.x is a decidedly "modern" Java codebase" eip: "[Vert.x] Callback spaghetti is hard to read and maintain." My take, "modern" = like node.js = Callback spaghetti = hard to read and maintain Of course this is coming from someone who hates callbacks, javascript and has ported node.js apps to Go and finds them faster and more maintainable in that form.