Good morning. I hope it's not too early for all the Java developers in the audience today. Looks like we've got a good group. I just want to kick off this morning's session with a little bit of information for you on the rest of the week. This is obviously our first session, our overview session. We've got a total of 10 sessions in one feedback form just in the Java track. That's the most content that we've ever had for you guys in Java. We've got a lot of exciting stuff to share with you. I don't want to steal any of the thunder that we have in this presentation and some of the other ones. If you add that together with the WebObject sessions, I believe there's a total of 17 of those. There's a whole lot of Java-related content at this show.

With that in mind, I want to go ahead and make my introduction brief this morning and bring up Steve Naroff. the senior director and dynamic object dweeb for Apple and have him come up and tell you about all this great stuff we've been doing. Thank you, Steve. - Hi there.

I've never put such a silly thing in my title, but last year when I say I'm director and I get off the stage and I want to interact with you guys, a lot of times people are taken back. "Oh, he's a director. There's this line between me and you." So I figured it was really important to let you guys know that I still actually enjoy programming and enjoy basically being very active in the software community, not just people pushers so to speak. One of the things I wanted to open with is I'm extremely, I'm feeling great today. Are you guys feeling great today?

Last night, I felt really bad. I was here until 10 o'clock getting ready, and I was feeling very old. And it was because first day of the show, we're getting all this stuff together, getting the demos ready for you guys, putting the finishing touches on the presentation. And also Steve in his keynote reminded me of my age, unfortunately, when he said he had been working with Avi for 15 years. I actually started at Next two months after Avi and then realized I had been working with him for 15 years as well. And I did some simple math, and I'm like, holy cow, I've been doing this for 35% of my life on earth. I've spent with Steve and Avi doing this stuff. And as most of you know, Steve's a pretty intense guy, and one year with Steve is not really equivalent to one normal year, right? So it's not quite a one to seven with dogs, right? But it's probably a one to three. So I really hope my life isn't going to end any time real soon because the math just doesn't add up. But anyway, speaking of age, Java is six years young.

And I think it's sobering to realize it's just a child, okay? It's just a child. And from its inception in 95, where it hit the streets about spring of 95, to today, a tremendous amount of change has occurred, not only at Apple, but in the Java community. And so I'm going to spend the first half of this talk giving the 10,000-foot view of what's going on in the Java community. I'm also going to talk about what's changed in the Apple community.

I'm going to talk about what our goals are. Fortunately, they haven't changed a hell of a lot. In the three and a half years I've been on this stage representing the Java team. And what's our strategy? Our strategy has changed a little bit over the years, but ever so slightly. I go back and review the presentations of prior years before putting a presentation like this together. And I was fairly happy with the consistency. And I think that should also be good for you guys, because you don't want to see us jerking you around, so to speak. That's not what we're here to do.

So from an Apple perspective, and actually a Sun perspective, we don't have any more excuses. I think Java is in a pretty interesting place right now. Not to say that we've solved all the problems or it's in an ideal location, but there's really nothing to be embarrassed about anymore. So for instance, when Java started in the browser for applets, it really wasn't an appropriate API for developing industrial strength applications. At that time, it was called the Java 1.1, and it had AWT, which was insufficient for developing great applications. And Sun has fixed that.

Sun has Java 2. Sun has Swing. Sun has JFC. There are quite a few interesting APIs on the platform that do enable you to do non-trivial things. And other things that I guess have changed is the development tools in this space have gotten fairly robust. And we're going to talk about tools as well later on.

Let's see, what else do I want to say about what's changed? Well, we'll talk about it later on over the course of time. What's our goal? Our goal is to be the number one desktop for deploying Java applications. Now, we've been working hard on this, and we're going to tell you where we are today and where we expect to be tomorrow. That's part of what the talk is about. And we want to be the number one desktop for developing Java applications. We have the coolest hardware on the planet. I see so many people with titaniums and running 10, And we need to enable Java developers to buy this great hardware and software and do their Java development.

So why are we doing this? Java is the fastest growing language on the planet right now. Just so you don't get mad at me, this is not my data, it's Gartner, that's why Objective-C isn't on the chart for you Objective-C people in the audience. And also C# is at the bottom there with a question mark.

C# is a language which is Java-like and Microsoft is currently promoting it as the next generation language for programming their platform. Right now it's not really on the radar screen, so to speak, because there are very few people presently programming in it, hence it doesn't have a line right here. So it's unclear whether it's going to overtake Java, but certainly at this point in time there's no evidence of that, certainly from a cross-platform perspective. of So last year at Java 1, Sun, I guess, had said that there were more than 2 million Java programmers. And that was really exciting given Java 1 had about 25,000 developers at the conference. And hearing there were 2 million people programming in Java was actually very exciting and a good marketing slogan.

However, if you look closely, a lot of these people are not qualified to do the type of development that's, I think, being done by people in this room. So there are a lot of hobbyists. In fact, most of the community are hobbyists right now. You know, this isn't a surprise, right? If any of you have been in small companies or even big companies that are growing, when you grow from what Java, when you experience this type of phenomenal growth, it's pretty clear that all 2 million developers are not going to be wildly qualified. So this is just natural growing pains of any successful platform. So this isn't meant to disparage the community, but to just educate you guys that basically not all the developers are created equal.

So it's becoming mainstream. This isn't any surprise. There are slices of this pie, which we're very interested in, certainly education, 19%. As you know, Apple's very big in education. Finance, personal finance in particular. Last year, Schwab released an application that was heavily advertised on television called Velocity. That application runs very well on our platform and, in fact, was developed on it. And now there's all kinds of financial applications that are following suit. And later on, we'll bring up someone from a company that does a product called Money Dance, which is a very interesting financial application written in Java. So it's becoming mainstream. And what's cool is it's mainstream, and it's good. It's good technology, especially the language.

The language is excellent, and the APIs are evolving to become excellent. I'm very much into music, and most of the popular music of today really stinks. I sort of expect that in our industry because it's becoming a fashion industry, whether you recognize it or not. So it's sort of cool that Java is technically sound and mainstream, and both of those are very important.

