Moderator (MDR): MDR-lisa

Guest Speaker (SPK): SPK-alice

MDR-lisa: Hi, everyone! Welcome to Java Live. I'm Lisa Stapleton, editorial director of the JDC. My guest today is Alice Farrelly, Sr. Product Marketing Manager for PersonalJava^TM. She's here to answer questions about the recent release of the PersonalJava 1.0 Draft Specification, available at the java.sun.com/products/personaljava portion of our site.

jimheintz: How should someone go about developing a product based on PersonalJava? Are devices being built that use it? If so, who is making them?

SPK-alice: Since PersonalJava is a feature-level subset of Java^TM, many developers have already begun prototyping applications by using Java and the PersonalJava Draft Specification. In this way you may begin learning about PersonalJava, since the bulk of the classes are in the current document. Actual reference implementations for PersonalJava will be generally available at the end of this year.

btegtmeier: Could you use PersonalJava in a game system like Sony's PlayStation and browse the Web?

SPK-alice: PersonalJava is designed specifically for network-connectable devices, with sophisticated, visual user interfaces that can be used by consumers without computer experience. PersonalJava includes a new version of the AWT called PersonalAWT, which you can use to create user interfaces for games, PDAs, and so on. PersonalJava is designed to be portable to any operating environment. Its foundation is a Java Virtual Machine¹ with core and optional APIs built on top—similar to the structure of Java today. Therefore, yes, a browser may be placed on top of PersonalJava from which a user could browse the Web from their device.

Joubin: My biggest concern is the absence of RMI from PersonalJava. If a developer has invested significant efforts in creating a distributed system—inclusive of PDA and an embedded system—using RMI, what course of action do you recommend to them? Should they revert back to rolling their own protocol on top of java.net and forget about RMI? Or have you anticiptated these issues and have appropriate bridging means?

