Welcome to Java in Snow Leopard. I'm Tom O'Brien, the Manager of Java Engineering at Apple and this is the only session between you and the party, but stick around until the end because I know you're going to want to hear the great things we have to tell you about Java in Snow Leopard.

If you've chosen to be in the room today you're probably already an experienced Java developer and you may have been developing your code on other platforms or deploying it to customers who run on other platforms and you're not really familiar with Mac OS X and you want to know what Snow Leopard and Mac OS X brings to you as Java developers and what it means for your customers.

Or you may have been developing in Java on Mac OS X for a while now and you really want to hear about what's new in Snow Leopard that'll give you even more power in your development process and more power for your customers' applications. You could be bringing your code to your customers in 1 of at least 3 ways.

You could be shipping double clickable applications for mathematical modeling, for graphical sequence analysis, for other custom-tailored solutions for research communities or for in-house applications. Or you might be getting your code out over the Web as an applet in the Web browser or as a Web Start application or some other kind of downloadable content for financial analysis for online communities or for great online games. Or maybe you spend your day writing server-side code, crafting thousands of lines of code to deploy on clusters of hundreds of servers processing hundreds of thousands of transactions a minute where the performance and reliability of your code is essential to your business.

No matter how you get your code out there you're probably using one of the great development tools, IDE's and other development tools for Java that run on Mac OS X and allow you to build, test, debug, package and deploy your application and get it out to your customers.

The great news for you as Java developers on Mac OS X is that you can harness the power of all of those processor cores. You can leverage the great advances you've been hearing about in 64-bit Snow Leopard from your Java code. In fact, the Java frameworks on Mac OS X were some of the first frameworks that were 64-bit enabled in Mac OS X back in Leopard, so we've been bringing you the power of the 64-bit address space and 64-bit performance for some time now, but in Snow Leopard we're making things even better. We on the Java Team have been working for over a year and a half to bring you an even better Java implementation for you and your customers, higher performance, more compatibility and more stability for your applications, and we're going to be telling you more about that today.

Here's the things we're going to be covering in this talk. First, especially for those of you who are new to the platform, we're going to give you a quick overview of how Java fits into Mac OS X and then we're going to move on to some of the new features in Snow Leopard.

We'll bring you up to date on performance advances for Java in Snow Leopard and give you some tips for getting even more performance out of your applications. We'll also give you more tips for bundling your applications to take advantage of 64-bit and enhancing them to take advantage of other features in the operating system. And we'll also give an update on the SWT/Cocoa initiative as the Eclipse Foundation moves SWT forward into the future of Mac OS X.

Let's start with our overview of Java on Mac OS X. There are 2 main things you need to know about Java on Mac OS X and the first is that Java is part of the operating system. Since the very first version of Mac OS X, Java has been bundled with the OS and ships with every copy of the operating system. This is different from some other platforms. And as Java developers it's important because you don't need to ship your own copy of the JRE along with your application because your customers already have a JRE on their system because it's built into the operating system.

As a core feature of Mac OS X it's available in all the deployment modes that you're expecting out of a Java framework. It's available for the Web browser, for Web Start applications, as double-clickable applications on the desktop and for command line and server code. But beyond just integrating into the OS and taking care of the essentials like making sure the Aqua look and feel is applied to your Java code so that it looks like the other applications on the platform.

We also let you go beyond that. For example, using things like custom Swing client properties, you can add extra polish to your user interface elements and still keep your code cross-platform so the same code runs on all platforms you deploy to but it looks especially good on Mac OS X and really looks like it's part of the operating system. You also get the power of the Mac OS X font system in addition to the built-in font support.

We give you more tools for letting you build double-clickable applications for your application so your applications can sit side by side with other apps on your customers' desktops. And even more features like dock integration, menu bar integration and AppleScript support lets your applications interact with the other applications on your customers' systems so that they really bring them what they expect out of an app on Mac OS X.

The second thing you need to know about Java on Mac OS X is that at any time in any one era there's one preferred version of Java on a version of Mac OS X. We refocused our efforts for the best compatibility and the enhancements for Java and the operating system to make it the best experience for your customers and the focus of your development.

There may be multiple versions of Java present on a particular Mac OS X version at some times but we really focus our attention on one as the preferred version that we expect the vast majority of the customer base to be running on that operating system. As advances in Java and advances in the OS move forward, this preferred version has changed with each successive version of Mac OS X. But let's take a closer look at the versions that are available on Mac OS X 10.5 Leopard.

First, there's Java 1.42, which is present solely as a legacy transition strategy for any remaining applications that you might have that depended on 1.42 but needed to move forward to newer versions of Java, and we expected it to go away as a deprecated version, we expected it to go away in the next version of the operating system. Second, we have Java 1.5, which is the preferred Java version on Leopard and is the one that we focused most of our attention on for Leopard to make it the best for you and your customers.

