Good morning. Welcome to the Java overview. I'm Scott Adler. I'm the Java Frameworks Technical Lead, and... Today we're going to tell you our secret plan for Java. Actually, most of you heard our secret plan yesterday. But we're going to talk about what you're going to learn today. One of the big questions we have is, is who's out there in the audience?

Now, how many of you out there have never done Java development on Mac OS X? Never done it. Okay. So we kind of think of you as the newbies to Java on Mac OS X. Now, how many of you have been to, like, three or four developers' conferences before? Okay, so here are seasoned Mac OS X Java developers. Well, we kind of have different things for each of you, so we're gonna talk a little bit about that.

So for all the people who are new to Mac OS X and Java, what are you going to learn? The first and most important thing is where do you start? Because you walk up to the computer, and what are you going to do when you start using Java? The next is what's available on Mac OS X? Lots of different platforms have different services available, so we're going to show you what's available on our platform. And then most importantly is when can you try it out? And that means throughout this whole week, there's going to be lots of sessions where you can actually get your hands on this stuff and be led through by other Apple engineers to actually try out all the details of Java.

Now, the other thing, hopefully one of the reasons you're here is that you're either learning Java or you're already a Java developer and you're bringing your cross-platform app to Mac OS X. Now, everyone knows Java promises write once, run anywhere, but we know that that's a little more of a promise than an actual reality. So you'll be able to learn things like what are the cross-platform issues. You're also going to learn how to manage up better. And what I mean by this is that you're going to learn what the cross-platform development issues are, and you're going to become the expert at your company on how to take your cross-platform Java stuff and learn how to tailor it for each platform. Because you know that if you just take a cross-platform jar, it's not going to look exactly right on Windows. You have to do some tweaks to make it look right, and it's not going to look exactly right on Mac OS X. So you're going to learn how to take your six months of development in time and say we need two weeks at the end to do Mac OS X specific things or we need, you know, a week at the end to do Linux things and all that. So you're going to be able to manage up those kinds of things and plan your resources. And hopefully after you've learned all this, you'll no longer be this young, new, fresh-faced person and you're going to become a little bit more of a Java expert.

Now, if you're one of these seasoned Mac OS X Java developers, sometimes we like to call the seasoned Mac OS X developers also the jaded Mac OS X developers. And if you're one of these people, you're here to find out what's new. You're also here to find out how to get the most out of Mac OS X and Java. And then, really importantly, is cool things that you don't even know about. Now, most of you didn't know about some of the stuff yesterday, and we'll talk some more about that. But there's also things in Mac OS X that if you're just using Java, you don't know about and you can take advantage of. So we're asking you to try out a new technology. Try something that you haven't tried before with Java and also make your app more Mac savvy. And this is a lot of the things if you went to Scott's talk yesterday, he talked about all the things to do to make your app Mac savvy. We're hoping you can do the same thing in Java. And hopefully after doing all this, you'll again no longer be jaded and you'll be excited to work on Java and Mac OS X. So now for everybody, what things are you going to learn? Obviously, you're going to learn technologies to make your applications better. That's the key. That's what we're here for.

The other is how to get your questions answered by the Java engineering team. Now, there are lots of Java engineers from Apple here. So hopefully you can figure out where to go, how to get your questions answered, specifically Java questions, Java, JNI, all those kinds of things. All right.

And then of course, we have all these hands-on sessions this year. So we want to teach you how to get the best experience out of those hands-on sessions. How to go and be prepared for your hands-on sessions so that you actually can follow along instead of just watching. Because in the past, our demos were always, watch, here's what I do. And then you go home and you're like, someone clicked on something and did something and I don't remember where that is. But if you're following along on your PowerBook, you'll be able to get a great experience and say, I made my app do this as opposed to I saw someone else do it.

So let's take a step back now, and what we want to do is, we want to do what we call slaying our old dragons. Now, Java has a lot of history and a lot of reputation behind it, and we want to address some of that history and reputation. So what are our old dragons? Well, our big old dragons are the questions you see up here.

Is it compatible? You're mostly writing in Java because you're bringing-- you want to write for a cross-platform environment. And actually, I liked one of the things I saw before where it's actually cross OS, because you could have multiple OSs on the same platform. So you're trying to write cross OS.

And is your cross-OS application gonna run on the different OSes, and is Mac OS X Java compatible? Well, we'll address that. The other question is, is it fast enough? And then, of course, the question we've been hearing a lot about is, where's the latest JDK? And finally, is Apple actively supporting Java? Now, I'm gonna address these first three questions, and I think you'll be able to figure out for yourself the answer to the last one.

So first, compatibility. So the biggest thing with compatibility is will your cross-platform application work? Now, one of the things we do is you file bugs with us and we fix those bugs. So for compatibility reasons, we went back and just looked at all the bugs we fixed since Panther. And the Java team alone has fixed over 2,000 bugs in Java components since Panther. So if you think about that, that's since our last OS release, over 2,000 bugs that we fixed, a lot of them are your bugs that you filed on your applications for cross-platform. So that's a lot of bugs that we've dealt with in compatibility. But don't just take our word for it.

We released Mac OS X Panther. We've had a lot of good feedback, and I wanted to share a little bit of it. On this one website, seagal.org, he keeps track of his own personal bugs, all in a nice table so you can track it. And his quote here was, many and possibly all these bugs appear to be fixed in Java 1.4 on Tiger. That's the kind of feedback we love to hear. Some of them we addressed directly through his bug report, some were through other bug reports, but he just ran through and tested a bunch of them, found that they were all fixed.

Another seasoned Mac OS X developer wrote in to us and said one of his clients installed One 5, installed one of their really graphics-intensive apps, and exactly what he expected happened. It worked great, happiness all around. So this is the kind of feedback we really like to see. It means we're doing our job on getting versions, compatible versions out for people.

So when we talk about compatibility, there are some subtleties that are really important to us. We pass what is called the Java compatibility kit. And this is a test suite from Sun that you have to pass in order to ship and call yourself Java, call yourself J2SE. So we pass this Java compatibility kit. But we know that this is not enough to be compatible. So what we take care of and we look at are what are called the unwritten specs. And what these are are things that have existed in Java for so long that if you don't support these, applications just won't work. And the problem is they're unwritten. So a lot of times there's applications that have been out there for five years, websites that use applets that depend on certain functionality of Java that we have to support. So we call these the unwritten specs. And what we do is we build regression tests for these what we like to call unwritten specs, and so that we're constantly testing them. We use a tool called JUnit, and how many out there have heard of JUnit before? Okay, that's great. So we use JUnit and we have automated tests that run on every single internal build and external build of Java. Now the one reason I wanna mention this is that if you build JUnit tests and you file them with your bugs, there's a strong possibility that we'll take those JUnit tests Because as you know, many JUnit tests can run automatically and have pass or fail right at the end. So those are the kind of tests we love, because there's not a description saying, if the button turns the correct color, it works. We know that your test will either pass or fail. Then those tests can go right into our nightly tests. And then your bug hopefully will never show up again. Or if it does, we'll catch it, and an email will go out to the Java team, and we'll file a regression bug without you having to wait for a developer preview and send it back. So I strongly encourage you to file JUnit tests with your bug reports as you do them. It will help us with compatibility and it will benefit you because your bugs will be automatically tested by us.

