Good morning and welcome to the last session of our Worldwide Developers Conference '05. You guys are the true die-hard developers to be here today. We have a great-- excuse me. We have a great program with the Eclipse guys. And so without further ado, let me go ahead and introduce to you Bjorn Freeman-Benson, our technical director for OS Processes and Infrastructure of the Eclipse Foundation. Welcome Bjorn, please.

And so just to be completely clear, OS is open source, not operating system. So the thing that I wanted to talk a little bit about for a few minutes to the few people who are still here is some of the overviews of Eclipse. And then Daniel is going to come up and give some actual hands-on demos. And if you guys had, say, gigabit ethernet fiber to your laptops, you could, if you hadn't downloaded Eclipse yet downloaded onto your machines. On the other hand, we're betting that if you start now, you're not going to finish in time. So if you've got it, you can play along. If you don't, you can get it later and memorize what you did.

The general thing about the Eclipse development environment is that it's not just a development environment. Originally, in version one of the Eclipse project, it was a Java IDE. But since then, the Eclipse Foundation and the Eclipse member companies have been working to build it into more than just a Java development environment.

Although today's talk with Daniel's demo is going to emphasize mostly on the Java development environment, I wanted to say a few words about some of the other things as well. But before I do, I'm curious how many of you actually have used Eclipse, downloaded Eclipse. So if I do that general stuff, you already know those answers. And in fact, Daniel, you might want to speed up the first few slides or something, because these people already know what they're talking about. So many of you might have already seen these slides about what is Eclipse, but I'll go over them a little bit. We claim on the Eclipse Foundation that it basically is four components. There's a client runtime. There's a number of extensible application platform frameworks that you can build on. There's some extensible tool platforms. And then on top of that, the thing we're talking about today is the Java development tooling. Now, you could just subtract the Java development tooling, and you could build some other tooling on top of that. So we have a C++ tooling. We have Fortran tooling.

We're going to have Pascal soon. We have COBOL. We have test and performance. We have business intelligence reporting, and a whole bunch of other things that are built on top of the same tooling platform. Or you can subtract it even farther, and you could get a runtime system that you use for rich clients. So you could just build a rich client platform with the basic user interface things. You could build some tools. Or in this case, we're going to talk about Java development tools.

The interesting--well, so when we talk about the Java development tools, you guys have-- almost all of you have downloaded it. I didn't actually notice how many people hadn't raised their hands, but there's what it looks like. It has, you know, boxes and sort of things, you know. If you look over here and if I press the button right-- oh, I guess it doesn't even work-- you have, you know, all the things that you expect in a standard development environment.

The interesting thing to me about the Java development tooling of Eclipse is that it keeps an entire model of the Java program in memory while you're busy editing it. And so that allows you to do interesting things from the tooling perspective that you wouldn't otherwise be able to do if you were just looking at text. So we have the usual stuff like automatic background, incremental building, and so on. But we have things like this, like code assistance and code completion and these sort of things. And you can do these strictly based on text pattern matching. But Daniel will show that if you just use text pattern matching, there are a few cases you can't catch. But if you use an actual model behind the scenes, you can catch more information about the system and do better versions of code completion. You can do code completion for Java 5 generics and keeping track of all the type parameters and the wildcard type parameters and the constrained wildcard type parameters and that sort of thing.

You can do linked editing, which is down there at the bottom. So linked editing is where you go to, say, a variable name in the Java program, and you rename it by typing over it, and it renames all of the others at the same time throughout the program simultaneously on the screen, because it's got a model back there, and it's not just text replace of each one. It's actually changing that model element back there. Now on the debug side, it has the sort of things that you'd expect from a modern programming environment. Hot code replace if your JVM underneath supports that. You can evaluate expressions. For those of you who know the history of the Smalltalk language, a lot of the people who built the JDT tooling for Eclipse came from Smalltalk, and they really missed being able to evaluate expressions on the fly, so they added that in. You know, it has searching that you would expect. It has... refactoring tools. It has Ant. It has JUnit. It has these things that you expect when you're developing with Java.

More important from the point of view of the Eclipse organization is that it's got these extension APIs where you can extend the existing Eclipse to do other interesting things. So you can build your own tools on top of these frameworks. You can extend these tools and frameworks yourself. So this little picture over here is a picture of some of the searching that you can do because, again, you have that model in memory so you can search not just on text things but also actual code fragments.

One of the things that these standard slides that the Eclipse Foundation likes to show, talk about, is that Eclipse is built on a series of plug-ins. I personally, even though I'm from the foundation to talk about it, don't feel that that's such an interesting thing, because everything these days is built on plug-ins. Operating systems are built on plug-ins. I mean, I think my Toyota Corolla is built on plug-ins. So here's the slide that says everything's built on a plug-in.

