Whether you are a new or seasoned Java developer on a Mac Pro or a MacBook Pro, Whether you're targeting Java desktop applications or heavy-duty server solutions, this session is for you. This is not a session about Java on the iPhone. Although we believe that there is an opportunity for WebObjects application servers as application servers for iPhone-based, whether native or web applications.

So what's new about Java? A month ago, we attended Java 1, and it really looks like Mac laptops have become the development platform, the Java development platform of choice. They were everywhere, in the audience more than ever. On stage, they were running their presentation on Macs, but also all the coolest demos in the biggest keynotes run on Macs.

even the latest JavaFX demos. The reason is backstage more and more Sun engineers are using Macs as their Java development platform of choice as well. This is really a tribute to the quality of the Java implementation on Mac OS X. And this slide is also here to remind you to download the latest Java 6 on your MacBook Air. It will not only keep levitating, but it will also fly.

Combining Java and WebObjects, we believe, gives you the strongest enterprise development and deployment platform. So WebObjects community is alive and strong. Over last weekend, we attended a pre-WWDC WebObjects conference that was impressive by the number of attendees, 50% more than last year, and impressive by the quality and complexity of the solutions presented. It has been true for the last 10 years. Every year, web designers and standard committees throw at us new web technologies, and every year, WebObjects adapts to them.

With the latest multi-core Macs combined With the just announced Snow Leopard 64-bit OS, we believe that you have at your fingertip an incredible, immense amount of computing power. Java 64-bit has been shipping for more than six months. And with Java and WebObjects, you are best positioned to take advantage of this computing power. So our agenda of the day is quite simple. We will spend half of the session talking about Java enhancement in Snow Leopard, and the other half about the latest WebObjects features and releases.

So who are the Mac guys of the day? Well, first we'll start with Tom O'Brien, a beloved Java engineering manager, followed by Pierre Frisch that everybody knows as a WebObjects manager, and his sidekick, Daryl Lee, our demo guru of the day. But forget the Mac guys, it's all about Snow Leopard and Java 64-bit, along with WebObjects. So Tom, come on up.

Thank you, Francois. Francois is a great choice for waking everyone up at 9 o'clock in the morning on day two. Quick show of hands, how many of you in the audience are experienced Java developers who are new to the Mac platform? Okay, great. And how many of you are Java developers who have been with us developing on Mac OS X for quite a while? We have news today that's going to be interesting to both of you. We're going to start out with a quick overview of Java on Mac OS X, especially for those of you who are new to the platform, just to recap some of the most important points.

We'll also highlight a few of the updates that we've shipped in the past year for Java on Mac OS X. We'll tell you the latest about Java 6 and 64-bit. We'll give you some pointers to some great UI enhancements you can make to your applications to make them really look great on Mac OS X but stay cross-platform. And we'll tell you about a couple other efforts that have been going on this past year in SWT and in the Java plug-in space. and we're also going to be looking at the Java that you're getting at the Snow Leopard preview at the conference this week.

So if you're new to Mac OS X, a key point about Java on Mac OS X is that it's a core framework. It's been built into the operating system since the very first release. Unlike on other platforms, Java is part of the operating system so you don't have to bundle it with your application and you don't have to deal with installation issues and configuration issues for your customers because they've already got a Java version that runs great with your application on their system. As a core feature of Mac OS X, Java is available in all the deployment modes that you're used to and your customers expect. Applets running in the web browser, WebStart applications, double-clickable bundled applications on the desktop, and command line and server code.

As Java developers, you already know, or you should know if you're coming to the platform, that the Java code that you depend on to develop your applications and the Java applications you ship run great on Mac OS X. So tools like Idea and Eclipse, Apache Tomcat, and many more are all running great with the built-in Java that's on Mac OS X today. And it can be true of your apps that you develop as well.

The next key point about Java on Mac OS X is that at any time we focus our efforts on one preferred Java VM for a particular hardware and software configuration and OS release. And over the releases of Mac OS X, we've moved that preferred Java version forward, starting with Java 1.3.1 and the very first release of Mac OS X years ago, moving forward to current releases where we have Java 1.5 as the preferred version. As we move the preferred Java version forward, we transition our efforts off of older versions to focus our attention on the latest preferred Java version to keep it the most compatible and most stable and secure for you and for your customers.

