 | |
|
Qusay Mahmoud: What is your job description at Sun Microsystems? Antero Taivalsaari: Well, I've worn quite a few hats in the past years. When I joined Sun in 1997, I started as a researcher at Sun Labs in Mountain View, California. That's where we did the Spotless research project that led to the development of the KVM product, J2ME, and all. Then I was the engineer manager of the J2ME KVM/CLDC team at Java Software from mid-1999 until early 2002. Starting from Fall 2002, I've been living in Finland, working as a senior staff engineer in Sun's Consumer and Mobile Systems Group. QM: What have you been up to this past year? AT: I've been primarily working on some exciting new features that you are going to see in future versions of the CLDC HotSpot virtual machine [the CLDC HotSpot Implementation, formerly known as Project Monty]. I'm also doing some J2ME specification work, as well as book writing. For instance, during the last winter and spring, we wrote a new version of our J2ME book, to cover the CLDC 1.1 and MIDP 2.0 standards.
QM: What is the CLDC HotSpot Implementation? AT: It's the high-performance implementation of the virtual machine that we use for running MIDP applications. CLDC HotSpot includes a completely new virtual machine that utilizes adaptive compilation and many other performance technologies that were popularized in the Java HotSpot virtual machine for J2SE and J2EE -- but the footprint of the CLDC HotSpot VM is obviously much smaller. QM: You have implemented "JavainJava" -- a JVM in the Java programming language. Is that language really suited for implementing JVMs? AT: Yes, JavaInJava was a research project that I worked on when I started at Sun Labs in 1997. It was a really fun project. I wrote one of the first Java virtual machines that was capable of running itself; in other words, you could give the JavaInJava system as a parameter to itself. The system was rather slow, but that wasn't really because of the Java programming language; it was because of some design decisions for the internal architecture of the VM. Even though JavaInJava wasn't too practical, I believe that Java can suit JVM implementation very well -- in fact, there are currently some interesting research projects doing just that. QM: How did KVM come to be? AT: I had been working for a cell phone manufacturer before joining Sun, so I knew that there was quite a bit of interest in having a Java platform that would be small enough to run in a mobile phone. The problem was that all the "embedded" versions of the JVM that had been built so far were much too large, given the tight constraints on memory and processing power in the mobile phones of the late 1990s. So when Bill Bush and I started talking about this back in January 1998, we decided to try to build a JVM that would require ten times less space than any commercial JVM at the time. Our manager at the Labs, Neil Wilhelm, was very supportive of the idea, so it was very easy to get started. Neil recommended we use the PalmPilot as the target device, because the devices and development tools were easily available. The initial implementation was completed in a few months of frantic coding. We demoed it internally at the Sun Labs Open House in May 1998. That event was so successful that customer discussions began soon afterwards. When Motorola got excited about the system, the project became a real product development effort. I moved from the Labs to Java Software to lead the product development. QM: What does the K in KVM stand for? AT: That KVM is a virtual machine whose size is measured in kilobytes rather than megabytes. There is another interpretation that comes from the name "Kauai," the code name for the product project when it started at Java Software. People can call it the "KVM" or the "K Virtual Machine," but not the "Kilo Virtual Machine". QM: So what is the relationship between KVM and Spotless? AT: In short, Spotless was the original research project, while KVM is the product. The actual relationship is a bit more complicated, because the development of Spotless continued even after the KVM product development effort was started. There was quite a bit of sharing and transfer of ideas and code between the systems and the teams. QM: What was the most challenging part of designing KVM? AT: Dealing with the compromises and making the right tradeoffs. I remember somebody saying once that "J2ME is all about making impossible tradeoffs against conflicting requirements." Whoever said that understood very well what kinds of problems we were facing when we were trying to reach our goal [of a JVM one tenth the size of existing implementations]. Quite obviously, reaching that goal meant that we had to make a lot of difficult compromises that didn't please everybody. But in the end I think we came up with a fairly decent set of tradeoffs. QM: What language is KVM implemented in? AT: It's implemented in C. QM: How large is KVM? AT: It depends on the target platform and the Java libraries that are included. The core of the KVM is about 35,000 source lines of commented code, or about 70-80 kilobytes of binary code these days, depending on the target platform. But when you include the native functions needed by all the libraries, the size can be a lot bigger. The original Spotless implementation was much smaller. If I remember correctly, the smallest fully functional binaries that we had were about 25-35 kilobytes. QM: Why isn't the LCDUI package a subset of AWT or Swing? AT: AWT and Swing were designed for much larger displays, so the set of widgets that they support isn't very applicable to mobile devices. Also, the footprint of AWT and Swing was way too big for mass-market cell phones, especially at the time when the requirements for the original MIDP 1.0 standard were being crafted. QM: If you could start all over again, what would you do differently? AT: I had a discussion about this with Bill Bush, the other original Spotless team member, a while back. We came to the conclusion that ignoring the library development during the original research project was a big mistake. Neither Bill nor I were really graphics experts, so we were hesitant to start writing a new UI API that would have had the right qualities for both mobile phones and PDAs We were simply hoping that the industry would be capable of reaching a consensus on the libraries quickly. In hindsight, the [MIDP 1.0] standardization did happen pretty quickly, but we could have avoided a lot of politics and confusion, especially between the cell phone people and the PDA people, if we had waited a bit longer and spent time designing the libraries before publishing our VM technology to the world. QM: Some devices have a small heap and a non-compacting garbage collector that prevent many MIDlets from working. What are your thoughts on this? AT: The drawbacks of non-compacting garbage collectors are well known. Basically, after an application has been running for a long time, the heap can become so fragmented that allocation of larger objects is no longer possible. In other words, the system will run out of memory even though a large number of small free chunks in the heap are still available. Historically, there were some good reasons why non-compacting collectors were used in some of our customers' products. However, over the past couple of years the garbage-collection algorithms in J2ME implementations have become far more advanced, and these problems will eventually go away. QM: What is a non-compacting garbage collector anyway? AT: Compacting garbage collectors move and pack objects in memory so that after collection there is only one, or a few, big free areas in memory. Non-compacting garbage collectors don't move objects around. They are generally simpler to implement, and have some other qualities that make them useful in the memory architectures that are commonly used in embedded devices. QM: What should developers be aware of if they want to make their MIDlets work on as many devices as possible? AT: I think it would still be healthy to remember that embedded development is different from "mainstream" desktop or server software development. Developers should pay attention to memory consumption and battery consumption, and generally try to use programming patterns and idioms that are geared towards embedded software development. There is a good book available on this topic that I've recommended to a lot of people, Noble and Weir's Small Memory Software.
QM: What is happening with the PDA profile or is that confidential information? AT: I haven't been following that activity for quite some time, so I don't really know the details. My personal interest has always been more on the mobile-phone side, I guess partly because I come from Finland, the home country of Nokia, and partly because mobile phones are where the really large device volumes are. The figure for total annual units sold is over 20 times larger than that of the PDA market. Out of curiosity, I just checked the JSR 75 web site recently, and it seems like the PDA expert group is finally reaching the finishing line. So things seem to be moving along. QM: How did the J2ME platform come to be? AT: This would be a very long story. The short version is that Motorola played a key role in the creation of the initial J2ME standardization activities, along with Sun's management. Both Sun and Motorola realized early on that, to create successful standards and products in the mobile Java area, we needed to have all the key players involved in the work. I was very surprised how quickly we managed to bring all the key companies to the same table, and how quickly the ground rules for the CLDC and MIDP standards were established. QM: The J2ME platform consists of configurations and profiles. What was the reason behind that architecture? AT: The main reason is the fragmentation of the embedded-systems market. There are so many different kinds of consumer and embedded devices that it would be impossible to address the needs of all those devices with just one standard. If you added all the necessary features into a single standard, you'd end up with a system that would be way too large for any particular device. That's why the notions of configuration and profile were invented. In short, configurations represent horizontal, "lowest common denominator" platforms. All the devices supporting the same configuration are assumed to have roughly the same amount of processing power, memory, and so on, even though the target markets of those devices may be entirely different. Profiles represent vertical market segments or different device categories. They address the needs of a particular type of a device, such as a mobile phone. For instance, MIDP defines a bunch of APIs that are specific to mobile devices. QM: How are you involved in the J2ME standardization process? AT: I've had sort of an "on and off" role. Initially, I was very closely involved, because I was the specification lead for CLDC 1.0. After that effort was completed, I didn't do any spec activities for quite a while, until I was asked to lead the CLDC 1.1 activity. That work was finished about a year ago. I guess I prefer doing technical work and research a lot more than participating in standards bodies. But participating in the standardization activities is important, so that one can have a better understanding where the entire J2ME platform is headed. QM: What are your thoughts on the other half of J2ME technology: CDC, CVM, Foundation Profile, and so forth? Do you see this technology picking up soon? Do you see it being deployed on set-top boxes and the like? AT: So far, the deployment numbers for CDC-based devices have been much smaller than for CLDC-based devices. But there is definitely a lot of interest in CDC currently, and it is possible that the demand for CDC-based solutions will increase dramatically as the device capabilities increase over time. Set-top boxes are just one of the application areas, along with high-end smart phones, PDAs, and mobile enterprise client devices. QM: Floating-point numbers are not part of CLDC 1.0, but CLDC 1.1 supports them. Why weren't they included in CLDC 1.0 in the first place? AT: The lack of floating-point support in CLDC 1.0 was mainly because of historical technical limitations in embedded devices. When we started the KVM development and the CLDC 1.0 standardization effort, there were no cell phones on the market that would have had hardware support for floating-point calculation. Even floating-point emulation software was not readily available at that point. QM: Do you see a future for CLDC and MIDP on Palm OS devices with 64MB of RAM? AT: It is definitely possible to run MIDP on Palm OS, but it still remains to be seen what the preferred or recommended J2ME standard for Palm OS will be. QM: In your opinion, what is the greatest achievement of J2ME today? AT: There are at least three key contributions. One is that J2ME has opened up an entirely new market for software developers. The second is that J2ME has made it possible to develop completely new types of applications and services that are truly mobile. The third contribution is that J2ME has made mobile devices a lot more customizable and personalized. If you go back and think about what cell phones were like five or six years ago, you realize that they were extremely closed and proprietary devices. The only personalization that you could do was adding your own phone numbers to the phone book. With the introduction of J2ME, mobile phones have become open and customizable. And for the first time in history, it has become possible to develop applications that work across a range of different devices from different manufacturers. Granted, there are still lots of compatibility problems, but the advances and changes in the past three to five years have nevertheless been phenomenal. QM: Does J2ME have any competition? AT: Sure: Qualcomm's BREW [Binary Runtime Environment for Wireless], Microsoft's Smartphone, ... QM: What do you think about WAP [the Wireless Application Protocol]? AT: I have some friends who were involved in the original WAP specification efforts back in the mid-1990s. They did some really neat work, but unfortunately they were a bit too far ahead of their time. Also, the technology that they developed was rather clumsy and difficult to use. It really didn't help that the marketing people then overhyped the technology, before the actual devices were ready for prime time. And when the WAP devices were finally launched, there were very few applications or services available, so the consumers couldn't use their WAP phones for anything useful. Interestingly, now that I'm living back in Finland, I use WAP almost daily. The technology still isn't very exciting, but there are some pretty useful news, weather, and financial data services available. And the technology works reliably all over Finland and across Europe. QM: WAP has been successful in Europe but not in North America? Any reasons why? AT: Well, the U.S. wireless market has historically struggled with a myriad of incompatible standards, poor network coverage, poor call quality, etc. Consequently, it has been very difficult to create reliable data services that work consistently all over the country. WAP is just one victim of this problem -- there are many others. For instance, the Short Message Service (SMS) is incredibly popular in Europe, but little used -- and still unreliable -- in the U.S. QM: Is there anything we can learn from the WAP experience? AT: The key point is that when we design new technologies for consumers, we should try to be primarily consumer-driven, not technology-driven. Another important point is that whenever we launch a new technology, we need to make sure that the content (interesting applications, services, etc.) is there right from the beginning. QM: What about the success of NTT DoCoMo's i-mode, which enables users of compatible mobile phones in Japan to browse web sites and download applications? AT: i-mode has been phenomenal. One of the key reasons for its success was that DoCoMo started collaborating with a large number of content developers early on. They didn't simply create a technology, but an entire business infrastructure and framework as well. Certainly the fact that Japanese consumers love gadgets also helped in the adoption of the technology. QM: What are your thoughts on Qualcomm's BREW? AT: In terms of the deployment statistics, BREW is not a very strong competitor, but it has gained ground in some areas. I may be biased, but from the European perspective Qualcomm has always been a niche player. They missed the GSM bandwagon that happened in Europe and all over the world except Japan and the U.S. Their CDMA technology is technologically advanced, but it never caught on as well as GSM did. With BREW, they are tying themselves again to a proprietary technology. Because Qualcomm controls BREW in a much closer way than Sun can control J2ME, they can move ahead with new features a lot quicker than us. But in the end I believe that open standards will win. QM: How does J2ME relate to technologies like WAP, BREW, and Bluetooth? AT: Well, WAP, BREW, and J2ME are all technologies for content definition and, to some extent, content delivery. Bluetooth belongs to a different camp because it is essentially just a communication protocol between devices. All of these technologies have some good qualities, and there is really no reason why they couldn't work together. When you compare J2ME, BREW, and WAP, you recognize that WAP is much less client-oriented and less interactive than the other two. J2ME and BREW are relatively similar in terms of the functionality that they offer to the users -- but J2ME is open and BREW is not. QM: What do you think of Microsoft's Smartphone platform? AT: Microsoft is trying to attack the wireless device space from the high end. Their strategy has always been to write software that addresses the needs of the hardware to come, and not so much the computers or other devices of today. In that sense, they are using the same old strategy that they used in the PC space. In the PC market they succeeded because of Moore's Law [that processing power doubles every 18 to 24 months]. Even though their software was always slow and crammed with many unnecessary features, sooner or later there would be PCs that would be fast enough to run their software. This strategy is less likely to succeed in the embedded space, because the development of mobile devices is constrained by so many factors other than Moore's Law: battery capacity, price, cost, convenience, style, .... At least so far, the Smartphone devices that I've seen have been rather clumsy, underpowered, and overly battery-hungry, but Microsoft has definitely made a lot of progress in the past couple of years. And as usual, Microsoft is a fierce competitor whose activities should never be taken lightly. QM: Do you think that J2ME will be the largest deployed platform on mobile devices? AT: Well, J2ME surely seems to have won the consumer mobile device market: mass-market handsets. In contrast, the battle for the domination of the wireless enterprise mobile device market has not really been fought yet. It is going to be interesting to see who the winners in the enterprise mobility area will be. QM: Where do you see J2ME technology three years from now? AT: I think one of the coolest things about J2ME is that it is enabling applications in some totally new, unexpected areas. People are not simply repeating "the PC experience" by porting their old desktop applications to run on mobile phones. Instead, we are seeing a lot of completely new types of applications that wouldn't have been possible or useful in desktop computers. As a result, one of the interesting things about J2ME is the unpredictability of the directions it is going. It is fairly safe to forecast that there will be at least 500 million J2ME-enabled devices in the world by the end of 2006. We also know roughly what the APIs will look like at that point. However, apart from the most obvious type of applications -- games! -- it is nearly impossible to predict what the most successful types of applications will be at that point. QM: What are your thoughts on wireless peer-to-peer? AT: WP2P will happen some day. Right now the architectural model for mobile devices is very server-centric. All the communication, software downloads, and so on happen through the servers. The server-centric nature of the wireless networks is a great business model for a lot of companies. In the future, you are going to see devices that will talk directly to each other, without intervention from the server. That's when P2P will really start entering the picture. Technologically, taking that step isn't actually a big deal. But there are a lot of business issues -- in essence, you will need a completely new business model -- and that's why the transition is likely to take a lot longer than many people assume or hope. QM: What are some of the challenges that wireless faces? AT: Oh boy, there are so many: fragmentation, complexity, the difficulty in creating new standards, ... There is so much unnecessary complexity in the current wireless technologies that I sometimes wish that we could start designing the devices and networks from scratch, but this isn't really possible. Progress in this area relies on being able to build new standards on top of earlier "legacy" technologies. As long as we manage to keep the technical complexity away from the eyes of the end user, we are still fine. But there is a danger that the internal complexity is becoming more and more visible to the user. That's a very disturbing trend. We should keep in mind that the primary users of consumer devices are consumers, not engineers or marketing people. QM: Wireless advertising seems to be gaining a lot of momentum. What is J2ME doing to help promote a standardized approach to presenting this information to users? AT: Personally, I wish that wireless advertising would never happen. But it almost surely will. There are no J2ME standardization efforts that focus primarily on marketing or advertising. However, many of the ongoing JCP efforts will be indirectly creating a lot of opportunities for the marketing and advertising companies. Take the J2ME Location API specification effort, JSR 179, for instance. The creation of location-based applications and services will open up a lot of entirely new possibilities for advertisers. QM: What changes are being proposed beyond CLDC 1.1 and MIDP 2.0? AT: Both CLDC 1.1 and MIDP 2.0 have been ready for quite a while now, but actual device shipments supporting these standards haven't really started until recently, so we haven't received a lot of change requests yet. The CLDC 1.1 specification is very stable, and there have been hardly any requests for changes or new features so far. There is a possibility that a maintenance revision of the MIDP 2.0 specification will be started soon. In general, most of the new J2ME functionality is being added to the new optional packages rather than to CLDC or MIDP. There are so many new J2ME JSRs these days that it's hard to keep track of all of them. QM: What are your thoughts on J2ME Wireless Web Services? AT: There is a JCP standardization activity that is focusing specifically on this area, JSR 172. I haven't been following that effort closely, so I'm not the best person to answer this question. QM: Processing XML on mobile devices is an expensive operation. What are your thoughts? AT: That is true. The dangerous trend that I've seen recently is that many developers are assuming that they can simply port their existing desktop applications and tools onto mobile devices with hardly any modifications. While the processing power of mobile devices is increasing and might allow this, there are many other factors (especially in the area of usability) that need to be kept in mind when writing software for mobile devices. QM: What are your thoughts on the security of wireless Java applications? AT: Security is obviously extremely important, because in many countries mobile phones are already being used for banking, stock trading, and other financial activities. Also, we are increasingly seeing applications that allow corporate databases and other enterprise information to be viewed and manipulated from mobile devices. Consequently, security has played an important role in many recent J2ME standardization activities, in MIDP 2.0 for example. QM: Do you have any advice for wireless Java application developers? AT: In terms of technical advice, I keep reminding people that embedded software development is different from desktop or server software development. Therefore, as I already suggested earlier in this interview, it is important to learn about programming patterns that help minimize memory consumption and battery consumption, that allow the limited screen space to be utilized efficiently, and so on. The other point that I would like to make is that you don't necessarily have to follow the crowd. Sure, you could make money by "downsizing" existing PC applications onto mobile phones, but the neat thing about wireless and mobility is that they are creating completely new business opportunities in areas that people didn't think about before. They are also reaching users that are not interested in conventional computers. For example, my father wouldn't touch a desktop computer with a ten-foot pole but he's already using his fifth or sixth mobile phone. Building useful services for ordinary people is a huge opportunity. QM: Any last words? AT: Well, this is a follow-up to what I just said: Be creative. Go boldly into new areas that haven't been earmarked by other companies. And have fun! Success is not just a destination but a journey and a mindset as well.
Back To Top | ||||||
| |
| ||||||||||||
Print-friendly Version