So compatibility beyond the desktop. What does that mean to us? Well, the two obvious things. There's Java Enterprise Edition. So you can use Mac OS X for development and deployment of your J2EE apps. And I strongly encourage you to go to the WebObjects and J2EE deployment workshop. And then Java 2 Micro Edition. Now this is the fastest growing area of Java. And doing mobile development, developing your J2ME apps on-- basically don't develop them on your phone, so you develop them on a platform and Mac OS X has tools to do that, and then deploy them to your phone. So we have a whole session, a hands-on session for mobile development with Xcode and J2ME devices. So if you're interested in that, I really strongly recommend you go to that session. But to give you a little brief teaser for that session, I'd like to bring up Michael Powers from Empower Player to demo a little bit about MIDP2O.

Hi. Let me ask you, how many of you are working with J2ME on the Mac? Anyone? Great. For the rest of you, I want to change that. I want to kind of evangelize you on the benefits of doing micro Java development. Let me talk a little bit about me. I'm Michael Powers. I'm a CTO of Empower Player. My company makes solutions for consumers to try, find, and buy mobile applications, but more importantly, we have a developer kit that will allow you on the Mac to develop J2ME applications. So in our workshop, we're going to talk about a few things, one of which is what it's all about, J2ME, MIDP, kind of give you a primer on what the landscape looks like. And then secondly, why do you care? Why should you be here? And the answer is really simple. You can make a lot of money doing it. And from the desktop to your mobile phone. So let me show you a little bit about what you can do with J2ME. I'm gonna show you our-- my company's web-startable showcase for mobile applications, and you can see that you can make pretty compelling content with the tools that are available to you on-- with J2ME and doing it on Mac OS X. This is a game written completely in Java, completely for mobile, and it's a quality title. It's from Gameloft. It's Tom Clancy's Splinter Cell Chaos Theory. That's a mouthful.

And anyone in this room can write a game of this complexity. And the neat thing, is that this kind of game is completely portable. It runs not only on here on the Mac, but also runs on Motorola, Nokia, Sony Ericsson, all these platforms, all through the power of Java. And here you see it running on the Mac.

And here is the same game running-- let me pull this up just a minute. That's me. And this is the game. You just saw loading. It's the same bytecode. We just transferred it over Bluetooth to the phone. And there it is. You guys can do this, and I want to show you how. So come to our session, and we'll tell you all about it. Thanks. Thank you.

Great. So as you can see, there's actually really rich things you can do on phones these days. Michael will tell you all about some of the details of MID-P2O and also Ted Jucevic, one of our DTS engineers. So there's a lot more functionality. One of the things we heard last year was we showed a MID-P1O demo. And the thing there was there's a lot of these functionalities of MID-P2O, and we want to be able to take advantage of them. So this MID-P2O specification lets you do a lot more things with networking, with sound, and some other details.

So let's go back to compatibility. We talked about different editions of Java, but with the Java standard edition, there's a lot of extensions that people like to use. And so one of the things we do is we bundle the extensions for compatibility. So we bundled Java Advanced Imaging and Java 3D right into Mac OS X Tiger. So you don't have to get an extra download. You don't have to do anything other than just use the extensions. They're there for you.

We also have had Web Start since the beginning of Mac OS X. Web Start, if you don't know about it-- how many people have written a Web Start app? Okay, so many of you know about it. If you don't know about it, it's a great way to deliver desktop-style applications through the web. And so you can do things like auto-updating of your application and lots of things that people would do hosting an application on a server, but you actually can download it right through your web browser, and then you have the experience of a double-clickable application. Of course, applet support, that's one of the biggest uses of Java on Mac OS X for consumers. And then we've had live connect for a while now with all of our WebKit and using our Java Cocoa plugin.

So let's move on to performance. Now, the question is, is it fast enough? Well, if you saw Bertrand's talk, obviously nothing is fast enough. We always want to get faster. But with Mac OS X Tiger, this is the fastest Java version we've ever shipped. We have a quote from the Australian Department of Defense, and we really like this quote because they were talking about their cluster of XSERVs, and they just took this cluster of XSERVs and installed Tiger on it.

And just from doing that, and they have this big Java clustering application, they got-- they say they're expected to deliver performance improvements. The reason they bought Tiger was for the Java improvements. So we really like the fact that they're buying it for our faster Java that's in Tiger.

So let me show you a couple numbers. What we have up here is a couple of benchmarks. Swing mark you might know. Line drawing is an internal benchmark we use. Image and graphics are things pulled out of CaffeineMark that we pay close attention to. And then Unicode text is another benchmark that we use internally.

Now, Panther numbers, what you'll see here in purple, we just normalized them all to 100%, just so you can see improvement over time. Otherwise, these numbers wouldn't show up well on this graph. So you can see with 142 on Tiger, we made some significant improvements in all these areas. And with J2SE 5.0, we made some improvements, all improvements over Panther. Some were better, some were a little worse. J2SE 5.0 has a little different performance characteristics, and so we're doing pretty well here. And the one over here we don't have any numbers for, and that's because they actually don't fit on the chart. We made some significant improvements in Unicode text performance, so if you have a Japanese application or Hebrew application, they'll be a lot faster with what we have in Tiger.

So now up to date. This is the question we've been hearing for a long time. Where is the latest JDK? Well, obviously, you all know about Mac OS X Tiger. And hopefully, every single person in this room knows that we shipped J2SE 5.0 for Mac OS X. Now, a year ago, I was up here at the Java State of the Union. And I told you that we were going to be shipping J2SE 5.0 on Tiger. And-- We didn't make any commitment to ship it on the CD or when on Tiger or anything like that. We made a commitment that it would ship on Tiger at some point.

We're very careful in what we say at these conferences because we like to keep our word. Well, we kept our word, and we kept our word the best we possibly could, is that we shipped them on the exact same day. So you can get the download of J2SU 5.0 on the exact same day. When you got those CDs in your hand, 5.0 is available for you. So that was a big deal for us to make sure that you didn't have to wait for 5.0. We put a lot of effort into Mac OS X Tiger 1.4. We didn't just take what we had and let it sit there. We wanted to make sure that all of those applets and applications that depend on 1.4 were as fast as possible, and we fixed those compatibility bugs that we knew we needed to address. So we didn't just let 1.4 sit there. We worked hard on it, and we also worked hard on getting J2SE 5.0 out. So this was a big priority for us and we're really happy that we could fulfill our commitment that we made last year.

