A View From Asia: A Conversation With Technology Evangelist Chuk-Munn Lee

Print-friendly Version

Chuk-Munn Lee has been programming in the Java language since 1996, when he first joined Sun Microsystems in Hong Kong. He currently works as a senior developer consultant and technology evangelist for Technology Outreach at Sun in Singapore and is a frequent speaker at conferences around the globe. He has spent six years working with key Asia-Pacific independent software vendors (ISVs) to design, prototype, develop, tune, size, and benchmark their applications. An avid gamer, Lee is also creating a 2D isometric Java technology game that is played between two players by email or peer-to-peer network. He graduated in 1987 from the Royal Melbourne Institute of Technology in Melbourne, Australia, where his favorite subject was compiler theory.

We met with him recently to get his unique perspective on promoting Java technology in Asia.

How do you approach technology evangelism?

For me, technology evangelism means attracting and recruiting new developers to the Java platform, while at the same time nurturing and upgrading the skill sets of the "converted." The eventual goal is to foster and grow the Java platform by generating fresh ideas and building an ecosystem around them. This is necessary for the evolution, longevity, and continued relevance of the platform.

When did you first encounter Java technology, and what turned you into an evangelist for the platform?

I joined Sun in February of 1996. Part of my job description was to help support a new programming phenomenon called Java. I spent my first week attending a Java programming course. One of the first things that caught my attention was how easy it was to create a thread and to specify a critical region.

When I completed the course, Sun Hong Kong, where I was based, began offering Java courses. I was asked to help teach the same Java course that I had taken about six months before. As I taught it, areas that I had not initially understood became clear. To bolster my fledgling Java technology knowledge, I worked on a program that provides call statistics reports for our support database. The program never got used much by my colleagues -- they had much better reporting tools than my upstart program. But I gained lots of hands-on experience in database access, AWT, and so on and grew quite comfortable with the language.

I did a lot of customer briefings as well. At that time, the entire Java platform architecture was new, and a lot of Sun's customers were curious about it. I was helping Sun's customers with Java projects, which were mostly applets. They began to make serious use of Java applications when the Java Servlet API was first released. At that time, lots of people were developing web applications with Perl. Sun had a product called Java Web Server (JWS) that implemented servlet technology. I spent a fair amount of time with customers explaining what a servlet was, how it could replace Perl CGIs, and how they could program servlets and deploy them on JWS. Servlet technology led to the adoption of other Java technologies -- Java DataBase Connectivity (JDBC) being one of them.

Then I was transferred to the Market Development Engineering (MDE) department, a position based in Singapore. My responsibilities at MDE primarily involved helping ISVs develop and deploy their applications on Sun's platforms. The applications were mostly written in the Java language, but there were also a few C/C++ applications. This gave me lots of opportunities to work with Java applications. As new Java technologies emerged, we would brief the ISVs about them and how they might use them in their products. So I was assuming the role of an evangelist without even knowing it.

After about eight years working as a "virtual evangelist," I transferred to the Technology Outreach department in 2004.

"I still marvel at how relatively easy it can be to port and run a complex Java Platform, Enterprise Edition application on different vendors' application servers."     Chuk-Munn Lee Technology Evangelist Sun Microsystems

What message, story, or theme about Java technology does not get enough attention?

Application portability. The Java platform introduced the notion of Write Once, Run Anywhere (WORA). WORA is reasonably easy to achieve if you are writing an isolated application, one that doesn't have to connect to external resources like databases or interact with other components and applications.

I still marvel at how relatively easy it can be to port and run a complex Java Platform, Enterprise Edition (Java EE, formerly known as J2EE) application on different vendors' application servers. At MDE, I worked with ISVs to help them port their application over to Sun's application server. If the application does not use any vendor-specific APIs, then porting the application means changing the deployment descriptors.

An ISV I was working with used nonstandard packaging for its application, which caused all sorts of errors when deployed on Sun's application server (AS). I spent a couple of weeks with this ISV sorting out the packaging. Once we managed to deploy the application successfully on Sun's AS, the ISV wanted to find out if the Sun AS package would deploy on the AS that the ISV had been using. The application deployed and ran without any problem. I had always known that it would work, but I'd never seen it done before. It was a powerful demonstration of Java EE's portability. This ISV has since made an effort to follow the standards.

What is your long-term vision for Java software? Where do you see it headed?

I am a gamer, and for self-serving reasons, gaming is an area where I would like to see Java applications play a greater role. Java applications, and games in particular on cell phones, are becoming quite popular.

Innovative stand-alone, connected, and multiplayer games are beginning to appear as more cell phones support Java technology. But Java technology is still not prevalent on desktop games, and there is a perception that it is not suitable for developing games. A few developers have begun to release Java desktop games, but on the whole, they are few and far between. I urge game developers to revisit this. I think the Java language is certainly ready for games -- if not the fast-paced 3D-type games, then certainly the slower, turn-based games like Civilization. There is a port of Quake2 to a Java app that you can find. Check out the benchmark against the C version.

