Good morning everyone, this is session 318, Using Xcode for Java Development. Please welcome Ted Jucevic, Java Engineer. Let's see, where is that clicker? There it is. So, welcome to Xcode for Java Development. Wednesday morning, halfway through the week, ready to get going. So, why are you here? Basically, if you do Java development on Mac OS X, and you want to learn more about the tools that we provide, if you want to know how Xcode can help you do Java development, and if you want to know what's new in Xcode for Java development. Those are the questions that we're going to try and address at this session.

So, more specifically, what are we going to talk about? Well, as you know, I'm going There's been lots of Xcode updates. We're going to talk about code completion, which is something new for Java and Xcode. We're also including Ant now with your Xcode distributions, and so we're going to be kind of going into that. It's a direction we're moving in. There's an application developer preview that will allow you to do a lot of J2EE development on your client machine. We're going to talk briefly about that, and then of course the Java 142 update.

We're also going to go into detail about actually doing builds with Xcode. and David And then also debugging and then finalize with our 1.5 and talk about what you need to do to actually do development with that in Xcode because it's not completely there yet but it's very easy to get working.

So what is Xcode? Actually this all should just be review. By this point in the week you don't know what Xcode is. Well, we'll show it to you. So C++, C, Objective-C, AppleScript, Java, IDE, full Java debugger, GDB integration, AppleScript debugger, included with every Mac OS X. Updates available, of course, from connect.apple.com.

We are also introducing previews for this week: 1.5 and 2.0. The 1.5 is for Panther, the 2.0 is for Tiger. Dave Ewings will actually go into a little bit of the differences a little bit later on. And like I said earlier, those are both available from connect.apple.com. So at this point, let me bring up Dave Ewing and give him to show you a demo of CodeSense. Here's Dave Ewing.

Thanks. Good morning. So, Codesense actually is one of the big things new in Xcode this year. We've had Codesense in some form for quite some time. The best support, of course, has been in Objective-C and C++, but now we're bringing some new stuff along. To you Java developers. So CodeSense is actually a group of technologies. It's used for class browsing. We have a Symbol smart group in the main window. There's a number of navigation capabilities that are provided by CodeSense. And of course, new is code completion for Java.

So CodeSense is based on indexing. Now, indexing has gotten a bad rap with Xcode for Java for a little while here. We've improved the speed quite a bit. Indexing the system JDK classes is about 10 times faster than it was in Xcode 1.2, so you'll definitely notice that speed difference. And in fact, indexing of source files happens on another thread, not on the main thread, so it won't get in your way while you're editing your files.

It's also important to know that CodeSense is something that's used by the Java portions of Xcode for the debugger and also for the Jam-based build system. The debugger uses it so that it can actually get the correspondence between class files that are running and the source files that you're editing. And the build system uses it to get dependency information so that it can speed up your build times.

So code completion, I think if you guys are Java developers, you've seen code completion on a number of IDEs. It allows you to automatically suggest a completion based on the current context that you're editing in. In Xcode, you can bring it up on demand, or you can have it automatically come up.

You can have it limit the list that comes up to only those that match what you've typed so far. That's something that's a little different from other IDE implementations, something that I personally like quite a bit. And when you insert method calls, it'll insert placeholder strings for each of the arguments.

So as I said, the Java support for code completion is new. We actually had some completion there in, well, 1.1 and 1.2, but it was based on only the words in the current file, so a little helpful, not quite what you're used to. The preview is here at the conference in both Xcode 1.5 and 2.0. There are some known limitations.

It's not done yet. It's definitely a preview. It's actually a little bit more stable in the 1.5 release than it is in the 2.0 release, just because everything around it is a little more stable. So with that, we still want to know what you like and what you don't like about it.

You're certainly welcome to tell us about some of the limitations you see while using it, although I swear we do know about some of them. It's not a surprise. We know we're not done. With that, I'm going to do a little demonstration of CodeSense. So let's bring up Xcode here. And just create a new swing application. Let's see, new project.

