So today, this is sort of a layered look at the Java deployment options that are available to you. You can build a double-clickable application, you can build a WebStart application, or you can build an applet and deploy it either through a web browser or through Applet Launcher. For this talk, we're going to focus on the right two-thirds of this chart, specifically WebStart and applets.

If we focus a little bit more on applets today, you see that if you have an applet that you're trying to deploy, you have a couple of options available to you. You can use Internet Explorer. You can use any other application that takes advantage of the Java embedding framework. Or you can use Applet Launcher, which is available in applications utilities. Now Internet Explorer and other applications work atop the embedding framework, which ultimately works on top of sun.applet.appletviewer. Applet Launcher talks directly to sun.applet.appletviewer, and you get a good, basic, double-clickable Applet Launcher.

So, how should you code your web page if you want an applet to show up inside of that? Well, for us it's pretty easy. You just use the applet tag. You know, you go to Sun's tutorial, read up about how to deploy applets, how to get applets to show up.

Everything you see on Sun's website is exactly what you need to do right now in Mac OS X. Some things to remember. Remember that the AWT widgets have the Aqua look and feel. Therefore, it's a really bad thing to hard code component sizes into your applet. A Aqua button is not going to be the same size as a window button or a motif button.

Furthermore, if you use some JavaScript to detect what platform you're on, know that if you've detected Mac OS X, you have Java 1.3.1. You don't have to ask if there's a plug-in. You don't have to ask what browser you're running on. You can just know that you're running on Mac OS X.

If you're writing an applet in a browser today, you should know that you have pretty much the same functionality as you can get out of UserBin Applet Viewer or the Applet Launcher. By this, it means that your applet will get the basic init, start, stop, respond to events the way you want it to. The main addition First you should know that all outputs, system.out, system.air, goes to the console application.

The additional thing is that we support signed applets inside Internet Explorer. You can use Netscape or Internet Explorer-style signing. If you sign your applet to work on Windows, it will work on Mac OS X without any modification. Use an RSA-style signature for your JAR files. And that is actually the main functionality that we provide over and above what you can get with the basic applet viewer.

Now Java WebStart, which is something we first started shipping in Mac OS 10.1, Java WebStart is an application as opposed to an applet deployment technology. I put it that way because, yes, you can deploy applets with Java WebStart. It's much more powerful than an applet deployment mechanism. So I think if you have something that really needs to be an application, you should really start taking a look at Java WebStart.

gives you one-click launching from the browser. You click from a JNLP file link in a web page, it will launch Java WebStart, your application will start up, and all the resources will start downloading for you. Scott Adler, and it's got a dynamic updating mechanism built into it already.

I call it platform neutral but not platform ignorant. By that I mean that you can set up your WebStart application. You can configure it such that on Mac OS X, if there are some additional features that you want to provide, like say you only want to provide only QuickTime for Java, where it makes sense, for example. Well, on Mac OS X and Windows, you can do that and you can ease the download burden on your user by only configuring the applications so that only those platforms get those specific resources. We'll talk briefly about how to do that.

The best advice I can offer you is you should use WebStart when the browser and its limitations get in the way. WebStart will let you read and write files from the user's disk, it will let you print, it will do a lot of the things that an applet normally just will not let you do. You can do this from an unsigned WebStart application, but you can take advantage of WebStart's functionality that will let you ask the user if it's all right to do these things first. as opposed to an applet where you just get a security exception saying no.

Remember that on Mac OS X, the end-user's desktop is already ready to go for a WebStart application deployment. They don't have to go to any website and download a package, download a Java VM. It's all just there. You can use it out of the box. Now, in most deployment situations, there's no special server support needed either.

You can just put your JNLP file and the JAR files up on your web server, and they will download, and you're ready to go. WebStart can download them. Now, if you do use Apache on OS X and Puma, you will need to configure Apache so that it knows how to send out the correct MIME type for the JNLP file. That's being fixed in Jaguar. You won't have to do anything about that.

And I mentioned here there are optional deployment tools available from Sun. You can set up what's called a download server. It'll let you do things like, you can set up things called jar dips, so you can download only the portions of the jar files that have changed. That's all pure Java. That's all operable from a servlet which you can install and it'll just As I mentioned, you can install Mac OS X-specific resources.

And to do that, it's very easy. In your JNLP file, you add another resources tag, I'm sorry, another resources element, and it has an attribute of OS equals Mac OS X. That's all you need to do. And in that, you can add any additional jars, any additional images, properties that only apply to Mac OS X, and so on.

