Good morning. Welcome to Building Great Java Applications on Mac OS X. I'm Mike Swingler, and I am the lead runtime engineer for the Java team here at Apple. And today we're going to talk about some things that you can do to customize and tweak your applications to make them look great on Mac OS X. But we're also going to talk a little bit about the tools that Apple provides for building your Java applications.

We're also going to talk a lot about 64-bit and what that means for building and deploying your apps and some steps you might have to work on. And we're also going to have some guest speakers to come up and talk about the future of SWT and what that means with 64-bit.

In addition, we also have another guest speaker coming up to talk about the new out-of-process applet plugin and how that works with 64-bit as well. Then finally, I'll finish up with Mac app essentials and sort of what you need to get your application going. So, let's get started. I'm Mike Swingler, and I'm the lead runtime engineer for Building Great Java Applications on Mac OS X.

So starting off with tools, there's three major things that you need to know about tools that Apple provides. The support that we give you to build your application, all the various debugging tools we have available on our platform, and some really awesome performance tools we hope you'll use in early bring-up of your application.

So to start off with building, what we use internally in Apple and we're transitioning and migrating onto is Ant. Ant build targets are universally understood by all Java IDEs, Eclipse, NetBeans, IntelliJ. It's really the common denominator that all IDEs on every platform understand, and it's something that we're moving to in Eclipse.

I'm sorry, in Xcode. We use Eclipse a lot internally, too. We're using internally in Xcode in order to build the JDK itself as well, because the jam targets that are in Xcode are legacy, and they will be being removed at some point in a future version of Xcode, simply because it just doesn't make sense to support a totally proprietary, single-world system that only works inside of one IDE. So if you have any targets, you should migrate those soon.

So in order to do that, one of the new features we added in Mac OS X Leopard's Xcode is the organizer window. And if you go up to the window menu inside of Xcode, open up the organizer, you click on the little plus down there at the bottom, and that's your starting point for all new Java applications on Mac OS X. You can build the standard templates for applets, web start, command line.

But this is also your starting point for JNI. And this is very important if you have any JNI to use the new ant-based Xcode template and use it inside of the organizer, because the organizer will put down all of the sub-Xcode prods that you need in order to build that JNI.

Moving on to debugging, we have some really awesome tools available inside of Mac OS X built into the kernel to support debugging your Java applications. So DTrace is a technology we use from Sun, that we've adopted from Sun, to actually probe down all the way from the system kernel calls through the native parts of Java and native applications all the way up to over 508 unique probe points in Java that we have available in Java 6.

This is available on Mac OS X Leopard and also in the Snow Leopard preview you have. And just to also mention that any new tools that Sun adds. You know, JMap, JStack, Jhat, JConsole, anything else that they incorporate into future versions of JDK, we'll pick those up along as well.

So for performance tools, we've had a really great performance tool built into Mac OS X Leopard since 10.2, and that's Shark. And currently right now in the Snow Leopard preview, Shark works for 32-bit Java processes. We're working on 64-bit, but Shark continues to be a really great tool at diving into getting to the very detailed hot points of not only the native part of your applications, but also the Java stack call traces as well, and really gives you some really great analysis that's just really not possible in any other tool.

But we've also added another tool in Snow Leopard, in Leopard actually, and that's Instruments. Instruments takes a kind of higher level view and allows you to not only look at the thread states and stacks inside of your Java application and actually see what sort of locks that you're finding in your application, but also see what sort of locks that you're finding in your application. So that's a really great tool.

And then we've also added a little bit of a So if your application is triggering something that causes a lot of disk paging or you see a lot of disk IO or network IO, Instruments is a great tool to help sort of visualize what happens at a high level on the machine as you're running your application. That basically are some of the tools that we provide from Apple on the Developer Tools DVD. And now I'd like to invite Pratik Solanki, our virtual machine engineer, to come up and talk about what 64-bit means for your app. Thank you.

Good morning, everyone. My name is PratiK Solanki, and I work on the Java VM team over here at Apple. So I'm here to talk to you about the 64-bit JVM. So we're going to talk about what 64-bit means to you as Java developers. We're going to discuss some of the performance characteristics of 64-bit and then tell you how you develop and deploy for 64-bit. So let's get started. Let's get started.

What is 64-bit? Well, at the low machine level, 64-bit means that the number of bits that your processor has to address memory has doubled. It's gone from 32-bit to 64-bit. But you guys write Java code. So what does it mean for you? Java doesn't expose your native C pointers, and the Java code is pointer agnostic. So your transition to 64-bit should pretty much be done. Your pure Java code should need no changes.

I mean, the Java class file is, in a sense, the ultimate universal binary, and that should just continue to run great when you move to 64-bit. But what can the Java code do now? Well, for one, since your process now has a huge virtual address space, your Java heap size can just grow like crazy. I mean, you could go up to 127 terabytes of heap in the 64-bit world.

And some of the... Some of the things that you could do once you have such a huge heap is you could cache whole databases in memory. You could allocate huge memory-mapped NIO buffers, which will allow you to do gene sequencing, image file processing. A variety of things are now available to you in 64-bit.

So I said before that Java doesn't expose pointers, but really the Hotspot virtual machine uses a 64-bit value to store your Java object reference. So what that means is the size of your Java objects will now increase when you move to 64-bit. We don't expect that they'll just double because you have your basic data types like ints and longs and bools.