We also had a version of Java 1.6 which was available for Intel 64-bit but was essentially for you as developers to move forward to the new versions of Java and start testing your applications with 1.6. But, again, we were focusing on Java 1.5 on Leopard as the preferred version, as the most compatible version for the customer base. Let's see how this landscape changes as we move forward to Snow Leopard.

First, as I suggested before, Java 1.42 goes away on Snow Leopard because it was deprecated in Leopard and it's no longer present in Snow Leopard. Second, we're also removing Java 1.5 because we've been focusing our attention on making Java 6 a great high-performance VM for you on Snow Leopard and for your customers and we're making it the preferred Java version on 10.6 in Snow Leopard and we're making it available for both Intel 32 and 64-bit hardware to match the hardware supported for Snow Leopard. We think it's a great implementation and we're going to be telling you a lot more about it in a few minutes.

Here's a couple of the highlights of Java in Snow Leopard beyond that. First we've got this great Java implementation, we've got a new high-performance Java 6 virtual machine and we have new tools for you to profile and debug your applications so that you can get the best out of the power that Snow Leopard brings you and that we're bringing you through Java 6 in Snow Leopard. But there's a whole lot more and I'd like to bring up Mike Swingler who's the Lead Java Runtime Engineer to start telling you about what's new for Java in Snow Leopard.

So, today there's actually 3 very exciting things that we want to tell you today about what's in Snow Leopard that we think you're going to be real excited about. First of all is a change in how we choose the architecture for your bundled applications, which will be very important for you to take advantage of 64-bit.

Second, we're going to show you a developer preview that we have of the out of process plug-in that you actually have on your Snow Leopard disk here today. And third, we're going to show you a great tool that we've integrated from Sun called Visual VM which actually allows you to introspect inside your application and really see in-depth of what's going on and will really help you debug and analyze the performance of your app, and so we're going to show you that later today.

So let's get started. So, first of all, the JavaApplicationStub is actually the heart of a bundled Java application on Mac OS X. It's a little piece of MoCo binary that links to the Java application launching framework and it actually kicks off Java and instantiates the VM for your app.

And the policy that we've had on Snow Leopard so far has been if you go into Java Preferences and you drag, say, Java 6 up to the top or 1.5 64-bit, we're actually -- we took all bundled applications and launched them in that 64-bit VM, and when we were developing Snow Leopard and we moved 64-bit Java 6 up to the top of that list because Snow Leopard is a 64-bit OS throdugh and through, we realized that there were some applications that were actually not ready for that transition, so what we did was we actually decided to change the policy for how applications are launched and we actually already had a pre-existing model for how this should work. What we're doing now is we're taking whatever architecture you have present in your JavaApplicationStub and if it's there we'll launch you in it. If you don't have an architecture present in the stub we won't launch you in it.

And so this is actually a policy that we're even back-porting to Leopard with Java for Mac OS X Update 4. So if you need to have a specific architecture or you require a specific architecture like x86_64 you should, you know, or if you can't launch in 64-bit you should lipo out that architecture in your stub when you bundle your application.

And, also, if you prefer a particular architecture you should use the LSArchitecturePriority bit so that in the Get Info window now when you check the Open in 32-bit Mode check-box it will actually do something or it'll be checked for you by default if you set the LSArchitecturePriority to Bias i386 up to the top. So why do you want to bundle an application in the first place? Well, bundling your app gives you a lot of really native behaviors that users come to expect out of Mac OS X apps.

If you launch your Java application from a shell script and then it kicks the AWT and then a dock icon materializes after that and the user takes that dock icon and drags it to a more permanent location in their dock, it's not going to persist around for them, but if you have an actual bundle for your app, what it will do -- if it has a real CFBundleIdentifier the dock will actually be able to persist that there and reference on disk where your application is actually residing, so there's a lot of things that actually key off of having a CFBundleIdentifier associated with your bundled application.

Things like spaces and the firewall and the Run at 32-bit check-box all depend on having this identifier for your applications so that the rest of Mac OS X, the way, you know, how Apple events are sent and all of this, they know how to refer to your app. And, also, if you deploy your application with Web Start and you create a desktop shortcut we'll actually create one of these bundled apps for you automatically.

So the second thing we'd like to talk to you about today is the Java Out of Process Plug-in; this is something we've been working very hard with on Sun and last year if you came to the session you saw a great demo of it. This plug-in is really at the cutting edge of technology and is really pushing the limits of browser technology so you need to install Safari 4 on Leopard if you want to be able to use this or use the latest betas of Firefox 3.5 with the Java embedding plug-in actually disabled from Firefox.

So running Java applets in a separate process not only gives you great stability and security and keeps the 2 processes isolated so, you know, if something goes wrong in one it doesn't impact the other. But we think this really offers a great new model for whole new kinds of applications to be developed, like a sort of try-as-you-buy feature almost.