So what's in Tiger? Java 1.3.1 is there, and we'll talk a little bit more about that. Java 1.4-- and the point here is that 1.4 is still the default VM on Tiger. It's what ships on the DVD. It's what most users are going to use. It's what most of your applications have probably been qualified with. J2SE5.0 is a download right now for Tiger, and it's not the default yet, and that "yet" is pretty important. So let's talk a little bit about J2SE5.

So with J2SE5, we've decided to give control to you, obviously. And you guys have always had some control in what version you can run. But we've also decided to give users some control. Now, the reason here is that things like applets, the users have to control that. There can only be one JVM running inside of a browser. So if you had different applets that were requiring different VMs, you'd have this whichever one loaded first decided, and that would be really confusing to end users. They go, sometimes my Yahoo games work, sometimes they don't. And it happened that they went to some other site that used J2SE5 and that loaded first. So we wanted to give users control. So there's a Java preferences application. This is similar to what you might see on Windows, but we've cleaned it up a lot to make it more of a Mac app. And it's inside of applications, utilities, you can see the whole path here, J2SE50 folder, it's called Java preferences and it lets users decide which VM they're going to use for applets. And that's separate from which VM they want to use for applications. Now, for applets we call it user controlled. They set this combo box, it says which choice they want, 1.4, J2SE 5.0, that's what they're using for their applets. It's very straightforward.

For applications, it's a little more tricky because we're giving you control, but we're letting the users influence it. And what that means is we're letting users decide which is their top VM. So by default, all these users are going to have 1.4 as sort of the top-level VM, and J2SE 5.0 will be available if they've downloaded it. And what that means is if your application has said things like, I will work with whatever the top VM on the system is, using the plus signature in the VM version, you'll get whatever the user has set as the top VM. Now, if you require a specific VM, if you have strong requirements that say, I have to run with 1.4 or I have to run with 1.5, then you can specify that in your VM version. But we recommend that you don't. We recommend that you try to be as flexible as possible, because some Some users may not have J2SE 5.0 yet and some users, in the future, there may be a system that has different VM versions that you're not prepared for. So we really, really hope that you can be flexible and there's lots of ways to test what VM version you're running. You can do things like disable features in your application if you're not running with the correct VM. You can use things like reflection so that if new functionality is available, you can have code that will work with that. And of course we recommend that you have things like fallbacks if a new feature is not present.

So the future. A lot of this conference has been about what you have in Tiger and what you have in the Apple development kit. We're gonna talk a little bit about the future on what things to keep an eye out for in Java. The things in 1.4.2 Tiger Update, the things we really want to do with 1.4.2 is we want to keep up with the 1.4.2 underbar bug fix updates and any security bulletins that come out for 1.4.2. Security is important to us, so we want to make sure we don't have any security holes that are found by Sun.

With J2SE 5, we want to make J2SE 5 available as a software update so that your end users will be able to get it through software update automatically. And we want to make it the default VM. Now, these two we really consider fairly intertwined. We want to make it the default VM, but we need your feedback on your applications. Some of your applications have been developed using a version string that says, I can run with any version of Java that's out there, the highest one in the system. And we've found a couple issues where people have not paid attention to what might be in J2SU 5.0. Either it's because you haven't downloaded it, you didn't have access to it at the time. So we want to make sure that your applications will work correctly with J2SU 5.0 before we make it the default VM. And so we need your feedback because we don't have everybody's application. We need to know what issues you might have with J2SU 5.0. And we need to know, even if it's successful, we'd like to hear that feedback. what kinds of things you've seen when deploying any other issues, because we want to make the switch so that when we install this onto a user system, J2SE 5 now becomes the default. And of course, keeping up to date with the underbar releases is a priority of ours, and security bulletins also with J2SE 5.

So another thing to keep an eye out for is J2SE6 Mustang. We're in discussions with Sun right now. We're looking at all the features that are in there. Obviously, we've been working on some other things related to the Intel box, but we're looking at what we need to do to get J2SE6 out there as soon as possible for you.

So I said I was going to talk about Java 1.3. How many of you were at the State of the Union last year? Okay, so last year I got up here and said, Java 1.3 will be going away. Not in Tiger, but it will be going away. Well, I'm saying the same thing again. It will be going away. This time I can tell you that it will be going away in the next major OS release of Mac OS X. There's also another caveat to that, but we'll get that later. But move to 1.4 and above now.

If you have a blocking issue that's keeping you from moving from 1.3 to 1.4 or 1.5, We need to know about this. We highlight these bugs. We pay attention to them because we-- when J2SE6 comes out, we're gonna have four versions of Mac-- of Java on Mac OS X, and you'll see how much is involved in supporting all that, and we're moving forward. So 1.3 has been a legacy compatibility release. It's going to go away. So I just wanted to say you've been warned again. So if you have issues, please make sure these issues with us.

So we've talked about some of those questions. Let's talk about some of the advantages of Java Mac OS X. So the first thing that we like to talk about is that it's bundled with the OS. We have a huge advantage in this in that Java has been on every single version of Mac OS X that we've shipped since its inception. So there's no extra downloads to get the basic functionality of Java in there. You can-- applets just work. And then we also consistently update our Java, so we're shipping new versions, new updates. If you've paid attention to what we've done in the past, We've shipped updates out of cycle from the main OS. So we had Panther had 1.4.1, and then we shipped 1.4.2 as an update. We even shipped a performance update on top of that. So we're constantly trying to improve Java, fix the issues that you've seen before with compatibility and performance and stability.

The other big thing is that we include tools. All of the SDK is included with Mac OS X, so there's no separate JRE, JDK deployment thing. You get the development tools with Mac OS X, and then when you install the dev tools packages, you get all the extra documentation. That's another thing we have is we have really good documentation available on Mac OS X for Java.

So another big advantage of Mac OS X is that we run on the G5 processor. Now, we'll talk more about the other architectures we run on, but G5 has been an important thing for us, and partly it's because you're writing bytecodes, and your bytecodes can automatically be taken advantage of-- we can automatically take advantage of the processor underneath without having to change any of your bytecodes.

So if we look at things like, this is a SIMAR composite index we did a while ago, and we just took a dual 1.25 gigahertz G4, and we measured it, and it was, the numbers here is about 98, and we just simulated it up to 2.5 gigahertz, said what if the whole machine was twice as fast, everything, and this means like memory is twice as fast, everything is twice as fast. We get a number of 196.

