Ladies and gentlemen, please welcome Vice President of Development Technologies, Ted Goldstein. Thank you very much. I'm going to talk about Java at Apple today. And Java--I'm going to is in a class by itself at Apple. It is a critical, critical important technology. You'll hear why. And I think Apple is a critically important member of the Java family companies. And we are extremely well suited for each other. People have heard me talk about this before, know that I think the two are very well married. Besides, I love apples and I love coffee.

We like to say that Apple loves Java. Apple loves Java. Great symbology and such. Java is Apple's strategic cross-platform technology. For people who need to develop applications that run on multiple platforms--at least one of two of you do need to run on something other than Macintosh--we think Java is the way to go. And Apple has made a tremendous commitment to Java to make that happen.

It is a key component of many, many enterprise solutions, including Apple's own running of its business. And we also think that Apple--and Java is extremely important to Apple itself because it has brought many applications to Mac OS X. And that in one swoop, we were able to bring in and make beautiful Acro interfaces for many, many applications. Often with no tuning at all or maybe with just a little bit of tuning, things can become letter sharp and very perfect.

And technologies and techniques that we've done are making that even better. And you're going to hear today about some of the infrastructure we've changed and improved to make Java on Mac OS X the best it can possibly be and to be a full first-class citizen with all--everything else that Apple does of Cocoa and Carbon and such.

But first, let's talk about Java and where it fits in the landscape. So when we think about programming languages and great languages of classic time, we think about things like Fortran and COBOL. These are great business processing languages, great scientific languages. And, you know, I want to actually hand it to Microsoft. They've made a language that's about as popular as COBOL and Fortran, something called C#. I think that's, you know, very thankful for Microsoft to remind us again about the bottom of the scale.

Basic and Perl far, far outstrip what's going on at that end, and that's because of the accessibility. C and C++, which are the main languages that people develop desktop applications in, dwarfs even those. But Java is the monster. Java is at 51 percent market share. It's going to take a long time for languages like C# or COBOL to catch up. And I think it's critically important to realize that, because while the Microsoft PR machine is manufacturing information about C#, Java is the winner.

Java is the winner and enjoys the mind share at universities. We hire summer interns at Apple, and almost unanimously, if they've had any programming classes at all, they've had programming classes in Java. And they are well-trained, and it helps us both to mold what they do for the technology they develop at Apple and for the languages that we develop applications in. So really, we feel very comfortable, very comfortable with Java as a fundamental mainstay of the Apple development tools story.

and David Javademand has increased. There are now 3 million Java programmers out there. Over half of the world's PCs have Java natively installed. HP and Dell have recently signed--they have copied Apple and are now shipping Java as part of the platform and are shipping Sun's latest version of Java that we are shipping.

And one of the nice things that I'm happy to say is that Sun has recommitted itself to desktop Java. For many years, you saw them putting their attention on either end--on the enterprise side and on the micro-Java, J2ME, Java in the phones and smart cards, which I'm very happy about.

But, you know, somehow there seemed to be something missing from the middle on the desktop platform. And I'm very glad to see it this year's Java 1. We saw a tremendous burst of enthusiasm, of renewed energy, of revising JSRs and such. And I think that this is extremely important. All these factors together show that Java has legs. It has long and sustained spirit to create great applications.

We use Java ourselves to run our business. So when we think about the kinds of applications that it takes to bring money into the company, right, to do the accounting services, to do the financial reconciliation, and website, Java itself is perfect as a business enterprise application. And Matt, let's begin. Switch.

Do you hear the sound? No? No? No sound? Nope. So this is -- I'll do a voiceover, then. Apple uses Java for SAP. All of our sales people use Java in its -- to book its numbers. Our website is used -- uses Java, and is based on WebObjects technology. Apple Music Store, 99 cents a click, and this is critically important.

Apple technology in every facet is devoted in many ways to create a tremendous desktop application experience to create and as well to create a tremendous server experience. And these things combined together, Java is a critical element. When we talk about and we celebrate many applications, such as iTunes and such, these are complementary technologies to provide that fabulous interactive experience, but also Java is part of that.

Java is also in the products that we sell and we develop ourselves. So, of course, we ship J2SE in Jaguar and in Panther and in Mac OS X server. .Mac is built itself using the Java technology. So the dynamic creation of the web pages uses the WebObjects application server and in many ways also hooks up to various third-party Java application servers as well. and, of course, our WebObjects platform, which runs not only on Mac OS X but on Solaris and on Windows 2000 platforms. That it itself is a portable applications environment to create applications for server-based applications. So let's also talk about applications that you've brought to Mac OS X.

Shall we switch? So here, for example, Smart Money, terrific application for monitoring. This is--what is this one? Can't see. Borland--this is JBuilder IDE. Thinkfree, terrific word processing system. What was the name of this one? Gawker, right. So Gawker is an understanding tool for Java, for understanding the Web and such. The Visual Cthaurus from Plum Design.

Many, many applications, all having tremendous visual appeal using the interactive approach. Why don't we flip back? Yeah, good. We also want to introduce a new application server on the Mac OS X platform called JBoss. This is something that you've asked us for. It allows you to deploy enterprise Java beans. It is inspired by J2E.

It has incorporated in it, as part of it, Apache's Tomcat system. One of the things we like about it is it's very good for hosting WebObjects 5.2.2 web applications, and it fits extremely well and integrated into the Apache web services. And one of the things that we like about JBoss, of course, is it is a cross-platform standard. It has that capabilities.

Our understanding is roughly about 40 percent of people who do this type of application are supporting and running JBoss, including--and about of those, 70 percent of those companies that use JBoss have deployed it. So it makes JBoss actually, I think--I believe the largest--largest of the J2E-like application servers.

