Well, good afternoon. Actually, I am not Steve Naroff. For those of you who know me, and for those of you who don't, I'm Alan Samuel, the Java Technology Manager in Apple Worldwide Developer Relations. So I think I'm in a very good mood today. You guys probably all know why. I actually get to stand up here and hopefully tell you what you want to hear.

I'm one of those people who's probably gotten a lot of emails from you in the crowd asking me when are we going to have Java 2? And for the first time we're really able to go out publicly and as you saw today in the keynote give you what you want and talk to you a little bit about what we're doing with Java 2.

And before I bring up Steve, I just want to go ahead and Put a general thank you out to all the engineers that work on Java at Apple. I think these guys have basically gone a long way. We've come from a situation where you could say in the MRJ land, maybe we weren't doing as good as we'd like to be.

And I think we are in a prime position to be a leader in the Java platform. And I think today's the day we start to tell you all the information that you need to make that happen. So I want to give a little hand to the entire Java team.

I want to take a quick poll. How many folks were here last year? Quite a few. At the Java talk, not only WWDC? Okay, great. You know where we've come from, so I won't belabor it too much. As Alan said, the team has really come together, not only the engineering team, but the developer support team, Alan and his folks, that help a lot of you guys before we get a chance to help a lot of you guys.

So I think all across the company we've pulled together and made Java actually pretty relevant in the Apple community, and I think it's just going to get better and better. You saw in the keynote that we're going to be offering Java 2 on Mac OS X. It's a great fit.

The Mac OS X platform is a great foundation for Java. A lot of the modern components of the operating system are components that Java really depends on, like the preemptive, multitasking, protected memory, all that good stuff. You've heard a lot of the features in Bertrand's talk, I'm sure. I think most of you attended that. Java was developed on Unix in a modern operating system, so again, it benefits us as we move the technology forward to be on a modern operating system and have modern underpinnings.

The Java that we're going to be shipping is Java 2 Standard Edition. Later on I'll talk a little bit more about what that means. The Swing UI toolkit is built into the Standard Edition, if you aren't aware of that. Swing is the modern GUI toolkit that people use to write Java applications. AWT was a smaller UI toolkit that was used primarily for applets. The two coexist right now in the Java 2 Standard Edition. We've done a lot to integrate with Aqua.

The demo that you saw on stage with WebObjects, that UI was a Swing application. It was a pure Java Swing, Java 2 Standard Edition application. It wasn't Cocoa, for instance. That user interface work was done by a very talented person we have working on our staff from Sun, named Leanne Rucker. I know she worked really hard with the WebObjects team to get that demo together.

and last and definitely not least, we have the Hotspot Client VM. This is an extremely robust VM that in many cases is a second or third generation technology. The garbage collection technology in it is state of the art. The compiler in it is state of the art. We'll go through some numbers later. The team, Ivan Posva, Jim Lasky, are our two leads on that project.

Just incredible results with the Hotspot technology. It was the type of decision that we were contemplating last year. I think we talked about that. We were disappointed that we couldn't tell you that we were going to commit to it. That's because we didn't know last year. It's amazing how well that technology has worked out for us. Now we'll go through a brief timeline.

In February of '99, right before last year's WWDC, we shipped MRJ 2.1 GM. And that was the first release of Java that I think the team felt proud of. We felt proud of it because it performed fairly well. It didn't exceed our expectations, but I think met our expectations in many ways.

But more importantly, it ran a lot of applications. And that's something that MRJ 2.0 was not doing. It was not running a lot of applications. It was crashing and it was dying and it just wasn't the type of robust platform that we all wanted. So 2.1 was a real breakthrough for us. I think it delivered on the strategy we outlined in '98.

and it's interesting because when I stood up here in '98, I was trying to think how could I put in perspective for you guys. I felt about four feet tall when I stood up here in '98. And last year I felt 5'7", which is actually what I am.

And because we delivered on a strategy, we still weren't happy with where we were, but we knew where we were going. This year I feel 7' tall and you can tell I'm not 7' tall, but I feel that way. And I feel that way because again, I'm standing on the shoulders of some really great people that make it fun to come to work every day, frankly.

Another part of the strategy we delivered on is we wanted to give you incremental releases that fixed incremental bugs and solved incremental performance problems. So we did a release in March, May, and July. And that was another promise that I think we've done a good job delivering on or keeping, was that we didn't want to go dark for nine months. And that was a problem before, that we would just wait too long before we'd show incremental progress. So I thank the team for working hard on those incremental releases.

And those are driven by emails, bugs, customer requests. I really feel that we do a pretty good job trying to prioritize what we're hearing from you and building it into the product. If not, you need to get a hold of our, if there are features that you've requested or bugs that you haven't seen fixed throughout the dot releases that we've released, you just need to get a hold of Alan or our developer support team and make sure that feedback gets back to us. So along with the 2.1.1. 1.3, we shipped 2.2 alpha.

and 214 was the last of our 2.1 based releases. The milestone there was we met Oracle Bronze Certification. We've been working really closely with Oracle because they're a very heavy Java user and they want to make sure their applications run really great on our platform. We've, again, worked closely with them to make that happen.

So in October, we released DP2. That was our first Java 2-based VM. So that's when, even though we made no public statements about where we're going with Java 2, folks looked under the covers and started figuring it out for themselves. And we did a 2.2 beta. And then in January, we went GM with 2.2. 2.2 was our, for lack of a better term, IE 5.0 release. We did fix bugs outside IE 5.0, but it really was targeted at giving the user or developer a better experience within the scope of IE 5.0.