If you have an applet running in a browser -- since the applet is actually running in a separate process you can actually take the applet and pull it outside of the browser and since it's a separate process you can close the browser window or even quit the browser entirely and your applet will still keep running, and this way your applet is really not all that different from an application.

And so the model kind of moving forward using the Out of Process Plug-in is to deploy your application or deploy your applet as a JNLP. So for right now the Out of Process Plug-in is still a developer feature but we hope to enable it fairly soon. So JNLP's are the basic building block that applets and applications and the shared libraries that they all depend on are built on.

The JNLP has a great way to describe all of the subdependencies and download all the components that you need on demand. So if you're deploying an application that actually needs to escape out of the standard Java sandbox you should also sign your JNLP's as well; this is -- when you have your JNLP hosted on your Web server you need a copy of that also inside of your jar and then you have to sign the jar and so the actual byte for byte representation of the JNLP's inside the jar and outside have to match exactly, so that's something you'd want to keep in mind if you deploy using Web Start or the Out of Process Plug-in and you need to sign your JNLP's.

So the third thing that we'd like to show you today is the visual VM tool which we think is really exciting and it does a lot of very interesting performance analysis and both take stack dumps and heap dumps and I'd like to invite Bino George on stage to show it to us.

Bino: So I've written a photoview application and my users are complaining that there's a memory leak in my application.

So, basically, what I can do -- let me try to produce a [inaudible] right now. So I can open an image by clicking on it and look at it in detail. And, basically, at the bottom of this application there's a little information bar and if I click on it I get more information about the image, so as I move around I can get more information about the image's sizes and their part and everything else, and, voila, there's my Auto Memory exception. So we know that we replace the problem and let's try to debug this in VisualVM. So I'm going to quit that, go back into -- so how do you start VisualVM? So you open up the terminal and you type JVisualVM.

So I'm going to restart my application in Eclipse and --

Bino: Connect to -- so I'm going to connect to it from JVisualVM and one thing you notice in this list of applications, you see 3 applications here, you see the VisualVM itself because it's a Java app and then you see this unknown application that is actually Eclipse and you see my photoview.

So I've now connected to the application and since I need more space I'll close this application panel and go into the monitor window and I'm going to -- there's a lot of information here so let me just hide some of this and focus on the thing that we need to know most importantly and that's the heap. So as you -- so let's look at the heap, how it behaves as we use the application.

So if I open an image you can see that the heap goes up and as I close it it should go down ideally and it looks like it does change as I -- it does go back down so that doesn't seem to be a leak. So let's look at the information about the image and notice my heap is growing, so there's something funny going on there, and suddenly I hit my Auto Memory exception.

So let's take a heap dump; this is something very useful in VisualVM and --

Bino: So once it comes up you can see the list of -- there's a list of objects and you can sort it by size to find out what's the big culprit.

And notice I have a lot of byte areas here so I can double-click on it and go into detail and look at the references who is referring to these areas and I'm going to expand this out and notice it's being referred to by my code called My Image Detail and this is kind of suspicious because I didn't really expect there to be a reference from My Image Detail and it looks like the instance field is called My Image so let's see if this is really true. We'll go back in the ID and look at My Image Detail and surely enough there's an instance field here called My Image and let's see who is using this.

Bino: Find references and it looks like I have 2 instances where it's getting used. The first instance is here and it looks like I'm using the Instance Field here and I didn't really mean to use Instance Field. This should be a local variable here so I'm going to change this to a local variable.

Bino: And I'm going to change the second instance usage also here and comment this out, I don't need this. It's probably because I'm using Eclipse's Auto-Completion and it just, you know, I had this Instance Field lying around so it used it. So let's see if this fixed the problem.

We'll restart this, I'm going to close the old connection, go back in here and reconnect to it and in this case I was able to produce the problem myself but there are times when you can't reproduce the problem your customers can reproduce it but you can't, your users can produce it. And so what you can do is you can ask them to do -- they can run VisualVM themself and they can do an application snapshot and what that does is it basically packages up everything that VisualVM knows about the application and into a file.

He can then email it to you and then you can look at it in detail just like you would do -- just like I just did. So let's look at the -- let's connect to it again -- I forgot to connect to it -- and let's see if my leak is gone now. I didn't click properly.

Bino: So as I mentioned, there are more debugging features and basically being able to get snapshots from customers is very useful. So I'm going to go back to the Monitor tab and close this and let's look at the heap again as I use the application. And now as I click around I can see the heap is moving but basically the memory usage is going back down and that's a good sign. It's not growing and I don't see the leak.

So it looks like I fixed the problem. There's a lot more things that you can do with VisualVM so one of the things that you can do with VisualVM is live -- actually --