Well then we compared it to a G5 dual 2.5 and we got almost 300. I mean this is like 43% improvement and this is more than twice as fast of a half speed machine. And what's the reason for this? Well the reason for it is that we're using 64 bit registers, we're using 64 bit instructions wherever we can.

That means we do this free for you. So if you look here, we've got a long edition. This is a pretty simple operation. I wanted to stick with something pretty simple. You've got two longs you're adding together. Longs are 64 bits in Java. You know, it's fixed. It's not like any other thing. So G4 instructions. These would be your G4 instructions. The first two, it's loading one long into two registers. Second two, doing the same thing. Then it's adding the high and the low, and then you're done.

Well, on a G5, it's four instructions. It's pretty obvious that four instructions versus seven instructions, the four is going to be a lot faster. So with things like CYMARC, things like any compute-intensive, things that use double and longs, you're going to have a huge advantage on G5 without any recompilation. No if-defs. Obviously, Java doesn't have that. So you just get that for free.

So the other big advantage we have is that we're built on top of all the Mac OS X frameworks. I wanted to go through each of these a little bit because there's huge advantages to each of them. So the first one is AWT. Now, AWT, as you all know, is the windowing toolkit. It's built on top of Cocoa. And the one thing that we get, one of the many things we get, is services available right inside of things like text fields. So this animation is showing you that right inside of a little text editor, you can do things like spelling and dictionary without having to do any lines of code. So you just, you know, you have an AWT text field. Your user control clicks on something, and they get that pop-up that's in every Cocoa text component. You also get all the other things of Cocoa. You get the, you know, the Aqua look and feel for free. You get all the windowing appearances and things like that in all of our AWT widgets.

With Java 2D, we build this on top of Quartz, Quartz which is our whole 2D rendering layer. So all of your Java 2D, which is a really nice object-oriented development for doing graphics, you can do your lines, your transformations, all of your compositing. It all works directly with Quartz. So not only do you get these great compositions, you also get our really good tech system under the covers. And this is how we got some of that advanced speed using double byte text is that we were using the text system underneath us and used it in a way that gave us a lot more performance. But you get this great text. You can take advantage of all the multi-directional or bi-directional text that's in there that Quartz supports.

With accessibility, when you use the Java Accessibility APIs, we wire these directly into the Mac OS X Accessibility APIs. So things like VoiceOver should work just right with your Java Accessibility APIs. You don't have to write anything custom for Mac OS X. So if you're supporting accessibility, and if you saw in the talk earlier, you know, there's some places that won't actually buy your applications unless accessibility works. If you just support the Java Accessibility APIs, we'll pick them up automatically.

And then with printing, with things like Java AWT printing and also JavaX printing, we build this right on top of our print services. So with Java AWT printing, you get all of the native print services, including our native print dialogues, being able to print right to a PDF, and all the things that users expect. And then in J2SU 5.0, we support JavaX print, and that's built right on top of CUPS printing, and you can get to all the details of the printers inside of using JavaX print. And so we wanted to show a little quick demo of this. I want to bring up Mike Swingler from the Java Classes team, show you a demo of JavaX Print.

Hi. Thanks, Scott. I whipped up a quick little demo of a Java Print Service Browser that uses the JavaX APIs. This is a brand-new feature in J2SE 5.0. And one of the interesting things as a side effect of being wired directly into the CUPS printing system is that it finds all shared printers on your network automatically that are shared through other machines on CUPS. And because we're also leveraging CUPS, we also get a lot of functionality from printing to various document flavor types, such as if you have a PDF as a file, you can grab that as just a raw Java I/O input stream and create a job around that and submit it directly to the JavaX print API, and it knows how to print it. If you have something like a PostScript that you load from a byte array or something, and you can do search and replace, you know, for little sentinel values to customize a prefab PostScript file that you might have. Or even if you have something as basic as a JPEG or a bitmap, you can load that out of a Javanet URL that you get from a jar. So if you cook in, you know, a bitmap or an icon or a JPEG into a jar, you can just load that directly.

And so the other aspects of JavaX print that you can access are the printer attributes that show you things like if the printer is currently accepting jobs, if there's color support on this particular printer. It also will show you some of the features of a job that you can construct, such as the actual printable area on the size of the page. So if you want to print to only very large format printers, for banners and whatnot, you don't even have to advertise the printers to your users that don't even support that capability. And there is just a whole plethora of options and APIs in JavaX Print that we hope you'll take a look at and we'll hope you enjoy.

So thanks, Mike. So one of the things that I hope you get out of Mike's demo program he wrote was that it's really easy to get to all this information. The reason Java X print exists is so that you can get to some of the details. And we've implemented it right on top of Cups. So if you're doing any complex printing application-- Mike wrote this in just a couple days. Between all the stuff we were doing with developing Java stuff for the Intel platform, we asked him to write a demo on Java X print. And he just jumped in and did it in a couple days. And it's not that hard to get all this information out.

So let's continue on. So all of the utility frameworks in Java are built on top of our core frameworks. So things ranging from networking, which is built right on top of our core networking services, which gives us all the IPv6 support just right out of the box, our keychain integration and security are all built right on top of these core frameworks. And I wanted to talk a little more in depth about this, because security is very important for us. So I wanted to talk a little bit about some of our security features.

The first one is keychain integration. And what does keychain integration really mean to you? Well, it means that as a Java application, if you're using certificates, there's just going to be one place to store your certificates that's the same as all the other native applications. And what this means is you're not this special Java thing that has certificates over in the Java land, and it's totally separate. It means your certificates are stored with everyone else in the keychain, and you get to go -- your users can use the same keychain application to manage their certificates. This is really important because our keychain application is used by anyone who's security aware. They know how to use this application. They know how to get to these certificates, manage them. So there's not a special management for Java. All of our applets and Web Start certificates are all stored in there automatically.

So the other thing is we've implemented the Apple Security Provider. And this is an implementation on top of the Java Security Provider. And what we've done is we've implemented this on top of our own native cryptography and security APIs. So it gives things like random number generation and a couple cryptographic functions built right in and exposed directly to Java. So you have our native cryptography available right to Java. And the point of this is that we have this basic version of this done that is useful and usable for basic cryptography functionality. But there's still a lot more we want to do in this area. We want to expose more. We have a large security team that works on these specific kinds of issues. And we want to leverage what they're doing. We don't want to reinvent this in Java. So we've done all the work to expose this up to Java. But we know there might be more that you want. So we really need your feedback. If you're working on any applications that need this kind of security, that need a security provider, and you have certain functionality that is maybe not yet available or you need, please tell us about it. Come to our feedback forum. Send us emails. Let us know, because we're still working in this area, and we want to make this better.