So Java technology usage, there's... a lot of energy going into the server. As you can see, that red point on the graph is for servlets and Java server pages. So right now, the biggest application, or the largest amount of Java code, is being written on the server to do Java server pages and servlets. The second most common is still applets, good old applets.

The difference between applets and Java server pages is Java server pages, says Gartner, is going to go up at a faster rate than applets. Applets tend to be pretty stagnant if you look into the future. The other point in the graph is applications, the blue line. The blue line is steadily going up, and we anticipate that to even go higher, mainly because all of these server applications need to have a face.

And HTML and applets aren't going to cut it for a lot of them. So there are going to be lots of applications which need to either supplement the web-based interface or replace the web-based interface. And then the most growth that's expected, even though it's a small amount of energy right now, is the enterprise Java beans. Right now, enterprise Java beans is the least popular in 2001, but that's expected to grow significantly, as the data indicates. So here's a diagram which I hope will explain our strategy. Excuse me for a minute.

We love the Java language, as I said. There's three virtual machines underneath. The one that we're focusing on is the Hotspot Java virtual machine. There's a KVM and a CardVM. So on one end of the spectrum, people are doing lots and lots of work in the enterprise, again, on the server.

As you know, most of you know, WebObjects has been completely retooled to be in Java, and it's certainly one example of this. Over time, I expect the WebObjects team to roll out their J2EE or Java 2 Enterprise Edition strategy. Right now, the reimplementation of WebObjects in Java is a necessary first step. However, to play on the server in the application server space with Java, You have to start adopting some of the idioms and methodologies that J2EE is implementing, mainly because BEA and Oracle and IBM, all these companies, their application servers, are starting to talk enterprise Java beans.

They're starting to talk Java server pages. And unless we talk that language, we're not going to interoperate with all that other work that's going on in the community. And hence, we're not going to take advantage of the full power of Java. So on the other end of the spectrum is JavaCard and also Java Ring and Java Lightbulb and, you know, all that kind of stuff. We're not interested in that. There's companies investing lots of time and energy in it, and that's great.

And on that side of the space, there's really no APIs per se that sit atop the Java language. On the other hand, for these other class of devices, cell phones, faxes, POMs, all that good stuff, there's the micro edition. There is an API suite that, again, is cross-platform as you define the washing machine and the fax machine. There's some lowest common denominator API that they're developing called the micro edition. Okay?

This is what we're focusing on. We're focusing on the standard edition. The standard edition could be considered the desktop edition. The other way of thinking about it, it's the core of Java. Again, it's the core of Java. For instance, the enterprise edition is a superset of the standard edition. So it includes all the standard edition technology. So one of the reasons we're focusing on it is the better we make our core, The better we make Java 2 Standard Edition, the better products like J2EE will run. For example, there are companies like Bluestone, who I think is now owned by HP, that have a pure Java J2EE implementation. I don't know if they formally support it on Mac 10 yet, but I ran into a couple of the guys at one of the meetings, and they said, yeah, we brought it over to Mac 10, and it just ran.

And so that type of stuff blows me away. It's like, wow, we have a full Java 2 Enterprise Edition stack, and it just worked on Mac 10. Yeah. And that type of stuff, again, explains the value of what we're trying to do here. So Java 2 Standard Edition, the Sun packages, Just to be technically accurate, this includes a little more detail than the previous slide. There are three packages which are really built into the language definition. They're the utilities or the collection classes, IO, and LANG, which includes things like language reflection and so on. Right above, we have packages like security, remote method invocation, mathematics, networking.

And I'm not going to go through all the packages. I'm trying to highlight the most important ones. Above that, you start to have user interface technologies-- Swing, AWT, Geom, which is just a poor name for Java 2D, and applets and sound. So without getting into any more detail about what packages there are, this is the pure Java 2 stack, so to speak, that people are writing to. And we want to support applications that are being written on other platforms so that they just work on our platform.

But that's not enough for us, okay? We want to go beyond Java 2 SE. We don't want to go beyond it because we don't think Sun is doing their job or that we think Java 2 SE is not good. We're going beyond it because Apple has some core competencies and some great technology that we think need to be available to Java programmers. So, again, it's not a competitive thing. It's not like by virtue of doing some of this work that we are not subscribed to the PureJava platform. We are. In fact, all these technologies layer on with standard Sun extensions like JNI. So right there we have Cocoa. For Cocoa to interoperate with PureJava, we have something we call the Objective-C Java Bridge. And that, again, uses JNI, which is the lowest level standard interface for native method invocation.

So in addition, Cocoa implements a lot of the same stuff at a GUI layer as Swing. So sometimes people get confused. Later on, I'm going to try and remove some of that confusion. I don't want to go through it right now. Here's QuickTime. So QuickTime is also layered on some subset of the Java 2 SE stack, and we have WebObjects, which is layered atop the entire stack. That is, you don't need any native code to run it. Whereas Cocoa and QuickTime both contain native code, Cocoa in the form of Objective-C and C code, QuickTime mostly in C code.

So we also, aside from offering the WebObjects, Cocoa, QuickTime Advantage, we want to take Swing and make it integrate with our platform in some fairly obvious ways. One, it needs to have the Aqua look and feel. So we've done that. Swing looks great. And we think it looks better than any other platform you can run Java on. And I'll have some people up later on to demonstrate some of that. And the menu placement is what Mac people expect. It's at the top of the screen, not associated with the window.

Quartz 2D integration, basically we get all the PDF support that Steve was talking about and very fancy graphics by virtue of having this stuff layered on top of Quartz. And we also have out of the box support. Now, here's a quote from Tony De La Llama at Worland.

Let me take a minute and really emphasize the importance of this. The Java 2 platform is, at the end of the day, an operating system. And when you think of it in those terms, the JRE, which is just the runtime environment, is about roughly 10 megabytes. I think it's actually 8 and change, but let's just say 10.

