We'd like to welcome Wiley Hodges, Senior Project Manager of Developer Products at Apple. Good afternoon. Things I deal with at Apple are related to development and developer products, and a very critical part of that is Java. And one of the most important and for me exciting Java development products that's available today on Mac OS X is Eclipse. I'm very pleased to be able to welcome John Wiegand and Erich Gamma to tell us more about Eclipse on Mac OS X. So, with no further ado, thank you.

See, when you leave the room, we have doubled this number. OK. How many of you have a product shipping on Eclipse? Good, still. So I can't promise you double these at the end of this session, but it's a good thing to do. So, what is Eclipse, is the first question. This is our famous quote. We've used this repeatedly for the last three years.

It's a universal tool platform, an open extensible IDE for anything, but nothing in particular. And this is an important theme. We have good Java development tools, but it's much more than that. So let's look at the building blocks here. We start with a runtime. Very small, less than a megabyte, knows about the notion of plug-ins and nothing else.

Built on top of that is a window toolkit and then a UI library. So this is our generic application platform. Knows nothing about tools even. This is just the core base. Can be used for any application you choose. So it's laid in two layers. Now SWT is just vanilla widgets. And Jface, higher level application level functionality. Like if you connect your widgets to your model behind that. This kind of stuff is in Jface. So it's laid in two layers.

Then we add the notion of tools on top of that. So we have a project model that we add, help facilities, an update mechanism, text infrastructure, compare, search, debug. All the specific stuff that makes it a tool platform. So all that's layered on top. Those are optional components. They can actually get leveraged for someone who's using it as a general purpose application platform as well.

And what you see on top of this IDE stack, you see now we have basically a language neutral layer. We have search, debug, compare, text. But this infrastructure is not language specific. And what you will see now when you go to the next layer in JDT, we build on top of those and add Java specific search, Java specific compare, Java specific editing. Right, that's the model.

So the JDT adds knowledge of Java to the platform. But the core platform doesn't know about Java. Which means for us as JDT developers, we get no privileges from the platform. Which is a healthy thing because this gives us this fair play and ensures good APIs. So we were kind of also the pioneers of the whole API extension story.

And it was a really healthy experience to go through this period of frictions, right? We want this from the platform. No, you cannot have it. So that's how we evolved JDT. So we're really going to focus in the JDT area for the most part this afternoon. We'll show the breadth, but JDT is going to be our primary focus and the platform through JDT perspective.

So we had three primary goals when we set out to do Eclipse. The first, called the open platform, we want to work on a wide range of platforms. We're showing Mac, Windows, Linux, Solaris, the full gamut. And besides working on those platforms, we want to be able to leverage the facilities that those platforms provide. So it looks like a Windows app on Windows, and it looks like and is a Mac app on the Mac.

Next goal, as Eric already alluded to, we want to build good Java development tools, but that doesn't want to be our center. Our center is we're a platform, and we make it possible so you can build a C development environment, Java development environment, web tooling, whatever makes sense. All this can be built. So the model is we have something which knows nothing about different artifacts. You extend the platform with knowledge about the particular artifact. You plug in XML tooling, you plug in EJB tooling to make the platform aware of these artifacts. That's our model.

So then once you put these tools in place, we want it to be such that you don't look at it as a user. You've got this wide range of tools that have nothing to do with each other, but rather you've got a seamless whole. So the seamless integration is really important, both in terms of the product that you get, the Eclipse-based product initially, but also any extensions that get added later. It feels like all parts of a single whole.

So our background, you see it's not our first attempt to build an IDE. If you look at the whole knowledge which we have in our team on different tools, you see we have Smalltalk, we have Taligent Technology, Visual Edge for Java, TeamV, C++ Tools. So some of these projects were more successful, some of them less successful, some of them even died.

But I think the key point here, we really tried to say, "Eclipse is our last chance to get things right." We hope we succeeded, partially. So we think we've really leveraged our experience. And the other thing is as our community grows, we've brought many more different areas of background to play over time as well. So we're seeing more teams and our roots are broadening.

So what is Eclipse again? Look at it from a different perception. Extensible tools platform. Out of the box function. We didn't really talk about this yet, but we wanted Eclipse when you get it. You take that initial download, it's something that's interesting and it's useful. So the Java development tools was a good test case of the platform, but it's also a useful function.

So if you take that with the plugin development environment on top of it, you can build plugins of your own immediately, so within minutes. And one of the things we're going to show today is how easy that is to do. So the trick here is, right, we want to give you a Christmas present, but we haven't forgotten to put the batteries in there.

It's not just good technology, but it's being applied. So we have Eclipse Foundation that's been established. There's on the order of 50 major organizations involved. They're building real products based on Eclipse. That real feedback is very valuable and puts it to serious product level use. But not just product level use. We really care about the open source community. And the open source project is basically our lifeblood.

And that's where we spend our time, listening and responding and working together. And also to make open source even simpler, we wanted to really have first class integration of open source tools like Ant, CVS, JUnit, right? That you can really work in open source environment in a seamless and productive manner.