Now, this is just sort of a bigger picture view. That attribute corresponds to the OS.name property. So if you want to do this on other platforms, just know what the OS.name is, and you can set up your JNLP for just about any platform you need to deploy on.

An important distinction, we do not support the downloading of a JRE. That's because the Java has already been installed for you on OS X. If you try to request a version that doesn't exist, you will get an error. I'm sorry, the user will get an error. And it'll handle the situation gracefully, is what we're trying to say here. Now with 1.4, the pre-release that's available today, We have not updated WebStart or haven't really done anything to specifically support that 1.4. I think by the time Jaguar ships will be ready to be able to deal with that switching as needed.

Now remember that in a WebStart application, you can also include native libraries. Those native libraries must be bundled in a jar file and they must be signed. Now on Mac OS X, all your JNI libraries end in .jnilib. So that's what we will look for. It has to end in .jnilib for us to load it as a native resource for your application.

Okay, right now I want to bring up Sean Allen and Jared Kaplan from TechEdence. We're going to show you, you've seen some of their demos in earlier sessions, and they're going to show you about how you can use TechEdence with WebStart and some of the other cooler features that are available to you.

So we're here from TechEdence to show you our application authoring tool, which creates Java applications. Basically what we can do is build applications out of pre-compiled Java objects, and our engine sort of lets these applications be a living thing that can be manipulated easily at runtime and wired together using JavaScript. I think you're on the... You're all set. Go ahead. Am I live? Yeah, go ahead. Okay. So we're just going to -- the reason we're here at this session is because we can publish using Java WebStart as an option.

So what you're looking at here is our object browser, and it basically has a default template with a window, and if you click on the window, you see the properties. So we have a property editor, and you can turn down the window and see the objects below it and so on. And if we open the window, we can actually edit the window in the spatial editor.

So if we go to the scrapbooks, Magic comes with about 80 sort of atomic objects that you can use to build other objects out of. They support user interface as well as importing Java code and web services and media. And so first off, maybe we'll just drag out a couple simple UI elements, maybe a slider and a couple of buttons.

So as we drop the button and drag and drop it in, and the slider as well, you can see that the application's actually sort of being built live. If you go to the instant preview mode, The buttons are going to be live right away, so we can see that they're going to work. But what we'll do is import some media really quickly. If we can grab a QuickTime movie and drop it in.

We like running Magic on OS X because we can take advantage of the QuickTime, the AquaUI, Java WebStart, all bundled and ready to go. So Jared just brought in a QuickTime movie. And now to add some functionality easily, he's going to use the patch tool to select and patch the slider and the buttons to properties of the movie. So as he clicks on the slider, he can choose the percentage value of the slider and then control any object that's on the screen here so he can control the current time. And then he's going to hook up the buttons to start and stop the movie.

So that's sort of showing some media and some UI elements, but we wanted to show some web services. So let's try doing -- bringing in some web services. Yeah, I think I'll just build a simple web service application here. I'll start off just by creating a new document. When we create a new document, we have a bunch of preset templates that are made. We'll just start off by creating a new basic application.

And we get, you can see here, a new empty template application. What I want to do is bring in another type of media here. It's a web service description file. It's a WSDL. And I'm going to bring in a pretty simple one. Most of these web services that we pulled off of X methods, so they're just standard services available out there already. So when I drag in the WSDL file, you can see it gives me an option to import it as a web service object. So I'll select that.

And you can see it shows up here in the window editor. Also, in the structure view, you'll see the web service object here. And what it does is parses out WSDL file and pulls out all the methods that are available in the web service. And here you can see a get traffic method and just an asynchronous result of that service.

And so what we'll do is just go ahead and bring back up that user interface scrapbook. And what I want to do is bring out a text field. Now I know that this web service, what it does is it takes a highway number and it'll go out and find the traffic information for that highway. And so using that patch tool that Sean was talking about earlier, I'll just select the text field and choose to take the text value. And I'll just connect it right into that web service into the get traffic method.

And now what I need to do is bring out another text area that we can put the results in from that service. So I'll do that. Resize this, make it a little bit bigger. And then patch from that web service object the result. And just take that value and patch it right into the text value of the text area. And so now when we go into the preview mode, you can see what the traffic's like on 101.

If we had a network cable, that was plugged into the... When we are connected to the network and that's working, that's how you do it. At least you know it's not a canned demo now. Our software actually, sometimes it doesn't So I guess what -- no, we don't have that web service to show you. I can show you actually a similar thing.