So as many of you who know Eclipse know, we have released 1.0, 2.0, 2.1, 3.0, and now 3.1. And there were a number of themes in each one of those releases. For 3.1, the themes were scaling up, being able to handle much larger programs, making sure that we had Java 5 support, making it enterprise ready, which I'm a little vague on exactly what that term is, except that there are a lot of large customers who want to build large systems with many tools. And then the one at the bottom, design for extensibility, is be a better platform. One of the things that the Eclipse Foundation and all of its member companies are trying to do is not just design the best Java IDE, but to build a platform on which other companies can build successful tools. So we're not just building a successful IDE, which is what Daniel's going to show you, but there are a number of APIs that you can build your own tools on top of, or build them and sell them. One of the big emphasis that the Eclipse team, especially from IBM, has spent a lot of time on the entire history of Eclipse is making sure that the performance is good. And it's one of those things where it's not a single large task that they did, but they constantly worked on incrementally improving each of the little things that they could to get the performance better and better and better. As you know, building a system that works fast is just a non-trivial task. And they have this nice little graph that shows their tests. And a few of them ran a little bit slower. They run this on every single nightly build. And it shows what the performance characteristics are.

in spite of new features. The reason for this, of course, is that people are building larger and larger systems with these things. And so if it performs, if it parses Java and compiles it at a particular rate today, tomorrow when your programs are 50% larger, you'd like it to be just as fast.

There's a number of user interface improvements. I can sort of wave my hand. There's more preferences, which means-- although, personally, I can't see that as an improvement, because it just means there's more things to configure. But I guess it means there's more things that can make it look exactly like you want it to. We have dynamic help. There's lots of new quick assists, so you can get comments on your code. You can get critiques on your code. You can refactor your code, and so on.

There are a few things in the runtime. Maybe the only interesting one is this Java web start. There's a few other things. You can sign your jars now. You can make your plug-ins as a single jar. Again, for people who are just using the tool, it doesn't really matter whether we have bundle permissions underneath. You don't really care. That would only be if you're planning to, say, release secure applications with it.

And then, of course, there's the Java 5 features, which are perhaps the most significant change I feel in the Eclipse JDT for 3.1, which is, you know, as you know, Java 5 has a lot of new typing features and so on, which add a great deal of complexity to the parser and therefore to the IDE. So for instance, when you're doing Code Assist, you want to make sure that the Code Assist handles generic types and wildcarded types and constrained types and so on. And similarly with refactoring. Now you can go and refactor and you just do-- instead of just the simple ones like rename or move method up or move method down, there's refactorings that take types and make them into generic types or back and forth. There's ones that take collections and map them over to generic collections. So there's a whole bunch of refactorings that you would use when you're actually developing with Java 5 code. Java 5 does auto-boxing. So one of the things that the compiler does to make sure that you-- one of the problems with auto-boxing, of course, is if you accidentally use it, you might get results you didn't expect, or you might get performance problems. Because while it's handy, it does have a cost. So you can turn on a feature in the compiler, and it'll tell you where all the auto-boxing is happening, highlighting them with little yellow underscores and that sort of thing.

And then, you know, on the enterprise-ready side, this is building big applications for big customers. And, you know, it used to be big customers meant Wall Street banks, but now there's other big customers, too. And so there's a lot of things in here, like shared settings per project, so that, you know, if you're working across a large team, you can have multiple people sharing the settings. One of the ones I really like is the NLS hovering and linking. So that's natural internationalization support.

And in Java, you use a bundle, and you go out, and you get the resource, and you format into the string, and you put it off. But of course, when you do that in your Java code, what you have in your Java code is a magic key. You don't have the actual string. But the Eclipse IDE will now show you the actual string in the editor, even though it's stored in the bundle. And you can switch back and forth between the bundle and the actual string by hitting, I think, it's the F5 key. It'll take you there or it'll take you back again. And it'll also do spell checking across the messages, even though they're in a text file rather than in the actual source file. And so they've made the support for making internationalized applications, at least at the text replacement level, much easier. Now, of course, there's a lot of other features in making an international application. But I'm sure that in 3.2, they'll get farther along on that.

And then here's that thing about better APIs. There's generalize, undo, redo. I'm going to sort of wave my hands here. Just saying better APIs doesn't really solve your problem unless you had a specific problem that you needed an API to solve. If you're a tool user, it doesn't really matter whether the tool is well-built underneath or not, as long as it's solving your particular problem. One of the things that they've been working on in 3.1 is this language toolkit enhancements. And they're going to work on that substantially more in 3.2 to make it easier to add-- See if I-- to add new languages. So at the moment, it's quite easy to add a new Java-like language and not so easy to add a new non-Java-like language. But there are many other languages out there that you might want to incorporate. And so they're working on making the support for languages more generic and less Java-specific.

One of the things that was announced recently, I think, was it Tuesday? was that the Apple people actually have a universal binary now for the Eclipse development. So it'll run on the new Intel processors as well as the existing processors. And that you could do this without making any code changes, just slight make file changes, and it recompiled, which was quite nice.

