Well, folks, it's a blisteringly hot day in San Francisco. I'm glad you're all here, because it's nice and air-conditioned. We're going to have a pretty code-intensive session today. I've got a fair amount of slides, but quite a bit of time at the demo machine, showing you how to develop your applets and do some debugging with Safari and the Java console. So let's get into it.

So today we're going to talk about the web-based deployment technologies on Mac OS X. If you saw session 608, you saw a little bit about applications and deploying those on Mac OS X. We'll get into the features available to you as an applet developer, some features available to you as a Web Start developer. I have a pretty long session with debugging tips for applets and some settings that you can use to help you figure out what's going on. And finally, at the end, we'll talk a little bit about helping you decide which is the right one for your deployment situation.

So here's a picture for deploying a Java application on Mac OS X. On the left, you have this traditional double-clickable application. Looks like any other application on Mac OS X. In the center, we have Web Start applications. And the reason we have sort of a left turn going on here is that you can deploy a Web Start application the traditional way, through a web browser with a link to the JNOP file. You can also make a double-clickable application out of that Web Start JNOP file.

And you can ship that around to your end users. Web Start is now smart enough that it will look at that JNLP file in the double-clickable, go out and update all the resources, and it will behave just as if you clicked from the link in the web page. And finally, we have applets through web browsers.

For this session, we're just going to focus on the right two-thirds of this diagram. We had a really good session about developing applications. Today, we're going to talk about your web alternatives. Specifically for applets, this is sort of the landscape today. Anything that uses the old embedding framework will get Java 1.3.1, and those are things like Internet Explorer, Netscape, or anybody else who's adopted the embedding framework.

Currently, if you are a Cocoa application, and right now that's primarily Safari, but you would use the Java Cocoa plug-in, which uses the 1.4.1 VM and the 1.4.1 applet viewer. And that distinction is somewhat important if you've done development on Windows, because you know the feature set between the two plug-ins is somewhat different.

All right, to build an applet-- when building applets on Mac OS X, some things you want to know and keep in mind is that it's all built on the Java plug-in technology. The applet viewer with Mac OS X is identical. It's feature-for-feature compatible with what you get on Windows or Solaris. It's already been installed. There's no additional end user install that needs to be done like you would on Windows. No getJava or anything like that. We've already done that for you.

: If you're going to use Safari or Applet Launcher, Applet Launcher is sort of a development tool that we use that also uses this applet viewer. You'll get 1.4.1.0.1. I want to make that distinction that we're currently at 1.4.1.0.1. 1.3.1 is what you'll get with Internet Explorer and Netscape and anything else using the embedding framework.

And another choice available to you on Mac OS X is Java Web Start. You can deploy an applet or an application, but Web Start is really geared towards delivering a full application via the web. We support one-click launching from the browser. Safari has already been configured to look at the MIME type for a JNLP file and open up Web Start and do the right thing.

It has the full dynamic updating features of Java Web Start. So you put all of your jars up on a server, and if you update those jar files, Web Start will just go get them and always bring the latest application down to your users. Scott Kovatch It has something I call, it's platform neutral, but it's not platform ignorant.

And by that, I mean you can tailor the JNLP file to the platform that it's running on. We'll get an example of that in a little bit. But basically, you can say, well, if I'm on Mac OS X, I need these additional files. We'll talk about that and how you do that.

Scott Kovatch And the big thing about Web Start is it lets you deliver a full application much more easily than you can in an applet. You can sign the application, and it gets the application done. It gets full access to the user's desktop just as a regular application to this.

And the last thing to mention, Mac OS X, out of the box, can serve a JNLP-based application. Now, if you're on Windows or actually in Solaris, if you're using Apache, for example, you know that you have to tell Apache that when it delivers a JNLP file, you have to send out the right MIME type with it. We've already done that for you. We've already configured Apache correctly, so there's no additional work for you to do if you want to use Mac OS X or Server to deliver a Web Start application.

Right now, I want to show you an example of some of these, I don't want to call them more advanced applets, but more feature-rich applets that are available to you. You've all seen an applet before, so we're basically going to focus on some of the more interesting ones as far as what's available.

Let's go to demo one. So the first thing I want to show you is Visual Thesaurus. And What's nice about this is it's got some pretty spiffy graphics for moving through a web of information about words. It's sort of a visual dictionary, if you will. So we'll start with the word demonstration.