Besides bringing in web services, we actually -- we can also bring in just Java code directly, and it's handled in a really similar fashion. So if we had, say, a Java class we wrote, stuck it in a jar, and it actually, you know, could fake it and return a web service, I could show you that. But what we have here is a text-to-speech jar. So I'll drag that in the same way that I did the web service. And when I bring that in, you see it shows here I can import it as a Java class. So I'll do that.

And since this is a JAR file, we have to specify the actual class file within the JAR. You can see here, similar to the web services, this just uses reflection and finds the public methods available in that Java class. This class here has the same method and a stop. What I'll do is go back to the window. Instead of patching the text to that web service, let's just patch it into the Java class instead, because hopefully that will do something exciting.

And of course, we don't have the audio hooked up either on the machine, so...

We have Java code that we can import. But really, you guys are all here to see the WebStart, and hopefully we can get that to work. Let me go real quick to the WebStart, and then if we can get the network working, we can show you the web services after.

So this is a game that Matthew created, sort of a Tetris-like game that we... This is the obligatory Tetris-- authored Tetris application that every authoring tool has to make. And if we bring up the window object here... You can see here there's the pretty complicated looking application, but if we go ahead and run it, you can see here we have a... It actually has some nice sounds, but you're not going to get to hear them.

So you can see we have a pretty nice working Tetris application here. And when you're done authoring an application in Magic, what you'll do is go into the publish, You can see we have different formats that we can publish in. Here you see a standalone document, a Java application. The Java application will just publish a standalone JAR file. But what we're interested in here today is the WebStart.

I already have the WebStart application selected. I can come here and you can see that we have some properties that we can set up. This is the information that just gets put into the JNLP file. We have a description we can set, the company information, and the home page, which is the link in the WebStart application, what will show up for that application, and an icon file. Let me actually just go in and reselect that icon file.

I'm going to just choose a GIF file for the icon. And you can specify code base. What happens when we publish the WebStart application, we publish it to the local file system with a template HTML file and a JNLP file, but we also publish a JNLP file and a template file with setup for whichever, for a remote code base if you're going to end up pushing it onto a server. So I'll go ahead and start with the JNLP Let's make sure I'm publishing this to the home folder.

Okay, so now that I have that set up, I can just go ahead and publish. And what it's doing while it's publishing is just going through the application that you built and collecting all the class files that was used in your application and collecting all the resources and media and creating a new JAR file out of that.

So while it's publishing, I'll just mention this is basically our beta trial version. It's available if people are interested in checking it out. You can go to our website, which is techadents.com, and you can download it if you want. And we have a user forum where you could even give us feedback if you like. So here you can see we've published to a local directory on the file system, and there's the local HTML template that we can launch. And here we have a simple template that you can modify if you want. Go ahead and launch.

I was complaining about not knowing the signer of the application. Just start it. And there you have it. A WebStart application that was pretty easy to make. So I think that's about all we're going to show, but we're going to be around. If anyone wants to talk afterwards, we'll hang out after the session.

Thanks a lot. Thanks. I feel like all you folks are in push-ups right now, but I don't think you want to see that. So right now I want to hand it over to Scott Adler, who's going to talk about the embedding framework and some of the features of applets and embedding.

So the embedding framework. The embedding framework is something we built when we moved to Mac OS X so that you can actually embed applications into--embed applets into browsers. It sits with all the other frameworks. That's where it is if you want to use the terminal and look for it or however.

Specifically, built for embedding applets into Carbon applications. I'm saying this because we have a lot of people who are trying to use the embedding framework for other things that it wasn't actually built and tested for. Feel free to try that out, but what we're building this for is for embedding applets into browsers.

The main clients are web browsers. How would you use the embedding API? If you look inside of there, there's a whole bunch of header files and things. You want to know how you actually would create your own applet container. First thing you have to do is you have to create the Java VM, because you're going to own the Java VM. That means you should create one of them. If you're doing a whole bunch of applets, you create one, you let each applet run, and then you get rid of that when your application quits.

Next is, there's this thing called the JNI environment. That is the context that you have to pass into all these, to our embedding framework every time you talk to us. You have to tell us what is the environment for this VM, because we don't own the VM, you own the VM.

Then you actually create the applet and you actually will fill out some structures talking about things that you've parsed out of the applet tag because you're a browser, you've just parsed that applet tag, and you're going to tell us what to do. So you create the applet. Then you actually create a control.

This is the representation of the screen space that the applet is going to take up. It's very well documented inside of javacontrol.h, what that createJavaControl does. That returns you a Carbon control back, and you use that as a Carbon control in many ways, except for the ways that we have to differ from the way Carbon controls work.

