My name is Ted Jucevic, and we're gonna be talking about Java today. So I'm one of your DTS engineers, so if you send a DTS incident in, I'll be one of the ones who would hopefully be helping you. And let's get this thing started. So why are you here? Well, of course, Java 2 standard edition 5.0 is new to the platform and there's some new configuration options on it. We're gonna talk about deployment strategies, about some things we recommend and don't recommend. We're gonna give some good debugging tricks and tips.

These are things that we found that, we thought was commonplace, but these are things that people really need to learn. And of course, an intro to Java development. So if you notice, we've actually turned this presentation a little bit on its top, where we're gonna start out with deployment, talk about debugging tricks, and then go into Java development. Mainly it's because you gotta know where you're going before you get there.

So, of course, Java on Mac OS X.4, New with 10.4, we actually include Java AI and Java 3D, so you don't have to worry about making sure that's installed. If your users are using Tiger, they have it. Of course, we got Java 1.4.2 and Java 1.3.1 by default on every user's install. And then available as a download is the Java 5 Standard Edition. The reason we have it as a download is at this point, Not everybody needs it, and so we don't want everybody to have to download it over software update over modem. But for those people who need it, it's available to you and your customers. Thanks, Lawrence. So of course we're gonna talk about Xcode in Java. It has all the features that you guys have been asking for up to this point that we're aware of. Code completion, native interfaces, source control management.

It has the works and it'll take care of you from start to finish when developing Java applications, including JNI libraries. We're not gonna lock you in, we're cross platform, it's Java. So there's tons of tools out there. NetBeans is a great one. Eclipse product, Borland's JBuilder, IntelliJ. It's all your favorite toys and tools are available for the platform.

Of course, Eclipse 3.1, we found that a lot of our developers are using it, so we actually have a complete session on it. Go ahead and check it out. It's Friday at 5 p.m., so if you're one of the diehards, stick around, and it's going to be a great session.

So we, of course, we also got J2EE strategy. It's bundled with every Mac OS X server. So if you buy, like, a 10 server product, you have JBoss, Patches, Tomcat, and Access. And, of course, there's also Xcode templates for doing deployment to that. Nice thing about it is these are just standard open source installs of JBoss and Tomcat. So if for some reason you don't like the configuration, It's very easy for you to update. And then also on your client machines, if you want to do some testing and developing with them, it's very easy just to install Tomcat and JBoss. And you can get everything going even on a client machine.

So what are we going to cover? Well, we're going to talk about deploying your application, of course, like I just said. We're going to start out from the simple jars and stuff to the custom deployment. Java Web Start has some really cool features we'll talk about. We're going to talk about the debugging. We've run into some situations where people kind of just get stuck when they get a hang and stuff. And so this is something that's going to really tell you how to get the most information out of it, figure out what it is, and if it turns out, which rarely occurs, it's our issue, how to write a bug that will make sense to us and will give us all the tools we need to actually fix it quickly and then get it in the next release, hopefully. And then, of course, we're going to talk about developing with Xcode. Like I said before, with Java 2 Standard Edition 5.0, there's a few additional things that you have to do if you want to target that JVM. So with that, let me bring up Scott Kovatch, and he's going to introduce you to our deployment strategies. Thank you.

Thank you, Ted. Thank you. Okay, so here's what I'm gonna talk about in this portion of the talk. We're gonna talk about what's available to you for deployment on Mac OS X. We're going to talk about what we've added in tiger. We're gonna talk about how Java 5 will affect your deployment options. There are things you wanna be aware of if the end user decides to put Java 5 on their machine right now. And we'll talk about what you need to be aware of for your work. And finally, transitions is a theme at this year's WWDC. And there's a few things you wanna be aware of if you pick up one of the developer machines that we offered this year. We'll talk about what you wanna know there and what were some of the deployment issues that are gonna be important to you down the road.

So here are the choices that you've got available to you right now on Mac OS X. The easiest thing you can do is build a JAR file, either on the Mac or on Windows, and put a main class entry in the JAR's manifest. If you do that, when you double-click on the JAR, it'll look like an application. We'll launch it as if you did Java-JAR.

Now, that's fine. That's pretty basic. That's the least amount of work you're gonna have to do. Much in the same way in Applet, there's not a whole lot of work involved with that as well. If you've done it on Windows, you probably just have to just bring it over to the Mac and launch Safari and get your Applet going, and you should be ready to go.

If you want to take a little bit more time and make your application integrate a little bit better with the Mac OS X desktop, you can build a bundled application. We'll talk a little bit about that later in the talk about building those, but basically a bundled application has everything a Java app needs in one application bundle, your JAR files, your resources, and you can just double-click on that, and it'll be an application like anything else on the X desktop. And finally, Java Web Start Webstart is a great way to deploy across different platforms that have different needs on different platforms. So say you have some native libraries that you need to build for each platform, Webstart is a great way to deploy using that because you can set it up for each platform. We'll briefly mention that.

And finally, we're not going to talk about in this session, we're going to talk about this afternoon on JNI development, but you can also build a custom launcher, and that's for those of you who are writing C code that will invoke the JVM yourself using JNI. We'll talk about that later today.