But on average, we think about a 30% increase in size of your Java objects when you move from 32-bit to 64-bit. And what that means for you is if you have ever in the past added flags to set the minimum and maximum size of your Java heap, then you would need to go back and remeasure the amount of heap that your application is using and update these XMS and XMX flags. And, you know, once again, you know, maintain good memory behavior. Just don't increase it to 127 terabytes just because you can. You know, your machine will start trashing and your performance will just go down the hill. So continue to use the smallest Java heap that you need.

The direct impact of having such a huge heap and allocating so many more objects is that your garbage collection times will now increase. So expect that if you're allocating a lot more heap space, your GC will take a longer time to run. But there's a workaround for that. We have in Java alternative garbage collectors available. We have the concurrent mark and sweep and the parallel garbage collector available. Take those out for a spin and you should see a reduced GC pos times. So we talk about speed.

We talk about the memory. Now, let's go over to speed. What happens to the speed of your application when you move to 64-bit? Well, another key thing that doubles when you move from 32 to 64 is the number of registers. The number of registers in 64-bit is twice as much as the ones in 32-bit. And what that means is the Hotspot virtual machine that's running your code can now cache more of your variables into registers, and that improves the speed of your Java application.

The other key thing that changes when you move to, The other key thing that changes when you move to 64-bit is the hotspot compiler changes from underneath you. In 32-bit, the default compiler is the client compiler. When you move to 64-bit, the server compiler becomes the default. The hotspot server compiler is a highly optimizing compiler. It has vastly improved code generation. So as a result, your code should just get faster. So let's check it out. We looked at a popular JVM benchmark.

And when we compared the default 32-bit to the default 64-bit, we saw around a 35% increase in speed. You know, code just got faster. When we dug deeper into, say, SciMark, another popular benchmark, we saw that the 64-bit VM performed about 61% faster than the 32-bit one. You know, your app may vary, so please measure and see how your app does in 64-bit. But we expect that things should just get faster.

So this was what 64-bit means and what it is. Let's take a look at 64-bit in the two OSs that you have in your hands. So let's take a look at Mac OS X Leopard. As you know, last October, we shipped Mac OS X Leopard with complete 64-bit support. What that meant is all of our tools and frameworks were 64-bit ready.

And Java being just another framework, and Java being a core framework of Mac OS X, we shipped it with Intel 64-bit support. We had Java SE5 available for Intel 64-bit, and earlier this spring, we also shipped Java 6 with Intel 64-bit. But the key thing to remember on Leopard is that all your apps run in 32-bit by default. And what that means is that 32-bit Java SE5 is the default VM on Mac OS X Leopard.

When we move to the Snow Leopard developer preview DVD that you got in your hands yesterday or today, all of our tools and frameworks are still 64-bit ready. You know, they're just better now. You know, more bug fixes have gone in, and they work even better. The Java that's on that DVD is Java 6, and we have Intel 64-bit and Intel 32-bit support in Java 6.

But the key thing to remember, the key difference for Snow Leopard is that apps will run in 64-bit by default, which means that... 64-bit Java SA6 is the default Java for Snow Leopard on capable hardware, of course. So I said before that your pure Java app should just run great in 64-bit.

Well, what if your Java app diagram looks something like this? What if your Java app had a JNI library that it communicated to, which communicates directly to the OS? When we switch the VM from underneath you, you'll start getting an unsatisfied link error, and that is because your library doesn't have a 64-bit component to it. So you need to recompile your library to be a universal JNI library. You need to add the Intel 64-bit support to your JNI code.

And the way you do that is you open up Xcode, you take a look at your JNI library target, you do a get info on that JNI library target, and you checkmark the 64-bit box. And Xcode will compile your library for 64-bit support. What Xcode is doing, under the covers for you, is it is adding a dash arch x86-64 flag to the GCC command line.

And this is what you have to do if you're not using Xcode and you're compiling it on the command line using a make file or any other means. You need to add the dash arch x86-64 flag to your GCC command line. All right. So, you know, you develop your app, you've got it all running, you test it, you make sure it all runs great. Now you want to deploy it. So let's take a look at that.

One important thing is, on Leopard and Snow Leopard, the Java Preferences app that we ship impacts the version of Java that gets used to run your app. What that means is, any user may select or may choose the 64-bit JVM to be their preferred JVM. And that means that your app might start running in 64-bit without you knowing it.

So if you need to override it, normally this should just work great, but in case you need to override this and you need to tie yourself to a specific architecture, you need to ensure that you pass the dash D32 or the dash D64 flags to your Java application so that it runs in the mode that you want.

If you're a bundled application on the Mac and you want to prefer a particular architecture, you need to add the JVM Arches key to your Info.plist that's sitting in your bundled application, and you need to specify the architectures that you prefer. So here's an example of a great app that prefers the Intel 64-bit version of the VM in preference to the 32-bit one. And if you don't need or if you want to run in 32-bit only, then you can get rid of the x86-64 from the JVM Arches field.

Another popular way to deploy applications is JNLPs or Java Web Start. And if you want to run in 64-bit using Java Web Start, then you need to pass the dashed D64 argument in your JNLP file, in the Java VM arcs field in your JNLP file. A fourth way of deploying applications is applets.

Currently, you know, Ken will have more to say about this, but currently, as things stand right now in Leopard and Snow Leopard, applets run in the address space of the browser. And what that means is, if you want to run a 64-bit Java applet, you could run it in any 64-bit browser. The problem, of course, is there are no 64-bit browsers right now. So, if you want to test this on Leopard, you need to build your own example code.