And you can see it jumps to that word, and now I can start clicking through here to other words and continue on a web of following through the words. Okay, cool. So this is sort of a neat visual applet that sort of highlights some of the graphics improvements we've made in the latest release with the Java DP that was released on Friday.

One other applet I want to show you, this is games.com. Games.com is cool, not for the only reason that it has really nice Parker Brother games that I like to play personally, but... One of the new features in 1.4.1 is that you're going to find that in 1.3.1, this applet would not work.

That's because we're relying on an older version of JSSE, Java Secure Socket Extension. A lot of those problems have been fixed in 1.4. So if an applet now encounters a certificate that it doesn't like in some way, whether it's out of date or self-signed or something like that, it will now ask the user if that's okay. And we'll just take a look at a game in progress here.

And the other impressive thing about Clue and some of these other games is they're fairly complex, and it's a great visual experience for the user. It's very responsive. And it's something you just couldn't do with 1.3.1. Now we can do it with 1.4.

So we won't find out who wins this game. But now, let's move on to a Web Start application.

And we've got, you know, save and print and all the things that you would expect out of an application. And what I'm going to do is create a very quick class diagram here. We'll use the canonical shape example. And we'll expand this a bit. Let's start with the shape class. Subclass it. Make a circle.

There you go. This is a Mac OS X application. It's...and it's delivered with Java Web Start. So whenever they make updates to Poseidon, all I got to do is just start it up again, and I'll get the latest version. Okay. Let's go back to slides. Let's get into a little bit more detail about how applets and developing applets on Mac OS X. Everything I'm going to talk to you about in these next few slides is documented at the URL you see here on the screen.

If you don't get it written down right now, that's okay. I'll show it to you at the end. But the message here is that everything you see in that documentation will work on Mac OS X. It all ported over fairly cleanly from Windows. What we're going to do is we're going to focus on the areas where we've made improvements for you in Mac OS X.

In particular, the first thing you want to think about in an applet is your HTML. A common question we get is, how should you write your web page? You can use an applet tag, object tag, embed tag. We would like you to use the applet tag if you haven't done so already. Applet is going to give you the most compatibility across platforms with Safari, Internet Explorer, or on Windows XP. The sun is really pushing people to use applet tags on Windows. And for the most amount of cross-platform compatibility, that's the way to go.

Another thing to think about... You should never assume a Java VM version based on the browser that you've got, that you detect with JavaScript. So just because a user's running Safari, don't automatically assume they're running 1.4. Just because they're running Internet Explorer, don't automatically assume 1.3. That will probably, it will definitely change in the future, and if you're making assumptions in your HTML, you're in for a lot of trouble. The best way to determine what you're running is when the applet starts up is to look at the java.version property, java.specification.version, and os.name. These three will help you determine exactly what you're running.

Now, Java.version will give you the full 1.4.1.0.1 with possibly a build after it, but Java.specification.version will give you the short, you know, what Java platform are you on. So in this case, for example, in Safari, if you did this, you would get 1.4. And that's it, just the string 1.4.

Another thing we often see is setting proxy settings. On Windows and Solaris in particular, this is a big deal. I think it's because Sun uses a firewall internally, so they need to get their proxy set up so they can get out of the firewall. On Mac OS X, there is one place to set proxy settings. That is in the network pane of the system preferences.

If you've got additional proxy settings for your particular deployment situation, create a new location in the network panel and set up your proxies that way. You can get at those proxy settings by looking at standard properties in your applet. If you've got additional proxy settings for your particular deployment situation, create a new location in your applet.

If we don't have a tech note or a Q&A, we should probably document the mapping of those things, but everything you see in that network panel has a corresponding Java property, and we'll get that information for you and make it available to your applet or application if necessary.

HTTPS is one of those areas that's really improved in 1.4. It's all built into the plug-in. There's nothing for you to do, and now in 1.4, there's nothing for you to do in your code either. All you need to do is make a URL with an HTTPS scheme and just open a connection to it, and we'll take it from there. It's all based on the Java Secure Socket extension, which is now a standard part of 1.4. In 1.3, it was an extra add-on that didn't really fit in with the plug-in, but it mostly did the job. But now in 1.4, it's all integrated and works very well.

One difference from Windows is that the root certificate store, by default, comes out of the keychain. Matt Kostin has a number of, I believe it's on the order of two dozen popular root certificates. And we can match a certificate that you generate against that list based on what's in the certificate. And sort of tying into that, if the user now decides that they want to always trust the certificate in your applet, we'll add it to the keychain.