So when you install Tiger, there are a few things that you, you know, what VM are you going to be using when it comes time to do your deployment? Well, just about by default, you're going to use Java 1.4.2. And the first three examples I show here, If you do Java from the command line, the default VM is 142, so Java dash version, that's what you're gonna get.

And if you double-click on a jar, again, that's roughly the equivalent of doing java-jar from the command line, so, again, that's 142. WebKit, which is, of course, what is used inside Safari, always uses 142 by default. And for a WebStart application, you get to pick. Part of the JNLP specification lets you pick the VM. You could pick 142 or 131 if you need it, but... We're gonna use the one you pick. And the last case is the most interesting one for bundled applications. Again, we'll pick the specified VM. You will put it in your applications info.plist. This is well documented. We're gonna show some examples of how you can use this and some of the implications of that, of the choice you make here and a demonstration pretty soon.

So let's talk about Java 5.0. Well, when the user installs that, what happens? Okay, generally you don't like to read out of these things, but there's actually a pretty important line in the release notes that bears repeating here. Java 1.4.2 remains the current JDK after Java 5 is installed. So what does that mean? Well, what that means is when you type java-version, it's still gonna say 1.4.2. That does not mean that you cannot use 1.5.0 for your applications or for your deployment. If you want 150, you gotta ask for it. You can ask for it in Web Start. You can ask for it in a bundled application. You just say 150 for the JVM version. Now, Customer can make Java 5.0 their preferred JVM. What does a preferred JVM mean? Well, I'm gonna show you in the next demonstration exactly what it means from a practical point of view, but basically what it says is that if you choose a JVM version that basically says I can work with a JVM version or later using the plus notation, you cannot automatically assume that Java 5 will be used. We'll show what that means here in just a moment. So how does this information then change the chart I just showed you?

Well, again, for the command line, nothing changed at all. For JAR-based applications and applets, we'll pick the preferred JVM. We'll pick what the user has chosen for the VM that they want to use to run applets and what they consider their preferred VM for application deployment. Now, for Web Start and applications, again, nothing's changed. We'll pick the VM that you specify, and that's pretty important.

If you want 150, you've done the testing, and you decide that's what you need, ask for it, we'll use it. So sort of to explain what's going on here and sort of give you a visual example of what I've just talked about, let's go over here to the demo machine. And what I'm gonna do is show you a little bit of Java preferences application. and show you what that's going to mean when it comes time to run an application. So for this part of the demonstration, I'm gonna focus down here on the Java application runtime settings. As you can see, 142 is the listed first, because again, it's the default.

So let's go over here with a small application I've written. You don't have this in the sample code for this session because quite frankly, it's not all that interesting. It's a basic Java application. and all it's gonna do is draw the value of java.version on the screen. And the other interesting thing for this particular application is that over here in... or pure Java, I have 1.4 plus. Now recall that 1.4 plus means that I'll use the latest VM starting with at least 1.4. Well, when you install 1.5, the meaning is follow the user's preferences as well. So let's run out this application. Let me see that I've used one four plus, and it says one four two oh seven. So now we'll quit that and we'll change the order and put J2SC5O at the front, run the same application. Oh, you're right, I forgot to say the settings.

Run it again. There we go. Java 5 is now being used as the VM. So if you want to get around this problem, because now you're saying, "Well, hey, I don't know what the user's done." Well, I can fix that by saying 1.4 star this and rebuild very quickly. And now we're using 14207. So, as I mentioned, you are in control of what VM you wanna use.

Okay, let's go back to the slides. All right, let's talk about very quickly what I just showed you. The important real estate you wanna understand in Java preferences is that Java application runtime settings. That's where the end user is gonna be able to pick right now what their preferred VM is for running Java applications. Wanna recognize the trade-offs that are involved when you pick a JVM version for your application. Plus is forward-looking. Plus means that I am absolutely certain that every version of Java that Apple releases is gonna work with my application. Maybe that's the right thing. Maybe that is the case.

But if so, you have to be prepared for the fact that the user may not always take the latest VM right now. Star is making a guarantee. Star is saying that I know that my application works with any version that's associated with that star. So whatever version of 1.4 that Apple releases, 1.4.2, if there's a 1.4.3 or 1.5.0, 1.5.1, so on, I know that I work with that major release of Java.

We want to discourage you from using a specific version. Get out of the habit of using 142 for your VM version. Now, you may want to do that if your organization, you know, you don't have the testing resources to test every version that we release, and maybe you want to just put, you know, you want to limit what your end users can use, and that's fine too. But be aware that if we release a newer version and we delete that version, your application's out of luck. So you might, so look in one of these wildcard versions and see what makes sense for you.

Now we're going to switch and talk about applets and WebStart. So in Tiger, we have two versions available for applet deployment. 14207, and I'm calling out the 07 because that's actually important for some people. We try to keep up with the latest versions from Sun, but sometimes it doesn't always mesh with our release schedule as well. So 14207 is what made it into Tiger. If we install 150, it's specifically 150.02. I believe 03 came out about three days before we shipped, so that's why we didn't make it. We've improved the integration with the keychain. The keychain is now the place to go for your certificate storage when deploying a signed applet and a signed WebStart application. We'll show you that in a few minutes.