The problem with not bundling it as part of the operating system is, number one, you have to have a fairly fast connection to download this stuff. Now that's only a small part of the problem. The much bigger part of the problem is if it's not bundled, each application will bundle its own because it doesn't trust any other application to install the right one for it. So for instance, you'll have, in the worst case, you might have five Java applications on a Wintel system that actually each application not only has its own copy of some unique version of the virtual machine, but when it's running, it has to instantiate that copy, and each application will instantiate its own copy. Okay? So the analogy is, imagine if all the Carbon apps that are being developed carried around its own version of Carbon. And when you ran it, had to instantiate its own version of Carbon. That's crazy. So it's really important to know this is an architectural flaw that is basically not a flaw on our system, but a flaw on every other system right now that's running Java, particularly Windows.

So let's move on. I'm going to get back to something I said before, which is, okay, there's the Java 2 Standard Edition, and we have Cocoa, but they have Swing, and we have QuickTime, and they have JMF, and there's some confusion about what people should be programming to. So one way to remove the confusion is to say, and I can't say this because I don't know all of you, you need to put yourself in a box, okay?

I know it's not easy sometimes, but you need to think, what are my goals and which box am I in? So the one box that I'm totally uninterested in for purposes of this discussion, unfortunately most of the software on the planet probably lives in the box, is the single platform and simple box. So let's just get rid of that. Don't care about it. The next box is multi-platform and simple. So on one end of that spectrum, you have something like a dumb terminal. It has the maximum reach, that is it runs on the most platforms, but it's arguably the worst user experience.

So HTML is in that same box. It has a great reach. And it's richer. But it's still not as rich as you'd like. So let's go to the blue box. The other end of that spectrum is a native application. And I'm doing this native app a little bit of a disservice because it actually isn't a point. Depending on how you've architected your application, it's a spectrum. So let me describe what I mean by that. With Java 2 SE, you're writing cross-platform code not only for your engine, but for your GUI. And that's a fully cross-platform application. What a lot of people do, especially the shrink wrap vendors that care about quality in a big way, what they do is they divide the back end of their application and their front end of the application. So what they do is they port the back end and make it as portable as possible, but plug in a native GUI, so to speak. So there are a lot of people right now doing that on the Mac 10 platform. They'll use Cocoa as the front end, but they'll bring over a lot of engine code from other platforms.

And that will give you the best possible native application experience on Mac 10, again, using technologies like Cocoa and Carbon. So another point on that graph is the browser plug-in that usually contains some native code. And I'm not going to talk much about that. You guys know what that is. But Java is in that green box, which is multi-platform and rich. So the very first version of Java had quite a bit of reach. In fact, it was almost as close as HTML.

Well, that's unfortunately changed because Microsoft and Sun decided not to see eye to eye on life with Java. So the bottom line is it isn't as ubiquitous. Gets back to my previous point on bundling. So you can't depend on it in the same way as you can depend on HTML. The other point of the graph is the Java 2 app.

This is where we see Mac OS X Java. We think that it's going to have much further reach than the standard Java 2 app. We also think that it's a much richer experience because of the integration we're doing, which we're going to demonstrate in this talk. It's right below the native app.

We think we're pretty close, but it certainly is not the ideal way to get to all the functionality of the Mac 10 platform. Can you get to 90 plus percent of it? Yes. And we hope to close that gap over time. So let's move on. Let's talk about precisely what we're doing.

You've seen this stuff, so I'm not going to... You've seen it from everyone, practically, I'm sure. But for purposes of this discussion, it's critical because Java was developed on a Unix-based operating system. This enables us to port more quickly, enables us to innovate rather than just port, which is not always fun. And it enables us to offer an environment which is familiar to the Java community. So there are many people in the Java community who never considered us before that are now coming over to 10, and like it or not, they open up a terminal and they can type Java C or Java, and they get all excited. Wow, this is a Mac platform, and I could actually go into this terminal, run Emacs, VI, and all these lowest common denominator editors, and use Java. And that's great.

OK, that's great, because who are we to tell them, no, you have to live in this IDE, or you have to live in that IDE? That's not appropriate. So we have a spectrum of tools, starting from the command line to some very great IDEs that we're going to talk about later. So just to put some of this into concrete perspective, I wanted to bring someone up from the company that's actually the first to deploy a Java shrink wrap app on Mac OS X. Fellow's name is Sean Riley, and he's chief technical officer from AppGen. Thanks, Sean.

Hi. As you said, my name is Sean Riley. I work with AppGen, and I wrote MoneyDance. MoneyDance started out its life being developed under Linux FreeBSD. That's kind of the world I come from. I had a lot of time one summer when my girlfriend went to London, and I started writing MoneyDance, you know, kind of evenings and weekends kind of thing. It continued that way for a couple of years, and now I'm doing it full time.

And MoneyDance is developing a lot faster because of that. And I'm going to talk a little bit about MoneyDance, and then talk a little bit about how my experience went with bringing MoneyDance to OS X. My current development environment is OS X right now. I've switched completely from Linux FreeBSD, so I'm now a part of the Mac world.

and enjoying it. MoneyDance is a personal finance application, a kind of program that helps you manage your checking account, credit cards, investments, track a budget, things like that. The newest version allows you to do some online banking. We've got a lot more online features on the way, and I'll show you that in a little bit. The program is probably familiar to anyone who's seen any type of personal finance application. It looks kind of like a checkbook register. click through things, and enter transactions, and has autofill.

standard features you expect to find that you don't generally see in a lot of Java applications. One thing about Java on OS X I like is the look and feel. You know, this looks a lot, you know, it looks very nice, the buttons and the Aqua and everything like that. When you run it on Metal and Linux and things like that, it looks, you know, it looks nice too. But Java on OS X is just beautiful, I think.

And I think you even put, didn't you put a picture of it on your box? Yeah, we have a box of money nets that should be in stores now and the screenshots on the box, you know, show the OS X version. or the version in the box, you can put on any platform, pretty much.

So I can step through the program a little bit, show you the investment management, the different views. And I think it's a very full-featured application. You can go on the internet and probably find 10,000 small Java applications that do one or two things. MoneyDance is intended to be very comprehensive, include all the features you need, and be a real full-fledged desktop application.

Some of the features that we have that you can really only have in a Java application are things like extensions. We have an interface to add something like plug-ins, so you can add new features to the program even after it's released. So we can go through adding an extension.

