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 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, download it 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, 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 boxes and sort of things. If you look over here, and if I press the button right-- oh, I guess it doesn't even work-- you have 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 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, you know, it has the sort of things that you'd expect from a modern programming environment.

You can do 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 JVM -- 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.

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. 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. It shows their tests, and a few of them run a little bit slower. They run this on every single nightly build, and it shows what the performance characteristics are.

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's a few things in the runtime. Maybe the only interesting one is this Java web start. You know, 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, 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, you know, 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, you know, collections and map them over to generic collections. And 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 the code is in the right place is to make sure that the code is in the right place. 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.

Daniel Steinberg, Bjorn Freeman-Benson 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 will take you there or it will 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-- 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-- 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--

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. Yeah. 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 one is when the final release of 3.1 is.

Is that right? Well, if everything goes well, Java one will, just before Java one, the final release of 3.1 will be out, and the Eclipse download servers will be absolutely maxed out. That's the goal. Daniel Steinberg, Bjorn Freeman-Benson 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.

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 it can get warnings about or 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 get. 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. Well, actually, strictly speaking, it's behind your back. It is. 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.

Daniel Steinberg, Bjorn Freeman-Benson 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 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 JUnit test case, are most of you familiar with unit testing? Great.

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 cases 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, I think that's a great question.

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. 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 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? Okay, 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 J menu. 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.

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 JMenu item. Let's add something else in here. And so what I'm going to type in here is Help Menu, Add, O, Find Towel.

Seemed perfectly reasonable to me. I know what FindTal 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.

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 FineTowel. 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. 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 Assert True, what we're testing is, is the cell alive? And now we're back to coding by intention because there is no isAlive 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.

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. 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 setAlive 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.

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-- 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.

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. 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. One of the nicest things was you no longer need to do get content pane dot 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.

If we look at the preferences, we're actually going to set it in two different places. If you go down to the Java menu, we're going to set it for the compiler. You see the compiler compliance level. 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. 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. Oh, we got problems. We 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. 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.

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 .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 is in an 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 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,

I guess I should ask Francois, the person that wrote this code here? Never mind. It's wonderful. But we're going to do it a little differently.

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. Okay.

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'll go back to the slides, please. 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.

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.

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. 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 plug-in, 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.

You can sit-- 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, Whiskey Whiskey, Delta Charlie. If we have to spell out WWC.