Again, we focus on it, it's still true. Always use the applet tag for the best compatibility. We know on Internet Explorer for Windows, it's possible to pick the VM that you wanna use via an object tag. We don't support that in Safari and WebKit. So use the applet tag and you're gonna work best across platform. So, One of the problems with, well, not a problem, but one of the things that can happen when you install 150 is, remember, the user gets to pick which VM they want to use to launch some applets. So this proposes a problem. You know, what do I do if I want to take advantage of some 15 features in applets?

Well, how am I going to safely deploy an applet when I don't know what the user's picked? Well, let's talk about how we can do that. We've got a demonstration to show you how to work around this. So what I've done is I've created... I've created an applet that the code of which is not, you know, it's not all that useful an applet, but it's gonna demonstrate a point.

And in this particular applet, what I've done is I've written something that uses mouse events to see what the user is doing with the mouse. So we've got a mouse motion listener and a mouse listener and we're going to watch for clicks and things like that. So let's run that. Keeping in mind that the VM for applets is currently 142.

So we build and run and Safari loads. And what I've done for this demonstration and for what you have in your sample code is I've used the ant-based signed applet template. And what I've done is we've automatically built a signed applet and I wanna show you some of the, very briefly, some of the new features for certificate management. I can show the certificate and we've got a much better looking certificate dialogue than we've had in the past. So that's one nice feature of it. Get a lot more information about the certificate than we could provide in the past. And we've got this checkbox here, always trust.

And when I check that, the certificate gets added to the current user's key chain and it's always there. And you can now go to key chain access and manage whether you wanna trust that certificate, delete it, whatever, using a standard Apple tool instead of this separate Java world thing that Sun has provided.

That's it for that. So I'm going to trust it and get our applet going here. And here you go. We see the mouse, you know, running around the screen, and I'm tracking it. It's left. We don't track anymore. We go inside. We track. That's neat and all well and good. So... I am an ambitious person and I decide that, hey, there's some cool one five features that I like to use for my applet. Well, let's take a look at that.

One of the other things in this demonstration and the sample code you get is that I've added the changes you need to get Ant to use Java 1.5. It's actually not hard. It's about four more lines of code, or four more lines you need to add to your build.xml. But once you do, you can have an Ant-based build that uses 1.5. So you wanna take a look at that in your samples.

So the difference here is that I am using these new pointer info and mouse info classes that are available only in 1.5. And what happens here is I ask a component where is the mouse located. If it's null, well, it's not in the component, so then I can go to the get pointer info class and find out where the mouse is. It's sort of a, you know, ask globally where the mouse is at any given time. Let's run this.

Now it's against the signed applet. Oh, now we got a problem. I build it with one five and we're running with one four. So that's what that error is telling me up there in the console. Well, that's bad. So how are we gonna deal with that? Well, just to show you that it does work, we'll quickly switch.

And we see that 1.5 did load, and now the mouse is running around. I even know, oh, it went in the menu bar. That's neat. It goes anywhere on the screen. I can track it. Yeah, all well and good. Well, now what? Well, one thing we've added in Tiger is that We've always put in the plugin description what it is. So you could tell that there was Java available. But what we've added in Tiger, we've now also added the plugin version into the description field of the plugin. So what we can do now is with some tricky HTML, is that we can look at the field plugin.description right here. And basically what I do is I look for a version that I pass through as an argument to that method, that JavaScript code that I've written above. So here I look, see if Java version available is 1.5.0, we're gonna load the 1.5 version of the applet. If I see 1.4.2, we're gonna load that version of the applet.

And if I don't find either one, 'cause it is possible to really whack your system and make Java unavailable, I'll put up something intelligent that says, you don't have Java, we're sort of out of luck. So here I have 5.0. So I'll run this version of my applet and see, yes, there it works in 1.5. And the same applet.

also loads and runs in 1.4. So I got one applet, one deployment, and I've switched VMs, everything's good. So take this example back with you, and now you can be able to cope with whatever the user's chosen. And it's not a perfect example. I don't check for Safari. I don't check for WebKit, anything like that. But it gets the point across that now there's a way that you can detect what version of Java is in the browser without actually launching Java, which is a good thing. All right. And with that, we'll head back to the slides.

Let's talk a little bit about Java Web Start. The slide's pretty short, 'cause there's not a whole lot new going on with Web Start and Tiger. It is 14207 as installed with the same version of Java. Java 5 installs something called Java Cache Viewer. This goes into Applications Utilities Java J2SE 5.0.

And what that basically is is Web Start 1.5. It conforms to a new version of the JNLP specification, which you can get from Sun. Lot of new things in that that we've been adding things to One5 and we're trying to keep up with Sun as best we can. There's some new features in that I wanna talk to you about. What Sun did is they refactored a good portion of the plugin in Webstart. So now, you saw that signed applet certificate dialog, you'll get one of those in Webstart as well if you deploy a signed application in Webstart. This is actually a big thing for a while. So we're very happy to have it now. A lot of enterprise enhancements. There are ways you can set up one configuration for your entire organization via Web Start. HTTPS client authentication is a new way to guarantee, make sure you know who's running your application.