Bino: Live CPU and memory profiling and so you can actually -- VisualVM will instrument the application and at one time basically give you CPU and memory profiling.

Also, VisualVM is very extensible so you can -- there are a lot of plug-ins out there that people have written for it. For example, you can use VisualGC to find more information about garbage collectors in detail and how they behave. Also, there's more information, you know, there are plug-ins that target certain servers like GlassFish and to talk more about performance here's Pratik Solanki who works on the Java VM.

Thank you Bino. Good afternoon everyone. My name is Pratik Solanki. I work on the Hotspot Team here at Apple and today I'm going to talk to you about performance. Specifically we're going to discuss performance of Mac OS X Server and Mac OS X Client. We're going to look at how performance changes through in Leopard and Snow Leopard. I'm going to call up some of the new VM flags that we've introduced in Snow Leopard and look over some of the changes that we've made in Hotspot, so let's look at them.

First, let's take a look at Mac OS X's server. If you're a Java developer deploying your server app on our, you know, new -- on our Intel Xeon X serves and you deeply care about performance then you're likely already using Java 6, because Java 6 on Leopard gives you the best performance right now. So what can you expect when you move from Leopard to Snow Leopard? Well, we'll take a look at SPECjbb2005.

SPECjbb is a great, you know, it's a very popular benchmark for Java Business Logic Measurement and when we looked at it and looked at Leopard versus Snow Leopard we saw that on Snow Leopard you could get up to a 19% performance boost just by moving from 64-bit Java on Leopard to Snow Leopard.

So how did we get this? Well, we get this by -- well, one of the facts that we use in order to get this high performance is Large Pages. You enable Large Pages by passing -XX:+UseLargePages. We also have a Large Page Size in Bytes option which is currently not supported.

But what this does is it increases the -- it allocates memory from the kernel using a 2MB page size. The default page size, the default virtual memory page size on Mac OS X is 4KB and by passing this option you're asking Java to allocate your heap and other VM structures using a much larger 2MB page size.

And what that gives you, really, is that it results in -- a bigger page size results in fewer TLB misses and, you know, higher cache hits and for a memory band with hungry application this can be a great win. In fact, we've seen up to a 10% win using this flag on some of the benchmarks, which is great, so that's UseLargePages. Now before you go start enabling it on your, you know, Java server application there's some caveats that you've got to be aware of. Well, first of all, UseLargePages only works on K64. It only works on the 64-bit kernel.

Luckily Snow Leopard's server will actually boot into the 64-bit kernel by default on many of our Mac Pro's and Xserves but, you know, when in doubt just run uname -m on the command line and confirm that you're running the 64-bit kernel before you start, you know, passing the slide down to Java.

And another thing you've got to be aware of is it uses wired memory. What that means is that the kernel needs to find a free contiguous physical memory to satisfy your allocation request. So, you know, our Xserves can go up to like 96GB now so you need to really, you know, add a lot of memory to your machines if you want to start using this flag. By default if Java cannot allocate using Large Pages it'll fall back to a default 4K page allocation.

And if it's really important that you get the Large Page feature than you need to pass ExitOnLargePageFailure to, you know, fail fast. So that was Large Pages in Mac OS X server, now let's take a look at Mac Os X Client. Now, millions of Mac users who are running Leopard on the 64-bit-capable machines have their default Java as Java5 -- as 32-bit Java 1.5. So we tried to look at what happens to them when they move from Leopard to Snow Leopard because they'll be moving from a 32-bit Java 1.5 to a 64-bit Java 6.

And for this we took a look at a popular JVM benchmark and what we see is across the board we see a massive improvement in performance, you know, whether it be image processing or XML passing or database access or, you know, scientific applications, the performance has just improved dramatically within Leopard and Snow Leopard. In fact, even, you know, playing virtual machine's Start-Up Timer, Java's start-up time has improved. And overall we see about a 65% performance boost within Leopard and Snow Leopard.

So let's dig a little into what happened here. Well, there are 4 things that changed or 4 transitions that we have made, so to speak. You know, first of all, we went from Leopard to Snow Leopard so, you know, all of the work that the Apple engineers have put into improving the kernel, the frameworks, everything we're getting since Java sits on top of it, we're getting that. In fact, you might have heard about LLVM GC at this conference and, you know, Java is being an earlier adopter is actually being compiled with LLVM GC so that we get that benefit as well.

The second most important thing is we moved from Java 5 to Java 6. You know Java 6 is the latest VM from Sun. You know it's got a lot of performance improvements, a lot of changes and we're bringing all of those changes to you on Snow Leopard. The third important thing is we went from 32-bit to 64-bit.