Mostly because Carbon is cooperatively threaded, and Java is preemptively threaded. That leads to many issues when you make a call in Carbon, you expect that nothing's going to happen between when that call starts and when that call stops. What actually happens is we might be painting the whole time while that's happening, and we get to some of that. So during the lifetime of an applet, first, we automatically init the applet for you. You've created it. It's been inited. You just have to tell us to start it.

Then you have to move and clip it together. These are actually separate calls in terms of typical control manager calls. You actually would move and clip it so that we can all do this in one atomic operation. Because, like I said, we could be preemptively drawing, and that could stop your cooperative threads, and we could just start blasting to the screen.

If you don't move us and clip us at the same time, if you move us, then you clip us, we're going to draw all over the place because we haven't been clipped correctly. So you have to use this instead of the control manager APIs. Instead of calling Draw1Control, you're going to call DrawJavaControl because we need a way in, which you'll see in a second.

And then asynchronous drawing. This is, again, the big problem we have in interacting between these frameworks is you've got, let's say, an applet that's drawing an animation. So you're just drawing like crazy on Java threads. You're calling paint over and over and over again. The Carbon application decides, you know what, we're going to live resize you now.

If we keep painting, you're not going to be able to tell us, hey, you're not supposed to be painting now if we didn't have these APIs. So you actually stop us from painting while you're doing things like live scrolling, live resizing. You'll know when the good places are for us to draw again, and you'll give a call to draw Java control. And then when you're done, you'll say, OK, I'm done.

Start us back up and we'll start animating. And you can actually see this if you run Internet Explorer and you load any animations and you just grab the grow box or something like that. You'll see sometimes animations seem to slow down a little bit, but at least they aren't overdrawing all portions of the screen. and then to end of life the applet. You stop it, you destroy it. Pretty straightforward. Then you get rid of the VM.

So, embedding applets, the summary. So, this summary is a very interesting summary, and it'll talk about some of our features. And the summary is that the new Java Internet plug-in should eliminate the need for all that stuff I just talked about. And that's really important to us, because the fact that I had two slides on it, and it's pretty complicated, and there are a lot of issues with frameworks, we don't want you to have to deal with that as browser vendors. And so, we're planning on providing an Internet plug-in that will take care of almost all the needs of the embedding framework.

So now we'll talk a little bit about where we're going. You've seen this sort of slide before. The one thing I wanted to point out is that, and Scott will talk about this a little more, is this double-clickable application area here has sort of slid in under WebStart applications, which means that we're going to have some good news about WebStart applications here.

So in terms of applets, where we're going. So I talked a little bit about the Internet plug-in, and you'll see here that these are the new pieces to this slide, to this stack. And the things we've added is the Sun Java plug-in code and the Java Internet plug-in. And what you'll see is that Internet Explorer, the way it exists right now, it'll use some things using the embedding framework and some things using the Internet plug-in, depending on tags, and we'll get a little bit more on that.

There's all these Netscape 4.0 compatible plug-in browsers out there, and they'll all just use the Internet plug-in and get that for free. And then there's the other embedding applications, and those will still use the embedding framework, but we're hoping that everyone moves over to the Internet plug-in. And then the fact that Sun's Java plug-in code that we've taken, we've put underneath the embedding framework, means everyone, without any modifications, now get all the new features of the Internet plug-in. So there are a bunch of features. We'll get into that. Yeah.

So Internet Explorer's applet viewer, this is what I explained in this last slide, will be based on the Java plug-in applet viewer. So the thing that most people use when they get Mac OS X out of the box is they run IE, they go to some website, it has a game, and it runs our embedding framework. So you will now get the Java plug-in applet viewer inside of there.

You actually get some good user feedback when you're loading applets. There are some things that are drawn in Java that say loading certain things or progress bars and stuff like that. So it's pretty good instead of just waiting and not knowing what's going on. There's a lot better signed applet support inside of the plug-in itself.

And then the biggest new feature for developers is the Java console. And this is an optional thing you can turn on. It's interactive, meaning that when you load an applet, the first time you load an applet on the browser, this will pop up if you have the preference set. And we don't want users setting this preference, so we ship it default off, and you can set it using some of our other tools.

And it's an interactive console. So when it comes up, all of the thread info, if you want to find out about it, if you want to force garbage collection, if you want to look at details of what's going on inside your applets, because it can be kind of confusing.

And since you're not an application, you don't own this stuff. The browser owns the VM. This actually gives you a window into seeing the VM, seeing all your stack traces here. It's pretty neat, and you can see, we'll show a little bit of it in a demo. System out and system error go here. Logging and tracing is a big feature of this. You can set log levels on your logging. You can log different actions, and then you can set log levels and see what's going on. what is outputting and Scott will show a little more about that.

