Moderator (MDR): MDR-Nancy
Guest Speaker (SPK): SPK-name
SPK-John Pampuch: Hello World!
MDR-nancy: Welcome to the HotJava Browser forum. Hi John. Thanks for joining us today. Terry Cline will also be joining us shortly.
SPK-John Pampuch: Hi Nancy, Thanks for inviting me!
MDR-nancy: John, can you tell us what your role is on the HotJava team?
SPK-John Pampuch: Nancy, I am one of the software engineers working on the Hotjava browser. Most recently, I've been working on the user interface of the security facilities.
MDR-nancy: Terry Cline has just arrived. Can you tell us what your role is in HotJava team?
SPK-TerryCline: Hi. I work on just about anything needed to be done on HotJava. I worked on a lot of the customization stuff -- frame-handling code, resource management for low-memory, ... And the external viewer most recently.
MDR-nancy: Thanks Terry. Here's our first question from speitrow.
spietrowicz: Can John explain the new security features for applets in the new version
of HotJava?
SPK-John Pampuch: I think I can answer that... <gr> Java has always had the ability to support alternate security managers. The previous versions of HotJava Java used the standard applet security manager. In the most recent release of HotJava (prebeta 2) we have added a more flexible security manager that allows users to provide applets with access to local files, and other services, which were restricted previously. These services can be permitted two ways: by granting access to signed applets and by granting access to all applets from a specified site. I could go into more details, but it might be easier if I answer specific questions.
MDR-nancy: hobbsa has a question about JDK 1.1 support.
hobbsa: When will HotJava support the 1.1 JDK. I am mostly interested in the JDBC and Security portions?
SPK-TerryCline: The pre-beta2 version of HotJava runs on JDK 1.1. The 1.0 FCS will come out
on 1.1. For JDBC, it depends when that ships. They are on a separate schedule from HotJava and JDK1.1.
SPK-John Pampuch: We will be fully supporting the new security features of JDK 1.1, although most of the the new security features of HotJava 1.0 were possible with the previous JDKs.
MDR-nancy: These are good questions. Continue to send them in!
MDR-nancy: Here's one from JohnEng.
JohnEng: In your web pages you mention that HotJava can load applets from behind firewalls -- does that simply mean that HJ does not have the DNS resolution problems that Netscape does?
SPK-John Pampuch: I'm not certain I know the entire answer to this. But Netscape may put specific restrictions on applets, which prevent use behind firewalls. Also, we may have slightly different security policies. The DNS explanation may also be related. In anycase, I'll see if I can find a more complete answer as a followup to this conference.
MDR-nancy: Here's another question from hobbsa.
hobbsa: What features will HJ offer that Netscape and/or IE will not. What advantages will Java Applet users have over using HotJava?
SPK-TerryCline: We'll be the first browser to use the 1.1 JDK features. (And for a while the only one until those companies release new versions)
SPK-John Pampuch: Because of our more flexible security manager, applets will be able to do more (like writing to files, etc.) that will make more useful applets, like word processors, more practical. Also, our browser is 100% pure Java, so it will really be the same (exactly) on all support platforms. (And the list of supported platforms is growing!)
SPK-TerryCline: We'll be fully HTML 3.2 compliant with support for object tags.
SPK-John Pampuch: Hotjava's user interface is completely customizable, so it is a great fit for embedded environments, like PDAs, as well as allowing users quite a bit of control over its presentation.
SPK-TerryCline: Many of the UI elements are implements as a combination of applets and HTML pages so they are customizable that way, in addition to the menus, controls, URL field, and elements that are customizable....
MDR-nancy: These are a lot of great features! Here's a question from patricksimp.
patricksimp: What are the goals of the HotJava Project? I mean is this a example of what Java can do or a real product?
SPK-John Pampuch: Where are those marketing people when you need them?<g> Both (it is a floor wax and a dessert topping). HotJava is certainly one of the first demonstrations of what Java could really do. But it is also a real product. There are certainly advantages to every commercial browser on the market, (including Hotjava), and Javasoft would like to see HotJava successful.
SPK-TerryCline: It's probably the only browser that can run in 2Mb of RAM!
SPK-John Pampuch: That by itself makes it a real winner in many places. Also, in areas like Kiosks, Net Computers, etc., it is really the only browser that is practical. It just so happens, it is also a pretty good browser on PCs, and other places where Netscape and Microsoft also run well.
MDR-nancy: JohnEng has a question.
JohnEng: Can you share your experiences in moving the HotJava code to the JDK 1.1 AWT model -- was it a rather big effort? Do you like the 1.1 model better?
SPK-TerryCline: We're using some of the new features (scroll pane, for example) but we are not using the new event model. It will probably be the next thing we do after the FCS release. We're living proof that the old event model and the new event model are compatible!
SPK-John Pampuch: Applets can use the new event model in Hotjava 1.0 FCS.
MDR-nancy: Our next question comes from turbogek.
turbogek: Could you briefly explain signed applets and how security is relaxed?
Also, is the applet signed or is each class/file signed?
SPK-John Pampuch: Briefly, probably not. <g>. First, applets can be signed by bundling them into a JAR file (essentially a ZIP file). The JAR file can then be signed. The jar file is signed using a certificate approach, and the user can grant permissions to applets that are signed using a specific certificate. At this point, we are discovering that there are some UI issues that need to be resolved in the permission granting process, but the basic technology has been demonstrated (internally). If you are willing to struggle through the creation of certificates, JAR files, etc., you can use the current prebeta 2 release and experiment with it as well. Have I answered the question, or are do you need more details?
MDR-nancy: Patricksimp has another question
patricksimp: I have another question, I understand that the currently available system is
pre-beta, but there still seems to be quite a bit of work to be done on formatting
and speed issues before this becomes viable. Are these issues going to be
addressed in time to meet the suggested release dates?
SPK-TerryCline: We have not done any tuning yet. That will be done during the beta process and before FCS.
SPK-John Pampuch: Also, we are working to relax our parsing even more... our initial implementation was very strict HTML 3.2, but Netscape, in particular, is remarkably tolerant of bad HTML. We do, of course, also have bugs, which need to be fixed. We certainly wouldn't choose to release if we had formatting bugs that were intolerable (which is where we are now.)
MDR-nancy: JohnEng has a question.
JohnEng: It appears that the general model in HotJava is to use a combination of several applets to achieve its functionality. Do you use inter-applet communication? If so, are you concerned that IAC is not clearly spec'ed?
SPK-TerryCline: There are two parts to the answer. Within HotJava, we subclass applet to provide a common parent and access to the applet context and to the editor's window itself. People writing applets to be seen in another browser can use a similar facility that is part of the advertised API for applets (hang on while I look this up)... In an applet, there is a method GetAppletContext. And from the context returned, you can find out about other applets on the page and set up whatever communication you want.
SPK-John Pampuch: Also, in the future, applets that are Java Beans will be able to use the features of Beans to provide inter-applet communications. Hotjava implements most of its UI using applets, but in order to do so, it exposes additional features to its internal applets so that they can work.
MDR-nancy: Here's a follow-up question to the one above.
JohnEng: What about applets appearing in different Frames (HTML frames)? They do not share the same AppletContext (at least in Netscape). Can we depend on static variables to be shared across frames for IAC?
SPK-TerryCline: Since each frame is a separate document, I'll have to check to see whether or not we do something different from Netscape. I'm not sure without looking. Send me the question (terry.cline@sun.com)
MDR-nancy: Here's a follow-up question to the previous HTML question.
spietrowicz: Follow-up to the HTML rendering question: Do you want us to submit
bug reports for sites that don't quite render correctly, or do you want us to
hold off until the next rev comes out? Getting a list of sites you can use
to test against may be helpful.
SPK-John Pampuch: I'd rather hear about them early than later. On the other hand, I'm concerned about being deluged with bugs, but it really doesn't take us long to identify duplicates, so getting reports to us is going to help. Of course, once we ship the next release, I'd want everyone to switch before reporting more bugs.
MDR-nancy: Patricksimp has a comment and another question.
patricksimp: Thankyou, I am hoping to be able to use HotJava1.0 as an example of what
can be done with this technology to justify further development to senior
managment <g>. Please keep up the good work.
patricksimp: How easy/hard is it to extend or implement your own internal applets for
HotJava?
SPK-TerryCline: Thanks, we appreciate the support. We'll try to make HotJava as good a vehicle as we can. It is as easy as for any other applets -- depends on what the applet is supposed to do.
SPK-John Pampuch: What do you mean by `internal' applets? I guess we're thinking in terms of applets that are part of Hotjava, but to add one later would be a touch more difficult, only because you wouldn't necessarily know the public interfaces that are exposed to internal applets. Also, of course, you'd need to have the class files locally to get all the added features of the internal applets.
MDR-nancy: Turbogek would like some clarification.
turbogek: Whoa! You said "applets that are Beans" what do you mean by that? Are you saying that I can Introspect other applets and call their set/get and other Beanish methods????
SPK-John Pampuch: I'm not sure I am enough of an expert to answer that question fully...(I can investigate later). But... Provided the permissions are granted, I think this would be possible.
MDR-nancy: Here's a question from Spietrow.
spietrowicz: Are there any plans to support JavaScript at some point?
SPK-TerryCline: It will not be in the 1.0 FCS but we do not see a need for it because of what you can do with applets. But it may be considered for a future release.
MDR-nancy: We're running out of time. Here's our final question from hobbsa.
hobbsa: Will HotJava allow applets to run without any restrictions (connecting back to the same URL, etc.) and will it also allow applets to not be displayed in dialog without warning banners?
SPK-John Pampuch: Yes and no. By default, applets will have restrictions similar to what they have now. (Possibly with warnings that allow the user to grant permissions on the fly.) But users will also be able to grant permissions more fully to signed applets, which would allow them to connect to other sites, write local files, display dialogs without warning banners, etc. This would be under user control, so rogue applets would still be reasonably restricted.
MDR-nancy: This concludes the HotJava Browser forum. Thanks for joining us.
SPK-TerryCline: Thanks for having us.
SPK-John Pampuch: Thanks for coming! Bye
MDR-nancy: Last moderator (me) signing off. The forum is now unmoderated
spietrowicz: Thanks Terry and John