You need to build your own mini-browser, and the example code for that is in slash developer examples web kit. You need to build it for 64-bit, and then you should be able to test your applets on Mac OS X Leopard. When we move to Snow Leopard, though, the story is better. We've got Safari that's Intel 64-bit capable. Not by default, but it still can run in 64-bit. And if you want to run it in 64-bit, you need to do a get info on the Safari app icon and uncheck that.

Open in 32-bit mode flag. Once you do that, Safari will start launching in 64-bit, and you should be able to test your applets with it. So going over deployment again, if you're a pure Java app, your work is done. You don't have to do anything. If you've got native code, please recompile. Add the Intel 64-bit slice to your JNI libraries.

64-bit is here, and we believe that your Java app should work great in 64-bit. You shouldn't have to do anything. You should just continue running in 32-bit or 64-bit, irrespective of what the user chooses. Leopard defaults to 32-bit, and Snow Leopard defaults, the Snow Leopard preview DVD that you have right now defaults to 64-bit.

and only if your app really requires it, only if you really need to use a specific architecture should you use the -t32 or the -t64 flags or set a preferred architecture in your Info.plist file. And if I haven't said this enough already, please recompile your JNI libraries to be universal. Please add the Intel 64-bit slice to it. So speaking of making your native code universal, I'd like to invite on stage Scott Kovatch, who's going to talk about Eclipse and the SWT and their move to 64-bit. Thanks.

Thank you. So for those of you who were here last year and are thinking, something's different about him, you're right. I'm not on crutches. Right? Thanks. So I'm here today, actually not really as an employee of Adobe, but I'm speaking more on behalf of Eclipse. I'm currently a committer in the SWT project, and today what I want to talk to you about is what Adobe cares about Eclipse and what Eclipse cares about for the Mac platform. So we'll get started. I think everybody in this room knows about Eclipse.app.

I think we all know that it's a great Java IDE. I think you probably also know that it's a great platform for building a rich client application. Eclipse has plenty of infrastructure to let you manage resources within your application. It has the SWT and JFase for user interface. It's also got a number of other facilities for dynamically loading in plugins as needed for your particular situation.

Eclipse is also a great framework for building an IDE for any language you can think of. I mean, there's projects out there for Python and Ruby. There's a very active C community. But the one I want to talk to you about briefly is ActionScript, which is the foundation of Flax.

which is Adobe's user interface solution for enterprise development. What you can do in Eclipse is you can build in all the support for the syntax highlighting for your language, support for external compilers. For Flex, that means we call out to the Flex SDK compilers. And also provides you with some framework for doing GUI layout.

And just very quickly, I want to show you some screenshots of... I'm sorry, jumped ahead of myself here. But first of all, Adobe took advantage of all of this and produced a product called FlexBuilder. And this is an IDE that we came up with for Flex, and it's all based on the Eclipse toolset.

The first version that really gained a lot of traction and was really made heavily use of the current release of Eclipse was FlexBuilder 2, which came out two years ago. And that was the first IDE that targeted version 2 of Flex and ActionScript 3. And if you have some time, you might want to look into ActionScript 3 and see why it fits in so well with Eclipse. But earlier this year, FlexBuilder 3 came out, and that now targets Flex version 3 as well, which is what I'm going to show you here in these next slides.

So here you see we've got some ActionScript code up in the top right window. And as you can see, this is Eclipse running on a Mac. And I should say that this is Eclipse 3.4 with a not-quite-yet-released version of FlexBuilder. But as you can see, there's not a whole lot of difference.

It doesn't really change how it fits into Eclipse. But as you can see up on the top left, we've got a collection of code, the standard Eclipse project layout. Down here we have an outline view on the bottom left, and up in the code you can see how we've highlighted the syntax of the keywords of the ActionScript language. And this takes some work, but if you're working on implementing your own language support, everything's there for you to do it.

Next, we have the Flex layout design view. And I've taken this shot from one of the Flex sample applications, but on the right, you see a collection of property editors specific to the component that's selected. You know, all of this is done in Eclipse and with the SWT.

And you see some of the collection of widgets you can use in Flex to build your application. And last of all, script debugging. The debugger infrastructure in Eclipse is fully extensible, and we've written our own debugger that works with the debugging version of the Flash Player to debug your ActionScript-based applications.

All right, so all this is great and wonderful. And you're thinking, okay, he just gave me a commercial for Flex and FlexBuilder. But I'm actually telling you these things for a reason. What's this got to do with the 64-bit world? Well, everything you saw on the screen is written in the SWT, and the SWT is currently written to the Carbon API set. As you've heard this week, and as you're going to continue to hear, there is no Carbon support for the visual portions of the SWT in OS X.

and That's currently true on Leopard and it's true on Snow Leopard as well. Now it's great that there's a 32-bit VM now for Intel on Snow Leopard. So that means that you can run Eclipse today right out of the box on the Snow Leopard that you got. Doesn't help you on Leopard yet.

and there's just no other way to describe it. And he's carrying a 32-bit briefcase of fail. So where does Adobe fit in all this? Well, as you can see, I think you can see that we consider the Mac platform really important to the future of FlexBuilder and to the future of our development tools.

and we have made Eclipse a key part of our product strategy. There's FlexBuilder, there are some other additional products coming down the pike that will also be Eclipse-based. So this is really, you know, a very clear part of what's important to Adobe for its customers down the road.

And, okay, great, you know, Adobe uses Eclipse, so what? Well, how are we going to prove that? Well, as you've heard earlier, there's an SWT port to Cocoa going on right now. The IBM engineers working on the SWT came out to Apple last fall and really got things going. They made a decent amount of progress. There's a lot of nice demos you can take a look at and see what progress has been going on.