The Intel 64-bit architecture actually has like double the registers and so the HotPort VM can actually create more optimal and much faster code when compiling your Java programs and give you a performance boost. And the fourth and final thing is because of this move from 32-bit to 64-bit we are actually moving from the Client VM to the Server VM. Now, we only have the Server VM available in 64-bit and the Server VM is a much more optimizing and a much -- it just applies, you know, more optimizing techniques in order to generate even much faster code for you.

So let's take a look at this Client VM and Server VM. Now, I said that the default is Server VM and Server VM is great, it's amazing for long-running server processes. But then what if you're running a graphical application, a, you know, simple GUI Java app, what happens, you know, what? Well, you don't want the server characteristics and what we have done is we have tweaked that Server VM to behave more like a Client VM so that your GUI apps launch faster and run faster.

And one of the things we did was we tweaked the compile threshold, you know, we tweaked it to be lower when -- we tweaked it to be lower out of the box and if you are running, you know, if you're not running graphical apps and you're actually running your server applications then be sure to pass -server so you disable all of those tweaks that we made for your Client apps and you get the server's server defaults.

Another important change we have done in Java 6 is we have enabled GC Ergonomics. What that means is HotSpot will now pick up Garbage Collector by default for you based on the machine that you're running Java on. So on any machine, on any Mac that has at least 2 cores and at least 2GB Ram we will switch to the Concurrent Mark and Sweep Garbage Collector.

We'll enable that by default. And we've done that because the Concurrent Mark and Sweep Garbage Collector gives you better UI responsiveness and, you know, smaller GC pass times and we think it could be great for the attractiveness of your GUI app. Again, if your server application pass -server because in that case we will enable the parallel GC because we believe that that's much better suited for the server applications.

So, you know, to summarize the performance of 64-bit Java 6 ond Snow Leopard is great, it's amazing and we would really like you guys to move your applications to 64-bit and make sure that your app can take advantage of, you know, these wonderful performance improvements. And to show you how to move your app to 64-bit, I'd like to bring back on stage Mike Swingler.

Thank you Pratik. So, to show you how your applications can take advantage of this great 64-bit performance that Pratik just showed us, I'd like to show you a couple of things that you can do with a variety of IDE's and tools and a number of profiling tools that we've made available on Mac OS X for you to actually inspect your applications and bring them up to 64-bit and actually understand their performance characteristics when you move up there. Also, I'd like to show you a number of great debugging tools that we've added into the operating system itself, and for JNI developers who will take particular interest in transitioning to 64-bit, we have a number of great things for you as well.

And also we're going to hear an update about the SWT Eclipse project and what they've done in their transition from Carbon to Cocoa in order for them to start to take advantage of 64-bit as well. So, if you're new to the platform you might be asking yourself what sort of IDE's do we have available on Mac OS X.

Well, the answer is all of the standard IDE's that you use on other platforms as well: Eclipse and Netbeans and IDEA and all that. We also have Xcode that's available if you're also writing applications that require JNI. We also have a variety of tools to help you once you have your application built as a series of JAR files in your Build Output Directory.

You can use Jar Bundler to take those and wrap them inside of a double-clickable app container. You would use Icon Composer to take art from your graphic designer and put that into Jar Bundler and create an icon for your app. And you'll probably use Property List Editor as well to modify any sort of VM options or various arguments that you need to pass after your application has already been built by Jar Bundler.

We also have VisualVM as Pratik showed earlier. And we also have a great tool that was introduced in Leopard called Instruments. Instruments allows you to see what your Java application does in a kind of holistic view of how it affects the entire performance of the machine that you're on.

So the file system access that you see inside of Instruments isn't necessarily always just file operations you do with java.IO.File opening up input and output streams, but it will actually show all of the side effects of, say, calling a security code in Java that might load a bunch of native frameworks in Mac OS X and page them all onto disk.

It will also show you your network access and even show you how the power usage of your application reflects on a portable machine that you might be running on. And, of course, Instruments is also very handy for JNI developers as it is for developers of ordinary Cocoa applications.

So if you're profiling your application you actually find that you're spending a lot of time inside of your component paint routines. One of the options that we allow you to change is the default graphics renderer for Java. And so we have 2 renderers available, the Sun 2D Renderer is t-he default because it has the most pixel-perfect cross-platform representation that you can see across platforms that the output matches almost exactly.

Quartz, on the other hand, has slightly different pixel coverage in different areas because they're fundamentally different software loops. Sun 2D Renderer in 1.6 also has radically increased in performance compared to the Sun 2D Renderer that was present in 1.5, so. But if you find that you're using things like image types that are optimized on Mac OS X like ARGB Pre or you're doing a variety of anti-aliased drawing operations you might find that the Quartz Renderer actually faster for you.

So if you benchmark your app and flipping to the Quartz Renderer is something that works well for you, this is a great thing that you should try out. The Quartz Renderer will continue to be supported for a very long time since it's the foundation of scaleable graphics printing in Mac OS X for things like, well, the print routines and for high DPI.

