Good afternoon. What we're gonna be doing today is going through-- basically, this is the next in a series of Java talks that we're gonna be doing through the conference. And the goal of this talk is to basically make sure that we're all on the same page as far as developing Java applications, because I don't know how many of you already have existing applications, but Java--we've got applications coming from MRJ on Classic Mac OS, also from a collection of other platforms. What we wanted to do before we dove into some of the other talks is to make sure that we're all working from the same foundation and understand how development on Mac OS X is going to work going forward.

So the first thing that I'm going to be going through, let's see if we can figure that out. Nope, nope, that's me. The first thing that we're going to do is go through just some basic foundations of what is on the Mac OS X platform, the CDs that you got yesterday. Make sure we're clear on the infrastructure that you've got, the development tools that you have available to you, and that kind of thing. And then what we're gonna do is spend the bulk of the presentation walking through what you need to do to bring your Java applications to Mac OS X, how you build them, how you set them up, that kind of thing, to the point that you're actually ready to deliver them to your customers on Mac OS X. And then at the end, I'm gonna point you at all of the different sessions that you can go to after this to get more information. But we wanted to make sure, into those other talks that were all talking on the same page.

So it occurred to me when we were like going through setting up this presentation, I was trying to figure out how to lay this out so that it would make a certain amount of sense. And it occurred to me that building a job application is real similar to cooking for, to put it real simply.

There's a whole collection of steps that you have to do to go through and make an application that are very similar actually to the steps that are required to bake a cake or something like that. First of all, there's a collection of ingredients and tools that you're going to need to make sure you have. In the case of a recipe, let's say you're making a cake, it's the flours, the sugar, the eggs, all that kind of stuff. It's the pots and pans, the oven, that kind of thing. And a Java application is real similar. You've got your source code. You've got the things that you're bringing from the other platforms into the equation. And then there's the things that we provide. Beyond that, there's a collection of pre-prep steps that you're going to need to go through.

and we're gonna go through that as it relates to your application. Then there's the actual bulk of the preparation of your application, what you do to actually build the application to get to the point where you've got a running executable that you can test and run and debug and that kind of thing. Um, but in my opinion, almost more importantly, especially if you're coming from a point where you've already got an application, is once you've got the application ready and running, there's a collection of basically flash-in-the-pan kinds of things. all of the garnish and the stuff that goes around your application to make it behave well and fit in well with the Macintosh. So we're gonna go into how to make your Java application, then blend into the Macintosh, and be something that your end users will be happy using, especially if you've got hardcore Mac users that are used to a whole collection of behaviors.

There's things that you're gonna need to be aware of in your application to make sure that Mac users are happy with your application. And then finally, there's the delivery. How do you actually bundle it up and give it to your developers? So, let's dive in. First of all, there's the supplies and ingredients that you need to walk into your development with.

Like I said before, the supplies and ingredients in cooking are the things you buy from the grocery store and the things that would be in your kitchen. In your Java application, it's your source code, it's your make files, it's your Code Warrior projects if you've got those, any resource files, icon files, images, that kind of thing. And it's also the tools that we're going to provide. So I'm going to walk you through basically what we're going to be providing and what you need to bring to the game. So let's start off first with a basic kind of block diagram that you're familiar with in all of these talks, is the basic architecture as it relates to Java. First of all, you've got the classic Mac OS X Core OS. It's a standard Unix style, Mach kernel, all of the systems facilities that Unix developers are familiar with are going to be available to you on Mach 10. And that's why Mac OS X lends itself very well to Java, is Java's designed around those kind of primitives and that kind of architecture. So that's what's sitting under the covers.

That's some of the work that we had to do on Classic Mac OS to shoehorn Java onto Classic Mac OS. We don't have to do as much of the nitty gritty kind of things because the OS is down there. On top of it, you've got the standard Unix development tools that Unix developers are familiar with as far as command line tools, all of the facilities that you've come to know and love or know and hate depending on how well you like Unix. Those are all down there and available to you. if you're coming at it from a Unix development environment, you've got those available to you.