For more information on JBoss, we'll be talking about that in the 605 Web Objects in J2EE session and in the 612 Enterprise App Deployment section. So great, great new technology that I think you'll enjoy using and which has a tremendous amount of appeal for our customers. Um, the thing that we'd like to say, and critically important is, Java is in every Mac OS X box. It's bundled in every system.

We're including -- in the Panther release, we've included both Java 1.3 and 1.4. There's slightly, subtly different APIs. Some applications prefer 1.3. Some will prefer 1.4. And Apple tools support Java. We're very focused on this. The new Xcode tools will be supporting Java fully in the GM release.

But, in fact, even today, it will support it with the Jam-based build system that we've had for several years. JBoss will now be included in the Mac OS X server product. So you can see that Java really is getting very rich and fully integrated into all aspects of what Apple does.

I think one of the things that Apple is very focused on is improving performance. And so J2SE technology, just-in-time compilation, is critically helpful for making things go faster to--as your application is running, the Java virtual machine is optimizing. We've put in technologies to optimize and improve for the new G5 system.

G5 is, in fact, a perfect machine, and there are hardware features designed specifically to support Java. And you'll see that some of the scientific benchmarks and floating-point benchmarks Java is terrific on. We've added in support for the new I/O, extremely fast streaming I/O into the Java application environment, and support to allow you for your applications to select between different versions.

One of the things that I think is as a Java programmer, you can actually be much more insulated from the hardware architecture, whereas if you're developing in C or C++ or Objective-C, you do have to actually know, are you running on all of G3, G4, or G5? Or you can optimize your code and select in the compiler, GCC compiler, to target specific hardware platforms. In Java, that worry goes away.

Because your application is dynamically loaded and the GCC compiler selects on the fly what it's going-- and knows what hardware it is being executed on, it can choose the best optimization technology for you. So this is one of the things that makes Java and this type of just-in-time compilation technology an extremely good match, especially when you have multiple machine architectures you're targeting.

I think one of the things that is also very interesting here is no matter where we go, when we get to G6, 7, 8, 9, 10, whatever, you'll know that your Java application is architected in such a way that it is upwardly migratable. And so the applications you create today are going to have a future role and a future life in a binary-compatible way.

One of the things that is really great about the new Java 1.4 implementation from Apple is we've made some big changes in how we've implemented Java. Previously, Java was built on a Carbon substructure and various layers. That allowed us to have some support for Mac OS 9 days, but also tremendous--and to migrate over to Mac OS X.

Much as many of you developers who develop Carbon applications, you wanted to deploy both on 9 and 10. But, of course, now that we are fully on 10, and really 9 is sort of a dot disappearing in the rearview mirror, we actually took the time to reengineer from the ground up the 1.4 environment.

So previously, with Java 1.3.1, As provided from Sun, there is 1,842 classes. From Sun we get in 1.4 almost 3,000, 2991 classes. But if you look at it, the code that Apple adds on top of it, right, in the 1.3 case we had to put in about 900 classes of code to connect it up to Carbon and the Carbon APIs and such.

In 1.4, we're hooking up to Cocoa. We've only had to add 300, much less code, and yet we have more functionality, more infrastructure that we have to bind to provided by Sun. And what's interesting here is that there's a very nice match, a very sweet marriage, if you will, between Java and the Cocoa and Objective-C environments.

Many of the people, in fact, who designed Sun's window swing system actually were original Nextians. So it's not... It's illogical that that should be true. So one of the nice things here is with less code, it then helps Apple put its attention on issues of fit and finish and performance and other things. So this is one of the things I'm really proud of in the Carbon to Cocoa transition. And with that, I want to invite up Scott Adler, the Mac OS X Classes Technical Lead. Thanks a lot, Ted.

So Ted's done a really good job of explaining why Java's important to us at Apple and some of the basic things we've done in 1.4 in our new architecture. But I want to talk a little bit about where we've come from. So we can look at a timeline here, and you can see that back here we had Mac OS X, and we shipped Java 1.3 with Mac OS X, and then 10.1 we shipped Java 1.3.1, but that's all way in the past. Then we had our 1.3.1 update that we shipped, plus a 1.3.1 version that came with Jaguar, and then recently we shipped another version of 1.3. But you can see we have fairly regular releases of our Java platform.

Now, over the past year, we shipped a year ago, a little over a year ago, we shipped a 1.4 preview that was still based off of our Carbon APIs at the WWDC. Then, from November to about February, we shipped, must have been between 10 to 20 developer previews of our 1.4.1 Java JDK. So the deal is here is we were shipping you our code as we were working on it, and we got lots of feedback from you.

We got so much feedback that we kept on adding to this and doing more developer releases, and this was a new thing for us, where we were shipping out things to you, and any ADC member could download our 1.4.1. So this was a great way to get feedback directly from you without just dumping a release on you and saying, oh, my application doesn't work.

So we took all that feedback, and then we released Java 1.4.1 in March of this year. So what we've been doing since then is we've been working on fixing all the bugs and improving performance. So what you have right now is you have a Panther preview. That has a version of 1.4.1 bundled inside of it.

And also you can download a 1.4.1 update preview. There will be eventually a 1.4.1 update, but there's a preview available for all ADC members. So you can, again, download this and then tell us what things, what issues you have. There's so many Java programs out there that our best bet is for you to try out your application and let us know if there are issues specific to you.

So what you can see with this timeline is that we have all these regular releases of Java, and we now have 1.4 and 1.3, and we still have regular releases of 1.4 going on into the future. And you can see that we have our releases with the operating system, and obviously we're going to have 1.4 and 1.3 released with Panther.

