Karl Hsu. So, good morning, afternoon, evening, depending on where you are in the world. Welcome to Session 614, Deploying Java Applications for Mac OS X. As introduced, I'm Karl Hsu. I'm one of the session engineers-- or, I'm sorry, I'm one of the Java runtime engineers, and I'll be your tour guide this afternoon.

So what are we going to talk about today? Well, we're going to talk about the various ways that you can deploy Java on Mac OS X. Mostly we'll be talking about client-side Java. We'll touch briefly on server-side, but that's actually in a different session. We'll talk about tools on how you can make that deployment easier, development tools. And you might think that's a little bit weird to be talking about that in a deployment session, but it's not.

We feel that your job as an application developer is to write applications. It's your job to make the code that people will run. It's our job to make it as easy as possible for you to get that code to your customers. That isn't anything that you should have to really worry about. You shouldn't have to work on it. We're going to try to make that a little bit easier. for you.

We'll talk about which one of those deployment options is the best one for your customers. It's the best way for you to get your application to them. And finally, we'll take a little bit of a look into the future and see what's coming in the year ahead with Java 1.5.0. I think it might have actually been renamed 5.0, but we'll have to see.

So this is the graphical overview where Apple, we have to have a nice UI on everything. One thing when you look at this, you have to realize is that the Java VM is underneath it all. And this actually is a little bit different from other platforms. On other platforms, the JDK isn't always there. You have to download it. Users have to find it, or you have to bundle it with your own application. Users end up with 15 copies of the runtime in their system.

Apple provides the Java VM and the JDK as a system framework. It means you don't have to worry about it. Every Mac OS X installation has a Java VM and a JDK. If the user has access to software update and has used it, they have the most recent version. This is a big relief on your part. Your applications can be small, and they can depend on the JDK being there.

So what kind of applications can you have? We start--and the most obvious one, the one that most users hit and most users use and see, are applets. Applets running in WebKit and applets running in Safari. Safari, of course, is using AppKit, but... Steve Jobs loves Safari, so it gets its own little box. Web Start, it's the next step. It's a little bit beyond applets. It's basically an application that's deployed as over the network. It gives you a lot of the benefits of being an applet, and it gives you a lot of the benefits of being an application.

The next step past that, of course, is to be a bundled application. I'm sure you've all seen them. There are tons of them out there. They look and they act pretty much like every other Mac OS X application. The end user doesn't know any difference. And yet, they're in Java. It's very nice.

All the way on the end, it's the poster child for things we don't want to think about, shell scripts and raw jars and class files. You can run shell scripts. All of these can be run from the finder. All of these can be run from the terminal. But you can't do anything with them, really. They require either a remarkable amount of technical savvy on the part of the customer, or they require that you need no configuration at all. So generally, we don't like that. We like things to look nice, to behave nice. for the end user.

So let's start by talking about applets. Applets on Mac OS X, our plugin is basically based on Sun's Java plugin. Like a lot of other things in Java, we try to maintain compatibility by, frankly, using as much of their code as we can get. 142 is available on any WebKit-based application. Safari uses it, but if you happen to use WebKit, then you can also use applets. and we'll see a really interesting demo of that later.

Our applets are cross-platform compatible. Anything that you can do in an applet on another platform, you should be able to do on ours. You shouldn't need to treat the Mac differently. Or if you're already on the Mac, you shouldn't have to treat Windows any differently. The bonus of that is that there's no download or installation. It's totally clean. From the user's point of view, all they need is a browser. They don't need anything else. They don't need to download anything. They don't need to install anything. It's all there for you.

This isn't to say that applets don't have any Mac OS X-specific technology, because they do. They do take advantage of Mac OS X technology when they can. They use the keychain to store certificates, HTTPS certificates, and when you sign a jar. They also take advantage of WebKit to do cookie management. So a lot of this stuff is in there, and it's done a little bit nicer.

We've just released 142 Update 1, Developer Preview 3, and if you haven't tried it, we would really appreciate it if you would try it and give us feedback. We've greatly improved stability and performance and correctness in a large variety of applets in the update. Proxy support is greatly improved, and by greatly improved, I mean it works now.