In addition, there's the Java, which is the bulk of this presentation and these talks, is what we're going to be providing is a core Java, Java 2 version 1.2.2 platform with all of the Java tools that are familiar to Java developers on Solaris, all of the standard command line tools, in addition to a collection of tools that Apple's providing to you to make your application better, make your application development experience better on the Macintosh, Mac OS X, pardon me.

And on top of it is your application. So that's the kind of final product that we're hoping to walk out of this presentation with. So first of all, the supplies, what we're going to be bringing to the table is a basic unit, MOX kernel, Java 2 standard edition, and Project Builder, which we believe is a world-class development environment that you can use to build your applications. And that's what the core of this presentation is going to be about is using Project Builder to build Java applications. I'll go into some of the other tools briefly as well, but this is how we're gonna slant this presentation. And what you're gonna be bringing is your standard Java application and your recipe for building it.

That may be the Makefiles, that may be the Code Warrior projects, that kind of thing. But however you build it, your understanding of how to build your product. So the base development platform, is a, like I said, the standard Mach Unix base OS, standard Unix development tools. For those of you that have more complex Java applications that aren't pure Java, you're gonna care about a collection, a lot of these.

Things like MakerGNU Make or Jam that comes with Project Builder. CC, GCC, if you care about those kind of things. GDB, standard Unix development tools for building native methods, for building any other portions of your platform. In addition, the Java 2 SDK standard edition, right now what's on your CD is the 1.2.2 version of the Java 2 standard edition. Our plans for Mac OS X GM as they stand right now are to rev to the 1.3 version, but that wasn't available at the time that we had to slam the CD, so we didn't merge that in to what you've got on your CD, but that is the plan for Mac OS X GM.

High-level Java 2 features, Steve went over some of these, and I could spend an entire talk talking about all the different features that are in Java 2, and I don't want to go into all those details, but there are some high-level features that you should be aware of that are interesting, especially to those of you that are familiar with MRJ on classic Mac OS. First of all, there's the Java Foundation classes, which, I mean, I'm biased, but those, in my opinion, are the most interesting, which is the Swing UI framework particularly, which is a much more flexible, much more well-architected UI framework for developing applications that allow you to write applications that much more seamlessly move from platform to platform than we got with the classic AWT. It also allows for pluggable look and feels, and you've seen actually demos of that in previous presentations of the Mac OS look and feel, the Aqua look and feel that we're working on for Mac OS X. In addition, there's the Java 2D graphics architecture, which is an extremely powerful graphics architecture that provides a lot more graphics primitives and functionality than you got out of Java in the past. And we're working really hard to tie this in with the platform and the infrastructure that's available on Mac OS X. There's also a collection of collection classes, the kinds of infrastructure that a lot of application developers end up rewriting whenever they get a new platform, Java's providing a lot of those things for you. In addition, there's a policy-based enhanced security which is a much more exhaustive security model than it was available in the past, much more flexible. And also a collection of APIs to the VM. And this is particularly interesting to those of you that are doing development tools. We would actually love to hear from you if you're doing development tools, because the VM that is on Mac OS X allows for-- provides APIs for plugging in debuggers and plugging in profilers and that kind of thing. So if you're interested in that, um, there, the follow-on talks will give you more information about that.

We would actually love to talk to you about that. And then there's a gazillion other features. I mean, I don't know if you, I don't know how many of you saw, um, Snarov's talk yesterday, but, um, the, the Java 2 platform is huge compared to, um, the JDK 1.1 platform.

So in addition, like we've done on MRJ in the past, Java for Mac OS X is gonna provide a collection of other features as well. First of all, the hotspot client compiler. You saw a bunch of numbers on this yesterday. We hope that this is gonna give us amazing performance on Mac OS X and make your application scream. In addition, we're working on an improved application embedding model. I don't know how many of you are familiar with the JManager, but the JManager we've discovered over the course of years of development is kinda complex to use.