So what is JDT? Screenshot. I think the screenshot is not too interesting. So what I want to do is, I will go through some demo. I must confess, I don't daily code on the Mac, so some of my keystrokes might slip. And I claim my wife is guilty for that because she's having a Mac, but she only borrows it to me on Saturday morning when she goes shopping. So I've really limited training experience.

So what I will show, yes, thank you. So I will show how some code exploration, and as we go, I will show you some new stuff. I will also show you some old stuff. I hope you can still profit from it. First of all, let me start with something. I guess the example, one word about the example. Let's get rid of this guy here.

The example is JHotDraw, which is a drawing framework which is based on HotDraw, which was initially built by Ward Cunningham and Kent Beck. And this is basically some sample code I wrote when I still thought about design patterns, right? Who wants to know about that anymore? But it's still a good sample. Let's first start with something which is really invisible, but which I think is where we have a big advantage over many other tools.

It's a feature I don't want to miss, which I don't see in other platforms, which is incremental compilation in the background. So our compiler technology, maybe John, you can say something about it while I try to open something here. One of the things that we've done from the beginning with our compiler is we use our compiler both to do the build engine, but also all of our tools are built on top of the same piece. So we get the same exact characteristics between the two. So our recovery mechanisms, et cetera, all leverage the same pieces. I feel like this is unfair, Eric.

We need something to make it a little more challenging. No, no. First I want to show you what our goal was. Our goal was you change a massive body, and below one second you should be able to run again. So you have to watch fast. It's done. Yeah, we need to, can we run this off battery, Todd? Just to make it a little bit... So, well, we have the progress view here. Let's just drag it so you can at least see we are building.

Watch quickly, right? So you want to have something more advanced? You want to let it change a comment, for instance? So you see incremental building, highly sophisticated when you want a quick turnaround. One thing which is also special, we come from an explorative environment, John even more than I do, and know Smalltalk, which is a highly optimistic language, which means what our compiler can do, which I don't know of any other one which can do that, it can generate code even when you have errors in your source.

If I have one method in error, for all the other methods in my file, code gets still generated, which means I can execute coded errors, which is just great. If you have a large piece of software you want to port, I want to run it without having done the big bang approach. So that's just some inheritage from our exploration days, Smalltalk, which was just given. Debugging is also very important. So let's do some debugging here. So I have to run this thing.

Don't be confused about the package name, it's old code. So it's CH stands for Switzerland. Joe Rowe. We are running the debugger now. And we debug it as a Java application. Here we go. I want to just make it a little bit more interesting and add some data. That's the most critical part of the demo, since I can easily get lost on the disk. But it happens to me.

Now John, it's your opportunity to talk. So again, notice we're using the native controls as we work through here. So this shows the native control integration. We leverage those pieces as we go. I save you, John. So here we go. This is from the young times when you had lots of fun. So it's not only a drawing tool, it's also an animation. So now I run it in the debugger. And you know, usually you use, You use tool palettes to change colors. That's a little bit boring, so we can do better than that.

"I want get attribute, I think that's not what I want, I want get fill color. Can you imagine what I'm up to? So let's set a break point. Here we are in the debugger now. So we look at what is in this fill color. Let's just get the expression and inspect it.

So that's something you will see often in the new release. Now we work with these lightweight dialogs, which means really we don't want to distract stuff. So you often work with this code assist-like style lightweight dialogs. That's what you see here, right? This is an inspector, but it's really lightweight and you can still have the full functionality. So you have some color stuff here. Now we want to be mean. Let's continue running. What we will do now-- hello. Oh, I have to remove the breakpoint. That will be better.

So guess what I'm up to now? I don't use the palette to change the color, I just change the code. So instead of restarting the program, you're just changing it on the block. What fits Apple style? And here's Red. So now what I will do is I will save. Whoops. So what happened, right? I saved in the background, the code got compiled, the change code got updated into the running VM, and of course I could do that without any reason.

So the next feature, just to show, you know, structure is really important to us. So I made a change to method that's also heritage from Smalltalk. But in Smalltalk, you could do this fine-grained history method level. So I can still do this now. So I want to go back to the previous stuff.

But I don't want to code it. Instead, I want to use local history. And I say replace with. And then I get the local history, but just of this single method. So on the fly, you know, we parse out the structure, things like that. We replace. Save. And we are happy again. Okay.

So just to reiterate there, all this is built on top of the language neutral structure, right? So this is JavaScript function that's layered on top. So let's look a little bit at refactoring. Refactoring is, of course, I think one of the most productivity increasing ideas and tools these days. And I think the different stairways to heaven when you think about refactoring. So the first step is now we can rename a class or a method, and then things get updated references.

That's the first step. The next step is you can do kind of structural manipulations like extract a method. Then the third step to me is the really interesting refactorings like extract interface. You have a type, you extract an interface, and you change all the code which could use this interface to refer to this new interface.

