Version 1.0

[Download] [How To] [JavaDoc]

VNCj is toolkit for creating 100% JavaVNC servers

Important: VNCj has very limited support for serving the operating system desktop. A number have people have thought they could use VNCj to serve the desktop from an applet. That would be great for help-desks but, alas, it won't work well due to Java's cross-platform limitations. If you are looking for a desktop remote control solution, you should install the dedicated VNC server for your operating system.

I wrote an article about VNCj for JavaWorld. Someone translated this article into Chinese.

What does it do?

Using VNCj, you can create a full graphical user interface (GUI) in Java, using Swing and AWT, and immediately export it to anyone on the network with a VNC viewer. Viewers are essentially dumb terminals that supply a graphic display, a keyboard and a pointing device, and are available for almost any operating system and platform (including Java). In fact, VNCj contains a tiny web server that can serve the Java applet to any Java-enabled web browser. Multiple users can connect at the same time and will each have their own user interface, and can also share a single session. VNCj also makes use of the AWT Robot class (introduced in JDK 1.3) to allow limited control of the operating system desktop.

What is VNC good for?

Dumb terminals solve many of the problems of distributed applications by exporting only the user interface. Because the application runs on a single machine, its data is secure, development is straightforward, and deployment is as simple as providing the tiny VNC viewer. Even if you plan to have the client run a full-blown distributed application in the future, VNC can let you quickly test it without going through distributed development woes.

What is VNCj good for?

While VNC is useful for remote controlling your desktop, it can also be used to remote control applications in certain situations:

  • In a VNC-rich environment, where everybody is running VNC viewers, you may want to provide services over VNC. With Java and VNCj you can create powerful services quickly.
  • You may not want to give the remote users full access to a desktop. A virtual machine gives you complete control over what the user can or can't do. You can make the user interface as simple or complex as you want. In fact, you can create a "virtual desktop" using Swing's JDesktopPane or AWT.
  • Java releases you from operating system dependency. You can run your server on any machine that supports Java. As for the client side, VNC viewers are available for many more operating systems than Java currently supports. And, there's always the Java viewer built into VNCj.
  • A virtual machine allows you to support multiple clients at the same time, a feature that not all operating systems support.

Note that VNCj, and VNC for that matter, are bandwidth and CPU vampires. This is not an efficient distributed solution as far as resource use is concerned, but its straightforward deployment may be just what you need. If your clients support Java, check out my more ambitious pet project, Java URL, that allows running a full Java application at the client securely and without installation, with minimal resource use. You may also want to take a look at jVNC Server, another 100% Java VNC-based application server, based on a different scheme. If you can allow text-based clients, you should check out my 100% Java telnet server toolkit, telnetj.

How do I get it?

You may download VNCj with its full source code as long as you agree to the terms of GNU Lesser General Public License, which basically gives you complete freedom to change and adapt the code to suit your needs, though you are required to continue to redistribute it under the same license. The latest release is available here. Read the status below for more information.

Source code is available at GitHub. Please report bugs there, too!

How do I use it?

Check out the How To page for an overview of how to create your own VNC server using VNCj. Latest API documentation is available online here.

Important! You can run servers and viewers on the same machine, but performance will be worse than on a local network! The reason is that viewers aren't designed for loopback connections. They keep polling the socket for updates, but because these updates come too quickly, they are overwhelmed. In fact, VNCj adds a small delay for loopback connections, otherwise they are too sluggish to work. Do your testing through the network for more realistic results.

Right now, VNCj requires the Java 2 Platform, Standard Edition (JDK version 1.4.0).

Demo servers are available in the distribution (vncj-demo.jar) with a batch file for Windows (vncj-demo.bat) and a properties file ( where you can define passwords and connection restrictions. The default password for all demo servers is "test". There is a demo for each of the six VNCj models:

  • Swing model: VNCJFrame with a JDesktopPane and a few JInternalFrames. Screenshot.
  • AWT model: VNCDesktop with a few AWT Frames. Screenshot.
  • Lightweight model: Simple vector drawing application. Screenshot.
  • Pixel model: Lightning-fast seven-segment real-time clock. Screenshot.
  • Console model: A simple command line interface. Screenshot. (also see telnetj)
  • RFB model: Desktop server. Since Java does not tell us which areas of the desktop have been updated, we cannot send correct incremental updates. And since sending the whole damn desktop for every refresh is terribly slow, I disabled automatic refreshes. So, you must "request screen refresh" manually to get the latest desktop snapshot. I know, it's barely usable, but this is a demo. If you want real desktop remote control, install the appropriate VNC server for your operating system.

All demos support shared sessions. For example, the shared lightweight model demo, when shared, acts as a network whiteboard.

How do I contact you?

My name is Tal Liron, and this is one of my pet projects. Contact me at "tliron at threecrickets dot com" if you want to help in development or report a bug, or to pay me for product support and consulting.


Known problems and limitations:

  • Limited testing (help!)
  • No clipboard support

Latest version tested on:

  • Windows XP Professional, JDK 1.4.0
June 5th, 2002
Version 1.0
  • Redesigned for JDK 1.4.0.
  • Authentication and host restriction support.
  • Fixed Swing refresh bugs.
  • Fixed bugs with backspace and delete keys.
January 22nd, 2001
  • Pixel model no longer requires AWT.
November 26th, 2000
Version 0.3
  • Shared session support. Separate event and incremental queues per client.
  • Hextile and CoRRE encoding support.
  • New super-fast console model.
November 15th, 2000
Version 0.2
  • True "virtual" remote frames. No more pop-ups on server.
  • Supports any pixel format desired by the client.
  • Incremental frame update. Only "dirty" regions are sent to client.
  • New remote AWT model. Uses Swing component peers.
  • Web server serves MF viewer applet.
  • Name changed to VNCj (used to be jVNC) to avoid conflict with another product.
July 1st, 2000
Version 0.1
  • Raw and RRE encoding of RGB888 pixel format.
  • Requires an AWT Frame to actually open on the server. Yuck.
  • Limited support for the Robot class.

"Oracle" and "Java" are registered trademarks of Oracle and/or its affiliates. RealVNC®, VNC®, RFB® and deskhop® are trademarks of RealVNC Limited and are protected by trademark registrations and/or pending trademark applications in the European Union, United States of America and other jurisdictions.