Good morning, everybody. My name is Scott Kovatch, and I am an engineer on the Java runtime team here at Apple. And I want to welcome you to this session on Eclipse development on OS X. Got a lot of ground to cover today, so let's get right into it. Today we're going to cover things at about the 10,000-foot level, and then very quickly go down to about the 10-foot level. So let's give you a look at what we're going to talk about today.

So you've all come in here thinking, "Yeah, I know what Eclipse is. I use it every day," or "I've heard about it." But it's probably a little bit more than your wear-up, so we're going to talk a little bit about that this morning. We're going to talk about what is new in the 3.2 release, which just happened earlier this year.

We're going to talk about the SWT, which is sort of one of the core widget foundations of Eclipse, how it gets along with the AWT on OS X, and a little bit more about how the two actually interact. We're going to talk about some things that we've done this year in this area. And finally, we're going to have a little session about how to contribute back to Eclipse. We've got a good little demo plan for you to basically show how you can get involved in this project as well as a Mac OS developer.

So let's start off with what is Eclipse? I had a professor once in college that always said, if you have something that says intro to X, you should always start out your lecture with what is X. So that's what I'm doing today. What is Eclipse? Well, you looked at it. Hopefully you all downloaded it and had time to get it before the session started.

And we know, you know, when you go back to your manager and say, we want to use Eclipse for our project as our IDE, well, what are the good things about it? You know, it's open source, right? It's one of the more high-profile open source projects out there today. It's written in Java. It's a Java development environment, of course.

It's an IDE, right? You know, there was a time when, you know, the concept of an IDE with Java was just a-- just a fleeting thought in somebody's mind, and IDs were really expensive. and you had to pay $500 and $600 to do basic development. And so of course the big thing is it's free.

Well, what I want to talk today about is that it's more than just all those things. This is sort of the, what you see up here now is sort of the mission statement of Eclipse, if you will. An open source community, projects focused on providing a vendor-neutral open development platform and frameworks for building software. And it's that last part I want to talk to you a little bit about right now.

Eclipse, when you download it from the server, gives you a lot more than just an IDE. Of course, that's a big part of what you're getting. But, you know, we have a Java IDE. We have an underlying... And the Java IDE, we'll show you a little bit more in a few minutes in a demonstration. But there's also a component architecture underneath. This is from something called the OSGI initiative. OSGI is a specification for module loading and unloading.

and it defines ways for you to write code that can inject itself into other applications and basically an operating system, if you will, for modules and code that can load and unload your code dynamically. That's sort of it in a nutshell. If you're interested in that, you want to take a look at the Equinox project, which is part of Eclipse.org, and they've got a lot of material you can read up on that. That's sort of the foundation layer of Eclipse, And that's something you can take advantage of as well in your applications if that's what you want to do. And sort of the next level up is something called a rich client application architecture.

And the rich client architecture-- consists of a number of layers. And sort of the eight points you want to look at, if you want to look at the RCP in sort of eight simple points, it's our component management, which comes from the OSGI. You have the runtime, which is for developing applications. It also has a mechanism for dynamic update of your application. So there's an entire infrastructure for installing new pieces of your application from within itself.

Let's sort of go through some of these layers in a little bit more detail. At the topmost level is the user interface layer. And these are sort of the high level things that actually Eclipse uses itself to implement Eclipse the way it looks to use it as an IDE. We have a number of definitions and plugins for defining your own editor. So you can define an editor for your specific language or your specific, you know, whatever it is, is important for your domain.

perspective management so that you can group together a number of views related to a given task. So for example, in the IDE, they have a Java perspective, which opens up a series of views for Java editing that makes sense for a Java developer. And so one level below that, which I've sort of implicitly mentioned, is the view layer, which defines the individual pieces that go into that perspective. So we have an outline view for looking at your code.

the text editing views, we have the console view, and we'll see some of those in action in a little bit here, but that's what this layer is doing and defining for you as part of the RCP layer. And finally, the workbench, which is sort of the top-level collection that sort of gives you a management layer for all these perspectives and views.

So the next level, going over to the left, which is more of the module management side of the RCP, the runtime layer is what takes care of managing extensions, of managing the extensions, which are sort of a level pulled up from the actual plug-in. But then we have the notion of an application and a product. And the RCP makes a distinction between the two, whereas the RCP is, I'm sorry, an application is a runnable unit. Eclipse, for an example, is an application. Thank you.

Well, a product is a combination of an application and a number of, for example, unique branding things. So a splash screen, the unique icon for your application, and just sort of extensions to help you make a unique product based on the RCP. And that's found over in this layer here. I'm sorry, going back over to the UI side, J face is a layer that basically gives you a higher level way of managing the user interface.