Now this is based on more interesting algorithms like we are using type constraints, which we have published at UPSLA last year. And then the fourth level is where it gets really interesting. That's where you start not only refactor, but first of all you can also update derived resources like Java documents, or you can allow others to participate like an updated JSP. Or you can update derived stuff like variable names. I change a class name.

I also want to update variable names which refer to this class name. Things like that. So we are at level three on the move to level four. So let me show you something. Some smell detection. Let's go ahead and set some brookmark here. What's a good one? Let's just do a reference search where this election is used.

Where is this guy used? Without this refactoring support, people tend to live with programs that are wrong. It's just not worth the effort of fixing them up. But with this, you just naturally keep your programs with better hygiene. So I see this expression a lot, you know, with F selection contains. So that's kind of some code smell. I want to extract it as a method. Others can do that too.

Let's call the refactoring menu, which is context sensitive, and I want to do extract method. However, what is interesting here is this little checkbox. When I extract this method, we will go in and find other places in your code where you used the same code, the duplication. And we will refact this as well for you.

This is kind of smell detection. We not only do what you want, we also help you detect other smells in your code, in this case duplication of this method. So let's do that, that you see that I didn't lie to you. Contains figure. And let's do the preview here.

Then you see replace duplicate code fragments. We go in another place in your code and we update this as well. You can imagine you can go even further with that. But that's kind of where I see refactoring is going. Refactoring in JavaDoc, as I mentioned, derived data refactoring. Let's maybe add some JavaDoc thing here. But I have a parameter.

You didn't really draw much attention, Erich, to the context sensitivity. Let me just mention, you went by that because we're used to it. But what happens on the pop-up is the JDT is finding the refactorings that are appropriate. So instead of seeing the long list of all the possible refactorings, you're seeing the ones that make sense in that context. So again, it's helping you do the work you need to do. Behind this is quite a machinery, right? There is always an abstract syntax tree you have to have to make these decisions.

So, I want to show Java doc updating. For instance, I've added a Java doc tag. I just go in. I rename this parameter to figure foo. And you see, ChaoDoc is now also getting updated, since you all have a helpful representation of these commands in our AST. So next thing is what I want to show is coding assistance. Of course, we do all kind of code assist stuff.

Would you just expect today from an IDE? Let's do a new... HashMap is good. So when you do that, you will import. But we have gone a little bit beyond that. Now we also offer what we call Quick Assist, which helps you with tedious coding tasks. For instance, now I have to type the object I want to create. I have to type it, such as do Control-1. And I can now assign the statement to a new local variable.

And of course the system will come in and infer which type this is, help me with the name. Well, HashMap is better. So which type should it have? Well, that's the clipping So I want to use a collection, right? A map. A map is good. I don't want to use the concrete type, I use the map.

But you see, we help you with editing, we infer, we know your program very well. In fact, we like Codasys that much that we have also extended it to also be part of our dialogues. So for instance, when you change, when you have to enter a class name... We also give you code assist in dialogs, and I guess it's just a homogeneous experience. Once you used to not type anymore, you really want to have it everywhere. So this light bulb is the indicator.

And of course, you will not only do this for classes, it's also really helpful when you do regular expressions, right? Who knows this index of regular expressions? I don't, but of course, we code this, you can get the same. So these are some of the ideas you have here. - So coding, huh? So templates is very interesting stuff.

For really boring, I want to iterate over an array with with the collection. Things are linked together. Actually, can I go back? Can you ignore what I just did? I have something cooler for you. I want to iterate over a collection because then the system will have to be smart.

"Ether, ether, so what is it, an object?" Things like that, right? You don't have to type it. The tedious stuff is linked editing. Very important when you do test-first development, XP practices, you often write code to test first, and when you write the test first, you write some method which doesn't exist yet.

And of course, you can also get support for creating this method from unknown references. And what you see here is a preview. We always can show you the preview of what we'll generate for you. That's also pretty neat technology, because it requires that we can do a what-if analysis of an abstract syntax tree. So quick assist, there are some fun ones that I'd like to show you. For instance, Some new ones which we have. Imagine you want to add a new constructor here. And the constructor, we are now 3D, we also have a depth argument.

So I've added the argument to the constructor, but of course now I want to have to assign it to a field. I have to declare the field, all the stuff. So we do this all for you. You can just control one and say assign parameter to a new field.

And this will give me the option to change the name. The name is OK. Yeah, and type is OK. Well, maybe it'll take a long, right? Things like that. So really helpful when it comes to adding new code. And consistent with that-- One of our nicer quick fixes is... What is a good example? I looked up a move selection is a good one.

So if I add another parameter here-- no, no, no, no, no. At the call side, right? I just see this method. I change it here at the call side, take an additional parameter. The system can help me to suggest to also change the calling side. This is really do what I mean, right? I change the call and Quick Assist, Quick Fix will help me to fix up the code. So I can say, yeah, I want to actually change the method to have this additional parameter, as you see highlighted here. That's pretty neat. Poof. I think poof is the word to say.