and then we did DP3, which added the classes. It was our first release. There were still a lot of bugs in it. Here we're at DP4, and the big addition is the Hotspot client, and many, many bug fixes to the Java classes, which we released in DP3. That's been the progression. It's been a lot of work. We actually combined our Java 2 MRJ team with our Mac 10 Java team, so now we're one Java team. I think the productivity enhancements we've gotten from even making that change has been pretty dramatic.

Again, I'm thrilled with the last year. I think a lot of people working on the team look back and are probably startled with how much we actually accomplished. So before I go into the crux of the talk, which is centered around Mac 10, I'd like to briefly go over our currently shipping product.

It's MRJ 2.2. I believe the latest version, minor version, is MRJ 2.2.1, and it integrates with the IE5 networking stack. Cabinet File Support, Cookie Support, Applicaching, all these features you're probably aware of if you've been using the product. How many people are using 2.2 right now? Okay, so you're familiar with it. And we added along file name support.

So that's our Mac 9 product, and we're going to continue to enhance it along the 118 code base. And now I'd like to go into the crux of the talk, which centers around a three-mug strategy. Cutesy. So we have performance.

So SpecJVM 98 is the benchmark we're currently using.

You might remember in previous years, we were using caffeine marks. We decided, along with a lot of other folks in the industry, that caffeine marks are not a great measure of performance. So we decided to look for a benchmark which would meet our needs, and in fact came up with the SpecJVM 98 benchmark. These performance numbers I'm going to show you are for DP4.

Just to be clear, the numbers you're seeing here are not seconds. They're a score. So it's a score that the spec JVM benchmark gives you, and higher is better, as you might imagine. And right here we have the orange, which is basically the interpreter running without the compiler. So the classic Java Virtual Machine prior to Hotspot was running at 1.8.

The interpreted Hotspot runs at 2.6, which is roughly a 50% increase. And you can see the green is the compiler. The compiler in both cases runs roughly 10 times faster than the interpreted code. But what's much more important and compelling than the 50% boost we get is the amazing, amazing reduction in memory. Amazing reduction in memory.

Taking pages off disk is very costly. It's clear that even though we've upgraded most Macs with 64MB now, asking people to have upwards to 128 and 256MB is not appropriate. We want to find ways to make Java programs run in a sensible footprint. So what this graph tells you is it only costs 7MB to run this benchmark in compiled mode.

And that 7MB not only includes the compiled data structures, but it includes the data structures for the compiler itself to do its job. And it's going to be, I think, roughly 40-60, 50-50 split. But in any event, from my perspective, that's a reasonable price to pay for compilation.

And if you do the math, it's 4.5 times smaller. And we've seen this translate into not only our benchmarks, but all the applications we're running use far less memory than they used to. So we're extremely excited about this. It's only DP4. We still have a lot of tweaking to do.

But we still feel fairly confident that we're heading in the right direction. The thing that... Just briefly about adaptive compilation technology, the reason it's so much less is in the semantic JIT world where you're running in a classic virtual machine, what the compiler tries to do is compile everything.

That's its goal in life, to try and make everything fast. What happens with a hotspot adaptive technology is it measures itself. As the program's running, it tries hard to only compile the things that matter and not compile the things that don't matter. An obvious example of something that doesn't matter is an initialized method. There are obviously lots of other methods that are used once, twice, maybe used a lot for, let's say, printing, but then printing gets swapped out and you don't need it anymore. The hotspot adaptive compilation system is always measuring to make sure that it's compiling the right stuff.

and SpecJVM is measuring. It's basically a suite of applications. I think it's six altogether. Database, the Java compiler. I think our Java compiler is two to three times faster now as a result of Hotspot. There's a compiler compiler for Purdue in there. There's data compression, an expert system shell, and MPEG audio decompression.

So you can see these are applications that most of you have probably heard of. Certainly you know Java. The Java compiler, you've heard of database, you've heard of compiler compilers, data compression. All this stuff is stuff that benefits real world applications that are being used out in the Java community.

So what do we have left? Hotspot tuning. This is our first release. Even though we're happy, we still have a ways to go. Graphics Tuning. Especially AWT, there's still some issues with how we integrate with Quartz and the windowing system that we need to resolve before we're really happy with our AWT graphics performance. We're fairly happy with the swing performance, and you'll see a demo later that I think will show you that we're in pretty good shape with swing, yet we still have some work to do there.

This is a feature which I've been persistent about for years, and I think we're finally getting to the point we're going to have it, I believe, hopefully by GM, is the ability to run multiple Java applications and share a lot of its metadata. It turns out that if you look at a class file, the instruction stream is only a small part of what makes up a .class file.

There's an awful lot of metadata in there, and if you don't share that metadata across invocations of a Java VM, then you could end up eating lots and lots of memory, especially for something like Swing. It's a fairly large UI toolkit. So, again, imagine running five Java applications. You want them to share as much data as possible, again, to get the footprint down.

And last and not least, launch time. We're very adamant that applications have to launch in a fairly sensible timeframe, where sensible is between one and five seconds. And we have some very large Java apps we're running now that take about ten seconds on Mac OS X. And again, we'll show you that. We hope to get that down to five seconds. But it's certainly a long way from where we've come, where some Java applications on MRJ on Mac 9 could take as much as 30 seconds, 30, 40, 50 seconds.