So multiple version support, we've been talking about this. If you were here a couple years ago, we had one version of Java on Mac OS X and that was one through one and that's what you got. As opposed to other platforms where you can install whatever version happens to work with your application and everyone had to install their own JREs and it gets all confusing because you then have like six different JREs on your system. So we have a version that we ship. Now we have two versions. So you have to be able to handle two versions. Well we knew we had to have backward compatibility.

Apps that worked with one through one and may have issues with the new APIs in one through one still have to work. So our double clickable applications will still work with one through one. But we also have to allow you to specify the version. So you can specify it the same way that Java Web Start does by saying what version or hire you work with or saying I'm locked into a specific version.

So that's really easy for you to do. So you can ship your apps working with whatever version that you need. And we're also gonna include both of them in Panther. Now if you have a one four app, you can be confident that your users will be able to have it because we're shipping one four through software update. Most people just automatically download it. I know my aunt downloaded it. She didn't even realize it.

So we have over a million downloads of one four one. And we're gonna keep shipping our updates to one four as software updates. And then when Panther comes along, it will be bundled right inside the OS. So you'll have both of them right side by side. One through one apps can run one four apps. Everything's happy.

So now I want to talk a little bit about the Java platform. If you were here two weeks ago at Moscone, at the old Moscone, there was Java 1 going on. And they talk all about the Java platform. And it's huge. You probably know about it. You're probably a Java developer. But the platform is pretty huge. I just want to run through really quickly the 1.3 to 1.4 differences. So we have all the OS releases that it runs on the bottom.

And then we have the actual virtual machine, or the runtime as we like to call it, which includes all the hotspot compiler. And it's small on this chart. But it's actually a big deal. There's a lot of stuff in there going on for figuring out when to compile your code. Then we have all the core APIs. This is the basic stuff in your application. This is things like all the collection classes to make it easy to do sorts, all the networking classes, utility string classes, all the basic things that Java just can handle for you.

Then you have your integration APIs, things like connecting to databases and remote method invocations. Then on top of that, the UI toolkit, which Swing and AWT are obviously the most basic things in that toolkit. And then you also have input methods for getting foreign language support, Java 2D if you just are a graphics application, accessibility support, which is definitely a big user interface issue, and sound support. Then on top of that are alternative deployment techniques, other than just jars and double-clickable applications, things like Java Web Start and the Java plugin for applets.

Now, when we went from 1.3 to 1.4, there were some new packages, brand new packages, some extensions that were bundled in, some other things that people just wanted that Sun added to 1.4. And people look at this and say, hey, that's all that's in 1.4, no big deal.

Well, actually, all of these packages have had major API changes. Swing has had brand new components, AWT has had lots of fixes, and there's just... There's all lists of API changes across the board. And then there also are all the other packages that have been touched or changed, that have bug fixes inside of and under the covers.

Especially the hotspot compiler in VM, there's lots of changes between 1.3 and 1.4, and almost none of them will... You actually have to do anything to take advantage of. There are just things that happen under the covers that make your application run better. But it's things that we implement.

So now I want to talk a little bit about Java 1.4 on Mac OS X and what the performance thinks we've changed. So first, starting at the bottom, there's the runtime improvements. So the biggest thing here is that these will directly affect all your server and scientific applications. So any runtime improvements we make, immediately, if we fix floating point, we make it work faster, your server applications will just start working faster. We have some things like aggressive inlining that's been implemented, the new I/O API that we've talked about earlier. And then, of course, the biggest thing that you get for free is support for new hardware.

Now, this morning in the keynote, you heard some talk about a developer who ported their application to work on the G5 and recompiled in something like 15, 20 minutes. Well, you don't have to do that. You guys get that for free. Your class files come over. They run through our compiler, which is now optimized for the G5. So let's just take an example.

There's a benchmark, which is the CIMARC benchmark. It's a scientific calculation benchmark. And we just looked at the composite score. And we're going to do a little bit of a test. So on a -- let's see, on a G4 1.4 gigahertz dual machine, we score 110, which leaves us somewhere in the 50 -- top 50 compilers out there.

Now, if we look at the new machine, which is a 2.0 gigahertz dual, we score now 232, which brings us into the top 10. And this is just with a couple optimizations for the G5. So we already are taking more than 100 percent improvement on this one score, just from optimizing things like our long instructions and all of the things that the G5 can take care of. So this is some great news for your applications, because you just get this. When you run on the new hardware, your apps will be that much faster.

So I really encourage you to go look at session 625. There is more info about the CIMARC composite score and all the different portions of CIMARC and what they did. They'll actually break down how they compile your byte codes into better instructions on the G5 and how you can set up your applications to better take advantage of this information. And then we'll take advantage of this if you want to, but again, it'll just automatically happen for you.

So also in the graphics area, we know we had a lot of work to do, and so we put a lot of effort into some graphics improvements. So the biggest thing is that we're faster across the board, even on Jaguar systems, this update should be faster for your applications and graphics.

We heard a lot of criticism about this, and we've tried to respond to it. We did things like our graphics system sits on top of Quartz, and the Java graphics system doesn't necessarily understand all the intricacies of Quartz. So we did things like we know more about it.

So we put in a new state management mechanism which should help all your applications be faster for basic drawing routines. We also have lots of bug fixes. So I have one benchmark I stole from the performance session, which is the Java wireframe demo, which measures basic primitive lines and maybe arcs drawing performance.

And in our 1.4.1 release, we got 20 frames per second. And then in our 1.4.1 update, we ended up with 35 frames per second. So you can see that's a pretty significant improvement. And then in our 1.4.1 update, we had a significant increase in just our update release. So you can find out more about this at the session again on Friday, the performance session.

So now in Java 1.4, there's also all the UI toolkits, and I want to talk a little bit about those. So, AWT. This is the big change we made over the past year. We changed the architecture of AWT. So, AWT is the whole toolkit that has the peer toolkit.