So another great debugging tool that we have in Mac OS X is DTrace. And so, DTrace is probably the most powerful and flexible way that you can call from the command line or using scripts to actually introspect what's going on inside of HotSpot and its interactions with libc and all of its interactions with the kernel.

And it has great support from Instruments. If you plug in your script into Instruments and output your data in such a way that Instruments can visualize it, we have the ability to take a lot of scripts that are available on the Web, a lot of them even that might have been written for Solaris will work out of the box on Mac OS X.

HotSpot has over 500 DTrace probes and you can turn them all on by passing the -XX:+ExtendedDTraceProbes to see the fullest extent of what's going on inside your application but that will have some sort of performance hit. Another option that we've added for -- another great feature that we've actually added in Snow Leopard is the ability to have POSIX thread names set in native.

While you might not think this is terribly interesting for a Java programmer what we've actually done in the VM is we actually take the name that you set on a thread in JavaLangThreadSetName and we'll push that name all the way down to the POSIX thread and so you can see that name in tools like GDB and Sample and Instruments and, God forbid, if the application actually crashes, even Crash Reporter; this will allow you to very clearly see what native thread corresponds with which Java thread in something like Crash Reporter or Sample.

The one caveat to this, of course, is that if a thread has already been named in ,ative, likely because it's owned by another sub-system like libdispatch, things like ConAppleMainThread are not going to be renamed in the AWT-AppKit thread, and so you can see that here in a sample that I took of a bundled version of SwingSet that I took with Activity Monitor. But you can see the rest of the Java threads are all prefixed with Java: and then the name of, like, the Garbage Collector thread or the AWT-EventQueue.

So another great feature that we've added to Java 6 is more understandable unsatisfied link errors. And so we found that when moving from 32-bit to 64-bit a lot of developers had a lot of problems with not necessarily JNI code that they wrote but if they depended on a third party library that contained some JNI they would get an unsatisfied link error and they would have no idea where it came from, so to show you an example of what I mean here are 2 errors that look identical on Leopard in Java 5 and Java 6 before update 4 and they don't look any different but they have radically different causes so what we've actually done in Java 6 is we take the error message that comes out of DYLD and we've actually taken that and patched that into the unsatisfied link error that's thrown in your application at runtime, so you can actually see the real reason for different kinds of unsatisfied link errors.

And so, finally, for developers of JNI we found that there was a template that we shipped with Xcode that really wasn't a very good representative example of how people would use JNI on Mac OS X. It called a native routine, it returned at 42 as an INT and didn't even touch a J object and it returned it up to Java and returned back to the command line and was actually pretty boring.

So in Snow Leopard we took the opportunity to actually redesign the entire example to be a full-swing application that talks to the Mac OS X Address Book and actually takes all of your contacts in your address book and converts all of those Foundation data structures into Java data structures and passes them back up to Java.

And so we've done that with the assistance of a new framework we've added called the Java Native Foundation Framework I'll talk a little bit about more in a moment, but if you want to check out this example for yourself in the Xcode New Project Window in Snow Leopard, you just choose Framework in Library and JNI Library's right there, hit Build and Go and you should see your full address book come up after that.

So the JavaNativeFoundation framework is actually something that we've used internally to build the Java VM framework on Mac OS X and implement Java 5 and Java 6 in Mac OS X over the course of many years. We've taken these routines and macros and classes and coalesced them together in a framework for JNI developers.

For example, JNF Cocoa Enter and Exit are wrappers that you put at the beginning and at the end of your native C functions that will actually catch NS exceptions that are thrown inside of foundation code, wrap them inside Java Exceptions and re-throw them at the boundary to Java as runtime exceptions in your code. Likewise, if you, in JNI, make a call using JNF back into the VM and that call results in a Java Exception being thrown, once it hits the JNF Boundary we'll take that, rewrap it as an NS Exception, and re-throw that in your Objective-C code.

And, of course, this all works recursively so that can get very interesting. We also include a wrapper object that you can use to take JNIGlobalRefs and put them inside of Foundation Objects and then when the Foundation Collection or whoever's retaining a reference removes the last reference and the ref count gets to 0 we actually release the JNIGlobalRef automatically for you.

And then, finally, and most powerfully, is the JNFTypeCoercer; this is a really cool piece of technology that you can configure and plug in your own types and we actually provide default implementations that will walk a non-cyclic object graph in Objective-C, for example, and walk every single object inside of it and convert it into a Java object if it has a coercer for it, and then it will return a JNIRef to you that you can pass back up to Java.

Likewise, it'll also take a Java object graph and convert that into an equivalent graph in foundation objects. And so we provide default implementations for strings, numbers, lists, maps and sets. The new JNI example actually shows how to convert ABPersons and ABRecords into an equivalent Java object as well.