And that gives the added benefit of letting people use the Keychain Access application now to take a look at all their certificates, delete them, or do what they need to do with them. It's not a common thing to do, but as you'll see, it's better than the alternative.

and the alternative is something called the Java Key Store. This is sort of Sun's cross-platform solution to storing certificates. Normally, by default, that key store is in /library/java/home/lib/security and buried down where a user wouldn't normally find it. It would have to go in a terminal to start doing things with it.

So as a result, you know, we've tried to start moving away from that and stick to keychain access. Now, currently, there is a bug. Actually, it's a bug generated from Sun where a self-signed certificate can't be stored in the keychain. That's not entirely true because I found situations where that's not exactly the case. But for, you know, for the sake of your development, let's assume that it's not going to work.

If that's a problem for you, we have a Java property, com.apple.security.useJavaKeyStore. If you set that to true, we will look in that Java key store for the root certificates, and if the user decides to always trust, that certificate will get stored in that Java location for certificates as opposed to the key chain.

Now, as I mentioned, if the user wants to do anything with their key store when you're using this property, they have to go in a terminal and use a key tool and start looking at, you know, looking with things in the terminal, and that's really not something we want end users to do. So that's why it gets a big red X. Use that key store as a last resort.

Most of what I said for HTTPS connections is true for a sign jar as well. You get full-signed applet support. It supports Netscape-style or IE-style signing. You can sign it once, and it'll work everywhere. If you sign something to work with a 1.x version of Java that comes with Internet Explorer, for example, or Netscape. Of course, now that the Java plug-in is pretty much becoming somewhat ubiquitous, this is less of a problem. But keep in mind that if you sign something for 1.0, it will continue to work in 1.4. I'm sorry, for 1.1, it will continue to work in 1.4.

And once again, if the user wants to always trust that jar file, the signature on that file, it will go in the keychain. And just like HTTPS, the same properties, if you will, apply to using that keystore if necessary.

For your deployment, try not to use a self-signed certificate. Use that key store as a last resort.

Okay. One thing that's new in 1.4, and is actually greatly improved in 1.4--over 1.3, is applet caching. And in 1.3, basically, applets were cached on demand when you were, I'm sorry, not so much on demand, but when indicated in the HTML file. In 1.4.1, every remote applet and every remote resource gets cached automatically.

will be joining us in a few minutes. Scott Kovatch will be joining us in a few minutes. I made a slight comment here about larger applets seeing the most improvement. That's because if you have a number of small files, the overhead of checking to see if things are up to date may negate all the benefits of keeping everything locally. Scott Kovatch I made a slight comment here about larger applets seeing the most improvement. That's because if you have a number of small files, the overhead of checking to see if things are up to date may negate all the benefits of keeping everything locally.

All right, what we're showing up here is an example of what you would put in your applet tag. I've left out the rest of the applet tag and only have the relevant parts for applet caching here. And what you're seeing here is, I guess, what I would like to call 1.3-style applet caching, because it works in 1.3 and 1.4. But what you have is, first of all, the first parameter is called cache archive, and what you list there is all the jar files that you want cached for your applet.

So you just string them out in a comma-separated list. And what goes along with that is something called cache version. And as you can see, the format is a dotted hexadecimal four-part number, so it looks something like an IP address. But you have to have one of these for each entry in the cache archive. So in this case, we have three jars we want to cache, and so we have three versions that match up with each other.

with each one of those jars. and the way this works is that the Apple viewer will look at each version and it will look at what it's already got cached. So if it sees in the cache, well, I already have 1.2.0.1 of a.jar, well, I don't need to update or do anything.

The reason this speeds things up at load time is that by default, The default mechanism for checking if things are up to date is to look at the last modified date on a jar and the size. So the Apple viewer will send an if-modified since up to your server to find out if that jar file is newer than what it's got.

Okay, and now the new 1.4 way is something called Cache Archive EX, and we have some additional things that you can specify in the HTML. Okay, what's different now is that the jar file name and the version are all put together in the same tag now. So you have the jar file name, semicolon, something optionally called preload, and then the version. And if you get preload, that means everything is loaded up front when the jar file is downloaded.

So if you, for example, want to stick a jar full of images in your applet, you could stick them all in that jar file, and they get loaded and turned into images right away. So you take a little bit of hit up front, but you take less of a hit while the user is running the applet. So the perception will be that things are somewhat faster.