and a little confusing for application developers to use. On Mac OS X, we're moving to a much simpler, and in my opinion, much more powerful embedding model that is very similar to what you're familiar with, with developing other Carbon applications. Um, so Blaine's talk, um, tomorrow will, um, provide more information on that, as well as a new, a new and improved, um, JDIRECT Native Method Access, um, that will, that we ended up having to read, make minor changes to, to allow for pluggable VMs, which is one of the features of the Mac OS X Java. And then there's a collection of other, um, features that, that are available as well.

What isn't in DP4? I figured it was worth calling out what isn't there so that when you're poking around and starting to play with this that you don't expect things that aren't there. First of all, the Aqua look and feel for swing, it's not that it's not there. There's a collection of very visible bugs. So when you're playing around, keep in mind that there's a couple of very visible bugs that you'll see that just didn't make the cut. We were like cramming to get stuff in and you'll see that those bugs have actually been fixed recently but they didn't make the cut for the CD. So we're going to work on a mechanism to get those out to you but in the meantime you'll notice things like scroll bars aren't appearing and things like that. That will be fixed, obviously, it'll be fixed on stage, but I didn't want you surprised and mailing us, telling us that it wasn't there, because we know. Um, input method support. Java 2 provides a, a... Impressive input method support for internationalization and that kind of thing. And that is not wired into the system input method support right now.

So input method support isn't there. Java sound, Java 2 provides, actually provides a sound architecture which wasn't really there in previous versions it was. But Java 2 sound isn't there in printing. Almost is there but not quite. So, and the MRJ toolkit classes. The MRJ toolkit classes are ones that if you're using in your application, we would also like to hear from you because we didn't put those in largely because we need to rethink some of those and see how they apply to Mac OS X. So those will be in as appropriate in GM, but we're re-architecting some of those. So if you're relying on those, those aren't available in DP4. We talked about what the ingredients are and the kinds of things that you need, but the next step in any recipe is making sure that you've got everything available to you, All the supplies are laid out, easily accessible, so that you can dive into the actual presentation. The first thing that you're gonna need to be aware of is your sources. You should be able to, and actually what I've done and what I was doing in the hall yesterday is basically taking your classic Mac OS drive, slamming it on Mac OS X, you've got your folder full of sources, your projects, all of those kind of things. Just make sure that they're available to you straight across, whether it be Unix style things or your Metrowerks projects.

The other thing you need to be aware of is development tools. There's a collection of, I keep using that word over and over again, there's a collection of development tools options for you. This presentation is going to be targeted at a project builder because frankly I think it's really cool. But there's a collection of other development tools and development environments that are also reasonably cool as well or really cool as well depending on what the kind of application you're developing. So project builder is what we're going to be talking about but Metrowerks Code Warrior is also available and there's, I don't remember if the Code Warrior presentations already will be happening, but Code Warrior for Mac OS X, as well as you can develop on classic Mac OS, your Code Warrior projects, and bundle them up for Mac OS X, so that's an option, as well as standard Unix-style tools. So there's a lot of options for you, and hopefully more to come.

And then there's a collection of other tools. The standard JDK tools, which I keep saying over and over again, that are all there. There's alternate tools such as the Jyce compiler, which in certain situations we've discovered is a lot faster than Java C, but it depends on your situations. There's application packaging tools that we're providing to you for creating app bundles. And we're going to go into app bundles a little more in a little while, but we're providing some tools for you to be able to do that kind of thing. And debugging tools. There's standard Unix debugging tools, GDB, JDB. There's also work going on to integrate the debugging into the IDE. There's already debugging support for native apps, and we're working on Java debugging in the IDE. So you should be able to, within Project Builder, do full-fledged Java debugging. So... The other thing to be aware of and be familiar with before you start diving in is where to find the JDK. Those of you that are familiar with Unix platforms, um, will be familiar to a certain extent with what you find on the disk on Mac OS X. On Mac OS X in general, the libraries and frameworks are down. If you go through your directory, if you've installed it, you may have noticed.

In system, libraries, frameworks, there's a Java VM framework. That's where the entire Java VM lives. There's links in Unix places to make, make some of the make files and work and that kind of thing. But essentially, you've got inside of your Java VM framework, you've got your classes directory that has classes.jar. You've got commands, headers, all the normal kinds of stuff.