So at this point in Leopard, the preferred Java version is Java 1.5. But let's take a closer look at the Java versions that are available on Leopard. First, as I said, Java 1.5, Java SE 5.0, to use its full Sun marketing name, is available on Leopard, and it's the focus because it supports the range of hardware that is the supporting configurations for Leopard.

It's available in both Intel 64 and 32-bit versions, as well as PowerPC.

There's also a Java 6 version, a Java 1.6 version available for Leopard for Intel 64-bit hardware that allows you to move forward to 64-bit and to Java 6 with your applications and get a jump on the future of Java in Mac OS X.

Because there can be multiple versions of Java available on the platform at any point, users have the option of choosing a different Java version to run as their version rather than the default preferred version that we set for that configuration. Most customers don't need to change this, but you should be aware that it's an option.

And if they want to, for their particular configuration or their needs, they can override the versions by reordering the list of available VMs in this list so that they launch applications in a VM of their choosing that's available on the system. They can also change the version that they use for launching applets in web browsers.

So these version settings let you or your users control which versions are being launched on that particular machine, on that particular configuration for double-clickable applications, for WebStart applications, for applets. And a new feature we added in Leopard that you're probably aware of if you were here at the conference last year is that this also changes the version of Java run on the command line for command line code.

Speaking of the command line, again, if you're new to the platform, there are a couple key file system path tips that you should know about if you're an experienced Java developer coming to Mac OS X. There's two main paths you should know. First, user bin Java is a symbolic link that tracks the Java version that is selected in the Java preferences application that I just showed you.

So that can change both on different versions of Mac OS X and even on individual customers' machines, but it'll track the version that is the most compatible for their situation. LibraryJava Home is fixed for the particular configuration and release of Java and the operating system on that machine by Apple, and that tracks the preferred Java version that Apple has set. So, for example, in Leopard, LibraryJava Home is a reference to Java 1.5's LibraryJava Home.

Now because Java is a framework, like other frameworks on Mac OS X, it lives in system library frameworks. But relying on any paths that are inside system library frameworks is really fragile and is prone to breaking and compatibility issues as we change versions of Java or move the operating system forward. So if you need to rely on file system paths, pick one of those first two.

Let's take a quick look at a couple of the recent Java updates that we've shipped over the past year. At the conference last year, you got updated versions of Java in the Leopard preview that was shipped 12 months ago. And we also shipped a version of Java 6 as a developer preview that would run on Leopard.

In the fall, when Leopard GMed, there were even newer versions of Java 1.4.2 and Java 1.5 in that GM build. And we also shipped in December an update for Tiger, Mac OS 10.4, to bring its Java 1.4 and 1.5 versions up to date with the latest versions available at that point.

And that was a very focused release, mostly focused on getting those versions to change and be compatible. We continued doing developer previews of Java 6 for Leopard, and we shipped the GM version of the Java 6 update in April of this year. And now at the conference this week, there's an even newer Java in the build that you're getting in the Snow Leopard preview.

One of the essential ways that we move Java forward on the Mac for compatibility and for making sure it's best for your customers is to listen to your bug requests and enhancement requests and respond to them in updates. For example, in Leopard, we dealt with a wide range of issues in moving the operating system forward to newer versions of Java and making it the best possible Java on Leopard.

And we also rolled in over 270 critical issues that came from you as developers that were important for moving Java forward for your particular needs. In the Tiger update last fall, which I said was a very focused update and had a very narrow range of bugs, mostly based on moving the Java versions forward, we still managed to bring in 25% of the bugs as critical developer fixes for key issues that were needed for compatibility on Tiger for critical customers.

And in the Java 6 update that we GMed early this year, in addition to bringing out a whole new version of Java, we addressed over 180 bugs that came from you as developers in the developer previews and from previous releases to make it the best possible Java it could be. All of those bugs came to us through Bug Reporter.