We'll jump ahead here to the SWT, which is at the lowest level, which is basically the widget library that all RCP applications are based on. We'll talk a lot more about the SWT today. But right now, what you want to know is that that's your basic UI toolkit that all RCP applications are based on. And if we-- Go back over here, back up to Jface. Jface is a layer above the SWT that is a pure Java layer, but it also lets you manage SWT widgets a little bit more. Provide something of a model and controller layer, as opposed to just the view that the SWT provides. There are classes for managing list data, tree data, things like that. And basically, it's an attempt to provide a view, like I said, more of a model, actually, than controller. but sort of a model to work with the SWT views. And finally, at the lowest level is this OSGI layer on the left. And that's where you find all the definitions for what are plug-ins and the bundles and services that you advertise to an application. And it manages the loading and unloading of those plug-ins.

All right. So who is using Eclipse? I mentioned we said you can use Eclipse for more than just an IDE. Well, some pretty big names are using Eclipse right now. in no particular order here. IBM, of course. Eclipse is not an IBM project, however, IBM is using Eclipse significantly in a number of its products. So you're going to see it now being used for WebSphere, for example, and some of their other products. PHP Eclipse is an open source project that is writing a number of plug-ins to do PHP development in Eclipse, as well as providing the custom editors and a debugger for PHP. And at the bottom right is Wolfram Research and Mathematica. And I thought this one was particularly interesting because I think just about everybody here has heard of Mathematica at one point or the other. It contains a scripting language for dealing with mathematical formulas. But what they've done is they have produced a collection of plug-ins that they call the Wolfram Workbench. and this is, I don't believe this is released yet, but we were able to get a screenshot to show you what's going on here, and what you see up in the top left is, I'm sorry, sort of the bigger layer here, this is a screenshot of debugging a Mathematica session. So you've written your code down in the center left there. You've written a couple of functions, and we're going to step through that code and debug it.

So at the top right, we see the variables that have been defined. On the right is an outline of the code that you've written to the left. So you could click on those functions and just jump to the function. And down below is a console that shows the results of interacting with the mathematics engine.

And at the top left is sort of the project view. What they have done is they have adapted a Mathematica workflow to sort of the Eclipse paradigm, if you will. And they've defined a plug-in that defines what a project means to Mathematica. They've written plug-ins for the debugger so that when you set a breakpoint and that breakpoint fires, they know how to talk to Mathematica and say, you know, wait a minute, now let's look at the data. data. And this is sort of an example of something you could do in your application if this is within your domain specific needs. This talks to the existing Mathematica product.

They haven't actually rewritten the product to put it into Eclipse. But what they've done is they've written a development environment that talks to their existing product. I thought this was a really interesting example of using Eclipse for, it's still an IDE, but it goes beyond just downloading it and using it to write Java.

All right. Let's move on a little bit to talk about what came out in 3.2. Eclipse 3.2 was also known as Callisto. If you went to their download site and you saw some information about Callisto, it was released at the end of June, officially. And this was the simultaneous release of 10 projects. Now, that does not mean that when you download Eclipse, you get 10 projects worth of code. That would be a huge amount of code. If you've downloaded it already, you've got about 110, 115 megabytes. But the core of Eclipse is the IDE and the OSGI and-- RCP layers that I mentioned earlier. But there are also a number of other things you can get. You can get a graphical framework, you can get a visual editor, there are reporting tools. There's also a C toolkit.

and you don't need all those things just to run Eclipse, but What is important about Callisto is that they were all released at the same time. So in the past, you may wanted to use Visual Editor, but it wasn't quite released yet, so you were using a late beta. But this other thing that you relied on was actually done. And so now they've harmonized everything and released it all at the same time. So everybody's starting from the same base. Mac OS X is now considered a supported platform of Eclipse. This is not true for-- I believe it is not true for most of 3.1. But with 3.2, anything you file, if you file bugs on it, they will officially take a look at it because they support OS X.

So to sort of give you an overview of what's going on in 3.2 and sort of an overview of the Java IDE itself, I've asked Daniel Steinberg from O'Reilly Media, who's done a couple of interviews with some people using Eclipse. And he's also done a fair amount of writing on Eclipse itself. So Daniel, come on up and let's see what's going on here.

Thanks, Scott. Thanks, Scott. I get to take you out to recess, so if you've got Eclipse loaded, open it up and let's play around a little bit. From the welcome screen, let's go to the workbench, which is this little guy here at the right. Thank you. And this should be a familiar view. If you saw Ben and James talk at the Java overview yesterday, they talked about NetBeans and IntelliJ's idea.

Here's another one of that trio that's so strong on Mac OS X for Java developers. So let's go ahead and create a new project. So from the File menu, create a new project, and let's call it WWDC. Now, this gets me all the time. You see a blue, so you want to type it in. This is not asking you to type in the name of your project yet. Select the type, so select the Java project. And at this point, type in WWDC, and down here, you'll see that you can choose which JVM you want to target with your project. And you'll see that it's pulling them out of your system folder and so that you're getting one six if you've got that loaded.