And I don't know why this slide says what you'll learn this afternoon, because by my clock, it's evening. But hey. So Daniel-- from, well, anyway, welcome, Daniel. Thanks. Thank you, Bjorn. Thank you. So I'm going to take you through a couple of examples that stress the Java model that Bjorn was talking about. I used to write an article about once a year for O'Reilly called The Ides of Mac. And we'd look at different IDEs. And then I'd go back to using VI and the command line. And finally, there was a reason to stay with a smart IDE that understood the Java model underneath. So for those of you that haven't played with Eclipse since 3.0, you can come back and look at it because it actually runs at a pace that almost keeps up with you. For those of you that haven't used Eclipse regularly, there's some features that are really nice. If you're really familiar with Eclipse, then start thinking about where you're going to be going tonight after.

So if you've got Eclipse installed and you'd like to fire it up and follow along, that'll be fun for all of us. The first thing you have to do when you start up Eclipse, and this is something that they often stress, is starting a project is not a common activity. It's working in a project day after day. So these aren't the steps that you have to take over and over again.

But identifying a workspace, and this is just your own private preference. Do you like to keep all your projects in a single workspace? Do you like to keep different projects in different workspaces? It's the way you want to organize your work. Different people have different preferences. The same way that you might keep all your files in a one subversion repository, you might spread them across several of them.

Once you've selected your workspace, go ahead and create a project, and we'll go through this quickly because you're all pretty familiar with this. The two projects we'll talk about today are a regular Java project and a plug-in project, and this might be the best trick to take away with you.

If you haven't seen it documented and you forget what the keyboard shortcuts are, make a note to yourself, Command-Shift-L, and that should bring up all the available shortcuts to you in Eclipse. Okay? So let's go to the demo real quick. And we're going to fire up Xcode because we needed some code that you could work on. And so there's nothing better to work on than the spotlight-- I'm sorry, the swing template in Xcode.

And so my favorite feature, how do you know Xcode has started? Well, you don't. So if you start up and create yourself a Java swing application and give it some name that you can remember, like WWDC, And now let's open up Eclipse and we'll use that code. So quickly, we'll get to the Code Aware stuff. You need a workspace. Choose any workspace you'd like.

Then you're going to fire up a new project, dance around quietly while Eclipse starts up. That's much faster than it used to be. So that's quite an improvement. They're at release candidate one right now. They're going to release candidate two. And then I think at Java 1 is when the final release of 3.1 is-- is that right? Well, if everything goes well, just before Java 1, the final release of 3.1 will be out. And the Eclipse download servers will be absolutely maxed out. That's the goal. So we're starting up a Java project, following the wizard.

And if we zoom in a little bit, give it a name like, oh, hands on. And we're going to create it from existing source. In this case, we'll find the code that we just created. In our home directory, there's WWDC. Choose it. Finish it. Along the way, Eclipse tries to help you out. It realizes that you're creating a Java application. And so it asks you if that's how you want to look at it. And of course you do.

Is that disconcerting to see that wave back and forth? I'll stop it then. So if you look at what it's created inside a default package, because there is no package that was created for that swing application, you see the three classes that are created for you. One of your best friends in Eclipse is the preference panel, and let's start there. Let's close off this and close off this.

I've already got problems. I'm reporting a whole bunch of errors there. Now, There are several ways to deal with warnings. And we're going to choose my favorite way, and that is to ignore them. So let's go to preferences. One of the best things you can do with Eclipse is get familiar with the preferences because most of the assistance is configurable. If you find it annoying that it pops up things and always reminds you, you can turn it off. If you find the level isn't strong enough for you, you can turn it on. So here under Java, under Compiler, under Errors, I get all the errors that I could get warnings about ignore, and here at the top of potential programming problems, I find the one that I'm being warned about. I can change it to error for a second and apply it. That requires that you rebuild.

and you see that these all turned red, they've now changed from warnings to errors. And now, of course, if you want them to go away, We rebuild. And we don't have to worry about the serializable problem. So let me interject just one thing here. One of the interesting things about the Eclipse compiler is that even if your project has errors in it, you can still run it, because the compiler actually produces class files for all the files, even the ones with errors in them. It just puts in an exception called there's an error here, wherever it finds an error, whether it's a syntax error or programming error like that. And so then you can run your program for as far as it can And if you didn't actually hit that statement or that class, it wouldn't stop. You find that often you aren't looking to build it.

It's just building as you go. And so the model's constantly being updated. And so if we take a look at this. We can run this. And right now, I'm Control-clicking on this and selecting Run As, Java Application. And there's your standard swing example. So if we can go back to the slides, please.