But, you know, it needs a little momentum. You know, the more people start working with it and using it, the better it is for the project. So I'm here to say that Adobe is going to give this product some momentum. We're going to actively contribute to the port of the SWT on Cocoa. We're going to dedicate at least two engineers, possibly more.

And because this is open source, you know, the best I can say right now is we will contribute to the port, but our ultimate goal is to actually lead the effort, right? My main job for the next six months will be actually actively working on this and keeping it moving. We're also going to have, as I said, other Adobe engineers who will be working out on and actually using what we build for the SWT in Adobe products.

So, that's sort of our big announcement for this week, and unlike just about everything else you've heard, As far as the future of Java, which is NDA, this is not NDA, this is public. We're gonna announce it on the Eclipse mailing list, things like that, and feel free to let other people know that that's what's going on.

So, if you want to get involved, what's going on so far? Now, this is just an announcement. It's not an actual please-go-download-it. Well, actually, you can download the code and get things going. But, just to sort of tell you where we are right now, we're really ramping up right now. I'm currently attached to some other tasks at work right now, but we're going to really get things going by the end of August of this year. The goal is to get this in the Eclipse 3.5 stream.

All this work will forward to the Eclipse 4 stream, if you've been reading about Eclipse 4. And we've been pushing some new features in Eclipse 4 SWT as well that you can read about them online, but I think we're going to be able to make good use of them on the Mac for Adobe products as well.

We want people to help. We don't want this to be an Adobe-IBM collaboration or an Adobe project. There's been some interest so far. Hopefully, if we get more momentum, more people will sort of get on the train and come along and help out. So the way to do that is to start by going to the URL that we showed you earlier about the CocoaPort. That's got all the information of where we are so far, how to find bugs, how to fix bugs, how to get involved that way.

Important that you, if this is important to you and you want to get involved, join the platform SWT dev mailing list. That's where all the communication is going to go on between Adobe engineers working on this and people across companies. We're going to keep it all out in the open.

And of course, file and fix bugs. You'll be able to get the code yourself, you'll be able to use the nightly builds and put it in your stuff, and that's the best way things will get fixed and get taken care of. And with that, I'm going to talk to you a little bit about how applets are going to move forward on Snow Leopard. I'm going to bring up Ken Russell from Sun, and he's got some very cool demos to show you here, as well as some other things as well.

Hi, my name is Ken Russell. I work at Sun Microsystems, and I'm here today to talk to you about the next-generation Java plugin and what does this mean for Java deployment in the web browser. Over the last year at Sun, we've been doing a ground-up rewrite of the Java plugin. This is the piece of software that makes applets run in the web browser.

There's one major architectural change with this rewrite, and that is that the applets are actually no longer executed in the same operating system process as the web browser. So on every platform, the new Java plugin spawns one or more JVM instances, and it's in those separate processes that the applets are actually run. They're not executed in an embedded JVM inside the web browser anymore.

From an architectural standpoint, this is very similar to how Java Web Start technology works, except, of course, that applets have a much stronger tie to the web browser. And one point to make is that multiple applets are still executed in the same JVM instance. So you have the same sharing characteristics, the same footprint characteristics, as you would with the previous Java plugin. There's just this separation. Now, why would we embark on this major rewrite? One big point to make is that the Java platform is a complex piece of software, and the web browser is a complex piece of software.

And when you wed them together very tightly, you sometimes get second-order effects that you don't expect in terms of reliability. So by very clearly defining the interactions that Java and the web browser have, we have achieved drastically improved reliability on all platforms for Java deployments in the browser. Another point to make is that the user experience is very important. to make is that the user experience is improved.

Applets are now launched in the background. So your web page comes up, your HTML content is rendering, and if your app takes a while to load it just pops into place as soon as it's ready. The web page and scrolling and everything is working just fine right off the bat. The Java JavaScript communication has been improved, there are more features, it is more portable, and the document object model support in Java has also been improved.

So you can very easily and powerfully manipulate the web page that you're contained in from within your applet and that now works reliably and portably. We've also improved the support for web services by bringing in the cross-domain dot XML connection model and this makes it very easy to access services like Flickr and Picasa and others from within your Java applets. But the main reason that we did this rewrite is the thesis that applets should be as powerful as applets.

So we've also improved the support for web applications and this sounds a lot like Java Web Start. So in the new Java plug-in you can define an applet using a JNLP file which is the same descriptor that you use when you write a Web Start application. This gives you a lot of advantages. Number one is that you have a finer grained security model.

You can on demand request things like I want to print or maybe I want to store a little persistent data on the disk and you don't have to go through the process of signing your applet. You also get support for the Java Web Start APIs like the persistent service and others. Another major advantage is that you can trivially use advanced extensions like for example Java OpenGL bindings within your applets.

So it's really easy to pull these into Web Start applications. Now it's just as easy to pull them into your applet content in the browser. You get really cool stuff like per applet JVM arguments. So if you have a really sophisticated applet you can say I need a bigger heap for just this applet.

That will be honored. You can even request a per applet JVM version. So if you're an enterprise customer and you built your app using five updates something and you say well just for understanding that I'm on the right platform I want that applet to run with that version you can request this and the plugin will honor it. So this is how the integration occurs.

You actually just use an applet parameter to point off to the JNLP file and the new Java plugin recognizes that and then it launches based on the JNLP file. So this is how the integration occurs. And this is roughly what it looks like. If you've written Web Start apps this is no big surprise. So first you have the information section.