One of the big ones is PAC 200 compression. And if you haven't heard about this or looked into it, I strongly suggest you do so. You can get an 8 to 1 compression ratio on your JAR files. If you have a megabyte of JAR code, 125K downloads. Now, and that scales up. I mean, you know, we've tested some applets in the area of, with 20 megabytes of JAR files. And if they ran it through PAC 200 and set up their server correctly, you can have a really big win for downloading data, or for downloading the code for your applets, or your WebStart app, for that matter.

Finally, there's an import facility, which is interesting. You could pre-import a WebStart application into the user's cache. And again, that sort of gets around the whole 20 megabyte download problem. So these are good things in WebStart. All these work on Mac OS X. Everything you see on this slide works on OS X. You know, we just brought it over from Sun. A few things we had to do ourselves to work-- to fit in on the Mac, but it's all just working.

Very briefly, I said we're not going to talk about custom launchers, but we're talking about deployment in Java 5 here, so I want to mention it very briefly. If your app is using JNI to load a VM yourself, you can pick 1.5. All you have to do is add the Java JVM version 1.5, and that will tell JNI and VM use 1.5.

This last point sounds a little mean, but we think we've got a lot of good deployment technologies on OS X. So, you know, ask yourself if you really need to use a custom launcher. We realize there are a lot of you that, yeah, that you do have a really good reason to use a custom launcher. But if you don't have to, look at bundling an application or Webstart. That's really the best way to go.

Okay, transitions. The good news for you is that if you wrote a pure Java application, you're done. I mean, Steve Jobs was right. You are done. Not that I would argue with Steve Jobs on something like that, but. But there are things you want to know. It does just work with the few caveats that we mentioned in the Java overview session on Tuesday.

The stub that is built into a bundled application is currently not universal. And what you built in the past is not universal, I should say. So if you were to bring that over to an Intel machine, double click on it, you're gonna get a slight performance hit during launch because we're gonna find a universal stub and use that instead.

So for the best performance for your application, you want to rebundle or rebuild your application. It takes no time to do. You just do a clean build, next code, if that's what you're using. Or if you're using Jarbundler, just rebundle your application. Take, what, two minutes to do any of these things.

Another important fact is that if an application, a Java application, or your C-based application is loaded in Rosetta, you cannot use the Java VM. You cannot load the VM. JNI will fail to load the VM. If you are trying to load the plug-in, that will also fail silently as well.

So, the answer there is, build a universal application, you'll get to use Java. And finally, there is no 131 on an Intel-based machine. So we will say it again. If you are using 131, please stop now or get to 14 as soon as you can. Let us know if that's a problem. We'll do what we can to fix your bugs, to get people off 131 as quickly as possible. So we'll say it again. Move to 142 or later now.

There are a few temporary problems. If you buy one of these transition machines, there are a few things you're going to have to be aware of that may be important to you. We can't support C2 right now in a bundled application. Small problem. We are confident we'll be taking care of it. And an old style of building a bundled application used a.properties file, as opposed to info.plists, which is what we use now. Those currently don't work, but we do realize that's important for backwards compatibility. We will be looking at that and hopefully taking care of it by the time we, in a future release. And with that, I'll take it over to Mike McDougall who's going to talk about debugging. Thank you.

Thanks, Scott. So debugging. We're developers or IS&T people. I mean, there's a lot of different people, but we all, We all eventually see stuff like this. This is my scary slide. I need this to get your attention. And you don't want your users to see this. We're developers, so we have to bear the burden of all of these things, crashes and hangs and stuff like that. There's some things that you should know.

sort of what to do when you encounter one of these things. There's some real basic tricks and tips and things that you should have in your pocket when you encounter this. We're gonna cover the two most high level problems. We're gonna talk about hangs and crashes. We're gonna go to two tools for dealing, most specifically with hangs. We're gonna really get hands on, so get your portables out if they're not out. We're gonna talk about crashes, then we're going to go into some more tools. So hangs and crashes. Why is my cursor spinning?

So sort of technically speaking, the reason that your cursor is spinning is the operating system is trying to give you a clue that it is no longer able to process events. There's... the Cocoa has a thread that it expects all of its events to sort of percolate through. And if for some reason events stop hitting that thread, the operating system notices, and it gives you this big spinning cursor of death saying, "Hey, something's going wrong."

But at a sort of higher level, one of two things has probably happened if you're working in Java. Either you've got a deadlock, or you've gummed up the event queue. Again, sort of a more straightforward situation, you crash. There's not much you can do in terms of tools, except maybe make it happen again, but we'll talk briefly about that. And then, in general, we'll talk about where to look for clues.

So, going to hangs first of all. When you're hung, really what you need to do is you need to start looking at threads. In Java, you know, threads are pretty cheap. You sort of spit them out like candy. We're going to go over kill-quit. Kill-quit is a... So, kill. Kill is a Unix inter-process communication command. Signal handling. And in Java, we've put a signal handle in there. It's waiting for this quit. It's like number three of the signals. And that's sort of a clue that the VM interprets to say, hey, sort of stick out your tongue and say, ah, tell me what's going on. So actually, just so I know sort of who I'm talking to, how many of you folks have had your application hang and have typed kill dash quit?