So, peers are these native widgets that Java relates to. So, AWT on Windows has Windows widgets. AWT on Mac OS X now uses Cocoa widgets. Now, the big deal here is it's transparent to users. They don't know whether it's Carbon or Cocoa. We don't want them to know. But what happens is the Cocoa widgets now have support for our native services.

So, the services menu just works. The speech and spelling in AWT controls, if you control-click on your AWT text field, you'll get that services menu, and you'll be able to select speech and speak those items, or see the little red dashed underlines and be able to get spelling right there, or send something to a man who's a Java developer. So, we're not going to be able to get that in the mail client because the mail has implemented something so you can say click send to mail.

The other thing is you get things like the colors and the artwork automatically. So, if you use AWT colors or system colors, those automatically are mapped to our UI system colors. So, if you change the highlight color in an application in the system preferences, it'll automatically be reflected in your application if you use the highlight color.

Plus, there are things like input methods are now supported in all of our AWT. So, that means you can get your input methods in the system. So, you can get your complex fonts and complex foreign language support, and also things like Inkwell. If you happen to have a tablet, you could use Inkwell right in your AWT text fields. Plus, we have accessibility for our AWT widgets and also for some of our swing widgets, and that means you can script everything. You have things available, accessibility can get to it, you can use it using UI scripting in Apple script.

So the swing Aqua look and feel. This has been rewritten with the architecture change to use the native Cocoa rendering. So what that means is when you draw a swing widget, instead of pulling the whole thing into Java and trying to draw it in Java, what we do is we go down into the native code and behind the scenes draw it with the same routines that Cocoa uses to draw it.

So when you ask for a swing button, it's actually drawing a Cocoa button behind the scenes and then putting a lightweight view of that thing up on the screen. So it means that your components will be more consistent with other swing apps and with other native apps. The other thing-- excuse me. Let me grab a drink.

So the other benefits you get from this is the native menu bar. You can actually use the menu bar at the top of the screen if you want. Plus, you can also get the brushed metal look and feel, if you want. You can set a property, get brushed metal, and then you can set backgrounds on windows, and they all of a sudden become translucent windows. And it's really cool. You can make--if you do a non-title window, you can make the background transparent. You just have floating swing controls, if you want. It's kind of cool.

There also are some new widgets. There's the indeterminate progress bar, the spinner, and plus we have new internationalization support. So with that, there's more info on--at session 608. They'll be talking about creating great Java applications. They'll talk about how to do all these customizations. Now I'd like to introduce Greg Bolsinga, whose title is up here.

That is-- Hi. Demo machine two, please. I've got a pure Java swing application here. This is it right here. It's using the Aqua swing look and feel, and in this particular case, I've set it to use the brushed metal look. On "Jaguar," we had some trouble with this, but with the Cocoa fixes that we got from the system, now it works, and we didn't-- I don't believe we had to do any changes to get that. So your Java swing program will look and behave as Mac OS X users expect.

What I'm going to be showing you today is how the Java accessibility has been tied into the Mac OS X accessibility, and you get all these great features for free. Mac OS X accessibility allows your program to be used by all users, people who may not be able to use a mouse or see the screen or hear or some such, but there's a lot of features that are cool for a whole lot of people as well.

So what you're going to use are pure AWT and swing components. If you have a custom component control, you'd have to integrate it with the Java accessibility APIs, and then when you use it on Mac OS X, you'll just get it for free. So the first thing I'm going to show you is the spoken user interface. It's part of the speech, and if you have it do the text under the mouse, it will read it out loud.

So again... Scott. These are just pure Java widgets that are getting this for free. So it's a pretty easy to use screen reader. And we also have speech recognition. You'll see here in speech recognition that there's the front window commands. I'm not doing that in here because the microphones in the big room don't work too well. But what I could do is go to this program and say add image, and it would click on it for me. This comes to you for free with Java. You have to do no additional Java programming nor any native Mac OS X programming.

And here's another really cool feature that we have is the UI scripting. Pardon me. So this is a JavaScript that's going to click on buttons. And it's going to fill out this little goofy program I wrote while the script is running. So I'll have it tell you about it. Thanks, Greg. First I'll add the Apple logo. Now adding the Java logo. There we go.

Now I'll add a picture of Greg. So it's filling out all these text fields as it goes. And lastly, a picture of Scott. Now it will start bouncing around. Now let's turn on the transparency. and Beth Dinkley. Okay, so what we have here is still a pure Java program.

We used-- We used standard AWT components and were able to script them. And this is pure Java. You'll notice this transparent window I have here. All I have is a Java AWT window where I've set the background color to have an alpha and the Quartz Extreme compositing takes care of the rest of it for us.

You can hear more about Mac OS X accessibility at session 421 on Friday. And I'll have more about this program on Thursday in session 620. So I'm going to run one more thing and it's going to open a website where you can learn about it. Now back to you, Scott.

Cool. Before you hang that up, I just want to show them the other thing you added. So Greg's been working on this demo just for like a day, and I said it would be really cool if everything blew up. So he had something where he could add a whole bunch of images and just have things blow up. So I just thought that was kind of cool.

So, this really shows things like, you know, your transparent window, the scripting. Now, what you don't realize is that's all swing. Those aren't Cocoa controls. The system doesn't know that those are Cocoa elements in there. If it was AWT, it would know about that. But these are swing controls. So, we implemented things so that your swing controls can get access to the outside world. And so that any other developer who goes in can see that, yes, there is a button there.

Even though that's a J button behind the scenes which on any other platform, they just think it's lightweight. I don't know what it is. On our platform, we've exposed that to our accessibility APIs. So, this is a big advantage to your swing applications because AWT applications are kind of boring sometimes. And swing applications can be really complex. And you can also -- is it true, Greg, you can expose your own custom components? Greg Schleusner: Yes, it is. You just tie them in with the standard Java accessibility APIs provided by Sun. Oh, one thing I forgot to mention.