And for those of you who are really picky, and you have your applets well organized into your site and bordered by things, we now have support for a dynamic resizing of applets. That means when you set width equal to a percentage and you resize your page, the applet will now resize. Your page won't suddenly look like a total disaster as soon as the developer decides-- or the user tries to resize the Safari window.

And new from last year, Live Connect. Live Connect is the ability for Java and JavaScript to talk to each other. This opens up a lot of things. There were a lot of legacy sites that didn't work with Safari before that do now. But it is a legacy technology, and that means that there are a couple of limitations. We don't talk to anything except for Java. There's no talking between JavaScript and Flash, for instance. There's no creation of new Java objects in JavaScript.

On the other hand, it means that because it's built in WebKit, again, any WebKit application should be able to use Live Connect. Once again, I have to plug our update. It improves things dramatically in all areas. So to talk a little bit more about applet deployment and how you can use the dev tools to your best advantage, Scott Kovatch.

Let's start off in demo one, please. And over here, I'm running Tiger. And what we want to show you here is basically what applets are going to look like on Tiger. Now, you're going to say, well, that's not very exciting. You know, they're just applets. But what we want to show you is the improvements, actually, mostly that the Keychain folks have made, but they're actually enhancements that your end users are going to appreciate.

So here's my first example of an applet. It's a pretty boring applet, actually. But as you can see, you know, as Karl mentioned, we work across platform. All these, you know, the color of the text and the progress bar and all those things are all things that you set in the HTML. We pick those up. They just work.

So here I have a security dialog because I've signed this applet, or I'm sorry, I've signed the jar in this applet. And as you can see, it's a self-signed applet. I did this myself, you know, threw it together using a key tool. And, you know, the alert is telling us that the company is not trusted. Well, Apple wrote it.

It sounds like I'm making fun of our own company that you shouldn't trust us, but the truth is that I'm a real apple pretending that Apple issued it. It's important, that's why we have this here, is that so you can verify the contents of the certificate, so your end users can trust that what you're deploying is actually from who it says it's from. All right.

So let's close that, and I'm going to always trust this applet. As you can see, when I did that, my certificate just showed up here in the keychain. So I'm going to look at that certificate, and we see, yep, it's a self-signed certificate. It's valid. I can double-click on it.

Click on it and get a lot more useful information. You're going to see an expansion of us using more of the public key infrastructure that's available on Tiger in the future. But for right now, this gives you an idea of what we support and we're going to be taking this further. Let's also go back here. And what's nice about this is that now the user can not only take a look at it, but they can delete the certificate from the keychain as well if that's what they need to do. And I'll quit Safari and launch it again.

And now even though I said always, we have to try to trust it again. All right. And just for comparison's sake, I'm going to show you Install Anywhere. And they also sign their installer. They have a web-based installer. It was issued by Thotay, or Thot, rather. And I'm going to always trust that.

And you'll see the difference over here as well. It's expired, but that's all right. In 1.5, this will be less of an issue, because you'll be able to get around these problems. But the important thing here is showing you what the certificate's going to look like in the keychain.

There's not much information there. OK. I thought I was going to be able to show you a certificate chain, but no. All right, so that's basically what you're looking at for applets as far as TIGER goes. In Panther, it's not a whole lot different, but we're making it easier to manage certificates for the end user. Okay, let's go to slides, please.

All right, now you've seen how easy it is for a signed apple to run on Mac OS X. How many of you actually have had to write a signed apple at some point? If you want to do it in Xcode, would you agree that it's somewhat of a pain? I mean, you have to get a shell script set up, you have to do the shell script phase, you have to get everything all set up, and do mostly work outside of Xcode.

Wouldn't it be nice if I could have a basic HTML file just created for me, I could sign it as part of my build phase, and build and deployment process, and just do everything in Xcode once. Don't have to go back, jump out to terminal, set anything up for myself. other than what Xcode will do for me.

Today we want to introduce a new project template. We've been talking about Ant a lot this week, and what we're going to introduce here is a new signed applet template. It's based on the Ant application template. I started with that and built up this template. We're going to take advantage of Ant to do a lot of the automation for us. We're going to start with an applet. We've got boilerplate code in here, but we're going to start with the applet that you've written. We also have a Java key store that's got your certificate in it already.