So let's look at some of these Java model aware things while I quickly flip ahead behind your back to the next demo. DAVID BADRE: Well, actually, strictly speaking, it's behind your back. JOHN MUELLER: It is. DAVID BADRE: It's not behind their back. So let's look at the things we can create. And you can see in the middle, the new things added for Java 5 are, of course, enumerations and annotations.

At the top, the things that you might want to create are packages, classes, interfaces. And at the bottom, we'll take a look at JUnit tests in a minute. One of my favorite parts of Eclipse is that JUnit is deeply integrated. And we'll take a look at that. So when you choose to add a package, you'll notice that there's this model thing that keeps coming up. There's a strong correspondence between folders and packages. Now, if you've used just a text editor, or you've used, oh, say, another IDE that doesn't have that correspondence, this might feel different for you, but it's nice that there's this very Java-aware environment for you. Right now I'm taking the first steps to Conway's game of life where there's cells that you turn on and off and and so I've created a package named life inside of this and Within that package, I'm going to create a test case So a J unit test case are most you familiar with unit testing Great And so we say, let's create a new test case. Along the way, again, Eclipse knows that if we're going to create a new test case, then we need this JUnit jar in our path, and so it helps us out by putting it there if we want it to. And then it gives us some choices. It says, well, you want a test case. Where would you like it to be? And so, for example, if you don't know what package, you can click Browse, and this guy will come up and allow you to browse to the package you want to put it in. You get to choose a name for it. and the superclass. And this is more important when you're creating classes than test cases. For those of you that do know JUnit, you know that it's often useful to set up or tear down. But because we do the simplest thing first, we'll start without that.

When you create it, all that information that you just stubbed out gets generated for you. The package information is there. The fact that you extended test case is up there. And so, of course, if you extend test case, you need to import it. And so there's the generated test class. Not deep, but really useful. And if you're doing this every time you create a new class, it's nice to have a tool that works with you. So let's take a look at a demo of what we might do here. And so, doesn't exist. I had this nightmare. Yeah, but at least in this nightmare, you have your pants on. Yes. Well, that is useful. Let me switch back to the last workspace if it'll allow me to and see if I can continue. Wow.

Okay. So what I want to do in this demo is when we created the original version, we had a bunch of cases-- a bunch of classes that were in the default package. In Java 5, at least, you know that that's definitely not a good thing. In general, it's not a good thing. So let's take a look here. Thank goodness there is a default package there. So let's create a new package.

Let's give it a simple name like GUI, G-U-I. I've got my new package. And now here's a nice little Eclipse feature. I've got these guys that were living in the default package. I want to move them to the GUI package. If I right-click here or control-click, you see this refactor menu? This refactor menu is your friend. Right now it tells you you can only do two things. It's context-aware, so in different settings, it will offer you different refactorings. In this case, what I want to do is I want to move these three classes, and I choose where I want to move them. I want to move them to GUI. It checks on them. It moves them over. It thinks a bit. It decides, do I want to crash on them and embarrass them twice in one day?

It moves them over, and if you take a look now, you'll notice that at the top of about box, it's added the package statement. It knows that when you moved it over, it had to add that declaration. So again, it's helping you along the way. We doing okay? Okay?

OK. Let's create a new menu. And actually, the version that didn't run, I'd increase the font size. So let me do that again for you. And so under Appearance-- Suddenly the day's gotten much longer, huh? Well, not for you. Adjust the font size. Waiting is a feature. That's another cup of coffee waiting to happen. Maybe not waiting this long. Let's apply it. Great. So let's add a new menu to the main class.

Are you all familiar with this template? Is it like your favorite code? Later, I'll tell you a story. So let's add another menu. So if I add a J menu and I call it Help Menu, and I, excuse me, say equals a new JMenu, I'm not going to be as proper, and that is one thing that Apple is very good at doing, going to the resource bundle so it's nicely internationalized. I'm not going to do that. I've just added a help menu.

And let's add a JMenu item. And let's just do that by saying, Help Menu, what can you do? And it pops up and tells me all the things it knows how to do. And so one of the things I'm going to ask it to do is to add something. What can it add? It can add a new J menu item. And appropriately enough, let's call it don't panic.

And finally, let's add this help menu to my main menu bar. Add. It knows what to add. I'll show you in the next demo why I've done it this way. We're going to show you another way to do it where it just thinks for you. So did you have to do anything special to get it to pop up what it's going to do? I didn't because I waited long enough. I could have by doing control space if I was impatient. You're good. So we run this.

We've got our new help menu with the don't panic item. We don't like where the menu bar is, but in the interest of time, we won't bother adding the system property. We'll just press through. Back to the slides, please. We having fun? Gosh, yes. This is one of my favorite features, programming by intention. You couldn't have even imagined this a while ago. Programming by intention says you're coding along, and you say to yourself, gosh, I'd really like a class named this. So you type in the class name, and the program doesn't freak. It says, would you like me to create this for you? And you go, okay. And then you say, I'd like this class to do this. And the program understands what you're doing. So some of the help that you have available to you in Eclipse is the light bulb help, some source hints, and then refactorings, which are your best friend. So the idea is whatever you want, you pretend it exists. So I want to create a new cell object. I say cell, cell equals a new cell. And Eclipse lets me know that there's something wrong. You can see this in two ways. You see the red squiggly lines under cell and new cell. And you see the light bulb with the X on it says something's wrong.