The Java plug-in settings we're going to include in Jaguar also. And this is where you set things related to this plug-in specifically. And you see the very first one is--I mean, the very second one is show the Java console. So that lets you turn off that console. It'll ship with it off. But if you need to turn it on, this is where you find it.

It's gonna be--it's planned to be an application_utilities. It lets you set the VM arguments, so this whole text field here lets you set things like, do you happen to know that you're gonna be shipping this large intranet application, so you have to increase the VM heap size, because Java still has this set limit on the VM heap so that it doesn't overrun, take over the whole system, especially applets. You don't want a bad applet to show up and just start allocating memory and just bring down everything. And there's a whole bunch of other things. There are other panels in there, and we'll get a little more into that.

The Java Internet plug-in. We're separating what Sun's plug-in is from the Internet plug-in. The Internet plug-in is the Netscape 4.0 style plug-in that we've now wrapped our embedding framework inside of there. You don't have to deal with it. You just deal with this Netscape 4.0 style plug-in. So any of these apps, any of these browsers that support Netscape 4.0 plug-ins should just work. It's all based on the 13103 release of the plug-in.

So now we're getting into the messy world of the Internet. The thing about the Internet is that when the Internet started, it started this thing called NetTime, that like every week was like a year or something like that. And so the Internet's really old now. And we're suffering from that because the Internet went through all this stuff of how do you use applets? Well, you use the applet tag. Then along came the Java plug-in, and you had to use the embed tag and the object tag.

And then this big company from Seattle came along and said, "We don't want that to work anymore," so Sun made it work with the applet tag again. So there's this whole confusion of what's out there. And there's web pages that do everything, all these different things. So people ask me, "What are we supposed to do?" And so we're encouraging people to use the applet tag. That hopefully will be the future of applets. Again, we're not defining this. We're trying to follow what other people are doing and make sure that you guys can deploy where you need to.

Some older browsers, they actually don't use the plug-in for the applet tag. So on our platform, like Internet Explorer, they take the applet tag and they use the embedding framework. In the future, hopefully they'll change this and they'll use our Internet plug-in, but they may not. And if they're not using the Internet plug-in, they own the VM.

It's up to them to do things like get those VM parameter options and things like that from the plug-in. What we're really hoping is that all the browser vendors move their applet tag to actually use the correct MIME type and just hand this off to the plug-in. And then it'll be a consistent user interface based, whether you use the applet tag or the embed tag.

Now, if you want to force people to use the plug-in, you can use the object and the embed tags. And that obviously will go through the browser and load a plug-in for whatever MIME type you specify. And to do this, it actually was a pretty hard thing for people to do. You don't want to go type in all your code.

So Sun provides a thing called the HTML converter that will convert old applet tags into this new object and embed tag framework. Now, it's confusing for me to say the new object and embed tag framework because it was new a year ago or so, and it's already going a little bit out of style because they're encouraging people to move back to applet.

So even on Windows, it's very confusing because if you're on older browsers, the plug-in won't work with the applet tag, and on newer browsers it will. So it's kind of a confusing thing, but we're encouraging people to use the applet tag. If you want to use the object and the embed tag, you can.

So just to give you a little overview of where this is, there's browsers and tags and what different things work in different browsers. On Mac OS X, we have IE 5.1, and with Appletag, it uses the Java embedding framework. Other--if you want to get to the plug-in, you use the object tag.

Netscape and Mozilla. The applet tag, by default, gets pushed the same way as the embed tag does with a built-in MIME type of application X Java applet. So that just works with our plug-in. And then the other tags, they look at the embed tag and they ignore the object tag, they look at the embed tag.

Opera is very similar to the way IE works. This is just sort of sampling of browsers that I've found. Java embedding framework they use for the applet tag. They're still working on their support there, which is one of the reasons why we're trying to get the Internet plug-in to work, because not all developers have an easy time with this. And then they use the object tag.

And then there's the latest IE on Windows, which the applet tag goes to, who knows, goes to the 1.1 VM if the user's downloaded it. If they set a preference, they could go to the plug-in. It depends on what the user might have done. So it's not totally sure what will happen there.

And then if you use the object tag, you can specify VM versions and things like that. So it's very similar to the way the object tag works on IE5 on the Mac. So now I want to show a little bit of the Java plug-in. So if we can go to the second machine here.

