Configure player

Close

WWDC Index does not host video files

If you have access to video files, you can configure a URL pattern to be used in a video player.

URL pattern

preview

Use any of these variables in your URL pattern, the pattern is stored in your browsers' local storage.

$id
ID of session: wwdc2004-318
$eventId
ID of event: wwdc2004
$eventContentId
ID of session without event part: 318
$eventShortId
Shortened ID of event: wwdc04
$year
Year of session: 2004
$extension
Extension of original filename: mov
$filenameAlmostEvery
Filename from "(Almost) Every..." gist: ...

WWDC04 • Session 318

Using Xcode for Java Development

Development • 1:00:48

This session will showcase the great features that Xcode offers Java developers. Some of the topics we cover include: J2EE and JBoss, Ant integration, javac and/or jikes—which one to use and when, debugging with GDB and JDB, Applets, and application packaging. We also highlight Xcode's ability to build JNI applications easily, and discuss how to use native Cocoa controls to build a great Aqua user interface for your Java application.

Speakers: Ted Jucevic, Dave Ewing, Greg Bolsinga

Unlisted on Apple Developer site

Transcript

This transcript was generated using Whisper, it may have transcription errors.

Good morning, everyone. This is session 318, Using Xcode for Java Development. Please welcome Ted Jusufik, 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 wanna learn more about the tools that we provide, if you wanna 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 gonna try and address at this session.

So, more specifically, what are we going to talk about? Well, as you know, There's been lots of Xcode updates. We're gonna 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. in Java, 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. If by this point in the week you don't know what Xcode is, Well, we'll show it to you, but. 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're also introducing this week previews, so the 1.5 and 2.0. The 1.5 is for Panther. The 2.0 is for Tiger. Dave Ewing 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 class 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. 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, but 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.

So you can see that that guy inherits from an action listener. All right, let me... Let's go ahead and close up the class browser. Well, I'm gonna do a little editing here, but what I wanna 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.

Quit out of that. I'm gonna change the preference box a little, and I'll show you code completion while I'm doing that. So let's just see what symbols have to do with preferences, and they come up. So the first thing I'll do is preferences is the method in the application that brings up the preferences box, and I wanna tell it to change its font. So I'm gonna say prefs, preferences, 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. Yeah, sorry about that. Okay, so where was I? Preferences. Okay. OK, 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 superclass version of set font. Let's go ahead and... Oops.

Wow, see this is why I didn't want to do it on Tiger. So there is an issue here, unfortunately. with code completion that came in at the last moment in Tiger. It's a conflict between AppKit and Xcode. We've fixed the bug since then, but of course, it didn't make it on your seed. So now you'll see-- oops, didn't mean to click on that.

that things aren't quite ready. That would have worked just fine on Panther, so I assure you that that's a well-known bug. Let's just go ahead and I'm going to -- 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 10 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. Thank you.

So, ANT. 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, it's a great build 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 target. One thing to note, we actually discovered another issue while we were quickly trying to get this out. And that the 161 that we have and we're distributing is actually missing a few of the-- the classes. So while it works for most things, if you discover that something is missing, just go redownload the ant from the ants website. There's actually instructions. It's just a direct replacement. We don't do anything special except name the folder ant versus ant 1.6 and all that. Just replace the one on the drives and you're up and running.

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. the templates point to the old one because this actually came out before our Xcode updates. But 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 tool 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. 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 the 1.2 install of Xcode, and you update to 1.4.2, and I'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 142. 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 this 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 make file. 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 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 I guess Java Home or something like that, that's something that you really don't need on our platform, but I mean you can set that all up in the executable. So, I keep talking about extending Xcode.

To-- AMP 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. And 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 set up that you want to set up for your built 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, like, a bunch of, say, 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, like, move things into your build results. This is something where if, like, you have a JNI library, you want to copy it into your application bundle. If you want to, 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, you know, throwing away things because they don't realize what it is, and then all of a sudden your application breaks. Cool.