Oh, good. OK, so I can actually go a little more quickly over this. For those of you who haven't, this is really, really good stuff to know. And you don't have to be a developer to know this. I mean, you can be in Safari, and your partner is playing Yahoo games, and they hang. You can sort of look like the Kung Fu debugger by going over there and pulling up the terminal and sort of finding out what's going on. And I actually want you to do that because I need that information.

On the native side, so there's two halves of every Java thread. There's the Java half, which as Java developers you'll be real familiar with. Maybe a little less you'll be familiar with is every one of those threads has a native side where all the sort of JNI and Cocoa and underlying stuff goes. So I'm going to talk to you about sample. It's got a lot of friends that, you know, GDB or Activity Monitor. But I'm going to talk about sample. Okay.

So again, same thread, this is looking for clues. How many of you folks have run the console app? Console app, okay, I'm not gonna have to go into this in great detail then. But these are places where you're gonna be looking for standard out. We're gonna, in particular, look at the run log because I'm gonna get you guys all to run Xcode soon.

So we'll bring up the spinning cursor of death so that those of you who have your portables, we're going to go hands-on very soon, but you should get your portables out. There's a sample code. If you don't have the sample code, still get your portables out. Fire up Xcode. Xcode is in developer applications. Xcode. So fire it up. If you have the sample code, get the sample code out. Launch the disk image. Go to blocked event queue..dmg, launch that. And then make a copy of that onto your desktop, so you want to be able to modify that. So I'm going to sort of stare at the spinning cursor of death with the rest of the audience until somebody tells me that they have sort of Xcode up and running, and it's ready to go along with me here. We got one, two, okay, so Xcode's up. So for those of you who are doing the sample code, get the sample code going. For the rest of you, go to the file menu and say new project.

new project, and then go down into the Java section and build yourself a swing application. I've timed this on my portable, which is really slow, and it's only about 45 seconds to get yourself a swing application up and running. So people following along with the sample code, anyone who's got the sample code up? Great, okay, so I'm gonna go to demo one, where I've got my sample code. Now, let's see.

Now, some of you folks, this is in... I wrote this in Xcode 2.0, and a lot of you folks have got 2.1. So you're gonna actually need to press... After you copy it onto your desktop so you can modify it, you're gonna have to say, "Yes, convert to the new Xcode format."

and then you'll be able to build and go like me. So this is a fatally flawed application that's also not very complicated. It's got two bits, it's got a panel, and it's got a great big button. And that button has got an action listener associated with it that is going to wait for the next paint event. Now the panel, as I said, the panel down here is just saying, every time you paint, bump a counter, and then tell me that you have painted. There's nothing here to actually cause it to paint, so I have to go down here and resize to make it paint a bunch of times. I had a big flashy thing with animations and stuff like that, but it made everything more complicated. So, and let's just get this to hang. Amen.

Wait, what's going on here? I've got the one that's fixed. You all should be hung. Okay. Anybody out there hung? Great. Okay. So anybody out there got a swing application and running? So these things that I'm going to show you, you don't have to be hung. It sort of helps. Let's go to the terminal where sort of God intended programmers to work. Terminal is in the utilities folder.

Come on, utilities. Oh, now I'm hung. Please demo gods, have mercy. What's going on here? I'm going to a fire where I drive. Okay, I'm gonna talk through this because you don't, you don't, I don't have to see it to explain it to you. So the terminal should come up.

It just, so the thing woke up. Thank you, folks. God. No, it hasn't. - Yeah. So the first thing you want to do to use these two techniques-- we're going to talk about kill-quit and sample-- you're going to do them in Unix. And so what you want to do is run top, T-O-P, And you want to find the process ID of the thing that's hung. Now, if you're running a-- a swing application, that's gonna be whatever name you gave it, like Simon Says, or Test, or Swing Applet. For us, it's gonna be Java. So use Command + C, put that in a buffer. and quit. Now, type kill dash quit.

and the process ID. I want you all to do this because, I mean, it's sort of like, Your fingers should know how to do this. It's one thing to hear a person on stage say kill dash quit, but I really want your fingers to have done this. So who's got kill dash, they've quit there. So folks are following along, good. So once you do that, Java sort of sticks out its tongue, says, "Ah, what's going on?"

And you get every single thread that's running, whether you're hung or not. So you can do this running application to sort of find out what's going on. Now, if you are hung, there's going to be two threads that you most care about. So stop looking at your screens for a second and kind of look up at me, because this is actually important to understand. The two threads are the event queue and the app kit thread. The event queue is what Java sort of cranks along all of its stuff on. Paints go there, events go there, action listeners go there.

The AppKit thread is where Cocoa sort of does its work. You're gonna find a lot of JNI code going on there, if you do JNI programming. If you're deadlocked, we're not actually deadlocked here, but if you're deadlocked, those are the two threads where you're usually gonna find your deadlock. And now, the other thing is, if you're running in a web site, If you're running in Tiger and you've got 5.0 installed, kill-quit is really great because if you have a classic deadlock, right at the bottom, it's going to say, you have a classic deadlock. And it's going to tell you the two objects that the deadlock has occurred with. So for those of you who have ever tried to parse through threads finding a deadlock, 5.0 is really great because we actually hand you the information. Now, everyone can look down again, find the event queue.