So within WWDC, I can either right click or I can go to the file menu and create a new package within it. And again, you can do this through wizards, or I'll show you in a minute something new in 3.2 that actually is kind of mind blowing and fun for demos. If you go to my.mac folder, it's dimsumthinking, you'll see a little clip file that we weren't able to post elsewhere. So we'll be using that in a little bit. So let's just call this demo. Well, Eclipse is warning us that this is pretty much discouraged. You can call it demo with a capital D, but that's discouraged. And of course, we know that we should use lowercase letters. So not only does it know the absolute things that you get out of strong typing with Java, it also knows sort of conventions too. So let's call this package demo. You see it here on the left side, and it's white because there's nothing in demo. So let's put something inside. So for instance, let's-- See what we can put inside. We can put a class, an interface, a num.

All the things that came with 1.5 are now supported. If you look at JUnit test case, no, we're not going to do JUnit again, Alan. But if you look at JUnit test case, you'll see that they now support JUnit 4, and that's new in 3.2. And so if you click over to JUnit 4, you'll see some things change in this interface. You've got two new methods that are available. And if you go back to 3.8 for a minute, you'll see that with JUnit 3.8, you inherit from the class test case. And with 4, you don't. So let's just create a fake one for a quick example here called this demo test.

Now, we've got another warning here that the superclass doesn't exist. And Eclipse makes it real easy for you. It says, you know, click here and you can add JUnit 381 to your build path and it brings up the dialog. So life gets much easier. I know it's religious whether you use a text editor, whether you use VI or Emacs. I know Emacs is an IDE for many of you, but this does anticipate many of your Java needs.

So now we have demo test in here. And if you look here at the package, it's now colored in yellow because the package now does contain something. So that's one way to create a class using the wizard. What I'd like to show you now is something new that highlights the fact that Eclipse understands One of the benefits of Java, you hear a lot about dynamic languages now, and those advantages, and the duck typing, and you just send a method, and if it knows what to do, it does it. The nice thing about Java is so much is known at compile time. And so what Eclipse does is takes that further, just as these other IDEs, and says if we can know it at compile time, we can actually know a lot at develop time. So if you look at this code snippet here, I'm just going to copy it, and I'm going to paste it right on top of this folder. Now check this out. - Yeah. It knew to create the package. It knew to create the class inside of it.

And then it cut and pasted and syntax highlighted the code. So there's a lot of intelligence going on. It's picking all that up from the code that you put in. And if you look at the hierarchy, here's the project that we just created. And inside of it is the package that was just automatically created. And so there's this one to one. Now, I never compiled this, but you already see that there's a class file here. So Eclipse is doing a lot of compiling sort of as you go.

Are we happy? Gosh, yes. Go on. And so if we go to run this-- We'll run it as a Java application. And it's a simple-- squares a bunch of numbers in that array, and everything's lovely. So let's make some changes to show some of the other new features that came with Eclipse 3.2. Let's change this i to j++ just to decouple this. And you'll see that I get a warning here, because I've introduced a variable, and I've never told you what that variable is. So let Eclipse do some of the lifting for you. Let's click and see what's wrong with it. If we just hover over it, we should get the message that j can't be resolved. And so let's see what Eclipse thinks we should do about it. Well, one of the things we could do is create a local variable. And you see in that yellow pop up that it even shows us what this is going to look like after you've done it. So let's go ahead and create the local variable. Eclipse still isn't happy, now what? Well, we've created a local variable and we're gonna increment it in the for loop, but we've never initialized it. And so Eclipse encourages us to initialize the variable.

Eclipse is now happy. Now you see these little boxes at the end? This is another nice feature. Boy, I don't remember what this used to be before, so if I hover over it, I can see the quick diff with what I used to have in the saved version.

And so you can see the sort of maroon here shows a new line, and the gray box here, or I don't know what color it's supposed to be, shows you a changed line, and you can go back and see a quick diff. Now once you've saved it, so let me control s and save this, that goes away because there's nothing to quick diff against. I guess that's where time machine will have to come in. So let's go ahead and run this. And this is wrong. Zero squared is zero, zero squared is one, zero squared is four. The lesson here is just because Eclipse has helped you make this valid Java code doesn't mean that it's made it do what you want it to do. So you still have to have sense about you. So let's Let's get rid of this line that Eclipse has helped us write, and let's uncomment out this line where we've declared the variable there.

It encourages us to save it, and now the program is right again. So Eclipse will make sure that things are valid for you. There's some other nice features though. Now that I've decoupled the J from the I, let's go to the source. and I'm going to clean up. Now this is kind of magic. And in the developer tools demo, you saw a lot of this is coming to Objective-C through Xcode. So here's the stuff that does the same things for you for Java. So you can do things like, well, let's look at clean up. One of the things I can do is convert for loops to enhanced for loops. So let's go ahead and let it do that. When I click Next-- I can see what the before and after looks like. And you can see that it's introduced a new iterator element. And it's replaced by for loop with the for int equals to this regular iterator that was introduced in Java 1.5. And so if I go ahead and finish that, it's made the changes.