Okay, searching quickly. What's new there is we search in the background. We have this new, nice responsiveness infrastructure. So what's a good search? Vector. Do I have a vector somewhere? I have to look something which takes a little bit longer. Vector. Here we go. So vector. Let's do a references search.

See, that's when I slipped. I didn't get it. So I want to reference this in the workspace. And now you see I have the option to run in the background and then I can continue working. Wow, it was too fast. Give me a slow demo machine. I prepared on my IBM ThinkPad, so I had plenty of time to talk. Maybe I have to look for a string.

No strings used. Oh, silly me. So I would like to show you our concurrency story, but I will do it in another example. Too fast. But you see, you can run in the background. You can continue working. And you can group your results in different presentations, things like that. What's also important is we have opened-up search. So when you do a Java search, you can now have the option to plug in additional sources to be looked up.

So if you have, for instance, the JSP development, you can hook into the Java search to say, when you look for reference to Java class, you can also look in your JSPs and give us the result. So this is kind of an idea of opening up that you handle not but only Java artifacts. So searching, well call hierarchy is something new we have. So who does actually the drawing? The draw all, draw, okay.

I want to show it. But what's nice to show the call hierarchy is because this is something we wouldn't have done because I think an over-objection system call hierarchy is the worst thing to look at because it's so complicated. But someone has written a nice call hierarchy plug-in and in fact it was so good that we decided to take it. So that's nice how the open source stuff works.

Okay. Now let's move to something which I think is pretty fun. Our background is we came from more -- I want to show you exploration, how we explore code, how we can navigate code we don't know yet. So we come from Smalltalk. And what we have offered here is when you come from Smalltalk you have typically hierarchical browsing.

Do I get some types here? Yeah. Right, you do some hierarchical top-down browsing. That's cool, but what we found, what really helps also when you do more exploratory understanding of a program, you want to do it way more editor-centric. You want to really have just the editor open, and everything you want should be at your fingertips. Okay, so let's go see and show you how we do that.

So our new look also helps us with that. So we can really-- that's how I work. Everything is the editor. Everything else is either collapsed here with our new minimizing feature and the new look, or I have fast use on the side. But my focus is really in the code.

So what's the example ever I want to go to? Here I have the... Yeah, that's not bad. So first of all, if I want to navigate inside the file, of course I have this quick navigation. I can go to get type whatever I want. If I want to also see the inherited code, I can just do it twice and then I get the inherited methods as well. If I want to understand how is something overwritten, I have an in-place type hierarchy. which shows me what I inherited from, how is this method overridden.

Of course, you have folding. Folding we added also for that because basically what you want is when you work editor-centric, you want to often hide Java doc commands so we can do that out of the box and you open a file, we collapse Java documents that it can really focus on your code. So we have folding, we have in-place stuff.

I showed you in the debugger we do the same thing. We have in-place diff, basically. Now when I type here something, I don't have to go to compare view to find out what I changed. If we just show you here this change bar, Oh well, that's something I will show you later.

And in a change bar, I can see what changed and I can retrieve my stuff if I want to. I can revert it to what it was before. So that's the same theme, right? We want to make everything editor-centric. You don't have to do lots of hunting around to find what's available.

Similarly, we have these occurrences highlighting, this mark occurrences feature here, which basically, behind the scenes, we know the structure of your program. So the idea is whenever you click somewhere, we can tell you more information about what you have currently clicked there. For instance, you click on a parameter, we show you where is this parameter used. Where is the result computed? It gets highlighted immediately. Or similarly, here is an exception. Where is this exception thrown? You just click at it and all the place where this exception is thrown. It's highlighted.

Or you go on the return type, you click on it, and all the exit points of the methods are highlighted. And of course, you go on. We will go on with that. Now, you click on an interface and we will highlight all the methods implemented in this interface. Things like that. You will see it's really point and click. The other thing is linking. So if you just want to see what something is, you have this link view below.

I click somewhere and immediately see the declaration of it, and that's linked. Again, I don't have to do anything, I can just by clicking, I have all the context to do my stuff. Or if I click on a variable, I see the declaration, I'm pretty sure. Right, this guy here. Yeah, it shows me the declaration. Same with Javadoc, if I'm more documentation-oriented.

I will see the Java doc below as I click around. Interesting point to mention here, this is Safari, right? So we have a native-- that's our widget story. We natively integrated the platform. So which means on the Mac, when you're on the Mac, we integrate with Safari or the WebKit.

So just if you're overwhelmed with all this function, you actually don't need to remember everything that Eric's saying here. The tips and tricks section goes through and enumerates both the new capability and some of the other existing stuff. So there's a lot of things at your fingertips. Really, navigation at your fingertips. Now, if you want to go quickly to another open editor, it's just one keystroke away, right? All open editors, Java, Java, stuff like that. So you see all this interaction, code assist-like, filter as you type, this is used heavily.