And with JGSS, this is the Java implementation of-- it's a full Kerberos implementation on Mac OS X. Now, the big thing here is that we access all the credentials in memory, so all your tickets are available in memory, and we're actually the first J2SE to fully support the MIT Kerberos. This is even before Sun has fully supported this, and there are J2SEs on other platforms. So someone who knows about Kerberos. That's great. Thanks. So this is really important to us because we want to support all these open-source efforts, and security is very important to us. So if you want to learn more about this, we have some documentation on this, and then you can come talk to us in the labs, too, and talk to some of our security engineers. Thank you, guys.

So we talked some about security and networking. And finally, there's a bunch of 3D extensions. Joggle is an open source 3D extension. Java 3D we talked about. All these are built on top of our OpenGL implementation, which is rock solid. It's used for games and lots of things internally, too. So you know that there's going to be a solid foundation for all of your 3D applications.

So here's the whole thing. We're built on top of all these frameworks. Our big job is to make sure that your Java applications take advantage of all the work that everyone else here at Apple is doing. As much as you're working on a cross-platform application, when you come to Mac OS X, we want you to have the best experience possible, so we want to leverage all the work that they've done. Thank you. So the other reason we've heard people really like Java Mac OS X is Aqua. Now, one of the big things here is that we have Aqua everywhere.

Your AWT programs we already talked about. AWT is built right on top of Cocoa, so it all will look with a native look. It'll be Aqua, everything you ever wanted. With Swing, we invested a lot into the Swing Aqua look and feel. And this is a full lightweight renderer that under the covers uses native rendering for look and feel. So this is something that pretty much only Apple could do. And this is, we made all of your swing components look almost identical to native components. When you're running a swing app, you just bring it over. Usually you bring it up and it fits in pretty well with the rest of the applications on the system. And this is really important. We've heard of some third party developers who have come into us and said, We prototype on Java all the time on Mac OS X because it's so fast for us to take -- you know, we have all these Java developers, they can write up things, and we'd rather show our clients on Mac OS X than on a Windows box because it just looks so slick on Mac OS X. So -- and we've heard that, you know, developers have gotten contracts this way because customers have said, "Really? That's a Java app running there?" Because they're only used to it running on Windows. And the key here is that it mostly just works. You bring your app over, it runs with the default look and feel, which is the Aqua look and you've got Aqua everywhere.

So another thing we provide on Mac OS X is this thing called extended AWT. And the reason we're providing this is because there's some things missing from AWT that you have to have to make your application a first-class Mac OS X application. Now, we're not trying to lock you into our platform.

We're trying to provide these so that you can actually make applications for your users that are applications that look and act the way people expect Mac OS X applications to act. Without this, you would have to have your own exit menu in your file menu somewhere. You would have all of your menus inside of your windows, all these weird things that Mac OS X users are not used to. So we provide functionality to let you activate and have access to all the items in the application menu, so things like preferences, about, and quit. We also allow access to things in the doc, like the open document event that happens when people drag a document to the doc or double click on a document that you've registered for. We also have other extensions inside of there for quit handling and some other things. So I strongly suggest you look at the extended E-A-W-T. We call it E-A-W-T. And there's tips and tricks on how to install this so that you don't have to be dependent on the package being there. So again, using things like reflection, you can have your build system. There were some stub libraries released a while ago, so that you can build this into your application, but still be cross-platform. And that's very important to us.

So in Bertrand's talk yesterday, he talked about Java for a while, which is great. And he talked about how Java is a really good object-oriented language. It's a good way to bring applications up and design things. But he said, you know, when you want to become a first-class application, you really want to turn to Cocoa. Well, we have a different view on that in that we want to give you as much as possible to get you to that first-class application.

Obviously, there are many things you can do in Cocoa, but we think there are a lot of things you can do in Java. And some of the things that I've talked about already, about using extended AWT, using the screen menu bar property that's built into the Aqua look and feel, is really important to us.

And we want your feedback on more things we can do so that your applications can become full native applications or native-looking applications because you don't want to be writing a lot of native code. Obviously, you can write native code if you want, and if you're doing things like WebStart deployments, you can have different native libraries that are bundled with an application, so you can have some native code on Windows and native code on Mac OS X, but we want to expose these as first-class Java applications, so these APIs, so you can actually be a first-class application. So there's a whole session on developing, debugging, and deploying Java applications.

The session number's right up here. You can see that on Thursday morning. And they're going to talk a little bit more about this. Thank you. Oh, it says p.m. That's wrong. It's Thursday at 9 a.m. So I think we're closed at 9 p.m. So, yeah, 9 a.m. And then the one thing I wanted to talk a little bit about was bundled applications. So bundling applications.

The reason I talk about this in the Java overview is many people are coming from other platforms, and a lot of other platforms don't have concepts of application bundles. It's something that's very important to us, To end users, applications are just a thing. It's the same as a file. We know, because we're all Unix heads and stuff, we know that inside there you can do a CD inside of the application and see what's in there. It's actually a file system. But it's an application bundle. So we want you to use the application bundle. We don't want this. We don't want a folder full of stuff with shell scripts and other stuff and all of your jar files spewed about and all that.

That's extremely messy, extremely fragile for end users. We do want something like this. All we want is you to install an application, and to end users, that's all they see. If you need a data folder, that's OK. You can do stuff like that. But really stay away from the shell scripts outside of the bundle. You want to deliver full-fledged, first-class Mac OS X applications. And there's a lot of tools to let you do this.

So I'm going to move on a little bit from that, and I want to talk a little bit about Cocoa Component. Now, this is an area where we're getting into Mac OS X specific things. And what Cocoa Component is is it's something we've made so you can embed any Cocoa NSView, so any Cocoa View, right inside of a Mac OS X application. And you can interact with that using JNI, but you don't have to. If it's a Cocoa View that knows how to deal with itself, you just put it in your application and just go. So the good thing about this is there's lots of little things in Cocoa that you might want to use, and you can just drop them right into your application. So I wanted to show you a quick demo of this. So we can go to demo one.

So what I did is I took an application that was written by one of our DTS engineers, Matt Drance, that has a very simple Cocoa component, and I just modified it a little bit. So if I launch this application, What you can see here is this is a Java frame, and it's got some controls on the top, and it's got this custom list I made over here, and this black area is a Cocoa component. And what this black area is is it's a Quartz Composer view.

So I can load any Quartz Composer thing I've built before. So if you've seen Quartz Composer, we have some demos. So here's a little demo here, And when I click on these and I load them, I also load some sound files and play them through Java Sound. So that's not done natively. That's done through the Java APIs. So this is just a Quartz Composer. So I have a couple other things. I just load different sounds. And what we're doing here is we're using Java events, the whole regular Java programming system.