Now another nice thing you saw Ben do is he showed you that IntelliJ is pretty smart. And so what I've done here is I've uncommented the line up here with element in it, because now I have three instances of the name element. You can see from the highlighting that Eclipse knows the difference between these elements and this element here. And so if I do a refactoring, and if you click on Refactor, one of them is Rename. And so I can rename this to Square.

Eclipse is smart enough to rename these two elements square and not this one. And so you're not just getting a grep. You're not just using a text editor anymore. There's some deep understanding of what your code means. More? Oh yes, let's go on. Okay. Yeah, I'm just mugging for you guys, right?

OK. So let's see. Why don't we-- we've already replaced i in that line above. Let's change the system out. to this one. So I've gotten rid of my j variable completely. Well, no I haven't. I've got this warning here. Now this is pretty slick. It says you've written a variable j but you've never used it. It helps you clean up behind yourself and know that this variable is not needed anymore. And so one of the things I can do is remove the declaration. I choose to do that and now j is gone completely. So it's never used. Why are you bothering to declare it? And so that's a nice way of removing the cruft from your code when, you know, people things later on down the line. So I've got a call into MathSquareRoot. Why? Cuz it's a hokey example to show you this next thing. It's another new feature with Eclipse.

When you make calls into libraries, and the library function doesn't do what you want it to do, boy, it'd be awfully nice if you could fix that. Now with obc we can do decorations, we can do all sorts of tricks to say, "Here's what I really wanted that method to do." One of the nice new refactorings in Eclipse is I can introduce indirection. And so in the refactoring menu, you see "Introduce Indirection."

and it says what do you want the new method name to be? Well I'll keep it as square root And I'll hit the refactoring. And now instead of calling math.square root, it calls into our local version. And by default, the local version does what this function used to do in the old days. And so now I can make my changes here if I want. And so that's kind of nice. You can fix library functions if you want to do something like decorate a text field, but you want to do it for every text field. Introducing indirection not only changes the call, but it changes all the references to the call too. So that's a nice new feature.

All right. So let's look at some templating here. And so let me introduce the other snippet. I'm just doing a simple shape. I'm doing a square. And so you can type this in yourself, or you can just cut and paste it. I just love this feature. So I'm going to cut it, and I'm going to paste it right here in the Package Explorer.

And so now I have a shape, I have a square. Square doesn't do much. It's got a side. I set the side. So let's see. There's a lot of typing I would have to do, but you know what I'd really like? I'd really like some getters and setters.

So I go to source code, and there's an item that says I can generate getters and setters. So what do you want to generate them for? Do you want to generate getters and setters, or you can choose which ones? So I say OK. I automatically have my get and my set. Actually, let me go back a second. I want to do this a little differently. Let me do it again. Generate getters and setters, but I do want to generate method comments just to show you this next thing. Okay.

And so I want to introduce this notion of category, because you've got getters and setters, and then you've got methods that really do something. And you don't want the getters and setters cluttering up your API, because that's not the method you want to be concentrating on. And so I can introduce this new @category tag. And Eclipse will pick this up if I write getter.

And I'll do the same thing for the setter. Here's another nice thing. I'm hitting Return. And notice when I hit Return, it knows I'm still within the comment, so it indents and it gives me the star. It saves me typing there. At, it pulls up the things that can be added. Category, and let's call this Setter. Now, Getter and Setter never existed before as categories. I just made those up. We can use any name that you want to collect your different methods. Again, it's sort of like how you group things if you're writing in obc. So let's save that. And let me bring up the outline view.

and you can see the getter and setter now appear after the name. But that's not the fun part. The fun part is if you click on this arrow, you can decide which of the methods you want to show. So if I want to unshow the getters and I want to unshow the setters, all of a sudden I haven't cluttered up the visible methods that I get to mess with. Scott, how are we doing for time?

Okay, I'll show you just a couple more things, but I think that's a nice cool feature too. The methods still exist, but you know, we know they exist. We don't need to have them right in our face. Let me create a quick subclass of square. So let's create a new class, and let's call it, I don't know, tiny square, and let's let it have square as the superclass.

So it extends square. Something's wrong, so I check out to see what's wrong. Let's see, what are you complaining about this time? Do you want to add a constructor? Oh, sure. So it's added a constructor. This still isn't quite right, because a tiny square should do stuff that the square does. Well, by default, it does. So I have to tell it explicitly what to override, and if you look here in the source file, you'll see that I have override or implement methods, And when I do that, a tiny square is a square, but it's also an object. So I can decide which of the methods all the way up the hierarchy I want to override. In this case, the area of a square is the area of a square no matter how big it is. But maybe I want to do something different when I draw it as a tiny square. And so I'll click there. And now I've overridden that. We have the same collapsing that we saw yesterday with the other IDEs. Here's a nice little thing. See that up arrow there? That up arrow says that you've overridden the method in the square. And if you click on that, it takes you to the method that you've overridden. So you can see and go back and forth to the relevant code.