And when we're all done, we're going to produce the final HTML, sign jar, and we're going to put it in a place where we can test it and try it out. And we've also got provisions for deploying that to a final location. Won't actually show that, but you'll be able to see how it's done in the build script.

I mentioned Ant. We talked about this a little bit. Ant 161 is now part of the core Java tools. If you install the developer preview 3 developer tools, you will get Ant 161. That version of Ant does work, and it will run JUnit and all external tools. It's been installed to developer Java Ant completely separate from the J2EE tools that we install as an optional tool. This is not meant to be a session to teach you how to learn to use Ant. Go to see ant.apache.org.

They'll give you all the information you need on external tools, tasks, how to link all this stuff together. What I am going to spend some time showing you is the important parts when you want to write your own Ant script that links into Xcode, the important parts that you need to make sure that you do have so that everything will work right.

All right, so in this particular script, I'm using Ant for some of its deployment features. Ant will do the jar, you know, the jar step for me. But it's got a nice feature called Sign Jar, and it basically wraps up the, The Jarsigner command line item pretty well with the sign jar task. And we're also going to use it for its deployment features.

I've written into the script an FTP task, and I'll be showing you how to use that and what extra things you need to get that to work. And as I said, as I mentioned here, it needs two third-party jars. We've got links on where you can get those. Very easy to do this yourself. All right, let's go to demo number two, machine number two. - Ooh, pretty. - Oh, wow.

Okay, here I've got Xcode, and just to show you that I'm not making this up, I'm gonna show you that we've got an Ant-based signed applet ready to go here in the Assistant, but I've already got one ready to go for you, 'cause I got the properties all set up so you can actually see this. So here we can see that I made a new project called Ant signed applet, and I filled in the archive so that I can, filled in the archive item for me. The code is the same as the project name.

And that's pretty boilerplate, but the interesting thing here is the build.xml file. Let's see here. Got a lot of setup. You can look through this. We'll have this available, a sample code available for you by the end of the week. Here's the jar step that puts everything together. Down here is the sign jar task. That's the interesting part for what I'm talking about right now. We're going to sign the jar file that we created in a previous step.

And the way I've written it is that it uses my username as the alias into the default key store that's created when you work with the key tool. So what you'll need to do before you do this is you'll need to make a key tool, make an... Just to get up and running out of the box, you'll need to do a one-time setup of setting up a key store for yourself. But then you can change this and do whatever, use whatever certificate you use to sign your jar files normally. and it's going to dump it out into sign.jar file, which puts it into the dist folder.

And one step here that's interesting, I have an install target. Actually, before I show you this, I want to back up here and show you some of these targets that we've set up. So we have a target name install, and a target name jar, and a compiled target.

When you're integrating Ant with Xcode, you need at least three targets in your build.xml file to get it all to work together. So you need a clean task, And we have that down here, which basically blows away my intermediate build and my distribution directories. I also need a compile phase Which is where I indicate, you know, what am I going to do to, what do I need to build with this task? And you also need for Java, you need a jar phase. And the jar phase is going to take care of, well really you can have it do what you want, but ultimately it should be doing a jar at some point along the way.

Oh, and the last one is the install phase. If you go out to the terminal and you do Xcode build install, it will run this install target. Oh, this install target, not this one over here, this one. And what I've done here is I've set up an FTP task.

To get that to run, you'll need to go to those locations that you see up there in the urls. You'll need two supporting jars to get the FTP to work. And instead of writing it down, just wanna let you know that you'll have to do this other piece of setup, 'cause we can't distribute these. And I'll just build it here.

Remember that? So there we go. We did a compile, and we did a jar phase, which had signed my jar and did everything for me all at once, and now I'm gonna do a run. and the run task is going to open up Safari because I used user bin open.

And there we go. I have my signed applet ready to go. There's my security dialog. And just to prove to you that the signing actually worked, I probably should have had to print out my username just for the heck of it, but there you go. So here we have a task for building, I'm sorry, an Ant-based template for building a signed applet. You'll be able to get this as sample code, and I believe that is gonna do it. I'll take it back to Karl.