And here's the URL for Bug Reporter, which I'm sure most of you already know about. And if you don't, you shouldn't. You should. And we also rolled in over 180 bugs that came from you as developers in the developer previews and from previous releases to make it the best possible Java it could be. Thank you.

One important thing you should know about the bugs that come in through Bug Reporter is that every single feature request, every single enhancement, every single bug report that we get through Bug Reporter gets read by Apple Engineering within 48 hours. We use your information that you provide in the bugs to prioritize our work and to focus our attention on things that will make it the best possible Java for you on Mac OS X.

If you're already working on Mac OS X, you almost certainly know about JavaDev. And if you're new to Mac OS X, it's a great place to learn more about Java. JavaDev is an active discussion list where new Java developers on Mac OS X come to learn more about the platform and where experienced developers can have in-depth discussions with Apple engineers about Java on Mac OS X. Here's the URL, and we'll be putting it up again at the end, but here's the URL for getting on the JavaDev list.

Okay, that is our quick overview of Java on Mac OS X, especially for those of you who are new to the platform to get you oriented. Let's talk about a couple of -- let's highlight a couple of enhancements that have been happening to Java on Mac OS X over the past year since the last developer conference. One of the key things that we improved in Leopard was an ability for you to add great user interface enhancements to your swing application to make it look great on Mac OS X.

With swing client properties that are custom for Mac OS X but are cross-platform, you can take this GUI, which is built with standard swing components, and add cross-platform code and make it look even better on Mac OS X. This is the same components using the swing client properties that are available, and this code continues to run and work on other platforms just great, but it looks even better on Mac OS X. It really looks at home on Mac OS X with the enhancements you can use.

We've been adding even more ability for you to add the polish to your Java applications on Mac OS X that your users expect and really give them the extra touches that they expect out of Mac applications. For example, a long-standing feature request was implementing modal dialogues with Sheets, and that's now available for you to use.

We're also using the JavaX Script API in Java 6 to allow you to access AppleScript, which gives your applications much better integration with the other applications on Mac OS X to really get them to integrate with the rest of the OS and the other applications that your customers are using. and we've added even more functionality, like letting you add a customizable dock menu to your application. Again, these are great extra steps for your application that really make them stand out for your users and give them the extra polish that they expect out of a Macintosh application.

In addition to the enhancements that we've been working on for Java at Apple and the new releases that we've been bringing out, there have been other developments in the Mac OS X Java community, and we'll highlight a couple of them here quickly. First, if you're in Java development, you almost certainly know about SWT. SWT is the foundation toolkit for Eclipse that the Eclipse IDE, other IDEs, and other applications are built on.

A critical point about SWT on Mac OS X is that the current implementation is based on the Carbon Framework. and as you may know, not all of Carbon is moving forward to 64-bit. So in order for SWT to have a future in the future of Mac OS X, SWT needs to migrate from Carbon to Cocoa.

Now, the good news is that there's already an effort underway to migrate SWT to Cocoa, which will give it access to full 64-bit support and all of the other enhancements that are happening to the operating system as Mac OS X moves forward. We'll be talking more about this in the talk in this room at 10:30, but you should know that the port is underway and they're actively looking for contributors.

Another effort that's been going on for Java in Mac OS X is the Java plugin enhancements that Sun has been doing over the past year. Sun has been working on a new out-of-process browser plugin model, which allows the applet process that runs your Java applet and the browser to run separately in separate processes. This has great advantages for stability because suppose the Java process were to crash and the applet were to go away. Theoretically, it could happen. The Java applet process can die, but the browser process will continue to run, which is great for stability.

Also, because the applet and the browser are running in completely separate address spaces, it has great advantages for security as well. It also has advantages in allowing you to have more version flexibility in the Java version you use to run applets. For example, a 32-bit-based browser could launch Java applets running in a 64-bit VM. For a lot more about the user interface enhancements that we quickly went over, the SWT Cocoa port, and the Java plug-in work from Sun, please stay where you are for the talk at 10:30 in this room, Building Great Java Applications on Mac OS X.