And I just wrote one JNI function. Actually, Matt wrote it. And it's one JNI function that just passes the name of which Quartz Composer thing I want to load. That's all the JNI had to do. The rest was just a COCA component. And so I downloaded a bunch of things. Well, these were demos. And then I downloaded this off the web, which is-- oops, let me quit out of this guy here and relaunch my sample.

And so this is a sample I loaded off of someone's website. I can't remember who, but just takes the input from the camera and and run some effects on it. So we like to call this the aha video and stuff. And then this one just has the particle effects with the camera input right in it. So the idea here is that whatever you want to do with Cocoa, you can do right in your Java application if you want. This is all standard Java code running here. So that's our demo. So we can go back to slides. Great.

So there's a lot of things you can do with JNI and Java native integration. So what we want you to do is we want you to learn how to do this easily if you want to do it. Because there's many things people have asked us for, and there aren't good Java APIs for it necessarily. So if you want to do it yourself, you can always jump down into native code. And this can be really useful for extending your application for those little edge cases that we haven't taken care of for you. So you might want to mix your Java code with native code.

There are other reasons why you may want native code. Sometimes you have a big C library that your Java code is just a front end for. So you want to build your Java code just to do this nice interface, and then you have the C library that does a bunch of computation or something, or some legacy Fortran library that you've compiled or something. So you want to learn how to do this. Well, we have an entire hands-on session that will show you how to do native code.

So JNI, how to do things like Java H, how to set up your native code, how to set up Xcode to do the development. It's kind of daunting the first time you do it. Once you have it set up and going, it's pretty easy. So this will take you through all the steps of starting with just a really simple project that just does one thing with native code all the way through a really complex thing, even including things like Cocoa component. So I strongly suggest you go to this one and this is 3:30 p.m., not 3:30 a.m.

So we've talked about this before, but I want to mention it again. Bonjour for Java is a functionality that we bundled into Tiger. And what this is, is this is so you don't have to do the JNI calls to do all the Bonjour support. So Bonjour is used for lots of different things. It's usually people talk about it in terms of discovering printers and things like that. It's way beyond that now. People are using it for games. They're using it for chat programs. They're using it for collaborative computing. this program SubEthaEdit we've even used internally where you can have multiple people editing the same document together and you just can discover people right in your local network. So the point of this is that we've made Bonjour available to Java. We've done all the work of exposing the APIs up to Java and we also have made it available for Windows. So if you have this cross-platform application and you want to use Bonjour, you have these APIs available. It's bundled right into Tiger. You can bundle it into your deployment on Windows because that's the way people do things on Windows. You deploy an entire JRE, so you'll have to bundle it yourself. But we have it on Tiger. It was a download available for Panther, too. So if you want to check this out, there's documentation online. The package name is comapple-dnsd, so you can do all of your dynamic lookup.

So tools. Tools is an important thing for us. You've seen why it's important for a lot of native applications. It's very important to us to have tools that you can use to build Java and also build your native code along with it. Not too many other tools out there can do this well. So if you're mixing Java and native code, Xcode is a really good platform for doing that. You can have separate targets that build Java code. You can have targets that build your C, Objective-C whatever you want underneath the covers. And as you learned, Xcode is the way to get to those universal binaries for the Intel platform. So if you're already building your JNI libraries there, it's very easy to build universal libraries right there. It also has integrated Java debugging, things like code sends, templates for building the typical things. So if you're one of those people new to Java and Mac OS X, fire up Xcode, bring up a Swing application or an applet, and you've already got Hello World there for you, and you can look at the way we've done things or change it all around, whatever you want, but it's got all the build systems set up for you. The other important thing here is external targets. Xcode does a lot of building. It can do Java C. It can--you can set it up to do things like Java H for JNI, but external targets are really important because we know a lot of you have big systems that have either a make file system or an ant build system, so you can build your external target right into Xcode and say, "This--you know, I'm gonna edit all my files here. I'm going to manage all my files here, but I'm still going to use an ant build system, or I'm still going to use a make file system. And so you could have one target that's--you know, your first target does an ant build, your next target does a JNI build, and then your last target could bundle them all together or something. And there are other features of Xcode. You can learn all about them from the Xcode sessions. There's custom executables, smart groups, lots of search functionality built right in there.

So other Mac OS X tools. We have building and deploying tools. So jar bundler is a tool we ship. So if you don't do your build using Xcode and you just have a jar file, you can bundle it into this great application bundle just using jar bundler. It takes jar files, it takes all of your resource files and pushes them right into one application bundle. Also, Ant we ship on Tiger, so you have Ant available for you. For profiling, we have all these tools like Shark and all the rest of the performance tools. And we also have graphics tools for like Quartz Debug. We have other tools like Thread Viewer, Spin Control that will let you see what's going on natively under the covers in case you're writing native code or if you just want to see what's going on with the JVM underneath your Java bytecode.

And then everyone's favorite, we have the terminal. So this means you have Java C, you have Java H, you have Emacs VI, and everything you ever wanted. If you really love the terminal, you can get to it. So you don't have to open an ID if you don't want to. This is something that's important to us that's easily available. law.

So we also have a lot of enterprise tools. We ship on Tiger Server. We ship Apache Tomcat. We ship WebObjects. We include JBoss. So you should have all the tools you need to get started with J2ED kinds of deployments. And of course, you saw the demo about J2ME. There's the third-party emulator that Michael showed you earlier. And then the big deal here is that you can use this emulator as your debugging environment and to run it and test everything out, but you still use all of our tools to develop. So you can use Xcode. You can use Shark for Java to try out your... to profile your J2ME application. So you can... If you have a performance problem in J2ME, You can try it out in that emulator using our Java tool, since his emulator is a full application written in Java. You can see what's going on inside of there. You can use our Bluetooth support that's all built into Tiger. We have great Bluetooth support. So if you want to deploy using Bluetooth, you can do it there.

And of course, third party tools. We have a full host of third party tools, including Eclipse, JDeveloper, and that means you can read the list on here. And Eclipse and JDeveloper are having sessions here at the conference. So if you're interested in Eclipse, Friday evening there's a session on Eclipse. Oracle is having a session, I think, right after this one. So if you're interested in JDeveloper, you can check those out.

So transitions. Steve talked a lot about this in his keynote, and we've been working really hard on the transitions that you've heard all about. So what do Intel-based Macs mean for Java? Now, Java was lumped together with everything else in our overviews-- Java, JavaScript, and all that stuff. So basically, we're going to tell you what works, what doesn't work, and what's new. Well, what works? You're told that everything just works.

So all of your Java 1.4.2, all your J2SE 5.0 applications work on both PowerPC and Intel. It's the same support on both of them. And that means there's separate compilers behind the scenes generating different kind of code. There's a lot of stuff we've done in the VM. Our VM team has done, and they've done an excellent job of making sure that we have parity between 1.4.2 and 5.0. So the way that we could get up there and say Java just works is because of this. Java works. Your byte codes don't have to change.