And there we go. Okay, there's one issue here. This is Xcode 1.2. So Ted, did you know that Xcode 1.2 is on there? Can we switch over to this machine? I'll do a demo on Tiger. It's a little less stable here, which is why I wanted to do it on Panther, but we'll go ahead and bring up Xcode and show this here. So, new project. Yeah, can you switch demo machines, please? Over to the demo one here? Sorry to change my mind on you.

Okay, so we have a new project here. Well, that's good. At least you guys can see it. So, there's the groups and file list over here on the left, stuff you've seen before, and a list of what's selected shows up on the right in the detail view. The first thing I want to show you is the project symbols smart group.

So a smart group is something in Xcode that gets its contents dynamically from the project itself. In this case, the project symbol smart group shows you the symbols that have been indexed in your project. Only the stuff in your project, it doesn't show anything that's brought in from frameworks or from the system JDK.

Okay, so we can go ahead and bring up an editor here, and you can click around on it, and of course take you to the location you're looking for. And you can filter. So you can say, "Oh, let's search for any symbol that has the word 'about' in it." And it shows you that all right away. Another thing in Xcode, is that you can command-double-click on words in your file to quickly navigate between them.

Now I command-double-clicked there, and of course there are quite a few classes that implement set-resizable. So let's go ahead to the dialog version of that. So this is something also that's new in Xcode 1.5 and 2.0. We have the system classes indexed for you, but we wouldn't show you any of their contents. So here we're showing you a dump of the class file, and you can move around it. It only shows you essentially the APIs.

It doesn't show you a dump of the bytecode or decompile. But it does give you an idea of what APIs are there. Okay, with that, let's go ahead and bring up the class browser for this project. It takes a second. There's actually quite a lot of classes in here, as you guys know.

What's that? Oh, there we go. Sorry about that. So it's got all the JDK classes in here, and you can click around between them. You can of course limit what you're looking at. So I only care about the classes in this project. I'm going to close this and then option click on the twisty triangle, and it shows all the classes in your project in the hierarchy. One nice thing, you can also look at all the classes in a flat view. This of course takes a second. I forget how many thousands of classes there are here, but there's many, many, many.

And if we were to click on one of those and wanted to see where it appeared in the hierarchy—I don't know if this is a particularly interesting one that I've clicked on—one thing you can do is just switch back to the hierarchy view and it'll keep that selected. It's down there at the bottom.

Let's go ahead and close up the class browser. Well, I'm going to do a little editing here, but what I want to do—this is a standard Swing application.

Go ahead and run it, just to show, you know, it brings up the standard stuff. It's got a preference box, which is kind of boring. I'm going to change the preference box a little, and I'll show you code completion while I'm doing that. Let's just see what symbols have to do with preferences, and they come up.

The first thing I'll do is preferences is the method in the application that brings up the preferences box, and I want to tell it to change its font. I'm going to say "prefs And if you hit option escape, it'll bring up a list for you of what's available. And it turns out that it knows about the instance variable prefs there, which is of type prefpane. Go ahead and hit tab to complete that.

How do you use that zoom feature? Actually, you know what, I can do something almost as good. Let's go ahead and make that a little bit bigger. And the text size—boy, that is small, isn't it? Is that a little better? Yeah, sorry about that. Okay, so where was I? Preferences.

Okay, and actually while I do this, let's go ahead into the preferences and show you quickly under the navigation, there's options to automatically suggest. I'm going to turn on the automatically suggest option here. since that's actually the way I work and I prefer it that way. So as you start to type, it'll underline the text that you've typed in. It says, "I know that there's something that can be completed." And the underline is that clue that there's something there and that it's ambiguous.

It doesn't know what is next. But if I type a little bit more, it says, "Oh, the only symbol that's next that has an F after it also has an O." And you can bring up the list, of course, and see. So there's set focusable and quite a few other routines there. But I'm going to do a set font. And if I hit tab and complete it, it inserts a little placeholder there that tells you the type of the argument. So I also know that there's--. A font instance variable there, too.

And let's go ahead into the preference pane itself, and we need to add a new method. It turns out if you just set the font on the pane, that won't affect the text inside it, so we need to go in there too. So we'll just click on one of those and start adding a new method there. So it knows public and just continue on here. We'll add set font and type font and just give it an argument named F. And for this, we'll call the super class version of set font.