And you'll also see a versions directory in there. This is an internal development process. We're not going to have multiple versions of the JVM on the, on the final shipping product, but this is how standard Mac OS X applications are going to be bundled up. So if you go rooting around, you'll discover things that you're familiar with. This is different than what you're familiar with if you're familiar with MRJ, because MRJ separates out the runtime from the software development kit so that you get the MRJ SDK with all the tools and that kind of thing. Those are on the disk here. So those will all be available to you in one place.

So the preparation, for the preparation I'm going to call Leanne Rucker up on stage, who is actually also the person that wrote the Mac Look and Feel, and she's going to help me drive some of the demonstrations. The thing to keep in mind as I'm walking through the entire presentation is that we're going to be working on Project Builder. What's in Project Builder right now supports building Java applications, but it doesn't support it through some of the wizards and that kind of thing. There's a few hoops that we're going to have to jump through to get to a final built Java application. And I'll point out the differences. I'm also gonna push up a demo project up onto a mailing list, which we'll tell you about at the end of the presentation. So that you can see the things that are temporary workarounds versus the things that you're actually gonna be doing. But the final goal of Project Builder is to have full support for Java applications. But what's on your desk right now doesn't do that. So for this, could I have demo one up on that monitor, please?

Okay, so the first thing that you're gonna need to do when you're, when you're building your application is create a new project. Um, so for this, it's fairly straightforward. New project, um, the... Wizards right now, like I said, don't support building Java applications. We're going to kind of walk around doing the building of the Java application.

So in this case, what we're going to do is build a Carbon application because there's a small Carbon stub that we're going to build that's going to launch Java. So you would select build Carbon application and then select your project name. In this case, I've actually got one that's kind of precooked a little that I'll show you the flag but I didn't want to dwell on all of the little details. So in this case, we're going to cancel out of here, go to file and click, select open new project, and then just select the MetroXPB project and open that up. What you'll see in here is basically your entire project. And what we're going to do with this template project is bring in all of the sources, all of the different pieces that make up your job application.

So first of all, what we're going to do is add all of your sources. So to do that, you click on the sources directory and go up to project, add files. and select all of your sources. You can add them in hierarchies or you can add them one by one. What we're gonna do is go ahead and add all the Java sources.

Project Builder is aware of how to build Java code, just not as standard applications. So you can see in here, we've imported all the sources into Java. In addition, there's a collection of resources that you're going to need to be aware of and be including in your application to make your Java application look and feel like a Mac-application. So what we're going to do here is, again, to add resource files, you add files, and then what we're going to do is there's a metalworks.icns. And basically what I've done in this is taken the Metalworks that you get out of the standard Java distribution and made some minor things to be able to build it with project builders. So we're gonna have a meta works that I see in this, which are icon files. I'll show you how to wire in icon files. And your MRJ app properties. So go ahead and add those.

MRJ app, for those of you that have already been playing with MRJ and gotten the latest MRJ SDK, you'll see the MRJ app builder. This is a new application bundling model that will allow us to take applications back and forth. I'll talk about that a little, a little later, but the important piece of it is this MRJ app.properties file. So if you could boink on that, go back one, go back to the files. MRJ app.properties. What you can see in here is basically the app.properties is is how you define all of the details of how to launch the application. This is where you define your main class, this is where you define your class path, and then there's a collection of other-- you can define command line switches, you can define all of the different flags that we would normally pass into the VM. You define these in here. So what you can see up here is I have defined a-- the com.apple.mrj_applications_main is the Metalworks, which is the main class, and the class path is where to find these.

And you'll see that the Metalworks just the standard class. The contents resources Java metalworks.jar is what Project Builder's gonna build. So that path up to it, I'll talk a little bit about in just a second, but it's a reference into the app package. And Project Builder is going to actually build a jar that is called whatever your target name is,.jar.