That was a brief foray into the light, vegetarian world of applets. But now let's talk about something a little bit more meaty. Let's talk about Java Web Start. So Java Web Start is basically a web-based deployment technique for applications and applets. Applets run inside of a browser or any WebKit app, but they're running inside of another process. Sometimes it isn't what you want. They're inside of a sandbox. Even with the signing, there's some limits, and they don't really look like real applications to the user.

So what Java Web Start does is the user can go to a web page, click on a link, and that will essentially download and run an application onto their desktop. It picks up where applets left off. They're kind of halfway between applets and applications. The second time you run it, it will actually attempt to build a bundled application. So to the user, the second time they run it, now they have this nice little application on their desktop or wherever that looks just like a regular application.

The nice thing about this is that it still updates. It still knows that it's a Web Start application, so it will still go back out onto the web and check, have I been updated? Do I need to download any new files? This is perfect from an enterprise deployment scenario. You have users who can download these apps, and they look like real apps, so they feel comfortable with them.

They each run in a separate VM, so if something freaks out Safari, you don't lose everything. And they're still talking across the network. This means you can be sure that all of your users are running the same version of your application. You don't have to run around badgering your users to upgrade to make sure that they're not talking to the database with the version that corrupted it.

The next time they run the app, it'll come, it'll grab the next version of the jars. It's beautiful. What's even better about Java Web Start is that even though it's platform neutral, you can run this on any platform you want. It's not totally platform ignorant. You can customize. What actually gets downloaded and run based on what operating system and what VM, actually, that it will be eventually run on. And we'll talk a little bit more about that later.

Before we talk about all this stuff in depth, I just want to give you a quick update. It's actually pretty short. Once again, Java Web Start. We try to base it as much as possible on Sun's code, just so we have to do less work, because we're lazy engineers.

And 1.4.2 is available. It's both available on Panther and Tiger, same as applets. It's all good. And once again, I'm gonna have to kind of preach about the update one. We'd love you to try it. It should make everything better, really. There's a couple more updates. They're basically mirroring what Sun has done. So let's talk a little bit more in depth about Java Web Start.

Some things that you can do. You can use JNI libraries. That means that you can have your native code integration. You can do things that are only possible on certain platforms. And that means that you can customize your Java Web Start app for Mac OS X or Windows or whatever other platform you like.

The ability to create desktop shortcut applications, the bundled applications I talked about earlier, looks great to an end user. It makes them more comfortable with what's happening. They don't have to keep going to a web page. They only do it once, and the next time, it's all good.

We use your icons for the dock and the desktop. We'll actually look in the JNLP file, the file that you use to determine what actually happens, what's downloaded and how it's run, and we can present it. That way, we don't have the generic Java icon. From the user's point of view, it's starting to look more and more like an application. And you can download custom jars just for Mac OS X. And we'll take a quick look at how.

So the Web Start JNLP file, this is the file that you use to basically say what's going to run. When I click on this, what's going to come down, what's going to get downloaded, what's actually going to run on the customer's computer. So the JNLP file specifies a couple of things. It specifies resources. Resources can be jars for code or images or whatever you want, or they can wrap native libs. This is what I was talking about earlier.

The neat thing about these resources is that they're conditional. You can actually download them based on what architecture or what operating system that you're running on. You can also make them lazy. And this is really useful. If you have a huge application, for whatever reason, you've decided to build your application in this giant monolithic thing with a lot of different areas, and particular users only use little bits at a time, you can specify all of the ancillary jars to be lazy, and they won't get downloaded. They won't eat bandwidth unless the user actually tries to use that functionality.

You can have multiple Java versions. If you find that your application behaves differently on 1.3 versus 1.4 versus 1.5, you can actually, in the JNLP file, you can specify particular settings. You can say some resources are only downloaded on this version of the VM, and a different resource is downloaded on a different version of the VM. You can specify heap settings if you find under one version of the VM you need more or less memory than the other.

You can even have an installer. If you have to install native libraries, you can have something that the first time they run the Web Start app, you'll run off and another application will be run just that one time. And you can finally have their equivalent of shared libraries or whatever, which is the component extensions.