So that brings us up to date with the Java in the past, the Java in Leopard. Now let's take a look at the Java you're getting in the Snow Leopard preview at the conference this week. First, quickly, let's recap the Java versions available on Leopard. Java 5 was preferred.

It was focused on the main compatible hardware for Leopard that Leopard supported. Java 1.4.2 was present but was going away, intended as a transition strategy. And Java 6 was available for you as developers for Intel 64-bit hardware to move forward to 64-bit development and to move forward to Java 6.

In the Snow Leopard preview that you're getting at the conference this week, we're making a bold jump forward. We're moving the Java 6 preview, the Java 6 implementation from Leopard forward to Snow Leopard, and we're making it the preferred version in Snow Leopard. Because it's also the only version of Java in Snow Leopard, We're making it compatible with the supported hardware configurations for Snow Leopard, which means it's available for both Intel 64 and Intel 32-bit hardware.

So the Java 6 and the Snow Leopard Disk you're getting this week is both Intel 32 and Intel 64. But the really main focus of Snow Leopard is 64-bit. So as Java developers, you're in a great position to take advantage of moving your applications forward to 64-bit. The main advantage that you get out of moving to 64-bit, in fact, the fundamental advantage, is unlimited virtual memory. It's essentially as much as you can count. 127 terabytes is a really, really big number.

What you can do with that is have giant data sets in memory. You can run simulations of weather across the entire globe. You can simulate all the air traffic in the US. You can process medical images that are in huge image files. You can do many things that you couldn't do when you were dealing with a 32-bit VM where you were limited to two gigabytes or less of address space.

The great news for you as Java developers is your application already runs in 64-bit. Because Java's pointer size agnostic, pure Java code moves forward seamlessly and just can continue running great in 64-bit. So you have a leap ahead compared to other developers who are moving their applications forward. A pure Java application running on a 32-bit VM with 32-bit frameworks continues to run just great on 64-bit with no change on your part.

Now, a bunch of you are already ahead of me because you know that there are some Java applications that don't move forward with zero steps. They need one more step. If you have a Java application with native code, with a native JNI library that's built for 32-bit, when you move the Java VM and the frameworks that it depends on forward, there is no 64-bit version of the JNI code that your application is depending on.

And so your application won't launch, it won't load because of this dependency. There's one additional step you need to do if you have something that involves JNI libraries, which is just rebuild your JNI library to be universal so it has both a 32-bit and a 64-bit segment, and it will run great in both 32-bit and 64-bit Java.

Okay, so great. You have a head start on moving your application forward to 64-bit as Java developers. You've done either zero or one steps. Your application is running great, and you're thinking about all the cool things you could do with all of that enhanced address space. Is there any downside to this? Do you pay a performance penalty, for example? The great news as Java developers is that the Java 64-bit version in Snow Leopard runs even faster than the 32-bit version. So you have a great, it's up to 61% faster. Sorry, I meant to say that magic number.

You're in a great position as Java developers. Your app comes over faster than for any other developers. If it's pure Java code, it's no steps. Otherwise, you have to rebuild your JNI library. You get the advantage of all of this great address space, and your code runs even faster on Snow Leopard.

You're in a great position to move forward with 64-bit. So let's talk about the key points in the Snow Leopard Preview Java that you're getting. Java 6 is the Java in the Snow Leopard Preview. It's available for 64 and 32-bit. 64-bit is the default version. You should start moving your applications forward today to 64-bit.

Take advantage of all that address space and work with Java 1.6. Tell us about any issues you find at bugreporter.apple.com, but you really can get started today. For a lot more about 64-bit and the Java in Snow Leopard, please stay where you are for the next talk at 10:30 in this room, Building Great Java Applications on Mac OS X.

So we sped through a quick tour of Java on Mac OS X. to recap the essential things you need to know as new developers, new enhancements in the past year, and Java in Snow Leopard. What are the essential things you should take away from this section of the talk? First, there's a 64-bit Java version available for both Leopard and for Snow Leopard.