And this works cross-platform. It will work on Windows, Mac OS 9, Mac OS X, Linux, anything. And we'll just choose an extension here. I don't know how many of you have heard of JPython, but it's a Python scripting language implementation written in Java. And we've written a little extension that will allow you to run Python scripts in Java and get at your finances, your transactions and accounts, and do whatever you want to do with them.

So make money that's more extensible. This is just one extension that we have. We've got a whole bunch of them on the way. A lot of online services, a lot of some extensions that are really only for hackers, if you want to just play around with it. You can write your own extensions. We have a public API that you can add whatever type of extension that you want. If your company wants to add, say, an online service to MoneyDance that connects to your service, you're free to write your own extension and give it to us. We can provide it to MoneyDance users. You can enter Python commands in here. I won't really get into this much, but, you know, just know that you can enter Python commands in there and it will access your data.

So how long did it take to port? TODD KERPELMAN: To port? I don't know if I would really call it porting. You know, we didn't have to rewrite any code at all. We didn't even have to recompile it. We just took our JAR file. When we distribute Monday Nance, we distribute it with a JAR file and several supporting JAR files, like JCE, JSSE, things like that. And we took the exact same JAR file that we use on any other platform, and we packaged it up using an MRJ app builder.

And it took us under an hour to figure out how to do all of this stuff and to have a clickable icon that you could run the application with. And that was starting from never seen Mac OS X before to having an application that looks like it's written in Cocoa running on that.

Well, thanks a lot, Sean. Thank you. So one note, that's running on stock Mac OS X. So he wasn't running on any custom version that we have. And we will be showing you some custom versions. So I want to make sure I distinguish between that. So Mac X is appropriate for development, deployment of these Java applications. And I'm amazed at the performance of that app and just the overall fit and finish, given, again, where we were a couple years ago with Java. So very exciting. Here's our roadmap for 2001.

As you all know, we shipped, again, the Mac 10 GM on March 24th. Available at the show, I believe, there's a pre-release, too, of IE. One of the things we didn't ship for the GM release of Mac 10 is applet support. So that was a collaboration between us and the browser vendors. The most notable ones are the OmniWeb group and the Microsoft folks who do IE. So IE is doing a pre-release. We're a little bit behind on the OmniWeb work, but we expect to do that as well. We're going to have a release by the end of this week. We wanted to have it available for you this week so that you could start playing with this stuff in the browser.

And we expect to have a full-fledged GM update of 1.3.1 in July. For those who aren't aware, last week, Sun actually blessed 131 GM, and that means we're only going to have a two-month delta between Sun's latest stuff and our latest stuff. Okay, this is the best that we've ever done, and, in fact, I think the best in the industry at tracking Sun's latest release. Again, years ago, we were always apologetic.

This year, no excuses. We have this stuff in a timely fashion. Two claps. OK, so what's new in DP1? As I said, Applet embedding now works. We've made many improvements to the Aqua swing look and feel, debugging and profiling work, and many bug fixes. So even though you can deploy, obviously we still have bugs, and we still fix them. So what's left? We are going to be updating to 1.3.1, and that contains some new APIs, a new version of Hotspot, and we have to make sure we're conformant to Sun's JCK validation suite. Right now, I think we're passing, the release you'll get, I think we're passing 90-plus percent, so we don't have far to go there and certainly fix more bugs.

So now I'm going to shift gears. You know what we're shipping with 10. You know what our plans are for the update. Fairly straightforward stuff. Well, what are other things that are on the horizon? Okay? Because I think we only meet once a year, and it's important for me to talk about this because I know many of you are interested in it, even though some of these things I'm going to be talking about we don't have product plans for to talk about today. But it's direction.

So Java Secure Sockets, this is some really good news. You can go get this today. It's a pure Java implementation of SSL and TSL for doing HTTPS or just Secure Sockets. It's available from Sun's website, and there's the URL for it, and you can bundle it with your application. So this is a perfect example of Sun continuing to add value to the platform and us being able to take advantage of it without doing any work. So that's the ideal world from my perspective. And the other thing to note is on Mac OS 9, the only place we had secure sockets was within the browser because of how we chose to implement it. We didn't have this feature for applications. And now with our emphasis on applications, it's critical that this feature exists. So again, this is richer than the capabilities we were providing on 9 with MRJ.

Java Web Start. This is a very interesting technology that enables you to just click on an icon within a browser and get your application to run. There's no ad hoc stuff you have to do, which varies from product to product, and it gives you transparent update. It also is available from anywhere. It's a shame this didn't exist three or four years ago, but it exists now, and we're right on top of it. we think it's great and it is also integrated with IE. So to demonstrate some of this is Steve Llewellyn from my team.

Thanks, Steve. Good morning, everybody. So I have two actual cool web-based demos for you this morning. One is Java Web Start, and actually I'm also going to show applets running in Internet Explorer as well. So Java Web Start, what is it? Where did it come from? You know, what's the deal about Java Web Start? Well, Java Web Start was developed through the Java community process, and for those of you who don't know anything about that, that's basically a forum that Sun established to work with their partners on developing critical technologies like Web Start for Java. So Web Start. Web Start is all about permitting Java applications, be they small or large, simple or complex, to be deployed from any vendor's web server to any Java-enabled Web Start desktop, such as Mac OS X, from any vendor's web browser. Meaning a web browser doesn't have to, for example, have the capability to display an applet to still use Web Start.

And all of that is to be done securely through a single click of the user's mouse. So we have a simple HTML page above us on the screens. And this is vanilla HTML, just some images and some links. The WWDC WebStart image here has a hot link behind it that is tied to a JNLP, a Java Network Launching Protocol WebStart document, which is written in standard XML. This document contains everything WebStart needs to know in order to find the application it needs to present to the user. So I'm going to start the demo off. I'm going to click on my little image here. And this click will trigger the download of the HTML doc--or the XML document. And that in turn will trigger the WebStart technology, which we saw--it happened very very rapidly, but it triggered the Web Star technology to examine that JNLP file. It found out what application needed to be downloaded, what version it was, what's its name, who wrote it, where to find out more information about it, all that kind of good stuff. In our case, it downloaded the application because it wasn't already in our system. Had it been and had the user requested the same version as was on our system already, it wouldn't have downloaded it would have just reused what was there, and the download would have been faster. And then it launches the application.