The event queue is really the workhorse of Java. And generally speaking, if you're hung, you're going to be able to look right at the event queue and find out where the problem is. Now, I'm not hung, but you are. So at the very top, you've got a little thunk of code, which is just Java saying, "How do I wait?" And then underneath that, you actually-- you should see, those of you who are hung, you'll see information that sort of points you right back into your code to where the problem is. So we're gonna look at that code. So who can see the line number that is probably problematic? Great. So let's go to the code.

Oh, before you go to the code, this little button here. Let's talk about this. This is an important debugging tip, too. When you hang, now this is a sort of special situation because I can make this program hang very easily. But if you're sort of living in the world and you hang, don't have it be your reflex to say, okay, let's just force quit here and see if I can make it happen again. No, because one time in 50, you're not going to be able to make it happen again. You're going to be in a case where it's some, you know, really curious race condition, and you've sort of fortunately got your machine gummed up in a way that your users will get it gummed up, but you're not going to be able to make that happen again. So before you terminate, before you force quit, Make sure you do a kill-dash-quit first. Make sure you do a sample first, and then go ahead and force-quit this thing. So, but we can terminate this here 'cause we've done the kill dash quit already. We've got the information. And where's my project?

Lost. Ah. So. Your code all looks like this. You got an action listener and you have this sort of more correct version commented out. What's going on with this sample is every time through the paint, as I said, it draws the paint, and then it sort of shouts out to anybody who's watching, "Hey, I just painted."

And down here in the button that does this waiter, it's saying, okay, I'm going to wait patiently for the paint to occur. So what's going on here is that all of this stuff happens on the event queue that I talked about earlier. So the action listener for this paint button is going to sit on the event queue, and it's going to say, okay, show me a paint. Show me a paint. But the paint also has to happen on the event queue. So it's not going to be able to actually do the painting that the button is waiting for until you free up that event queue so you have sort of a deadlock situation and you're wedged.

The way to unwedge yourself, and this is just generally always a good programming tip, is be very light on the event queue. Get off of it. Give all the work to another thread and let that thread do the work. So you guys can get this all running again. Comment this out. I think it's command slash. Yeah, command slash. It'll uncomment it. Put this flawed version here doesn't spawn a new thread to do all the work, rebuild and go and everything will work great. So the other tool that I want your fingers to have done, so get your Java app, get it running, go to the terminal, type sample, and the same process ID. Ah, I'm not running, so that won't work.

I'm gonna have to do a few more steps here. Find out what's running, grab the process ID. Takes a process ID and it takes a short interval, number of seconds. And this is gonna sort of watch for a few seconds to see what's going on. Now the important thing to know here is that it gets dumped into a temp file in your temp directory. So let's take a look at that. Open and I copied and pasted the name, so we'll just open it.

And I'll just talk to you a little bit. This is the native side of things. Mostly you won't have to look at this unless you're doing a little JNI code. But I have to look at this, right? If you write in a pure Java application, your problem probably won't be in sample. But if the problem is in someone else's code, this is information that you need to give to them in case they have a problem in their JNI code, or their native code. The way that sample works is it just pokes in every 10, I guess in this case it's every 10 milliseconds, and it says what do the native stacks look like? The first number is a count, the second number is a symbol, you can see some things don't run very often. The structure of this is pretty obvious if you look into it, so I'm not going to go into this in great detail, but one of the things that you need to know is that if you're providing information to somebody else, to Apple, to another developer, These are the two sort of collections of information that we need to sort of grok what's going on with a hung application. We need kill-quit to give all the native threads, and we need something from the native side. Samples is a fine thing to give us all of the native side. So with that, let's go back to slides.

tread lightly on the event queue. Okay, so the other situation, just a little more straightforward, you're running along in Java and you crash. Well, it's sort of a tragic thing, but it happens. So, If you've written pure Java code, pretty much as far as debugging goes, you're done. It's not your fault. It's somebody else's. So really what your job is at that point is to try to make sure that it doesn't happen to your users by gathering all the relevant information together and sending it to me or my colleagues or if you know that the problem is likely in someone else's application, sending that information off to them. So where do you get the information?

The native information is gonna be right where, inside Crash Reporter's folder. So it'll be like java.crash.log or safari.crash.log. And the Java information, so there's some sort of clever stuff in the Java VM. That's going to be in a folder in a very similar location, but it's got a Java stack in it. This is also useful for you if you are doing JNI code. It'll have the Java stack, if it can figure it out, right leading up to the JNI code that crashed. So good information. If you folks are typing furiously, like every release note that we send out tends to have a sort of summary of where the stuff is. So the other thing I want to encourage you all to do, use Bug Reporter. We really, really love your bugs. In fact, one of the reasons that Tiger is so good is because I've gotten bugs, or I and my colleagues have gotten bugs from you guys and had a chance to deal with them. So what makes a great bug report? It's really down to steps to reproduce. If you give us a bug report, or one of your colleagues a bug report, and you can tell them how to make that crash happen, that's like gold.