You'll also see the to-dos here. The to-dos appear with this little checkbox here, or if you bring up your task list, you can see all the to-dos that you have to do there as well. And so that's just a quick tour through Eclipse and some of the new features. Thanks. Thank you. Thank you, Daniel. All right, so I hope that gives you a feel for what you can do with Eclipse.

The thing about messing around with a new environment is that it can take you easily two weeks just to look at all the great, cool things, and once you do that, you've forgotten everything you've learned in the old IDE. Well, for me, anyway. Go ahead. All right, let's move on a little bit to talk now, going a little bit lower level, talking about the SWT and the AWT and OS X.

So the standard widget toolkit, SWT, what is that? That sort of gets thrown around when you hear Eclipse as well. And again, this is from the SWT page. Efficient portable access to the user interface facilities of the operating system in which it is implemented. Now, behind that statement are a lot of, I don't know, assumptions, if you will. The SWT is built entirely on the native toolkit on a given platform. There's no peers. There's no, you know, no theme, no extra stuff, if you will. It's a thin layer over the user interface toolkit.

This is a different philosophy than swing. You know, if you ask the SWT guys, that's what they'll say. This is a different philosophy than what swing did. That's it. No agenda, no politics, no nothing. It's a different way of doing things than what's funded. That's all it is. - That's all. There is one API across all UI toolkits. That means GTK on Linux, Win32 on Windows, GTK as well on Solaris. There's our QNX, which is for embedded systems. And OS X, that means Carbon. They use the Carbon APIs to implement the SWT.

So the SWT and the AWT are meant to get along. You should be able to use-- open up an AWT window in, you know, from an SWT application, and it should just work. That wasn't always true on OS X. For a long time, we actually started out hostile to the SWT. If an SWT application started up, it starts up on the main thread or the first thread of your application. You try to use the AWT, boom, we just throw an error. You know, you started up wrong, go away. We don't wanna talk to you.

And as I was thinking about the history of this, how many have seen Seinfeld? Right? How many saw an episode-- well, actually two in the early seasons with Keith Hernandez, the boyfriend? All right. Well, the relationship between the AWT and the SWT is pretty similar. You can't stand these guys. You give them their number, they don't call. Why do they do that? Right? All right. And Elaine's response, I'm sorry, honey. And that was sort of Apple's response to people who complained about this for a long time. Sorry, doesn't work. That's the way it is. Live with it.

Well, we moved along a little bit. You could use the AWT if you had turned on AWT's headless mode. Set Java ought headless equal true. Now you could use dimension, point, a few things like that. That will let you do some image processing. That's better. Well, we've been this way for about two years now. So the relationship moved a little bit further now. Hey, you want to see a movie on Friday night? Have you seen JFK?

Sure, that would be great. And that's sort of where we were for a long time. We acknowledged each other's presence. We'd say hello to each other. That's about it. Well, earlier this year, we released a version of our Java that would allow an SWT application to create a window. You can create an AWT frame. The two would live in the same application. Things are a lot better now. We're back to the state where I said before, where this should just be a normal part of things.

He wants me to help him move, but I don't feel right about it. That's a big step. That's like going all the way. Well, yeah, that's about right. We're making that final step here. So what was that last step? Next thing you know, you'll be driving them to the airport. I'm not driving them to the airport.

And this metaphor falls apart because actually they break up and they don't want to see each other anymore. But we don't want to do that. All right, if you've been following this whole saga, then you know what this number means. 67384, this was the bug in their Bugzilla system that said the SWT-AWT bridge was not implemented. This was not the SWT team's fault. This was our fault because we never provided a way to do this. Well, we've taken care of that. We've implemented it.

And we did that earlier this year with something called the SWT Compatibility Pack. We released that at Java 1 this year. with great ceremony, if anybody of you were at the Mac OS X BoF at Java 1. And this is the AWT support for the bridge. Got an add-on pack that you would install into Java 5. Did not modify your installed Java. And it did the-- it does require Java 5 release 4, which was released shortly before that.

And I'm going to show you a little bit about what it does. This is not exactly an exciting demo, but it gives you an idea of what we were trying to accomplish. So I'm going to go over here to this example. And all I've done here is I have taken the-- snippet 135 from the SWT snippets page. And if you get some time, you might want to look around there because the snippets page consists of a number of test cases that basically show you how an SWT widget works. So sort of the thinking is if we have 10,000 snippets that are small, compact, and explain the API, that's at least as good or better than documentation. Not that you don't need documentation, but if you're like me, I like to read code to understand what's going on. So here's an example of what's going on with the bridge.

And what we have here is-- we'll look down here, which is where the action is. Down here is where we create an embedded shell. I'm sorry, we create a shell and get ready to embed an AWT frame inside of it. So we make up a collection of SWT widgets, and then down here we make an AWT frame that will be embedded inside that composite. We're going to add a text field and show it in the window. And we'll do another one down here that creates a J table, puts that inside of a panel and inside of a frame. And then finally an AWT label. And I will run this.

Here we have our snippet application. And this is just a simple file browser. This is an SWT tree view over here on the left. And we'll sort of walk down. And we see this is just a SwingJ table with the Aqua look and feel. I can resize the columns.