So once you get a bunch of these applications on your system, you may have difficulty managing them. Well, Web Start has built-in application management in it. So I'm going to go and I'm going to start the Web Start Management Console. Bring up my doc. And-- Once this launches, we'll see that the Aquapad application that launched is now being managed by Web Start. Here we can see it highlighted there. And from the Web Start application manager, we can actually launch the application again.

Say we forgot what web page we originally got it from or whatever. When we do that, even when we launch it from the Web Start application manager, it's still launched in a secure environment. So the user is as safe launching it from the manager as he was launching it from the web browser. We could also remove the application completely. Say we're done with this application, we want to clean up some space. Instead of having it be in some mysterious cache somewhere and we're just running out of disk space, who knows why. So we can completely wipe it from our system. We can also find out more about who wrote the application, in this case, Apple Computer. We can find out a description about it. In this case, it's the Web Start Aquapad demo. Also from the application manager, We can do things like set our operational settings. For example, do we want the Java console to open up when we run a Web Start application?

We can also set security settings, like the digital certificates used during the security piece of role that Web Start plays. So that, in a nutshell, is Web Start. Now, since we have this application up, AquaPad, let's take a closer look at it. We can see that, as we'd expect, it has a crisp, clean, Aqua-compliant appearance. But there's a few things about this application that are different that may not be apparent immediately. What we've done is we've enhanced AquaPad with a couple of Apple Java frameworks newly available as of this week from Apple's developer website and freely downloadable by you guys to use in your Java swing applications. The first of these is the Java Speech Synthesis Framework. Now this framework uses the speech capabilities built into every copy of OS X. And it enables a Java programmer to do basically text to speech conversion. Hand it a bunch of text, the computer reads it back to you through its speaker. It also can play a few other tricks and do some neat things. It basically has 100% coverage of the capabilities of the speech technology built into OS X from Java. So I'm going to demonstrate in our AquaPad application, we're using this to read back the contents of the AquaPad document to the user. So I'll just ask it to do so.

Java Web Start Example Application. This is a demonstration of integrating Macintosh technologies such as speech synthesis and Cocoa system services such as spell checking with Java 2 standard edition swing applications on Mac OS X. the Java frameworks for these two technologies, as well as speech recognition, will be discussed in session 502, Wrapping Mac OS APs into Java Beams. So Mac OS X. Should have been Mac OS X. If you go to that session, I'll show you how to fix that. So the other capability included in AquaPad is the Java Spelling Framework. The Java Spelling Framework uses the built-in Cocoa Spelling Service that's included with copy of Mac OS X. And as you might guess, it allows the Java programmer to build in spell checking capabilities into its Java application. So in this case, for today's demo, we're going to take a look at the real-time spell checking capabilities of the framework. So I'll turn on the real-time spell checker, and I'll go down to the bottom of the document here, and I will deliberately type in a horribly misspelled sentence. I think I'm the first person that stood on stage and said that. So let's see. This is really something. Okay. I have three misspelled words. And the first thing to notice is the pace with which the real-time spell checker kept with my typing. Now, what it's doing when it's checking the spelling is from Java, it realizes I've hit a key, it gets the text out of the style pad, It hands it to another process, the Cocoa Spelling Service, also running on the system, asks it if it's spelled correctly. If it's not, it goes and it marks up in the red underscore misspelling cue that the word is misspelled. Now that's really fast. Now when we type, since the real time spell checker is still active-- for example, ISS, I know I've just made a typo there. I can just correct it. But watch, as I go back and forth, I'm going to keep making this misspelling error and every time it's doing that whole conversion back to the Cocoa Spelling Service, back to Java.

I mean, that is like-- it can do it faster than I can type it. So that is a premier example of how tightly you can integrate Cocoa services with current Java. So we can also ask the framework, what are the suggested corrections? I don't really know how to spell the word this, maybe. So I'll go and I'll Control-click over the word.

And I'll get a list of possible corrections. And this is my correction. I'll do the same thing for the second word. The second word, I want to point out that we can also tell the system, just ignore this. You know, it's a funky word. You know, remove that red underscore. I don't want to see it.

Or we could say, this is a new word. A lot of times in our business, we know that the spell checkers complain about all kinds of technical terms that we know are really spelled correctly. So I can actually ask the system to learn it. And then all applications, native and otherwise, that use the Cocoa Spelling Service on OS X will now realize that that word is a correct spelled word and not indicate that it's been spelled incorrectly. So in this case, I'll just choose something and it's corrected. So there we have it. We've taken a standard Java swing application. We aquified it. We turned on the AquaLook and Feel. And we added a few new Apple Java frameworks, released this week, that you can use for free. And we wrapped it up in Web Start. We deployed it through an Apache web server. down to our Mac OS X desktop through Internet Explorer, all with a single click of the mouse. So that's the Web Start demo.

So let's see how applets are doing today. As you know, in the first version of Mac OS X, applets weren't running so great. We've made a lot of progress with working with Microsoft. And the Java team has worked really hard on getting this to work. So here is pretty much the biggest swing applet I could find. It's a demo application that Sun wrote quite a while ago to demonstrate all the capabilities of the swing UI toolkit. And we've probably all seen this before. I'm just going to play with it a little. And we can see the performance and see that it's OK. Now the very first demo tab that comes up is really my favorite, internal frames.

And the developer that did this really went to extremes to make it very OS X look and feel. So we see our windows here. We can move them around. That's pretty fast. And we can resize them. That's happening fast. And let me make this small so I can scroll. And that happens fast. But what's really cool is, of course, Mac OS X has a dock on it, right, a transparent dock. So if I start minimizing these windows, we see a transparent little dock appearing at the bottom. And it's even-- you see the transparency as I move the window around. So that's really cool. They did a great job. So let's take a look at some other pieces of this swing set demo. This is a good one. We can see how fast the columns move around. And I can resize them and do that kind of cool stuff. And we can see-- we'll look at the progress bar. It's all in the mail. It's working very fast. So that is Swing Set 2 demo, running as an applet inside of Internet Explorer. And those are my demos. So thanks, Steve. Great. Thanks, Steve. STEVE GROVE: No problem. Pretty cool. Next, I'd like to bring up Larry Abrahams from Sun Microsystems.