It gives your company and title and stuff of your applet. Then there's the resources section which describes the jar files that you use in your app, the Java version that you want, any extensions like Joggle or something that you might want to pull in. And finally this is how you describe your applet.

And if you were writing a Web Start application you would use the application desk tag here. This is the JNLP spec because we're writing an applet. Now I'd like to point out that we actually have some very interesting stuff to show you today thanks to a great collaboration with the Java and Safari teams at Apple between them and Sun Microsystems.

We have a prototype to show you. This is only a prototype. Let's go to the demo machine. But there's still some pretty interesting characteristics to talk about. All right. So this is Leprechaun. This is actually not even Snow Leopard. This is Leopard and this is a 32-bit Safari browser. So we can do something like load up a little clock.

Okay. Here's our clock. Not very exciting, okay? But what we can show is that scrolling works. Clipping works. Okay, so if we occlude the applet, okay, everything is working correctly as expected. Okay. One interesting point is that this is actually running in a 64-bit JVM right now, even though the browser is in 64-bit. And you get this advantage because the applets are no longer executed in the same operating system process as a web browser.

So the browser side just launches a 64-bit VM by default. So pow, instant 64-bit capability. Now, let's say that something goes drastically wrong. And I don't like to advertise this. You know, we certainly don't like to say, hey, this is really likely to happen. But on the off chance that something goes really drastically wrong with your applet, or maybe it pulled in a native code library that did something bad and the JVM crashes, okay, let's see what happens. Okay, so we can actually mimic this by simply doing.

Kill all Java. Okay, so we do that. Now, what happens? The applet disappears, and the web browser is unaffected. This is the major advantage of moving the applet execution out of the web browser. Okay, and all we have to do is reload the web page, and the applet comes back. Okay, so now we have rock-solid guaranteed reliability of Java content executing in the web browser.

Okay, now let's see what kind of advanced and really sophisticated content you can get with the new Java plugin. Okay, so this is the really fantastic WorldWinds Java software developed by NASA Ames down in Mountain View. And you've probably seen this before in some form or another. They've had this on their webpage. This is an open-source project. It's written in Java. It's pure Java, and it provides you with just amazing Earth globe that you can embed in your Java applications.

Okay? What we're showing here is the same software embedded as an applet on a webpage and showing you the integration that you can get. You know, this is really Web 3.0 kind of stuff. Okay? Now, what we have is some text from Wikipedia describing the Pacific Cascades mountain range. And the HTML links that are on this page are actually little JavaScript callbacks. So let's see what happens. We can go here and click Mount Rainier, for example.

The software navigates over and shows you where that is. You can go to Mount St. Helens.

All right, this is fully portable. Okay, no longer are you constrained to one particular platform if you wanna get virtual earth capabilities in your webpage. This already works on every other major platform, and now we're proud, really proud, to be able to show you this running seamlessly and with full performance on Mac OS X.

Okay, let's take a look at another demo. A few years ago, a bunch of really crazy guys in Germany took the GPL Quake 2 source code that was on id Software's website and they ported it to Java. All right, actually, hang on. I think I need to change the video size here.

So these guys took this, like, I don't know, 60,000, 70,000 lines of C code, and they transliterated it from C to Java. And so why did they do this? Because they love Java. They wanted to see what they could do. This is using the Java OpenGL binding, just, by the way, as the NASA WorldWinds software is. So the Quake 2 thing is pure Java, okay, sitting on top of the OpenGL Java binding.

And for a long time, for several years, they've actually been able to run this by going to their web page, clicking a Java Web Start launch link, and then the game is running. It's running on your machine. There's no software installation of any kind. All you have to do is have Java on your machine, and then you click the link, and the program runs.

Now, note the user experience that we just had. We just navigated to this web page, right? I'll reload it, okay? So we just navigated to the web page. You see, like, a little spinner for a second. Now, this could be cleaner, but that's sort of in the... Oh, got to change the video mode again. Sorry. I didn't save it before I...

The model loader is a little flaky in this thing.

All right, there we go. Okay, so note again the user experience. You go to the web page and the game is running. There's no software installation of any kind. You just have to have Java and the new Java plugin on your machine, and then you go to the web page and you can get a fully hardware accelerated OpenGL game running in the web browser, all right? This is, in my opinion, the future of internet game distribution.

Web browser-based, full speed, and just go there and it runs. Now, there's one interesting thing to point out, which is that some slight adjustment of the source code was needed in order to make this thing run effectively, and I didn't do a very good job with it. I actually did that work, and basically, this game is still rendering typically when it exits, and so it's doing like OpenGL to the screen as the web browser is tearing it down. So it pretty much crashes the JVM every time it exits.

And you would never notice, because the new Java plugin allows you to say specifically, I want my applet to be completely walled off, be in a completely separate JVM instance from every other one, and that's honored, and then you just don't see any adverse side effects. So you really can embed full power desktop applications into the web browser using Java technology.

Okay, I'm late already, so let me do this last demo very quickly. This is some of the latest leading-edge content. These are some applets built using the new JavaFX technology. And you may have heard about this initiative from Sun, but we're trying to make it really much easier to develop rich graphical content using the Java platform.

So these applets are written not using Java, but JavaFX, JavaFX script, which is a declarative language that makes it much more terse to write really advanced visual effects. So here's a stopwatch, okay? It's got really nifty, whizzy effects. It's got, like, drop shadow on the main hand there. It's got, you know, drop shadows inside the numbers here. Nice gradient-based glints and stuff like this. All right. So this is very cool. And it's actually full vector graphics.