On other platforms, to get Java to native accessibility, you'd have to do an additional download -- we don't believe in additional Java downloads except when it's a new release, I guess. But -- so you would just get Java to Mac OS X accessibility linkage for free. Great. Thanks a lot, Greg. Greg Schleusner: Thank you.

So again, if you want more information about these, go to the Creating Great Java Applications, that's session 608. You'll see at the end all the times for these sessions. So now we have the other thing, which is tying yourself into some of Apple's APIs. Now, some people might not want to do this, but there's a lot of good reasons to do this. We have some great things that you can do on the Mac with Java, and they're exciting, actually.

The whole WebKit SDK allows you to build WebKit applications that you can just embed Java applets right inside of. So that's really cool. Then the other way around is you can take a Java application, and you can embed a Cocoa View inside of your Java application. So you can take some custom Cocoa component and embed it right inside of your swing application, and just have it sitting there interacting with the user just alongside all of your swing controls.

And it's really cool. It means you can take almost anything from other projects and just pull it into your Java application. There also are ways to get to other APIs through native interfaces to get to things like our disk burning API, our cryptography APIs. It's really cool, and you'll see some of this. But you can also do it on your own.

So you can do it on your own. So you can do it on your own. And you can do this in some of the later sessions, building a disk burning program with almost all pure Java, with very little native code. But then you get all of the disk burning utilities.

We also have QuickTime for Java 6.1, which is being seeded. It's a developer seed, if I remember correctly. It has new bindings for new QuickTime APIs. So it's a little different than the QuickTime for Java that you might have used with 1.3. The big deal here is that it works with 1.4 on Mac OS X. And I recommend you open it. You all check it out. Anyone who's used QuickTime for Java before, check it out. Give us feedback on it. Talk to the QuickTime team, because they want a lot of feedback on this. And they actually are having a session.

Session 708 is where you can learn all about the new QuickTime APIs. And I really encourage you, if you're a QuickTime developer who uses Java, who's used the old QuickTime for Java, or has taken a look at the new one, to go there and give your feedback and learn all about it at that session. There's also some sessions on WebKit, session 4.0, 4.20. We'll talk all about WebKit and how you can get WebKit in your own application, which means you can then have access to applets in your application.

And then also session 6.20, we'll talk in-depth about these features, native integration on Mac OS X. So you can learn all about the different ways to embed native services in your application. So now I'm going to do a quick demo of access to native services, all the extensions. So if we can switch to demo machine one.

So what you see here is this is actually a sample app I downloaded from our developer site. And it's actually something that lets me connect to video cameras, which was really cool because we announced a new video camera today. I didn't even know. So I made this app, and it was developed by Ted and our DTS group to show how to embed Cocoa components inside of a Java app.

So how you can get some native functionality inside of your pure Java app. So I just gave it this great icon, and I named it after my favorite '80s name, Super Video Pro. So it's got a real icon. It actually is a real application. Everyone thinks it's just a plain old application. They don't know there's Java under the covers.

So it's already launched here. So here's my camera view. Now, this is really exciting. It doesn't look like much. Well, what's actually here is this area right here is a Cocoa component. Inside of this Cocoa component is an NS Quick Draw view, which is then talking to QuickTime.

So we've got everything in this one little application. Now, according to Java, there's just a component in there that's going to give us pixels. And it's just going to fill the screen, fill this section of the window. So as soon as I say connect-- There I am. So this is getting stuff directly from QuickTime. There's nothing tricky going on here. You can download this exact source. So I can just pick this up. Maybe not. I'll just leave this right here.

I don't know how that's attached there. I was going to show you what the demo guy is doing back here, but I don't think we'll be able to see him. So you can see that we're getting live stuff right here in our application. And then there's some other things, like I used extended AWT, and I added an about box with some custom Java inside of it.

So just to show that there's real Java in here, I just threw some goofy things in my about box. And this is just a regular old Java sample I threw in here. And I can click here and see Ted, who wrote the sample, and all this exciting stuff. So this just means you can do your own about box in here.

And then we also have the Preferences menu. So this, again, is hooked up to just my plain old Java code, and I can change any preferences. So one of the cool preferences in here is show DV setup when connecting. So if you turn this on, I say OK, and then I stop. And now I'm stopped. Now if I reconnect-- It goes directly to the native DV setup, video setup.

So this is now no longer Java code. This is a native window that's come up inside of my Java application. It took, I think, one parameter that I passed to the QuickTime setup that says now I want this native window. And now I get things like our vector scope in here. So there's all these cool things.

We can see what color am I and things like that. You can also decide if you have other sources, you can choose different videos and things like that. So this is a real easy way to get to native functionality in your Java application. Okay. Let's go back to slides.

So web integration. When you use Java, most of you when you develop Java, you're developing Java applications or applets. Now a lot of users run into applets all the time and don't even know about it. So we have to do a good job with web integration. So the biggest thing is Safari. Safari is our browser, our main browser on our platform, and we have to have good applet support for it.

So we have 1.4 applet support in Safari. Safari is a Cocoa program. And so our new Cocoa architecture works really well with Safari. So you actually have a much more seamless integration between Safari and our 1.4.1. So now we can actually say that we have more applets than ever running on Mac OS X using the combination of Safari. You also have applets inside of Internet Explorer. We also are working on a 1.4 plugin that will work with Carbon browsers.

So all those people who are writing Carbon browsers out there, maybe they won't be around for long because of Web Kit and how cool it is. But there still are some people who are writing Carbon browsers, and people may want to embed their applets inside of there. So we're going to have a way to put 1.4 content inside of those browsers. And then Java Web Start, which is kind of lonely at the end here, but it's actually a really important technology. And not that many people know about it, but it's a way to deliver applications through a web browser.