Larry has been one of our strongest supporters and son, and I just wanted to bring him up to thank him for all the work that his team has done on our behalf and all the help they give us. So I also wanted him to take the time to say a few words. Thanks, Larry.

Thank you. First thing I want to do is thank Steve and his team for the great job they did on 1.3. It was sort of a long time coming in getting Java 2 on the Mac, but it was worth the wait. As you can see here, it's just fantastic implementation. So thanks, Steve, to you and your team for doing such a great job. And one of the comments Steve made about 131, about Apple shipping 131, I guess, within two months of when Sun ships. Well, just to put that in perspective, Apple will probably be, I can't say for sure, but Apple will probably be the first platform port of 1.3.1. So we've come from a situation where Apple, in many cases, lagged behind Sun much further than either party would have liked to today when Apple is the first licensee to be shipping on 131. So congratulations and thanks for And I expect the same on 1.4 as well. I expect Apple will be close behind us. Did you give a date for that yet, Steve? Well, did you? Yeah. End of November. And we're right on schedule. In fact, next week we'll be shipping the beta for 1.4. So let me talk a little about the state of the partnership, and let me make a little confession. So before I joined Sun-- When I joined Sun in '98, I was an Apple employee. I worked at Claris, actually, which, at least in those days, was Apple's software arm, in a sense. And, as most of you know, Claris has now sort of migrated into FileMaker Inc. Well, when I was there, I was responsible for Claris' internet products, homepage and email and some other things.

Still some good emailer fans out there? Glad to hear that. It's a great product. And when I came to Sun, my boss at the time, who was heading up all of Sun's Java efforts, told me, I have three missions for you. Number one, get Java 2 shipped. Because at the time, Sun was having problems getting 1.2.0 Java 2 out the door. It was a big deal, and there were some problems with the schedule and with getting the thing product ready. The second mission was to get Hotspot shipped. It was sort of in a similar state. Hotspot was a really cool next generation VM technology that we were having some trouble at the time productizing. And the third thing was, can you please, given that you're coming from Apple, could you please try and fix the Apple and Sun relationship and get Apple to a point where we're shipping compatible products in a reasonable time frame? So very early on-- and that's true. Those were my three commands from my boss at the time. So very early on, Steve and I got together and talked about, well, what could we do to make things better? And I just want to, once again, thank Steve for, from those early conversations, the spirit of partnership that the two teams have shown and the really getting better with every month collaboration. We've gone from almost two camps that were barely working on the same agenda to now intimately working on technologies that we're sharing for fundamental Java technologies that the two teams developed collaboratively. I'll give you two examples of that. The Aqua look and feel for Swing that looks so beautiful. I won't in any way put down our metal look and feel or our windows look and feel, but I've got to say this one looks pretty hot. It was actually the result of a really tight collaboration between Sun engineers working at Apple and Apple engineers. That's something that Sun has committed real resource to invest in and will continue to invest in. The second example I'll mention is on the VM. Our two VM teams ever since Hotspot have worked extremely closely together. Our VM team is extremely excited about working with Apple on Apple's port of Hotspot. As a matter of fact, there's some really exciting work that Steve may talk about for the future where Apple has developed some great extensions to Hotspot that Sun is going to be looking at productizing. So at this point, the collaboration is so strong that the technology is flowing in both directions. And that's just a great comment on the state of the partnership. So let me talk a little about the future of client Java as Sun sees it. And I think it lines up very well with what you've seen and heard here today. Sun's latest statement and vision for client Java is something we call rich clients for web services. If you come to Java 1, you'll hear a lot more about that. But there's a lot of talk about web services. So what are web services? Web services are essentially internet or web or network services, in our case, implemented on top of either J2SE and things like servlets, Java server pages in some cases, and Java enterprise edition and things like EJBs. And these web services today are being made accessible through standard XML protocols like SOAP, which is something that Sun is, at this point, standing behind from a strategic web service perspective.

So what good are these web services, though? I think Steve brought this up, without a great face on them. So as we all know, the most popular, lowest common denominator face is HTML and technologies that create HTML. But it's always been my vision in particular that the need for interfaces that go beyond the browser, for a lot of reasons, is something that is going to really come back in a sense. We sort of took a detour in many ways with the birth of the web through HTML and through, in a sense, a lesser user experience for online and network data. And I think the time is rapidly approaching where we're going to see a lot more innovation in user interfaces that go beyond the browser.

And I think Java is going to play a key role in that. And the types of things you're seeing with Java 2 are going to play a key role in that. So our vision is that Java 2 and certainly Apple's version of Java 2 will be a great user experience for this emerging generation of rich clients for web services. And I think it's only natural that Apple, in a sense, be the leading provider of those or the vanguard of those since Apple invented the rich client, the rich interface. And Sun would like nothing more than to see Apple be in the lead in terms of showing off this new generation of technology. So thank you once again. Sounds good to me. And I look forward to-- Thanks a lot. --our next year.

So for those of you that didn't attend Java 1 last year, actually Steve Jobs was on stage. He was featured along with Scott McNeely. And it was one of the first appearances Steve has made where he wasn't the star. And it was pretty interesting to get him up on stage with Scott and actually shake hands and make sure the two companies are working together. So not only are the people in the trenches working well, we have our executives that are actually kissing and hugging as well, which is great.

So, as far as kissing and hugging goes, performance. I think you'll want to kiss and hug me after we go through this. At least I hope so. What's hot? As Larry alluded to, we're innovating in the area of shared metadata. Well, I don't think he said that, but that's what we're doing.

Basically, in a dynamic language like Java, well, in static languages, all you care about is the instruction stream. That's pretty much all that you share. So DLLs or shared library schemes, all they're concerned with is sharing code, instructions. With a dynamic language, it turns out that metadata or data that describes the program overwhelms the instruction stream.