So you should get started running your apps in 64-bit today. Second, learn about and take advantage of the great enhancements that you can make to your applications to make them really look great on Mac OS X and fit what your customers expect out of a Macintosh application. and Paul Schmitz.

And finally, the fundamental thing under all of this is that Java is a core framework for Mac OS -- on Mac OS X. It's a great foundation for your Java development and it's a great foundation for delivering applications to your customers. It's also a great foundation for other technologies on Mac OS X. And I'd like to welcome up Pierre Frisch, who's going to tell you about WebObjects, one of the great technologies based on Java on Mac OS X.

Thank you, Tom. So, good morning. I'm Pierre Frisch. I'm sure that most of you know me. For those who don't know me, I'm Mr. WebObject. So what are we going to talk about this morning? Well, we have got quite a number of topics to cover. First of all, for those who don't know WebObjects, I'm going to go and do a small summary of what WebObjects is all about.

Then we're going to talk about WebObjects 5.5 and some of the future. Then we go back on the tools and talk about the WebObjects community and that great event that we did last weekend. So, what is WebObject? WebObject is actually the granddaddy of all the application servers on the Internet. WebObject was created in 1996 in Objective-C and started its life...actually Francois was one of the first engineers to work on WebObject.

In 2001, WebObjects was ported to pure Java and actually started to be really the mainstay of the application service. Last year, we released version 5.4 of WebObjects, and with Snow Leopard, we are going to release version 5.5. The main highlight of 5.4 was actually compatibility with Java 5. The main highlight of WebObjects 5.5 will be the compatibility with Java 6. And obviously, 64-bit and all the goodies that you get with Java 6 and 64-bit.

WebObjects is the marketplace. Well, WebObjects, first of all, is used internally by Apple to run the company. We use WebObjects for the Apple Store, so if you bought a Mac on the Apple Store, you use WebObjects. We also use it internally to run systems like DotMacs, eMusicStore, which is probably one of the largest e-commerce sites on the planet, but we also use it internally for manufacturing and running our own internal business.

If you look at your Mac, every single part of every single machine that we manufacture is actually tracked by a WebObjects application. So we actually use it for very small things, but we also use it for huge applications. So you can scale, and don't worry, if you build an application with WebObjects, you can scale it. Outside, last year when I was on this stage, I actually counted the number of pages that you can actually see on the internet made with WebObjects. There was 4 million. This year, there are 6 million. So you have been very busy. Thank you very much.

And that obviously doesn't include any of the private page. So WebObjects is well alive and growing very, very fast. WebObject 5.4, what we did last year. We released in October a new release, 5.4 with Leopard. We released an update in February, and today, posted on ADC, you are going to find WebObject 5.4.2 available.

We also cleaned up the license. We got a lot of criticism, so we actually made it absolutely abundantly clear that the WebObjects application that you can develop on WebObjects, you can deploy it on any machine of any system that your customer requires. So it's absolutely, absolutely clear.

So I'm absolutely sure it's the first time and last time you ever read it, so at least you have read it once.

Anyway, so you have read the license, you're happy with it, we can go on. and also we fixed, during the course of the year, 210 bug fixes. We actually been very, very busy on trying to fix the bugs and make the enhancement. And most of those bugs actually come for you.

45% of the bugs that we fixed were actually issues or improvement or requests that you made. And so it's very important that you keep carrying on sending us requests. 33% are actually internal developers, so that bugs that are actually discovered or issues that are requested by internal developer, our own internal use. So please carry on sending us reports on bugreporter.apple.com.

So, now that we've seen what's passed, what's coming? Well, we are working on WebObjects 5.5. 5.5 is going to be released with No Leopard.

So, change. A lot of things have changed under the hood. We try to keep the public API stable, but... You don't make an omelet without breaking eggs. Anything which is private API has changed, will change, and so if you subclass or patch private internal API, your code will break.

So, localization. What did we do? We actually introduced a feature that was requested since 1997. And we actually moved from language string to local, to Java local. So, we are all here in America and we all know what a gas station is. Fortunately, in England, you go to the petrol station to fill your tank. or you check the level under the bonnet and not the hood.

