Vert.x vs J2EE comparison

[Xomi]

Hi everyone,

I'm currently in the process of starting a new project and I am evaluating different technologies. Since the project will be based 

on real-time communication (chat) with many concurrent users, I'm considering the following platforms: 

 1. Vert.x 

 2. Java EE

 3. Node js 

My question is: what is the main advantage of using Vert.x compared to using standard J2EE?

I understand the performance gains of using asynchronous, event-based programming, but as I understand, the latest 

servlet specification also supports asynchonous calls. I understand the gains of using separate processes that communicate 

only through messages (EventBus), but I can acheive that easily in the J2EE world by using JMS. I understand that vert.x supports

web sockets but many app servers also support them and with JSR-356 it is now standardized. 

So, could anyone elaborate why is vert.x better for real-time applications? 

(can we just ignore the polyglot part, which is, in my case irrelevant)

[Tim Fox]

On 09/10/13 13:16, Xomi wrote:
> Hi everyone,
>
> I'm currently in the process of starting a new project and I am
> evaluating different technologies. Since the project will be based
> on real-time communication (chat) with many concurrent users, I'm
> considering the following platforms:
> 1. Vert.x
> 2. Java EE
> 3. Node js
>
> My question is: what is the main advantage of using Vert.x compared to
> using standard J2EE?
>
> I understand the performance gains of using asynchronous, event-based
> programming, but as I understand, the latest
> servlet specification also supports asynchonous calls.

Yes, but most of JavaEE is still synchronous.

> I understand the gains of using separate processes that communicate
> only through messages (EventBus), but I can acheive that easily in the
> J2EE world by using JMS.

JMS has a much clunkier interface and isn't available in other languages
or the client side.

> I understand that vert.x supports
> web sockets but many app servers also support them and with JSR-356 it
> is now standardized.

Websockets are still poorly supported in real-world networks including
corporate proxies and such-like. That's why Vert.x supports SockJS which
automatically falls back to other protocols.

>
> So, could anyone elaborate why is vert.x better for real-time
> applications?
> (can we just ignore the polyglot part, which is, in my case irrelevant)

Are you sure the polyglot part is irrelevant for you?

From the fact that you are considering JavaEE (which is Java only) and
Node.js (which is JavaScript only) implies you haven't made up your mind
on programming language yet.

A good thing about Vert.x is you don't have to make up your mind - use
JavaScript for the parts where JavaScript is better (e.g. scripting,
glue code etc), and use Java for the parts where Java is better (perhaps
more complex logic where you want the benefits of type safety).

Other reasons you might want to consider Vert.x over JavaEE/Node.js are:

Simplicity - very easy to run things without complex configuration,
packaging etc. (Well node is simple in this regard, but JavaEE not)
Performance - Vert.x wipes the floor with Node.js

>
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "vert.x" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to vertx+un...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

[Xomi]

Ok, thanks for the answers. My comments:

1. Most of J2EE is synchronous.

Well, most of Java is synchronous, so there's nothing stopping me from using synchronous Java libraries inside

Vert.x and thus defeating the whole pupose of it. Right?

2. Websockets are still poorly supported, you need a fallback mechanism

I've used libraries like Atmosphere that support fallback if web sockets can not be used.

3. Polyglot.

I'm not saying that this is not important, but it's just not important for me personally, because I'm familiar with both 

Java and javascript so it's not a language issue for me. I see how this can be important for large projects with many 

developers...

4. Performance

The only node.js vs Vert.x benchmark that I've seeen is the one done by Vert.x people so I'm not totally convinced...

[Tim Fox]

On 09/10/13 16:16, Xomi wrote:

Ok, thanks for the answers. My comments:

1. Most of J2EE is synchronous.

Well, most of Java is synchronous,

Java itself is neither synchronous or asynchronous, it's particular APIs that are synchronous/asynchronous.

so there's nothing stopping me from using synchronous Java libraries inside

Vert.x and thus defeating the whole pupose of it. Right?

Vert.x has a specific mechanism for dealing with legacy blocking libraries (worker verticles)

2. Websockets are still poorly supported, you need a fallback mechanism

I've used libraries like Atmosphere that support fallback if web sockets can not be used.

You were referring to using websockets with JavaEE, not atmosphere. Not sure if you can use atmosphere with JavaEE (?)

3. Polyglot.

I'm not saying that this is not important, but it's just not important for me personally, because I'm familiar with both 

Java and javascript so it's not a language issue for me. I see how this can be important for large projects with many 

developers...

4. Performance

The only node.js vs Vert.x benchmark that I've seeen is the one done by Vert.x people so I'm not totally convinced...

Well.. in the latest round of techempower benchmarks we beat node.js, and that was using a really old version of Vert.x and the tests were setup poorly. I've just submitted a PR to upgrade Vert.x there and when I ran it locally we were right up at the top of the table (which is way ahead of Node.js)

[El Gazali]

Tim,

Could you sort this "Techempower Benchmarks" thing once and for all and make sure they get it right this time. Vertx should be where it belongs and that is the top.

[Norman Maurer]

Tim has sorted it and it was pulled in already.

So all is good :)

[Ken Yee]

On Wednesday, October 9, 2013 11:16:59 AM UTC-4, Xomi wrote:

I've used libraries like Atmosphere that support fallback if web sockets can not be used.

IMHO, I think that's a more appropriate comparison w/ Vert.x...not J2EE which is a huge stack that does lots of other stuff.  You can embed both Atmosphere and Vert.x in any Java application to make it a server.

Websockets almost by definition is async since it involves callback event handling.

Node.js is more analogous to the JVM using only async APIs since JS by nature is async.  Node.js + Sock.js is more like Vert.x.