SPK-alice: RMI—excellent question. Keep in mind that PersonalJava is in public review and the spec is not yet final. We expect the spec to be finalized in mid-September. The RMI question brings up the general topic of network connectivity support. RMI is too large for target-memory footprints now (if I'm not mistaken), but it is being actively discussed at JavaSoft^TM. I don't have an official statement on this, but anticipate one soon. This involves both the RMI team and the PersonalJava team. (Remember—we aren't just cutting and pasting from Java. We need to address underlying implementations of features so they fit in the space and performance requirements of this market.) You ask if you should revert back to rolling your own protocol on top of java.net and forget about RMI. This depends on your timing. If you are basing work on PersonalJava 1.0, then you should probably use this route in the short term.

elnor: What are the delineating factors that someone should use in deciding whether to build their applications around EmbeddedJava^TM versus PersonalJava? That is to say, what killer functionality is supported in PersonalJava that is not in the Embedded spec?

SPK-alice: Deciding when to use PersonalJava versus EmbeddedJava depends on the device you are creating. EmbeddedJava and PersonalJava share the same core--though they are not necessarily "identical." EmbeddedJava has a smaller memory footprint, and is targeted primarily for high-volume, lower-cost devices such as pagers, low-end cell phones, etc.—devices that typically run on a less-powerful processor (>25MHz clock) and significantly lower amounts of ROM/RAM. PersonalJava includes the PersonalAWT, and offers graphics and windowing subsystems and supports java.applet. Therefore, PersonalJava supports the downloading and execution of applets from the Web, where EmbeddedJava does not. Note that both Personal and EmbeddedJava are designed to be modular and flexible. Developers are free to add their own apps, libraries, tools, etc. on top of the platform.

JoeSam: My question relates to all areas of Java, but is certainly important, maybe even critical for PersonalJava. We hear about 100% Pure Java^TM certification. Is there a similar certification process developers can count on for VMs?

SPK-alice: JoeSam, I'm sorry I don't fully understand this question. Can you provide more info on the VM angle?

JoeSam: I've seen comments that lead me to believe that different VMs act somewhat differently in timing, object construction, and so on. This makes me wonder how we can be assured that one VM is certifiably the same (in effect) as another. Does Sun or anyone else verify them officially?

SPK-alice: I am not the expert on the 100% pure program, but I can tell you that two new Java Compatibility Kits are under development to test for adherence to PersonalJava and EmbeddedJava APIs respectively.

MDR-lisa: I was wondering which features of Java are particularly suited
to embedded and personal systems?

SPK-alice: Java was originally created as a control language for an embedded device. As such, it has numerous features that make it an ideal language for embedded development. First, it's object-oriented, promoting code reuse and the creation of multipurpose objects, which contributes to reducing overall code size. Second, Java is secure. Unlike C/C++, Java contains no pointers, so access to memory or overrunning arrays can't happen. And those are bad news on an embedded device. Third, Java uses late binding, meaning you can create and load new classes on the fly. Classes can by dynamically linking and loading, enabe remote management of embedded devices (which have longer lifecycles than desktops). For example, a screen phone manufacturer is not going to want to replace the actual phone when upgrading—but rather upgrade the software within the product—keeping the hardware in tact. Fourth, Java saves codes space because Java bytecodes are generally significantly smaller, which saves storage space.

jimheintz: Who will be developing hardware that supports PersonalJava? Is JavaSoft developing any devices?

SPK-alice: Last week at Internet World Chicago, we did a press release naming some of our licensees. There are quotes from: semiconductor manufacturers—Motorola; real-time operating system vendors—Microware, Wind River, and more; and quotes from companies developing applications using PersonalJava—WebTV. PersonalJava has been gaining momentum since JavaOne^SM from the vendors who matter in the embedded market. This is great news. Unfortunately, who is designing which devices is usually a well guarded secret—and for good reason. As you know, many of the technologies of tomorrow are being developed now in the embedded market. Sorry I can't elaborate more.

mbf1: I have a question about the classes removed from the AWT API, or classified as Optional. How do programmers create a GUI-based program with the API without access to the AWT.Frame class? What GUI containers will be used if any?

SPK-alice: The use of frames implies the use of overlapping windows in the user interface. Given the screen limitations on consumer devices, and the technical expertise of the end user (remember your mom needs to run this thing) features such as: overlapping windows, scroll bars, double clicking, and pull-down menus should probably be avoided. The goal is to design a highly intuitive user interfacethat consumers will like and catch on to quickly. We are about to post a new document for public review, which is a style guide addressing the design of consumer interfaces using PersonalJava. Expect to see the guide in August. Certain high-end apps will want more functionality, so the current notation about Frames in the spec reads: "if a given implementation gives the user control over the placement of overlapping windows (Frames), this constructor must operate normally." Remember the spec lists classes of the following types: supported, unsupported, modified, optional, and new. Frames is an optional class for the reasons given above.

PeterGruhl: Please comment on the development process for PersonalJava. I assume we can develop under other systems so long as we restrict ourselves to the allowed subset of commands. Will the display look similar to the target device?

SPK-alice: This is the neat thing about PersonalJava. (sorry I'm biased :-) ) PersonalJava is a feature-level subset of Java, so the class structure is the same. The underlying implementation of a feature may change to make it more modular, smaller, and faster—since this is needed for embedded devices. Development is done using the JDK. We are enhancing the JDK so that you can use it to develop Java code for multiple JAEs (Java, PersonalJava, EmbeddedJava). So the JDK could be used to create both the device-resident code on a dedicated-purpose PDA. For example, when you return a rental car, the server-resident piece that accepts the information from the device and processes it.

MDR-lisa: I was wondering what kinds of things our developers are using PersonalJava for. Telephony, games? I'm just wondering, because it makes it easier for me to figure out what types of articles, tutorials, etc. we should put up on the web site.

PeterGruhl: In response to your last question, I am looking at developing for telephones and home automation—things like turning the lights on and off as people enter/leave rooms, controlling the stereo/TV/watering system, home security, voice activation, and so on.

MDR-lisa: PeterGruhl, that sounds really cool! I once did a story about people who used Unix systems to do the same types of things ("Men Who Have Ethernet Taps in Their Bathrooms, and the Women Who Love Them") for UnixWorld, and it seems like a lot of people are interested in off-the-shelf stuff that does those things.

SPK-alice: Since this is a developer chat, let's discuss the tools as well. As you develop Java code for PersonalJava, you will be able to use a tool that checks for adherence to the API prior to compilation. Also available separately is a tool to"ROMize", which compacts code and creates a relocatable image. However, the basic thing to keep in mind is that because you use JDK to develop, you can use the systems you have and start development prior to selecting or receiving hardware (the CPU selected for the device + RTOS).

Joubin: Are you in a position to elaborate on the security/encryption issues of PersonalJava? Will they remain optional, or will they become standard on these systems? If they will remain optioinal, what kind of network/system overhead should one anticipate for loading these packages on the fly?

SPK-alice: There are many devices where the security is not needed—games, for instance. For this reason it is optional. I don't have the numbers on network/system overhead right now, as we have not yet frozen the spec. Once we are really cooking on reference implementations, we will be more focused on performance. I have heard that people need a way to identify what resources are available on a device. This would at least enable apps to know if something isn't on the device they need to bring with them, like a downloaded applet that performs a financial transaction when a user selects an item to buy. We have this on the radar screen, but I have no official commitments yet.

MDR-lisa: Thanks to Alice and all the participants! See you next week!

> ¹ As used on this web site, the terms "Java virtual machine" or "JVM" mean a virtual machine for the Java platform.