If you have a bunch of jars and a lot of setup that's shared between multiple applications, you can pull that out into a separate JNLP file that's referenced. And then you can do just less maintenance work. You don't have to keep changing JNLP files across 20 different applications.

So to do another Web Start deployment demo, back to Scott. Thank you again, Karl. Okay, let's say with demo two this time. And right here I'm going to show you Java Web Start. And, you know, if you've run Web Start on other platforms, this should look pretty familiar to you. Don't get used to it. We'll be talking about that in a little bit.

But the first thing I want to show you is actually a game that was deployed with Java Web Start. And if you've ever looked at this, it's called Puzzle Pirates. And what's interesting about it is that Puzzle Pirates is, I believe, over a 20 megabyte download. And we're going to get it started up here.

And I hope I don't scare anybody in the back because it's changing the resolution because Puzzle Pirates runs in full screen mode. And what we're showing off here is that full screen mode finally works, works beautifully in DP3. And just to show you what you can do with this, I have my own little pirate. Yes, I test with this application quite frequently.

And it's a massively multiplayer online game. So I can wander over here, and we can scroll into a different part of the village, and we can head over here and see what's going on. Full screen mode is very smooth. It's a lot of good work's going on in improving the graphics rendering in full screen and regular mode. So I'm not going to spend too much time here. You don't want to watch me playing a game, so I'll quit that.

And here we got, and I've already downloaded it once, but as you can see, it's already in the cache, it's ready to go. Actually, a little story about this is that the first time I ran this, it said, "Mac OS X is fully integrated with Oxygen." So I thought it was a... I was hoping that would just come up for you. I couldn't control which one. Yeah.

So what's interesting about this, and the reason I pulled it out, is that if you look at this, this is an application that looks right at home on Mac OS X. I mean, they might want to have a, you know, look at Matt's session on building great applications for the toolbar, but overall it's pretty good.

And because it was signed for full permissions, I can go on the desktop and I can just open a file here, and I've got a great XML editor. I've actually played with this. This is a very nice application. This is a, just a build.xml that I was playing with and doing some development of the template. Copy-paste works. I mean, this is a full application. This is a great way to get this down to an end user. And let's see.

That's all I need to show here. So the point of this demo, and the whole reason I show this to you, is that if you're writing a Java application, this is a great way to get it to an end user, whether you're in-house, this came across through the internet, publicly available, but you can easily make a full application that you can deploy to your end users in your organization if that's what you need to do. Okay. So now for the demos, let's go see some code.

How many here have tried to write a Java Web Start application? Or using Web Start? Would you agree it's a pain in the neck? In general. Okay. If you want to start with, usually what I ended up doing when I needed to test this, I have to go steal another JNOP file, copy and yank out all the parts that I don't need, fix all the bugs that occur from doing the copy and the paste, and, you know, I've got to deploy it somewhere because Web Start will try to download it from someplace. It doesn't really have a good notion of running locally. So in order to make life easier for you as a developer, we came up with an Xcode template that is built on Ant.

One thing, sorry. Can I have the slides for one second, please? Running theme this week seems to be, wouldn't it be great? So wouldn't it be great if I could get a basic JNLP file created for me? It's a drudgery task, you don't wanna be bothering with it every time you need to do some work.

Wouldn't it be great if I could deploy everything to my server to test it so I can do all my testing? And, you know, we're Apple, we want you to use Xcode. Wouldn't it be great if we can just do this all on Xcode? Well, we've created another new project template, which I was just getting ready to show you, but I got ahead of myself.

It's a Java Web Start application template. The product, much like the last template I gave you, is an HTML file, a JNLP in a jar, and we're going to deploy it to where you need it to be deployed for your testing or your final development. Sort of the boilerplate setup, we'll just put it in your home directory in your sites. That's probably going to be fine for your development. All right, now let's go back to demo two.

Okay, and once again, just to show you that we're not pretending here. Actually, I think you probably saw this before, but we have the Web Start application template. They're ready to go. I'm going to open up one I've already made for you. And we've made a HTML file that's gonna download the JNLP for you. We've got a basic JNLP where most of the information is filled in for you. You want to put a better title. It'll put your organization name using the macro fill-in that Xcode uses for templates. The HTML file that, where it came from.