Let's go ahead and—oh, Wow, see this is why I didn't want to do it on Tiger. So there is an issue here, unfortunately.

Let's see, talk about one more thing in Xcode. Showing that demo is not that amazing. I mean, it does actually set the preferences and change the style. So the last thing I want to tell you about is index templates in Xcode.

In order to speed up indexing even more—so we've made indexing ten times faster for indexing your system class files—well, you can actually get rid of the time to index that all together, and that's done using a feature called index templates. And they're not set up for you by default on the machine, but they are documented in there.

It's very easy to do. It's just running one command line application that will set them up for you. And the instructions for doing that are down inside developer. Extras, Xcode templates. Oh, it's Tiger, that's right. Were you going to say use Spotlight? Anyhow, so they're inside Xcode index templates here.

Yeah, we're not showing off spotlight, right? And these instructions tell you how to set it up. It's very easy. It takes a couple of minutes for it to index everything. It sets up index templates not just for Java, but also for Cocoa project types and Carbon project types.

So what that does is that when you create a new project, it'll instantly index all of the system files. You don't have to do it every time you create a new project. And when you rebuild your index, if you were to do that, which you shouldn't need to do nearly as much as you did in the past, then that is sped up quite a bit, too. Okay, with that, I think we'll bring it back to Ted here. Thank you very much, Dave. Okay.

Ant is very important to the Java environment and it's a great build system for Java. Up to this point, we've been focusing mainly on the Jam build system. With the addition of Ant into the Xcode 1.5 and 2.0, the Xcode is a great way to build a Java system.

We're not abandoning the Jam stuff at all, so you don't have to scramble and move your stuff over. We're just providing options. So in addition with this Ant, you get a bunch of templates, an empty project, one for building a jar, and one for building an application jar, so one with manifest and all that.

The Ant that comes is 1.6.1, the latest release, and you target it using an external build environment. One thing to note, we actually discovered another issue while we were quickly trying to get this out, and that the 1.6.1 that we have and we're distributing is actually missing a few of the components.

So, the application developer server preview. This includes JBoss. It's actually the final candidate version of it, or the release candidate version actually. It includes Tomcat, xDoclet, and also an older version of Ant. The older version of Ant is actually installed in a different location. This version will be going away and we're going to be using the new one in the 1.6 from the Xcode install. Maybe the templates point to the old one because this actually came out before our Xcode updates.

Just continue using it and at some point you may just need to switch your build file if you're using one of those templates, but it's pretty easy to do. This is also available in the developer tools section of connect.apple.com. One of the things that we like to do is do demonstration of how easy it is to do servlets and J2EE applications. Okay. We're actually doing a demo of this in building your website on Apple computer later. I think it's Thursday afternoon.

So the application server in Xcode, the web modules is one of the templates that's installed. That's essentially a servlet. EJB module for doing Java bean, and of course the enterprise application. All those templates are included in that update. One of the cool things about this is that when you install this server update, it installs in a location that's the same location as if you're deploying on XServe with 10 servers.

So if you build and set up everything on your client machine using this, you can then deploy to XServe without having to worry about any directory configuration stuff or anything like that. It's actually very easy. Of course, you can deploy to any platform, you know, portable ant targets and all that. So it's actually something really cool to check out. Additionally, we came out with the 1.4.2 update for Xcode.

This includes JNI headers, stuff like that. So if you had, like, the 1.2 installed Xcode, and you update to 1.4.2, and it'll send you JNI libraries when your building breaks, just download this 1.4.2 update, and you'll get all the headers and all that. They'll be installed in the right location. Of course, on Tiger, it comes with 1.4.2. The Xcode 2.0, of course, has all these updates. This also includes source files and stuff, our sources that we can legally release, and documentation.

So definitely get a hold of that. So building an Xcode. I'm not going to go into so much the philosophy and the UI of Xcode, but we are going to touch on at least some of the stuff for the Java and focus on the Java portions. Of course, on the left-hand side you have your source files and stuff like that, your products and your frameworks, or jars. You also have underneath that your targets and then of course your executables. The Java targets, you have the jam targets and stuff like that. The external targets you would normally use for calling ant or something like that or makefile.

