Java solutions profile: Java Web conferencing

Flash is widely considered the technology of choice for real-time audio and video, but Java’s open standards-based approach is essential to many developers and clients. In this Java solutions profile, four developers explain how they’re using Java to build real-time Web conferencing and collaboration software, and also reveal their wish list for improved client-side media support on the Java platform.

“Without Java, WebHuddle would not exist,” says John McCaughey, creator of this open source Web conferencing tool. “Java’s rich runtime library and cross-platform, cross-browser support allowed [WebHuddle] to be developed in less than two years.”

“The only other contender in my mind would have been Flash. As we see on YouTube and other sites, Flash performs well. In the end, I don’t think Flash is quite as platform-independent as Java is. Thus, it would have required much more testing to get it to work correctly on all platforms,” says Malcolm Patterson, one of the main developers of Internet phone service The Switchboard.

“The Java Runtime Environment provides quite good native-coded libraries for image manipulation, image and data compression, and socket and HTTP networking,” says Ed Hardebeck, vice president of engineering for Glance, a desktop sharing tool. “Java Platform (JRE) classes in java.net, java.awt, java.awt.Toolkit, and java.util.zip were particularly important to us in in choosing Java as a platform.”

Another reason why developers are choosing Java for Web conferencing: Users can quickly join conferences without having to download and install large-sized, complex software. This entices people who are more accustomed to accessing Web services, like webmail, through their browsers.

“The extensive class libraries available in the [JRE] allow us to produce a very small and lightweight client. This removes almost all download time and allows the users to get into a session almost instantly,” says Hardebeck.

Java meets Flash

Even though Vyew uses Flash as part of its service, its developers also built the service using Java in order to scale back on download times. “It allowed us to provide our customers with powerful features that normally only an installable desktop app could provide. It integrates smoothly with our Flash Web app for a continuous communication link from the desktop to all logged-in Flash clients,” says Tim Hon, product manager of Simulat Inc., the company behind Vyew.

“Flash speaks to Java in two scenarios,” says Hon. Getting Flash to the Java server on the backend “is done over a standard TCP/IP network socket, using an XML-based protocol. This is working great.”

On the client side, “Flash talks to a Java applet through JavaScript. So it goes from Flash to JavaScript to Java applet, and back through JavaScript, back to Flash.”

“Issues we had to deal with on the Flash-to-Java backend are mainly character encoding issues, such as Unicode vs. Latin, which aren’t a big deal.”

Issues on the front end were more cumbersome, Hon says. “Flash-to-JavaScript is usually fine, the problems lie between the JavaScript and Java communication. […] On certain clients, when the user upgraded their Java environment, the problem was not fixed until they deleted the old installation directory, implying that a Java Upgrade did not truly upgrade every part of the system, or left remnants of the old version.”

Vyew’s developers are experimenting with having the Java applet open a local socket connection directly to Flash.

The open source toolkit

Another advantage to developing on the Java platform is easy access to open source technology.

“We use lots of Apache software, both directly and indirectly,” says WebHuddle’s McCaughey. “We use the JBoss application server, which itself uses many Apache packages, especially the Tomcat Web server/servlet container. We also use the Apache Ant build tool heavily. The build is pretty complex, as the product is both a Web app and a signed Java applet that runs on modern and 1.1 (Microsoft) JVMs, and uses native C/JNI code. We couldn’t have pulled the build off without Ant’s awesome capabilities and cross-platform support.”

“Another software we use is the Spring Framework, mainly for its Acegi Security framework,” says McCaughey. “This gave WebHuddle pluggable authentication that can point to external sources such as SQL tables of users or LDAP servers.”

WebHuddle also incorporates lesser known projects such as NSIS (a scriptable Win32 installer), Speex (a codec designed for speech), and Thinlet (a small-footprint GUI toolkit).

“From the start, I knew WebHuddle had to be of, and for, open source. Java has always had a huge open source community, and now Java itself is open source. So a proprietary, closed technology such as Flash wouldn’t have been a good match,” says McCaughey.

The Switchboard’s development team also created the vast majority of its service using open source technologies. The biggest help for them came from JSpeex, a Java implementation of the Speex audio codec.

Vyew’s back-end server layer, which handles all of the real-time interactions for the service, consists of two Java-based media servers: Unity and the open source Red5. “Unity provides a great cost benefit over the alternatives and is powerful and scalable. We are still testing Red5, but it appears to have a bright future,” says Hon.

Multiple versions of Java

While the cross-platform nature of Java is attractive to these developers, making their client software function consistently across all platforms, browsers, and current versions of Java has been a technical challenge.

“Some other products advertise support for Mac or Linux, but there’s usually a caveat: These OSs are supported for [client-side] participation only; you need Microsoft Windows to host a meeting. With WebHuddle, all features are fully supported on all platforms, participant or host,” says McCaughey.

In order to best take advantage of newer and better features of recent versions of Java, Glance developers chose to conditionalize code and use Java reflection to dynamically link to newer classes and methods. In deference to the performance issues as a result, they devised alternate clients that would run more effectively on certain platforms.

“We can’t control the version of Java the user has, and we want to run on as wide a selection as possible without requiring an upgrade,” says Hardebeck. “Originally, we even ran on Java 1.1.4, but eventually, due to performance considerations, we had to drop support for this version.”

“On the client side, there are headaches involved when testing from one Java version to another,” says Hon. “Some features work and others don’t between differing browser and Java install versions. Additionally, sometimes even when an end user updates his Java version, the old Java version still hangs around and must be manually deleted to fix certain bugs.”

In fact, Hon’s company is presently looking for experienced Java developers who could help resolve these matters: “If you know any consultants who are experts in this area, we would love to hire them!”