And it goes sort of in three tiers of how rich the vein is. If you give me words saying, do this, do this, do this, do this, and then you will crash, that's really good. But even better is if you have a little chunk of sample code, static, void, main, open paren, and your instructions to me are, compile this, run, and you will crash. I mean, that's like platinum.

And the other thing you should know as developers is those bugs sort of trickle to the top of the, Let's deal with this immediately, Q. And then really, really, really the, what's better than platinum? Diamonds. So if it's got a JUnit test, it's not that far to go from static void main to subclassing JUnits test case, and then putting asserts in to say what you really expect to happen. Now, if you put one of those in a bug report, not only are we gonna eventually, hopefully be able to see exactly what the problem is, But we're going to be able to put that into our test harness at Apple so that if we make some boneheaded mistake three months later that might make your bug come back, we're going to know immediately, oh, we've messed up. So please, please, if you go to the effort of putting code together, think about using JUnit. And finally, if you just crash and you're like, damn, I'm busy, push the Send to Apple button.

Those things get collated together internally inside of Apple. And if you get a bug report on your desk and it says 513 people have seen this stack trace in their crash, I mean, this sort of gets your attention. And we do get that. So please push the send to Apple button, if nothing else. And finally, because I care about this, automate in your testing. This will make your life easier. Automated testing is here. Use JUnit, use some other automated test framework, but build testing into your development cycle. So let's talk about other important tools. Of course, you get the Java debugger and the IDE of your choice. You can do it in Xcode. You can do it in Eclipse or NetBeans or... JDB. JDB is a great native debugger. It's really, you know, gets you into the guts of the native side. So if you're doing JNI code, this is a good tool to sort of learn. It takes some doing, but it's really good. This is a sort of terminal level thing.

So, Shark, I hope there's not a session at the developers conference today that doesn't say, go use Shark to profile your application. It's great, Java's fully integrated into it. Objects, you know, allocation you can look at, you can look at methods, you can look at times. It's a terrific tool. We've got a session today, Ah, tomorrow. So check this one out. This one is definitely worth going to. And because I care about this stuff, this is something that I think pretty passionately about. Go look at JUnit. Go look at this whole test-driven development thing. It works really great. And with that, I'd like to bring up Ted Jucevic, who's gonna talk to you more about the sort of front-end things, development.

So, my name's still Ted Jucevic. We're gonna talk about where things are, as this may be an old hat for some people who have been developing on the platform. But what is different is we're gonna talk about where the Java 2 Standard Edition 5.0 stuff is. We're also gonna talk about, show you a quick tour of Xcode from a Java perspective. Some of you, that's a little old hat, but, The rest of you, it's good stuff. Of course, your standard command line tools for the Java 1.4.2 are available on the path. Java, Java C, all those fun toys. The standard Java home, library Java home, so if you're running, say, Tomcat or an application that needs to know where Java home is, that's what your environment variable would be set to. At this point in time, that point it's at the default JDK. So that would be the 142. At some future point when we move it to Java 5.0, you won't have to change your environment variable or anything like that. It'll automatically happen for you.

Extension libraries for JNI libraries, because we provide the JVMs for you, you can't really put your JNI libraries and extensions with the JVM like you do on other platforms. And then additionally, your users could say, well, you know what, this bug is occurring in 1.4.2, but I've heard it's fixed in 5.0, so let me switch to Java 2 Standard Edition 5.0. Of course, you want your JNI libraries and extensions to continue to run. So what we've done is we've provided some global spaces for you to put JNI libraries and extensions. The first one, library Java extensions, is system-wide.

So this would be something if, say, you were installing something for all users, putting in slash applications, and for some reason you didn't want to include your JNI library or extension with the application bundle. The other place is in your user's home directory, same path, and you may need to create this if it isn't already there, but, you know, the user's home directory library Java extensions. You can put that in there. That will be per user install, you know, so if for some reason this is, say, a banking application or something like that and you don't want to share that with everybody else, it goes into there. And of course, where your JNI includes for the preferred JDK, system library framework, Java VM framework.

Now, the reason you have to add that include path is on Mac OS X, we have this concept of frameworks. But, of course, JNI doesn't know about frameworks. So it doesn't put javavm slash jni.h. So what you have to do is say, go ahead, if you don't find, you know, this header file, say, jni.h, in the default framework search paths, look also here. And you can add that to the build properties in Xcode.

Of course, if you're going to be using Java 2 Standard Edition 5.0, you're going to want to put system library frameworks, javavm.frameworks, versions 5.0 headers. Now, don't write this all down. I probably should have said that at the beginning of the slide. This is well-documented in our documentation. When you install developer tools, of course you get that documentation, and then with Java 2 Standard Edition 5.0, there's another set of developer tools I'll also include the differences for Java 2.0 Starin Edition 5.0.

So, like I said, the 142 is the default one on the command line. So the same kind of thing you have to do with the JNI headers is for the Java C. You have to point it to the correct Java C. Again, that system, library, frameworks, javavm.framework, versions 1.5, commands, Java C. Now, again, don't write it down. It's well documented. You can copy and paste from the documentation. So let's actually just do this real quick. Let's go back to this demo machine. Let me go ahead and quit just about everything.