expand that and as I click on that it updates the model over here on the right and I see my path up here and sort of just as an example of some SWT widgets as well, here's one of their buttons which brings up another shell which is like a modal dialog and so you know very straightforward. I mean I'm using the scroll wheel and because that's a native view it just works, there's There's no extra work for you as a developer to get that to happen.

Um, and that's pretty much it in a nutshell. I mean, I think it's important to note here that, um, SWT-AWT bridge also implies swing. So you can write if you've got an old swing component that you need to use, or you bought a package and you don't have access to the source, you want to wrap it up and put it inside an SWT plug-in or an RCP application, you can do that.

And what you can see here is that when you do that, it's gonna look right. That's sort of the message here, and it's just gonna work. All right, so I'm going to quit that. And you will notice that our application is hung. I'm calling that out for a reason, because we're going to go back to the slides now.

And I want to let you know that when we release this and it's out there, there are a few things you want to be aware of. First of all, keep in mind that the SWT event loop is the toolkit thread. The SWT is pulling events off with Carbon and dispatching them to Windows directly.

Because of that, we have a rule in the AWT that you should not manipulate AWT objects from the SWT thread or the toolkit thread. This is all well documented in Technical Note TN-2147. I recommend that you go look at that if this is something that-- if you're going to develop a plug-in or anything that's going to use the bridge, because that's got lots of good information. As you're reading through that Technical Note, keep in mind that when you're in SWT code, think of yourself as in the Cocoa layer that that document talks about, or in the Cocoa thread.

All right? So that means that-- Sorry, back up one step there. So that means you're going to need things like invoke later when you call an AWT object, when you make a call to manipulate that. Don't bring up a modal dialogue from an SWT button, because once you do that, nothing's dispatching events anymore and you're going to hang. You're going to get a nice spinning beach ball. Those are the two main things you've got to look out for.

Right now, you've got to use system.exit if you're writing an SWT application. Don't do this in a plug-in. All right? Nobody wants your plugin bringing down Eclipse. You don't really need it in Eclipse itself. But if you're writing a standalone application, you will need it for a while.

The application pack-- well, what we call the application-- the SWT compatibility pack is built into Leopard. No additional downloads will be needed. I do know it's in Java SC6. I think it's in Java 5. After testing yesterday, I'm not so sure now. But it will be in the final version. There will not be any extra downloads needed. We're just going to build it. Build it in. In Tiger, it will be in our Java SCC. It's in our developer previews already. It's already built into that. And that will continue to be the case down the road.

Things I'm describing here about system.exit and the toolkit thread and those issues, we consider those bugs. We know about them. We're working to fix them. We hope to have it taken care of by Leopard when it finally ships. We know about this, but keep in mind that it's largely a compatibility thing with Windows to do it that way. If you look at some documentation on the AWT, they will also tell you to, you know, if you're using JNI, don't manipulate your code from Windows, from Win32 event handlers, for example. So what I'm saying is technically consistent. You're often lucky that it works.

on Windows the way it does. But we're going to do our best to see what we can do to fix it. Please use it. File bugs on it. Whatever you're finding. Differences in behavior. That's mainly what I'm interested in right now is differences in behavior for Windows and other platforms. For example, we know that there are some focus issues that we've got to work out. but it's there, we're gonna keep maintaining it and updating it, and so, you know, we want to continue to let you use this product on Mac OS X 'cause we think it's important.

All right, so that's a little bit of the details on where we've come so far. Part of building that bridge layer involved me contributing a chunk back to Eclipse that implemented the SWT portion of that bridge. And in doing so, I got to learn a few things about how about how the contribution project process works in the SWT. So the SWT on Mac OS X We know a lot of things about it, of course, right? It's open source. I've already told you it's based on Carbon. You can go get the code, and you'll see what it looks like, how it's using Carbon.

There are a few things that are less widely known, for lack of a better word. If I want to get involved, you know, the standard mantra in an open source project is, if you don't like it, submit a patch, right? That's what real programmers do in an open source project. You submit a patch. Well, okay. How do I do that? No, no, no, no, no, no, no, no. I don't know. You just learn, right? Otherwise, you'll never get into that, you know, inner circle of people working on the project. How can I contribute?

Well, you do this, that, and the other thing. I don't know. Well, today... I had the luxury of having somebody show me how to do this. And I thought it'd be beneficial for all you guys to learn how to do this too. So I have invited Steve Northover, technical lead from the SWT and Selenio Quartier, one of the engineers who works on the Carbon pieces of the SWT, to come up here and we're gonna show you how to contribute back to the SWT. We're gonna fix a bug right here and show you the process. And hopefully you can get involved too if you're a Carbon developer. So guys, come on up.