We also, to make it really easy for you to use those features, added some localization in components. So you can now write Directly into your string, a localized string, so you can actually address from the key and the default and you don't have to actually write the glue in the Java code to actually call the localized string.

So that would make your life simpler. And the last feature in localization, but not the least, is we introduce geolocation. So you can not only know what the browser is reporting, but you can also, from the IP address of the browser, know where your customer is coming from. And even if you are in New Zealand, which is that map of the world, you can find the people where they are.

and for that I'm going to ask Daryl to show you a short demo of that feature. Okay, thank you, Pierre. So I prefer the view of the northern hemisphere this way on a map. So what I'd like to show you is a quick preview of some of the geolocation features and just how easy it is to use localization tables within WebObjects 5.5.

So for this demo I'm going to actually have to spoof some IP addresses because, well, we're in San Francisco right now and I'm going to need some to generate requests from various parts of the world. So I create this map and say we get a request from South Africa.

What just happened right there is that we made a request from the IP address 4131.255.255, and we realized that this was in the country region of South Africa, and we did a lookup in the localized table, and we got a localized hello greeting, hello from Cape Town. And so let me try a couple other addresses, like let's go do a German one, so Guten Tag, or let's go to the United States here, and...

And so the next great feature I want to talk to you about in 5.5 is codeless component. We've discovered that most of WebObject applications write quite a lot of glue code.

And one of them being for the iteration variable. So we actually made it easier for you to not have to declare those iteration variables in the Java code. So instead of writing this type of code, which is a classic way of writing WebObject iteration, you can now just put directly into your Word file the iteration variable. So don't go and write any more of those.

and the same thing, we went a step further. It's that very often when you do a repetition on a bunch of objects that you grab from the database, so we actually added to the repetition a fetch binding that enabled you to return directly a list of objects from the fetch spec in the database.

So how does that work? It works with using name fetch spec, and we pass as a binding all the values that you build in your variable dictionary. So actually you can make some really interesting pages directly without any Java code. And for that, Daryl is going to show you another demo of what we can do with it.

Thank you, Pierre. So I just wanted to give you a quick tour of a component that I wrote really quickly. It's a master detail-like component. And it kind of leverages a lot of new features in WebRx 5.5, but we laid down the foundation of this with WebRx 5.4 and the new bindings parser.

And in 5.5, as Pierre mentioned, we introduced a fetch type of binding. So what this little highlighted code says here is that I want to reference the movie entity, and I want to call the fetch all movies name fetch specification. And I'm stuffing this into a world repetition list, and then for each item in that list, let's stuff that into a variable name, a movie.

And this allows us to do a lot of great things. So I can reference that variable while in my repetition and reference the title right here. But I can also traverse relationships. So as you can see, I've created another repetition here, and I'm traversing and iterating over roles, and I'm printing out the role name and printing the first and last name of the actor.

and just to show you, I'm not writing any Java code. Here's the basic templating code. There's no specific bindings there, no Java code at all. It's purely within the HTML code right here. And so here's my app really quickly and how that turns out. And as you can see, here's Indiana Jones movie.

The master or the movies entity is printed on the left column right here. If you look to the right, we've got detailed relationship like the studio and various actors and actor names. And hopefully that gives you an idea of how just quickly and painless it is to access functionality and the new bindings. So back to Pierre. - Thank you, Darryl.

The next feature is that we change the login in WebObject. You have been requested that for a number of years, and we actually agree that NSLog is a very nice feature, but it's a bit complicated to use. So instead of keeping NSLog internally in WebObject, we actually move to Log4j. So actually, all of WebObject code is moving from NSLog to Log4j. And it's a much simpler API. I think all of you are using it already.

You can actually turn on and off the logging without restarting the application, which is a great, great feature, because when you have got an application that's run away in production and you want to see something, being able to turn on and off the logging while the application is running is really a great saving.

And you can also do remote logging. Log4j will support and does support remote logging, so you can actually log on a separate machine if you need to in this production. And I'm just going to start to show us the logging page so that you can actually see what's on there.

