My name is Ted Jucevic, and we're going to 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,

So, of course, Java on Mac OS 10.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've 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.

So of course we're going to 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 going to 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, 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 X 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 Kovach, and he's going to introduce you to our deployment strategies. Thank you, Scott.

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've added a few things, and there's just improving our integration with the operating system.

We're going to talk about how Java 5 will affect your deployment options. There are things you want to 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'll want to be aware of if you pick up one of the developer machines that we offered this year. We'll talk about what you want to know there and what were some of the deployment issues that are going to 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.

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 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, Web Start's a great way to deploy using that because you can set it up for each platform. We'll briefly mention that later.

And finally, we're not going to talk about it in this session, we're going to talk about it 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-version, that's what you're going to get.

is a great example of how to use Java Web Start. 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 Web Start 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,

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

And 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 Java-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 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 going to 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 and I have one for plus. Recall that one for plus means that I'll use the latest VM starting with at least 1.4. When you install 1.5, the meaning is follow the user's preferences as well.

So let's run 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.

is running 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.

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 want to understand in Java preferences is that Java Application Runtime Settings. That's where the end user is going to be able to pick right now what their preferred VM is for running Java applications.

You want to 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 going to work with my application. Maybe that's the right thing. Maybe that is the case. All right.

We want to discourage you from using a specific version. Get out of the habit of using 142 for your VM version.

We're going to switch and talk about Applets and Web Start. 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 15002. 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 Web Start application. We'll show you that in a few minutes.

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 Applets. So this proposes a problem. You know, what do I do if I want to take advantage of some 15 features in Applets?

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 going to demonstrate a point.

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 AntBase signed applet template. And what I've done is we've automatically built a signed applet, and I want to 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 keychain, and it's always there.

And you can now go to Keychain Access and manage whether you want to trust that certificate, delete it, whatever, using a standard Apple tool instead of this separate Java world thing that Sun has provided. So,

I am an ambitious person, and I decide that, hey, there's some cool 1.5 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. There'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 want to 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.

So how are we going to 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

is the head of the Java Development and Development team. He's the director of the Java Development and Development team.

and if I don't find either one, because it is possible to, you know, really whack your system and make Java unavailable, I'll put up something intelligent that says, you know, you don't have Java, we're sort of out of luck. So here I have 5.0, so I'll run this, 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 1.4.2.0.7, 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 1.5, 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 Web Start. So now, you saw that signed applet certificate dialog. You'll get one of those in Web Start as well if you deploy a signed application in Web Start.

This is actually a big thing for a while. So we're very happy to have it now. 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 Web Start app, for that matter.

is the developer of Web Start, and he's going to talk about how to use Web Start to deploy Java Application. Finally, there's an import facility, which is interesting. You could pre-import a Web Start 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 Web Start. All these work on Mac OS X. Everything you see on this slide works on OS X.

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 set info, 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 Web Start. That's really the best way to go.

Okay, transitions. 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 a 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. is the developer of Java Application Services, and he's going to talk about how to use Java Application Services to debug Java Application Services. 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 in Xcode if that's what you're using. Or if you're using Jar Bundler, 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 plugin, that will also fail silently as well.

So, you know, 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.

will be talking about the development of Java and Java's 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.

All right, so the first thing we're going to cover today is 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 going to cover the two most high-level problems. We're going to talk about hangs and crashes. We're going to go to two tools for dealing most specifically with hangs. We're going to really get hands-on, so get your portables out if they're not out. We're going to talk about crashes, then we're going to go into some more tools. So, hangs and crashes.

Why is my cursor spinning?

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.

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

And 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-quit?

On the native side, 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 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. So, again, same thread. This is looking for clues. How many of you folks have run the console app? is an expert on Java application development.

He's been working with us for a long time. He's been working with us for a long time. He's been working with us for a long time. 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, 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. It's like, 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 going to 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 going to actually need to press, after you copy it onto your desktop so you can modify it, you're going to 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.

Hey, 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. So the first thing you want to do to use these two techniques, we're going to talk about kill-quit-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-- is the developer of Java, and he's going to be talking about how to use Java to debug Java.

and Quit. Now, type kill - quit and the Process ID. I want you all to do this because it's sort of like-- - It's 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?"

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, to where the problem is So we're going to 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 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 do kill-quit, before you force quit...

You got an action listener, and you have this sort of more correct version commented out.

What's going on with this sample is that 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.

Ted Jucevic 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 for it. So, you know, you have sort of a deadlock situation, 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 it, give, give, give another, 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.

Ted Jucevic I think it's command slash. Yeah, command, command slash will uncomment it. You know, put this, this flawed version here that doesn't spawn a new thread to do all the work. Rebuild and go and, and, 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.

and I'll just talk to you a little bit of, 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've written 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, 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 you need to provide to somebody else. So, with that, let's go back to slides.

will be joined by Ted Jucevic, who will be joining us in the chat room. Ted, you're welcome to join us. Thank you. 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 going to 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 like 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 like a little chunk of sample code, static, void, main, open paren, you know, 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 queue. And then really, really, really, what's better than platinum? Diamonds. So if it's got a JUnit test, you know, 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 going to eventually, hopefully, be able to see exactly what the problem is, but we're going to be able to put in a bug report and we're going to put that into our test harness at Apple so that if, you know, 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, 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.

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.

and 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.

So, my name's still Ted Jucevic. We're gonna talk about where things are. 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's at the default JDK, so that would be the 1.4.2. 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.

You, 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'll 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, for 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 Java VM slash JNI.h. So what you have to do is say, go ahead. If you don't find 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.

If you're going to be using Java 2 Standard Edition 5.0, you're going to want to put system library frameworks, Java VM.frameworks, versions, 5.0, headers. 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 that will also include the differences. for Java 2.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. 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. 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 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, oh, 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, go to this pop-up, and you don't have a choice.

It's Java C, Jikes, and the-- the default are the one, four, two. 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. PERS, IONS, 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. 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'm going to show you how to use Java 5.0 for 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.0 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. And so I go out, Etch-a-Sketch, and 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.

We have this thing called the com apple EAWT. 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.

took me to the Objective-C stuff. 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, this application class that you can set up. What it will do is 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 will find those empty stub libraries in your application bundle and be up and running in time. 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 your, 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 and 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've 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.

There's actually 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 a.m., right? That is going to be a great session. That's going to 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.