So that's, I think, enough for now. Well, oh no, I want to show you one thing, and then I will stop. How are we doing with the time?

Consistently, the more validation you do as you type, the better your code gets. So we detect some unused code, new in 3.0, we detect Java doc problems.

So when you have a missing tag, when you have the wrong tag, we will flag that. And the other thing we have added, we try to help you as much as we can, so why should we stop checking the code? We can also help you checking the commands.

Okay, you see the weekly line here? So our spell checker has found that in this comment I have mistyped this. Control-1 and the same thing, like Quick Fix cannot only fix Java code, it can also help you fix your comments. So I change it back to contents or add it to my dictionary. Beyond that, there's JUnit, there's Ant integration. Time for some slide break.

It is kind of harsh to only let you demo that little amount of function because if you look at the amount of things that were done in Eclipse 3.0, there were on the order of, if you look at the pile of enhancements and bug fixes, in the last year 10,000 line items were addressed. So lots of things.

This gives you a flavor of the biggest ones, but lots of stuff occurred. So let's put JDT in place again. It's a set of plugins built on top of the platform. And what we're going to do now is look at the plugin architecture itself a little bit more closely.

So everything in Eclipse is a plugin. Look at a plugin as a set of contributions. You can look at it ranging from an HTML editor, set of things, the Java development tools. It can be a simple contribution. It can be just a menu entry with an action for that menu entry.

So the full range of things can be contributed. The plugin defines its implementation, its prerequisites, and it has this ability to define an extension point, which is a named entity. So it names a concept that can be contributed to. So we've got a very simple story here. Plugins define extension points.

WWDC ImageView.

So the way it helps you to create stuff, ImageView, I want to create the plugin with the view. There is some wizard that helps you to do that, but it generates very little code, so as we'll see. Again, this is the community helping ourselves because we're building a lot of plugins. We need to build tools to make it easier for us to build plugins. We've just kind of kept making this better and better.

So basically this extension point model is declarative, which means we declare the information you need to know about extension points in an XML file, which is called the plugin XML. And we provide you with ways to edit this in a convenient way. For instance, here we see the extensions we define here. In this case, we'll define one extension, which is a sample view. And you see what the extension has to do.

It has a name, it has an icon, it has a category, why this is needed, because you want to be able to present it without having to load the code that implements the view. So here you see, that's how we can present views. And given the information we have in the plugin XML, we can do that without loading code. So where does the code come in? There is a class attribute, and this class attribute will be responsible to implement the actual behavior. Once the user has activated the contribution, but not before. So of course this is linked. Let's look at this code.

So what, ah, I haven't told you what I want to build. So this is a true story. So we were hacking away, Kent Beck and I were hacking away, and he came in one of these Smalltalk, he had one of these Smalltalk retro attacks. You know, we want to find an image, and he said, see, in Smalltalk I would have just written a plug, some code, and would have gotten a view which shows me all these images. And of course, well, we can do the Eclipse as well, and five minutes later, we had it.

So I replay this experience now for you, and I hope I don't make a box, any problems. So I want to have a table with all the images that are used in Eclipse. So it's all the standard images. So that basically two things you have to know. There is a content provider. This is the guy who defines what is the data you show in your view. There is the label provider, and this is the guy that knows how to render your data.

Okay, so currently there's just a string, one, two, three, not very interesting. So what we want to do is we want to render here all the images. So let's go in here. So you will recognize some of the stuff I've shown before. New array, list. I want to collect all these images. Of course, I'm lazy. I don't type this stuff myself. It's fine. Well, I'm still polite. I use a collection. So then I will iterate over.

I'm going to iterate over the collection. So again, the flavor here is we've got the template generated, the plugin created the view, and now Erich's just putting the contents in for this view. So you have a class, the shared image class, that has all these static fields in it. You're going to collect all their icons. Yes. I know I will screw up once, so. Where did I screw up? I know where.

Iterate over the array with a temporary variable. I know there is a class, Shared Images. So I go to the class. I want to get its fields because all the images are stored in fields there. Get fields. "Array type, well, I'm too tired to type that. So let me, Eclipse knows that, yes, a field, that's right. Okay, here we go, and then we have to add it, we have to add it to our list.

What's the guy? Yeah, sure. Oh, the array element I want to do, huh? So, boring, boring. And we return the stuff. Return list to... So let's do some cleanup here. That's a bad name list. That's basically fields, right? Renaming file. This should be fields. All right. Again, we have some code smell here, the duplication. Let's just extract this quickly.

What is it? So let's just extract this quickly. Extract the method. So by putting this function right at your fingertips, you're naturally inclined to clean up your code as you go. You refactor, and you will see. We manipulate code like plastic. So you see again, it has this code, I have a duplicate code fragment. Of course, this will be fixed as well. So, okay, now I have to get the image. So I will just show you the object to string should do it.