But there's that asterisk I put up there. And what is that? Well, the first thing is that 131 is not supported. The second is that if you have JNI libraries, then you're really not a straight Java app. You're actually a Java app that also runs native code, so you have all the restrictions that other JNI libraries have, I mean, that other native applications have. And then the other thing is that Rosetta applications cannot have embedded JVMs inside of them. So there are a couple things there. What that means is if your application depends on Rosetta, you can't launch a VM. You have to make a universal application to launch a JVM because it has to be running on processor-specific code.

With your JNI libraries, you've already heard how to turn those into universal libraries. When Java is running, it will be running processor-specific. So this is important for you to remember. And there's a session that's not on your list. It's a new session that is the Java Virtual Machine Exposed, which will go into detail on some more of the things we're talking about. That's Friday at 10.30. So if you're interested in more details about what's inside of our VM for Intel-based Macs, you can go to that session.

So I wanted to just show a little bit about what just works. This is the list of all the things that just work. And this should be, you know, 95% of all the applications out there. And then what we talked about was what doesn't work. So a PowerPC-based app that calls JNI Create Java VM is not going to work. And any Java app with a PowerPC JNI library is just not going to work. So please pay attention to this. Look at the tools. Figure out how to bundle these things together so that you can create universal libraries, or if you're dependent on doing Create Java VM, figuring out how to make a universal version of your application. But mostly, everything just works.

So I just wanted to run through a couple things here on Demo Machine 2. Let's see. So we've got one of the Apple development systems here, and I just wanted to pop open Safari and run a couple applets, because applets obviously are on external sites, and they... We haven't touched them at all. And so here's one that we like. That's the baby namer applet. I don't know if you've ever seen this. But this shows all the baby names over the history. So I can put in my name here. And I can see that, you know, back in the 60s and 70s when they landed on the moon, Scott was a really popular name. Not so much anymore. And then we can look up other names like, you can see Paris has become really popular now. And Paris for guys is not as popular. Things like that. So we can just look up other names. But the important thing here is that we're, you know, we didn't do anything to this.

This is just running using our JVM for, I think it's using the 1.4 VM. I didn't even check to see what was installed on here. So it works that well that I just walked up to this machine and, you know, put these links in here. I didn't really have to install anything special to get this to work. So this is a really cool thing. If any of you are pregnant or your significant others are pregnant, check out the names and stuff. So let's look at another one here. This is another applet that I really like. It's a thinking chess machine. And it was, the big thing about this is that they use all these particle systems and other stuff for chess, which you're thinking, why do they do that? Well, they're showing areas of influence with these kind of ripples going out. So if you're black and you're more influenced, the squares will be darker. And that's just kind of a cute thing. but when you move, so I'm going to move this move, because I'm told that's a great starting move. Now the computer is showing me what it's thinking against me, and it's highlighting its moves and my moves, and it's showing every time it thinks of a move, it's making it darker and darker and darker. So I can see it thinks I'm probably going to move my bishop out here, and so I can do a move here. And this is just an example of an applet that's kind of a cool applet, and we didn't have to do anything special to support them. It just works right out of the box. And let's run through one more here. So if you're really interested in chess, this is kind of a cool one to check out. So this is another applet. They also have an application. This is called Grokker. And what Grokker does is I just enter something here, a search thing, let's say Apple Intel.

And it'll use, I think, Yahoo to search the web, and then it presents all these, you know, So let's see what we can do. Switching to Intel chips, and we can zoom in here, and we can see that something's going on in San Francisco, and we can see there's some report, and then they bring up a search over here. But this is just a real simple way to view searches on the web. And again, it's pretty graphics intensive, and it just runs just fine on Intel. So, you know, this kind of emphasizes the whole point of I could have been doing this whole demo -- oh, I probably should -- here, I can prove it to you. This is-- the proof we're running right here on the Intel machine. So this is just a simple run-through of a couple things that I found. You know, I just looked these up this morning, so let me quit out of here. Let's go back to slides.

So let's talk a little bit about the Hotspot compilers on Mac OS X. On Tiger, obviously on PowerPC, we shipped J2SE50, 14, and 13. Now the C1 at the end, in case you don't know that, the compiler we ship is what's called the C1 compiler. And that's a compiler that's optimized for end users. It's optimized for double clickable applications and applets. It's made so that startup time is fast. It's what Hotspot is really all about, is that you can interpret all the stuff just to get you up and then as time permits, you can compile what you need to. But it's got certain advantages to it, but it's really defined for footprint and for startup time.

On Intel, we took all these over and we actually do not have 131. So 131 doesn't exist, but we still have J2SE50 and 14, the C1 compilers. But, you know, we took away 131, but we're going to give you something. And that something is the C2 compiler for J2SE50. So what is the C2E compiler?

So the C2 compiler is another thing that plugs into the VM. You activate it just by passing the dash server option to the VM, and it's a much more advanced compiler than C1, but it compiles a lot more and spends a lot more time doing it. So the reason here that you'd want to use it is that if you have a long-running, compute-intensive app, if you don't care so much about startup time and you just want it to compile a lot. It may take up to 10 times as long to compile some things, but the end result code will be a lot faster. And if that's important to you, if you're going to run that end result code thousands and thousands of times, then that 10 times up front doesn't matter.

So let's look a little bit at comparing C1 versus C2. This is using SCIMARC2, using composite score. And when we look at C1 versus C2 on our Mac OS X Intel, we're getting almost-- we're getting 2.3 times faster just on SCIMARC score. And that's just from the compiler. And this is our first implementation of the C2 compiler. So we've only just begun on this. Our VM team worked really hard on getting these compilers out.

They're available for download on the Apple development systems. So when you download the J2SE 5.0 download for those systems, it'll include C1 and C2 bundled in it. All you have to do is pass the dash server option. So the C2 compiler is available for you. You can try it out with your apps on the development system. And to learn more about what's in C2, please go to the Java VM session, the one that's not in your guides. So that's, again, on Friday at 10.30. So speaking of what's on Intel boxes, I'd like to bring up Scott Kovatch, who's one of our engineers on the Java Classes team, to talk a little bit about Eclipse. Thanks, Scott.

All right, let's go to demo two, please. So how many of you here have heard of Eclipse? Good. Makes that easy. So you've probably seen it. You've probably played with 3.1, and this is the 3.1 M7 release, which was recently brought out by the Eclipse Foundation, sort of an offshoot of IBM and OTI, but it's a great project that has a number of plug-ins, and we're going to focus on its Java development capabilities. But one of the things, you know, we can collapse whole classes just to make things easier to navigate through your code. We have a nice outline view over here where you can jump from method to method and look at all of your member variables. And one of the interesting things in this M7 build is what they call smart fixes. And they've added a number of new smart fixes. This is one of the more interesting ones I saw. If you do an instance of-- And then you go back over here to string. Now that red underline is, let's see, what are we seeing here? Okay.

