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 Web Start and Applets.

forget focus on a little bit more on applets today you see that when you when if you have an apple they'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 job embedding framework or you can use apple launcher which is available in apple 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. Thank you. 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 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 10.1.

some things to remember remember that the w_t_ widgets have the Mac OS and have the opera 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. And 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... uh... which which i will get to in a minute uh... but first you should know that all output system.out system.err 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. Thank you, Dr. Now, Java Web Start, which is something we first started shipping in Mac OS 10.1, Java Web Start is an application as opposed to an applet deployment technology. And I put it that way because, yes, you can deploy applets with Java Web Start. 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 Web Start.

gives you one click launching from the browser. You click from a JNLP file link in a web page, it'll launch Java Web Start, your application will start up, and all the resources will start downloading for you. And it's got a dynamic updating mechanism built into it already. call it platform neutral but not platform ignorant. And by that I mean that you can set up your Web Start 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 quick time 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.

And 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. And 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. Thank you. 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. WebStar 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, and 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 work. Thank you.

Now, 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.

Excuse me. 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. Amen. 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 one dot for that you the pre-release that's available today uh... We have not updated Web Start 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 Web Start 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 TechEdents. 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 TechEdents with WebStart and some of the other cooler features that are available to you. Thank 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 precompiled 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 then. You're all set.

Go ahead. Am I live? Yeah, go ahead. Okay. So we're just gonna-- The reason we're here at this session is 'cause we can publish using Java Web Start 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 objects below it and so on. 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, you know, 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 Web Start 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 on a button-clicked message, we'll... set the playing state to true and on the other one we'll set the playing state to false to stop it. And again we can go into instant preview mode and try it out. It should just run so it's playing. That should scrub the time and the other button should stop it and start it. Amen.

So that's sort of showing some media and some UI elements, but we wanted to show some web services. So let's try 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. And when we create a new document, we have a bunch of preset templates that are made. And 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 gonna bring in a pretty simple one. Most of these web services that we pulled off of X methods, so they're just-- there's 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 it's 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. Thank you.

And now what I need to do is bring out another text area that we can put the results in from that service. So 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.

and maybe there's no traffic. Sorry to do web service. If we had a network cable, that was plugged into the... All right, so, well... When we are connected to the network and that's working, that's how you do it. So... At least you know it's not a canned demo now. Our software actually, sometimes it doesn't work.

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. 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 it's a jar file, we have to specify the actual class file within the jar. And you can see here, similar to the web services, this just uses reflection and finds the public methods available in that Java class. And this class here has the same method and a stop. So what I'll do is go back to the window. And instead of patching the text to that web service, I'll just-- let's just patch it into the Java class instead, 'cause hopefully that'll do something exciting. And of course, we don't have the audio hooked up either on the machine. So anyways, we have web services.

and we have Java code that we can import. But really, you guys are all here to see the web start, and hopefully we can get that to work. Let me go real quick to the web start. 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 work in Tetris application here. And when you're done authoring an application in Magic, what you'll do is go into the publish, And you can see we have different formats that we can publish in. And here you see a standalone document, a Java application. The Java application will just publish a standalone jar file. And -- but what we're interested in here today is the Web Start. And so I already have that Web Start application selected. And I can come here and you can see that we have some properties that we can set up. And this is the information that just gets put into the JNLP file. And so we have a description we can set, the company information, and the home page, which is the link if you-- in the Web Start application, what will show up for that application, and an icon file. And 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 a code base. And what happens when we publish the Webster 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 a remote code base if you're going to end up and pushing it onto a server. So I'll go ahead and start. 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, um, just a simple template that you can modify if you want, but just go ahead and launch.

I was complaining about not knowing the signer of the application. Just started. And there you have it. A Web Start 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 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. Now, 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.

course. That means 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, and that is the context that you have to pass in to 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. Thank you.

Then you actually create a control, and this is the representation of the screen space that the applet is going to take up. And it's very well documented inside of javacontrol.h, what that create javacontrol does. And 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. And 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. And what actually happens is we might be painting the whole time during 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 innited. 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. Drawing, instead of calling draw1 control, So 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 application or 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, "Okay, 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 plugin 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 plugin and that will take care of almost all the needs of the embedding framework. work.

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 Web Start applications, which means that we're going to have some good news about Web Start 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 plugin. So there are a bunch of features. We'll get into that.

So Internet Explorer's applet viewer, this is what I explained in this last slide, will be based on the Java plugin 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 plugin 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 plugin 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 You can set log levels and see what is outputting. Scott will show a little more about that.

The Java plugin settings we're going to include in Jaguar also. And this is where you set things related to this plugin 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 in application utilities. 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 more into that.

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

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 plugin. 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 plugin, you can use the object and the embed tags. And that obviously will go through the browser and load a plugin 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. 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. 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. If you want to get to the plug-in, you use the object tag. Thank you.

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 plugin. And then the other tags are 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. It 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. Thank you. So now I want to show a little bit of the Java plugin. So if we can go to the second machine here. Thank you.

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.