And so you're gonna need to point your MRJ, MRJ app.properties into there. So the other things you can see up here are some of what I was talking about, some of the kind of workarounds that you're gonna need to be able to use what you've got in your CD right now. A lot of these will be going away, and Project Builder will be able to burp out the correct application, um, for the GM version of Project Builder, but right now you're gonna have to do a little bit of-- a little bit of a dance to get this to happen. So what you can see here is the Java App Shell, which is basically a little tiny C Carbon application, um, that actually launches the Java application, and, um, and the headers. And then there's a collection of external libraries and frameworks, which are C libraries and frameworks that are on the system that the app builder needs. Carbon, the system, and then libappshell, which is basically a piece of our Java VM that is responsible for bootstrapping up the VM. So those things will be abstracted away from you in the final, but I did want to point them out in this presentation because when you're rooting around in your project builder files and trying to get your applications up and running, you're going to need to be aware that they're there for right now. So with that, let's go ahead and set up the build so that we're ready to build. So we boink on the targets, and then boink on the Metalworks target. So we select the actual application target that we want. And what you'll see up here, and I am just flying through this, what you'll see up here is a collection of paint that allow you to set all of the build flags that you need for your application.

Um, actually go back to the files, the files and build phases real quick. Um, this is where Project Builder is rocking all of the different files that make up your application. So you can see here, you should check when you're importing your, your sources that all your sources appear in here. You can see all your Java sources. You can also see the little stub app we have there, the frameworks and all of the other bundle resources and things like that.

So you need to make sure that those are all visible and appearing how you expect them to appear. I misimported a couple of files yesterday when I was playing with it, and they ended up in bundle resources instead of sources. So you should double check just to make sure that you didn't make a mistake in importing your files. So the next thing we want to do is click on build settings. Build settings is where you define a collection of flags that you need to build your application.

First of all is the application project name, which in this case matches the targets. The more important ones that you need to be aware of, most of these are fine with the exception of down in build flags, there are two flags that were-- Project Builder doesn't add to the Carbon application by default that you need to look for if you're not going to use our template. The Java compiler, which points at the Java--which Java compiler you want to use. If you want to use JIKs, you would point at a different Java compiler. And then the library search paths. And this basically points the access paths and compilers to point to the right to be able to find the Java VM libraries. So--and the rest of this should be set up fine.

So the next thing we want to do is Boink on the application settings. And this is where, for those of you that read through your book, the book that they gave you yesterday, you'll see there's a collection of information that goes into bundles, whether they be app bundles, or whether they be frameworks, or whatever they are. There is a info.plist that is defined in your application that defines a collection of properties. This pane here is where you go ahead and set those kind of things. This is where you set all the different CFBundle properties and any custom properties that you might want to use in your application. So most of these are actually set up correctly when you build your application. You can see your executables defined as Metalworks. You could change that if you're doing anything custom.

The only one that we're gonna define in here is the CFBundle icon file. The icon file, um, is where you would drop all of your icons from Mac OS X. So in this case, we've already got a file called that we're going to go ahead and push into there. So go ahead and hit return.

Um, so that's all we need to do in there. You can add things if you want, you don't need to. Um, the defaults for the most part are fine. Um, and then there's the executables pane. Go ahead and blink on the executables pane. This should be fine, but it defines where the executables live and how Project Builder's gonna go ahead and run your executables.

So with that, everything is set up at this point to be able to run your application. You've imported all of your sources, you've set all of your command line switches, you've told it about all of your resources, that kind of thing. So what we want to do now is go ahead and build. There's a couple of different ways you can build. There's the build menu up top or there's the shortcuts which you can see the little hammer there. If you point to the little hammer, it's going to go ahead and execute essentially under the covers of Jam Makefile. But the things that you're going to need to be aware for right now are first of all the little, the little barber pole down in the bottom right, and in the upper left you can see the hammer's turned into a stop, which tells you that it's in the process of building. You can, you also saw a collection of lines scroll by in that middle little pane there. Had there been build errors, you would have seen in the upper larger white pane, compiler failures, that kind of thing. There weren't any because that's not the point of this exercise. So, so at this point we're ready to go ahead and run your application. So if you boink on the little computer screen, or again in the debug menu, say "run," it'll go ahead and launch your application.