So now I have a conditional here that will let me... I'm trying to do a downcast of my class variable into something else. One of the smart fixes is that it will say, do you want to make a local variable out of this? And what it will do is-- Focus on that red squiggle line. Ah, okay.

All right, so this is going to be stubborn. But anyway, what I'm trying to show you here is that there's a lot of productivity features in Eclipse that you can take advantage of for your Java development. And another feature of the-- of this-- of Eclipse is that it comes with something called the SWT, which is a different user interface toolkit that's built on Carbon.

And just to show you, I built one of the samples here, and we're gonna run it very quickly. And here we see an SWT application, and all these native-- all these widgets are actual Carbon controls that have been exposed to you through Java. And this is just the basic SWT application. Well, um... You know, this is all interesting. There's a lot to learn about SWT. The reason we're showing this to you in this demonstration here is that I want to show you here in the finder that this is a universal application.

And what we were able to do, because Eclipse is an open source project, is we were able to get the sources and make the modifications needed to build Eclipse Universal. So Eclipse is ready to go for an Intel-based machine. Let's jump back to the slides real quick. Thank you.

So as I mentioned, Eclipse is an open source environment. You know, tons of plugins. Java is just the one part of what Eclipse can do. There's a lot of work going on, and, you know, just about anything you can think of can be done in Eclipse. I'm not even going to attempt to cover it here. Go to www.eclipse.org, and you can find out about the project, what's going on, latest builds, all sorts of good information there. And Eclipse is pretty much a pure Java application, but it's got this SWT layer underneath that's entirely C-based with a very thin layer over the Carbon APIs. And that's where this gets interesting as far as building a universal application. I had to make no changes to the code to get this to happen. You know, it's mostly Java, so, of course, there's nothing to do there. But all I had to do to build the SWT library is make a few makefile changes where you pass dash arch i386, and that's all you need to do to get a universal JNI library. Now, Eclipse doesn't use Xcode, of course, because it builds everywhere, but it has standard make files, and it's very trivial to modify those to get a universal application. And it's our hope that we'll be able to just push these back to the Eclipse project so that you'll all be able to use these when you get your hands on an Apple development machine for Intel.

And we've got a session on Friday. Scott mentioned it again, but I'll bring it up very quickly. If you want to learn more about Eclipse and some more advanced things that you can do with it on Mac OS X, come to our session Friday at 5:00, and you'll learn all about Eclipse. Take it back to Scott. Great. Thanks.

So that's really cool that we got Eclipse. Scott just spent a couple hours with it, and I just want to repeat, he didn't change any lines of code. All he did was mess with one line in their make file. So that's really good news for any of you who have these kinds of builds. Again, SWT is a full Carbon application and was just using a make file, so they were good to go.

So just to summarize, everything just works with that asterisk. So remember if you fit in that area. One thing we didn't mention is that the application launcher that has been bundled by default in your applications using things like Xcode and Jar Bundler is a PowerPC-only application launcher. Now, we did a little trick where when we notice we're launching the application launcher in PowerPC, we kind of stop everything, relaunch it with our new universal launcher.

Now, that's a trick we can do because we know we can recognize the launcher being launched. But we also will have--we have a new universal launcher that's installed with the 2.1--Exco 2.1 tools. And so we ask you that if you're bundling your applications from now on, re-bundle them using those new tools because you'll have a real universal launcher. And your startup time might be a little bit faster. I mean, you won't have to go through this, you know, starting in Rosetta, noticing that we're in a Java application and then zipping back into Intel specific instructions.

Obviously, build universal JNI libraries. That's the biggest thing. If you're doing JNI, that's what you have to worry about. Build universal. You can learn all about that. So the other thing, Java here at Apple and elsewhere is still growing. That's one of the big things about it, is that we have more support for Java in Mac OS X Tiger than ever before. We've got six different compilers that we're supporting at the same time on Tiger. I mean, this is unprecedented for us. We have all the C1 compilers on PowerPC. We have the two C1 compilers on Intel and the C2 compiler on Intel. So we're putting a lot of support behind Java, and we hope it shows.

The community is growing. There's a Java dev mailing list. We really encourage you to sign up for this list. There's a lot of good discussion, occasionally debate on this list. So please, your questions usually can get answered within hours on this list, usually by your other developer, the developer community, and Apple engineers watch this list and will chime in when necessary. But it's usually developers helping developers. And also there's an archive of this mailing list. So I recommend if you have a question, check the archive, because most likely someone else has had a similar question.

Also, we recommend you look at ADC. Make sure you all are ADC members, obviously, but that's where we're going to put future downloads and developer previews. So if you've been paying attention to Java in the past, we're pretty aggressive about putting out developer previews, and we want to get your feedback on how well your applications work with these things and file bug reports, you know, tell us your experiences. And we're going to be posting developer previews for all of our new products when they come out, Hopefully, when they'll be up on ADC, in the past with Tiger, they've been seated with Tiger, but now that Tiger's out, we should be able to seat it to everybody. Thank you. So for more information, obviously there's the WWC 2005 site. It'll have all the links to the documentation that you need.

The hands-on labs, I can't stress this enough, but the hands-on sessions that you can go to are going to be different than anything you've ever been at WWC before. We've worked a lot on making sure that the content is something you can follow along, you can build on your machine. Like I said earlier, it's not just something where you'll sit there and watch us do things.

You'll be able to follow right along. So what can you do? Get J2SC 5.0 because we use it for some of the sessions. try out Shark for Java, download our sample code, and check out our documentation. There's a whole bunch of sessions. I don't think you'll be able to copy these down, but we're almost out of time. There's one on JNI development. There's a performance session Friday at 9:00. There's sessions on Shark. These are some related to Java things. There's Oracle we've talked about on WebObjects.

And of course, after each of our sessions on Thursday and Friday morning, there'll be labs that most of the Java engineering team will be at. So please, after those sessions, follow us over to the lab. Almost the entire Java engineering team will be there. So if you have specific questions, that's a great place to meet us, to ask us questions, to show us your applications.

and we want your feedback. So the feedback forum is also on Friday. It's a WebObjects and Java feedback forum, so please come there. Send us emails. Come to the labs. We -- this is a two-way process. We've been -- I've been talking a lot here today. We want to hear back from you. So we want to hear what things we're doing right, what things we're not doing right. It's very important to us. And who to contact? Anyone but me. No. Alan Samuel and Francois Jouaux. Francois is the manager of the Java team. Alan Samuel is our evangelist. So please send them your emails. Talk to them. That's fantastic. And of course, thank you all for coming.