So the deal with Web Start is that it's a Sun-specified way of doing things, and you can have your, your JAR file up on a server somewhere, and you just have a link to a JNLP file, which is the thing that will then launch your application. And you click in the web browser, and it downloads your JAR file, puts it in a cache, and then creates-- it runs the application. And on the Mac, we've actually extended that so that if you download that more than once, you could actually have the option to create a double-clickable application out of your Web Start JNLP file.

So what will happen is you'll then end up with an application bundle that knows where it came from. So you have all the advantages of Web Start, because one of the big things about Web Start is that you can actually go to the original website every time you start the app and check to see if there are updates. You can automatically put updates out there, and then anyone who's using your app will get an announcement saying there's an update.

Do they want to download it? So there are a lot of things there where people want to deploy through the browser, but don't want to be an applet inside the browser process. They want to download something and not just be a DMG file or something like that. And this is a cross-platform way. It works on Windows with other JREs. is.

So there'll be a lot of talk about this at the Java on the Web session 619. There's a lot of details about the new things in Safari. We actually have support for cookies in Safari now, which is a big deal. And then all the details about the new plug-in and many details about how to specify your Java Web Start application.

So Java moving forward. So we've been talking about our Java update and other things like that. Let's talk a little more detail about it. So the future of Java and Mac OS X. The first thing in our future is the 141 update for MAC for for Jaguar Mac OS X 10.2. So what's in that? Well, we have hundreds of bug fixes. We've been fixing lots of bugs.

We've been getting the biggest issues and knocking those down. The other thing that we've been working on a lot has been performance enhancements. So what's the biggest thing that we've been working on? There are graphics performance enhancements, which you saw some of and you'll see more of on Friday if you go to that session. The VM, which has been optimized for for the G5.

But there also are some other optimizations in there that can work on Jaguar. And then Aqua has had some improvements in it. So we actually have some updates for our Aqua look and feel and to our AWT components. And the big thing here is that it'll be developed as a software update. Now it's available to you through ADC download as a preview. And we really encourage you to download it try out your applications. See if you have any other issues that we don't know about and give us feedback on it.

So now I want to give you a little demo of one of the things that we've seen in our release versus our software update. So if we can get demo machine one. This is a little application called Robocode. How many of you out there know about Robocode? How many of you tried running Robocode on 1.4? Okay. So be lucky you haven't because you're about to see what Robocode looks like on 1.4. So Robocode is actually an interesting application.

It's developed by IBM's AlphaWorks, and it's a program where you program little AI robots in Java that are subclassed off of a robot type, and you can compile your robots and everything. It's very cool, and it's very cool to us developers. Outside people might not care about it, but developers think it's really cool because you actually get to, you know, it's kind of like Core Wars and all those kinds of things. You get to program your robots and have them face off in teams or whatever. So this is a kind of graphics-intensive kind of thing, and this is running on our 1.4 release from March. And if I just resume the battle.

You can see up here, this is our frames per second, which this was--I think one of our developers deemed this unacceptable performance, which-- I think is completely correct. So what did we do? Well, we looked at this and we said we know there's something wrong here. We can do a little better.

So I'm going to switch from this machine to demo machine two, which even though we have a rack of Xservs here, this is the exact same configuration machine as this one here. You'll have to believe me on that. And we set up the exact same battle except it does random placement so the guys aren't in the exact same location, but you might be able to notice a difference. So this is running our 141 update 1.

And if I resume here, now we're actually getting--let's-- We're getting 2022. This is--let's see. This is a little less than what we were getting in our-- Oh, okay. So we're getting about 20, 22. This is a lot less than we got in rehearsal, but it's still an order of magnitude better, which is pretty good. So what I wanted to do is show you that we actually have--let's cancel this battle. Let's open a battle that I saved, which is a really big one here that I enjoy. And let me pause that, and I like doing this, too.

Let's see if this works. Okay, we're only getting about 10 frames per second, but it's probably because we have another thing going. But you can see that this is actually an order of magnitude better than what we had before. And you can actually run this in--it's actually usable now.

And we found out a couple reasons why this was happening, and we fixed those reasons. And hopefully we can find out why it's only 10 to 15 frames per second here and not 30, which I was getting in my test run earlier today. But that's still better than before. So we can go off of this one.

So we can go back to slides. So that's the update, and now the future of Java is actually going to be Panther. That's the future of Apple. So what's in Panther? Well, what you got in Panther was pretty close to what's in our update that you can download now.

It's a little different. There aren't all the exact same bug fixes, but we're going to have all those bug fixes in there. So when Panther is released, it's going to have everything that was in our update. So 141 update 1 is going to go out before Panther, and then when Panther is final, it's going to have everything that was in that update plus all the Panther graphics improvements.

So everything that Panther did, we've -- what Ted told you earlier is we've architected for the future, and this is actually where we start reaping the rewards of that architecture because we're living on top of all of the core APIs. We live on top of core graphics. We use all the text APIs. So if you're at Scott Forsdall's discussion about text.

We immediately get those two times performance gains. So every Panther performance improvement, those will affect us. Aqua improvements, we're revving our Aqua look and feel to match the new Aqua look for Panther. Font performance is huge. The font performance change in Panther, and we should be gaining most of that. Also things like the improved IO performance. And then the big deal with Panther is that it will include 141, so you can count on your applications having 141 there if you need it.

You don't have to get a download for Panther. And then the other big thing which has been mentioned in the last session and this session is that JBoss is going to be bundled with Mac OS X server. So you can count on having something that is close to the J2EE standard and be able to run your J2EE applications there. So with that, I want to bring up Alan Samuel, who is our Java Technologies Evangelist.