Here's a quick pointer. Three incredibly talented people, two in the VM space, and one graphics nut, John Berkey. Why does it say Jim Berkey? Did I say Jim?

Compatibility. This section of the talk is mostly Sun stuff, but I still think it's important to review with you.

If you haven't kept up with the Java lingo, when they went to Java 2, they defined a whole new process, they defined a whole new set of terms, and so on. And a lot of that was actually good, but it takes some getting used to. And standard edition is called J2SE, that's the acronym that a lot of people use.

There's a micro edition, and there's an enterprise edition. Right now, we're focusing on the orange, which is the standard edition. I think it might be better termed desktop, so that's why I put that up. The micro edition is probably better termed embedded, and you can think of the enterprise edition as the server.

So since desktop is our focus at Apple, we want to be great on the desktop, and then potentially worry about some of the other editions. Web objects, for instance, might take some components from J2EE, like Java beans, but might not support the whole stack in its entirety. Those are decisions that we have yet to make.

So, key features. Swing interface objects, I guess one of the more compelling features of Swing is it supports multiple platform look and feels, and we'll get into that later. Java 2D, advanced graphics support. The Java 2D API is actually very similar and supports a similar feature set to Quartz. And, in fact, our implementation on Mac 10 relies heavily on Quartz. There's new collection classes.

Drag and drop is a feature that I believe we have in our MRJ. We put that in as a stopgap. It was modeled after the Java 2 support, so now we're just relying on the standard drag and drop that Java 2 supports. We have print support and improved font and international text.

There's a very fancy policy-based security mechanism. There's Corva support. For those who are unfamiliar with Corva, Corva is a way for other languages and other processes to talk to Java and vice versa. Many people are using that technology in the enterprise. A really cool feature of Java 2 is they've really taken each subcomponent of the VM and made some nice APIs to it.

For instance, there's a JNI.h JVM. These are all interfaces which, if you wanted to plug your own VM into our implementation, you could. I don't anticipate that most of you are going to go to the trouble of implementing your own VM, but some of you may plug into the debugger or the profile interface. That enables you to basically write GUI-based tools atop our VM for profiling and debugging and so on. For instance, those are the APIs that MetroWorks, CodeWarrior, Project Builder, and so on and so forth use. Sound support.

and a ton of other stuff. It's huge. Talking about that. 1.1.8 is a set of 23 packages, about 5,000 members. Java 2 Standard Edition is a huge platform. It offers a ton of functionality. We went through this last year, people who were here. It contains about three times more APIs.

Now, whenever you do that big a release where you've expanded the API surface area by three times and you've made all kinds of changes, you're undoubtedly going to break people. That's one of the concerns that people had in the Java community is as they take their 1.1 apps, it can be challenging to find the compatibility differences, particularly in the AWT area.

This is an issue that we're working on with Sun. All the licensees are working on with Sun. I don't think Sun will ever make that big a leap. That is, add three times more APIs at one step. I think they've learned their lesson, so to speak, and the releases that will be coming out now will be more of an incremental fashion. Again, it's just more sensible to incrementally release these APIs rather than go to 3X overnight. As a result, mission-critical applications have been slow to move.

There's a very good 15-page document on the web. If you're interested and concerned about moving your 1.1 code to 2.0, reference this document. It has a ton of great information on what the source level, binary, and other types of changes that you're likely to encounter. And in general, new Java applications are targeting the Java 2 platform. Applets aren't being written to Java 2 in general.

So we test our Java product with something called the JCK, the Java Conformance Kit or Compliance Kit from Sun. And we're obligated as licensees to pass it. But what's much more compelling to me is how many real world applications we run. So for instance, Oracle has 40,000 test suites. We currently pass their tests as well and are continuing to work with them on passing even more tests. Charles Schwab has this really cool trading app.

It was advertised in this guy over here. It's called Velocity. Anyway. But it's our first example of a shrink-wrapped Java app that actually people are using day to day, in this case for trading stocks, a pretty mission critical thing, if that's what you want to do. And it's... That's worked incredibly well. We're extremely happy with the reliability of that product as well, and they've been great to work with.

And SAP is another company we're working closely with to make sure their enterprise applications are working really well. We're getting a lot of testing, and it's really neat to see how relevant actually this Java technology has become in the enterprise space. So with that in mind, I'd like to bring up someone from Oracle. His name is Peter Heller. Thanks, Peter.

Okay. Our apps, this is, excuse me, there's actually just one great word, which is finally. We've been working, I've been working with Apple on trying to get our apps running on their Mac platform and a variety of hardware OSs in the past for, I think, three or four years. So we've finally actually been able to achieve this with the most recent release.

If you don't know Oracle apps, Oracle apps are basically mission critical enterprise apps dealing with financials and manufacturing and CRM applications, call centers, sales force automation, all these different things. There are 70 in total. And our co-markets really are the university market and a lot of creative services firms, people that are, obviously have Mac as a dedicated platform.

And they also want to run their standard business apps. They don't want to have to have them sit side by side with PCs. So we have actually, I think easily, a hundred million dollars of potential revenue that we could probably earn, we will probably earn as we move forward into this space. So that's a great opportunity for you as well. What I thought I'd do is just show you a little bit about our apps.

If we can switch to the system. This is, these apps are built with Oracle's Jade, with Oracle's developer tool, which is a 4GL style tool and it runs now on the Mac platform. So what we're looking at here is, this is just going to be a quick general ledger example, but basically what we have is a process flow navigator.

