Let’s have a look these three frameworks,

Vert.x is an event driven application framework that runs on the JVM – a run-time with real concurrency and unrivalled performance. Vert.x then exposes the API in Ruby, Java, Groovy, JavaScript and Python. So you choose what language you want to use. Scala and Clojure support is on the roadmap too.

Node.js is a platform built on Chrome’s JavaScript runtime for easily building fast, scalable network applications. Node.js uses an event-driven, non-blocking I/O model that makes it lightweight and efficient, perfect for data-intensive real-time applications that run across distributed devices.

Netty is an asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers & clients.

And here are some useful comparison articles,

• Vert.x: Why the JVM May Put Node.js on the Ropes

	Vert.x (Polyglot JVM)	Node.js (Javascript)	Netty (Java)	EventMachine (Ruby)	Twisted (Python)	LibEvent (C)
Language Type	Dynamic or Static	Dynamic	Static	Dynamic	Dynamic	Static
Speed of Development	Fast	Fast	Slow	Fast	Fast	Slow
Synchronous Threading Support	Great	None	Great	Poor	Poor	Good
Library Threadsafety	Good	N/A	Good	Poor	Poor	Good
Backed By	VMware	Joyent	Redhat	N/A	N/A	N/A

• Vert.x vs node.js simple HTTP benchmarks
  1. Vert.x is much faster than Node.js when reading the same file from the filesystem more than once. Neither Vert.x nor the JVM is doing any explicit caching, so this is most likely due to the OS caching it (memory mapped files?). In a webserver-type app the same file is likely to be served many times so this is pretty significant
  2. Node.js doesn’t appear to scale particularly well using the `cluster` module. The advice from the node.js folks is not to use it (for now). This leaves node with no out-of-the-box way to scale across multiple cores 
  3. Many of the out of the box load testing tools don’t appear to pipeline very much. The Vert.x results are dramatically better when there’s a high degree of pipelining going on.
  4. Java on the JVM is extremely fast. No surprises there  But what is very encouraging is how the other JVM langs held up – in particular Rhino held up very well against V8 

After the first release, I found a bug of jbig2.exe,
when I tried
jbig2.exe -p 1.tiff>1.jbig2
I found the created jbig2 file under Windows is bigger than under Linux, and after check, it is not correct jbig2 file.
After some efforts(sorry for my poor c/c++ and python), I fixed the bug.

P.S.
Change logs of this release

*pdf.py create correct PDF to stdout under windows
for details, please visit How to Let Python Send Binary data to stdout under Windows
*fix a bug, that jbig2.exe -p can not get the correct content, also stdout issue.

recently I successfully compile jbig2enc under windows, but when I tested pdf.py, I got incorrect PDF document, after asked to the author,

because of the bug of python under windows, file(p).read() can not read all content of output.0000, so the pdf created is not correct, I modify file(p,’rb’).read(), but the pdf created is still not correct, is some bigger than it create under linux, I have send you the two pdf files as attachment.

I got the following answer,

My only guess would be that Windows is performing newline conversion. Keep your current change to use file(p, ‘rb’).read() and alter line 137 to read:
file(‘output.pdf’, ‘wb’).write(str(doc))
and see if output.pdf is any more valid.

in this way, I can get the correct PDF, but it is not the stdout way, and after some search, I got the following answer, and now it works as I want.

You want to send binary data, such as for an image, to stdout under Windows.

import sys

if sys.platform == "win32":
import os, msvcrt
msvcrt.setmode(sys.stdout.fileno(), os.O_BINARY)
note:
If you are reading or writing binary data under Windows, such as for an image, then the file must specifically be opened in binary mode (Unix doesn’t make a distinction between text and binary modes). But this is a problem for a program that wants to write binary data to standard output (as a web CGI program would be expected to do), since the ‘sys’ module opens the ‘stdout’ file object on your behalf and normally does so in text mode. You could have ‘sys’ open ‘stdout’ in binary mode instead by supplying the ‘-u’ command-line option to the Python interpreter. But if you want to control this mode from within a program, then (as shown in the code sample) you can use the ‘setmode’ function provided by the Windows-specific ‘msvcrt’ module to change the mode of stdout’s underlying file descriptor.

reference,
http://code.activestate.com/recipes/65443/
issue: pdf.py can not create correct pdf under windows
Convert JBIG2 to PDF with free and open source software agl’s jbig2enc
Windows Version Jbig2enc(Jbig2 Encoder)