So what you can see here is your standard Java application. You notice down in the dock, there's the icon for our application. That's the icons that we actually put into-- we defined in the properties panes, and it's a standard Java application. The windows have Mac frames, but this is standard Metalworks that you've seen in the Java distribution. So that's all set. So now at this point, actually, can we go back to the disk? Am I going to short circuit something? Go back to the finder.

Okay, so now, and favorites, Java dev. You can see on our disk, we've got our Metalworks folder, which is where all of our sources were. You can see the source directory. Native is the little stubs that we have in there. You can see the metalworks.pbproj, which is what you'll select to open it in the future. You can also see a build directory. We open that build directory, you'll see we've got the different pieces that go into our application. Intermediates is where our project builder is going to leave all of the intermediary build files. And you can also see the application. This is the application that we just ran. So if you double click on that, it's gonna flip over. That's what Project Builder ran. So we've got an application on our disk that's ready to go. So... That's the basic preparation phase. So, like I said, and can we get the slides back up on the screen now?

So like I said, there's the basic preparation phase of okay, you've got a lot of sources that you want to dump on Mac OS X and you want to get them up and building. Um, project builders should make it very easy. You've got a collection of build tools and that kind of thing that will help you and get your Java application up and running. But in my opinion-- Oh, demo, ha, presentation. Um, in my opinion, once the preparation's done, you've basically got a pie in a pan that isn't particularly appetizing to people that are gonna want to actually use your application, eat your pie, whatever. Um, there's still a bunch of steps that you need to go through, um, to-to build a full-fledged Macadosh application. Um, we would love to believe that what JavaScript is touting as write once, run anywhere really is the case, but in my opinion, what I've been trying to tell developers for years now is that there's still a lot of work that you-- maybe not a lot of work, a lot less work than you would have to do if you're porting from Windows to Macintosh with C, but there's still a fair amount of work you need to do to make your application look and behave like Macintosh users are accustomed to. If you've got users that are accustomed to your own custom UI framework, like Oracle had, and that kind of thing, that's fine, and that's different from Mac users and Windows users.

But in the case where you're trying to write an application that's transparent to the end user, what the development environment is, then you've still got work to do to get there. The first most obvious thing that you probably saw in Metalworks running is the look and feel. The look and feel looked like a Java application. It didn't look like what Macintosh applications look like. And this is a problem. So what we've done and what you've seen in previous demos is the Aqua look and feel, the Mac OS look and feel for Swing. And what we've done is implemented a look and feel that will run both on Mac OS X now and we've actually are investigating project plans to bring it back to Mac OS 8 as well. the layers on top of Swing that takes advantage of the Macintosh toolbox, that takes advantage of Carbon, and lets you write a Macintosh-- write Swing applications that feel, or at least look, like, uh, Mac applications. The first--the first thing to keep in mind is it's-- it's Mac OS native. It's implemented on top of Carbon. Um, this has a couple of implications. First of all, it should be re-- it should be fast. Second of all, it won't run on other platforms. We have no intention of bringing the Mac look and feel to Windows. That would--I don't-- I don't really want to do that. So we have no intention, it's layered on top of Carbon, it uses the Carbon infrastructure. And the most important thing from my perspective is that you're going to get the Aqua appearance on Mac OS X or the Platinum appearance on Mac OS 8, or classic Mac OS, and most importantly, you'll get the changes that are made as the underlying platform progresses with no work on your part, and more importantly to me, no work on our part. Since it's layered on top of Carbon, as the behavior, the looks, and that kind of thing of the experience changes, our calling through Carbon will exhibit that in your application. So let's say tinges on scroll bars, any of the looks of the Aqua appearance, as they change, your application will pick them up for free. Like I said, you get the Platinum appearance on classic Mac OS. We don't have product plans for that immediately, but we do intend to roll that out. We just don't have a release platform for it. That was where the initial work was done for the look and feel, was on top of Classic Mac OS. The other thing is menu placement. Menu placement is one of those things that Windows users, Mac users fight about all the time, and we've been fighting with with Swing, is Swing traditionally has had the menus associated with Windows, which in my opinion is wrong. So for the Mac look and feel, we've allowed you to change the menu placement so the menus are in the right place where Macintosh users will expect them, so that when you bundle your application up, it will look like a Macintosh application.