So users as they want to do transactions, whether it's purchasing or general ledger or manufacturing or billing or whatever, they have a kind of a map that they can walk through as they go through the transactions. So one of the things that we can do here is, for instance, let's say we were going to reclassify our revenue.

As we move through these maps, you get a little green line. You can see that we have a map that says, "I'm going to go through this. I'm going to go through this." And then you can see that we have a map that says, "I'm The App comes up relatively quickly. I guess I should also mention the environment here.

All we've got here running is Internet Explorer with the standard Apple MRJ, and all of our apps and everything is across the network at Oracle Corporate. What we have here is basically a way to look at information. For all our journal entries, we can resize some columns, we can add and subtract some things. Let's just quickly do a journal entry to show you.

I want you to see part of the modified or enhanced AWT is you see the whole screen just pop at once because all the objects are being laid down in memory before they're being displayed. So what we can do is we can do a quick transaction here. If I can type without my fingers here.

So we can kind of go down here. One of the characteristics of a Java app for us is what we call high volume productivity. One of the key elements-- we have two product strategies or design points, if you will, for our apps. We have what we call a self-service design point, which is generally characterized as HTML, easy to use, single click, that kind of thing. We're all familiar with it.

And placed in the hands of completely untrained users. The other audience, what we would call the professional clerk, is somebody that actually demands high productivity apps. They're sitting down. Their whole job is doing nothing but keying in data all day long. And what they have-- some of their requirements are things that only Java can handle. Things like type ahead.

Things like when you're looking for a list of values, the windows pop up in the context of the screen. Having keyboard equivalents. There's actually a large number of things, as you probably have made choices yourself, about what's good for Java versus what's good for HTML. And of course, we have Java embedded in HTML as well. But these are the core, what we would call, heads down administrative apps. So you get certain kinds of dialogues popping up.

And all sorts of keyboard equivalents here. I'll just show you some of our UI here. What we're going to do is-- We're going to move product revenue from-- let's see here. I have to find my accounts here.

from unearned revenue, we're going to go to miscellaneous revenue, and we just so happen--oops, an error message there.

Product X, which means Mac 10. So we're going to go with that, and we're going to put in

Okay. So basically we do a transaction. We interact with it a little bit. We go ahead and post the transaction. Oh, tells me it did it. and it gives me a tracking number and basically the transaction is done. That's kind of an interactive experience for a production user. What I can do now is just show you as we go down through the process map.

What we want to do is as we go through the process and post the journals, then you end up seeing the continuousness of the process. It's a great way to write apps, and it's a great way to build them modularly, and based on different kinds of control points that businesses need, this is a really nice user interface to break up big apps into functional components and do stuff.

That's just the marketing of our own products. Basically, that's what I wanted to show, which is our developer product. This product actually is the development tool for roughly 7,000 of these products that cover 70 modules. It's a very big app, and it's Oracle's premier application. Thanks, Steve. Thanks a lot. Okay.

So I know there are folks out there saying, "Well, that doesn't look like a Macintosh UI." That's not the idea. The idea for Oracle is--and people could argue with this, but at least it's their goal to have a branded UI, and for them to have a UI that works the same across multiple operating systems.

And in fact, Oracle spends quite a bit of time making sure their app does have the Oracle branded look and feel. So that's, in a nutshell, why it looks different. And again, that's one of the goals of the platform, the Java 2 UI toolkit, is to allow you to have the branded UI if that's what you want.

So I don't know how many of you folks caught it, but there was a release, press release, April 14th, that talks about Sun working closely with some Blue Ribbon vendors. Fortunately, Apple was one of them. There's been a lot of frustration in the Java community, some of you are probably aware of this, with Sun's attempt, or lack thereof, to standardize Java.

There was an ANSI attempt, there was an ECMA attempt, and now the third pitch, so to speak, is this new JCP 2.0. And we've been working closely with them to make sure this is a sensible process, which will benefit Apple, as well as the other companies, and actually as well as individuals who might want to get their say in as well. So I think this process is actually looking pretty good, and it's still evolving. But the good news is we're at the table.

The other press release, as far as Java compatibility is concerned, is they just released 1.3, which is the hotspot client VM that actually we're shipping. It's the same hotspot client VM we're shipping in DP4, but we haven't integrated all the 1.3 stuff yet. So the release that you're getting is based on somewhere in the middle between 1.2.2 and 1.3.

But by the time we go GM, we will upgrade to 1.3 entirely, which is the current shipping standard. We currently pass 96% of the JCK tests, I'm told, for a beta product. I'm pretty happy with that, so we have 4% left that we'll nail by the time we go GM.

and Sun really did listen to their customers for 1.3. Again, they got a little bit burned by the big gulp they asked everyone to take with 1.2, and 1.3 is almost entirely performance and compatibility focused. It has almost no new features and has about the same footprint as the previous version.

So another demo. The first demo might have been obvious, but again, it's MRJ 2.2 running on a Mac 9 platform. The demo I want to give now is ask Blake Stone, an incredibly talented engineer from InPrize, to come up and give a demo on Java 2 on 10.

Thanks, Dave. Before we launch into this, I have to clarify a few things. We're going to be showcasing some fairly interesting technology here. At this point, it is a technology demo. We're obviously working with early technology from Apple in the form of DP4. We're working with technology of our own. But we haven't announced any products at this point, so I'd like to remind people of that before things get too excited. But it is interesting to note what we've been doing.