So what's wrong? Well, first of all, there is no cell class. Second of all, there is no no argument constructor, although if you created a cell class, chances are you'd have your no arg constructor, and so the code won't compile. That's where I disagree with you slightly. It will compile. It'll just compile with an error. Thank you.

Is that a feature? No, it actually is a feature. I use it all the time. I write my code and then I don't complete it all and I run what I have so I don't have to finish the program before I start. So this is great with students who, if you're a teacher, with students whose relationship with the compiler is not a friendly one and they think that the compiler is not there to help them.

How can we fix this code? Well, Eclipse lets us know, and it's pretty darn smart. It says, you've got lots of options here. You've typed in cell, and maybe you're mistaken, or maybe it's what you meant to do, and here's some things that we could do to make that code work.

So in this case, we'll choose to create the cell class. We again get this helpful little pop-up, and we choose what package it's in. We choose its superclass. Now, everything in Java, of course, has a superclass, even if it's just plain old object, which it is in this case. And we decide what we want to happen here. In this case, I've changed the modifier from public to default.

And there's the generated cell class. Can you back up one slide there? No. No. So one of the things they've added in 3.1-- I'll just show you here. You see how properties is now an active link? So when you get a dialog box like that and you click on that active link, it'll take you to the dialog box to set the properties. So you can then configure it. You don't have to remember which menu it is and so on. It just tells you this is the thing that affects that particular checkbox. Cool.

So already you're seeing that this is better than a text editor. It's anticipating, it's helping you, it's working with you. Not that I'm saying anything about VI or Emacs. So let's take a look at how this might work. So if we can go back to the demo machine, please. So if we go back to the Help menu, We've already added this new J menu item. Let's add something else in here. And so what I'm going to type in here is help menu, add O fine towel.

Seem perfectly reasonable to me. I know what Find Tal is supposed to be. Apparently, Eclipse doesn't. And so let's see what it's telling me I can do. I click on the light bulb. This is magic to me. It says not only what it could do for me, but if you look in the right side, it gives me a preview of what the code's going to look like if it does that. And so in this case, one of the things it can do is create local variable findTowel, but it's not done yet. Thank you. So we created the local variable. Something's still wrong. What's wrong? I haven't-- well, I'll let it tell you. You need to initialize the variable. So we let it initialize the variable.

Now, you'd think Eclipse would know exactly what's in my mind. I'll take that back and let them know. Huh? I'll let the developers know that that's a problem there. But that's pretty far. The fact that I actually have to write a couple words of code doesn't worry me too much. So I can write a new JMenu item, knowing that Bjorn is going to have that fixed in 3.2. And let's call that fine towel. Run it.

And that's programming by intention. I think that's pretty neat. We have the slides, please. Okay, programming by intention is one way to go about things, but there's times that you know what your intentions are, and you're typing along, and you just like to know what's available to you. Now, you see this in other IDs. It's very common that you start typing a package name, and you do javax. and all the options pop up, and that's useful, and we saw that before. And that's more of what I think of as code assist. And so to activate code assist, that's what Bjorn was getting at before. The two ways is if I pause long enough after typing my frame dot, it'll pop up. Or I can just do control space. Control space is really nice if you're in, say, a class that extends J frame and you don't want to do this dot so that you can see all the things available. And you just do control space and you can see all the things that's available to you. The other thing is the amount of time it takes to pop up is configurable. It's really the way you code. Sometimes it pops up too fast for you and it gets in your way, and sometimes you just don't want to wait that long. So you go to the preferences and you can set that time. Thank you. So for instance, in the test cell method that we wrote, if I'm in it and I type that I want assistance, here are all the methods that are available to me. And that should look familiar to you if you've done any unit testing using JANET.

For once you've got assert true, you've got this pop-up message that lets you know that, well, here are the arguments it's expecting. It's expecting a string that's the message and then a Boolean condition that it can test against. And then let's say inside of insert true, what we're testing is, is the cell alive? And now we're back to coding by intention because there is no is alive method in the cell class. And so these things work back and forth. But again, it knows I don't have an isAlive method. It prompts me, and you can see that that's how it stubs out. In this case, we're choosing the simplest thing, and so isAlive just returns false. 1 And there's the generated method. That to-do is very nice. To-do then appears on your tasks list. And so you can see all the things that you have left to do. Click on one of them, and it takes you to where in the code you have to complete it. And as part of the Enterprise Ready thing, you can configure that to show any number of tags. So you can have the way we program is we have a different tag for each person in the project. And then I can select to show all of the tags, the to-do tags for all the people, or just my tags, or just Daniel's tags.