Audio and network latency

“Java does a lot of the heavy lifting in the audio sampling area of things,” says The Switchboard’s Patterson. “It abstracts away nearly all of the tedious, platform-specific development that would be necessary to gather audio from the audio device on Windows, Mac, and Linux platforms.”

The Switchboard uses the Java Sound API for sound sampling and playback. “We steered clear of JMF as it needs to be installed on the client system (separate and in addition to the JRE) and we did not want this extra requirement to impede the end user from using the applet,” says Patterson.

“JMF does provide a higher level of abstraction when working with various media encodings, but the flip side of this is that you have much less control over the process of encoding and decoding this media,” says Patterson.

Audio latency is the biggest technical challenge for developers of Web conferencing services. The Switchboard’s developers had to do lots of tweaking — adjusting sampling settings and sample sizes — to get the service’s audio as close to real-time as possible.

Patterson concluded that the Java Sound API is geared more toward playback and recording in a resource efficient manner, rather than in a time efficient one. “Basically, Java tries to buffer stuff during various stages of the sampling process, which is good in terms of resource usage, but is a killer in terms of audio delay, which is the bane of any real-time communication software,” he says.

McCaughey, too, has found balancing the latency and reliability of real-time audio to be difficult. His WebHuddle’s architecture is server-centric, and has been designed that way for reasons of security, simplicity, firewall compatibility, and bandwidth. But the trade-off is that it is hard for the service to achieve the low latency of a peer-to-peer application like Skype.

Says McCaughey: “The WebHuddle client is heavily threaded, so you have to watch out for deadlocks, and it’s less deterministic in general.”

Pushing for real-time

Network latency is also a sticky issue for Java developers implementing real-time Web conferencing services. The Switchboard’s developers had to tailor the service’s packet size to suit the compression they were using, so as to avoid as much network buffering as possible.

Hardebeck advises: “Developers do need to remember to use the appropriate buffered stream for best performance, and more performance would always be nice! Personally I find the URLConnection API a bit cumbersome, but once you understand it, you can usually get what you need done.”

Latency is not the only enemy. Developers of Web conferencing solutions also must find ways to work around routers, Web proxies, and all the other impediments to P2P connectivity that most residential and corporate network setups throw in their way. “Luckily, there are methods, not Java specific, to deal with most of these situations [like] UDP tunneling,” says Patterson.

Regardless, McCaughey says that “Java’s networking support rocks. If it didn’t, Limewire and Azureus wouldn’t be so successful. Real-time audio support is pretty good, but could use more love from Sun to get the quality up a bit.”

“It seems to be a struggle to get near real-time performance, but I think we have proved with The Switchboard that it is possible,” says Patterson.

Memory hungry and bloated

A common criticism from developers of Web conferencing solutions is that Java applets tend to be fairly memory hungry. “This could be a browser [or] specific Java implementation thing, but it seems to affect all platforms that I have tested on,” says Patterson.

Hardebeck points out: “Memory management is still a challenge, since the heap size allocated for an applet can only be changed by the user via a tricky manual reconfiguration.”

Another disadvantage of using Java is the current file size of the JVM installation itself. Version 6 for Windows is over 7 MB and requires 98 MB of disk space to install. “This is a lot to ask of a user without Java [installed] that just wants to join a session instantly,” says Hardebeck.

Though Java is a more “heavyweight” language compared with DHTML/Ajax, McCaughey says some features, such as screen sharing and voice, would be impractical to implement well under JavaScript. Additionally, he points out the matter of security:

“In my opinion, Java is more secure and reliable than JavaScript. I see JRE exploits reported maybe once or twice a year, while JavaScript exploits seem to require a patch to Firefox [and] IE every few weeks.”

Room to grow

Developers of these Web conferencing services have suggestions about what future versions of Java should have in order to improve the language for their needs.

Foremost, they would like Java to become easier and faster to install for the end user. Hon of Vyew even thinks this process should be automated and adds: “There should be more resources available for getting things to work across all browser types.”

Similarly, Hardebeck of Glance thinks a more reliable method designed to detect if Java is installed and available in a Web browser is needed. Other improvements he would like to see: Socket connection timeout and canceling of Socket and URLConnection operations; and improved performance, quality and functionality of image decompression and scaling, and of drawImage when scaled.

“Getting the best performance out of image scaling and drawing requires careful selection and use of the API,” says Patterson. “Major changes introduced in Java 1.4 make it subtle when graphics driver/card features, such as acceleration and on-board memory, are being used.”

Another area Patterson would like addressed in Java is the Swing toolkit. It is fairly heavy in terms of its memory usage, and not quite as “snappy” as other UI libraries, such as SWT.

“Also, the layout system for arranging the user interface elements can be quite obtuse at times, and requires quite a bit of trial-and-error to get just right,” he says. “That said, it worked well for us. We were able to get the look of it to blend with our Web site design quite well, so I can’t complain too much.”

McCaughey, whose WebHuddle presently does not offer video streaming, would like to see a free, open source video format like Ogg Theora for the Java platform. But, mostly, he feels that Sun needs to become more competitive against Adobe’s Flash in the marketplace: “[Their] JavaFX push seems to recognize the success of Flash. Hopefully, something good comes out of that. The open-sourcing of Java was a huge improvement!”

In conclusion

Java solutions profiles are case studies in Java development, with emphasis on the developer experience and lessons learned. In this Java solutions profile four developers of Java-based Web conferencing solutions have discussed the choice to use Java for real-time audio and video streaming. Join the discussion below to let us know whether this profile was valuable to you and what areas of Java development you would like to see profiled in the future.