What we've been doing is we've been working with a partner who is extremely interested in building a premier Java 2 platform, in building technology that makes Java developers sit up and take notice. So that attracts our attention. After all, we have some absolute world-beating products in that area as well, and so there's some natural synergy.

And we thought this is an opportunity to see how they work with partners and how that process might work out. And to be honest, it's been exceptional. I've been very responsive to our need to work with partners. And I've been very interested in working with them. And I've been very interested in working with them. And I've been very interested in working with them. And I've been very interested in working with them. And I've been very interested in working with them. And I've been very interested in working with them.

And I've been very interested our need for performance tweaks, our need for fixes in some areas. In fact, just the last session I was in with John Berkey, I saw him in the row ahead of me, busy trying to tweak a few last things to make the product even faster.

I'm not going to take the chance and run with those fixes here on stage, but just so you know, that kind of thing is ongoing, we're getting better and better performance. So what is it that I'm talking about? Of course, what I'm talking about is JBuilder. So if we can switch to the machine over here.

and bring it up. I'd like to have a look at a product that consists of about 5,000 classes. So you saw the statistics on Java 2 itself. This is enormous. In terms of code bulk, our product is actually larger than the JDK in terms of the amount of Java code involved. So will it run on this new platform in a preview stage? Well, we'll hope so. This is a demo after all. We'll see just how far we can get. But I'd like to showcase some of what you can do with a pure Java application.

For those of you who aren't familiar, JBuilder is a Java development IDE. And as such, it has a lot of what you'd normally expect, the ability to create and manipulate projects, edit code, and so forth. And I'm going to start with a new project and just bring up some of the wizards that we have for manipulating projects in our environment. Let the system swap itself back in.

This is always the way I like demonstrations to begin. We'll see if this doesn't behave well for us, we'll restart the product. Of course, this all went incredibly well in rehearsals. So some of what was being talked about earlier is the launch performance for Java applications. So we'll get an ideal opportunity to demonstrate that here. Launch performance for a Java application, of course, is critical. And a lot of what we're seeing is a very expensive startup process in terms of loading the imaging and so forth at the basic class libraries.

But really, the launch time for the product is not bad. It's actually faster than a lot of native applications on the platform, which has got us quite gratified. So from there, we're going to go ahead and start off with our new project. So we built a new project here.

Within that project, I'm going to request that we go ahead and build an application. And it will give us a couple of the sort of basic application starting point and a frame and bring us into the editor in this environment. What's interesting here to note is that we're running a pure Java application. The editor isn't some piece of native code in the environment.

The editor is actually written in Java code. And as such, you'd expect it to exhibit performance problems. But in practice, things like syntax highlighting, noticing with a keystroke that the contents is changed into a comment is incredibly quick. The ability of the environment to keep up with structural changes is quite amazing as well.

What you're seeing on the left-hand side here is a structure pane showing me the structure of my file. But I have a single class with a number of elements declared. If I were to go in and declare a new structure element, it just shows up in a list. So we're parsing behind the scenes to try to give us the information. So we can see the information about what is in our particular file here.

And we can browse We're also getting additional information on the fly because we're parsing the Java code in the background. If I make a mistake in my code and just keep working, it'll notify me by showcasing that there are errors in my code and allow me to go directly to that line of code so I can fix my error on the fly. So we're not waiting for compile time to catch that kind of thing. It's an extraordinarily productive environment.

So I like to start with that as a starting point and go ahead and try to build something. But of course, when you're building something, what you'd really like to be able to do is use a visual layout to work with Java Bean. So I'm going to move over to the designer here. And in the design environment, we have the ability to place Java Beans. I'm going to use swing components. After all, they are more or less standard Java Beans, and they'll allow me to prototype a UI fairly rapidly.

For those of you coming from an environment where I hear lots of concerns about layouts, is there enough space on my layout to accommodate this change? Well, if you're a Java developer, you know that there's some extremely sophisticated technology for dealing with layouts, but it can be quite difficult to learn. So it's easiest to start in sort of a raw positioning, an XY layout mode. I'm going to go ahead and use XY layout to place a scrolling region.

and within that scrolling region and go ahead and drop back a list and i want to drop in couple buttons and I want to drop in a text field. And then we'll go ahead and write some code. What's interesting is that I have been writing code all along. Everything I do in here, every time I drop a component, every time I edit something, it's writing Java source code. So you can see behind the scenes that it's written source code here to set the text on the buttons and so forth.

What's unique about our approach is that we don't deal with this as a code generation or one-way technology. We don't block this off from your editing. We treat this as a fully two-way tool where I can go ahead and modify my source code and then drop back into design mode and you'll see that those changes are reflected immediately in my design. It's actually parsing and executing the source.

So we'll make a few more adjustments to my layout here. And once I've got the layout more or less the way I want it, of course, this gives me absolute positioning, which when I scale things or change the text on buttons isn't going to work for internationalization. So I'd like to change it to a grid bag layout. So what do I need to do? I need to tell it to change to a grid bag layout. And what's happened is behind the scenes, it's figured out the optimal grid bag layout to use for that positioning.

So as I internationalize this, excuse my internationalization, we'll see the automatic adjustments that are taking place. So I've got the basic layout in place, and I'd like to go and add a little bit of code behind the scenes. And, of course, we can just wire events up. I'd like to go ahead and wire up an add item.

And immediately I discover I want to add an item to a list. Swing lists are a little awkward. You need a model. You need to wire up the model, and so forth. That's fine. This is fully two-way. We can drop back into our designer and pick up a swing model using our class browser.