So there's an example of how you can use that down below. And in this particular example, the way I've set it up, applet.jar always uses the default mechanism for seeing if it's up-to-date, and it gets preloaded. util.jar gets preloaded, and it has a version on the end of it. tools.jar gets loaded on demand and has a version at the end of it.

So that's some things about the HTML and some other things that you can set up for your applet. Let's talk a little bit about the debugging tools available to you. As a developer, you're probably going to be using the Java plug-in settings application quite a bit. We keep it in Applications Utilities Java, and there's two versions in there, one for 1.3 and one for 4. Pay attention and pick the right one for the VM that you're going to be targeting.

I'll give you a demonstration of how you go about using this later on in a few minutes. But that's where it's found, and we'll talk about it shortly. And one of the things you control with that is the Java console. The Java console is where you'll find all the system.out and system.error if it's turned on, if your applet generates any messages like that. Exceptions, stack crawls, things like that will all go here. It's got additional logging and tracing mechanisms that are very useful to help you keep an eye on the loading activity for your applet.

You can get thread stacks. If your applet's hung, you can go over to the console and find out where the deadlocks are in your applet. It's got something called class loader cache control, which is important for when you're doing iterative development. We'll talk about why you need to know about that and why you need to clear it out every now and then.

Let's go to the demo machine again. And now I'm going to spend some time actually developing an applet. : And show you some of the techniques that you can use for doing some debugging. All right, so the first thing I'm going to do, I'm going to start with the Java plug-in settings.

This first tab has the controls for the Java console. Right now, we only support either making it visible or not making it visible. On Windows, you can hide it in the toolbar so that it comes up minimized. We don't have a good mechanism for doing that on 10, so right now we only have show or don't show, basically. So for this example, I'm going to show it, and the console only comes on when an applet is loaded. So if Safari launches up, you will automatically get a Java console. And we can turn this on to pop up an alert when an exception happens during loading.

I'm going to turn it on for our examples here. Click Apply. Now I'm going to go over here to Xcode. And for the purposes of this demonstration, I made a very simple applet that's going to paint out a system property.

As part of building this, I want to point out one of the nice things about about Xcode is that I can set Xcode up to automatically sign my JAR file.

You have to sign the JAR file for this applet in order to get this to work. And so I've added a shell script phase where I'm just gonna run JAR signer and I've already got a key start with a self-signed certificate in it on my disk. So we're gonna build the applet and it's going to automatically sign it for me.

So we're going to build it. And that is that. It's pretty-- not much to do here. Alright, so there's my console. Okay, now here's my security alert. It says, "Do you want to trust this applet?"

The message I'm trying to give you here is that a self-signed certificate is inherently unsafe. I, in here, said I'm with Apple Computer. Well, I am, but I could easily have said I'm with Sun. Or I could easily have said I'm from the government. So, we're just going to say yes, and there's our property. All right.

So I'm going to bring up the console here, show you a few things that you can do. Let's see. All right, one of the first things I'm going to show you is-- I'm going to hit S. And here's a list of all the system properties. Now, because this is a signed applet, we're allowed to read every property available in the system.

I'm sorry, available in the VM. So we've got a number of these, you know, sun.boot.class.path, things like that, that you wouldn't normally get from an applet. Click H to get the help again. Another thing is a list of all the threads that have been created by this applet. We have a thread group for your applet down here.

Here's my applets main thread and the event queue for it. So you can take a look at those. And 1.1.4 is the ability to dump out all of the thread stacks. And as you can see, the deepest stack is the one that responded to the keystroke for the dump all stacks.

That's usually going to be the case. In fact, you'll probably always find this particular stack when you're looking at the stacks for your applet. All right, so let's go back here and to Xcode, and let's make a very small change to the applet. I'll just say "Home dir," and I want to build it.

All done there. Okay, so I'm going to go back here and refresh. And look, gee, nothing happened. That must be a bug, right? No. This is not a bug. The reason is something called a class loader cache. And what the plug-in does is it caches class loaders. Say that ten times fast. You'll just spin your head around for three minutes. What it does is that it caches class loaders so that if you go back to a page, it speeds up the load of the page again. Because starting up an applet is an expensive operation.

Now, if you're doing iterative development like this, that's going to be somewhat of a pain. So the console gives you the ability to hit X, and it clears out the class loader cache.

Just to show you, if you've done some, we'll reload this applet. Let's see here, I have two Safaris running.