All right.

So again, the build.xml actually is not a whole lot different than the signed applet template, so I'm not going to spend a whole lot of time on it. But here we have the clean and the install phase. A couple of gotchas I found while developing this is that you need to chmod everything that you actually deploy, because if you don't, it's going to set it up as read-only for the user that put it there, and nobody will be able to download it.

This depends flag is actually a very cool feature of the FTP task. It'll look at what's on the server and it'll say, oh, that's newer than what I've got already, or newer or the same, so I won't upload anything. Or, you built something newer, I need to put that up on the server. So it's a very useful way to... Make sure you've only got the latest stuff on your server for testing.

And I'm going to run it, because every template should be able to run and do something. Oh, what happened there? Seems to be a running theme today. Just gonna build it, sign it, and put it in the sites. And I've set up my run phase to open it up with Web Start. Okay, you know what? Let's do this.

So, today is not a good day for demos around here. What was supposed to happen is that the application would start up in Web Start. It would be signed, so it would ask for full permissions, and it was going to open up www.apple.com. This will be cleaned up, and you will be able to use it before too long. Thank you very much, and let's go back to Karl. Thanks.

So I hope you missed me. I'm back. And I say, hi, these are applications. So this is a really short slide, because really, applications haven't changed that much. You use the bundler, jar bundler, and you make a little application. This is sort of the traditional way to deploy your application. Developers are sort of used to it, and users are sort of used to it. So it's the thing to do. The only thing I'm going to do is take a brief foray into the Java dictionary of the InfoP list, because people have asked.

So the Java Dictionary is a dictionary that's embedded in the Info.plist of your bundled application. And what it is is basically a whole stack of information that we pass to the running Java app, to the started Java app. You have your main class. That's sort of self-explanatory, and obviously it's mandatory.

You have the Java VM version. You have to specify which version of the VM, but we prefer that you not be too specific about it. Scott talked about it very briefly when he said 1.4 plus. So what we'd like to do is we'd like to get people away from saying, "Oh, I'm going to run on Java version 1.4.2." Because 1.4.2 may not be there later. If we come out with, say, there's a monster security breach or a massive, you know, missing chunk of functionality or whatever, and we put out 1.4.3, 1.4.2 won't be there anymore, and your app will stop. working.

So we would much prefer that you use 1.4*, which means any 1.4 VM, any minor version, or 1.4+, which means I'd like to run on any VM that's at least 1.4. These are good things. Try to do that. This is the same thing that Java Web Start uses in the JNLP file to specify which VM version to use. Specific Java properties. These are the same properties that you access with system, get, and set properties, so on and so forth. Arguments.

These are arguments passed directly to main. You don't usually want to use these, but it can be useful if you're wrapping somebody else's command line app. If you have a Java program that you kind of--that expects to have all this stuff passed to it as arguments, you can pass them here. The class path, path of files, obviously this is probably going to include at least one file. That would be the one with your main class. And VM options.

So there is a bit of a difference if you notice that the VM options are all the options that you can have. Java Web Start doesn't have that option. You can specify multiple VMs, but you can really only change the heap settings. So the application's a little bit more flexible in that regard.

So I'm not going to go in-depth about building applications. It won't force Scott to come back up here. And the reason is because there's an entire session on this, or there was an entire session on this, Xcode for Java Development this morning. You should be able to see it later at some point, either on ADC TV or whatever we use. If you have access to last year's DVDs, there's also Session 608 from back then.

So now we're on to the sort of the part that we don't talk about, the Java deployment that will not be named. And that's shell scripts and J2EE. Shell scripts, only if you really have to. I mean, if you're really, really sure of who your deployment audience is, go ahead, use shell scripts, it'll be okay.

But in a general sense, we would prefer that you not use shell scripts to launch your apps. There are a couple reasons. Obviously, they don't look familiar to users. There aren't something that, you know, most users, you can't tell them, oh, to run my Java app, go to terminal and do this or that or this. Or when you double-click my Java app, this giant terminal window is going to open and do all this stuff. They're not going to be happy with that. But there's actually another reason. And the reason is because there's no launch architecture surrounding it.