So if you scaled this thing up to full screen, you would see the same visual fidelity as you do inside the web page. Okay? Here's a... Here's another example of, this is a buddy list applet. Okay, it shows you your friends' names and their pictures and what time it is where they live and even what the weather is like, okay. A cool thing is that we can go over here and click our friend's name. We can even see where they are on the globe, all right.

So this applet, this Java FX Script applet is embedding the NASA WorldWinds Java component as a portion of the FX Script applet. This really shows a very seamless transition from your existing Java content to the new world of Java FX Script and the power that this brings you.

All right, so this is pretty neat. Now, let's say hypothetically speaking that we think that the pals thing is really, really useful. Maybe it's even got an IM chat client built in or something. You say, well, maybe we'd like this to stick around, you know, after we've exited the webpage.

You know, maybe we don't want to have the webpage around all the time that we want to be interacting with it. All right, so this is actually pretty simple. We can just come in here and take the applet and drag it out of the page onto our desktop. Pow, okay. Now we can go in here and we can quit the web browser and the applet is still running.

Okay, there's a lot of ramifications to this. Every applet, if you design it in the way, you have to opt into this capability as a developer. Okay, so don't be worried about, oh, well, you know, is anybody going to take my applet and rip it off the page? You have to opt in.

This is documented on the JDK 6 release notes. But basically, this is the new paradigm, in my opinion, for application deployments on the internet. Try before you buy. Go to the web page, try out the app. If you like it, you drag the running app with all of its state.

Out onto your desktop, that's the app installation experience. And when you close down the web browser or switch away from the web page, you get an option to, for example, create a desktop shortcut, and that allows you to relaunch without going back to the web browser later. Okay, and we are very much looking forward to collaborating with the Java team and Apple to make this a really seamless and effective user experience on the Macs that you get like a .app created for your JNLP-based applet as you drag it to the desktop.

And we think that it'll be indistinguishable. It's going to be a little bit more flexible from a native application ultimately and still give you this awesome power of being able to go from the web to the desktop completely seamlessly. So I'd like to go back to the slides, please.

Okay, so please, please get involved. Again, this is prototype software. We cannot commit to a release date at this point, although we're collectively working together as quickly as possible to get this out there on the Mac. It's already available on other platforms. So if you want, please check out the release notes. This is the website, jdk6.dev.java.net. We'll take you everywhere you need to. But if you go to the Plugin 2 sub-link, that's where you can find the information about it. And please let us know what you think.

We're on the forums all the time, so just go to forums.java.net, go to the desktop forums, then Java Plugin, and give us your feedback. So with that, I'd like to turn it back over to Mike to show you how to build really whizzy Mac OS X user interfaces in Java. Great. Thank you, Ken.

So that was an amazing demo, and I'm looking forward to working with Ken and bringing some great JavaFX apps to the Mac. But what I'd like to talk about next is what happens when you actually pull those applications onto your desktop. What are some things that you need to do to actually make the app look like it really belongs at home in Mac OS X? And so there's three major things that your app should do.

Your app should be bundled like a Mac OS X app. You should use a screen menu bar, and we'll talk a little bit about capturing application events. So on Mac OS X, when you build your Java application, what winds up in your destination directory after you're done compiling it probably looks something a lot like this. You have a bunch of jars, you've got a bunch of resources, you've got some class files, you've got a run.bat, because you're probably deploying on other platforms.

But on Mac OS X, we don't do that. We have a single unified .app that we bundle everything that your application requires inside of. And so this allows for a great end-user experience. The end-user can just take this right out of their downloads directory or from a disk image and just drop it in their applications folder. And if they don't want it anymore, they can just throw it away in the trash. Easy, breezy, beautiful, just one drag.

So how do you do that for your Java application? Well, it all starts off with your icon. You get some graphics from your graphic designer or whoever whips together your icon. You drop that into icon composer. And this may seem a little bit whimsical, but you start off with your ICNS when you get ready to deploy. And then you take that and you move it into jar bundler.

And you just drop that into a little well there. And then you take every other component that's in that destination directory of yours and you can put that into jar bundler. And take all of your jars and all of your resources and everything. And just, you know, check the little check box and click create application. And that will generate a single double-clickable Java application on your desktop. And in jar bundler, we make it really easy for you to use step two, which is using the Mac menu bar.

Just by setting the Apple Laff useScreenMenubar property, what we'll do is we'll actually hoist that menu bar out of your frame and put it up at the top of the screen, just like every other Mac application. This is not something we do by default because, for compatibility reasons, some Java applications were never thought they would ever be run on the Mac, so they might need that menu bar there.

But for anyone who's ever even looked at their Java application on the Mac, this is a property that should be very easy for you to set and doesn't have any real compatibility problems. Set it early, set it often. You can do it in your Info.plist. Jarbundler helps you do that for you. You can set it on the command line if that's how you deploy. You can set it in code. However you like it, please set it.

And so the third thing I'd like to talk about is handling your application quit events. And so what we do on Mac OS X when you instantiate the AWT is that we create an application menu for you automatically. And that application menu has a quit handler, and when you hit Command-Q, it triggers and fires off. And we will do a system exit zero and unceremoniously just terminate your application because, well, we don't really know what the proper shutdown routine is for your app.