And of course you have native targets for JNI libraries. The executables, this is where you select your run debug configuration. So if say you want to debug your JNI library, you can do that. You can switch to GDB or if you want to debug the Java stuff, you can use the Java debugger. You all do that on the Xcode or in the executable.

Your arguments that you're passing to your jar file or your application, you set this all up in the executable. And then any environment variables that you want to set. So if you want to pass in, you know, a code that you want to use in your application, you can do

Ant is an external target, and that's one of the ways that Xcode allows for extending for Java stuff.

An additional way is in the build phases. So if you have a Jam target, one of the things Jam does is it calls out to external tools and stuff like that. So you can use either a shell script build phase, and often use this for like signing files or something like that, or a copy build phase. I'm actually going to go into those right here.

Shell script build phase. This is the kind of thing when you're doing a JNI target, you use a Java H. You call Java H from the shell script build phase. Signing JAR files, shell script build phase. If you have an executable or a directory setup that you want to set up for your end result, the shell script build phase is useful for that. That's what we actually use it for, to set up localization files for packages.

Also, if you have a bunch of properties files you want to write or something like that, and you want it to be dynamic, you can use that in the shell script build phase. The copies files build phase, this is where you want to move things into your build results.

This is something where if you have a JNI library, you want to copy it into your application bundle. If you have, say, one of the things that you can do is you can call out using runtime.exe to external tools. So if you want to copy those into your application bundle, copies files build phase. Nice thing about that is you can hide everything within your application bundle and not have to worry about somebody throwing away things because they don't realize what it is. And then all of a sudden your application breaks.

I'm going to give you a quick tour of Xcode. Let me go to the Panther machine over here. What I'm doing right here is, for most of the talk, we're actually going to focus on Ant. But like I said, we're not really abandoning the Jam stuff at all. We're just providing the options. So what I'm going to do is show you a little bit about some of the Jam stuff that is in there, currently in the 1.2 and in the 1.5 and 2.0. Of course, this is the targets and stuff that I talked about.

These are all the files. There's different ways that you can actually View them, just double-click on them. I know this is all pretty rudimentary. But for some people who haven't really used it, this is actually important for them. And if you want to include a file in a target, here's the check box for it. So if you have it over here, you can see, of course, the build results are included in the target. Double-click on the target.

It'll actually bring up the property list. This hasn't actually changed that much from Project Builder. So if you used it in there, it's pretty much the same. It's still in the 1.2. The panels that are important to you are the Java -- the compiler settings. This is where you can select Java C, JIKs, and stuff like that.

Set your target JVM if you want to target something else. The Java archive settings, this is where you include a manifest file. So if for some reason—well, of course, we all want our double-clickable jars to be launchable. So what you do is you put the manifest file at the root of the project, and then just type in the name here.

And of course, all these are properties, so if you set something in there, it'll show up in this list and you can go on and configure things manually. So if you wanted to call out to another Java compiler or something like that, Greg's actually going to show you that.

Peer Java Specific, down here. These are actually the plist entries, and these are the kind of things that are used when you're launching your double-clickable application. These are the kind of things like your properties, if you want to add additional properties for the Macintosh platform. Additional JVM options, say if you wanted to do profiling or something like that, you could type that in here, set your heap size.

Set the current working directory to the content's resources/java subdirectory. This is, say, if the current working directory of the Java application is normally just outside the executable bundle, but you can actually set it to internal to the executable bundle so that when you're calling out to external tools or something like that or referring to property files, they're within the actual application bundle.

Sometimes this is just something—if for some reason you say if you see an error, it can't launch the—invoke the NSJVM or something like that, it means this was accidentally checked. Just uncheck it. And then over here, that's the targets pretty much for the Jam stuff. This is the executable.

This is where you could create a custom one, but you can go in and set your launch arguments, things that are passed to your application, environment variables, like I said. This looks a little bit different than the 1.2. They actually have a couple of tabs across the top.

Let me see if I got—actually, on this one, I think it's the same look and feel. I can actually show it to you. If we switch to the other machine—can you do that for me real quick? Yeah, over to this other machine. Let me just show you that real quick.

