Configure player

Close

WWDC Index does not host video files

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

URL pattern

preview

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

$id
ID of session: wwdc2005-601
$eventId
ID of event: wwdc2005
$eventContentId
ID of session without event part: 601
$eventShortId
Shortened ID of event: wwdc05
$year
Year of session: 2005
$extension
Extension of original filename: mov
$filenameAlmostEvery
Filename from "(Almost) Every..." gist: ...

WWDC05 • Session 601

Java Overview

Enterprise IT • 1:16:40

Java is used everywhere on Mac OS X, from games to desktop applications to high-powered server clusters. Learn about Java on Mac OS X and how it takes advantage of the power of the G5 processor, the flexibility of the underlying frameworks including Quartz and Cocoa, and the power of Xcode for development. We will cover the latest releases of Java and give you insight into the future of Java on Mac OS X.

Speakers: Scott Adler, Michael Powers, Mike Swingler, Scott Kovatch

Unlisted on Apple Developer site

Transcript

This transcript was generated using Whisper, it has known transcription errors. We are working on an improved version.

Good morning. Welcome to the Java Overview. I'm Scott Adler. I'm the Java Frameworks Technical Lead, 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 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 going to 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 time and say we need two weeks at the end to develop.

We need two weeks at the end to do Mac OS X specific things or we need 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. 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, you know, 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 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 going to run on the different OSs 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 going to 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 and found that they were all fixed.

Another seasoned Mac OS X developer wrote in to us and said one of his clients installed One5, 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.

So we have a lot of tests 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, 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 want to 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. You know, 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'll help us with compatibility and it'll 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 J2EE apps on -- you 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 J2EE devices. So if you're interested in that, I really strongly recommend you go to that. Scott Adler, Michael Powers, Mike Swingler, Scott Kovatch So we have a whole session, a hands-on session, for mobile development with Xcode and J2EE devices.

So if you're interested in that, I really strongly recommend you go to that. Scott Adler, Michael Powers, Mike Swingler, Scott Kovatch 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 MID-P2O.

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, mid-P, 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 thirdly, we'll show you how to develop, debug, and deploy your applications from the desktop to your mobile phone. So let me show you a little bit about what you can do with J2ME. I'm going to show you 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. So let's go ahead and start. 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, The great thing about Java is that this kind of game is completely portable. It runs not only on here on the Mac, but also runs on, you know, 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... 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.

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 MIDP2O and also Ted Jusovic, one of our DTS engineers. So there's a lot more functionality. One of the things we heard last year was we showed a MIDP1O demo, and the thing there was there's a lot of these functionalities of MIDP2O, and we want to be able to take advantage of them. So this MIDP2O 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 said 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. Swingmark 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 1.4.2 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. And 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 J2SU 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. J2SE 5.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 J2SE 5.0.

[Transcript missing]

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 going to 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 J2SE5, we want to make J2SE5 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 found a couple issues where people have not paid attention to what might be in J2SE5. 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 J2SE5 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 J2SE5. And we need to know even if it's successful, we'd like to hear that feedback.

What kinds of things you've seen in the past? What kinds of things you've seen in the past? What kind 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, J2SE5 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 J2SE5.

So another thing to keep an eye out for is J2SE 6 Mustang. We're in discussions with Sun right now. We're looking at all the features that are in there. We have, 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 J2SE 6 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 when J2SE6 comes out, we're going to have four versions of Java on Mac OS X, and you'll see how much is involved in supporting all that, and we're moving forward. Scott Adler, Michael Powers, Mike Swingler, Scott Kovatch 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 you file these issues with us.

So we've talked about some of those questions. Let's talk about some of the advantages of Java on 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. 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 DevTools 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.

So 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 CIMARC, 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 text 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 Java X 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 Java X 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 Java X 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 Java X print.

[Transcript missing]

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 LAN 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.

So, you can manage your certificates by using the keychain. And what's really important is you can manage your certificates by using the keychain. And so, if you're using a keychain, you can use the keychain application to manage your 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 and 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 in their 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.

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.

So the other reason we've heard people really like Java on 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 the look and feel. So this is something that pretty much only Apple could do, and 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.

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. And we've heard that 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 feel, 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 are 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 dock like the open document event that happens when people drag a document to the dock 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 AWT we call EAWT. And you can, 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's 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, 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 AOT, 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 a first-class application. So 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.

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, you know, because we're all Unix heads and stuff, we know that inside of 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 okay. 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 I had to do. The rest was just a Cocoa 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 runs 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 is a very good example of that. So you can go to the JNI website and you can see 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 would 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've 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, Sabetha Edit, 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.

[Transcript missing]

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.

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, NetBeans, 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 1.3.1 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 CreateJavaVM is not going to work.

And any Java app with a PowerPC JNI library, 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 CreateJavaVM, 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. 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 him 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. And 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 this 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

[Transcript missing]

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. I just looked these up this morning. 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 J2SE 5.0, 1.4, and 1.3. 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 running. 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 1.3.1. So 1.3.1 doesn't exist, but we still have J2SE 5.0 and 1.4, the C1 compilers. But, you know, we took away 1.3.1, but we're going to give you something, and that something is the C2 compiler for J2SE 5.0.

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 you can download, when you download the J2SE 5.0 download for those systems, it'll include C1 and C2, right, bundled in it. All you have to do is pass the dash server option. So the C2 compiler is available.

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.

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 plugins, 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 Now you go back over here to string. Now that red underline is... Let's see, what are we seeing here? Ah, 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 Eclipse is that it comes with something called the SWT, which is a different user interface toolkit that's built on Carbon.

[Transcript missing]

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.

So as I mentioned, Eclipse is an open source environment. Tons of plugins. Java is just the one part of what Eclipse can do. There's a lot of work going on. 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. 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. That's where this gets interesting as far as building a universal application. I had to make no changes to the Carbon APIs. I had to use Xcode to get this to happen. 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 make file 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. So you can't 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. Okay.

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 Jarbundler 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 and when it's being launched. But we also will have, we have a new universal launcher that's installed with the 2.1, Xcode 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. It 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. 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. 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, 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 seeded with Tiger, but now that Tiger's out, we should be able to seed it to everybody.

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 WWDC 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. There's sessions on Shark. These are some related to Java things. There's Oracle we've talked about and WebObjects.

And of course, after each of our sessions on Thursday and Friday morning, there will 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. This is a two-way process. 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.