OK, so if we take a look again at the demo, please. We've run the GUI code here. And let me look at the About box here. Here's the About box. Not very interesting. So let me get rid of it. Let's go to aboutbox.java. And under super-- Let's see what we can do to add to this. I've got an About box. I'd like to customize the color, perhaps. I don't want to write this dot to see what I can do, so I use Control-Space.

I see all the things that I can do in this guy. And so one of them is set. What can I set? I can set the background color. As soon as you see the guy highlighted that you want, you can stop typing and just hit Return. And so I'll hit Return. It tells me it's going to take a color. What colors are available here? Well, cyan works for me.

And so Code Assist is a wonderful thing. Code Assist has enabled me to very quickly find the methods that I want, find the parameters that I need. And now within the About box, I have a beautiful blue box. Slides, please. How are we doing for time? When your demo crashes, you go faster, don't you? OK, let's look at running some tests.

This is a different view of JUnit. It's actually inside the IDE, so you're not running it as a standalone. If we run JUnit at this point-- and I'll show you what we did. Instead of running it as a Java application, you just right click and choose to run it as a JUnit test. What's nice here is my tests are running green, and I'm feeling good because I tested that when I created a new cell, it should be dead, and isAlive always returns false.

That's a pretty trivial way to get your test to pass. You should always do the simplest thing, and then you should make it fail again. So is a live cell alive? Let's create a new test method. And so we've decided to test a new cell should be dead. A live cell should be alive. We have a set alive method that doesn't exist yet, so we use a little help.

We run the test as soon as the code compiles, so we have to add the setAlive method. Let's just do nothing inside of it. isAlive always returns false. That used to be a good thing, but now, of course, my test will fail because a new cell will be dead, but a live cell, the call to isAlive, will also return false. Thank you. So we muck around in it. We've got a fool with it. Watch this. This is what I'm saying. If you're used to coming from the world of just text programming and not the model underneath, you see those three lives?

I didn't know that Eclipse put orange circles around things. That's pretty cool. How do you make that happen? It's in 3.2. Oh, OK. Those three Alives are different from those two Alives. Not all the Alives are the same. This is part of the magic of the refactoring, that if I wanted to-- This could be a much-- Oh. If I wanted to change these two Alives to a different name, it would leave the other ones alone. It knows the difference between the Alives that refer to this local variable from the ones that refer to the instance variable. And in spite of the fact that the orange circles didn't come from Eclipse, the yellow highlights do. Yes. So you can highlight the variables. The art department didn't think that was clear enough, so there's your orange circles.

So highlighting is smart, and that's a huge thing, and that's what enables this refactoring, or more accurately, the same thing that enables the highlighting is the same thing that's underneath the refactoring. You can also, though, if you want, just use regular, regular expression, look for text, and replace it. So you can just be searching everywhere for some string and just replacing it that way. And there are times that one is useful, and there's times that another is useful. And so, for instance, you'll find all over this swing code, this.gitcontent pane. Well, in Java 5, we don't need that anymore. One of the nicest things was you no longer need to do getContentPane.add. You can just do direct add. I know it sounds like a small feature in Java 5, but boy, it feels good.

Common refactorings and one of the major code smells is when you see repeated codes. So for instance, the fact that you created a cell each time, you pull it out. If you look at the available refactoring, so if you want to take this code back and then right click on it with Eclipse and see what refactorings are available to you, you'll see that you can make the local variable into a field, you can extract the instantiation, you can pull it up, you can use your setup method. And so your resulting code is much cleaner. You've only created your cell once. You've got your declaration. It's private cell, cell at the top. And inside the setup method is where you instantiate it each time you run a test method.

So once more to the demo machine. And while he's switching to the demo machine, the interesting thing-- well, another interesting thing about that highlighting of the yellow variables and so on is that that works also in Javadoc. So the model that Eclipse keeps behind there is not just for the source code, but also for the Javadoc. So you know when you're typing Javadoc tags about like C, another method, and another class, you can go to that Javadoc tag and press take me to the definition of this method, and it'll take you right to that source file Because it's not just textual substitution, it's actually a model, and it works on the Javadoc side as well as on the code side.

So we talked about all this Java 5 stuff, but where do we set that? So let's look at the preferences again for Eclipse. And if we look at the preferences, we're actually going to set it in two different places. And so if you go down to the Java menu, we're going to set it for the compiler. So you see the compiler compliance level. And so that's what it's going to use to enforce at this level for all the new keywords and such. If I apply that, well, something's changed. We have to rebuild it. And the second place is I'm going to go down to install JREs. And even though this looks like checkboxes, these are radio buttons. And so check Java 5.