I'm on the right one. /temp swing app. So let's go into here. So, looks a little bit different, but arguments and then debugging, this is where you actually set the arguments. I haven't indexed this project so it doesn't have all that yet. But that's essentially where you set up all the Jam stuff.

That's kind of the stuff that we currently provide. We actually, if you look at the project builder documentation, it'll point you to it, clear all that up for you. But we're actually coming out with new Xcode for Java documentation. Soon our tech pubs people are actively working on it.

So let's go back to the slides. Where are we there? So I keep hitting this again, but Ant integration, it's an external target. It's the same as like a legacy makefile target. it's uh... were essentially calling out to external bill tool Some of the arguments that you can pass to it, the standard ones in our templates is what I have listed here, but you can actually pass in any other kind of options you want. You're calling out to an external tool. And then in the build styles, if you've used Xcode build styles for something else, you can set variables and stuff like that. They'll be passed on to the targets.

And then if, say, you have some sort of property that you want to pass in, you can just add a dollar sign and then whatever the value is that you define in the build style onto that executable line. And that'll automatically be passed to it when you define that.

Whenever you call out to an external target, there's a lot of environment variables that we pass along. If you look at the build settings notes under the help menu, this will tell you a lot more about available options that you can capitalize on. So definitely check that out.

This is something that's overlooked, but a valuable piece of information. J2ME We're not really promoting J2ME on our platform, but it's a great example of what you can use Ant to build for on our platform. In the DMG, we're going to provide a sample template for building J2ME midlets. That will be in the disk image available tonight for the session. It's a custom executable, like I said, or it's a custom executable to run the mid-P emulator. You can use Bluetooth to push the file over from your laptop or desktop machine.

Thank you. It's a Bluetooth executable. You use Bluetooth to push it over. When you're pushing over a JAR file for MIDP, you can't define any properties in the JAD file. But if there's any properties that you need, you can just define them in your actual executable and push it over. In MIDP, you can actually use a JAD file to define additional properties that would be passed in. When you're pushing over with Bluetooth, you can only send one file at a time. So just define those within your executable.

And, oh, yes, most importantly, the emulator I'm using is actually from Mike Powers' website. It's mpowers.net, and it's the midp-osx directory. Of course, this URL is provided in the disk image, so don't worry about writing it down. And actually, we just found out today that he's going to make available a J2ME 2.0 emulator. As soon as that's available, we'll make that available or at least point you to it.

We'll get it to you somehow. I just heard about it today, so that's why I'm just kind of stumbling with that. So let's actually go over to the Panther and let's do a quick J2ME demo. And so let's go over to the Panther machine. And let me go over. I've already installed the template for the J2ME.

And so if you follow the directions included in the disk image, this will show you how to get that in there. And once you do that, it'll actually show up in Xcode as a project template. So let me just go ahead. Let me build that on the desktop. Let me just call it Asteroids.

I'm a creative speller, so I have to double check all this. And at this point, it's just pretty much just a hello world application. Let me launch X11. The current emulator, the midp1.0 emulator, is an X11 executable. So let's go ahead and just run this real quick and show you. It comes up. There it is. It's your phone on an emulator. Go ahead and just launch. Hello world.

Not very exciting, but proof of concept. But next step is, let's actually go in and Let's see, this should be in my home directory. Let's get this source. What you see over here, let me just go into it, is that you've got this blue source directory. So I'm going to go in, delete that file.

It should go ahead and delete in there. Let's copy in these sources from over here. This is a GPL version of Asteroids game. Just look on Google for Asteroids mid-P and you should be able to find it. The next step is the manifest. Let me update those. Let's just go in and copy it in from the other directory. The manifest in the JAD file.

Let's just copy that in. Replace. Replace. Now, in theory, I should just go ahead and be able to Bill, he's in the current template. Let's see, Bill Cho. Build successful, that's always a good sign. Went through, did the whole build here, and we should just be able to run it. Let's see if it actually runs. Oh no, that was the whole world. Let's try this again.

Oh, this demo's not going well. But the concept is, and what we're doing is we're actually showing Ant building for mid-P. And if you saw earlier in the Java State of the Union, it does build and everything like that, the asteroids for Mac OS X. But that's only a part of the story. Let's just send this file over actually to my Bluetooth phone. So let me go into my home directory. I got the asteroids, the build bin. And let me just send this jar file over.