Oh, empty the trash. Oh, well, okay. All right, let's move on. All right, let's go back to the Java plug-in settings here. Over here on the Advanced tab, we have a little box called Java Runtime Parameters. This is a place where you would set properties that can go into, that the app will pick up.

You can actually set a number of the properties that you saw in the session on applications, things like anti-aliasing and things like that. But for the purposes of this discussion, one of the more interesting things that you can set is security-related properties. So I'm going to define, just to show you some of the security properties available, I'm going to do java.security.debug equals help.

and here you can see everything, all the properties available to help you figure out what's going on with your jar files when you're loading up an applet. This is really useful when developing a signed applet because, as you'll see, it'll dump out a ton of information to the console about what it's doing while it's looking at your jar file or looking at authentication. Another common use for this is with the policy. I won't show it in this demonstration, but the combination of access and policy.

Say you're developing an applet and you're doing something that generates a security exception and you can't figure out why. If you set this particular property, java.security.debug equals access, it will show all of the permission checks that it's doing and log them out to the console and help you figure out what's going on. All right. So that's it for that. So I'm going to show -- here I'm going to put java.security.debug=jar.

I can see I've got a whole pile of information about how it's taking a look at all the entries in my manifest. Here's my certificate. is looking at the public key. Just a ton of information that will help you figure out what's going on if something goes wrong.

Okay, let's quit Safari one more time, and let's go back here to the plug-in panel again. Over here is the cache control panel. For an end user, the reason they would use this, If you run a lot of applets in your day-to-day work, for example, a common situation is Oracle. Oracle delivers a ton of their functionality via applets.

What you can do is you can go over here and set the jar compression level. Now, if the jar that you deliver is already compressed, this won't be much of a savings. But what this will do is, since these are all zip files, when it writes them out to disk in the cache, will compress them even further.

We'll take a look at the cache. And we'll see here's games.com and Visual Thesaurus in the cache. As I mentioned before, you know, we didn't have to do anything. All this stuff got cached for us automatically. Now, one thing you'll notice is that in this demonstration, I've been building a jar file and, you know, running it through Safari. So you may ask, well, where is it? Well, it's not cached because its scheme is file. A file-based applet won't be cached. Thank you.

Okay, now this is completely separate from the Safari cache or the Internet Explorer cache. It has nothing to do with any of those. So I can go in here and delete individual entries out of here, for example. And Safari's cache will not be touched at all. And I can clear out the entire cache. You know, just like that.

I'm going to show you very quickly the certificates tab. This tab only gets used when you've set the property that uses the Java key store. So if the user would then, you know... I haven't trusted any sites and stored them in the keychain yet. That's why these panels are empty.

But if I did, I would see them in this panel, not in the keychain. So if you don't want to use a keychain for whatever reason, you would come over here to the plug-in settings and look at it that way. Okay. Now the last thing I want to show you is using the keychain.

For this particular example, I'm going to go to Install Anywhere's download site for Install Anywhere 5. Here we have a signed applet. It was generated by a thought, which is one of my root certificates, so it's showing up as a trusted certificate. and this time I'm going to say always. I always trust it. And now I'm going to go over here to locations, utilities, key chain access. And there I see my certificate.

We've got all the details of the certificate. And if I quit Safari again and load it up. Here you go, we didn't get the security dialogue because we already said that we already trust the certificate that came from install anywhere. So now I'll go over here and delete this.

We'll go back and load up install anywhere. And there it is. We don't have it anymore, so now it's asking us to trust it again. This is pretty much immediate. Whenever I click always, it immediately goes right into the keychain. I can take a look at it. Okay.

All right, let's go back to slides. So I hope that gives you some new ways of looking at your applet development and some additional things that you can use for your deployment. Let's talk a little bit about Java Web Start now, some of the details for OS X.

On Windows and Solaris, it's possible to tell the user, hey, you don't have the version of Java that I want you to have for my application, so I'm going to download it for you. Well, we don't support that in Mac OS X. If end users need to go to software update to get Java 1.4.1 or our website to update the VMs...

Finally, with Web Start, keep in mind that if you want a native library, which is something you can do in Web Start, it has to follow the Mac OS X conventions. So it has to be lib, the name of the native library name, .jnilib, where native library name is what you would pass as system.loadlibrary.

And here's an example of something I was talking about earlier, where you can install Mac OS X specific resources using a resources element. And if you pass in OS equals Mac OS X, only those things will be downloaded to the user when they're running on Mac OS X. You can do this for Windows, you can do this for Solaris, but on Mac, you specifically have to use Mac OS X, because that's our OS.name property.