I believe that Java technology can change the way we play games. Traditionally, games are played on either a PC, a game deck, or a console -- and more recently, on cell phones. However, these games are confined to these boundaries. If you think of a game as a conversation, there are so many ways that we can converse with our friends: face-to-face chats, telephone gossip, email sharing, SMS updates, pagers, and IM for everything else in between. Similarly, games can be richer if we can provide multiple modes of access and interactions. We can extend the reach of the game beyond the desktop and keep a gamer engaged.

"I believe that Java technology can change the way we play games."     Chuk-Munn Lee Technology Evangelist Sun Microsystems

So imagine that we are trying to develop Doom or a turn-based game like Diplomacy. The game server, game states, matchmaking, leader board, game artifacts, and missions are running on a Java EE server. A gamer can play the game on the desktop using clients developed on Java Platform, Standard Edition (Java SE, formerly known as J2SE). In games like Diplomacy, we can also provide a pure browser-based client developed around servlets and JavaServer Pages (JSP) technology. This allows gamers to access their games from any Internet café around the world. If the gamer is away from the desk, then they can continue the game on the cell phone. The game functionality may be limited, but at least the gamer can still get their "fix" while commuting or waiting for a friend.

I believe that Java technology is uniquely positioned to deliver this experience. The Java platform today spans almost all the gaming platforms. Game libraries like JOGL, LWJGL, JOAL, and ODE are maturing on the Java platform. There are, of course, other libraries like speech, embedded scripting engine, peer-to-peer networking, and desktop integration that game developers can take advantage of to make their games more innovative, interesting, and engaging.

What's happening with games in Asia?

Java applications and games in particular have taken off on cell phones. There are lots of cell phone games, mostly stand-alone, that you can purchase from your telco in the Asia-Pacific region. There are lots of interesting APIs like wireless messaging (SMS/MMS support), Bluetooth, and Location that game developers are using to create interesting games. Game developers, in partnership with telcos, are also releasing multiplayer games. I've seen some shoot-'em-up games in which players across the Asia-Pacific region can cooperate or compete on a given scenario.

Another mobile game genre that I've recently discovered is connected games. Connected games are somewhere between stand-alone and multiplayer. The idea behind connected games is that the game interacts with a games server, and the game is updated by downloading new content and features from the server. A tie-in with a television program is an example of such a game app. In such a scenario, a user can interact with a television show before, during, and after the program. Connected games of this nature effectively extend the TV show from a one-hour slot to all week.

I wish there were more Java desktop games. However, there are encouraging signs. Game publishers are releasing games, and as basic game libraries like OpenGL, OpenAL, and ODE mature on the Java platform, I'm confident that quality desktop games will appear.

You are working on a Java technology-based game in your spare time. How's it going?