Oh, I do it. Aha. There we go. Cool. So this is Jaguar with the, I think it's the same as what we shipped to you guys. And I've got a bunch of browsers on here. And I'm going to show browsers other than Internet Explorer for a change. And so let's start by looking at Opera. I've already got some of these loaded. So in Opera, I'm going to look at this one. So this is Opera. This I just downloaded from their website. I didn't make any changes to their application. I, it just uses the Internet plug-in.

This actually has, I don't know if you can read the, I don't know if you can read the URL, but it's an embed tag. It's actually being pulled down over the Internet from my home server. And it's just working. And that's what we expect to happen with this. It even has, let's see if this loops around again. It should have interactivity. Yeah. So this applet has some mouse overs and things. So if I mouse over here, it pauses and I can click on it. And if I'm actually, yeah, I'm connected. That's cool.

So I got to the Apple page. So it's got a couple things in here that, things you expect to see in applets. I specified, this is just a little customizable applet. So I decided it would be nice to have it snow in Florida where the shuttle launches. So you can do that.

So, so that's just an example of the plug-in working right here in, in Opera. So an interesting thing I downloaded the other day is this program called Chimera, which is called Navigator, but the project is Chimera. And it's taking Mozilla's rendering engine and wrapping it inside of a Cocoa environment. So it's, it's basically Mozilla, but using Cocoa.

So this is kind of cool because this is, again, they just, this is version 2.4, 24. I'm not sure how the version numbers work, but they, they released this last week sometime. And this was their first release that actually worked with Netscape plug-ins. And I just loaded up this one applet that has, you know, it's just a little display applet and it just worked here. So it was, it was pretty cool to see that that works. This is, again, I didn't talk to the developers.

I just went to their website, downloaded it, tried it out. So that's a little applet there. We can, and then there's one other one. Let's see. And then in Mozilla itself, Let's see, Mozilla, make a new... Yikes. Okay. So in Mozilla here, I'll just go to my site.

Let's see. Okay, so I play here and I... For those video game diehards out there, you'll notice all the differences between this and the real game. It's pretty cool. This is all running on Jaguar. These aren't applications we touched at all. With Mozilla, I just wanted to point out that the guys at Netscape are actually working on a really good implementation of the plug-in on top of our embedding framework.

Some of the good things there is that they're doing more than you can do inside of the Netscape or OAPX. I just wanted to point out really quickly that we do have the Java console running here in the background. I just hid that out of this browser, but you could look at things in the console if you want. All the dumps are going there.

You could print out your entire thread list if you want here, and there's nothing running, so that's not that exciting. You can look at a lot of stuff. We could actually look at our memory usage when we're not running it all, and I think that's M. Here we've got some stuff sitting around because they haven't shut down the VM. That's about it for the demos. If we can go back to slides, which I still do, and I'll bring it back to Scott. Thank you. Thanks, Scott.

All right, now I'm going to spend a little bit of time talking about some of the additional new features in the plug-in. And the first of these is jar caching. Now, if you've used this on Windows, you know that jar caching lets you store jar files from your applet on the user's hard drive for later use.

It's very similar to the jar caching that we had in the older version of MRJ from the OS 9 days. You may need to modify your HTML to get it to work. I say may because if you've already done it on Windows, you shouldn't have to do anything on the Mac.

The cache is stored on a per-user basis in their home directory and library cache is Java. The reason we did that is to make it so that the user can go in there and clean up after the applets after a while, if necessary. Let's talk a little bit about the HTML changes that you may need to make.

First of all, if you want to turn on the JAR cache, you have to have a param in your applet that says cache option and with the value of plug-in. You must have this or you will not get JAR caching. The next thing, you need to specify the jars that you want cached. That's just a comma-separated list. Param name is cache_archive.

And finally, an optional tag. Actually, I think I reversed this. If you want caching, you need cache archive. The cache version param, that's optional. And what you do with the cache version is that you have a list of version specifiers that map one for one with everything in the cache archive. If they don't match one for one, you'll get an error in the applet viewer.

A little bit more about the cache version. You don't have to modify your JAR file. All you're doing is you're modifying your HTML so that you can tell the browser, the version that I think that I have on the server is this specific version. If that's newer than what's on the user's machine, the Apple viewer will download it.

If you don't specify the cast version, by default you use a head request. I'm sorry, the Apple viewer will use a head request and do an if-modified-since lookup. That's not a big deal, but that's some network overhead. So if you want to cut down on the network traffic, use the cache version, and that'll save you some trouble.

And note that the jars that you specify in the cache archivers are going to be searched first as far as the search path, as the class path goes. Use the cache archive first and then we use what's in the archive tag. Now, we know that 1.4 is out.