And now this code is almost right. I want to pass in the name of the image and it should return it from me from this call. But it's too specific, this call. It has a hard coded parameter. So let's fix that and do object to string. We want to here use another refactoring. We want to introduce a parameter. I want to make this method more general, so I say here just introduce a parameter.

And the parameter is called field name. Actually I have code assist as the lamp tells me here, but it's not very helpful. Field name. Okay, so you see what happened is here an additional parameter got added and the call, the parameter, got also fixed up at the call sign.

So I don't need the object parameter anymore, so we do just the other refactoring, change method signature. And remove this guy. OK. So I think we should be able to run now. So let's do it in the debugger, just to be careful. So we run the workbench on-- did I press the debugger, John? JOHN WIGAND: Missed it. Can't quite focus from here.

I did do it, right? Did you do a search? Did I do a search? I did do it, right? Did you do a search? Did I do a search? Sample, Category, Sample View, and I will get this nice table with all the images. Oops. Hey, this is beyond pair programming. We program all together. Oops. Hey, this is beyond pair programming. We program all together. So we ran out, we got the labels, but we didn't get the icons themselves. The name, right? I have to put the name of the field here.

Did you notice? So I didn't tweet star, right? And we chose to do plugin development, big system, hot code in place really works. And it can happen. Now, depending on the quality of your VM, I can work for a full day without having to restart. It really depends on the strength of your VM. I know one VM which is really good that can almost survive one day of coding. So that gives you the flavor. Let's move on to the next part. But that gives you the flavor, how easy it is to start in, build a plugin, and make things happen.

So there's more to the world than just plug-ins. There's cases where you want to be able to attack additional function onto a plug-in. So logically, there's the notion of a plug-in, but there's fragments where you can provide platform-specific function, you can provide translations or subsets of translations, and there's cases where you need to be able to provide auxiliary function for other means.

So logically, we think of this as part of the plug-in, but just to show you, there's more there. So it's plug-ins plus fragments equal the logical unit. So that's basically what the runtime operates in, plug-ins and fragments. Then we have a notion of features, which is the other way. This is the deployment unit. So you deploy sets of plug-ins and fragments.

This groups them into logical chunks that make sense at the user level. So as developers, we build plug-ins. That's too small of a unit for giving to our end users. So we have this notion of feature for deployment purposes. Should I quickly do a feature? Two minutes? Let's keep moving on this. We can come back at the end. My next live I will demo it to you.

So that gives the flavor of how all our pieces come together. And just to reiterate, everything from the bottom to the top of this picture, we have the runtime, everything above that is constructed out of plugins. So the kinds of tools that Eric was showing here, we can leverage those for building SWT, Jface, all these pieces and all the pieces above it.

So transitioning on to what's new in 3.0. Now Eric leaked a lot of what's new in 3.0 already. ERIC GAMMA: It would have been too boring, right? It would have been too boring not to hide this from you. So I-- JOHN WIANDA: So we didn't want to hold it.

So we'll give you a flavor of what happened over the course of the last year. We started off listening to what issues are important to the community. So back up a year, 15 months, and the kinds of comments we were hearing are things like this. I'm lost in all these contributions. I love this plug-in story you guys have, but I've got a lot of plug-ins, and now there's more function. I can't navigate my way through all of it.

So this is really serious, and we're a tooling platform, and what we observe, what we suffer from is the tools are getting bigger and bigger and bigger. Once you have thousands of plug-ins and they all want to show their stuff in the UI, you get lost. Consider a business process modeler.

Since business process modeling is also plugged into Eclipse, the business process model will be exposed to Java. That's kind of not what they want, in fact. It's confusing to them. So you have to think about how to scale up to really large-scale applications, and that's the problem. So I think that's the problem that you pointed out to us.

Yeah. The next one, Eric's already shown us the fix for, which is I don't want to be blocked when I'm doing operation A, B, or C. So I'm doing searches, or I'm doing repository synchronizations, and I'm stuck waiting all the time. So this is in the past. People were stuck waiting, and they wanted to get that fixed. - What? This can't be true. - A year ago, this statement was being made. So people wanted to see more. We like what we're seeing. You're on a good path. We'd like to see more coolness.

We're here to serve. The third class of feedback is very interesting. The community went off and started, they took Eclipse, they were using it as their IDE, and they said, I really like some of the things I'm seeing here. So the way the UI presents itself, this plugin architecture, this is something I can leverage in my own applications.

So it's great as a tool, but I'd actually like to leverage some of this code as the basis for my development work. So the first few things that happened is people took the plugins, they threw some away, they modified a bit of code, and then they kind of set this cookbook around.

to other people, say, here's the kinds of things we needed to do to make this work. And we went from that cookbook into a rich client platform. So before we look at the response point here, this is just to give you the flavor. There's lots of input and lots of different ideas. So we structured these ideas into a set of themes that we could work on. And the kinds of themes that we worked on is mature the platform, so improve the user experience, make things more responsive, one big area.