Okay, so thank you, Pierre. So what we did is we created a component within the Java OLO extensions, and what it will allow you to do is actually dynamically reconfigure the logging for any class that you have or that's in the WebObjects runtime. So it's not just limited to our classes. And it's just as easy, or we have all the log levels exposed right here in a pop-up. So here's like the info level, and we have a nice little icon here that displays what log level or associates that with it.

So I just want to log out fatal errors to NSArray. Now, we have a lot of classes within the WebObjects runtime and probably in your applications, too. So you might want to quickly search for them. When you want to set a custom log level. So if I want to set something on EO editing context, edits.

Thank you, Darryl. The next feature I want to talk about is qualifiers. We discovered that in some cases, the current qualifiers are not fast enough. And so we introduced a new set of qualifiers, essentially the in-qualifier and the set qualifier, that are now fully integrated in the core of the WebObject.

And we did some testing on performance, and actually on performance with the in-qualifier versus the set of and and ors, or the except qualifier of the same condition. And running on a sustained system, so that when the database has time to optimize a query, we get about 50% gain. On a cold system, where the database has no chance of optimizing the query, we can get up to 10 times faster. So this is a great, great way of optimizing your queries when you have problems in terms of performance. I hope that you're going to like that.

And the last feature I wanted to talk about about 5.5 is foundation. Foundation is relying a lot on locking and protection from threads. We are moving to Java concurrency class, which instead of a re-entrant, instead of locking, that should actually improve the performance dramatically in some cases. We have seen in some of our testing for internal apps up to 50% gain on key value coding. So this should also improve the performance of your app. dramatically.

The last thing is that we actually reintegrated properly WebObjects in the server admin, so you can actually now access Monitor directly from the server admin UI. You can also access some of the more obscure features of WebObjects, like you can actually go and access the WOTA-SD configuration that very few people know how to access, but now it's directly in the code.

You can also look at your logs, directly the log for Monitor and WOTSD in the server admin, and you can actually configure everything directly from the admin panel. So we hope that the server admin panel is going to be a lot more useful than before. and from that, I'm going to talk about something that is very unusual here. I'm talking about a roadmap for WebObjects.

And no, I'm not going to talk about version 66. Okay, so what are we working on in the future? We are working about a new deployment architecture. So we are going to rewrite Monitor and WaterSD to make them more stable, more useful, and give you a better ease of deploying WebObjects application, especially on Mac OS X, but still keeping the compatibility with other platforms.

We're going to add asynchronous fetch. This has been a long-running request. What we're going to do is enable you to have a pool of stacks so that you can actually fetch on various pools and various connections transparently. and we're working on a set of AO extensions so that you can actually not rewrite code all the time for accessing user and accessing GNDI integration so that if you need to have the LDAP users or access control list.

Okay, so in terms of tools, first of all, I want to reiterate that our recommended tools are Eclipse and Wallips. And I know that Wallips is supported by the community and I want to extend a very warm thank you to all the people that contribute. But... Today we are introducing one more thing. And this is that you can access today everything that we've talked about this morning. All of the features that I've talked about this morning are available today on ADC.

You can gain early access to everything through what we are going to do, which is releasing every day our nightly build. So you are going to find our own Apple internal nightly build of WebObjects, all three versions, on ADC every day. and for making that really easy for you to use, we have contributed a significant plugin to Wallips to actually enable you to access those, check them, and verify that your bugs have been fixed. And for that, I'm going to ask Daryl to actually show you the demo of how it's done.

Thank you, Pierre. So we contributed a Eclipse plug-in or a plug-in to WorldLibs that will enable you to link against the Nightly Build repository. And one of the things we did is to make it easy for you guys is to create some project templates. And let me just go create a project really quick and show you how to access this stuff. So what we did was actually add two project templates, one for creating a Maven WebObjects application, and then there's a framework-styled project. So I'm going to create a quick application for you right now.