So to enable this, it's super easy. It's super easy. Right now, what you've got on your CD doesn't have it on by default largely because it's still got bugs in it. We're still not completely happy with what's on the CD. So we've still got some work to do, so it's not on by default. But to turn it on just to play with it, it's super simple. It's just like enabling any other look and feel. You go ahead and call UIManager.setLookAndFeel to comApple, MRJ, Swing, MacLookAndFeel, um, just like you would any other LookAndFeel. And then if you've got a preexisting component tree, you're gonna go--have to go ahead and tell your component tree to update itself, to walk through, um, and update the LookAndFeel so that, um, it becomes visible and catches exceptions. Kind of standard Java kind of stuff. There's nothing you need to do.

To get the Mac OS menu placement, if you're writing standard swing applications, you're probably already doing what you need. All you need to do is call jframes set jmenubar. That will set the menu bar that you need and put it in the right place. There's a couple things you need to keep in mind. First of all, you can't have an AWT menu bar associated with it at the same time. You need to pick. You're going to need to pick swing menus or AWT menus. You also can't do this on jdialogues right now. They don't support heavyweight menus.

So, and there will also be a property to be able to disable this. So let's say the architecture of your application in the short term isn't set up to be able to deal with the menu bars in the right place. There will be an architecture to be able to disable this, although we'd really rather you put them in the right place. So, but like I said, it's super easy. Basically to get the Mac look and feel for Swing, it takes almost no effort on your part to enable it. So if we could get this screen up, demo one up on the screen. Oh, ha, cool. So like I said, it's super easy. Let's go back into Project Builder. In Project Builder, you've got your Metalworks.java, which in this case is where we define the Mac look and feel. So all we need to do is enable the Mac look and-- is where you define your look and feel. So all we need to do is basically comment out the line-- uncomment the line that sets the metal and comment-- do the right thing. Rebuild. Take just a second.

We should be ready to go. That's the only change that needed to be made. And if we run it now, We get the Mac look and feel. And what's funny is when I was doing this the other day, I like looked and go, "Oh man, it's broken. We got an empty frame." And then I realized that Metalworks is basically a desktop with menus. We punted the menus to the right place, and now we've got full Metalworks with the Mac look and feel just like you would expect. The only change that you had to make to get an application that looks like the Mac look and feel is to set the -- It's kind of cool, huh? It's kind of impressive. So that's all you have to do to make your changes, to make it look like the Mac-- make it use the Mac look and feel. But-- and if we can get the slides back up on here one more time.

But that's not quite enough. It's fine to make it look like a Mac-- make the widgets and that kind of stuff look like a Mac, but that's not enough to get to the point where your Macintosh users will see an application that they're aware of. you are going to need to go and read the Macintosh HI guidelines. You're going to need to be aware and basically the best advice I can give you is if you're not familiar with how Macintosh applications behave, play with them for a while.

Figure out the kinds of things, the kinds of behaviors that Macintosh application developers expect. Things like menu placement and naming. There's a collection of standard menus and standard places that Macintosh users are going to expect. They're going to expect a file menu. They're going to expect a number of items in that file menu to be standard. They're going to expect the command key shortcuts to be standard. They're going to expect an edit menu, the same kind of thing. Button positioning is another. Things like the okay and the cancel button in dialogs. Macintosh users have come to expect that certain behaviors, hitting enter in a dialog when an okay button is up, is going to do the correct thing. And that user experience is different than Windows. So it's fine to take your application to the other platform to build it for the other platform and you're basically there and technically you can run and that kind of thing. But I guarantee you that if you're trying to ship a heavyweight application that users are going to use on a regular basis, that they're not going to expect a Java look and feel. That you're going to have to do a little bit of work to rearrange things so a Macintosh user is familiar with them. Keyboard shortcuts is another. I mean basically, Macintosh users have come to know and love behaviors of their application And in my opinion, the application user shouldn't be aware of the platform you developed it on. All they should be aware of is that the application does what it expects and harmonizes in the environment that it's supposed to be. So if it's expected to look like a Macintosh application, then there's some behaviors that you're gonna need to be aware of too. So the best thing I can suggest is play with some Macintosh applications if you haven't already. I'm sure most of you have already, but if you haven't already, become familiar with that and pick up the HI guidelines because there is some work. You can't just take an application across and expect it to behave like a Macintosh application. Java's different. So you need to be aware of that.