Let's go ahead and turn on the camera, give it a second, it tends to fall asleep. There it goes. And if any luck, there's the phone. Notice the aspect ratio is not completely maintained with that piece of sample code. That's actually COCA component right there. And let's go ahead and send that file over. That should wake up the phone. Unable to validate device.

These demos are all going pretty good today. Um, but it does. So basically what would happen is I'd send over the file. The phone automatically wakes up, which is actually pretty cool to see. And it says, do you want to accept this file? It doesn't just blindly accept any file.

I say yes, it downloads, it starts the file, and you've got mid-P running on your phone that you built on Mac OS X. And it's actually pretty easy. The sample template will be in the disk image, and it'll be great for you to try it out. So let's go back to the slides and continue on.

So that was the J2ME demo. So, one of the problems that people have run into is building JNI on Mac OS X isn't exactly straightforward. Let's talk a little bit about it. It's actually easy, once you know how. When you're building a mid-P target, you want the library to be a JNI target.

You want the library, the executable, the result to have the start with lib and then end with the extension jnilib. And so, if say you wanted to be able to do a system.load library foo, you would actually name your target libfoo and then change the executable, the extension to be jnilib. And so, the JNI library would be libfoo.jnilib.

So there's two steps to do this in Xcode. The first step, normally what I do is I split this into multiple targets. The first step is actually to build the headers, and that's where you call JavaH with the shell script, and then to build the JNI library, and that's the second target. And then of course you have your actual application target, but I'm just focusing on the JNI library at this point.

So the header target, you add, you create a new target, a package target, a Java package. It's essentially a JAR file. Add all your classes to it with the native methods and any supporting classes that you need to compile those. Typically, you don't add all your classes because if you have 100 or so classes, then you'll end up building all those classes many times. You just want to include a subset. And then add a shell script build phase to this target.

This is essentially what you would want to add as a shell script build phase. We actually have JNI samples that includes this stuff, so you don't have to write it down. You can get it from our sample code website. But essentially, you add the JAR file to the class path, and then Java H will, if you pass in all the class names with the native methods, it'll generate all the header files for you. The next step is the JNI library target. This is a BSD dynamic library.

The first thing you need to do is to change the extension to JNI lib. This is a build option. You set the native build option for wrapper_unersort_extension to JNI lib. You do this with the custom options, the build options, and this will actually give you a JNI lib extension versus a DILIB extension.

You can build C, C++, Objective-C, anything you want into that JNI library. Just expose C entry points because that's what JNI expects. Once you get your JNI library built, the next step is actually deploying it or... Copy files build phase: That is the one where you copy the JNI library into your Java application bundle. Using the copy files build phase, there's a pop-up that you can select where in the application bundle, and you would want to use the Java resources. We add that to the dial-up search path for JNI libraries.

The Java Web Start, you would actually want to copy that file, or you would want to add that file to the Web Start project, and so that will include the JNI library in your jar. And so when you download the Java Web Start application, it will be able to find that jar for you.

And of course, talking about JNI libraries, there's a few more places that you can actually install them on the system besides the application bundle. Of course, anywhere in the Dylib search path, we look for them. Additionally, we look in the library job extensions at the root of the system, so if you want to install a JNI library for the entire system, that's the place to put it. Or if you want to install a JNI library just for the specific user that's currently running, you can install it in the same directory structure but in their home directory and we'll look there for it also.

So just a quick note, while we're talking about Java JNI, there's a few things to be aware of. Some of the threading between Java and... Our GUI is a Cocoa GUI. And what happens is when you're running a Cocoa application, it actually...the app kit thread is thread zero, and that is the one that is actually receiving all the Cocoa events and stuff like that. You don't want to block that.

And then, of course, you don't want to block the Java AWT thread. So when calling between, say, Cocoa and Java, there's a couple things that you may want to use, is when you're calling Objective-C from the Java side of it, you may want to use perform selector on main thread. And what that'll do is allow you to dispatch an event to the Objective-C app kit thread, and then be able to let your AWT thread return, say, if it was in response to button click, or mouse down, or something like that.