end a little bit today with actually one of you from the audience, a developer. Now the story on this is my counterpart actually in our Swedish office, Mark Turner, actually we had, I think he had a phone call one day, told me a little bit about this developer that he was working with that had developed this really cool product in Java. Originally developed on Windows and Solaris, I believe. I believe it's even over a million lines of code, a pretty hefty application. It was in the video conferencing space.

My first thought when Mark told me this, I was like, are these guys crazy? Who's going to take this on in Java? I want to show you guys what these guys have done. In a very, very short period of time, they've taken this product, and I think it's one of the showcase applications on Mac OS X. Unlike some of the things that you saw today with our video conferencing offer with iChat AV, you know, more of a peer-to-peer Mac-only solution, their offering works on both Macintosh, Windows, Linux, and Solaris.

It also offers a whole host of things like whiteboarding and other features to sort of more on the lines of a groupware application. But I don't want to take too much more time. I'd rather have you guys see it, but I think no matter what application framework this was developed in, this is going to be a showcase application for the platform. So with that, I want to go ahead and bring up Magnus Hedberg, the chief strategy offer with Meritech, and actually have him give you a demo of their incredible product. Thank you a lot. Thank you. Thank you very much.

Do you hear us, Staffan? That's good. I'm actually going to turn the camera around here so that you can see that you have a very nice audience today. This is one of the nice features with the new EyeSight camera from Apple that you can actually turn it around like this. Thank you very much. I've been looking at you all week last week. Yeah, I know.

It's terrible. So, Staffan is tonight with us from Stockholm, Sweden. And the reason I say night is because it's pretty much night over there. It certainly is. If I'm out of sync, it has nothing to do with the application, but with the time zones. What time is it? 3:00 AM. 3:00 AM. OK.

We always like dedicated staff. We don't have all the dedicated staff online. We have a few more actually here in the background that I'm going to bring in. One nice feature with this system is that we can actually do a little recording and playback. So what I'm going to do now is that I'm going to bring in some of our friends from earlier tonight before they left for home. That's how we can deal with that. I'm just going to press the play button here and you will see some more colleagues showing up. And this is really the beauty of the system, group collaboration.

I'll now let Staffan run a little talk about the application itself, and then we'll get back and I'll finalize talking about our Java experience. So, Staffan, the word is yours. Thank you very much. I'll start with introducing myself a bit. My name is Staffan Seadre, and I'm sitting here in Stockholm, Sweden, as Magnus said. Just briefly about who we are and where we come from.

Swedish software development company started R&D back in '95, mainly sponsored by Ericsson, which is a fairly well-known mobile company, at least back here in my end of the woods. The purpose was to create a solution that supported distributed projects and mainly distance education. Market demands led to that we founded the company back in '98, and since then we have a bit more than 130 clients that have verified the solution and verified the technology. So they have, together with us, made what you see here today possible.

A part of our vision is to create a truly distributed workplace. And with that I mean, you are right now somewhere around here, and whoops, and I'm over there. And that is a distributed workplace in a sort of global scheme. Very early this morning I had a bit of a conversation with some clients of ours in Sydney and in Perth. Earlier, in the last week, I was in contact with Germany, with the UK, and even more so with our development team that is based way up north in Sweden, almost close to the Arctic Circle. So this kind of distributed workplace is what we are--that's our world, basically.

This is made possible through convergence--a convergence of audio, video, whiteboard chats that creates what we believe to be very efficient group collaboration over internet. And that is over the public internet. I'll guide--just take you through some of the features here now. What you see on the top of your screen is what we call video for presence.

Basically, it increases the sense of presence. You see everybody's there. You see if they pay attention or if they nod off. If they nod off, you're a speed up. Everyone--all the participants have a P button that stands for private, meaning I can send private chats to anyone in the audience or any one of the participants.

And I can also have a private conversation going on with one particular participant without disturbing the rest of the group. Right now, you probably just see one or two or a few participants here, but I think the internal record is close to 500 people simultaneously in one session.

The voice quality--and I really hope that you experience decent quality over at your end. We usually do. Yes, we do. Thank you. You're welcome. It's developed for use over Internet, and since we don't really have any quality of service over Internet, it will have to be robust and handle packet losses efficiently. It's a wideband codec, so it's a lot better than traditional telephony. And a lot cheaper.

The video screen, the largest video screen that you see on your right hand side, is a strong tool because it increases commitment considerably. It's a lot easier to say "it will be done Monday" over the phone and don't mean it, than to include it in applications. So it's a very good tool for in-group environments when you want to have things done. The chat can of course be used in any way, but during a regular meeting, use it to ask questions, spell names, or type in URL, whatever. That's my email address, so in case you have any questions, don't send me those. Ask Magnus, since he's there. Makes sense.

And last but definitely not least, the whiteboard area. Use it as I'm using it right now to present stuff or make annotations. Highlight stuff, share ideas, and share documents, regardless of the application that you're on. I mean, you can be on an application that I don't have on my machine, but we can still share the information and make annotations and discuss the content. This is made available now in a cross-platform environment. We are strong believers in cross-platform communications. The client that you see on your screen, the big screen right now, is available for Sun Solaris, for Windows, for Linux, and, as of tomorrow, for Windows. Or for Mac.

It is 3:00 a.m. in the morning. It's out there. It is. Hang in there. The server that makes this meeting possible, that creates this virtual meeting room that we're in right now, is also available for a variety of platforms. And as of tomorrow, for Mac OS X. We are actually running this off an X server located in Stockholm right now. We don't want to prevent people from participating in meetings. That's why we have the client software freely available. So anyone can download the client software and connect to the server that is hosted by someone. In this case, it's us.