So I'm gonna 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 AMP. 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 checkbox 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, and 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. And then you can also use the compiler settings 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 gonna show you that.

Pure 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 contents Java, the 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.

And 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. So and then over here, that's the targets pretty much for the Jam stuff. This is the executable.

And this is where you could create a custom one, but you can go in and you 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. Slash temp, swing app. So let's go into here. So it looks a little bit different, but arguments and then debugging, this is where you actually set See, 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. And... 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. We're already there. So I keep hitting this again, but ant integration, it's an external target. It's the same as like a legacy make file target. We're essentially calling out to an external build 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, say, 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. Um, Whenever you're calling 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 kind of capitalize on. So definitely check that out. This is something that's kind of overlooked, but a valuable piece of information. So J2ME, this is a, We're not really promoting J2ME on our platform, but it's a great example of what you can use AMP to build, using build for on our platform. I'm actually-- we're going to-- 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 either your laptop or your desktop machine. Thank you. It's a Bluetooth executable. Sorry about that. Use Bluetooth to push it over. When you're pushing over a JAR file for mid-P, 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 mid-P, 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 Power's 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. So, um... 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. and 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 mid-P 1.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. And let's get this source. What you see over here, let me just go into it, is that you got this blue source directory. So I'm gonna go in, delete that file, It should go ahead and delete in there. And let's copy in these sources from over here. And this is a -- it's a GPL version of Asteroids game. Just look on Google for Asteroids mid-P, and you should be able to find it.

And let's see, the next step actually is the manifest. Let me update those. Actually, 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. 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 MidP. 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.

And I got the asteroids, the bin, and -- or the build bin. And let me just send this JAR file over. And... head, turn on the camera, give it a second, it tends to fall asleep. There it goes. And with any luck there's the phone. Notice the aspect ratio is not completely maintained. That piece of sample code, that's actually a 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. 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 MidP 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 start with lib and then end with the extension JNI lib. 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 extension to be JNI lib. 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 Java H 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 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.

of course named lib, and then whatever the extension, the library that you actually want to have loaded with system.loadlibrary. You change the extension to JNI lib. This is actually a build option. You set the native build option for wrapper under sort 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 dylib extension. And of course 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. So once you get your JNI library built, the next step is actually deploying it or... or copying into your application or something like that. Of course, like I said before, the copy files build phase, that is the one where you copy the JNI library into your Java application bundle. And actually, if 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 Dylib 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'll include the JNI library in your jar. And so when you download the Java Web Start application, it'll 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 Java 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. 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 will 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 AppKit 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 in 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 Welsinger. We're going to talk about debugging in Xcode. And Greg. - Bye.

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. Oh, I'm sorry. The Tiger demo machine, demo one. 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, 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. 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 plugin. For debugging, it's really useful. When I'm debugging the actual Java plugin, I use the Java plugin 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 plug-in. 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 run it from the command line, of course.

So here you could 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 did the demo before the slides. So now 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. Because 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, 142 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. 415. So what you 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 a 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, 415 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 gonna... show you how to use 1.5 in Xcode. Go back to Xcode over here. Close up that project I had going.

I don't need that anymore. I'm even 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 it. And we use here-- Fork equals true. So this is gonna fork the Java C 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 one five 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, 'cause 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. Thank you. Thank you again. So. 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 ArrayList 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 and Xcode, because this sample here will not build in 1.4 because of the generics in the odd four 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 could 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 gonna run it using one five 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 you can see that Xcode is very versatile. It can do all these things. I don't know why I wasn't able to get it to run using Xcode today, because I did it this morning. So I think that now we're going to bring Ted back on stage. TED KOPPEL: Thank you, Greg.

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 ANT 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. ANT 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-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 long. And occasionally, the job engineers actually, when they have time, will lurk on the list, and you'll get the information directly from the source. So with that, we move on to the Q&A. Oh, there's another thing to it. Yeah, definitely the mid-P stuff. There's an article on Sun's website about doing mid-P development on Mac OS X. Check that out. It goes into a lot of details from the command line. And now, Q&A.