You'll notice that our class browser knows about comApple classes. It's because it's dynamically discovering from the class path what classes are available. So if you add third party classes or switch to a different version of the VM, we'll automatically adapt to that additional technology. But let's go in right now and pick up the JavaX swing. And I'm going to use the default list model, if I can find it.

and so I'm going to drop a default list model in place, take my JList and wire the model up, and now I've established a relationship between those two and I can do something interesting in code with them. What I'd like to do in code is go ahead and add something to that list model.

Do I remember the name of the list model? No, heavens. It's a list, default list model something. So I'm going to invoke Code Insight, which is a technology that, from within this context, tells me here are the things I can legally refer to. In this case it knows about default list model one because within this scope it's visible.

So, okay, I want to use default list model one. What do I want to do with it? Well, now it's reevaluated that scope and said, here are the available methods. And there is, in fact, something called add element. And for add element, it's gone and checked and there's only one overloading of that method.

It takes one parameter of type object and it's even gone to the source code for that method to find the name of the parameter, obj. And it's kind of convenient. So we'll go through and pick up the jtext field, this jtext field one. And again, use Code Insight to find get text.

It takes either no parameters or an offset in the length, but that sounds fine to me. We'll go to the next step, which is that I want to wire up the delete button to go ahead and delete the selected item. Okay. So it looks vaguely similar, but what I really need to do is I need to find out the, the position of the selected item. And I can do this from the list.

There's a get selected index. But what does that return if there's no selection? Well, if I can't remember offhand, I can simply select with a single keystroke that I'd like to go and find the declaration for that method. It found the source code where I can see the Java doc, see offhand that it returns negative one if there's no selected item, and just use the browser style controls to navigate back to where I was writing my source code.

So this database, we can see how much object allocation is working within the file. We can see a bunch of the tables that are available within the tables. We can see indexes and so forth. So we have this full management interface. Again, the management interface itself, of course, is written in Java.

So we've got a database to connect to. Let's go ahead and use an existing connection to this JDataStore database. Test that connection to make sure, again, the database is up and running and that we can connect to it without any problems. Probably shut the database down helpfully by quitting that prior application. And then go ahead and connect a query to it. And so we have a nice little component that represents a query. Let's see. Hang on.

and connect the query to our existing database, use our built-in SQL builder to go and find a table within that, grab all of the columns from the table. We can see the SQLs that it's automatically generated on our behalf, and we have a query. Fine, but we need to connect that to visual information. That's fine. We have components for that as well. I'm actually going to just use border layout : I'm going to do my work here.

Drop a scrolling region and a table, and how much code have I written so far? Well, I can connect to this database and get live data at design time and at runtime without writing a single line of code. And we'll take that a step further, drop in a and the navigation interface as well, and connect those both to the same data set. So now I have an application that I'm going to go ahead and compile and run. And I'm going will go ahead and connect to the database and see what Xero code can do in terms of database connectivity with Java.

: Excuse me, launch time again. It takes a moment for it to come up and actually connect to the database in the background. But what we'll have here is a UI that allows me to view that information, manipulate information, navigate through it, et cetera. So we can navigate.

We can, of course, resize columns. We can reorder columns. If I want to change the name of somebody here, I can change it. We can see in the status area that I am editing a row. Normally the status area shows us what record we're on. We can commit those changes back to the database, all without writing a single line of code.

So that's fine. That's dandy. What we've got is the ability to be extremely productive at dealing with Java code in this environment, but you wouldn't have much of a full-featured IDE if you didn't have a debugger. So I'd like to take a quick tour of the debugger, if we're doing okay on time here. I have no idea, to be honest. Basically, I'd like to bring up a basic application, place a breakpoint in it, and we'll go in and launch the debugger.

Our little application here performs some basic console UI. In this case, it's going to prompt me for my name before hitting that breakpoint, and then stops when it hits the breakpoint, of course. At that point, I'd like to be able to see the context that I'm in. So I can see that I am stopped at a thread called main in the main thread group, which is in the system thread group, and that there are two stack frames here.

I called from the main method into the go method, and I can see in the go method that I can see the this reference, drill down into that, see the class that it belongs to, any of that class's parent classes and static members. I can see other variables in context, like this first, what have you. We have some interesting convenience functionality for allowing you to manipulate information as well. I can actually go and change values on the fly in an application I'm debugging.

Steve Naroff For example, if I see that I'm in the main thread group, and I step past this line that prints my name, I could go and even change a string value on the fly and say the new string value... I got focus in the wrong place Of course, we are running on beta software. Please expect a few quirks along the way. So we can change string values, integer values within the debugger. We can also do things that are quite unusual for a debugger, like create a field breakpoint.

What's a field breakpoint? It's going to tell me every time it tries to reference this particular variable. So I'm going to continue my execution here, and we'll see that it has stopped automatically at this line, which is referring to name, and given me the message, "Stopped at breakpoint reading debug me name." In fact, we can go and select for that field breakpoint individually, whether it should break on reads of that variable or break on writes of that variable. So an enormous amount of flexibility.

I'd like to do one last look, because Java takes a serious look at what it takes to do multi-threaded applications. There's language support built right in for multi-threading. So what happens when we go to debug a multi-threaded application? Well, it adds a whole new set of problems, because we need to be able to keep track of what locks are being acquired. In this case, I'm acquiring two locks on a thread, and our debugger will actually show you the monitors. It'll show you what the object is that's locked, and what thread is locking it.