So in order to get that knowledge, you have to tell us. If you have any sort of unsafe changes or you need to push some state out to the network or you need to do some preference saving or something like that, basically, you have to extend an com.apple.eawt application adapter.

And it's in the handle quit method that you override. That's where you can tell us, well, now is a good time to quit. You know, this is where you can start doing your shutdown routine. Or you can say now is not a good time to quit. We have unsafe changes.

We need to prompt the user for that. And you set the event set handle to false as opposed to true. So it's very easy to set up. You just implement this. You extend this adapter or you implement the application. You add the application interface. And just add that to com.apple.eawt application add application listener.

For the rest of the time, I'd like to talk about what you can do to add an extra little polish and shine to your application. Some things that you can do in a mostly platform-independent way, in many cases, really make your app pop and really amaze and delight your end users. So we've got a bunch of features to talk about, so let's start on client properties.

Client properties are the most platform-independent, very neutral way that you can actually add just a little bit of custom behavior or appearance to your application that actually has no effect on any other platform. The root jComponent object has a putClientProperty method on it that takes a string and an object key.

And you just mark your components as having, you know, like a jComponent size, and it's just ignored on all other platforms or any other look and feel. And on the Mac, when you launch your app, it just has a little extra something special. And so you can go from an app just like this that we saw in Tom's talk, which has no modifications and no custom client properties at all, to something more like this, which looks more like Safari and has nice segmented controls and a beautiful search box.

So let's dive in. So let's dive a little bit into that. So jComponent size variant allows you to specify whether you want smaller controls. We set this on buttons and sliders and a bunch of other components. We have a tech note where you can check out all of the ones that they apply to. Small components are good when you want to kind of cluster and bring controls together in sort of a subgroup.

Many controls should probably only be used very sparingly because they actually are very small. But in this case, we're going to use a little bit of a different type of control. In some cases, if you have like a palette and you need some sort of really small clustering and grouping, occasionally a mini checkbox or a mini slider might be appropriate.

Another client property which applies to buttons, we've actually had since Mac OS 10.2 in Java 1.4, and these are the three styles that we supported. But in Leopard, we added a whole bunch more. The textured button looks really good on textured-style windows, round-wrecked for kind of HTML-style layouts and views where you have your own buttons there. We even have a little purple help button as well that you often see in the little corner of system preferences.

So another modifier that you can add to the button type is the segment position. And this actually allows you to create whole bars and kind of long controls that you can toggle between, just like you can toggle between the views in the Finder or in iTunes. And so if you put your buttons into a layout manager that directly abut these components together, you actually get them to fit together in a nice, single, cohesive control. And we'll take care of automatically scaling everything for you in high DPI. And your app should look just great.

So another client property that we added to text fields was the search variant. And this was something that we know you guys have asked for quite a lot. And we've added a lot of default behavior to this automatically. When you click the little cancel icon, we clear out the text for you.

When you start typing, a little cancel icon appears. We also will add a pop-down next to the magnifying glass for you if you attach a pop-up to this in another client property as well. And in order to really capture all of the events that are going on inside this, if you want to implement sort of a live search feature like you see in iTunes, you really want to attach a little cancel icon to this. And when you click the little cancel icon, we clear out the text for you. And when you start typing, a little cancel icon appears. And when you start typing, a little cancel icon appears.

The next series of client properties I'd like to talk about are actually applied to Windows. And so you can take your window and put a little document proxy icon up at the top, just like you see in a lot of Cocoa applications, simply by setting the window document file client property to a Java.io file that actually represents the document that that window represents.

What this will do is it'll give you this little pop-up if you right-click or command-click on that, and it'll also make the icon draggable as well, just like in any other Cocoa application, because, unsurprisingly, the Java AWT is based on Cocoa. We also allow you to set the document modified bit.

If you have any sort of unsafe changes in that window, it's a little hint to the user that if you click close, you're going to get something to pop out and say, hey, you have unsafe changes, you know, please save. We also allow you to customize your window to be able to use it in a lot of different ways. We also allow you to customize the window style itself.

So if you have something kind of like a palette, we'll actually let you set the palette style on that window. And you do that with window style and give it the key of small. We also allow you to take your window, and you can implement a lot of custom effects with them. And so you can change the opacity, and you can determine whether or not the window has shadow. So if you want to do something really snazzy that would require a transparent overlay window, we allow you to do that as well now using client properties.

and finally, a feature that we added in Java 6 was window document modal sheets. And so if you use the Java Document Modality API to specify that your JDialog is document modal to a particular J frame, and you set the window document modal sheet property, we will automatically turn that into a sheet for you and animate it in and animate it out based on your set visible true, set visible false.

We don't set this automatically for you though, because in some cases, some applications, we're never expecting to be run on a Mac or have some sort of document modal behavior, automatically get rid of the window accoutrements on their JDialog. So if they never put a cancel or don't save button in their dialog, and they were depending on you to click the little check, click the close box on the window, well, sheets don't have close boxes. So unfortunately we can't set it by default, but we really wish we could.

So finally, that's sort of a conclusion of all the client properties I'd like to talk about. Next, I'd like to show you various things that we've installed inside of the UI manager. So the UI manager in Swing is sort of a common bucket of colors and properties and borders and strings and objects that are installed by the look and feel.

And so the Aqua look and feel installs the focus color, which allows you to actually get at whether the user is specified there in blue or there in graphite in the appearance preference pane. Also in the appearance preference pane, the user can also choose a very different selection color as well. And so on Mac OS X, we actually make a distinction between the text selection color, which is a very light variant, in this case, a very light orange.