switch to demo? We are there. Well, first things first, I'm going to take these shoes off. My shoes GP'd this morning on the way. Goddamn Microsoft shoes. So we're gonna fix a bug. So one of the interesting things about Eclipse and SWT is it's open source and all of the work happens out of Bugzilla. And when I was with Scott at Java 1, we just went searching for a bug for Scott to fix. Scott's a Carbon expert and so you know the place where you find a bugs to fix is in Bugzilla. So go to Bugzilla and we were just searching around for something effects and so we looked for cursor. So, but select the OS Mac, right, so that we don't get every cursor bug in the world.

And we kind of looked down the menu to see what's a good one. And column resize cursor shows it wrong position. So we just grabbed on that one. One of the things you might want to-- why would you want to contribute to SWT or Eclipse? Well, you're using Eclipse, and there's a bug, and it's driving you crazy. And it's not getting fixed fast enough. Or you have an RCP app, and it's holding you up, and it's still not getting fixed fast enough. And the best way to get something fixed is the squeaky wheel gets the grease. And if you embarrass us with code or some patch or a fix, that causes us to go into action.

Bug Report comes with a nice test case in it. So we grab that test code and paste it in. It should show the problem, whatever that is. I suppose we can go through there. I think an important thing to note is run the test case. Just sort of an aside here is that Steve looked at it and said, oh yeah, we'll just go run the examples. And that's got a table in it. We can just do it there. So we ran it. Oh, can't reproduce it. Won't fix. Works for me. So we're on the verge of marking it as won't fixed. And then, oh, maybe we should actually run the code. Yeah. So very important.

So one of the things you'll notice that Selenio is doing here is he's building and running it, is that-- We're not showing it to you here, but one thing you have to do is set the build path as part of building anything that uses the SWT. Before we go on, did everybody have a chance to download the SWT? Did anybody try to do that or take a look at that? Okay. If you're able to follow those instructions, you should at least be well enough along that you can run a sample application like this against the code that you just downloaded. So if you set the build path to include the org-eclipse.swt project. This is just going to-- you know, all the imports will resolve, and you'll be able to run, and here we go. So now let's see if we can reproduce this bug. Oh, look at there.

We were on the resize portion of that table view, but now we're sort of off and up to the left, up and to the left a little bit, and it's changing. In fact, actually, it's doing more than that. It's changing at the wrong place, but it's also flickering back and forth to a pointer. So when I see that sort of thing, it's like, you know, it looks like an off by the inset, right? Because it's changing. If I move that table up a bit, the resize bar would be in the right place. Right. So how do you set the cursor in SWT? Well, there's a method, control.setCursor. So Selenium will go and get that.

Go to Control, which it's there already for you, and get to SetCursor. Somebody made a-- OK, fine. And there's a great wad of crap. And oh, look at all that Carbon. I wish I had Time Machine to go back and have it all be Cocoa. Time Machine actually could be really useful to go back to high school. But anyways, down at the bottom after all that rubbish is Handle Control SetCursor. And that's the Carbon API that changes the cursor for you. Real quick, let's call out how you're using Carbon here directly.

You see these OS dot whatever. Those are direct calls into Carbon. If you look down underneath, there'll be a.c file that has all these Carbon API calls. And all we're doing is we're taking Java data types, marshalling them to Carbon call, calling that call directly and coming right back. One for one. And so that's one of the reasons why Scott could help out right away. Because, I mean, it was just a bunch of Carbon calls. He's a Carbon expert.

And he could see what-- I mean, Modulo, the piles of goo, he could see what was going on in the code. And so we do references to this guy. So I know in that example code, we weren't actually setting the cursor. The cursor is being changed automatically by-- or it's being changed inside of Carbon. So do references of this thing.

And I happen to know that it's actually in this method in Display Run Inter-Exit that runs as part of the event loop so the cursor gets set. So we'll go to that one. Are we on it? Yep. And there's a bunch of mouse still down and blah, blah, blah, blah, blah. But there we're getting the window bounds. And we won't bother going, but we can go get the documentation for handle control set cursor. And it's going to tell us that under compositing mode, it have the point in terms of the control, not in terms of the window. JOHN LUTHER: Of the HIV, as opposed to-- yeah. So there's our bug right there. And we had the indication of it because it's sort of off by the size of the inset. So Selenium's going to go and grab the fix, which we could We could generate if we wanted. You'll Food Network's method of code demonstration here. We go to the oven and bring you the final copy. Pre-baked.

And I guess we have that. We run both compositing. We've foolishly called the variable that controls that high view, which would be called compositing or whatever. But anyway, so the toolkit runs compositing and not compositing, because I guess we ran before there was. That's right. You've been around long before the new HIV modes were around. Although Eclipse wouldn't officially support us. We've been running-- like, call it-- we had a Mac port for quite a while. But anyways, so there's the HIV compositing case. And we convert the point and then send that off to handle control set cursor. So Sonia will save that stuff. What we were doing effectively was a global to local in the old port thinking. But now we have to actually convert it to the coordinate system of the HIV. So that's what we're doing here. And unfortunately, there's a very cool call in 10.4 that does this in one step. But Eclipse, remember, Eclipse works back through 10.3, right? 10.3.9, at least? Yeah, we-- Officially. So any patches you make need to work against 10.3.9, at least. So we save the code, rerun it. Notice we're not building it. We don't build any C files or nothing because there's no C code there. It's all the one-to-one mapping. And there we go. And we move. Hey, look at that.