And now we're 5.0 compliant. We've got problems. We've got problems already. So the method show is deprecated. So it takes us to show, and we think, well, it's deprecated. It's got a cross through it. You know what? I don't need it. Once I've set visible to true, I don't need it.

So I've removed it, and my problems go away. OK? I'm looking at my notes here because my stage demos aren't there. Sorry about that. So I wanted to show you a find and replace. And so if we look at pref pane-- So here's two different ways of renaming. If I have Prefs text here, do you see when I clicked on it, all the other things that are highlighted, those are other references to the same variable. So that's what Bjorn meant was that wasn't an artifact of the slide. That's actually in Eclipse. And so if I choose to refactor that, a shortcut to refactoring, which you'll come to love, is Alt-Command-T. And so one of the things I can do is rename.

If I rename it to preferences, text, You'll notice that all the instances are now renamed to Preferences Text. I know, but it saves you. The other thing you can do is do a search. And so I can do a search for this.getContentPane. And I can choose to replace that with anything, including replace it with nothing.

in all three files. And now I've cleaned up all the this gate content paints from my files that easily. You can replace one. You can replace just in the file. You can replace all. Any other magic I was going to show you? Oh, yeah. This is kind of cool.

Not only does Eclipse know what you do want to have, Eclipse has a good idea of what you don't want to have. And so let me add an import statement for something I don't need. So let me do import javax.media.jai. I feel so proud of myself. I've imported this new package. And do you see the yellow underline there?

Eclipse knows that I've imported something, and I never use that import. And so for those of you that don't use dot star and use specific ones, as you no longer need the classes that you've done an import for, you get flagged and you get told, you don't need that anymore. Do you want to get rid of it? And so we can remove the import because it's not needed anymore. And that's a nice way to clean up code, because otherwise it just gets gooier and gooier.

Boy, there's a thought that just went flying somewhere. Well, one of the things I use that scheme for is I actually never write imports because I find them redundant since Eclipse will do them for me. So I just write all my code and it says, well, I don't know this class and I don't know this class. And then I use the organize imports method, which goes out and puts in all the import statements for me for all the classes that it doesn't know about and asks if there's any ambiguity. And so it just fills it all in because I'm lazy. And again, that's all configurable in the preferences. And so that's another nice thing, too. So we'll go back to the slides, please.

So we've now set the IDE to use J2SE 5.0. And so let's take a look at some of the things that it can do. We just set the VM preferences. This is so that it's in your slide. So when you go home, you go, oh, where was that? That's where you do it. So that little circle also isn't in Eclipse. But you can see that interface and enums are now in. And so you can work with those.

Also, one of the things you can work with is generics. And so for instance, here-- We're working with an int, and we want to change it. So let's take a look. We have squares, and we're getting these yellow squiggles. It's telling us that, well, you can use ints here, but maybe it would be nicer. if you used an iterator with a generic type. You specified the type that you're using. And so if we go ahead and use a parameterized type, you'll find that appears whenever you need it in your refactorings.

And so the list for squares, it didn't fill in the type in this case. I'll show you an example in a minute where it does. So it didn't fill in the type. But you go ahead and fill in that question mark instead of the wildcard with the type you actually want.

in this case, integer. And I'd get a lot safer, smarter code. That's, of course, Java 5 dependent there, though. So to the Batmobile. Back to the demo. And here in About box... um we have this array of about labels now I guess I should ask Francois, is the person that wrote this code here? Never mind. It's wonderful. But we're going to do it a little differently.

And so just for a moment, what we're going to do isn't going to make it better, but it just couldn't make it any worse. And so let's do a list. Let's call it a label list equals new array list. And you can see there's eight of them in there, so I'll go ahead and fill that in.

I'm getting a problem here. So what's the possible problem that I'm getting? I don't have the import statement in there, so I'll go ahead, even though Bjorn has a better way, but I'll persist. Now, this is a little flaky. List labelList equals new ArrayList, and it seems like it doesn't understand what I'm saying. The fix is going to be a little bit interesting here. Change the type of labelList to ArrayList. You see the deal here? LabelList is being created by a call to ArrayList, so it knows it has to be of that type.

And yet when I double click here, One of the choices is to use the interface list, which is what I typed in the first place. But because it's not just using a string, it had to make sure that that was the list that I meant. So I apparently double-clicked on ArrayList instead of List. But you'll forgive me and we'll go on. So we can now-- one of the nice things, because we're now Java 5 compliant here, is we can use that sort of a for loop instead. And so we can say for a JLabel.

OK, named label in about label. and it's just as happy as can be. I can do whatever I want in there. So there's your new for loop as well. Not doing anything now, but again, it's no worse. So we go back to the slides, please. Peace. Home stretch. Building plugins. You can do this on other platforms. It's not the part of Eclipse that Bjorn was stressing today. And the main thing was to show you that it can be done, and it can be done very easily here on the Mac as well.