So the important thing is to share metadata, okay? And we've done that, and I'll show you some numbers. In addition, the more you share, the more launch times improve. The other thing I'd like to talk about is accelerated swing. First, let's look at two applications. Obviously, to talk about sharing, you need to run two things. The two things that we benchmark is running JBuilder, which is a non-trivial big app, and MoneyDance, which is a non-trivial big app. Today with sharing off, when you're using both apps, the working set is roughly 92 megabytes. With sharing, basically, we reduced the working set by 30%. This is significant. This is significant. Again, just because you go to an interpreted dynamic language doesn't mean you throw the baby out with the bathwater. Dynamic shared libraries and code sharing, metadata sharing is something that's been proven and we need it in the Java space, and Apple has done that. Right now, it's primarily focused at sharing the platform classes. We don't right now enable you to share your frameworks, but that's a feature we anticipate adding in the future.

So that's sharing. By the way, I'm running low on time, so I'm going to really have to Zoom, unfortunately. I usually go too fast. Now I'm going too slow. So an industry first. in the Steve Jobs tradition, very dramatic. Hardware accelerated swing is what I'd like to talk about right now.

In the product that we're going to be giving you later this week, it is not the default, okay? However, this support is in there, and if you go to some other talks that are part of the Java track, the guys will hopefully tell you how to enable it, again, if you're nice to them. So accelerated swing, caffeine marks.

Caffeine mark is a micro-benchmark, which we don't particularly like, but everyone else seems to want to measure Java by it. So let's talk about the imaging score. In the past, when we focused on the just-in-time compiler, we have had advancements over the years in some of the low-level compiler jitsi space. We always looked fairly mediocre, if not poor, on imaging and graphics.

But now with the hardware-accelerated swing, basically, we're 8.5 times faster for graphics. Okay? I'm sorry, that was imaging. Now it's graphics. The graphics score is even more impressive. We go from a mark of-- what is that, 200? To-- whoa-- 23 times faster for caffeine marks. So again, we don't really like caffeine marks, but we're showing them because now we do well.

A more interesting benchmark is actually an internal benchmark that-- that's swing-- that Sun has developed to measure swing. So because a lot of the focus of the GUI is now centered around swing and not AWT, measuring how fast swing performance can be is very important. So for swing, our swing mark on a 500 megahertz G4 with a radion is 65. That's the mark.

When we hardware accelerate, we're 55% faster. In this benchmark, unlike the other one, lower is better. An interesting test that the engineers who were working on this decided to do, they said, what if graphics were infinitely fast? So what they did was they stubbed out, so to speak, from Java, the calls to the lower level graphics where they didn't do any drawing at all, And the swing mark was only, what, five points off from where we were when we were doing hardware acceleration. I mean, this is incredible.

So the pendulum swings, right? Oh, the Jitsi's the problem. The garbage collector's the problem. No, we got that right. Now the graphics are the problem. Looks like graphics are going to go away. Well, the pendulum will swing back, and we'll be back to the compiler. So it's an iterative process. The important point is performance is critical, and we're working on it. I'd like to close with development tools.

Core Apple tools, we're investing in tools. Steve told you that. You know that. You have a disk in the bag. Actually, I'm thrilled to say you have three disks in the bag. You have Apple's tools, which I'm responsible for. You have JBuilder, which is a fabulous pure Java development environment.

And you have CodeWarrior early access. So I think at a high level, it seems like Mac 10 is just out of the gate, But you guys have more tools than you've ever had in previous years. Okay? Okay. Again, Steve is very aggressive about wanting you to be on the platform.

Without the tools, you wouldn't be as successful. So I think you have all the tools to be successful. Here's a slide on Apple's tools, web objects you're familiar with. I'm not going to go through this in detail because I have eight minutes left. But there are talks on all these. I think the important point is just what I said. You have the tools to be successful. We have the application server. So again, you could do your rich, swing-based Java app, or you could do the browser UI. Okay?

There's a rich GUI, rich web GUI. Again, Apple uses this stuff so you can be assured that we're eating our own dog food, and if we have problems, we're going to fix them. And it's critical that we find them before you do, typically. So CodeWarrior has Java 2 support, full RAD support. Debugging is much improved for both application and applets. And Java deployment, you folks are mostly familiar with, hopefully, 0G. They have been a great partner for the last three years. They're very easy to work with, give us lots of feedback on the run time, and I think they have some great products, and I hope you agree with that. Java performance analysis. One of the reasons we're getting faster is because we actually have tools to analyze performance now, and this tool is fabulous. It's best of breed. That's another point I need to make.

The dust has settled in the Java tool space. If we were to choose a tool three years ago, we would have probably picked the wrong one. So right now the dust has settled. We are choosing to work specially with the products that I'm referencing here. I'm not just putting them on a slide because the product exists. There are many products that exist. For instance, Forte is Sun's development environment. I hope that's very successful on our platform.

There are other Java development environments. The people who are being called out here are people that Apple has chosen to partner with and give special love and care. So these tools, we think, are the best of breed, basically. So last, I have six minutes left. I'm going to bring up Blake Stone of Borland, someone who supported us for the last two or three years. Thank you. BLAKE STONE: Thank you, Steve.

We're really excited about this. This is something that we've been working hard for the past year. You saw early technology demos last year of JBolder 4, but announced last week is our JBolder 5 product and shipping in all of your bags you have a preview release of JBolder 5. So I hope you have a chance to look at that after the show is over or even during the show. I wanted to talk a little bit about this and some of the path to get here, but we have only a few minutes here. So I'm going to sort of tailor this discussion, I guess, and showcase the product. You'll get just a little bit of a glimpse of what JBuilder 5 is about here. You can see an awful lot more in a couple of other sessions. Wednesday at 10:30, there's a session showcasing a couple of Java-related tools. We'll be there. But there's also a session Wednesday at 5:00 I'd encourage you to come to where we'll showcase JBuilder in a lot more depth and see a lot of what we're going to gloss over very quickly here.