Let me show you some of the significant parts of this. So the real significant page right here actually is the artifact page and this particular pop-up where you pick the WebObjects version. And right now we have a WebObjects 5.4.2 snapshot, a 5.5 snapshot, and a 6.0 snapshot. So I'm going to pick up the WebObjects 5.5 snapshot and of course we have a licensing text here. I encourage you all to read that and I'll click through that and we'll just finish our application here.

So what that's doing is grabbing all the necessary information to find my local repository and

Okay, save that, and no link errors. We're all happy and ready to go. So say I've got this 5.5 app, and I'm not sure if this feature was available in 5.4.2, or is there a bug in 5.4.2 or 5.5 that I want to regress against? Let me go change the version really quick. So I select the project properties.

here, and I select our plugin, and it's called the Apple MIM plugin, and let me just switch that to webbox542. More licensing text. But one other thing I want to point out to you is that this is an area where you would also customize where your local repository is, and there'll be more information following that, but these are two other fields that you might be interested in, the repository URLs. Okay, so I selected webbox542, let me hit okay, and we're rebuilding, and all of a sudden we got a link error, because that API is not available in webbox542.

Okay, so that's a really quick demo, and...

So, after that, I want to thank you, to extend a very warm thank you to a number of people that works with WebObjects and help us to make WebObjects a very great, great product. First of all, I want to extend an extremely warm thank you to Wallips and all the people that contribute to Wallips that made some great tools that not only you use, but Apple uses internally to actually develop WebObjects applications and that we personally use for developing WebObjects. So, we are using the same tools for doing WebObjects that you are using externally. So, thank you very much for everyone that contributed to Wallips.

The next group that I want to recognize is the WoW Community Group. WoW Community Group do an awesome job at marketing WebObjects. WoW Community is, at the same time, an organization and a website. The organization that actually did the WoW Odyssey conference last weekend, which was extremely well attended and there was extremely good technical presentation, but also maintains a website where you can find podcasts, you can find help, consultings, people that you need for developing your great WebObjects application, and also reference sites, applications that have been developed with WebObjects that you can actually use to show to your customers. So, if you don't know WoW Community, go and have a look. It's really an interesting website.

and the last one I want to actually acknowledge is Project Wander. Project Wander is a collection of all the frameworks and all the bits and pieces of development that you can find on WebObject. If you have got a hard problem to solve, chance are somebody did it in Project Wander. That's where you go if you need to do something on WebObject.

So, in summary, WebObject is why make your life difficult when you can have a very simple solution? and many more. Really, make your life simple. Use WebObjects. WebObjects is a proven way to create web applications from the tiniest things to the very, very large e-commerce solutions. It's really, really fast in development and we are trying to make it even faster to just make you write less code.

Really, you should try it out. Actually, we have got a great session coming at 2:00 this afternoon where we have got two trainers that are going to build a full WebObject application on stage in less than one hour. So if you want to see how a WebObject application is built, I invite you all to come to the session this afternoon where you're going to see how it's done in less than an hour. On that, I'm going to call Francois back on stage.

I realize that the second part of this session was very WebObjects-centric. For Java desktop developers, stay tuned and stay seated because next session, the session starting in about half an hour, I'd say, will be all about Java on the Mac OS X on Snow Leopard. So the conference is young. We know that throughout the week you're going to hear about competing server technologies such as Ruby on Rails on whichever new interpreted web stuff there is, I don't know. Let me restate a simple fact. Mac OS X server, Java, WebObjects, all of Apple's business is built on these technologies.

Every way money comes into Apple goes through Java. We are not taking chance with anything else. The question is, should you take any chance? At this point of the presentation, I'd like to welcome my co-presenters to come back on stage and prepare for Q&A. But in the meantime, I have a few announcements to make.

For more information, please contact Matt Trans, who was brave enough to put his email on the slide. And you can also participate in the Java Dev and WebObjects dev mailing list, but be aware these lists are not under NDA, so you cannot discuss whatever you have learned today. Documentation sample code, the demo code that Daryl has so well presented, will be available on the developer.apple.com WODC website. We have two related sessions, one right after on Java, one this afternoon on WebObjects. We also have two labs throughout the week and a WebObjects community gathering.