If you wait until done, you'll actually end up blocking that thread, so that may be something you may not want to do. And then when you're calling back into Java from Cocoa, you want to avoid running Java on the app kit thread. So to do that, you'd actually use swings invoke and wait, invoke later, or something like that, or actually invoke and wait.

Invoke and wait is kind of like the wait until done, and that you might end up hanging the app kit thread, so be very cautious if you use that. I should probably have had this build on to put a couple Xs on those. But specifically, if say you're using JAWT or a Cocoa component, JAWT paints on the AWT dispatch thread, so if you're calling out to a native Cocoa function or something like that, don't block that AWT thread because your application will sit there and won't be responsive until it comes back from the Cocoa app kit.

And then in Cocoa component, it paints on the main Cocoa thread. If you block that, then all of a sudden you won't be getting any events sent to your AWT from Cocoa. So don't block that thread. So, let me bring up Greg Bolsinga. We're going to talk about debugging in Xcode.

And, Greg. I'm going to show you a little bit about debugging in Xcode and another little thing about 1.5. I think it's pretty funny the way that we have Java 1.5, which Sun calls Tiger and ROS is called Tiger. Usually from us, you'll never hear us call Java 1.5 Tiger because it's confusing for us, too. So first off, I'm going to show you how to debug a Java applet in Safari.

I had told—I believe it was Ted that I could do this, and he said, "I didn't even know that." So we thought it would be a good demo to have here. So I'm using Tiger here. I'm going to create a swing. and the Tiger Demo Machine, Demo 1. Thank you.

So I'm just going to create this little example on the desktop. What we have here is just a standard, really simple swing application. Swing applet, I'm sorry. And what you can do is create a custom executable, like Ted had mentioned earlier. You go to the project menu, you create a custom executable. We're going to call it Safari. Choose it from the chooser.

And when you edit the custom executable here, you'll see that the executable path is application Safari. And to debug it, you'd pick the Java debugger here. This will launch Safari using Xcode and hit our breakpoint. This morning-- and I didn't want to tempt the demo gods-- I was thinking that other applications that do run Java using WebKit could also be debugged the same way. But I didn't want to try any of those other WebKit applications right now. So I started up Safari using Xcode. I set a breakpoint in the paint method here. And-- I'm going to open the HTML file for my applet.

It's going to load the applet, and now it hit the breakpoint. You can see with standard Java debugging, you get to see your thread stack here, arguments, you can examine these items here, you can step through code, or is it step over? Sorry, that was by code. And then you could just let it continue. And then there's your Java applet in Safari. Oh, I got to repaint. That's why.

Doesn't that make sense? And so you can debug Java applets in Safari if you deploy your applets that way. Another handy tool that some people may not be totally aware of is the Java plug-in. For debugging, it's really useful. When I'm debugging the actual Java plug-in, I use the Java plug-in control panel a lot as well as Java debugging, and you can even debug the native AWT code in Safari.

But you could pass all sorts of interesting things to the "Runtime, when it's invoked, using the Java runtime parameters here, you can set the boot class path. That's what I do because I'm always replacing AWT or the plugin. So you would apply it, and then the next time you run Safari, And you open that applet that I just ran, you'll see that what we—oh, I ran it from—you couldn't see the console if I just ran it from the command line, of course.

So here you can see that the output, you get to see where all your classes are loaded from. So I find it particularly useful when I'm debugging if I have got my boot class path set up wrong. I use the verbose class loader option for the Java plugin there. So what I'm going to go to now is the slides.

So like I showed you just now, you select the Java debugger in your custom executable and you'd select Safari there. And if you need to, you can debug both Java and JNI code simultaneously outside of Safari. Because JNI cannot run in an applet without certain security issues. Typically you'd use the Java debugger in Xcode. And then you could attach to that process from the command line with GDB and see your stack there. Alternately, you could probably do it the other way around if you launched your application such that it could be debugged with JDB.

I'm going to talk about how you can use the Java 1.5 preview in Xcode. Xcode is an amazing tool because it has so many options. It's amazing what it can do. Without even knowing about Java 1.5, it can both build it and run it, and that's very useful.