Still, I would like to bring up and showcase a few things, just for those of you who may not be familiar with JBuilder. Of course, we brought it to the Macintosh. Of course, we got a nice Aqua icon for it. It was critical to us to really look like we belong in this environment. In fact, we've done quite a bit of tailoring. And you can't necessarily see all of the details we went through, but everything from the default order of buttons to making sure that Aqua looked right in the environment. These are things we really focused on with JBuilder. So here it is in all its glory, and we'll demo it in Aqua this time around, because Aqua works great. It looks fantastic. It's the right way to work on products on the Macintosh platform. So I have a simple application, our Welcome app, the default that comes up here. And I want to extend that a little bit by taking advantage of a few pieces of the product.

First of all, I'm going to go into our graphical designer, which allows us to do visual manipulation of Java Beans. And so we're going through and looking at this particular application and discovering that what we have here, essentially, is an empty frame. This empty frame we want to use instead of border layout.

Perhaps we want to use an X, Y layout, allow me to position some things, drop a button in place, drop a text field in place. And we get to see our app being designed in Aqua here. That's an option. We could choose if we were designing something for another platform to preview that, but why? So we'll get a scrolling region and perhaps just drop a list in this region as well. I can even work with non-visual components. You can see on the side here, I'm getting a collection of components that I'm manipulating. And all of them so far are visual components. But I could also go in and say, I'd like to select a non-visual component. In this case, I'd like to go find a model for this list. And I can just scroll down and find my default list model.

and drop one of those as well. So now I have a non-visual component that I can interact with by telling it that I'd like my list to use this model that I've created, and then write some code. So the visual designer lets me very quickly assemble the user interface. It doesn't use any proprietary techniques. What it's doing is it's writing Java code for me the way I would write it, using setters and getters. But it then allows me also to drop in and write my custom code. And I might want to write some code here that interact with this default list model. And if I can't remember the name of it, I can ask for some assistance with that. And perhaps I can add an element.

And the element I will get from a-- see, we have a text field on here, jTextField. I'll just go ahead and get the text from it and compile that. One of the things that's really critical to us is fast compile time. We've got an integrated compiler that does incremental compiles through a smart dependency checker so that even on large projects, and I mean enormous projects, JBuilder itself consists of more classes than the entire JDK. And we can do an incremental compile in under 10 seconds. So speed, again, is critical to us. We can go right from there to being able to actually run this code. And we'll take a shortcut here and jump right into even debugging this code. So it'll do a quick dependency check to make sure that nothing's been changed. We'll get the debugger UI up, and we'll launch our Java swing application here.

where I can type some text in, click the button to add it, and we hit a break point. So we have a pure Java debugger here that has a really rich set of capabilities. Now, we're not going to be able to look at them all here. Again, I encourage you to come to another session. But if I want to find things out about this text field, I've got access to a really rich UI that allows me to browse that object and all of its characteristics, the class it belongs to, and so forth.

So that's pretty exciting in its own way, because we've got a real best-of-breed development environment here, running on Mac OS X, letting me do all of my work on my favorite platform. By the way, that's not just marketing speak. Long-time Apple fan, you may be able to tell that I wear the colors here. I've been a believer for a long time, and this is like coming home for me. But there are a lot of other interesting things that showcase the power of the environment that we're working on. We're working on an environment that has a ton of very sophisticated integration with the native environment. JBuilder is probably the worst torture test you could throw at a Java VM, because not only are we a fast editor, a graphical environment, a debugger, which is one of the nastier areas in porting the Java VM, but also we just include a whole bunch of functionality. So one of the things I wanted to showcase is if we go and look at our release notes, we'll bring them up in our integrated HTML viewer.

Well, if you're not really too fond of the HTML viewer you're using currently, you may want to note that this particular viewer you can just type a URL into, and from within JBuilder, browse directly to the web. And the performance is-- and get completely reasonable performance. Now for sort of the surprise. All of this is running without hardware acceleration. So the hardware acceleration makes things enormously faster. Let's showcase perhaps one of the worst case examples of what happens without the hardware acceleration. If I grab and move this split, you can see that the performance is perhaps not what we would hope for. Let's see what that's like with hardware acceleration on.

So I'm going to come down and go find my collection of JBuilder icons. And I'm sorry, I absolutely have to. We spent enough time on the artwork for these. We really wanted to get that photorealistic icon thing down pat here. And go in and have a look. I've got a couple of configuration files that if you go ahead and register your version of JBuilder that's in your bag, you'll find that we provide you tips. So once you can get the new Java VM from Apple and please get the new Java VM from Apple. JBuilder really benefits from a lot of the work these guys have been putting into it. We'll show you how to make these kinds of changes to turn on things like the hardware graphics acceleration in the license email you get. So we'll bring JBuilder back up and have a look at the kind of difference it makes and sort of that one key indicator, which is dragging that splitter. So if you remember before, we were getting sort of a frame or two a second, and now with hardware acceleration, it's smooth.

Why don't you go to the web page? Go to the web page. Can you go to the web page? Oh, yeah, we can actually-- sure. That's just a text view. Let's bring up something with graphics. So you got a favorite page in mind? No. Well, why don't we go back to the Mac OS X page from Apple's side here. So look at that. The scrolling performance, you'll find, is remarkable.

We're really pleased with what hardware acceleration can do. And I would like to take this opportunity to thank many of you in the audience who worked on this and have been working on it very hard. The Java team at Apple has been doing a phenomenal job, and we've been really proud to be working with them. Thank you, Steve. Thank you.

pretty much out of time. I think I've said a lot today, which is why I'm out of time, along with my great demoers and speakers. So I just want to touch on the important points. The important points are what we ship with MAC-10 we're very proud of. We're actively working to make it a lot better. And we've talked about some of that. We think we're going to have the best platform on the planet for running Java. And you've seen applications today that all work very well. And we hope to bring the hardware acceleration to you guys in a timely fashion. And I guess that's all I have. I have a bunch of tracks here. There's the Java Virtual Machine track, or session, I should say, Wrapping Mac OS APIs in Java Beans, Java Development Tools, Java Performance, JBuilder. There's another five sessions. Since we didn't have time today to take Q&A, given the length of the talk, feel free to come to the Java Feedback Forum on Friday and we'll hope to answer any questions you have. Thanks for coming. Take care.