Jar caching changed a little bit in 1.4, and we're going to be moving to this eventually, but I want to let you know what the differences are right now. The jars in the archive parameter are not cached. You must use the cache archive param to get the caching to work.

There's an additional parameter called cache version EX. I won't go into what that does, but just know that we don't support it. We'll ignore it. It won't give you an error, but we don't support it in 1.3.1. We don't have JAR indexing. That's, again, a 1.4 feature. If you use the cache archive and the cache version params now, that'll be your best compatibility route for 1.4 when we're ready to support the 1.4 caching mechanism.

Talk a little bit about HTTPS connections. There's no new bug here because it really hasn't changed since Puma. Again, if you want to make a secure connection, just make a HTTPS URL and ask for a URL connection out of it. This is exactly the same thing that you do right now in 10.1.

No additional initialization is needed. We set up JSSE for you already in the browser. Just go ahead and ask for a connection and you'll get it. As I mentioned, support is provided by JSSE. And JSSE is an interesting package in itself, and that's why I put this URL up here. You get a lot of good information about where it stores its certificates and other properties that apply to using JSSE.

Now, as far as certificates go with HTTPS, JSSC provides you a number of certificates by default. These are a lot of CAs. They're just a basic set of certificate authorities that are provided for you. If you need to add your own, go to Library, Java Home, Lib Security, CACerts, and you'll need to use the key tool to import those into that file. As you can imagine, that's not the most friendly way to do things. We're working on a better mechanism. We don't have anything we can talk about right now, but we are looking into doing this, making this better.

Talk about sign jar support. There are a few new things here. Not a lot, but a few. SSL certificates are not the same as sign jar certificates. They're similar in nature, but they're used in different ways. Again, sign jars continue to work exactly like they did in 10.1. There's no change to the support that we had before. The slight difference is that if the user decides they want to always trust that file, that jar file, we're going to store it now in your preferences folder with a more readable name, Java plug-in certificates 131.

You can also take a look at the JAR certificates that have been accepted in the Settings application. Basically, it will give a list of all the people that sent you a sign jar certificate so you can keep track of what you've trusted and what you need to pay attention to when you're running applets.

Okay, switching gears very quickly since I'm running out of time here. Java WebStart today I want to talk a little bit about how it works today. You go to a website that's got a JNLP link on it. Click on the link. We download the JNLP file. It gets fed through Java WebStart, and you get your Java WebStart application up and running. Well, here's where we're going with Java WebStart. Again, you'll have the link in your web browser. You'll click on the link. We'll download to a JNLP file.

We're going to provide the ability to make a double-clickable application out of that JNLP file. And, once you make that double-clickable application, the next time the user double-clicks or clicks on that link in the web browser, we'll go straight to that application. We won't have Java WebStart involved at all.

Talk a little bit about what's going on here in detail. A user will be able to create a double-clickable application from the downloaded WebStart application. So if you go into Java WebStart and you look at the Cached Application panel, you'll be able to select an application, go up into the menu and choose Create Application. You'll get a double-clickable application wherever the user wants to save it.

Now this is similar in functionality to what's called the Local Install mechanism, what WebStart calls Local Install. This is standard across platforms. We've chosen to implement this as a double-clickable application. And by doing it that way, we get some nice benefits that I'll talk about when I show you a demonstration.

It's done automatically via WebStart. By default, it's set up to ask the user if they want to do this, if they've run the application twice. I'll show you an example of that in a moment. We'll use your WebStart icon. Remember that you have to specify, or you can specify, a GIF or JPEG as part of your JNLP specification for your application. We'll take that, download it, turn it into a .icns file, and use that as the application's icon.

And finally, it is a double-clickable application, but it's a very small application. The actual resources for that application are downloaded into the user's WebStart cache, and it's stored on a per-user basis in the cache. Now, as I said, it's a double-clickable application, so you'll be able to customize this. That means it's got a plist.

That means it's got some properties that you can set. So for those of you that have thought in the past, well, how am I going to, you know, there's an ambiguity in the JLP specification about when properties get set. Well, by making a double-clickable application, you'll be able to set some of those properties at launch time.

And you'll find out a lot more about customizing applications in the next session. That's over in room J when we're done here. All right, right now I'm going to show you a demonstration of some of these features that I just talked about. And in particular, the application, or I'm sorry, the applet that I'm going to show here If you were at WWDC last year, you saw a demonstration of the Java speech framework. I'm going to write an applet that uses that speech framework just as a demonstration to show off some features. If you know anything about the text-to-speech, that's native code.