enhance the Java IDE, which actually has many facets to it. Eric, do you want to talk about the range of things you had in mind on the platform? It's not just the things that Eric demoed. It's JDT as a platform in its own right at this point. Right. I will catch it later. Okay. So you'll come back to that and then the rich client piece.

So we'll walk through these and we may or may not intersperse a few demos. We're actually moving through the time pretty quickly. I will make fast demos. OK, so we'll get some fast demos. OK, so I'll go very fast in the description here, and then we'll get quick demos.

So the problem with large products, now we have to help the user find their way into it. So it's kind of important how you welcome them to the product. So we all think if the platform supports that, it's even better than just letting each product invent how it wants to welcome its users. So that's why we come with a standard welcome framework where others can plug in, and we support different learning styles. Demo in two minutes.

Cheat sheets, complex workflows. Complex products have complex workflows, like a web service. No one likes to go through 12 pages of wizards. That's kind of really modeful. You want to have a more guided way, but less modeful way to do complex stuff. And that's what we use cheat sheets for. Demo in one minute 30. And capabilities, I've already shown you that. So the demo you have seen for that, no, I haven't shown that.

The problem is exactly the business process modeler. They don't want to see. They want to see Java. So they want that Java gets hidden from them. Now, but imagine the business process modeler that learns Java. How can they discover that there is also Java in Eclipse? So capabilities are our means to do that.

Okay, the last one in this improving the user experience area is our work on responsiveness. We've already demoed this as well with the search facilities. But basically we're stuck in this modal world and we got rid of the modality, number one. Then number two, we did such a good job of getting rid of the modality, the users didn't realize things were happening in the background. So then there was, did I do it? And then you found the build, build, build characteristics. Then we needed to do another iteration on how the user experience worked to make sure the user was in control of what was happening, they understood how it was working.

I think in fact that at least four iterations, right? So till we got this right, that we really felt that user in control. It was really one of the most challenging things we have. So can I have the screen please? Quickly, welcome. Imagine, I will not do it now, you just start up your screen for the first time, so you get the welcome experience. The welcome experience is kind of, you can compute to it, you can compute documentation to overview tutorials for the different learning styles.

Pretty nice eye candy. Samples, that's interesting. Those samples get fetched from an update site, installed dynamically on your workspace, so that you can explore them. Or if you're just bored of the stuff, you can just go to the workbench. So that's the welcome. The nice thing is it's extensible, you can define and you have a mechanism to compute this in the platform. Cheat sheets. So this is non-modal multi-step operations. So let's do a-- Hello World application with G-G. That's not a typical application. Consider making a building a web service, something really complex, multi-step.

So here's my cheat sheet. Cheat sheets are modeless in a view. They guide you through stuff. And they're active. Some steps, they provide you with actions that you have to fill in. When I create a Hello World project, I have to create my Hello World project. So hello world, finish. The nice thing is now the user is in control. Hello, source folder, finish.

So you see how this basically works, right? You have always access to documentation, you have active links, you know where you're done. If you want, you can go back and revisit the stuff, things like that. What's nice is it's very easy to build these cheat sheets. It's really mostly a configuration task and a coding task.

So basically you describe in XML what the steps are, you define the actions that should be called out, and off you have your cheat sheet. Much less programming is involved in coming up with a wizard, okay? What was it? Capabilities. Capabilities next. Again, it's your transition capabilities. These are all facilities provided by the platform that plugin developers can leverage and that users gain the advantages of.

So capabilities are almost too simple in Eclipse because Eclipse now has about 60, 70 plugins by now. A real rich product can go to 100, 500, 1000 plugins, which is 5,000 features. So in Eclipse, you basically have grouped the functionality into capabilities, development, and team support. When I don't use CVS, I don't want to see CVS in the UI at all.

So for instance, plugin development, I will disable it now because when I just look at Java development, I don't want to be bothered by plugin development. So I disable it. And the thing is, hiding function is easy. How does the user discover it once it's hidden? So for fixing that, we have I'm going to show you how to use the plugin project to create a new feature. The plugin project is a trigger point.

I still see it. It's intentionally not filtered out. But when I say next, the system will remind me, hey, this is actually a capability you haven't seen yet. Do you want me to enable it? And when you say yes, then all the contributions will show up in the UI. OK, so that's basically how it works. So the idea is reduce overload of menus, toolbars in a feature oriented way. Back to the presentation.

So enhance the JDT we've went through for the most part. So I'm going to go through this pretty quickly, and you can talk as fast as you want. And I'm going to keep flicking. No, I have to stop there. I haven't stopped there. Java family, that's another thing.

Once you have done Java, you notice when you do development today, you have other artifacts which refer to Java. When you do struts development, you have class names in the struts description files, or when you do a web app or a new JSP. So we have thought we really have to support that. So we open up, we allow others to participate in our stuff. And see, I heard it that much. I'm talking to the wrong slide.