And so instead of choosing to build a new Java project, you'll choose to build a new plugin project. If you look in the plugins, you'll see that Eclipse is just a ton of plugins. And during their first couple years of existence, that was a big part of the stump speech, was that Eclipse is this very thin platform on which everything is done with plugins. And people said, well, I want to build my own. And so here you can. So you choose to create a plugin. You name your plugin. We're going to create it based on the Java project. We'll call it hello-wwdc.

And if you look at the choices here, soon we're going to say, well, what do we want to build it on top of? What do we want to use to get started with? Plugins come in different flavors. And so the choices are these. What do you want to configure it with? And for now, we're just going to pick a simple Hello World plugin. It creates something in the title bar. It creates something in the menu bar. And you click on either one of those, and it brings up a little J option pane. So here's what's been generated.

Looks like a lot of stuff. And I don't know if you go to your local jug meeting and you hear this, but it seems that in Cleveland, at our local jug, a lot of people come in and say, look how much you can do and not write code.

And that's a little scary. But here you can actually access the code that you're generating and modify it and play with it. And so here's the directory of what you've created and where a lot of the life is going to live down there in that plugin.xml file, but you'll see that what it calls is that sample action.java file.

So running the plug-in, this is kind of interesting. You're creating a plug-in. The plug-in has to run as part of Eclipse, but you're developing in Eclipse. And so what you have to do is you have to bring up another instance of Eclipse to test your plug-in in. And that's what happens at the bottom where it says launch an Eclipse application. So you'll launch another instance of Eclipse in which you are testing the plug-in that you're developing. Okay? Okay.

And that looks a little bit weird on a Mac, because at the bottom you see that extra instance in your dock, or I'm sorry, or in your dock, or in your dock, wherever you have your dock. So here's the before and after of the toolbar. Before you create your plug-in, it looks pretty much like this, and then afterwards, you can see that there's the new little guy. And this is really as easy as can be, and I'll show you that in a second. Same, that's the toolbar, same with the menu bar. Here's your menu bar beforehand. You create the new guy.

And it looks something like that. You create a new menu with a new menu item in it. So when you run the plug-in, either way, you get a little pop-up. Life is happy. Thank you. OK. If you look in the extensions, you see the sample action. That's whether you accessed it from the menu bar or from the toolbar, that's the thing that actually happens. And so here is the XML view. This is the GUI view.

I find it easier to see things here, but however you're more comfortable. If you look down here at the bottom, You can see, as I jump off the back of the stage, you can see there's the class that's called when you enable the action. There's a tooltip there, and there's a menu bar as well. And so you've got something in the toolbar, you've got something in the menu bar, and you've got the tooltip that pops up when you access the thing in the toolbar. So it's all there right in the XML file. Deploying the plugin, again, there's another wizard that takes you through that.

What's new in Eclipse 3.1 is you can now deploy the plug-in as a JAR file instead of a directory of different things, and that's sort of a neater way to distribute it. And so we can package the plug-in as a JAR archive. Thank you. And I'm not going to, because of time, we're about where we should go to questions. I'm not going to go to this demo because it's really basically doing what I just did in slides. It's following the wizards through. And so I think at this time, we'll look back. Let me say something about the plug-in development environment. One of the reasons that the plug-in development environment in Eclipse is as good as it is, is because all of Eclipse is built out of plug-ins, like Daniel was saying. And that means that every one of the teams built plug-ins is to build the Java compiler and the editor and the C++ compiler.

And one reason they did that is because it was built in a distributed environment inside IBM. Every one of the teams is in a different location. The guys who write the Java compiler are on the coast of France. The guys who write the debugger are in Winnipeg, where it's snowy 11 and a half months of the year. The guys who write the loader are in Ottawa, where it's snowy 11 months of the year. So because they were all in separate locations, they had to get that plug-in thing working well so that they could put all the pieces together. So this distributed development in the case of Eclipse really helped them actually make a better product. They completely used the plug-ins.

There's no cheating between them at all to put that together. The plug-ins, if you've done Cocoa development, you know with Interface Builder, you decide what it's going to look like, and then you create your hooks in and out. It's the same thing with plug-ins. You create what are called extension points, and so you're creating these hooks hooks that other people can call in and find out things from your plug-in at that point. And Eric Gamma and Ken Beck wrote a book that pretty much takes you through pretty comprehensively creating plug-ins. So that's pretty much a look at what we've done. If you've got a pen, I'm allowed to give you, because the O'Reilly booth has closed, I'm allowed to give you the discount code good till the end of the month for 20% off and free shipping in the U.S. if you want it. Okay.

Well, because they have an Eclipse book, but they were closed before the session's over. And so it's-- So can you use it to order things other than the Eclipse book? You can. So for Pearl Books, it's T5 WWDC. Tango 5? Yes. Whiskey, Whiskey, Delta Charlie? If we have to spell out WWC--