If you're going to use native code or JDIRECT in your applet, you need to sign that applet. This is going to show you an example of a signed applet and how that would appear to the end user and some things that you can look at yourself as a developer.

I'm also going to demonstrate JAR caching in this example as well. The reason why you would do that is in this case, you see I've turned on the cache with the cache option in the first param. I've got an archive here of the speech demo. That's what I'm going to build in my applet. The last thing is the javaspeechframework.jar. That's the speech framework jar that you can download off of connect.apple.com.

That comes out to about a 750K JAR file. A lot of users, DSL isn't that widespread and you still have a lot of 56K connections. That's a pretty good chunk of code to be downloading every time. That's the kind of thing that makes sense to cache on the user's machine for later use. There's a lot of things that you can do with this.

I'm going to show you how to do this. I'm This is the Jaguar version of Project Builder, and I've added a shell script at the end that throws everything into one directory, and it's going to assign the two jar files, one that I'm creating and one that I'm using as a library. And I've just built a, I don't Let's move that up here so you can see it a little bit better. And I've just built a simple file of keys that I used to sign the jar file.

So I'm going to go ahead and build

So what I've done is I've put my applet on my homepage.mac website. And now you can see that I've signed the jar file. And now we've got a slightly different dialogue than we, that we used to have in PUMA. And it's a little bit friendlier, a little easier to read. You can look at the details of the certificate if you need to. Who signed it? Where it came from? What organization? Things like that.

For this particular example, I'm going to say grant this session. You know, nice and simple, we have... We have no sound. No sound. Well, you're going to have to take my word for it that this speaks, because this is speaking in the demonstrations here. Volume's up. I'm not sure what's going on.

Now we've tried this. I know we've tried this. There you go. I sure like being inside this fancy computer. There you go. Just to prove that it does indeed work. Thank you. Okay, now, I'm also going to show you some features of the Java console. Since it came up pretty quickly, we're going to reload this applet and show you some things about it.

So first of all, I'm going to set the log level to 2, and we're going to get some basic and networking-related messages. So I'm going to refresh the applet. Now you see that we're getting a trace of the what's going on

Typically, this will help you figure out if something goes wrong in your init method or in your applet start, you'll be able to figure out when, what's being called, so you know where the problem is actually coming into play.

And here, this level of logging also tells you what's going on with the JAR cache. So as you see that I've asked to try to archive Java Speech Framework. We're going to see if it's up to date. And I didn't use the cache version option, so we're going to look at the timestamp.

The last modified, it hasn't changed. I put it up there a few days ago and I haven't changed it since. And we've run it on this machine once, so it's already in the cache and it's up to date. So you've got lots of good information about what's going on in the cache.

So now, I'm going to take the level up to three. Now I'll get some security information as well. So I'm going to do a refresh. And you can see that we've got tons of information about security and certificates and things that are, you know, shows you where the comparisons are going on, lets you look at the details of the certificates that are being compared against. Okay, I'm going to very quickly show you Java WebStart since that's one of the interesting things that we've done here. Okay.

So a friend of mine comes along and says, hey, I got this cool tool called SmartCVS. And it's a graphical CVS client. And here's the link down here, SmartCVS. We're going to download it. And, bad example, So as you can see, I've already run SmartCVS twice and we've created a desktop application for it. And it's gone right into, it's created the application.

All right, we'll try this one more time. Okay, we didn't find an application, so we're going to launch it the usual way. WebStart wants unlimited access, so I'll say yes and go ahead. We'll cancel out of that. Okay, now tomorrow I come along and I need to run it again, so I'll click on a link and we'll download it.

And WebStart's going to say, "Hey, you've run this twice. Do you want me to create an application for you?" So I'll say yes. And I'm going to put it on the desktop. Let's call it SmartCBS Beta.

Cancel that and click all that. And I can just click on that and launch it like a regular application. It's also got a plist I can modify so I can start working around with that as well. And that's it for Java WebStart.

So to sum up, which should you choose, Applets or WebStart? Well, it's only for you to decide. We hope we've given you enough information to start figuring out for yourself what's the right thing to do. If you're working on a web browser, we want you to support the Java Internet plug-in.

And finally, here are the remaining Java sessions. If you head over to Room J when we're done here, you can look into tailoring Java applications. Good things to see there. You see all the details about the other remaining sessions. For more information, if you want WebStart information, you can start at our page on developer.apple.com. I'll bring this page up again for Q&A at the Q&A session. How to get documentation. and you've seen all these before as well. A man to talk to is Alan Samuel as always for any non-technical or business-related information.