So finally, there's the final step of, okay, we've got an Macintosh, we've got an application that looks like a Macintosh application, behaves like a Macintosh application. Um, we now need to deliver it to our users. This is, this is something that actually I'm actually kind of excited about on Mac OS X. Mac OS X has created this, this concept of a bundle. And what I would suggest you do is, I was actually leafing through the documentation we gave you, um, when you first got here, there's a really good chapter in that book on what bundles are. There's application bundles, frameworks, that kind of thing.

Um, it gives you a good breakdown of what all goes into a bundle. And when you're building heavyweight applications, you should be familiar with that. And that's what we are taking advantage of on top of Mac OS X. So Java applications are bundled just like any other applications, where you've got your info.plist, which I pointed out before in Project Builder, is where you define Macintosh-specific settings. You'll also notice, um, there's a Mac OS folder inside of the contents folder. And the contents folder is what contains contains all of the meat of your application. Inside there, there's a Mac OS folder, which is where the native stub application lives. For the most part, you're not gonna care about that if you're doing a pure Java application because we're gonna generate that for you. With Project Builder GM, we're gonna generate that for you, but that's what was generated with the little stub code that I showed you previous. You can also notice the resources folder. Resources Java is where all your Java built stuff is gonna go, and is also where your MRJ app.properties goes, and all the other resources that go along with it. So it's a pretty well laid out, and this should be obscured from the user.

We've created a tool so that if you've already got a built Java thingy-- You can drop, you can bring your pre-built jars or zips or whatever over to Mac OS X and you don't need to go through the full series of steps on building your application with Project Builder. Let's say you've got an application that has a jar already. What you would do is use the MRJ app builder to define all the same kinds of things. Point at your MRJ properties, MRJ app dot properties file, point at your configuration files, any of your applications, that kind of thing. Um, and MRJ app builder will cons up an application for you. So you don't have to go through project builder if you don't want to and it'll have the same effect. Um, but pro-this, this functionality is being merged into project builder. So project builder is gonna do the same thing.

The other cool thing, in my opinion, about the bundle model is it's going to carry back and forth between classic Mac OS and Mac OS X. The goal by Mac OS X GM for us is for you to be able to build an application bundle that will carry from Mac OS X to classic Mac OS with basically no changes.

The packaging is the same. Mac OS 9 is aware of Mac OS X bundles and should display them to users as a single double clickable application. The folder nature will be visible on pre-9.0 systems, and the way that we get-- the way that we're gonna deal with that is if you-- again, this is all documented in the book that you got earlier, but the way that you're gonna get around that is your Macintosh application folder is gonna have an alias at the top to the classic thing, so that your pre-9.0 users will open that folder and double-click on the alias. Now in DP4, you can build Mac OS X applications. We don't have the support for you yet. we will for GM to be able to build classic Mac OS applications. So for GM you'll be able to build a job application bundle that has the information for both classic Mac OS and Mac OS X for what's on your CD. You're not going to be able to do that right now.

So that's basically how you get to a full packaged application. The things I want you to take home is first of all that the development environment, while it's a little different, isn't really all that different than you're familiar with. If you're familiar with Unix, then all the tools that you're familiar with are available. But also if you're an MRJ developer, we've provided a collection of tools and interface to abstract you away from the Unixisms. You'll notice we never, in this demo, never went down into a command line to do any of that kind of work. A project builder should take care of all that for you. But if you need to, you can go down in there. Like I said, we've got a collection of enhanced development tools. We've got the ability to create a fit and finish that makes your application, the fact that your application is a Java application, transparent to the users, and we've created a simple develop, um, delivery mechanism. So, my goal and my hope is that you'll be able to go home with, um, what I've given you and the CD that you've got, um, with the ability to create a fully bundled Macintosh application.