And as I proceed a little further here and get three threads, we can see situations where this object is owned by one thread, there's another thread waiting on it, so that we can see situations where we're getting multiple threads cooperating here, and go a step further to situations where our entire application has locked up on us. And by pausing it, we can see that it's highlighted these two as the cause of the deadlock that is currently active in my system.

I can tell we're running a little low on time here, I suspect. But I would like to take this time to really point out that what we've taken here is, again, an enormous Java application and brought it over to the Mac OS X platform. And while it would be natural to say, what kind of porting work did you do to bring it here, the porting work we've done is working with Apple to tell them what issues we've run into in terms of compatibility with their VM. Not a single line of code has changed from our shipping product. This is the product you can purchase today on a number of other platforms. So that's really exciting from our perspective. We're looking forward to moving a little further with this technology. Incredible. Thank you. Incredible.

Well, that demo blows me away. You guys were a little quiet. Didn't it blow you away, too? Again, it's the best way for me to show you how real Java 2 is on Mac 10. This thing is a torture test for the Java VM. I think Sun uses it internally to make sure their stuff runs every time they make a change. Again, it's not a shipping product.

It's not perfect yet, but considering how much work was done on Enprise's part, it's just incredible how far we are. The person on our end who actually helped get it to this point and really owned this is John Berkey. John, could you stand up for a second? In fact, last year at WWDC when I got off the stage, Blake introduced himself and told me they were doing this work and asked if we were going to have Java 2.

And I said, "Yes, we're working on it." And then went back to the shop and just informally said to the folks, "We have to make sure this stuff works for next WWDC." And to see it working now again is really great. At that time, it wasn't even a product. You would come and show me the product later on.

And actually, I gave Avi a demo as well because it was the first large, pure Java application we had seen running on Windows at the time that looked like a great application. It wasn't slow. It didn't look funny, and so on and so forth. Whereas a lot of the other IDEs and products in the Java space were typically not of the fit and finish that we typically expect at Apple.

Let me find my beeper. I think it's in my pocket. The last part of the talk, we have 15 minutes left. And because this is an overview talk, we're advised not to do Q&A. So I don't think we're going to have any time to do Q&A today. So I urge any of you, if you have any questions on this stuff, either go see the other talks about Java or come to our feedback forum, which we'll talk about later. So now I'd like to talk about the third mug. which is integration.

by far this is the most important thing we're doing at Apple is integrating this in a sensible integrating Java in a sensible way. What does that mean? From my perspective, Windows deployment is totally busted now because again, Sun has made this big leap. They went from 1.1.8 to a 2.6 megabyte footprint, that's what those numbers say, to a 19.2 megabyte installed footprint with 1.2.2. Microsoft doesn't bundle this.

We are going to be bundling this, so anyone who writes to the Java 2 platform gets to depend on it, on our platform. They don't have to lug it around like they have to on Windows. To give you a sense for what 20 megabytes installed is like, I decided I'd measure Carbon. Carbon weighs in at about 11 megabytes on DP4. You know, since you're a Mac developer, what Carbon is about.

Imagine two times that, which is again what the installed footprint is on Windows. But the installed footprint is only one side of the story. I think the most important side of the story is Java was not designed with a static deployment model in mind. Just think, if you're an application and you're carrying around this Java runtime environment that's 20 megabytes, and it's just a part of yourself, so to speak, why are you paying for the interpretation? Why are you paying for the class verification? Why are you paying for interpreting? There's just so much stuff you pay for because Java is a great systems model, system language and VM model that carrying it around makes no sense from a time perspective either. So both from a time and a space perspective, what people are doing on Windows is nonsensical.

Sun will solve this problem, I believe, even in spite of Microsoft, but it's solved today on our platform. So Oracle can go to their customers when they move to Java 2 and not have to carry around another 20 megabyte jar file every time they open a connection, for instance. So I think it's pretty critical that we're bundling this stuff, we're tightly integrating it, and we're going to make sure the footprint is very low.

As I think most of you are aware, we really like the Java language and virtual machine. Again, it's a great model. It's a great systems model. C++ drifted away from many application uses at the system layer because it wasn't a great system-level object model. It's a fine object model, but it just isn't appropriate for systems development, and that's one of the reasons Java's taken off technically as much as it has. It's very appropriate for a system object model.

Just to further explain what I mean by that, I'm sure some of you are aware with the fragile base class problem, I guess is one common way of referring to it. Basically, the ABI that a compiler uses is in the C++ world, typically proprietary and owned by the compiler. Java VM specifies how all .class files are to be interpreted. This is a huge interoperability win. It means you can... migrate to new instances of the VM fairly painlessly.

We have the Java 2 Standard Edition packages. But here's where we innovate. We have WebObjects. And as you heard today, we're going to a pure Java version of WebObjects, but even right now it's all wrapped today so that you don't even know it's written in Objective-C, even though it is. Cocoa is written in Objective-C. We wrapped that as well, but it's totally accessible from Java. And QuickTime is also accessible from Java. All three of these technologies are incredibly important to Apple. And sitting atop is Project Builder and Interface Builder.

Let's take the tools first. I just want to show you a screenshot of something I think you saw in the keynote. Avi brought it up briefly. We have totally rewritten what Next used to call Project Builder. Rather than rename it, we kept the name but rewrote the entire product.

We figured most folks in the Apple community weren't familiar with Project Builder, so the name was sensible. We kept the name and rewrote the whole product. What you're seeing here is a sketch, which is on the system. You can go look at it. It's a Cocoa Objective-C program. It's a little bit silly. We still have yellow in the package names, but they'll be renamed appropriately before we go final with this.