It just uses the Internet plugin. This actually has, 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 connected, that's cool. So I got to the Apple page. So it's got a couple things in here, 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 that's just an example of the plug-in working right here 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 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 their version numbers work, but they released this last week sometime, and this was their first release that actually worked with Netscape plugins.

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 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, I'm going Let's see, Mozilla, make a new, yikes. Okay, so in Mozilla here, I'll just go to my site.

favorite thing of playing some video games. Let's make sure the sound is on. Oh yeah, we're plugged in. Okay, so we get to play this little, um, Let's see. Okay, so I play here and I-- And for those video game diehards out there, you'll notice all the differences between this and the real game. So it's pretty cool. This is all running on Jaguar. These aren't applications we touched at all. And 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.

And some of the good things there is that they're doing more than you can do inside of the Netscape 408. So, I'll put it out of there. And I just wanted to point out really quickly that we do have the Java console running here in the background. So I just hid that out of this browser, but you could, you could look at things in the console if you want. All the dumps are going there, and so you could, you know, you could print out your entire thread list if you want here, and there's nothing running, so that's not that exciting. But you can look at a lot of stuff. We our memory usage when we're not running at all, and I think that's M. And here we've got some stuff sitting around because they haven't shut down the VM. So that's about it for the demos. So if we can go back to slides, which I still do. And I'll bring it back to Scott. Thank you. Thanks, Scott. Thank you. All right, now I'm going to spend a little bit of time talking about some of the additional new features in the plugin. 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. And 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. And 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. care. 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 plugin. You must have this or you will not get JAR caching. The next thing, you need to specify the jars that you want cached. And 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. Thank you.

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. Now, You know, 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 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. here. If you use the cache archive and the cache version params now, that will 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, JSSE 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 Plugin 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 Web Start 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 Web Start, and you get your Java Web Start application up and running. Well, here's where we're going with Java Web Start. 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 Web Start involved at all. All right.

talk a little bit about what's going on here in detail user key i will be able to create a double clickable application from the downloaded web start application so if you're going to have a web start you look at the cashed application panel you'll be able to select an application uh... go up into the menu and could that she's create application you'll get a uh... a double clickable application of wherever these are wants to save it now this is similar in functionality to what's called a 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. generation. It's done automatically via Web Start. By default, it's set up to ask the user if they want to do this, if they've run the application twice. And I'll show you an example of that in a moment. Amen. We'll use your Web Start 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. And I'm going to write an applet that uses that speech framework just as a demonstration to show off some features. And if you know anything about the text-to-speech, that's native code. Well, if you're going to use native code or JDIRECT in your applet, you need to sign that applet. So 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.

So I'm also going to demonstrate JAR caching in this example as well. And the reason that is, why you would do that, is that in this case, you see I've turned on the cache with the cache option in the first param. And I've got an archive here of the speech demo. That's what I'm going to build in my applet. And the last thing is the javaspeechframework.jar. And that's the speech framework jar that you can download off of connect.apple.com, and that comes out to about a 750K jar file. Now, you know, a lot of users, DSL isn't, you know, that widespread, and you still have a lot of 56K connections.

So that's a pretty good chunk of code to be downloading every time. So that's the kind of thing that it makes sense to cache on the user's machine for later use. So there's the HTML for my applet. I want to briefly show you Excuse me. 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 gonna 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-- 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 that. that. You can see we're going to jar everything up and the shell script goes ahead and signs the jar files. Now we're all ready to go. So I'll go ahead and hide project builder.

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 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. uh... for this particular example must be grant the session Nice and simple, we have 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. 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 gonna set the log level to two, and I'm gonna get some basic and networking-related messages. summary first the apple and i see that we're getting a trace of the what's going on as part of the applet shutdown and startup process to track when all your events are being fired to your applet.

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 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 gonna take the level up to three. Now I'll get some security information as well. So I'm gonna 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 Web Start since that's one of the interesting things that we've done here. Okay. 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 smart c_b_s_ on the download it and that 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. and It was in my trash and I didn't empty the trash. Okay. Let's quit this real quick.

All right, we'll try this one more time. Okay, we didn't find an application, so we're gonna launch it the usual way. Web start 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 Web Start is 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. I'm going to call it SmartCBS Beta. and i've got an application so now when i want to use it again third day i come back again click on the link and we've just now we're going to use the one that's on the desktop and again this is a real application so i can now do keep in doc 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 Web Start.

So to sum up, which should you choose, applets or WebStart? Well, it's only for you to decide. Thank you. 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 plugin. 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 Web Start information, you can start at our page on developer.apple.com. And I'll bring this page up again for Q&A at the Q&A session. how to get at the 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. Thank you.