7 ms·

As a modern java developer I was surprised to find no mention of Vert.X which to me seems like one of the most modern and forward-thinking java web frameworks.

As a modern java developer I was surprised to find no mention of Vert.X which to me seems like one of the most modern and forward-thinking java web frameworks. Not only does it support scaling your app out-of-the-box but also provides a simple way to deal with concurrency.

oblio 12y ago
Isn't Vert.X async a-la Node?
- java-lang 12y ago
  It is asynchronous event driven like Node but can process events on multiple threads
eip 12y ago
I've been stuck using Vert.x for a year and half. I recommend using something else. It's a questionable framework mashed together with a poorly though out messaging system. I would rather use Spring Integration, Quasar, or Akka.
- java-lang 12y ago
  Hmm, I find it surprising, hasn't been my experience at all.
- zmmmmm 12y ago
  Would be interested in any more concrete description of the problems? I'm considering using Vert.x in a project, mainly because of the polyglot features (ability to be extended by many different people some of who only know Python, others who only know Java and some who might only know Javascript, etc).
  - eip 12y ago
    Non-standard build/deploy/run. Classloader per verticle type makes dependency injection painful. "I don't know what a Spring "ApplicationContext" is" -- Tim Fox Uses multiple classloaders so you can "run multiple versions of the same module at the same time". Not something I have ever done or would do. Uses Hazelcast for clustering but uses tons of classloaders so using anything other than simple types in Hazelcast is hard and inefficient. Message bus is tightly coupled to application cluster through Hazelcast. Messaging is missing the most useful features of AMQP like wildcard topics and queues. Only possible to do very basic message routing. Many messages have to be sent multiple times to mimic advanced routing. Dividing everything into 'verticles' encourages use of callbacks for everything. This increases code size and complexity which increases the need for testing. 'Callback hell' Encourages polyglot programming. Writing Vertx apps with Groovy makes me feel like I could add a whole chapter to 'How to Write Unmaintainable Code'. https://www.thc.org/root/phun/unmaintain.html https://www.thc.org/root/phun/unmaintain.html
    - vorg 12y ago
      > Encourages polyglot programming. Some of these "problems" aren't problems at all, e.g. what's wrong with polyglot programming? > Writing Vertx apps with Groovy makes me feel like I could add a whole chapter to 'How to Write Unmaintainable Code'. Vert.x enables many JVM languages to program it. Perhaps the real problem's with the language you've chosen. Groovy's business purpose is to ensure jobs (i.e. consulting contracts and conference seat sales) for life for its promoters at SpringSource. Choose a language with another mission and that could make all the difference.
      - eip 12y ago
        > Vert.x enables many JVM languages to program it. Perhaps the real problem's with the language you've chosen. Groovy's business purpose is to ensure jobs (i.e. consulting contracts and conference seat sales) for life for its promoters at SpringSource. Choose a language with another mission and that could make all the difference. The framework and the language are both problems in my opinion. If it was up to me I would have chosen a different framework, messaging system, language, and more. Wasn't my decision to make though.

oblio 12y ago

Isn't Vert.X async a-la Node?

java-lang 12y ago
It is asynchronous event driven like Node but can process events on multiple threads

eip 12y ago

I've been stuck using Vert.x for a year and half. I recommend using something else. It's a questionable framework mashed together with a poorly though out messaging system. I would rather use Spring Integration, Quasar, or Akka.

java-lang 12y ago
Hmm, I find it surprising, hasn't been my experience at all.
zmmmmm 12y ago
Would be interested in any more concrete description of the problems? I'm considering using Vert.x in a project, mainly because of the polyglot features (ability to be extended by many different people some of who only know Python, others who only know Java and some who might only know Javascript, etc).
- eip 12y ago
  Non-standard build/deploy/run. Classloader per verticle type makes dependency injection painful. "I don't know what a Spring "ApplicationContext" is" -- Tim Fox Uses multiple classloaders so you can "run multiple versions of the same module at the same time". Not something I have ever done or would do. Uses Hazelcast for clustering but uses tons of classloaders so using anything other than simple types in Hazelcast is hard and inefficient. Message bus is tightly coupled to application cluster through Hazelcast. Messaging is missing the most useful features of AMQP like wildcard topics and queues. Only possible to do very basic message routing. Many messages have to be sent multiple times to mimic advanced routing. Dividing everything into 'verticles' encourages use of callbacks for everything. This increases code size and complexity which increases the need for testing. 'Callback hell' Encourages polyglot programming. Writing Vertx apps with Groovy makes me feel like I could add a whole chapter to 'How to Write Unmaintainable Code'. https://www.thc.org/root/phun/unmaintain.html https://www.thc.org/root/phun/unmaintain.html
  - vorg 12y ago
    > Encourages polyglot programming. Some of these "problems" aren't problems at all, e.g. what's wrong with polyglot programming? > Writing Vertx apps with Groovy makes me feel like I could add a whole chapter to 'How to Write Unmaintainable Code'. Vert.x enables many JVM languages to program it. Perhaps the real problem's with the language you've chosen. Groovy's business purpose is to ensure jobs (i.e. consulting contracts and conference seat sales) for life for its promoters at SpringSource. Choose a language with another mission and that could make all the difference.
    - eip 12y ago
      > Vert.x enables many JVM languages to program it. Perhaps the real problem's with the language you've chosen. Groovy's business purpose is to ensure jobs (i.e. consulting contracts and conference seat sales) for life for its promoters at SpringSource. Choose a language with another mission and that could make all the difference. The framework and the language are both problems in my opinion. If it was up to me I would have chosen a different framework, messaging system, language, and more. Wasn't my decision to make though.