So that's something that's really powerful and we think you'll be really excited to use that if you are so inclined to use JNI. So, with that I'd like to bring up Scott Kovatch who actually writes a lot of JNI for the SWT Project for Eclipse to show us some exciting new stuff that they've been working on.

OK, so, who in here, first of all, does not know what Eclipse is? Anybody, anybody, OK, so the SWT is, basically, the GUI toolkit that's part of the Eclipse Project, so when you run Eclipse you're running the SWT that shows you all of your buttons and your controls and everything in the window.

It's also the foundation for RCP apps which are, basically, applications that you build for your custom application that take advantage of all the Eclipse Project frameworks. It began many, oh, many years ago now as a 32-bit Carbon implementation and it's been maintained and it's been heavily used over the years but, you know, as you heard last year, Cocoa 64-bit is the future of Mac OS X, so if you have a Carbon application, well, you've got to do something about that.

So last year an effort to move the SWT over to Cocoa got underway from the IBM Ottawa Group and then late last summer I got involved from Adobe and contributed some work to that. And because of all this effort the Cocoa SWT in Eclipse 3.5 is now -- not only is it an officially supported platform but when you go to download Eclipse 3.5 for Mac OS X you will get the Cocoa version by default, so the Carbon version is going to be officially deprecated.

Thank you. The Carbon version is going to be considered deprecated when 3.5 ships. So that means that we'd really like you to move your code off of the Carbon version and onto Cocoa as best you can. If you find any new bugs in the Carbon 3.5, not much is going to happen with it at this point.

We really want to get people onto Cocoa so we can start flushing out any remaining problems that are there. So if you've ever moved from Carbon to Cocoa you know that, you know, thanks to the fidelity between the 2 frameworks you're not going to see a whole lot of difference unless you're looking in very specific places.

And I've written a, because of that, when you go to the Cocoa SWT you're going to wonder, well, you know, OK, what's new other than, you know, it looks like Eclipse when I run Eclipse and, you know, what's new and what's new in the Cocoa SWT? So I've written a little application that I'm calling "8 New Features in Under 8 Minutes" where I'm going to show you what's new in the Cocoa SWT.

So on the left here I've written -- OK, both -- first of all, both of these are using the 3.5 SWT and on the left I wrote these are the identical application. The application on the right has a little clock I've added but otherwise the code is identical for presenting what I want to show you in this next little session here. And on the left is the Carbon SWT and on the right is the Cocoa SWT.

So the clock is running, let's get going with Feature Number 1. So these first couple of features are in both the 3.5 SWT's and so I'm going to zip through them but they're worth knowing about because they're actually nice additions. So in Swing it is possible to set a Client Property on a window or on a J Frame and we'll set the Window Modified flag up in the Close button for the window. Well the SWT now has that as well.

It's a new API and you can set that, unset it, and if you run Eclipse 3.5 you'll notice that when you start typing in the window it takes advantage of this, so that's Feature Number 1. Feature number 2; OK, what I have here is a standard text widget and over here on the Carbon I'm going to Control-click on some text here and as you can see, well, nothing's really happening. I've got a misspelling here but Control-clicking, nothing goes on.

And because we're using Cocoa now if you do that same thing in the Cocoa SWT you see that we get the standard Context Menu in a Text Object. And, of course, I can turn on, you know, Spelling and Grammar, Check the Document. You see, oh, look there I've got a misspelling and I'm going to fix that.

Yeah, all the normal things you expect out of a Text field in Cocoa and that's Feature Number 2. That comes for free, you don't have to do anything. If you make a multi-line or a single-line Text field that's just going to work. All right, Feature Number 3; again, this is something that was in Swing that Mike added the last year.

We've now taken advantage of the Native Search Field that's available in both Carbon and Cocoa These are extra bits that you put onto an SWT Text, on a single-line Text. If you look into the Text Java Dock you'll see the bits. You can add one for the Search icon and the Cancel icon, so if we go over here, and "What Do You Want to Find?" Stuff. And I can cancel that with the X and it clears it out and, you know, if you add 2 bits to your Text Field Constructor now you've got a Search Field, so that's Feature Number 3.

OK, in Feature Number 4 here, look on the left you have; this is a Date/Time Widget and in Carbon there really wasn't like a system-provided control you could use so what they ended up doing is writing in their own custom version. And it, you know, it's not bad but it doesn't look like a -- it looks like a home-grown thing.

Well, in Cocoa now we use NSDate Time or NSDate Picker rather and, basically, you get the same behavior. But the nice part is you get all the standard behavior out of the Cocoa widget. So I can, you know, click here, move around and jump back to where I was. You know if you've ever written an NSDate Picker you know you're going to get all of those behaviors for free as well. That's Feature Number 4. OK, now we're getting into some of the interesting stuff.