I am currently developing a turn-based game that derives from an out-of-print board game called Space Hulk from Games Workshop. Space Hulk pits the heavily armed units called Terminators against Alien-like creatures (Ridley Scott's) called Genestealers.

Initially, I wasn't thinking of doing a full-blown game. I just wanted to try out the new Tiger language features. As I began to feel comfortable with the new features, my focus shifted to the game. The game itself is a 2D isometric game that is played between two players by email or peer-to-peer network. The game will be linked to a web site for matchmaking, new game mission, leader board, and so on. I'm also trying to practice what I preach by trying to develop a game that is accessible from the desktop, the browser, and possibly cell phones.

What do you say to people who want to learn the Java language?

Great! Welcome! First and foremost, I would suggest exploiting the web. There's tons of learning material. There are forums to post your queries and download open source code. Getting books is another good way, but I've had people complain to me that the moment they buy any technology-related book, it's already out-of-date. I suggest trying the local library or subscribing to something like Safari Bookshelf.

For a beginner, the plethora of Java APIs can be quite intimidating. Choose an area of your immediate need, for example, web programming, servlet/JSP/JSF, GUI, Swing, persistence, JDBC/JDO (Java Data Objects)/CMP (container-managed persistence), or what have you. Work on a project that gives you experience in using the API, the development tools, and the runtime environment. Keep the project manageable -- I tend to pick something that is fun and that I can complete in three months max.

"When I look at the Swing toolkit, it reminds me of my favorite quote from Alan Kay: 'Simple things should be simple. Complex things should be possible.'"     Chuk-Munn Lee Technology Evangelist Sun Microsystems

What misconceptions do you encounter?

I frequently hear ISVs and customers alike say, "Swing is complex," but I don't think it is. Swing's basic programming model hasn't changed that much from the AWT days. The idioms for creating a frame, setting layouts, adding widgets, intercepting events, and setting properties are still the same. You can create a pretty decent GUI with just the basic knowledge. And with GUI painters like NetBeans, the task of creating Swing applications is even easier.

However, Swing technology allows you to do a lot more than AWT. For example, you can add borders to widgets, editors to a table cell, define key bindings, create custom input methods, implement models to hold large datasets efficiently, override the default focus traversal, drag and drop, cut and paste, and so on. I've worked with these and do not find them particularly difficult or complex. They can be somewhat tedious because some of them have a lot of methods to implement.

When I look at the Swing toolkit, it reminds me of my favorite quote from Alan Kay: "Simple things should be simple. Complex things should be possible." Swing allows developers who are new to Java technology to create functional UIs quickly and easily without preventing more mature developers from doing creative things. One of my personal favorites is the 3D splash screen and a particular 3D: think red and blue paper spectacles.

You work with a lot of ISVs in Asia and the Pacific, helping them design, prototype, develop, tune, and benchmark their applications. What should the rest of the world know about Java technology in Asia and about Asian developers?

The adoption of Java software is on the rise in Asia. Most of my activities with the ISVs involve developing new applications and porting existing applications to Java EE. A lot of these ISVs are fairly new to Java applications, but that does not stop them from being ambitious or bold with their application features.

For example, I was assisting Java Platform, Micro Edition (Java ME, formerly known as J2ME) developers with their MIDlet. These particular developers were new to Java ME. They wanted to develop a MIDlet that could dynamically gain functionalities as a user pays for them. An example would be a value-added Short Message Service (SMS). A basic user would get garden-variety SMS. As the user subscribed to additional features like password-protected SMS, compress SMS, read-once SMS, time-bombed SMS, and so on, these features would be dynamically provisioned or enabled on the SMS MIDlet.

The developers I was working with were familiar with Java SE's class loaders and wanted to do the same in Java ME. However, class loaders were not supported in CLDC. It's experiences like these that I live for! I would never have thought of doing what they wanted because I "knew" it could not be done. Why attempt it, right? But because the developers wanted it, I had to work with them. We eventually compromised on certain things and got the functionality that they wanted.

When you give a talk on Java ME technology in the enterprise, what is the take-home message?

Java ME extends the reach of enterprise applications. Enterprise applications have traditionally been bound to desktops where you access them either through a rich client or a browser. There have been attempts to use Wireless Markup Language (WML) and SMS to allow these applications to be accessed from cell phones. I saw an example of this recently. As you probably know, credit card merchants typically swipe your card on the credit card terminal for authorization of payment. These terminals are typically connected to the credit card company by telephone lines. In rural areas where telephone service may be unreliable or nonexistent, this can be a problem.

"Developers often try to cram too many features or information into Java ME applications. This makes the MIDlet difficult to use on small form-factor devices."     Chuk-Munn Lee Technology Evangelist Sun Microsystems

One solution is to use a mobile phone and an attached thermal printer. First, the credit card info is keyed into the MIDlet, which sends the details in an encrypted SMS to the credit card center. Upon approval, an SMS is sent to the merchant and customer. At this point, a receipt is printed. The beauty of this solution is in its simplicity, setup cost, and in the fact that it works anywhere and everywhere! Since most telco supports SMS roaming, the merchant could be anywhere in the world, and the solution still works!

One of the strengths of Java ME over SMS and WML is that, first, Java ME applications can be used on- or offline. Second, Java ME applications complement SMS and WML: Server-side applications written to SMS and WML can work with little modification on a Java ME client. Third, Java ME clients can provide richer interactions.

Developers often try to cram too many features or information into Java ME applications. This makes the MIDlet difficult to use on small form-factor devices. Make the application specific: Do only one thing, keep the interface simple, and display only what is essential.

What is the significance of the NetBeans IDE?

I can remember not so long ago when NetBeans was the poster child for all that was perceived to be wrong with Swing. If you give NetBeans a test drive today, you'll be pleasantly surprised. NetBeans and many other Java applications like it prove that you can develop complex, responsive, and extensible desktop applications using classes and libraries based on Java SE standards.

NetBeans also provides a user-friendly interface to both Java SE and Java EE. I like to think of NetBeans as "Visual Java SE" or "Visual Java EE." NetBeans is an extremely powerful IDE. And NetBeans is very quick to support all the newest Java standards. Thus, if you are new to Java programming, you can use NetBeans as a learning tool as well. Take Enterprise JavaBeans (EJB). EJB is presented as a logical whole instead of three separate files: Finders, select methods, business methods, and so on are categorized. So if you are new to EJB, you can easily grasp the programming model without being overwhelmed by the details.

Competition is good for the marketplace. As NetBeans improves, other free and commercial IDEs will have to keep up. I believe this kind of competition benefits developers and the evolution of Java programming. You cannot build quality software with bad tools.