You notice in Java Web Start, and in the bundled application case, you can give us hints as to what version of the VM you'd like to use. When you run in terminal, when you run with a shell script, there's no way to do that unless you do it manually.

You either say Java, blah, blah, blah, and we pick whatever we think is the most current version, or you have to mark a full path. You have to system, library, frameworks, Java VM framework, versions, blah, blah, blah, and you pick, like, 1.3.1, you know, slash bin, slash Java. And if that ever goes away, your application just completely stops working. Even minor changes to that path. If we move the framework or rename something, your application stops working. So try to avoid that if you can.

So JBoss and Tomcat, J2EE deployment isn't actually, you know, it's not bad. It's just not what we're talking about today. And there's a whole session on it, so I wouldn't want to steal somebody else's thunder. Friday, 9 a.m., how to deploy JBoss on Mac OS. 10 server. This is only available on server, so unfortunately you can't count on it being in the client version.

So, before we talk about which of these deployment options you might want to use, let's talk about a couple of deployment gotchas, things that aren't always readily apparent, particularly if you're coming from another platform. So where is Java Home? Java Home is library Java Home. And the lib directory, your source jar, all the stuff that you expect to be in Java Home, the in directory, it's all there. And it's symlinked to the appropriate location. So the obvious question is, well, where do extensions go? Extensions go into library Java extensions, or the user's home directory library Java extensions.

There's a little bit of a catch here, which is that while Java Home is symlinked to the appropriate version-- so when you run Java 1.4.2, you get the Java 1.4.2 Home-- all of the library Java extensions are used by all the different versions of the VM. So if you drop ant.jar into library Java extensions, ant.jar is going to be available no matter what version of the VM you're running under. So that's a little bit something to keep in track of. It's confused some people before.

One thing to keep in mind-- and I've talked about how Web Start and Apple bundled applications can try to pick which version of the VM. Applets don't have that luxury. Applets launch in whatever version of the VM their container has decided to use. So Microsoft IE Internet Explorer uses 1.3.1. Applets launch there, use 1.3.1.

They don't have a choice. WebKit uses 1.4.2. Applets launched in there use 1.4.2. They don't have a choice. So applets are limited not necessarily by the technology, but with the knowledge that your deployment may have to be the lowest common denominator. of what you think your users will be using.

So I'm going to harp again. Sorry about this, but I've been asked to harp on it, so I will. Don't use 1.4.1 and 1.4.2 as your JVM version when you write Web Start apps, when you write bundled apps. It is Apple's policy that minor version updates will outright overwrite older, minor updates. 1.4.3, if and when it comes out,

Thanks. All right.

So at this point, we've gone over all these options-- applets, signed applets, Java Web Start bundled applications. And you've got to be wondering, well, why? Which one of these should I be using? So applets. Applets are the lightest weight. They have nice things. They have built-in SSL support. They don't require downloads or installs.

But they're kind of limited. You can't choose the VM version, and they're floating in somebody else's process. And they're in a complete sandbox. If all you need is to walk outside the sandbox, pick a signed applet. In a signed applet, you can get local disk. You can get some restricted property access.

The next step up, if you need native code, but you still want that ability to talk over the network, the ability to get frequent updates, or you need control over the VM, which VM you're using, which resources get downloaded, think about Java Web Start. You still get the ability to be dynamic in terms of what's running. But you get a little bit more control over what's actually going to happen.

Finally, you have bundled applications. This is if your app's really huge. If you want to distribute it on a CD some way, or you don't have the network bandwidth. You know, you want to distribute it, and you want to be done with it. Then you use the bundled application. Or if you're bundling an existing tool that needs arguments, Java VM options that are very specific, all of those things have to be bundled apps.

Let's look into the future. We've talked about what's happened, and let's talk about what's going to happen. So we have the 1.5.0 developer preview 1. And we just released it. It runs on Tiger. So sadly, since I've just been talking about it, there's no Web Start or applet support in the developer preview. It's an enterprise preview. It will be coming, and in the end result, you have all the Web Start applet deployment goodness that you've come to love and expect from Apple.