In Carbon if I want to put up a File dialogue here's what I'm going to get, just, you know, plain old standard File dialogue. And I'm going to pick a file here and I'm going to get an alert saying we're going to try and delete it. Well, in Cocoa I can now add a bit to my Constructor and I get a sheet.

Pick a file and the Message Box also has -- can be created as a sheet. Anything that drives from dialogue you can add a bit that says SWT.sheet, order that in and we're going to make a sheet appear on Cocoa. That is Feature Number 5, and when did that show up? All right, now, Feature Number 6; this one's kind of sneaky and dishonest because I'm showing you work in progress. In Cocoa -- I'm sorry -- in Carbon if you want to put a Toolbar into your window it's going to be stuck into the window as a sub-view of a composite or of the shell itself.

Now if you grab a patch, which we're going to make available to you through the Eclipse Bugzilla, and you apply it to your SWT you can make a toolbar that looks this. And, basically, what we've done is we've hooked into with a separate bit, we've hooked into the standard Window Toolbar API's and, basically, you can create the equivalent of an Eclipse Toolbar and Tool Items and it'll get stuck up into the standard place for a toolbar.

Now, this is work in progress because we need to come up with new API in which we are really pushing to have happen in 3.6 because there's a lot of implications here because the toolbar is not considered part of the content of the window, so, you know, we've got to do some thinking about it. But if you really, really want this today you can do this and, you know, we'll let you know how to -- we'll have a link available for you to figure out how to get it if you want to do it right now, and that's Feature Number 6.

All right, Feature Number 7 is actually my feature but I'm going to show you changes in how we do Drag and Drop Feedback. So if you look over here on the left in Carbon I'm going to select a bunch of files and we'll start dragging things around and we'll zoom in here and you can see that we have this sort of generic-looking square.

If you do any drag in Carbon this is what you're going to get. So in Cocoa we now have normal-looking drag feedback so if you start dragging out of a tree or a table or anything like that we'll get an actual ghost of the things that you're dragging and if you drag over some place it can be dropped, you know, if you look in the Finder or if you look in Xcode you'll have the exact same looking feedback on -- now in an Eclipse or RCP app. That all comes for free.

And last of all you see I've been running these examples in Java 6 and you'll see that in Carbon it's only x86 or i386. In Cocoa I've been running this on the 64-bit SWT. And for those of you who say, well, yeah anybody can put strings into their hard-coded strings if you don't believe me, here's Activity Monitor and we'll look at SWT and see, yes, indeed, I have a 64-bit process running.

[applause] So, and I actually did it with 37 seconds to spare. So just a quick summary of what I just showed you, here's the 8 new features that I showed you. The biggest are towards the end. 64-bit support is available as a separate download. You would basically grab the 64-bit drop of Cocoa SWT. We are working to make a universal build of the SWT.

I'm hoping that can happen in the near future because that's actually very important to us at Adobe, but, you know, you can get this today. It's available at like Release Candidate 4 Status and you can go to download.eclipse.org and that'll show you all the available versions. Eclipse 3.5 ships in 2 weeks from yesterday which is June 24, and so now is the time to start thinking about how you're going to move your application to Galileo, which is the code name for Eclipse 3.5. And with that I'm going to take you back to Mike to finish up.

So SWT looks fantastic. And so just to recap briefly what we've seen today. We've seen that Java is a Core Framework of Mac OS X and it's actually built into the OS and it's something that you and your customers can count on as always being there and Apple will keep it up to date and give you the best version for your customers.

We also showed you a couple of exciting new features in Snow Leopard and the great Java 6 performance in Snow Leopard, especially if you can move your application up to 64-bit. We showed you how you can tune your application using VisualVM and Instruments and showed you a number of little tips and tricks to debugging to help get your app up to 64-bit.

And then, finally, we saw fantastic work that Scott and the SWT Team have been doing to bring their applications to Cocoa so they can take advantage of 64-bit as well. So if you want to see more information about all you've heard about today I'd actually highly encourage you to check out the Java Development Guide for Mac OS X which has been recently revised for Snow Leopard.

A lot of what we talked about today is actually contained in that document and it's actually associated with the session so you can check that out on WWDC Connect or you can -- well, it'll be published publicly once Snow Leopard is generally available. We also encourage you to subscribe to the Java Dev Mailing List on list.apple.com.

It's a place where seasoned Java developers and the members of the Java Team at Apple actually help solve technical problems that you might be having and it's fairly medium traffic so we would like to see you there. Also, please check out the Snow Leopard Developer Forums. But most importantly, if you encounter a bug, please send us your bugs at bugreport.apple.com; this is your way to communicate directly with the team. We screen your bugs every -- many times a week in order to, you know, see everything that's coming in, so if you have a feature request or if there's a problem please let us know at bugreport.apple.com.