So some things to know about Java 1.5: It's a preview. It's not all complete yet. So in Tiger, it's only in Tiger, and in Tiger 1.4.2 is still the default Java. You can only run it from the command line. We didn't set it up so that double-clickable .apps work. Even double-clickable jars don't do anything for 1.5. So what you'd have to do is use the full version path in the terminal.

Our Java is set up so that we could have multiple Javas installed at once. It's system, library frameworks, Java VM frameworks, versions, 1.5 commands, and then Java. And all the other regular tools are there, too, such as Java H, Java C, and JAR, all those other types of tools are there.

And the new ones, PAC 200, and I'm not sure of the other ones off the top of my head. Right now, you can only debug Java with the JDB command line tool, 4.1.5 in Tiger. We don't have the debugger set up inside of Xcode yet. It's a problem in the JDK, not in Xcode.

And AWT and Swing are present in the 1.5 build, but if you try to run any, you'll find you'll quickly crash in some kind of font code. So unfortunately, that's not yet ready for the preview, but we'll have it soon. So now I'm show you how to use 1.5 in Xcode. Go back to Xcode over here.

Close up that project I had going. I'm going to use the new Ant templates available in Xcode. There's no Ant templates for Applets yet, so that's why I wasn't able to… I wasn't able to show the swing applet in Ant. So we're going to call this one Java 1.5.

These are in the release notes for 1.5, but the way to get 1.5 to compile using Ant First off, we have to get it to compile using Ant. And we use here, we use, um, Fork = true. So this is going to fork the Java CE off into a new process. and this is where you're going to give the path to the executable. Ant would seem to be versatile enough that you can also use any version of Java that you may have laying around.

I don't even know why it doesn't work. So I have to type in the full path. What I've done, and what if you do 1.5 development in the preview, what you'll want to do is certainly make a command line shortcut, an alias in your terminal to this command, because it's quite long to type in all the time. "Especially without the command line completion." So you would type in the full path to the executable in the build XML.

Right now, this source here is a very simple Hello World program, and so I made a very complicated I don't know why this worked before. Oh, actually, it's already in my clipboard, isn't it? I made a very complicated 1.5 only Hello World. We're using the generic string array list to add Hello World here, and we're using the for loop here. I don't know what the enhanced for loop is, what I believe they call it.

And this is just to show you that I'm going to be able to build using 1.5 in Xcode because this will not build. This sample here will not build in 1.4 because of the generics in the odd for loop. Choose build. We are not having luck with the demos today.

Thank you again. So now we'll see that the build has succeeded beyond all our beliefs. What we'll make now is a new custom executable. So this is how you'll be able to run 1.5 in Xcode. So because it has all these custom executables and you can set the variable names, you can even build 1.5 with Jam if you'd like to. So once again, I have to type in that path because I can't figure out how to get... See, the clipboard does work in Tiger.

So now we're going to run it using 1.5 in Xcode, and it's a terribly exciting one that says, I'm terribly sorry about that. I should have remembered that. Now you'll see that we have yet another problem. We did this this morning. Well, we always have my favorite thing.

So we built this class file here using Xcode, and now I ran that 1.5 program using 1.5.

So in theory, what we showed you is how Xcode can help you with your Java development on Mac OS X. We've gone into things that we've talked about, the AMP that's coming with the 1.5 and the 2.0. We've talked about some of the things like not quite cross-compiling but targeting other platforms, say J2ME. AMP is very useful for that.

We talked about the application server update and the 1.4.2 update for the current Panther install. With this, I think we've gotten you guys enough information to get you started, probably enough to get you up and running and asking questions. Be sure to use some of these things. One thing that we don't have up there that's actually a very useful resource is the Java developers mailing list. If you go to list.apple.com, join the Java. You'll see the Java-dev mailing list. This is an extremely active mailing list. You're going to want to set up a filter to put it into a folder for you. Otherwise, it's going to fill up your inbox rather quickly.

But the nice thing about it is you can ask pretty much any question on there, and there's usually somebody up around the world who will be able to answer it without too much -- too long. And occasionally, the Java engineers actually, when they have time, will lurk on the list, and you'll get the --