And this Java preferences is in application, utilities, Java, and then there's a folder for Java 5.0. Let me just go ahead and switch this back to 142 for my demo. And I'll get rid of my iDisk. So let's go ahead and launch Xcode. And I'm just going to create a quick project. This is actually something we don't have in, like, the hands-on SDK, but just to follow along, the important part is not the code, but actually the Java C setting. Let me just go down to Java, and let's call it a swing app, and 5.0 swing app. It's going to create it in my home directory. And if I was to go into the target, these are all your files and stuff. If you guys aren't familiar with the Xcode, Thursday of WWDC, you should get familiar with it. But from a Java perspective, if you go into the targets, double-click on the target, you'll see all these properties and settings and stuff. If you go to Java compiler settings, you go to this pop-up, and you don't have a choice. as Java C, JIKs, and the default, or the 142. So what you need to do is go to the expert settings and change the value of the Java compiler. So system, library, frameworks, javavm.frameworkversions P-E-R-S-I-O-N-S, 1.5, commands, Java C. Copy and paste works well, too.

Yes, I've done that quite a few times. So if I go ahead and run this right now, I will compile with Java 2 Standard Edition 5.0, but I get this exemption. Same kind of thing that Scott ran into. The classes, you know, they're compiled, they're targeted at the Java 5 compiler, so of course it doesn't run in 1.4.2. So the next setting is you have to go in and set the deployment. And for this, we just use 1.5 plus, Um, Let me just do a clean just to make sure everything gets updated. And of course, this will go ahead and run in Java 2 Standard Edition 5.0. Or it should. Oh, star.

I found a feature. So. Now, that application, you know, yeah, we didn't get actually any errors and stuff when we ran it, but I have this quick thing. There's this, It's kind of a theme with this session, but Scott and I, for some reason, both selected mouse pointer type stuff that's specific for Java 5.0. So let me just go ahead and get rid of the paint in here. And it's down here. Let me just cut this out and drag in this snippet of code so that we can actually do something Java 5 specific. And all this does is it essentially just creates a simple Etch-a-Sketch type application drawing based on the mouse pointer location and stuff like that. So I go out and I just get some stuff like that. So, Let's look at that application real quick. And let me give you a quick tour of things that are Macintosh specific.

So we have this thing called the comAppleEAWT. Java applications on other platforms don't have this concept of an application menu. They don't have this concept of application preferences or handlers for our standard about box. So in this EAWT, we got this thing called a... Let's see, dun-dun-dun, where is it? Application. Now, I believe if I option double click on it, I should go to the documentation for that class. Oops.

Actually, it took me to the Xcode or the Objective-C stuff. But if you look in our documentation for the Java 2 Standard Edition 1.4 or 5.0 stuff, you'll see there's a bunch of action listeners or this application class that you can set up. And what it'll do is it'll allow you to put up your about up here in the left-hand corner and actually handle those events, actually do preferences, and then handle the quit in Xcode. There's also some, so what I'm pointing you, though, at is not cross-platform. So up on our sample code website, we have this thing called an application adapter. Essentially, it's an empty stub file for all these functions that you would be calling, and you just include it in your application, your JAR file, and then when you deploy this to, say, Windows or Linux or any other Java platform, your application will continue to run. even though you've referenced these Apple-specific packages, your application will still run because it'll find those empty stub libraries in your application bundle and be up and running and fine. Let's see if there's a few more things. We've got a few minutes that I can actually talk about here. We also have events for handling open application and open file.

So if for some reason, say, like, you're, say, a word processor or something like that, And you want your application, when they double click on, say, a doc, your word processor extension document. What you can do is you can set up your application's plist, just standard application bundle plist settings, so that you'll handle that extension. If you set up for this application listener, to handle open file, what you'll do is you'll get in this application event a pointer to the URL for where that file was opened, like on the finder or something like that. And so you can actually get a full-fledged Mac OS X Java application using this class that doesn't necessarily look or feel like a Java application just brought over from another platform. But at the same time, using that application, Um, the sample code that I referred to on our website, the application stubs, you can still use that same binary on other platforms. So definitely check that out. It's in our documentation. It's under com/apple/eat/AEWT. And look at the application listener stuff. This is some really cool stuff that will make your application just run and behave and act like a normal Mac OS X application.

So we've actually come to the end of our presentation. If we can go back to slides, I think that's the last one there. And I think we're at the point where we got Q&A. So for more information... We got a humongous URL that you can go to and download all the documentation that we are pointing you to and stuff like that.

Related sessions, well, there's actually a little conflict. Right after here is the Develop, Debug, Deploy lab. And go to that, but there's also a J2ME devices. So if you're interested in doing Java 2 micro edition development, there's a session in the Presidio right after this. But if you're just doing standard Java development, go to the lab. And if you have any questions, they'll be happy to help you there.

And there's actually, there's a JNI session. There should have been more on here. There's a JNI session that Scott pointed out that's this afternoon. Go to that one. That's a great session. There's also a performance session. I believe that's tomorrow at 9 AM, right? That is gonna be a great session. That's gonna talk about graphics, just general performance tips on Mac OS X. If you have any concerns about performance at all, Go to those two sessions and you'll get essentially all your questions answered.