Another thing we commonly get questions about is the JVM versions. And specifically, if I specify a J2SE version, well, what am I going to get? Now, in Web Start, this is far more well-specified than we do in applications. Applications, it's pretty much identical to this, but for Web Start, it's very well-specified what you're going to get. If you specify 1.3 star, you're going to get 1.3.1. "If you specify one four star, right now you will get one four one.

Now, In the future, if we do a 1.4.2 or a 1.3.2, not that we would do that, but say we do a 1.4.2 or 1.4.x, we have an implicit ordering that says we will always give you the newest dot-dot version, if you will. So when 1.4.2 comes out, a 1.4 star will give you 1.4. We'll give you 1.4.2.

And similarly, a 1.3 plus or a 1.4 plus gives you the most recent VM greater than or equal to, um... I'm sorry, instead of doing it mathematically, what it will do is it will give you the newest VM that's newer than that baseline that you specified. So 1.4+, if we have 1.4.1, 1.5, 1.6, whatever, it will pick the newest one. It will pick the, yeah, it will pick the newest VM.

Now, one thing we've done, I've done below, put red Xs over the product version of the J2SE version tag. The first four are platform versions, and that's the most flexible because basically you're saying that I work with anything supporting the 1.4 platform. Similarly with applications, if you say that I only support 1.3.1,

All right, let's talk about some new things that we have.

In the update one for Jaguar that just came out, we now have cookie integration with Safari. This is something that's been long requested, and now that we've finally got Safari, we've got a good platform, and now we can work much more closely with them. This is one of the first things that you're going to see as a result of that collaboration.

Nothing needs to be done on your part to get this to work. If there's a cookie, if the user's already got a cookie for a particular URL, we'll fetch that out of the database and send it along with the HTTP request for the jars or whatever other resources are needed. Same goes for set cookie as well as get cookie. It works in both ways.

: For 1.3.1, we don't have that integration, but we do have a Q&A, number 1265, that gives you an example of how you would go about doing this on 1.3. It's not automatic. There's some work that you have to do, but we think it's a good compromise until you're able to move over to 1.4.1. And we want you to give us your feedback on using this.

Another new thing to talk about, let's go back to our Where We Are Today slide. And as we mentioned, that 1.4.1 is only available in Safari right now with the Cocoa plug-in.

What we want to announce this week is the availability of a Java Carbon plug-in. And what this will do is it won't automatically make it available to IE and the other browsers, but they will now be able to get to 1.4.1 via a Carbon plug-in. So if there are any browser vendors out here in the audience that are built around Carbon applications,

Finally, let's talk about some deployment choices that are available to you. Everything I'm going to talk about here applies whether you're doing it on Windows or Mac OS X.

So basically you want to look at the resource needs of what you're trying to deploy. If you're just doing something simple, talking to a server, giving some status, things like that, look for a simple applet. That's probably going to be your best solution. If you need to write something out to the user's disk as a preference or something like that, look into a signed applet.

If you want to build a real application, you want to deliver it dynamically, Web Start's the way to go. Web Start will let you have some native code to put some customization into your application. Web Start's also going to give you all the functionality that you need. Things like the EAWT and things like that are available to you through Web Start, so you can build a full application with Web Start. So if that's what you want to do and use dynamic updating and all the features of Web Start, that's the way to go.

Here are some more URLs for everything I've talked about in this session. For Web Start documentation, start at our site and I'll eventually take you over to Sun's site where you can get the JNLP spec. The JNLP specification is what you need to look at if you're going to be delivering Web Start. Look again with the Java plug-in documentation. Go to java.syn.com. Everything you need to know about applets is there. And, of course, all of the Apple documentation for Java in general.

You can go to connect.apple.com and you can get the 1.4.1 developer preview, update 1 developer preview. There is now a quick time for Java Seed.

People to contact, Alan Samuel, Bob Frazier. I highly recommend that you join Java Dev if you haven't done so already. It's a great resource for getting lots of questions answered, and usually very quickly. Not by one of us, but one of the other members.

And here are the rest of the sessions. Actually, for those of you watching me on DVD right now, you can go back and get session 608, which talks about Info.plist. We've got an additional session this afternoon on Java native integration. Good session tomorrow about performance, and please come tomorrow to the feedback forum and give us your feedback on anything you've seen this week.