You guys are good. All right. So that's typical. There's two managers and one guy doing the work. Yep. Is this mic even turned on? No. So there, I fixed a bug. But did you really fix it? Well, did I really fix it? OK, so what else is wrong? Anybody from the audience? Did we actually fix this? We fixed the test case, but-- Well, we can check it in. That would be fine, too. But there's a bunch of things. I mean, just fixing the one case, did we put other stuff out? There were other references to handle, set cursor, control, whatever. And we need to check all of those references. If we made the mistake of not converting the coordinates in one place, we may make the mistake in multiple places. So there's that.

And then did we break setting cursors for tables or for every control in the universe? So there's a bunch of more. Also, we need to run the JUnit test case to see if we put something else out of whack. So there's a bunch of more stuff that needs to happen. But as a guy contributing to Eclipse, like just random person, you made the patch, you fixed it, and you want to give us the code.

And if you submit a patch that fixes the test case, we will take that patch. But we'll also evaluate it in terms of the whole toolkit, Which, as a guy, until you're more familiar with a large code base and until you're more familiar with it, you're not going to know all the places where you need to change.

However, getting to the place where the bug is and showing us the fix is 99.9% of the work. And it's amazing, right? And in this particular project, I have noticed that if you submit a patch that's not 100%, Steve's actually pretty good about writing you back and saying, well, you did, but you didn't do this other thing over here. He's very nice about it. This is really my first involvement with an open source project, and that was encouraging to me. So I don't know.

I think it's a good thing. The ultimate goal is that your patches get better and better to a point where it's just a matter of checking in the code. And at that point, when the patches are right and all the cases are covered, the person is really familiar with the code base. And at that point, we vote for commit rights. And it's like three committers have to say plus one. You vote for a commit right. And then it's because it becomes more of an annoyance to submit your fix to go and, oh, Scott knows what he's doing or whatever. Go and change the code and fix it, right? But that's a relationship that is, you know, it's actually a personal relationship with the individual. Like it's commit rights are not for Apple. The commit rights are for Scott or, you know, the individual.

So they go with the individual. So we've had people with commit rights leave, like some from IBM leave and go to other places. they don't lose their commit rights. So let's attach the patch. So we have to build the patch. Let's go and view. So we did a right click on that, go to Team Create Patch.

And the way Bugzilla works on OS X is that you've got to write it out to a file first. So we're going to save it out to our desktop. And you'll notice here that we're actually hitting the CVS server, getting a diff against the latest stuff, and now putting that on the desktop.

And now it's time to actually attach that patch. So he's going to create an attachment. Got to create-- got to log in. A login account for Bugzilla on Eclipse is free. Anybody can have one. And it's useful if for no other reason that you get to attach yourself as a CC on a bug, so that you can watch the progress of it. You got typers anxiety? No. All the people watching your every keystroke? There we go. Yay. Hey, all right. Woo hoo. So we're going to go find our file, pick that patch.

Don't forget to mark patch. It will complain. OK, we can put in the comments that we can say-- we didn't check all the references. Right. This fixes the bug. This fixes the bug and that sort of thing. But I mean, there was a slight chance that a committer would have found this bug and fixed it before this presentation, which would have been disastrous because it's all live. But we could have unfixed it.

All right, now we go back to it and we'll see it over there. So the owner of the bug gets a notification. I bet you it's Selenio that owns the bug. Yep. I bet you. So you got a notification. There we go. So. All right. Message to himself, but anyways. Okay. There you go. That's sort of a look at what a patch looks like. It's basically a CVS code.

So that's how you do it. I think everybody in this room is capable of that. And so that's something you can get involved with. Hey Steve, you need a ride to the airport Thursday? Okay. Nobody watches Seinfeld, I guess. I don't know. All right. So in summary, as soon as I find my clicker.

The big thing to let you know is that Eclipse is more than a Java IDE. It's free, you can download it, there's lots of other stuff you can do with it. A lot of companies are building products on top of the RCP and the layers of the Eclipse. 3.2 is now available. This was a simultaneous release of 10 separate projects. Go take a look and see what's out there. And Mac OS X is supported now. So you can build an RCP application for the Mac.

Apple is committed to making Eclipse great. We've already shipped an update to make it work on Tiger. We're building it in the Leopard. We are contributing. We're gonna support the SW team as best we can. The Carbon guys are involved as well. We've got them looking at things and providing feedback as well because for everything that I look at, Eric Schlegel and Guy Fullerton look at it and just say, "Oh yeah, that's it." So as a company, we're committed to making this work. You can help out too. That was the big message for the last part of our session today, is that it's possible for regular guys to get in there and get your arms dirty and make changes and contribute back to the project. Thank you.