And it's designed to select text on a field of black text on a field of white. So it's, you know, it's, you won't have to invert the text color. Unlike the list selection background, which we use for lists, J tables and J trees, which is actually a much darker color that's supposed to highlight the fact that something is selected. And so the selection background color is a lot darker. And then some cases will actually invert the color of the text for you automatically.

If you're implementing any sort of custom controls, you can rely on the selection background color. And then you can also use these three client properties, or you can rely on these three UI manager values to be set for you that you can take and pull out. And always, you know, check for null in case you're running under a different look and feel or on another platform where, say, focus color is not available. And so you can use these to implement your custom controls.

Another great feature that we've installed in the UI Manager is an aqua-style border. This will take the default titled border, which by default just has an etched border variant, and will actually give you the full layering, descending aqua-style grouping. So this is how you access it. It's in titled border. Aqua variant is the value that you need to pull out of the UI Manager.

And if you actually want to set it for every single title board in your entire application, you can actually tell the UI Manager, I'd like to install this titled border as the titled border border. And so that will unilaterally change it for every titled border that you have inside your application. And obviously it takes up more space. It'll affect your layout. If you're using good layout managers, that shouldn't be too much of a problem.

But another caveat of this is that you have to take the components that you put inside of those panels that you apply this border to, you have to take them and set them set visible or set opaque false. And so what that'll do is allow you to actually see this nice layering descending in. Otherwise, J panels by default are set opaque true.

Another improvised painter that we've installed as a border is the even and odd row background color, which will change automatically for you, whether you're using blue or you're using graphite. So that's sort of a brief overview of things that we've installed in the UI manager. Next, I'd like to talk about some stuff that is more custom to Mac OS X that is not necessarily as platform independent, but I think you'll agree that it's pretty cool. So we in Java 6 allow for a lot more native dock integration.

By setting a pop-up menu on your comApple E-AWT application, we allow you to specify what comes up above the items that are provided for you automatically by the system. And so this allows you to

But the most exciting thing that I think we've added in Java 6 is AppleScript support.

And so JavaScript is a new API that was added to Java 6 that allows anyone to provide a script engine implementation to run any sort of arbitrary scripting language. And at Apple, we thought, well, this is fantastic. We could expose AppleScript to Java applications, and you can tell applications like iTunes to do things.

So we fully implemented object marshalling for parameters to scripts as well as return types. And so this is how you do it. You ask for the AppleScript engine by name, and then you can do things like tell iTunes to get the current track and get the data of the first artwork of that track. And what it will return to you is an object, a Java object.

In this case, a Java AWT image that you can put inside. So you can take a copy of an image icon and put it in a label and throw it up in JFrame, and you have the full image automatically marshaled for you with zero work on your part.

So we automatically coerce images, strings, numbers, lists, and maps. In AppleScript's case, they called them description, or, and others. Thank you. So we automatically coerce them back and forth between their Java object types, and so this is an example of taking -- of getting the Apple Script Engine and actually using that to pass some parameters to the finder. In this case, you set the JavaX script function that we want to call, in this case doTrash, and we'll specify that we want an argument to go down into that script.

And so in this case, you set the script engine argv in the bindings, and then you do the call to doTrash and tells finder to, you know, take that file string and treat it like a POSIX file and toss it to the trash. So we think this is really powerful, and we think that a lot of applications will want to do this, you know, to get sort of native integration with other apps like iPhoto and iTunes and Mail and, well, just about anything that's in your dock.

So where can we find all of these properties? Well, we wrote up a tech note, 2196, that describes a lot of the swing client properties. We also have a lot of really hidden gems inside of the release notes for Java on Mac OS X v10.5 update 1 release notes. And so those were the release notes for Java 6.

And we're hoping to get more documentation about this stuff out to you very soon and get some sort of example code as opposed to just cryptic little release notes. So sort of in summary, what did we talk about today? We talked about a lot. So we've got Java tools. Use Ant to build your projects. This has great integration with Xcode and Eclipse and NetBeans and all the Java IDEs.

We have some great performance tools with Shark and Instruments. And check out Dtrace if you haven't. There's some really powerful things you can do all the way from your Java functions all the way down to the kernel syscalls. We talked a lot about 64-bit since that's very important for the conference this week. It's on by default for Snow Leopard. You should be able to get great performance effectively for free. We had Scott talk about... How SWT is moving to Cocoa and the fantastic contributions that they're making to the SWT Cocoa port.

Ken showed us a really fantastic demo of out-of-process applets and moving applets out of the browser. And then finally, I told you about some three basic things that your app needs to do once you get it onto the desktop to actually be a good Mac citizen. And then finally, we just finished up with using client properties. And UI manager values for platform-independent customization that really looks great on the Mac.

As well as some custom EWT dock integration to allow you to customize your dock icon. And finished up with AppleScript. So, in conclusion, these are some places you can go. The Java Dev mailing list is absolutely fantastic for anybody who's new to the platform. There's a lot of friendly faces there to help you get going.

With any problems you might have. And there's a lot of senior people there who come talk to us as Apple engineers. Because we hang out there, too. And we'll occasionally pipe up about something that's particularly sniggly or some sort of preferred way to do something. So, we've got a bunch of documentation and sample code.

Please do come to the labs that are on Wednesday and Thursday. Bright and early, 9 a.m. One's in the Infotech lab and the other's in Mac Lab A. They're going to be available to you. They're two different spaces, but they're both on the same floor. And with that, I'd like to invite everyone up for Q&A.