So let's talk a little bit about what will be coming, what's new. Well, the applet plugin and Web Start have been combined. I think they just decided they're so similar, why have them be separate? There's a number of enterprise enhancements. You can set a security model across an organization. You can have deployment properties specified in a URL, and you can mark properties as either overrideable or not overrideable by specific deployments. HTTPS client authentication rears its wonderful head.

And then a set of things which are really interesting to me personally. There's PAC 200 compression for jars. It's a new jar compression, and it has the capability of compressing your jars up to eight times smaller than they are compressed now. This is great. From a user's point of view, it means when they hit your web page and they download an applet, or when they click on the Web Start link and they start downloading your app, it launches just like that. It's much nicer, and it starts bringing things like Web Start into the realm of being real desktop apps. desktop app replacements.

The next thing, the fact that Web Start desktop apps can now have document types. You can actually bind. You can say, I claim this particular document, dot J-L-N-S-T-W, whatever, you know, your own personal little initials. But now you can associate. When the user double clicks on that document, your bundled app is going to launch. And that's awesome.

And finally, an import facility, one more step in the ability to make Web Start apps more and more like real desktop apps. With an import facility, you can pre-populate the cache. It's basically like an installer that sets a Web Start up app as if the user had already downloaded all the jars and built the app. So you get all the niceness without that initial niggling startup, you know, the first couple times that the user has to click on things. They can treat it like it was always a desktop application that just knows how to update itself.

All right, part de. So let's go in a little bit more depth about what's changed. So in particular, the applet plugin and the Web Start have merged. That means that they share a cache. This is good. It means that you're more likely to have whatever it is you're trying to run in cache. It simplifies things considerably. This means there's no more Web Start application. There's a couple of new applications that take it place. There's a plugin settings and a cache viewer. The rest of that functionality, I think they rightly decided, was to be pushed off into the browser.

So what's already there? These are new to Java 1.5, but frankly, they're not new to the Mac. As always, we've been on the leading edge, so we've had these for a while. Java 1.5 has integration with Keychain, but even on 1.4.2, Scott demoed it for you. And we have auto detection of all installed VMs. This is a lot more important on platforms that don't provide the VM as a supported system framework, which we do.

So we've talked about Java 1.5 in the future. And actually, we were going to end the session at this point, but they announced Tiger earlier this week. And I was thinking about Dashboard. And I thought, wow. That's pretty cool. I can write little widgets. But then I thought, you know what? I really hate JavaScript.

I don't like writing things in JavaScript. Yeah. But if it's a real -- and then I went to the dashboard gadget session and they said, you know what? This is a real WebView. It's not just a JavaScript engine, you know, putting up custom graphics. And then I thought, hey, that could be really interesting. So if I could switch to demo One, please.

And I thought to myself, hey, that's kind of funky. Look what I can do. I can run Java applets inside of Dashboard. So this is a completely different way For you to deploy your Java applications, you can write little desktop widgets for people to use at the touch of a fingertip. And we'll leave you with that. That's Deploying Java Applications on Mac OS X. Thank you, and have a good evening.

So we're going to do Q&A, but first I get to do this whole thing. Look, it's the reference library. We have a ton of documentation. Some of it's ours. Some of it is Sun's. It's all very exciting. It's gripping text. You should read it. It will enrich your life.

Now if you have any complaints, you can complain to him. So if you have people to talk to, if you have questions, comments, feature requests, bugs, anything, talk to Alan Samuel. He's our Java evangelist. His email is up there. Bob Fraser is our marketing person. If you feel that we're not, I don't know, we're not marketing Java, talk to Bob. Not actually sure.

And the Java Developer Mainland List. Java Developer Mainland List is great. It's a place where people of all kinds of occupations and creeds can come together and, well, really flame each other about Java. No, it's good. It talks about things and people hash out problems and they, you know, where a lot of the web, I'm sorry, a lot of the Java engineers are on the Java dev list.

So actually if you have issues, you have questions, how do I do this thing on the Mac? How do I make this app look better? You know, why does this behave differently on the Mac than other platforms? Join Java dev and ask and somebody from the Java team will try to answer your questions. But of course, if you really think it's a problem, you should file a bug. Always file bugs. Bugs are our friends. Because they keep us in business. I mean, that's my job. I fix bugs.