Right there you can see with Project Builder we're going more for, I guess some people refer to it as user centered, some people refer to it as document centered, but that editor/viewer is used to viewer edit multiple data types. In the keynote I think you saw a fancy diagram in there.

In this case you can see there are release notes, which is an RTF file, that's a TIFF file, and that's a Java file, all from the same context. You're not switching to and from many apps. Project Builder is a tool which at DP4 fully supports C, C++, ANSI C obviously, and supports a lot of our frameworks. Java development is just coming online. It works fairly well, but for GM it's going to work a lot better. If you care about it, go see the Project Builder talks.

Another important thing to mention about Project Builder. You just saw the great enterprise development environment. One of the big differences between Project Builder and JBuilder is JBuilder is pretty much a single language, single framework development environment. It's targeting Java 2. What Project Builder is, is a multi-language, multi-framework development environment.

Again, it supports the C-based languages along with Java and is going to be supporting AppleScript as well. There are some demonstrations on that. There are trade-offs you make in a multi-lingual environment that you don't have to make in a single language, single framework environment. I believe both actually have different markets and I hope to see both of them thrive in our community.

WebObjects, they're giving their State of the Union right now. I snarfed a couple of their slides. Fortunately, they're going at the same time because this was going to steal some of their thunder. Powerful, I'm sure you're familiar with it. We use it internally pretty extensively. We run our whole Apple store on it.

and here are some of the features. So one thing that's important to note with WebObjects, again, we use it. There are many, many customers who are using it, Disney, MCI. Just Steve showed the whole list of them at the keynote. It's technology which is very mature. It's been around for a while. And it integrates not only with Java now, but with QuickTime for Java, as you saw in the keynote.

We've won many awards. The most recent one, I believe, is we won the CODI in March. It's critically acclaimed. 5.0. The big thing with 5.0 is it's going to pure Java. Right now, it depends on the Objective-C runtime for its deployment. The benefit of going pure Java is WebObjects can benefit from all the other Java VMs that are being done at HP, at Sun, and so on, just as we're investing in Java. It means we don't have to deploy some of the Objective-C technology on some of the servers. and it uses JDBC. I don't know when 5.0 is going to be released. I guess I shouldn't say. In the future. Quick time for Java.

I won't go into it, except there's a beautiful book that's been written. I don't have a copy, and I couldn't get a screenshot of it, but I urge you to take a look at Stacy's or wherever you buy your computer books. There's a great book on QuickTime for Java.

Again, it gives you the real professional quality digital media capabilities from Java, and in fact allows those class files to be used verbatim on either Windows or Mac. There's nothing proprietary or special that we're doing to make this work. and there's a quick time for Java talk actually right after this one that'll probably be a really nice talk for you to attend in A2.

The Swing integration we've done is pretty unique in that many of the platform look and feels that are done with Swing are emulated. That means they don't interact with the native system at all. They try and emulate the look and feel. What happens there, as you can imagine, is when the look and feel changes, you have to then re-emulate or end up having the wrong look and feel. In addition to changes, sometimes you just get it wrong because you didn't really understand what the native look and feel was.

There's a whole class of bugs that usually crop up around emulation. What we're doing is integrating directly with the appearance manager. The Aqua look and feel you saw on stage in the WebObjects demo with Swing was a Swing application that was, again, written directly to appearance manager. The Java programmer didn't know anything about the integration. It just happened automagically. We also do the correct menu placement.

Now that Java is fairly fast, and I think it shows that that demo, again, that's a large application, the performance of it is fairly good. So the only problem, so to speak, with that app is it didn't have the Aqua look and feel. So I'm going to bring Blake up briefly to show you that.

: What we're going to do is have a quick look at the fact that JBuilder was designed from the beginning to be look and feel aware. So when we go to choose IDE options, it gives us the ability, among other things, to switch between the installed look and feel. So here the Mac OS adaptive look and feel is just one of the ones that shows up. So once we pick that and hit OK, we'll see that we get the Aqua look and feel.

Okay. So actually, I have these boring -- these will seem boring now. But that's good. So you can see -- What did I do? Oh, I hit, okay. So, you can see switching back and forth. It's almost like, well, let's go to the next one. Here's a, it's called Metal. It's the built-in Java look and feel. And when you switch to Aqua, it's almost like it comes to life. It's just so much prettier. Right.

So, unfortunately, some of this cool Aqua integration isn't in DP4, so you guys won't be able to play with it for DP4. Sorry about that. We actually hope to do a net release in between now and GM, where you can get some of this stuff from us before we actually go GM. We're going to improve our project builder support for Java. I think I mentioned that.

We're going to a new application embedding model. The main folks who care about this are like OmniWeb, the Internet Explorer folks. That's how you embed a VM and an applet within an application. But you may have an application that wants to embed this stuff within you. If so, then you'll have this application embedding model that we're doing.

Wow, closing thoughts. We have how many minutes? We have four minutes left. I guess what's getting fun now is we have a team that's kicking some serious butt on this stuff, and there's real applications that are starting to get exciting like Velocity, like Oracle's apps, like this beautiful IDE that Enprise has done. Fundamentally, that's what we do. There's no way to look at Java by itself and say it's great.

You have to look at the applications that are going to be produced on top of it and say they're great. If in fact they're great, then we're happy and we know we're doing a good job. I have two or three minutes left. I'd like to bring the team up and give them a round of applause.