The Java I've set as of now has been encrypted, 108-bit encryption end-to-end, meaning that regardless if someone else is sitting on the server, they cannot listen in on our conversations. That goes for all media, for video, for voice, for chat, for whiteboard, and so on and so forth. So it's dead safe, which is crucial, especially for professional users.

The audio, I mentioned it earlier, is probably even more crucial because voice is such a cornerstone in all human interaction. So I can lose video, maybe, but I can't lose voice because then our conversation is not really efficient. That's why we are focused to create a very robust solution that handles network packet losses. We can even lose up to 30 percent packets and I will still make myself understood on my broken English.

It's very easy to get up and running. The client that you see on your screen right now, you will probably have it up and running in five minutes. Unless you're a technician, because then you probably need 15 minutes since you just have to fiddle around with all the settings. The server is equally easy to get up and running, I would say.

You can have it up and running, meaning creating these virtual meeting rooms on a server and invite people to join you in less than 30 minutes. The whole solution is also NAT compatible and very firewall friendly, meaning it cuts through it like butter. A nice feature is that you can record and play back the sessions. Say you missed your management meeting, it's a very good thing that you can listen in to what was actually decided, since everything probably ended up on your table since you were there.

It's also used especially in education. Students can listen in on the recorded lectures that they missed for one reason or the other. Take them 20 lectures at once and still 8 exams at the end of the semester. That concludes the features. So now I'll leave you with Magnus that will guide you through some of the experiences that we had developing this for Mac OS X.

Thank you, Staffan. You can hear the audience is impressed by your ability to work late at night. I guess you have a new future. As Alan mentioned, we have our roots all the way back in Java, actually at the time when it was called Oak, back in 1994, 1995. We worked very close with Sun.

And we later--it took us to like '99, actually, before we went onto the Windows platform. And we have been staying away from the Mac until Mac OS X. That was a huge relief for us because we have a lot of users in the educational field, and they really love the Mac.

And so do we these days. It's beautiful. And the way it comes across with a Unix operating system in the bottom, and we started playing around with Java 1.3, and the performance, it just sucked. So once we got to know the Worldwide Developer Team, we started working with Java 1.4.1. It was a breeze.

The service side, it took us less than a day to reuse the Linux version, putting it on the Unix box. The only thing we had to do was to change the installation script. That was about 15 minutes of work, and we were up and running. So we have been running this in an XR environment since November last year, and an uptime of more than six months. Beautiful. So it's really straightforward, even though it's a very complex server functionality on the server side.

When it comes to the client side, it's a different story. That's where we have had our biggest challenges. And that's really when we saw the big improvements from Java 1.3 to 1.4.1. Now this application is really usable, as you have seen on the screen today. Most people wouldn't have an idea, a clue, that this is implemented in Java.

We have, of course, had to pull off some tricks. Pretty much the way the super video demo was done earlier tonight, we have been using the same technology with QuickTime Video, basically accessing the native code for doing the rendering and grabbing. And it comes out pretty good. When it comes to audio, we have always been working very close to the hardware, because that's really a need, to be able to reduce latency and to handle the packet loss, etc.

We have had a lot of issues in the world of Windows, because every machine has a different sound card, and the operating system is not that stable, I must say, when it comes to real-time audio. When we come to the Mac OS X platform, we have been astonished about how smoothly and how easily it was to implement this great audio quality. It just works, and it works so well. So if you want to have great audio quality, it's OS X to go.

We have also truly appreciated the support which you find on OS X and the ease to access the PDF functionality supported by Quartz. And it just took us a day of work to have full support to import PDF into our interactive whiteboard. And that's also really neat, the ability to do that. And what we see is how easy it is to develop in terms of how difficult it many times can be to develop on other platforms. such as the windows.

And what we have learned is really that it takes collaboration. And we have been working very closely with the Worldwide Developer Team over the last, I would say, six months, or maybe even longer. And we really love the brushed metal look. And to be honest, it really doesn't look this beautiful if you just do it with Java. You have to pull some tricks.

But with the Worldwide Developer Team that is available to you, you can do those things. It takes some effort. But if you ask them, they will help you out. And they will guide you to make it look truly great. So we are very happy with what we have achieved so far. And we would like to thank the Worldwide Developer Team a lot. And I'm sure that you will get to enjoy their services as well. Thank you. Thank you, Magnus.

Thank you. Can we go back to slides? Can we go back to slides? There we go. One thing I should add today, this is a little interesting. Magnus didn't know about the little surprise with the new camera. We had not actually tested this until last week. I actually had one of the prototype units and had to hide from everyone and go and test it.

We had some of the Apple hardware people that were in, and we were using a couple of the cameras, and we were actually connecting to their XServe in Sweden. But I was really only going two doors down to Apple. So I was video conferencing basically from my office in Cupertino to Sweden and then back. And the product manager was saying to me, "Wow, the video is really great.

This is great. Is this like the peer-to-peer stuff that we're doing?" I said, "No, we're actually going to Sweden and back." We tested out the cameras. Everything worked great. I think these are going to actually be--iSight is going to be a nice compliment for Ameritech's offering. Thanks, Magnus.

So this is just a kickoff session. You guys all probably scouted out what sessions you wanna go to for the rest of the week. We've tried to highlight them in the content, so I'm not gonna go over all of these, but between Java, WebObjects, QuickTime, networking, all of the things that we're gonna be talking about this week, there's a whole lot of Java in all of it.

Let me go ahead and show you the last one, sort of an enterprise side with all the WebObjects pieces. I encourage you to get to all the sessions, especially the people that are doing the QuickTime for Java stuff. Please go to the QuickTime API session and give them feedback on that. And with that, I'll give you guys our contact information, and I wanna thank you very much for coming, and we appreciate your time. Look forward to seeing you guys the rest of the week.