Okay, still. So we have to handle JSPs and other stuff. Rich API, we want to make JDT a richer platform. If you want to write tools that manipulate Java source, we have extended it. We have added abstract syntax tree APIs, which not only allow you to analyze Java code, but also to modify it. We have an AST rewriting API.

We make our own function open that you can extend it. Quick assist, quick fix, you can compute to that by extension points. And what's very important, and that's, you see, our design style, we start pioneering new stuff in JDT, and over time we push it down into the language-neutral layer so that others can also be cool.

So the linking stuff, you have shown the linked editing, it was pushed down one layer below so that other tools, like the C development tools that you also have in Eclipse, can leverage this as well. Refactoring support, just the same theme, participation, enhanced JDT, we have seen that live. We've seen these as well. We have seen this.

So we didn't talk about this one yet. The work for J2SE 1.5 has been ongoing throughout the 3.0 development cycle. We decided somewhere in the spring timeframe that it didn't make sense to try to release that with 3.0, but the work's in progress. You can download it. We've codenamed the effort Cheetah, and we're going to be working on it from when we started early this year through the summer and fall.

The primary effort so far has been in the compiler and extending the compiler region, but it turns out there's lots of tooling opportunities here. This was one week ago. So one week ago, most of it was focused on compiler, but since I've shipped 3.0, everybody was eager to do new stuff.

So I guess by midnight tonight, if you go to the update site, you get not only a core compiler plugin, but also a UI plugin. And with this, you can already browse code which uses 1.2.5 features, and I also checked the JCK coverage, and we are now at 97%. So it's tremendous progress. But the nice thing is we leverage our plugin story to not risk the main 3.0 stream for now. But now after 3.0, we will immediately merge the streams and work on the 1.5 support.

So we've done this demo already. So we'll move on to the rich client piece. A wide range of comments from the community on this one. So the first is, I've got all these plug-ins in Eclipse more than I need, so I'd like to be able to get rid of some of them. The second, although you've given me too much, some of these are not IDE specific. So we've kind of talked about optional plug-ins already so you can get the flavor of that. And the third is just the request. I'd really like to be able to build my application.

on top of Eclipse. So what did we do? I'm just going to give you a little bit of a philosophy statement here, and then we'll run a brief demo. First, we remember we're a tools platform. We started off tool-centric. We didn't want to lose that, so that's quite important.

However, some of our decisions were IDE-centric, so we wanted to remove that predisposition and move that to a separate layer. So we'll have a generic workbench with a separate layer that has the IDE specific characteristics in there. An implementation detail, we also knew about projects. We'll projects don't make sense. That's the wrong data model for a rich client application, so we needed to break that linkage.

and then provide optional components. So that's what we set out to do. The simple version, given we have no time anyway, is we just took the UI plugin, carved it in half. So we took it, it was IDE specific, we made it a generic workbench, so a generic component, and then we layered on top of that the IDE specific stuff.

So my name is there? Your name's on that one. So basically what I will show you is now how you can liposuct Eclipse to run really simple stuff, but still having all the Eclipse plugin infrastructure in your hands. So I will run this famous HP 35. HP 35 is a famous calculator. Mind you, it's kind of a computer museum. It can even calculate. Eight, nine, enter, nine plus. Great.

What you see here, that's an Eclipse application. But you see there is no project management, there's no build. It's really liposucted to vanilla application, right? So you have the choice. You can basically liposuct it to almost nothing. And the nice thing about our rich client platform story is everything is optional. You want to have help? Sure.

Install the help plugin. You want to get some resources support? Install the resources plugin. So you can grow and there's a spectrum of functionality you can get from Eclipse. But the key point is you always get the component model, the plugin model with your application. Which is, I think, a really good thing to have. So the last thing, I'm not sure whether I'm navigating really advanced.

What I want to show you is we have a new runtime. We have built the runtime in 3.0 on top of a standard component model, OSGI. And the idea was for 3.0, we want to have dynamic plugins, which means plugins which can dynamically come and go. And I will show you that.

So first, let's look at the plugins which we currently have. Okay, we see we have 15 plugins now installed in OSGI. This is called a bundle. And I will now go in and install another one and then see what happens in the UI. So I need to file one.

So one of the characteristics we got when we moved to OSGI is the ability to dynamically add plug-ins and technically we're able to remove plug-ins from the system. So what Eric's doing now is he's going in, pointing to an area in the file system saying there's a plug-in here, let's install it please. So if he can type the path correctly. Bundle ID 16. Now we start it. And you have to watch over here. So basically I have done a plug-in which extends the calculator to the new operator. So I start 16.

Boof. Okay, dynamically the plugin gets loaded. Well, we always load plugins dynamically, but we now have mechanisms to also update the presentation, the UI of your plugins dynamically. And if John lets me, I even calculated it once. Yes, you're right. Multiply with zero. Okay. You should have stopped me. Very good. Let's go back to the slides. So a reminder, Eclipse 3.0 available today. Turns out the final bytes went up on Friday and they're available for everyone to put to use.